Skip to content

Developers Summit 2020 day2

Share
   

https://event.shoeisha.jp/devsumi/20200213

14-B-1 「ともにつくる」を実践するドメイン駆動設計

成瀬 允宣[GMOインターネット]

  • ドメイン駆動設計
    • 当たり前のことを当たり前にやるためのプラクティス
  • 構成要素
    • モデリング
      • ドメインの物事を、知識として抽出する
      • 何が重要かはソフトウェアによって異なる
        • 「トラック」は「アクセルを踏めば進む」のか「荷物を運ぶことができる」のか
        • どちらが重要かは「ドメインエキスパート」が知っている
    • パターン
      • ドメインモデルをコード（ドメインオブジェクト）に落とし込む
  • 開発者とドメインエキスパートのコミュニケーション
    • 会話が必要
    • 会話のためには共通基盤（ユビキタス言語）が必要
    • 「単語帳」ではない
    • 技術語と固有語、どちらかに寄せる必要はない
    • 開発者が主体となって協力して構築する
  • 境界付けられたコンテキスト
    • 「注文」を発注側と受注側で分ける
      • 発注側コンテキスト、受注側コンテキスト
      • チームを分ける場合にも使える
      • チーム間コミュニケションのために、「コンテキストマップ」が必要
  • 開発者だけで完結しない
    • 開発者、エキスパート、ステークホルダーの「共創」
    • ボトムアップアプローチで「パターン」からやってみる
    • コードとドメインは相互変換できる必要があるべき

14-E-2 プリンシプル・オブ・“ともにつくる”～ Web Performerを支えるドクトリン ～

上田 勲[キヤノンITソリューションズ]

  • 撮影禁止
  • プリンシプル：長い歴史を持つ抽象的知見
  • 我と汝
    • 世界は人間の二重の態度に応じて二重である
    • 人間の世界は　「我（ヒト）と汝（ヒト）」か「我（ヒト）とそれ（モノ）」か
    • 「我とそれ」ではチームにならない。コミュニケーション不全に陥る
      • 相手がヒトであってもモノとして見たら「我とそれ」になってしまう。「汝」として見ることが必要。
  • シニフィアンとシニフィエ
    • 言葉は恣意的である
    • 意味するもの（文字や音）と意味されるもの（実物）
    • シニフィアンとシニフィエの関係は一意ではない
      • 言語が違えばシニフィアンが異なる（「馬」と「Horse」）
      • 日本では「蝶」と「蛾」に分けられてもフランス語では「パピヨン」
    • 世界の文節化
      • 世界があって言葉があるのではなく、言葉があって世界があるという概念
    • パッチワーク
      • 認識している世界はありのままではなく、言葉におって歪められたいびつなもの
    • 人間は言葉で思考／会話している
      • 言葉は世界を完璧に表現できない
        • 思考も会話も完璧にはならない
          • 言葉が世界を構築するなら、知識を増やせば思考も豊かになる
          • いびつな世界しか表現できないなら、言葉より、「何を意味したいのか」に意識を向ける（我と汝）
  • 無知の知
    • 自らが最大の知恵者だとすれば、それは「自らいかに知らないかを知る」ことだ
    • 無知の無知は、成長を止める
    • 既知の既知 ＜ 既知の未知 ＜＜＜＜ 未知の未知
    • 無知を自覚する
      • 無知である姿勢で、どんなヒトからも学べる。知識を吸収し続ける
      • 知れば知るほど、知らないこと（既知の未知）が増える
    • 既知すら疑う
      • 自分の考えは、振り返ると間違っていることが多い
        • 時代の変化により間違いになることもある
      • 決めつけずに「自分の知らない世界があるかも」と考えてみる
    • 「謙虚さ」が必要
  • 絶望
    • 死に至る病とは絶望のことである

  • 環世界

  • アフォーダンス
    • 人間の行動は、環境と近くの直接の対応関係によって決定される
  • ドクトリン：
  • 保守主義
    • 歴史と時代の変化
  • フリクションレス
    • 宣言型にしてユーザーのやりたいことを表現する
  • プラガブル
    • 拡張ポイントを多数用意思している
  • 家具の裏側
    • 目に見えない部分にこだわることで、全体の品質を上げる
    • 自動生成するコードの可読性
  • まなざし
    • ユーザー専任のロールをおいている
  • 卓越性
    • 得意な部分を活かす
  • 工学
    • 科学との対比でわかりやすい
      • 科学：自然を説明するるルール
      • 工学：役に立つものを作成する
    • 現実と対峙するのは工学
      • ヒトの役に立つためのハブ＆インターフェース
    • 「目の前の仕事をこなす」から「この仕事で役に立つ」に視点を転回
    • 「余らせる」という意識を持つ
      • 対象は何でも良い
      • 余っていないと、役に立てない

14-B-3 K8S使ってますか？リテールテック（小売・決済等）でのコンテナ活用例と「2025年の崖」克服に向けたコンテナ導入のススメ！

