https://github.com/tamiat/tamiat

Firebaseを使ったCMSを探していて、見つけたもの。

セットアップはリポジトリのREADMEに書いてあるとおりでほぼ行けた。 1箇所だけ、パッケージの依存が解決できなくて手動でyarn addしたものがあったくらい。

GCPでプロジェクト作って、Cloud Shellで作業。便利。

で、構築は簡単にできたけれど、使い方がわからない。。

先日のデブサミのハンズオンで使ったアカウントに１ヶ月のサブスクリプションが付与されていたのを思い出して、途中になっていたKubernatesのクエストの続きを終わらせた。 Jenkinsを使ったCI/CDのやつ。

Jenkinsは昔使ったことあったけれど、最近はCI/CDのサービスが充実してきているので自前で用意して使うことはなくなってきたなー、ということで久しぶりに触った。

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がある
  • https://github.com/nginxinc/nginx-asg-sync
• 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: 認定試験の勉強で思想が理解できる

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

13-D-3 サーバーレスなPCI DSS対応クレジットカード決済基盤システムを運用しながら、みんなでわいわいDIYの精神で、新しいモバイル決済サービス6gramを作っている話

田岡 文利[ミクシィ]

• PCI DSS
  • クレジットカード業界のセキュリティ基準
  • イシュア、決済代行業者は対応必須
    • カード情報を保存しないといけないので
  • エンドユーザは対象外
  • 通信経路も対象
    • 直接カード情報を取り扱わない（トークンなど）で回避可能
  • 12要件、約400項目
  • 運用手順のドキュメントなど監査の対象になる
  • アカウント要件
    • パスワードが必須になっている
    • パスワードレスにしたいのに。。
• 運用負荷を下げたい
  • インスタンスを使わない
  • コンテナをReadOnlyで使う
    • ログインできない＝IDパスワードが不要
  • DynamoDBを使用
    • RDBのID/パスワードからの開放
    • KMS, IAMで暗号化や権限管理ができる
• 6gram
  • 物理カードの重量（5g）＋1
  • 満たす製品がない
    • なぜ
      • 既製品はコンテナネイティブなものがない
  • サービス間通信にSQSを採用

13-F-4 若年層におけるプログラミング的思考の学びの場づくりと動機づけ

鷲崎 弘宜[早稲田大学]/齋藤 大輔[早稲田大学]/坂本 一憲[早稲田大学]

• プログラミング的思考
• なぜ必要なのか
  • 第４次産業革命
    • 本質を捉えて論理的に思考し手順建てて世界を再定義する考え方と技能を
    • 諸外国では始まっている
  • プログラミング学習の意義
    • 創造的思考、数学的思考、メタ認知に効果あり
  • プログラミング的思考
    • 日常生活の問題解決にも有効
• どのように養うか
  • 知らない→知っている→使える→応用できる
• プログラミング的思考の整理
  • 現実の世界→モデルの世界
    • 分解、一般化、抽象化
  • 論理的推論
    • 身近な話題で考える
• 地域におけるプログラミング学習の場の形成
• 活動テーマ：ものづくりと地域貢献
  • ルーブリック（Rubric）を用いた評価
• 課題
  • 人、モノ、金
• 学びの動機づけ
• 学習効果＝教材の質×学習の量
  • 適切な動機付けて、行動量を増やせる
• 内発的動機づけ
  • 行動自体のために行動したいと感じる意欲のこと
  • ３大欲求
    • 自立性、自己決定間：」選択肢をああ得る
    • 有能勘・自己効力感：自身を与えるべき
• 報酬と動機づけの関係
  • 統制的昨日、情報的昨日
  • ２つの側面があり、使いどころに注意
• 内発的動機づけの低下（アンダーマイニング効果）
  • 効果については論争中
  • 良くない報酬の共通認識はある
• 個性とやる気が出る刺激がある

13-B-5 Best Practices In Implementing Container Image Promotion Pipelines -知っておくべきコンテナイメージ・プロモーションの方法

Baruch Sadogursky[JFrog]

• https://jfrog.com/shownote/developers-summit-2020/
• 開発と本番環境の切り替え
  • LABEL METADATA
  • DOCKER REPOSITORIES

13-E-6 なぜ技術力評価会の評価者はペアなのか？ー 8年半で378組の評価者ペアが835回評価した事例からみるペアの効果 ー

小賀 昌法[VOYAGE GROUP]

• 2011年以前は上長だけがする評価制度だった
• 現在はほぼすべてのエンジニアが評価に関わるように
• エンジニア技術力評価の難しい理由
  • バイアス
  • 技術の多様化
    • 評価者が被評価者より詳しいとは限らない
  • 評価スキル向上機会の不足
    • 1on1をやっても考え方を引き出すスキルやフィードバックのやりかた
  • 同じ人が長く評価することでの方より
• 技術力評価会制度は効果が見られた
• 評価制度
  • 誰がどのグレードかは社内に公開されている
  • 上の等級に上がるには何が必要か
  • 評価を通じて成長を促す
  • 半年に１度実施
  • 事業貢献×能力×CCFBの総合評価
• 報酬制度
  • 報酬と評価の結びつき
  • 年功序列や均等割なら評価はいらない
• 技術力評価会
  • チームを超えた技術力評価
  • 評価委員がいる
  • プレゼン30分＋質疑応答60分
    • プレゼンの技術で評価されないよう、質疑の時間を多くしている
  • 誰から評価されてるのかは対面なのでもちろんオープン
  • 評価は数値ではなく文章で書く
  • 評価結果も社内に公開している
    • ８年で1050以上の蓄積
  • 社外評価者
