投稿者: TechCrunch Japan

Android版Twitterアプリケーション、「アカウント」タブを開けないバグをフィックス

先週リリースされたTwitterのAndroid版アプリケーションにバグがあったことにはお気づきになっていただろうか。主な問題点は「アカウント」（Me）タブ部分にあり、開こうとしてもいつまでも読込中になってしまうというものだった。

「アカウント」タブを開けないことで、DMを読んだりアカウントの切り替えができなくなってしまっている等、不満の声はTwitter上にも多く見られた。自分自身を検索して、表示されたアバターをクリックすればプロフィールを表示することができたが、そんなハッキング風の手順を誰もが知っていたわけではない。多くの人は接続状態が悪いのだと判断して、延々と、いつまでも、読み込みが完了するのを待っていたのだった。

今日になって、ようやくこのバグに対応するアップデートがリリースされた。日本語ページには「その他いくつかの不具合の修正」とあるだけだが、英語ページでは次のように記されている。

v4.0.1
- Fixes “Me” tab loading issues
- Improved UI on Honeycomb devices

「アカウント」タブが読めないというバグに遭遇していた何人かの人に確認したところ、今回のアップデートで確かに問題は解決しているとのことだ。確かに「アカウント」タブをクリックすると、すぐに画面が切り替わる。ちなみに今回の問題はすべてのAndroid利用者に影響していたというわけではないようだ。但し、影響のあった人はTwitter上で不満の声を表明していた。

たとえばこんな具合だ。

Twitterは、ネイティブアプリケーションなども含めて、Twitterエクスペリエンスの統一化を志している。バグで問題になった前回のアップデートは新しいTwitter Cardsをモバイル環境で提供するためのものだった。

ただ、Android版ではスワイプ動作によってタブの切替ができるようにしたのだが、その際にバグが紛れ込んでしまったようだ。

対応版のリリースで、ようやく当初の狙い通りの動作が行えるようになったわけだ。スワイプすることで、4つのタブをいずれも切り替えて利用できるようになっている。

[Photo credit: Flickr]

［原文へ］

（翻訳：Maeda, H）


BlinkとServoとRust: ブラウザの次の進化の方向性が見えてきた

先週は、ぼくのようにブラウザを追っているブロガーにとっておもしろい週だった。週の終わりには、Internet Explorer 11がWebGLとSPDYをサポートするらしい、という話も聞いた。その前の火曜日にはMozillaがメールで、MozillaのCTO Brendan Eichへの電話インタビューの可能性を打診してきた。その話題は次世代のブラウザエンジンServoと、それが書かれているプログラミング言語Rustだ。しかしMozilla Researchが単独でこれらを手がけているのではなく、この、マルチコアプロセッサと異種混成的なアーキテクチャ向けに最適化されている新型エンジンをAndroidとARMに実装する作業には、Samsungが協力しているのだった。MozillaはこれまでServoについてあまり何も発表しなかったから、今こうやって大きく発表することは少々意外だ。

おもしろいことに、GoogleのChromeのチームが話をしたいと言ってきたのも、先週の火曜日だ。おかしなことに、そのときの広報の連中は、いつもと違って、詳しい話を何もしない（通常は、何の話かぐらいは事前に教えてくれる）。Googleのエンジニアリング担当VP Linus UpsonとOpen Web PlatformのプロダクトマネージャAlex Komoroskeは、WebKitをフォークしてWebKitベースの独自のレンダリングエンジンBlinkをローンチする、と言った。ぼくは自分が話を聞き間違っていないか気になって、何度も彼らに念を押した。WebKit開発の外部の人間ににとっては、GoogleがWebKitの本流を去るという話を、にわかには信じられない。一般的にWebKitは、ChromeとSafariのおかげでデスクトップとモバイルで大成功した、と見られている。それを独自フォークする理由が、思い当たらない。

でもBlinkは正しい

だからGoogleのWebKitフォークは先週のいろんな発表やリークの中で、いちばん話題になった。Googleはフォークの理由を純粋に技術的なものと言うが、WebKitは今でもAppleとGoogleが仲良くやっている数少ないものの一つだから、政治的動機も疑われる。しかもWebKitへのコード貢献量は、このところGoogleが最大なのに。

今後の成り行きを予言するのは早すぎるが、ぼく自身はかなり楽観的だ。たしかに、Webデベロッパが自分のコードを試験すべきレンダリングエンジンが一つ増えてしまう。でもChromeのチームによれば、それは彼らにとって“苦渋の決断”だった。Googleはレンダリングのスピードを上げたいが、WebKitは今いろんなブラウザで使われている。だから、WebKit本流における抜本的な改作は難しい。

Chromeのチームは、“ブラウザが複数あることと同じく、レンダリングエンジンも複数あった方が、今後の健全なイノベーションを刺激し、オープンなWeb全体のエコシステムの健康にとって良い”、と考えている。たしかに、そのとおりだろう。2008年にChromeが突然現れてから、ほかのブラウザのイノベーションは加速した。当時の競争の中心は、高速なJavaScriptエンジンの開発だった（そしてWebKitを使っているブラウザも、JavaScriptエンジンはそれぞれ違っていた）。BlinkとServoという新しい馬が走り出した今は、レンダリングエンジンも重要な競争の要素になり、そしてその競争は、より速くてより安定的なブラウザを求めるユーザとデベロッパに利益をもたらす。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）


2013年Q1、アプリストア総売上22億ドル、ダウンロード134億回、Google、Appleの2社寡占が続く

AppleのApp StoreとAndroid用Google Playは、依然として世界のモバイルアプリをリードしており、BlackBerryとMicrosoftのWindows Phoneは「水をあけられた挑戦者」から抜けられない。今日（米国時間4/8）のCanalysによると、2013年Q1にトップ4アプリストア合計で、134億ダウンロード、有償アプリ、アプリ内購入、および購読で売上22億ドルを記録した。しかし、Googleは世界最大のスマートフォンプラットフォームとして以前からAppleをリードしているにもかかわらず、こと収益化となるとAppleが未だに文句なしのリーダーだ。全ダウンロードの51%（68億回）がGoogle Playだが、AppleのApp Storeは全売上の74%（16億ドル）を占めている。

ダウンロード数に関して、AppleはGoogleにさほど大きく離されてはおらず約40%。BlackBerryとMicrosoftは依然として1桁パーセントに留まっている。Canalysの上級アナリスト、Tim ShepherdがTechCrunchに伝えたところによると、GoogleとAppleの差は、Androidの世界スマートフォン市場での支配状態が続く限り、広がっていくだろうという。

しかし売上でGoogleが追いつくにはまだまだ時間がかかりそうだ。Appleの74%に比べて、Googleは「20%足らず」だと彼は言う。それ以外は1桁だ。

ダウンロード数では前四半期から11%伸びており、売上では約9%増だ。市場別で見ると北米は売上が8%増、ダウンロード6%増、ヨーロッパ西部ではそれぞれ8%、10%の増加だった。

このAppleとGoogleのプラットフォームへの集中は、他社にとって端末でSamsung/AndroidとAppleに立ち向かうのが大変なだけでなく、コンテンツに関しても同じことが言えることを意味している。

これは挑戦者たちにとってあまり良いニュースではない。彼らは自分たちのハードウェアの魅力を高めるために、それぞれのアプリストアに大きく力を注いでいる。例えば、デベロッパーに協力して重要なアプリを比較的小さい市場に投入してもらう、あるいは有名アプリを新しいプラットフォームにもたらすキャンペーンなどだ。（有名なところでは、InstagramをWindows Phoneに載せるようNokiaが取り組んだ）。

