パリに行ってて読めないので、記録しておく。もう適当。

Masayoshi Hagiwara @masayh

DSLの設計では基準となる実行環境の論理的階層モデルの位置づけが重要な意思決定になる。プロセスアプローチかドメインモデルアプローチかの違い、モデルの分析方法と論理モデル上の位置づけなど。クラウドでバッチ処理とリアルタイム処理の両方を想定したDSLモデリングに関連して。

Masayoshi Hagiwara @masayh

クラウドではモデルが計算可能であることが重要です。つまりクラウド自体を使い、最適化やシミュレーションを行えること。DAGはその一例でバッチ処理の計算ノードの物理配置の決定の最適化を数学的に行います。それで、CSP、PetriNetなどが出てきます。

Masayoshi Hagiwara @masayh

DAG自体は順序性、非同期入力の待ち合わせ、デッドロック回避、負荷分散などをすべて含むモデルです。宣言的トランザクションのプログラミングモデルを超えるほどの有効性を持ちます。

Masayoshi Hagiwara @masayh

DAGなくして、MapReduceはありえません。

Shinpei Ohtani @shot6

@tamagawa_ryuji @shita そのとおりですね。なので原理を理解するための本と思ってます。だから、開発者のレベルが上がるたびに何度も読み返す必要がある、という事かと思います。

ICHIRO SATOH @ichiro_satoh

先日、国内学会の英文論文誌特集号の査読で、もう一人の査読者がまったく関係のない論文の参照を採録条件にいれてきて不思議だったのですが、どうも査読者（特集号の編集委員）はその参照対象の論文の関係者らしい。ある種のアカハラですよね。

ICHIRO SATOH @ichiro_satoh

続き。ちなみにその著者は参照する理由がないとして拒絶したら、その査読者（特集号の編集員）は採録条件を満足していないと編集委員会で強く主張して不採録。その方が国内では有名な研究者なのが悲しい。

ICHIRO SATOH @ichiro_satoh

続き。後日談があって、その査読者さんは、某大学に教授公募されていて、当方に研究評価が求められたのですが、その一件のいきさつを話すしかなかったです。

Masayoshi Hagiwara @masayh

noSQLやMapReduceなどのformalismが確立していないのに、CAP定理ばかり取り上げられてクラウドの原理みたいな説明をされるのは偏りがあるね。技術のトレンドってどうして一方的に流れていくのだろう。それによってある意味発想が限定的になってしまう。

Masayoshi Hagiwara @masayh

実装手段の主流がOOPであり、その分析設計法の主流がOOADであるのに、そこに並列性や非同期が主であるクラウドとの関係について、原理的な思想的背景を唱えないのは不思議でしょうがない。明らかなことだから言わないのだろうか。ならば、並行単位のオブジェクトグループはどう定義するか？

Masayoshi Hagiwara @masayh

プロセスモデルの半順序から全順序を導く部分に本質的な問題があるの、誰か触れている？

Masayoshi Hagiwara @masayh

非同期の待ち合わせを実装非依存に定義する方法はどうなの？

ICHIRO SATOH @ichiro_satoh

1990年前後に並行オブジェクトは散々議論されてきたのですが、COMだとか、Javaとかで先祖返りしたわけで、いったん並行オブジェクトにもどる しかないとのでは。RT @masayh: 実装手段の主流がOOPであり、その分析設計法の主流がOOADであるのに、そこに並列性や非同期…

ICHIRO SATOH @ichiro_satoh

そう思いますし、そうでないといけません。RT @ProfMatsuoka: そういう(アカデミアで最も基本である)Peer Reviewを冒涜する輩は排除されて当然。正義は勝つ。RT @ichiro_satoh 後日談があって、その査読者さんは、某大学に教授公募されていて、当方…

Masayoshi Hagiwara @masayh

そう思います。でもって、実践との融合で方法論や言語仕様との摺合せをしてフレームワークやらDSLで間を埋めるのかなと思います。@ichiro_satoh Javaとかで先祖返りしたわけで、いったん並行オブジェクトにもどるしかないとのでは

Masayoshi Hagiwara @masayh

@kimtea 書籍の準備はしようと思ってますが、その前に検証が必要です。理論的に正しいだけでなくて、実際に使ってみていろんなフィードバックがないといけないので、すぐには難しいですね。

ICHIRO SATOH @ichiro_satoh

悩ましいのは、例えば並行性一つとっても、どんな並行性があって、それをどこまで見せるかがまだ見えていない。RT @masayh: そう思います。でもって、実践との融合で方法論や言語仕様との摺合せをしてフレームワークやらDSLで間を埋めるのかなと思います。

ICHIRO SATOH @ichiro_satoh

勉強になります。@across_the_view: 初めまして。オスロ大学の博士審査では、defenderが3人のoffenderとそれぞれ持ち時間約30分で公開の場で闘います。ただし聴衆は質問してはいけないという仕来りがあるようです。危うく、質問した最初の聴衆になるところで…

浅海智晴 @asami224

OOAのアクターはシステム外のオブジェクトのこと。お願いはできるが制御はできない。お願いして観測するのみ。システム内のリソースとアクターの持っているリソースではモデリング上の扱いが異なる。

浅海智晴 @asami224

伝統的なWebアプリのアクター：システム内リソース比率が1:9とすると、クラウドアプリの場合ものによるけどマッシュアップでリバレッジをかけたものはたとえば9:1といったことになる。システム外リソースに対する比重が全く違う次元に入ってくるのでモデリングのバランスも変わってくる。

浅海智晴 @asami224

枠組みが根本的に変わるのと同時に、いままで軽く流していた所の精度を上げていくことになる。

浅海智晴 @asami224

遅延、故障をOOA的にどのように見せるかというのもある。利用者に隠蔽できる場合にはOOA的には見えてこないけど、利用者介入があるならOOAでハンドリングが必要。

浅海智晴 @asami224

クラウドアプリは、いざとなったら利用者介入でリカバリするという保険を前提に、コスト削減、体感性能向上が得られる、と考えてみる。保険が効かない応用では、今まで通り要塞型のシステムが無難。リカバリ不要な応用は保険もいらないのでクラウド向き。

浅海智晴 @asami224

故障、遅延を利用者にどう見せるのかというのはUX, UI的な扱いも重要になってくる。この要素をOOAでも扱っていかなければならない。もちろん、ボタン押下とかそういうのがOOAに入ってくるという意味ではないけど。抽象UXとかビジネスUXとかそういう切り口。

浅海智晴 @asami224

OOADは静的構造、状態機械、協調が三本柱。静的構造と状態機械は宣言的に書けるけど、協調は帰納的、imperativeで宣言的でないことが弱点。