｢QCon Tokyo 2016｣へ行った その2
- タイトル: QCon Tokyo 2016
- 日時: 2016年10月24日（月）9:45～19:00
- 会場: ベルサール新宿グランド コンファレンスセンター
- URL: http://www.qcontokyo.com/index.html
先日参加したのでまとめを書きます。個人的に注目だったorまとめられるものだけ書いています。そして、登壇者の皆様に感謝。
その1はこちら
B-2 DDDとマイクロサービスの現実と可能性
現場からの実践報告 上坂 貴志
資料: TBD
- オブジェクト指向をエンタープライズに展開がDDD
- ユーザーとシステム開発側の双方が持つ暗黙知が悪さする
- ユーザーの言葉を一緒に定義しなくてはいけない
- 言葉は境界が違えば定義が変わる
- モデル駆動が重要
- モデリング→実装イメージができてなかった
- 貧血ドメインになった
- ER図がダメ
- 最大のうまくいかない理由は恐らく不安
- ｢オブジェクト指向を勉強したけど役に立たない｣という感覚
- オブジェクト指向ができる = モデリングができるではない
- モデリング = ER図 ではない
- サンプルを用意。過去とのマッピングが重要。
- モデルと実装が連動すればとりあえずはOK
DDD&モデリング導入のコツ 増田 亨
資料: http://www.slideshare.net/masuda220/ss-67660572
- 利用者の満足するものではなく、技術者が満足していた
- 習得したときはスピードが上がる
- 会話が重要
- 2つのブレークポイント
- オブジェクト指向
- データクラス+機能クラスの世界から脱却
- クラスを作ったからってオブジェクト指向ではない
- データクラス+機能クラスの世界から脱却
- インクリメンタルな設計
- 最初に綺麗に設計したがる
- オブジェクト指向→インクリメンタルな設計の順番
- オブジェクト指向に自信が無いとできない
- オブジェクト指向
- 体で覚えるオブジェクト指向設計
- 名前=何のためのコード化がわかるので重要
- Getしているということはどっかにロジックを書いているはず
- プログラムのしたいことをメソッド名を通して表現する
- クラスとテーブルをぶった切りに行かないとダメ
- リファクタリングを多用するので静的型付けが必要
- インクリメンタルな設計
- もっと速くコードを書こう
- 最初からいい設計が見つからない
- 設計書だって下書きしてからアウトラインができていく。コード一緒
- できない理由はいくらでも考えられる。
DDD実践ベストプラクティス 加藤 潤一
- CQRSとは
- 質問をすることで回答を変化させてはいけない
- DBを分けなくても、CQRSはありえる
- 形式変換を行う。ドメインはライトだけにする
- ライドでも状態を問い合わせることはありえる
- イベントソーシング
- 発生したイベントを全て永続化する
- Updateはスケールしない
- イベントが10万件あったら、Journalとsnapshotで解決
- 今はAkkaだけ、Springもこの方向
- マイクロサービスとコンウェイの法則
- 複数サービスにまたがる変更がデリバリーコストを上げてしまう
- コンウェイの法則とDDDの関係性
- 言葉の持つ意味は使われ方によって変わる
- 主語が一番見捨てられる可能性が高い
A-4 サーバーレスアーキテクチャ 伊藤 直也
資料: https://speakerdeck.com/naoya/serverless-architecture
- サーバーレスアーキテクチャとは
- 単純にはFaaSを使ったシステム
- 必要になったときだけ計算する
- ハード的な意味でサーバーがない
- 常駐プロセス的な意味でサーバーがない
- 単純にはFaaSを使ったシステム
- AWS Lambda
- イベントごとにその関数を実行できる
- コンテナで実行、終了時に破棄される
- CGIに近いモデル
- 基本的にステートレス(Shared Nothing)
- AWSLambdaはスケールするし早い
- EC2でたちあげっぱなしをAWSLambdaでやると安くなるのでは
- 事例から
- イベント駆動が結合
- Bot常駐などで使える
- 複数のイベントを連携させる
- アーキテクチャの性質を解剖
- CGIはShared Nothing で安全、簡単だった。
- ただCGIはアプリケーション全体を毎回forkがとても非効率で
遅くなった原因を調べると、アクセスカウンタなんてことも - Node.jsでは並行性のが高いが可用性に難。
- よく考えると、起動に伴うオーバーヘッドが少なければ毎回実行で構わないのでは
- AWSLambdaは毎回実行だが、コンテナで起動にともなうオーバーヘッドが小さいのが特徴。
- LambdaからMicroserviceが見えてくる
- Lambda 関数はイベントへの反応として記述する
- 完全な疎結合になる
- リアクティブである
- FaaSは自然とMicroserviceになる
- オーケストレーション(リクエスト、リプライ)
- コレオグラフィ(イベント駆動)
- パブとサブの間に関係はない
- スターバックスは2フェーズコミットを使わない
- トランザクションが失敗したらどうするのか？
- スループットが最大化できる
- コレオグラフィ(イベント駆動)
- Fassは自然とコレオグラフィを指向する
- デバッグが大変
- オーバーヘッドは少しかかる
- サーバーレスアーキテクチャとはイベント駆動で系を設計した、 リアクティブでコレオグラフィなマイクロサービスのこと
- ぶっちゃっけどうなの
- はまれば強い
- EC2より超安い
- 自然と良いアーキテクチャに向かう
- 開発工数はそこまで削減できないかも
- FaaS特有の(バッドを含む)ノウハウが必要
- ピタゴラスイッチになるのでデバッグが大変
- 結合テストが難しい
- はまれば強い
A-5 HTML5/フロントエンド開発 白石俊平
- Webはいまだに重要なのか
- Web is Dead
- ザッカーバーグ｢HTML5を過大評価したのはわれわれ最大の失敗｣
- スマフォの利用時間の8割がアプリ
- 昔はWeb100%だったのと比べると落ちた
- Chromeアプリは2018年終了
- 技術トレンドとしても減少傾向
- HTML↓
- W3C↓
- HTML5は問題だらけ(特にAPI)
- 2009-11年にAPIが増えた
- ユースケース始動だった
- ユースケースにはまらないと使いにくい
- HTML5のAPIが使われない
- APIの抽象度が高い
- 低レベルのAPIをそろえよう→Extensible Web→盛り上がらない
- Webの利用時間は減ってきている
- Webの重要度は、以前に比べて下がっている。「モバイル・オンリー」という選択も珍しくない。
- モバイル中心で考えると、Webはオプショナルな存在になった。
- WebとWeb技術の利点を再評価
- Webの利点を再評価
- SLICE
- Webブラウザ上のURLを踏んだらアプリを起動できる
- Webとアプリをシームレスにつなぐ
- Web技術の利点を再評価
- クロスプラットフォーム
- JavaScriptは世界で最も人気のある言語
- まだまだ進化がやまない
- AMP
- 制約を守ると早く表示
- グーグルがキャッシュしている
- HTTP/2
- 1つのサイトにつき1つのTCP接続で高速化
- クライアントの差し替えなく導入可能
- ES.next
- トランスペアレント
- クラスとモジュール
- 今までは人によっていた
- モジュールハンドラー
- JavascriptはWebの性質上非同期
- promise
- async/await
- let/const
- オブジェクトリテラル
- TypeScript
- コンポーネント指向開発の本格化
- これまでは基盤技術が足りなかった
- Web Components
- template要素
- shadow DOM
- HTML template
- プログレッシブウェブアプリ
- AMP
- Webの利点を再評価
