Previous month:
October 2007
Next month:
December 2007

ナノチューブ・ラジオの動作原理

...the antenna and tuner are implemented in a radically different manner than traditional radios, receiving signals via high frequency mechanical vibrations of the nanotube rather than through traditional electrical means...【Nanotube Radioより引用】

 「ナノチューブ・ラジオの作成に成功」とのニュースを見たのだが、そこではその原理がちゃんと説明されてなかったので、もともとの論文にまで遡って調べてみた。

 これが革新的なのは、このラジオが物理的な「共振」の原理を使って、ラジオ信号を拾っていること。ナノチューブで作られた「アンテナ」は、その形状から決まる固有の振動数を持ち、その振動数と同一の周波数を持つ電波のみを拾うことになる。つまり、この「ナノチューブ・アンテナ」は、アンテナとチューナーの両方の役目を果たすのだ。このナノチューブの動きを電気の信号に変換し、増幅してスピーカーを鳴らすようにすればラジオの出来上がり。

 下の写真が、その「ナノチューブ・アンテナ」の顕微鏡写真。それが実際に動作している映像(当然、音声付き)がこれ


Javascriptの「this」は日本語の「僕」みたいなものだ、と言ってみるテスト

 先日のエントリーで、Javascriptのthisについてブツブツと言ってみたところ、なかなか良いトラックバックが返って来たので紹介。 

setInterval(this.callback, 33)がうまく動かない理由

 コメント欄でも少し会話を続けたのだが、こんな「ゆるい」コミュニケーションがとても心地良い今日このごろ。

 ◇ ◇ ◇

 ちなみに、thisの説明をするときに、「Javascriptのthisは日本語の「僕」みたいなもの」と言ってみるのはどうだろう。

 太郎「僕はPerlが好き」         // この「僕」は、
 次郎「僕はやっぱりPHPだよ」        // この「僕」とも違うし
 太郎「三郎だったら『僕は絶対Ruby』と言うに決まってるよ」 // この「僕」とも違う

 ただし気をつけなければいけないのは、太郎が次郎に向かって、

「三郎に会ったら『僕に電話して』って伝えといて」

と言った場合、日本語なら「僕=太郎」なことは自明だが、Javascriptのインタープリタは「僕=次郎」と解釈してしまうこと。そのあいまいさを避けるためには、

「三郎に会ったら『太郎が「僕に電話して」って言っていたよ』って伝えといて」

と言う必要がある。

 かえって混乱しちゃうかな?


「au向けのiPhoneは作ってはいけない」という契約になっている(らしい)

 UWで受講している"General Management & Strategy"という授業の課題の一つが「携帯電話事業」に関する"Five Forces Analysis" (新規参入の難しさ、業界内の戦いの厳しさ、などの5つの側面から業界を分析すること)。2000年からこの業界で働いている上に、iPhoneやgPhoneに関しては誰にも頼まれてもいないのにブログで色々と書きまくっている私としては、「待ってました」という感じのテーマ。

 とは言っても、何の資料も使わずに書いても説得力がないので、ネットで少し調べものをしてみたところ、思わぬ発見。今年の5月の記事(USAToday)だが、AT&TとAppleの間の契約について、公式発表には含まれていない条件が書かれている。

AT&T has exclusive U.S. distribution rights for five years — an eternity in the go-go cellphone world. And Apple is barred for that time from developing a version of the iPhone for CDMA wireless networks.【AT&T eager to wield its iWeapon - USATODAY.comより引用】

 ソースがあきらかではないので、この手の記事は必ずしも頭から信じては行けないのだが、もし本当だとすると、Appleは5年間の間、米国に限らずCDMAキャリア向けにiPhoneを作ることはできない。CDMAキャリアと言えば、米国ではVerizonとSprint Netel、日本ではKDDI/au。つまり、iPhoneはやはりDoCoMoかSoftbankからということになるのか。

 AT&Tとすれば、米国内でのiPhoneの排他的権利さえ持てれば十分にも思えるが、そこを「(米国に限らず)CDMA向けのiPhoneを作ってはいけない」とまで踏み込んだ契約を本当にしたのだとすれば、これは結構面白い。

 まあ、歴史を遡ってみれば、「3Gに関してはDoCoMoと足を並べてWCDMAで行く」とKDDIが一度アナウンスしながら土壇場でCDMA 1xRTTに切り替えた裏での政治駆け引きの結果が、ここになって影響を及ぼすとはなんとも面白い。KDDIとしても、CDMA 1xRTTを選んだおかげで良かったことも悪かったこともたくさんあるわけで、たかだかiPhoneだけのことで大騒ぎをする必要もないのかも知れないが、どうなんだろう。

 おっと、ブログを書いている暇なんかないはずだった。勉強、勉強、と。