それでも、アプリ数の差異はデベロッパーがどのプラットフォームに力を注ぐかの指標の一つだ。AppleとGoogleは50万アプリを大きく越えているが、BlackBerryは10万本前後だ。

このアプリ数の多さが示すもう一つの重要なポイントは、より一般的なウェブ利用と釣り合いを保っていることだ。モバイルウェブがオープンでチャンスが大きいかどうかに関わらず、モバイル端末でアプリが主要なアクセス手段である限り、それがデベロッパーの判断基準になる。タッチスクリーンの世界では最初の入口はアイコンのようであり、ハードウェアをフル活用した体験は、今後も消費者にとって必須だろう。

困難な状況とあまり期待のできない数字をよそに、Canalysは今でもBlackBerryとMicrosoftにはそれぞれ状況を改善するチャンスがあると見ている。

「AppleのApp StoreとGoogle Playは、未だに世界アプリストアの重鎮だ。一方BlackBerry WorldとWindows Phone Storeは、今は大きく離されているものの、やは無視できない存在である」とShepherdは語った。

Canalysは、これらの後発アプリストアが、南アフリカ、ブラジル、インドネシアのように未だ成長の余地のある未成熟市場にどう取り組むかによって、チャンスはあると見ている。

[原文へ]

（翻訳：Nob Takahashi）


文字のパスワードはもう古い。UCバークレー教授が「パス思考」を開発中

「パスワードをタイプする代わりに、将来はパスワードを思い浮かべるだけでよくなる」と、UCバークレー情報スクールのプレスリリースは説明する。これは数字や文字のパスワードの代わりに脳波を利用して個人認証を行う研究だ。100ドルの消費者向け脳波検知ヘッドセット、Neurosky MindSetを使って、John Chuang教授は、集中して息をするたけで個人を特定できることを発見した。

脳波測定装置、即ち脳電計（EEG）は、頭皮上の電気的活動を測定し、その波長から特定の気分、精神状態、および行動を推測する。過去数十年にわたり脳電計を使用した多動症候群、心的外傷後ストレス障害など様々な精神衛生問題の治療が研究されてきた。

技術の進歩によって脳電計の大きさも価格も小さくなり、Neuroskyのような家内工業製品によって、思考制御コンピューターの普及が可能となった。上の画像は本誌のAnthony HaがNeurosky強化版ネコミミを着用しているところで、ユーザーが神経を集中すると回転する。

「パス思考」（passthought）研究の次の段階では、親しみやすい思考対象を見つけることに集中する。これまでのテストでChuang教授は、被験者に好きなスポーツの動作を演じているところを想像するよう依頼したが、「実際に動かさずに自分の筋肉が動くところを想像するのは不自然である」ことがわかったという。

しかし、解読不能パスワードの登場をセキュリティー強更硬論者たちが喜ぶ前に、研究者たちは人の思考を「ハック」することに成功している。バークレーの別のチームは、見覚えのある情報について考えさせることによって、ATMの暗証番号などのデータの抽出が可能であることを発見した。

つまり、もし今後〈パス思考〉が主流になることがあれば、署名を思い浮かべるのはやめた方がいいかもしれない。赤ん坊にキャンディーを渡すことだけ考えることだ。

[原文へ]

（翻訳：Nob Takahashi）


全世界の登録ドメインネームが２億５千万を突破: 約半分が.comと.net

Verisign’sが発行しているDomain Name Industry Briefの最新号によると、インターネットの登録ドメインネームの数は2012年の最終四半期に2億5000万を超えた。2012年の第四四半期には600万あまりのドメインネームが登録され、全世界のドメインネームは合計で2億5200万になった。

もちろんもっとも多いのは.comドメインだ。昨年12月現在で.comドメインネームは1億620件、.netは1490万だ。この二つのドメインは新規登録数でももっとも多く、2012年で計800万が登録された。前年の790万より、やや増えている。

.comと.netのWebサイトの約21%が1ページだけのサイトと、そして15%はサイトが存在しない。

この二つのTLD以外では、国別コードが前年同期比で5%伸び、合計で1億1020万となった。とりわけ、中国の成長が大きい。このVerisignのデータによると、.cnドメインネームは7番目に多いTLDである。

上位のTLDは: .COM, .DE, .NET .TK

上位のTLDは、次のようになっている:

登録数の多いTLDを順に挙げると、次のようになる:

  1. .com
  2. .de（ドイツ）
  3. .net
  4. .tk（ トケラウ）
  5. .uk（イギリス）
  6. .org
  7. .cn（中国）
  8. .info
  9. .nl（オランダ）
  10. .ru（ロシア）

トケラウ(Tokelau)諸島を表す.tkが多いのは、無料登録のFreedom Registryで使われているためだ。このドメインネームはフィッシングサイトが悪用しているという噂もあるが、これだけ多いのはやはり無料登録の魅力だろう。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）


Microsoft、あと365日でサポート終了とXPユーザーにクギを刺す

もしまだWindows XPを使っているなら、あるいは使っている人を知っているなら、Microsoftは、サポート終了まであと365日しかないことを思い出してほしいと言っている。XPは2001年10月25日にニューヨークで登場した。Windows XP SP3およびOffice 2003共、2014年4月8日にはサポート対象外となり、それ以降XPユーザーは、Microsoftからセキュリティー・アップデート、緊急修正、その他サポート（有償無償を問わず）を受けられなくなる。全世界のデスクトップおよびノートパソコンの40%弱が今でもXPを使っている、とNet ApplicationsのNetMarketShareが報じている。

すでにMicrosoftは、Windows XPの主たるサポートを2009年4月に打ち切っているが、企業ユーザーの拡張サポートおよび全ユーザーに対するセキュリティーアップデートは続けている。

2014年4月以降、XPの利用は「移行しないことを選択した利用者の自己責任」であるとMicrosoftは書いており、XPを使い続けれる時間が長くなるほど移行コストは高くなる可能性が強い。

今日の発表でMicrosoftは、XPを使い続ける落伍者たちに対して、「検討提案から移行完了まで」に平均的企業で18～32ヵ月を要すると念を押した。現時点でWindows 7または8への移行を提案することは簡単（Windows 8の方が難しいとしても）に思えるかもしれないが、現実には相当数の企業が新OSへの移行を決断していない。もちろん、XPからWindows 7への直接アップグレードパスがないことも移行を難しくしており、技術サポート要員のいない中小企業ではなおさらだ。

もちろんMicrosoftにとって、Windows XPの終了は潜在顧客にWindows 8の「利点」を再考させるチャンスでもある。同社はWindows 8について「近代的企業のための近代的OSであり、Windows 7のスピード、信頼性、およびセキュリティーといった中核機能に基づき、新しい世代のハードウェアオプションのためにデザインされた最新プラットフォームを作り上げた」と言っている。

しかしMicrosoftは、企業によって「全社一斉にWindows 8に移行するのが最善である場合と、まずWindows 7に移行する方がよい場合とがある」ことも認めている。しかし多くの場合、モバイルユーザーにはWindows 8タブレットといった具合に、Windows 8とWindows 7を並行して展開していくシナリオが主流になるだろう。

Windows 8への移行を促進するためにMicrosoftは、2013年6月30日までWindows 8 ProおよびOffice Standard 2013の15%割引キャンペーンを実施している。

[原文へ]

（翻訳：Nob Takahashi）


ソーシャル・ログイン市場は依然Facebookが46%を占めてトップ―Googleも2四半期連続で差を詰める

今年に入ってすぐ、GoogleがGoogle+によるサービスを開始したので、ソーシャル・ログイン市場は再び激戦区となった。ログイン・プロバイダーのJanrainが発表したところによると、Facebookは依然としてソーシャル・ログイン市場のシェアでトップを占めているが、Googleに追い上げられている兆しがあるという。

