はてダはじめて半年たったのでちょっと振り返ってみる

この日記を書き始めたのが４月なので、今回の２２回目のエントリーで約半年を迎えることになります。文章を書くことも含め半分は勉強のつもりで始めた日記ですが、自分の書いたメモですら何を言ってるのか分からないような文章を普段から使っている身としては、なかなか苦痛な作業です。
Google Analytics で確認する少しづつ上昇してくアクセス数をささえになんとか続けられています。
と言うことで半年の間にやってきた事をちょっと振り返ってみます。

JS 自分ライブラリの検討

昨年、Seasar2 の Teeda を採用した際、UIまわりにホットエントリに登場するような JS系ライブラリを適用したのですが、その時強く感じたのが、ミニマムな必要最低限の機能のみを持ち、必要に応じて( jQuery のプラグインのように ) 独自拡張が自分でできるようなライブラリが欲しい、ということでした。

高機能な JSライブラリはたくさんありますが、実際業務で使用してみるとかゆい所に手がとどかない状況になったりします。そんな時、

- 多機能ですごそうだが、実際は本質的な機能しか使ってない（し、学習にあてる時間がもったいないので活用しきれてない）
- かゆいところを解消しようとソースを読むが、多機能ゆえにコード量が多く解読が難航する
- 解消されない場合は（時間もないので）それを補完するような他のライブラリを適用しさらに太っちょシステムになる

という状況になります。（いろいろ試したくて意図的にたくさん導入した面もありますが。。）

で、先に言ったような自分で自由にいじくれる自分ライブラリが欲しくなる訳です。

その後 jQuery を使ってみたところ、各所で言われてるようにその利便性がクセになり、jQuery をラップするような独自ライブラリがいいな、と思うようになりプラグインについて調べてみました。

jQuery のプラグイン開発は jQuery オブジェクトにメソッド（関数）を追加するだけ。だから手軽に作れますとの事…

jQueryは、プラグインで手軽に機能を実装できるのが特徴です。プラグイン・ディレクトリ（Plugins | jQuery Plugins）に沢山のプラグインが公開されていますが、作り方を調べてみたら、かなり簡単に自分でも作成できるよう。以下の記事は分かりやすいチュートリアルになっています。
jQuery For Programmers: Part 1
jQuery のプラグインを作成する - GoodPic.Com

自分ライブラリの実装の指針として、

- 1.本質的な UI 周りの機能の基礎を持つプラグインがまず必要
- 2.必要に応じ 1. を継承又はラップしたプラグインを作る

と考えていたので、JS の prototypeベースな OOP で書こうと思っていたのですが、「オブジェクトにメソッドを追加するだけ」＝「プラグイン開発」だとするとこの思想にマッチしません。

jQuery のメソッドチェーンを生かしつつ、JS の OOP 定義を活用するには、以下のような工夫した書き方が必要になります。

jQuery.fn.plugin1=function(opt){

    //コンストラクタの実行後、実体化したplugin1をカレントjQueryオブジェクトのメンバにする
    this.plugin1 = new jQuery.fn.plugin1.prototype.init(opt)

    //カレントjQueryオブジェクトに公開メソッドを追加する
    jQuery.extend(this,this.plugin1.public);
    return this;
}
jQuery.fn.plugin1.prototype={
    init : function(opt){/* etc */},
    methodA : function(){/* etc */},
    methodB : function(){/* etc */},
    public : {
        methodX : function(){
            this.plugin1.methodA();
            this.plugin1.methodB();
            return this;
        }
    }
}
//init を new したら自身の所属するメンバオブジェクトが実体化されるようにする
jQuery.fn.plugin1.prototype.init.prototype=jQuery.fn.plugin1.prototype;

継承機能や定義方法の汎用性、引数の伝播等を考慮するとさらに工夫が必要になってしまうので、とりあえず

1. jQuery は置いといて、まず JS のみで、OOP 的で継承も可能な汎用的な書き方ができないか？: myclass.js の作成で対応
2. myclass.js と同じ書き方で jQuery プラグインの追加を可能にする jQuery プラグインを作れないか？: myclass4jquery.js の作成で対応

という経緯を経て今に至ってます。

CSS 自分ライブラリの検討

で、ここまでできてやっと、UI 周りのプラグインの開発となる訳ですが、UI と強く関わるのが CSS 。
こちらも専門家の方々のブログ等で勉強させていただくと、いろいろと奥が深く、JS 以上にブラウザ互換の問題があり、とにかく IE を憎くむようになりました。

そんな中、昨年の内作案件でのTeedaの採用、はてブしまくったAjax系ライブラリの乱用(？)で、標準準拠の大切さを身をもって知りました。今はCSSの先生方のブログなどを参考にさせてもらいながら、自分デファクトなCSS定義セットを少しづつ作っている段階です。
自分デファクトなCSS定義、mydesign.cssを考えてみる(1) - Cyokodog::Diary

結果、

こちらも自分流 CSS定義となる CSS リセット + 拡張が必要という考えとなり: mydesigin.css を作成

こちらは業務の優先順位の関係もあって開発が停滞気味ですが、以下の順でラップして使用するようにしています。

- 1.デザイン抜きの文字間、サイズのみを考慮したシンプルなリセット → myreset.css
- 2.業務システムでも無難なサイト/パーツカラー、デザインを設定 → myparts.css , myskin_default.css
- 3.システム別に特色を出すための拡張デザイン → myskin_***.css

myclass4jquery.js による UI系プラグインはこれら mydesign.css で定義されたパーツデザインと絡ませて作ってく予定です。

現在開発中なのが以下のようなプラグインです。

