今日のつぶやき - goldenportのブログ

コンパイラのような重たい変換器を #appengine 上で実現しようとすると30秒制約が厳しい。コンパイラのパイプライン処理ごとに処理を切ってtask queueでつなげるのが基本だけど、各段が30秒を超える可能性も考えないといけない。 #

コンポーネントを疎結合にする意味として今までは再利用という意味が大きかったけど、task queueでつなぐ単位としても、より実用的な意味が出てくる。 #

operation呼出しモデルではなくて、event駆動モデルでtask queueつなぐコンポーネント。クラウド・アプリのビルディングブロックとしては、ここを起点に考えるとよさそう。 #

task queueでつなぐのか、不揮発性のMQでつなぐのか。そういったところはアプリケーション・アーキテクチャ的な視点で選択できるコンポーネント・アーキテクチャを取りたい。 #

サービスとコンポーネントを同じ層で扱うか階層化して扱うかということも考慮点。階層化した方が性能的には得策だけど、アーキテクチャが複雑化する。 #

#scala をスクリプト言語として使うのもなかなかよい気がしてきた。
("" /: System.getProperty("line.separator"))*1 とかが簡単にできる。 #

スクリプト言語的にも文法がこなれているのと、Javaクラスライブラリがフルセット使えるのが大きい。まあ、このあたりはJRubyやGroovyも同じですが。 #scala #

コンポーネントがリアクティブに動くメカニズムとコンポーネント内のエンティティがリアクティブに動くメカニズムは階層化して作っていく感じか。なんだかウィンドウマネージャみたいだ。 #

ユースケースからリアクティブシステムを抽出する場合に鍵となるのは、リソースの状態遷移。状態遷移を確定させないと、リソースに対するアクションを疎結合で結びつけることができない。 #

リソースの状態遷移に対するアクションの集合でシステムを記述するとすると、これが利用者の目標に合致しているのかを検証するメカニズムが必要。ユースケースのコラボレーションからのフローの解析と、状態遷移の突合が基本線。 #

日本の出版社が直面するイノベーションのジレンマ - My Life in MIT Sloan - BLOGOS（ブロゴス） - livedoor ニュース ff.im/eRlYC #

NHKのニュース見てたら、うちの冷蔵庫がリコールされてた。 #

Automatically shipped by LoudTwitter

*1:i, j) => i + "%04x".format(j.toInt