• ペアで評価することの効果
  • 評価が難しい原因を解消
  • 悪い点もある

13-B-7 コンテナをシンプルに使おう 〜 Cloud Run のすゝめ 2020 冬

篠原 一徳[グーグル・クラウド・ジャパン]

• 撮影禁止
• 開発者はK8sを直接触りたいのか？
  • コードを書きたいのではないか
  • k8sを使うには多数の手順が必要
  • 簡単にするならサーバーレス
    • インフラ管理不要、古マネージドセキュリティ、使った分だけ支払い
• Cloud Run
  • Knativeベースのサーバーレスサービス
  • 高速デプロイ
    • 0スケールから数秒でURL付与まで
  • サーバーレスネイティブ
  • 高いポータビリティ
• 知っておいたほうが良いこと
  • リソースモデル
    • Project > Service > Revision > Container
    • Serviceごとにエンドポイントが発行される
    • デプロイごとにRevisionが生成される
  • コンテナに関する
    • タイムアウトデフォルト5分（最大15分）
      • 長時間のバッチの利用には向かない
        • 今後に期待
    • 1vCPU、最大2vCPU
      • 今後に期待
    • メモリ256MB、最大2GB
    • データの永続性なし
      • コンテナとともに消える
  • オートスケーリング
    • リクエスト数に応じてスケールする、最大1000
    • コンテナインスタンスが0になるまでの仕組みは非公開
  • Concurrency
    • 1コンテナインスタンスで同時に受けられるリクエスト数
    • 最大80
  • 課金時間
    • 最初のリクエストが始まったところから最後のリクエストが終わったところまで
    • インスタンスの生存時間ではない
• 実践的に使っていく
  • アクセス制御
    • IP制限はない
    • IAMで発行したトークンがヘッダに乗っていたら許可する
  • GCPサービス関連系
    • サービスアカウント（アプリケーション用アカウント）を使う
    • デプロイ時にサービスアカウントを指定する
  • 3rdパーティサービスの利用
    • Secret Managerを使う
  • DBとの接続
    • デプロイ時にDBのインスタンスIDのを指定すると、UNIX Socket経由でアクセスできる
  • 独自ドメインを使う
    • CNAMEを登録すれば独自ドメイン持ち込み可能
    • 証明書はLetsEncrypt
  • トラフィックの制御
    • Update traffic昨日でBlue/Greenデプロイやカナリアリリースが可能
    • リビジョンを指定する
      • 今日GA
  • コンテナインスタンスが増えすぎないようにする
    • Max instancesを指定する
      • DBコネクション枯渇対策
  • Cold Start対応
    • Minimum instancesで常時起動コンテナ数を指定できる
      • アルファ機能
  • ビルドデプロイの自動化
    • Cloud Buildを使う
    • kanikoを使うと、artifactのキャッシュをしてくれるのでおすすめ

13-F-8 あのイベントの裏側が知れる！？カンファレンス運営者LT

西馬 一郎[Backlog World]/島根 義和[JaSST Tokyo]/岸川 孝明[JAWS DAYS]/高橋 慎一[明日の開発カンファレンス]/谷本 心[JJUG CCC]/細澤 あゆみ[XP祭り]/柏岡 秀男[PHPカンファレンス]/【司会】鍋島 英莉[翔泳社]

• Backlog World 2020でともに学びましょう

• 2/29 大崎
• DevRelCon Tokyo、技術書典と同日

• JaSST Tokyo実行委員のお仕事

  Read more

https://ntt-techconf.connpass.com/event/161866/

NTTグループのエンジニア有志が主催するカンファレンスイベントの4回目とのこと。 初参加です。

Opening Keynote

• 参加者の半数がNTTグループ
  • NTTグループは919社もある
  • 30万人いるのでグループと言ってもでかすぎる
• エンジニアの有志が主催しています
• 前回から1年半
  • 退職エントリとか押しかけラグビーとか色々炎上していたので自粛していた

Kubernetes基礎

吉村 翔太

• https://speakerdeck.com/yosshi_/kubernetesfalseji-chu
• 基本的なリソースを理解する
• 全体像
  • masterのAPIサーバーを経由して動いている
    • 状態はetcd
  • master
  • node
    • Container runtime
    • Kubeket
    • Kube-proxy
  • etcd
  • kubectl
• MasterとControl Plane cmponentsのち外
  • Master + Kubelet + Kube-proxy = Control Plane
  • ドキュメントによって表現に揺れがある
• etcsに行かない例外もある
  • 4パターン
  • /proxy, /exec, /attach, /logs
• マネージドで使うなら、kubectlとコンテナだけ使えれば良いことが多い
  • オンプレでやるなら全部理解しないと辛い
• Workload
  • Pod
    • コンテナのデプロイの最小単位
    • 複数コンテナをまとめたもの
    • メインのコンテナ＋サイドカーみたいな構成
  • ReplicaSet
    • Podの数を維持するためのリソース
    • Podのラベルで認識する
      • ラベルの付け方に注意する
    • selectorとtemplateのラベルは基本的に同じ。歴史的経緯で冗長になっている。
  • Deployment(deploy)
    • ReplicaSetを管理するリソース
    • RollingUpdateに使う
• Configuration
  • Configmap
    • 設定情報を保存するリソース
  • Secret
    • opaque
      • 使い方はConfigmapと同じ
      • エンコードされている
      • configmapと権限を分けて管理するのが良い
