GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
ブックマークされました!
ブックマークがエラーになりました。もう一度お願いします。
作者 Abel Avram , 翻訳者 渡嘉敷 満理子 投稿日 2010年1月14日
Googleは、FCC (米連邦通信委員会) にWhite Spaces Databaseの管理者になることを提案した。このWhite Spaces Databaseには、無線周波数帯の未使用チャンネルを利用している機器の位置情報が格納される。
2008年のFCCの決定により、米国の無線通信用ホワイトスペースを一般向けに開放し、無線ブロードバンド通信に使用することとなった。ホワイトスペースとは、既存のテレビ局間で干渉を防止するため、意図的に使用されていないテレビ放送用チャンネルである。さらに、テレビのアナログ放送からデジタル放送への移行により、広域の周波数帯 (698-806 MHz) が開放されたが、この空スペースには、長距離アクセス用に80 Mbps以上、短距離アクセス用に400-800 Mbpsの速度性能が備わっていることから、すぐさま、インターネット ユーザ向けの高速無線アクセスに役立つと考えられた。
FCCの決定に対し、開放されたチャンネルを使用することで、テレビ放送用の信号との干渉を懸念したテレビ局側 (PDF形式の嘆願書) や、同じ電波スペースを使用しているライブ シンガーらが異議を唱えた。
干渉を回避する解決策の1つとして、操作開始前に、周辺機器およびその周波数を検知する機器のみを使用する案があったが、この解決策では、既存のユーザを保護できるほど、安全性があるとは認められなかった。これにより、White Spaces Database (WSDB) という考え方が導入された。これは一般からのアクセスの登録や、その位置に基づいて使用される機器および周波数の検知を許可するデータベースである。このデータベースは、機器間での競合を避ける理由から、ローカル デバイスの検出と同時に使用される。この考えを支持して、Comsearch、Dell、Google、HP、Microsoft、Motorola、Neustarなどが団体を設立し、White Spaces Database Group (WSDG) と名付けられた。
Googleは、広告キャンペーン「Free the Airwaves (放送電波を開放しよう)」の実施など、はじめからこの考えをサポートしてきた。当初、彼らは次のように述べていた。
われわれ自身が、データベースの管理者になるつもりはないが、White Spaces Databaseが確実に機能するようにFCCと協力することを望んでいる。これを年単位ではなく、ほんの数ヶ月で展開できればと考えている。
Googleが、WSDBの作成者および管理者に自らを指名するよう、FCCに提案を提出して間もないため、彼らがその考えを変えた理由は不明である。
今回、Googleがテレビ放送用White Spaces Databaseの管理者になるという提案を提出することで、委員会の任務を引き続きサポートできることを喜ばしく思っている。
Googleは、少なくとも5年はWSDBの運用を行うことを提案しており、彼らがそれを実現できない場合は、「このデータベース、データベースへのアクセスに使用されるIPアドレスとURL、および登録済みの固定用ホワイトスペース機器のリストを後任の者に引き継ぐ」ことを約束している。Googleの提案は、そのような既存の他のデータベースの可能性を制限するものではない。
Googleは「問合せ単位での課金」は考えていないが、デバイス単位での課金を検討している。まだ何ら決定は下されていないが、FCCはWSDB管理者によるそのような料金の徴収を認めている。
White Spaces Database Groupに関連のあるWireless Innovation Allianceのウェブサイトは、現在「停止中」である。これは、WSDGがもはや機能しておらず、各企業が独自に行動していることを意味しているのかもしれない。
【豆蔵】「オブジェクト指向を現場で活かすリファクタリング入門」新規講座キャンペーン中
【ネクストスケープ】.NET、C#のアプリケーション開発者募集
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
スレッド表示 返信