Windows Phone SDK 7.1.1がリリースされました。(以前はCTPだった)
大きな変更点としては256 MB版のWindows Phoneデバイスへの対応、Windows 8 CP上での動作OKの2点です。
個人的にはWin8CP上で動作するのが嬉しいですね。(もちろんまだサポート対象外ですけど)
Windows Phone SDK 7.1.1がリリースされました。(以前はCTPだった)
大きな変更点としては256 MB版のWindows Phoneデバイスへの対応、Windows 8 CP上での動作OKの2点です。
個人的にはWin8CP上で動作するのが嬉しいですね。(もちろんまだサポート対象外ですけど)
わぁいSamsung Series 7 Slate あかりSamsung Series 7 Slate大好き!
というわけで、待ちに待ったWindows 8 CPに対応した加速度センサードライバとタッチスクリーンのファームウェアアップデードがリリースされました。
Samsungのページ下部にあるTouch Screen Sendor Firmware Configuration Update ToolとST Micro Rotation Sencor Drvier for Windows 8 Customer Previewがそれです。
さっそくインストールしてみました!
この通り不明なドライバが無くなりました!素晴らしい。これで縦に持ち帰れば画面が回転するはず!
ばっちりですね。縦画面に対応してるMetro Style Appならちゃんと縦になります。標準のReaderでPDF読むときも縦もちすると見やすくてイイデスネ!
あと画面の回転ロックボタンがあるのですが、押すたびにOn/Offの状態が画面に表示されます。
これでかなり快適になりました。
ちなみにタッチスクリーンのファームウェアはタッチ&ホールドがしやすくなった気がします。うまく計りようがないので感覚ですけど。。。
Windows Azureのセキュリティが心配で心配で夜も眠れない人に朗報。 クライアントPC等で企業向けに提供されているMicrosoft Endpoint Protection(以下MEP)がWindows Azureでも利用できるようになりました。(※2012年3月19日現在ではCTP)
「緊急」のセキュリティ更新プログラムが公開されてました。
みなさんご推察の通り、RDPを有効にしたWindows Azureのインスタンスも例外ではないと思います。
というわけで、このセキュリティ更新プログラムが適用されたGuestOS(1.17/2.9)がリリースされています。
※手動での適用はイメージが伝播するまでしばらく待ちましょう。(自動更新の場合は適用が開始される場合があるかと)
※ホスト側のリブートもありそうですね。
2月29日に発生したWindows Azureサービス中断ですが、Microsoftから公式として以下のRCA(根本原因分析)が出ていました。
詳細はリンク元を見て頂くとして、やはり発端はうるう日(2月29日)に証明書を発行できなかったのが原因のようですね。有効期限1年の証明書発行に問題があると。(うるう日なので)
これだけならせいぜい新規のインスタンス起動が出来ない程度じゃ?と思ったんですがFabricController側への障害通知が繰り返し行き、本来ソフトウェアの問題のはずがハードウェアの問題と捉えられてどんどん影響範囲が広がって行ったみたいですね。
時系列でも解説されていますが、なるほどという感じです。共用型で自動化されたPaaSならではな印象もうけますが、、、
バグそのものは早期に修正されたみたいですが、更新の過程で2次停止も起こったあたりも興味深いです。それだけPaaSのインフラを管理するのは複雑で大変なのかというのがわかりますね。
ただ今後の対策なども明確になっているようですので、再発の防止とより良いサービスの提供を目指してもらえるといいかな~。
サポートについてはパンクっぽい様子だったようで、利用者から見ても改善の余地はあるかと思ってます。(スパイクに対応させるのは難しいと思いますけどね…さばき方の問題かな)
技術者目線だとなるほど、ですが利用者目線だともう少し違う説明をしないといけないんだろうなぁ。もうひと踏ん張りですね。
以下余談。
問題の発生当初は実はグロサミでWelcome Receptionまっただ中だったわけです。でそのパーティーのさなか某はうはう氏がノートPC広げてAzureの障害が~と日本の仕事の対応してたんですね。で症状を聞くにその場にいた抱き枕氏と「これって閏年(うるう日)だからじゃないのー?日本はもう29日だよね。こっち(PST)はまだ28日だし大事になってないし。つまり閏年なバグじゃね?」「まさかー。ねぇ」とか冗談で言ってたわけですがドンぴしゃとは…
で、その後自分が関わってるサービスもぐるぐる祭りが続いたりそれなりに大変だったわけで(おそらく2次停止のほうに巻き込まれた感じ)。まぁ大変といってもインフラの問題なので出来ることはReImageやら再デプロイ程度でぐるぐる祭りを眺めてる程度なんですが。
さて日本人的に気になるのは世間体ですかね。SLA99.95%に何を求めてるかわかりませんがやたら要求だけは厳しい日本の企業にはどう映るかな、という心配はあります。1秒でも止まったらアウトなミッションクリティカルなシステムだとそもそも99.95%で保証なしなんて論外でしょうし、そうじゃないなら、自社運用でも何でも好きなのコストかけてがんばって運用すればいいじゃないですかとか思いますが。。このあたり思考停止してベンダーになすりつけてるところ多い気がするので心配ですね。そんなことなければいいんですが。
サービスをうまく使うには利用者側も勉強しましょう。これは大変ですけどその見返りも当然あるわけで。そこをないがしろにしてたらうまく行かないと思いますよと昨今のSI業界にも通じるような思いがあったりなかったり。(とはいえどっちの言い分もある程度わかるのでなんともですけどね。)
どんどん本筋とそれてしまった感がありますが、今後の展開次第では本筋と違う話ばっかりになる可能性もあるのでそんなのは嫌だなというのだけわかって頂けると嬉しいです。
たぶん後半は言葉足らずで的外れな部分もあるでしょうけど、まいっか。
2012年3月13日追記
日本語公式サイトで翻訳された内容が公開されたので追記。公式発表は大事ですよね。ちゃんと根本原因分析ができて公開できるのは凄いことだと思いますよ…
というわけで唐突ですが価格改定があったようです。
Announcing Reduced Pricing on Windows Azure Storage and Compute
XSサイズはSサイズと比較すると1/6になりました。Sインスタンス1台分で6台分のXSが動かせます。多少スペック低くても台数欲しい時とか上手く活用すればかなりコスト削減になると思います。
SQL Azureの値引きも先月発表されましたし、現実的な使いやすいプランになるのはいいことですね。
参考:
というわけで2月28日~3月2日に米国で開催されたMicrosoft 2012 MVP Global Summitに参加してきました。
一応思い出なんぞをつらつらと書いておこうと思います。(内容はNDAなので書けません)
今回は初参加だったのですが、時間に追われるのが嫌いなのと人見知りで団体行動が苦手なのでツアーはやめてちょっと期間を延長して行ってきました。
Worker Role上の.NET Frameworkの動作CLRバージョンに関した質問がMSDNフォーラムにあがってたので見てみました。
とりあえず適当にですね、Worker Roleを作ります。
public override void Run()
{
while (true)
{
Thread.Sleep(10000);
string clrVersionRuntime = System.Runtime.InteropServices.RuntimeEnvironment.GetSystemVersion();
System.Diagnostics.Trace.WriteLine("CLRVersion:\t" + clrVersionRuntime);
}
}
寂しいので適当にCLRバージョンを吐き出すようにしました。
さてこいつを既定のママ(.NET Framework 4設定)で動作させてみます。
エミュレータ上
Windows Azure上
v4.0.30319 ですね。
では.NET Framework 3.5にしてみましょう。
エミュレータ上
Windows Azure上
※DebugViewでなぜかキャプチャできなかったのでProcess Explorerで。(最初からこうすれば(ry
v2.0.50727 でした。
想定通りと言えば想定通りです。
2月16日/17日に目黒雅叙園で行われたDevelopers Summit 2012に参加しました。
いろいろ縁がありましてなんとスピーカーでした。
「17-E-5 震災とHackとクラウドと」というタイトルで0311直後~1週間ぐらいに行ったHackについて話しました。
セッションそのものは冨田さん、菅さん、おいらの3人でそれぞれ分担という感じで。
またセッションにあたり熱い思いなどは冨田さんがまとめてるのでそちらを見て頂いたほうがいいかと思います。
Developers Summit 2012! / あれとアレは混ぜるな危険
こんな状況を乗り越えていくために、Developers Summitという場を通じて、そろそろ技術的にどんなことをしたかという事を共有しないと、次につながらないのではないかという思いを個人的に持っています。今回のセッションでは完全に技術の話にフォーカスして、次の危機に対してディベロッパーが立ち向かっていくためのヒントを共有したいと考えが根底にはあります。
Googleの及川さんも言っていましたが、技術者は無力ではないこと、技術者なりに出来ることがあるということを証明できたのが東日本大震災での成果の一つだと考えています。(実際には証明の途上にありますが)
その当事者として活動していただいた方が、震災直後にどんなことをしていたのかを共有することで、多くの方に「次は自分もできる」という気持ちを共有できれば本セッションは成功だと考えています。
冨田さんの資料はこちら
菅さんの資料はこちら
というわけでして、おいらのほうもですねキャッシュサイトの構築といったHackをやりましたのでそのあたりを喋らさせて頂きました。
おいらの資料はこちら。
中身見て頂いたらわかるかと思いますが、心情的なところはいったん置いておいて、技術面のみにフォーカスしました。技術面にフォーカスといいながらそんなに深い話じゃないんですが…
だって単にRevProxy置いただけですからね。平時ならそもそもRevProxyで対応とか第三者でやらないし、やるにしてももっといいやり方とか仕組みとか構成ってものがあるかと思います。
でまぁセッションでも口下手ながら言いましたが(文面も下手ですが)、内容じゃなくてその時に必要だったから、そのタイミングだったから活きたHackになったんじゃないかな、ということ。
※実際にはキャッシュサイトは周知されて使われないと意味がないので実測としてどうだったのかはあまり把握できてませんが…
補足すると、(今回のHackのターゲットだと)この手のシステムって、直近で必要で1~2週間もたてばたぶん破棄されるシステムなんだろうなと言うのは分かってて、やっぱり労力をかけずに泥臭くてもいいから作り上げて世に出すのが必要だったんだなと思います。そういう意味ではRevProxyにするとかどうやって作るかとかは気を使いました。純粋なTechとはちょっと違う気もしますがまぁそういう視点も必要だったかなと思います。
で短期で破棄される+すぐに必要というサーバーを作るのにクラウドコンピューティングってほんとあってよかったです。触ってたのがWindows AzureだったのでAzure使ってますが、これ2年前とかならそもそもこういう対応も出来なかったし、自分は何もできなかったと思うんですよ。
あと競争じゃないけど本当にささっと出す必要があったんですよね。というかそう思ってました。なんでって誰かが暫定の解決策を出せればほかの人が同じようなことする手間をかけずに、違うことにリソースさけるじゃないですか。同じことするなんてもったいない!でも実際同じような話あったと思いますたぶん。なんか当時はTwitterやメール追うのも大変だったので記憶があいまいだけど。ただ、少なくともJAZ内での2度手間3度手間はなくせたかな~。
で、いろんな要因や人との縁(JAZの人たちや冨田さん、翔泳社の岩切さん達)が重なり、デブサミのスピーカーという場所に出たわけですが、ほんとうに境目なんてないんです。ちょっとしたことをやって手をあげたらなんかマッチしたぐらいの感覚。本当にその程度の差なんじゃないかな。だから冨田さんも言ってたように、今からでも遅くないしみんなもできるよ。だってゼロから何かを創造できるDeveloperなんだぜおれたちw
あんなしょぼいRevProxyじゃなくてもっとCoolな仕組み作ったぜ!とかいう話が今後いっぱいでてくるといいな~。それでこそ、このセッションをした甲斐があるってもんです。
なんかフォローのようななってないようなPostですが…そんな感じです!
たんたかさんが PHPでRoleEnvironmentを使う というへんたい素晴らしいPostをしてたのでもっと手軽にできないかなーと。
もともとWindows Azure SDK 1.5以上でサービス定義ファイルにxPathを使用してRoleEnvironmentの値を環境変数にセットできるのですが、これがちょっと曲者。
というのもサービス定義ファイルのEnvironment要素に指定した環境変数はプロセス環境変数で、つまりRoleEntryPointがあるプロセスでしか見れません。
これはどういうことかというと、別プロセスとして動作するFull IISや、たとえばPHPなどからはせっかくの値が見れないってことですね。
これは不便極まりない!ということで冒頭のたんたかさんのBlogにあるようなHackが必要なわけですが、もっとお手軽にできるんじゃない?ということで試してみました。
まずサンプルということで、ASP.NET MVCで環境変数を出力するようなアプリを作っておきます。
<h1>Machine</h1>
<table>
@foreach (System.Collections.DictionaryEntry env in Environment.GetEnvironmentVariables(EnvironmentVariableTarget.Machine)) {
<tr>
<td>@env.Key</td>
<td>@env.Value.ToString()</td>
</tr>
}
</table>
</p>
<p>
<h1>Process</h1>
<table>
@foreach (System.Collections.DictionaryEntry env in Environment.GetEnvironmentVariables(EnvironmentVariableTarget.Process)) {
<tr>
<td>@env.Key</td>
<td>@env.Value.ToString()</td>
</tr>
}
</table>
</p>
<p>
<h1>User</h1>
<table>
@foreach (System.Collections.DictionaryEntry env in Environment.GetEnvironmentVariables(EnvironmentVariableTarget.User)) {
<tr>
<td>@env.Key</td>
<td>@env.Value.ToString()</td>
</tr>
}
</table>
</p>
適当にViewにはっておきましょう。
さてやること1つ目。サービス定義ファイルに環境変数を追加します。
<ServiceDefinition name="WindowsAzureProject3" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
<WebRole name="MvcWebRole1" vmsize="ExtraSmall">
<Sites>
<Site name="Web">
<Bindings>
<Binding name="Endpoint1" endpointName="Endpoint1" />
</Bindings>
</Site>
</Sites>
<Endpoints>
<InputEndpoint name="Endpoint1" protocol="http" port="80" />
</Endpoints>
<Runtime>
<Environment>
<Variable name="EnvironmentTest1">
<RoleInstanceValue xpath="/RoleEnvironment/CurrentInstance/Endpoints/Endpoint[@name='Endpoint1']/@address" />
</Variable>
<Variable name="EnvironmentTest2" value="EnvironmentTest2Value" />
</Environment>
</Runtime>
<Startup>
<Task commandLine="env.bat" executionContext="elevated" taskType="simple">
<Environment>
<Variable name="ENVIRONMENT3">
<RoleInstanceValue xpath="/RoleEnvironment/CurrentInstance/Endpoints/Endpoint[@name='Endpoint1']/@address" />
</Variable>
</Environment>
</Task>
</Startup>
</WebRole>
</ServiceDefinition>
上記のEnvrionmentTest1、EnvrionmentTest2、Envrionment3はそれぞれテスト用です。後で見たらわかりますが、これらの値はASP.NETなアプリ(別プロセス)からは参照できません。
で、ここでのポイントはStartup要素以下のEnvrionmentですね。ここでスタートアップタスクに環境変数を渡してるのですがこのままだとStartupTaskのプロセスが終わったら消えてしまいます。
ということで、StartupTask内でプロセス環境変数をシステム環境変数につけかえましょう。
@echo off setx ENVIRONMENT4 %ENVIRONMENT3% /M
Setxコマンドに/M引数つけてシステム環境変数に設定してるだけです。簡単!
注意点はシステム環境変数に設定するのでStartupTaskを管理者権限(Elevated)で動作させてるのと、システム環境変数を参照するには設定終わった後にプロセスが起動しないといけないのでtaskTypeをsimpleにして他のプロセスより先に実行されるようにしてるところでしょうか。
もし他にもStartupTaskがあるのであれば、優先順位を付けたりするといいかもです。
さて実際にデプロイして確かめてみましょう。
他の環境変数は取れてませんが、StartupTaskで付け替えたシステム環境変数はバッチリ取れてますね。
これで非.NETアプリ等でもシステム環境変数さえ触れればRoleEnvrionmentの値を触ることができますね!