Weld + JSF2で、Scalaを使う。
まぁ、Scalaでも普通に使えるのだけど、getXXX()とかsetXXX()とか並べるのは、あまりにダサいので、el-api-2.2jarに細工をしてみた。
再挑戦。WeldをGoogle App Engineで動かす。
前回は一苦労だったが、Weld 1.0.1 CR2が出たので、再挑戦。
Weld 1.0.1 CR2を、Google AppEngine 1.3.1で動かす
結果的には、あっけないほど簡単になっている。Google App Engine上で使用するフレームワークして、Weld + JSF2は、なかなか好印象。というか、これ、同じやり方で、TomcatやJettyでも動くはずだよね。なかなかお手軽で良いと思う。GAEGWTと、Weldとの連携も予定されているようだ。
リファクタリング:Rubyエディション
献本いただきました。リファクタリング:Rubyエディション。
内容的には、コードをRubyで書き直しただけかなと読み進めるも、6.17あたりから様相が違ってくる。動的メソッド定義をどういう時に使うのか、とかevalをそのまま使うと遅い時もあるから、evalでメソッド定義をしようとか、動的言語を使う場合のリファクタリング技法も追加されているのだ。動的な言語を使っている時は、ともすると機能を使い過ぎて、どうしてもカオスの道へと転がり落ちる危険が増すので、こういう指標をベストプラクティスとしてまとめていくことが、重要となるのだろう。
個人的には、IDEやコンパイルエラーを活用することで機械的に行えたリファクタリングを、動的言語でどう解決するのか、という点に興味があったのだけど、この本の中では、まぁ普通にテストで乗り切るという感じだ。やはりこの点は静的な型付言語に分がありそうだ。
元のリファクタリング本は、人にあげてしまったんで、元からそうだったかは覚えていないのだが、この本では全く正反対のことがリファクタリングとして取り挙げられていることが面白い。例えばローカル変数を抽出すること、逆に問い合わせメソッドに置き替えて削除してしまうこと。ローカル変数を抽出し、そこに意味のある名前を与えることで、コードが読み易くなるなら、抽出すれば良いし、無意味なiとか、valueみたいな短命ローカル変数が存在するなら、削除すれば良い。ただ、どちらが良いのかはやはり個々のプログラマのセンスが試されるところだろう。
そういえば、メソッドチェインも良いとされる場合もあれば、悪いとされる場合もあるね。でも最近は積極的に使用される場合の方が多い気がする。傾向としてはデータの連鎖がある(つまり外部にデータの構造が晒されている)のは悪く、処理が連鎖するだけであれば良いのだと思う。つまりデータ構造は隠蔽すべきなのだ。
感心したのは、Extract Surrounding Methodに対する「サンドイッチメソッドの抽出」という訳語。なるほどね〜。これはセンスの勝利だ。
内容的には、Clean Codeと、激しくデジャブだったりする。Clean Codeはより実装寄りで、この本は、もう少し設計寄りかな。ただ、いずれにせよ、どちらの本もコードを読めないければ理解は困難だろうという点は同じだ。その点では「高尚なアーキテクチャ本」では無いが、その手の本よりも、ずっと重要なことが書かれており、これをないがしろにした開発プロジェクトは100%失敗するだろう。
