OSGiは色々なJVM向け言語を走らせるのに最適なフレームワークではないだろうか。clojureとかのっけてみようっと。
興味があるのは向きが逆なヤツでclosure on OSGiってなところだ(EclipseにはE4 JavascriptというJavascriptでOSGiバンドルを作る話がある)。
標準の役割が少しずつシフトしてきているように思える。CORBAやEJB 2.0の頃とは隔世の感がある。
aegif blog: Alfresco Maven Repo
CMS的な要素はほとんどの業務系アプリケーションに不可欠だ。有名なECMSエンジンのView層がSpring Surfとして利用できるというのは面白い状況だと言える。
Ymacs — AJAX source code editor with syntax highlighting and automatic indentation
残念ながら、ブラウザでelispが走るわけではない。(w
apdfviewer - Project Hosting on Google Code
Androidで使えるPDF Viewerがやっとでた。そうか、でたのか。ぢゃ、NetWalkerはどうしよう(w
InfoQ: RESTfulie - ハイパーメディアを意識したサービスとクライアントを生成するGem
記事は分かり難いのだが、GETやPUT以外のビヘイビアをハイパーリンク（が示すリソース）と結びつけるという話らしい。ページにAtomでの例が記載されている。
WS-*に対応する機能は語られない形でRESTにも存在する。ただ、それがRESTとしての標準的な使用方法という形で認知されなければ意味がないという事だろう。
InfoQ: JDK 7が、突然”単純な”クロージャをサポート、しかしリリースは、2010年の終わりに。
いったい何を揉めているんだろう？シンタックス的にもセマンティクス的にも微妙なのは覚悟の上で、エイヤっと載せるしかないというのは明白なのだが、民主的に進めるのは難しいという事か。
個人的にはJavaがこれ以上複雑になるのはどうも気が進まない。
OSGiとモジュラリティ
今日、同僚とOSGiの話をチラっとした。モジュラリティというルールのゲームの中では、「何が出来るか？」ではなくて、「何をするのか？(しないのか？)」という事がずーっとクローズアップされるのではないかと思うようになった。多分、それが「インテグレーションの時代」の到来という事なんだろう。
モジュール化とか、オープン・イノベーションとかその辺で議論されていた事が現実の世界で大きな意味を持つようになってくるんだと思う。
後輩に説明しようと思ってググったら出てきた。というか平鍋さん、こんな記事書いていたんですね。
TPS(Toyota Production System)をベースにしたリーン開発では、サイクルタイムの短縮は重要な指標の一つになる。サイクルタイムのターゲットになるのはプロセス全体だけとは限らないので、色々なレベル（例えば、開発中のバグ発見→修正→確認とか）で見てゆく事が重要。
中でも、在庫に例えられるように記述・蓄積された情報は放置すれば放置しただけ劣化してゆく。こうした劣化による非効率を防止するためにもサイクルタイムの短縮は重要だ。
ただ、より大きなスコープで見たときに無駄な作業の繰り返しになっていては、個別の効率化が進んでも意味がない。プロセス全体から着実にブレークダウンして全体のサイクルタイムを向上させるという視点をチーム全体で共有する事がやはり重要なのだ。
木を見て森を見ず、また、概要だけを見ていて細部に宿る現実に目を向けないの問題と言うところ。サイクルタイムの短縮は様々なレベルで現実を計るための重要な指標で、待ち行列理論が示唆する単純なメカニズムに従っているので、チームで共有しやすいのだ。