JanrainやGigyaなどは、ユーザーがウェブサイトにサイン・インする手続きを簡単にし、同時にウェブサイトにはさらに豊富なユーザー情報を提供するサービスだ。こうしたサービスはユーザーの身元確認にさまざまな方法を用意している。Facebook、Google、Yahoo、LinkedIn、Twitterなどがポピュラーなオプションだ。しかしニッチなウェブサイト向けにSoundCloudやTumblrなどもそれなりのユーザーを得ている。Janrain Engageは25のネットワークをサポートしている。

現在JanrainのソーシャルログインではFacebookが46%を占めてトップ、Googleが34%でこれに続いている。ただしFacebookについては2012年第4四半期と比較して3%の減少で、同時期にGoogleのシェアは逆にちょうど3%増加している。これで2期続いてFacebookとGoogleの差が縮まった。Janrainは「Googleのサービスが信頼性、親近性を増している表れだろう」という。Googleは自らの既存の各サービスへのログインにGoogle+を使わせることでこのソーシャル・ネットワークへのトラフィックの増大を図っている。JanrainはGoogle+ログインを最近になってサポートしたので今回発表された数字には含まれていない。次期のレポートの結果が楽しみだ。

Janrainのレポートによれば、ソーシャル・ログインに用いられるネットワークには地域によって大きな差があるという。たとえばオランダでは地元のソーシャル・ネットワークのHyvesが好まれ、ブラジルとインドでは依然GoogleのOrkutが人気だという。

[原文へ]

（翻訳：滑川海彦　Facebook Google+）


Facebook HomeのChat Headがもたらす真のマルチタスキング。今後の「標準」はここにあり!

モバイル環境においては、シングルタスク式のやり方が一般的だった。しかしFacebook Homeの登場で、Google、Yelp、地図などのアプリケーションを使いながら、オーバーレイ式のドロップダウンウィンドウでチャットができるようになる。これはデスクトップの効率性を小さなデバイスにも持ち込むことになるものだ。Homeで実現されたカバーフィードやレスポンシブデザインの完成度の高さは確かにすばらしい。しかし言ってみればそれは「当たり前」のことでもある。ところがチャットをマルチタスキング化するというのはすなわち、コンピューティングとコミュニケーションを融合するという意味で、携帯デバイスの新次元を切り開くものであると言えるだろう。

ちなみにイノベーションというのは、誰も思いつかなかったアイデアを生み出さなければならないというものでもない。問題解決のための、新たな方法を提供するものをイノベーションと称するわけだ。これまで、モバイル環境でメッセージのやり取りをする際には、コンテクストの切り替え作業が必要だった。すなわち、誰かとメッセージをやり取りするか、「あるいは」アプリケーションを使うかであったわけだ。この両者を「同時に」行うことはできなかった。AndroidもiOSも「マルチタスク」をうたってはいたが、いずれも「タスクスイッチング」であり、「同時に」作業できるわけではなかったのだ。確かに通知機能があって、他の作業をしていても送られてきたメッセージに気づくことはできた。しかし返信を行うためには作業を中断する必要があった。作業を切り替えるにあたっては、「意識の中断」も生じることになっていた。

こうしたコンテクストの切り替え作業は不自然であり、不便なものだ。私たちはしばしば、今まさにコンピュータ画面で行なっていることについてコミュニケーションを行う。たとえば画面で示される疑問に答えようとしたり、同じ資料を見ながら共通認識を持つために会話をしたり、あるいは特定の場所に道案内をしたり、何か面白いものを見つけて、それについて意見を言い合うというような形でコミュニケーションを行なっているのだ。会話している友人に細々とした物事を正確に伝えたり、複雑に絡み合った事象を説明するには、SMSないしFacebook Messenger画面と、他のアプリケーション画面を行ったり来たりしなければならなくなる。これは非常にストレスを感じることだ。スピーカーフォンモードにして音声通話をするのがベストかもしれないが、場合によってそうした方法が取れないこともある。

デジタルワールドをいろいろと見て回りながら会話をするというやり方は、モバイル時代以前には当然のことだった。デジタル以前についても、何かをしながら会話するというのは当たり前過ぎる行為だった。IRCや（TechCrunchの親会社である）AOLのインスタントメッセンジャーでも、画面を見ながら同時にチャットを行うことができていた。それがモバイル時代になってからは不可能となり、これまでは単純に画面サイズのせいで行えないのだと納得して（させられて）きた。Galaxy Note IIのような大画面ファブレットや、iPadのようなタブレットなら可能かもしれないが、スマートフォンのような画面では無理だと考えてきたわけだ。

しかしFacebookのデザイナーに、「そうではないのだ」と考える人がいたわけだ。デザインチームは、人びとの「実際の生活」の様子に注意をはらってデザインプロセスを進めている。たとえば既読通知機能なども、そうした流れから導入されたものだ。面と向かって話をしているときには、話が聞こえればそれを態度で示すものだ。Facebookメッセージにも同様の仕組みが必要であると考えたわけだ。発表当時、FacebookのProduct部門ディレクターのPeter Dengに話を聞いた。相手に読まれたかどうかを示す仕組みは絶対に必要だと考えたのだそうだ。

技術というのは、私たちの手伝いをするために存在するのです。強引にやり方を変えさせたり、複雑な手順に従わせるというようなものであってはならないと思います。たとえば私たちは、人間同士の「会話」を模するための仕組みを作りました。何千年もの間、慣れ親しんできた実際の「会話」に着目するところから始めたのです。面と向かって行う会話と同じような効果を出すことを心がけました。今回導入した既読通知機能は、今後に向けての第一歩なのです。

Facebook Homeで実現するマルチタスクチャットも、そうした流れの一環であるということができる。誰かがメッセージを送ってくれば、現在使っているアプリケーションの上に送信相手の顔アイコンがポップアップ表示される。そして送られてきたメッセージの最初の方の文字がアイコン横に表示されるようにもなっている。従来型のアプリケーションであれば、ここで送信相手の顔をタップすると、使用中のアプリケーションを閉じてFacebookメッセージ画面に遷移することとなるだろう。しかしFacebook Homeでは利用中のアプリケーションが見えるままの状態で、オーバーレイ式のメッセージウィンドウが表示されるようになるのだ。チャット画面上の顔アイコンを再度タップすると、メッセージウィンドウが小さくなって元の画面に戻ることになる。これにより、メッセージのやり取りをする際に何をやっていたか見失ってしまうようなことはなくなる。発表イベントでデモに触れてみることができた。モバイル機器を操作しながら、シームレスにメッセージ送受信が行えるのは非常に快適なエクスペリエンスだった。この仕組みならばチャットも「邪魔するもの」ではなく、「相補的なもの」として利用することができそうだ。

ここで実現しているチャットシステムこそ、他のモバイルエクスペリエンスと「同時に」楽しむことができるものだ。ただ、オーバーレイ画面を表示したままで、下に表示されている別アプリケーションをスクロールしてみたりすることができないのが残念ではある。HTC Firstの画面や、標準的なサイズのAndroidデバイスには、そうした操作を有効に行うための広さが足りないということなのだろう。しかしそれでも操作できれば便利だろうと思うのだ。最近は画面サイズが拡大する傾向にあるようなので、サイズ的な制約は今後消えていくことにもなるだろう。

Facebook Homeのハンズオンビデオを見た人や、説明を聞いた人は皆、このチャット機能に導入されたマルチタスクに拘りを見せる。「Chat Heads」（頭部のアイコンが表示されるからそう呼ぶらしい）という妙な名前ながら、機能的に大いに注目を集めているわけだ。ワシントンDCで27歳の非テック系の女性にも紹介ビデオを見てもらった。ここでも人気を集めたのはやはりChat Headだった。「欲しい」という声や「ぜひHTC Firstを買いたい」とも言っていた。

