de:code 二日目。技術セッション漬け。

ちょっと朝は調べ物してて遅刻したんだけど、この日も内容の濃いセッションばっかりだった。

全体を通してのまとめ

大分長くなりましたので、結論を先に書くと本当に楽しい二日間でした。 Microsoftの今後の方向性として、モバイルファースト・クラウドファースト。オープンソース。オープンソースについてはTypeScript等で徐々に浸透してきていますが、悪い印象を変えるには10年ぐらいかかるかなぁと思います。 今まではMicrosoft主導でいろいろな技術が導入されましたが、今後はコミュニティ主導に変わりつつあります。私も一開発者として、応援していきたいと思います。

また、今回はいろんな人と出会えたのが本当によかったです。特に同じ地方から参加したGrapeCityの皆様には大変お世話になりました。ありがとうございました。

では各セッションの内容は次に続きます。

ジニアス流。プレゼンには楽しみを。

ジニアスセッション。途中から参加したけどわかりやすい。トピックがそれぞれ独立してるからか。初期の前提知識を学習する必要無いんだな。 #decode14— Masaki Yamamoto (@nnasaki) 2014, 5月 30

SQL Server 2014は大して興味はなかったんだけど、ジニアス平井さんのセッションは是非見た方がよいということで見たら本当に良かった。SQL ServerのインメモリDBで性能100倍とか基本的なポイントは押さえつつ、所々のデモアプリで文字を書いたり地球をミラーボールにしたり遊び心にあふれていた。

最後はアプリで1分間に何回タップできるか競争。AzureとSQL Serverの構成で秒間数万リクエストまで耐えられるそうな。

自分もこんなふうに楽しませるセッションが出来ると良いなぁと感じた。

Microsoft Azure や IaaSの自動化はコンテキストをそろえる

次に、Azure IaaS 自動構成ツール Chef, Puppet, PowerShell DSC。自動化は大変人気があって、満席でした。みんな苦労しているのかな。

仮想マシン自体を作る（外側）はAzure Automation を使用する。作った後（内側）はChef, Puppet, PowerShell DSCを使う。混同しやすいので注意 #decode14 #RoomD— Masaki Yamamoto (@nnasaki) 2014, 5月 30

ということでコンテキストをまず合わせることが重要。

若干駆け足で範囲が広かったので、細部まではあまり理解できなかったけど概要はなんとなくつかめた感じ。Chefはちょろちょろ使ってるけど、ChefServerは立ち上げず、knife soloを使っているのであまりピンと来なかったところもある。

Azure 仮想マシンでChefを試す場合は、Extensionが用意されている。LinuxのExtensionはGUIが無いので、Powershell等を使用して追加する。 #decode14 #RoomD— Masaki Yamamoto (@nnasaki) 2014, 5月 30

Chef で IIS をインストールするときは、PowerShellのスクリプトを実行するというとってもクソなことをしている。 #decode14 #RoomD— Masaki Yamamoto (@nnasaki) 2014, 5月 30

Puppet か Chef のどちらかというと、Puppet 推し。独自DSLとか回りくどくてめんどくさくて心折れるけど、乗り越えると楽しい世界がある。 #decode14 #RoomD— Masaki Yamamoto (@nnasaki) 2014, 5月 30

knife-azure で WRM を使用して、仮想マシンを作成することも可能。こっちのほうを使いたいかな。 #decode14 #RoomD— Masaki Yamamoto (@nnasaki) 2014, 5月 30

PowerShell DSC for Linux でLinuxを管理することも可能。けれども CTP なので足りない機能がたくさんある。 #decode14 #RoomD— Masaki Yamamoto (@nnasaki) 2014, 5月 30

ChefからWindowsのサービスをいじると、結局PowerShellでゴリゴリのスクリプトを書かなくてはいけないので、うーんって感じだった。Puppetがお勧めと言われても独自DSLが嫌でChefを好んでつかっているので、こちらもうーんって感じだった。

