確実に売り切れる分しか作らない。欠品による機会ロスを容認し、賞味期限切れなどによる廃棄ロスを最小にすることで、リスクを最小化する。これによってた原価率が高く薄利であっても確実に利益を上げ、継続的に商売を行うことが出来る。
もちろん最終損益をプラスにするだけの最小販売数を売り切れる立地とか、弁当の原価を低く抑えるとか、固定費を抑えることは必要でしょう。でも、もっとも重要なのは売切れる量しかつくらないことで、赤字になるリスクを抑えることだと思う。
一般的な飲食業の原価率は30～40%程度だそうだ。飲食業は売り上げ変動リスクが大きく、売り上げが減少すると、食品の賞味期限切れにより廃棄ロスが急増し、あっという間に赤字になると言うリスクを負っている。そのためどうしても原価率を上げることが出来ないのだ。そこで商売の原則に反して売り切れを認めることで、高い原価率で商売できるようにしたところが凄いのだ。
あるリスクを容認することで、あるリスクを押さえ、新しいソリューションを生み出す辺り、セキュリティの考え方にも近いものを感じて感動した。
＃某経済NEWSで「たくさん一度に作るから安く出来るんですよ」などという
＃経営者の声を紹介していたけど、んなわけねぇだろ。
Google App EngineでCookieを使う
Google App EngineでCookieを使う場合には、Pythonの提供するCookie関連クラスを使うことは出来ない。変わりに「self.request.cookies」と「self.response.headers.add_header」を使うことになる。
Cookieの書き込みには「self.response.headers.add_header」を使用する。以下のようにheadersコレクションを直接に追加する以外に無いようだ。
myCookie = 'name=%s; expires=Tue, 1-Jan-2030 00:00:00 GMT;' % myName
self.response.headers.add_header('Set-Cookie', myCookie )
Cookieの読み込みには「self.request.cookies」を使用することが出来る。以下のようなコードで読み出すことが出来る。
myName = self.request.cookies.get('name', '')
Failed to create database ‘DevelopmentStorageDb20090919’
Windows Azureのアプリケーションをデバッグ実行しようとすると次のメッセージが表示される。
「Windows Azure Tools: Failed to initialize the Development Storage service. Unable to start Development Storage. Failed to start Development Storage: the SQL Server instance ‘localhostSQLExpress’ could not be found. Please configure the SQL Server instance for Development Storage using the ‘DSInit’ utility in the Windows Azure SDK.」
ローカルにインストーすしているSQLServerの接続設定で、リモート接続やWindows認証を無効にしている場合には、これを有効にしてからやり直す必要があります。また使用するSQL ServerがSQLEXPRESS以外の名称の場合にはC:\Program Files\Windows Azure SDK1.1\bin\devstore\DSInit.exeを実行して手動でAzure Data Storageの初期化をおこなう必要があります。
ですが手順に従って「DSInit.exe /SQLInstance:サービス名」としても以下のメッセージが表示される場合があります。
「Failed to create database ‘DevelopmentStorageDb20090919’ : SQL Server への接続を確立しているときにネットワーク関連またはインスタンス固有のエラーが発生しました。サーバーが見つからないかアクセスできません。インスタンス名が正しいこと、および SQL Server がリモート接続を許可するように構成されていることを確認してください。 」
この場合には「DSInit.exe /SQLInstance:」とSQLInstanceオプションつきでサービス名を指定せずに実行してください。これでAzure Data Storageの初期化を行える場合があります。
どうもSQLServerのインストール後に、OSのコンピューター名などを変更している環境で、上記の問題が発生するようです。
参考：Visual Studio 2010 Problem: Windows Azure Tools: Failed to initialize the Development Storage service.
Google App Engine 習作、オセロゲーム
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を見てもらう事が重要なのであって、コピープロテクトは重要ではないでしょうから。