ianime.jsの高速化

 先日公開した、iPhone/iPod touch用アニメーション・ライブラリ「ianime.js」、夕食を食べながらもっと早くできそうなアイデアが浮かんだのでちょっとトライ。これが思い通りの効果を出して、50個のアイコンを特別な効果なしに動かした時のフレームレートを11fpsから15fpsに改善。

 iPhone/iPod touchのJavascriptの実行があまりに遅いので、ちょっとでも余計な条件判定やファンクションコールが入るだけで格段に遅くなる。そこを上手に避けながら、かつさまざまなオプション機能を提供する、というのはなかなか難しい。

 ちなみに今回のデモは、アイコンの落ちるスピードに少し変化を持たせたベンチマーク。これだとその変化の分だけ遅くなり14fpsほどだが、ちょっとした落ちゲー(「さめがめ」とか「bejewlled」)の効果には十分。「連鎖」だってこなせる^^。

http://satoshi.blogs.com/ianime/test20.html

  ◇ ◇ ◇

 しかし、javascriptのsetIntervalには悩まされてしまった。コールバック関数にthisを渡す方法がなかなか見つからずに、色々と無駄なことをしてしまったのだ。結論から言えば、

var self = this;
setInterval(function() {self.callback();}, 33);

で良かったのだが、この二行にたどり着くまでにいったい何行の無駄なコードを書いたのだろう(短い文章を書く方が時間がかかるというが、プログラムも同じだ)。

 どうして

setInterval(this.callback, 33);

setInterval(function() {this.callback();}, 33);

ではだめなのかをちゃんと理解している人ってどのくらいいるんだろう?このあたりの「直感的なプログラミングのしにくさ」っていうのがJavascriptの欠点だと私は思っているんだが、どうなんだろう。


優秀なエンジニアは「入社時のスキルを問わない会社」には就職してはいけない

 ちまたで問題になっているIPAフォーラム2007に参加した学生がエントリーを書いているのだが、それが半端じゃないぐらいのエンターテイメント。

...IT産業というよりSIerの人気がないことについて語りたいだけなんじゃないかという顔ぶれだったし...

...はてなブックマークのコメントを見ている限りでは、パネリストの方々は相当現実の見えていない発言をしているようだ。...

...ITを専攻している学生達からは、「就職時にITスキルが問われないのだとしたら、大学でやっていることには何の意味があるのか」という質問が出ていたのだけど、明確な回答はなかったと思う。その人たちは、ちょっとショックを受けていたような気がする。...

...その流れで、「入社時にITのスキルを問わないというのは、Googleのような企業の方針とは反対であるが、それですばらしいサービスを作ることができるのか」という質問が出たのだけど、「Googleの開発と日本のカスタムメイドなシステムを作るSIerの開発は違うもの。Googleはスモールチームで仕上げるが、日本は製造業的にラインを組んで仕上げるため、いろんな人材が必要になる。」とのこと。単に効率の悪いシステム開発をしているということではないかと思ったのだが、どうなのでしょう。...