きっと、ここから新しい時代が切り拓かれていくことになるに違いない。他のアプリケーションでも同様の仕組みを実装し、あるいはさらに進化させていくに違いない。たとえばAppleのiMessageの新版が、が同様のマルチタスク機能を備えていなければ非常にがっかりすることになるだろうと思う。もちろんこれは近々の登場が噂されているGoogleの統合メッセージングシステムについても同じ事が言える。真の「マルチタスク」はもちろん、さらなる進化を見せて貰いたいと思っているのだがどうだろうか。

少なくともしばらくのうちは、このChat Headsの魅力によってFacebook Homeのダウンロード数は伸びるだろうし、HTC Firstを購入するという人もでてくることだろう。メッセージングの重要性については、改めて各開発者が再認識している段階でもある。メッセージのやり取りから、ここからさまざまなコミュニケーションが始まっているのだ。非同期のメッセージングシステムのおかげで、安心してネットから離れる時間を持つことができるようにもなっているのだ。そしてメッセージングアプリケーションはさまざまな進歩を遂げてきた。そのような中でスマートフォンが広まり、利用者としてはさらなる進歩を期待するようになってきているのだ。

Facebook Homeの今後について、少なくともしばらくのうちは注意しておくべきだろう。

［原文へ］

（翻訳：Maeda, H）


30台のRaspberry Piがカメルーンの田舎の中学校でコンピュータ教育に使われる

マイクロコンピュータRaspberry Piは発売後の1年で、合計100万台がメーカーたちや、電子工作マニア、親たち、子どもたちの手に渡った。子どもたちをコンピュータ科学に入門させるための教育玩具として作ったものが、こんなに広い層に売れるとは驚きだ。Pi Foundationはとくに、イギリスの子どもたちがこれでプログラミングを初体験することを意図していた。でもPiの力は実際には、最初に考えた使命よりも大きい: カメルーンでは、Piが中等学校のコンピュータ教育で使われているのだ。

Pi Foundationのブログのゲスト記事で、ベルギーのボランティアが書いている。彼らは資金を募り、30台のPiをスーツケースに詰め込んでカメルーンへ行き、コンピュータ教室を作った。ディスプレイとキーボードとマウスは、ベルギー国内で買った。このPiを使ったコンピュータ教室は、まだ電気が来ていない田舎なので、自家発電を使っている。

その学校、Saint Marcellin Comprehensive Collegeは、カメルーンの北西部のNkambeに近いBinshua村にある。今現在は、Piを使ってオフィスソフトの使い方を教えているが、ねらいは子どもたちにプログラミングを教えることにある:

OSは12月時点のRaspbian〔Raspberry Pi用のDebian Linux〕で、その上にLibreOfficeとCUPSをインストールしている。今は子どもたちにOfficeの使い方の基本を教えているだけだが、先生にはすでにScratchによるプログラミングを教えたし、良い本もあげた。だから次からは、学校のカリキュラムにScratch入門が入って欲しいと思う。

このコンピュータ教室にはまだインターネット接続がないが、この状況もベルギー人たちが変えようとしている:

コンピュータはすべてネットワークに接続している。ネットワークの中心はルータで、それはWANのモデムに接続されるのを待っている。近い将来にはインターネットへの接続を提供したいが、そうなるとこの田舎に小さな革命がもたらされるだろう。インターネット接続のない今でも、この未開発地域に相当高度なコンピュータ教室を作った、とわれわれは自負している。この地方の子どもたちに、より良き未来を切り開く力と機会を与えた。それこそが、われわれの動機だったのだ。

この、小さくて安くて低能力なマイクロコンピュータは、開発途上国の人たちに初めてのコンピューティング体験を与えることができる。Piのハードウェアは多くの場合、携帯電話よりも安い。スマートフォンよりも、もちろん安い。スマートフォンはこれまで、“次の数十億人”に最初のコンピューティング体験を与える、と持て囃されてきた。またPiは、そのほかのLinuxベースのローコストコンピューティングプロジェクト（たとえばOLPCのXO laptop）よりも相当安い。もちろん、周辺機器の価格も考慮に入れる必要はあるが。

下のビデオでは、教師が生徒たちにPiを紹介している。彼女はMicrosoftのWindows OSの名も挙げているが、その言及は同社の人たちを喜ばせないだろう: “この小さなボックスはWindowsオペレーティングシステムでは動きません。別のタイプのオペレーティングシステムで動きます。それはLinuxといって、とっても人気があり、しかも無料です”。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）


Google Compute Engineが月額400ドル24/7電話サポート付きの利用形態をローンチ

昨年のGoogleのデベロッパカンファレンスI/Oで、Compute Engineがローンチされた。それはクラウドコンピューティングのプラットホームで、デベロッパはGoogleの大規模なインフラストラクチャの上でホストされているLinuxの仮想マシン上で、自分のアプリケーションを稼働できる。しかしこれまでは制約のあるローンチで、デベロッパは招待されるかまたはGoogleの営業からアクセス許可をもらわないと、利用できなかった。

しかし今日からは、月額400ドル払ってGold Supportの会員になると24/7の電話サポートが利用でき、招待も営業へのコンタクトも不要でCompute Engineにアクセスできる。

新しい料金体系

この有料サポート付きパッケージは、Compute Engineを利用する権限を与えるだけだ。アプリケーションがGoogleのインフラを利用するときには、それなりの料金が発生する。ただし今日の発表とともにGoogleは、その料金を4%引き下げた（11月にはストレージの料金を20%下げた）。新しい料金体系では、最小の仮想マシンが1時間0.132ドル（13.2セント）で、現在の最高の料金は8コアのマシン、52GBのメモリ、1770GBのハードドライブ2基という構成で1時間1.211ドル（1ドル21.1セント）だ（ヨーロッパではこれよりやや高くなる）。

新しい機能

Compute Engineの機能とインスタンスタイプも増えた。たとえば、各インスタンスタイプにはディスクレスのバージョンがある。管理コンソールも改良され、これからはルートファイルシステムとしてマウントされた永続性のディスクからブートできる。ヨーロッパのゾーンが二つ増え、それにより“ヨーロッパの顧客に低レイテンシと高パフォーマンスを提供できる”という。新機能の詳細は、このページにある。

Googleのインフラは大きくて潤沢だから、そのCompute EngineはクラウドコンピューティングにおけるAmazonの強敵になるかもしれないが、しかし現状ではAmazonの幅広いサービス構成にGoogleは追いついていない。数週間後に迫っている今年のI/OでもCompute Engineについて何か発表があるかもしれないが、月額400ドルのサポートパッケージに続いて今度は無料の最小構成が出てくるのなら、まあ当然と思うだろうね。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）


Web上のペイメント（支払決済）には共通APIがあるべきだ, と頑張るMozillaがFirefox OSに実験的実装

Mozillaはペイメントベンダ(payment vendors, Paypalなど)やWebの標準規格団体W3Cに働きかけて、支払決済の 共通APIを作ろうとしている。それはデスクトップとモバイルの両方で使える、使いやすくてセキュアなAPIだ。Mozillaはすでに、実験的なJavaScript APIをスマートフォン用のFirefox OSに実装している。それは最終的に、Webアプリケーションが支払を受け取るための共通APIになるものだ。支払を取り扱うための共通のAPIを複数のペイメントベンダが実装すれば、デベロッパやパブリッシャーにとって新しいビジネスモデルが開かれる、とMozillaは主張する。

