Google App Engineを使ってみながら、オセロゲームを作ってみた。本当ならソースコードもと思ったが、弄ったり、戻したりを繰り返した汚いコードなので非公開です。
URLから適当に名前を入力してログインすると、対戦相手が現れるまでの待機画面になります。ほかの誰かがゲームにログインすると、見慣れた升目が表示されて、ゲームスタートです。
Google App EngineでのセッションID生成
意外なところで嵌るものだ。
Pythonでは乱数生成用のエンジンを何種類か積んでいる。Wichman-Hill(WichmannHillクラス)と、メルセンヌツイスタ(randomクラス)、OSの提供する乱数ジェネレータ(SystemRandomクラス)から選ぶことが出来る。セッションIDに使用するなら、予測不可能でビット数の多い乱数を生成できるSystemRandomクラスを選択したいところなのだが、Google App Engineでは対応していないらしい。セキュリティ上重要なハードウェア乱数が提供されていない辺り、本当に片手落ちだと思う。
デバッガ上だと普通に動くので、気が付くのが遅れた。
・・・と言うわけで、メルセンヌツイスタ(randomクラス)で生成する以外の方法はないようだ。
マルチスレッドプログラミングとvolatile
マルチスレッドを使った最適化のWEB記事を続けて見かけたのだが、みんなvolaileについてはスルーしているので補足してみる。volatileは変数単位でコンパイラの最適化機能を無効にする修飾詞です。C++にもC#にもJavaにも、主要な言語には大抵用意されています。volatile宣言を忘れると、Releaseビルドでしか発生しない、再現性の低い、達の悪いバグに襲われる事になります。
何故volatile宣言が必要なのかと言うと、最近のコンパイラは高度に最適化作業をおこないます。その結果として、プログラマが記述したとおりの順序で処理を実行しない事もあります。マルチスレッドで特に問題になるのが、命令の順番の入れ替えや、演算処理のループ外への移動です。
例えばループの中でA*B*2という計算をしていたとします。コンパイラは局所的に見て、ループ内で変数Bが変更される可能性が無い事を判断した場合、B*2演算をループの外に移動したりします。すると別スレッドで変数Bの値を変更しても、他スレッドのループ内の演算には反映されないという事になってしまいます。
コンパイラが最適化する前： int a, b, d; void funcA(void) { while (true) { a = funcB(); d = a * b * 2; } }
コンパイラが最適化した後： int a, b, d; void funcA(void) { int e = b * 2; while (true) { a = funcB(); d = a * e; } }
実はVisual C++やC#ではstatic変数やグローバル変数を無条件にvolatileな変数として扱うようになっています。スレッド間で共有するような変数の多くはstatic変数やグローバル変数ですから、殆どの場合volatile宣言を忘れていても動いてしまいます。でもそのために、ケアが必要だと言う事も忘れがちなのです。
「クラウドはメリットよりリスクが大きい」…
「クラウドはメリットよりリスクが大きい」、IT専門家の45％
うん、まぁ、そうだよね。
PaaSやSaaSに限れば、サービスの継続性について、他社に依存する事になる。サービスが中止されたときに他社のサービスに移りたいと思っても、アーキテクチャに互換性が無いため、設計レベルからやり直さなければならない。これってかなり大きなリスクだよね。
HaaSやIaaSについては他社へのサービスの乗り換えも可能だけど、これだってクラウドのスケーラビリティの高さに依存した設計をしていたら、クラウド以外の環境には逃げようがないのだ。自前でハードウェアを用意してもいいけど、損益分岐点は跳ね上がってしまうもの。
結局のところ、短期集中でスポット的に利用するシステムじゃないと、なかなか業務でクラウドに載せると言う訳にはいかないよね。
Google App Engineの弱点はバックグランドの処理を作れないこと
Windows Alureの開発経験はまだないけど、セミナーなどで聞いている限りでは、Google App Engineの最大の弱点はバックグランドタスクを作れない事だなぁ・・・と実感する。
Google App Engineにも定周期で処理を起動するcronはあるのだけど、最短でも一分周期が限度。基本的にはCGI経由で呼び出されるのと同じなので、1～2分以内に処理を完了しないと異常終了してしまう。したがってUIに相当する処理と、バックグランドで動作する処理を即時に連携させるような事はできない。
これがWindows Azureならバックグランドで処理をするプロセスを常駐させておき、UIに相当する処理と通信させることができる。
この差が結構大きくて、ログインしている複数のユーザ間でリアルタイムのデータ交換をおこなうようなアプリケーション・・・具体的に言うとゲームとかチャットとか・・・を実装しようとすると結構な問題になる。Data Store上の一つのエンティティにデータを集中させて、そこでトランザクション制御をおこなうぐらいしか手が無い。もちろん、こんな事をすればスケールアウト出来るメリットを放棄する事になるし、ユーザー数にも大きな制限を受ける事になる。
これがWindows Azureならバックグランドで調停をおこなうタスクを複数常駐させて、UIに相当する処理からの要求を順番に調停しながら処理する事も出来るのになぁ・・・。それとも私が見落としているだけで、Google App Engineなりの良い実装方法があるのだろうか？
クラウドってなーに？と言うのを今更ながら整理してみる
クラウドを使ったサービスは知っているけど、クラウドが何なのかわからない・・・という人は多いと思う。要は冗長化した複数のハードウェア上で動作しており、今この瞬間にどのハードウェアで動作しているかを意識しないシステムの事だ。理解を難しくしている理由は、どのレイヤーでサービスするかとか、どの物理ハードウェアで動いているかを何処まで意識させるかによって、さまざまな亜種があり、その境界が明確ではない事だ。
まず一つ目の軸として、パブリックよりか、プライベートよりかという話がある。たとえばGoogle App Engine（GAE）はパブリックなクラウドです。GAEは世界中の何処に設置されたハードウェアで動いているのか、ユーザーはまったく意識できません。Windows Azureはもうちょっとプライベートよりです。Azureはハードウェアがアメリカ大陸にあるのか、アジアにあるのか、EUにあるのか、ある程度意識する事ができます。NTTのBiz Cityはさらにプライベートよりです。Biz Cityのユーザーは何処の建物の中で動いているのか意識する事ができます。もっともプライベートよりのクラウドは、ハードウェアを自分で購入して自分で管理します。自分の作ったアプリケーション以外が動く事はないでしょうけれど、複数のハードウェアに冗長化されており、どのハードウェアで動作しているかは意識しないので立派なクラウドです。
二つ目の軸がどのレイヤーでサービスを提供するかです。よりハードウェアに近い方から、HaaS、IaaS、PaaS、SaaSと呼ばれています。HaaSの場合提供するレイヤーはハードウェアです。仮想化されたハードディスクやCPUを提供します。IaaSで提供するレイヤーはOSです。仮想化されたWindowsやLinuxなどの実行環境を提供します。PaaSで提供するレイヤーはミドルウェアです。GAEの用にクラウド固有のミドルウェアを提供する場合もあれば、EC2の様に既存のミドルウェアを提供する場合もあるし、Azureの様に両方を提供する場合もあります。SaaSの場合にはそれ単体でも完成されたサービスを提供します。
この二つの軸に明確な境界線はなく、様々な切り口でサービスを提供しているので「クラウドとはこういうもの」と言う概念をつかみにくいのです。
クラウドにすると何故コストを下げる事ができるのか？
それはハードウェアの稼働率を限界近くまで高める事ができるからです。一般的なサーバーではCPU負荷が一瞬100%になるかもしれませんが、普段はずっと低い状態が続きます。この間に他の処理を動かせば稼働率が高くなります。同じハードウェア価格で、より多くの作業をさせる事ができれば、単価を安くする事ができます。
従来、故障によって停止する確立を下げるには、フォールトレトランスに対応した効果はハードウェアを揃える以外にありませんでした。故障時には他の正常なハードウェアに処理を移動させる事で、安価なハードウェアでも故障により停止する確立を下げる事ができたのです。
ユーザーとしてクラウドを使うメリットは安いだけではありません。一般にIT投資は固定費なのです。それもハードウェアの減価償却がすむ５年後を見据えて、現在必要なスペックよりも遥かに高いスペックのハードウェアを揃えなければなりません。ところがクラウドなら、必要なときに簡単にスペックの高いハードウェアに置き換える事ができるのです。これはIT投資が固定費ではなく変動費になりうる事を意味しています。店舗が増えて売り上げが増えるとIT関連の費用が増えますが、運悪く店舗が減って売り上げが減るときにはIT関連の費用も減るのです。
私自身はクラウドの本命はHaaSやIaaSだと思っています。PaaSやSaaSの多くは提供業者独自の規格に乗っ取ったつくりが多いのです。この場合、独自にアプリケーションを開発しなくてはならないため初期コストが高くつきます。また、業者が撤退すると開発したアプリケーションを捨てるしかありません。その点でHaaSやIaaSは一般的なOS上で動作するため、将来事業者が撤退しても自前のハードウェア上で動かすなど、どうとでも対応を取れるのです。
ですが残念な事に、今のところHaaSやIaaSよりのサービスは出揃っていません。2010年の秋ごろに、各社サービススタートを予定しているようなので、それまで情報収集しながら楽しみに待つ事にしましょう。
地デジやフルセグ携帯が民放キー局を苦しめる・・・
日経BP：地デジやフルセグ携帯が民放キー局を苦しめる
地上放送事業者がB-CASカード発行時に手数料を払っていた事を初めて知ったのですが、どれだけ間抜けな状況ですか？TVが一人一台に近く普及している事や、CSBS放送の普及程度をみたら、100億/5年程度の支出は素人でも予想できそうです。年間20億を6つのキー局で負担したら、一社あたり3億円ですね。純利益が3億円減ると言うのは企業にとってかなりの痛手です。まして、地デジにむけた放送設備の変更や増設コストを負担し、近い将来には3DTVに向けたコスト負担を求められそうな状況なのですから。
そのうちに「弊社はスクランブルかけるの止めますから、B-CASカードの発行手数料を負担するの止めますね。」なんて会社も出てくるのではないでしょうか？とくに民法にとってはCMを見てもらう事が重要なのであって、コピープロテクトは重要ではないでしょうから。
もし高校野球の女子マネージャーがドラッカーの『マネジメント』を読んだら
日経BPで紹介されていたので思わず衝動買い。
色々と萌える本が出ているが、企業経営まで萌える本になっていたのかと、ちょっと呆れつつ届くのが楽しみだったり。相当に人気があるらしく、Amazonでは売り切れになってます。
Google App EngineでDjangoメモ
Google App EngineではDjangoというWEBフレームワークを使った開発を行えます・・・そのはずです。とりあえず情報収集中で実現できていないけど、そのメモなどを。
Google App EngineでDjangoを使うには、いくつかの方法があるらしい。
1.Google App Engine Helper for Djangoを使う。
2.Use Django on App Engineを使う。
3.Google App Engine SDK標準のDjangoを使う。
4.標準のDjangoをGoogle App Engineで動かすべく自分で設定する。
3.が理想的な気がするが、標準のGoogle App EngineだとDjangoのver 0.96が起動するらしい。ver1.0やver1.1を動作させるには設定を変更すればよいらしい。でもGoogle App Engineに標準でインストールされているDjangoは古くてセキュリティホール持ちらしい。したがって、DjangoまるごとGoogle App EngineにUpしないと実用には耐えないようだ。→
よって最新のDjangoを落としてきて、1.のGoogle App Engine Helper for Djangoを使うか、Use Django on App Engineのパッチを充てるのがもっとも現実的な解となるようだ。
LED電球に変えてみた
E17対応のLED電球で適当なものが見つからず長いあいだ探していたのだが、ようやく適当な電球に巡り合えました。株式会社STEのDECO LIGHTに付け替えましたよ。大手メーカーよりもはるかに安い1980円で買ってきました。60W相当を階段に設置してます。このぐらいの値段だと交換も現実的になるよね。
ちなみにE26口金用は来年三月の発売になってしまうらしい。