今日、初対面の技術者との会話の中で、ハドゥープという単語が出てきた。最初よく聞き取れず、「はぁ？ハヌですか？ハドブ？」なんて聞き返してしまった。恥ずかしい。
帰宅して、ヤマ勘で Hadoop とタイプしてググってみると、ちゃんとスペルが合ってたらしく、それっぽいのがたくさん引っかかってくる。その中に、Apache Hadoop とかいうのがある。うん、なんか知らないけどこれだろ、これ。
つうか、どこの馬の骨とも知れないマイナー製品かと思ったら、れっきとした ASF の Top Level Project らしい。YouTubeでも、たくさん動画がある。
※ちなみに、「ハデュープ（敢えて五十音にマッピングすると）」って感じで発音してる欧米人も多い。
簡単に言うと、分散コンピューティング環境上で稼働する大量データ処理フレームワークで、分散ファイルシステム、分散DB、MapReduce の Java 実装なんかが含まれているらしい。Google の既存製品やプログラミングモデルに影響を受けているとの事。
下の動画が、紹介レベルとしては能くまとまってる感じ。（ただし音声は滅茶苦茶に酷いが）
しかし、こんな有名で面白そうなのを知らなかったのか、俺…。
まあ 2年以上、仕事としては Java から離れていたわけだけど、
うーん、やっぱブランクかなあ…
2011年5月29日日曜日
ユビキタス言語のベースの言語
ドメイン駆動開発（DDD）を謳っている開発案件が、なんだか最近出始めてきたらしい。今日は、このDDDの中での最重要プラクティスのうちの一つである「ユビキタス言語」について思案してみる。
ちょうど一年くらい前、日本のソフトウェア開発現場でも、せめてユースケースだけでも英語化されるといいなあ、という思いを書いた。そこで、「ほとんどの日本の現場では、日本語による要件定義と英語ベースの実装作業との間のどこかに日本語⇔英語のギャップが横たわっていて、これがオブジェクト指向開発の効果的な流れを阻害しているが、要件定義側、特にユースケースの段階で英語化してしまえば、この不経済がかなり解消できると思われる」という事を述べた。
個人的には英語→日本語のギャップが、実はかなり昔から、オブジェクト指向分析やドメイン・モデリングの普及や実施において大きな阻害要因になっていたのではないかと常々思っていたが、意外と取り沙汰される事がない。必然的に問題として認識しようもない英語圏ならばともかく、日本の開発現場では、一応気にはなっている技術者もきっと少なくないはずなんだけど。
さて DDD においては、業務の世界と開発の世界の狭間に、ユビキタス言語---つまりドメイン専門家とのコミュニケーションにおいても、プログラミング言語を用いたコーディングにおいても、常に一貫して使用する事を求められる共通言語---が策定される事になっていて、これが肝だったりする。
で自分が思うに、このユビキタス言語についても、ユースケースと同じ理屈で英語ベースにしてしまってはどうかと。
この英語ベースのユビキタス言語の語彙を用いて、クライアントや業務SEと対話し、ドメインモデルの各要素に名前を与え、プログラム中のクラスやメソッドに識別子を与えるようにすれば、無駄なギャップが解消され、少なくとも英語圏ではほぼ自動的に実現されるレベルの一貫性・直接性に、ちょっとは近づけるのではないかと思う。※1
もちろん、言語の差異の吸収という非英語圏特有の負担を押し付けられてしまっているわけだから、Eric Evans らが考えるオリジナルのユビキタス言語からはちょっと変質してしまうかもしれない。英語の使用により、業務屋にとってもプログラマにとっても、多かれ少なかれユビキタス言語の「難易度」は高まるとは思う。
それでもやっぱり、開発工程全体のどこかで必ず生じるこのギャップを、結局はどこかで吸収せざるを得ないならば、開発序盤、あるいは「上流工程」で英語化してしまうのが一番経済的って気がする。
もちろん顧客によっても、事情は大きく変わるに違いない。社内公用語を英語にするような動きのある顧客では、さして抵抗も強くないはず（楽天だけじゃなく、最近は結構増えてきている）。逆に、余りにも一般教養レベルが低いような層の顧客だと、ワンクッションとしての業務SEを置いて、英和変換させるなどの策を講じないと難しいかもしれない。
あと、単なるユースケースの英語化と違って、ユビキタス言語の場合は文書だけじゃなく会話でも使うだろうから、カタカナ英語を日本語の助詞や助動詞でくっつけたような変な会議風景が現出するかもしれない（完全英語化すれば別だけど）。
まあ、日本語と英語のどちらをユビキタス言語のベースに採用するにせよ、「どっちを選んだときに、どんな作業や問題が発生するか（DDD関連の洋書には普通書かれていない）」について、予めよくよく考えておく事が、DDD導入にあたっては大きなポイントになってくるんじゃないだろうか。
====
※1 あまりにも無学なPGばかりが集まる底辺プロジェクトだと、JavaやC＃等の高水準OOPLが英語ベースであることすら認識されていない事が多い。彼らにとってはプログラミング・コードなんて、記号の羅列としか認識されていないから、そもそもドメインの語彙とか分析とか殆ど関係ない。従ってもちろん DDD も大して意味が無い。
ちょうど一年くらい前、日本のソフトウェア開発現場でも、せめてユースケースだけでも英語化されるといいなあ、という思いを書いた。そこで、「ほとんどの日本の現場では、日本語による要件定義と英語ベースの実装作業との間のどこかに日本語⇔英語のギャップが横たわっていて、これがオブジェクト指向開発の効果的な流れを阻害しているが、要件定義側、特にユースケースの段階で英語化してしまえば、この不経済がかなり解消できると思われる」という事を述べた。
個人的には英語→日本語のギャップが、実はかなり昔から、オブジェクト指向分析やドメイン・モデリングの普及や実施において大きな阻害要因になっていたのではないかと常々思っていたが、意外と取り沙汰される事がない。必然的に問題として認識しようもない英語圏ならばともかく、日本の開発現場では、一応気にはなっている技術者もきっと少なくないはずなんだけど。
さて DDD においては、業務の世界と開発の世界の狭間に、ユビキタス言語---つまりドメイン専門家とのコミュニケーションにおいても、プログラミング言語を用いたコーディングにおいても、常に一貫して使用する事を求められる共通言語---が策定される事になっていて、これが肝だったりする。
で自分が思うに、このユビキタス言語についても、ユースケースと同じ理屈で英語ベースにしてしまってはどうかと。
この英語ベースのユビキタス言語の語彙を用いて、クライアントや業務SEと対話し、ドメインモデルの各要素に名前を与え、プログラム中のクラスやメソッドに識別子を与えるようにすれば、無駄なギャップが解消され、少なくとも英語圏ではほぼ自動的に実現されるレベルの一貫性・直接性に、ちょっとは近づけるのではないかと思う。※1
もちろん、言語の差異の吸収という非英語圏特有の負担を押し付けられてしまっているわけだから、Eric Evans らが考えるオリジナルのユビキタス言語からはちょっと変質してしまうかもしれない。英語の使用により、業務屋にとってもプログラマにとっても、多かれ少なかれユビキタス言語の「難易度」は高まるとは思う。
それでもやっぱり、開発工程全体のどこかで必ず生じるこのギャップを、結局はどこかで吸収せざるを得ないならば、開発序盤、あるいは「上流工程」で英語化してしまうのが一番経済的って気がする。
もちろん顧客によっても、事情は大きく変わるに違いない。社内公用語を英語にするような動きのある顧客では、さして抵抗も強くないはず（楽天だけじゃなく、最近は結構増えてきている）。逆に、余りにも一般教養レベルが低いような層の顧客だと、ワンクッションとしての業務SEを置いて、英和変換させるなどの策を講じないと難しいかもしれない。
あと、単なるユースケースの英語化と違って、ユビキタス言語の場合は文書だけじゃなく会話でも使うだろうから、カタカナ英語を日本語の助詞や助動詞でくっつけたような変な会議風景が現出するかもしれない（完全英語化すれば別だけど）。
まあ、日本語と英語のどちらをユビキタス言語のベースに採用するにせよ、「どっちを選んだときに、どんな作業や問題が発生するか（DDD関連の洋書には普通書かれていない）」について、予めよくよく考えておく事が、DDD導入にあたっては大きなポイントになってくるんじゃないだろうか。
====
※1 あまりにも無学なPGばかりが集まる底辺プロジェクトだと、JavaやC＃等の高水準OOPLが英語ベースであることすら認識されていない事が多い。彼らにとってはプログラミング・コードなんて、記号の羅列としか認識されていないから、そもそもドメインの語彙とか分析とか殆ど関係ない。従ってもちろん DDD も大して意味が無い。
2011年5月28日土曜日
FedoraCore12 + JBoss6.0 + Helios
久しぶりにJava案件をやることになりそうなので、自宅環境を準備。だいぶ前に FedoraCore12 を入れたマシンがあったので、これを使うことにする。
FedoraCoreメニューの「ソフトウェアの追加と削除」に Eclipseがあったのでインストールしてみたが、これは一世代前の Galileo だったので、アンインストールして Helios を入れ直すことにした。と言っても、Eclipse 本家サイトから java EE開発用のバイナリを落として、単に /usr/local/eclipse/下に展開しただけで、特に難しい作業は無し。
で、一応Webアプリという事で、アプリケーションサーバが必要になるが、とりあえず JBoss の6.0 を入れることにした。JBossサイトのインストールの説明に従ってしばし簡単な作業をしてから、run.sh で起動して正しくインストールされ起動する事を、ログとブラウザで確認。
次に Eclipse との連携を準備。Eclipse の Servers ビューで新規追加しようとしたら、Server Adapter が JBoss5.0 までしかなくて一瞬戸惑ったが、JBoss5.0 のアダプタでも問題なくJBoss６.0を動かせるという話があったので、とりあえず信用してJBoss5.0でサーバを追加。ところが、起動してみるとrun.sh からの起動では出ていなかった例外がスタックトレースされている。
ググってみると、同じ現象についてとあるサイトで議論されていた。これを参考にプラグインのjar（JBoss 6.0 対応の Server adapterらしい）をダウンロードして（ここから）eclipse/plugin下に展開。さっき作った JBossサーバを一旦削除してからEclipseを再起動し、再び Server ビューから新規作成を始めると、今度はJBoss6.0が選択肢に含まれている。これを指定して再作成。
おもむろにスタートボタンを押すと今度はエラー無しに起動する。念のため、適当に Dynamic Web Application を作成し、適当なtest.jsp を追加してデプロイ。ちゃんと表示される事を確認。
とりあえず、準備できた。
FedoraCoreメニューの「ソフトウェアの追加と削除」に Eclipseがあったのでインストールしてみたが、これは一世代前の Galileo だったので、アンインストールして Helios を入れ直すことにした。と言っても、Eclipse 本家サイトから java EE開発用のバイナリを落として、単に /usr/local/eclipse/下に展開しただけで、特に難しい作業は無し。
で、一応Webアプリという事で、アプリケーションサーバが必要になるが、とりあえず JBoss の6.0 を入れることにした。JBossサイトのインストールの説明に従ってしばし簡単な作業をしてから、run.sh で起動して正しくインストールされ起動する事を、ログとブラウザで確認。
次に Eclipse との連携を準備。Eclipse の Servers ビューで新規追加しようとしたら、Server Adapter が JBoss5.0 までしかなくて一瞬戸惑ったが、JBoss5.0 のアダプタでも問題なくJBoss６.0を動かせるという話があったので、とりあえず信用してJBoss5.0でサーバを追加。ところが、起動してみるとrun.sh からの起動では出ていなかった例外がスタックトレースされている。
20:56:53,101 ERROR [AbstractKernelController] Error installing to Instantiated: name=PostEjbJarMetadataDeployer state=Described: java.lang.NoSuchMethodError: javax.annotation.Resource.lookup()Ljava/lang/String;
at org.jboss.metadata.annotation.creator.AbstractResourceProcessor.createResourceEnvRef(AbstractResourceProcessor.java:394) [:2.0.0.Alpha24]
at org.jboss.metadata.annotation.creator.AbstractResourceProcessor.process(AbstractResourceProcessor.java:237) [:2.0.0.Alpha24]
…略
ググってみると、同じ現象についてとあるサイトで議論されていた。これを参考にプラグインのjar（JBoss 6.0 対応の Server adapterらしい）をダウンロードして（ここから）eclipse/plugin下に展開。さっき作った JBossサーバを一旦削除してからEclipseを再起動し、再び Server ビューから新規作成を始めると、今度はJBoss6.0が選択肢に含まれている。これを指定して再作成。
おもむろにスタートボタンを押すと今度はエラー無しに起動する。念のため、適当に Dynamic Web Application を作成し、適当なtest.jsp を追加してデプロイ。ちゃんと表示される事を確認。
とりあえず、準備できた。