Swipe：Apple TV アプリを誰よりも早く作りたい人のために
４月から開発して来た Swipe がようやく安定して動くようになったので、Apple TV 向けのアプリが解禁になるのに合わせてオープンソース化することにしました。Swipe により、プログラミングの経験のないデザイナーやイラストレーターにも Apple TV 向けのアプリの開発が簡単に出来るようになります。 Swipe を作ることになったきっかけは、とあるメディア業界の人に「未だに紙に描かれた漫画をスキャンしてスマフォで読むという時代遅れな状態をなんとか解決して欲しい」と頼まれたことにあります。しかし、そのルーツは、Microsoft を辞めるきっかけにもなった「Intelligent Document 構想」にあります。 この構想は、「特定のアプリケーションで作ったドキュメントはそのアプリ（もしくはビューアー）が存在しないパソコンでは中身を見ることすら出来ない」という問題を解決しようと
node.js モジュール ajmax の公開
東京Node学園祭2012 アドベントカレンダー １４日目の記事です。イベントの告知の意味も含めて、毎日だれかが１つづつ node.js についてブログで書く、という企画だそうです。 そこで本題ですが、github に ajmax という node.js モジュールを公開しました。npm にも登録してあるので、"npm install ajmax" でインストールが可能です。 詳しくは readme ファイルに書いてありますが、英語なので簡単に解説すると、AJAX（eye candy 的な AJAX ではなくて、実際に非同期にデータをサーバーから取得してページの一部をアップデートするタイプの AJAX） を活用した one-page web application を作るための micro MVC framework です。 これまでいくつか AJAX を駆使したアプリを作って来ましたが、
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 だった。コネクションが１０００を超すとやたらと遅くなり、しまいには落ちてしまうという欠点を持っていたため、一時は「出荷出来ないところか、
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 と thread hog の話（１） ・node.js と thread hog の話（２） では、なぜ今頃になって HTTP Server の c10k 問題（もしくは、thread hog 問題）が顕在化したのだろう。 当時（９０年代の終わり頃）と比べて、もっとも大きく変わったのはCPUの性能である。クロック数は、数百MHzから数GHzへと一桁増えたし、マルチコア化もしている。CPU 性能だけ見れば、当時の数十倍の能力が出てしかるべきである。 しかし、実際の人生はそう簡単ではない。サーバーのパフォーマンスはCPU性能だけが決めるわけではないからだ。そこで、ボトルネックの一つとして注目されはじめたのが、thread の数なのである。 前回述べた様に、thread 一つあたり 2MB～8MB のスタック領域を仮想メモリ空間に確保しなければならな
非同期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)
ザッカーバーグの面接試験２：アクティビティ・インディケーター
先日の「ザッカーバーグの面接試験：Objective-C のブロックを使いこなす」には数多くの答えをいただいたので、それに気を良くして第二問。これも iOS 用だが、先の問題と違い、この問題は初級者〜中級者向けだ。 [問題] iOS ではステータスバー上のアクティビティ・インディケーターの ON/OFF は、[UIApplication sharedApplication] の networkActivityIndicatorVisible プロパティに YES/NO をセットすることにより行います。そのため、複数の非同期通信を同時に行うアプリケーションの場合、少なくとも一つの非同期通信が行われている時だけ YES にする仕組みを作る必要があります。 そこで、NetworkActivityManager というシングルトン・クラス（インスタンスを一個しか持たないクラス）を作り、非同期通信中
Retina display 向けの画像生成に関する一考察
Retina display は iPhone4 から存在しているのだが、neu iPad になって表示される画像の鮮明さがとても重要になり、色々と細かなところで見直しが必要になっている。neu.Notes に関しても、neu iPad 上で走らせると サムネイルの鮮明さが重要になる。 例えば、neu.Notes でユーザーが描いたベクターデータを保持した Canvas ラスタライズして UIImage を返す API。Retina display 登場前には、UIImage には一種類しかなかったので大きさを指定しさえすれば良かったが、これからはそれをデバイス上に表示するのか、JPEG などに変換してメールで送信したりするのか、によってデバイス向けのスケーリングをするかどうかを指定する必要がある。 具体的には、imageFromRect:size:clipPath: というメソッドにde
オリンパス事件と日本企業のコーポレート・ガバナンスの欠如と
オリンパス事件は、タックス・ヘブンであるケーマン諸島に席を置く会社が出て来た時点で何かあるとは思っていたが、やはり不正会計であった。 注目すべきは、「バブル期に株式投資で失敗したこと」が悪いのではなく、「その投資の失敗を株主に秘密にしたこと」である。誰にでも失敗はあるので仕方が無いとしても、上場企業であるオリンパスの経営陣が投資の失敗による損失を株主から隠したことは、明らかな「犯罪」である。 ホリエモンが投獄される事になった不正会計が「スピード違反」であるならば、オリンパスの損失隠しは「ひき逃げ」に相当する重罪である。当時の責任者は、当然、投獄されるべきである。 ちなみに、問題の本質は、経営陣がこれほどまでに悪質な不正会計をしながら、それを監視する仕組みが全くなかったということ。米国の会社であれば、株主を代表する取締役会が経営陣の上部組織として監視をするのだが、取締役会が基本的に社内の重役
HTML5 Widget入門：あなたにも作れるiPad用Widget
今朝の「iPadでHTML5 Widgetを走らせて遊ぼう」に対して、「もう少しWidgetについて知りたい」との声が聞こえてきたので、「Widget入門編」を書いてみようかと思う。 Widgetとは何か？ 先のエントリーで書いたが、ひとことで言えば「パッケージ化されたウェブアプリケーションである」。通常のウェブアプリは、特定のURLにアクセスすることにより走らせるが、Widgetの場合は、.wgt のエクステンションを持つWidgetファイルをダウンロード＋インストールした上で、それを起動する。 Widgetファイルの中身は、HTML+CSS+JS+メディア・ファイルで構成されており、それをZIP圧縮して、エクステンションを.wgtに変更しただけのものである。 なぜそんなことをするかと言えば、（１）オフラインで動かしたい、（２）通常のデスクトップアプリの感覚で起動したい、（３）パッケージ
SNBinder入門：一行おきに背景色を変えるテクニック
「ピュアAjaxアーキテクチャ」なウェブサイトを実現するために作ったSNBinder、多くの方々からフィードバックをいただけ、私もとても良い勉強になっている。そんなフィードバックの中に、「テンプレート内で条件分岐ができるようにして欲しい」「テンプレート内にスクリプトが書ける様にして欲しい」などのリクエストをたびたび見かけるので、今日はそれに関してひと言。 たしかに、従来型のテンプレートのほとんどに「繰り返し」や「条件分岐」の機能がある。ものによっては、そのテンプレート中にスクリプトが書けてしまうものもある。SNBinderにそんな機能を追加するのもけっして難しくないのだが、私がSNBinderで実現しようとしている方向性とは少し違う、と感じている。 そもそもテンプレートとは、JavaとかPythonなどで記述された「ロジック（もしくはコントローラ）」と、ユーザーに何を見せるかというHTML
マルチ・スレッド（multi-thread）プログラミングの落とし穴、その１（かもしれない）
ここのところ技術系ブロガーの間で話題になっている、「C10K問題（参照１、参照２）」は、ひとことで言えば、多くのウェブ・サーバーで採用されているmulti-threadやmulti-processに頼った（もしくは頼りすぎた）多重処理というアーキテクチャーのスケーラビリティに対する極めてまっとうな警告である。 この話は、決して最近になって始まった話ではなく、パソコン業界ではパソコンのOSにpreemptiveなマルチタスクが導入されはじめた９０年代の前半から、さらに遡ると、DECを中心にテクノロジーが進化したミニコンの時代から、ソフトウェア・エンジニアたちの間で盛んに討論されてきたテーマである（さすがに、メインフレーム時代の話は私は知らない）。 十数年を経た今でも、いまだに決着が付いていないこの問題は、私の大好きなテーマの一つでもあるし、もし私が博士号をこれから取得しようとするのであれば、
技術者にも必要な「もうける決意」
「日経エレ１０月９日号」の「日本半導体産業・復活への提言（湯之上隆著）」。半導体産業に限らず、ソフト・家電・ゲーム・ウェブサービスなどを含んだ広い意味での「この業界」で生き残るために必要な提言を含んだ、すばらしいペーパーだ。 オンラインで全文を読んでいただくことが出来ないのが残念でしかたがないが、このペーパーにこめられた著者のメッセージが集約された部分を引用させていただく。 ある日本のメーカーの技術者は「開発部門の技術者は、開発にしか興味がない」と証言した。別の技術者は「おおくの技術者は、コスト削減を工場の仕事と考えている」と話した。（…中略…）一方、Intel社の技術者は「ある開発プロジェクトに対する社内評価は、どれだけの最終製品をいくらで出荷したかが判断基準になる」という。開発者のボーナスも最終製品の利益で決まる。これが、開発段階で徹底した低コスト化を目指すインセンティブになっている。
「足あとライブ！」に関するテクニカル・メモを書いてみた
「足あとライブ！」や「ホットエントリーライブ！」を作っているうちに、CometサーバーとJavascriptをどう組み合わせれば良いか、なのどノウハウが色々とたまってきたので、一度テクニカル・メモの形にまとめてみることにした。ちょうど英語のブログの更新が止まっていて、なんとかせねばと思っていたので、そちらのエントリーとして書かせていただいた。 Live Page-View Counter, Comet server and JSON-push ソースコードすべてを公開しているわけではないが、C++で直接ソケットを操作するコードを書くことができて（つまりCometサーバーを自作することができて）、サーバー側のスクリプト(言語は問わない)とJavascriptをある程度書ける人であれば、このペーパーに書かれた情報を元に自分でも同じようなサービスを作ることが可能になるように書いたつもりである。も
Life is beautiful: JSON COMETでリアルタイム・ページビュー・カウンターを作ってみた
最近Linuxの勉強もかねて作っているのが、超シンプルなアーキテクチャーのHTTPサーバー。そこそこ動き始めたのだが、それだけでは面白くないので、サーバー側からイベントに応じてデータをPushできるCometの機能を足してみた。 ストレステストのために、昨日からこのブログにこっそりとテスト用のIFRAMEを貼り付けてあったのだが（そのおかげで、バグを三つばかり見つけることができた―感謝、感謝^^）、安定して動き始めたので、見栄えを整えてこのブログの右上に貼り付けてみた。 題して、「リアルタイム・ページビュー・カウンター（RPV Counter）」。Totalはこのカウンターをリセットしてからのページビューの数、Currentはその時点でこのブログを見ている人の数（ただしノイズあり）、PeakはCurrentの過去最大値だが、ページを再ロードせずとも、それぞれのカウンターが自動的にアップデー
Life is beautiful: Edward Tufteに学ぶプレゼンのスキル
「スティーブ・ジョブスに学ぶプレゼンのスキル」は、このブログの人気エントリーの一つだが、ことプレゼンに関して私が師と仰ぐのはEdward Tufteである。日本ではあまり名が売れていないようだが、米国では「データのプレゼン技法」に関しては第一人者で、本も何冊も書いているし、全米各地でセミナーも行なっている。 私自身も、一日セミナーに参加したことがあるが、膨大な量の実例を集めて、それぞれのどこが優れているか、どこがダメなのかを的確に分かりやすく説明してくれるTufteは、まさに「プレゼンの神」であった。彼からは色々なことを教わったが、特に心に残り、今でも常に実戦しようと心がけていることは、 ・文字に頼らず、図を効果的に使うこと ・一度に見せる情報量を絞ること ・意味を持った色使いをすること の三つである。特に最後の「色も情報を運ぶことができる」という点は、それまで意識したことがなかっただけに
できるかぎりエレガントな解法を見つけて「うっかりミス」を減らす
このブログでも何度か書いたことがあるが、ソフトウェアを書くのに高度な数学が必要なケースはマレで、ほとんどの場合は中学生程度の数学で十分である。ただし、中学生時代の数学を「公式の丸暗記」でしのいで来たような人ではなく、「難しい応用問題をエレガントに解くのが楽くてしょうがなかった」ような人が向いているというのが私の持論だ。 例として、以下の二つの数学の問題を見て欲しい。 例題１．時計の長針と短針は、１２時にちょうどピッタリと重なります。次にピッタリと重なるのは何時でしょう。 例題２．サイコロを２個、順番に投げることにします。１つ目のサイコロの目の方が二つ目のサイコロの目より大きい確率を求めてください。 どちらも、中学生の数学を使って解ける問題ではある。例題１は方程式を使って解くことができるし、例題２は順列組み合わせの考えを適用すれば解くことはできる。しかし、それで満足してはいけない。 プログラ
ユーザー参加型コンテンツビジネスのまとめ
最近CGM（Consumer Generated Media）関連の質問をされることが多いので、一度頭の中にあるものを整理する意味でも、箇条書きにしておく。 従来のWeb1.0的なコンテンツビジネスと比べた時の利点 ・常に新鮮なコンテンツをコストをかけずに提供できる点 ・バイラルマーケティング効果（コンテンツを作ったユーザーが他の人に宣伝してくれる） ・根本的にコミュニケーションツールであること（人がオンラインになるのは、他の人と繋がるため） ・ユーザーの数が増えれば増えるほどサービスの価値が上がる点 ・長く使えば使うほど、そのユーザー自身の財産が形成され、サービスから離れにくくなる点 意識しておくべき点 ・自社コンテンツを持っていない企業が新規参入できる点 ・ユーザーは予想もしない使い方をすることがあること ・コミュニティの作られ方しだいでサービスの質が大きく左右されること ・積極的に参
Life is beautiful: SEはメニューのないレストランのウェイターか？
一昨日書いた「ソフトウェアの仕様書は料理のレシピに似ている」というエントリーに対して沢山の人からフィードバックをいただいた。このように情報を発信すると、逆により多くの情報が集まり自分にとっても勉強になる、というフィードバックプロセスがあるからブログは楽しくて仕方がない。 フィードバックの中に「これでSE不要論も再燃か？」などという過激なコメントから、自分自身がSEという立場の方からのものすごく真面目なフィードバックまでが集まったので、これを機会に、ここに私なりに「SE」という職業をどう解釈しているか書いてみようと思う。もちろん、私自身がSEという職業を経験したことがあるわけでなないので、間違っているかも知れないが、その場合は遠慮なく指摘していただきたい。 私の理解では、SEという職業はレストランに例えればウェイターである。それも、メニューから料理を選んでもらう通常のレストランとは異なり、「
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
