Chrome Beta,Andy Rubin,Firefox OS
WebOSによるWebアプリが当たり前になったとき、大きなルールチェンジが起きるかもしれない話をしたい。
▼Chrome Beta
AndroidはアプリケーションをJavaで開発するGoogleのOSで、Chrome OSはWebの技術でアプリを開発するGoogleのOSである。異なる２つのOSをGoogleは持っており、それらを統合することは、ずっとGoogleの懸案であった。だから、Googleは少しずつだが取り組みを進めていた。
AndroidにはChromeブラウザーアプリがあるが、Chromeのβ版も存在している。最新のChrome Betaでは、WebRTCやWebGLといった最新の技術をモバイルの世界に導入した。次のGoogle I/Oで紹介されるであろう、新しいAndroidでは更に強力なWebブラウザを搭載することになるだろう。AndroidのブラウザをChromeに置き換え、強力なWeb機能を提供し、その中でChrome OSとの融合を図っていくことを想定していたと考えられる。
▼Google Play&Data Compression Proxy
一方でWebで強力な機能を提供しすぎると、Google Play(Googleのアプリケーションストア）の価値はなくなっていく。GoogleはWebの側での新たな囲い込みとして、Data Compression Proxyを配し、全てのWeb通信をGoogle経由にさせる準備を進めていた。GoogleにとってPlayを毀損するだけの代償もきちんと準備を進めていたと言える。綿密な戦略のもと、Android とChrome OSとの統合を少しずつ進めていたのであろう。
▼Andy Rubin
このたび、アンディー・ルービンががAndroidの開発チーフから離れた。そして、次にはサンダー・ピチャイに変わるという。サンダー・ピチャイはChrome OSのトップであるため、２つのOSのトップを兼務していく事となる。AndroidとChrome OSの統合はGoogleの懸案であった。この統合の路線をサンダー・ピチャイが担うということは、Android側でなく、Webの側を中心に統合を加速する人事だと考えられる。
そして、この人事に関して着目したい事がある。ルービンが5月にD11 Conferenceに出席する予定だったことだ。ごくごく最近まで5月以降もルービンは、Androidのトップの予定で、この人事がGoogle内部でも急激な変化だったと考えられる。つまり、AndroidとChromeOSを戦略のもとに統合を進めてきたGoogleにとって、何らかの時計の針を一気に進めざるを得ない事案が浮上した可能性がある。
▼Firefox OS
それに相応するのが、先日のMWC(Mobile World Congress)ではないだろうか。Firefox OSやTIZENの発表が相次ぎ、一般紙まで第三のOSと騒いだのは記憶に新しい。これらのOSは想像以上に強い力を持つ、ムーブメントとなった。
なかでもFirefox OSはクリステンセン言う破壊的テクノロジーに相応しい。今はローエンドとやかましく言わないようだが、そもそもMozillaは100$のスマートフォンを目指していた。Mozilla自体が次の20億人へインターネットを提供する事を目指しており、中心となる価格もそれに応じたものになるだろう。
また、Firefox OSは多くの人が親しんでいるWebの技術で非常に簡単にアプリが開発できる。Web開発者の数はiOS/Androidに比べ十倍以上存在する。
つまり、既存のアプリにはJavaやObjective-Cといったプログラミング言語により、それなりの障壁があった。それが誰もが親しんでいるWebの技術で簡単にアプリができるようになる。しかも安い。Firefox OSが目指している、既存の市場を支配しているものをチープ、ありふれたもので置き換える戦略は破壊的テクノロジーで主張されているパターンと非常に良く合致しているように思う。
WMCではWebOS陣営が明確で強いモデルを描き始めているのが明確になってきた。一般紙に掲載されるほどの明快で単純なモデルだった。WebOSへの流れが強まりが、Googleの対応を早めることに繋がったのではないかと思う。
▼Webアプリの世界でプレイヤーの変更も
Webアプリではサイトそのものがアプリになる。HTML5の進歩により、サイトをオフライン化することも可能である。またFirefox OS等では、サイトをパッケージにしてアプリとして配布することも可能である。アプリとWebサイトの境界がなくなり、アプリストアの意義が変わる。
アプリ提供者がストアを使って課金をすると、現在は数十%の中間マージンが取られている。それがAppleやGoogleに濡れ手に粟とも言える収益をもたらしていた。だから、ストアでの課金をためらい、ワシントンポストのようにWebサイトに変えていくところも存在していた。そういったストア回避の流れがアプリ全体に及ぶ可能性がでてくるだろう。
では、ストアを通さない決済を実質握っていくのは誰か？ここに主要プレイヤーが変わる可能性が出てきている。Googleは新しい流れに備えて手を打とうとしているが、AppleとMicrosoftからはその動きは見えない。
Mountain LionでもGIMP動くよ
以前にLionでもGIMP動くよと書いた。
今回はMoutain Lionの話。
■ダウンロード先:変更なし
http://gimp.lisanet.de/Website/Download.html
Mountain Lion用があるのでダウンロードください。
■インストール、その前に
今回からはXQuartzが必要と書いてあります。
下記から、ダウンロードしてGIMPをインストールする先にXQuartzをインストールしておきましょう。
http://xquartz.macosforge.org/landing/
Oracle v.s. Google訴訟のGoogleの対応が微妙すぎる件
OracleがGoogleに対して行った訴訟、AndroidでのJavaの特許や著作権侵害を争う訴訟の裁判が始まっています。まず、裁判の様子は下記で報じられています。
■Oracle vs Google 裁判で注目される Java API
http://www.infoq.com/jp/news/2012/04/oracle-vs-google-week1
こちらの記事でもあるように、Oracleの主張とGoogleの主張はそれぞれ、
・Oracle
http://www.oracle.com/us/corporate/features/opening-slides-1592541.pdf
・Google
http://www.groklaw.net/pdf3/OraGoogle-Trial-GoogleOpeningStills.pdf
にまとめらています。
Java(を動作させる環境)を提供する場合にSunからのライセンスが必要なことはJavaの技術屋だったら誰でも知ってたわけで、ましてやSunから技術者を引っこ抜いていたGoogleが知らないはずがありません。Oracleの資料は丁寧でわかりやすいだけでなく、丹念にGoogle経営層やAndroidの開発責任者がライセンスが必要と知っていたことを明らかにしています。（少なくとも個人的にはそう思います。）
これに対するGoogleの対応は微妙すぎます（と個人的には感じています）。SunからGoogleへ移ったLindholm氏はwe need to negotiate a license for Javaと、Javaライセンス交渉が必要としたメールを書いたことを法廷で認めながら、それは誰かからのライセンスだと特定されたものではない、誤解だと斜め上に展開中です。（Sun以外にJavaでライセンスするっていったい誰なんでしょう）また、Googleは本人が法廷でメールの存在を認めたにもかかわらず、Lindholm氏のメールを裁判の証拠から除くよう主張しています。本人が認めたのに除くって、何なんでしょう。
また経営トップのPage氏も微妙な対応だったと思います。
>また，Oracle が立件に使用した Google 社内資料については，見覚えがないと語ったという。
といった次第でメールがデッチあげだと反論するわけでもなく、記憶にございません戦法を使っています。確かにメールのToにも入ったりしてますから、存在しないと否定するのは無理かもしれません。そういうのは理解します。ただ、このような証拠から除け、見覚えない、誤解だなどは裁判のテクニックとしては有効かとは思いますが、Oracleに対する直接の反論にはなってないように思えます。
Oracle資料を見る限り、個人的にはライセンスしなければいけないと知っていたで良いじゃないかと思うのです。法廷というジャングルで勝ったところで、たとえ無罪判決を得たところで、かえって黒々しくなってませんか？どうなんでしょう？
Javaの父、GoslingはSunを買収したOracleをやめて、Googleに引き抜かれましたが、そのGoogleも退社しました。願わくは彼のもとで、もう一度、牧歌的なJavaを取り戻して欲しいものです。あの時代は単なる幻想で、もう叶わぬ夢なのかもしれませんが。。。
IPv6のフォールバックどころか、そもそもM2Mが問題な件
IPv6 Dayもが終わり、IPv6への移行も現実味を帯びてきています。その中で話題の中心といえば、IPv6のフォールバック（遅延）の件だと思います。本日、ひとつのニュースが流れ、解決に向けて行動が始まったようです。
■ネット次世代規格 遅延対策へ
http://www3.nhk.or.jp/news/html/20120417/k10014495531000.html
ただ、個人的にはもう一つ問題だと感じていることがあります。それはIPv6の理想、M2M(Machine to Machine)と深く関係している問題です。
■IPv6の理想
まず、IPv6の理想論を思い出してみましょう。NATが不要であらゆるものにIPアドレスが割当たってNAT越えのような複雑な技術は労せず、機器同士が直に繋がり合うんだと。そういう世界でしたよね。
http://www.nic.ad.jp/ja/newsletter/No20/sec0700.html
＞少なくとも元々のInternetはPeer to Peerを前提としており、サーバ／クライアント型を指向するものではない、ということはいえるでしょう。IPv6によって無尽蔵にグローバルIPアドレ スが使えるのであれば、この原点に回帰できるというわけです。またNATを回避するための技術的な工夫をしなくてすめば、それだけ別のことに注力できてビジネスチャンスも広がろうというものです。
確かに、このように昔は理想に燃えていた時代がありました。しかし、機器同士が直接つながるのであれば、攻撃者からもつながってしまいます。このことは比較的早い段階から、懸念されていました。
http://www.atmarkit.co.jp/fnetwork/tokusyuu/10ipevent/ipevent04.html
＞IPv6導入で考えられるデメリット
＞・NAT／プロキシがなくなることによる、内部ネットワークへの直接攻撃の可能性（外部から内部への攻撃機会の増大）
＞・グローバルIPアドレスの固定化による、特定アドレスへの継続的な攻撃可能性
＞・グローバルIPアドレスでの常時接続による攻撃機会（時間的）の劇的な増大NAPTなどが持っていたダイナミック・フィルタ的効果の喪失
確かにIPSec等あるから、IPv6では大丈夫という楽観もあったと思うのです。しかし、考えてみると、この懸念を覆すことはかなり難しいと思います。
そして、長い議論の結果が、下記リンクのような形にまとめられています。
■IPv6家庭用ルータガイドライン
http://www.v6pc.jp/jp/entry/wg/2010/08/ipv620_2010729.phtml
■RFC 6092(Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service)
http://www.rfc-editor.org/rfc/rfc6092.txt
これらを読んでいただくとわかりますが、確かにNATは要らなくます。しかし、インターネット側からのアクセスは排除しなくてはいけないという、IPv4時代に獲得した智慧（フィルタリング）に何ら変わりはありません。結局、End to Endで直接通信しようとしても、相手側のフィルタリングに阻まれることになります。機器同士を繋ぐにはホールパンチングや中継サーバーなど、IPv4時代と変わらぬ手口が必要なことに変わりはありません。それが結論です。
ソフトウェア技術者の方はIPv6といえば最初のバラ色のイメージ図が強く刷り込まれていると思いますが、ソフトウェア技術者はIPv6でも解決に至らなかった問題が多く残っていることを理解しておく必要があると思います。
■地雷が設置され続けている現実
さて、一方で現実はどうなっているでしょう？NAT不要を喧伝してきた弊害だと思いますが、市場に投入されている家庭用ルーターのIPv6対応の多くはなんと「素通し」です。
http://qa.itmedia.co.jp/qa7325013.html
こういったルーターでIPv6を使えば最初の図のようにM２Mもできますが、家の中の機器に攻撃かけ放題という状態になってしまいます。（なので、通常はIPv6はオフにされているはずです）
家の中の個々の機器が安全であれば素通しでも問題ないです。つまり、家にある金庫がそれぞれ素晴らしければ盗難される恐れはないでしょう。しかし、それでもわざわざ家の鍵を開けておく必要はないわけです。特にIPv6になれば家庭内から沢山の機器をネットワークに繋ぐはずなので、どれかの機器になんらかの問題を持つ家庭も増えるはずです。そのことを加味すると、いっそう家の鍵をあける行為はおかしいわけです。個人的には今ある家庭用ルーターのIPv6は機能が不十分ですので、IPv6を有効にするのは疑問です。
ところが、インフラ屋さんはフレッ○光みたいにどんどんサービスを広げていますし、機器屋さんはIPv6対応を謳った機器を発売しています。うちのルーターはIPv6対応しているとIPv6機能を有効にするたびに、ご家庭にどんどん穴が開いていく状態になっています。このルーターはフレっ○にも使えると、買ってくるたびにご家庭に穴があきます。私としてはネットワークに携わる企業がこれで良いのか首を傾げたくなります。（フレッ○は閉じたネットワーク網とはいえ）
IPv6を前提とするサービスをやるならガイドラインに従ったルーターを推奨し、家庭向けルーターを売るなら、素通し（パススルー）じゃなくて、ちゃんとガイドラインの機能を実装する、それぞれが責任感を持ってやっていただけないものでしょうか。安心して利用できる環境を一般ユーザーが揃えられるようにした上でIPv6のサービスを推進していくべきではないかと、あくまで個としては、そう思います。
新しいiPadで必要になるのはSVG,CSS
新しいiPad旋風ということで、新しいiPadに関するコメントが沢山でています。そういうコメントはもう十分ということで、技術屋の観点から新しいiPadの登場で何が求められるようになったのかを考えて見ましょう。
Rentinaディスプレイでは、文字はうっとりするくらい綺麗に見えます。ただ一つ問題を引き起こしてしまいました。多くのWebサイトでは、ロゴや画像はまだ低解像度が前提なのでロゴなどがボヤけてしまうことです。これではかえって印象が悪いです。特に外見(スタイル)がウリの企業でロゴがボヤけるのは放置できないでしょう。
そこで、これから画像の差し替えが起こると思います。ただ画像が重たくなるのはユーザー体験の低下になってしまいますので、おそらく勝負がかかっているようなメインの画像にしか重たい画像はつかえないでしょう。
ということで、低解像度画像はベクター的情報、つまりはSVG(やCSS）に置き換わっていくように思います。これからSVGが少しだけブームを迎えそうです。
まずはSVGやCSSがどこまでできるかはデモサイトを見てみましょう。たとえばSVG少女（http://jsdo.it/event/svggirl/）やRaphaël(http://raphaeljs.com/)なんかは良い感じです。そして、一歩抜け出すためにSVGについてのTipsも理解しておきましょう。
■SVG女子を90%軽くしたSVG軽量化テク+α #svggirl
http://design.kayac.com/topics/2011/04/svggirl.php
AppleにRentinaディスプレイ用に液晶を提供しているのはどうやら３社ありそうです。独占技術ではないので、今後、Rentinaの解像度がスタンダードになっていくと見ていいと思います。CSSやSVGなどをうまく使いながらサイトの重さは変えないで、高解像度デバイスに対応するスキルが今後求められそうです。
Windows8のセキュアブートにはまる。
Windows8 Customer Previewをインストールして、ディスクに空きがあったので、Linux DVDをインストールしようとしたら、何度やってもカーネルパニックで転びます。
(kernel panic not syncingとか...)
LinuxのDVDをチェックしても悪いところは見当たりません。うーん、どうしたんだろうと思っていたところ、Windows8 Consumer Previewをインストールすると、セキュアブートが入る話を思い出しました。
そういう話は知っていたのですが、ぐはぁ、これがそうだったのかぁぁぁぁ！！
まさかLive CDも起動できなくなるとは・・・
仮想PCや古いPCなら良いですが、Windows8インストールには皆さん気をつけましょう。。。。
WebRTCを試して、新しいWebの世界を見てみよう！
先日、Google Chromeの開発版がWebRTCを搭載しました。
■Chrome開発版がWebRTCを実装 - JavaScriptからカメラやマイクが利用可能に
http://news.mynavi.jp/news/2012/01/23/041/index.html
WebRTCって何？と思われるかもしれません。WebRTCは将来のWebの仕様で、Web Real-Time Communications の略称です。Webブラウザの上でカメラやマイクの利用や、ブラウザ同士の間の双方向通信(P2P)を実現します。対戦ゲームでのブラウザ同士の通信やビデオ会議、音声会議など、これからのWeb体験を大きく変えていくことになる非常に強力な仕様です。
詳しくは、こちらをご覧ください。
https://sites.google.com/site/webrtc/home
さて、そんなWebRTCですが、現在ではアプリケーションをインストールするだけでとても手軽に試すことができるようになりました。早速、試してみませんか？試し方は下記のサイトに掲載されています。
https://sites.google.com/site/webrtc/running-the-demos
上のサイトによると、
http://tools.google.com/dlpage/chromesxs
から開発版のChromeをインストールして、ショートカットキーのプロパティを開き、「--enable-media-stream」と付け加えればＯＫです。下のイメージのようなデモを幾つか試すことが出来ます。
Chromeの起動後、下記のデモサイトにアクセスしてみましょう。
こういったデモが楽しめます。
Paul Neave さんのビデオ効果アプリ
http://neave.com/webcam/html5/
Justin Uberti (Chrome-webrtc チームメンバー) の方の1:1ビデオ電話デモ。
http://apprtc.appspot.com/
Justin Uberti (Chrome-webrtcチームメンバーの)顔検出デモ。http://apprtc.appspot.com/html/face.html
Greg Miernickiさんが送った公式の初めてのデモ
http://miernicki.com/cam.html
現在、WebRTCはＣ＋＋のライブラリを開発をしていて、今後はさまざまなブラウザへ搭載されていくと思われます。これからのWebの世界をいち早く体験して、Webの世界をもっと楽しいものにしていきましょう！