この新しいAPI、navigator.mozPay()は、MozillaによるとGoogleのWallet for Digital GoodsのAPIを参考にしており、まずFirefox OSに実装されてから、その後Firefox for AndroidやデスクトップのFirefoxにも加わる。今のきわめて実験的で不完全なAPIでも“Firefox OSフォーンの上でライブの支払を十分に処理でき、急速に実用レベルでの採用が進む”、とMozillaは期待している。

しかし疑問なのは、ユーザやデベロッパにとってはPayPalやStripeがあれば十分で、オンラインの支払決済はそれほど重大な問題ではないのに、なぜMozillaがことさらそれを取りあげるのか、だ。それは、Mozillaの主張では、あらゆる支払サービスにおいてAPIが統一されていれば、個々のWebアプリケーションを使っているユーザに選択の自由が生ずる。また現状では、ユーザも企業もクレジットカード情報という重要な個人情報を扱わざるを得ず、Webという混雑した環境で事故や事件に遭わないことはつねに、運を天にまかせた結果でしかない。言い換えると、ユーザ自身が自分のセキュリティをコントロールできない。

navigator.mozPay()ではデベロッパが、彼/彼女が選んだペイメントプロバイダをを認可でき、きわめて単純率直な方法で支払を処理できる。それはクレジットカード情報の交換ではなく、（ローカルな）トークンの交換処理になる。

今のバージョンのAPIを実装して試してみたい人は、ここへどうぞ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）


カスタマイズOS搭載のFacebook携帯、HTC Firstはダウンロード版Homeアプリにない機能を提供

今日（米国時間4/5）のFacebookの発表は“Home”と呼ばれるホームスクリーン・アプリに重点が置かれていた。これは標準的なAndroidの多くの機種で作動する〔HTCの数機種とSamsungのGalaxyIII/IVが当面サポートされる〕。

一方、HTCは私の取材に対して、「われわれはFacebookと協力してAndroid OSのカスタマイズに取り組んできた。HTCのFirstスマートフォンにはダウンロード版のHomeにはない機能がいくつもある。たとえばFirstではメールとカレンダーの通知をホームスクリーンに表示できる機能がある」と述べた。HTCの提携担当マネージャー、Michael Goodwinは私にこう説明した。

そう、われわれはOSにいくつか手を加えねばならなかった。システム通知をホームスクリーンに表示するために新たなフックをいくつか開発した。Android OSのカスタマイズのおかげでAndroidの通知トレイに現れるさまざまな通知がすべてFacebook Homeに表示される。

また発表イベントでFacebookのCEO、マーク・ザッカーバーグとプロダクト・ディレクターのAdam MosseriはHTCのFirstスマートフォンはHomeの体験を最良とするために最適化されていると述べた。

「Facebookはカスタマイズ版のAndroidを搭載したHTCスマートフォンも発表する。これにはダウンロード版にはない機能が含まれている」という先週の私のスクープはやはり正しかった。HTC Firstは現在、99.99ドルでAT&Tが予約受付け中だ、。出荷開始は4月10日でユーザーの手元には4月12日まで届くという。

HTCの社長、Jason MackenzieはHTCがFirst向けにAndroid OSの改造をするという努力を払った理由をこう説明している。

ユーザー体験の一貫性を高めたかったからだ。ユーザーにとってもっとも簡単でもっとも使いやすい方法を提供したかった。Chat Headsや通知機能でホームスクリーンでFacebook関連のメッセージを扱えるのに、他のメッセージやメールは別のアプリを起動しなければならないというのでは一貫性に欠ける。HTC Firstはスマートフォンの中心にアプリではなくユーザーの友だちを据えるというFacebookとザッカーバーグのビジョンをもっともよく実現するものとなっている。

Google PlayからダウンロードできるHomeはFacebookのコンテンツのみをホームスクリーンに表示するが、OSをカスタマイズしたHTCFirstはGoogleカレンダー、Microsoft Outlookのメール、利用可能なWi-Fiネットワーク、その他の通知をホームスクリーンに送り込む。またHTCFirstは上にスワイプしてアプリのショートカットが表示でき、右スワイプでGoogleの検索バーが表示される。これらもダウンロード版にはない機能だ。

つまり、やや逆説的だが、HTCのFacebook携帯はダウンロード版にくらべてFacebookコンテンツ以外も広く表示し、いわばより中立的なユーザー体験を提供するものとなっている。

下はHTCのMichael Goodwinのインタビュー

[原文へ]

（翻訳：滑川海彦　Facebook Google+）


Facebook Homeは殆んどの端末でGoogle検索をホーム画面から追い出す

今日（米国時間4/4）Facebook Homeが発表された直後、私はFacebookのAndroid担当技術責任者のTom Allisonと話す機会を得た。そこでは彼がHomeで気に入っている点、ベースとなるOSをどのくらい変更する必要があったか（＝多くはない）、およびHomeの開発でもっとも苦労した点について話を聞いた。

特に興味深かったことの一つがこれだ。発表されたばかりのHTC Firstに内蔵されるバージョンのFacebook HomeにはGoogle検索が組み込まれているが、その他のユーザーがダウンロードするバージョンには入らないという。これがプレインストールされていない端末では、まずChromeに入って専用の検索アプリを立ち上げるか、旧ホーム画面を使う必要がある（後者は驚くほど簡単だ。下のビデオ参照）。

なぜこれが重要なのか。検索（もっと正確に言えば、検索結果に入る広告）はGogleのビジネスモデルにとって極めて大きい部分を占めている。ホーム画面に検索ボタンがあれば、検索は衝動的に行われその結果検索の量が増える。もしFacebookが、望み通りにこれを多くの端末に載せることができれば、Googleが検索によってAndroidから得る収益を多少なりとも減らすことになるかもしれない。

ホーム画面に関していえば、もしFacebook Homeをインストールしてみたいが、元のホーム画面（SamsungのTouchWizであれHTCのSenseであれ、Android標準のホーム画面であれ）やそのウィジェットを使い続けたいという人も心配は無用だ。以前Galaxy Note 2でFacebook Homeが動いているのを見た時、2つのホーム画面が共存しているデモを見た。設定画面をいじったりスイッチを切り換えたり端末をリセットする必要はなく、アプリドロワーに隠れているMore…ボタンをタップするだけでよい。その後端末のホームキーを押すと、再びFacebook Homeに戻る。

（ひどい音声で申し訳ない。混雑した部屋にいた上に私のiPhoneが怖がって耳をふさいでいたようだ）

[原文へ]

（翻訳：Nob Takahashi）


Mozillaもブラウザの並列処理に本腰, Samsungと提携してマルチコアプロセッサ向けエンジンServoを開発

一見すると不似合いなカップルのようだがMozillaが今日（米国時間4/3）、同団体の次世代ブラウザエンジンServoでSamsungとのコラボレーションを開始した、と発表した。Mozilla ResearchがServoに研究プロジェクトとして着手したのは2012年だが、今もまだ商用プロジェクトにはほど遠い。Rustという比較的新しいプログラミング言語で書かれていて、この言語もMozilla Researchが開発している。MozillaとSamsungは、RustとServoをAndroidとARMアーキテクチャに実装することで協働する。

Samsungの広報によると、同社がこのプロジェクトに関心を持った理由は、同社が“レガシー製品を革新するためのさまざまな新しい技術を探究中であるから。このコラボレーションによって未来のWeb体験の新しい局面が切り開かれることを期待している”、とのことだ。

マルチコア時代のブラウザエンジンとは

