Ajax、PDA、自然言語――なぜあのとき失敗したのか
ソフト開発に関して言えば、Googleのアダム・ボスワース氏はスピードを必要としている。 「物理学、スピード、心理学：ソフトウェアで何がうまくいき、何がうまくいかないのか。それはなぜか」と題された講演の中で、Google副社長のボスワース氏は、Ajax、PDA、自然言語などの技術がなぜ過去にははやらなかったのに、今成功しているのかを語った。同氏は1月29日、Google NYC Speaker Seriesの一環としてGoogleオフィスで講演を行った。 ボスワース氏は、これまで約30年間ソフトを構築してきたが、常に「そのすべてがうまくいくわけではない」と述べた。「その理由は、振り返ってみると、主に物理的要素と人間心理によることが分かった」。同氏はまた、「その多くはトム・クルーズと関係がある」と語り、映画「トップガン」のトム・クルーズの台詞「I feel the need, the nee
Web2.0の先にあるC10K問題 ― ＠IT
個々のクライアントがサーバに要求する処理量は小さなものでハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする――。これが最近Web開発者の間で話題となっている「C10K問題」（クライアント1万台問題）だ。 プロセス番号が足りなくなる パンクするのは例えばプロセス番号だ。 Ajaxの実装として最近注目されている技術に“Comet”（コメット）と呼ばれるものがある。HTTPのセッションをあえて切断せずに、サーバとクライアント間でつなぎっぱなしにするテクニックだ。Cometを使えばクライアントからのリクエストに応えるだけでなく、サーバ側からも不定期に情報を送り出すことができる。例えば、Web上でチャットサービスを実装するには、通常はクライアント側からサーバに一定間隔でポーリングすることで、ほかのユーザーの発言分をサーバから取得して表示するが、Cometの
CNET Japan Blog - 江島健太郎 / Kenn's Clairvoyance：Lingr and Comet - 技術解説編
さて、お待たせしました。いよいよCometとLingrについての技術解説です。 ■Comet解説 さて、まずはCometとは何で、どういう背景によって生まれたのか、についての解説から始めます。 まず前提として、Webアプリケーションにおいては、通信開始のトリガーは常にクライアント側が握っています。つまりURLを入力したりボタンをクリックしたときなどに通信が発生することになるわけですが、このようなアーキテクチャは、サーバ側で発生した変化をリアルタイムにクライアント側に通知することが原理的にできないことを意味します。 チャット・アプリケーションでは、複数のユーザから不定期にメッセージが送信され、それが他の参加者に一斉に配信されなければなりません。しかし、メッセージを受け取ったサーバ側では、それをクライアントに即座にプッシュで通知する方法がないのです。 そのため、一定期間ごとにブラウザがサーバに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
