先日リリースした、VideoShader だが、撮影した時の体感が面白いというユーザーの声を反映して、「VideoShader グラス」を試作してみた。自分の周りを「アニメの世界」として見ることができるというのはこれまでにない体感だ。 「スマートフォンの次に来るもの」を考える上で「他では得られない体感」を提供することが大切と考える私としては、Kickstarter でも利用してハードウェア事業に乗り出すのも悪くないと考えている。
Google に対抗して、「VideoShader グラス」を作ってみた
先日リリースした、VideoShader だが、撮影した時の体感が面白いというユーザーの声を反映して、「VideoShader グラス」を試作してみた。自分の周りを「アニメの世界」として見ることができるというのはこれまでにない体感だ。 「スマートフォンの次に来るもの」を考える上で「他では得られない体感」を提供することが大切と考える私としては、Kickstarter でも利用してハードウェア事業に乗り出すのも悪くないと考えている。
neu.Node リリースのお知らせ
去年の暮れから準備を進めて来た neu.Node だが、ようやく今日、オープンソース・プロジェクトとして github に公開することができたので報告する。 https://github.com/snakajima/neunode 詳しくは README.md ファイルに書いたが、neu.Node は iOS 上で Node.js の API を使って作った マイクロ・サーバーを走らせる仕組みである。iTunes ストアで配布する iOS アプリに組み込んでも良いし、自分や仲間だけで楽しむ「手作りアプリ」に組み込んでいただいても良い。ライセンスは MIT で、ライセンス料フリーで、非営利・商用、無料・有料の区別なく使える。 neu.Node が目指すのは、新しい形の分散コンピューティングである。「モバイル・デバイスはクライアント、サーバーはウェブ・サービス」という垣根をとっぱらい、全てのモ
特許庁のシステム開発が破綻した本当の理由
特許庁と東芝の新システム開発契約打ち切りについて、なぜこの開発プロジェクトが破綻したのかについて私なりの解説をしようとバックグラウンドを調べたところ、調べれば調べるほど、この問題の根底には（１）コスト意識が欠如し自分たちが「公僕」であることを忘れてしまった霞ヶ関官僚、（２）霞ヶ関から流れて来るお金にたかる IT ゼネコン、（３）そのお金の流れに対する影響力を利用して票を稼ぐ政治家、という原子力業界と全く同じような構図があることが明らかになり、ウンザリしてしまった。 破綻の原因は、ソフトウェア・アーキテクチャやプロジェクト・マネージメントにあったのではなく、「競争原理が正しく働かない社会構造」そのものにあるのだ。これではうまく行くはずがないし、たとえうまくいったとしてもやたらと高くつく。 そもそも破格だと言われた９９億円という落札価格も、私から見ればどうみても高すぎる。特許庁のシステムであれ
node.js で「サラリーマンの朝」をプログラムしてみる
先日の「node.js と thread hog の話」には、たくさんのコメントをいただいたが、やはり「イベント駆動型」のプログラミングには抵抗がある人も多いようだ。そこで、JavaScript の無名関数を使ったイベント駆動型のプログラミングの可読性が悪くないことを示すために、「朝７時に目覚まし時計をかけて眠りにつき、朝ご飯を食べ終わったら会社に行く」という典型的な「サラリーマンの朝」をイベント駆動型のJavaScriptで記述してみた。 注目して欲しいのは、素早く出来る「着替える」「顔を洗う」などの動作は割り込み不可な動作なので、通常のプログラミングと同じようにシーケンシャルに実行するが、時間のかかる「朝ご飯を食べる」「駅まで歩く」などの動作は割り込み可能な状態で実行し、"complete" のイベントを受けてから次の動作に移る点だ。 ちなみに、目覚まし時計は 「スヌーズボタン」付きな
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 のスタック領域を仮想メモリ空間に確保しなければならな
誰も言いたがらない「Sony が Apple になれなかった本当の理由」
Sony や Panasonic が家電のコモディティ化で大赤字を出して苦しむ一方で、今や株価総額が日本の大手家電メーカー８社の株価総額の３倍以上にもなった Apple（参照）。 この差に関しては、私も含めて、リーダーシップの欠如だとか、ゼネコン型のソフトウェア開発スタイルが悪いとか、ソフトウェアの重要性を理解しない経営者、などのさまざまな考察がされているが、その根底にあるのは、「大企業は一度正社員になった人は会社が倒産の危機にでもさらされない限り解雇してはいけない」という日本特有の雇用スタイル。 家電業界の成り立ちは、日本の家電メーカーが業績をのばしていた高度経済成長期とは大きく変わってしまった。ソフトウェアがものすごく重要になったのはもちろんのこと、ハードウェアに関しても、中国を含む東南アジアが「世界の工場」となった今、「何を自分で作り何をアウトソースするか」がコスト削減の上でも差別化
トヨタ自動車が原子力発電機を搭載した自動車を売らない理由
福島第一原発事故の「事故原因」が少しづつ解明されてきているようだが、なによりもこの事故から我々が学ぶべきなのは、どうやったら二度とあのような事故を起こさないようにできるか、という教訓だ。 そしてその教訓は、「防護壁をもうけて１０メートルを越す津波にそなえること」のようなその場しのぎの答えでも、「すべての原発を直ちに止める」という極論でもない。 二度とあのような事故を繰り返さないためには、「事故原因」を「非常用ディーゼル発電機が津波により使えなくなってしまったから」という「直接の事故原因」を求めるだけでは不十分なのはもちろんだが、「津波の危険を知りながら対処を怠った東電が悪い」という「人的事故原因」を求めるだけでも不十分である。 もっとも重要なことは、なぜ東電が「津波の危険を知りながら対処を先送りするような行動に出たのか」を明確にし、その根本原因を修正することである。 普通のビジネスであれば
原発どころか火力発電所まで不要にする夢のエネルギー、E-Cat
ForbesのHello Cheap Energy, Hello Brave New Worldという記事によると、今月の２８日についに夢の発電システム E-Cat の１メガワットの発電施設のデモがイタリアのボローニャで公開されるらしい。 発明者は Andrea Rossi。２００８年に出願された特許によるとニッケルと水素を核融合させて銅に変換する際に生じるエネルギーを使う「低温核融合（Cold Fusion）」らしい（Rossi自身は、Low-Energy Nuclear Reactionと読んでいる）。 これまでも何度か招待制で小規模な発電のデモをしているが、出席者の中にも「これはエセ科学にすぎない」と決めつける人もいるぐらいで、多くの人たちが懐疑的な目で見ている。 確かにWikipediaの記事を読むとエセ科学にしか見えないのだが、それでもForbesが取り上げるのは、「人類はいつか
「空気が読める日本人」と「言論の不自由」と
今朝の私のエントリーに対して、池田信夫氏がTwitterで二回つぶやいた。最初のものがこれ。 首相がブログ読んで素人に「脱原発」の知恵を借りるって末期症状だな・・・ 典型的な「菅おろし」発言。まるで読売新聞のようだ。原発に関して色々と書いているブロガーと意見交換しただけなのに、なぜ「知恵を借りる」という表現を使ってわざわざこき下ろすか私には理解できない。オバマが同じことをしてもこんな風に解釈するのか？それとも、オバマだったら「国民の声を聞く、開かれた政府」と褒めたたたえるのか。 そして次がこれ。 私も彼のソフトウェアについての洞察には敬服しているので、おそまつな床屋談義はやめてほしい。 つまり「素人は黙っていろ」という意味だ。池田氏のうらみを買うようなことを言った覚えはないのだが、なぜここまで侮辱されなければならないのかまったく理解できない。「原発のことは原発の専門家に任せておけば大丈夫」
エンジニアの役割
技術評論社の WEB+DB PRESS に連載中のコラムが新しくウェブで公開されたので、ぜひとも読んでいただきたい。 エンジニアの魔法の手〜面白いプロジェクトの関るには このコラムで一番注目していただきたい部分は、以下の一節。 自分が関わっているプロジェクトの方向性がおかしいと思ったら，自分がどんな立場にいようと強く主張すべきだ。会社はそんなエンジニアを必要としているし，本当に会社のためになるのであれば必ず耳を傾けてもらえるはずだ。「そうは言っても，難しいんだよ」などと逃げを決める上司は怒鳴りつけてやればよい。 会社にとって最悪なのは，「こんなものを作っても誰も使わないんじゃないか，会社の価値を上げることにつながらないんじゃないか」と思いながらも黙々と仕事をするエンジニアだ。そんなエンジニアばかり集まっている会社は絶対に市場で成功しない。プロジェクトに関わるエンジニア全員が，「自分たちがど
菅直人 vs. 経済産業省の戦いが壮絶になって来た
福島第一原発での事故以来、私も含めてあまり一般の人たちに知られていなかった数々の問題点が見えて来たわけだが、一番注目すべきなのは、今回の事故の、そして事故後の政府と東電の対応のていたらくの諸悪の根源は東電でも管政権でもなく、霞ヶ関の官僚たちだ、という事実である。 そもそも日本の原発を中核においたエネルギー政策は、米ソの冷戦時代に、日本国民の「反核」感情が「反米→共産主義」という方向に傾きかけたとき、米国が「毒をもって毒を制す」と読売新聞の正力松太郎を利用して日本の世論をコントロールして無理矢理押し付けたもの（参照）。「保守＝原発推進、革新＝反原発」という日本特有の図式が作られたのもその時期だ。 最初は政治指導で原発を押し進めて来た霞ヶ関の官僚たちは、少しづつ「天下りの甘い罠」に陥り、電力業界と癒着し、星の数ほどの「天下りのための原発関連法人」を作り、「いまさら原発を辞めたら自分たちの将来が
エンジニアから見た原発
典型的な「理科系少年」として育った私にとっては、原子力発電は宇宙旅行や人工知能とならぶ「人類の英知を集めた科学技術の結晶」であり、あこがれでもあった。ブルーバックスの相対性理論に関する本はすべて読んだし、アインシュタインの書いた e=mc2 という式は私にとってはまさに「人類の英知」を象徴するシンボルであった。高校時代の前半までは、自分は物理学者になると確信していたぐらいだ。ひょんなきっかけからコンピューターの世界に足を踏み入れ、ソフトウェア・エンジニアとしての道を歩むことになったが、科学技術全般に対する情熱は今でも持っている。 そんな私なので、今までは当然のように「原子力発電」の支持者であった。資源の乏しい日本にとって「石油が不要で、二酸化炭素を放出しないクリーンな原子力発電」こそ日本にふさわしい発電方法であると信じていたし、自動車・エレクトロニクスに続く輸出産業としての原子力に期待もし
Life is beautiful: 優秀なナースがいるとシステムがなかなか改善されないという話
「Why hospitals don't learn from failures（なぜ病院は失敗から学ばないのか）」という論文を読んでなるほどと思う部分があったので、ここにメモ代わりに書いておく。 この論文の筆者（TuckerとEdmondson）は、医療ミスがなかなか減らない原因を探るために、全米の１０の病院を長期間に渡って調査・研究したのだが、その結果判明したのは、「システムの改善」という観点からは、ナースの優秀さと勤勉さが逆効果になっているという皮肉な話。 「優秀なナース」の定義はどこでも同じで、「目の前の患者が必要としているものを、あらゆる障害を乗り越えていち早く提供する」こと。取り替えるべきシーツが不足していれば別の階に走って行って調達してくるし、新米のナースのミスにはいちいち噛み付くこともなくそのミスを取り繕う。そんなナースたちにとっては、その手の「不具合」や「障害」は避けられ
google appengine に関してひと言
ここ数日、Twitter上で appengine に関する発言をたくさん目にする。それを見る限り、「注目をされてはいるが、手を出しかねている人が多い」というのが現状だろう。そこで、私からもひと言。 App Engine は純粋なソフトウェア・エンジニアにとっての天国 私自身、色々な開発環境を試して来たが、私のようにプログラミングが大好きで、新しい言語や環境を学ぶのが楽しくて仕方が無いエンジニアにとっては、「App Engineは天国」というのが正直な感想。SQLやRailsのように一見開発効率を良くしてはくれるが、直感的に実行効率とかが把握できない「補助輪付きプログラミング」と違い、App Engine上でのプログラミングは、ちょっと手を抜くとすぐに実行効率の悪さとして跳ね返ってくる「一輪車プログラミング」。 新しい言語を学ぶのが苦ならApp Engineは避けた方が良い 現時点で、Pyt
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
スタートダッシュ型仕事術：実践編
昨日書いた「『時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す』という働き方」というエントリー、Twitterやハテブでたくさんのフィードバックをいただいたが、その中で気になったものの一つが、「そうは言っても仕様がころころ変更になるからスタートダッシュで仕事をしていたら時間が無駄になる」というもの。 まず最初に言っておくと、「仕様がころころ変更になる」のはソフトウェアの宿命。どんなに頭の良い人が設計しても、「作ってみなければ分からない」「使ってみなければ分からない」ことはどうしてもあるので、「アーキテクチャの大幅な変更」「ユーザーインターフェイスの大幅な変更」があるのはあたりまえ。 ぜひとも認識して欲しいのは、「だからこそスタートダッシュで肝となる部分を一気に作って、早めに（仕様変更が必用かどうかの）見極めをする必用がある」という点。特に「作って見なければ分からない」部
Google App Engine入門：Datastore上で「ユニーク制限」を実現する方法
Google App Engine のDatastoreには、通常のリレーショナルデータベースと比べた時にいくつかの制限があるが、その一つが「このプロパティの値は常にユニークでなければならない」という指定（ユニーク制限）ができないことである。 Invoice IDのように自動生成するものであれば、アプリケーション側でなんとかすることも簡単だが、メールアドレスやハンドル名など、ユーザーが入力するものになると、ユニークであることをきちんと判定した上でEntityを作ることが必要になる。 もちろん、単純に「有無をチェックして、なければ作る」というプログラムではスレッド間の競合に対応できないので、そこはトランザクションを使ってアトミックに処理をする必要がある。 App Engine上でトランザクションを実現するには、エンティティグループという仕組みを使って行うが、気をつけなければいけないのは、エン
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に繋げ
iPad用スタイラスを自作する方法
iPad向けのお絵描きソフトを共同開発している友人（Pete）と私が会う時は、お互いにiPadを持ち寄って、（自分たちの作ったアプリで）メモを取りながら色々と相談をしているのだが、彼がその時に必ず持って来るのがスタイラスペン。 確かに指より細いので書きやすそうだが、その価格が１２ドルと聞いて「それは暴利だ！」とつい叫んでしまった私である。Peteは動揺もせずに「このスポンジが特殊なんだよ」と自慢げに見せてくれたのが、そのスタイラスの先っぽについた黒いスポンジ。 なんだか見覚えのあるスポンジだったので、「このスポンジなら秋葉原で入手できる」と言った私に、「それなら今度日本に行った時に買って来て証明してみせろ」というPete。 そこで早速、今回の出張を利用して秋葉原に行って来た。例の「部品市場」の二階のどう考えても消防法違反をしていそうな店の一軒に入り、「名前は知らないんだけど、例のIC用のス
iPadに最適化したPDFファイルの作り方
iPad向けにPDF/マンガリーダーCloudReadersを発表してから、いままで直に付き合いがなかった出版業界の人たちからちょくちょくコンタクトをいただくようになった。その中で良くある質問の一つが、「iPad向けに最適化したPDFファイルの作り方」。そこで今日は、そのあたりのノウハウをまとめて書いてみる。 まもなく日本でも発売されようとしているiPadは色々な意味で画期的なデバイスだが、あくまで位置づけはモバイル・コンピューターであり、パソコンではない。画面も大きく、CPUも高速になったとは言え、搭載するメモリ（RAM）の量はiPhone 3GSと同じだ。 そのため、メモリがふんだんにあるパソコン用に作ったPDFファイルを読もうとすると、メモリ不足でアプリが落ちたり、極端に遅くなったりしてしまう。アプリを作る側もいろいろと対応はしてはいるが（参照）、やはり快適にiPad上でPDFファル
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
