タグ

ブックマーク / satoshi.blogs.com (11)

  • node.js と thread hog の話(3)

    [前回までの話へのリンク] ・node.js と thread hog の話(1) ・node.js と thread hog の話(2) では、なぜ今頃になって HTTP Server の c10k 問題(もしくは、thread hog 問題)が顕在化したのだろう。 当時(90年代の終わり頃)と比べて、もっとも大きく変わったのはCPUの性能である。クロック数は、数百MHzから数GHzへと一桁増えたし、マルチコア化もしている。CPU 性能だけ見れば、当時の数十倍の能力が出てしかるべきである。 しかし、実際の人生はそう簡単ではない。サーバーのパフォーマンスはCPU性能だけが決めるわけではないからだ。そこで、ボトルネックの一つとして注目されはじめたのが、thread の数なのである。 前回述べた様に、thread 一つあたり 2MB~8MB のスタック領域を仮想メモリ空間に確保しなければならな

  • node.js と thread hog の話(2)

    [前回までの話へのリンク] ・node.js と thread hog の話(1) 最近になって「c10k 問題」が広く知られるようになったが、実際には、前回書いたように、thread を使いすぎるプログラム(thread hog なプログラム)はスケーラビリティが悪いということは、当時(90年代の終わりごろ)でもすでに「知る人は知る」問題になっていた。 複数のクライアントマシンとの間のソケットを開きっぱなしにしておく、Proxy Server、Chat Server、MMORPG に関わっている人達の間で、ソケット一つに thread を一つ割り当てるスタイルのプログラミングがスケーラビリティに欠けることが知られるようになったのもこのころである。 当時、Microsoft で MSN Messenger を作っている知り合いが「ついに1万人が同時接続しても大丈夫なアーキテクチャに到達した

  • node.js と thread hog の話(1)

    ここ数日、 node.js で色々と作りはじめているのだが(node.js が一番力を発揮するのは、xmpp server や、push notification server のようにソケットを開きっぱなしにして非同期通信をするケースだと思うのだが、それについては来週のメルマガで詳しく解説する)、これで思い出すのが Microsoft 時代の「"thread hog" 退治」だ。 "thread hog" とは私が作った造語で、"memory hog" (メモリをやたらと使うプログラムのこと)と同じように、thread を不必要に作るプログラムのこと。 最初に出会った thread hog は、Microsoft が作っていた proxy server だった。コネクションが1000を超すとやたらと遅くなり、しまいには落ちてしまうという欠点を持っていたため、一時は「出荷出来ないところか、

  • 新社会人のあなたに

    新社会人への私からのメッセージは「サラリーマンにならないで欲しい」というひと言に尽きる。 ここで言う「サラリーマン」とは、 「なぜこの仕事をする必要があるか」を理解せずに仕事をする人 経営陣や上司の言うこと、やることに疑問を持たない人 当事者意識を持たずに仕事をする人 失敗を恐れて、他人のしないことや冒険を避ける人 社内の人とだけ交流し、社外にネットワークを作らない人 社内ばかり見て、自分の社外での人材価値を高めようという努力を怠る人 自分のキャリアパスは会社が描いてくれると考えている人 善悪を自分で判断せずに「まわりの人がやっているかどうか」だけで判断する人 いままでのように、横並びでスペック競争をしていれば良い時代ではなくなった。今年、就職ランキング100以内の企業が10年以内に倒産してしまう可能性だって十分にある。そんな時代だからこそ、常に「なぜこの仕事をする必要があるのか」を意識し

  • neu.Notes の iPhone 版をリリースしました

    以前からここで何度か紹介している、iPad向けの手書きメモアプリneu.NotesのiPhone版をようやくリリースすることができたので報告させていただく(無料)。iPhone/iPod touchをお持ちの方にはぜひともお試しいただきたい。 簡単なメモを取って自分宛にメールで送ったり、Evernoteにしまっておいたり(メール経由)、Twitterに投稿したり、というシナリオに特化させて作ったので、「機能」よりも「手軽さ」「使いやすさ」を重視している。 ライブラリーから写真を貼付けることもできるので、手作りアルバムのようなものも簡単に作れる。 また、描いたものをベクターデータとしてAdobeのイラストレーターに渡すこともできるので(PDF経由)、ちょっとしたイラストやデザインの下書きなどにも使える。 ちなみに、基的に機能拡張はユーザーの声を聞きながら決めているので、ぜひともフィードバッ

    neu.Notes の iPhone 版をリリースしました
  • もし日本のメーカーが iPhone を発売していたら..

    iPhoneは会社から支給されて使っていますが、非常に使い勝手がいいです。 ただ、これでは、いまほど欲しくならないことはたしかですね。 他の機種と同じ土俵の上に上がってしまっているので、「なんかいろいろ機能がごてごて付いてる中の携帯の一つ」というところでしょう。 つまり、「売れるモノも売れなくなる」、「売り方次第」ということを今更ながら思い知らされました。

    もし日本のメーカーが iPhone を発売していたら..
  • Life is beautiful: とある家電メーカーでの会話:クラウドテレビ編

    ある日の家電メーカーでの会話。まずは副社長室での会話から。 技術部長:副社長、来年度の予算の件はどうなりましたか 副社長:大丈夫だと言っただろう。台湾中国からの追い上げは相変わらず激しいが、テレビは家電ビジネスの要だ、経営陣としてもここだけは手を抜けない。来年も君たちにがんばってもらわなければならない。 技術部長:もちろんです。そのあたりは現場のエンジニアたちも強く感じてると思います。ちなみに、メールに書いてあった「戦略の変更」って何ですか? 副社長:そのことなんだが、経営会議でも持ち上がったんだが、台湾勢と戦うには、我が社にしかできない「差別化要因」が必要だ。価格競争では彼らにかなわない、消費者にとって目に見える価値を提供して、台湾製品よりも3割・4割増の値段でも喜んで買ってもらえるテレビを作らなければならない。私は、キーワードは「クラウド」だと思っている。 技術部長:え?「ク、クラ

    Life is beautiful: とある家電メーカーでの会話:クラウドテレビ編
  • Ruby on Railsの「えせMVC」の弊害

    先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC(Model View Controller)がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの(コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること)を避

  • OilCanvas作品集

    PhotoArtistをリリースした直後にも言った気がするが、この手のソフトをリリースした後の一番の楽しみは、PhotoShareに投稿されるユーザーの方々の作品を見ること。OilCanvasをリリースしてからわずか2日だが、すでに数百枚の作品が投稿されており、目を通すだけで大忙しだ。

  • プラットフォームを選ぶということ

    この業界で仕事をしていると、しばしば迫られるのが「どのプラットフォームに向けて商品開発をして行くのか」という決断。会社としての経営判断の場合もあれば、個人のスキルアップやキャリアパスのための判断の場合もあるが、いずれにしろ限られたリソース・時間をいかに有効に使うか、という点ではとても大切。 パソコン用のソフトウェアであれば、「Windows向けに作るのかMac向けに作るのか」というOSレベルでの選択肢もあるし、「Windows Vista独自の機能を使って差別化を図るのか、それともWindows XPでもちゃんと動くように作ってまずは大きな市場をとりに行くのか」というOSのバージョンレベルでの選択肢もある。もちろん「そもそも特定のOS向けのアプリを作るべきか、それとも、すべてウェブ・アプリケーションとして作るか」というアーキテクチャ・レベルでの選択肢もある。 「少なくともここ数ヶ月はiPh

  • 「作っては壊す」過程があってこそ良いものが作れる

    iPhone用の「はてな人気エントリーリーダー」、そろそろ形になってきたのだが、作ってみていろいろと発見した部分もあったので、全面的にクラス構成を見直し、大幅に書き直した。 HTTPで通信をしているコードが二カ所に分かれていたので、それをDataOverHTTP/XMLOverHTTPという二つのクラスにまとめ(XMLOverHTTPはDataOverHTTPのサブクラス)、はてな独自のRSSフィードを読んでいるコードから一般的なRSSフィードを扱うコードをくくりだしてRSSFeed/RSSFeedLoaderという二つのクラスにまとめて、あとで別のアプリケーションで再利用することを可能にした。それに加えて、各種ローダーに非同期通信をさせる主体をController(HotEntryViewController)からModel側(HateneHotEntry)に移すことにより、難解になりが

  • 1