私的 de:code 2014 まとめ

はじめに

個人的な脳内Dumpなので、多くの人に役に立たないことをお断りしておきます。それにたぶん1週間後ぐらいたって読み返すと自分でもだいぶ恥ずかしいと思う。

ソフトウェア技術者として何をすべきか

• 主にAR-003 「パネルディスカッション：日本のトップアーキテクトが最新アーキテクチャを斬る！」より。
• Cloud First, Mobile Firstは別にMicrosoftのマーケットタームじゃない。
• Cloud Firstとは何か？
  別にコンシューマ向けサービスだけの話ではない。業務アプリケーションもCloud First、ハードウェアもCloud Firstに。
• ハードウェアのCloud Firstとは。
  • サーバーは単独(1台単位)で購入できない時代が5年後ぐらいにやってくる。バルク(ラック(数十台)、コンテナ(数百台～数千台)、データセンター(数万台))の単位でしか買えない時代が5年後にやってくる。ようは業務システムのためにサーバーなんて買えない。つまり、オンプレミスでのソフトウェアシステム開発なんてなくなる。
  • クライアント側の構成ももちろん変わる。
• Cloud Firstでのシステム開発
  • クラウドではアプリケーションにあわせてミドルを選択、作成する必要がある。(別にクラウドだからじゃない。)ミドルウェアがこうだから、それにあわせてアプリケーションを作るのでは無い。アプリケーションにあわせてミドルウェアを作成する。(ミドルウェア前提のフレームワーク利用開発の終焉とも。。)
  • ここだけオレが見ればいいという時代は終わった。問題を解決するためには全てのレイヤーを見て考えなければならない。アプリケーションのためにI/Oのミドルウェアに手を入れなければならないかもしれないし、コンテナのグレードやスケールの設定も考えなければならないし、仮想ネットワークの設計もしなければならない。等々。
  • クラウドもパターンだけでは足りない。それに現状のパターンは多すぎる。パターンだけではなく、それで足りない部分を埋め合わせるのがアーキテクトの仕事。
  • システムの中での変更される部分と変更されない部分の見極め。それを出来るだけ早い段階で見極め、アーキテクチャの設計に反映させる。
  • とりあえず作ってと言うなんちゃってアジャイルは通用しない。実際のコードがイメージ出来るまで設計する。とにかく設計する。
  • クラウドとは結局コストモデルの話。クラウドデータセンターの建設コストは下がっていっていて、結局コストの大半は運用コストでアリ、その大半は電力。消費電力を抑えるようなシステム設計が、クラウドサービスのユーザーにとっても、運営側にとってもメリットになる。
  • 消費電力を下げるためにハードウェアベンダーがやることはクロックを下げ、回路を単純化すること。つまり個別のハードウェア（CPU) の演算能力は下がる。しかし大抵の業務アプリケーションはCPUパワーに依存するので、同処理とデータを分散させるかが、クラウドのシステムでパフォーマンスを出していく上での仮題になる。
  • 現状のクラウドストレージは一貫性についてはなんの保証もない。それについて今までみんな口を閉ざしてきていたが、まずいことはみんな理解しているので、そうは行かなくなってきている。目指す先はRDBMSだが、必ずしも同じにはならない。やはり分散である以上トレードオフはある。
• Cloud Firstのシステム開発時代の技術者の姿
  • チャレンジを許して、それを正しく評価できるよお客さんを見つける。
  • 何でそういう設計をしたのか、現在設計を選択した理由を説明できるか。その為の知見や、技術検討、実際に手を動かすことが出来ているか。自分が納得できるまで追い込んでいるか。
  • 多くの知見を持っているといこととそれをどう使をちゃんと区別する。
  • 美しいものを作るという価値観。

Cloud Firstでの開発スタイル

• 主にTL-004 「クラウド時代の開発スタイル」より。
• 組合せの秒。単一のプラットフォーム(.NET Frameworkだけとか)の上で何かを一から作っていくのでは無く、用意された物の中で組み合わせていく。Cloudの中で用意された物の中からしか選択するしかない。何を選択肢、組み合わせるかが大変重要になる。それで全てが決まってしまう。
• 組合せのための道具としての、パッケージシステム、Git、テストツール、CI/CDツール。またそれらを統合したYEOMANのような環境構築ツール達の使用と習熟。
• ツールを使って、アプリケーションの動作に必要な最小限度のパッケージをダウンロードして環境を用意し、開発を行いデプロイする。インストール済の大きなクラスライブラリや、フレームワーク製品を前提として開発しないし、必要のないもので(クラスライブラリのバイナリとか)含めて大きな単位でクラウドにデプロイしない。node.jsやRoR、Pythonでの開発スタイル。.NET/ASP.NETでもvNextではRoslyn, kツールで、同じ開発スタイルになる。
• ソースコードリポジトリも、CI/CDのツールも、プロジェクト管理も、開発環境もクラウドに。どこからでも、どんな環境でも同様な開発スタイルが維持できる。
• 以上はコンシューマサービスの話に非ず、俺たちの今日から明日の話。
• とにかく始める。（オレてきにはスタイルを身につけるにはnode.jsの開発を勉強してみるのがお勧め。ああ、後、ちゃんとAzure WebSiteにデプロイするように。）
• アークウェイ森屋さん社長とかうらやましい、濡れちゃうとか思いつつ、それはそれで社員だといろいろと気が抜けなくて大変だと思う。

Windows Runtimeとはなにか

• 主にDE-010, DE-011 ようは荒井さんのセッション
• Windows RuntimeはCOMのリファクタリング。
  • オレ、前にCOMは死んだとか言ってすいませんでした。ほんとうにすいませんでした。
• 大事なことなのでもう一度書くと、Windows RuntimeはCOMのリファクタリング。
• ストアアプリとデスクトップやサービスとの連携は「通信」。それを踏まえた上での制約を考えて、何を使用するか選択する。
• 何かから漂うCOM+臭。

Azureについて。

• いや、もうなに、使うこと前提だから。という姿勢で各位臨んでいきたい。
• イケメンさとうなおきさんのファブリックコントローラの話は、必見。

教材

• あくまでも教材。あくまでもだ。
• 日本の法律は守ろう。絶対だぞ！
  とか言いつつ時々どこかのグアムにいるのは許してください。
• Dynabookタブレットの質感はすばらしいので、どうしても重さが気になる人とか、ペンが必要な人以外には8インチタブレットとしてはお勧め。
• 今のATOMプロセッサすげー。
• どこか良いsimを教えてください。(日本の法律は守ろう)

まとめ

ソフトウェア技術者として、今日と明日のために始めることが大事だと思います。始めましょう。node.jsをインストールすることでも、WebSiteを作ってmonacoを使ってみることでも、VS 2013でストアアプリを作って見ることでも、何でも良いと思います。

昨日や今日と同じ事が明日も続いていくと思っていることは間違いです。それだけは確かです。

変わる明日を生きて行くには自分も何かを初めて変わるしかありません。

de:codeはその為のマップを得るための一つの手段です。でも、これだけで全ての地図が得られるわけではないです。むしろ地図を作るためのヒントに過ぎないのかもしれません。このヒントから時分で地図を作っていくほかないのでしょう。

では、運営スタッフのみなさんとも、講演者のみなさんとも、参加者のみなさんとも、今年お会いできなかった人とも、来年もde:codeでお会いしましょう。

追記(2014/06/01 23:11)

一般公開されるセッションのビデオはこちらで公開されるはず。
de:code 2014 – channel 9