IPAフォーラム2007で討論してきた - 東大MOT学生の奮闘記より引用】

 先入観のない学生の目で見ても、日本のSIerのイメージは良くないし、このフォーラムでもまったくそこは拭えていない。唯一の救いが、この学生もSIer = IT業界ではないことを知っていることぐらいか。

 しかし、この書き手の学生だが、なかなかものが良く見えているようですばらしい。特に「入社時のスキルを問わない」点に関する問題意識もマトを得ている。

 ちゃんと大学でコンピューター・サイエンスを学んだ学生は決して「入社時のスキルを問わない」ような企業には行くようなもったいないことをしては行けない。「入社時のスキルを問わない企業」が「技術力ではなく安い人件費と体力で勝負している会社(=7K企業)」「社員教育を顧客の金を使ってする会社」である可能性はものすごく高いのだから。

 しかしよくも堂々と「日本は製造業的にラインを組んで仕上げる」と言えたもんだ(「ソフトウェアの仕様書は料理のレシピに似ている」参照)。そんな会社には私だったら絶対に行かないし、知り合いの学生の相談されたら「絶対に行くな」と説得する。いつまでもそんな仕事のさせかたをしているということそのものが諸悪の根源だってことを、SIerのトップが心の底から理解できるまでは、どんなPR活動を行っても学生は来ない。

 自分は「プログラムを書くために生まれて来た」と思えるぐらいプログラミングが好きで、それで自分のキャリアパスを作ってみたいのならば、逆に「優秀なプログラマーしか採用しない」企業に入って自分より優秀な人に囲まれて自分を磨くべき。上場企業ばかりでなく、小さなベンチャー企業にも目を向ければそんなところはたくさんあるんだから。

【雑記】恥ずかしい話だが、数年前まで「SIer」のことを「SI屋」だとばかり思っていた私である。でも最近はやはり「SI屋」の方があっているんではないかと思う。うどん屋、本屋、総会屋、テキ屋、質屋、SI屋、人材派遣屋、ウェブ・サービス屋、組み込み屋、ソシアル・ネットワーク屋、... だんだん苦しくなって来た。


じょうずな討論会のやり方

今日の討論会を見て思ったのは、明石家さんまのやっている番組「恋のからさわぎ」「踊るさんま御殿」のやり方がうまいということ。これらの番組では、あらかじめお題について回答させておき、その回答に対する詳細説明として話をしてもらう。
IPAフォーラム2007 - 発声練習より引用】

 全く同じ情報を得ながら、そこから学ぶものが大きく違うということは良くある。「恋のからさわぎ」は何度か見たことがあるが、あれがシロウトの頭を真っ白にしないための綿密な手法だとは全く気がつかなかった私はいったい何を見ていたんだろう^^;。

 とにかく、これは本当に使えそうなので今度機会があったらぜひとも試してみたい。CTIA wireless (Cellular Telecommunications & Internet Association Wireless)みたいな思いっきりまじめなカンファレンスで「恋のからさわぎ方式のパネル・ディスカッション」。そのギャップがなんとも楽しそう...。


これは今年一番の名言かも。ちなみに、「業界の文鎮」とは?

大変恐縮なのだが、私はこの参加者のすごさが全く理解できなかった。...なぜなら、彼ら「業界の重鎮」たちが、何を作ったのか、そこには全く書かれていないから。
404 Blog Not Found:イメージを形にできない人は減衰するより引用】

 たとえ今はたまたま一部上場企業の重役というタイトルを持っていても、その役職をはずしたら「ただの人」。そんな人たちを重鎮とは呼ぶべきではないし、そんな人たちが何を語ったところで業界の魅力はまったく伝わらない、という指摘。

 私も今まで同じようなことをあの手この手で語っては来たのだが、ここまでクリアなメッセージを伝えることに成功できたことはなかったと思う。

 ちなみに、本文中に「ビジョンを語るのは文鎮の仕事じゃない。」と書いてあるが、これはなんなんだろうか?「役職の重さだけで偉そうにして座っている人=文鎮」という皮肉か?


