デバッガー

僕がNZに来た頃に、最初に一緒に仕事をした開発リーダーの人は、全くデバッガーを使わずロギングだけでデバッグする人だった。

もう１０年近く前だし、その頃使ってたSunのEJBコンテナーiPlanetなんて当時のJBuilderの中で動かしても遅くて使う気にならなかった。

その後、使う機会が多かったのはWebSphereで、やっぱしこれも重くてあんまり僕はデバッガで動かす気になれなかった。その開発リーダーの影響もあって、殆ど、ロギングだけでデバッグするのに慣れてしまってたし。

現在働いてるプロジェクトでは、主にTomcat+Spring、または自分たちで作った一種のコンテナー、なので皆デバッガー中心のデバッグだ。TomcatとかJBossとかJettyとかは、非常にEclipseの中でデバッグしやすく嬉しい。でも、ロギングだけでやってきた人なので、あんまりデバッガーの使い方が分ってない。今日、友達に、ちょっとした小技を見せられて、もっと勉強して使いこなさなきゃなぁと思った。

XP関係の本

Kent BeckのExtreme Programming Explainedという本をオーダーした。
オーダーしてからAmazonのレビューを見るという間抜けなことをしたら、『説教ばかりで実際的なことを言ってない』とかいうレビューがいくつかあって、うーむ早まったかなぁという印象。

ま、XPについて勉強するんであれば、これから始めるのが順等じゃないかと思うので楽しみに届くのをまとうっと。

ドメインオブジェクト

数日前に、Javaは長くやってきたのでオブジェクト指向は分る気がするとか大言壮語してしまった。今週、仕事でチームのメンバーと作ってるシステムのドメインオブジェクトについて議論することがあって、ドメインオブジェクトって物が分ってないことに気がつかされた。そんでDomain Driven Design(日本語)をよんだりしてます。

僕の問題は、ドメインオブジェクト同士の関係をメモリー上に作り上げる時に必要な操作を提供してくれるインフラ的なオブジェクトを、ついドメインレイヤーで考えがちということ。例えば、何かプロダクトを表現するドメインオブジェクトがあって、それの内容をバリデートするドメインオブジェクトを定義したとする。プロダクトのタイプが、適用されるバリデーターを決定するとする。このバリデーターをロードしたりするオブジェクトは、どっかに必要だけど、それは裏方であってドメインオブジェクトではない。例えば。その裏方のオブジェクトについてビジネス(ユーザー)側は理解できない。なぜなら、彼らのドメインに’バリデーター・ローダー’みたいな言葉はないから。

追記
上記を書いた翌日に、Domain Driven Design(日本語)のリポジトリーの項を読んでいて、はて、自分の考えていたのはDDDでいうアグリゲートをリポジトリーから取り出すことではないか、とするとリポジトリーをドメインオブジェクトと考えるのもあながち悪くないのかもしれないが、と疑問がでてきた。

Erlangのお勉強

ほんの単純なこと、例えば、文字列を特定の場所でスプリットしたりするのさえ、未だ、どこにライブラリーのリファレンスがあるのかとか、いったい、そういうのはライブラリーなのか言語の機能なのかとかわかりません。

Functional Programmingって何？

一応、長いことJavaで仕事してるので、オブジェクト指向の要素とはどんなもんかは分ってるつもり（例えば、ポリモアフィズムとか、インターフェースとか)。オブジェクト指向的に美しく書けるかどうかは別として。

Erlangで初めて、Functional Programming言語に触れてみてるのだけど、何がFunctionalの要素なのか、今ひとつ未だ分らない。一回変数にアサインすると変更できない、ってのは一つの特徴なのかな。とはいえ、リストの中身は変更できるんだ。なるほど。

Twitterにつぶやいた方が良いような、まとまりのないエントリーになってしまった。

EASYBとかいろいろ

現在働いてるプロジェクトはアジャイルで開発している。朝は、スタンドアップ・ミーティングで始まり、毎週月曜にストーリー・ブレークダウンを行う。

だもんで今日は、午前中、一時間弱ストーリー・ブレークダウン。

テスターも加わってストーリーをタスクに落としていきテスト可能になるようにタスクを考える。ユニットテストは普通にJunitでクラス単位に書いているけど、その上の所謂、インテグレーション・テスト（定義が曖昧で、散々、チームで議論した）を僕らはストーリーテストと呼んでいる。つまり、ストーリーをテストする。

ストーリーをタスクに落とす時に、テスターはポスト・イットにBehaviour Driven Developmentの感じで、テスト内容を記述する。それを後刻、Easybのストーリーとして実装する。

Easybは、なかなかシンプルで良いと思う。groovy生で書くよりも、後から見た時に何やってるのかわかりやすいし、テスターやユーザーとの意思疎通に役立つ。ただ、Easybから他のgroovyのコードを使おうとすると、Eclipse+groovy pluginのビルドが、依存しているgroovyコードをコンパイルしてくれない。仕方ないので、antでコンパイルさせるようにしたり、Easybのストーリーから呼ぶものはJavaで書いたりしている。イマイチ、良い方法が分かってない。