ピュアAJAXアーキテクチャのススメ
先日、ここで発表したFacebookユーザーむけグループウェア「Fruence.com」。今年のトレンドになるであろう「ソシアル・アプリ」の実例という意味もあったが、私自身の中で少し前から形になりつつあった「AJAXを最大限に活用した新しい形にウェブ・アプリケーション」のアーキテクチャの実践という意味合いも大きい。 このアーキテクチャの特徴は以下の３つである。 サーバー側は、JSON over HTTPのAPIとHTML/CSS（およびそのテンプレート）をスタティックな形でのみ提供する（サーバー側では、ダイナミックなHTMLの生成はしない） クライアント側では、JavaScriptを使ってサーバーから取得したJSONとHTMLのテンプレートを組み合わせて（データ・バインドして）表示する。 ウェブサイトはあたかも独立したアプリのように動き、操作中はURLは一切変化しない もともとは、HTML
UIEngine、自動車に載る（Toyota Entune）
今回のCESではいくつもの発表があったが、その中でも私として一番うれしかったのが、Toyotaが発表したEntune。米国のトヨタ純正カーナビには、bing（検索）、Pandra（インターネットラジオ）、MovieTickets.com（映画情報）、OpenTable（レストラン予約）などの「アプリ」が走るのだが、そのアプリとアプリのローンチ画面のUIを担当するのがUIEngineなのである。 UIEvolutionは、私が２０００年に「これからはいろいろなデバイスがネットに繋がり、その結果、さまざまなプラットフォームが乱立する戦国時代に突入する。その問題を一気に解決するのがUIEngine。携帯電話から、テレビ・自動車・冷蔵庫までいろんなデバイスにUIEngineを載せて組み込み機器のUIの開発を大幅に簡単にする」というビジョンを掲げて起業した会社だが、１０年たってようやく自動車に到達。
Facebookの使い方：実践編
日本ではまだまだ普及率は低いが、今年中にも１０億人ユーザーに達すると予想されるFacebook。今年の夏前には、「Facebookの使い方」のたぐいの本が日本の本屋さんに平積みになっている様子が目に浮かぶ。 単純な「Facebookウェブサイト使い方」は、その手のガイドブックに任せるとして、私がどんな風に使っているかを実例を使って説明しよう。 先日書いた、「ピュアAJAXアーキテクチャのススメ」というエントリーに対して、「BigPipeに似ている」というコメントをTwitter経由でいただいた。そこで調べてみると、「BigPipe: Pipelining web pages for high performance」という論文が見つかった（Facebook内のNoteという仕組みを使って書かれており、誰でもアクセスできる設定になっている）。 読んでみると、私のアプローチとは少し異なるが、そ
iPadアプリ作成日記：書き心地重視のneu.Notesリリース！
先日予告した「書き心地重視の『手書きメモ』アプリ」、ようやくiTunesストアに並んだのでここで発表させていただく。名前は neu.Notes（"neu"はドイツ語で「新しい」という意味)。読み方は「ノイ・ノーツ」。日頃のちょっとしたメモや、ミーティングや授業のノートを取る時に便利な様に、使い勝手と書き心地を最重視して作ったアプリ。無料なので、iPadをお持ちの方は、ぜひともお試しいただきたい（iTunesストア上のneu.Notesへのリンク）。 これを作るきっかけを与えてくれたのは、Adobe Idea。最初に見た時には「やられた」と思った。簡単なメモを取るには十分な機能があるし、何よりもベクター・データのままIllustratorに渡せるという部分がすばらしい。描いた線をなめらかにしてくれる機能もなかなかしゃれている。これで私にとっての「メモアプリ」の座は決まりだと思った。 しかし、
Google App Engine上のベスト・プラクティス、その１: Datastore
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
誰にでも分かる「クラウド」
ここの所、「クラウド」という言葉が一人歩きしているようなので、言葉の定義を明確にして業界関係者間のコミュニケーションをスムーズにすることを試みてみたい。 クラウド・コンピューティング もともとは、すべての計算をクライアント側で行う「デスクトップ・コンピューティング」に対して、（しばしば雲の形で図式化される）ネット上のサーバー側で計算してしまうことを表すために生まれた言葉。しかし、後述の「クラウド・サービス」の普及とともに狭義・広義・誤用・バズワード化が進み、今や「ユビキタス」と同じぐらい使っている人によって意味が異なる言葉になりつつあるので要注意。 クラウド・サービス アマゾンのec2、GoogleのApp Engineのようにサーバーの能力を従量課金方式で提供するサービスのこと。自社サーバーやレンタルサーバーと比べて、初期投資の面でもスケーラビリティの面でも優れていることが特徴。 クラウ
jQBinder, ブラウザー側でのHTML templateを可能にするjQuery plug-in
一昨日はMVCの話で妙に盛り上がってしまったが、考えてみるとModel/View/Controller間の分離が不十分という話はサーバー側だけの話ではなく、クライアント側にも言える事。事実、私自身も div.innerHTML = "<span class='red'>" + message + "</span>"; みたいなHTMLが混ざったJavaScriptコードを書く事は良くある。特に、最近はJSONとして取得して来たデータセットをリストとして表示するケースが増えて来たが、そんな時に「サーバー側のようなHTMLテンプレートが使えたらいいな」と思う事は良くある。手っ取り早くとりあえず動くものを作るのにはHTML埋め込み型のJavaScriptで良いのかも知れないが、後々のメンテナンスを考えると少なくともModelとViewぐらいはキチンと切り話しておいた方が良い事は確か。 ということ
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
ターゲット・ユーザーとユーザー・シナリオを絞り込んで大手との直接競合を避けるビジネス戦略
PhotoShareがiPhoneユーザーのみを対象にしていることに対して、「なぜ他の携帯電話もサポートしないの」「なぜウェブから写真を投稿できるようにしないの」という質問を良く受ける。 答えは単純で、「新しい会社で全く新しいサービスを作るのだから、ターゲット・ユーザーとユーザー・シナリオを絞り込んで、大手SNSサービスとのはっきりした差別化をはかる必要があるから」である。 ふたたび、今読んでいる"Marketing Management"（MBAの教科書）から引用する。 Successful new firm formation typically requires a competitive strategy that delivers superior value to a narrowly defined target segment in a way that either av
iPhone 3Gに関しての続報
3G版iPhoneに関しては、昨日の速報のあとも色々と情報が入って来た（情報を発信するとさらに情報が集まってくるという良い例）。一番興味深いのが、ジョブズによる基調講演では明らかにされなかったビジネスモデルの変化。３G端末に関しては、レベニューシェアは行わず、通信キャリアからアップルへ一括で支払われるインセンティブ型のもの（日本の販売奨励金に近いもの）となるそうである（参照）。 それが「一台あたり○ドル」なのか「何台売ろうとミニマムコミットメントは○百万ドル」なのかは公開されていないが（たぶん、キャリアごとに違うのだろう）、少なくとも一台あたり２００ドル前後だろうというのが業界の予想（というか常識）である。 ジョブズの現実歪曲空間の強さがキャリアの旧来型のビジネスモデルをぶちこわしてくれると期待していた私としてはいささか残念だが、７月１１日に世界２２カ国で同時発売というスピードのためには、
Life is beautiful: 法律の勉強：著作権法で保護されるのは「特定の表現」であり「情報そのもの」ではない
先日、著作権に関するとても興味深い話を弁護士の人から聞くことができた。実際にあった法廷闘争に基づく話だが、トピックは、「他の人が書いた料理の本に乗っているレシピを参考に、似たような料理の本を出版した場合、どんな法律を破っていることになるか」という話である。 適用できる法律は、著作権、特許、登録商標の三つ。それぞれについて考察を加えるとこうなる。 【著作権】このケースで言えば、著作権で守られているのは、文章そのもの・イラスト・写真。レシピそのものは著作権では保護されない。つまり、オリジナルの料理本の文章を丸写しにしたり、イラスト・写真をそのままコピーしさえしなければ、（材料・調理方法などが）まったく同一のレシピの本を書いても著作権法違反にはならない。言い換えれば、著作権で保護されるのは、「特定の表現」であり「情報そのもの」ではない。 【特許】レシピに特許権が成立するかどうかは微妙ではあるが、
米国の近代経営工学の手本になった日本の製造業
昨日も紹介させていただいた海部美知さんの「パラダイス鎖国」、草稿をアスキー出版から入手して読ませていただいているのだがとても面白い。最近の日本の「自主的鎖国」状況を彼女なりの考察を加えて解説した本だが、同じく「外から日本を見る」という立場にいるせいか共感できる部分も多くあり、楽しく読ませていただいている。 彼女の本にも、私と梅田氏との対談（「おもてなしの経営学」に収録...宣伝、宣伝^^）にも出て来る一つの共通する大きなテーマは、「なぜ高度成長経済の時期に、自動車だとかエレクトロニクスなどのハードを作る企業がこれほどグローバルな経済で成功出来たのに、時代がソフトやネットに以降した時に日本企業は世界の波に乗り遅れてしまったのか」という疑問。簡単に解答が見つかる話ではないが、海部氏の「パラダイス鎖国」論はその難しい質問に一つの光を差しかける。 ちなみに、MBAのクラスを取り始めてつくづく認識し
Life is beautiful: Microsoft／Yahoo：買収はたぶん成功するだろうけど、問題はそれからだ
今回のMicrosoftによるYahooの買収のオファー。ウェブの世界ではどうしてもGoogleに勝つことができないMicrosoftとしては、Yahooのビジネスはのどから手が出るほど欲しい存在。Googleに追い越され、成長に陰りが見え始めた結果株価が安くなったYahooは今がお買い得。WindowsとOfficeというドル箱を抱えながらも、そのドル箱が稼ぎだす莫大な現金をどこに投資すべきかがいまいち見いだせてないMicrosoftとしては、Yahooを買うことによりその価値を買収価格より高くする、というストーリーは説得力がある。 一方、Yahooの株主にとってみればこれは朗報。ずるずると下がり続けていた株に対してこれだけのプレミアムを付けてもらえば喜んで売るのが大半の株主。 少し悩ましい立場にいるのが、Yahooの現行の経営陣。株主利益を最大にするのが役割の経営陣とすれば、このプレミ
個人のブランド力を磨くことの大切さ
先日紹介したばかりの「リッツ・カールトンで学んだ仕事でいちばん大事なこと」。もう一つぜひとも引用したかった部分があるので、今日はそれの紹介。 ときどき、企業のブランド力を自分自身のブランド力と錯覚している人がいます。ところが、勤めている間は気がつかないものですが、バックにあった会社がなくなると、突然まわりが冷たくなるということが少なくありません。 よく、「会社を辞めたとたん誰からも相手にされなくなった」とか、「独立したら会社に勤めていたときの取引先に無向きもされない」などという話を聞きますが、それはその人自身に、ブランド力がなかったということです。 ◇ ◇ ◇ 横並びが尊重された時代にはブランドというものを身につける必要などなかったかもしれません。むしろ「出る杭は打たれる」からブランドなどないほうがよかったのかもしれません。 ですが、年功序列や終身雇用が崩壊した時代を生き抜いていくためには
Life is beautiful: スタバとアップルの提携が見せてくれるメディアビジネスの将来
Appleが最近申請した特許出願には、iPhoneユーザーを対象にした未来におけるキラー機能のヒントが垣間見える。コーヒーショップやその他小売店舗での商品注文をiPhoneから行うことで、（店舗内の）順番待ちの行列をバイパスできる、と言ったものだ。【TechCrunch Japanese アーカイブ » Apple、長い行列での順番待ち回避方法を特許申請より引用】 この特許そのものに有効性があるかどうかはいささか疑問だが、この特許やアップルが現在スターバックスでしていること（「店の中で流れている曲」を購入できる機能）を良く見れば、今後iPhone（iPod touchを含む）を利用したラテの注文および電子決済に進むのはほぼ間違いないだろうことが分かる。 スターバックスとアップルは、わずか数ヶ月前にスタバという実店舗とiTune Storeを連携させることを発表したばかりだが、「スタバのiT
交渉の場にのぞむ前にしておくべき心の準備
ネゴシエーション（交渉）に関するテクニックにはさまざまなものがあるが、その多くが「いかに自分の欲する条件に近いものを勝ち取るか」をゴールとしたもの。それはそれで役に立つのかも知れないが、私としてはどちらかというと、今読んでいる「Getting to YES（日本語訳：ハーバード流交渉術）」という本に書いてあるアプローチの方がしっくりと来る。 この本の筆者（Roger FisherとWilliam Ury）は、一般に良く使われる「交渉は勝つか負けるか」「相手に手の内を見せない」「自分はできるだけ譲らずに相手に譲らせる」などのテクニックは交渉を長引かせるだけだし、その過程で相手との信頼関係を損ねかねないと警告する。 この本にはいくつかの有効な提言が含まれているので何回かに分けて紹介したいと思うが、まず最初に紹介したいのは、交渉の場にのぞむ前に自分がしておくべき心の準備の話。 多くの場合、人は交
「渡された仕様書を実装するサラリーマンプログラマ」の悲哀
@ITの「業務用途でRubyを使う上での課題 」を読んでなんだか悲しくなった。 チーム開発でRubyを使ったときに今後起こりえる問題として、サン・マイクロシステムズ システム技術統括本部 チーフテクノロジストの下道高志氏は、こう指摘する。「他人の書いたPHPコードのメンテナンスはできない。Rubyはどうかといえば、現状はいい。しかし今後“職業プログラマ”ではなく、渡された仕様書を実装する“サラリーマンプログラマ”が増えてくると、コードのスパゲッティ化は避けられないだろう」。 【業務用途でRubyを使う上での課題 − ＠ITより引用】 これは言語の問題ではなく、日本のソフトウェア産業全体が抱える問題。以前にも「ソフトウェアの仕様書は料理のレシピに似ている」というエントリーで書いたが、本来のソフトウェア作りとは、絵を描いたり、音楽を作ったり、建物をデザインするのと同じ「創作活動」である。ドラッ
Life is beautiful: ソフトウェアの資産計上に関する素朴な疑問
会計の勉強をしはじめてから、今まで見過ごして来たようなことが気になるようになった私だが、最近一番気になったのが、日経エレの８月１３日号に書かれていた、Aplixの７６億円の特別損失の計上の件（参照）。要約すると、過去２年の間「ある顧客が買う予定」と言う名目で（経費としては報告せずに）資産として計上してきたソフトウェア資産を、「やっぱりすぐには売り上げにはつながらなそうだから」と一気に特別損失として計上した、というニュースである。 建物や原料のようにはっきりと形のあるものを資産として計上することは会計上もっともなことだが、自社で開発したソフトウェアやパテントのようなものを資産として計上することには非常に大きな危険がともなう。Aplixのケースのように社内で開発したソフトウェアが将来売り上げに繋がらないということはしばしばあるわけで、そんなにあやういものを資産計上されてしまっては、投資家はどの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
で、実際のところHTML5でどのくらいのアプリが実装できるのか実験してみた
Google Docs in Plain English