「CanCam」 5月号
少ないとはいえ知人に見られているのにこのネタはどうかとも思うのですが，日記なんだから気にせず書いてしまいます．
CanCam*1というのは女性向け*2のファッション雑誌です．同じような雑誌にJJ，ViVi，Rayとあって，皆同じ発売日で同じサイズで値段もほとんど同じ，表紙を見ても中身を見てもたいていの男には区別が付かないような雑誌です．自分は区別付いちゃいますけどね．．．
その手の雑誌をこの6年くらい買ってます．一時期は4冊全部買っていたのですが，最近はCanCamともう一冊買うか買わないか．
というのもですね，6年前に知り合った彼女は趣味が少なくて，ほとんど唯一の楽しみが洋服などのショッピング．そんなわけで，共通の話題作りのためにその手の雑誌を読むことにしたわけです．それで彼女が好きそうな服を見つけると，電話で「○ページのこれかわいくない？」なんてはしゃいだりなんかして．彼女好みの服を彼女より先に見つけることにプライド!?をかけています．
ところでCanCamというと，ここ数年，元モデルだった米倉涼子，長谷川京子，伊東美咲*3が立て続けにブレークして，タレント予備軍的なポジションを確立しつつあるようです*4．
そんなCanCamの現役モデルで次にブレークが期待されているのは，フジテレビのF1キャスターもつとめている山田優ちゃんということになるのだと思われますが，個人的な一押しは 蛯原友里ちゃん！ 今月はこの二人が表紙です．でもこの表紙の友里ちゃんはあまりよくないかなぁ．1月号といい，複数で表紙だと全員が写りのいい写真を選ぶのが難しいのか？(^^; 去年単独で表紙だったときとか，通販雑誌「IMAGE」の表紙の友里ちゃんは最高にかわいいと思うのですが．
友里ちゃんもドラマやCM*5にちょっとずつ出ているのですが，テレビだとあまりインパクトがないというか隣のきれいなお姉さん的な感じになってしまうので，先輩ほどの大ブレークは難しいかもしれません．
結局何が言いたいのかよく分かりませんが，ともかく蛯原友里ちゃん頑張ってください!!
それから，最近のCanCam厚すぎです．600ページ近いじゃん．それがほとんどカラーで600円か．頑張ってるなぁ．
「MDA導入ガイド」1-3章
日記のための読書シリーズ第2弾です．
第1弾で読んだ「MDA モデル駆動アーキテクチャ(ISBN:4434038133)」に比べると初心者にも優しいようで，一気に3章まで読めました．
1. MDA開発プロセス
まずは従来の開発プロセスの問題点があげられています．主な問題点としては，分析や設計の成果物であるモデルが「単なる紙」にすぎず，それらはコーディングが始まると(コードとモデルが乖離して)価値がなくなってしまうことだとしています．そのため，XPなどのようにコードを中心とする開発プロセスに注目が集まっているものの，大規模なシステムを開発チームが解散した後も保守することなどを考えると，「目印」としてのモデルが必要である，ということです．
しかしながら，モデル(ドキュメント)を正しく維持するのは困難です．この理由について著者は，次のように書いています．
1.1.4 保守と文書化の問題
文書を作成することで開発者の主なタスクがサポートされるわけではありません．文書を利用することでサポートされるのは，後で発生するタスクです．従って，文書の作成は全体の繁栄のために行っているようなもので，自分自身のために行っているのではありません．
確かに．ここで「人のために」だからこそ頑張れる人ばかりならいいのですが，不幸にして私は自分が楽しいことしかしたくないタイプ．．． 心より恥じる．
そこで，コードではなくモデルにより開発プロセスを駆動する，MDAが役に立つというわけです．
「1.2.1 MDA開発のライフサイクル」では，開発プロセスの各工程ごとの成果物が説明されています．それによると，「分析」の成果物がPIMということになっています．そして「設計」の成果物がPSM，「コーディング」の成果物がコード．どうなんでしょうか？ ちょっと納得しがたい定義です．PIMは確かにプラットフォームから独立しているという点で抽象度が高いとは思いますが，とても分析の成果物とは考えられません．「MDA モデル駆動アーキテクチャ(ISBN:4434038133)」の印象では，コーディングでなくても間違いなく実装だと思わざるを得ない雰囲気だったのですが．
MDAによって得られるメリットとして，お約束の生産性が上げられています．理由の一つはプラットフォームの詳細を扱わなくていいこと，もう一つの理由は開発者が焦点をコードからモデルに移せることだとしています．最初の理由はまだ分かるとして，2番目の理由はどうなんでしょう？ なぜモデルに焦点を移すと生産性が向上するのか，その理由は説明されていません．最新のモデリングツールは，優れたエディタやIDEでのコーディングを凌駕する生産性を実現できるのでしょうか？ 少し疑問を感じました．
2. MDAフレームワーク
ここでは，「モデル」とはどういうものかという定義やその種類，異なるモデル(PIMとPSM)間の変換について解説されています．
3. 今日のMDA
MDAの現状を解説しています．
それによると，アクション・セマンティクスは抽象度が低くPIMの記述には向いておらず，OMG(UML)の標準でもないとのことです．そうだったんだ．．． また，「Executable UML(ISBN:479810602X)」で紹介されているステートマシンを使用した振る舞いモデリングは，組み込み系では有用でも，業務系では面倒すぎるとしています．やばい，次に読む本なんだから，ほめてほしいんだけどなぁ．
という感じで，いかにも導入部です．PIMが分析の成果物というあたりが納得できませんが，読み進んでいくと「なるほどぉ」ってことになるのでしょうか？ 今後に期待します．
Spring Framework 入門記 Beanその11 XmlBeanFactory
本来なら次は「3.7. Lifecycle of a bean in the BeanFactory」のはずだったのですが，つい最近になって
This chapter will be re-written soon.
となってしまいました．(^^;
RC2のドキュメントには状態遷移図付きの解説があったのですが，それほどの内容ではないので飛ばしましょう．
ということで次は「3.8. BeanFactory structure and implementations (WIP)」．ここを読めばBeanFactoryの階層化について理解できるのかな，と思いきや，
From here on, up till the Context stuff, needs an overhaul.
とか書いてあるし．．．(^^; ま，開発中なんだからこんなものですよね．っていうか，これだけドキュメントがあるって異常なくらいです．「全体の繁栄のために」ドキュメントを書いてくださったSpring Frameworkのスタッフに感謝です．おかげさまで最高の日記ネタにしています．
現状で書いてあることは，いつも使っているコンテナXmlBeanFacotryを構成するためのXMLについて，ここまで説明がなかった<props>，<list>，<map>を含めて解説されています．でも<set>は書いてありません．なぜ？ それに，<props>と<map>はもう使っちゃったんだよなぁ．
Beanのプロパティに他のBeanの参照を設定したりするための<ref>要素の説明では，bean属性およびlocal属性の他にexternal属性を指定できると書かれています．しかし，DTDではそのような属性は宣言されていません．説明には，参照しようとしているXML(BeanFactory)ではなく，外部からBeanを探すことを明示するそうです．必要なのかなぁ？
このまま終わるのも何なので，とりあえず<list>要素だけでも使ってみましょう．
まずはjava.util.Listのプロパティを持つクラスを用意します(ソースは省略)．
そして定義ファイルを作成します(<bean>要素のみ抜粋)．
<bean id="foo" class="study.Foo" singleton="false">
<property name="list">
<list>
<value>Yuri</value>
<value>Yuu</value>
<value>Moe</value>
<value>Izumi</value>
</list>
</property>
</bean>
<list>要素の内容には，<value>要素だけでなく，<ref>要素などはもちろん，<props>，<list>，<map>を記述することもできます．リストのリストとか作れるわけですね．
これを以前より使用しているMainクラス(「入門記 Bean その8」の終わりの方参照)で実行すると，
- Loading XML bean definitions from (no description) foo : study.Foo@12940b3 list=[Yuri, Yuu, Moe, Izumi] class=class study.Foo
となりました．バッチリです．
なお，Listの実装クラスはjava.util.ArrayListでした．これはカスタマイズできないのかな？ DTDには属性などはありませんから，現状ではどうしようもなさそうです．ちなみにMapの実装クラスはjava.util.HashMapです．
どうやら，Spring FrameworkのBeansパッケージの基本的なところはだいたいクリアできたようで，次の「3.9. Introduction to the ApplicationContext」からはContextパッケージになるようです．順調，順調．このドキュメントの目次を見るとまだまだ先は長いのですけどね．．． でも，日記のために頑張るのだぁ．
Spring Framework 入門記 Beanその10 FactoryBean
今回は，昨日の学習中に「毛色が違う」とすっ飛ばしてしまった「3.4.3 FactoryBean」について学習します．
FactoryBeanというのは，自身がFactoryであるようなBeanということです．言い換えると，Beanとして扱うことのできるFactoryですね．このようなものがなぜ必要なのかというと，インスタンスの生成をコンテナにやってもらうのではなく，その外で用意して，それをDependency Injectionの輪に加えたい場合でしょう．
FactoryBeanインタフェースには，次の3つのメソッドが宣言されています．
Object getObject()- オブジェクトを返します．
Class getObjectType()- この
FactoryBeanが返すオブジェクトの型を返します． boolean isSingleton()- この
FactoryBeanが返すオブジェクトがsingletonならtrueを返します．
簡単そうですね．
それでは例として，ThreadLocalで保持しているスレッド固有の情報をSpringにDependency Injectionしてもらうサンプルを作ってみます．とはいってもサンプルなので，ちょっと手抜きしてスレッド固有の情報はただの文字列ということにします．
まずはFactoryBeanの実装です．これ自身はSpringで扱われる普通のBeanですから，プロパティを持つことができます．ということで，ThreadLocalをプロパティとして，そこからget()したオブジェクト(今回はString)を自分のgetObject()の戻り値になるようにします．この文字列はそのときの状況で変わりうるので，Singletonではありません．
ということで，こんな感じ．
package study;
import org.springframework.beans.factory.FactoryBean;
public class ThreadLocalString implements FactoryBean {
ThreadLocal threadLocal;
public ThreadLocal getThreadLocal() {
return threadLocal;
}
public void setThreadLocal(ThreadLocal local) {
threadLocal = local;
}
public Object getObject() throws Exception {
return threadLocal.get();
}
public Class getObjectType() {
return String.class;
}
public boolean isSingleton() {
return false;
}
}
では，これを使用した定義ファイルを作成します(<bean>要素のみ抜粋)．
<bean id="threadLocal" class="java.lang.ThreadLocal"> </bean> <bean id="threadLocalString" class="study.ThreadLocalString"> <property name="threadLocal"><ref bean="threadLocal"/></property> </bean> <bean id="foo" class="study.Foo" singleton="false"> <property name="text"><ref bean="threadLocalString"/></property> </bean>
ここでのポイントは，fooという名前を持ったBeanのtextプロパティはコンテナが設定してくれるのですが，その値(文字列)はthreadLocalStringというFactoryBeanが返す値だということです．
最後に実行用のクラスを作ります．
package study; import java.io.FileInputStream; import org.springframework.beans.factory.xml.XmlBeanFactory; public class Main { public static void main(String[] args) { try { XmlBeanFactory factory = new XmlBeanFactory(new FileInputStream("beans.xml")); ThreadLocal threadLocal = (ThreadLocal) factory.getBean("threadLocal"); threadLocal.set("Midori"); Foo foo = (Foo) factory.getBean("foo"); System.out.println(foo.getText()); threadLocal.set("Saeko"); foo = (Foo) factory.getBean("foo"); System.out.println(foo.getText()); } catch (Exception e) { e.printStackTrace(); } } }
この実行用クラスでは，fooを取得する前に，ThreadLocalに文字列を設定しています．そのため，取得したfooのtextプロパティには，その時それぞれの文字列が設定されているはずです．
それでは実行します．
- Loading XML bean definitions from (no description) - Creating shared instance of singleton bean 'threadLocal' - Creating shared instance of singleton bean 'threadLocalString' Midori Saeko
いいねぇ*1．
という感じなんですが，惜しいことにFactoryBeanが返したオブジェクトはDependency Injectionしてもらえないんですよね．無念だ．
大して難しい話じゃないと思うのですが，現状はDependency Injectionした後に，そのオブジェクトがたまたまFactoryBeanだったらgetObject()するという流れになっているようで，そこで再度Dependency Injectionするようにはなっていないのですね．DTD的にも，FactoryBeanのプロパティとそれが返すオブジェクトのプロパティを区別する書き方はできませんし，しょうがないとあきらめましょう．ただ．．． 無念だ．
