で、実際のところHTML5でどのくらいのアプリが実装できるのか実験してみた少し前のエントリーでも触れた事があるが、「このままHTML5が普及してくれればスマートフォン向けのアプリの大半はHTML+CSS+Javascriptだけで作れるんじゃないか」と感じ始めている私である。 もちろん、そうなるには「規格がきちんと統一される」「まともな実装をしたスマートフォンが十分に普及する」「iPhoneの一人勝ちにはならない」などの条件が満たされる必要があるため、必ずしもそうなるとは限らないが、少なくとも「そろそろキチンと勉強しておいて損はない」技術であることは確か。
もうすぐ開始後３ヶ月になるPhotoShare
左のグラフは、PhotoShareに対するトラフィックの変化を図にしたものだが、なにを表しているかお分かりだろうか。 PhotoShareを開始したのはAppleがApp Storeをオープンした７月の１１日なので、もうすぐ３ヶ月である。ユーザーの数も順調に増えているが、何と言っても嬉しいのは、アメリカ人やフランス人の中にも定着して使い続けるヘビーユーザーが現れ始めたこと。 日本のユーザーに支持されていることは嬉しいのだが、せっかく世界中に向けて作ったサービスなので、色々な国の人に参加していただくことはとても重要。先日も、旦那が鉄道の運転手だというフランス人の女性が、運転席からのフランスの海岸の風景とかをリアルタイムで投稿してくれたのだが、そんな「体験のリアルタイムな共有」がPhotoShareならではの楽しみだ。 ちなみに、累計で投稿された写真の数が２０万枚をちょうど超えたところだが、ま
App Storeついに開店、そしてBig Canvas PhotoShareも世界にデビュー
iPhone OS 2.0のリリースに先駆けて、App Storeがついにオープンした。待ちに待ったBig Canvas最初のアプリ、PhotoShareの世界に向けたリリースだ。PhotoShareはその名前の通り「写真共有アプリ」。iPhoneで撮影した写真を友達や家族と共有することにより、「経験の共有」をしようというコミュニケーション・ツールだ。 PhotoShareの特徴はとにかく使いやすいこと。Flickr、Facebook、MySpace などの既存のSNS向けの専用iPhoneアプリがたくさん出てくることは当然予想できた（そして実際出て来た）。それにも関わらず、PhotoShareを独自のウェブ・サービスとあわせて開発をしたのは、「iPhoneに最適化されたおもてなし」を提供するため。ユーザー登録が不要なところ、すべての通信が非同期で行われること、友達や家族の招待がとても簡単
ソフトバンクに拍手：iPhone向けサービスの通話料＋通信料は7,280円
ついさっき、先日のエントリーにコメントをいただいて知ったのだが（参照）、ソフトバンクからiPhone 3G向けのサービスの詳細が発表された。 結果から言えば、 本体価格：実質23,040円 （私の予想を24,000円を下回る価格） 通話料＋通信料：7,280円 （私がお願いした8,000円を下回る価格） ととても妥当な価格。孫さんえらい。 日本では「実売価格２万４千円。ソフトバンクに対する月々の支払いが、音声＋データ＋端末月賦のすべてをあわせて８千円」というのが妥当な落としどころ。【Life is beautiful: ドイツのT-MobileはiPhoneをわずか１ユーロで売るらしいより引用】 と言って来た私としては大満足^^。 ちなみに、本体を分割で払うことになるが（月々980円を24回払い）、本体価格の定価は69,120円で、そこから特別割り引き46,080円（1920円x24ヶ月）
iPhoneがなぜそれほどまでに「革命的」なのか
iPhoneに関しては、まだ誤解している人も多いようなので、念のために解説しておくと、iPhoneがこれほどまでに通信業界で注目されているのは、マルチタッチのUIを採用しているからでも、NextStepの血を引く最先端のiPhoneOSを積んでいるからでもない。NTTドコモなどの旧来型の通信キャリアからみれば「単なるデバイスの調達先」でしかなかったデバイスメーカーがキャリアのビジネスに口も手も出している点にある。 私がAppleとAT&Tの提携発表で一番驚かされたのは、その料金体系であった。パソコン並にネットワークを使うiPhone向けの使い放題プラン（日本の「パケ放題」に相当する部分、ただし容量制限は一切ない）が月々わずか２０ドルというのは、本当に破壊的な価格である。この価格故にiPhoneは非常に魅力的なデバイスとなっているし、これだけ普及している。もちろん、それを実現するためにAT&
これぞマッド・サイエンティスト
面白い物理の実験を見せてくれるMITの教授のビデオがYoutubeで大人気だが、これを見て思い出したのは、子供のころは科学の実験の時間が大好きだった私（物理より化学だったが）。自分の家にも実験室を持とうと、小遣いをためては、ビーカー＋フラスコ＋石綿金網＋三脚＋アルコールランプと買い集めていたころを思い出す。専門の薬局に水酸化ナトリウムと塩酸を買いに行って「子供には売れない」と断られたのも私だし、木炭を作ろうとしていて部屋の中に一酸化炭素が充満してしまい、「何このにおい！」と母親に助け出されたのも私だ。 ちなみに、このビデオは落下する水と空き缶だけで発電するという実験。確かにすごい。こんな先生ばかりだったら、科学好きの子供たちが増えるだろうなあ、と。
HTML+JSでプレゼン、YAML版も作ってみた
一つ前のエントリーに対して、アップルの増井さんから「もうちょっとシンプルな『メタ言語』で良いんじゃないでしょうか。YAMLみたいなのとか。」という良いアイデアをいただいたので、早速実装。先のサンプルが、ページ内にこんな感じで直接記述できる。 ==iAnime.js: Benefits *Small footprint (<6KB compressed) *Lightweight (runs fine on iPhone) *Works well with jQuery.js and prototype.js *Free (MIT license) ==iAnime.js: Power *Easy to use (only three methods) *Powerful JSON-based animation language *Extensivle ("effects" and "pl
iAnime.js のドキュメントがようやく完成
v.28でようやく一段落したiAnime.jsだが、ドキュメントもようやく数日遅れで完成。コードを書くのは楽しいが、ドキュメントを書くのはけっこう大変だ。まだまだやりたいことはたくさんあるのだが、コードばかり書いているとドキュメントが大幅に遅れてしまうので、ここで一度キャッチアップ。 ちなみに、ドキュメントは以下の４ページから成り立っている。 デザイン・プリンシプルとファイル構成についての説明 コンストラクターとメソッド アニメーション・インストラクション アニメーション・エフェクト 質問や要望はこのブログでも受け付けるし、Googleグループのianimejsグループでも受け付ける。あと、コードそのものに対するコメントも大歓迎（最新版は、Google CodeのiAnime.jsプロジェクトページからダウンロード可能）。 ちなみに、現状で動作確認が出来ているのが、パソコン用でSafari
Life is beautiful: Javascript、クロージャを使ったプライベート関数の隠蔽について
（このエントリーは「Javascriptクイズ：無名関数と実行効率の話」の続編。） 「？？？」と頭をかしげる太郎に、「じゃあ、これだったらどうかな？」と三郎はコードを書き始めます。 function code2name(code) { var mapping = { 'us': 'United States', 'ja': 'Japan', 'ko': 'Korea', 'ru': 'Russa', 'uk': 'United Kingdom', 'fr': 'France', 'cc': 'China', 'gw': 'Germany' }; return mapping[code] || '(unknown)'; } 「カントリーコードを国名に変換しているんですね。」と太郎。 「どこが問題だか分かる？」 「うーん、マッピングのためのオブジェクトを毎回作り直しているところかな。」 「そう
iaime.js v0.28: style-tweenを追加
ようやく期末試験もメドが付いたので欲しかったstyle-tween機能をiAnime.jsに追加（v0.28としてGoogle code/ianimejsにリリース済み）。使い方は下の例を見ていただければ自明だと思うが、アニメーション前のスタイルと後のスタイルをfrom/toで指定するとその間を指定した時間で変化させる。JSON形式で渡すため、スタイルシートとは少し異り、値の方は必ず"か'で囲う必要があるし、スタイル名が'-'を含む場合も"か'で囲う必要がある。色のフォーマットは#rrggbb形式のみサポート。 anime.add({ element:this, effect:'style', from: { background: '#eeffff', 'font-size':'10pt', width:'20pt', height:'14pt', margin:'1pt', 'padd
Life is beautiful: フィボナッチ関数とJavascriptの黒魔術と
「最近あなたのブログ、プログラミングの話ばっかりじゃない？」とは妻の指摘。確かにその通りなんだが、これとかこれを読んでしまうと、どうしてもそちらに走りたくなるのが私の性分。ということで、とことん「ギーク街道」に堕ちてみた。 今回の作品は、iAnime.jsの非同期JSON言語（名前はまだない）を使って非同期に自分を再帰的に呼び出しながらただひたすらにフィボナッチ数列を表示するというプログラム。 function start(k1, k2) { var span = (k2+" ").length*10; var obj=document.createElement("span"); obj.style.position = "absolute"; obj.style.left = -span+"px"; obj.style.right = "0px"; iBrowse.setText(ob
iAnime.js をGoogle code上のオープンソース・プロジェクトとして正式スタート
「オープンソースとして自分の書いたコードを公開する」意味を知るために初めたianime.jsプロジェクト。そろそろ形も整い始めたので、週末を利用してGoogle codeにプロジェクトを立てて本格的なオープン・ソース・プロジェクトとしてスタートすることにした。 Google code - iAnime.js: ligh-weight javascript engine for PC and iPhone これからドキュメントやサンプルの整備など、やることはたくさんあるが、こうやって公の場にプロジェクトを立てることによって自分にプレッシャーを与えるのも良いかも知れない。 あまり欲張っても長続きしないだろうから、とりあえずはiFreecellを題材に、iAnime.jsを使ったゲーム・プログラミング入門のようなものをシリーズ化してwikiに書いてみようかと思う。 ちなみに、ライセンス形態として
gPhone雑感：「モバイル・プラットフォーム戦国時代」の幕開けだ
今朝になって、話題のgPhoneがアナウンスされた（参照１）訳だが、大方の予想を裏切ってそれはデバイスではなくてソフトウェア、それも2005年にGoogleが買収したandroidという会社の作っていたLinuxベースのマイクロ・カーネルと、バーチャル・マシン。androidの買収とともにGoogleに入ったAndy Rubinがandroidの前に作ったSidekick (Danger Inc.)の中身を良く知る私としては、「これってDanger OSとどこがちがうんねん？」という感じ。 ほぼ同じ時期に会社をスタートしたこともあり、Dangerの連中とはスタートアップ当時から一緒に仕事をし、サードパーティとしてSidekick向けのソフトウェアを作った数少ない会社の一つがうちの会社UIEvolution Inc.だ（資料２）。 Javaに似てはいるが微妙に異なるバーチャル・マシンを持ち、
普通のiPhoneユーザーは月に100MB以上のデータを送受信する
iPhoneは現在のところ米国でしか販売されていないし、AT&Tのネットワークでしか使えないが、興味深いのがそのデータ通信料金。使い放題で$20ドル（訳2400円）と良心的な値段だが、一つ興味があったのが、パソコン並の機能を持ったブラウザーとメールクライアントを乗せたiPhoneの場合、どのくらいのデータ量を使うことになるのだろうということ。 ちょうどiPhoneを入手して二週間になるので、settings->usageのページを開いて調べてみた。AT&TのEDGEネットワークを使って（つまりWiFiの圏外で）送信したデータが20MB、受信したデータが120MBである。これを月に換算すると300MB近いデータ（パケット換算で200万以上）を送受信することになる。 私がヘビーユーザーであることを差し引いても、普通のユーザーが月に100MB（78万パケット）以上のデータを送受信する可能性は十分
ビルゲイツの面接試験―ドラゴン桜編、解答
大晦日に出題した「ビルゲイツの面接試験―ドラゴン桜編」。「４つ」という典型的な誤答から、「８つ（図付き）」という正解まで寄せられた。 やみくもに探しても注意深い人であれば８つ全部を見つけることは可能かもしれないが、そんな解き方は再現性・信頼性の意味でもあまり好ましくない。ソフトウェア・エンジニアとしては、やみくもに探すのではなく、きちんと筋道立てて考えて、抜かりなくすべてのケースを見つけ出すように考える習慣を身につけて欲しい。 そこで、私が解いた手順を参考までに下に示す。 まず、円と円との接し方には外接と内接があることに着目する。すると、平面上に二つの円があるのだから、それぞれに外接・内接をする組み合わせを考えれば、「外接・外接」「内接・外接」「外接・内接」「内接・内接」の４通りがあることが分かる。 そこでまず、ひとまず直線のことは無視して、両方の円に外接する円にはどんなものがあるかを考え
Life is beautiful: ビルゲイツの面接試験―ドラゴン桜編
今年のしめくくりのエントリーは、久しぶりの頭の体操。今回は、mixiの「幾何学おもちゃ」コミュニティーから仕入れた図形問題。先週の「ドラゴン桜」で紹介された問題だそうだ。 問題はいたってシンプル。平面上に大きさの異なる二つの円と直線が左の図ような関係に配置されているときに、二つの円と直線のいずれにも接する円はいくつかけるか、という問題である。 「ソフトウェア・エンジニアにとってもっとも大切なことは知識ではなく考える力」と言いつづけている私としては、この手の「中学生にも解ける問題でありながら、しっかりと問題を把握した上で論理的に考えなければ正しい答えにはたどりつけない問題」は大歓迎。「ビルゲイツの面接問題シリーズ」に取り上げる価値のある良問だ。 ソフトウェアのバグの原因は色々とあるが、その一つが、設計者が想定していなかった状況でプログラムが実行されてしまうこと。しかし、後になって考えてみれば
Life is beautiful: Googleの強さはStructured Chaosにあり
今週号のFortuneの特集記事（原文へのリンク）は、"Chaos by Design"というGoogleのマネージメントスタイルに関する記事。GoogleのBusiness Operationの上級副社長は、Shona Brownという元マッキンゼーの女性。1998年にCompeting on the Edge: Strategy as Structured Chaosという本を書き、イノベーションを起こすには、会社を「カオス状態」と「きちんと構造化された状態」の間の "structured chaos"(構造化されたカオス)と呼ぶ状態に置くのが一番良いと説いたのだが、Googleが今ある状態はまさにそれ、というのがこの記事の論点だ。 今考えてみると、Microsoftも、９０年代の前半から中盤の、Windows95、IE3.0、IE4.0を出した時期は、まさに"Structured C
Livedoor の「テレビ番組RSSフィード」で遊んでみた
「新しいテレビの楽しみ方」にやたらと興味がある私としては、Livedoorが番組表のRSS配信サービスを始めて以来何か作りたくてしかたがなかったのだが、やっとプロトタイプを作る時間を見つけることができた。まずはその作品の発表から。 「テレビ番組ガイド」（Javaのランタイムが必要） 工夫した点は以下の４つ １．上下左右キーだけで操作が可能 ２．マニュアルを見なくとも使えるぐらい使い方が自明 ３．非同期通信中でも操作が続行できる ４．携帯電話のように少ないメモリでもサクサク動く もちろんUIEngineを使っているので、携帯電話だけでなくさまざまなデバイスで動かすことが可能だ。 ちなみに、サーバー側はPHP。Livedoorのサーバーから取得したRSSをXMLParserでパースし、PHP版のミニコンパイラでバイナリのレコードセットに変更してデバイスに返す、という仕組みだ。 XMLParse
今日はIE3.0の１０才の誕生日
今朝になって、昔の仲間からのメールで、今日がInternet Explorer3.0の誕生日であることを知った。１０年が過ぎ、すでにほとんどのメンバーがMicrosoftを辞めてしまっているにも関わらず、メールアドレスをかき集めて、「誕生日おめでとう」のメールを送ってくれた人がいるのだ。感謝、感謝である。 Microsoftがインターネット・ブラウザーのシェアをNetscapeから奪ったことが業界全体にとって良かったのかどうかは「神のみぞ知る」が、ほとんどシェア０％の状態からIE3.0によりシェア３０％にまで引き上げ、IE4.0でほぼブラウザーのシェアを独占する状態にまで持っていくという大きな仕事に関われたことは本当にラッキーだったと思う。こういうのを「エンジニア冥利につきる」と言うのだろう。 UIEvolutionを創設してから色々なプロジェクトに関わったが、まだまだWindows95や
「色に情報を運ばせる」テクニック
昨日のエントリーで、プレゼンの資料において、「色に情報を運ばせる」ことについて簡単に触れたが、少し説明が不十分だったと思われるので、具体的な例をあげてもう少し分かりやすく説明しよう。 まずは下の図を見て欲しい。 ブログに関わる人たちをグループ化した図だが、グループが三階層に分かれることと、その数が上位層になるほど数が少なくなることを表現する、という目的はきちんと果たしている。 問題は色使いである。せっかくカラー画面を使ってプレゼンをするのだからと、色を着けたのだろうが、色分けそのものは何の役も果たしていない。「役目はないが、無駄ではなかろう」というのが通常の考え方だが、Tufteはそれを「情報量の無駄使い」と呼ぶ。彼ならば、こんな「色使い」を薦めるだろう。 上位層に行けば行くほどブログとのかかわりが「濃い」ことを色の濃淡で表している。つまり色情報がちゃんと役割を果たしているのだ。それに加え
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