• Discovery & LB
  • ClusterIP
    • クラスタ内のアクセスを保証する
    • これもラベルで宛先を認識する
  • NodePort
    • クラスタ外からポート指定でアクセスする
    • ノード内に同じラベルのPodが複数あったら、どこに行くかはランダム
• Metadata
  • Namespace
    • 1つのクラスタを仮想クラスタにわかる
    • 障害の影響範囲でどう分けるか考える
      • 開発環境ならNamespace、本番環境はクラスタとか
      • クラスタ分けると管理コストが上がる

1870件以上のカーネルの不具合修正に貢献した再現用プログラムを自動生成する試験自動化技術

藤井 秀行

• https://www.slideshare.net/nttdata-tech/syzkaller-linux-kerneltestingnttdata
• GoogleのDmitry Vykovが開発したsyzkaller（シスコーラー）
  • Go言語
  • Googleとしては非公式
• ファジング
  • 未知の不具合や脆弱性の検出に適したテスト手法
  • Linuxのセキュリティ品質向上に貢献
  • リリース前にセキュリティ脆弱性が修正されるようになりCVEが現象してきている
• ドキュメント調査
  • 入力データの生成の仕組みが肝
  • ソースカバレッジも気にする
  • カーネルの入力インターフェースはシステムコール
  • syz_manager
    • 仮想化ホスト上に存在するプロセス
    • syz-fuzzerに指示を行う
  • workdir
    • 入出力ファイルを置く
  • syz_fuzzer
    • 試験環境内に存在するプロセス
    • syz_executorを生成
  • syz_eecutor
    • システムコールを送る
• 動作確認
  • 20分くらいで見つかった
• 試すなら私物PC、私物ネットワークでやる。絶対。

Coffee Break

• Showcaseで「技術系業務自動化のエンジン展示」の説明を聞きました。
  • TSVを入力として、コマンドを実行する
  • sshとかtelnetとかブラウザとか操作できる
  • これを横連携させて実行できるのは（開発開始した当時は）あまりなかった
  • OSSとして公開したいが、まだ調整中。
  • 公開されたら試してみたいと思います。

React HooksとGraphQLで社内レガシーサービス巻き取ってみたらものすごくはかどった話

奥井 寛樹

• https://speakerdeck.com/hrk091/react-hookstographqldeshe-nei-regasisabisuwojuan-kiqu-tutemitaramofalsesugokuhakadotutahua-153983bf-84bd-4be7-83c4-c8fa826db79e
• フロントエンド＋BFFの話
• うまく行った理由
  • フレームワークによる抽象化がうまく、ユースケースにフォーカスした開発ができた
  • GraphQLエコシステムが充実していた
• React Hooks
  • React FCでStateを扱えるようにするフレームワーク
  • React lifecycle eventを意識しなくて良くなる
  • Context APIの使い勝手が向上
• GraphQL
  • APIプロトコル
  • RESTより柔軟
  • クライアント側でレスポンスを定義できる
• Graphene
  • PythonのGraphQLフレームワーク
  • ORMモデル定義からAPIを自動生成してくれる
• Apollo
  • GraphQLのライブラリ
  • バックエンドとフロントエンドクライアントを提供
  • Reactに標準対応している
• 漸近的型付け
  • 動的型付け言語に後で型をつけること

海外講演を通じて得られた知見(英語力＋α編)

神原 健一

• https://speakerdeck.com/korodroid/ntt-tech-conference-hai-wai-jiang-yan-wotong-zitede-raretazhi-jian-ying-yu-li-abian
• https://qiita.com/korodroid/items/bf029f7aad896731771a
• 英語を学ぶ目的を具体的に描く
  • 海外カンファレンスで講演する
• skills
  • reading, listening, writing, speaking
  • 自分のレベルの把握
  • どのスキルをどのくらいにしたいのか
• 先人に学ぶ
  • SlideShare, Speaker Deck
• 登壇→フィードバック→次回への反映のループ
  • 習うより慣れろ
• 頭の中にある考えをリアルタイムに英語で話す
  • Cheat Strategy
    • スライドのノートにセリフを全部書く
    • →会場を見ないで読むだけになってしまった。失敗。
  • 自身を持って自分の言葉で話すことが大事
• tips for communications
  • 自分から話しかける
  • お互いの作品を見せ合う
• 英語の教材の選び方
  • （自分の目的とレベルに合わせて選ぶしか）ない
  • ノンネイティブ英語の練習
    • ノンネイティブスピーカーのセッション動画
  • ネイティブ英語の練習
    • TOEIC公式問題集
  • 英語の「音」の聞き分け
    • 英語耳
• オンライン英会話
  • 体験レッスンやってみると良い
• 英語を話す機会を増やす
  • 面倒なことこそ、修行のチャンス
  • 知識＜＜＜実践
  • ビジネスだけではなくプライベートでも

パワポをよくしただけなのに〜デザインの力で会社に貢献するチームの紹介

鈴木 雅貴

• https://www.slideshare.net/suzukima/ss-226433621
• 2つのデザイン支援チームができてしまった
  • 統合した
• 製品の価値・魅力向上
• 社外のデザイナーと比較して気軽に依頼できる
• デザインサポーター制度

アジャイル開発手法における監視システム開発効率化の取り組み

石田 瑛一

• https://drive.google.com/file/d/1imNXoqfQAbBGUDH1Y45fn1sVb1rgHjW6/view
• デプロイ作業の効率化が必要
  • 手順書でやってた
