今日のつぶやき
またまた、Twitter APIの調子が悪かったらしく昨日の分が自動ポストされてませんでしたので、手動で書いておきます。このためいつもと逆順(新しいのが上)。
投稿時間変えよっと。
evernoteはApache ThriftのRPCベースのAPIを提供してるみたい。JavaとPythonの言語バインディングもある。twitterに何か入れたらevernoteとGDataにプッシュというようなbotも面白そう。 @myen
GData級のサービスを作るならさすがにJavaがよいかも。でも、この手のWeb向け重量級サービスを書くならScalaの方が明らかに楽だよなぁ。 @myen
GDataを改めてみてみるとすごいことになってるやん。HTML5+GAE+GDataで大抵のことができるんちゃうの、と思ったり。HTML5はJSとして、GData糊付けするだけならPythonで十分かも。Javaはどこで使うんだ。 @myen
tweeteがiGoogle様のリフレッシュで消えた。
AtomをJSON representationでって思いついたんだけど、GDataは既にやってました。HTML5 & Open Web Platform with AtomPub as JSONがいい感じかも。 @myen
AtomをJSONにエンコードして配信するのはあるなぁ。ゲートウェイを作れば一般化もできそう。 @myen
javascriptでxml parseするのは技がいるんやね。HTML5で汎用AtomブラウザUIフレームワークがあれば面白そうだけど、まだ敷居が高いかな。 @myen
evernoteのUIみてると、裏側はatomかもって思ったりして。entry(note)が木構造化（スレッド化)できないのもatom由来かも。一般論としてはlink使ってオレ流すればスレッドみたいなこともできるはずだけど、これはアプリ独自になる。 @myen
#atom linkでこんなの見つけた。 http://trunc.it/2rhl4 @myen
atomのlinkも使い出がありそうだ。relの使い方の世間相場はどこかにまとまってないかな。 http://trunc.it/2osqr @myen
atomのcategoryをどのように扱うかな。メタ情報をちゃんと管理できるようにしないと。 http://trunc.it/2slk0 @myen
センターグリル。ｲﾏｺｺ! L:神奈川県横浜市中区花咲町一丁目32
浜ランチ http://f.hatena.ne.jp/twitt...
#simplemodeler goal: 利用者オブジェクトはバージョン・ミスマッチの問題があるので、SerializableでDataStoreに格納するのは危険。simplemodelerでXMLにエンコードして対応する。 @myen
TaskOptionsはSerializableやん。DataStore readyやね。 @myen
不揮発性キューの場合、フロントはmemchache&TaskQueueでよいとして、タイムアウト起こしたらDataStore&Cronでよいか。CronでTaskQueueを起動しまくりアーキテクチャでいけそう。
TaskQueueでpub-sub:これも登録されたハンドラをすべて呼び出すようにすればよいか。entry urlとhandler urlsの対応をどこかで管理。揮発性キューでよいならすぐにできそうやん。 #appengine @myen
TaskQueueでpeer-to-peer：普通にURLを叩いてハンドラをやればよい。entry urlとhandler urlの対応をどこかで管理。 #appengine @myen
#appengine に引き写すとAtomPub & TaskQueueということやねぇ。 @myen
クラウドでのコンポーネント、クライアントはREST/JSONでよいとして、サーバサイド・マッシュアップはAtomPubとメッセージングが鍵になる、と考えてみる。 @myen
evernoteはノートを木構造に組織化できるともっといいんだけどなぁ。Waveのスレッドみたいな感じ。
文脈⇒協調⇒利用事例、という写像はある。利用事例の集りの共通文脈を領域文脈として扱うのか。協調における役割。協調と領域模型を写像するDSL文法は工夫のしどころやね。 #simplemodeler @myen
aggregateとかscopeといったものを導入して文脈を宣言するという手はあるなぁ。文脈からの相対位置でクラウド文脈へのマッピングを定型化できる。複数の文脈に別のロールで参加してもよい。 #simplemodeler @myen
#scala のmatch文、いい。
java(programming) + xml(dsl + presentation) ⇒ scala(programming + dsl) + xml(presentation) ということか。 @myen
XMLは分散技術のmissing linkを埋めるすごい技術なんやけど、DSL用途については向かんかった。この機能は #scala を使うことにした。というのが個人史ということやね。改めて考えてみると。 @myen
SQLの言語埋め込みでも四苦八苦だったのに、いわんや木構造をや。言語埋め込み→言語のScalability→Scala、とかとか。 @myen
ScalaはDSL、XML、forを使った問合わせ(つまりモナドを使った問合わせ)という点からもクラウド時代のプログラミング言語として申し分ない。 http://www.slideshare.net/a... @myen
木構造は再帰でプログラミング言語に結びつく。この点で関数型の得点が上がる。関数型、DSLとくればScala。Scalaのfor comprehensionで問合わせ。 http://bit.ly/UsJbh @myen
問合わせ言語の機能は(1)検索・集計と(2)プレゼンテーションの再構築。SQLは(2)が表構造だったので、(2)の重要性が意識されにくい。次世代は(2)が木構造になるやろけど、木構造の表現方法、組み立て方のDSLが論点になる。 @myen
クラウド・ミドルウェアの重要課題が問合わせ言語。SQL使えないから。XSLTやXQueryが面白そうなんだけど、XMLがDSLに向かないのでハードルが高い。LINQは.NET縛りが難点。次の局面では、ここで戦争が勃発するね。表構造から木構造へ。 @myen
GoogleのProtocol BufferはASN.1やね。OS内でXML使うのは軽すぎるということ。
地味だけど、クラウドでもXMLは重要技術。AtomPubもあるし。XMLがDSLに向かないというのは結論がでたけど、Presentation Protocolとしての価値は落ちていない。
仮想化のメリットは、そのままクラウドのメリットになるねぇ。さらには端末1万台ぶら下がったシステムのテスト環境を数セット用意するとなるとクラウドでないと賄えない。クラウド化必至ということやね。
そうか。仮想化使うとテストで本番システムと同じ構成を簡単に組めるね。 http://bit.ly/aVEuB @myen
