今日のつぶやき
loudtwitter今日も動かなかった。なぜだろ。 #
GData,twitter,evernoteといった所をマッシュアップしてアプリケーションを作る時の、ドメイン・モデルとは。まず利用者IDの集約がいるね。認可はサービスごとに異なることを前提としたモデルになる。 @myen #
既存サービス(GData, twitter, evernoteなど)は実装への写像が補償されたドメイン・モデルを事前に提供して、そのまま使ってもらう。つなぎの所は、自動的に適切なアダプタが自動生成される。 #simplemodeler @myen #
Amazon A2Sとかをカバーすると電子商店とかできるなぁ。google checkoutやpaypalもある。改めて考え見ると、すでにクラウドだけで大抵のことができるようになっている。 @myen #
クラウドではスクラッチでアプリを作るということがほとんど考えられないので、既存サービスをモデル上でも手軽にきれいにマッシュアップできるのが、モデリング技術の課題。 @myen #
利用事例がサービスを結びつける糊。利用事例と領域模型の追跡性をいかに担保するか。これは #simplemodeling と #simplemodeler で工夫している点でもある。 @myen #
利用事例はさらに商売目標と連結されていなければならない。商売模型の商売利用事例と電脳模型の電脳利用事例の追跡性。商売模型は要求開発の方式がよいだろう。ここに雲役務の模型を足し合わせる。 @myen #
利用事例を実現するための(雲)役務をリストアップして、強調の糊で結びつける。既存役務でカバーできない活動を役務として新規に開発して、糊で結びつける。 @myen #
役務の持続性を考えると算譜は静的型付のJava, Scala,糊の方は動的型付&超越&閉包(関数型)でRuby, JavaScript、 #
といった所が候補。Scalaは糊の方にも使えそうだけど、重たいかなー。超越がないのが微妙に効いてくるかもしれない。 @myen #
糊で案外来るんじゃないかと考えているのがJavaScript。クライアントはHTML5&JSでGUIやったら、サーバ側フロントの糊もJSでええんとちゃう、ということ。糊にクラス指向OOは必ずしも必要ないし、逆に超越の価値は非常に高い。 @myen #
クライアント(HTML5)とサーバ糊はJavaScript、サーバ役務はScalaでどうだ。 @myen #
言い直し。UI, 糊(クライアント、サーバ)はJavaScript。役務はScala。 @myen #
javax.script.ScriptEngine #appengine のwhite listに載ってるやん。少なくてもJavaScript(rhino)は動きそうやね。 @myen #
糊と役務を一つの算譜言語でカバーするならGroovyという手もある。Scalaの糊利用は重たそうな印象。ただ、糊にJavaScriptを選ぶなら役務は関数型readyのScalaを選びたい。 @myen #
appengine pythonを使った印象では、python & djangoはwebサイトをさくっと作るのにとても向いている。ただ、pythonは超越持ってないので、糊として効果的に利用できるのかが未知数。 @myen #
tag(category)はpowertypeという意味合いが強いけれど、state的な使い方も多用される。GTD的な利用方法では利用者は自然にstate transitionの操作を行っている。GTDは分類を従、状態を主にした所に革新がある。 @myen #
分類が従、状態が主のGTDがクラウド的なアプリケーションの振舞い。とすると、クラス指向の電脳算譜との相性問題が出てくるね。プロトタイプ指向なのか関数型なのか。超越の価値も上がる。いずれにしてもJavaという選択肢は小さくなる。 @myen #
関連を振舞いに写像するのは色々なパターンがありそうやね。どのようなstereotypeを導入するのか、DSLでどのように記述するのか。アプリを作りながら整理していくのが効率的。 @myen #
RT @yasushia: @asami224 ThriftはScalaも対応してたような、と思って検索したらgithubにありました github.com/robey/scrooge #
ESTA申請完。ぐぐったら怪しげな申請代行業者がスポンサーリンクに出てきた。転記だけで$50かぁ。.usドメインとかなのでうっかりしたら引っかかりそう。.govドメインだと無料。 #
ありゃりゃ、ESTAの申請情報をevernoteでクリップしたらデータの載ってないテンプレートだけとれた。やるなーUS。この手の情報のノートは画面キャプチャがよいということやね。 #
RT @shin1ogawa: Google、Twitterとリアルタイム検索の取り込みで提携 - ITmedia エンタープライズ ff.im/ag5V4 #
association, aggregation, compositionの使い分け、特にaggregationの使い方が難しく、aggregationは使わないというアプローチもある。DSL的にはこのaggregationをうまく活用したい。 @myen #
twitterとbing, twitterとgoogle trunc.it/2s1w8 @myen #
#wave 協調して活動するためのアプリはこんな感じになるのか。 trunc.it/2pcjd @myen #
#wave はただコミュニケーションするだけでなくて、成果物を一緒につくるというところがポイントだなぁ。協調して成果物を作る系の応用でかなり使えるかも。 @myen #
閉包をトランザクションに登録して、楽観ロックエラーでの再実行。ウィンドウの再描画のイメージ。 @myen #
associationやassociation classをKVSでどう実装するか。文脈依存の場合はどうするか。DSLでどのように表現するか。 @myen #
ウィルスソフトはMSの正規品が無料なのか。今度ライセンス切れたら乗り換えよっと。 #
atom:linkが曲者やねぇ。DSLでどう見せるか。ドメイン・モデルからクラウド・リソースとのリンクにどのように使うか。工夫の為所だ。 @myen #
KVSを内部スキーマ、AtomPubを外部スキーマの一つとすると、概念スキーマはどうなるか。AtomPubを概念スキーマと考えるのはやや軽い。 @myen #
ローカルメモリ、共有メモリ(memcache)、KVSレコード、KVSパーティション、データセンター、グローバルの6階層で考えてみる。 @myen #
KVSは、いずれ巨大な記憶空間を提供することになるメモリDBをフロントにしたアーキテクチャを前提に考えていかないと中長期的な技術の方向性を見誤るかも。 @myen #
6つの層それぞれのscopeに応じたaggregateが存在しておりミニ木構造を構成している。この木構造を接木してグローバル木構造を構成する。パス言語によるアクセス、問合わせ。ツリーオートマトン。概念スキーマはこのあたりに落ち着くのか。 @myen #
atom:linkをassociationと考えてみる。relはassociation roleか。この方針で考えてみると領域模型での扱い、DSL上での表現も見えてくるね。 @myen #
Automatically shipped by LoudTwitter