AskTheSpeakerでいろいろ聞きたかったんだけど、次のランチセッションが満員になりそうだったので、聞けずじまいになってしまった。

PowerShell DSC をつかった Infrastructure as Code

Chefから離れて、ランチセッションはPowerShell DSCのお話。PowerShell DSCについてはPowerShell DSCで始めるWindowsインフラストラクチャ自動化の基本を参照。

PowerShell DSC すごいよかった。内容はすごい高度で詰め込まれているのに、とてもゆっくりに感じるのはスピーカーの実力なんだなぁと思った。 #decode14 #ROOME— Masaki Yamamoto (@nnasaki) 2014, 5月 30

スピーカーの @guitarrapc_tech さんの発表がとてもわかりやすかった。さすがグラニさんだなぁと思いました。

PowerShell DSCも結局独自DSLになるんだけど、Puppetと異なり自前で拡張を書かなくて良いので、準備は楽。PowerShell DSCのIIS Installのサンプルコードはこんな感じ。(PowerShell DSCで始めるWindowsインフラストラクチャ自動化の基本より引用)

Configuration IISInstall
{
    Node localhost
    {
        WindowsFeature IIS
        {
            Ensure               = "Present"
            Name                 = "Web-Server"
            IncludeAllSubFeature = $true
        }  
    }
}

良いことをたくさんいってたので、箇条書きで。

  • クラウドでインフラがソフトウェアになったんだら、構成もソフトウェアに。コードで書けばいいじゃないか。
  • PowerShell DSCから Azure Resource Manager, Azure Automation等を呼び出す。コードはc#でもPowerShellでも良い。
  • PowerShell DSC の守備範囲はインスタンスを起動してから、アプリケーションデプロイ前まで。
  • PowerShell v5 にて OneGet でソフトウェアのインストールが出来るようになる。
  • 自動化が楽しくなるとついついコードを書きすぎるが、目的は自動化じゃなくてサービスを成功させることなので、バランスをとること。
  • PowerShell4.0が含まれるWMF4.0が必要。
  • WMI, MOF, WSMan, HTTPを使っている。
  • .mofファイルを使って、CIM経由で構成する仕組み。特定言語に依存していない。Chef, PuppetもDSCを利用可能。
  • PushとPullを比べると、Pullのほうが楽。Resourceをサーバーに置くだけで済むので。
  • ノードがPushモードになっていると、Pullを受け付けないので、Pullに設定する必要がある。
  • 構成管理をコードで書いたなら、バージョン管理すればいいじゃないか。

PowerShell DSCがChefと競合するので、WindowsはChefから離れた方が良いかなぁという気がする。

TypeScriptはVisualStudioとの統合されており、ブラウザーもデバッグに対応している

午後一のセッションは @chack411 さんのTypeScript詳説を聞いた。

ブラウザはTypeScriptを実行できない。なので、TypeScriptはコンパイルされるとJavaScriptが自動生成されて、ブラウザーはJavaScriptとして実行する。しかし、ブラウザーの開発者ツールでJavaScriptをデバッグしようとすると、mapファイルを読み込んで、TypeScriptのソースコードでデバッグできる。

この仕組みはChromeとかでjquery.js.minとかと同じで、TypeScriptに各ブラウザーが対応しているところをみると、MicrosoftのOSS戦略も徐々に浸透しつつあるのかなぁと感じた。

ECMAScript6 で使える、アロー演算子やGetter/Setter はコンパイルオプションの指定がいるのと、実行環境もECMAScript6に対応している必要がある。 #decode14 #RoomB— Masaki Yamamoto (@nnasaki) 2014, 5月 30

この辺は注意が必要と感じました。ECMAScript6が早く使えるようになるといいなぁ。

古いIEの対応だけの知識ではない。Fiddlerの実践的な使い方は現場のWeb開発には必須の知識

続いては物江さんのセッションで、IEの互換性に関する話だけと思いきや、Fiddlerの使い方も紹介されており、これは他の人にも是非教えてあげたいなぁと思いました。

