A Life in Shinjuku.

WindowsでLeiningen behind a proxy

2011-11-08T16:26:00.001+09:00

JavaEE勉強会でProgramming Clojureを読んではいるものの、途中不参加だった時期もあり、いまいち身についている感がない。このまま終わってしまうのもアレなので、Webアプリでも作ってもう少し慣れようなどと思い立つ。仕事で時間ができた時に少しずつさわることを想定して、Windows上で環境構築をはじめることにした。

まずはNoirフレームワークで

Webで調べてみたところ、Clojure用フレームワークとしてはCompojureが有名っぽい。そういえば、JavaEE勉強会の角田さんによる発表で、Heroku＋CompojureでWebアプリを作っていたような気がする。しかし、社内からはProxyの問題でHerokuが使えないことは確認済み。同じ構成だとHerokuに上げたくなって悔しくなりそう。違うフレームワークを探してみたところ、Noirというものを見つけた。シンプルなWebフレームワークらしいので、まずはNoir向けに環境を作って動かしてみよう。

# と思ったら、NoirはCompojure＋Ring上に構築されてるらしいです

Leiningenインストール

lein-noirというプラグインを使えばNoir関連の依存ライブラリをインストールしてくれるらしいので、Leiningenからインストールする。現在の最新バージョンは1.6.1.1。LeiningenのGithubからlein.batをダウンロードし、Pathの通った場所に置いてから

lein self-install

すればOK。ただし、Path上にWget.exeがない場合は leiningen-x.x.x.x-standalone.jar がダウンロードできずに怒られるので注意。この辺りは親切にも、lein self-install のエラーメッセージにダウンロード先を含めて書いてあるので問題ないとは思う。

Proxy環境の人なら、環境変数にhttp_proxyを設定すればOK。認証ありでも同じく環境変数を設定すれば問題なし。

lein-noirインストール

最新のバージョンは1.2.1。以下のコマンドでOK…のはずだった。

lein plugin install lein-noir 1.2.1

しかし、あえなくエラー発生。リポジトリ上にlein-noir-1.2.1.jarが見つからないらしい。ブラウザからclojars.org/repo に行って確認したところ、JARはきちんと存在している。

D:\>lein plugin install lein-noir 1.2.1
Exception in thread "main" org.apache.maven.artifact.resolver.ArtifactNotFoundEx
ception: Unable to download the artifact from any repository
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=lein-noir -DartifactId=lein-noir -Dversio
n=1.2.1 -Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=lein-noir -DartifactId=lein-noir -Dversion=
1.2.1 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

