ＮＴＴ東日本は12日、米グーグルの携帯電話向け基本ソフト（ＯＳ）「アンドロイド」を使った小型インターネッ
ト端末を2010年度上期に発売すると発表した。ＫＤＤＩも同ＯＳを使ったネットテレビの受信機を開発中。アンドロイドは無償で利用でき、デジタル家電の
コスト低減に役立つため、携帯電話以外の市場でも急速に存在感を高めている。
ＮＴＴ東が開発したネット端末「光ｉフレーム」（仮称）は画面に指を触れて操作する７インチのタッチパネルディ
スプレーを搭載。「デジタル写真立て」として使い、必要な時にネット閲覧に利用する。無線ＬＡＮ（構内情報通信網）の通信機能を備え、宅内で持ち運んで利
用できる。
- 前ページ
- 次ページ
Googleは米国時間11月5日、「Closure Tools」と呼ばれるプロジェクトをリリースし、同社のウェブサイトおよびウェブアプリケーション作成レベルに達することを望む開発者をサポートしていく方針を明らかにした。
Googleは、ウェブ中心のビジョンの一環で、JavaScriptを用いたウェブベースのプログラム記述を強く推進している。確かに Googleは、「Gmail」や「Google Docs」などのサービスを通じて、JavaScriptを最大限に活用しており、より高速にJavaScriptプログラムを実行できるようにする目的もあって、「Chrome」ブラウザの開発に努めてきた。
ロゴ
しかしながら、JavaScriptプログラムは時に異なるブラウザ上では異なった動作をするなどの理由から、高機能なJavaScriptの記述、デバッグ、最適化は困難なものともなってきた。Googleがオープンソースで提供するClosure Toolsのプロジェクトでは、こうした難題に取り組みやすくすることが目指されている。
同ツール群の最初のものは、「Closure Compiler」と呼ばれるソフトウェアパッケージであり、より小サイズで高速に稼動するように、JavaScriptプログラムのスリムダウンを図ることができる。たとえば、「DisplayAddress()」という名称の機能は、単に「()」に置き換えられる。
コンパイラに加えて、「Firefox」ブラウザ向けには他にもツールが提供される。Firefoxの「Firebug」アドオン向けのエクステンションとなる「Closure Inspector」も、その中に含まれており、再び「()」を「DisplayAddress()」に関連付けるといった、プログラマーが新たに記述されたJavaScriptの理解を深め、デバッグできるようにサポートするものとなっている。「Google Page Speed」エクステンション向けの別のアドオンでは、プログラマーがコンパイラのサポート進行度を見極められるようになっている。
また、Googleは、「Google App Engine」サービスにホストされたウェブアプリケーションとしてコンパイラを提供する計画も立てている。
Closure Toolsの2番目には、プレ構築されたJavaScriptコードのコレクションとなる「Closure Library」が挙げられる。Closure Libraryにより、プログラマーは、配列およびストリング処理といった高度に洗練されたテクノロジを扱えるようになる。
Closure Toolsの最後には「Closure Templates」が挙げられ、JavaScriptやHTMLユーザーインターフェースの作成を容易に進められるように、あらかじめ記述されたコードが提供される。
Googleは、ウェブ中心のビジョンの一環で、JavaScriptを用いたウェブベースのプログラム記述を強く推進している。確かに Googleは、「Gmail」や「Google Docs」などのサービスを通じて、JavaScriptを最大限に活用しており、より高速にJavaScriptプログラムを実行できるようにする目的もあって、「Chrome」ブラウザの開発に努めてきた。
ロゴ
しかしながら、JavaScriptプログラムは時に異なるブラウザ上では異なった動作をするなどの理由から、高機能なJavaScriptの記述、デバッグ、最適化は困難なものともなってきた。Googleがオープンソースで提供するClosure Toolsのプロジェクトでは、こうした難題に取り組みやすくすることが目指されている。
同ツール群の最初のものは、「Closure Compiler」と呼ばれるソフトウェアパッケージであり、より小サイズで高速に稼動するように、JavaScriptプログラムのスリムダウンを図ることができる。たとえば、「DisplayAddress()」という名称の機能は、単に「()」に置き換えられる。
コンパイラに加えて、「Firefox」ブラウザ向けには他にもツールが提供される。Firefoxの「Firebug」アドオン向けのエクステンションとなる「Closure Inspector」も、その中に含まれており、再び「()」を「DisplayAddress()」に関連付けるといった、プログラマーが新たに記述されたJavaScriptの理解を深め、デバッグできるようにサポートするものとなっている。「Google Page Speed」エクステンション向けの別のアドオンでは、プログラマーがコンパイラのサポート進行度を見極められるようになっている。
また、Googleは、「Google App Engine」サービスにホストされたウェブアプリケーションとしてコンパイラを提供する計画も立てている。
Closure Toolsの2番目には、プレ構築されたJavaScriptコードのコレクションとなる「Closure Library」が挙げられる。Closure Libraryにより、プログラマーは、配列およびストリング処理といった高度に洗練されたテクノロジを扱えるようになる。
Closure Toolsの最後には「Closure Templates」が挙げられ、JavaScriptやHTMLユーザーインターフェースの作成を容易に進められるように、あらかじめ記述されたコードが提供される。
HTML5策定で中心的役割を果たすWHATWG（Web Hypertext Application Technology Working Group）のイアン・ヒクソン氏は2009年10月27日、同グループのメーリングリスト上でHTML5および関連仕様の「Web Workers」、「Microdata Vocabularies」などを最終草案（Last Call）とすると宣言した。Web WorkersはJavaScriptでスレッド処理のようなバックグラウンド処理を行うための仕様。Microdata VocabulariesはvCardやvEvent、iCalendarといった“マイクロフォーマット”の名称で呼ばれていた機械可読なメタデータを HTML内で扱うための仕様。このほか、Web Storage、Server-sent Events、Web SocketsがWHATWGの最終草案となり、Web Database仕様だけが残された形だ。
現在HTML5はW3CとWHATWGが共同で策定を進めているが、作業がスタートしたのも作業自体もWHATWGが主導しているため、大きなステップと言えそうだ。ただし、ヒクソン氏はW3CのHTMLワーキンググループのエディタも務めているが、今回のWHATWGの案が、W3Cの最終草案となるかどうかは別問題だと注意を促している。また、HTML5が最終的にW3C勧告となるには、まだW3Cにおいて最終草案、勧告候補、勧告案などのステップを踏む必要があり、この意味ではHTML5の最終着地にはまだかなりの時間がかかることが予想される。一方で、主要なWebブラウザベンダはHTML5および関連仕様の実装に積極的で、多くの関連仕様がOpera、Google Chrome、Firefox、IE8などで実装済み。技術仕様の基礎が固まることには大きな意義がありそうだ。
ヒクソン氏は最近作成された技術仕様書「Web Applications 1.0」にも言及している。これは肥大化してスペックの分離独立を繰り返しているHTML5関連仕様を取りまとめた文字通りWebアプリケーションのための技術仕様書だ。
これまでHTML5の草案には、テキスト・マークアップ言語としてのHTMLの側面と、WebアプリケーションプラットフォームのためのAPIが混在してきたきらいがある。Web SocketsなどはHTTPの拡張プロトコルで、マークアップ言語とは本来関係がない。この意味では各API群をモジュールに分離させることは技術的合理性がある。モジュール化が進めば、実装時の取捨選択もやりやすいだろう。
HTML5ではこれまでWeb Storage、Web Workers、Web Socketsなどが順次独立したAPI仕様として分離独立してきた。また、最近では2DベクターグラフィックのCanvasを分離させる議論が出てくるなど、「HTML＋API仕様群」という構成に変化していた。勢いを得つつあるHTML5策定グループが、Webアプリケーションに必要な機能を一気に HTML5の仕様に盛り込もうとしたものを、仕様策定のスピードや複雑さ回避のためにHTML5自体は文書マークアップのコアに縮小してきたようだ。つまり、Web Applications 1.0は、HTML5の策定プロセスで次々に産み落とされたきた関連仕様を、再び全体像として有機的に結びつけて見せる仕様と言えそうだ。もともと WHATWGでHTML5の元になる仕様策定が始まったときにも、「Web Applications」という名称が使われていたため、その名称が復活した形にもなっている。
現在HTML5はW3CとWHATWGが共同で策定を進めているが、作業がスタートしたのも作業自体もWHATWGが主導しているため、大きなステップと言えそうだ。ただし、ヒクソン氏はW3CのHTMLワーキンググループのエディタも務めているが、今回のWHATWGの案が、W3Cの最終草案となるかどうかは別問題だと注意を促している。また、HTML5が最終的にW3C勧告となるには、まだW3Cにおいて最終草案、勧告候補、勧告案などのステップを踏む必要があり、この意味ではHTML5の最終着地にはまだかなりの時間がかかることが予想される。一方で、主要なWebブラウザベンダはHTML5および関連仕様の実装に積極的で、多くの関連仕様がOpera、Google Chrome、Firefox、IE8などで実装済み。技術仕様の基礎が固まることには大きな意義がありそうだ。
ヒクソン氏は最近作成された技術仕様書「Web Applications 1.0」にも言及している。これは肥大化してスペックの分離独立を繰り返しているHTML5関連仕様を取りまとめた文字通りWebアプリケーションのための技術仕様書だ。
これまでHTML5の草案には、テキスト・マークアップ言語としてのHTMLの側面と、WebアプリケーションプラットフォームのためのAPIが混在してきたきらいがある。Web SocketsなどはHTTPの拡張プロトコルで、マークアップ言語とは本来関係がない。この意味では各API群をモジュールに分離させることは技術的合理性がある。モジュール化が進めば、実装時の取捨選択もやりやすいだろう。
HTML5ではこれまでWeb Storage、Web Workers、Web Socketsなどが順次独立したAPI仕様として分離独立してきた。また、最近では2DベクターグラフィックのCanvasを分離させる議論が出てくるなど、「HTML＋API仕様群」という構成に変化していた。勢いを得つつあるHTML5策定グループが、Webアプリケーションに必要な機能を一気に HTML5の仕様に盛り込もうとしたものを、仕様策定のスピードや複雑さ回避のためにHTML5自体は文書マークアップのコアに縮小してきたようだ。つまり、Web Applications 1.0は、HTML5の策定プロセスで次々に産み落とされたきた関連仕様を、再び全体像として有機的に結びつけて見せる仕様と言えそうだ。もともと WHATWGでHTML5の元になる仕様策定が始まったときにも、「Web Applications」という名称が使われていたため、その名称が復活した形にもなっている。