MozillaのCTO Brendan Eichによると、未来のコンピューティングにおいては並列処理がふつうになる（そう思っているのは彼だけではない）。Mozillaの研究部門はこのことをWebという視点から見て、今多くのユーザのコンピュータや携帯電話やタブレットがマルチコアのプロセッサを使っているにもかかわらず、今日のブラウザはもっともベーシックなマルチコアプロセッサすら有効活用していないことに気づいた。というより、Eichによれば、Webの今日のスタンダード自体が、これまでのブラウザが用いているシーケンシャルな処理から、マルチコア上のより効果的なページレンダリングに移行することを、妨げている。今その例外と言えるのは、GPUを使うWebGLと、JavaScriptにマルチスレッドを導入するHTML5のWeb Workersぐらいだ。

しかしEichが強調するのは、ブラウザの処理の一部とレンダリングのパイプラインをただ並列化するだけでは不十分である、ということ。彼によると、全体的にすみからすみまで、いちばん深い部分で並列化されているWebエンジンだけが、明日の16コア32コア〜〜といったマルチコアプロセッサを完全に有効利用できる。

Samsungはもちろん、モバイル用の強力なマルチコアプロセッサの開発に取り組んでいる。だから、今マルチコア指向にはまっているMozillaとのパートナーシップは、良い相性である。しかし問題は、SamsungとGoogleの長年の深い仲、それにAndroid上のモバイルブラウザとしてのChromeの強力な地位が、今後どうなるのかだ。

RustとServo

そこで、Rustが登場する（Mozillaは今日、コンパイラのバージョン0.6と関連ツールをローンチした）。Rustは、C++、Lisp、Erlangなどいろんな言語の良いとこ取りをしたような言語だが、言語設計の力点は安全性（C++のようにメモリ管理のエラーが頻発しないこと）と並列処理に置かれている。RustはMozillaによると、“多くの用途においてC++をリプレースできる現代的な言語を作る試みであり、とくに、クラッシュやセキュリティの脆弱性に導くタイプのエラーの抑止を目標としている”、という。今年の終わりまでにはコアライブラリが完備し、めでたくRust 1.0をリリースすることをMozillaは目指している。現在の開発チームはMozillaから5〜6人、Samsungから10〜20名、という規模だ。

Geckoの将来

Mozillaにはすでに、Geckoという優秀なエンジンがあり、それが同団体のブラウザとFirefox OSのベースになっている。また現時点では、Geckoを完全にServoでリプレースする計画はない。むしろMozillaはServoを、“新しいハードウェアのための新しいエンジン”と位置づけるだろう、とEichは語る。Firefoxの人気から考えると、Geckoの抜本的改良は互換性を損なう危険性が大きい。しかしたとえばFirefox OSでは、かなり新しい機能をエンジンに導入することに成功している。だからEichが考えているのは、ServoがMozillaに多くのことを教えて、それがGeckoにも使われていく、という将来の道筋だ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）


手軽にオンラインストアを開設できるStores.jpが3週連続で販促サービスを開始

stores.jp

誰でも手軽にオンラインストアを開設できるECサービス、Stores.jpはオンライン上だけでなく、店舗の運営に欠かせないオフラインでも利用できるサービスも強化しはじめている。無料でストアカードやロゴを作成するサービスに続いて、今日は配送用の段ボールを無料提供すると発表している。これはこの3週間の間に行われている。今年1月末にはストアに掲載する商品の写真をプロのカメラマンが無料で撮影をしてくれるサービスも開始している。

Stores.jpを運営するブラケット代表取締役の光本勇介氏は、オンラインサービスを展開しているが、こうしたオフラインのサポートも充実させることでストアの売上も伸びるという。すでに商品の写真をプロが撮影したものに置き換えたストアの商品は1カ月後には売上平均が約2倍になったそうだ。

今回、名刺（ストアカード）、ロゴを無料で作成するサービスを提供するに至った経緯だが、Stores.jpのビジョンである「すべての人へ、オンラインストアを。」に基づいたものだ。というのも、ストアを開設してもトラフィックを集められなければ意味がない。そこですでに実店舗を持っている方は店にカードを置いたり、人と会う時に名刺と一緒にオンラインストアのカードを渡せば集客に繋がる。

また、ストア開設者がロゴを作成するスキルを持っているとも限らない。ロゴ作成を発注すれば数万円は費用としてかかってしまう。初期コストを抑えたい運営者も気軽に作れるようにとStores.jpはロゴ作成をするそうだ。

日本の小売店鋪は120万ほどあるそうだが、このほとんどは数名で経営しているような商店街の店舗だという。この大部分を占める店舗が日本の小売市場を支えており、彼らがオンラインにも進出できるようになって欲しいと光本氏は語る。そのため、予算がなくITリテラシーがそれほど高くない人達でも充実したオンラインストアを運営できるように、今回オフラインサポートの充実に力を入れた。

さて、手軽にオンラインストアを開設できるサービスといえば、最近はStores.jpとBASEがよく比較されているので、ここでも少し見てみよう。

Stores.jpの店舗数は現在約3万、月間50万UU、250万PVにまで成長している。こちらはフリーミアムモデルでプレミアムユーザーは月額980円で商品数が無制限になったり、アクセス解析といった機能が使えるようになる。すでにプレミアムユーザーは一定数おり、サービス開始4カ月で黒字化しており、1日に100万円ほど売り上げる店舗もあるそうだ。

一方、BASEは昨年11月20日リリースされ、今年1月に1万店舗を突破していた。直近の店舗数は公開されていないが、順調に成長していれば2万数千店舗ほどあると予想される。BASEに関してはマネタイズはまだしていないが、これから動きがありそうだ。今年1月にはEast Venturesやpartyfactoryなどから2,300万円の資金を調達している。


LEDでテキストをスクロール表示するスマートブレスレットLinkMe–とにかくデザインは美しい

[筆者: Michael Seo]

LinkMeは、左の写真のようなリストバンドないしブレスレット（腕輪）だが、スマートフォンにBluetoothで接続してSMSやソーシャルメディアのアップデートをテキストでスクロール表示する。その表示装置は、LEDである。

スマートウォッチやスマートブレスレットをちらっと見ることは、あなたのぴっちりしすぎているジーンズのポケットからアラーム音の鳴っているデバイスをあせって取り出すより簡便である。だが今のところ、それらの多くはデザインがださすぎる。たとえばスマートウォッチPebbleは、機能的にはすばらしいがルックスは不格好で退屈だ。あれを腕にはめている自分を、人に見られたくないね。

LinkMeは文句なしに美しい。単純なクロームメッキのリングで、それを腕につける。リングを覆っているLEDディスプレイは、デザイン的に腕輪本体とうまく融合している。ちょうどニューヨークのタイムズスクウェアの電光ニュースのように、青または赤の文字で長いテキストをスクロールする。

表示するものは、テキストなら何でもよい。SMS、ソーシャルメディアのアップデート、フライト情報、個人的リマインダー（備忘録メモ）、アラート、などなど。メッセージを表示しないときはデフォルトで時刻を表示するから、腕時計としても使える。

しかし機能性では、Pebbleの方がLinkMeよりもいろんな点で上だ。Pebbleは表示がeインクだから、グラフィクスも含めていろんな表示ができる。複数行のテキストも一挙に見られる。LinkMeでは、メッセージが最後までスクロールしていくのを、じっと待たなければならない。

しかしLinkMeには、これなら腕にはめてもいいな、と思わせる何かがある。機能性よりも美、ということだろうか。でもAppleがいかにもAppleらしいスマートウォッチを発売したら、あっさりと、「機能も美も」になってしまうだろう。

でも、今のところ、ぼくはLinkMeが気に入っている。

LinkMeは今KickStarterで資金募集中なので、99ドル‘出資’すると一つもらえる。目標額は、5月5日までに10万ドルだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）