lein-noir:lein-noir:jar:1.2.1
from the specified remote repositories:
clojars (http://clojars.org/repo/),
central (http://repo1.maven.org/maven2)
(NO_SOURCE_FILE:0)
at clojure.lang.Compiler.eval(Compiler.java:5440)
at clojure.lang.Compiler.eval(Compiler.java:5391)
at clojure.core$eval.invoke(core.clj:2382)
at clojure.main$eval_opt.invoke(main.clj:235)
at clojure.main$initialize.invoke(main.clj:254)
at clojure.main$script_opt.invoke(main.clj:270)
at clojure.main$main.doInvoke(main.clj:354)
at clojure.lang.RestFn.invoke(RestFn.java:551)
at clojure.lang.Var.invoke(Var.java:390)
at clojure.lang.AFn.applyToHelper(AFn.java:193)
at clojure.lang.Var.applyTo(Var.java:482)
at clojure.main.main(main.java:37)
Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable
to download the artifact from any repository
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=lein-noir -DartifactId=lein-noir -Dversio
n=1.2.1 -Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=lein-noir -DartifactId=lein-noir -Dversion=
1.2.1 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

lein-noir:lein-noir:jar:1.2.1
from the specified remote repositories:
clojars (http://clojars.org/repo/),
central (http://repo1.maven.org/maven2)

at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De
faultArtifactResolver.java:212)
at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveAlw
ays(DefaultArtifactResolver.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:90)
at clojure.lang.Reflector.invokeInstanceMethod(Reflector.java:28)
at leiningen.install$standalone_download.invoke(install.clj:39)
at leiningen.install$install.invoke(install.clj:62)
at leiningen.plugin$install.invoke(plugin.clj:32)
at leiningen.plugin$plugin.invoke(plugin.clj:75)
at clojure.lang.Var.invoke(Var.java:373)
at clojure.lang.AFn.applyToHelper(AFn.java:167)
at clojure.lang.Var.applyTo(Var.java:482)
at clojure.core$apply.invoke(core.clj:540)
at leiningen.core$apply_task.invoke(core.clj:229)
at leiningen.core$_main.doInvoke(core.clj:294)
at clojure.lang.RestFn.applyTo(RestFn.java:139)
at clojure.core$apply.invoke(core.clj:542)
at leiningen.core$_main.invoke(core.clj:297)
at user$eval42.invoke(NO_SOURCE_FILE:1)
at clojure.lang.Compiler.eval(Compiler.java:5424)
... 11 more
Caused by: org.apache.maven.wagon.ResourceDoesNotExistException: Unable to downl
oad the artifact from any repository
at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(Def
aultWagonManager.java:332)
at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De
faultArtifactResolver.java:200)
... 33 more

どうやら内部的にはMavenを使っているようなので、 ~/.m2/settings.xmlにproxy設定を追加してみたが状況は変わらず。ちなみに、プロキシがローカルホストなのは、NTLM認証が面倒なのでローカルプロキシを入れているため。

<settings>
  <proxies>
   <proxy>
      <active>true</active>
      <protocol>http</protocol>
      <host>localhost</host>
      <port>9090</port>
    </proxy>
  </proxies>
</settings>

切り分けのためにMaven3をインストールし、切り分け用のpom.xmlを作って depenencies に lein-noir 1.2.1 を追加。リポジトリにも clojars を追加してから mvn compile を叩くと、正常にダウンロードが完了した。この後再び lein plugin install lein-noir 1.2.1 と叩くと、無事にインストールが完了したらしい。謎。

lein plugin install lein-noir 1.2.1
Copying 1 file to C:\DOCUME~1\....~1\LOCALS~1\Temp\lein-c7edc836-8953-4a2b-b0e
0-830eeeaa1ad0\lib
Including lein-noir-1.2.1.jar
Including clojure-1.2.1.jar
Created lein-noir-1.2.1.jar

Noirプロジェクト作成

LeiningenでNoirプロジェクトを作成。

lein noir new samplenoir
Creating noir project: samplenoir
Creating new dirs at: D:\...\projects\clojure\samplenoir
Adding files...
Project created!

プロジェクトディレクトリに移動してlein runでサーバが起動してデフォルトアプリケーションが利用可能になる。

lein run
Downloading: org/clojure/clojure/1.3.0/clojure-1.3.0.pom from central
Downloading: org/sonatype/oss/oss-parent/5/oss-parent-5.pom from central
Downloading: noir/noir/1.2.1/noir-1.2.1.pom from central
Downloading: noir/noir/1.2.1/noir-1.2.1.pom from clojars
- 中略 -
Downloading: org/mindrot/jbcrypt/0.3m/jbcrypt-0.3m.jar from clojars
Downloading: org/mindrot/jbcrypt/0.3m/jbcrypt-0.3m.jar from central
Copying 31 files to D:\watanabeknt\projects\clojure\samplenoir\lib
Starting server...
2011-11-08 15:00:00.098:INFO::Logging to STDERR via org.mortbay.log.StdErrLog
2011-11-08 15:00:00.098:INFO::jetty-6.1.25
2011-11-08 15:00:00.238:INFO::Started SocketConnector@0.0.0.0:8080
Server started on port [8080].
You can view the site at http://localhost:8080
#<Server Server@1f02b85>

普通に依存ライブラリをダウンロードできているっぽいんですけど、さっきは何がダメだったのだろう？

Noirアプリケーションにアクセス

コンソールに表示されているとおり、localhost:8080にアクセスすればデフォルトページが表示される。ここには、簡単なサンプルとともに、チュートリアルへのリンクが表示されている。

(defpage "/my-page" [] (html [:h1 "This is my first page!"]))

あれ？なんかあんま好きじゃない感じの記法なんですけど…。なんか昔Javaでこんないけてないライブラリがあったようななかったような。

一区切りついて気に入らなかったら、結局Compojureに行ってしまうかもしれない…。

次

次は、Noirのチュートリアルと、エディタの整備をやりたい。エディタは、CounterclockwiseかClojureboxどちらかの予定。Emacsとは仲良くなれなかったのでCounterclockwiseが有力。

QCon Tokyo 2011 アーキテクチャパネルディスカッション＋DDD雑多ネタ

2011-04-20T16:35:00.004+09:00

アーキテクチャパネルディスカッションとラウンジ・ビアパーティでの雑談から、主にDDDに関して興味深かった話をいくつか。聞き取り能力は低いので抜けている部分もあると思いますがご容赦を。

ビジネス的な有用性はどこにあるのか

Evans氏発言要旨

経営層など意思決定を行う人たちに対して、ドメイン駆動設計の有用性をどう訴えかけるのか？という問いに対して、Evans氏は主にコアドメインへの注力によって競争上の優位、市場優位につなげる部分を強調。ここから一段階細かいレベルとして、ビジネスパーソンにとって理解できるソフトウェアへと進んでいくとのこと。ただし、常に労力に見合う価値が得られるわけではないことも忘れずに付加。

雑感

この質問はなかなか難しく、聴衆の反応も微妙なものだったように思う。これは、DDDをオブジェクト指向設計方法論として受け取っている人が多く、こうした部分の有用性についての回答を期待していたものの、Evans氏は主にPartⅣの戦略的設計（Strategic Design）の有用性について語ったために、ギャップが生じたためだと思う。

DDDは一読するとオブジェクト指向分析・設計方法論に関する本のようにも見えるが、実際はOOに直接結びついているわけではない。ドメインを中心に設計をする上で都合の良いパラダイムが現状ではオブジェクトパラダイムであるために、実現方法を記した部分（PartⅡ、PartⅢ）がオブジェクト指向設計に沿った形で書かれているにすぎない。DDDにとって根本的に重要なのはOOではなく、その名が示すとおり「ドメイン」へのフォーカスだ。この点を踏まえたなら、コアドメインへの注力はシステム/ソフトウェア全体をドメインの観点から区分するという意味で、まさに大きな意思決定を行うレベルでのドメイン駆動設計そのものだということが理解できると思う。
OO話がなかったのは…残念でした。

ドメインエキスパートをどうやって巻き込むのか

Evans氏発言要旨

ドメインエキスパートとの最初のミーティングで、「あなたが最も難しく、面倒だと感じるのはどういった部分なのか？」「安眠を妨げるような問題はないか？」とたずねて、具体的なシナリオをあげてもらう。細かい問題は後で決めれば良い。画面項目の最大長や色などを聞くのはナンセンスで、ただでさえ忙しいドメインエキスパートの貴重な時間を浪費することになる。そんなことをしてはいけない。本当に難しい、重要な問題にフォーカスしてシナリオを描き、シナリオを解決できるモデルをホワイトボードに描き出して共有する。

仮にドメインエキスパートが示す問題がドメインにとってはさほど重要な問題ではなく、彼にとって重要・面倒であるだけであっても大きな問題ではない。彼と信頼関係を構築するのが重要。このセッションがうまくいけば、ドメインエキスパートはセッションを楽しみに待ってくれるようになることもある。これは実際にEvans氏が経験した話。

雑感

画面項目の最大長…といったくだりは刺さった。多くのプロジェクトでは、まさにこうしてドメインエキスパートの時間を無駄にしている。ここでも、ドメインにフォーカスし、重要な部分にリソースを投入する、というドメイン駆動の原則が生きている。リソースというのは、開発者のリソースだけではなく、ドメインエキスパートのリソースも同じなのだ。モデリングセッションの進め方はWhirlpoolに沿ったものだが、ここに至って、繰り返し型・反復型開発の重要性も浮き彫りになってくる。ウォーターフォール型の開発プロセスで、横並びに設計を進めるのなら、こうしたアプローチを取るのは難しくなるだろう。しかし、重要な部分を先に進めることを合意できているなら（RUPくらいなら顧客合意も難しくないだろう）、ドメインエキスパートにとって重要な問題にフォーカスすることで注意を引きつけ、それを知的に解決するさまを共有することでモデリングセッションを軌道にのせる姿も現実的なものとして見えてくるのではないだろうか。

一般的・形式的な概念体系をどう扱うか

問題要旨

書籍Domain Specific Languageでは、ドメインエキスパートとのコミュニケーションを促進するためにDSLを構築し、DSLの背後にある概念体型としてセマンティックモデル（Semantic Model）を導入する。このセマンティックモデルの一形態として代替計算モデル（Alternative Computational Model）が挙げられており、よりうまく問題領域にフィットする場合に有効である旨が記述されている。代替計算モデルとして挙げられているステートマシン（State Machine）、依存ネットワーク（Dependency Network）、決定表（Decision Table）などは言わば確立された形式的な概念体系であるのだが、こうした体系とDDDのモデルはどういった関係にあるのか。

Evans氏発言要旨

確立された概念体系自体は非常に有用であるものの、これは汎用的なものであって、ドメインの重要な概念を直接的に表すものではない。重要なのはむしろ、モデルからこうした概念体系を分離した後に残るものであり、それこそがドメインの概念をより良く表すものとなり得る。

雑感

これは、15章「蒸留（Distillation）」に属するパターンの1つである、凝集されたメカニズム（Cohesive Mechanisms）を念頭に置いた回答ではないかと思う。DDDの書籍では、組織内の関係を表すモデルからグラフ構造をCohesive Mechanismsとして取り出す例があげられており、こうすることで組織のモデルからグラフ構造にまつわる概念群（ノード、アークなど）を消し去って、残されたモデルをより本質的なものにしている。また、貨物輸送の例でも配送ルートを決定する際にグラフ構造が使われており、Itineraryを実装した際に混入したであろうグラフにまつわる概念群を引き剥がすことに成功している。これはDDD Sampleでも確認できる。

DSLの代替計算モデル相当をDDDに組み込む場合、最も素直なアプローチはCohesive Mechanismsとして利用することだと考えている。貨物輸送の例であれば、うまくすればエンドユーザーが書いたDSLスクリプトを解釈実行することで、直接配送ルートを表すグラフ構造を構築でき、このモデルを使って最適経路を計算できるだろう。

ただ、この回答については少し疑問が残っていて、実際は「確立された概念体系」と「ドメインの本質を表す概念群」との境界はそんなにはっきりしたものではないのではないかと思っている。例えば、8章「ブレークスルー」などで登場するシェアパイ（SharePie）は、代数的構造の1つである「群」の概念に沿ったもので、確立された概念体系、もしくはそれに限りなく近いものだが、DDD書籍ではドメインエキスパートがこの概念を操り、ユビキタス言語の一部にもなっている。このように、純粋にメカニズム的な意味を持った概念体系は確かにモデルの本質を表しはしないのであろうが、確立された概念体系自体がドメインの本質を表す場合もあるのではないかと思う。

# この話、酔っ払った状態でEvans氏に話そうとしたけどstuckしてしまった…無念すぎる。酔っ払ってなくてもダメだったかもしれないことは置いておこう…。

関連：

英語以外の言語ではどう実践すべきか

問題要旨

英語以外の言語を用いる場合、ほとんどの実装言語が英語に沿ったものであるため、ドメイン概念をそのままソフトウェアとして実装できないことが問題になる。仮にここで、実装言語にあわせて英語を混在させた場合、ユビキタス言語が歪められてしまう。

Evans氏発言要旨

ソースコードでも日本語を使え。以上。

雑感

実際にはこれほど乱暴な話になったわけではない。Evans氏も英語以外の言語での実践経験はなく、他の言語圏でどうやって対処しているのかは不思議に思っていた様子。ただ、Javaのコードを見ながら話をした際にクラス名に対して日本語でコメントがつけられているのを見て、これではダメだと感じたようだった。「ドメインエキスパートがこの言葉（日本語コメントで書かれたクラス名）を使っているのなら、なぜクラス名にこれを使わない？」とのこと。「日本語でJava等を書くと、Java慣習にかたっぱしから違反してしまうので問題なんだ、コードも読みづらいし」と反論（？）してみたものの、「重要なのはドメインの概念であって、技術的な問題はそれに比べれば瑣末なものだろう？」と言われてしまい、もう納得するしかなかった。実際のところ、主語・動詞・目的語・修飾語等の位置が異なるため、英語に比べるとかなり違和感のあるコードが出来上がってしまうのだが、DDDがこれまで述べてきた「ドメイン重視、技術要素は二の次」という姿勢が貫かれていることを知ってすっきりした。これでDDDerは、日本語でコードを書いてみなくちゃならなくなった！実践した人は、Evans氏にフィードバックしてあげましょう。

QCon Tokyo 2011

2011-04-18T10:41:00.001+09:00

QCon Tokyo 2011に、DDD読書会（JavaEE勉強会）のコミュニティ枠として参加させていただきました。初回開催となる2009以来2年ぶりの参加になります。

今回のセッションプログラムはビアパーティまであわせると総数が21で、以下の6つに分類されています。総プログラム数からすると多彩な内容ですね。

クラウド
Design & Patterns
技術
クオリティ & テスト
アーキテクチャ
ケーススタディ

しかし、なんといっても今回の目玉は、DDDの創始者Eric Evans氏の来日でしょう。基調講演に通常プログラム、パネルディスカッションと盛りだくさんの内容でした。僕はこのDDDと、クラウド関連のセッションに的を絞って出席してきました。具体的には、以下の7つ＋ビアパーティに参加、という形です。

ドメイン駆動設計：複雑な問題群に対する有用なモデルたち
Webアプリケーションエンジニアが見てきたこの10年
クラウドのデータアーキテクチャー設計の原則
Understanding IA: The Extension of Man 2011
クラウドコンピューティングの未来：10年後の情報システムを考える
ドメイン駆動設計においてレガシーシステムを扱うための戦略
アーキテクチャパネルディスカッション

セッションの感想
QCon2009風に感想を分類すると、こんな感じでした。

[面白かった！]

クラウドのデータアーキテクチャー設計の原則
クラウドコンピューティングの未来：10年後の情報システムを考える
ドメイン駆動設計においてレガシーシステムを扱うための戦略
アーキテクチャパネルディスカッション

[ふつう]

ドメイン駆動設計：複雑な問題群に対する有用なモデルたち

[いまいち]

Webアプリケーションエンジニアが見てきたこの10年
Understanding IA: The Extension of Man 2011

雑感

今回のQConでは、2年前に比べると統一的な方向性のようなものを見出すことはできませんでした。色々な人が色々なことをやっていて、その成果を個々に見ているような感じです。これは、僕が主に出席したクラウド系のセッションとDDD関係のセッションの方向性がかなり異なっているのが大きな理由かもしれません。

クラウド系

クラウド系で特に面白かったのは、佐藤一郎氏の「クラウドコンピューティングの未来：10年後の情報システムを考える」でした。この講演では、クラウドコンピューティングをソフトウェア技術中心の他のセッションとは異なった視点から捉えており、クラウドコンピューティングと物流業態との類似性や他の業態を模した異なる形態でのクラウドコンピューティングの可能性、アプリケーションとの関係、アプリケーションのビジネス化のヒントが散りばめられていて、非常に新鮮なものでした。

DDD系

DDDのセッションで面白かったのは、Eric Evans氏の「アーキテクチャパネルディスカッション」でした。ここでの収穫はなんといっても、Evans氏自らドメインエキスパートとのモデリングセッションについて、具体例を交えて生き生きと語ってくれたことでした。ドメインエキスパートとのモデリングセッション自体はDDD書籍にもいくつか例示されているのですが、どのようにしてドメインエキスパートとのモデリングに入っていくのか、的を絞ったモデリングセッションを続けるにはどうすればいいのか、どの程度の頻度でモデリングを行うのか、など実際に実行する上で不明な部分が多く、果たして現実的に可能なのだろうか、と疑問に思った人は多数いたように思います。今回は氏自らセッションへの入り方、雰囲気作り、関係の保ち方、焦点の絞り方といった部分を語ってくれたことで、こうした部分を現実感を持って理解することができました。こうした方法は、Model Exploration Whirlpoolというミニプロセスとして形式的にまとめられており、DDDの前進を感じることができました。

# 面白かったものについては、備忘録的に個別にエントリを書こうかと思います。

ブレイクスルー体験記＠DevLove Beautiful Development

2011-04-14T01:52:00.000+09:00

DevLoveさんのイベント「DevLove Beautiful Development ソフトウェアの核心にある複雑さに立ち向かう」にて発表させていただきました。
僕のITスキルが低い＆緊張のために、画面が小さいことに気づかずにそのまま進めてしまいました。見えにくかった方、申し訳ありませんでしたorz
イベント全体の情報は、オフィシャルサイトにて非常にわかりやすく整理されています。ぜひそちらへ。

Beautiful Development ブレイクスルー体験記

View more presentations from kentaro watanabe

実は、スライドの最後には僕の大好きな漫画である日本橋ヨヲコ先生の「G戦場ヘヴンズドア」の1シーンを入れてました。すさまじい才能を持ちながら、漫画編集者の父との確執からストーリーが作れなくなった鉄男と、漫画家の父との確執から歪んだ形で小説家を目指す町蔵が心を通わせ、ともに戦場に歩み出そうとするシーンです。

町蔵「バカかお前…何こんな中途半端なモン世に出そうとしてんだよ！！オレは本気が見てえんだよ！！人の顔色うかがって描いてんじゃねえよ！！」
鉄男「作れないんだ、ストーリーが。もう言いたいことがないんだ、オレは、からっぽだから堺田君にひかれたんだよ。」
町蔵（……ああ、こいつもか。）
町蔵（誰にも、）
町蔵（期待してないんだな。）
町蔵「お前は天才かもしれねえ。けどそれだけだ。才能だとか画力だとか、プロはもうそんなとこで生きてねえ。」
町蔵「万人受け狙えば通用するような甘い世界でもねえ。」
町蔵「いいか、オレと組むなら手加減すんな。」
町蔵「…もしお前がもう一度…」
町蔵「オレを震えさせてくれるなら、」
町蔵「この世界で、一緒に汚れてやる。」

ヘタレだから出せなかったよ。でももう何も言うことはないよ。

Code Generation & Language Workbenches＠DSL読書会

2011-04-13T23:17:00.004+09:00

少し前になりますが、DSL読書会＠JavaEE勉強会でCode GenerationとLanguage Workbenchesのまとめを発表したので、ここにも載せておきます。

Google Docsで作ってみたのですが、Slide Shareと勝手が違っていて、埋め込んだ状態でうまく閲覧できそうにないです。まともに見たい人は、最大化ボタンをクリックするのが良いかと思います。

僕の担当分はDSL本の最後の部分で、この資料はそれまでの部分のまとめが他の人から発表されている前提で作っています。これだけ見てもあまりわからないかもしれませんので、字だけになりますが少しだけ補足しておきます（Fowler DSLのエッセンスにさらっと目を通しておかれると、少しは分かり良いかもしれません）。

DSL Overview
DSL概念全体の中でCode Generationがどのような位置づけにあるかを俯瞰するために、Fowler DSLの全体像を示しています。

DSLスクリプトを言語処理層（Language Processing Layer、パーサー/ビルダーなど）が処理することでセマンティックモデルが構築され、セマンティックモデルをアプリケーションから直接実行したり、他の環境向けにコードを生成してから実行することで望みの計算を行います。セマンティックモデルはFowler DSLのキーとなるもので、Fowler DSLを他のDSLアプローチと隔てている最も大きな要因の一つです。

DSLは、DSLスクリプトと言語処理層の形態によって内部DSLと外部DSLに分類されます。内部DSLはDSLスクリプト、言語処理層、セマンティックモデルを同じプログラミング言語上に構築するもので、外部DSLはDSLスクリプトを独立した言語で記述するものです。

言語処理層を構成するパターン群を総称して、構文解析戦略（Syntactic Analysis Strategy）と呼び、特に内部DSLを構築するテクニックが豊富に語られています。

セマンティックモデルから望みの結果を得るためのパターン群を総称して、出力生成戦略（Output Production Strategy）と呼びます。Code Generationはこのうちの1部分という位置づけです。

ちなみに、ハートマークはFowler自身がセマンティックモデルを直接実行するスタイルを好んでいる印としてつけています。本命はセマンティックモデルの直接実行であり、コードジェネレーションは仕方なくやっている、という匂いが文章の端々から感じられるためです。

Code Generation Patterns (What to produce)
コード生成のためのパターンのうち、「何を（どのようなスタイルのコードを）生成するか」についてのパターンを示したスライドです。

Model Ignorant Generationは、その名の通りモデルらしきものがまったく存在しないコードを生成するパターンです。モデルが持つ振る舞いはすべて、コードの中に手続きの形で平坦化されて埋めこまれます。これは、ターゲット環境がサポートする言語に抽象化能力が乏しく、モデルが構成できない場合や、モデルを実体化できるほどメモリリソースに余裕がない場合にある意味仕方なく取られるパターンです。もちろんFowlerはあまり好んではいません。

Model Aware Generationは、ターゲット環境上にも（限られた形態かもしれないものの）モデルを構築し、モデルを操作する形のコードを生成するパターンです。Fowlerお気にです。

Code Generation Patterns (How to produce)
続いて、「どうコードを生成するか」についてのパターンを示したスライドです。「どう作るか」は「何を作るか」に強く依存することに注意が必要です。

Templated Generationは、テンプレートエンジンを使ってコード出力するパターンです。生成対象となるコードで静的に決定される部分が多い場合に有効です。Model Ignorant Generationを使う場合、平坦化されたコードが一定のパターンで繰り返されることが多いため、このパターンが向いています。通常テンプレートエンジンは複雑な制御機構を持っていないため、分岐や選択が入り組んだ複雑な生成には向きません。

Transformer Generationは、モデルを変換するコードをカスタムで作るパターンであり、要はTemplated Generation以外の場合を指しています。複雑な制御が必要であったり、コードに動的に決定される部分が多い場合に向いています。Model Aware Generationを使う場合、コードの記述は最小限となり、繰り返しも少なく静的に決定される部分も小さいため、このアプローチが向いています。

Language Workbenches
言語ワークベンチは、「独自のカスタムDSLを容易に構築できるようにしてくれる環境」です。さらに次のスライドで、言語ワークベンチに共通する要素を紹介しています。FowlerのDSL概念と似た形はとっていますが、異なる部分もいくつかあります。

最も大きな違いは、セマンティックモデルが振る舞いを持つことはほとんどなく、必要な振る舞いはコードジェネレーションのプロセスでテンプレートエンジンによって埋め込まれる点です。
セマンティックモデルが振る舞いを持たないのは、言語ワークベンチが汎用的・統一的に個々のセマンティックモデルを扱えるようにするために「メタモデル」を用意した（せざるを得なかった）のが主な原因のようです。あまり詳しくはないのですが、メタモデルに汎用的な振る舞いの表現を埋め込むのは確かに難しそうです。

もう一つは、セマンティックモデルを様々な方法で視覚化したり、編集したりできる編集環境が用意されている点です。自分が見たツールでは、メタモデルと関連づけながら独自エディタを生成するための開発環境が用意されていました。

MOFとの関係
最後のMOFとの関連はおまけみたいなもんです。とりあえずMOFは忘れてよし！

手抜きで字だらけなのであまり分かりやすくはないと思いますが…

外部DSL実装のためのAntlrチュートリアル

2010-09-19T15:17:00.003+09:00

昨日、JavaEE勉強会で外部DSL実装に向けたAntlrのチュートリアルをやってきた。

AntlrWorks for DSL

View more presentations from kentaro watanabe.

JavaEE勉強会では今Fowler DSL本の読書会をやっており、導入、内部DSLを終え、外部DSLもほぼ終わったあたり（全体だと2/3くらい？）まで来ている。過去内部DSLが終わった際には、理解を深めるために各自で内部DSLを実装して発表するハンズオンを開催している。外部DSLでも同様のハンズオンが開かれる予定で、このチュートリアルはそのための準備という位置づけ。

実際やってみると、以下のようなファイルの保存先パスに日本語が入っているとNGになるケースがあった模様。

AntlrWorksのJAR保存先
文法ファイル（*.g）の保存先

また、文法ファイル名と文法名（文法ファイルの先頭に定義された「grammer」に続く定義）が不一致なため、デバッグ時の自動コンパイルで失敗している人もいた。注意注意。

Fowler DSLのエッセンス

2010-09-19T15:00:00.001+09:00

とあることからFowler DSLのエッセンスを考える機会があり、昔内輪向けに作った資料を引っ張りだして眺めてみたが、わりと良い線いってると思う。

HEAD FIRST DSL

View more presentations from kentaro watanabe.

FowlerのDSL本が提示する価値は、おおまかに以下の3点にある。上記のスライドでは1と2にフォーカスしている。

モデルを中心に据えた思想の提示
実装スタイルの分類
実装テクニック集

これは、紙幅の大半が3に割かれており、書いた時点では実装テクニックを全て把握していなかったことや、そもそも3はまとめがほぼ不可能、ということもあった。

モデルを中心に据えた思想の提示
従来のDSLでは、スクリプトによるモデルの組み立て、という考えが必ずしも明示的に意識されておらず、DSLがもたらす価値の源泉はDSL自身にある、と考える傾向が強かった。
FowlerのDSL本では、DSLによってモデルを組み立てるという点が非常に重視されている。DSLでモデルを構築する場合、今まではDSLによってもたらされている、と思われていた価値の多くは、実際はDSLによってではなくモデルによってもたらされている、ということがわかってくる。
DSLの価値は、モデルによってもたらされる価値を高めることにある。

実装スタイルの分類
これは、最近DSLについて書かれた文章ではほぼ常に述べられている内容で、実装スタイルを以下の2つに分類する、というもの。

内部DSL
外部DSL

スライドだと言語ワークベンチを第３の実装スタイルにしていたが、言語ワークベンチは外部DSLの実装をサポートするためのツールという位置づけかと思う。

実装テクニック集
内部DSL向け、外部DSL向け、共通トピック数多くのパターンが記述されており、DSL実装のためのパタンランゲージが構成されている。少なくとも、普段の仕事でこれらの語彙が使えるようになると非常に助かる。

本の大半を読み終えてみて、1, 2について付け足したいことがあるとすれば、以下の概念同士の関係の補足だろうか。

意味論モデル
（ドメインモデルを含む従来の）モデル
アクティブモデル
代替計算モデル

意味論モデル

意味論モデルは、一般のモデルをDSLの観点から構築対象として見た時の名称／概念。

意味論モデルは、従来のモデルである。
意味論モデルは、アクティブモデルである場合がある。
意味論モデルは、代替計算モデルを表す場合がある。この場合、意味論モデルはアクティブモデルである。

従来のモデル

最も一般的／汎用的なモデル概念。

従来のモデルは、意味論モデルである場合がある。
従来のモデルは、アクティブモデルである場合がある。
従来のモデルは、代替計算モデルを表す場合がある。

アクティブモデル

アクティブモデルは、従来のモデルであるが、インスタンス間の関係が変わるとモデル全体の振る舞いがきわめて大きく変更されるモデルのこと。この性質によって、個々のモデル要素の変更なしに、モデル構成を変更するだけで様々な計算を行うことができる。

語源はOOの「アクティブオブジェクトモデル」だが、オブジェクトパラダイムである必要はないため、アクティブモデルとした。

アクティブモデルは、従来のモデルである。
アクティブモデルは、意味論モデルである場合がある。
アクティブモデルは、代替計算モデルを表す場合がある。

代替計算モデル

命令型計算モデル以外の計算モデル。計算モデルとは、ざっくり言えば計算を表す方法を指す。

命令型計算モデルは、個々の計算ステップを逐次／選択／繰り返しといった制御フローを使って並べることで計算を表すモデル。これ以外の計算モデルとして、「デシジョンテーブル」「ステートマシン」「プロダクションルールシステム」などがあげられている。

代替計算モデルは、アクティブモデルで表現される場合がある。

20110414追記：ドラフト版では「アクティブモデル」と「アダプティブモデル」の間で揺れていた用語は、出版版では「アダプティブモデル」に統一されています。

デブサミ2010 - 出張！DDD難民救済キャンプで話してきました

2010-02-21T01:55:00.000+09:00

DDD読書会＠JavaEE勉強会代表として、「DDD難民に捧ぐ」の佐藤さん、読書会主催syの角田さん、思想系プログラマの和智さん、モデレータのt-wadaさんと一緒にパネルをさせていただきました。
推進派の佐藤さん、懐疑派の角田さん、受託開発現場の立場から自分、言葉を重視する立場から和智さんと、短い時間ながら立場を明確にしたパネルができたと思っています。

【19-B-5】出張！DDD難民救済キャンプ

View more presentations from kentaro714.

パネルの内容自体に関しては、SlideShareをながめながらtsudaってくれた方のTweet（#devsumi2010ハッシュタグ）を眺めれば、おおよその話は見えてくると思います。特に@yattom さんがとても詳細にtsudaってくださっています。
# yattomさんありがとうございます！
というわけで、ここでは内容について書くかわりに、パネルができる過程で起きた「ZENに導かれたブレイクスルー」とでもいうべき転換点について書き残しておきます。

ZENに導かれたブレイクスルー
当日パネルでお話した内容のほかにも、DDDについて話したいことは山ほどありまして、打ち合わせの段階ではThe bookについてのより体系的な紹介や、最近のDDDコミュニティの広がり、実装レベルの具体的な話、BDDやTDD、DSL、PoEAA、アナリシスパターンなど他のアプローチとの関係などなど多くのトピックが候補としてあげられていました。
# 機会があればこれらも何かしらの形でまとめられれば、と思いますが

パネルのタイトルは「出張！DDD難民救済キャンプ」なので、当初はパネルを聞いた人ができる限りDDDの内容を持って帰れることを目指して進めていました。が、これらの内容を50分で、しかもパネルの形式で伝えきるのは明らかに無理があります。やればやるほどパネル形式を取る意味がわからなくなってきて、一度行き詰まりました。

スライドを見ればわかるとおり、僕らはプレゼンテーションZEN廚状態でした。
「PCから離れよう」
このZENの教えに従い、僕らは一度PCを閉じ、これまでの方針を忘れて一から考え直すことにしました。

今回のパネルでは、ZENの言う主要なメッセージは一体何になるのか？つまり、来てくれた人が会場を出るときに持っていて欲しいものは一体何なのか？複数人が議論する「パネル」という形式でも主要なメッセージというのは可能なのか？パネリストがそれぞれ違う意見を持っているのではないか？それぞれが伝えたいことは何なのか？考えの違いを超えて伝えたいことはあるのか？

こうして考えた結果、The bookの内容紹介やDDDの近況については思い切って省略し、かわりにDDDに対する自分たちのポジションを明確に打ち出す方向に転換しました。その上で、個々のメッセージを超えて、会場に来てくれた人に「ちょっとDDDについて調べてみようか」と思ってもらえるようにしたい。これが僕らのメッセージであり、このことに気づいたこの出来事が僕たちにとってのブレイクスルーだった、ということになっています。この思いが暴走した結果、「１、２、３、ディーーー！」みたいな事故が起きたわけですがw

DDDをはじめてみよう！
実際のところ、どうだったんでしょう？メッセージ、伝わったんでしょうか？僕らはただの痛い人になってしまったんでしょうか？痛い人なのは全然かまわないんですが、少しでもDDDに興味を持ってくれる人がいたなら幸甚です。

共訳させていただいた「実用Git」が発売になります

2010-02-17T13:04:00.000+09:00

このたび発売になる「実用Git」を、hirataraさん、kaisehさんと共訳させていただきました。きょう配本だそうなので、ぼちぼち書店に並ぶのではないかと思います。

この本は、前から順番に読みつつ出てくるコマンドを叩いていくことで、自然とGitが内部構造も含めてわかるようになっていることが特徴です。Gitを理解するには内部構造を知ることが近道なのですが、概念的な話だけでは頭に入ってきません。この本では、実際にリポジトリを用意し、コマンドを順に試していくことで、日常の作業と内部構造がつながりをもって理解できるように構成されています。
コマンド出力も丁寧に載せられているので、Git環境が手元にない場合でも、実際にGitを使っているように学ぶことができます。

自分自身、この翻訳をはじめた時は特にGitに詳しいわけではありませんでした。しかし、翻訳をすすめてGitを理解するにつれて、バージョン管理システムをもっとうまく使うことで、今の開発をよりよくできることに気づきました。いま開発でCSV/Subversionをなんとなく使っている人も、この本を読むことで開発をよりよくする道が見えるのではないかと思います。カオスなソースコード管理に悩んでいる人にもおすすめできる本です。興味がわきましたら、ぜひ読んでみてください。

ちなみに、本には直接関係ありませんが、この本の翻訳もGitを使って進められました。

翻訳者3人による編集
監訳者吉藤さんによる監訳
オライリー・ジャパンの宮川さんによる編集

こうした分散作業をGitで行っています。もしこういう仕事の進め方に興味がわいたなら、日本語版で追加された、瀧内元気さんによる「GitHub入門」や、hirataraさんによる「Gitにおける日本語の利用」が役に立つかもしれません。

モデル上に明示されたトランザクションとしてのAggregate

2009-12-19T18:00:00.012+09:00

最初に読んだ時には今ひとつ理解できなかったAggregate。社内のDDD読書会で読み返してみて感じたのは、「Aggregateは、従来の手続き的な一貫性維持に関する情報（トランザクションスコープ含む）をモデル上に明示したものである」と捉えることで理解しやすくなる、ということ。以下もう少し詳しくみていく。

Aggregateの定義と位置づけ

DDDのGlossaryを見るとAggregateは、

A cluster of associated objects that are treated as a unit for the purpose of data changes. External references are restricted to one member of the AGGREGATE, designated as the root. A set of consistency rules applies within the AGGREGATE'S boundaries.

データ変更を行う上で1単位として扱う必要があるような、相互に関連するオブジェクト群。外部からのAGGREGATEへの参照は、ルートとして識別されたものだけに制限される。一貫性を保つためのルールの集合は、AGGREGATE境界の内部に対して適用される。

このように説明されており、データの一貫性を保つ単位であることが強調されている。しかし、本を流し読みしただけでは、Repositoryと同レベルのビルディングブロックとして扱うほどの重要性は感じない。冒頭に述べたとおり、Aggregateの位置づけやその重要性は、従来のトランザクション設計と対比させることでわかりやすくなるのではないかと思う。

手続き型トランザクション

まず最初に、従来の手続き型アプリケーションでのトランザクション設計を考えてみたい。従来自分が行っていた典型的なトランザクション設計は、手続きの範囲を指定することでトランザクションスコープを設定し、その内部で主にデータモデルに対して楽観・悲観の同時実行制御を行う、というものだった。DDDの構成要素で言えば、アプリケーション層のService（のメソッド）をトランザクション境界として設計し、SQLやストアドプロシージャでロックをかけることが多い。

DDDのAggregateで紹介されている、注文（PurchaseOrder）、注文明細（PurchaseOrderLineItem）、商品（Product）の例を使った例を考えてみる。

[単純な注文のモデル]

（残念ながら自分が）よく見るコードはこんな感じだろうか。

[AddPurchaseOrderLineItemService]

public class AddPurchaseOrderLineItemService {
    @Transactional
    public void addNewItem(Command cmd) {
        ...
        // PurchaseOrderとPOLineItemを結合したオブジェクトのList
        List<PurchaseOrderResult> porList = poDao.findForUpdate(criteria);
        ...
        PurchaseOrderLineItem newItem = new PurchaseOrderLineItem(poList.get(0).getId(), ...);
        ...
        // 内部ではinsert
        if (porList.get(0).getLimit() >= (totalPrice(porList) + newItem.getPrice())) {
            poLineItemDao.insert(newItem);
        }
        ...
    }
}

上記のコードでは、一貫性維持に関する知識は…

一貫性維持の範囲

=> ApplicationService上の@Transactionalアノテーション

一貫性維持範囲内で守るべき不変式

=> if文の条件式

同時実行制御戦略

=> DAOのメソッドによるロック

これらの中に分散して存在し、モデル（データモデルorオブジェクトモデル）上ではまったく表現されていない。

さらに、ApplicationServiceはユーザーイベント単位に作成されることが多いため、同じモデル（ここではPurchaseOrder）の一貫性に関する情報であるにも関わらず、ユーザーイベントごとにも散逸してしまうことになる。

一貫性の知識を手続きからモデルへ

DDDでは、ドメイン知識はドメイン層のモデルとして表現するのが原則であり、重要な知識であればモデル上で明示的に表現することを強く推奨している。この方針に沿って上記の問題を解決しようとすれば、自然とモデル上への一貫性を表現する単位の導入に辿り着く。具体的には…

一貫性維持の範囲

=> 維持範囲のモデル表現としてAggregateを導入する

一貫性維持範囲内で守るべき不変式

=> Aggregateルートの変更操作内に移動
=> グローバルなルールや、ユビキタス言語に登場すべきルールであれば、Rule/Specificationの導入を検討

同時実行制御戦略

=> モデル側で表現
=> ドメイン知識ではないので、外部に追い出す

以下、具体的に見ていく。

一貫性維持の範囲を明示
最終的にはService上で手続きに対する一貫性制約を明示することにはなると思うが、まずはモデルに対して一貫性の維持範囲を設定し、必要に応じてそれらをServiceで調整する、という方針に転換する。今回の例で用いた言語（Java5 or later）ではAggregateを明示的に扱うことができないため、設計上の決めごとに加え、対応するRepositoryを作ることで間接的にAggregateを表現する。

今回の例での一貫性維持単位、つまりAggregateを構成する要素は、PurchaseOrderとPurchaseOrderLineItemとする。ルートは当然PurchaseOrderになる。

現状のDAOでは、Aggregateの子であるPurchaseOrderLineItemを直接取得・変更するようになっているので、AggregateルートであるPurchaseOrderを取得するように変更し、名称もPurchaseOrderRepositoryに変更する。

[AddPurchaseOrderLineItemService]

public class AddPurchaseOrderLineItemService {
    @Transactional
    public void addNewItem(Command cmd) {
        ...
        PurchaseOrder po = poRepository.findForUpdate(cmd.id);
        ...
        PurchaseOrderLineItem newItem = new PurchaseOrderLineItem(po.getId(), ...);
        ...
        if (po.getLimit() >= po.getTotal() + newItem.getPrice())) {
            po.add(newItem);
            poRepository.save();
        }
        ...
    }
}

また、最低限一貫性を持たせねばならない範囲はPurchaseOrderのAggregateであるため、トランザクションスコープはPurchaseOrderの状態変更メソッドであるaddItemに設定する。トランザクション設定値としては、このAggregateが必要とする値を設定する。
# 今回はデフォルト値のまま

[PurchaseOrder]

public class PurchaseOrder {
    List items = Lists.newArrayList();
 
    @Transactional
    public void addItem(PurchaseOrderLineItem item) {
        if (limitOver(item.getPrice())) {
            throw new ...
        }
        items.add(item);
    }

    private boolean limitOver(int price) {
        return (price + total) > limit;
    }
}

これで、呼び出し側がトランザクションを開始していなくても、PuchaseOrderが必要なトランザクションを設定できる。

不変式をモデル内に移動

if文内の条件式をAggregateルートの変更操作内に（不変式として）移動させる。これで、ドメイン層のモデル上で表現された。

[PurchaseOrder]

public class PurchaseOrder {
    List items = Lists.newArrayList();

    public void addItem(PurchaseOrderLineItem item) {
        if (limitOver(item.getPrice())) {
            throw new ...
        }
        items.add(item);
    }

    private boolean limitOver(int price) {
        return (price + total) > limit;
    }
}

移動後のサービスには、重要な知識は何も残っていない。

[AddPurchaseOrderLineItemService]

public class AddPurchaseOrderLineItemService {
    @Transactional
    public void addNewItem(Command cmd) {
        ...
        PurchaseOrder po = poRepository.findForUpdate(cmd.id);
        ...
        PurchaseOrderLineItem newItem = new PurchaseOrderLineItem(po.getId(), ...);
        ...
        poRepository.save();
        ...
        }
}

同時実行制御戦略の場所を移動

同時実行制御戦略を、取得操作側ではなくEntity側に設定する。また、具体的な制御戦略はドメイン知識ではないので、モデルから追い出すのが良い。

[PurchaseOrder]

@Entity
@org.hibernate.annotations.Entity(
    optimistcLock = OptimisticLockType.VERSION
)
public class PurchaseOrder {
    List items = Lists.newArrayList();
    
    public void addItem(PurchaseOrderLineItem item) {
        if (limitOver(item.getPrice())) {
            throw new ...
        }
    items.add(item);
    }

    private boolean limitOver(int price) {
        return (price + total) > limit;
    }
}

# TODO:とはいえ、ここの記述はイメージで、この設定でPurchaseOrderLineItemを追加した場合にPurchaseOrderのVERSIONが更新されるようにできるかは未確認…Hibernate詳しくない^^;

Repositoryのインタフェースからは、同時実行制御戦略を消す。

[AddPurchaseOrderLineItemService]

public class AddPurchaseOrderLineItemService {
    @Transactional
    public void addNewItem(Command cmd) {
    ...
    PurchaseOrder po = poRepository.find(cmd.id);
    ...
    }
}

維持範囲の変更／調整

DDD本書では、一貫性の維持範囲内にProductを含めるかどうかという議論が出ており、以下のような論点から組み入れるのは好ましくない、という結論になっている。

個々の注文を編集するためにProductまで同時実行制御の対象となってしまい、編集エラーが多発する

Productは、PurchaseOrder/PurchaseOrderLineItemに比べてHigh-Contention

Productのpriceが変更になった場合、過去のPurchaseOrderの金額に影響を与えたくない

これらはいずれもドメイン知識（もしくはそこから得られる洞察）であるため、ドメインモデルに反映したい。Aggregateを明示的に示し、PurchaseOrderAggregateからProductを除外しておくことで、こうした設計判断をモデル上で示すことができる。
いずれにせよ、ProductをPurchaseOrderAggregateの子にすると、Productの変更をPurchaseOrder経由で行うことになり、これは明らかにおかしいので、ソフトウェア設計の視点からも当然の判断だと思う。

手続き＋データのパラダイムでは

一貫性を保たねばならない範囲をモデル上に表現すべき、というのはオブジェクトモデルに限った話ではなく、データモデル上で明示するのも良いプラクティスだろう。DAOやストアドプロシージャなどデータモデルにアクセスする各処理は、こうしたモデルに関する情報に基づいて適宜一貫性を保つようにすることで、一貫性上の問題を起きづらくできる。

KPT2009

2009-12-12T00:50:00.007+09:00

というわけで、2008のKPTおよび2009年のTRY評価を踏まえた上での2009年の振り返り。

■ KEEP

* 英語

日常の情報ソースを含めた多聴・多読
定期的な実務翻訳

* 体系的な学習

コンピュータ科学の不足部分学習
「モデル」とその扱いの学習
数学とそこそこ仲良くする、関わり続ける
DDDの学習

* 交流

内外の勉強会への参加
社内勉強会の開催

* 現場の改善

現場での設計プラクティスの改善
現場の洗脳（自分がやりたいことをやるための土壌作り）
コードの適正化への働きかけ

* 趣味

楽器を定期的にさわって楽しむ

■ PROBLEM

数学の基礎知識が圧倒的に不足。数学系の勉強会に出続けるのはつらい。技術士の一次にも不足。
精読とリスニングの力があまりあがっていない。基礎からやらねば。
満足いくようなソフトウェアを作れていない。何か1つ作りたい。
相変わらず趣味と料理が…orz。好きなことを学ぶのが趣味みたいなもんだが…。
会いたい人に会いにいけてない。躊躇してもしょうがない。

■ TRY

* 英語

来年こそTOEICで900点！
精読の力を身につける。
リスニングの力をつけるために、シャドウイングをもっと実践する。

* 実務

自信を持って内外に紹介できるシステムを作る。
DDDのアイディアを使って、現場の開発を改善する。コードの可読性も向上させる。
ESBをうまく使ってみる。
機会があればDSLをうまく使ってみる。

* その他学習

より利用者側にフォーカスしたアーキテクチャの学習。The Timeless Way of Buildingのシステム版のようなもの。いかにシステムと人間が同居するのかを探求。
数学。まずは技術士試験用に基本的なところから。
OOの原典。どうも、原典を読まないと話が空転する場合があるようだ。
コンピュータ科学。どのあたりに行くかは未定…

* 社交／発信

社外での勉強会開催。一度くらいやってみたい。
何か役に立つソフトウェアを1つ作って公開。
会うべき人に会いにいく。

* 趣味

今年こそバンド。無理か？
年賀状を自作の絵で。無理か？

思いつく限りではこんなところ。あまり面白くない！てか地味なんだよ！

2009年TRYの評価

2009-12-12T00:01:00.008+09:00

明日のJavaEE勉強会のポジペネタでもあるので、この機会に整理。まずは、KPT2008のTRY（つまり2009年のTRY）の評価から。今年のTRYはこんなんでした。

■TRY

* 英語により慣れる

今年はTOEIC 900点を目指したい
オリジナルが英語の情報は全部英語で読む

* 交流をより増やす

OSSプロジェクトに参加する or 書籍出版に関わる
何という無理くささ

* 体系的な勉強

ドメイン工学系（GenarativeProgramming => Multiparadigm Design）
ビジネスモデリング系（Ericsson-Penker => Analysis Patterns => Data Moedl Patterns）
DSL系（Fowler DSL Books WIP => Meta Programming System）
ビジネス系（会計～中小企業診断士を趣味的に）

* 趣味

ベース楽しく弾く
できればアマ志向でバンド組んでスタジオで騒ぐ
かっくいいのかいてpixivとかに投稿してみたい
もっかい将棋はじめてもいいかなぁ

* 料理

とりあえずペペロンチーノで乳化あたりから

英語に慣れる

TOEICは900点には届かず。相変わらず、リスニングでの取りこぼしと、文法まわりのミスが目立つ。反面、リーディング部分はほぼ満点で、高速でざっくり流し読みする、というのは非常に得意になった。ここ数年、インプットとしての英語情報の量に圧倒されていたため、多少の精度は犠牲にしてとにかく高速で流し読みするスキルを鍛えてきた。このスキルをどうやら取得できたのは歓迎すべきことだ。長文の英語を読む前の、あの「ヤだなー」という感じや、読んでいるとすぐに疲れてくる感じはほとんどなくなり、日本語を読むのと近い感覚で読み進められるようになってきた。

しかしながら、文法を含めた精読のスキルはあまり向上しておらず、特に実務翻訳を行う場合に苦労した。わかりづらい英文に対して、論理的に英語の意味を確定していく、という作業の精度が、流し読みのレベルに比べると低いのだ。

今後はリスニングとあわせて、精読のスキルを重点的に鍛えていきたい。

交流をより増やす

交流…増えたのかなぁ。層・圏・トポスや檜山さんのセミナーである程度増えたんだけど、最近予定が合わずにあまり行けてないからなぁ…。

交流する人数が劇的に増えているわけではないと思う。そもそもそういうタイプの人間でもないし。今交流がある人とのつきあいを大事にしつつ、機会をみつけてちょこちょこ手を伸ばしていく感じにしたい。

書籍の出版に関しては、層・圏・トポスのご縁からお手伝いさせてもらえることに。色々ご迷惑をおかけします。お世話になってます。

体系的な勉強

今年やった勉強は、こんなところ。

圏（基礎およびモナドまわり）
ラムダ計算（初等テキスト）
コンパイラ基礎（ふつパイラで）
DDD（書籍勉強会開催＋現場でいくつか実践）
DSL（JavaEE勉強会でFowlerのDSL本輪講中）
微積分（技術士向けに勉強はじめた程度）

ドメイン工学系やビジネスモデリング系はあまり進んでいない。去年力を入れていた、「システム全体」や「人間系＋コンピュータ系の複合システム全体」をうまく捉えるための、より広範・抽象的で多分に曖昧さを含む方向にはあまり手を伸ばさず、詳細・厳密な方向へ行っている印象。コンピュータ科学の専門教育受けてないので、専門知識や土台の不足を実感したのが主な要因か。来年はもう1度そっち方面に向かうかもしれない。

ビジネス系にまったく手を出せていないのは、自分には基礎的な技術の勉強とビジネス系の勉強を同時に進めるほどの器用さがないと悟ったから。仕事での必要性を考えると、基礎技術を固めるのが重要だと考えて、ビジネス系は優先順位を下げている。来年もそうなりそう。

趣味

ベースはちょこちょこさわっているけど、継続してやっている感じではないなぁ。面白い曲を見つけたら耳コピして演奏、楽しんで満足している程度。バンドを組むにはほど遠い。環境だけは整えたんだけど。

絵については、好きな漫画をパクってイラスト描いてみたり、会議中に色々描いて（^^;）描くことに慣れるようにしているんだけど、あまりうまくなった感なし。描き散らしているだけで、きちんとした作品にするまで頑張れていないんだよなぁ。基本的なスキルも身に付いてない印象。絶対的に量が足りてない。とりあえず形から入る意味で、ペンタブでも買ってみようかと画策中。来年の年賀状（メール）は、手書きの絵を送りたいものだ。

料理

orz…iPhoneにクックパッド入れたよ！

全体的に見ると、趣味系がいまいち、あとはそこそこ頑張っているが満点では決してない、という感じか。トータル65点くらいかな。KPT2009に続きます。

ユビキタス言語と日本語

2009-10-02T16:26:00.008+09:00

数ヶ月前から社内でDDD勉強会を実施していて、最近「ユビキタス言語(Ubiquitous Language)」まで来たんだけど、ここでやっぱり「日本語を使ったら1つの言語、モデルになるのか？」という疑問が出てきた。JavaEE勉強会でも同様の意見が（確かhirataraさんから）出てきていたものの、残りの部分に答えが書いてある可能性もあったので、その時点では「まぁ、用語の一覧みたいなのを作ってなんとかすればいいんじゃないの？」と流したものの、あらためて同じ問題に直面してみると、なかなかやっかいな問題だ。先に進む前に、この時点での自分なりの結論を書いておく。

DDDの世界観

まずは、DDDにおけるユビキタス言語やモデルの扱いについて簡単にまとめておく。

# 断るまでもないと思うけど、もちろん個人的な理解。

ユビキタス言語はドメインモデルに基づく言語であり、ドメイン専門家と開発者の双方が作り、双方が使う。これら2つは一体となっており、片方が変更されればもう一方も変更される。

ユビキタス言語が構成する世界−−言い換えれば、言語によって制限された物の見方−−がモデルであり、モデルは第一義的には概念上の存在である。わかりやすく言い換えると、モデルのマスターは頭の中に存在している、ってこと。これを文章やダイヤグラム、コードで表現することもできるけど、そうして表現されたものはすべてモデルの死体のようなもので、作った瞬間から古くなっていく。

モデルが頭の中にしかないのであればユビキタス言語も同様で、会話の中にあらわれるものこそが第一義的な「ユビキタス言語」になる。

僕たちはソフトウェアを開発したいので、モデルが頭の中にしかないってのはあまりうれしくない。最低でも（モデル表現としての）コードは必要になってくるけど、DDDではモデルを複数作らないのが原則だ。となると、コードの構造は頭の中のモデルを投影したものになり、コードはユビキタス言語で表現されることになる。

DDDの世界観は、こんな感じ。

で、問題は何よ

日本で開発する場合、顧客と開発者の会話はふつう日本語で行われる。よって、ユビキタス言語は日本語として構築されることになる。

一方、プログラミング言語は通常英語（というよりは英数字）がベースだ。日本語プログラミング言語も存在しているが、少なくとも業務システムではほとんど使われていない。最近の言語はたいていUnicodeをサポートしているので、識別子として日本語を使えばいいじゃん、と思うかもしれないが、言語が持つ標準的なコーディングスタイルから著しく逸脱するので、信じられないほど可読性が低下する。

# 一度Javaでやってみたことがあるが、正直2度と読みたくない。

どうするべき？

ここで取るべき道は2つ。

コードは英語、その他は日本語
コードはローマ字による日本語表現、その他も日本語

ここで、僕のような西洋かぶれは1番目の方法を選びたがるわけだけど、これはおそらく大きな誤りだ。

英語と日本語は、単に文法や単語が違うだけではなく、世界の見方自体が異なっているので、どうやってもうまく対応させられない部分が出てくる。それがわかっていればまだ良い方で、うまく対応させたと思っているものの、実際は完全に間違えていることだって少なくない。そうした無理な変換によって、実質的にはモデルが2つできてしまいかねない。

そもそも母国語だけ使っていても、単一のモデルを（言語、文章、コードにわたって）維持するのは非常に困難なので、基本的な道具立てに撹乱要因が入るのはできればご遠慮願いたい。

2番目は、おそらく現場で一般的に取られている方法だろう。コードを見ると頭が痛くなるような識別子が並ぶことになるのだが、無理に英語を使って混乱するよりはまだマシだろう。

言語学との関連

実際のところ、一番興味深いと感じたのは、Evansのユビキタス言語に関する考え方が、最近読んだ言語学の本での言語に対する態度とかなり近いという点。言語として会話を重視する、といった態度のことね。考えてみれば当たり前なんだけど、言語の中には文字がないものだって存在するし、何より頻繁に変わっていく（設計のためのユビキタス言語のような）言語に追随するには、話されている生きた言語を捕える必要がある。

にもかかわらず、自分も含めて、言語を「紙に書かれた文字や文章」や「文法書」、「辞書」である、と考える人が異常に多いということに気づいて愕然としてしまった。

2009/10/8追記：

勉強会でさらに話し、名詞の厳格な扱いのおかげで概念をより厳密な言語（プログラム言語）に落とし込みやすい英語と比べ、日本語では概念を明確にしづらい…といった話が。結局、ユビキタス言語は混成言語（ピジン語）のようなものにせざるを得ないのかもしれない。ただし、文法の混成はかなり限定的になりそうだけど。

コンテキストあれこれ

2009-10-01T13:48:00.008+09:00

知り合いのu1hoshinoががんばってAP設計のノウハウをまとめはじめたようです。手始めはコンテキストですが、前半の概念を導入している部分でいろいろ消化不良感があったのでコメントに書こうと思ったのですが、長くなりそうだったのでこっちに書きます。脳内ダンプ的なものなので、特に結論はないです。

コンテキストって何

計算機の話に限定すれば、「コンテキスト」は「特定の計算における環境」だと言えます。ここで言う「環境」としては、広義には言語やランタイムを表すこともありますが、今回は（元記事の想定に基づいて）「変数と値のセット」に限定します。

特定の計算を構成する命令（ステートメント）を、何かしらの形（関数、プロシージャ、クラス…）でモジュール化することを考えた場合、計算に必要な入力値すべてを引数や戻り値で渡せば、環境は不要になります。実際、純粋関数型言語ではこのようにして計算を組み立てます。しかし、モジュール（の複数の命令）をまたがって同じ情報を繰り返し参照するなら、その情報はパラメータで渡すのではなく、環境として設定してどこからでも参照できるようにすることで、モジュール間の結びつきが煩雑化するのをある程度抑えられます。これが、コンテキストを利用する比較的大きな理由だと思います。

# 他方で、抽象化された「環境」を引数や戻り値として受け渡していくことで、副作用を排除しつつモジュールの煩雑化を防ぐ、モナドのようなアプローチもあります。

何故Webでコンテキストを作るのか？

Javaで標準的なWebインフラ（Servlet）には、組み込みでリクエスト・セッション・アプリケーションなどのコンテキストオブジェクトが存在しており、自由に利用できます。

これらのコンテキストにはServlet内から自由にアクセスできるため、まさに「特定のリクエスト実行における環境」になっており、Servlet内部に命令を書いている限り、これらがまさにコンテキストとして機能したはずです。

しかし現状では、レイヤパターンの適用によってリクエスト処理を複数モジュールに分割し、Webレイヤ以外では上記のコンテキストは使えないように設計するのが一般的になりました。これによって、ビジネスロジックと呼ばれる命令群が特定インフラへ依存することは少なくなったものの、コンテキストの喪失によって最初に設定した問題が発生することになりました。これを解決するために、Web非依存の独自コンテキストを再設計している、というのが元記事で言うところの「コンテキスト」が誕生した経緯です。

コンテキスト情報として何を設定する？

これは、計算の性質や、どのようにモジュール分割するかによって変わりそうです。また、リクエスト処理のコンテキスト設定がアプリケーションプログラム側で許可されていないケースも多く、基盤や（APじゃない）アーキテクチャが把握できる範囲となると、相当広範囲で共通的に使われるものに限られるケースが多くなります。結果的に、元記事でも書いてあるような

ユーザー情報
日付

などが多くなるわけですね。

また、コンテキスト情報として設定するものの中で、レイヤ指針に反するような内容を設定した場合、不適切な依存関係が発生する可能性があるので注意する必要があります。ビジネスロジックをインフラから切り離すためのレイヤ化だったのに、コンテキストに端末IDやIPアドレスが設定されていると、ロジックがこれらに依存する可能性があります。単なるデータとして扱っているうちは良いですが、不用意にインフラに特化した「型」に依存してしまうと、物理モジュールの管理が面倒になるので、注意が必要です。

結局

結局、「コンテキスト」が何で、どうして必要なのかを自分の中でもう少し整理しておきたかったというわけでした。書いてみると当たり前というか、しょーもない話ですね。

第4回「層・圏・トポス」読書会にいってきた

2009-06-29T13:34:00.005+09:00

めでたく読書会が開催されるようになってから、めっきり自分で勉強しなくなってしまったんだけど、もともと数学的な知識や素養があるわけでもないので毎回結構辛い ^^; その辛い感じが結構楽しいんだけども。

というわけで、今回から（iPhone3GSを買ったこともあり！）黒板を写真に撮ってきて、Descriptionつけながら復習することにした。Picasaにあげようかと思ったけど、iPhotoがFlickrに対応していてアップロードが楽だったので、Flickrにあげた。

Flickr : 第4回層・圏・トポス読書会

まだ半分くらいしかDescription書いていないけど、思い出しながら地道に埋めていく予定。ちなみに、読書会はGoogle Groupsも出来ました。

Google Groups : 『層・圏・トポス』読者の会

謎の合宿（水着のおねえちゃん目当て？）も企画されているようなので、興味があれば是非。

Poken[Rockstar]が来た。

2009-05-15T21:13:00.008+09:00

Poken 到着〜ユーザー登録
QCon Tokyo 2009 のアンケートで当たったPokenが来た。こんなの。この子はどうも、Rockstarっていうらしい。まぁまぁかわいい…よね？

思ったよりずいぶん小さい。大きめの消しゴムくらいの大きさ。箱から出すと…

こんな。コレ以外何も入っていない。

キャップ（Rockster氏）を取ると、USB端子が。これをUSBポートに差し込むと、autorun が有効になっている（危険な）PCでは、Poken の登録サイトが表示される。
autorun が無効になっている場合は、マスストレージになっているので、中に入って"Start_Poken.html"をブラウザで表示すればOK。
# ちなみに、Chrome では正常に表示できない模様（友人談）。

あとは、表示された Poken サイトで Poken 専用アカウントを作成し、個人情報をポチポチ入れていけば完了。

Pokenの仕組み
"Start_Poken.html"の中を見てみると…

<META http-equiv="Refresh" content="1;    URL=http://p.poken.ch/u/なんかデバイス固有のトークンっぽいもの-+の大量繰り返し">

てな感じになっている。http-equiv="Refresh" で自動的にサイトに接続される仕掛けのようだ。肝心の URL は、デバイストークンと-+の繰り返し。-+ の繰り返し部分にはおそらく、交換した名刺の情報が入るのだろう。Poken で情報を交換するたびに、Poken デバイスがこの URL を書き換えているのだと思われる。
# このファイルは当然、ユーザーからは書き換え不能。

Poken on Mac
初回接続（新規ユーザー登録）時には Poken サイト上に表示されているPoken デバイス接続状態を示すアイコンが正常に表示されておらず、もしかして Win + IE でしか使えないデバイス認識プラグインとか使ってるのか！？と思ったが、2回目は正常に認識された。どうやら、デバイストークンが送付されていれば接続状態だと認識しているようだ。デバイスが接続されていても、トップページから普通に（"Start_Poken.html"を使わず）ログインすると、デバイスは認識されていなかった。
というわけで、ネイティブ環境にアクセスできるプラグインを使っているわけでもなさそうだ。Mac ユーザーも安心。

セキュリティ
Poken/セキュリティ上のご注意 - オートログインはoff、でね。

仕組みのところで見たけど、接続先の scheme は https ではなくhttp になっている。上記のサイトではこれが問題視されてるんだけど、なんでだろう？情報は全部 URL で送っているんだから（それはそれで問題なわけだが）、SSL だろうがなんだろうが関係ない気がするけど。Poken サイト自体は SSL に対応しているし。昔は対応してなかったのかなぁ。セキュリティはあんま詳しくないからわからないんだけども。

デバイストークンや交換した名刺の情報がURL経由で漏洩する可能性については、どうにもならないから割り切ってあきらめるしかなさそうだ。信頼できないネットワーク環境（Proxy含む）では使わないように心がけよう。

さーて、誰か交換できる人見つかるかな。

DDD Sample Application version1.1.0: ユースケーススライスから見たアプリケーション構造の確認（2）

2009-05-06T15:57:00.006+09:00

前回は、シンプルな参照の機能が、サンプル上でどのように構成されているかを確認した。今回は、積荷の一覧・詳細表示で参照機能の構成を確認しつつ、積荷の新規登録・状態更新まで確認してみたい。

~~配送状況の詳細表示~~
積荷の一覧・詳細表示
積荷の新規登録
積荷の状態更新
配送ルート候補検索
積荷への配送ルート設定
配送状況の更新
配送状況の更新（バッチ）

積荷一覧・詳細表示の概要
これは、商品発送側が現在管理対象になっている積荷の情報を確認するためのもの。おなじみの一覧・詳細表示アプリだ。アプリケーション内では、Booking と呼ばれている。Booking （Trackingもそうだが）はコンテキストなのだろうか？
この機能は、一見すると配送状況の詳細表示と同じように思えるが、内部的には異なった作りになっており、Web層の Controller からリモートサービスとして構成された BookingServiceFacade を呼び出す形になっている。

BookingServiceFacadeの先も、前回のように単純にRepositoryを呼ぶだけではなく Application層（BookingService）を経由しているため、多少複雑な構成になっている。

積荷の一覧・詳細表示
よくあるエンティティの一覧・詳細表示。検索の種類が違うだけで、アプリケーションの構成はどちらもほとんど同じ。なので、ここでは一覧検索だけを見ていくこととする。

INTERFACES
エントリポイントは、上記の図でわかるとおり interafaces パッケージの CargoAdminController。

[CargoAdminController]

public final class CargoAdminController extends MultiActionController {

このクラスは Spring WebMVC のMultiActionController を継承しているが、これは複数のリクエストを1つのController で処理するためのクラス。デフォルトでは、リクエストURIのスラッシュで区切られた末尾部分と同じ名前のメソッドを呼び出す。その他は SimpleFormController と大差ない。

一覧表示は index.jsp から「/admin/list」で呼び出されているが、「/admin」は web.xml で BookingDispatcherServlet に割り当てられており、booking-servlet.xml 経由で上述のCargoAdminControllerに割り振られ、最終的に list メソッドが呼び出されている。

[CargoAdminController#list]

  public Map list(HttpServletRequest request, HttpServletResponse response) throws Exception {
    Map map = new HashMap();
    List cargoList = bookingServiceFacade.listAllCargos();

    map.put("cargoList", cargoList);
    return map;
  }

BookingServiceFacade#listAllCargos() を呼び直しているだけだ。

[BookingServiceFacadeImpl#listAllCargos]

  public List listAllCargos() {
    final List cargoList = cargoRepository.findAll();
    final List dtoList = new ArrayList(cargoList.size());
    final CargoRoutingDTOAssembler assembler = new CargoRoutingDTOAssembler();
    for (Cargo cargo : cargoList) {
      dtoList.add(assembler.toDTO(cargo));
    }
    return dtoList;
  }

Repository で Cargo の一覧を取得している。ただし BookingFacadeService はリモートサービスなので、呼び出し元に結果を返却するために DTO を作っている。DTO には Cargo の情報だけでなく、関連する配送ルートの情報まで展開した上で返却している。

[CargoRoutingDTOAssembler#toDTO]

  public CargoRoutingDTO toDTO(final Cargo cargo) {
    final CargoRoutingDTO dto = new CargoRoutingDTO(
      cargo.trackingId().idString(),
      cargo.origin().unLocode().idString(),
      cargo.routeSpecification().destination().unLocode().idString(),
      cargo.routeSpecification().arrivalDeadline(),
      cargo.delivery().routingStatus().sameValueAs(RoutingStatus.MISROUTED));
    for (Leg leg : cargo.itinerary().legs()) {
      dto.addLeg(
        leg.voyage().voyageNumber().idString(),
        leg.loadLocation().unLocode().idString(),
        leg.unloadLocation().unLocode().idString(),
        leg.loadTime(),
        leg.unloadTime());
    }
    return dto;
  }

ちなみに、CargoAdminController から BookingServiceFacade へのリモート呼び出しは RmiProxyFactoryBean でうまく隠蔽されている。

[booking-servlet.xml]

  <bean id="remoteBookingService" class="org.springframework.remoting.rmi.RmiProxyFactoryBean">
    <property name="serviceUrl" value="rmi://localhost:1099/BookingService"/>
    <property name="serviceInterface" value="se.citerus.dddsample.interfaces.booking.facade.BookingServiceFacade"/>
  </bean>

  <bean name="/*" class="se.citerus.dddsample.interfaces.booking.web.CargoAdminController">
    <property name="bookingServiceFacade" ref="remoteBookingService"/>
  </bean>

ここまでがINTERFACES。というか、ここまででほとんど終わりだ。

APPLICATION
今回はアプリケーションサービスとして BookingService が存在するが、このシナリオでは使われていない。

INFRASTRUCTURE
Tracking との目立った違いはない。

積荷の新規登録
エンティティの新規登録。新規登録画面の初期化・表示と、入力された積荷情報の登録の2ステップにわかれている。
新規登録画面の初期化時は、出発地・到着地を選択するためのドロップダウンメニューに設定する情報を取得しているのみであるため、ここでは積荷情報の登録を見ていく。

INTERFACES
エントリポイントは、CargoAdminController の register メソッド。

[CargoAdminController#register]

  public void register(HttpServletRequest request, HttpServletResponse response,
                       RegistrationCommand command) throws Exception {
    Date arrivalDeadline = new SimpleDateFormat("M/dd/yyyy").parse(command.getArrivalDeadline());
    String trackingId = bookingServiceFacade.bookNewCargo(
      command.getOriginUnlocode(), command.getDestinationUnlocode(), arrivalDeadline
    );
    response.sendRedirect("show.html?trackingId=" + trackingId);
  }

BookingServiceFacade に丸投げ。

[BookingServiceFacadeImpl#bookNewCargo]

  public String bookNewCargo(String origin, String destination, Date arrivalDeadline) {
    TrackingId trackingId = bookingService.bookNewCargo(
      new UnLocode(origin),
      new UnLocode(destination),
      arrivalDeadline
    );
    return trackingId.idString();
  }

さらにアプリケーションレイヤに丸投げ。

APPLICATION
ついにアプリケーションサービスが登場。

[BookingServiceImpl#bookNewCargo]

  @Override
  @Transactional
  public TrackingId bookNewCargo(final UnLocode originUnLocode,
                                 final UnLocode destinationUnLocode,
                                 final Date arrivalDeadline) {
    // TODO modeling this as a cargo factory might be suitable
    final TrackingId trackingId = cargoRepository.nextTrackingId();
    final Location origin = locationRepository.find(originUnLocode);
    final Location destination = locationRepository.find(destinationUnLocode);
    final RouteSpecification routeSpecification = new RouteSpecification(origin, destination, arrivalDeadline);

    final Cargo cargo = new Cargo(trackingId, routeSpecification);

    cargoRepository.store(cargo);
    logger.info("Booked new cargo with tracking id " + cargo.trackingId().idString());

    return cargo.trackingId();
  }

処理の流れとしては、Command から取得したコードをもとに ENTITIES や VALUE OBJECTS を復元して新規 Cargo に設定し、最後に Repository で保存している。ごくごく基本的な流れではあるが、設定項目が多すぎて少しぎこちなくなっているため、将来的には CargoFactory を作ってそこに移すのが良いと考えているようだ。
この時点で既にトラッキングIDが発行されていることから、ビジネス的には配送ルートが設定されていなくても、正当な積荷らしい。また、Cargo が状態を持っている様子もない。
@Transaction でこのメソッドをトランザクション境界に設定している点にも注意。

INFRASTRUCTURE
一件検索系はもういいので無視して、トラッキングIDの新規発行を担っている CargoRepository#nextTrackingId を確認したい。

[CargoRepositoryHibernate#nextTrackingId]

  public TrackingId nextTrackingId() {
    // TODO use an actual DB sequence here, UUID is for in-mem
    final String random = UUID.randomUUID().toString().toUpperCase();
    return new TrackingId(
      random.substring(0, random.indexOf("-"))
    );
  }

あぁ…TODO とかついちゃってるよ…。現段階では UUID が使われているが、本来はDBシーケンスを使う、とのこと。もうバージョン1.1.0なんですけど :-D

積荷情報（到着地点）の更新
基本的な流れは積荷の新規登録と同じなので省略する。

まとめ
リモートファサードを使う場合の実装方針がわかった、ってところだろうか。あえてドメインの構造には立ち入っていないが、このユースケースではドメイン層に入る余地もなさそう。おそらく、配送ルートの検索あたりでないとロジックらしいロジックは出てこないだろうな。

目次：
DDD Sample Application version1.1.0を確認する

DDD Sample Application version1.1.0: ユースケーススライスから見たアプリケーション構造の確認（1）

2009-05-06T12:06:00.010+09:00

前回まででユースケース、アプリの全体構造までを確認したところで、今回はユースケースごと（ユーザーイベントごと）のアプリケーション構造を追っていく。ユーザーイベントを再掲する。

配送状況の詳細表示
積荷の一覧・詳細表示
積荷の新規登録
積荷の状態更新
配送ルート候補検索
積荷への配送ルート設定
配送状況の更新
配送状況の更新（バッチ）

まとめてやろうかと思っていたが、思った以上に長くなったので1イベント per 1エントリで進めることにした。今回は一番上、配送状況の詳細表示。

配送状況詳細表示の概要
主に、顧客が発注商品の配送状況を確認するために使う機能。アプリケーション内では、Tracking という言葉で呼ばれている。
Web インタフェースから情報を参照するだけの機能なので、Spring WebMVCのコントローラから Repository 経由でデータを取得して表示するだけのシンプルな作りになっている。アプリケーション層のクラスは存在しない。

INTERFACES
se.citerus.dddsample.interfaces.tracking の CargoTrackingController がエントリポイントになっている。このクラスは、Spring WebMVC のSimpleFormController を拡張している。

補足：Spring WebMVC の仕組み
中身に行く前に、これから何度も出てくるであろう Spring WebMVC の仕組みを確認しておく。SimpleFormController は Form のサブミットをハンドリングするために用意されたクラスだ。onSubmit メソッドを決められたメソッドシグネチャで作成しておくと、Form が送信された際に自動的に呼び出される。メソッド引数は、HttpServletRequest, HttpServletResponse[, AnyObject as Command] [, AnyExceptionClass] のようになっているらしい。
リクエストが送信された際には、CommandClass プロパティに設定されたクラスがインスタンス化され、リクエストパラメータが設定されて onSubmit の引数として渡されてくることになる。

[CargoTrackingController.java]

public final class CargoTrackingController extends SimpleFormController {

  private CargoRepository cargoRepository;
  private HandlingEventRepository handlingEventRepository;

  public CargoTrackingController() {
    setCommandClass(TrackCommand.class);
  }

  @Override
  protected ModelAndView onSubmit(final HttpServletRequest request, final HttpServletResponse response,
                                  final Object command, final BindException errors) throws Exception {

    final TrackCommand trackCommand = (TrackCommand) command;
    final String trackingIdString = trackCommand.getTrackingId();

    final TrackingId trackingId = new TrackingId(trackingIdString);
    final Cargo cargo = cargoRepository.find(trackingId);

    final Map model = new HashMap();
    if (cargo != null) {
      final MessageSource messageSource = getApplicationContext();
      final Locale locale = RequestContextUtils.getLocale(request);
      final List handlingEvents = handlingEventRepository.lookupHandlingHistoryOfCargo(trackingId).distinctEventsByCompletionTime();
      model.put("cargo", new CargoTrackingViewAdapter(cargo, messageSource, locale, handlingEvents));
    } else {
      errors.rejectValue("trackingId", "cargo.unknown_id", new Object[]{trackCommand.getTrackingId()}, "Unknown tracking id");
    }
    return showForm(request, response, errors, model);
  }

  public void setCargoRepository(CargoRepository cargoRepository) {
    this.cargoRepository = cargoRepository;
  }

  public void setHandlingEventRepository(HandlingEventRepository handlingEventRepository) {
    this.handlingEventRepository = handlingEventRepository;
  }

}

設定可能なプロパティには以下のようなものがある。

sessionForm
- Commandオブジェクトをセッションに保存するかどうか
commandName
- CommandオブジェクトをRequest/Sessionにバインドする際の名前
formView
- 初回アクセスまたはバリデーションエラー時に表示するビュー名
successView
- onSubmitが成功した場合に表示するビュー名
validator
- Commandのバリデータ

これらは、Bean定義ファイルを用いて以下のように設定されている。

[tracking-servlet.xml]

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">

  <bean class="org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping">
    <property name="interceptors">
      <list>
        <ref bean="openSessionInViewInterceptor"/>
      </list>
    </property>
  </bean>

  <bean name="/track" class="se.citerus.dddsample.interfaces.tracking.CargoTrackingController">
    <property name="sessionForm" value="true"/>
    <property name="commandName" value="trackCommand"/>
    <property name="formView" value="track"/>
    <property name="successView" value="start"/>
    <property name="validator" ref="trackCommandValidator"/>
    <property name="cargoRepository" ref="cargoRepository"/>
    <property name="handlingEventRepository" ref="handlingEventRepository"/>
  </bean>

  <bean id="trackCommandValidator" class="se.citerus.dddsample.interfaces.tracking.TrackCommandValidator"/>

</beans>

onSubmitの処理内容
onSubmit では、コマンドオブジェクトから取り出したトラッキングID を使って CargoRepository から Cargo オブジェクトを、HandlingEventRepository から HandlingEvent のリストを取得してビューに返しているだけだ。ただし、ビューにはドメインオブジェクトをそのまま返すのではなく、アダプタを作って返している。この点は後述する。
TrackingCommand は trackingId しか持っておらず、TrackingCommand のバリデーターは、trackingId が空でないことを確認しているだけだ。

プレゼンテーションモデルの選択
DDD では、プレゼンテーション層のモデルとしてどのようなものを採用するかがよく議論になっている。一般的なものとしては、以下のような候補がある。

DomainObject をそのまま返す
DomainObject のアダプタを作り、View にはアダプタインタフェースを返す
専用のプレゼンテーションモデルを作り、DomainObject のデータをコピーした上で返す

今回は2番目の、アダプタを作ってビューに返す方法を取っている。

OpenSessionInView の採用
Hibernate の Lazy 用として、openSessionInViewInterceptor がインターセプタとして設定されているのが面白い。Seasar コミュニティでは Dxo の導入が一般的になっていた気がするけど、こちらは OpenSessionInView パターンを使っているのか。OpenSessionInView は嫌われているようだけど、自分は別に嫌いではない。常に Dxo 層導入するの面倒くさいし。

APPLICATION
存在しない。

INFRASTRUCTURE
ここで出てくるのは、（上記で説明したSrpring WebMVCを除けば）Repository のHibernate 実装の部分だ。中を見てみると実際はあまり大したことをしておらず、ほとんどの処理を Hibernate に丸投げしている。ORM 万歳。

[CargoRepositoryHibernate.java]

@Repository
public class CargoRepositoryHibernate extends HibernateRepository implements CargoRepository {

  public Cargo find(TrackingId tid) {
    return (Cargo) getSession().
      createQuery("from Cargo where trackingId = :tid").
      setParameter("tid", tid).
      uniqueResult();
  }

  public void store(Cargo cargo) {
    getSession().saveOrUpdate(cargo);
    // Delete-orphan does not seem to work correctly when the parent is a component
    getSession().createSQLQuery("delete from Leg where cargo_id = null").executeUpdate();
  }

  public TrackingId nextTrackingId() {
    // TODO use an actual DB sequence here, UUID is for in-mem
    final String random = UUID.randomUUID().toString().toUpperCase();
    return new TrackingId(
      random.substring(0, random.indexOf("-"))
    );
  }

  public List findAll() {
    return getSession().createQuery("from Cargo").list();
  }

}

今回は、find メソッドしか使っていない。これは、単に JPQL を使って一件検索しているだけだ。すべての XxxxRepositoryHibernate は HibernateRepository を継承しているが、HibernateRepository はサブクラスからの getSession 呼び出しに応じて Session を提供しているだけだ。

[HibernateRepository.java]

public abstract class HibernateRepository {

  private SessionFactory sessionFactory;

  @Required
  public void setSessionFactory(final SessionFactory sessionFactory) {
    this.sessionFactory = sessionFactory;
  }

  protected Session getSession() {
    return sessionFactory.getCurrentSession();
  }

}

HandlingEventRepository はさらにシンプルで、メソッドは1つしかない。こちらも、JPQL で一覧検索しているだけ。

[HandlingEventRepository.java]

@Repository
public class HandlingEventRepositoryHibernate extends HibernateRepository implements HandlingEventRepository {

  @Override
  public void store(final HandlingEvent event) {
    getSession().save(event);
  }

  @Override
  public HandlingHistory lookupHandlingHistoryOfCargo(final TrackingId trackingId) {
    return new HandlingHistory(getSession().createQuery(
            "from HandlingEvent where cargo.trackingId = :tid").
            setParameter("tid", trackingId).
            list()
    );
  }

}

まとめ
シンプルな検索は、（アプリケーションレイヤをスキップして）Web-FWから直接 Repository を呼び出すことで実現している。プレゼンテーションモデルとしては、Adapter アプローチを取っている。

もともとシンプルなユースケースであることも手伝って、なんだか依存テクノロジの説明がほとんどになってしまった。次回からはこういった説明は少なくなるはずなので、もっとさくさく進むはず！

目次：
DDD Sample Application version1.1.0を確認する

DDD Sample Application version1.1.0: アプリケーション全体構造の確認

2009-05-06T03:33:00.009+09:00

続いては、アプリケーション全体構造の確認。ここからようやく、ソースコードレベルでの確認に入っていく。単にソースを見るだけならダウンロードページからダウンロードすればいいが、効率よく読んでいくためには Eclipse 等 IDE のサポートが必要だろう。Maven を使っているので多少面倒くさいが、ダウンロードページには IDE で使うための情報も書かれているので、（特に Eclipse ユーザーは）参考にすると良い。

インフラストラクチャが依存するテクノロジ
実際のアプリケーションに入る前に、まずはインフラが依存する基本的なテクノロジ（ライブラリやフレームワーク）を確認しておく。採用するテクノロジは列挙にとどめる。

IoC (DI)コンテナ
- Spring 2.5.6
Webフレームワーク
- Spring WebMVC 2.5.6
ORM
- Hibernate 3.3.1
ロギング
- log4j 1.2.14

パッケージの概要
アプリケーションは、大きく以下の3つのパッケージに分割されている。

com.pathfinder
com.aggregator
se.citerus.dddsample

com.pathfinder は配送ルート候補を計算するために使われているのだが、これは一般的なグラフ構造を扱うパッケージになっており、Distillation の観点から見ると COHESIVE MECHANISMS（一般的な問題を解決するためのメカニズムを表す部分）になっている。もしかすると、GENERIC SUBDOMAINS（ドメインの観点から見て重要性が低い部分）とみなしても良いのかもしれない。

aggregator は配送状況を一括更新するための Java-XML マッピングと Webサービスを扱っているパッケージだが、この部分を interfaces に含めず独立したパッケージとして扱っている理由がよくわからない。Webインタフェース用の Servlet や Spring WebMVC の Controller が interfaces パッケージに含まれることを考えると、Webサービス用だけが独立しているのは理解しづらい。

se.citerus.dddsample は、CORE DOMAIN（ドメインの観点から重要度の最も高い部分）、またはCORE DOMAINを含むパッケージとなっているはずで、主要な機能はすべてここにおさめられている。

レイヤの確認
se.citerus.dddsample パッケージはさらに、以下の4つのパッケージで構成されている。

interfaces
infrastructure
application
domain

このうち、interfaces を除く3つは、the book で基本的なレイヤとして紹介されているもので、それがそのままパッケージ構造に反映されている。これらレイヤの概要は、Architectureと題されたページに書かれている。
# なお、テストパッケージにはこれらに加えて「scenario」が存在し、シナリオテストが収められている。

INTERFACES
今回から新たに導入されたレイヤ。Webブラウザ等のヒューマンインタフェースを含む、外部システムとのインタフェースすべてが配置される。入力データの解釈、検証、変換や、出力データのシリアライズはこのレイヤが担う。DTO も含まれる。
# だったらなおさら、なんで aggregator が独立パッケージなのかわからないが

このパッケージは、さらに以下の3つのパッケージで構成されている。

tracking
booking
handling

これは、ビデオで紹介されている主要なインタフェースに対応…つまり、 tracking が Customer による配送状況の確認に、booking が配送手配者による積荷の管理に、handling が配送業者による配送状況の更新に対応している。

これらのパッケージは、それぞれがさらにテクノロジ依存のサブパッケージ（web, file, wsなど）を持っているが、この部分の詳細は次回以降で確認する。

APPLICATION
積荷の新規登録（Booking）と配送状況更新（Handling）に関するアプリケーションサービスとその実装、それに ApplicationEvent というイベント通知用のインタフェースから構成されている。アプリケーションサービスに配送状況確認（Tracking）がないのは、おそらくシンプルすぎてサービスが必要ないからだと思われる。Tracking は参照のみなので、Repository のメソッドを呼ぶだけですんでしまう。次回参照するが、この処理は interfaces パッケージ内の Controller に直接記述されている。
ApplicationEvent はいわゆるイベントオブジェクトではなく、ステートレスなイベント通知インタフェースで、ほぼサービスと考えても良いくらいのものだ。ApplicationEvent の実装はメッセージングを使うようになっており、そのインフラ色の強さからか infrastructure パッケージに配置されている。

テストやサンプルデータ生成用のユーティリティも配置されているが、これらは本来ならテストソースフォルダなりリソースフォルダなりに移すべきものだろう。

INFRASTRUCTURE
infrastructure パッケージは、以下の3つのパッケージで構成されている。

persistence.hibernate
messaging.jms
routing

persistence.hibernate パッケージには、何度も the book で述べられているとおり（ドメイン層にインタフェースだけ存在する） Repository の Hibernate 実装が配置されている。

messaging.jms にはその名のとおり JMS 関連のコードが配置されており、infrastructure の観点では特に興味深い点はないが、ApplicationEvent のような application レイヤの実装も含まれている点は面白い。Sample Application 1.0 にはinfrastructure パッケージが存在せず、すべて application につっこまれていたことから、application は infrastructure-aware で良いのかと思っていたが、application もきちんとインフラから分離するようだ。

routing パッケージに唯一存在する ExternalRoutingSerivice は、なんとドメインサービスの実装だ。ドメインサービスの実装が infrastructure に配置されるなんて構成は考えたこともなかった。このサービスは、COHESIVE MECHANISMS として紹介した pathfinder へのリモート接続を含むため、infrastructure に配置されているようだ。接続先の pathfinder サービスは javax.rmi.Remote を実装しているため、RemoteException をスローする。

DOMAIN
すべての中心となる部分。パッケージは以下のように分割されている。

model
service
shared

model には、ENTITIES, VALUE OBJECTS, DOMAIN EVENTS, REPOSITORIES, FACTORIES といったDDDのビルディングブロックが含まれている。また、各種 Exception も含まれている。あまり説明はいらないだろう。

service には、ドメインサービスが含まれている。今回は、先ほど infrastructure で説明した RoutingService しか配置されていない。

shared には、DDDビルディングブロックを表す各種インタフェースや、Specification 関連の基本クラスなど、まさにドメインレイヤの基盤になるクラスたちが配置されている。

まとめ
まずは主要な部分である se.citerus.dddsample と補助的な部分である com.aggregator/com.pathfinder とは明確に分離できる。主要なドメインである dddsample は、（interfacesが追加されているものの）基本的には the book に忠実に分割されていることがわかる。

目次：
DDD Sample Application version1.1.0を確認する

DDD Sample Application version1.1.0: ユースケースの確認

2009-05-06T02:15:00.017+09:00

さて、まずは Sample Applicatin のユースケースを確認する。これには、実際に動かしてみるのが一番だが、そこまでするのが面倒な人のために、丁寧にもビデオが用意されている。なので、確認はこのビデオに沿って進めていきたい。

概要
細かい説明に入る前に断っておきたいのだが、このアプリケーションは the book（Evans の DDD本）で何度も例としてあげられている、積荷の出荷とトラッキングを扱ったアプリケーションがもとになっている。イメージとしては、DELL やら Amazon やらで商品を買った際に通知されてくる、配送状況確認ページを思い浮かべてもらうとわかりやすいと思う。
このアプリケーションではさらに、上記のような商品を買った側（Customer）からの配達状況の確認だけでなく、商品提供側（DELL や Amazon）による配送の手配や、配送業者による配達状況の更新までできるようになっている。最初にこれくらいのイメージを持っているとわかりやすい。
というわけで、ビデオはこれ。とりあえずは、ざっと画面のイメージだけ確認できればOK。細かい内容はこの後にも書いてます。逆に、ビデオの内容が完璧にわかれば、この後はほとんど読む必要ないです ^^;

このアプリケーションには、以下のような3つのインタフェースがある。

積荷（Cargo）のトラッキングインタフェース
配送予約とルートの管理用インタフェース
配送状況の更新インタフェース

最初の2つは Web、3つ目には Swing によるリッチクライアントアプリケーションと、ファイルトリガのバッチアプリケーションの2種類が用意されている。

積荷のトラッキング
これは、顧客（Customer）が注文した積荷の配送状況を確認するためのもので、トラッキングIDを入力できるだけのシンプルなインタフェースになっている。ここにトラッキングIDを入力して送信すると、以下の情報が表示される。

積荷の到着予定時刻
現在の積荷の場所
次に積荷が向かう場所
積荷の配送履歴

積荷が間違って（予定とは異なるルートで）配送されてしまった場合には、画面上に「Cargo is misdirected」とエラーメッセージが表示され、次に積荷が向かう場所は表示されず、積荷の到着予定時刻は不明と表示される。また、配送履歴のうちミスがあった部分に「×」がつく。
# 実際、顧客に直接こんな情報表示するんかいなという感じがするが…。
後で出てくるのだが「配送状況の更新インタフェース」にて誤った情報を送信した場合にこのように表示されることになる。

配送予約とルートの管理
商品の配送者（DELLとかAmazonとか）が、積荷の新規登録や配送ルートの選択を行うインタフェース。以下のようなことが可能。

積荷の状況確認
積荷情報の更新
積荷の新規登録（配送予約）
積荷の配送ルート候補の検索および確定

積荷の状況確認機能では、積荷情報の一覧表示、詳細表示ができる。詳細画面では積荷情報の更新に進むことができ、配送先のみが変更できる。「モノ」を管理するための典型的なインタフェース構成で、業務システムを作ったことがある人なら見飽きているだろう。
積荷の新規登録では、一度にすべての情報を入力しきるのではなく、まずは出発地点と到着地点、そして到着デッドラインのみを登録する。この時点でトラッキングIDが払い出されるが、配送ルートはまだ決まっていない。配送ルートは、配送ルート候補の検索および確定機能で別途確定させる。

配送ルートの検索と確定は、このシステムで一番面白いところだろう。入力された情報をもとに、配送ルートの候補がいくつか表示される。管理者はこの候補を確認し、好ましいルートを選択して配送ルートを確定させる。

なお、ビデオでは到着地点の更新は実行されていないが、既に配送ルートが選択された状態で到着地点を変更しても、エラーになることもなく警告メッセージのようなものも表示されない。かなり寛容な作りなようだ。

個人的には、こんなことに興味がある。後で確認してみたい。

Cargoに別々の状態を持たせているのかどうか
トラッキングIDをどのように払い出しているのか
配送ルート候補の検索で使われる、ルート選択ポリシーの種類とその扱い

配送状況の更新
配送業者（クロネコとか佐川とか）が、配送状況を随時更新するためのインタフェース。このアプリケーションはシンプルで、1画面しかない。ここに、以下のような情報を入力する。

更新時刻
トラッキングID
便（Voyage）
イベント発生場所のコード
イベントタイプ

便は必須項目ではないらしく、イベントタイプによっては必要ないようだ。例えば、工場から積荷を受け取るイベントが発生した場合、この時点では便は関係ないので入力は不要だ。

項目名に「イベント」とあるように、これは DDDのビルディングブロックの1つである「DomainEvent」を発生させるためのインタフェースであるらしい。これだけがリッチクライアントとして作られているのは、配送の現地（倉庫や船）から更新することを考えるとバーコードなどの専用端末からの更新が現実的なためで、Swingは端末を簡易にエミュレートしているのだろう。

個人的には、このあたりに興味がある。

バリデーションが存在しないのは、DomainEventパターンの適用によるものなのか、端末エミュレートによるものなのか

配送状況の更新（バッチ）
Swingアプリケーションとは別に、配送状況を一括更新するインタフェースも存在する。これは、タブ区切りのテキストデータが指定のフォルダに置かれると、そのデータをもとに自動的に配送状況が一括更新されるというものだ。一括更新であること以外の機能は Swingアプリケーションと同じで、テキストデータの1行として記述する項目も、Swing アプリケーションと同じ。ビデオでは、配送状況の更新インタフェースの一部として扱われている。

まとめ
というわけで、ビデオを見るとだいたい何をやっているかはつかめると思う。一応、次回以降で確認するイベントをあげておく。

配送状況の詳細表示
積荷の一覧・詳細表示
積荷の新規登録
積荷の状態更新
配送ルート候補検索
積荷への配送ルート設定
配送状況の更新
配送状況の更新（バッチ）

次回は、これらイベントの個別のハンドリング方法を確認する前段階として、アプリケーションの全体構造を確認する。

目次：
DDD Sample Application version1.1.0を確認する

DDD Sample Application version1.1.0 を確認する

2009-05-06T01:04:00.008+09:00

ようやく Evans の DDD本（the book）をすべて読み終わった（長かった！）ので、オフィシャルに提供されているサンプルアプリケーションである DDD Sample Application を確認し、具体的な実装方法やビルディングブロックの実例を見つつ理解を深めておきたい。昨年リリースされたバージョン1.0は軽く確認したのだが、3月25日にリリースされたバージョン1.1.0はまた結構変わっているようなので、あらためて最新のDDDアプリケーション構造を確認していく。
とりあえずは、こんな感じで進めていく予定。

ユースケースの確認
アプリケーション全体構造の確認
ユースケーススライスから見たアプリケーション構造の確認
ドメイン構造の確認

ユースケースの確認
このアプリケーションが何を目的として作られ、どんな機能を提供するのかをユーザー視点で確認する。

アプリケーション全体構造の確認
細かいコードの確認に入る前に、アプリケーション全体の構造がどのようになっているのかを確認する。主に、Distillation や Large-Scale Structure の観点からアプリケーション全体構造の特徴を把握する。

ユースケーススライスから見たアプリケーション構造の確認
機能的な観点から見たアプリケーションの構造を確認する。各ユーザーイベントに対してどのようなソフトウェア要素が対応し、どのようにドメインレイヤにつなげていくのかを把握する。主にプレゼンテーション層（interfacesパッケージ）、サービス・アプリケーション層（applicationパッケージ）、インフラ層（infrastructureパッケージ）を確認する。

ドメイン構造の確認
ドメイン層がどのように構成されているのかを確認する。メインの部分。

最後までできるかな…てか予定どおりいくかな…。

コンテンツ一覧：

DSM(DomainSpecificModeling) + DDD

2009-05-02T01:14:00.011+09:00

DDDオフィシャルサイトに掲載されている、DSM(Domain Specific Modeling)に関するインタビューを起こしてみた。オリジナルのビデオはここ。どうでもいいと思ったところや一部よくわからなかったところは飛ばしてるし、間違っているところもあると思います ^^;

はじめに
Interviewer(以下"I"):
Peter Bellが来てくれた。自己紹介してくれる？

Peter Bell(以下"P"):
カンファレンスなど、色んな場面でこのトピックについて話している。DSMやコードジェネレーションについて話すのにベストな人間だと思う。

DSMとは
I: 今日はDSMについて話したいが、まずはDSMが何か教えてもらえるだろうか？

P: 役に立つ良い定義としては「開発プロセスのスピードアップ、アプリケーションの一部または全体の生成、コードベースのメンテナンスなどのためにDSLを使うこと」のように言えると思う。

I: じゃあ、DSLって何？

P: 3つのコンポーネントがあると思っている。
まず1つは、Javaなどの汎用言語とは異なり、特定の問題を解決するためのものであるということ。
2つ目は、コンストラクションのレベルをひきあげるものであること。JavaやC#とおなじようにかかなくても良い。
3つ目は、実行可能であるということ。ユビキタス言語は必ずしも実行可能でなくてもいいが、DSLはジェネレーションやインタープリタを通して実行できる。

I: それがユビキタス言語とDSLの違いなんだね？

P: その通り。DSMはアプリケーションを生成したり実行したりするのに十分なユースケースのセットにフォーカスしていて、ユビキタス言語から直接アプリケーションを生成する。こうすることで色々メリットがある。

I: プロジェクトでは、会話で使われるようなユビキタス言語もあればコードにあらわれるユビキタス言語もある。後者は実行可能なユビキタス言語、つまりDSLなのか？

P: そう言える。えーとここで、DSMの世界で重要なDSLの興味深い区別について話しておきたい。内部DSLと外部DSLだ。内部DSLはAPIとかRuby Groovyのような言語を使って、人間が読めるようなDSLをコード内に作るアプローチだ。このアプローチではDSLの利点をフルに受けることはできない。なぜなら、ホスト言語の構文上の問題を気にしなければならないからだ。
外部DSLはよりパワフルで、DSLをコードの外部に持ち出し、DSLのステートメントを書くためのツールを別途用意できる。これは、箱と線で書けるようにもできるし、テキストで書くようにもできるし、スプレッドシートで書くようにもできる。
外部DSLの利点はジェネレートされた個々のステートメントをテストしなくていいので開発やメンテナンスのスピードをあげることができること。

I: 利点についての話があったが、他に利点はある？
P: 最も大きなものとしては、テスティングコストの低下があげられる。よくできたユビキタス言語は確かに、ステークホルダーとプログラマの間のコミュニケーションの問題を改善できる。しかし、コードへの変換時にはインピーダンスミスマッチがあるため、ここで理解の齟齬が発生し、バグの発生につながってしまう。DSMではこのような事態を完全に避けられる。ステークホルダーとコミュニケートし、彼らが話すことをそのまま書き、コードをジェネレートできる。

I: 言語が正しければ、テストの必要はない？
P: セマンティクスはもちろんテストする。DSLのステートメントが正しくその意図を表しているか、つまり与えられたステートメントが正しくジェネレートされるか、もしくは正しくインタープリタで実行されるかどうかはテストするということだ。しかし、すべての個々のステートメントをテストする必要はない。

I: 開発のスピードがあがるとのことだが、アップグレードも頻繁になるのでは？
P: その通り。頻繁にビルドするようにもなる。だが、メンテナンスの際に細かなコードブロックを見るのではなく、意図が明示されたDSL（ユビキタス言語）を見ればいいからメンテナンスも楽になる。

I: 利点にはすべてトレードオフがある。モデルが変更された場合、言語も変更することになると思うが、既存のツールでこの変更に対応するのはどれくらい難しい？
P: シンプルなリファクタリングサポートは既に存在しており、軽微な変更には問題なく対応できるが、根本的な変更に対しては無力。ただし、これはJavaやらC#を使っていても同じ。
ドメイン（に関する理解）が安定するまで、ジェネレータやインタープリタの作成を先延ばしにするのも良いかもしれない。

DSMにまつわる誤解
I: 誤解について話したい。DSMについては色んな話（誤解？）を聞いたが、そのうちのいくつかはUMLについてだった。
P: そりゃDSMではもっとも有害な誤解だと思う。仮に私がDSMをMDAやUMLからはじめていたとしても、UMLは使い続けなかったと思う。UMLは世界中で多くの人が使っていて、標準化もされており、多くの利点がある。しかしUMLの問題は、記述のレベルは抽象的すぎるということ。ステレオタイプでドメインのコンセプトを表せるようになってはいるが、クラスやメソッドが何をすべきかは何も決められていない。クラスごとに箱が1つ用意されるだけだ。なので、モデルからモデルへの変換やモデルからのテキストへの変換は簡単ではない。XMIみたいに。MDAがDSMの小さなサブセットにすぎないことを理解しておくことは非常に重要だと思う。
MetaCaseとかOpenArchitectureWareはEclipseプラグインも提供していて、開発者はテキスト指向のDSLを書く事ができる。これは、MDAに比べるとだいぶ使いやすいと思う。

DSLとドメインエキスパート
I: DSLはドメインエキスパートが書けるようにするべき？
P: ここはDSMに関してさまざまな関心がある部分だ。秘書が会計システムを書けるようにしようとしている、とかね。DSMアプローチでドメインエキスパートがDSLを書けるようにすることはできる。が、より利点があるのはドメインエキスパートが読めるようなDSLを作る事。ドメインエキスパートとプログラマの間のミスコミュニケーションを防ぐ事ができる。ユビキタス言語が引き起こしがちな、実装時の齟齬を防ぐ事ができる。

I: 少し自分の経験について話させてもらうと、ユニットテストやシナリオテストを書いてドメインエキスパートと共有した時、ドメインエキスパートはJavaなどのシンタックスノイズに悩まされていた。ユビキタス言語を使っていたとしても、ドメインエキスパートには（コードが何を意味しているのか）説明しなくてはならない。DSLを使えばわかりやすくできるように思うが、どうか？

P: BDDのようなアプローチが既に存在しているよね。統合テストではあまりできていないが、DSLが貢献できるいい例だと思う。統合テストにDSLのアプローチを持ち込むことで、ドメインエキスパートにとってとても読みやすくなる。将来はもっとよくなって欲しい。

Big Design Upfront or Agile
I: ドメインを前もって知っていれば、急激な変更が少なくなり、DSLにとって利点が大きいとするなら、前もってヘビーな分析作業をしなくてはならないのでは？
P: Big Design Upfrontをやりたがる人は最近ではほとんどいないと思う。コミュニティは、よりアジャイルなアプローチを取ろうとしている。MetaEdit + MetaCaseなどが良い例だ。これは、頻繁なモデルの変更を助けるような機能が豊富に用意されている。DSMは決してBDUではないことを強調しておきたい。

どの程度コード生成すべきか
I: アプリケーション全体を生成すべきか？
P: コード生成については色んな考えがある。アプリケーション全体を生成しなければならない、というものもあれば、アプリケーション全体を生成なんてできっこない、というものもある。これは、どちらも間違っていると思う。
100%の自動生成は可能ではある。変数のないテンプレートのようなものを使えば、既存のコードに1対1対応するようなコード生成はできる。だが現実には、（このようなアプローチで）すべてのコードを生成するのは意味がない。
DSMの世界では、色んなコードジェネレーションのツールがあり、コードを書くのが非常につらい、クラスやAOP、イベントドリブンプログラミングなどを書かなくてすむようにしている。これらのツールではジェネレートされたコードとカスタムコードは分離して扱うことができ、これら両方でアプリケーション全体を構成することができる。100%のコードを自動生成する必要はない。ドメインモデルが比較的リッチな場所を探し、ドメインエキスパートとコミュニケートして、DSLを作る、といった作業にスタッフをあてるといいだろう。そういうエリアにDSMを適用するのは労力に見合った利点があるからだ。

DSMに適したプロジェクト
I: DSMはどんなプロジェクトに向いている？
P: 良い質問だ。プロジェクトをよりDSMに適したものにしてくれるいくつかの要素があると思う。
1つ目、これはあまり言ってないことだが、DSMの熟達度だ。SpringやAOPを導入する時と同じで、最初に技術を導入するときには色んな面倒なことがある。また、動的言語、パーシャルクラス、クロージャなどを使う事でエレガントなアプリケーションをすばやく作り上げる事ができるが、開発者がそれをメンテナンスできるとは限らない。
なので、DSMの経験がある人をプロジェクトにいれて、経験をプロジェクトに持ち込むことが重要だ。これは非常に助けになる。

他の話としては、能力が許す範囲でいくつものプロジェクトを並行にすすめられるしても、投資を回収するには、ドメインの特定のエリアにとどまり、DSMがより長い時間使われるようにしなければならないということだ。DSMにはかなりのオーバーヘッドがあるので、6回以上やりたいかもしれないが…外部DSL用のツールがこの種の問題を解決しようとしてはいる。

水平的ドメインと垂直的ドメイン
ドメインは水平的にも垂直的にもなり得ることを理解するのも重要だ。
垂直的なドメインでは、成果は（例えば）1つの保険会社のためだけに使われる。

だが一方で、Webの部分は何度も同じようなものを生成することになる。例えば、ドレスショップ向けのeコマースと法律事務所向けの文書リポジトリなど。これが水平的で技術的なドメイン。水平的な技術ドメインはどこでも変わらないので、我々はモデル、コントローラー、バリデーション、リレーションシップなどWebアプリケーションを迅速に構築するための一連のDSLを既にもっている。
1つの企業で働いている人…つまり垂直的ドメインを対象にしている人たちは、領域を限定することで、DSMの能力を最大限に生かし、素早くアプリケーションを作ったりメンテナンスしたりしている。多量のJavaのコードに戻ることなく、少ない文で正確に意図が表現されているからだ。

現実のDSL/DSLの構築方法
I: HibernateはDSL？
P: HibernateはORMに関するDSLをいくつか示している。
こういう言語を作る場合、どのように始めればいいか聞かれることがあるのだが、盗めばいい。
ORM, DI, AOPのような水平的ドメインを扱うなら、既に多数のDSLが存在するので、この上にかぶせる形でシンプルな、カスタマイズされた自分のユースケース向けの小さなサブセットを作れば良い。
水平的ドメイン（たぶん垂直的の間違い）では、XMLスキーマも良い出発点になるだろう。銀行や保険の業界では、標準がすでに存在している。それらのサブセットを作る形で、必要に応じて自分の状況に応じてカスタマイズすればいい。

ドメインのコアコンセプトを理解する方法
I: ある特定のドメインを扱うような場合、ドメインに関する市販本などもあるが、読んでる？ドメインのコアコンセプトをどうやって知っている？
P: DDDと連携していくのがいいと思っている。
DDDは（DSLにつながる）ユビキタス言語を作るためのアプローチをあげており、DSMはジェネレートやインタープリタを使って効率的に実行する方法を持っている。これら2つのコミュニティは、お互いにディスカッションするといいと思う。既に2つのコミュニティでは活発なコミュニケーションがあると思っているが、より強くしていきたい。DSMコミュニティはDDDコミュニティからよりよく言語を設計する方法を学べるし、DDDは言語を実行可能にする方法を学べる。

I: 今日はどうもありがとう。

雑感
一部マーケ的においはするものの、全体としてはまっとうなことを話している印象。コード生成に関するスタンスも現実的だとは思う。しかし、DSMという新たな用語は必要なんだろうか？世の中を混乱させたり、コミュニティの評判を下げかねないので"DSL"を使い続けた方が良いのではないかと感じた。
また、DDDが向かうべき方向として良いのかどうか、今ひとつ確信が持てない。実行可能なユビキタス言語を作ることで、色んなロスがなくなるというが、それが本当かどうかは具体例を見てみないとなんとも言えないな。ドメインエキスパートの可読性を保ったままDSLを構築できるのだろうか？ユビキタス言語全体がDSLとして構築されるとは思えないのでサブセットになるのだろうが、一部だけ妙に形式的になるのだろうか？モノが見てみたい。

技術者／プログラマのためのモナドと圏論第1回行ってきた

2009-04-24T10:20:00.028+09:00

またまた行ってきた。前回（論理・ラムダ・圏）、タイトルに「圏」とありながら、実際は圏の話がほとんどできなかったことを受けてはじまった、新シリーズ。細かいところや背景知識なんてわかるわけがない（数学ほとんどやってないし）ので、わかった範囲で書きとめておく。間違いまくってる可能性大。

全体的に

教科書的に進めようかと思っていたそうだが、檜山さんが体調不良で方針転換。形式的なものより、お絵かきメインで進めることになった。

というわけで、第1回の予定はこうでした。

まえおき／まえせつ
いろいろな図の描き方
圏の定義と実例
休憩
行列の圏で遊ぶ
コレクション・データ

実際は、3の途中まで（休憩はやったよ！）で終了しました:-D

まえおき／まえせつ

シリーズ全体の目標としては…

圏の基本概念を学ぶ
モナドの実例をたくさん知る
モナド法則に慣れる
モナドのクライスリ圏の作り方を知る
モナドがモノイドであることを理解する

こんなとこで、4くらいまではいきたいそうだ。自分としては、ここまでいければ当面満足なので、しばらくは独学であがかなくてもよさそうなのが非常に嬉しい。

今日の目標は…

圏の定義と直感的なイメージの両方を知る
お絵かき実習する
圏の実例をいじって体になじませる
横道にそれて面白そうな話題を紹介する

モナドの意義

今のところさっぱりわかっていないモナドの意義。計算の観点からは、

コレクション・データ構造に統一的見方を与える、らしい
関数計算を拡張・一般化できる、らしい
文や式の構文論を整理できる

どれもこれも現段階では具体例がわからないのでいまいちピンと来ないんだけど、1番目と2番目はHaskellやらの関数型言語をさわる際に、（気持ち・理解的な）役に立ちそう。特に、関数計算に部分関数、エラー・例外、状態・副作用などを導入する形で拡張するのに出てくる、というあたりはとても興味深い。楽しみだ。

圏論の観点からの意義は、知らない語ばっかりでいまいちよくわからなかった。好奇心の観点からは、色んなものがモナドでっせーみたいな話のようで、もしかしたら後で出てくる「色んなものを圏の枠組みで見ると同じように見え、同じような問題が同じように解ける」とかいう話と関係しているのかもしれない。が、よくわからない。

回路とか関数とかの書き方

[ ボックス図 ]

関数をブラックボックスとして記述。

[ オダンゴ図 ]

ボックス図の省略版。箱を書くのがめんどうくさいので生まれたらしい。ボックス図もそうだが、ブラックボックスの内部を書くこともできる。

[ ストリング図 ]

オダンゴが小さくなった感じ。

さて、以下の3つの関数で…

f(x, y) = 3x + y
g(z) = z + 1
h(x) = x * x + x

f(x, y) と g(z) のComposition（結合・合成）をオダンゴ図で書いてみる。

きたねええええええ！

…h(x) をオダンゴ図で書いてみる。

h が少し面白いのは、普通に書こうとすると、x が1つしかないので2乗などができずに困ってしまう点。xを複製するようなワイヤリングをすればいいのだけど、このようにに、引数も消尽され得るリソースだと考えると、コンピュータによる計算のリソースセンシティブな部分をうまく表現できるようだ。これは、論理の世界で考えると線形論理に対応しているらしい。なんか前回そんなことを言っていた。この複製（や交差）なんかのワイヤリングを計算と考えることもできる。

テキスト表記（Symbolic Calculationというらしい）だとわからなかったことが、絵算（Pictorial Calculationというらしい）だとわかる、というのも面白いところ。これらは一長一短があるので、状況によって使い分けるといい、とのこと。

引数・戻り値の数

引数は複数あるが、戻り値は常に1つでないといけないのか？

そんなことはない。実際、先ほどの f と g の合成関数の例では、ボックス（ダンゴ）の位置を少し変えれば（合成関数自体は同じでも）簡単に戻り値が複数あるような関数に変更できる。

が、人間は多値（特に戻り値）を扱うのはあまり得意ではないので、1つにしていることが多い。複数必要になった場合には、タプルで対応する。

f: A, B => C

これはAとBの2引数を取り、Cを返す関数だが、

f': A×B => C

このような、A×B型のタプルを引数として取る関数とまぁ同じと考えて良い。掛け算記号の×は、タプル型をあらわす。タプルは色んな表記法があり、（特にプログラミング言語では）()だったり[]だったり{}だったりする。プログラミング言語から中立であることを示しつつタプルを表記するため、<>をよく使うらしい。

f'(<x, y>) = f(x, y)

g'(x, y) = g(<x, y>)

これは、絵算で言うと、ワイヤーを束ね（て1本にす）ることに相当する。フラットケーブルとかそういうやつ。こんな感じ。

ダンゴ図で書くときは、右下にちっちゃく書いてるように、ゴムみたいなので束ねるように書いたりする。

ストリング図とアロー図

今まで書いてきた、ボックス図・オダンゴ図は、どちらもストリング図という種類になるが、一般的に図（Diagram）というと、たいていはアロー図を指す。以下のような関数について考えてみる。

f: A => B

[ ストリング図 ]

関数が箱（または点）、引数や戻り値が矢印（アロー）になっている。

[ アロー図 ]

関数が矢印（アロー）、引数や戻り値が点になっている。

# なんか、圏っぽい。てか圏のセミナーでした。

この2つの違いは単に趣味的なものではなく、大きな差である、らしい。ちなみに、アロー図はペースティング（Pasting）図や球状（Globular）図とも言うらしいが、これは絵を2次～3次元に拡張した場合に円や球に見えるから、だそう。スライドには高次圏とか書いてあるし、とりあえず今はわからなさそうなので飛ばしてしまう。

矢印で何を表すのか

矢印は、色んな意味で使われるので注意が必要。違うことが同じ記号や同じ言葉で語られるため、混乱しやすい。これから出てくるものとしては…

要素関の対応関係（集合の要素、元同士の対応関係）
集合同士の対応関係（集合同士の対応関係、写像？）
関手（どうやら圏と圏の対応のようなものらしい）
自然変換（関手同士の対応のようなものに見えるが）

こんなものが、すべて矢印であらわされる。

圏、しりとり圏

はじめての圏論で書かれていた、しりとり圏をもとに圏を説明。以下、しりとり圏の構成要素の転記。

対象の集合: H -- ひらがな文字全体の集合
射の集合: HStr -- ひらがな文字列全体の集合
域 dom と余域 cod ： first, last : HStr => H（最初と最後の文字）
恒等 id : unit : H => HStr（1文字からなる文字列）
結合（composition） : しりとり結合 s;t は last(s) = first(t) のときだけ定義される

まずは、圏のなんとなーくのイメージをつかむ。といっても、今まで出てきた話の延長線上にある。というか、もちろんそういう風に話を持っていっているんだと思います :-D

対象というのは、アローダイアグラムでの点みたいなもの。射というのは、アローダイアグラムでの矢印のようなもの。域というのは、矢印の出発点側にくっついている点のようなもの。余域というのは、アローダイアグラムの終点側についている点のようなもの。

結合は、（つなげられる）矢印同士をつなげること。

# f;g は、fとgの結合です。

恒等は…ものすごくぶっちゃけていえば、ある点から出て同じ点に帰ってくる矢印みたいなもの。

で、同じ点に帰ってくる矢印なんだから、他の矢印と結合しても、元の矢印（がたどり着く点）は変わらないでしょう、というようなもの。

なんかこんなイメージ。これを、しりとりにあてはめると、こんな感じになる。

# 実際には、点や線はもっとたくさんある。

以下、圏の構成要素がしりとり（圏）において何に対応しているのか考える。

[ 対象 ]

対象は、ここで言えばひらがな1文字1文字のことにしてある。'あ' とか 'い' とかそういうやつ。なので、対象の集合は、ひらがな文字全体の集合になる。

[ 射 ]

射は、対象、つまりひらがな文字の間に引く矢印みたいなもので、今回は（ひらがな文字を並べた）文字列、ということにする。射の集合は、ひらがな文字列全体の集合。

[ 域と余域 ]

域は、文字列の先頭の文字とする。"きまいら"の域は、'き'。余域は、文字列の末尾の文字とする。"きまいら"の余域は、'ら'。

[ 結合 ]

結合は、射（つまり文字列）同士をくっつけることで、定義では「1つめの射の余域」と「2つめの射の域」が同じでなくては結合できない。これを今までの定義で言い換えると、「1つめの文字列の末尾の文字」と、「2つめの文字列の最初の文字」が同じでなければ結合できない、となる。つまり、しりとりできる文字列しか結合できない。今回の結合では、（しりとり可能な）文字列同士を結合し、重複した文字を（1つ）取り除くこと、とする。

"きまいら";"らいおん" => "きまいらいおん"

こんな感じ。なんかしりとりっぽくなってきた。

[ 恒等 ]

恒等は、射と結合しても変わらない射なので、これまで決めてきたことから考えると、長さ1の文字列になる。"あ"とか"い"とか。例としては…

"きまいら";"ら" => "きまいら"

"き";"きまいら" => "きまいら"

こんな感じ。少し前のざっくりした説明だと、同じ点に帰ってくる矢印みたいなもん、って書いてたんだけど、同じ点に帰ってくる射（文字列）でも、"きつつき" なんかは恒等にはならない。これは、他の射と結合した場合に違う射になってしまい、定義を満たさないから。たぶん。

# 射が同じってのは、定義しなくても大丈夫なんだろうか？文字列が同じって考えていいんだよなぁ…？

恒等自体は射（矢印）なので、"あ"とか"い"とかは、文字ではなく文字列なのに注意。

圏の法則

ここで、圏の法則をば。下つき文字の書き方がわからないので unit はプログラミング言語っぽく書いちまいます。今作ったしりとりの圏が、この法則を満たしていることを確認する。

first(unit(x)) = last(unit(x)) = x (x∈H)
first(s;t) = first(s), last(s;t) = last(t)
(s;t);u = s;(t;u)
x = first(s), y = last(s) なら、unit(x);s = s;unit(y) = s

[ 1つめ ]

対象xの恒等（射）の域は、対象xに等しい。
対象xの恒等（射）の余域は、対象xに等しい。

と言っている。しりとりで文字をあてはめてみると…

文字: 'あ'
対応する1文字の文字列: "あ"
文字列 "あ" の域: 'あ'

というわけで、きちんと法則を満たしている。当たり前か。末尾も同じ。

[ 2つめ ]

射sと射tを結合した射の域は、射sの域に等しい
射sと射tを結合した射の余域は、射tの余域に等しい

これもしりとりで文字をあてはめてみると…

射s: "きまいら"
射t: "らいおん"
射sとtの結合: "きまいらいおん"
射sとtの結合の域: 'き'
射sの域: 'き'
射sとtの結合の余域: 'ん'
射tの余域: 'ん'

というわけで、成り立っている。

[ 3つめ ]

射sと射tを結合し、それに射uを結合したものは、射sに射tと射uの結合を結合したものと同じ

全然わかりやすくなってないな…。しりとり。

射s: "でんき"
射t: "きまいら"
射u: "らいおん"
(s;t);u: ("でんき";"きまいら");"らいおん = "でんきまいら";"らいおん" = "でんきまいらいおん"
s(t;u): "でんき";("きまいら";"らいおん") = "でんき";"きまいらいおん" = "でんきまいらいおん"

成り立っている。なんかむなしくなってきた。

[ 4つめ ]

射sの域がxであり、余域がyであるならば…
xの恒等（射）unit(x) と射sの結合は、射sに等しい
射sとyの恒等（射）unit(y) の結合は、射sに等しい

しりとりで。

射s: "きまいら"
射sの域 x: 'き'
射sの余域 y: 'ら'
xの恒等 : "き"
yの恒等 : "ら"
xの恒等と射sの結合 : "き";"きまいら" = "きまいら"
射sとyの恒等の結合 : "きまいら";"ら" = "きまいら"

OK。しりとり圏はちゃんとした圏。らしい。

unitで混乱

セミナーの最後に、unitに関して質問があり、微妙に混乱した。内容は…

構成要素には、unit が「対象」から「射」への写像（って言ってたかなぁ…）だとされているけど、絵で見ると恒等というのは「対象」から「対象」への射になっているので、別のものですよね？というもの。

これはたぶん…

unit: unit(x) で「対象xに関する恒等（射）」をあらわすもの、つまり対象から射への写像
unit(x) : ある対象xに関する恒等（射）、unitに具体的に対象が与えられたもの

というものがごっちゃになって混乱した、という話だと思った。あってるのだろうか。

Map Finite Ordinals

２つめの圏の例。こんな対象を考えてみる。

[0] = {}
[1] = {1}
[2] = {1, 2}
[3] = {1, 2, 3}
[4] = {1, 2, 3, 4}
…

射の具体的な内容は、要素間の対応関係（の組み合わせ）になる。ここで、対象間の矢印と要素間の矢印は違うものをあらわしていることに注意。

具体的に域が[2], 余域が[3]であるような射について考えてみると、射の数は9つになる。これは、実際に書いてみればわかる（が省略！）。[1]も加えて射の数を考えてみると…

こんな感じ。一般化すると、[n] から [m]への射の数は、mのn乗になる。

# この先はハイスピードでとばしまくり。

部分圏

MapFOの中でも、こんなものは部分圏になる。

InjFO 単射の圏
IsoFO 同型射の圏
IncFO 包含写像の圏

IncFOよくわからなかった。

関手

スライド0.2秒くらい、説明ゼロでした :-D

例を見ると、HSiri => KSiri が関手になっているので、圏を「対象」として見たとき、つまり圏の圏を考えたときの射が関手、ということなんだと思う。けど、具体的なイメージが…。

同じに見える色んな問題

スライドに書いてある色んな問題たちが同じようにみなせるらしい。が、どれとどれが同じなのか、はたまた全部同じなのか、よくわからなかった。

時間切れ、終了。なんか飲み会行ってテンションあがったので頑張って書いてみた。他の出席者の方のように、「あー、なるほど、あれがあれね！」とか「じゃああれはこうですか？」みたいなつっこんだ話は全然できず、道のりの長さが感じられたんだけど、それはそれでよかった。わかってること勉強しにいってもしょうがないしね。もう少し初級者向け（幻想？）の圏論読書会も立ち上がるかもしれない雰囲気。

アーキテクトの審美眼

2009-04-18T23:00:00.009+09:00

MS萩原さんのセッション。同名の書籍（元ネタはDBマガジンの同名の連載）が元になっていて、そのダイジェスト版＋最新の動向の補足、という形。

とても示唆に富んでいるんだけど、抽象的な上に、1つ1つのトピックがめちゃめちゃ重たいので、きちんと理解しようとすると調べる量がとても多くなってしまう上に、そもそも理解しきるのが難しすぎる。とりあえずは現段階の自分の稚拙な理解をもとに、こんなことじゃないかなーと補足しながら書いていく。

アーキテクチャの原則

アーキテクトにとっては、アーキテクチャの原則を理解することが重要。アーキテクチャの原則は、インフラなどが変化しても変わらず、クラウドでも通用する。

アーキテクチャ先行定義の原則

アーキテクチャは先行定義せねばならぬ、という原則。アーキテクチャ設計を含むソフトウェア開発は、こんな風な流れになるはず。

モデリングとアーキテクチャ設計の双方のインプットとして、システムの機能要求・非機能要求があげられていた。

■ モデリング

この部分は、システム化対象（ドメイン）を何らかのパラダイム（DOA/OOAなど）でモデル化する作業だと思われる。ドメインモデリングであれば、主に機能要件がそのインプットとなりそうだ。

■ アーキテクチャ設計

アーキテクチャパターンやリファレンスモデルをもとに、機能/非機能要件を満たしうるアーキテクチャを整備していく作業だと思われる。アーキテクチャ設計では、例として以下のような項目を（仮）決めしていくようだ。

# メモしきれなかったので一部のみ ^^;

プラットフォーム

フレームワーク

データモデル

トランザクションモデル

セキュリティ

[メモ]

図では、モデリングとアーキテクチャ設計が並列になっているが、モデリングとアーキテクチャ設計を完全に独立で実施できるとは思えない。アーキテクチャ設計にフレームワークやデータモデルが入っていることから、お互いになんらかの関係があることを示唆している気もする。もしかしたら、順序関係や依存関係を定義した図ではないのかもしれないし、マッピング/設計のフェーズがそれを包含しているのかもしれないが、セッションからはよくわからなかった。

個人的にここで重要だと思うのは、システム開発にはなんらかの形での「システム化対象のモデリング」が存在することを明示している点。そして、DOAやOOAを包含して「モデリング」としている点。データモデリングやオブジェクト指向モデリングをしているんじゃなく、「システム化対象」を「データの観点」や「オブジェクトの観点」からモデリングしているんだ、というのは、個人的になんだかしっくりくる。
[/メモ]

データアーキテクチャの原則

データには、マスターデータとトランザクションデータが存在するが、それぞれのデータには特性があり、扱う方法にも原則がある、という話。

■ マスターデータ

複数のアプリケーションで共通的に使われるデータ

論理的にはアプリケーションの外に出すのが原則

■ トランザクションデータ

属性として「時間」を持っている

追加（新規作成）のみで、変更も削除もされない

ETLなどでDWHやDMにぶちこまれる

# なんかこんな感じだった気がする。

実際は、特にマスターデータに関してはこのようになっていないことが多い。これは、マスターデータ自体の共通性は高いのだが、ビューが異なると必要な属性が異なってくる（属性にバリエーションがある）ため、Factor outしづらいのが原因。

なお、マスターデータは論理的に一箇所で管理すればよく、必ずしも物理的に一箇所で管理する必要はない。

[メモ]

マスター、トランザクションの区分はデータモデリングの王道中の王道。THでもTMでも、定義の厳密性や名前の違い（イベント/リソースなど）こそあれ、基本的なスタンスは同じ。

マスターデータをアプリケーションにまたがって共通的に持つ、というのは、最近DOA界隈（と言ってしまっていいのだろうか）ではやりのMDM（Master Data Management）と同じですね。データ総研の椿さんも同じこと言ってました。

マスターデータがコンテキストごとに属性のバリエーションを持つ、という問題を解決する方法は明示されなかった気がするんだけど、どのように考えているんだろうか？「外だしする＝共通性として認識する」、「コンテキスト（アプリケーションやビュー）ごとに持つ＝可変性として認識する」と考えると、結局は共通性と可変性の認識の問題になる気がする。負の可変性とか。この境界は、時間の経過や事業領域の変更でも変わっていくのだと思われる。

物理的に一箇所にする（大福帳DB？）のではなく、論理的に一箇所にすれば良い、というのは現実を考えると非常に重要だと思う。

[/メモ]

Entity（個体）識別の問題

Entityはそれ単独（そのものが持つ本質的な特性）では決まらず、他との相対的な関係でしか決定できない。Relationshipは関数従属性であり、ビジネスから決まる、とも言っていた。

[メモ]

これは、データモデリング（OOも）の永遠の課題である、個体（Entity）をどうやって認識するのか、という話だと思うが、CoddのRelationalモデルとChecnのEntity-RelationshipモデルはどちらもEntityの識別方法を与えてくれない。詳しくは忘れてしまったけど、そもそもRelationalModelにはEntityなんてなかったと思うし。ChenのE-Rモデルでは、Eのまともな定義がないため、抽出の役に立たない。

TMとTH、両方のセミナーを受けたことがあるんだけど、ChenのERモデルが工学的（実務的？）に問題があることまでは共通の認識として持っていて、それぞれに定義を補足した上で抽出手順を決めている。詳しくはそれぞれのモデリング技法をどぞ！

追記：
書籍の方では、データモデリングにおいては既存の帳票や画面からのボトムアップ＋関数従属性による正規化によって、Entityは一意に識別できる。が、OOの場合はトップダウンにならざるを得ず、一意性を保証できない点が問題だ、という感じで書いてあった。

[/メモ]

アプリケーションの設計モデルは、データモデルと独立して定義可能。ビジネスモデルをそのまま反映することもできる。アプリケーション設計モデルのコアな部分は、ユースケースと独立して、先行して定義する。関係はユースケースが決まらないと確定しないので、ブレが大きくなる。

[メモ]

「アプリケーション設計モデル」が少しわかりづらいんだけど、自分はアプリケーションの構造（特に、PoEAAのDomain Logic Patternsに相当するもの）の選択と、それがドメインごとに具体化されたものだと理解した。そうすると、Domain Logicのモデルはデータモデルとはある程度独立になる話も理解できるし、アプリケーション設計モデルのコアがUCの定義に先立つ、という話も、勘定構造（Accounting Patterns）の導入などと絡めて考えれば理解しやすい。気がする。

[/メモ]

縦の構造と横の構造

アプリケーションの構造は、縦の構造（Entity）と横の構造（Relationship）から成ると考えることができる。縦の構造は比較的固定化されており、横の構造は比較的流動的。変更要求があった際に、それが縦の構造に影響を与えるか、横の構造に影響を与えるかによって、修正コストは大幅に違ってくる。

# よって、（このコンテキストでは）いかにEntityを安定なものにするかが重要になってくる。

[メモ]

この「縦の構造」と「横の構造」は、ソフトウェア（ひいてはビジネス）は視点によって複数の構造を取りうることを表している。
ただ、モデルとしては複数の構造を持っていたとしても、複数の構造をソフトウェアとして実装するのは単一のパラダイムでは難しい。
手続き型では階層的に詳細化された手続きを呼び出すような単純な構成になるし、オブジェクト指向であってもクラス構造は基本的に単一で、まったく違うクラス構造を重ね合わせて実装することはできない（多重継承やMix-inはある程度これを可能にするが）。
複数のパラダイムが形作る構造が対等な関係で関連し合うようなアーキテクチャも考えられるのかもしれないが、現段階では主たるパラダイムが主たる構造を構成し、それ以外のパラダイム（やメカニズム）が補足的な構造を形作ることが多い。この、主たる構造が縦の構造、補足的な構造が横の構造と呼ばれているのかなーと感じた。

補足的な構造を導入するためのパラダイムがアスペクト指向で、現状では主としてアスペクト指向プログラミングが、（ビジネス構造を表す主たるクラス構造に）非機能要求の実現を表す構造を導入する形で用いられている。ヤコブソンは、アスペクト指向による分析・設計を考えており、ユースケース（というアスペクト）を分析・設計段階で扱うことを考えているようだが…。

[/メモ]

パラダイムの進化

オブジェクト指向には限界がある。

言語間の通信が困難

動的なオブジェクトのブートやシャットダウン

非機能の扱いが困難

[メモ]

言語間の通信とか、OOの問題ではなく、OOの典型的なプラットフォームが持つ問題のような気がするんだけど…。動的なオブジェクトのブートやシャットダウンも同じく。

[/メモ]

パラダイムは進化してきた。

手続き型 => オブジェクト指向 => コンポーネント指向 => サービス指向 => Web指向

[メモ]

コンポーネント指向は、言語間の通信が困難である点を解消する。サービス指向が改善するものはなんだろう？再利用可能性だろうか？

Web指向というのは聞いたことがなかったんだけど、分散化され、メッシュ上にリンクされたリソースをコードが扱う、というモデルらしい。

[/メモ]

これらの進化は、古いものを置き換えてきたというわけではない点が重要。新たに登場したパラダイムでの開発には、以前にパラダイムも必要になる。組み合わせて使うことが必要。

[メモ]

フレームワークやミドルウェアの登場で開発はどんどん簡単になっているはずなのに、なぜか難しく感じる理由は、これである程度説明できるのかもしれない。抽象の破れとあわせて説明すれば、直接開発に関わらない人が「うまく開発することが、なぜいまだに難しいのか」を理解する助けになるだろうか。

[/メモ]

モデルをどう作るか？

システムはさまざまな視点からのモデル化することになるが、どのようにすればうまく表現できるのか？

# モデルの話再び。個人的にはここが最重要トピック。

問題をうまく分類し、分割することが重要。単一のパラダイムではうまく対応できないため、マルチパラダイムで対応する。これから、いくつかのパラダイムとその問題点を見ていく。

■ オブジェクト指向

クラス決定に一意性がなく、属人的であることが問題とみなされる。このせいで、手続き指向への回帰が起こっているケースが多々見られる。

（個別UCの）要求によってクラスの構造を変えてはならない。要求の実現ではなく、保守性を目的としてクラス構造を取る。

OOには多くの制約があり、これを乗り越える・補完するためにさまざまなパラダイムが考案・導入されつつある。

■ アスペクト指向
可変性にフォーカスした技術。メモで前述。このあたりから全部、ものすごいさらっと紹介していく流れに。

[メモ]
可変性というのは、ドメイン工学やマルチパラダイムデザインの用語で、システム・もしくは概念の変わりうる部分のこと。AOPが可変性にフォーカスした技術である、ということは、システムの変わりうる部分をアスペクトとして実装することが意図されている、ということだろうか。あまりそんな風に使ってないような気がするが。
ユースケースをアスペクトとして扱うのであれば、この言説に合致するんだけど、あってるのだろうか。
[/メモ]

■ サブジェクト指向（Subject Oriented）
再利用にフォーカスした技術らしい。こちらもさらっとした紹介程度で終了。

[メモ]
どんなものかもわからないので、Webで調べてみた。

サブジェクト指向プログラミング（Wikipedia英語版）：

サブジェクト指向プログラミングは、下記をサポートするようなプログラミング手法を指す。
サブジェクトの組み合わせによるオブジェクト指向システムの構築
システムの、既存サブジェクトおよび新規サブジェクトの組み合わせによる拡張
サブジェクトの組み合わせによる、システムの統合
サブジェクトの組み合わせがもたらす柔軟性によって、OOプログラムの開発やモジュール化に新たな機会がもたらされる。
広義のサブジェクト指向は、システムのサブジェクトへの分割や、サブジェクトを正確に組み合わせるためのルールの記述を含む。サブジェクト指向はOOPを補完し、以下のような問題を解決する。
OOPが大規模システム開発に用いられた際に発生する問題
OOPが、相互運用可能または統合されたアプリケーションスイート開発に用いられた際に発生する問題
SOPは、サブジェクトを作る事で、プログラマの認知能力にまつわる問題も解決しようとしている。サブジェクトはその出自からして、アスペクトと大きくは違わない。アスペクトは初期に、主としてコンパイルタイムに先立ってソースを組み立てるようなコードウィーバーのコンセプトに労力を向けていたが、SOPパラダイムはクラスの組み立てに多くを依存している。

なんのこっちゃ。雰囲気からすると、オブジェクト指向システムをクラスとは別の構造（サブジェクト）に分解し、サブジェクトを組み合わせることでオブジェクト指向システムを構築する、というコンセプトらしい。これも、補完的な構造（横の構造）を導入するためのパラダイムのようだ。

Hyper/J：
IBMによる、サブジェクト指向開発環境のJava実装らしい。暇があれば使ってみようかな。

DCIA：
講演の中で出てきた、サブジェクト指向アプローチか製品のようだけど、調べてもよくわからなかった。
[/メモ]

■ DDD（Domain Driven Design）

ビジネスのモデルをそのままソフトウェアクラスの構造に反映する。ユースケースの要求はサービスとして実現することで、ビジネスのモデルを安定にできる。

[メモ]
DDDによる本来のサービスの定義は、ビジネスで認知されている純粋な手続きや、複数のドメインクラス（Entity/ValueObjet）にまたがる処理をサービスに記述することになっている。
結果的にユースケース要求がサービスに実装されることになることもあるかもしれないが、本来のDDDの意図とは少し違っているように思える。DDD本で紹介されている本でも、ユースケースによって徐々にドメインクラスを変更していっているしなぁ。このあたりはできれば直接質問したかったんだけど、できずじまい。
[/メモ]

■ フィーチャ指向

可変点をフィーチャとして分析する。フィーチャ指向は、静的・コンパイル時バインディングが基本だが、これを動的にバインドできるようにしたものとして、コンテキスト指向というものがある。

かなりさらっとした紹介で終了。もう少し掘り下げて調べてみようと思ったけど、それはそれで膨大になりそうなので今回は省略。それにしても、フィーチャ指向のフィーチャって可変点だけだっただろうか？システム自体を概念とフィーチャで分析していく手法で、フィーチャの分析として可変かどうかを調べていたような記憶があるんだけど、間違っているかもしれない…。

■ セル生産方式
プロセスの抽象化と再利用らしい。さらっと終了シリーズ。

[メモ]
セル生産方式の解決する問題が、プロセスの再利用だとは知らなかった。簡単にしか紹介されなかったので、詳しいことはわからずじまい。書籍に期待。

[/メモ]

■ 関数型パラダイム
すべてが関数。クラウドの普及によって、中〜長期的には重要になってくるはず。

以上紹介してきたように、パラダイムは多数存在しているが、いずれにしろドメインに特化したパラダイムを選ぶのが重要。

妥協のない意思決定の方法

目的－手段の階層を意識するのが重要。手段のレベルでトレードオフが発生した場合には、同じレベルでは選択できない。目的−手段階層をさかのぼり、上位の階層でトレードオフを解消できないか（まったく別の手段を取る事ができないか、目的レベルで考えると手段の1つは不要になるのでは、などなど）を考えることで、妥協せずに意思決定することができる。

[メモ]
これ重要っすよね。事業戦略もまったく同じで、経営レベルから自分へいたる意思決定のパスが明示されていないと、現場レベルでは判断つかないことが多い。
[/メモ]

萩原さんの夢とメッセージ

プログラミングやインフラなどの実装に近い部分や、ビジネスや要求よりの部分は注目され、色んなことが試されているが、その間の設計の部分は意外と注目されておらず、軽視されているとも言える。ここにはまだまだ向上の可能性があるので、ここをきちんとやっていくということを夢として持っている。

みなさんへのメッセージとしては、ユニーク性を持つ、ということをすすめたい。ユニーク性のない仕事は、どんどん代替可能な人材に置き換えられ、価値も下がってしまう。ユニーク性を持てば代替は不可能となり、価値を発揮できる。ぜひユニーク性を持ってください。

雑感
個人的には、一番ストライクゾーンに近かったセッション。ここ1年ほど興味を持って調べていた内容に非常に近く、自分の考えを確認しつつ新たな試みに触れることができた。もちろん、より良い整理のヒントも得ることができた。
内容は全体に浅く広くだったとはいえ、モノの見方を紹介するという意味ではどんな人にとっても刺激になるセッションだったんじゃないだろうか。書籍「アーキテクトの審美眼」も発注したので、届いたら改めて深く掘り下げてみたい。

目次：
QCon Tokyo 2009に行ってきた

Yコンビネータにトライ

2009-04-17T20:33:00.009+09:00

via おとうさん、ぼくにもYコンビネータがわかりましたよ！

きしだんさんすごいっす。自分も学習のために、ラムダの復習も兼ねつつJavaScriptでトライしてみる。独学で適当にやってるので間違いも多数あると思いますが、ご容赦を。

ラムダ
ラムダ式は、関数の表現形式みたいなもので、おおよそfunction式に相当する。引数が複数あるのが違うところだけど、この話は後で解決する。（非形式的な）ラムダ式ってこんなもの。

λx.x*2

このラムダ式は、xを受け取ったら2倍して返す関数を表している。
最初は読むのに（特にλ記号が複数になった場合に）とても苦労したんだけど、引数を「λ」と「.」で挟み込む形で表現した関数だ、と考えるとずいぶん読みやすくなった。これをJavaScriptで表すと…

function(x) { return x * 2 }

こうなる。ラムダ計算の体系では、計算のすべてをラムダ式であらわす。ラムダ式は関数なので、計算のすべてを関数であらわすということだ。ということで、JavaScriptから余計なものをそぎ落としていきましょー。

カリー化
さっきも少し出てきたけど、もともとのラムダ計算体系ではすべての関数は1引数関数として扱う。一般にラムダ計算体系では…

f(x, y) = f(x)(y)

が成り立つ（理屈は省略）ので、多引数の関数はすべて1引数の関数に変換できる。こうすれば、多引数のことあんま考えなくてもいいから、世界がシンプルになる。たぶん。
で、カリー化とは、上記左辺の f(x, y) から f(x)(f) への変換のことを言う。Haskellとかで関数の部分適用の話が出てくるけど、Haskellの関数はすべてカリー化されている（1引数関数である）ので、部分適用といっても単に、順番に関数適用しているだけなんだと思う。

JavaScriptの関数は引数を複数取ることができるが、上記の法則によって、必ず1引数の関数に変換できる。関数や引数が特定された形であれば、特別な機構がなくてもカリー化はできる。

function func(x, y) { return x + y }

この関数を引数3でカリー化（＋部分適用）したければ…

curried_func = function(x) { return func(x, 3) }

こうすればいい。
# これをカリー化とか部分適用というかどうかは甚だ疑問だが、とりあえずイメージってことで…。
でも、これだと関数や引数が変わるたびにガリガリコードを書かなければいけないので、嬉しくない。どんな関数や引数でもカリー化できる機構があれば楽ちんだ。
JavaScriptには関数をカリー化する標準的な機構は用意されていないんだけど、カリー化する関数を作る事はできる。カリー化関数の実装にはいくつかバリエーションがあるんだけど、ここではわかりやすさを重視して nanto_vi さんのカリー化関数を使わせていただくことにする。

function curry(f) {
 if (f.length == 0) return f;
   function iterate(args) {
     if (args.length >= f.length)
       return f.apply(null, args);
     return function () {
       return iterate(args.concat(Array.prototype.slice.call(arguments)));
     };
   }
 return iterate([]);
}

これを使えば、どんな関数でもカリー化できる。元ネタの例を拝借して、2引数の以下のような関数をカリー化してみる。

function add(x, y) { return x + y }

curry関数を使って…

var curried_add = curry(func(x, y))

これで、1引数関数になった。

curried_add(1)(2)
> 3

OK。間にごちゃごちゃはさまるものの、関数は1引数だけ考えればよくなった。また1つ、世の中が単純になった。本当か？

ラムダで条件分岐
じゃ、次は1引数関数で条件分岐ができるようにしてみる。これができれば、if文なんていう特別な構文を用意しなくても if文相当のプログラムが書けるわけで、世界は単純なまま進行する（JavaScriptで言うなら、if文を忘れ去ることができる）わけだ。よーし、じゃあif関数みたいなものを作るぞ！こんな風に動けばいいよね。

myIf (b)(exp1)(exp2)

…しかしmyIfで全部やろうとすると…

var myIf = curry(function (b, exp1, exp2) {
 return b ? exp1 : exp2
}

結局は内部に if文相当のもの（ここでは3項演算子だけど）が出てきてしまう。余分なものをそぎ落とすのが基本方針なので、やはりきしださんと同じアプローチを取る。
関数はすべて1引数なので、if関数が条件として真偽値をとらなければならないなら、真偽値自体が実行する関数を選ばなくてはならない。とうわけで、真偽値を関数として定義する。ラムダ式で書くとこんな感じ。

true=λx.λy.x
false=λx.λy.y

trueは、xとyを順に適用すると、xを返す関数。falseは、xとyを順番に適用するとyを返す関数として定義している。JavaScriptで書くと、こんな風になる。

var myTrue = curry(function(x, y) { return x })
var myFalse = curry(function(x, y){ return y })
// trueやfalseは予約語だから使えない

さて、条件分岐を書いてみよう。せっかくだから右の扉を…じゃなくて if っぽい関数を書いてみよう。全然型安全じゃないのがアレな感じだけど、とりあえず気にしない。

var myIf = function(x) { return x }
myIf(myFalse)(0)(1)
> 1

条件分岐できた。一応 (my)True も試しておく。条件分岐後に関数が実行されるようにもしてみる。

myIf(myTrue)(curried_add(1, 2, 3))(10)
> 6

OK。なんかカッコだらけなんですけど…。言語はシンプルだけど、世の中はどんどん複雑になっていっている気も。

さて、今のままだと、JavaScript の bool値はまったく使えない。ifを忘れ去るんだし、別になくても問題ない（というかなくしたい）んだけど、一応 JavaScript の bool と myTrue/myFalse/myIf をブリッジするための関数も用意してみる。

var bool = function(b) { return b ? myTrue : myFalse }

myIf の JS boolean バージョン。

myIf(bool(true))(curried_add(1, 2, 3))(10)
> 6

OK。振り返ってみると、真偽値自体を

Trueの場合は1番目の式を評価する関数
Falseの場合は2番目の式を評価する関数

このように定義することで条件分岐を可能にする、というアイディアだったわけですね。たぶん。

ラムダでループ
やっと本題にきたよ！さて、世界をシンプルに保つために、今度は関数でループできるかやってみよう。関数だけでループするためには、再帰を使えば良いよね。
フィボナッチを考えてみよう。とりあえずはプレーンなJavaScriptで。

function fib(n) {
 if(n < 2) { return n }
 else { return fib(n - 1) + fib(n - 2) }
}

ここでは、fib関数の中で自分自身（fib）を呼び出す事で再帰を実現している。普通に関数で計算を表現するだけなら、別にこれで十分だと思う。myIfで書き直したいんだけど、自然数とか比較とか（+とかも）作ってないからとりあえずこのまま ^^;

ただし、ラムダ計算の世界では自分自身を含む関数を定義することができない。せっかくなので、自分自身への呼び出しを取り除いて、ラムダ計算の体系に沿うように考えてみよう。

自分自身を呼び出すように記述できないのなら、自分自身を表す関数を引数に取って、その関数を呼び出せばいいのでは？と一瞬思ったが、結局それ、自分自身を呼び出してるよな…。

じゃあ、自分自身みたいだけど自分自身じゃない関数（fake_fibとでもしよう）が引数としてわたってきて、その関数を呼び出すことで間接的に自分自身が呼び出されるようにするのはどうだろう？JavaScriptで書くと、こんな感じ。

function fib(fake_fib, n) {
 if (n < 2) { return n }
  else { return fake_fib(n - 1) + fake_fib(n - 2) }
}

fake_fib(n - 1)呼び出しが、さらにfib(fake_fib, n - 1)を呼んでくれれば再帰が実現できることになるのでは？fibを g に、fake_fib を f にして簡潔に書きなおすと…

function g(f, n) {
 if (n < 2) { return n }
 else { return f(n - 1) + f(n - 2) }
}

こんな感じ。で、f(n - 1) が g(f, n - 1) に（1引数の世界で言えば、f が g(f) に）展開されれば再帰が実現できるはず。というわけで、展開するとg(f)になるような f、つまり

f = g(f)

となるような f を見つける、という問題に帰結する。このような条件を満たす f は一般的に「不動点」と呼ばれており、以下のようなラムダ式で表すことができることが知られている。

Y = λg.(λx.g(xx))(λx.g(xx))

これがいわゆるYコンビネータってやつらしい。
# このラムダ式がさきほどの条件を満たすことは、きしださんのところに書いてあるとおり、試してみればわかる。これをJavaScriptで書いてみると、

function Y(f) {
 return function(x) {
   return f(x(x))
 }(function (x) {
   return f(x(x))
 });
}

# ナンダコレハ…。
こうなる。これを使う形で、あらためてフィボナッチをJavaScriptでちゃんと書くと、こんな感じになる。

var fib2 = curry(function(f, n){
 if(n < 2) {return n }
 else {return f(n - 1) + f(n - 2)}
})

実際に呼び出すには、Yを使ってこんな感じで呼べばいい。

Y(fib2)(10)
> InternalError: too much recursion

しかし、こちらも同じく再帰エラー。まねっこしてZコンビネータを作ってみよう。

function Z(f) {
 return function(x) {
   return function(m) {
     return f(x(x))(m)
   }
 }(function(x) {
   return function(m) {
     return f(x(x))(m)
   }
 })
}

…なんかもう慣れてきた。呼び出し。

Z(fib2)(10)
> 55

えええ！動いちゃったよ！そりゃ動くように作ったけどさ！

で、これで何ができるかっていうと…自分自身を参照しなくても、再帰が書ける。だから、無名関数でも再帰が書ける。他にどんな良いことがあるかというと、相変わらずよくわからない ^^; ラムダ計算の体系に沿って計算を組み立てておくことで、何か良いことがあるのだろうか。

チャーチ数とかもやってみようと思ったけど、力尽きた。続く…かもしれない。

Google App Engineの料金体系が面白い

2009-04-16T21:32:00.013+09:00

社内でGoogle App Engineのミニ勉強会をやることになったので、技術者らしくAPIとかBigTableまわりとかやろうかなーと思って色々ドキュメントをあさっていたところ、思いがけず非常に面白いものを見つけてしまった。

それは、料金体系。たいていのGAE紹介サイトには、〜まで無料、以降〜みたいな形でさらっと書いてあるんだけど、思った以上に奥が深い。DoCoMoやソフトバンクモバイルより奥が深い。しかも、この料金体系によってアプリケーションの作り方にまで影響が出てくる可能性がある。こうなってくると、JPAとかJDOとか開発環境とか紹介するのなんて馬鹿馬鹿しくなってしまった。Google App Engine勉強会、って名目で人呼んどきながら、ずーっと料金の話ってありだろうか？なしだろうなぁ。

基本的な概念、リソースとクォータ
さて、Google App Engineには利用可能な資源、リソースが定義されており、リソースにはクォータ（割当）が設定されている。逆に言えば、クォータが設定されているものがリソースであるとも言える。リソースには2種類存在し、固定的に割り当てられていて基本的にはクォータの上限が変更できないもの（Fixed）と、支払いによって上限を増やせるもの（Billable）がある。
ややこしいことに、Fixedのリソースのクォータは、Account保持者が支払い可能状態になると上限が増える（一方Billableなリソースのクォータは、実際に上限を増やすように設定しないと増えない）。

また、クォータにも2種類あり、日ごとの上限値と、分ごとの上限値が設定できる。分ごとの上限値は、日ごとに割り当てられたリソースが急速に消費されつくし、日のうち大部分が稼働不可能になる...といった状況を避けるために設定できるようになっている。

リソースの枯渇と補充
リソースは、クォータの上限値から消費されていき、Pacific Timeの0時にリセットされてクォータの最大値まで補充される。
リソースが枯渇した状態で枯渇したリソースにアクセスしようとした際には、例外が発生する。リソース枯渇に適切に対応しようとする場合、適切にこの例外をハンドリングしなければならない。たとえば、ユーザーにそのサービスが利用不可能であることを通知したり、管理者にメールで通知する等の事後処理が考えられるだろう。これが、アプリケーション設計に影響を与える要素の1つである。

リソースの種類
以下でリソースを紹介するが、支払いによって上限を増やせるものは、オリジナルのドキュメントに従って[B(illable)]と表記する。また、参考のために、無料かつ支払い可能でない状態での日ごとの上限値を並記する。

■ リクエスト系

リクエスト数（HTTPSを含む）: 1,300,000 requests
出力帯域総数[B]（HTTPSを含む）: 10 gigabytes
入力帯域総数[B]（HTTPSを含む）: 10 gigabytes
CPU時間[B] : 46 CPU-hours

CPU時間はデータストアで使った時間も含む。外部サービス呼び出し等による待機時間は含まない。また、CPU消費時間の目安として、以下のようなものがあげられている。

データストアへの書き込みは、読み込みに比べておよそ5倍のCPU時間を使う
インデックス更新が必要な書き込みは、そうでないものよりCPU時間を使う
Entityのプロパティが多いほど、読み込みでも書き込みでもCPU時間を使う
Queryは常にIndexを使うため、Queryはほとんどの場合に同じくらいのCPUしか使わない
ただし、フェッチが必要な場合は追加のCPU時間が必要になる

リクエスト系のリソースの特筆すべき点は、これらのリソースが不足した場合にはリクエストのハンドリングを開始すらできないため、ユーザーにはHTTP Status403が返されてしまう、という点だ。

■ データストア系

データストアAPI呼び出し回数 : 10,000,000 calls
格納データおよび関連インデックスのサイズ[B] : 1 gigabyte
APIに送信されたデータのサイズ : 12 gigabytes
APIから取得したデータのサイズ : 115 gigabytes
データストアに使ったCPU時間 : 60 CPU-hours

■ メール系

メールAPI呼び出し回数 : 7,000 calls
メール送信先アドレスの総数[B] : 2,000 recipients
送信メール総数 : 5,000 mails
メッセージボディのデータサイズ総数 : 60 megabytes
送信添付ファイル総数 : 2,000 attachments
送信添付ファイルデータサイズ総数 : 100 megabytes

■ URLフェッチ系

URLフェッチAPI呼び出し回数 : 657,000 calls
URLフェッチデータ送信サイズ総数 : 4 gigabytes
URLフェッチデータ受信サイズ総数 : 4 gigabytes

■ Image操作系

Image操作API呼び出し回数 : 864,000 calls
APIへのデータ送信サイズ総数 : 1 gigabytes
APIからのデータ受信サイズ総数 : 5 gigabytes
変換実行回数 : 2,5000,000 transforms

■ Memcache系

MemcacheAPI呼び出し回数 : 8,600,000 calls
APIへのデータ送信サイズ総数 : 10 gigabytes
APIからのデータ受信サイズ総数 : 50 gigabytes

■ デプロイ

デプロイ回数 : 未定義

リソース[B]の単位あたりコスト

出力帯域総数：1 gigabytes あたり約12円
入力帯域総数：1 gigabytes あたり約10円
CPU時間：1 CPU時間あたり約10円
格納データサイズ：1ヶ月あたり1 gigabytesで約15円
メール送信先アドレスの総数：1アドレスあたり約0.01円

安…！いよね？

アプリケーション開発への影響
こんな感じで、明確に上限回数やリソース追加のコストが明示されたら、アプリケーション開発にはどんな影響があるだろう？まず、テストが変わるんじゃないだろうか。従来も行われてきたであろう、リソースの上限を突破しないか、という観点での試験に加えて、費用対効果を考慮した試験がより厳密に行われるようになる可能性がある。なにせ、無駄にCPUリソースを消費した処理を作ると、明確に費用として跳ね返ってくるようになるのだ。そうなると、富豪プログラミングにかわり、効率の良いアルゴリズムが再び脚光を浴びるようになるかもしれない。つまり、（今後の料金変動や景気、規模にもよりそうだが）今よりも省エネな設計が求められるようになる可能性があるんじゃなかろーか。

その他雑感
こうして、使用リソースに応じた料金表を見ていると、携帯電話料金表や電気料金表を見ながら最安のプランを考えているときと同じ感覚をおぼえて「あぁ、本当にユーティリティコンピューティングの時代が来たんだなぁ」と思いがけず実感してしまう。
と同時に、CPU消費時間で費用が変わるような世界は、よくよく考えると、本や口伝えでしか見聞きしたことがないような、コンピューターリソースが貴重だった時代に似ているような気もしてくる。マシン使用時間に応じて料金がかかっていたらしい、自分の知らない時代。
トレンドは螺旋を描いて戻ってくるとはよく言ったものだ。

GAE/Jにいまいち惹かれない

2009-04-15T00:12:00.007+09:00

QConでのGregorのセッションを受けて、Google App Engine熱が再度高まってきた。ってわけでGAE for Javaをさわってみたのだが、イマイチぐっと来ない。

Webインフラが素のServletまで退行。
Webフレームワークが手探り状態。もう少ししたら一通りそろってくると思うけど。
久しぶりにさわったJavaが、予想以上に柔軟性がなくて萎えた。
現状AOPも使えないんじゃあ、のっぺり感満載…。Moduleとかtraitとかないんすか。
GAE/Jの永続化メカニズム（JDO/JPA）がどっちもいまいち好きになれない。
Scala使おうかと思ったけど、JDO/JPAのエンハンスとか考えると開発環境を快適にするのがめんどくさそうで萎えた。Actorは当然使えない。
JDO/JPAみたいな形だと、BigTableの柔軟性（行ごとに違うデータ項目を持っていてもOK）が生きてこない気がした。

てな感じ。これなら、（少なくともしばらくは）Python版でよくないか？てかPython版のがよくないか？お下がりとして頂いた「初めてのPython（第2版）」をぱらぱら読んでると、関数系が結構充実してる（lambda式とかリスト内包表記とかジェネレータとか）みたいで、使ってて面白そうだし。でも、なんか世の中に取り残されているみたいで寂しい。もしかしてSIer社員失格か？

しばらくはPythonでGAE使っていこうかな。世の中が落ち着いてきたらJavaも使ってみればいいし。

JavaScript: The Good Parts

2009-04-14T23:20:00.003+09:00

今更だけど見てみた。

1時間以上あるのに軽く引くが、本当に重要なのは30分程度。残りはこの人の経験談や、JavaScript界隈の近況、質疑応答。
この人のプレゼンは、皮肉がきいていて面白い。とりあえず、わかった範囲でメモっておく。

JavaScriptの現状

いまだに最も誤解された言語
誤用しては怒っている人多し
最もすばらしいアイデアから、もっともひどいアイデアまで含まれている
こんなに幅の広い言語はほかにない
コンピュータ科学者からカット＆ペースト厨まで、どの言語よりも幅広いスキルの人が使っている

JavaScriptへの不満

ブラウザプログラミングはひどいもんだ。 => まったくその通り
十分な速度が出ない。 => 現在ではすでにJSではなくDOMの問題。今はランタイムは十分速い。
失敗の積み重ねだ。 => Javaが完全に失敗した環境でうまくやりつづけているだろ？

影響を受けた言語
Self：

prototypal inheritance
dynamic objects

Java：

syntax
conventions

Scheme：

lambda
loose typing

Perl：

regular expressions

Schemeさんパネェッス。
loose typingを問題視する人もいるが、テストすればよい。テストは他の言語でも必要　型チェックだけじゃわからないことは多い。Javaのシンタックスはあんまよくないね。

Bad Parts

グローバル変数。
+ をaddと結合に使う。Javaもやってるが、Javaは強い型つけを持ってるから問題ない。
セミコロン。初心者向けにCのシンタックスを導入したが、予期しないエラーがおきたりする。後述。
typeof。役に立たない。なんでもObjectになってしまう。
with と eval。evalは一番誤用されている。evalを使ってるときは、なんかまずいことをやってる。
まがいものの配列。本来はメモリを区切ってすばやくアクセスできるが、JSのはこういうのじゃない。実際はハッシュテーブル。
== と !=。Cから受け継いだ問題の多いシンタックス。
false, null, undefined, NaN。たくさんありすぎ。

どうなるかわかるだろうか？

'' == '0' // false
0 == '' // true
0 == '0' // true
false == 'false' // false
false == '0' // true
false == undefined // false
false == null // false
null == undefined // true
"¥t¥r¥n" == 0 // true

常に ===を使うべき。==は（暗黙の型変換がカオスすぎるので）使ってはいけない。本当は間違いだけど、偶然うまくいくケースもある。

// 間違い
var obj = myObject[name]
if (obj == null) {
....

// 正解
var obj = myObject[name]
if (obj == undefined) {

単独では良い機能が、関連するとがうまく動かないケース

Objectは他のオブジェクトを継承できる
関数はオブジェクトのメンバになれる
for..in文は、継承した関数とデータメンバを区別しない

=> 全然嬉しくない挙動

実際、for .. in は問題が多い
// 浅いとか深いとか、よくわかんなかった

Bad Heritage
ブロックのないステートメント：

if (foo)
bar();

expression statement：

  foo;

Floating point arithmetic：

  0.1 + 0.2 !== 0.3
// JSの問題というわけではないんだが

++ and --：
バッファオーバーランとか色々問題があるらしい。コードもトリッキーになる。

switch：
Javaと同じ問題。falling through

Good Parts
Lambda：
パワフルで安全

Dynamic Objects：
非常にパワフルで使いやすい

Loose Typing：
良い。クラスとかいらない。

Object Literals：
とてもよい。JSONとか。

Inheritance
コードの再利用。クラスベースとプロトタイプベースがある。
よく理解されていないが、プロトタイプベースはとてもパワフル。

Prototype Inheritance
Classは不要、オブジェクトから継承。
他のオブジェクトへのリンクを持ち、委譲する方法がある。

var newObject = Object.create(oldObject);

if (typeof Object.create !== 'function') {
 Object.create = function(o) {
   function F() {}
   F.prototype = o;
   return new F();
 };
}

new はクラスベースっぽい記法を提供しているが、あまりよろしくない。コンストラクタ関数を呼ぶときにはnewが必要だが、忘れるとグローバルオブジェクトが変更されてしまう。そして、その際にはまったく警告が出ない。私は危険だから使わない。

Global変数いくない

var names = ['one', 'two'....]

functionでスコープ制限したらどうだろう？

function hoge(n) {
 var names = ['one', 'two'...]
 return names[n]
}

=> 遅い。呼び出しごとに配列が初期化されてしまう。

クロージャを使おう！

var digit_name = function() {
 var names = [...]

 return function(n) {
   return names[n]
 };
}

=> 無名関数のスコープ内で一度だけ初期化される。遅くない。これは、コンストラクタパターンとして一般化できる。といいつつ、次のスライドがModule Patternなのはなぜだ。

Module Pattern

var singleton = function() {
 // 無名functionのスコープにとじこめられる
 var privateVariable;
 function privateFunction(x) {
   ..privateVariable...
 }
 // Objectリテラルで無名関数のスコープを使うように定義
 return {
   firstMethod: function (a, b) {
     ...privateVariable...
   },
   secondMethod: function(c) {
     ...privateFunction()....
   }
 };
}();

これは、（ようやく）コンストラクタに応用できる。

Power Constructor
1. Make an object.

Object literal
new
Object.create
call another power constructor

2. Define some variables and functions
これがプライベートメンバになる
3. 特権メソッドでobjectを複製する
4. 作ったobjectをかえす

コードで見てみると...

function myPowerConstructor(x) {
 var that = otherMaker(x);
 var secret = f(x);
 that.priv = function() {
   .... secret x that ....
 };
 return that;
}

コーディングスタイル

return {

}

と

return
{

}

どちらがいいか？これは、感情的な宗教論争ではない。少なくともJSに関しては。

return
{
 ok: false
}

このように書いた場合、何も返らない。これは、returnの後ろに暗黙的にセミコロンが挿入されるから。

return;
{
 ok: false
}

JavaScriptにはブロックスコープない。

ok: false

はラベルだとみなされる。

return;
{
 ok: false;
};

こうなるということ。どのみち、return以降は到達しない文。

ビューティフルコード
JSLint使いなさい。Bad Partsを避けるように強制してくれる。注意しておくが、これを最初に使うと凹むことは請け合い。

他の良い点
安定してるぜ！1999からデザインがかわってないのだ。

標準化動向とか質疑応答とか省略。あー…うん。1度Youtubeの動画を貼ってみたかっただけなんだ…。

大規模ウェブサイトのベストプラクティス－eBayでの事例－

2009-04-13T14:07:00.011+09:00

分量がめちゃめちゃ多かったので、あまりメモってない ^^;

ほとんど「大規模サイト構築のノウハウ全部見せます！－全部で20以上あるよ！－」みたいなノリだったので、とても全部メモることはできなかった。プレゼン資料欲しいです。

eBayシステムのプロファイル概略

トランザクションデータは2ペタバイト
DWH用データは50ペタバイト
1日あたり48億回のSQL実行

ペタバイトとか、もう多いか少ないかもわからん。

大規模システムの原則

ということで、eBayのシステム構築の原則。

Partition Everything
Asynchrony Everywhere
Automate Everything
Remember Everything Fails
Embrace Inconsistency

なんだか清々しいです。

Partition Everything

分割方法は、データ、負荷、使用方法の特徴など、色々なものがあげられる。分割の動機としては…

Scalability
Availability
Manageability
Cost

このような感じ。PartitionとAvailabilityとは、Partitionによって故障箇所を局所化することでAvailabilityを向上できる、という点で関連する。PartitionとCostとは、Partitionによって問題を細分化することで、price/performance比がベストの点を選択できるようになる、という点で関連する。特に、Availabilityを重視している印象を受けた。

eBayでは、いくつかの方法でシステムを分割している。

■機能による分割（処理）

Selling
Search
ViewItem
Bidding
Checkout
Feedback

■機能による分割（データ）

User
Item
Transaction
Product
Account
Feedback

■水平的な分割

ノード分割＋ロードバランシング
データをアクセスパスにしたがって分割（RDBのパーティションのことだと思う）

また、Partitionのため、セッションステートはアプリケーションティアに保持しないようにしている。CookieやURL、DBに持っているらしい。この辺は王道。

Asynchrony Everything

非同期化のメリットは…

ピークロード（最大負荷）ではなくアベレージロード（平均負荷）をターゲットにリソースを配分することができる点
ユーザーが許容可能な時間を越えて、リクエストを処理することができる点

# 他にもいくつかメリットがあったけど、個人的に重要だと思ったのだけなんとかメモ ^^;

非同期化の方法には、キューイングやマルチキャストメッセージがある。

eBayで採用しているキューでは順序性は保証していないが、メッセージ自体にはデータは入れず、イベント通知を受けた側がその時点で正しいデータを読みに行く（Read Back）ことで整合性の取れた処理を行えるようにしているらしい。

マルチキャストメッセージは、商品情報などのデータがアップデートされた際に、サーチエンジンのインデックス更新を通知する場合などに使われている。Feed Daemonというプロセスが定期的にデータ更新をポーリングしており、更新があった場合（eBayの場合、ほぼ確実にあると思うが）に各サーチエンジンにマルチキャストメッセージを送信する、という形を取っている。

Automate Everything

興味深い例として、ユーザーの振る舞い（サイト上でどのように行動したか）情報を収集し、それに応じてシステムを最適化する、という一連のアクティビティを自動化している例が紹介された。

収集したデータをもとにメタデータを更新し、システムがその振る舞いを変えるところまで自動化されているのが面白い。データ収集や、分析のネタ作りの自動化くらいまでは結構やってると思うんだけど、ここまでやっているのは珍しい。いいアイデアのヒントをもらった。

Remember Everyghint Fails

システム上のすべての変更は、すべてもとに戻せるようにしているらしい。これは、データだけではなく、システム機能に対する変更にもあてはまるようで、すべての機能はコンフィグでON/OFFが切り替えられるそうだ。データ更新に対するロールバックをどう扱っているかに興味があるが、それは次の「Embrace Inconsistency」で扱われるトピックなのだろう。

また、Graceful Degrationも可能らしい。まぁ、このレベルだとある意味当たり前と言える。

Embrace Inconsistency

ここで、満を持して（？）CAP Theoremが登場。このセミナーで3回目。はじめて、CAPの正確な定義がスライド上に登場する。が、はやすぎてメモれず ;-(

C : all clients see the same data even if system ...
A : all clients will get a response even if system failure exist...
P : 時間切れ ;-(

# おそらく、AmazonのCAPの定義と大差ないはず。でも、誰か知ってたら教えてください… ;-(

さて、ここでの基本的な主張は、もうおなじみ「Consistencyは"あり"か"なし"かの2者択一ではなく、Immediate ConsistencyとNo Consistencyの間に多数のConsistencyレベルがスペクトラムのように存在する」というもの。

-----------------------------------------------------------

Immediate <------- Eventually -------> No Consistency

Bids/Purchase Search Engine/ Preferences

Billing System

-----------------------------------------------------------

金融システムにおいてすら、必ずしもImmediate Consistencyが必要とは限らない。ちなみに、eBayでは分散トランザクションはまったく使っていない（これが噂のTransactionlessか）。そのかわり、DB操作の順序を厳密に決定することで、システム全体の整合性を高めている。

# ステートマシンを使っている、という発言もあったけど、分析に使っているんだろうか？

最後にもう一度、重要なことを繰り返す。

Partition Everything
Asynchrony Everywhere
Automate Everything
Remember Everything Fails
Embrace Inconsistency

清々しいですね。

雑感

このセミナーで一番中身が濃かったのではないだろうか。大規模システム構築のパターンとして、本が一冊出せそうなくらいの内容だった。それだけにメモも難しく、セミナー資料の公開が待たれるところだ。

目次：
QCon Tokyo 2009に行ってきた

ビューティフルコード

2009-04-13T13:20:00.007+09:00

Matzのビューティフルコード。講演内容は、少し前に開催された「まつもとゆきひろが語る『ビューティフルコード』×『プログラマ35歳定年説』」と同じだと思われる。

というわけで、包括的な内容は以下を見ればとてもよく書いてあるとオモイマス。

雑感

全体的には、教科書的な内容を集めた話になっているなぁ、という印象。以下のような話はなかなか興味深かった。

Brooksの生産性不変の法則（どんな言語でも、プログラマが生産できる単位時間あたりLOCは変わらない）から考えても、表現力の高い言語が求められている、ということ。
コードはアート、プログラマはアーティストとしての自覚を持つべき。アーティストの条件とは、自覚、自発である。
アートはビジネスとして成立しないという意見があるが、デザイナなど、アートとビジネスを両立させている職業はいくらでもある。

一方、疑問点も多数。

ソフトウェアは一品モノだし、プログラミングは設計なので、ソフトウェア工場というアイデアは間違っている、という話があったが、ソフトウェアの性質は一品モノか大量生産かの2択ではなく、この間の多様な中間点も取りうるはず。自分の経験上、大量生産に比較的近いようなソフトウェア開発も確かに存在するし、プログラミングが設計（＝コードが設計書）だとしても、設計書同士が似通っている場合にはより効率的なアプローチがあり得るだろう。設計書同士の類似点が大きければ大きいほど、工場のメタファが有効になるかもしれない。ソフトウェアの種類を限定せずにこのような主張を行うのは、ポジショントークにしてもやりすぎであるように思える。
プログラミング言語は水鳥のようであるべきで、現実の複雑さは言語が引き受ければいい、という話があったが、現実の複雑さの多くは汎用言語では引き受けられないのではないか？複雑な現実を分類し、それぞれの分類に特化した言語を作ることで複雑さに対応する、というアプローチ（つまりDSL）が主流になりつつある。個人的には、現実の複雑さに対応するために汎用言語が目指す方向は、言語が複雑さを引き受ける方向ではなく、言語の表現力を増す（＝複雑な現実を表現できる可能性を増やす）方向が良いのではないかと思う。まんま内部DSLのホスト言語のイメージだけど ^^;
Rubyは（動的型付けやクロージャ、オープンクラスやメタクラス、Mix-Inなどによって）かなり表現力が高い。これが、内部DSLのホストとして好まれる大きな理由の1つじゃないかと思う。
アルゴリズム記述用擬似言語みたいなものを目指す、と言っていたけど、それはアルゴリズムに特化しているだけで、アルゴリズムは書きやすくなるかもしれないけど他の部分に影響が出る可能性があるのでは？

自分のような言語のシロウトがMatzに疑問を持つのもアレなんですが、このあたりの疑問は解消されないまま今に至る。

目次：
QCon Tokyo 2009に行ってきた

Programming the Cloud -the Internet as Platform-

2009-04-13T01:20:00.008+09:00

イケメンGregor Horhpeによるクラウドセッション。この人は、Martin Fowler SignitureのEnterprise Integration Patternsの著者の一人でもある。今回はEIPではなく、BASE〜CAP Theorem〜Google App Engineといったあたりのお話。

クラウドの良い点、悪い点
アーキテクト（の関心事）にとっては、夢を実現するコンセプト。

疎結合
拡張性
標準への準拠
耐障害性
無制限のコンピューティングパワー
ユビキタス

しかし、開発者にとっては悪夢の発現。

No Call Stack
No Transaction
No Promises
No Certainty
No Ordering Constraint

# No Certaintyがよくわからず、訳せなかったので全部英語 ^^;

[メモ]
このあたりは、パネルディスカッションでGregorが話していた、ランタイムを考慮したテストの重要性が増すだろう、という話と対応しているようだ。
（ACID）Transactionがない点は、システム特性や方針レベルでは（CAP TheoremやBASEモデルとして）わりと整理されてきているんだろうけど、アプリケーションレベルでの対応方法は別の課題として（少なくともしばらくは）残ることになりそうだ。この話は、少し後にスタバの例つきで出てくる。
順序性の保証がない点は、同じくプログラミングモデルの変革に関わる部分。この話も最後あたりにStatelessとStatefulの分離の話と絡めて出てくる。

ACIDコンセプトの移り変わり
以前のACID

Atomic
Consistent
Isolated
Durable

以前のACIDに合うように作ってみた、今日のACID

Associative（結合性）
Commutative（交換可能性）
Idempotent（羃等性）
Distributed（分散）

[メモ]
結合性や交換可能性は、並列化をすすめる上で非常に重要になってくる。関数型パラダイムにも通じる概念（ですよね？）。分散は並列化のために必要になってくるのだが、分散をすすめるとノード故障への対応が難しくなってくる。この際に効率よく回復するために、計算の羃等性が重要になってくる。計算が羃等であれば、同じメッセージを再送信するだけで回復できるからだ。

分散システムにおけるトランザクション
分散システムにおいて、特定のノードと通信できなかった場合、どうするか？2フェーズコミットが必要か？スターバックスを例に考えてみよう。

結論から言うと、スターバックスは2PCをやっていない。つまり、注文を受けてからコーヒーを作り、清算して、これらすべてを1トランザクションに…というような仕事のやり方をしていない。スループットを出すために、注文を受け付けたら、清算前にコーヒーを作り始めたりしている。
さて、この一連の流れで以下のようなマズいことが起きたらどうすればいいだろう？

この飲み物は嫌だと、顧客に却下/返品される
コーヒーメーカーが壊れる
顧客が支払えないことに気づく

顧客に却下された場合には、飲み物を作り直す（Retry）。コーヒーメーカーが壊れてコーヒーが提供できない場合、代金を払い戻す（Compensation）。顧客が支払えなかった場合、飲み物を捨てる（Write-off）。
このように、最初から完全を求めるのではなく、事後的に対処することで最終的な一貫性を保つようなやり方は、スタバだけでなく銀行のようなシステムにも当てはめることができる。例えば、日銀とバンク・オブ・アメリカが決済をするような場合、エントリを互いに送信しあう際には完全性を求めず、どこかのタイミングで突き合わせをすることで、エントリ送信の誤りを修正するようなことをしている。
# らしい。もちろん、本当かどうかは知らない。
ちなみに、このWrite-offというオプションは、システム開発でも特に忘れられがちな事後対処のオプションなので、もっと考えてもいいんじゃないか、というようなことも言っていた。

Googleの並列化への取り組み
みたいなタイトルで、MapReduceとかGFSとかBigTableとかの話が続いた。このあたりは有名な話ばっかりだったのでメモってない。Sawzallだけ知らなかったんだけど、これらのインフラを効率よく使うためのDSLらしい。

並列性を高めるための方法
いかにStatefulな部分をStatelessな部分から切り離すか、が重要。
例として、ファイル読み込みのようなものを考えてみる。ファイルを先頭から順に読み、一行ずつ処理していく場合、処理は何行まで進んでいるかの情報を利用可能で、処理のたびに位置情報が更新されていく形になるため、状態を持つことになる。これは、処理が位置情報を利用できるという意味で、Listに対する処理と考えても良い。
ここで、状態を持っている部分（ファイル読み込みの部分）をインフラ（ここではMapReduceだろうが）にまかせ、処理の部分はListではなくSet（集合は順序持っていないので）に対する処理とすることで、Statefulな部分とStatelessな部分を切り離すことができる。

こうすることで、Statelessな部分は並列実行できるようになる。しかし、Statefulな部分をデータ処理と切り離したことで、できないことが増えることには自覚的になる必要があるだろう。例えば、データ処理が状態を持っていれば可能な、連続して同じデータ内容の行を読み込んだ場合に誤入力としてスキップするようなことはできなくなってしまう。どんな妥協をしたのかを自覚しておくのは非常に重要。

Google App Engineのデモ
Java版の紹介とデモ。Hello, 東京！デモってやっぱり楽しいね。

雑感
拍手とともに終了。Gregorさんは話すのが好きなのか、セッションも楽しかった。
ホスト「それではいつものように、よかったと思った人は緑、まぁまぁかな、という人は黄色、いまいちかな、という人は赤を入れて...」
Gregor「Green！」
会場「ハハハハハ！」

内容的には、丸山先生の話のGoogle版といった感じかな。スタバの例がすごくわかりやすかった。自分が見たセッションで、唯一デモがあったセッションでもある。緑入れときました。

目次：
QCon Tokyo 2009に行ってきた

Spring in a Changing World

2009-04-12T23:41:00.006+09:00

Rod Johnsonのセッション。なんかマーケ色がわりと強かったので、あまりメモっていない。メモった範囲で。

ビジネス、技術の両面で変わる世界

JavaEEの失敗
よりシンプルな技術への指向
世界的な景気後退

今は、リーンなソフトウェア（目的にフィットしており、シンプル）が求められている。

技術の変化がとてもはやいため、マネージャは開発者に頼らざるを得なくなっている。開発者は今、かつてない力を持っている。

今まではSilicon Valleyがすべてのルールを決めていたが、これからは世界中に主導権が分散する。言語の問題はあるが、徐々に解決していく。

OSSはシンプルであり、リーンな開発につながる。今後のソフトウェアはこうなる。
巨大ベンダー => OSSコミュニティ
パワーポイント上でうまく動くソフトウェア => 開発者に支持されたソフトウェア

JavaEEは、単独ですべてを解決しようとしているが、これはリーンではない。

日本でのSpringの利用率は、他国と比べて高くないが、これはSeasarというプロダクトがあるからだと聞いている。しかし、長期のトレンドで見れば、他国と同じようになっていくだろう。

Next Spring
未だに残る、JavaEEの複雑性を取り除く。例えば、プロジェクトの開始時にプロダクトを選択し、動作可能なまでに整えるのはいまだに面倒。
新たな挑戦者（RoR, Django, Zend...）もいる。
.NETも色々やっている。.NETの利点は、MSが全体像を考えてドライブしている点。Javaにはそのような役割を果たすものがかけている。Sunは、EnterpriseJavaの方向性を示すのに失敗している。ただ、MSは独占企業なのが問題。
Spring Sourceがその役割を果たす。MSとは違い、オープンなアプローチで、統合された、アプリケーションのライフサイクル全体をカバーするものを提供する。

具体的には...

Tomcatへの支援を継続する
ツールスイートを作る
クラウド製品を提供する

雑感
開発者のエンパワーメント、という流れはいいなぁ、と感じたが、それとSpring Sourceの取り組みの結びつきがあまりぐっとこなかったな。個人的には、インフラや言語コミュニティの話より、アプリケーションやアプリケーションモデルの話がききたかった。

「技術の変化が早いから、マネージャは開発者に頼らざるを得ない」という下りは、必ずしもそうはなってない面があるように思う。技術の変化が早いことに、古い技術に固執することで対応しようとしたり、完全に無視することで対応する人は結構いる気がするんだなぁ。

目次：
QCon Tokyo 2009に行ってきた

クラウドの技術的な特徴について

2009-04-12T15:29:00.007+09:00

丸山先生のジェネラルセッション。内容的にはEric Brewerの資料（CAP Theorem/Eventually Consistent）をクラウドの立場から眺める、といったもの。

ScalabilityとAvailability
Scalabilityは、Scal-outによって達成できるが、Scale-outには技術的な裏打ちが必要であり、ノウハウの蓄積が必要。
Availabilityは、故障に対する適切な対処によって達成できるが、これには複製を作成する戦略（Replication）が基本になる。複製を作ってしまうと、同期の問題、すなわち一貫性に関する問題が発生する。

[メモ]
CAP定理で言うと、ScalabilityがおおよそPartitionに、AvailabilityがそのままAvailabilityに、一貫性がConsistencyにあたると考えてよいと思う。上記は、クラウドにおけるCAPの関係をわかりやすく説明してくれていると言える。

Partitionが必須となる背景
High-endコンピュータとCommodityコンピュータの価格性能比は、約1:33。経済的な選択をすると、必然的にPartitionを選択することになる。安いハードウェアはそれなりの能力しか持たないが、障害に強いソフトウェアが、安いハードウェアを役に立つものに変える。

[メモ]
ただし、よくよく考えると、Partitionと、Partition度合いを容易に増減できるかどうか（=Scalability）は、違った特性のようにも思える。セミナーでも、一口にクラウドといっても、リソースを動的に増減できるもの（Hot Scalable）とできないものとできないもの（静的にのみ可能、Scalable）がある、と言っている。

CAP定理とクラウド
これは、共有データを持つシステムにおいては、Consistency, Availability, Partitionの3つのうち、最大でも2つの特性しか持つことができない、というもの。
クラウドではPartitionは必須になるため、ConsistencyかAvailabilityのどちらかを選ばなければならない。…が、この選択はシステム全体に一律に適用しなければならないわけではない、というのが重要な点。単一のシステム内でも、カートに商品を入れる段階ではAvailabilityを優先し、注文の段階では一貫性を優先する、といったように、部分ごとに必要となる特性は変わる。

また、上記でAvailabilityを「優先する」と書いたように、AとCはどちらかを取ればもう一方が完全に失われる、というものではなく、AとCの配分には中間的な選択肢が数多く存在する。特に、Consistencyにはいくつかのレベルがあり、これには名前もつけられているようだ。以下、結城さんの翻訳サイトからの引用。

強い整合性(Strong consistency): 更新が完了したら, 続くアクセス(A, B, C いずれかによる) は更新された値を読み出す
弱い整合性(Weak consistency): システムは続くアクセスが更新された値を読みだすことを保証しない. 更新した値が返される前には様々な条件を満たす必要がある. 多くの場合, その条件は経過時間である. 更新された時刻から更新した値の読みだしを観測者に保証するまでの間隔を 不整合ウィンドウ(inconsistency window) と呼ぶ.
結果整合性(Eventual consistency): ストレージシステムは, オブジェクトに(不整合ウィンドウが閉じたあとも)最後まで変更が加えられなかったなら, 全てのアクセスが最後の更新値を読みだせると保証する. 結果整合性を実装する最もよく知られたシステムは DNS だ. 名前の更新は分散しており, 設定のパターンやキャッシュ制御の組合せで振舞いがかわる. クライアントは最終的に更新された値を見ることになる.

さらに結果整合性にも細かなバリエーションがあるらしい。

因果整合性(Causal consistency): プロセス A がプロセス B と通信を行い, その B がデータ要素を更新したとき, B が続けてアクセスをすると更新された値が戻る. また書込みはその前の書込みを上書することが保証される. プロセス A と因果関係をもたないプロセス C は通常の因果整合性に従う.
Read-your-wrie consistency: このモデルは重要だ. プロセス A が書込みをしたとすると, そのあと A は常に更新された値にアクセスできる. 古い値は決して見えない. これは因果整合性の特別な場合だ.
セッション整合性(Session consistency): 上のモデルの実用的なバージョン. プロセスはあるセッションの下でストレージシステムにアクセスする. セッションのある間, システムは Read-your-wrie consistency を保証する. 何らかの故障シナリオでセッションが破棄された場合は新たに作りなおす必要がある. また保証はセッションをまたがない.
単調読み出し整合性(Monotonic read consistency)：もしプロセスがオブジェクトからある値を読みだしたら, それ以降にはより古い値を読み出さない.
単調書き込み整合性(Monotonic write consistency): この場合はシステムが同じプロセスからの書込みが直列化されるよう保証する.このレベルの保証をもたないシステムでプログラムを書くのは難しいことで悪名高い.

クラウドの場合にConsistencyが問題になるのは、複数ノードへの書き込み（失敗）のケース。書き込み失敗時の対処としては、リトライや、失敗したノードの切り離しがあげられる。一定回数リトライし、それでもダメだった場合にはノードを削除することで、一定時間後にはシステム内は整合性が保たれた状態になる。これが、（クラウドにおいて）Eventually Consistentレベルの一貫性の実現方法の概要。

このような、リトライやノード削除の機能は、従来データベース製品が担っていたのだが、これらは本来OSが担っても良い部分。現段階でこの部分をOSが担っていないのは、単に歴史的な経緯によるものだと思われる。少なくともクラウドの分野では、OSとデータベースの統合がはじまっている。

このような、厳密にACIDを満たさないような新たなトランザクションモデルをBASE(Basically Available, Soft-state, Eventually-Consistent)と言う。ACIDはデータベース製品などが担当する比較的局地的なトランザクションモデルであるのに対し、BASEはもう少し広い、システムレベルのトランザクションモデルらしい。

Soft-State
分散システムにおいて、状態を完全に守りきるのは不可能。丸山先生の説明はよくわからなかったので、ネットで調べてみると、こんなのがでてきた。ステートと状態がかぶっているのが気になるが、丸山先生よりわかりやすかった。

ハード・ステート状態管理
　データ通信を管理する方法の一種。一般に、通信中のコンピュータが通信プログラムを終了する際に、「データ通信の終了」を通知しないと、それが正常に終了したのかどうか相手にわかりません。このため、通信プログラムの動作には高い信頼性がもてません。これに対して、「データ通信の終了」を相手に通知してから終了するようなプログラムであれば、そのコンピュータの動作には高い信頼性が期待できます（終了通知なしに終了すれば事故だとわかる）。したがって、このようなプログラムに対しては、通信を始めるときにだけ状態を確認しておけば、以降の動作には信頼性がもてます。
　このように、通信の開始のときだけ相手プログラムの動作を確認するデータ通信管理手法を、ハード・ステート状態管理と言います。既存の電話システムが、この例です。反対語は、通信中に絶えず相手の動作を確認するソフト・ステート状態管理で、インターネットがこれに当たります。

Eventually Consistency by Example
さて、ここで、2つのシステム要素（A, B）を持つ分散システム上で、システムAが自身の状態を更新し、その状態をもとにBの状態を更新するケースを考えてみる。
極端な例として、システム要素AとBが銀河をまたいで離れているようなケースを考えると、光速度の制約があるため、Aの状態変更とBの状態変更をACIDに行おうとすると、使い物にならなくなってしまう。この場合、まずはAの状態を（ACIDに）変更し、その後でBに状態変更を通知するのが現実的になるだろう。この際、Aが通知を送ってからBに届くまでの間、システムは不整合な状態となる。Bに通知が届いた後は整合性を回復したと考えることができ、Eventually Consistentとなる。逆にこうした動作を前提にすると、ACIDトランザクションをコーディネートするようなTransaction Managerは不要になる。

こうした状況を現実の分散システムにあてはめて考えてみると、ACIDトランザクションはBASE(Eventually Consistent)トランザクションの特殊な形態（Consistencyをほぼ完全に満たすことができるケース）とみなすことができる。

クラウドにおける排他戦略
悲観ロックより楽観ロックだよね、という話。Scalabilityのためには楽観ロック。ある意味当たり前？

クラウドと永続化
クラウドのようなシステムのノードは、落ちることなく動き続ける。であれば、メモリもPersistencyを担うことができるのではないか？という発想が出てくる。となると、DBのインデックスのようなものはハッシュテーブルとして実装されることになり、自然に分散ハッシュテーブル（Distributed Hash Table）への注力へとつながっていくことになる。

現実のEnterprise SystemへのEventually Consisitency概念の応用
システム全体を単一のトランザクションモデル（特にACID/Immediate Consistency）でカバーするのではなく、ケースに応じて一貫性レベルを選択することで、PartitionやAvailability、特にPartitionを増すことができる。こうした形で応用すると良いのではないか、みたいな話だった。
Eventually ConsistentやSoft Stateは、情報システムにおける物理的な限界点を示したものであり、基本原理となるため、考慮するのは必然、といった話もちらっと最後に出てきていた。

目次：
QCon Tokyo 2009に行ってきた

CAP Theorem（定理）

2009-04-11T12:41:00.015+09:00

QCon Tokyoでは色々なところで「CAP Theorem」という定理が出てきた。が、eBayの人をのぞけば（たぶん）正確な定義は提示されておらず、不明な点がいくつか残っている。これからのインフラを考える上でも、QConセッションの内容をより良く理解するためにも、このあたりをまずきちんと理解しておきたい。主な疑問点は以下のとおり。

C, A, Pの特性の正確な定義は何なのか
CAP定理が前提にしているシステムのモデルはどのようなものなのか
Theoremとなっているが、単なる経験則なのか、それとも数学的な定理なのか

頼みの綱？のWikipediaを調べてみたが、日本語版はおろか英語版にも載っていない。概観をまとめた海外の記事を結城さんが訳してくれているようなので、これを読んでみる。

CAP Theoremそのものは、Eric BrewerがPODCカンファレンスのキーノートで提唱したものらしい。CAP Theoremには形式的な証明があるらしいので、数学的に証明された、文字通りの定理であるようだ。証明の論文はACMの有料会員にならなければ見られないらしく、無料のWeb会員では見ることができなかった。残念。Eric Brewerの資料はWeb上で公開されているので、これを見るのが一番良さそう。

Eric Brewerのスライドでは、availabilityやgraceful degradation, performanceのためにはCとIが犠牲になるが、これは根本的なトレードオフである、という認識が出発点になっており、丸山先生も紹介している BASE（Basically Available, Soft-state, Eventural consistency）の概念の提示に続いている。さらに、ACIDとBASEはどちらかを選択しなければならないような排他的なものではなく、スペクトラムのようなものではないか、とも書かれている。

C, A, Pの定義
さて、CAP Theoremだが、CAPは以下のように紹介されている。

C:Consistency
A:Availability
P:Tolerance to network Partition

QCon（少なくとも同時通訳で）では、Partitionについてはネットワークとの関係は言及されておらず、並列処理可能性とほぼ同等に扱われていた気がする。が、ここでは明確に、ネットワーク分断への耐性、と書かれている。
AmazonのCTOによる、2007年InfoQの発表では....

- Strong Consistency: all clients see the same view, even in presence of updates
- High Availability: all clients can find some replica of the data, even in the presence of failures
- Partition-tolerance: the system properties hold even when the system is partitioned

となっているらしい。Partition-toleranceは、システムが分割された場合でもシステムが保持する特性、と定義されている。つまり、 Partition-toleranceが低いシステムは、分割すると色々な特性が失われる、ということだろうか。この定義からすると、並列可能性というのもあながち間違った表現ではないように感じる。

CAP定理
さて、以上のように簡単な定義がなされた上で、CAP定理は以下のように定義される。

You can have at most two of these properties for any shared-data system

すなわち、「共有データを持つシステムは、CAPとして定義された特性のうち最大でも2つの特性しか持つことはできない」。以降、例をもとに説明してあるんだが、例自体があいまいなので、例の技術に詳しくない自分にはなかなかわかりづらい。想定している状況の単純なモデルを先に確認した方が話が早いと思う。

想定するモデル
2つのモジュールと、その間のインタフェースについて考える。クライアントとサーバーでも、ピアとピアでもなんでも良い。典型的には、プロシージャコールの形を取るが、この際インタフェースをはさんだどちらの側も同一のアドレス空間にいる。スレッドはこのインタフェースを超えていく。

しかし、インタフェースをはさんだそれぞれの空間が同じアドレス空間ではない場合、Call by Referenceは使えず、データをコピーしなければならなくなる。こうした状況になった場合のCAPについて議論しているようだ…うーん。それでもやっぱりわかりづらいな。例を確認してみる。

C+Aを持つケース

単一サイトのデータベース
クラスタデータベース
LDAP
xFS file System

一貫性と可用性を持つかわりに、ネットワーク分断に対する耐性を失っている例。このようなシステムは、2フェーズコミットや、キャッシュ検証のプロトコルを持つ。
単一サイトのデータベースを考えてみると、確かに一貫性は得られている。ネットワーク分断で失われる特性が多いというのは、何をさしているのだろうか？少なくとも、ネットワーク分断をすすめていくと、性能が犠牲になるのは間違いなさそうだが。
可用性が得られている、というのはさらによくわからない。2PCの例では、TMがACID特性を保証しているので、データのコピーは発生せず、常にすべてのデータが得られるため可用性が高い、ということだろうか？少なくとも、クラスタでは可用性は高そうだが。

C+Pを持つケース

分散データベース
分散ロック
主要なプロトコル

一貫性とネットワーク分断への耐性を持つが、可用性を失っている例。悲観ロックを使ったりしているらしい。
分散データベースを考えると、ネットワーク分断への耐性はかなり高そうなのはわかる。また、システムが一部故障した際にはすべてのデータを得られなくなるだろうから、可用性が低いというのも理解できる。分散データベースの一貫性については、実はよくわかってないのだが、きちんと保証できているのだろうか？本当にきちんとできているなら、2pcとあまり変わらない気がするのだが。

A+Pを持つケース

Coda
Webキャッシュ
DNS

可用性とネットワーク分断への耐性を持つが、一貫性を失っている例。リース/期限切れのアーキテクチャパターンや、競合解決、楽観的同時実行制御などを用いるようだ。
DNSについて考えると、確かにネットワーク分散しても失われる特性は小さく、可用性も非常に高いが、一貫性を失っていると言える。

この後もスライドとしては細かい話が続いていくんだけど、結局CAP定理が前提としているモデルがどのようなものであるのかは、正確にはわからないままだ。
例えば…

ネットワーク分断というのは、どの要素とどの要素の分断のことを言っているのか（あらゆるシステム要素間の分断なのか、特定の部分の分断なのか）
分断によって失われる特性、失われない特性とはどのようなものなのか
高い可用性が意味するものは何なのか
などなど

これらがわからないと、きちんと理解できた気もしないし、分散システムにおけるアーキテクチャ設計で自信もって決断を下せないと思うんだけど、これらの資料から完全に理解するのは難しそうだし、どれくらい時間がかかるのかも見当がつかない。なので、一旦はここで終え、QConの個別セッションを見ていきたい。当面は、結城さん翻訳資料にある以下の説明を、例による便宜的な定義として使っていく。

ネットワーク分断への耐性を捨てたシステムなら, データの整合性と可用性を実現できる. これには普通トランザクション・プロトコルを使う. 実現のためにはクライアントとストレージ・システムが同じ環境にある必要がある. これだとシナリオによってはシステム全体が故障してしまうし, クライアントは分断を検知できない. 重要な洞察がある: 大規模な分散システムではネットワークの分断が所与のものであり, 従って整合性と可用性は両立しない. どちらか一方は捨てる必要がある. 整合性を妥協すればシステムは分断のある状況でも高可用性を実現できる. 整合性を優先すればシステムの使えない状況を生む.

パネル・ディスカッション「エンタープライズ・ソフトウェア開発の動向」

2009-04-10T23:12:00.004+09:00

QCon Tokyo最後のセッション。以下のような豪華な参加者陣でした。

Floyd Marinescu （InfoQのエラい人）
Dylan Schiemann（Dojoのエラい人）
Randy Shoup（eBayのエラい人）
Gregor Hohpe（Googleの中の人、EIPの共著者）
Henrik Kniberg（Agileなコンサルタント）

一緒に行ったメンバーとの会話で、なんとなく自分が担当になった雰囲気がしたので、わかる範囲で書き起こしつつ、自分の感想も（発言とは区別がつく形で）書いていきます。メモが中途半端なので、話をつなげるために微妙に補足してたりします。会話口調は、そのときの雰囲気から適当に作ってます。敬称はすべて省略してます。発言者とか間違えてるかもしれないので、その辺ふまえつつ適当に見てやってください。

[まずは、エンタープライズソフトウェア開発の動向について全員が2分ずつ発言。]

Henrik：
プロセスにかかわる立場からの話をしたいと思う。
北欧ではAgileの導入がかなり進んできているけど、Agile導入に際してはScrumをエントリポイントとして採用しているところが多い。こうして、特に従来よく見られていたような、技術チームと業務チームのコミュニケーション上の問題を解決することに成功してきている。
ただし、Agileでこうした問題が解決されるにつれて、その他の問題、例えばコードの品質などの技術的な問題もあらわれてくる。このような問題を解決するために、今後はXPで採用されているようなプラクティスが重要になってくるだろう。
# Scrumは他のAgileアプローチに比べてプロジェクト管理に強いが、技術上のプラクティスはあまり多くないことを受けての話だと思う。

また、企業では、ソフトウェアの開発が終わったあとも色んなプロセスが続いていく。リーンの手法が重要になってきており、ソフトウェア開発だけでなくバリューチェーン全体を改善することが重要になってきている。
これまで企業は、変革を口にするだけでなかなか実行に移そうとしなかった面もあったが、今回の経済危機の影響を受け、話だけではなく実際に実行にうつしつつある。
無駄なプロセスを続ける余裕があった企業も余裕がなくなってきており、組織的な変革がはじまろうとしている。

Gregor：
あんまりネタを考えてこなかった。
立ってのパネルディスカッションってはじめてっす。
立ち飲みみたいっす。
残念なことに、飲み物がアルコールじゃないです。
ってことは、これは立ち話ってうんですかね。
ビールがあると最高だったんですけどね。
とかジョークをいいながら、話のネタを考えていました。

大きなトレンドの話としては、知っていることが何度もまわってくる、ということがある。知っていることが何度もトレンドとしてやってくるのだが、そこには新しい考えが注入されていく。
SOAやクラウドはほんとに新しいのか、との疑問がよくあるのだが、新しいとも言えるし古いとも言える。古いコンセプトに新しい考えが注入されているのだ。こうしたトレンドのサイクルは、ファッションと似ている。色んなものはやがて戻ってくる。これは当然で、実証済みの概念というのは古くても役に立つ。

さて、これは開発者にとってはどんな意味があるのだろうか？開発者はどうすればいいのか？
まずは概念を理解することをすすめたい。サイクルする技術は、詳細はかわってしまうかもしれないが、多くの概念が転用できる。開発者は、転用できるアイディアにフォーカスすべき。重要な概念を概観できることが大事。

Henrik：
[難しくて曖昧な話はわかったから、といった調子で :-)]
結局、具体的にはどういう動向が重要になってくると思う？

Gregor：
人間は未来を予想できない、予想できなくても僕のやり方なら大丈夫なはずなんだけどね！ :-)
あえて新しいトレンドを推定するなら、ランタイムの重要性の高まりかな。
今までランタイムは見えないもので、みんなはモデルや言語なんかの表面的な部分に注力してきたけど、クラウドの登場などでランタイムが重要になってきている。
ソフトウェアを書くのは全体の一部、という話がHenrikからあったけど、組織プロセスの観点だけでなく、ソフトウェア実行の観点でも同じことが言える。ソフトウェアを書き終わったからといって、全体のほんの一部しか終わったことにならない。

Randy：
トレンドとしては、3つあると思う。

まず1つは、大きな企業のプラクティスが小さな企業に浸透してきているということ。分散化、パーティショニングのような課題を、小さい企業も意識しはじめている。

2つめは、アプリケーションの開発方法。
たいていの企業では色んな言語やプラットフォームでシステムを作ろうとしており、ヘトロジニアスな環境が多くなってきている。多様な選択肢があるが、最適なものを見極めることが重要だ。

3つ目は、デプロイメント、つまりアプリケーションの展開に関するもの。
クラウドが一番明らかな例で、これまではコンシューマ向けにしか使われておらず、クラウドのプレーヤーも少ないが、これからは銀行や大企業、政府機関などが内部にクラウドを持つようなことも起きてくるのではないか。また、クラウドが浸透していくと、中小企業にまでその利用が広がっていくだろう。

Dylan：
2つの大きな相反する動き、統合と細分化に注目したいと思う。
例えばJavaを見ていくと、90年代から統合化がどんどん進んでいった。
# この辺よくわからなかったっす
# 統合化されて肥大化し、使いづらくなると、小さなプレイヤーにチャンスが来るとかそんな話をしていたと思う

OSSでは細分化が進んでおり、ものすごくたくさんのプロジェクトやソフトウェアが生まれている。一方でOSS同士のアライアンスも増えてきており、統合化も同時に展開されているという興味深いことが起きている。これは非常にエキサイティングだ。

Floyd：
FowlerとRod Johnsonのかわりにきました。彼らはもういなくなっちゃったからね。
Martinは、プロジェクトに常に1つの言語を使うのではなく、目的にマッチした言語を組み合わせて使う、というようなことを言っていた。Rodは、リーンなツールが必要になってきているという話をしていた…と思う。なんかこんな感じだったよね？北京ではこんな話をしていたと思うんだけど、あってる？

Dylan：
ともあれ、すべての根底にある流れは、Webがアプリケーションのプラットフォームになってきている、ということだ。クラウドコンピューティングもRIAのようなものも、すべてこの流れから出てきたものだ。

ところで、Javaのコミュニティってつまらなくなってない？あきてきた人？
[手をあげて賛成者を探す。結構手があがる]

これは、Javaを使うタスクが安定化してきたということだ。2000年頃は、色んなWebのフレームワークが出てきていた。これはつまり、Javaを使ってWebアプリを作るのが新しかったということだ。

技術がかわるとまたいろいろとエキサイティングなものが出てくるだろう。クラウドもその端緒になると思う。Javaで標準かが次々進んだように、クラウドのプログラミングモデルを統一化する動きがはじまるかもしれない。みんなベンダーにロックインされたくないだろう？

クラウドコンピューティングってのはすごく重要な流れだ。これによって、中小企業が効果的に色々な仕事ができるようになるだろう。Linuxやコンフィグファイルを気にしなくてもよくなるんだ。低コストで色々できるようになる。

Gregor：
ここいらで、今まで出た話を統合してみたい。
フラグメンテーションや統合の話、クラウド、開発者のエンパワーメント、これらはつながっていると思う。
# 開発者のエンパワーメントは、Rod Johnsonがセッションの前半であげたキーワード
開発者の力が増すという流れと、クラウドは同じ方向を向いていると思う。開発者がまたガレージで開発を始められるということだ。ここのところあがってきていたWebに対するインフラの要求レベルに、やっとおいついてきた。

こういう、土俵が平らになるような時期が訪れることがあるが、こういう時にはイノベーションが次々とおこる。

Floyd：
ここで、Rodが持っていた、少し違う意見を紹介したいと思う。Rodは、GrailsはJavaコミュニティにおける重要な進展だといっていて、Javaはまだまだエキサイティングだと言っている。
SpringSourceもクラウド対応機能みたいなものをもうすぐリリースするそうだ。

Gregor：
ちゃんと機能するものを作るのが生活の糧であるなら、Javaにとって安定はいいことかもしれない。安定することによって、新しいことをする余裕が出てくる。細かなバグをおいかけたりしなくてもよくなる。こういう意味で、Javaの安定にはいい面も悪い面もあるだろう。

Dylan：
今や、Javaは世界のFortlanやCOBOLのようになってきているよね。

[ここで質問タイム、外国の方が英語で質問]

質問者：
Javaコミュニティというと、Webアプリ開発者ばかりが対象として語られることが多いけど、JavaコミュニティはWebだけじゃない。WebではないJavaコミュニティの人がこういう場にきていないのは残念なことだ。

Randy：
eBayはフロントエンド以外はWebとは関係ない処理をたくさんやっているよ。

Gregor：
自分もそう思う。実際のシステムではWebは一部のみ。Webの定義にもよるけど、HTMLを扱っているのがWebだとすると、システムの大半はHTMLとは関係ない。
バックエンドでは、SOAやコンポーネント化、RESTのような技術を扱っているのだろうけど、これらもWebと似たような課題を持っているのではないか？Web的な考え方がシステム全体に広がってきているのではないか？

Randy：
たしかに分散システムという意味では同じような特性を持っていると思う。とはいえ、銀行や政府のシステムとeBayのようなシステムでは要件はかなり異なってくる。

Floyd：
Webは新しいプラットフォームなのでしょうがない面もある。デスクトップJavaはずいぶん前に死に絶えてしまったし。

質問者：
確かにそうかもしれない。JavaがWebを捨ててしまえば生き残れないだろうから、仕方ないとは思う。

Dylan：
ヘテロな環境が増えてきたので、最適なものを選ぶことができるようになってきた。
# これ、なんだったか思い出せない...

[次の質問。]

質問者：
Scalaが好き！Scalaは分散処理などの面で面白いと思うけど、どう思う？
# すごいはしょってます...

Randy：
実際に使ったことはないが、Scalaは良いと思う。正しいツールを正しい仕事のために使う、という話で考えると、すばらしいツール。Erlangにも興味深いアプリケーションができてきているし、特定のタイプの作業に特化した言語を適切な場所に使うのが重要になってくる。

Gregor:
一貫性・分散性を考慮すると、もっといい言語がほしいという気持ちはある。Javaはこの辺りを考えると、あまり適していない部分がある。
# このあたり、C#がLINQや関数的な要素を入れていろいろやっている話をしていたが、どうつながっているのかよくわからない。

僕はツールに興味があって、コンパイラとかエディタとかIDEとか、そういうものが生産性を高めてくれることを重要だと思っている。言語を切り替えるとツールも切り替えることになってしまうので、新しい言語は5倍くらいの表現力がないと、ツールの変更で損なわれるものを埋められないんじゃないかと思う。

Dylan：
僕はviだから大丈夫！

Gregor：
私はNotepadだ！

Language Workbenchはこういうのをうめてくれるのかもしれないが、うまく動くようになるまでにはもう少しかかりそうだ。

Randy：
.NET開発者とかJava開発者とかいわなくなったのが、最近の状況を表している。1つのシステムを構築するにも、色んな言語やツールを使わなければならなくなっているということだ。Scalaについて言えば、Scalaの専門家とまではいかなくても、色々知ってるジェネラリストが必要。どの分野にどの言語を使えばいいか、判断できる人が必要だろう。そこで、より深く専門的な知識が必要になれば、言語の専門家が必要にもなってくるだろう。

Gregor：
賛成でもあるし反対でもある。どういうアイデアを転用できるかを知るのが大事。デザインコンセプトを知るということ。
ところが実際に、言語を使いこなす方法をツール・パターン・ベストプラクティスを含めて理解するまでには時間がかかる。Javaで我々は10年かかった。
あまりに多くの言語があふれると、開発者は大変になる。現代では、最大の制約は人間の学習能力になっている。現段階で存在する大量の言語は、既に一人の人間が理解できる範囲をこえている。色々な言語やツールに触れていると、深く使いこなすことができなくなるかもしれない。これはもしかしたら問題にならないかもしれないが、考える必要はあると思う。

Dylan：
ツールがやってくれるんじゃね？

Others：
ツールを選ぶためのツールがいるのか！
そうなったらコンサルタントいらないね！
ハハハハ！

[次の質問。]

質問者：
言語・アーキテクチャやプロセスに色んな変化がおきているが、テストについてはあまり変化がないように思える。テストの変化についてはどう考えている？また、どうなっていくべき？

Dylan：
テスト用のクラウドサービスやブラウザモックもある。社内でできないようなテストを行うサービスもできてきている。AjaxのテストにはSeleniumやWindmilもある。テストツールはいつも少し遅れて出てくるが、だいぶ追いついてきた。

Gregor：
テストには2つの大きな目的がある。正しいかどうかを確認するためのテストと、開発の一環としてのテストだ。開発の一環としてのテストには、TDDやBDDなどの革新がある。
これは、ツールの問題ではなく、使い方、使いこなし方の問題だ。JUnitが出てから8年たつが、このような新しい使い方が出てきている。

もう1つ、ランタイムへのシフトがあげられる。ランタイムで設定される様々なプロパティや環境情報をテストする必要がある。

職業としてのテストの輪郭はぼやけてきている。これは、アーキテクトなどのほかの職業にも言える。テスタの役割も変化してきていて、自動化できないところをやることが重要になっている。テストはかなり自動化されてきているので。実験的なテストなど、自動化できないテストをうまくできることが強みになってくるだろう。

[次の質問。]

質問者：
典型的な業務（会計とかなんとかとか）の用語がほとんど出てこなかったが、このような業務に関わる人はあまりいないのだろうか？最初の話にも少しあったが、業務側と技術側がわかれているような気がするがこれはいいことか？エンジニアであれば、どちらもできるべきじゃないのか？
こういう問題はあると思うか？あるとしたら、どういう風に解決しているか？

Henrik：
これは、問題だと思う。しかし、リーンやScrumを使うことでビジネス側とつながってきているので、どんどん解決に向かっている。

Gregor：
Fowlerはもう語り尽くしたから言わなかったんだと思うよ :-)
問題はあると思う。これに対する解決策としては、自分はテスティングをあげるようにしている。仕様上の問題点などは、テストとして起こして、みんながそれを見ることができるようにしている。今の仕事上、業務というとHTTPヘッダとかそういうテクニカルな話になってしまうんだけど。

Randy：
eBayの経験からすると、一番うまくいったプロジェクトは、ビジネスチームと技術チームがタッグを組んだもの。これらの間の乖離がひどいものは成功していない。

Dylan：
私もCEOをしているのだが、ビジネス的なバックグラウンドを持つのはいいこと。なぜそういう要件が必要になるのかがわかるようになるし、自分たちのしていることがどのような収益を生むのか、なども理解できるようになる。事業側の立場にたって考えることは必要。

Gregor：
極論すると、ビジネスユーザーがVBマクロを書いたときに、一番うまくいっていた。マクロのスクリプティングは強力だ。
しかし、（例えばVBが新しいバージョンになった時などに）これらをどうやって拡張するのか、再利用するのか、といった問題は解決されていない。

[このあたりで時間切れ。ありがとうございましたー。]

目次：
QCon Tokyo 2009に行ってきた

QCon Tokyo 2009に行ってきた

2009-04-10T21:47:00.019+09:00

QCon Tokyo 2009

QCon Tokyoは2日間開催で、それぞれの日ごとに3つのトラック（{1日目 => [Architecture, RIA, Ruby], 2日目 => [Cloud Computing/SOA, Agile, Case Study]}）が設定されていて、トラックごとにセッションが4つ設定されている。また、各トラックに属する個別セッションとは別に、日ごとに2つのジェネラルセッションが設定されていて、大御所たちが話すことになっている。

QConでは、良いと思ったセッションに緑、普通と思ったセッションに黄、いまいちと思ったセッションに赤のカードを入れることになっているんだけど、これに習って自分が出席したセッションを評価すると、こんな感じになる。

[緑（よかった！）]

アーキテクトの審美眼 by 萩原正義
General Session 1 クラウドの技術的な特徴について by 丸山不二夫
クラウドのプログラミング − プラットフォームとしてのインターネット by Gregor Hohpe
大規模ウェブサイトのベストプラクティス −eBayでの事例− by Randy Shoup
パネル・ディスカッション「エンタープライズ・ソフトウェア開発の動向」 by Floyd Marinescu

[黄色（ふつう）]

General Session 1 ドメイン固有言語 −その役割− by Martin Fowler
General Session 2 ビューティフルコード by まつもとゆきひろ
Open Webの進展とその今後 by Dylan Schiemann
実世界のRuby −3年間の経験から− by Martin Fowler
QCon Tokyo Conference Party
General Session 2 Spring Today and Tomorrow by Rod Johnson
アジャイル開発を始めるために −実例で得られた知見から− by Henrik Kniberg

[赤（いまいち）]

Amazon Web Services in Action by Jeff Barr

もともとはRod JohnsonとMartin Fowler目当てで行ったようなものなんだけど、Rod Johnsonの話はちょっとマーケティング色が強すぎて微妙だったので黄色。Martin Fowlerのジェネラルセッションは、既存の資料（DSL WIPやThought Works Anthology）で知っていた話が多かった。Rubyのセッションは興味深くはあったものの、Martin Fowlerの話というより、Thought WorksでRubyに取り組んでいる人たちの話をまとめた内容になっていて、Fowler自身の言葉があまり聞けなかったのが残念。

上記のセッションを聞いてみて自分が持った感想は、「世の中や技術は複雑さを増し続けていて、単一の言語・製品・モデル・パラダイムだけでは（少なくとも効率的には）対応できない」ということ。Rod Johnsonは「JavaEEのようにすべてを包含しようとするのではなく、リーンな（特定の目的のために存在し、シンプルで無駄がない）仕様や製品を、適した場所に使っていくこと」を提唱していたし、Martin Fowlerは「特定のドメインに特化した言語を使い、それを場所に応じて使い分けることで、効率的にシステムを記述/開発できる」と考えているようだ。丸山先生やeBayのRandy Shoup、GoogleのGregor HorhpeはACIDとは異なる新たなトランザクションモデル（丸山先生はBASEモデルと呼んでいる）を提示して、ACIDトランザクション一色の既存のシステム開発の再考を促している。MSの萩原さんは、まんまマルチパラダイムへの流れを強調していたしな。
Rubyは、DSLを記述するための高い表現力を持つため、内部DSL向けのホスト言語として重要な位置を占めることになる。
# あれ…アジャイルは？^^;

個別セッションのまとめは、内容的に興味が持てたものでかつ、かけそうなものを選んでちょこちょこ書いていく予定。たぶんInfoQの方にビデオ出ると思うし。とりあえずは、パネルディスカッションあたりから起こしていく予定。

レポート：

追記：
発表資料公開されました。
http://qcontokyo.com/tokyo-2009/schedule.html

技術者／プログラマのためのラムダ計算、論理、圏第3回に行ってきた

2009-03-21T13:22:00.008+09:00

実は第2回にも行っていたんだけど内容をまったく咀嚼できず、そのうちやろうと思っているうちに第3回が開催されてしまった ^^;

第2回ラムダ計算と停止性問題
第2回は、主にラムダ計算について。前回の復習からはじまって、回路図のような絵を交えながらラムダ抽象化につなげていき、最後はJavaScriptのようなCのような疑似コードを使って、チューリングマシンの停止性問題を背理法で証明して終わった（と思う）。詳しくは、檜山さんのBlogに書いてあるので、そちらを見た方が良いと思う。

セミナー資料
紙芝居：ラムダ抽象
セミナー非参加者にもわかるリアルワールド向けラムダ計算
なぜ停止性について話したのか？

第3回自然演繹と型付きラムダ計算、カリー／ハワード対応
第3回は、カリー・ハワード対応についての感覚的な理解がゴール。第2回とはうってかわって論理を中心に話をすすめていき、論理でやっていることが最終的にラムダ計算に対応することを感覚的に理解することで、カリー・ハワード対応を感じるのが目的、という感じ。こちらも、檜山さんのところに、他の参加者さんのまとめへのリンクを含めてきちんと色々書いてあるのでまとめは書きません、というか書けません！

セミナ資料
カリー／ハワード（Curry-Howard）の対応を知らない子供達および大人達へ
演繹系の話題と演習

もともと、「素数の音楽」「暗号解読」「論理学入門」あたりの書籍や、TM（T字形ER）のセミナでの疑問（数理論理学まわり）解消のためにちょこちょこ調べていたこともあって、今回の話の大半は馴染みがあった。とはいえ、雰囲気つかむことを重視してたので、導入規則や除去規則についてあまりよくわかっていなかったのだが、今回具体例をもとに理解できたのはとても良かった。
セミナの内容の本筋としては「計算と論理は以下のように対応する」

論理	算術
演繹系	算術回路キット
推論	基本演算
証明図	計算図
演繹系の証明図	算術回路キットの計算図
証明可能	計算可能
derived rule	計算のマクロ
公理	最初から使える定数
定理	計算済み定数

でFAな感じなんですが、話の中でちらちら出てくる用語や、自分が既に知っていることとの関係がよくわからなくてもやもやしている。というか、聞けば聞くほど疑問が増えるという状態...

檜山さん的アプローチでのラムダとは少しは仲良くなった気がするが、一般的（形式的というか記号的というか）なラムダ計算についてイマイチわかっていない感
カリー／ハワード対応が何を意味しているのか（この理解が何につながっていくのか）
自然演繹以外の演繹系と、型付ラムダ計算以外の計算も対応するのか？
フォーマルメソッドや自動証明との関係は？
プロセス論理との関係は？
型推論との関係は？
結局、絵算というのは何がエキサイティングなんでしょう？

檜山さんのエントリによると、話題同士の関係についてこれからいくつかエントリをあげつつ説明してくださるようなので、それらのエントリをながめつつ、自分なりに理解を深める過程を書いていこうと思う。ううむ...文系は土台からしてしょぼいからつらいなぁ...。

何か関係ありそうなリンク
型＝命題、プログラム＝証明
　Haskellを例に、型推論との関係について説明してくれそう。
Curry-Howard対応を知らないこども達
　サーセン（笑）
Curry-Howard Isomorphism
　ざっと読んだけど、概要を把握するにはとても良さそう。
CiteSeer : Curry-Howard Isomorphism
　カリー／ハワード同型対応についてきちんと書いてあるらしい論文。
自然演繹-Wikipedia
　型理論や線形論理との関係も書いてある。
ラムダ計算-Wikipedia
　ここに書いてあることが「そりゃそうだよねぇ」と言えるくらいにはなりたい。

自分のブランディングを考える inspired by 「抜擢される人の人脈力」

2009-03-18T23:01:00.007+09:00

同僚に貸してもらって「抜擢される人の人脈力」という本を読んだ。これは、人脈をつちかっていくことで自分自身も成長し、トータルでの仕事の能力も上げ、最終的には代替不可能な人材になって自由な働き方を手に入れよう、てな本。目指すところには非常に共感した。

人脈を広げるための5ステップ
この本では、人脈を広げるためのステップを、以下の5段階で定義している。

自分にタグをつける
コンテンツを作る
仲間を広げる
自分情報を流通させる
チャンスを積極的に取りにいく

2番目以降は考えるだけではダメなのでおいおいやっていくとして、まずは自分にタグをつけるとしたらどうなるのかを現時点で整理して、ブログの紹介文にでもいれとこうかと思う。

自分へのタグづけ
さて、タグをつけるには、以下の3つの観点から考えると良い、とアドバイスされている。

将来、どんな仕事をしたいか（Will）
自分にできることは、何か（Skill）
相手にどんなメリットをもたらすか（Value）

はい、では1から。

Will/将来、どんな仕事をしたいか
第二の就職活動のような内省が必要になる部分だろうと思うが、自分は日常の会話やふとした反応から、自分にいくつかの指向があるのを感じていた。まず、最も根底にあるのは...
「すばらしい仲間と最高のシステムを作る」
ということ。ここでの「すばらしい」が意味するのは、必ずしもすばらしいスキルを既にもっている、ということではない。それは、志を同じくしていて、そのシステムをより良いものにするのに真剣に心を砕き、全力を注いでくれる、という意味だ。そして、そんなシステムを作るために、日頃から鍛錬を惜しまない、という意味でもある。だから、結果として高い能力はついてきているはずだ、という期待もある。もちろん、自分がその仲間になるのであれば、自分も同じようにあらねばならないのは当然のことだ。...できてるかどうかあやしいけど...。

簡潔にタグにするとすると、どうなるんだろう？「目指せドリームチーム入り」？チームメディカルドラゴンみたいな感じでしょうか。

さらにもう1つ、それは...
「アカデミックな研究成果で現場を進歩させる」
ということ。自分はもともと経済学部でミクロ経済学を専門にしていたんだけど、色んな仮説をたてて市場をモデル化し、現実の経済を分析しようとしても、そのモデルがどの程度現実を反映しているのかを知ることは非常に困難であり、現実世界に寄与する方法があまり具体的にイメージできなかった。この現実世界との乖離度合いに我慢ならなかったために、企業に入社したようなものだ。

元々自分はアカデミックな研究成果（というより、先人が払ってきた膨大な労力）に対して敬意を持っているのだが、往々にして現場はアカデミックな研究成果を現実的でないと馬鹿にしていたり、そもそも理解するどころか、どのような成果があるのかを確認すらしていないことが多い。
彼ら（我ら）が我流で考えだす改善策やソリューションにも一定の意味があることは多いが、たいていは研究成果の出来の悪い焼き直しであったり、よくわからない局所最適解であることが多い。今は昔とは逆に、アカデミックな研究成果を現場に取り入れることの難しさにもがいているわけだが、大学から現場に口を出すよりも、現場から成果をひっぱってくる方が遥かに簡単だと感じている。自分は研究と現場をうまくつなぐような役割を果たしたい。
こういうの、なんていうんだろう？「現場の学者」のようになりたいのだ。

最後にもう1つ、それは...
「才能を持った人材が比較的自由に仲間や仕事を選べる、職人ギルドのような組織を作り、個人の力を最大限に解放できるようにする」
なんか長いな。これはもう、そのまま。特に動機になっているのは、企業内では才能を持った開発者が自己の能力を最大限生かして働くことが非常に難しい、ということ。さらに、生かせたとしても、それに対してあまり高い報酬をもらっていないケースをよく見る。逆に、大した寄与がない人間が非常に高額の報酬をもらっているのもよく見る。自由もなく報酬も少なく、評価もあまりされない。仮に自分を成長させられたとしても、居場所がなさそうな世界なんてぶっつぶしてやりたくもなるよね？これを実現するには、周囲が才能や能力を認知できる状態にしなくてはならないので、みんな一定の能力が求められることになるんだけど。
タグづけすると...「才能を縛らない現場を作る」かな。

Willはこんなものかな。次、2。

Skill/自分にできることは何か
自分にできること...
「小規模から超大規模まで、10近くの様々な規模の業務システムでソフトウェアアーキテクチャ設計に携わっている。そのうちの2つの中規模システムは主たる設計者として参加している。」
「業務アプリケーションから基盤ソフトウェア、開発支援ツール類までの設計・実装をしている。」
「業務システム開発の技術リスク監査ができる。」
「業務モデリングもある程度できる。」
「Domain-Driven Designをわりとよく理解している。」
かなぁ。

Value/相手にどんなメリットをもたらすか
ううむ、難しくなってくるな...
「どんな規模のシステムでも、ソフトウェアアーキテクチャ設計できますよ」
「インフラだけでなく業務もある程度わかるので、ソフトウェア全体の最適化の役に立てますよ」
「業務モデリングによる業務最適化も考慮したシステム開発ができますよ」
「DDDアプローチによる、柔軟性の高いシステム構築に対応できますよ」
こんな感じだろうか。

最後に、コンテンツを考えるうえでのヒントをメモって終わりにする。

能力
実績
意欲

以上の3つを把握する。実績を積むためには...

脳に汗をかくくらい頭を使う
ビジネス上の修羅場を経験する
自分の名前で仕事をする

以上を心がける。さって、がんばるぞー。とりあえず明日、檜山さんの主催する、「技術者／プログラマのためのラムダ計算、論理、圏」最終回にいってきまっす！

DDDのメモサイトを作ってみた

2009-02-08T12:44:00.003+09:00

DDD-memo
EvansのDDD本やNilssonのドメイン駆動、DDDの公式フォーラムの内容から大事そうなものや興味のある内容を選んでメモっていくサイトとして作ってみた。
とはいえ、本読んだりForum読みながらとりあえずレベルで殴り書きしてることが多いから、読み物としては微妙なんですが。Wikipediaみたいに、記事ごとに完結させていけたらいいんだけど、なかなか難しい。そのうち、記事ごとにそれなりに内容がまとまった状態にしていきたい。

Google Siteに作ったんだけど、Google SiteってRSS出してないのね…。どうした、Google様らしくないなぁ。

赤坂BLITZ

2009-01-13T11:06:00.003+09:00

奥さんと赤坂BLITZに行ってきた。改装後ははじめてのBLITZ。ライブのパフォーマーは、ミリオンヒットを出した経験もあるものの、最近はそんなに売れていないミュージシャン。ちなみに自分はそのミュージシャンをそんなに好きではないので、行く前はいつも気がすすまないのだけど、実際行ってみるとライブというのはやっぱり良いものだと思って帰ってくる。

このライブ、赤坂BLITZでやるにも関わらず、スタンディングではなく席が用意されていた。なので、満席にも関わらず600人弱しか入っていない。

チケットは一枚あたり6300円なので、チケット売り上げはせいぜい400万円。企画立てて、ハコ押さえて、ミュージシャン集めて、リハやって、当日スタッフ雇って、演出決めて、機材用意して、ステージセッティングして…などなど考えると、400万というのは非常に心もとない数字に思える。チケット業者にも何パーセントか流れてるだろうし。相場をまったく知らないんだけど、他のライブハウスの相場から推測するに、ハコ代だけで200万くらいいってそうだし。

ライブは基本的に、チケットでは収支プラマイゼロくらいで、物販で稼ぐと聞いたことがあるけど、物販顧客の母集団が600人じゃあ売り上げもたかがしれている。客単価が2000円で300人買ったとしても60万。実際ここまで買ってるかどうか。となると、本当に収支トントンくらいなのだろうか。

それなりに有名なミュージシャンがそれなりに有名な場所でやってるのに、動くお金の量があまりに少ないことに驚いてしまった。TVアニメのDVDの初動枚数が、ベスト10でも5000枚くらいなのを知ったときも驚いたんだけど。

ピアプロ/ニコニコで活動しているジミーサムPことOneRoomという人がいて、最近気に入ってずっと聴いている。最近、既発表曲のiTunesでの配信（タイトルは「Resound」）がはじまり、アルバムランキングで最高3位に入っているのを知った。アルバムで買えば900円で、ピアプロにいけば無料でMP3も手に入る。彼がライブすることはないだろうし、一般に広く知られることもないだろうけど、自分は金を払って買うCDよりもこっちの方を気に入って聴いている。音質が良さそうならあらためてiTunesで買うかもしれない。iTunes plusだったし。音楽活動に直に関わっている感じもあり、とにかく距離が近いのも良い。

とりとめがなく、まとまってもいないんだけど…若い人を中心に文字情報で起きてること、ひょっとして音楽でも起きる…のか？

KPT2008

2008-12-22T15:57:00.006+09:00

DDD勉強会でもやったんだけど、口頭アドリブでグダグダになってしまったので改めて整理。

■KEEP

* 英語に慣れる

TOEIC 800点取れたのは上出来

フィードや書籍、Podcastも英語のものが増えた

* 交流を増やす

DDD読書会で結構知り合い増えたと思う

てか今までが少なすぎ

* 体系的に勉強する

情処資格2つとも受かったのはまぁ良かった

OOとかDDDとか結構真面目に勉強できた

集合を中心に、数理論理とか数学系を多少勉強できた

■PROBLEM

* 趣味が増えてない、ってか挫折

+ ベースどうなった

+ EDIROL買ったのに全然使ってない

+ あんまり絵がうまくなってない

+ 特に人物うまく描けない模写は結構得意だけど空想で色々描けない

* 運動できてない

+ 何ができてないかも話せなくらい何もやってない

* 料理できてない

+ レパートリー増えてなさすぎ

■TRY

* 英語により慣れる

+ 今年はTOEIC 900点を目指したい

+ オリジナルが英語の情報は全部英語で読む

* 交流をより増やす

+ OSSプロジェクトに参加する or 書籍出版に関わる

+ 何という無理くささ

* 体系的な勉強

+ ドメイン工学系

GenarativeProgramming => Multiparadigm Design

+ ビジネスモデリング系

Ericsson-Penker => Analysis Patterns => Data Moedl Patterns

+ DSL系

Fowler DSL Books WIP => Meta Programming System

+ ビジネス系

会計～中小企業診断士を趣味的に

* 趣味

+ ベース楽しく弾く

+ できればアマ志向でバンド組んでスタジオで騒ぐ

+ かっくいいのかいてpixivとかに投稿してみたい

+ もっかい将棋はじめてもいいかなぁ

* 料理

+ とりあえずペペロンチーノで乳化あたりから

…こんなもんかなぁ。なんか、多すぎ？

人に教えるということ

2008-12-16T14:29:00.004+09:00

「全部俺のモンだ孤独も苦痛も不安も後悔ももったいなくってさ、テメエなんかにやれるかよ！！」－PLANETES ハチの台詞

昔、自分がまだ学生だった頃に、色んなことをアドバイスしてくれる大人がいた。彼らの知っていること、経験してきたこと、そしてこうすべきであるということを（迷惑にも）丁寧に教えてくれるのだ。
自分はその人（たち）に対して、ずっと思っていた。俺が本来経験するはずだったものを取っていかないでくれ、って。

だからなのか、元からそうなのかはわからないけど、自分は人に何か結果を教える気が起きない。理屈を後で教えるとしても、問題にぶちあたり、悩み、考え、到達し、評価し、羞恥し、学ぶこととは比べ物にならないと思えてしまうから。たどり着いた結果だけでなく、その過程自体に価値があると思うから。

極端な意見であることはわかってるし、TPOもあると思う。一度知ってしまった後でも同じことができるのに、見くびってるのかもしれないとも思う。君みたいな人ばかりじゃないとか、やる気なさすぎとか言われてよく怒られもする ^^;

でも、これが人に教えることについての基本的な自分の考えなんだよなぁ。これはずっと変わってない。これからも変わらない気がする。もちろん人によって変えはするけど、理想はいつもここに持っている。少し前に、人を教えるにはどうすればいいか飲みながら話したことを思い出して。

ハチほど熱くもわがままでもないと思うけど、気持ちはよくわかるよ、うん。

Scala勉強会の資料

2008-12-04T11:58:00.002+09:00

自社でScala勉強会やりました。勉強しながらなので間違ってるところもあると思いますが、とりあえず公開してしまいます。

勉強の過程で色々わかったから、そのうちここにまとめて書いていく…かもしれない。

Scala Study Session

View SlideShare presentation or Upload your own. (tags: scala studysession)

Scalaでの可変オブジェクトの扱い

2008-11-06T12:55:00.000+09:00

今までは、関数は副作用を持たないものとして扱ってきた。なので、時間の概念を気にする必要もなかった。一連の処理は、どのような順番で評価しても最終的に同じ結果が得られる。これを合流性（confluence property）とかチャーチ・ロッサー性と呼び、関数型プログラミングの理論的基盤となるラムダ計算の重要な帰結らしい。知らなかった。

ざっとWebを流し読みしたところ、ラムダ計算の体系では、ラムダ式をベータ簡約することが計算そのものとなるようだ。ベータ簡約は関数適用による正規化のこと。で、チャーチ･ロッサー性とか合流性とかは、ベータ簡約の順序がどうであっても最終的に同じ正規化されたラムダ式が得られる、ということを言っているようだ。これはつまり、どのラムダ式から評価・計算しても同じ計算結果が得られるということになる。…簡約、つまり計算が停止さえすれば。

つーか、これを調べてる間にラムダ計算の迷宮に迷い込んでしまった…大学で情報の基礎教育を受けていない身にはつらい…けど、勉強になる。

さて、これは不変の世界・参照透過性が保証された世界の話で、ここでの本題はScalaでの可変の世界の扱い方。ここでは、オブジェクトがhistoryによってその振る舞いを変える場合、オブジェクトは状態を持つという。このあたりは、純粋関数型とかそういうのはもう捨ててしまって、完全にオブジェクト指向の世界に入っている。いわば、Javaな人にとってはおなじみの世界。Javaとの違いといえば、変数は定義と同時に初期化しなければならない点くらいだろうか。なので途中の例は思い切って省略！つまんないし。

同値性と変更

「代入」の導入により、二つの式が同じかどうか判別するには、より正確な「同値性」の定義が必要になってくる。具体的には、可変の世界では以下のようにして同一性をテストするらしい。

式xと式yを含む任意の一連の処理Sを実行し、結果を観測する。
Sの処理のうち、yをxにすべて置き換えた処理S’を実行し、結果を観測する。
もしS’の実行結果がSの実行結果と異なっている場合、xとyは同じでない。
SとS’の実行結果がすべて同じであれば、xとyは同じ。

これは、インスタンス自体が同じかどうかみたいな話をしているようだ。Javaのequalsに慣れた身としてはなんとももどかしい定義だ。理屈としてはこれで良いとして、実際上はどうするんだろう？

代入と置き換えモデルの崩壊

今までは、値の名前を常にその値を定義する式に置き換えることができた。例えば、

val x = new BankAccount; val y = x

のval y = xは、val y = new BankAccountと置き換えることができた。しかし、可変の世界ではこのモデルはもはや機能しない。このように書き換えてしまうと、違う意味になってしまう。

手続き的制御フロー

おなじみのwhile/do-whileがあります。なーんだ、あるじゃん！と手続きに馴染み深い自分は一安心してしまった。変数に値を代入できるから使える制御フローではあるよね、確かに。while (j <>

だけど結局、whileループも以下のような再帰の関数で置き換えることができる。

def whileLoop(condition: => Boolean)(command: => Unit) {
 if (condition) {
   command; whileLoop(condition)(command)
 } else ()
}

こうすれば、可変オブジェクトは不要になる。なるほど。ちなみに、whileLoopは末尾再帰なので、実際はループとしてコンパイルされる。ということで、一定のスタック領域しか消費しない。

後は、回路をシミュレートするサンプルが延々続いてるけどこれは省略。おなじみだし。

まとめ

状態（代入）を導入すると、プログラムは複雑になる。とりわけ、参照透過性が失われる。が、状態はこれはこれでエレガントなプログラムを作るのに役立ったりもする。どちらを選ぶかは状況によりけり。

A Life in Shinjuku.

WindowsでLeiningen behind a proxy

QCon Tokyo 2011 アーキテクチャパネルディスカッション＋DDD雑多ネタ

QCon Tokyo 2011

ブレイクスルー体験記＠DevLove Beautiful Development

Code Generation & Language Workbenches＠DSL読書会

外部DSL実装のためのAntlrチュートリアル

Fowler DSLのエッセンス

デブサミ2010 - 出張！DDD難民救済キャンプで話してきました

共訳させていただいた「実用Git」が発売になります

モデル上に明示されたトランザクションとしてのAggregate

KPT2009

2009年TRYの評価

ユビキタス言語と日本語

コンテキストあれこれ

第4回「層・圏・トポス」読書会にいってきた

Poken[Rockstar]が来た。

DDD Sample Application version1.1.0: ユースケーススライスから見たアプリケーション構造の確認（2）

DDD Sample Application version1.1.0: ユースケーススライスから見たアプリケーション構造の確認（1）

DDD Sample Application version1.1.0: アプリケーション全体構造の確認

DDD Sample Application version1.1.0: ユースケースの確認

DDD Sample Application version1.1.0 を確認する

DSM(DomainSpecificModeling) + DDD

技術者／プログラマのためのモナドと圏論 第1回 行ってきた

アーキテクトの審美眼

Yコンビネータにトライ

Google App Engineの料金体系が面白い

GAE/Jにいまいち惹かれない

JavaScript: The Good Parts

大規模ウェブサイトのベストプラクティス －eBayでの事例－

ビューティフルコード

Programming the Cloud -the Internet as Platform-

Spring in a Changing World

クラウドの技術的な特徴について

CAP Theorem（定理）

パネル・ディスカッション「エンタープライズ・ソフトウェア開発の動向」

QCon Tokyo 2009に行ってきた

技術者／プログラマのためのラムダ計算、論理、圏 第3回に行ってきた

自分のブランディングを考える inspired by 「抜擢される人の人脈力」

DDDのメモサイトを作ってみた

赤坂BLITZ

KPT2008

人に教えるということ

Scala勉強会の資料

Scalaでの可変オブジェクトの扱い

技術者／プログラマのためのモナドと圏論第1回行ってきた

大規模ウェブサイトのベストプラクティス－eBayでの事例－

技術者／プログラマのためのラムダ計算、論理、圏第3回に行ってきた