- 1. iframe ベースの Ajax プラグイン（インフラ環境の関係でXHRベースなAjaxが使用できないので）
- 2. 1.を継承したモーダルダイアログを生成するプラグイン
- 3. 2で必要となるコンテンツ位置を固定表示、ポップアップブロックするプラグイン

仕事方面

前述の内容も仕事の効率化を目的にやっていることですが、なかなか仕事に適用するレベルまでもっていく事ができず、今それをし始めてる状況です。
仕事方面でやってきた事を確認してみます。実際は日記を始める前からやってるので1年程さかのぼりますが、内容的には以下の「はてなダイアリ初エントリ」に書かれてることとほぼ一致します。

他の対策として、私ともう１人が教え役でWEBアプリ開発の勉強会をしていく予定です。
（省略）
システム間で重複する機能（環境変数読み込み、シングルサインオン、メール送信機能、ファイルアップロード機能など）の外だし汎用化を進めることで、標準化、肥大化の防止と保守性の向上を見込んでいます。連携については、特にシステムの中核である業務ロジックの連携は、PL/SQL（ストアド）で実装するのが最良の選択と考えています。PL/SQL（ストアド）ならWEBサービスなど作るまでもなく容易に連携できます。
業務ロジックはストアド（PL/SQL）で - Cyokodog::Diary

環境変数読み込み機能の汎用化

上の記事にも書いてありますが、今の会社では mod_plsql というオラクル製の特殊な機能を使用した web アプリがメインになっています。システム構成自体は三層になってるのですが、サーバサイドロジックが PL/SQL のため DB 内で処理が行われます。そのため環境変数の定義もストアド内で行えば楽なのですが、テスト環境を最新にするため本番環境の DB をコピーすると環境変数自体もコピーされるので、「テスト環境でアプリをテストしていたつもりが、いつの間にか本番環境に接続されていた！」という危険を含んでしまいます。
これを解決するためアプリサーバ上にシステム単位に環境変数を定義した XML を配置し、システム実行時に PL/SQL から動的にこれを読み込み、オラクルの XML パーサ経由で PL/SQL 内の変数にバインドするというライブラリを作成しました。

シングルサインオン化

システム数の増加と外注時の開発標準化の未整備等が起因し、ログインアカウントの多重管理や、パスワードの有効期限管理などが問題視されるようになってきました。一時期、親会社の意向で市販アプリを導入しシステムログインをシングルサインオン化するという計画があったのですが、アプリケーションサーバのバージョンや OS が対応してないとかでなかなか計画が進まない状況でした。
今年も新規システムの開発を２件程割り当てられ、認証機能を作るのが面倒だったのと、人事系システムとのインターフェース処理の見直しもしていたので、シングルサインオンを実現するライブラリを自前で作成しました。
現状、mod_plsql にしか対応してませんが、APIを作ることで Java や .NET でも使用できるようにしています。

webアプリ勉強会

６月ぐらいからぼちぼち始めました。勉強会用ホームページに技術系の関連サイトのリンクと課題を載せて、個別にフォローしてくやりかた。最近は停滞気味。

mod_plsql フレームワーク

Seasar2 の Dolteng と Teeda を参考に作りました。
世間ではまずニーズはないかと思いますが、うちはこれメインなのは確かなので作ってみました。勉強会の兼ね合いもあるので。
mod_plsql の強みは DB アクセスの気苦労が不要というのが大きいと思いますが、デメリットもいろいろあります。Java で例えるなら MVC 的な考えも JSP もなく、サーブレットのみで web アプリを作ってるようなものです。

詳細は省略しますがざっと書くと

- 画面アイテムの定義ツールでエンティティ名や表示名、型などを定義
- それらをもとにフレームワークソースファイルと、その上で動作するページロジックソースファイルを自動生成。(Dolteng相当の機能)
- ページロジックソースにロジックを追加していく。フレームワークソースファイルはいじらない。
- ページロジックソースは MVC を強要されていて、従わないとコンパイルエラーになる。
- MVC + Teeda のようなソース構成。init , prerender , submitボタンに対応してコールされる専用プロシージャ(ex. procedure save_btn)
- 必要なアイテムの増減があった場合、フレームワークソースの再生成でページロジックで使用可能
- リクエストデータ、レスポンスデータの自動バインド
- 汎用バリデートの一括・個別実行。フレームワークによるメッセージとエラーアイテムの管理と表示。

などなど。
機会があったら記事にしてみたいと思いますが、あまりにニッチなので需要はおそらくないでしょう。。（個人的にはこれが一番役立ってますが…）

メール送信機能、ファイルアップロード機能の汎用化

Oracle Forms のコンバージョン作業でうちにきてる外注業者さんが一段落ついてので、技術調査などをいろいろやってもらてます。
どちらも Java でやる予定。アップロードは、Teeda か commons かで迷ってます。
それ以外にも気になる技術を試してもらってます。(DOM Strageとか。本人も楽しそう。)

システム連携、サービス化

すこしづつ整備してます。前述の環境変数やシングルサインオンも対象。

所感

主だったところは、こんなとこでしょうか。
こうしてみると web アプリ勉強会以外は、もともと正式に割り当てられた自分の業務でないですね。業務のスキをつきながら少しづつ積み上げてきたものばかりです。もっとも、シングルサインオンや mod_plsql フレームワークのようにある程度すぐに効果がみられそうなやつは、それとなくアピールして業務化を黙認させてる面もありますけど。

昨年から業務見直しの一環でいろいろと討論する機会があるのですが、机上の理論で熱いやり取りはその場限りで、「会議が終われば業務に追われて進展なし」の繰り返しだったような気がするので、こうして少しづつでも目に見えるものをつくり、言葉ではなく形でアピールしてくことが重要なんじゃないかなと思う次第です。