GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
ブックマークされました!
ブックマークがエラーになりました。もう一度お願いします。
作者 Abel Avram , 翻訳者 徳武 聡 投稿日 2010年6月14日
Microsoftは8つのカテゴリに分類される192項目のテストの結果を発表した。これらはHTML5、SVG 1.1、CSS3、そして DOM Level 2&3についてのテストで、テスト結果を見るとIE9のプレビュー版はすべてのテストに合格している。一方で、Chrome、Firefox、Opera、そしてSafariのテスト結果はカテゴリごとに濃淡がある。この結果だけ見るとIE9が最も正確にW3C標準に準拠したブラウザということになるが、当然、GoogleとMozillaと Operaはこの結果に異議を表明している。
Microsoftは192の“テストページを作りました。これらのテストページは私たち[Microsoft]とWorld Wide Web Consortium(W3C)のワーキンググループが協力して作ったものです。” そして、主要なブラウザのテスト結果は下記の通り。
テスト結果の要約から各テストページを含む詳細な結果をたどることができる。したがって、誰でも同じテストができる。テスト結果は、IE9プレビュー版はW3C標準に100%と準拠している一方、他のブラウザは標準に対応する作業に遅れをとっている、というものだ。他のブラウザの中では、FirefoxがDOM2のテストで100%を記録したのがもっとも良いテスト結果だが、他のほとんどのブラウザが多くのカテゴリで黄色か赤の成績しか残せなかった。InfoQはこのテストやテストの結果に対する意見を聞くため、Google、Mozilla、そしてOperaを取材した。
GoogleはGoogle I/Oの初日のキーノートでHTML5の課題について触れている。彼らの見通しでは2010年末にはIEを除くすべてのブラウザがHTML5標準やその他の仕様を完全に実装する。(キーノートの9分35秒を参照)
Mozillaの考えでは、Microsoftのテストはテスト範囲を制限しているので、不正確で誤解を招く。
Microsoftがテストをして標準に従おうと前向きに取り組んでいることは喜ばしいことですが、これらのMSDN上で行われた各テストはブラウザの能力の一部分しか対象にしていません。率直にいって、標準への準拠に関する彼らの発表は誤解を招くものです。
MSDN上のSVG-in-HTMLテストは壊れていて、HTML5のパースルールにもDOMの仕様にも合致しないことはよく知られています。また、このパース処理にはIEにもバグがあり、このバグを利用することでテストに合格しています。Microsoftのエンジニアはバグのことも、そして、テスト自体が間違っていることも知っています[1][2]。なので、このテストがブラウザ間の相互互換を促進する活動の中の重要なテストとして持ち上げられているのには驚きました。一方、Firefoxのベータ版ではHTML5パーサの準備は整っています[3]。ナイトリービルド版[4]はSVG-in-HTMLの本物のテストにも合格するでしょう。
加えて、MSDN上のCSSのテストは正確ではありません。このテストに合格するブラウザは標準に従っていません。CSS3-selectorsテストは公式のものがあり、私たちはすべての関連するテスト[5]に合格しています。また、ウェブ開発者に対してはcaniuse.com[6]のようなサイトを推奨します。このサイトはブラウザのHTML5、CSS3、そしてSVGのサポートについて議論するときにとても有用です。Mozillaは引き続き、問題になっている仕様に対して忠実でオープンで公正なテストを実施することに貢献していきます。また、他のブラウザベンダに対しても同じような対応を求めていきます。
追記: Mozillaが以下のように声明を更新した。短いが重要な情報である。
私たちはMicrosoftから返答を受け取りました。現在、彼らと協力してテストを修正しています。
OperaはMicrosoftのテストとその結果を知っているが、彼らは異なったテストを使って異なった結果を導いている。
私たちは内部で特定のテストを実施したことはありません。すべての範囲を網羅するテストを常時行っています。HTML5標準に対する私たちの貢献が私たちの製品に間違いなく実装されていることを確かめるためです。OperaはHTML5標準に対する大きな貢献者です。Videoタグを標準に含めようと提案したのはOperaです。私たちは私たち自身の製品を改善しようといつも努力していますし、可能な限り標準に従おうとしています。
今回のテストはテスト対象の要素がとても偏って選択されています。テスト結果も他のブラウザよりIEを優遇しているように思えます。HTML5のテストを実施するのであれば、すべての種類のテストで判断基準を一致させておくべきです。テストの権威性も独立していなければなりませんし、テスト自体も仕様の本質を反映していなければなりません。IEよりもOperaが格段に優れていることを示す、他のHTML5関連のテストは簡単に見つかります。例えば、http://www.codedread.com/svg-support.phpがそうです。…
私たちは、開発しているブラウザがどの程度の互換性を持っているか確認するために随時テストを行っていますが、HTML5は現在も仕様を策定中です。したがって、Microsoftのテスト用のページは、HTML5のほんの一部分を選択してテストしているようです。例えば、Canvas要素のような多くの要素をテスト対象から除外しています。
面白いことにOperaが示したテスト結果ではOpera10.53はSVG 1.1のテストの94.89%に対応している。一方でIE9のプレビュー2は同じテストの30.55%にしか対応できていない。Opera10.52でMicrosoftのテストを実施するとほぼ同じ結果になるのに対して、このテストで100%だったIE9は30.55%と大きく離れた結果になってしまう。
Jeff Schiller氏はOperaが示したテストを実際に実行したソフトウエア開発者だ。氏はMicrosoftのテスト結果についてコメントをしている。
IE9が進んでいる方向についてはとてもわくわくしています。また、SVGのワーキンググループへしっかりと関わったことにも感銘を受けました。しかし、“IE Testing Center”には問題があります。とても誤解を与えるからです。確かにこれらのテストは自分たちで作成した(IE9は合格した)テストだけであり、完全なテスト項目ではないことはMicrosoftも認めていますが、それにしても問題です。
例えばSVGのテスト項目は275あります。しかしMicrosoftはこのうちの31しかテストしていません。一例を挙げると、IE9はまだ勾配に対応していません。
他にも、例えば彼らのHTML5テストで取り上げられているインラインSVGマークアップは間違っています。IE9だけがこのテストに合格するのは、ブラウザにバグがあって、そのバグが子ノードをうまく扱ってしまうからです。もしこのテストを正しく修正したら、Firefoxのナイトリービルド版はこのテストに合格するでしょう。しかし、IE9は合格しません。
Appleは私たちの取材に答えなかったが、HTML5 Showcaseを公開している。これも議論を巻き起こしている。
【ネクストスケープ】.NET、C#のアプリケーション開発者募集
世界の先進エンジニアが集結 - QCon TOKYO 2012 早期割引実施中!
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。
Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。
GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式
本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。
前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。
Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。
スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。
No comments
スレッド表示 返信