IE11のエンタープライズモードは、開発者向けツールでIE8 を選ぶのとは異なり、cssの解釈もIE8同等になる。 #decode14— Masaki Yamamoto (@nnasaki) 2014, 5月 30

ちなみにエンタープライズモードはIE11のサポート期間まで使えるので、IE8向けのサイトは2024年近く（おぼろげな記憶なので不正確）まで使えるとのことです。やったね（白目

非互換性はCompatInspector.jsを使う。デバッグすれば非互換性箇所もわかる。 #decode14— Masaki Yamamoto (@nnasaki) 2014, 5月 30

Fiddlerと開発者ツールを組み合わせて使うとサーバーのcssやjsを書き換える必要なく、ローカルのファイルを読み込ませることができる。 #decode14 #RoomF— Masaki Yamamoto (@nnasaki) 2014, 5月 30

CompatInspector.js を全てのページに読み込ませるのは大変。これもFiddlerを使用すればサーバーをいじることなく読み込ませることができる。スニペットのリンクが切れてたのどうするんだろw #decode14 #RoomF— Masaki Yamamoto (@nnasaki) 2014, 5月 30

Fiddlerは本当に便利です。SSL通信の中身も見られますし。スニペットのリンク切れはおそらく後日フォローがあるはずです。

COMは死なない。asyn/await は万能ではない。

Windows Runtime DeepDiveを途中から聞いた。ストアアプリは.NET, JavaScript, C++で書いて、Windows Runtime を共通的に呼び出すんだけど、その呼び出し方の仕組みはそれぞれ違う。

Windows RuntimeはCOMをリファクタリングしたもの。捨てて無かったのねー。 #decode14 #RoomF— Masaki Yamamoto (@nnasaki) 2014, 5月 30

Async/Awaitは便利だけど、Dispacherを使ったほうが良い時がある。内部ではDispatcher を使ってるため #ROOMF— Masaki Yamamoto (@nnasaki) 2014, 5月 30

Microsoftの技術はロングラン！でも、コアな部分ってそんなそんな変えられないですよね。パッチの積み重ねだし。*nixのカーネルもしかり。

Azureを支える技術。初期の頃からパフォーマンスは飛躍的に向上。

最後はいろいろ迷ったんですが、Azureのセッションを今までまったくうけてなかったので、佐藤 直生 さんの「Microsoft Azure インターナル ～ ファブリック コントローラーを理解して、正しい設計を!」を聞いてみました。さすがにレベル400(専門)ということでほとんど理解できなかったｗ

ハードウェアのロードバランサーがあまりよろしくなかったので、ソフトウェアのロードバランサー(SLB)を自社開発して使っている。ほー。 #decode14 #RoomC— Masaki Yamamoto (@nnasaki) 2014, 5月 30

このように要所要所でMicrosoftの独自テクノロジーが導入されており、ネットワーク構成もメッシュ化に構成を変更することで当初と比べると飛躍的に向上したとのこと。

私は Microsoft Azure モバイルサービス の記事をよく書いていますが、内部的にはPaaSのCloud Servicesが使われている。これはWebSiteも同様。モバイルサービスが実際どのような仕組みかは Ask The Speakerでも伺いましたが、モバイルサービスは結構ブラックボックス化されているとのことで、Kuduを使用してゴニョゴニョしていくとわかるのかなぁという感じでした。

見たかったけど見れなかったセッションたくさん。。。

どれも興味深いセッションばかりで泣く泣く見れなかったセッションがあった。例えば「パワフル モバイル アプリ開発 ～ 最新 Azure Mobile Services をフル活用しよう！」や「Azure Mobile Services & Notification Hubs で Windows、iOS、Android 等、すべてのデバイスにプッシュ通知を送る」Azure関連がほとんど見られなかった。 後日動画が公開されるのと、フォローアップ記事が公開されているので、おさらいしておきたい。