非同期APIと例外処理（node.js の domain について）
node.js のような非同期APIを使ったプログラミングに拒絶反応を示すエンジニアが多い理由の一つが、非同期APIと例外処理の相性の悪さだ。 Javascript の場合、例外処理はこんな感じに記述する。 function f(i) { try { throw new Error('an error #'+ i); } catch(e) { console.log('Error caught:', e.message); } } ところが、これに非同期APIが絡むと、とたんに分かりにくくなる。例えば下の例。 function f(i) { try { setTimeout(function() { throw new Error('an error #'+ i); }, 1000); } catch(e) { console.log('Error caught:', e.message)
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 のスタック領域を仮想メモリ空間に確保しなければならな
Javascript雑学：SetTimeoutについて知っておくべき事
昨日のベンチマーク・プログラムだが、MacやWindows上で走らせて60-70fps程度しか出ていない事に驚いた人も多いかも知れないのでひと言補足しておく。 あのベンチマーク・プログラムは１フレーム描画するごとにSetTimeout()を使って1msの遅延で関数updateFrameを呼び出し、実際に１秒間に何回呼び出されるかを測定している。スマート・フォン上でこのベンチマーク・プログラムを走らせると、フレームの描画の部分に30msとか40msとかが必要なので、その結果33fps、25fpsなどの測定結果が得られる。 ということは、Javascriptの実行速度が猛烈に早ければ1000fpsも可能なはずだが、どんなに高速なパソコンを使おうと、どんなに描画のロジックを単純化しようと、実測値が通常100fpsを超えることはないのをご存知だろうか。
Life is beautiful: 「時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す」という働き方
かれこれ３０年以上もこの業界でプログラムを毎日のように書いて来た私。当然、自分なりの働き方のノウハウみたいなものも会得して来たつもりだ。以前ここに「私のとっておきのプログラミングスタイル」というエントリーを書いたので、まだ読んでいないプログラマーの方にはぜひとも読んでいただきたい。 ちなみに、そんな中でも後輩とか部下に教えるのが一番難しいのが、「スタートダッシュでできるだけはやくめどをつける」という仕事スタイル。どのエンジニアも、ちゃんと説明すればこの働き方の効用は理解してもらえるのだが、実際の現場でちゃんと実行できる人は１００人に１人もいない。 「人はみな怠惰だから、締め切りに迫られなければがんばれないんだ」と言ってしまえばそれまでだが、「まがりなりにもプロとして仕事をする限りは、ペース配分ぐらいはちゃんと考えて仕事をすべき」というのが私の主張。トップクラスのマラソンランナーでペース配分
勝てば官軍、負ければガラパゴス
私が数年前からこのブログで使っている「ガラパゴス化」という言葉、今やテレビや雑誌でまで見る様になり、何だかうれしいような悲しいような、複雑な気持ちである。 私が最初に公の場でこの言葉を使ったのは、２００１年のCTIA（米国最大の携帯通信業界のカンファレンス）でのこと。UIEvolutionというベンチャー企業を立ち上げたばかりでもあり、この業界でなんとか注目を集めようと、「NTTドコモのiモードのことなら詳しいので、日本の若い人たちのライフスタイルがiモードでどう変わったからなら解説できるよ」と会議の主催者に連絡すると、いきなり２０００人も収容できる会場を割り当てられたのだ。 私がNTTドコモから来た人間だと勘違いした人もいたようで、会場は超満員。冒頭でドワンゴの「釣りバカ気分」の面白さを手振り身振りで伝えたところそれが大受けで、日本のギャルの生態系の解説も交えながら、日本の「ケータイ文化
iPad上でHTML5 Widgetを走らせて遊ぼう
昨日の「HTML5: W3C Widget とその応用を考える会」は参加者も多く、私自身とても良い勉強になったが、そこでも予告した通り、iPad発売を記念してWidgetのサンプルをいくつか用意したので、ぜひともお試しいただきたい。 手順は以下の通り。 ステップ１. iPadにCloudReadersをインストールする（iTunes ストアへのリンク） ステップ２. 以下のWidgetをダウンロードする Download 3dClock.wgt (2.5K) ー CSS3を使った３D時計 Download TimeTrial25.wgt (7.8K) ー タイムトライアルゲーム Download JSCalc.wgt (3.4K) ー 電卓 Download QuadraBench.wgt (2.5K) ー Canvas のベンチマークプログラム ステップ３. iPadをPC/Macに繋げ
UIプロトタイプ：autocomplete (jQuery plug-in jSuggest)
昨日に引き続いて、今日も作成中の Google App Engine アプリ用のUI部品の作成。HTMLの一部に記述された（もしくは別途JSONで取得した）ワード・リストの入力を autocomplete を使って簡単にしようという試み（Google Suggestのようにダイナミックにリストを取得する必要はない）。 そこで、まずは既存のライブラリ・プラグインの調査から。必要とする人も多いようで、少し調べただけで２０個ぐらい見つかる。デモを見て５つに絞ってからそれぞれのソースコードを解析。例によってどうしようもない品質のコードもあるので、結局のところたどり着いたのは、比較的コードがきれいなこの二つ。 jQuery Autocomplete Mod JQuery Plugins by Dylan Verheul - autocomplete どちらかをそのまま使っても良かったのだが、どちらも
「富豪プログラミング」もいいけど「けちな大富豪」になるべき
Ruby on Railsに代表されるDRY（Don't Repeat Yourself）スタイルのフレームワークは、手っ取り早くサイトを立ち上げるのにはとても便利だ。特にRailsのActive Recordの様に、ランタイムにダイナミックにコードや設定ファイル（もしくはそれに相当するもの）を生成してくれる仕組みは、情報を一カ所のみに記述することによりミスを減らすという意味でもアジャイルな開発という意味でも重要である。 ただ、この手のフレームワークを使う場合に一つ気をつけなければならないのは、それがスケーラビリティの面で商用に耐えられるものか、という点である。特に、その手のダイナミックなコードや設定ファイルの生成（Railsの場合だとデータベース上のテーブルのスキーマに基づいたActive Recordクラスのダイナミックな生成）が、最初にサイトにアクセスが来た時に一度だけ実行されるもの
Python入門：デコレータとは
前から常々思っていることだが、何かについて勉強する一番効率的な方法はそれを誰かに教えること。人に教えようとすると、それなりに準備をしなければならないし、自分の頭の中を整理しなければならない。また教える過程でするどい質問をされたり間違いを指摘されて、さらに勉強を強いられることもある。 私がこの手の「入門編エントリー」を書くのは、ほとんどの場合「自分自身の理解をより深めたい」ことが一番の目的であるが、ブログの場合、教室などと違って「その道の達人」みたいな人たちがツッコミを入れてくれるケースもしばしばあるので、そのメリットは何倍にもなる。 先日のクロージャに関するエントリーなどは良い例で、「そんな用途にはmemoizeというデコレータが便利」などの指摘がいただけだけであれを書いた価値があるというもの。 そこで、今日はPythonのデコレータに関して。デコレータがPythonという言語に導入された
優秀なエンジニアは「入社時のスキルを問わない会社」には就職してはいけない
ちまたで問題になっているIPAフォーラム2007に参加した学生がエントリーを書いているのだが、それが半端じゃないぐらいのエンターテイメント。 ...IT産業というよりSIerの人気がないことについて語りたいだけなんじゃないかという顔ぶれだったし... ...はてなブックマークのコメントを見ている限りでは、パネリストの方々は相当現実の見えていない発言をしているようだ。... ...ITを専攻している学生達からは、「就職時にITスキルが問われないのだとしたら、大学でやっていることには何の意味があるのか」という質問が出ていたのだけど、明確な回答はなかったと思う。その人たちは、ちょっとショックを受けていたような気がする。... ...その流れで、「入社時にITのスキルを問わないというのは、Googleのような企業の方針とは反対であるが、それですばらしいサービスを作ることができるのか」という質問が出
Life is beautiful: 私のとっておきのプログラミングスタイル
404 Blog Not Found の「LiveCoding に学ぶプログラミングの三原則」を読んでいたらどうしても書きたくなったので。あくまで私のスタイルなので、参考にするもしないもご自由に。 1. スタードダッシュでできるだけはやくめどをつける 学生時代から夏休みの宿題は７月中に終わらせていた私とすれば、ラストスパートよりはスタートダッシュで勝負する。どのみち、どこかで思いっきり頑張らなければならないのであれば、締め切り間際ではなく、スタート間際に頑張るべきというのが私のポリシー。十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、本当は大幅な設計変更をすべきなのに応急処置で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
単なる「低コストの外注先」ではなくなりつつあるインドのIT産業