GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
ブックマークされました!
ブックマークがエラーになりました。もう一度お願いします。
作者 Dionysios G. Synodinos , 翻訳者 鰈崎 義之 - CSKシステムズ 投稿日 2009年12月20日
Dojo チームは、新機能だけでなくパフォーマンスと安定性を改善した Dojo 1.4 のリリースを発表した。
このリリースの一番の目的は、安定性とパフォーマンスの改善であるので、私たちは、大きな新しい機能性がさまざまなプロジェクトに、ほんの少しでもこっそり持ち込まれないように管理しました。ここに挙げるにはあまりに多する、すべての重要な変更は、1.4 リリースノート (移行の問題を含む) に記載されています。単純な利便性の変更に至るまで幅があります。dojo.Animation のようなコールバックは、アニメーションされているノードが渡されるようになりました。完全に新しい dojo.cache のような API は、dijit._Templated の外側でインターン化されたビルドを提供しています。いくつかの変更は、長年"プライベート"としていた API を単純にパブリックにしたことです。dojo._Animation は、今やパブリックの dojo.Animation として、dojo._contentHandlers は、上級ユーザに Ajax トランスポートの構成を公開する、dojo.contentHandlers となり、それらの API 利用への公式なコミットメントを与えています。
この記事の著者は、Firefox 3.5.5 で TaskSpeed を試した。サンプルテストに Dojo 1.3 で 701ms 要したのが、Doj 1.4 では 687ms 要したことを確認した。IE 8 の仮想マシンでは、同じ数値が 2694ms と 2613ms になった。
James Burke 氏が述べるように、Dojo の DOM API は、jQuery で利用可能なものとより近くなっていくようにもみえる。
私が Dojo Core でやりたい事のひとつが、DOM API をもたらすこと、特に dojo.NodeList (dojo.query() 呼出が返すオブジェクト、Dojo の CSS セレクタメソッド) のメソッドを jQuery で可能なようによりインラインとすることです。jQuery は、その API が開発者に強く共鳴することを示しました。そのことが意味をなし、Dojo の哲学に合う部分は、開発者にとってより簡単になるように、私たちもその API を提供すべきです。以下の Dojo 1.4 の変更がゴールを示しています。
- dojo.ready()、ただの dojo.addOnLoad() のエイリアス。
- dojo.NodeList-traverse: dojo.NodeList に追加したヘルパモジュール。そのゴールは jQuery に存在する DOM トラバースするためのいくつかのメソッド 、特に: children、 closest、 parent、 parents、 siblings、 next、 nextAll、 prev、 prevAll、 andSelf、 first、 last、 even、 odd を NodeList にもたらす。
- dojo.NodeList-manipulate: dojo.NodeList に追加したヘルパーモジュール。そのゴールは jQuery に存在する DOM 操作するいくつかのメソッド、特に: innerHTML、 html、 text、 val、 append、 appendTo、 prepend、 prependTo、 after、 insertAfter、 before、 insertBefore、 remove、 wrap、 wrapAll、 wrapInner、 replaceWith、 replaceAll、 clone を NodeList にもたらす。
- IO パイプライン Topics: dojo.subscribe/dojo.publish からの IO イベントの通知を得る。IO 呼出が発生したような時に、一般的な"ロード中"を示す状態を取り出すことに役立つ。これらの Topics は、この機能を jQuery が公開している方法とは厳密には違うが、私たちはこの機能を実装するために dojo.publish/subscribe の力を使うことができる。
InqoQ は、SitePen の CEO であり Dojo Toolkit の共同作成者である、 Dylan Schiemann 氏に、最新リリースについての小さな Q&A を行った。
InfoQ: あなたにとってこのリリースのハイライトは何でしょうか?
Dylan: 私にとってのハイライトは、http://www.sitepen.com/blog/2009/12/10/dojo-1-4-released/ に記載されています。
- IO パイプライン Topics
- dojo.cache
- dojo.contentHandlers
- dojo.hash、ネイティブ HTML5 の onhashchange イベントのサポートで利用可能となる
- NodeList (dojo.query の返り値) のトラバーサルと操作
- dojo.ready (dojo.addOnload よりもタイプしやすい)
- Dijit API と Dijits のコレクションのための数百の洗練とDojoX へのいくつかの 新しいウィジェット
- dojox.drawing の登場!
- Editor の改善と Dijit と DojoX 両方の新しいプラグイン
- 速くなった Grid と、EnhancedGrid の登場!
- TreeGrid 用の ForestStoreModel
- GFX の改善
- dojox.jq、jQuery API に可能な限り近づけ合わせる事を目標としたとても実験的なモジュール、しかし表面下では Dojo を使っている
- Dojo ビルドシステムは、オプションで Google Closure ツールコンパイラをサポートしている
- 特に IE においての大幅な速度改善
大きななグリッド改善と拡張、dojox.drawing の導入は、IE パフォーマンス全般にわたる主なコアの改善と同じくらいとても印象的です。
InfoQ: あなた方は Firefox 2 のサポートを止め、Safari、Chrome、Opera (コア機能のみ) の最新バージョンしかサポートしていないように見えます。
Dylan: 私たちがブラウザのサポートを止めたとしても、それは動かないことを意味していません。単に、私たちが QA/テスティングサイクルを通して実施しないことを意味するだけです。もし古いバージョンの FF を落とすようなバグがあれば、一般的に今でもそれに対処します。Safari と Opera においては、それらのユーザは、一般的に自動更新するのでそれでいいと信じています。しかし繰り返しますが、もしユーザが問題を報告すれば、一般的に私たちはサポートされていないブラウザであっても、それらを修正します。これは、YUI でいうところの最上級と2番目のクラスのブラウザサポートの中間に当てはまります。
InfoQ: Dojo 1.4 のリリースと一緒に、James Burke 氏は、DOM API に "jQuery で可能なようによりインライン" をもたらすことへの彼の興味を述べました。どのように Peter Higgins 氏によって彼の "jQuery でお気に入りのところ" として述べられた plugd とされた作業と関連しますか? あなたは、これらの二つのフレームワークがより近づいていくだろうと感じますか?
Dylan: plugd の作業は、jQuery API 互換性のための dojox 作業、そして dojox.jq の作業は全ての 開発者の DOM での生産性のゴールへ取り組むことを意味しています。jQuery は DOM 操作のための素晴らしい API を提供しているので、私たちのユーザをサポートしたいです。plugd はこれへの最初の取り組みでした。そして dojox の作業は、このいくつかを Dojo に移動することに向けた最初の一歩です。それらがよくテストされ、高いパフォーマンスで、API が安定すれば、最終的には、重要な断片は、Dojo Core の中へのそれらが取り込まれるでしょう。
リリースについてのさらなる詳細は、リリースノートとドキュメントの中で見つけられる。Dojo は BSD ライセンスとバージョン 2.1 の Academic Free License の元にリリースされている。そしてダウンロードもしくは二つの CDN から利用可能である。
あなたは、Dojo と JavaScript に関するさらなる情報をちょうどここの InfoQ で見つけることができる。あるいは Dojo.connect() カンファレンスを調査することから得ることもできる。
【ネクストスケープ】.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
スレッド表示 返信