gPhone雑感:「モバイル・プラットフォーム戦国時代」の幕開けだ

 今朝になって、話題のgPhoneがアナウンスされた(参照1)訳だが、大方の予想を裏切ってそれはデバイスではなくてソフトウェア、それも2005年にGoogleが買収したandroidという会社の作っていたLinuxベースのマイクロ・カーネルと、バーチャル・マシン。androidの買収とともにGoogleに入ったAndy Rubinがandroidの前に作ったSidekick (Danger Inc.)の中身を良く知る私としては、「これってDanger OSとどこがちがうんねん?」という感じ。

 ほぼ同じ時期に会社をスタートしたこともあり、Dangerの連中とはスタートアップ当時から一緒に仕事をし、サードパーティとしてSidekick向けのソフトウェアを作った数少ない会社の一つがうちの会社UIEvolution Inc.だ(資料2)。

 Javaに似てはいるが微妙に異なるバーチャル・マシンを持ち、独自のAPIを提供するDanger OS向けにアプリケーションを作る企業はなかなか見つらなかったようだ。そこでうちの会社が、UIEngineをポーティングした上で、UIEngine上で走るゲームを5つばかり提供した、という経緯がある(T-Mobileから発売されたSidekickにプリインストールされた)。

 結局のところ、Sidekickというデバイスはメインストリームにはなれなかったし、Danger OSもサードパーティによるアプリケーション・マーケットができるまでには育たなかった。Andyとしてはそれが悔しくて、今度はデバイスではなく純粋にソフトウェアを作る会社、androidを作ったのだろう。

 そこに目をつけたGoogleが2005年8月に買収し(資料3)、ここまで密かに育てたあげくに「オープン・プラットフォーム」として提供することにしたのである。「モバイル向けのバーチャル・マシンなら、うちの方がはるかに老舗(しにせ)なのに、何でうちを買収しなかったんだろう」と一瞬憤慨したが、考えてみれば、うちはその1年以上前(2004年3月)に買収されていたぞ、と。タイミングは大切だ。

 Andyのことだから、Sidekickと似たようなバーチャル・マシンを作った可能性は十分ある。モバイル・デバイスに要求されるセキュリティを考えれば、アプリをサンドボックスに閉じ込めることができるバーチャル・マシンは必須だ(ここが、QualcommのBREWの致命的な欠陥だが、本題から外れるので今日はここまで)。

 Androidのバーチャル・マシンがまたまたJavaのVMライクなものかどうかは何とも予想しがたいが、Googleがモバイル向けのウェブ・アプリケーションのプラットフォームと位置づけるのであれば、Javascript向けVMであることも十分に考えられる。ちまたでは、GoogleがWebkit陣営に加わるとの噂もあり、そこから推理すると、gPhoneのブラウザーはWebkitベースで、そこにAndyの作ったJavascript VMが組み合わされる、というのはとってもありそう。まあ、そのあたりの情報はおいおいと明らかにされるだろう。

 Androidの正式なアナウンスと同時に公開されたのが、"open handset alliance"という組織のサイト(資料4)。まだまだ参加企業の数は少ないが(このエントリーを書いている時点で8社34社)、この「オープン」というキーワードを武器にパートナーを集めようと言うのがGoogleの戦略。

 ちなみに、このandroidとほぼ真っ向から戦うことになるのが、(1) MicrosoftのWindows Mobile、(2) Nokia+Symbian、(3) Ericsson+Motorola+UIQ (資料5)、(4) Qualcomm BREW。少し番外で追いかけるのが、SavaJを買収した (5) Sun Microsystems (資料6)。そして、マイペースで我が道を行くのが(6)アップル(資料7)。すごいメンツだ。

 日本のアプリックスも同じようなものを作る試みはしていたようだが、主要な顧客(うわさではSamsung)を逃して特損67億円を計上したばかりだ(資料8)。PalmSourceを300億円以上かけて買収(資料9)したアクセスも当然ここを狙っているわけだが、さすがにここまでのメンツが揃ってくると戦うのも楽ではない。

 これに加えて、ドコモなどの携帯電話事業者も黙ってはおらず、「キャリア主導」のプラットフォーム(資料10)を作ろうとするから、マーケットはますます混乱するのは目に見えている。モバイル・プラットフォーム戦国時代の幕開けだ。

【追記】続々と新しい情報がブログ等で公開されている。Googleからの公式情報ではないが、VMに関してはDangerと同じくJava VMライクなものであること、それに加えてskiaというやはりGoogleが買収した会社のベクター・グラフィック・スライブラリが提供されるだろうことが書かれている(資料11)。ベクター・グラフィックスに関しては、オープンをうたう限りは、HTML5.0でも標準となるcanvasにAPIを合わせるのが当然と思うんだがどうなんだろう。

 ◇ ◇ ◇

 え?UIEvolutionは指を加えて見ているのかって?いやいや、うちはもう一つ上のレイヤーなので。UIEngineは既にJava, BREW, Flash, Symbian, Linux の上で動いているし、Android VMの上にだろうと、iPhoneの上にだろうと簡単に移植できるのがUIEngineの強み^^。