• Ansible、Gitlab CI/CD
  • 安定するまで2ヶ月くらいかかった

スタートアップチームで学んだエンジニアの心構え

松木 久幸

• https://speakerdeck.com/matsu0228/the-attitude-of-the-engineer-who-learned-from-the-start-up-team
• 開発で一番難しいのは何を作るか決めること
  • 詳細まで認識を合わせる
  • 正解は誰にも判断できない
    • 常に変化が求められる
  • 価値向上のために「発散」も必要
• 仕事を楽しむこと
  • メンバーが主体的になるためにも、承認欲求を満たすことが大切

NTTデータのトップ技術者育成！「技統本塾」のご紹介

小泉 鉄之祐

• 技術革新統括本部

Amazon EKS上でのVNF開発奮闘記

篠原 健太

• https://speakerdeck.com/sinohara/amazon-eksshang-defalsevnfkai-fa-fen-dou-ji
• ネットワークの仮想化
• 閉域NW構築
  • AWSを閉域として構築できるか？
  • サブネットを分けて構築する
  • EKS v1.13から対応
  • マネージドのLBが外向きの通信に課題があったのでnginxを立てた

Cisco ルータのログを Stackdriver に送って可視化してみた

田島 照久

• https://speakerdeck.com/tjmtrhs/cisco-rutafalseroguwo-stackdriver-nisong-tuteke-shi-hua-sitemita
• ログ基盤を作りたいわけではなく、可視化したログを見たいだけ
• stackdriverは外部のsyslogを直接受信できない
  • ルーターで処理すれば良い
• Ciscoのルーターで、Pythonが動かせる機種がある

Closing Keynote

• 151/180人参加（速報値）
• 15人#1〜#4までに登壇した退職者
• もっと面白いエンジニアになる

http://docomo-rd-openhouse.jp/2020/

昨日に引き続き、来ました。 昨日より人が多い印象。

[特別講演] 5G時代の幕開けとサスティナブルな社会の実現

(株)NTTドコモ 取締役常務執行役員 R&Dイノベーション本部長 中村 寛

• 18の未来
• 5G, AI, デバイスの進化
• この先の10年の展望
• 5Gプレサービス
  • まだ端末が販売されていないので、プレという位置づけ
    • イベントなどではドコモが貸出している
  • 春、商用スタート
• 通信基盤（1G〜2G）、生活基盤（2G〜4G）から社会基盤（5G）へ
• 5Gを軸としたパートナーとの共創
  • 3200を超える企業、団体が参画
  • 様々な業界
  • 業界を超えた価値共創
  • 事例
    • スポーツ/ライブ観戦
    • ゲーム/eスポーツ
    • 観光
    • TV番組制作の作業効率化
      • ケーブル取り回し・敷設が不要になる
    • 工場内
      • 多品種少量生産への対応
        • レイアウトフリー生産ライン
      • 熟練工不足への対応
        • AI/IoTによるリアルタイムコーチング
• ネットワークの進化
  • トラフィックのスパイク
  • セキュリティ
  • いままではE2Eで最適化されたネットワーク
  • 仮想化
  • 可搬基地局
  • O-RAN, MEC, 5GC
• ドコモオープンイノベーションクラウド
• 6Gに向けたホワイトペーパーを公開（2020/1/22）
• 4Gと5Gの比較
  • 5Gの特徴
  • 4Gと5Gの連携
    • スムーズなマイグレーションができるよう設計されている
    • LTEからLTEアドバンスドへの移行のときもそうだった
    • 4Gネットワークでもできることはある
• デバイスの進化
  • 電話の進化（〜2G）、情報ツールの進化（〜4G）、ユーザー体験の進化（5G〜）
  • まだ発展の余地がある
    • 操作の制約、画面サイズの制約
  • マイネットワーク構想
    • スマホのみでは不便なところをサポートするデバイス
      • スマートグラス、VR、フレキシブルディスプレイ
      • Magic Leap社と連携
• AIの進化
  • 環境が整った（第3次ブーム）
  • AIの意義
    • AIを個人に活かす
      • 翻訳の高度化
        • Mirai Translator
          • 2年前はTOEICで700点くらいを目指していた。現在は960点いける。
            • プロの翻訳家なみ
        • 話し言葉のリアルタイム翻訳
          • 実用的なレベルになってきている
    • AIを社会・産業に活かす
      • ネットワークの品質向上
        • 最適なエリアの自動設計
        • サイレント故障の検知
        • ユーザー申告要因解析
      • AI会議室管理
        • 利用データを解析して未来の利用を予測する
  • ドコモのAIの強み
    • 活用ノウハウ、データサイエンティスト、ビッグデータ
    • KDD CUP 2019で世界一位
• サステイナブルな社会の実現に向けて
  • サイバーとフィジカルの融合
  • 実世界の人・モノ・コトを情報化し、未来を予測して、実世界を最適化
  • 90年代のユビキタスコンピューティングの概念から
  • 通信インフラやコンピューティング、AIなど環境が整って、実現の可能性が見えてきた
  • 提供価値
    • 交通
      • 現在：スマホやカーナビで渋滞情報がわかる
        • 最短ルートを示してくれるが、渋滞自体の解消はしてくれない
      • 未来：車両の走行状況や目的地、周辺道路状況などを情報化し、交通を制御
        • 信号のコントロールも考えられる
    • 農業
      • 現在：労働集約多々産業であり、従事者のノウハウで成立している
        • 産業の効率化と後継者不足
      • 未来：
  • 融合の要諦（ようてい）
    • 人モノコトの情報化：デバイス
    • データ取得と蓄積：AI
    • 未来予測地の発見：AI
    • アクチュエイト：デバイス
    • のループを回す
    • AIとデバイスは5Gで接続

