Ivyで複数のMavenリポジトリを使う

最近個人的にivyを使ってみてます。

Mavenよりは若干取っ付きにくいですが、慣れてくると自由が利いていいのかもしれません。
まだ慣れてないので、なんとも言えないのですが。。

さて、以下の設定はScalaTestとか、ibiblioでない独自のリポジトリを持っているライブラリを取ってくるために、
複数のMavenリポジトリを使うようにする、ivy-settings.xmlの設定例です。
自分用メモです。

 1 <ivysettings>
 2   <settings defaultResolver="default"/>
 3   <resolvers>
 4     <ibiblio name="ibiblio" m2compatible="true"/>
 5     <url name="scala-tools" m2compatible="true">
 6       <artifact pattern="http://scala-tools.org/repo-releases/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]"/>
 7     </url>
 8     <chain name="public" returnFirst="true">
 9       <resolver ref="scala-tools"/>
10       <resolver ref="ibiblio"/>
11     </chain>
12   </resolvers>
13   <include url="${ivy.default.settings.dir}/ivysettings-shared.xml"/>
14   <include url="${ivy.default.settings.dir}/ivysettings-local.xml"/>
15   <include url="${ivy.default.settings.dir}/ivysettings-main-chain.xml"/>
16   <include url="${ivy.default.settings.dir}/ivysettings-default-chain.xml"/>
17 </ivysettings>

Mercurial使用感

最近仕事ではPHPのフレームワークをつくったりして暮らしているのですが、
どうせなら使ったことないツールをためしてみようと思い、
バージョン管理にMercurial、Issue TrackingにRedmineを使っています。

もう使い始めて半年くらいになりますが、Mercurial は非常に良いですね。

バージョン管理のモデルがSVNよりずっと安全・確実で、おかしなことが起こりにくいのに、
運用はずっと柔軟にできます。

安全・確実さという点でいうと、リモートのリポジトリにローカルの変更点をPushする際に、
ローカルにないリモートのリビジョンと、ローカルのリビジョンをマージすることを
強制する点が良いです。

コミットだけしてアップデートをしなかったために起きる問題を回避できます。

マージする前に、ローカルのワーキングコピーの変更点をコミットすることを強制する点もすばらしい。
マージに失敗しても、ローカルの変更がどこかへ消えてなくなってしまう自体だけは避けることができます。

繰り返しマージする場合に、前回マージした場所を覚えていて、差分のみをマージする点もすばらしい。
既にマージしたところが差分として表示されないので、本当に重要な部分に集中することができます。

結果として、SVNで普通にUpdate/Commit する感覚でブランチがマージできるので、
恐ろしく気軽にブランチが切れます。

分散型であるが故の運用の柔軟性も魅力です。

リポジトリは思い立ったその場ですぐつくれるし、
リポジトリをHTTPで公開する設定も簡単です。
フレームワーク用のリポジトリをクローンして、フレームワークを利用するプロジェクトのリポジトリを
作り、適宜フレームワークへの変更点を個別プロジェクトのリポジトリにマージしながら開発するといったスタイルは
分散型のリポジトリであるが故に可能になることでしょう。

ローカルに完全なリポジトリがクローンされているが故に、対障害性も高いです。

ちなみにgitでなくMercurialを選んだのは、完全に勘です。
なんとなくマルチバイト文字の処理とか、Windows上での挙動とかが大丈夫そうな感じだったから。。くらいの感じ。

あと、オフラインで作業できるというのは、今日びそんなにメリットでないと思われるかも知れませんが、
使ってみると、つまらない会議に出席せざるを得ないときにこっそりコーディングできたりして意外に便利です。

Redmineの話はまたにします。

Scala: Manifest

Manifests: Reified Typesで紹介されているScala2.7.2の隠し?新機能が自分的にヒットです。

Java の Generics はコンパイルされてバイトコードになると消えてなくなってしまうものでした。そのため、実行時にパラメータ型が実際どの型になっているのかを知る手段がありませんでした。

たとえば、

----
public <T> T hoge()
----

というメソッドがあったとき、
hogeメソッドの実装は今、このTの実際の型をどうがんばっても取得できなかったのです。
なので、hogeの中でTの型を知りたいときは、

----
public <T> T hoge(Class<T> type)
----

のように引数にClassを渡す必要がありました。

この問題を解決するため、 Scala 2.7.2からは、scala.reflect.Manifestという
クラスを暗黙のパラメータとして引数に指定しておくと、
呼び出し側では、明示的にパラメータを渡さなくても、

勝手にManifestのインスタンスを渡してくれるし、
このManifestのインスタンスから、Tの実行時のクラスも取れるということです。

まだ実験的なものなので、Undocumentedな状態らしいですが。

Amateras ERDを使ってみた

仕事でER図を書くことなったので、Amateras ERDを使ってみました。
まだ図を書いてみただけですが、Amaterasシリーズらしく、軽快でシンプルで、とても使いやすいですね。

最近、ER図がわかる人は意外に多い気がしていて、コミュニケーションツールとしても有効な気がしています。