GoogleがWebKitをフォークして新レンダリングエンジンBlinkをローンチ, 速さと単純性を追求

Googleがさきほど（米国時間4/3）、WebKitのフォークBlinkを発表した。Googleの説明によると、Blinkは“包括的なオープンソースコミュニティ”および“WebKitをベースとする新たなレンダリングエンジン”であり、将来的には当然、“WebKitとは異なる方向へ進化していく”。Googleによると、Blinkはスピードと単純性がすべてだ。それはもうすぐChromiumからChromeのさまざまなリリースチャネルへ持ち込まれ、ユーザは近い将来、ChromeのBlinkで実装されたバージョンをデスクトップや携帯やタブレットで見ることになる。

WebKit: コラボレーションは最高だったが

Googleの技術担当VP Linus UpsonとOpen Web PlatformのGoogle側プロダクトマネージャAlex Komoroskeの話では、WebKitをフォークする決定は完全に技術者チームからの発意であり、その動機はただ一つ、WebKitの技術的複雑さと、それがもたらす束縛だ。Komoroskeによると、WebKitプロジェクトにおける他社との協働関係そのものは、たいへんすばらしかった、という。

しかし、プロジェクトの立ち上げまでには難関もあった。Upsonによると、このWebKitフォークの動きに関して、“管理部門からは厳しい質問を大量に投げかけられた”が、結局は、技術的な複雑性を軽減して、Googleのレンダリングエンジンをチームが望む方向に進化させていくことが優先された。

Blinkはスピードと単純性がすべて

Komoroskeによると、具体的な問題としては、Chromium（ChromeとChrome OSを支えるオープンソースプロジェクト）の多重処理を核とするアーキテクチャは、WebKitとの相性があまり良くなかった。GoogleがWebKitでGoogle流を貫こうとすると、WebKitのほかのパートナーたちとの統合という課題が発生し、開発過程の全体を牛歩にしてしまった、とKomoroskeは回顧する。

ChromiumとBlinkはオープンソースプロジェクトなので、誰もが自由にコミットできるが、この種のプロジェクトの通例として、そのためにはプロジェクトの正規メンバーである必要がある。

現時点ではWebKitとBlinkは機能的にほとんど同じだが、Googleの予想としては、長期的には両者は非常に違った方向に進化していくだろう。たとえばKomoroskeは、IFRAMEを別のプロセスとして実装したいと考えているが、それを今のWebKitでやるのはきわめて困難だ。

ただし今のところは作業の中心がアーキテクチャのレベルでの改良なので、機能や見た目の上での違いはほとんどない。Googleによると、今行われている改良とはたとえば。“7つのビルドシステムを取り除き、7000あまりのファイル（計450万行あまり）を一度に削除する”、といった低レベルの作業だ。このような大掃除によって、コードベースがより健康的になり、安定性が増し、バグが少なくなる、とGoogleは期待している。

WebKitプロジェクトは、Appleが同社のSafariブラウザのためにKDEのオープンソース製品KHTMLエンジンをフォークするところから始まった。その後KHTMLのチームとAppleのあいだにいろんなやりとりや経緯があり、Appleは2005年にWebKitをオープンソースにすると発表した。そしてGoogleはそれを、同社のChromeブラウザに採用した。興味深いのは、初期のChromiumが実はWebKitのフォークされたバージョンを使っていたこと。そしてその後、そのフォークがあらためて、WebKitプロジェクトの本流に合流したことだ。

というわけで、今現在WebKitを使ってブラウザを作っているベンダは、実はすでにそれぞれが、きわめて異なった実装を使っているのだ（そして彼ら独自のJavaScriptエンジンも使っている）。

WebKitの開発におけるGoogleの今の役割

目下、WebKitのリビュワーの大多数がGoogleから（95名）で、次に多いのがApple（59名）だ。以下、Blackberry、Intel、Nokia、Samsung、Adobe、Netflixなどが続く。WebKitのリポジトリへのコミットも、その大半はGoogleがやっているから、Googleが脱けたら今後のWebKitがどうなるのか、それを見守っていきたい。Googleの広報は今日、Blinkのチームメンバーは今後も“そうしたければ”WebKitに貢献できる、と言ったが、おそらく、そんな余裕のない人がほとんどだろう。

WebKitに切り換えたばかりのOperaはどうなる？

数週間前にOperaは、独自のエンジンの開発をやめてWebKitに切り換える、そのためにブラウザのベースとしてはChromiumを採用する、と発表した。今回のGoogleの発表がOperaにどう影響するのか、それはまだ分からないが、本誌は同社に声明を求めている。

Operaが切り換えを発表したとき、多くのデベロッパたちがWebKitによる文化的独占を心配した（とくにモバイルのWebで）。GoogleがBlinkを手がけたことにより、その心配はなくなり、イノベーションが再び加速すると思われる。Komoroskeも、GoogleのWebKit離れにより他社もWebKitをよりはやく開発するようになり、Googleのこれまでとはまったく異なる実装(Blink)がその動きを一層刺激するだろう、と言っている。

アップデート: Operaが今、次のような声明を寄越した: “Webがデベロッパにとってさらに一層オープンになりアクセスしやすくなることは、喜ばしい。それは動きの激しいプラットホームであり、継続的かつ迅速な更新が必要とされる。Googleのブラウザ担当者たちと話し合った結果、弊社は今後、オープンソースのプロジェクトすなわちBlinkに貢献していくことを志向したい。弊社からのインプットを有効利用できると思われるさまざまなオープンソースのプロジェクトに対して、これまでもそうしてきたように”。

なぜ”Blink”か？

Googleはなぜ、新しいレンダリングエンジンをBlink（まばたき）と呼ぶのか？　Upsonによると、それは当然、スピードと単純性を重視するからだ。しかしブラウザのデベロッパたちには、名前で遊ぶ傾向が以前からある。たとえばChromeは、”chrome”（派手で中身のない外見）をできるかぎり消滅させることと関連している。そして彼によるとBlinkは、90年代にNetscape Navigatorが導入した、古き良き（そして迷惑な）<blink>タグを、人びとに思い出させるためだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）


ディズニー、ルーカスアーツを買収後わずか154日で閉鎖

わがゲーマーの友たちよ、今夜はGold Guyに一献を。業界の聖なる柱が倒れた。

Lucasfilmから40億ドルでLucasArtsを買収してからわずか154日、Disneyはこの伝統的ビデオゲーム開発会社を消滅させた。

今日（米国時間4/3）からDisneyは、LucasArts作品（即ち〈スターウォーズ〉）のライセンス供与は継続するが、社内プロジェクトの開発をすべて中止する。いくつかのプロジェクト（例えばあの驚くべきStar Wars 1313は、他の開発会社に行き先を見つけるかもしれないが、その状況も現在は宙に浮いている。

この動きは予想されていなかったわけではないが（同社の最近のいくつかのゲームは必ずしも成功しておらず、買収以来プロジェクトの閉鎖が噂されていた）、それでも今日のニュースによる落胆が和らげられることはない。私の子供時代、いやあらゆる世代のゲーマーの子供時代の一部は、LucasArtsと共にあった。

今日解雇されたであろう150名の人たちと、これまでLucasArtsの歴史を作ってきた人たちに感謝したい。

ガイブラッシュ・スリープウッドとモンキーアイランドの世界にぼくたちを送り出してくれてありがとう。

マニアックマンションとデイオブザテンタクルは、ビデオゲームに「ユーモア」を持ち込めることを証明したゲームだった。