[招待講演] ラグビーから学ぶ組織づくりと技術進化に伴う スポーツの未来について

元ラグビー日本代表 神戸製鋼コベルコスティーラーズ アンバサダー 大畑 大介

• 今回の大会を振り返って
  • 選手たちのハードワーク
  • 明確な目標のイメージ
  • 年間240日一緒に生活
  • 一緒に過ごした時間が長い
  • それぞれの役割が適材適所に与えられた
    • 個々ができることを同じベクトルを向いて全力で取り組む
• アイルランド戦の前半最後スクラムで押し込んだ場面
  • 軸になるものをしっかり作った
  • 体格だけではなく、技術を高めた
  • 足の向きなど細かいところまでこだわる
  • 精神的に優位に立てた
  • 精神論だけではない
    • データも活用
    • レフェリーの癖も分析して対策する
      • トップのレフェリーほど基準がブレない
• 15人の個性をまとめ上げる
  • ジャッジを下す人がどこに向かっているのかを明確に示す
  • 各自がどこにいてどこに向かっているのかを意識する
  • しっかりした方向性、目標
  • 目標の道中での評価
    • 適切に軌道修正も行う
  • 権限を預ける
    • 個々人がそれぞれ考えて動く
• 30年くらい前の大学ラグビーとの比較
  • ラグビーは進化している
    • ルールも変わる
      • 昔はトライは0点だった
  • 前に送るにはキックが手っ取り早いが、ボールが相手に渡ってしまう
    • キックの技術の向上
  • ある程度行き着いた先に何があるかを考える
  • 指導する立場でも自分が覚えた頃のことが通用しなくなる
    • 押し付けでは伝わらない
    • 自分の中で思い描き、伝える
    • トップの言葉の説得力
• データ取りの方法
  • 5G時代どうなる
  • GPSや心拍数の例
  • 選手の負担が減る
• 観戦体験
  • 試合会場で見るよりわかりやすい
  • 臨場感は負ける
  • マルチアングル視聴
    • 8系統
    • 解説者には最適
    • それぞれが好きな場面を見れる
  • スタッツの活用
  • レフェリーの技術向上
  • レフェリーカメラで技術伝承
• スクラムの衝撃
  • スクラムの中も見れるようになる？
• 個人の人気から競技の人気へ
• サッカーとラグビー
• ラグビーの良さ
  • 自己犠牲のスポーツ
  • 人間関係
  • チーム（組織）に対して不利益なことをしてはいけない
• 2023フランスWC
  • 自国アドバンテージのない中でどう戦うか
  • ランキング8以内に入れるかが重要
    • 予選のグループ分けに影響する

[パートナー講演] 5GEvolution & 6Gパネルセッション：「5Gの発展とその先の未来」

(株)NTTドコモ 執行役員　5Gイノベーション推進室長 中村 武宏 Ericsson,Nokia,Nvidia

• 結構ゆっくり喋ってくれたので、比較的聞き取りやすい英語だったけれど、知らない単語が多くて理解できないところが多かった。
• 以下はスライドからのメモ。書き写すのが間に合わなくて足りないところ多数。
• Dr.Erik Dahlman
  • 6 pillars for 6G
  • Journey towards 6G
    • Connectivity everywhere
    • Joint communication and sensig
    • Zero-cost, zero-energy devices
  • Some key technology components
    • Further spectrum extension
      • Entering the THz range
    • AI
    • New ways for connectivity
      • Evolved IAB, D2D, non-terrestrial components, …
• Dr.Amitava Ghosh
  • 6G
    • RF Sensing 100 Gbits/sec @ short range, Gboos @ high speed
    • Industrial IoT optimezed
  • Six questions
    • most important net technologies
    • primary use cases
    • most important KPIs
    • serve limitations of 5G
    • flexivility and scalabilyty
    • backwards compatible
• Mr.Masataka Osaki
  • 3 REVOLUTIONS SHAPPENNING
    • IoT
    • 5G
    • AI
• Questions
  • Typical use cases in 2020s and 2030s, respectively?
  • Definition of 6G
  • Key requirements for 6GG
  • Major technologies for 5G evolution and 6G
  • Role of AI for 5G evolution and 6G
  • Time schedule for 6G

[オープンセミナー] 無人販売機とドコモ会員基盤を使った購買データ分析について

• 無人システム販売のトレンド
  • RFIDから画像認識に
  • キャッシュレスが追い風に
  • 店舗対象が激増したが、ほとんどが実験段階もしくは実装店舗
  • 自販機が復権

    

• 無人販売の限界
  • 日本の小売業界の諸問題
    • ロジスティック
    • 年間商品点数の多さ
    • 各種法規制など
  • システムだけではなく「運用をどう回すか」が重要
• ドコモは昔から自販機ビジネスをやっていた
• 社内で実証実験中

  

  • 専用アプリでQRコードを読み込んで認証＆自販機のドアロック解除
  • 商品を取り出す
  • ドアを閉めると決済が走る
• 商用化に向けた検討
  • 必要機能の洗い出し
  • 運用上の課題抽出
  • データ分析手法の開発
