node.js と thread hog の話（３）
[前回までの話へのリンク] ・node.js と thread hog の話（１） ・node.js と thread hog の話（２） では、なぜ今頃になって HTTP Server の c10k 問題（もしくは、thread hog 問題）が顕在化したのだろう。 当時（９０年代の終わり頃）と比べて、もっとも大きく変わったのはCPUの性能である。クロック数は、数百MHzから数GHzへと一桁増えたし、マルチコア化もしている。CPU 性能だけ見れば、当時の数十倍の能力が出てしかるべきである。 しかし、実際の人生はそう簡単ではない。サーバーのパフォーマンスはCPU性能だけが決めるわけではないからだ。そこで、ボトルネックの一つとして注目されはじめたのが、thread の数なのである。 前回述べた様に、thread 一つあたり 2MB～8MB のスタック領域を仮想メモリ空間に確保しなければならな
node.js と thread hog の話（２）
[前回までの話へのリンク] ・node.js と thread hog の話（１） 最近になって「c10k 問題」が広く知られるようになったが、実際には、前回書いたように、thread を使いすぎるプログラム（thread hog なプログラム）はスケーラビリティが悪いということは、当時（９０年代の終わりごろ）でもすでに「知る人は知る」問題になっていた。 複数のクライアントマシンとの間のソケットを開きっぱなしにしておく、Proxy Server、Chat Server、MMORPG に関わっている人達の間で、ソケット一つに thread を一つ割り当てるスタイルのプログラミングがスケーラビリティに欠けることが知られるようになったのもこのころである。 当時、Microsoft で MSN Messenger を作っている知り合いが「ついに１万人が同時接続しても大丈夫なアーキテクチャに到達した
node.js と thread hog の話（１）
ここ数日、 node.js で色々と作りはじめているのだが（node.js が一番力を発揮するのは、xmpp server や、push notification server のようにソケットを開きっぱなしにして非同期通信をするケースだと思うのだが、それについては来週のメルマガで詳しく解説する）、これで思い出すのが Microsoft 時代の「"thread hog" 退治」だ。 "thread hog" とは私が作った造語で、"memory hog" （メモリをやたらと使うプログラムのこと）と同じように、thread を不必要に作るプログラムのこと。 最初に出会った thread hog は、Microsoft が作っていた proxy server だった。コネクションが１０００を超すとやたらと遅くなり、しまいには落ちてしまうという欠点を持っていたため、一時は「出荷出来ないところか、
Android OS のアップデート問題に関してひと言
最近、再びAndroid OSのアップデート問題が話題になっているようだが（参照）、OSの開発の関わったことのある開発者としてひと言言わせてもらう。 OSの開発というのはただでさえ簡単な仕事ではないが、特に難しいのは過去のアプリとの互換性を保ちながらOSそのものを進化させて行くという仕事。Windows95の開発の際も、一番苦労したのは、スタートメニューだとかデスクトップなどの新機能の追加ではなく、Windows 3.1との互換性を保つ部分。その当時のエピソードは、少し前の「Windows95と地上の星」というエントリーに書いたので一読いただきたい。 今回の話は、さらに厳しい要求だ。iPhoneのように一社がデバイスの仕様すべてとリリースタイミングをコントロールしているならいざしらず、Androidのように複数のメーカーが、それぞれの仕様でばらばらのタイミングでデバイスをリリースしている世
テクノロジー・ベンチャーにはなぜソフトウェア・エンジニアが不可欠なのか？
WEB-DB PRESSに連載中のコラム、「第10回 アイデアを目に見える形にしてこそのエンジニア」が公開されたので、エンジニアの方たちにはぜひとも読んでいただきたい。 この文章で、私が一番強く訴えたかったメッセージは下の一節。 注目すべき点は，この「プロトタイプという叩き台を作って企画を煮詰めていく」というアプローチは，エンジニアにしかできないということだ。ソフトウェアのことがまったくわからない人から企画を丸投げされて閉口した経験は多くの人が持っていると思うが，そんな無駄なことを避けるためにも，企画の段階からリーダーシップを発揮するためにも，エンジニアはプロトタイプを作るべきだと私は考えている。 シリコンバレーでベンチャー投資家をしている Guy Kawasaki が、「私がアーリー・ステージのテクノロジー・ベンチャーに投資をする時は、ざっと見積もって、優秀なエンジニア一人あたり５０万ド
ベジェ曲線の数と「達筆度」と
neu.Note+ 向けに曲線のスムージングのアルゴリズムを開発中。特に文字の場合、オリジナルの字形を崩さずにどこまで自動できれいなスムージングをかけられるかが勝負になる。 左の図で、一番左のものがオリジナル。iPad上に指で書いたものだが、手書き特有の「よれ」が見れる。それぞれのストロークは３０〜４０個のベジェ曲線から構成されている。 これに開発中のアルゴリズムを適用したものが真ん中のもの。隣接するベジェ曲線を組み合わせることにより、ベジェ曲線の数を減らしたもの。あまり減らしすぎると字形が崩れるので、そのバランスが難しい。結果としては、それぞれのストロークに含まれるベジェ曲線は６〜１３個に減っている。「よれ」がなくなり、かなりきれいになった。 これをさらに手動で最適化したものが一番右のもの。各ストロークに含まれるベジェ曲線は３〜９だ。ここまで来ると、「達筆」と呼べる。 この場合、アプリを
脱原子力宣言
今回の原発災害についていろいろと調査・考察を積み重ねて行くうちに、一つのことが明らかになってきた。私自身を含めて、これまで大半の日本人（特に首都圏に住む人たちが）が、原発問題を「特定の地方の問題」として軽視して来たという不都合な真実である。 今回の原発災害の根底にある問題をきちんと見つめれば見つめるほど、これは決して他人事ではなく、電気を消費する立場にある日本人全員がもっと真剣に向き合わなければいけない重要な問題だという事が明らになる。 そこで、私自身も含めた「今まで原発問題を他人事として軽視して来た人たち」に向けたメッセージを書いて見たので、ぜひともご一読いただきたい。 脱原子力宣言 当然、賛成される方も反対される方もあるとは思うし、私が見逃している点もあると思うので、活発な議論をお願いした。ただし、コメントはこのエントリーにではなく、リンク先のFacebook Noteに直接お願いする
GoogleのAndroid向けのアプリビジネスはなぜ魅力的ではないか？
PhotoShareをiPhone向けに提供して早くも一年になるが、もっとも良く投げかけられる質問は「PhotoShareはAndroidとかの他のプラットフォームに移植しないの？」というものだ。 少し前までは、「まだiPhone以外のビジネスが十分に大きくないから今はまだ早い」、「iPhone上でやるべきことはまだ沢山あるから」、などと答えて来たのだが、最近は少し見方が変わってきた。 今の勢いでHTML5が進化・浸透してくれるのであれば、わざわざ移植コストをかけてAndroidやWindows Mobile向けにネーティブ・アプリを開発するよりは、少なくともUIの部分をすべてHTML+Javascriptにまかせたアーキテクチャでのインタラクティブなアプリの開発というのも十分に可能性があるように思えてきたのだ。 この「HTML+Javascriptですべて出来るじゃん」という発想は、そも
ユーザーに尋ねても必ずしも正しい答えは返ってこない
今日はたまたま「ユーザーからのフィードバックを集めることの難しさ」が話題になったので、それに関連するエントリー。 もの作りにおいて、「ユーザーが何を必要としているか」を知ることは大切だが、だからと言ってユーザーに尋ねれば正しい答えが返ってくる訳ではないところが難しいところ。具体的な例としては、こんなものがある。 1. サイレント・マジョリティの声は聞こえてこない これはMicrosoftで実際にあったことだが、Outlookのチームではユーザーから寄せられる機能追加のリクエストに従って色々な機能を足していた時期があったが、その結果不必要な機能ばかり増えて、単純な作業が逆にやりにくくなってしまった（たとえばカスタム・フォームが良い例）。このケースでは、ごく一部のヘビー・ユーザーばかりが声がでかく、「今の機能で十分、これ以上複雑にしないで欲しい」というユーザーは何も言ってこない（こういう人たち
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
外国為替相場取引（FX）で確実にもうける方法（必勝法）