石川さんのところに行ったときに「テクノロジーは世界をインターフェースする」という話を聞いたのですが、その元ネタがこれ、「Designing World-realm Experiences:The Absence of World "Users"（世界経験のデザイン＿"世界"に"ユーザー"はいない）」。 書かれたのはリビングワールドの西村佳哲（にしむら・よしあき）さん（参考記事：リビングワールド：世界を感じるものづくり）。様々なデザイン活動でも知られていますし、最近では自分の仕事をつくるという本でも有名です。 で、西村さんが1999年に書いた文章。かなりシビレます。長い抜粋。 デザインとは、インターフェイスすることであって、インターフェイスをつくることではありません。私たちは、他の人々や生きている世界と接したいのであって、コンピュータなどの情報機器や、インターフェイスデザインと接したいわけで

2008年2月8日に行われたVoIP Confarence 2008にて、SIPropプロジェクトのメンバーとして講演をしてきました。プレゼン資料はこちらから。 SIPropについて SIPというのはSession Initiation Protocolの略で汎用的なセッション管理のプロトコルです。HTTPはステートレスなんでセッション管理はCookieを使って実現しています。一方のSIPではプロトコルそのものがセッションの維持を保証してくれます。 このSIPはVoIP（ボイス・オーバー・IP）、ようはIP電話の制御プロトコルとして利用されていることで有名です。ちなみに、僕も勘違いしていたのですがSIPの上を音声パケットが通るわけではありません。SIPはセッション管理しかせずに、シグナリング、電話で言うならば呼制御をしています。電話が鳴るとか、受話器を上げるとか、電話を切るとか、そういう

さて、電話とWebの融合ってなんやねんということなわけですが、くだらなくて秀逸な事例を。 セクシーなCMで有名なAXE。そのキャンペーン、AXE WAKE-UP SERVICE Inc.は美女がモーニングコールをしてくる、というモノ。 さて、実際に予約をするためにはイタ電防止のために自分の電話であることを確認をする必要があります。そのため電話をかけるのですが、その時に自分のかけた電話に画面の中の美女が出てくれて、話しかけてくれるという演出になります。これが、なかなか萌えます。もちろん技術的に。あまりに技術的に面白くてニヤニヤしてしまう可能性があるので、人前ではやらないことを強く推奨します。 これをアーキテクチャとして書いたのが以下の図です。電話とWebの機能がきちんと連携しています。 ここではプッシュボタンの入力を予約番号の確認にしか使っていませんが、たとえば美女と会話できる仕組みにするこ

Web2.0 Expoでベスト講演をあげるとすればチームラボの猪子さんによる「インターフェースデザインのイノベーション（テクノロジーとデザインの境界線があいまいなもの）」です。これはヤバイ。 以下、サマリ。 サーチやマッチングというテクノロジーがあるおかげで、Webにある情報はサイト内外の情報を動的に再編集して構成されるようになった。だから、そのリンク構造も動的。当然、サイトマップやきれいな階層構造なんて存在しない。 サイトの構造が動的なんだから、インターフェースも当然、動的だよね。逆にインターフェースが構造の動的さを引き出して魅力を出さなきゃいけない。 テクノロジー（構造）とインターフェースは切り離して考えることなんてできない。一体なんだよ。 いえーい！も、マイナビバイトも、SAGOOLも、Laboo!も、そうやって作った。 これって「インターフェースの革新の本流」。すごい西洋的。iPa

都内某所にてエンジニア話で盛り上がったのですが、そのときに出てきたのが「グローバルではPHPできないと話にならん」という話題。確かにPHPで作られたOSSというのは非常に多くて、たとえばSugarCRMとかもそう。USでも大手ユーザー企業でもPHPを重視しているところがあるそうです。 一方でRubyやJavaというのは開発者にとって"Sweet"な言語ではあるもののユーザーには難解。ユーザーにとって使いやすい言語という点ではPHPが非常に洗練されているのではないかと。 もちろんPHPが簡単だからって、へぼ開発者が作ってしまうとメンテナンス性も何もない、ということをいうことはできます。でも、ちょっと考えてみると、それは作り手の視点なのかなと。使い手の視点からすればPHPという言語はよくできているということではないかと。 つまり、世の中でコーディング作業をする人は「モノを作るためにやる人」と、

良い悪いは置いておくとしてRubyOnRailsはStrutsになるのだなと感じています（エンタープライズ開発でデファクト・スタンダードになって一定のポジションを獲得する）。先日のRubyKaigiでの話し、あるいは最近のエンタープライジーな企業のプレスリリースを見ていると着実にその道を歩んでいるようにみえます。特にSUNがJRubyへのコミットメントを強めている中でJava環境でもRailsが使えるという期待感が強まっており、この傾向に拍車をかけているようです（既にJRubyの上で動きます）。 背景としては金融･内部統制景気が続く一方で、中大規模のSIerでも小粒案件（1-4千万円）をちゃんと利益出してやっていこうよ、みたいな流れがある気がします。これまではプロダクトなどでカバーしていましたがOSSの発展や顧客ニーズの多様化によってSI案件化せざるをえなくなってきた。でも社内の標準フレー