• 購買データ分析の世代
  • 伝票からPOS、個人IDへ
  • 企業目線から消費者目線での分析に変化していっている
  • 匿名ではあるが、実際に存在する人間の購買データが分析できる

    

• プラットフォーム化がもたらすもの
  • 顧客像
  • 行動特性
  • 異業種のデータ
• 活用アイデア
  • 業界をまたがったクラスタによる商品レコメンド
  • 健康管理サービスとの連携

[オープンセミナー] IVA（Intelligent Video Analytics）エッジAIプラットフォーム 〜IoT with AI時代を支えるエコシステム構築に向けて〜

• IoTの普及でセンサーやカメラなどのエッジデバイスから大量のデータが発生
  • データトラフィック予想、2022年には25EB/Month
  • クラウドだけで処理しきれないならばデータ生成場所（エッジ）で処理する

    

• IoTにおいて映像解析がフィ津用となるユースケースは多い
  • セキュリティ
    • 顔認証、人物検知、不信物検出
  • スマートシティ／ビルディング
    • 人流計測、入隊管理、火災検知
  • 交通
    • 交通量計測、車種認識、ナンバープレート認識
  • 建設
    • 稼働監視、動線分析、危険検知
  • 工場
    • 製品検査、行動・動線分析、在庫監視
  • 物流
    • 車両検知、動線分析、倉庫監視
  • 広告／マーケティング
    • 人数計測、滞留検知、人物属性認識
  • 小売
    • 人数計測、顔認証、万引検知
• AIソリューション導入の課題
  • 利用者側
    • システム基板への高額な投資
    • AIソリューション選定の難しさ
    • 運用・維持の煩雑さ
  • AIアルゴリズムメーカー側
    • 設定やチューニング作業の現場実施が困難
    • 設置作業者と設定技術者がほとんどの場合異なるため、設置現場での共同作業は非現実的
    • 設置後も微調整が必要
• エッジAIプラットフォームでAI流通エコシステムを構築

  

[オープンセミナー] 電池で10年動く！省電力LTE端末開発の取り組み

• 昨日と同じ内容でした

[オープンセミナー] ドコモオープンイノベーションクラウドのご紹介

• 5G実現に向けたロードマップ
  • 2019年9月20日：プレサービス開始
  • 2020年春：商用サービス開始
• DOCOMO 5G Open Partner Program
  • 2018年2月：プログラム提供開始
  • 約3200団体・企業が参加
  • 263件の5Gトライアル実施
• ドコモオープンイノベーションクラウド
  • ドコモ網との直結により伝送遅延の低減を実現するMEC（Multi-access Edge Computing）
    • 通信のリアルタイム性
  • 閉域での提供
    • セキュリティ担保

会場散策

• オリンピックのトーチ

  

  Read more

http://docomo-rd-openhouse.jp/2020/

まさかビッグサイトが2箇所あるとは知らず、東京ビッグサイト駅で降りてどこで開催されているかわからず、そしてここじゃないということに気づいた。

https://freee-tech-night.connpass.com/event/157012/

会計freeeのデプロイを10倍早くした話

北川修平 (shuheiktgw)

• 会計freee

• Phusion Passenger
  • https://www.phusionpassenger.com/
• Capistrano を使ったデプロイ
  • 問題点
    • 直列デプロイ
      • LBから１つづつ外してデプロイしている
    • 50分ちかくかかっている
  • 解決案
    • EKSへの移行
    • AutoScalingGroupを使ったBlue/Greenデプロイ
      • サーバー自体のプロビジョニングに４分ぐらいかかる
    • アプリケーションサーバー（unicorn）によるホットデプロイ
      • これを選択
      • デプロイ・ロールバックの時間が短くて済む
• アプリケーションサーバーの入れ替え
  • Phusion PassengerをUnicornにした
  • 安全に入れ替えるには
    • 影響範囲が大きい
    • プランBの確保
      • Blue/Greenを用意
    • 変更対象を深く理解する
      • ソースコードリーディング
      • 起動から陸セストをさばき始めるまでの流れ
      • USR2シグナルを受け取ったときの処理
      • 各パラメータの使われ方と影響範囲
• PreloadによるFileDDescriptorの共有
  • Linuxのfork処理の理解が必要
• 段階的リリース
  • テスト環境での負荷試験
    • 「負荷試験コトハジメ」
  • 他サービスでの先行リリース
  • 本番環境でのカナリアリリース
    • 2%程度
• Unicornへ移行した結果
  • 25〜30分かかっていたのが2〜3分に短縮
    • デプロイ数の増加
  • Redisまわりで一部問題があった
• FusionPassengerの有料版なら同じことできるが、サービス規模で試算したら高額だった

データの構造から再検討するパフォーマンスチューニング

久保卓也 (tkuboma)

• 会計freeeの中の話
• 監視
  • Mackrel
  • NewRelic
  • Monyog
    • DBリアルタイム監視に利用
  • Datadog
• Redashで見えるか
  • index効率、フルスキャンなど
