ここのところPerl勉強日誌的な記事が続いていますが、ff14.nameとff14.asiaの開発は細々と続いています。それはもう申し訳ないほどに細々としていますが......（一方で、「やや真面目なサイト」としてサイドバーに晒してあるエスペラント日本語翻訳システムは、かなり遅滞気味です）。
これらサービスのそもそもの開発動機の一つが自分自身の勉強ということもあって、色々と新進気鋭のモジュールを試しながら使わせていただこうとして出発点を置きましたが、少なからぬ依存モジュールの数々を、新進気鋭のモジュールではなく、定番系のモジュールに切り替えようとしています。これは、定番系の重厚長大モジュールでさえ深く使い込んでないのに、新進気鋭の軽薄短小なモジュールを巧く使いこなせずに開発が遅滞するということが、早すぎる最適化の一類型に当てはまるのではないか、という危惧に由来するものです。最終決定はまだ先ですが、10月20日版の主要依存(予定)モジュールなどでは、その辺りの弱気が透けて見えるかも知れません（「or」の前後をかなり入れ替えています）。
具体的には、例えば
- やっぱりまだまだRDB的な考えからKVS的な考えに切り替えが出来ない私は、Data::Modelではなく、まずはDBIx::Classで一通りを組んでみようと考えを改めました
- 出来るだけAny::Moose経由でMouseを使うようにしていたのですが、まずはMooseの豊富な拡張モジュール（MooseX::*）にお世話になってプロトタイピングにいそしもうとしました
などという点です。
この方針の転換は、すべて私の能力の至らなさによるものです。8月中旬頃まで色々試行錯誤をしていたのですが、色々な使いどころの妙を得ずに開発をしていて、プロトタイピング自体で蹴躓くことが多かったという体験があります。ということで、最初から完成形のアプリケーションを作れるわけでは当然ないにせよ、まずは形を作ってからそれから新進気鋭のモジュールの使用を試みようというような、私の身の丈にあった開発をしようと思います。モジュールそれ自体が冒険的ということでは全くなくて、モジュールを自分が十全に使いこなせないという冒険的な開発を改め、多少なりとも安定的にプロトタイプを作れることを優先するということで。
などと書いた舌の根も乾かぬうちにというか打鍵音も静まらぬうちに......。
DI（dependency injection : 依存性注入）の魅力に触れてみました
実は今回、上述の「主要依存(予定)モジュール」に、牧さん(lestrratさん)のDIコンテナーであるOrochiをしれっと差し込んでいます。この辺り、「身の丈に合ったモジュールの組み合わせを使う」方針の不徹底さが知れようものです。ただ、DIコンテナーで疎結合にすると後々楽になりそうなので、（メリットとデメリットは多々あるでしょうが）まずはメリットに着目してみました。
Orochiは、4月のYokohama.pmテクニカルトークでお話があった、Bread::Boardの牧さんfork版の流れをくむものだと理解しています。（同梱の）MooseX::Orochiでいい感じに定義出来る優れものです。
COBOLとJavaの会社なのにJavaのDIについて恥ずかしながら知らなかったので、当時はググって以下のような情報源に当たりました（殆どdannさんの記事にお世話になっています）。
- PerlのDIコンテナ - Bread Board
- Catalyst+ DIでアプリケーションのCatalystへの依存を切り離す
- DI(Dependency Injection)とは - 第1回
- DI(Dependency Injection)とは - 第2回
- Java開発を変える最新の設計思想「Dependency Injection（DI）」とは
そのときはBread::Board採用の億劫さが勝ってしまっていたのですが、牧さんのブログで先週金曜の晩にTest::mysqldとかでテスト走らせる際に行ったいろんな事。という記事で言及があり、日曜辺りからOrochiを触り始めてみました。
そうした結果、比較的手軽に（無理せずに）DIコンテナーを使えることが今回分かって、積極的に使っていこうとしているところです。OrochiのPODに記載してある通り、Bread::Boardが進化すれば、そちらにお世話になることになると思います。
コメントする