iPhoneのベンチマーク:javascriptの実行は遅いがcanvasがなかなか

 昨日発表した、iPhone用アニメーション・スクリプトianime.js、遅いという評判のiPhoneのJavascriptを使って、いったいどのくらいの数のオブジェクトを同時に動かすことができるかを測定するページを作ってみた。

回転なし:http://satoshi.blogs.com/ianime/test16.html

回転あり:http://satoshi.blogs.com/ianime/test17.html

 50個のアイコンを表示し、クリックしたアイコンから下のアイコンすべてを同時に1秒間アニメーションさせ、最後に何フレーム描画することができたか(fps)を表示する仕組みだ。setInterval()には33msecを与えているので、最大で30-31フレームは表示できるはず(実際パソコンで実行すると50個全部動かしても余裕で31フレームになる)。Javascriptの実行がそれに追いつかなければ(つまり、1フレームあたりの処理が33ms以内に終わらなければ)、「フレーム落ち」を起こし、数値が30未満になる。

 iPhoneで測定した結果は以下の通り(回転あり、回転なし、の順)。

50個:11 fps, 8fps
40個:12 fps, 9fps
30個:14 fps, 11fps
20個:16 fps, 13fps
10個:19 fps, 16fps

 用途にもよるが、20〜30個ぐらいのオブジェクトをぐりぐりと動かすのはなんら問題がなさそうである。「ギャラクシアン」ぐらいのアニメーションなら十分に可能なスピードだ。

 興味深いのは、アイコンの回転という複雑なことをさせても、あまりスピードに影響がないこと。やはり、「javascriptの実行そのものはあまり早くないが、描画そのものはGPUのおかげでかなり高速化されている」という話は本当らしい。これがCPUの問題なのか単にjavascriptの実装が悪いのかは不明だが、少なくともcanvasの実装だけはなかなかなので、canvasに頼った形でアプリケーションを作ることがiPhone用のインタラクティブなアプリを作るこつではあるようだ。

 下に貼付けたのは、回転がある方のテスト・ページ。Safari、Firefox では動作確認済み(IEは未サポート、Operaでも動くとの報告を受けている)。適当なアイコンをクリックすると、アニメーションが始まる。


ianime.js、iPhone/iPod touch 用アニメーション・ライブラリ

 先日予告したiPhone向けのアニメーション・プログラムの解説だが、解説のためにソースコードを整理しているうちに、どうしてもライブラリ化したくなってしまい、土曜日の午前中を使ってianime.jsというアニメーション用のライブラリを作ってしまった。まだ色々とやりたいことはあるのだが、温存しておくと熱意が冷めてしまうたちなので、一気に公開。ただし、解説は予告通り英語で書かせていただいた。

ianime.js - Animation Javascript Library for iPhone and iPod touch

    「Javascript使い」の方たちには、ぜひとも遊んでいただきたい。私自身、javascriptのprototypeを使うのは初めてなのでとんだ勘違いをしているかも知れないので、そこは遠慮なく指摘していただきたい(人前で自分の間違いを指摘されても平気なたちなので)。

 なお、リンク先のコメント欄は英語圏の人たち様に英語限定にしたいので(日本語のコメントがずらずら並ぶとひかれてしまうかも知れないので)、日本語のコメントはこちらのエントリーにいただけるとありがたい。

 ちなみに、次のバージョン・アップでぜひとも入れたいのが、GIFアニメのように、複数の画像を順番に表示しながら動かすことにより、「人が歩いている姿」「鳥が羽ばたきながら飛ぶ姿」とかを簡単に実現する仕組み。デモ作りのための著作権フリーの素材を探しているのだが、どなたがご存知のかたがいらしたら、ぜひとも教えていただきたい。

 おまけに、英語版では未公開のデモをここに貼付けておく。iPhone/iPod touch だけでなく、FirefoxかSafariをお使いの方であれば見ることができるはずである(IEは未サポート)。アイコンをどんどんとクリックしていくと、それぞれが同時に、かつ独立に動くところがミソである。これがiPhoneで動いたときには嬉しくてはりきって息子(18)に見せたのだが、「これなに?え、ゲームじゃないの?」との反応。まあ、当然と言えば当然なんだが...^^;。