グリムファンダンゴとフルスロットルにありがとう。みんなが10年以上待ち望んでいる続編を見ることはもうないだろうが、これらのゲームはプロジェクトリーダーのTim Schaferにゲームの世界を紹介し、彼が自分の会社、Double Fine Productionを作るきっかけになった（この会社は、Psychonauts、Brütal Legend、およびKickstarters史上最大級のヒットを生んだ）。

The Digをありがとう。このゲームは、小学校3年生でひどいインフルエンザにかかった私を慰め、当時萎えかけていた私のコンピューターへの興味を再び燃え上がらせてくれた。

Sam and Maxをデジタルワールドに連れてきてくれてありがとう。彼らはTelltale Games（Double Fineと同じく、LucasArats出身者が立ちあげたチーム）の中に住んでいるが、Sam and Maxに単なるインディーズ・コミック以上のポテンシャルを見出したのはLucasArtsだった。

Star Wars: Battlefront（Pandemic Studiosと共作、この会社も消えた）、The Force Unleashed、X-Wingシリーズ、そしてKnights Of The Old Republicへの関わりをはじめとする数えきれない思い出をありがとう。

LucasArtsにはヒットも外れもあったが、その遺産はどのゲームやブランドやシリーズだけにも留まらない。彼らのゲームは新たなジャンルを生みだし、LucasArtsが90年代を通じて育て上げた多くの才能は、業界全体を動かす力となった。

さらば、LucasArts。そしてあのSCUMMのすべてに感謝している。

[原文へ]

（翻訳：Nob Takahashi）


アメリカのモバイル・アプリ経済は活力旺盛、モバイル・ブラウザはFacebookアプリに押されて苦戦（Flurry調べ）

モバイル・アプリのアナリティクスを提供するFlurryは毎月10億台以上のスマート・モバイル・デバイスの利用状況を調査している。最近Flurryはアメリカの消費者がモバイル・アプリとモバイル・ブラウザをどのように使い分けているかレポートした。それによると、iOSとAndroidのアプリは元気一杯のようだ。消費者のスマートフォン、タブレットの利用時間は１日あたり平均2時間38分だが、その80%の時間はアプリを利用している。モバイル・ブラウザの利用は5分の1（20%、31分）しかない。

アプリのカテゴリーでみると、やはりゲームが大きな割合（32%）を占めている。次に大きいのがFacebookで毎日の利用時間の18%を占めている。さらに他のソーシャルメディアのアプリの6%を加えると、ソーシャル関係の利用時間はほぼ全体の4分の1となる。

しかしFlurryの調査によれば、Facebookアプリの利用時間を長くしているのはソーシャルな活動だけではないという。Flurry CEO、Simon Khalafは「ユーザーはおそらくFacebookアプリ内で他のウェブコンテンツを相当時間見ているに違いない。いわばザッカーバーグは壁に囲まれた庭を作ることに成功している。Facebookは消費者がもっとも長時間利用するウェブ・ブラウザになっているのは間違いない。消費者が全体として毎日39分近くの時間をFacebookアプリ内で過ごすというのはFacebookにとって非常に有利な状況だ」」と述べた。

Facebookは消費者がもっとも長時間利用するウェブ・ブラウザになっている

KhalafはFlurryのブログ記事にこう書いている。

モバイル・アプリが登場してから5年になるが、このエコシステムは大いに繁栄している。成長が鈍化するきざしに目を光らせているが、今のところその兆候はまったく見られない。これはスマートフォンに続いてタブレットも急速に普及したいるためだだ。タブレットとスマートフォンはデスクトップ、ノート両方のパソコンを侵食している。Facebokを始めとするアプリが消費者のモバイル滞在時間の大部分を奪っている。

ブラウザではiOSのSafari（12%）の利用時間がトップだ。Flurryのデータを見ると、iPhoneとiPadのユーザーはAndroidのユーザーよりブラウザを利用する率が少し高い。あるいはAndroidのユーザーがiOSユーザーよりも熱心なFacebookユーザーなのかもしれない。Safariの優位はiPadの普及のせいかもしれない。タブレットの大きな画面ではブラウザの利用が快適になる。しかしAndroidのタブレットは（少なくともまだ）iPadのシェアに及ばない。

これ以外の分野については、エンタテインメント・アプリとユーティリティー・アプリがそれぞれ 8%ずつを占めているという。生産性アプリ、ニュース・アプリはそれぞれわずか2%しか占めていない。またiOSとAndroid以外のモバイル・プラットフォームの支持者が言うような「消費者はアプリに飽きている」という証拠はまったく見出されなかった。ここ3年間の世界のモバイル・アプリの1日あたり平均リリース数は次のとおりだ。2010年誌第4四半期は7.2、2011年第4四半期は7.5、2012年第4四半期は7.9。

「このようにアプリのリリース数が着実に増加していることはまだまだアプリ史上が飽和していないことを示すものだろう。消費者はますます多くのアプリを利用するようになっている」とKhalafは書いている。 ただしアプリの大部分は書籍、テレビ番組、ゲームのように寿命が短い。いずれにせよ「2010に比べて2012年の方がアプリの利用が減っている」という主張には根拠がないようだ。

2010年誌第4四半期から2012年第4四半期にかけて、ユーザーが新アプリを利用する率がほとんど2倍になっていることも発見された（下のグラフ）。これは220万台のデバイスについて2年以上にわたって行われた調査の結果だ。消費者がますます多くの新しいアプリをインストールしているという傾向はデベロッパーにとって朗報だ。

「消費者がこれほど多数の新しいアプリを利用しているということはアプリ市場はまだ成長期にあり、今後イノベーション、ブレークスルーをもたらす新しいアプリの登場が期待できることを意味する」とKhalafは結論している。

[原文へ]

（翻訳：滑川海彦　Facebook Google+）


Rovio、Brightcoveと組んで予定していたビデオ配信をいよいよ開始

Angry Birdsのファンの方ならご存知だろう。否、もちろんAngry Birdsに興味がないなどという人は見たこともない。すなわち読者の方々は皆、既にご存知のことかもしれない。すなわちAngry Birdsはもはや単なるゲームではなくなっているのだ。過去最高の人気となったAngry Birdsの製造元であるRovioは短編ビデオ映画をも提供することにした。そしてそのビデオを、これまでに数多くダウンロードされたアプリケーション内で配布することとしたのだ。

ただ、ビデオの配信にはいろいろと難しい面もある。ゲームは、この数年のうちにスマートフォンからインターネット対応テレビへと広がった。ダウンロード総数は17億にも達し、それぞれのデバイスに対応した驚異的な数のビデオを提供する必要があるのだ。しかもそうした作業を日曜日毎に繰り返すこととなる。これはなかなかの作業となるはずだ。そこでRovioは、すべてを自前で行うのではなく、Brightcoveと組むこととしたようだ。同社は長期間にわたってビデオ配信サービスを手がけてきている。またアプリケーション内でビデオ配信を実現するためのAPIも提供している。

BrightcoveのファウンダーであるJeremy Allaireによると、Rovioはアニメの配信および配信状況の管理、ないしメタデータ管理にBrightcoveの機能を用いるのだとのこと。BrightcoveのVideo Cloudプラットフォームを用いることにより、iOSおよびAndroid版のネイティブアプリケーションを使って簡単にアニメーションの配信が行えることとなった。またインターネット対応TV等でAngry Birdsをプレイしている人もおり、そういう人に対してビデオの提供をするには、Brightcoveを利用するのが非常に便利になっている。

Brightcoveを利用する他の企業同様に、もちろんRovioも利用料を支払うこととなる。利用料は閲覧者数と利用する機能によって変動するのだそうだ。しかしいずれにせよ、自前でビデオ配信環境を整えるよりは相当に安価であることは間違いない。

［原文へ］

（翻訳：Maeda, H）