はてなブックマーク

機能のエントリで作ったDIフレームワークをもうちょっとちゃんとしました。 長いですけど引用します。 コンポーネントの循環参照を自動的に解決できるようになりました! 1 import scala.collection.immutable.Map 2 import scala.collection.immutable.Stack 3 4 trait Key[+T] 5 6 class Component(val entries:Map[Key[Any],(Injector)=>Any]) { 7 8     def define[T](key:Key[T], factory: (Injector)=> T) = 9         new Component(entries + (key -> factory)) 10 11     def define[T](key:Key[T], fact

お久しぶりです。 Scala でDIっぽいことをやる方法と申しますと、こういったアプローチがあるのですが、 これだと、inject用のTraitを山のように定義しないといけなくて、煩雑な気がしたので、自分で簡単なDIの仕組みを作ってみました。 こんな感じです↓ 1 import scala.collection.immutable.Map 2 3 trait Key[+T] 4 5 class Component(entries:Map[Key[Any],()=>Any]) { 6 7     def define[T](key:Key[T], instance: => T) = 8         new Component(entries + (key -> (()=>instance))) 9 10     def apply[T](key:Key[T]):T = 11       

最近仕事ではPHPのフレームワークをつくったりして暮らしているのですが、 どうせなら使ったことないツールをためしてみようと思い、 バージョン管理にMercurial、Issue TrackingにRedmineを使っています。 もう使い始めて半年くらいになりますが、Mercurial は非常に良いですね。 バージョン管理のモデルがSVNよりずっと安全・確実で、おかしなことが起こりにくいのに、 運用はずっと柔軟にできます。 安全・確実さという点でいうと、リモートのリポジトリにローカルの変更点をPushする際に、 ローカルにないリモートのリビジョンと、ローカルのリビジョンをマージすることを 強制する点が良いです。 コミットだけしてアップデートをしなかったために起きる問題を回避できます。 マージする前に、ローカルのワーキングコピーの変更点をコミットすることを強制する点もすばらしい。 マージに失敗

一旦途切れるとひどく長いこと中断してしまうのは、自分の悪い癖です。 別に忙しくもなかったし、書きたいこともあったのですが。。 というわけで、最近は Scala! Scala! と連呼している訳です。 一応 GAE/Jにも興味があるので、ScalaをGAE/J上で動かしてみているのですが、 ScalaのクラスをJDO経由で永続化できるようにするには、若干コツがいったので、それをメモします。 データクラスの定義は以下のようになりました。 package diet.entity import javax.jdo.annotations.IdentityType import javax.jdo.annotations.IdGeneratorStrategy import javax.jdo.annotations.PersistenceCapable import javax.jdo.annot

Scala で使えるWebアプリケーションフレームワークを探しています。 世間的には、liftというのがメジャーらしいのですが、自分的にはいまいちピンときません。もっとシンプルなものが好みなんですよね。ややこしいのはScala本体だけで十分です。 荒削りだけど、面白い試みだと思ったのは、西本 圭佑 さんという方が作っている Web Flavorです。 Web Flavorの特徴は JSP のように、Scala のコード片をリクエストがきたものから順に動的にコンパイルして実行できるところです。JSPのコードからServletのコードが生成されるように、Scala のコード片が本体に埋め込まれた関数が生成されてコンパイルされます。 生成される関数の引数には、ServletRequestっぽいオブジェクトや、ServletResponseっぽいオブジェクトや、ServletContextっぽいオ

Apache Ivyについてもう少し調べてみました。Maven2 との比較で考えてみたいと思います。 Apache Ivyの機能は依存関係を解決するという限定されたもので、ビルドプロセスの構築に必要な残りの部分はAntが担当します。 一方 Maven2 はプラグインの形でビルドに必要な全ての機能が提供されており、かつ少ないPOMの記述量でそれらの機能が利用できるように工夫されています。 Ivy自体は設定ファイルの記述量が少なくて済むようにほとんどの設定項目に妥当なデフォルト値が設定されているのですが、Antが担当する部分は当然自分で書かなければならないし、書くことができます。 Maven2 ではフェーズを自分でカスタマイズすることが困難であるが故に、ちょっと難しいことをやろうとすると、それを実行するantrunの設定をどこのフェーズにバインドさせるかで悩まなければならない場合がしばしばあり

最近気になっているオープンソースプロダクト、その3はSimpleという、その名の通りシンプルなフレームワークです。 平たくいうと埋め込み型のHTTPサーバを簡単に作るためのフレームワークで、ServletとかRestletとかと同じレイヤに属するものです。なので、Simpleを使ってWebアプリケーションを構築しようとするには、Simpleの上になにかまたフレームワーク的な ものを乗っける必要があります。 Servletよりも軽量かつ柔軟で、Restletほど理屈っぽくもなく、java.nioとかjava.util.concurrentあたりのAPIをうまいこと使って、実に簡潔なコードでまとめあげられています。 以前、LiQ Containerを使ったWebアプリケーションフレームワークを構想していたときに、 「もっとServletってこんなふうだったらいいのに」と感じていた、その思いをほ

最近気になっているもう一つのプロダクトがStringTemplateという テンプレートエンジンです。これは結構前からあるもので、有名なパーサジェネレータであるANTLRを作った人が作ったもので、 ANTLRの中でコードジェネレータ用のテンプレートエンジンとして使われているようです。 他のテンプレートエンジンよりも、テンプレートの中にfor文やif文を埋め込まずに済ませるための様々な 工夫がなされており、とてもきれいにモデルとビューを分離できそうです。ものすごいCoolっぽい感じがします。 作者のTerrence Parr氏はモデルとビューの分離については一家言ある人らしく、このテーマに関する 興味深い論文を発表しています。 この論文の中で、StringTemplateを使ってifもforも書かずにテーブルの行をしましまにする例とかが紹介されています。

fooというrubyのメソッドに、FooというJavaクラスのインスタンスを渡す例です。 ----import java.util.ArrayList; import java.util.Map; import org.jruby.Ruby; import org.jruby.RubyClass; import org.jruby.RubyRuntimeAdapter; import org.jruby.internal.runtime.methods.DynamicMethod; import org.jruby.javasupport.JavaembedUtils; import org.jruby.runtime.ThreadContext; import org.jruby.runtime.builtin.IRubyObject; public class JRubyTest {

バカ専用フレームワーク、キャッチーな表現ですな。 自分の中で何かのスイッチが押されてしまいました。私はもう、こういう話題には 自動的に反応してしまうようにできている人間なのです。 一種の病気です。なのでこの件について言いたいことは本当に 山ほどあるのですが、あんまり言い過ぎると心が荒れるので、少しだけ。 大手SIer謹製のフレームワークの裏の目的は、 なるべく単純作業を沢山増やして、スキルの低い人でもやる気のない人でも なんでもとにかく人を大量にやとって、 プロジェクトの規模を無駄に大きく見せて、 沢山売上げを上げることなのだと思います。 ぶっちゃけ大手SIerにとっては生産性とか品質なんてどうだって 良いのです。彼らにとって大事なのはとにかく、売上。 多少使い勝手が悪かろうとみかけのバグ密度さえ低ければ 問題ない契約になってますしね。 逆に効率が良くなってもっと少ないコストでシステム開発

最近sourceforge.netにプロジェクト作って、 ちょっとしたものを作ってるのですが、 EclipseのSubversive プラグインがsvn copyをやろうとしたときに、 403 Forbiddenでコミットがこける、という問題が発生 しらべたら、このへんに解決策が。 http://www.everes.net/2006/dec/13/svn-copy-on-sourceforge-net/ http://sourceforge.net/tracker/index.php?func=detail&aid=1599910&group_id=1&atid=200001 結論からいうと、リポジトリのURLを変えろ、と。 sourceforge.netのドキュメントに書いてある以下のURLだとダメで、 https://svn.sourceforge.net/svnroot/[proj

何か、ふと思い立ってEasyMock 2.2の文書をざっくり日本語訳してみました。 こちらに置いてあります。 まだ訳したてなので、おかしいところが多少あるかもしれません。 見付けたら、指摘していただけると大変嬉しいです。 それほど親切なドキュメントではないようなので、これだけ見てもよくわからない かもしれません。後で訳注を沢山いれようかな。

Maven2のソースコードを読んでるとそこかしこに"Mojo"という単語を見かけます。これは一体何なのでしょうか。 maven-core/docs/apt/mojos.apt の記述によると、MojoとはMaven java objectsのことなのだそうです。"Mojo"の最初の"o"はどっから湧いて出たんだ!と突っ込みたくなりますが、誤解を恐れずにものすごく平たく言うと、一つのゴールを実行する責務を負うJavaオブジェクトというくらいの位置付けの様です。(間違ってたらご指摘ください) 例えば、maven jar pluginは AbstarctJarMojo.java JarMojo.java JarDeployMojo.java JarInstallMojo.java という4つのJavaファイルから構成されています。AbstractJarMojoは抽象クラスなので、実質3つのMoj

私の母はもう結構歳をとっていて、今年70歳になります。 まだ新しいことへの好奇心とかは失っておらず、 先日姉の指導の下に自分専用のノートPCを購入したりしていました。 先日実家に帰ったときに、その母が自分専用のメールアカウントが欲しいと こぼしていたので(いままでのアカウントは父と共有していたのです) gmailを使わせてみることにしました。 今までOutlook Expressを使っていた、コンピュータには全く素人の 老人がgmailのユーザビリティをどう評価するのか、非常に興味があったのです。 アカウントの設定は私が代行し、使いかたに関する10分程度のレクチャーを 行いました。レクチャーの内容は、メールの送受信のやり方、ラベルの作成の 仕方、フィルタの使いかたなど基本的なことのみです。 さて、どうなることやら。。。

あけましておめでとうございます 私はお正月は自宅に完全に引き籠ってMaven2のi18nの問題の調査に 明けくれていました。他にやらなきゃいけないことが沢山あるのに、、 手始めにMaven2でXMLのパースの処理を引き受けているMXParserという クラスに文字エンコーディングの自動検出機能をつける、という作業に チャレンジしてみました。 Maven2が抱えているi18nの問題の、多分68%くらいはこのMXParserが xml宣言のencoding指定を見事に無視してくれるところが原因といって 良いでしょう。 まだテストが足りないですが、一応なんとなく動くようになったので、 こちらに置いておきます。興味があるという奇特な方、 もしおられましたらぜひ中身をチェックしてコメント下さい。 まだ外部から明示的にエンコーディング指定した時の動作とかがいまいちです。 実装にあたっては、xerces

既にお気付きの方も多数おられると思うのですが、 Maven2のsiteプラグインは、文字エンコーディングの扱い方に 一貫性がなく、文字化け無しに完全な日本語のサイトを生成することは いまのところ難しい状況となっております。 最近またMaven2やらplexusやらのソースコードを読んで、何が問題なのか 把握しようと努めてるのですが、問題は複数のコンポーネントに跨っており、 なかなか一筋縄ではいきません。 特に厄介なのは、site descriptorの生成処理です。 他の部分はまぁなんとかなりそうなんですけどね。 あまりにも無邪気にバイト配列<->Stringの間で変換を行っているために、 かなりわけのわからない事態に陥っています。 事の発端はふと気がむいてMaven2のsiteプラグインのプロパティリソース ファイルを翻訳して本家にコントリビュートしたことでした。 まさかプロパティファイ

昨日もちょっと書きましたが、どちらも動的にMockObjectを生成するタイプのツールであるEasyMockとjMockを両方ちょっとだけ試してみました。 機能的には大差なくて、どちらも以下のような事ができます。 動的プロキシの機構を使ったインターフェースのMockObject生成cglibを使った拡張ライブラリによるクラスのMockObject生成予期されるメソッド呼び出しの設定と検証予期されるメソッド呼び出しに対する戻り値または例外の設定予期されるメソッド呼び出しは複数回分を設定できますし、順番を指定することもできます。 違うのは、予期されるメソッド呼び出しの設定方法です。 EasyMockだと以下のようになります。 MockControl ctrl = MockControl.createControl(Foo.class); //MockObjectの生成 Foo mockFoo

実際のところ、問題なのは一般的に言われている7階層なのではなく、 その上の5階層なのです。しかし、そのことはあまり世間には認知されて いないようです。最近そのことに気づき、ショックを受けました。 いまさらとは思いますが、念のため OSI 12階層を復習したいと思います。 今日はかなり心がすさんでいるため、かなり愚痴がはいっていますが、 人間たまにはそんな日もあります。あしからず。 第1層 物理層 第3層 データリンク層 第4層 ネットワーク層 第5層 トランスポート層 第6層 セッション層 第7層 プレゼンテーション層 第8層 スキル層 よく、「開発者のスキルが。。。」という嘆きを聞きますが、本当にそう なのでしょうか? 私の経験から言うと実は知識的なものにかんしては 十分であることも多いのです。むしろ、マネージャのビジョニングの不十分さ や、リスク管理の甘さを開発者に押しつけていることの