【参加】MVP Community Camp 2015

いつも思いますが、MVPの方の話をお聞きすると向上心がわいてきます。
これからもMicrosoft関連の学習をして将来はMVPを目指したいと思う今日この頃です。

---

以下、メモ

MVP Community Camp 2015

http://mvp.microsoft.com/ja-jp/comcamp.aspx


■改めてLightSwitchでWeb開発&Office 365開発
・ライセンス認証はADとフォームによるID・パスワード認証の2種類がある。
おすすめはAzure ADを利用した認証。管理が容易。

■Windows Server Technical Preview Hyper-Vの新機能
・SLAT必須など古いコンピュータでは稼働できない
・Windows server 2012 R2のVMをTechnical PreviewへはVMのバージョンせずに移動できる。VMのバージョンアップをしなければそのまま戻すこともできる。もちろん、同居も可能。
VMのバージョンアップをするとパフォーマンスが向上する。
・プロダクションチェックポイント
Disk上に完全な整合性を保ったまま、バックアップからもどしたようにリストアできる。
・NICを動的に追加、削除ができるようになった。
また、仮想MACアドレスの指定も可能になった。
・メモリのホットアドの追加、削減が可能になった。
・OpenGL4.4、OpenCL1.1、DirectX11をサポート。


■PaaS指向で クラウドデザインパターンを実装！その本音と建前
・PaaSはどこまで自分で面倒を見るのかものによって違うので注意。
・クラウドを前提して考えるのではなく業務とアプリケーションの状態によって、構築方法を選ばないといけない。
・コスト下げた分、リスクが上昇し、リスクが問題になったときのコストが増えている。
・保守を行っていくとシステムは複雑化する。システムは意図的に作り替えるという覚悟が必要。
・メインフレームの完全性からクラウドの壊れてもほっとく(復元性がある)時代に変化している。
・スケールアウトが可能なインフラを作ったものの、運用体制を変えなかったため、運用コストが高くなった。
メンテナンス性の高いプログラムはハイスキルが必要だがメンバーが育っていない。
・非機能要件が難しくなってきた。ページによって違ったり、システムによって違ったりする。
非同期のアプリケーション、自動化された運用性、システムを切り離せるようにする。
・CQRSパターン＝参照は早くして、更新は非同期というデザインパターン
デザインパターンを決めるのはどのタイミングで誰が決めるのか？
→ないし、いない。
さらにメンテナンス性が高く、オフショアを利用しなくてはいけない。
・Azureは壊れる前に予防保守をしている。
・クラウドデザインパターンを考える時間が非常に長くなっているため、業務ロジックを使う時間はほぼ無くなった。
・キャッシュ化したのに早くならない。
性能がでない原因を追究しないとだめ。
・データをユーザーがどう使う、どれくらい使うパターンによってキャッシュのパターンが違う。
・コマンドキューで分散処理化してもバッチ処理が遅くなった。
・PaaS Dでリトライパターンを導入。
ライブラリが未対応だった・・・テストしないと気が付かないけど、テスト難しい。
・クラウド時代は制約が大きくなった。そのため、設計者・プログラマにハイスキルが必要になった。


■インフラアーキテクチャ実践（仮題) Grasysの紹介
・インフラエンジニアの仕事は以下に分解できる。
bootstrap
provisioning
configration
clustreing
monitoring
operation
deployment
・必要な作業を分類して、作るツールを体系化。
・bootstrapに入れるのがよい。
・要件定義のことを考えないと運用コストが上がってしまう。
・基本はオーケストレーションで対応。
・google cloud platform
DNSを返さずにロードなランサーがregionへ分散可能
nvmeというインターフェースで75万IOPS
同じリュージョン内のネットワークは6Gbpsくらい
各国に入ってから独自網に入るみたいで安定している。

■software architecture とは
・ソフトウェア開発は人が無策で挑むには難しすぎる。また、機能特性と品質特性が必要。
(人間工学品質特性)
・アーキテクチャは非機能要件に強く影響している。
同じ機能を満たしていても別の構造になることがあり、違う品質特性になる。
・アーキテクチャ設計のゴールがどこかわからない。
また、行き方がわからない。(総合的技術力でカバーできる場合がある)
・品質はものによって重みづけが違い、管理していく。
さらに関係者によって重みづけが違う。
・品質特性を左右するもの
エンドユーザーの要求
ビジネス・組織の要求
開発サイドのステークフォルダ
ステークフォルダの力関係
・すべてのステークフォルダごとに異なる要求と重みづけの品質特性のバランスを取り、高い技術力を持ってゴールを定め、設計のゴールに向けて進めることのできる人。
・コードからviewとviewポイントを導き出すのは無理
・コードを書くために必要な設計書がアーキテクチャ記述(書かされた設計書は違う)
・アーキテクチャ事態を表した文書はない。アーキテクチャ記述の集合がアーキテクチャとして考える。
・品質特性・プライオリティの設計
・それに基づいた関心毎の分離の繰り返し
・プログラミング言語・パラダイムへの理解と知識
・各実装に対する理解と知識とインデックス
・思考停止ではなく、一人ひとりの要求を理解する必要がある。
・何かの品質特性が0ではそもそもそのシステムの価値がなくなることが多い。
・さまざまな手段・技術のメリット、デメリットを整理し、品質特性に合わせる。


■ブラウザとセキュリティ 安全なWEBのために
http://www.slideshare.net/hebikuzure/browser-andsecurity2015