なんか盛り上がっているので参加してみます。火元はこちら。 頭数論はSI業界の確かな事実 別に藤田氏の言い方に違和感は覚えません。SI業界では確かな事実です。 SI企業の事業計画を考えてみると良く分かります。SI企業に対するM&Aをされている方から聞いたのですが、買収先の企業に事業計画書を作らせると、目標売上の数字に対して人月単価で割り算した人数が記載されているそうです。その売上の実現性は営業による案件の獲得でもありますが、重要なのは人材採用計画に他なりません。 つまりSI企業の事業計画とは人材採用計画のことであり、売上は人数に比例して増えるのです。 Web2.0企業では頭数に意味はない で、藤田氏の発言に対して「理解が足らん」というメッセージが多く見受けられます。それは、もちろん正しい。 実はWeb2.0的なサービス企業は「理解が足らん」という話だけで頭数論を回避できてしまうのです。

TuscanyはエントリしないくせにAJAX Toolkit Frameworkはエントリします（だってSCAが理解できなかったんだもん）。 日本時間20日深夜にApache Incubatorあてに"AJAX Toolkit Framework"が提案されました（提案書のメール）。 これZimbraとIBMのエンジニアが中心というから驚きました。ZimbraといえばBEA Systemsの元CTOスコット・ディッゼン氏を引き抜き、カレンダー、メールなどを含むZimbra Collaboration Suiteをリリースしたことで知られるベンチャー。 しかも、そこらのAJAXフレームワークとは考えていることのでかさが違います。EclipseプラグインとしてAJAX/DHTMLのIDEを提供がメインになるようです。 a JavaScript editor with edit-time syn

arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ とある記事のお仕事でオープンソース・プロダクトを現場に導入するためにはどうしたらよいか（そもそもはDIコンテナを採用してもらうには）という内容を書こうとしたのですが筆が止まってしまいました。 友人とも議論したのですが、この話を突き詰めると「責任の所在」という根本論になってしまい、なかなか書きにくいからです。 責任論でオープンソースを語るのは間違い オープンソースには様々な利点があります。 メリット1　コモディティ化の原理で、共有されているからこそ品質が良い メリット2　コードが見れるので、問題が生じてもなんとかできる可能性がある それでもなおオープンソースを採用しないのは「責任が取れない」という理由からではないでしょうか。自分で責任を取らない（責任は誰かに取って

またも独り言。 「ハッカーしか扱えないけど、ものっすごく効果的」というものよりは、「それなりの人が扱えて、それなりに効果的」なほうが受け入れられるのではないかという気がしてきました。それって、ある意味のオープン性ではないかと。 その証拠として考えているのがWebサービスとStrutsと"はてな"です。 Webサービスはただのメッセージ交換 Webサービス（SOAといってもよい）というのはデータメッセージングに過ぎません。分散コンピューティング技術で考えれば、CORBAよりも簡単だしJiniなんか比較にならない。当初のSOAPはセキュリティも考えちゃいないしメッセージ種別も同期のみ。でも普及できたのはリーチがある技術だったからです。 XMLなわけだからプログラミング言語やOSを選ばないどころか、EXCELでもいいし手書きしてもいい。マイクロソフトアプリとJavaアプリが会話できるのもWe

arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 今回はちゃんとしたハックに近い気がするのでちゃんと説明してから（笑）。 ブックマークレット 前回とは異なり「自由にユーザーや地図の位置を替えられる」ようにします。9月9日の機能アップによって、はてなマップに個人ページが用意され、個人のはてなフォトライフデータをロードすることが可能になったのでこれを利用します。 しかし、Ajaxで困り者なのはセキュリティの関係上、XmlHttpRequestで他ドメインの情報をロードできない点です。これを回避する方法はいくつかあるのですが今回はブックマークレット（Bookmarklets）にしてみました。 ブックマークレットとは、ブックマークにURLの代わりにJavaScriptを登録し、欲しい情報があるドメインのページを表示した状態

最近、再びStrutsをいじるようになったことで、あらためてStrutsのアーキテクチャが古くなったことを感じた。Strutsは2001年ごろに開発されたものであり、1.X系は、現在もそのアーキテクチャを引き継いでいる。そのため、去年あたりから注目されているPOJOやDIという概念に対応していないのだ。 POJOへの未対応でわかりやすいのは、ActionFormの存在だ。ActionFormの責務は、reset、validate、そしてマルチパートのハンドリングだ。つまり、入力情報に関わることは自分で処理するというオブジェクト指向らしい考え方である。しかし、現在であれば、ActionFormをPOJOにしてしまい、validateやresetは、Actionにおいて実施すればよいと考えるだろう。すぐに思いつくメリットとしては、Strutsから先のビジネスロジックに引数として渡しやすいこと。