• DBパフォーマンス改善
  • indexでチューニング
    • explainで地道に
    • インデックス追加したり、使うようにしたり
    • ActiveRecordのscopeに注意
    • indexを無駄にはらない
    • 検証は本番相当のデータで
  • クエリの変更でチューニング
    • 対象データのrowが多すぎる
      • 抽出条件の追加
    • クエリの結果が変わらないように注意
      • アプリケーション側で頑張る
  • データの持ちかたの見直し
    • idでなくstringでjoinしているテーブル
    • マスターデータとunionしている
      • マスターデータをコピーしてしまう
    • 頻繁にマスターデータが更新されるテーブルだと使えない
      • 設計でカバー
  • テーブル構成の見直し
    • 大量データを都度集計している
      • 集計テーブルを作成する
        • 圧縮率＝削減行数
    • ロック問題
      • 別トランザクションにして非同期実行する
        • Kinesis streamを利用
    • 集計テーブルのデータの切り方の設計重要
    • リアルタイム性の低下
    • 導入までのリードタイムが結構かかる
  • 機能の見直し
    • 必要以上に実行されていないか
      • Home画面とか
    • ビジネスサイドとのコミュニケーション必要
  • slaveへ逃がす
    • レプリケーションのラグに注意
    • 社内ライブラリを使用（OSSではない）
  • N+1の解消
    • bullet
  • Elasticsearch化

エンジニアがドメインロジックに集中するためのコアパッケージ整備

志賀誠 (@Maco_Tasu)

• コアパッケージ：各サービスで共通して使われるもの
  • ロガーやエラーとか
• マイクロサービス化でgoを使うことが多い
• マイクロサービス基盤にK8sを採用
• マイクロサービス化で各チームでそれぞれ作り込んでいて横連携ができていなかった
  • サービス基盤
• 全マイクロサービスのコードを読んで機能を洗い出す
  • goらしい作りになっているか
• デファクトとしてのパッケージ
  • 強制するものではない
• 拡張性
  • ダッグタイピング
  • go-cloud（CDK）を参考にした
• かんたんに組み込める
  • 依存関係
  • wire（DIツール）を使う
    • 依存の依存も解決してくれるのが良い
    • https://developers.freee.co.jp/entry/service-infra-and-wire
• 改善点
  • 早めに提供して改善ループをまわす
  • 使うことによる利点を伝える
• claat
  • チュートリアル作成ツール
  • https://github.com/googlecodelabs/tools/tree/master/claat

https://shuuu-mai.connpass.com/event/155130/

初参加。 エンジニアのキャリア、組織論についてお話いただく回とのことです。

きました pic.twitter.com/uRtdj6xWH2

— umemak (@umemak8) December 19, 2019

柱が邪魔でトークセッション見れない疑惑。

18:30 開場・受付開始

19:00~19:15 主催者からのご挨拶・当日のプログラムご案内

19:15~20:00 CTOトークセッション ※リアルタイム質疑応答あり！

株式会社SmartHR CTO 芹澤雅人氏

株式会社FiNC Technologies 代表取締役CTO 南野充則氏

株式会社クラウドワークス執行役員 兼 エンジニアリングDiv GM 飯田 意己氏

モデレーター 安尾 友佑 氏＊dely株式会社 サーバーサイドエンジニア

• なぜCTOになることを選んだのか
  • 南野：最初からそういう役割で参画した。
  • 芹澤：不可抗力的な感じ。VPoEから。VPoEになったのも不可抗力（前CTOの退職がきっかけ）。
  • 飯田：前CTOの退職がきっかけ。あえてCTOとは名乗っていない。
• どうやったらなれるのか
  • スタートアップに行けば不可抗力的になれる（笑）
  • 技術力だけではなく、ソフトスキルも必要。ビジネスとかマネジメントとか。
  • 経営も理解しないといけない。
• 今までの人生で一番影響を受けた本
  • 南野：「CEO」
    • 役職についてからどうあるべきかが書かれている
  • 芹澤：「ハッカーと画家」
    • 今でも通用する内容
    • ネットでも読める（？）
  • 飯田：「エンジニアリング組織論への招待」
• 良いエンジニアとはどんなエンジニアか
  • 南野：サボるのがうまいエンジニア
    • できるだけ楽に成果を上げる
  • 芹澤：課題にフォーカスした行動ができる
    • 技術は手段でしかない
  • 飯田：考えを表明できる
    • 周りを巻き込んでいく
• エンジニアの採用で見ているところ
  • 南野：マインド（価値観、こだわり）
    • ものづくりの原体験
    • ものをつくることを楽しめる
  • 芹澤：課題解決のプロセス
  • 飯田：結果よりプロセス
• エンジニアの評価について
  • 南野：行動指針の360度＋OKR
    • 評価が難しいと思ったことはない
    • エンジニアの人数比率が多いとやりやすい印象
  • 芹澤：OKR（半年ごと）
    • 成長につながる目標を設定する
    • 定性的な結果をどう評価するか
  • 飯田：MBO
    • 目標設定
• 今後エンジニアに求められることとは何なのか
  • 南野：技術、VPoE、プロダクト
    • テックリードとして。会社のどこを伸ばすのか。強みはなにか。そこに自分はどう関わるのか。どんな知識が必要なのか。
  • 芹澤：スペシャリストを目指すor浅く広くやるか
  • 飯田：責任を持てる範囲を広げていこう
    • 影響範囲を広げていく

20:00~20:15 スポンサー様ピッチ

CBcloud株式会社

• 物流系スタートアップ
• 課題
  • モノリス
  • toC向け

株式会社LegalForce

• 法律×テクノロジー
  • 契約書レビューシステム
    • アップロードすると、修正箇所と修正例を出してくれる

株式会社オープンエイト

• 素材から動画を生成する

freee株式会社

• 会社紹介

20:15~21:15 まつもとゆきひろ氏講演「エンジニア・キャリアアップ」

