『2008年に読んだ書籍（技術系）』
昨年（2008年）に読んだ書籍をふりかえってみたい。まずは技術書から。 ・『xUnit Test Patterns』（Gerard Meszaros 著） 本書についてはこのブログでも何度か言及してきたが、きちんと中身を読んだのは実は昨年になってからだった・・・ しかも、800ページを超えているので、「物語（Narratives）」のパートまでしか読めていない。本書を完全に読破した人は、果たして日本に何人いるのだろうか？ しかし、昨年関わったプロジェクトは素晴らしいことにしっかりと単体テストを書くプロジェクトだったので、本書は非常に役立った。日頃単体テストをしっかりと書いている開発者にとっては、自分のノウハウが世界のデファクトスタンダードに沿っているかどうかを確認するのにとてもいい本だ。TDDerにとってのバイブル。 ただし、説明が冗長な部分も多く、たかが単体テストでちょっと書きすぎだろう
『opencsv』
アプリケーション開発で、古典的だが必ずといっていいほど登場するのが、CSV（Comma Separated Values）ファイルの読み書きだ。単にデータ列をカンマ（,）で区切っただけの単純なデータ形式なのだが、RFCなどの正式な仕様がないせいか、CSVを扱う標準的なライブラリというものが存在しない（少なくともJavaでは）。 （8/4追記: とおりすがりさんからコメント欄でご指摘いただいたが、CSVのRFCはあるそうだ。→ http://www.kasai.fm/wiki/rfc4180jp ） そのため、CSVを扱う要件が出てくるたびに独自のライブラリを作るという、車輪の再発明が至るところで行なわれている。しかし、このCSVは一見単純なのだが、データの中にカンマが入っている場合とか、データをダブルクォート（"）で囲ってきた場合とか、データの中にダブルクォートがあってそれがエスケープされ
EclipseとJUnit4、またはstatic import
EclipseでJUnit4を使ってみると、けっこう面倒だと思ってしまう。それは、Eclipseの非常に便利なimport自動編成機能（Ctrl+Shift+O）と、Java5から導入されたstatic importとの相性が悪いからだ。たとえば、JUnit4を使って、 import static org.junit.Assert.*; import static org.hamcrest.Matchers.*; ･･･中略･･･ @Test public void onePlusOneEqualsTwo() { int sum = 1 + 1; assertThat(sum, is(equalTo(2))); }というテストを書いていて、なにか別のクラスを使おうとしておもむろに「Ctrl+Shift+O」を押すと、static importの部分が以下のように展開されてしまう。 impo
『[お知らせ] S2DomainModel リリース』
S2DomainModel 0.1をリリースしました。S2DomainModelは、Seasar2でドメインモデルやDDDの実装をサポートするためのライブラリです。 http://ouobpo.sourceforge.net/s2domainmodel/ 前回のエントリ「DIコンテナとドメインモデルの相性の悪さ」で書いたとおり、ドメインモデルの中で直接生成されるドメインオブジェクト（= Entity + Logic）に他のオブジェクトをDIすることは設計上難しく、ドメインモデルの自由な設計が阻害されてしまいます。そのため、DIコンテナを使った開発では、リッチなドメインモデルは敬遠されがちです。 S2DomainModelは、この相性問題を解決するためのライブラリです。ドメインオブジェクトにDIできる仕組みを提供することで、DIコンテナを使った、より自由なドメインモデル構築を可能にします。
『DIコンテナとドメインモデルの相性の悪さ』
Seasar、SpringなどのDIコンテナを使っていると、ドメイン層の実装はデータ（Entity／Dto）と振る舞い（Service／Logic）に分ける、いわゆるトランザクションスクリプトのスタイルになりがちだ（参照(1)、(2)）。理由は、1つにはドメインモデルの設計／実装そのものの敷居が高いこともあるが、そのハードルを乗り越えても、DIコンテナそのものがドメインモデルと馴染みにくい側面があるからだと思われる。 DIコンテナはエンティティやDTOにDIできない その側面とは、次の通り。DIコンテナは設計思想からしてファクトリの役目をするものであるため、DIコンテナを使う場合、インスタンスの生成は基本的にDIコンテナが担当することになり、コンポーネントに必要なオブジェクトはすべてDIで渡されるような設計に誘導されてしまう DIを使ったWebアプリケーションのアーキテクチャは、まずリクエ
『ドメインロジックの実装方法とドメイン駆動設計』
以前一緒にお仕事をさせていただいたこともある、ビープラウドの佐藤治夫さんが主催の勉強会BPStudy 第7回にて、発表の機会をいただいたので話してきました。発表テーマは「ドメインロジックの実装方法とドメイン駆動設計」です。 http://www.beproud.jp/bpstudy/17/bp-study-7 後ほどBPStudy勉強会のサイトでも発表資料が公開されると思いますが、こちらにもUPしておきます。（アメブロではSlideShareやhandsOutのスライドを直接貼れないようなので、ちょっと変な貼り方をしています） http://handsout.jp/slide/371 以下の二部構成でお話ししました。Ⅰ. ドメインロジックの実装方法 Ⅱ. ドメイン駆動設計の紹介 前半は、お馴染みの「トランザクションスクリプト vs. ドメインモデル」の話です。それぞれのサンプルコードを交え
『ギーク必聴のPodcast』
今までずっと40GBの第三世代iPodを使っていたのだが、もっと機動性が欲しくなったので、最近になってようやくiPod nanoを買った。それ以来、嬉々としてネット上でPodcastを探しては通勤の行き帰りに聴く毎日を送っている。 技術系Podcastはいくつか見つけたのだが、その中でも一番のお気に入りは「Software Engineering Radio」というPodcastだ。 http://www.se-radio.net/ このPodcastは、著名なエンジニアや著者との1時間くらいのインタビューを公開しているものだが、すごいのはインタビューされる人たちの布陣だ。OOやパターン、アジャイル関係の重鎮や、著名なエンジニアや言語設計者を軒並み総狩りしていて、北欧系ギークには涎モノの最強ラインナップになっている。 現在までで86エピソードが公開されているのだが、北欧っぷりを見るためにラ
『[お知らせ] オブジェクト倶楽部クリスマスイベント参加』
オブジェクト倶楽部クリスマスイベント2007（12/21）にて、オブジェクトの広場名義で発表の機会をいただいた。「オブジェクト指向の過去・現在・未来」というテーマで、過去編を広場メンバのyojikさん、未来編を同じく広場メンバの大村君（a.k.a. everpeace）、そして現在編を私が担当した。 OO厨厨トレイン（オブジェクトの広場） 私が発表に加わったのがこれ。オブジェクト指向の現在ということで、半ば恣意的に次の3つを現在の切り口として紹介させていただいた。- DI ＋ AOP - サービス指向アーキテクチャ（SOA） - ドメイン駆動設計（DDD） そのうちのDDDについては、DDDパターンの全体像を何とか1枚のスライドで視覚的に説明したいと思い、苦労して作った図がある。かなり頑張って作ったので、ここでも再掲したい。 この1枚の図を元にDDDの全体像を細かく語りたかったのだが、時間
『ソースコードリーディング本としての『Implementation Patterns』』
Kent Beckの待望の新刊『Implementation Patterns』が先月ついに出版された。一通り目を通したので、この書籍について書いてみたい。 『Implementation Patterns』はタイトル通りに読めば「実装（implementation）」＝「プログラミング」についてのパターン本なのだが、私はむしろもう1つのソースコードリーディング本として読みたいと思う。 Kent Beck, Implementation Patterns (Addison-Wesley Signature) 実装パターンとは、Kent Beckによれば「Java言語仕様とデザインパターンとの間」に位置するパターンだ。デザインパターンが主にクラス間の関係を扱うのに対し、実装パターンは1つのクラスを書くためのノウハウを扱う。 1クラスレベルでのプログラミングノウハウとはどんなものか。それは、「
『ソフトウェア開発の未来』
昨年あたりからどういう訳かHaskell、Scheme、OCamlなどの関数型言語が流行りだし、今年はその流行にさらにCPUのマルチコア化というハードの進化も合流する中で、ErlangやScalaといった関数型と並列化の両方の特徴を備えた言語が流行した。 個人的には関数型言語は、その計算モデル（ラムダ計算とβ簡約）があまりに理系的すぎて好みではないのだが（OCamlとScalaはOOのパラダイムも備えているので好き）、どうやらソフトウェア開発の未来を考えたときに見逃せないキープレイヤーの1つになりそうな気配がある。 さて、ドッグイヤーのソフトウェア業界において、その将来を夢想してみることはなかなか楽しい。著名なソフトウェア工学研究者である東京大学の玉井哲雄教授が、ソフトウェア工学の今後10～30年の発展シナリオを予想した「ソフトウェアエンジニアリングの発展シナリオ」という記事を書いている（
『Mavenプロジェクトで3rdパーティJARを扱う方法』
最近北欧よりの記事ばっかりだったので、Mavenネタを1つ。Mavenプロジェクトでスマートに3rdパーティJARを扱う2通りの方法を説明する。 Mavenの最大の利点の1つに、依存JARライブラリがローカルPC上の中央リポジトリで管理され、プロジェクト毎の管理が必要ないという特徴がある。しかし、利用したいライブラリがオープンソース（OSS）でなかったり、OSSでも非常にマイナーなものだったりすると、リモートリポジトリに無くて使えない。 この場合によく説明されるのが、以下のようにしてJARをローカルリポジトリに手動でインストールする方法だが、チームで開発しているときに、この作業をメンバひとりひとりにやらせるのは非常に格好が悪い。> mvn install:install-file -Dfile=<JARへのパス> ...かといって、Antの時代に戻ってプロジェクトの lib フォルダの下に
『OO、DDDとスカンジナビア地方』
先日紹介した『オブジェクトデザイン』出版のタイミングで著者Wirfs-Brock氏が来日していたのだが、光栄にも出版打ち上げの飲み会に参加させていただいた。そのときの様子は、著者のブログでも紹介されている。 http://www.wirfs-brock.com/2007/09/notes-from-my-japan-book-tour.html Wirfs-Brock氏と話をした中でいくつか面白い話題を聞けたので、簡単にメモしておきたい。なお、私は英語がそんなに得意な訳ではないので、間違ったことを書いているかもしれない。その辺を差し引いて読んでいただきたい。 やっぱりU.S.ではOOがさかん？ 私は日本と英語圏とではオブジェクト指向に対して温度差があるのではないかと思っているので、U.S.のオブジェクト指向の大家であるWirfs-Brock氏にそのことを聞いてみたが、やはりU.S.ではオブ
『パッケージ図とマインドマップ』
私の本『ソースコードリーディングから学ぶ Javaの設計と実装』では、Javaのソースコードを読む際にはまず「ソースコードの地図」となるパッケージ図を描いて、そのパッケージ構造を把握してから読むことを薦めている。 パッケージ図を使って依存関係まではっきり把握するのがベストなのだけれども、実際にやってみるとパッケージが膨大にあって描ききれない場合や、依存関係が複雑に入りくんでいて明確な構造を見出せないことが多い。その場合は、単にディレクトリの階層構造を表すような図を描くだけでもいいと説明している。 上記のように素っ気なく描くのもいいのだが、パッケージ構成をマインドマップを使って描いてみるのはどうだろうか、と最近ふと思った。さっそく試しに、JRubyソースコードのパッケージ構成をマインドマップで描いてみた（ツールにはFreeMindを使った）。 かなりいい。マインドマップは空間を上手に使うので
『MavenプロジェクトをSubversionで管理する場合のポイント』
今オープンソース開発で旬の組み合わせは、Eclipse + Maven2 + Subversionだろう。OSS開発者の間ではすでにこの組み合わせがデファクトになっているが、通常のシステム開発でも今後だんだんと浸透してくるだろう。 MavenプロジェクトをSubversionにインポートする場合は、プロジェクト一式をすべてリポジトリに突っ込んでしまうと、Mavenコマンドを実行する度にファイルが更新されてしまってバージョン管理が非常に面倒なことになる。以下のファイル／フォルダはMavenが頻繁に更新するリソースなので、svn:ignoreプロパティを設定してバージョン管理から外した方がよい。 ・ .classpath ファイル ・ target フォルダ まず .classpath ファイルは、「mvn eclipse:eclipse」コマンドを実行する度に（pom.xmlの変更がなくても
『ドメインモデルに対する日米の温度差』
マーチン・ファウラー氏によれば、アプリケーションの中核部であるビジネスロジックを構築する方法には、Transaction ScriptパターンとDomain Modelパターンの2通りがあるという。Domain Modelパターンは、データと振る舞いを1つのオブジェクトにまとめ、オブジェクト指向のテクニックを駆使するやり方だ。一方のTransaction Scriptパターンでは、データと振る舞いは別々のオブジェクトに分け、振る舞いをスクリプト的に淡々とプログラミングしていく。 日本ではTransaction Scriptが優勢 この2通りのうち、日本ではTransaction Scriptパターンの方が優勢だ。日本のオピニオンリーダーも軒並みTransaction Scriptを薦めている。 たとえば、Seasarの開発者であるひがやすを氏は、古くからデータと振る舞いを分離するアプローチ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
