北朝鮮のミサイル発射施設を見てみる
今回の北朝鮮によるミサイル発射実験は、米国でもトップニュース。ニュースの一つに、ミサイル発射施設の衛星写真が掲載されていたので、Google Mapでも見れるものかと試してみると、さすがにミサイルの形までは分からないが、なにやらそれらしき施設があることは分かる。 そこで、さっそく北朝鮮のミサイル発射施設をGoogle Mapで見るための簡単なMash-upアプリを作ってみた。下の衛星写真上のマーカー（ミサイル発射施設の場所）をクリックすると、そこの拡大写真をみることができ、さらにそこにあるマーカー（４つある）をクリックすると、それぞれの設備を更に拡大した写真を見られる、という趣向だ。 【追記】ソースコードを見たい人は、「北朝鮮ミサイル発射ページ」を開いてそのページのソースを見ていただければよい。
対称性の大切さをトイレットペーパーに学ぶ
以前にも書いたことがあると思うが、私は「商品の『能書き』を読むこと」が妙に好きである。コーンフレークを食べながらついついそのパッケージに書いてある文字を隅から隅まで読んでしまったり、お風呂につかりながら入浴剤の成分を確認したり、という毎日を送っている私だが、色々と発見もあるし勉強にもなる。 先日も、宿泊先の旅館のトイレにおいてあったトイレットペーパーの『能書き』を読んでいたのだが、あまりにもツッコミどころが多いので、感動して写真を撮ってきた（トイレの中で「ピロリーン」という音を立てていたのは私である）。 何と言っても「対称性」が思いっきり壊れている点がすごい。何かを箇条書きにしたり、アイコンやボタンを並べたり、APIを決める際には、対称性を強く意識することが大切であることは周知のことであるが（「ノンデザイナーズ・デザインブック」に丁寧に説明してある）、この『能書き』は絶好の反面教師だ。 ま
「登録ユーザー数１００万人突破！」などという数字が素直に受け取れない私
先月日本に戻った時に小田急線内で見かけた自社広告。一見数字とグラフで説得力があるように書かれているのだが、この文章で使われている「混雑率」の定義： ※全体（８両編成）の混雑を１００％とした場合 の「混雑」の定義があいまいなのがものすごく気になる。 ８号車が２６％、１号車が６％となっている所を見ると、実際に乗っている人の数ではなさそうだ。立っている人の数にしてもおかしい。 たぶん、小田急線なりの「一両あたりの定員」が定義されており、それを超した人数を各車両で数えて、それを「混雑」と呼んでいるのだろうとは予想できるが、それならちゃんとそう書いて欲しい。 子供のころはこの手のものを見ると「きっと大人はみんな『混雑率』の定義を知っているんだろうな」など謙虚に世の中を見ていた私だが、大人になってまわりを見ると、結構世の中には定義があやふやなものがあふれているの。定義があいまいでも全然気にしないで使っ
スターバックス２．０
さすがにスターバックス発祥の地だけあってシアトル近郊にはスタバがたくさんあり、どこも繁盛している。私が良く立ち寄るスタバも常に数人の人がレジに並んでいるのだが、それにも関わらずあまり待たされることはないのがすばらしい。 レジに並んでいると、手が空いたバリスタが列まで来てくれて「あなたは何を頼むの？」と注文を聞き、レジでお金を払う前に作り始めてくれるのである。そのため、レジでお金を払った後の待ち時間が、従来よりずっと少なくなったのだ。 ラテを飲みながら「これはパイプライン処理と呼ぶべきだろうか、それとも非同期通信と呼ぶべきだろうか？AJAX化されたスタバは今や2.0か？」などとくだらないことを考えてしまう理科系頭の私である。
UIEngine で AJAX な RPG ゲーム
CTIA2006が先週ラスベガスで開かれたことは、すでにこのブログに書いたが、一つ大切なことをアナウンスし忘れていた。米DisneyがUIEngineで作ったRPGゲーム「The Chronicles of Narnia」が、GameSpotとCNetの主催するモバイル・エンターテイメント・アワードの「RPG/Adventure」ゲーム部門で堂々の二位に選ばれたのだ（参照）。一位を取ったのは同時に全部門での金賞に輝いた「Doom RPG」である。 The Chronicles of Narnia は米DisneyとUIEvolutionが共同開発したAJAXスタイルのRPGゲーム。世界１７カ国、３００機種に向けてほぼ同時にリリースされたのだが、UIEngineがJava・BREWといったプラットフォームの違いや端末ごとのクセやバグを吸収するので、ゲームそのものは一つだけ作れば良かった、とい
デジタルデバイドとユーザーエクスペリエンス
CNetのブログに「ユーザー・エクスペリエンスとパーベイシブ・アプリケーションの世界」というエントリーを書きつつ考えたことがあるので、今日はそれに関するエントリー。テーマはデジタルデバイドである。 デジタルデバイドとは、さまざまなデジタルデバイスやネットワークの恩恵を受けられる人と受けられない人の間に大きなギャップが生まれることを指す（参照）。ギャップが生まれる原因には、所得、地域、年齢、教育の違いなどさまざまなものがある。「所得・地域格差」に関しては、私のようなエンジニアに何が出来るわけでもないので口を挟むつもりはないが、「年齢・教育」に関しては言いたいことが山ほどある。 この手の議論の際に「デジタルデバイドを解消するために人々の情報リタラシーを高めよう」などという発言を聞くことがあるが、私はこの「○○リタラシー」という言葉が大嫌いだ。もともと「リタラシーがない」とは「文盲である」という
なぜFカップを持つグラビアアイドルが最近増えたのか、に関する一考察
【注："Fカップ、グラビアアイドル"でググってこのページにたどり着いた方へ】 このエントリーは、いたってまじめな科学的なテーマに関する考察であり、そういったキーワードから類推されるような画像は掲載していないので、ご了承いただきたい。 「最近のグラビアアイドルは、胸が大きくなったものだ」と感じているのは私だけでは無いはずだ。８０年代なら、CカップやDカップでも十分にグラビアアイドルとしてやっていけたが、今はFカップが当たり前である。いったいどうなっているのであろう。 一昔前であれば、それを「最近の子供達は戦後の食糧難の時期と比べて良いものを食べているから」と説明できたが、ここ数年の変化はそれでは説明できない。科学うんちくの大好きは私としては、この謎を解明せずにはいられないと考えていたのだが、その謎を解く手がかりを、先日知り合いのアメリカ人二人と食事をしているときに手に入れることができたのでこ
大規模ソフトウェアプロジェクトの臨界点
ワシントン州レドモンド市のあるスターバックスでの会話 知人：おお、Satoshi、久しぶり！ 私：やあ、最近見なかったけどどう？ 知人：言わなかったっけ、Microsoftに戻ったんだ。Vistaだよ。 私：Vistaか、大変だろう。 知人：大変なんてもんじゃないよ。 （ここから、彼の愚痴がしばらく続く） 私：そっか、大変だね。がんばってね。 知人：Satoshiは戻って来ないの？ 私：だめだめ、OSだけはもう作りたくない。 知人：そうか。でも、気が変わったらいつでも連絡してよ。 私：そっちもまた外の空気が吸いたくなったら連絡しろよ。 私は常々「プロジェクトの大きさと、エンジニアのプロダクティビティは反比例する。だから、ある程度以上にプロジェクトの規模が大きくなると幾ら人を追加しても全体のプロダクティビティは上昇しなくなる」と言ってきたが、ひょっとするとVistaはその臨界点を超えてしまっ
「ムーアの法則」とUIEngine
CNET Japan でのブログの連載を始めたのは１月の末からだが、このブログとのバランスをどうするかは結構悩みであった。そこで、CNet側ではある程度テーマを絞り連載コラムの様に書く、という手法を採って来たのだが、その日に思ったことを気楽に書くこのブログと比べると、まだまだ違和感がある。どうにかこうにか、編集者との「週に１～２個のエントリー」という約束をぎりぎりのところで果たしている、とう所である。 ちなみに、これを引き合いに出したのは、今朝のエントリー「ソフトウェアの肥大化とムーアの法則」に結構私としては重要だと思っていることを表現することが出来たので、このブログの読者にもぜひとも読んでいただこうと思ってのことである。 言いたいことの要点は、最後の段落、 それが実現できれば、「ムーアの法則」がもたらすものを「プラットフォームにどんどん機能を詰め込む」という方向性の進化に消費してしまうの
知的労働者には「組織を移る力」がある
前回のエントリーに、Doraさんという方から「次回エントリー『こうすれば日本のSEは救われる！』を楽しみにしております！？」とのコメントをいただき、少し悩んでしまった。日本のSIer（少し前までは「SI屋」だと思っていた）の階層構造の問題を指摘しておきながら、何も提案しないのはあまりにも無責任かも知れない。 だからと言って、「日本のIT産業はこうあるべきだ」などと部外者である私が本当の意味で影響力のある発言をするのはあまりにも難しい。特に、IT業界に限らず、一旦こういった階層構造が出来てしまうと、業界で力を持つ上位レイヤーの会社や人たちにとって、改革は自己否定にもつながりかねないので良いと分かってはいても自分からわざわざ着手できない、というジレンマがあるのが一層解決を困難にしている。 では、現時点でIT業界で苦しむSEやプログラマーの人たちは何をしたら良いのだろうか。 とても難しい問題では
Life is beautiful: SEはメニューのないレストランのウェイターか？
一昨日書いた「ソフトウェアの仕様書は料理のレシピに似ている」というエントリーに対して沢山の人からフィードバックをいただいた。このように情報を発信すると、逆により多くの情報が集まり自分にとっても勉強になる、というフィードバックプロセスがあるからブログは楽しくて仕方がない。 フィードバックの中に「これでSE不要論も再燃か？」などという過激なコメントから、自分自身がSEという立場の方からのものすごく真面目なフィードバックまでが集まったので、これを機会に、ここに私なりに「SE」という職業をどう解釈しているか書いてみようと思う。もちろん、私自身がSEという職業を経験したことがあるわけでなないので、間違っているかも知れないが、その場合は遠慮なく指摘していただきたい。 私の理解では、SEという職業はレストランに例えればウェイターである。それも、メニューから料理を選んでもらう通常のレストランとは異なり、「
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
「ラボ」サーバー設置
今年に入ってからレンタルサーバーを使って色々と遊んでいる私だが、そんな私を見て、社内からもそういった「遊び」の部分を会社として正式にサポートする仕組みを作るべきでは、という声が上がってきた。やっと分かってもらえたようだ。 そこでさっそくサーバーを「ラボ」用に一台立ち上げてもらい、その上で前から作りたいと思っていたアプリを作ってみた。携帯電話用の「シアトル近郊の交通情報表示アプリ」である。シアトル近郊の交通情報は、ワシントン州の交通局のウェブサイトに無料で公開されているのだが、携帯電話から見られるようには作られていないのだ。 そのサイトに表示されている画像をこちらのサーバー側で一度取り込み、細切れにスライスした上でディスク上にキャッシュし、それを携帯電話にダウンロードしたUIEngine上に表示してGoogle Mapのように自由にスクロールできるようにする、というアプリを前から作りたかった
元パソコン少年はマシン語の夢を見るか
このブログの副題にもあるとおり、私は高校生の時から半田ごてを握ってパソコンをプリント基板から作ったり、アセンブラでプログラムを書いて雑誌に投稿していたりした、いわゆる「パソコン少年」の第一世代である。 そんな私が最初に C という言語に出会った時は、「Cでプログラムを書くのは素人だけだ。本当のプログラマーはアセンブラだ。それも１６進のマシン語を直接書けなきゃだめだ」などと生意気なことを言っていたものである。しかし、大学に入ってから作った Candy をディスプレイドライバーを除いて全てCで書いたのも私である。 C++ にも最初は抵抗があった。当初はコンパイラの性能も低かったので、とんでもないコードを生成していたし（コンパイラの吐き出したマシン語を読まずにはいられないたちであった）、「オブジェクト指向の本質は言語ではない、プログラミングスタイルだ」（どこかで聞いたことがある）と言いながらあえ
Life is beautiful: 会社作りとモチベーションの話
UIE Japanの正式な活動が３月１日にスタートした。まずは、正社員三人、インターン二人が３月１日付けで参加。今の仕事の引継ぎが終わりしだい入社してもらえる人が三人。外部からコンサルタントなどの形で参加していただける人も含めると１０人超の会社が、去年の１１月末にこのブログで人材募集を始めてから（参照）わずか３ヶ月でここまで出来できてしまったことになる。これもすべて関係者の寛大なる理解と甚大なる努力のおかげである（感謝、感謝）。しかし、何と言っても、ネットの力を効率良く利用すると、これだけのことがこんなスピードで出来てしまうものかと、われながら関心してしまう。 木曜日と金曜日は、主に UIE Japan で作るサービスの企画に関するブレスト。面白そうなアイデアがホワイトボード一杯にかかれる。どのサービスもとても楽しそうだ。しかし、全部はとうていできないので、投票でまず４つ～５つに絞り込むこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