商用のツールは高くて重かったりするので、Amateras ERDで、さくっとER図書いて、「こんな感じでどう?」
みたいなことがやりたいです。

ぜひ今後もこの路線を追求していってほしいです。。

ScalaにてDI

Real-World Scala: Dependency Injection (DI)
Scala で Dependency Injection を実現するための、幾つかの選択肢が示されています↑

特別なライブラリを使用せず、Scalaがもつ機能のみでDIっぽいことを実現する方法を解説している最初の例が興味深い。

言語自体の機能が十分に豊富である場合、DIコンテナやテンプレートエンジンのような基本的なライブラリのいくつかは、不要になってくるのかもしれないですね。

Scala のWebフレームワーク: Web Flavor

Scala で使えるWebアプリケーションフレームワークを探しています。
世間的には、liftというのがメジャーらしいのですが、自分的にはいまいちピンときません。もっとシンプルなものが好みなんですよね。ややこしいのはScala本体だけで十分です。

荒削りだけど、面白い試みだと思ったのは、西本 圭佑 さんという方が作っている Web Flavorです。

Web Flavorの特徴は JSP のように、Scala のコード片をリクエストがきたものから順に動的にコンパイルして実行できるところです。JSPのコードからServletのコードが生成されるように、Scala のコード片が本体に埋め込まれた関数が生成されてコンパイルされます。

生成される関数の引数には、ServletRequestっぽいオブジェクトや、ServletResponseっぽいオブジェクトや、ServletContextっぽいオブジェクト等が渡ってきているので、JSPの暗黙オブジェクトのように、本体となるコード片からそれらを参照できます。

JavaをベースとするJSPに対して、Scalaをベースとする Web Flavorの大きな強みは、

Scala ではXMLをリテラルとして記述できる

点にあると思います。しかも Scala では関数やメソッドの中で最後に評価された式の値が戻り値になるため、Web Flavorにおいては Valid な XHTMLをファイルの最後に無造作に書いておくと、それはそのまま完全な Scala コードに変換され、関数の戻り値であるXHTMLが出力されます。
また Scala では for文やif文を書く必要性も減るので、JSPのように訳の分からないスクリプトレットまみれになる可能性も減ると思われます。

まさにテンプレートエンジンいらず。

実プロジェクトで使うには乗り越えなければならない壁がもちろん多々あるのでしょうが、非常に刺激的です。

と、いっている間に、今日、0.2.4がリリースされたようです。

Scala: traitのパワー

A Scala-style "with" Construct for Ruby
↑ScalaのtraitがどうすごいかをRubyとの比較において述べたエントリ。

Rubyとの比較云々は良いとして、クラスをnewするときにtraitをmixinできるのは非常に面白いと思いますね。

Chain Of ResponsibilityとかDecoratorのパターンでオブジェクトの構造を組み立てるところとか、Javaの動的プロキシとか、AOPライクなこととかがとっても簡潔に記述できそうです。

追記：
良く考えると、似たようなことがObjectクラスの変更で出来てしまうRubyの柔軟さもやっぱりすごい。

Scala

実はScalaには数ヶ月前から興味をもって調べ始めています。

長い時間をかけて LiQ Container を作っていたあたりから関数型の言語には強い関心をもっていて、
その中でもJVM上で動き、関数型言語の特徴を持ちながら既存のJava資産を活かせるScalaはいずれちゃんと勉強しようと心に決めてました。

しかし、文系出身で社会人になってからプログラミングの勉強を始めた私は関数型の言語に全く免疫がなかったので、Scalaを勉強する前にHaskellあたりを勉強しておこう、とHaskellを勉強していました。Haskellはひどく難しい言語でした。。

でも結果的にはScalaを勉強するときに再帰によるリスト処理や高階関数やカリー化やパターンマッチといった、関数型言語特有の機能を理解できたので良かったと思っています。

で、最近漸く Scala 自体を勉強し始めました。意外に覚えることが多い言語なので、習得にはそれなりの時間がかかりそうですが、このBlogでも今後折に触れてScalaネタも展開していきたいと考えてます。

XMLの方のSimple

HTTPの方のSimple Frameworkから分かれたXMLシリアライゼーション用のフレームワークがあります。その名もSimple。同じかよ!

HTTPの方と同様非常にシンプルだけれどもパワフルで、XMLの読み書きがバカみたいに簡単にできる良くできたフレームワークです。両Simple Frameworkともに、APIのデザインといい、コーディングのスタイルといい、今までのJava界のしがらみにとらわれない新しい世界を切り開くものだと思います。

なのに。

いかんせん名前がひどすぎる。最早、怒りすら覚えるレベルです。非常に惜しい。

Maven 2.1.0-M1 リリース

リリースされたようです。
アナウンスメールによると、2.0.x 系は今後end-of-life モードになるそうです。

今後は2.x系は比較的保守的な改善点のみを取り込むそうで、もっと根本的な変更は 3.0 系の方に対して行われるようです。
具体的なロードマップが書いてあるページ↓

Maven 2.1.0 Release Plan
Maven 3.0

これらのプランにはざっと目を通しましたが、なんとなくIvyの方が筋が良さそうな気がしている、今日この頃です。