程 建強[Rancher Labs]/山澤 一仁[スーパーソフトウエア]/井川 知幸[カゴヤ・ジャパン]

  • 今後3年以内に76%の企業がK8sを標準基盤として利用
  • コンテナの良さ
    • ゲストOS不要で資源効率性
    • 移植性
    • 設置性
    • 開発容易性
  • RANCHER日本の利用率は低い
  • RANCHERはOSSなのでベンダーロックイン回避可能
  • Rancher Pipelines
    • Rancherに統合されたCI/CD
    • UIもついている
  • Rancherカタログ
    • HelmベースのアプリケーションをRancherからデプロイする機能
  • RIO(Micro PaaS)の統合予定

14-C-4 エッジコンピューティング、エッジAIの可能性

中村 晃一[Idein]

  • エッジコンピューティング
    • デバイス状やデバイスの近くで計算を行う
  • エッジが注目される背景
    • データセンター・回線のキャパシティオーバー
      • デバイスの増加、計算負荷・データ量の大きいアプリケーションの需要増加
      • データセンターへの電力供給量の限界、半導体そのものの電力効率の頭打ち
    • プライバシーへの関心の高まり
      • GDPRなど
      • 不要な情報は送らない
    • 超低遅延化への需要増加
      • 自動車・ロボット・ドローンなどリアルタイム性が重要なもの
      • 5Gの恩恵を活かしたい
        • 無線区間は速くなっても、有線区間は変わらない
  • 計算資源が制限されるとめんどくさい
  • 電源の制限もある
  • 機械学習は仕様を決められない
    • 売り切りにするのは難しい
  • Mobile GPUで汎用計算を実現するためのコンパイラスタックを自社開発
    • なので、コンパイラ職がある
  • AIベンダーが作成したアプリを1日単位の課金（数十円）で利用できるマーケットプレイスを用意している
    • ここで稼ぐビジネスプラン
    • Pythonで書く

14-D-5 マルチクラウドに向けてNGINX活用促進する為に知っておいてほしいこと

鈴木 孝彰[NGINX (Part of F5)]

  • Nginxの利点
    • 同時接続処理
    • メモリ使用量
    • 目安はnginxのサイトに公開されている
  • オートスケールに対応するためのOSSがある
  • K8sのingressコントローラーとして使う
  • External Nameを指定してマルチクラウド構成を構築できる
  • nginxでJWT認証もできる

14-G-2 【GCP Kubernetes ハンズオン】 GCP をさわりまくろう！スペシャリストに聞きまくろう！〜 QWIKLABS 大会 Kubernetes 編 〜

Google Cloud チーム[グーグル・クラウド・ジャパン]

  • 面白かった。けど疲れた。

14-C-8 雲の中心で愛を叫ぶ！ クラウド横断パネルディスカッション

濱田 孝治[クラスメソッド]/松村 優大[オルターブース]/高野 遼[クラウドエース]/【司会】近藤 佑子[翔泳社]

  • アメリカ１週間滞在でひとり50万くらい
  • 業務における気付きについて
    • どんな案件が増えているか
      • AWS: 多種多様な顧客
      • AWS: コンテナ案件増えている
        • これからサービスを作ろうとするときに選ぶ
      • Azure: エンタープライズ系、モダナイぜーション案件
      • Azure: PaaS、サーバーレスの組み合わせが多い。ノーコードも。
      • GCP: DX。BigQueryを中心にしたデータ分析案件。
      • GCP: GSuiteとの連携が強い
    • 便利なところ
      • GCP: プロダクトが多くない、選択で悩まない
      • GCP: Googleがお手本を見せてくれる
      • Azure: 開発に特化したサービス。イベントドリブンな処理を作りやすい。
      • AWS: なんでもできる。選択肢が多い。
      • AWS: 開発者向けに寄ってきている（CDK）
    • 他のクラウドで羨ましいところ
      • Azure: AWSは利用者が活発（JAWS-UG）
      • Azure: GCPはFirebaseのような気軽に使えるサービス
      • AWS: JAWSは偉大
      • AWS: GCPは使おうとしている顧客がイケイケなイメージ
      • AWS: AzureはMS系のライセンスの扱いが楽（BYOL）
      • GCP: Oracleが使えるところ、シェアがたくさんある、情報がたくさんある、サポートもいい（らしい）
      • Azure: ドキュメントはたしかに多い。変な翻訳も。
  • 個人のキャリアや組織について
    • キャリアの変化、可能性
      • AWS: 自分の市場価値
      • Azure: アプリケーションの作り方が変わった
      • GCP: 最新の技術の周りには最新の問題が転がっている
    • チームとして成果を出すにはどうしたらいいか
      • AWS: AWSの範囲が広いので、得意領域を持って組み合わせる。社内勉強会おすすめ。
      • Azure: AWSと同様。一人で全部わかるわけがない。アウトプット大事。
      • GCP: 機能分けの組織。自分の守備範囲を認識する。他のポジションのことも理解する。
  • クラウドの学び方について
    • GCP: 教える側は魅力を伝える必要がある。学ぶ側は全部を学ぶ必要はないが、基本的なところは抑えておく必要がある。
    • GCP: 膨大なサービスは覚えない。ざっくり覚える。
    • Azure: 公式ドキュメントやサンプルドキュメント
    • Azure: 今はマイクロソフトラーンhttps://docs.microsoft.com/ja-jp/learn/
    • AWS: 低レイヤーや基礎ををないがしろにしない
    • AWS: 認定試験の勉強で思想が理解できる