• 桜を見る会の招待もらった
• 「へびのように賢く、鳩のように素直であれ」
• Ruby開発までの話
  • バブル崩壊
  • 社内ツール開発からのチーム解散
  • 保守している間に作った
  • 自分のためのツール
  • クラスとインスタンスどっちが先問題
  • emacsのソースコードを一番参考にしていた
• 言語と思考の関係
  • サピア・ウォーフ仮説
    • 人々の思考は使っている言語に影響される
• へび
  • 自由であることとコントロール意識
  • 叱ると生産性60%低下
  • 叱られることはコントロールできていないこと
  • コントロール意識で生産性向上
  • 環境、未来は変えられないが、意識を変えることはできる
  • コントロールできないものと戦わない
  • 変えられないものは変えられない
  • 伝えないことは伝わらない、伝えたことも伝わらない
  • 諦めの気持ちが大事
  • 雨の予報は変えられないが、備えることはできる
  • 他人の態度もコントロール不能
    • 自分の受け止め方はコントロール可能
  • 「There must bu a reason」を３回唱える
  • できないことに心を傷めない
  • 未来予測
    • ソフトウェア開発者としては「上がり」のいちにいるので「現状維持」
    • Rubyが落ちぶれないようにする
    • できることに集中する
  • 「正解」もコントロールできない
  • 正解がある分野都内分野
    • ないぶんやで正解を追い求めることは無駄
    • 正解がないことを認める
  • 「浅く広く」と「深く狭く」は両立できない
• 鳩
  • 何が流行るかわからない
  • 運の要素
  • 未来予測に依存する判断を避ける
  • 判断基準
    • 実績、ライブラリ、相談できるヒトの有無・・・
    • 本能、勘
    • 「好き」な技術を
      • 外れても学ぶことはある
  • 本能や勘には自認が要る
    • 自分の興味、傾向を棚卸しする
    • 「好き」を知る
    • コネクティング・ドット
      • ３点→面
  • 「期待に応えない」
    • 勝手な期待
    • 外から来る動機は弱い。内からの動機は強い
    • 他人を動機にしない
    • 他人を制約にしない
• モチベーションの外部化はうまくいかない
• 後追いではないキャリアを
• 「鶏口牛後」の時代

21:15~21:25 アンケート回答/お写真撮影

21:25~21:55 懇親会 ※本物のシューマイ出します!!

22:00 完全撤収

今回はCMS回です。Webサイトの基本ともいえるCMS（コンテンツ・マネジメント・システム）におけるPWA活用法を学びましょう！

https://pwanight.connpass.com/event/156622/

きました pic.twitter.com/Fb0SO391qZ

— umemak (@umemak8) December 18, 2019

19:00 開場

19:20 挨拶&PWA Nightについて

• 2/1 PWA Night Confernce
  • タイムテーブル公開しました
  • LT応募これから
  • まだチケット買えるよ

19:30 自己紹介（全員）

• 本当に全員やった（持ち時間10秒）

19:40 microCMSとPWAで創るウェブ開発の未来

ウォンタ株式会社 松田承一（@shoma2da）さん

• https://speakerdeck.com/shoma2da/microcmstopwatechuang-ruuehukai-fa-falsewei-lai
• https://microcms.io/
• ヘッドレスCMS
  • 管理画面とDBを持って、出力はAPIを用意する
  • 全体ではなく、画面の1部のみCMS化できる
  • サイネージで使ったり
• 日本ではWPが強い（非ヘッドレス）
• 管理画面はReact/Reduxで使ったSPA
• インフラはAWS Amplify
• デモ
  • フォームの項目は管理画面で定義する
  • 「コンテンツ参照」が特徴的
  • 管理画面でAPIプレビュー（JSON表示）ができる
  • HTMLのtemplateタグ初めて見た
• 5Gでネイティブアプリのインストールが容易になったとき、PWAの立ち位置はどうなるか

20:00 WordPress と SSG で作る、情報発信サイト の JAMstack な PWA

lulzneko (ラルズネコ)さん

• WPは世界の30$のウェブページで使われている
  • WPで色々やろうとするとPHPの知識なりスキルが必要になってくる
• SSG(Static Site Generator)
  • ServerSideRenderingの対義
• JAMstack
  • JavaScript + API + Markup
  • パフォーマンス、コスト、スケーリング
  • セキュリティ
  • データとHTMLの分離
• こういう使い方をするならば、WPもヘッドレスと言える
• コンテンツ管理システムとしてのWPの強みを活かす
• WPの運用どうする問題
  • マネージドWPを使う

20:20 休憩

20:25 Firebase、Flamelink、Nuxt、Netlify、PWAを使ってJAMstackなブログを作る（仮）

みやおかさん

• https://slides.com/masayakazama/pwa-night-cms#/
• https://flamelink.io/
• ヘッドレスCMSはプレビューがないのが課題
• CSR with Prerendering
• 1年運用した感想
  • 開発者側は楽
  • 編集者側はいまいち
    • 管理画面使いづらい
• CMSのデモ
  • https://studio.design/ja
  • なんかすごい
  • 開発中

20:45 LT-1

hissyさん（5分）

• https://speakerdeck.com/hissy/introducing-concrete5-pwa-add-on-japanese
• concrete5 CMSのPWAアドオン
• 100ドルで試せる

LT-2

mercyさん（5分）

• https://www.slideshare.net/bitpart/pwa-night-vol11-20191218
• 「漢はコピペ」

21:05 懇親会

21:55 片付け

22:00 終了