「Cloud Native Meetup Tokyo #6」に参加してきました

勉強会メモ
  • Cloud Native Meetup Tokyo #6 KubeCon + CNCon Recapに参加してきました。

cloudnative.connpass.com

  • あまり詳しい領域ではないですが情報キャッチアップのために参加しました。
  • みなさん説明が論理だっていてわかりやすく雰囲気をつかむことができました。資料公開されているものは改めて確認したいと思います。
タイトル 発表者
Cortexの話をKubeConで聞きたかったっていう話 Shinya Uemura(@uesyn)
KubeCon + CNConに見るetcdの未来 Akihiro Ikezoe(@zoetro)
Monitoring Kubernetes Audit Log by Falco Makoto Hasegawa(@makocchi)
KubeCon + CloudNativeCon 2018 Seattle Recap ~Vitess~ Yutaka Ichikawa(@cyberblack28)
KubeCon + CNConでみたPrometheusの今後 Yoshi Shota(@yosshi_)

Cortexの話をKubeConで聞きたかったっていう話

  • Shinya Uemura(@uesyn)
  • KDDI & Creationline

KubeCon

  • Cortexのセッション一つ

Prometheus

  • メトリクス収集してローカルストレージに保存する
  • Long-term Storageではない

Cortex

  • Prometheusメトリクスのストレージ
  • マルチテナント型のモニタリングサービスを実現する

アーキテクチャ

  • 長期データS3やGCSに保存
  • chunkデータはDynamoDBやCassandraに保存

github.com

マルチテナント

  • リクエストヘッダ内のIDでテナント判断
  • テナントIDをもとにprometheusがふりわけ
  • 認証認可の機能はないのでIDを付与して送る実装を自前でする必要がある

kubernetes上で動かす

  • 「人類にははやすぎる」
  • まだリポジトリにreleaseブランチないしtagもついてない
  • 公式の入門ドキュメントまだない
  • フロント自前実装しないとマルチテナント使えない
    • nginxでやると楽だった

まとめ

  • cortex情報まだ少なめ

KubeCon + CNConに見るetcdの未来

  • Akihiro Ikezoe(@zoetro)
  • Cybozu

KubeCon

  • KubeConでetcd関連のセッション5つ

etcd

  • 分散キーバリューストア
  • HighAvailable
  • 強い整合性
  • Raftによる分散合意
  • k8sやVitessやCoreDNSなど多くの分散システムのバックエンドで使われてる

etcdの未来

  • CoreOS(Redhatに買収された)が作ってる
  • Container Linux
    • Fedora CoreOSが後継
    • 2020年いっぱいはメンテされる
  • rkt
    • Redhatとしては開発ストップ
  • etcdは?
    • CNCFのプロジェクトに採用
    • RedhatからCNCFに寄贈
    • CoreOSの外のメンテナ多いので体制に変化はなさそう

etcdの新機能

  • Raft Learner
  • etcd operator
  • Server Downgrade
  • Cluster init

Raft Learner

  • etcdはRaftという分散合意アルゴリズムを使ってる
  • クラスタからリーダーを選出
  • リーダーがメンバーにハートビート
    • リーダーは常に一つ
  • 問題点
    • データ同期中はI/O負荷高い
    • 同期中にネットワーク分断すると障害起きてしまう
  • Raft Learner
    • 同期中はLearnerという状態になる
    • その間は分散合意のメンバーとしてカウントされない

Cluster init

  • etcdの起動オプションいろいろ設定めんどくさい
  • 自動的にメンバーごとの名前やリッスンするアドレスなどを解決

etcdadm

  • etcdの運用大変
  • k8s上にetcdクラスタの運用
    • etcd operator
  • etcdadm
    • 実機やVMで動かしているときに使う
    • k8sに特化
    • etcdのクラスタの構築運用を自動化してくれる
      • メンバー追加/削除
      • バックアップ/リストア
      • アップグレード/ダウングレード
      • 証明書の管理

トラブルシューティング

  • etcdctl
  • auger
  • etcd-dump-logs

まとめ

  • etcdはk8sをはじめいろいろなところで使われている
  • CNCFに加わりメンテは安心して良さそう
  • 今後は運用者向けに嬉しい機能が出てきそう

Monitoring Kubernetes Audit Log by Falco

概要

  • Falco Deep Diveのセッション内容の紹介

Falcoとは

  • Container Native Runtime Security
  • コンテナ環境のセキュリティをモニタリング
  • CNCFのsandboxプロジェクト
  • モニタリングするだけ遮断とかはしない
  • 検出された時には手遅れだけど検出できる仕組みをつくることは重要

モニタリング

  • DKMS(Dynamic Kernel Module Support)によってmoduleがbuild/installされる
  • Ruleをyamlで書くことでモニタリングするイベントを定義

通知

  • 検知時にプログラム実行できる
  • webhookすればslack通知なんかもできる
  • Falco.yamlに設定

medium.com

k8sのaudit logをモニタリング

  • k8sのaudit log
    • k8s APIの呼び出しを時系列に記録
      • 怪しいリクエストの調査
      • 統計情報の収集
    • ファイル書き出し以外も対応(webhook等)
  • GKEではdefaultで有効になってる

k8sにfalcoを入れる

  • docker runでも動く
  • Helmのchartがあるのでそれが楽
  • falco operatorもある

KubeCon + CloudNativeCon 2018 Seattle Recap ~Vitess~

  • Yutaka Ichikawa(@cyberblack28)
  • APC

セッションサマリ

  • KubeCon
    • Vitess関連は3つくらい
    • 移行事例のセッションも
    • Intro
    • Deep Dive

Vitess

  • MySQLのshardingで水平にスケールするクラウドネイティブなDBクラスタ
  • goで出きててgRPCで通信
  • 事例
  • Sharding
    • 2つ以上のDBに分割してデータを格納
    • パフォーマンス向上
    • 垂直
      • テーブルごとに複数DBに格納
    • 水平
      • 1つのデーブルを複数Shardに分割して格納

HubSpotの事例

  • 10年間AWSを利用
    • 30日でGCP + k8s + Vitessに移行
  • なぜ？
    • シャーディングが魅力的だった
    • k8sとの親和性
    • OSS
  • 500データベースをアップデート

まとめ

  • youtubeの実績は強い
  • プロダクション事例増えつつある
  • k8sとの親和性の高さ
  • システムに合わせてチューニングは必要
  • Vitess as a Serviceなるものが生まれてきそう!?

KubeCon + CNConでみたPrometheusの今後

  • Yoshi Shota(@yosshi_)
  • NTT Communications

Prometheusの課題

  • 長期保管機能ない
    • 保管期間のばすと性能劣化
    • -> アダプターを使ってサードパーティストレージに保存
  • デフォルトで冗長構成がない

長期保管

  • Thanos
  • Cortex
  • M3

Thanos

  • 複数のPrometheusを横断して収集したい
  • 無制限に保管したい

Grafana Loki

  • ログの収集と可視化ツール
  • メトリクスだけではインシデントの全容の半分しかわからない
  • メトリクスとログの参照切り替えコストを最小限に抑える
  • まだAlpha版なのでproductionでは使っちゃだめ

Demo

https://grafana.com/video/loki_intro.mp4

「第１回AtomicDesignについて考える会」に参加してきました

勉強会メモ
  • 第１回AtomicDesignについて考える会に参加してきました。

thinkatomicdesign.connpass.com

  • AtomicDesignに関して様々な視点からの考えが聞けて学びが多かったです。
  • エンジニアとデザイナーあわさって、共通の考えを持って取り組むのがよいという意見が多かったです。
  • AtomicDesignにこだわりすぎずプロジェクトの中での共通認識のベースにしていくというのが良さそうと感じました。
  • パネルディスカッションでの質問の多さからもみんな悩んでるんだなってのを実感できました。
タイトル 発表者 ロール
コンポーネント指向から見るAtomic Design camcam_lemon (camcam_lemon) フロントエンドエンジニア
デザイナー・エンジニアのコンポーネント分割境界と、その理想郷 resessh (resessh) フロントエンドエンジニア
AtomicDesignを導入する理由と悩み sakito (mki_skt) フロントエンドエンジニア
手戻りが少ないアトミックデザインの導入 fujiken (kenshirof) デザイナー
Redaing The Atomic Workflow 腹筋ローラーの力を信じろ (8845musign) デザイナー
StorybookでAtomicDesignなコンポーネント管理してる話 masaya (msykd) フロントエンドエンジニア
サーバーサイドエンジニアがAtomicDesignを学んでみた remsleep_zzz (remsleep_zzz) サーバーサイドエンジニア
Atomic Design との上手な付き合い方 takanorip (takanori_oki_9) フロントエンドエンジニア

コンポーネント指向から見るAtomic Design

  • camcam_lemon (camcam_lemon)
  • フロントエンドエンジニア

AtomicDesign

  • 考えること多い
  • よく分かってないままアプリ単位で採用してるから
  • チームに合った設計を取り入れるのが正解ではないか

コンポーネント指向

  • UIパーツを部品として使う
  • 見た目と機能をカプセル化
  • 粒度が小さいほど再利用性が高まる

UIライブラリ

  • よく使うUIパーツを提供
  • AtomsかMoleculesを提供する
  • 再利用性に極振り
  • ロジックは入り込まない
  • UIライブラリのパーツに加えて再利用されないAtomsやMoleculesをアプリで作る

まとめ

  • 小さい単位で考えると悩みが減る
  • 再利用性に特化したUI設計に集中
  • 小さく始めて大きくスケール

デザイナー・エンジニアのコンポーネント分割境界と、その理想郷

  • resessh (resessh)
  • Retty
  • フロントエンドエンジニア

デザイナー視点

  • ユーザ行動をベースに考える
    • 画面を開いて関心のあるコンテンツを探す
    • コンテンツを理解
    • 手順を理解
    • アクションを実行する

エンジニア視点

  • コンテンツ内のレイアウトとコンテンツ外のレイアウト
    • 外 -> サイドバーとかヘッダーとか
  • データソースが決まったコンポーネントとそうでないコンポーネント
    • Storeにアクセスできるかどうか
    • Container Component / Presentational Component

コンポーネントの分類

  • Organisms
    • URLを持っていることが多い
    • アクションも付随していることが多い
    • 特定のデータソースに依存してもよい
  • Molecules
    • コンテンツが一つで完結しない
    • 特定のアクションを行うUI
    • 特定のデータソースに依存しない
  • Atoms
    • HTMLのタグに対応
  • 迷う時は
    • デザイナーとエンジニアが分類について対話できる環境があるとよい

AtomicDesignを導入する理由と悩み

  • sakito (mki_skt)
  • Yahoo
  • フロントエンドエンジニア

なぜ導入したか

  • デザイナーとエンジニアでコンポーネント分割の考え方が違う
  • 人数が多くて指標がなかった
    • 個人に依存
  • 導入して指標ができた

導入して抱えた悩み

  • PagesとOrganismsどの単位でReduxをConnectするか
    • プロジェクトの規模によりけり
  • AtomsなのかMoleculesなのか
  • エンジニアだけで導入してもダメ
    • デザイナーのアウトプットとの認識齟齬があってはいけない

まとめ

  • デザイナーとエンジニアで密にコミュニケーションをとる大事さは変わらない
  • チームにフィットした形で柔軟に返ることも大事

Redaing The Atomic Workflow

  • 腹筋ローラーの力を信じろ (8845musign)
  • デザイナー

The Atomic Workflow

  • 静的なカンプではなくブラウザに早く持っていくべき
  • Role
    • UX Designer
    • Visual Designer
    • Frontend Developer

UX Designer

  • コンテンツの並びを書いたもの
  • ページの構造と階層
  • レイアウトを作らずに議論できる

Visual Designer

  • The 20 second gut test
  • Style Tiles
    • 色とかフォントとかをまとめたもの
    • ビジュアルの洗練なしにレイアウトについて検討できる
  • 静的カンプ
    • 作らないわけではない
    • 全体像を描くのには有効
    • 段階が進んでからかく

Frontend Developer

  • デザイナーと近い席に座るべき
  • デザインプロセスのコアパート
  • 先行してマークアップしていくべき

ワークフロー

  • ブラウザでイテレーションすること
    • 一度ブラウザでデザインしたらブラウザにとどまり続けるべき
    • 意思決定を動くものでするべき
  • パターンベースで回す
    • 使い回せる

まとめ

  • ブラウザで生きた設計を
  • 常に全体を見て設計を
  • AtomicDesignの本質はステークホルダー全員との合意形成プロセス

手戻りが少ないアトミックデザインの導入

開発初期

  • 新規事業でAtomicDesignを導入
  • デザイナー一人
  • デザインデータが管理しきれなくなる
    • このデザインどっかで使ってたけどどこかにあるか分からん

導入前

期待

  • 管理が楽になる
  • 使い回しの適用がしやすくなる
  • スピードがあがる

導入してみて

導入するなら

  • カトナ期待はせずに
  • 定期的な整理整頓が待ってる
  • 整理で進捗が止まることを伝えておこう

導入中

  • 整理整頓そんなにうまくいかない
  • 整理整頓してる暇がなくて大きくなってしまう
  • コンポーネント化しすぎて無駄に時間かけすぎた
    • 適度にやることが大切

導入後

  • 曖昧さを許容すること
  • コンポーネントの粒度どうしてますか?
    • デザイナーとエンジニアで話し合ってる
    • 見てる視点が違うから理解し合うことが大切
  • 最初は特定の動作に特化した部品
    • 徐々に汎用的な部品に
  • ほとんどのデザインはすぐに消える

まとめ

  • 導入前：覚悟をもとう
  • 導入中：タイミングと量に注意
  • 導入後：曖昧さを許容しよう

StorybookでAtomicDesignなコンポーネント管理してる話

  • masaya (msykd)
  • モノオク株式会社
  • フロントエンドエンジニア

モノオク

  • モノの保管場所に困ってるユーザとスペースが余ってるホストをマッチング
  • React/Redux

Storybook

Storybookいいところ

Storybookつらいところ

  • メンテがめんどくさい
  • 開発に追われていると時間がない
  • コンポーネントマネージャーをおいた

まとめ

  • Storybook便利
  • 1,2人くらいのチームだとメンテコストのほうが高い
  • 他と比べてメンテの優先度下がりがち
  • 目的をもって運用方針を考えるべき

サーバーサイドエンジニアがAtomicDesignを学んでみた

  • remsleep_zzz (remsleep_zzz)
  • CyerBuzz / STARACT
  • サーバーサイドエンジニア

導入事例

  • うまくいった
    • デザイナーがReactかけたり
    • フロントエンドがAPI書いたり
    • といった環境だったから

サーバサイドから見ていいところ

  • 共通言語として使える
    • 学習コスト少し高い -> 習得後のブレが少ない
    • プロジェクトの途中から導入するるのはとても大変
  • 開発速度の向上
    • organismsとpagesだけにstateをもたせる
    • それよりも小さい粒度はstatelessなので爆速で作れる
    • Reduxみたいなところはフロントエンドエンジニアにまかせてコンポーネント単位で作り込める

まとめ

  • サーバサイドエンジニアからみてAtomicDesignのメリット
    • 共通言語としての役割
    • 粒度間違えなければ開発爆速

Atomic Design との上手な付き合い方

  • takanorip (takanori_oki_9)
  • フロントエンドエンジニア

思うこと

  • AtomicDesignに真面目すぎる
  • 設計の手助けのはずが難しくしている
  • 大雑把に付き合うことが大切
    • そこが本質ではない

意識すること

  • 最小単位(Atoms)を意識すること
    • それ以外はある程度全体見えてきてからでよい

なぜつらい

  • 考えることが多いから
  • ルールを整備することで考えることを減らせる
  • 再利用しないものとしてコンポーネントを作る
    • 共通化しすぎると捨てづらくなる

責務を分ける

  • Pages/TemplatesとOrganisms以下の責務の分離

デザイナーを巻き込むこと

  • エンジニアだけでこういう話をするのは良くない
  • デザイナーにAtomicDesignの概念をフローに入れてもらう
  • 単位はデザイナーに決めてもらうのがいい

コンポーネントのデザイン

  • デザイン管理はFigmaが優秀
  • StoryBookもあるけどデザイナーが使うことも考えるとFigma

パネルディスカッション

  • コンポーネントガイドないとつらいですか？
    • レビュアーがつらい
    • PR出された時にそれもうありますって言えないとつらい
    • Storybookはディレクトリ構造をしっかり練ることが大切
  • コンポーネントの命名規則
    • MoleculesはInputWithButtonのようにelement名をつけるようにするとわかりやすい
    • 使う時はSerchFormみたいな名前になるかもしれないけど

「Repro Tech : Frontend Reliability support NAVITIME」に参加してきました

勉強会メモ
  • Repro Tech : Frontend Reliability support NAVITIMEに参加してきました。

repro-tech.connpass.com

  • フロントエンドのreliabilityがテーマということでリアルな開発現場の苦労話を多く聞けました
  • Reproのイベントでしたが半分は豪華なゲストスピーカーということでバランス良かったです
タイトル 発表者
E2Eテストを継続するために brn
ReproのWeb SDK開発を支える技術 cheezenaan
続・Vue.jsによる大規模開発 kazupon
フロントエンド開発の土台としてのチーム作り 渡部啓太
クックパッドにおけるwebフロントエンドの改善 @hokaccha
フロントエンドと向き合う @treby

E2Eテストを継続するために

E2Eテスト

  • ユーザと同様に操作して機能を確認するテスト
  • Selenium等で自動で打鍵
  • メリット
    • ユーザが触る画面を直接テストするので確実性高い
  • デメリット
    • 遅い
    • アニメーションとかAPIアクセスとか遅い
    • 謎のエラーで失敗したり不安定
    • メンテナンス大変

E2Eのメンテ

  • CSSセレクタでDOMを選択
    • 変化が多いから大変
  • styled-components使ってるとE2E用にクラスつけないと
    • 自動生成のクラスが付与されるから
  • -> 放置されがち

デメリットの解決策

  • 遅い
    • アニメーション等はクラス名変えて停止してテストするとか
  • 不安定
    • リトライ入れて対応する
    • BrowserStack等外部環境を利用するとか

メンテナビリティ

  • メンテナビリティを実現するにはHTMLの構造に立ち入らないこと

VisualRegressionTest

  • スクショとって画像で比較
  • 前回と比較して変化がないかテストする
  • 変更ないのに差分検知してしまうことも
  • 失敗した理由がわからない
    • 結果しか見えないから
    • 目で見るようにする
    • 部分実行できるように作る

ブラウザ操作レイヤーの抽象化

  • ページ遷移とかはボタン押したりするのでHTMLの構造に依存してしまう
  • Graph Based PageObject
    • ユーザの操作単位でメソッドをきる
    • 部分的な実行もしやすくなった

まとめ

  • CIの整理やレビュー体制等のプロセスが大事
  • プロセスがアウトプットの品質を決める

QA

  • E2Eどれくらい時間かかってる？
    • CIで回してて30分くらい
    • mergeするタイミングで回してる
  • IE対応どうしたらいい？
    • BrowserStack使うか
    • Windowsサーバ立てるか
    • IEだけ手動でもいいと思う
  • SeleniumIDEどう?
    • その時通るテストしか作れないから手直し出てしまう
    • 雛形作るものとしては使えるかも

ReproのWeb SDK開発を支える技術

  • cheezenaanさん(Repro)

Web SDK開発

SDK

  • Software Development Kit
  • アプリ提供者向けの便利なライブラリ集

Web SDK

  • ブラウザ上でで動くSDK
  • ネイティブアプリと比べるとブラウザの分一層多い
    • ブラウザの種類・バージョンの差異がつらい

ReproのWeb SDKに求められること

  • 安心安全で信頼できるSDKを提供したい
  • なるべく多くのブラウザで動かしたい
  • プラットフォーム・バージョンどこまで対応する？？
    • ビジネス要求と開発リソース次第

実際の取組み

  • ほぼ最新Chromeを基準にGraceful Degradation
  • 標準化されてないブラウザAPIは過信しない
  • 外部ライブラリへの依存を極力減らす
    • 使ってるライブラリ
  • ファイルサイズは小さく保つ
    • polyfill入れるくらいなら自分で書く
  • UnitTest手厚く
    • ブラウザ差異はE2Eで
    • 浅く広く作ってる
  • E2E

まとめ

  • ブラウザという壁から逃げずに向き合うことが大事
  • 依存少なくテスト手厚く

QA

  • WebSDKのE2Eどんなことやってる？
    • サンプルアプリに適用してテストしてる

続・Vue.jsによる大規模開発

  • kazuponさん

Vue

中大規模向け開発

  • 複数人で開発する
  • 生産性やメンテナンス性を考慮
  • 最初からフルスタックにはサポートしない
  • 公式にライブラリは提供してる

開発環境セットアップ

Vue CLI 3

  • プラグインベース
  • 構築拡張メンテが楽
  • VueCLIのレールから外れることはできない
  • ts対応
  • prettier
  • cypress

Vue CLI UI

  • ブラウザ上でVueCLIでできることは一通りできる
  • プロジェクト管理
  • GUIベースで設定
  • コマンドライン苦手な人に優しい

その他

  • VSCode + Vetur(VSCodeのプラグイン)
  • eslint-plugin-vue
  • 通信
    • REST -> axios
    • GraphQL -> vue-apollo
  • 状態管理
    • VuexはTSだとつらい
  • E2Eテスト
    • cypressも使えるようになった
    • NightWatch

アプリ設計

コンポーネント設計

  • AtomicDesignに従いSFCを抽出
  • 秩序がたもてるなら無理にAtomicDesignに従わなくてもいいと思う

状態モデリングとデータフロー

  • UI使用から状態に落とし込む
  • モデルとAPI仕様はバックエンドと認識齟齬ないように工夫が必要
    • swaggerやOpenAPI Generator
    • Consumer Driven Contruct

ルーティング設計

  • スクロール位置喪失問題

アプリ実装

  • TS入れるといい
    • VueCLI3なら簡単に導入できる
  • TDD
    • テストはjestを推奨
      • スナップショットテストが便利
    • コンポーネント、データフロー、ルーティング全部TDDやる必要はない

デバッグ

  • Vue Devtools 5でより便利に

まとめ

  • VueCLI3で環境構築が楽になった

フロントエンド開発の土台としてのチーム作り

組織作り

  • すべての人間が同じ方向を向くことが大事

以前

  • お互い何をやってるか分かってなかった

やったこと

  • 情報の同期
    • ファイブフィンガー朝会
  • 情報の共有
    • 自分は何が得意
    • 何を期待する
    • 偏愛マップ
    • 自分の取説
    • スキルマップ
  • 目的の明確化
    • 我々はなぜここにいるのか
  • 毎週振り返り

今後

  • ビジネスサイドとの協働
  • 高負荷の解消

まとめ

  • チーム力は開発力の土台
  • チームと個人を向き合わせる
  • 振り返りでカイゼン

クックパッドにおけるwebフロントエンドの改善

クックパッド

  • Rails化して10周年
  • いろんな負債が積み重なってる

クックパッドのフロントエンド

  • Performance
  • Productivity

performance

techlife.cookpad.com

Productivity

  • 生産性をいかに上げるか

エラートラッキング

  • 全社的にsentry使ってる
  • ノイズがひどいので対応中

コードの整理

  • 現状
    • どこに何書いてあるか分からん
  • 対応
  • 既存コードを動かしながら対応するのは大変

モダン化

今後

  • 各チームが自由にライブラリ選定できる体制にしたい
  • Micro Frontendとか
    • 理想だけど難易度高そう

フロントエンドと向き合う

  • @trebyさん(Repro)

フロントエンド

  • フロントエンドはこわれる
    • ES2015でまともになってきた
  • 変化が激しい
  • テスト充実させたい
    • フロントエンドは簡単に壊れる
  • 3つの柱
    • 技術
    • チーム
    • 根性

「UIT#5 わたしたちにとってのVue.js」に参加してきました

勉強会メモ
  • UIT#5 わたしたちにとってのVue.jsに参加してきました。

uit.connpass.com

  • UITは#2から毎回参加していて4回目の参加でした(#4の参加レポート)
  • 今回はVueにフォーカスした勉強会で、事例を中心に技術選択の参考になるお話を聞けました。
タイトル 発表者
ゆるふわに既存Vue(Nuxt)プロジェクトをTypeScriptに移行してみた @Motonori Iwata
カメラを利用したアプリを作って約1,000人で遊んだ話 @KenjiroKubota
jQueryからVue.jsへリファクタしたPJの話 @tak
さくらのフロントエンド さくらの Vue.js @ravelll
Vue.jsは裏切らない @Yuji Yamaguchi
building better Vue components with storybook @julien

ゆるふわに既存Vue(Nuxt)プロジェクトをTypeScriptに移行してみた

  • @Motonori Iwata

TSへの移行

  • 社内ツールをTSに移行
  • Nuxt
  • Firebase
  • コンポーネント23個
  • 新規開発は停止
  • 4週間で移行完了

移行の順序

  • components -> utils/plugins/middleware -> store -> test
  • testが通ること確認しながら

設定

  • tsconfig.json
    • alloJSは一時的にtrueで
    • implicit anyは弾く

Linter

  • Xoを使ってる
  • https://github.com/xojs/xo
  • 型引数にしか使ってない変数がエラーになる
    • no-unused-varsをoffにして対応
  • 結構罠がありそうだからTSLintの方がいいかも

Components

  • vue-shims.d.tsをおく
  • vue-convertを使ってclassに変換

Test

  • jest使ってる
  • ts用のjestを追加

カメラを利用したアプリを作って約1,000人で遊んだ話

  • @KenjiroKubota(株式会社アイスタイル)

社内のイベントでアプリを作った

  • 表情を検出して笑顔度を測るアプリ

技術

WebRTC

  • WebRTC API
  • videoのリソース開放も忘れずに
  • requestAnimationFrame()
      • beforeDestroyで都度終了させないと重くなっていく

まとめ

  • Vueはググれば情報豊富
  • VueCLIのおかげでwebpackの苦労が不要
  • Firebaseすごい

jQueryからVue.jsへリファクタしたPJの話

  • @tak(LINE)

背景

  • 古い技術スタックのプロジェクトを担当した
  • どうやってリプレイスしていったのか

現行とゴール

  • LINE Webログイン
    • SSOを実現するページ
  • 現行ページ
  • 新ページ(順次公開予定)

なぜ置き換える必要あったか

  • 既存コード
    • 複雑に絡み合っていた
    • 担当者のスコープや責任が明確になっていなかった
      • CSS/HTMLの変更でもサーバサイドに手が入る
  • データやイベント発火フローの確立
  • 今後のリッチなUIへの対応
  • jQuery -> Vue
  • VueCLI3
  • バックエンドではエントリーポイントのルートコンポーネントだけ作成

リプレイス方法

  • $('xxx').on -> v-on
  • $('xxx').hide -> v-if
  • 等々

移行の例外

  • グローバルなメソッドを使った暗号化処理
  • 無理せずそのままにした
  • 外部ライブラリ的に使えるようにした

まとめ

  • データフローが明確になって運用コスト下がった(はず)
  • リファクタリングが危険な道は回避することも大事

さくらのフロントエンド さくらの Vue.js

さくらのフロントエンド

  • サーバ屋さんのフロントエンド
  • Vueがけっこう使われている
  • Vueの使い所
    • コントロールパネル
    • 問い合わせ/申し込みフォーム
    • 社内向けツール

なぜVue

  • デザイナと協業しやすそう
  • 公式からツールが出てる安心感
  • 日本語ドキュメント充実

事例

  • サービスコントロールパネルを刷新した
  • メンテしづらく属人化
    • Vueにリプレイス

技術スタック

  • Vue + Vue Router + Vuex
  • SPA, 非SSR, 非Nuxt

ディレクトリ構成

  • components
    • storeにはアクセスしない
  • pages
  • plugins
    • アプリ全体の挙動を変更する実装
    • Vue.useして使うもの
      • Vuelidateとか
  • utils

エラー検知

  • Sentry
    • 導入簡単
    • 401(セッション切れ), 422(APIのバリデーションエラー)以外を記録

テスト

  • コンポーネントのテストは複雑なとこだけ
  • データフロー以外のロジックを含むStoreのメソッド
  • jest使ってる

パッケージアップデート

  • yarn upgradeしてPR投げるCIを週一で
    • これはマイナーバージョンだけ
  • メジャーバージョンは手動

困りごと

  • デザイナーとの協業
  • コンポーネントの細かい挙動をSketchで伝えるのが大変
  • storybookを導入しようとしてる

Vue.jsは裏切らない

事例

従来

  • jQueru製の独自FW(2014末)
  • BabelifyでES6化
  • 秘伝のタレの積み重ねで完成度は高い
    • でも継続性に不安

やったこと

  • Browserify -> Webpack
  • Grunt -> Gulp/npm script
  • Mocha -> Jest

心がけたこと

  • 小さく移行する
    • 稼働してるプロジェクトだから
  • 画面ごと部品ごとに
  • さわるところだけとかリファクタリングだけとか
    • I/Fが変わらないことが大事
  • レガシーコードでもロジックは資産

良かったこと

  • バックエンドから転向組でもスムーズだった
  • template/script/styleのSFCわかりやすい
  • 人材が少ない中で誰でもそれなりに

難しかったこと

  • 自由にできすぎる
  • やらないことを決めるのも大事

まとめ

  • 利益をだしてるサービスの継続性は重要
  • Vueなら徐々に移行できた

building better Vue components with storybook

  • @julien(LINE)

Atomic Design

Vueに適用

  • 親から子はproperty
  • 子から親はイベント
  • propertyは一番シンプルに
  • 兄弟要素で相互に通信するのはだめ
    • 親を介してやりとりする

Storybook

  • 簡単にインスール/セットアップできる
  • whiteroom
    • Vueで作ったStorybook
    • Storybookの足りないところがあったから自作した
  • Vueで作ってるからライフサイクルを意識する必要がない
  • イベントも全部見れる
  • propertyとeventを同時に見ることができる

「Cookpad Tech Kitchen #20 クックパッドのマイクロサービスプラットフォーム現状」に参加してきました

勉強会メモ
  • Cookpad Tech Kitchen #20 クックパッドのマイクロサービスプラットフォーム現状に参加してきました

cookpad.connpass.com

  • Cookpadにおけサービスメッシュ、gRPC、ECSの導入事例を紹介してもらいました。
  • gRPCやEnvoy等気になっているサービスの話を聞くことができて参考になりました。
  • 講演だけでなくQAセッションもあり、採用する技術に対する深い話も聞くことができてとてもよかったです。
タイトル 発表者
クックパッドでのサービスメッシュについて 小野大器
gRPC in Cookpad 岩間雄太
Amazon ECS の安定運用 鈴木康平

クックパッドでのサービスメッシュについて

背景

  • 開発者200+
  • サービス100+
  • 色んな開発チームとSREチーム
    • 運用をSREチームから各チームへ移していきたい

課題

  • 昔は大きなモノリシック
    • 今は100近いアプリが相互に連携通信している
  • マイクロサービス内でインシデント起きた時の特定が大変
  • キャパシティプランニングも難しい
  • 何が起きているか見えるようにしたい

解決策

  • Expeditor
  • aws-xray
    • 分散トレーシング
  • ruby以外も各々作って改善を続けていかないといけない
  • ネットワークプロキシを挟んでそこでやらせればいいのではないか
    • サービスメッシュ
    • 2017年ころから

導入と運用

  • 2017年はじめに計画
  • 2017年終わりにMVP作った
  • 2018年から利用

Envoy

  • 当時使えるもので一番良かった
  • Istioはまだなかった
  • AmazonECSを使っていた
    • IstioはKubeが前提だから使えないかも

ゴール

  • 各アプリで管理するのではなく中央で制御したい
  • メトリクスはPrometheus
  • 運用コストを抑えたい

運用

結果

  • 一時的なエラー率上昇がタイムアウトリトライの設定で回避できるようになった
    • SREチームの負荷が下がった
  • 設定が中央に集まったのでレビューしやすくなった
  • Observability
    • 情報が可視化されるようになった

QA

  • 冪等性をどう担保している
    • GET/PUTは自動でリトライ
    • POSTとgRPCはリトライできると分かったるものはリトライ
      • デフォルトはリトライオフ
  • Istio使わない?
    • 今の構成で安定してるから今はこのまま
  • マイクロサービスを導入するタイミングは?
    • 組織が大きくなってきてコミュニケーションコストが大きくなってきたとき
    • 明らかペイするのは2000人とかの規模

gRPC in Cookpad

これまでのCookpadのサービス感通信

CookpadでのgRPC

gRPC

  • IDLとしてProtocol Buffersが使える
  • Protocol Bbufferでクライアント/サーバのコード生成
  • 多言語対応
  • HTTP2上で動作
  • Interceptorでログ、認証、エラー処理など

gRPCの運用

  • 基本的にhako上で
  • cookpad.comでも使ってる
  • Envoy経由でリクエストを受ける

サービス定義(ProtocolBuffer)の管理

  • 1つのリポジトリで管理
  • サービスごとにディレクトリを切ってる
  • ciでlintも入れてる
  • ドキュメントもciで自動生成
    • protoc-gen-doc

メトリクス

  • Envoyコンテナでメトリクス取る
  • Prometheusに入れてGrafanaで見る

rubyでgRPC

  • grpc gem
    • C, C++で作られたものをRubyの拡張として使用
    • マルチスレッド(シングルプロセス)
  • grpc-tool gemでクライアント/サーバのコード生成
  • 公式のgRPC実装を使用してる

今後

  • Envoyの機能を使ったかなりあリリース
  • 自作gRPCライブラリへの移行
  • grpc-gatewayの導入

QA

  • gRPCをRESTで叩くことはしてない
    • gRPC使う時はクライアント/サーバどちらもgRPCでやってる

Amazon ECS の安定運用

前提

  • ほとんどのアプリがECSで動いてる
  • hakoを使ってデプロイやバッチ起動
  • ECSインスタンス 40
  • ECSサービス 500
  • 1日あたりのRun Task 80000

コンテナインスタンスの管理

  • オンデマンドインスタンスはAutoScalingGroup
  • スポットインスタンスはSpotFleet
  • オンデマンド:スポット=1:4
  • Fargate
    • 一部使ってるけど基本自前管理
      • 自前のほうが安いから
      • 起動が遅いし起動時間が安定しないから
    • 使うケース
      • ECSクラスタのオートスケールするジョブ
      • 特別大きいCPUリソースを使うジョブ

オンデマンドインスタンス

  • 自前でオートスケール
  • AutoScalingGroup

スポットインスタンス

  • オートスケールは自前
  • SpotFleet

オートスケーリング

スケールアウト
  • CloudWatchの値をチェックして閾値を超えたらスケールアウト
  • 各サービスの値をチェックしてスケールアウト
  • hako oneshotがリソース不足で失敗したときにSQSで通知を受け取ってスケールアウト
スケールイン
  • CloudWatchの値をチェックして閾値を下回ったらスケールイン

ログ

  • fluentd経由でS3に保存
  • Athenaで簡易検索できるようにしてる

CloudWatch Logs

  • 量が多すぎてピークタイムではリアルタイムにに入りきらない
  • スケーラブルで安価なS3を使うことに

ログ配送

  • 各コンテナからfluentdの集約ノードへ転送
    • 集約ノードには大量のログが来ることになる
  • 集約ノードのfluentdが1分毎にログをS3へ

ログ検索

  • Athenaで検索できるようにGlueでカタログを日時更新

モニタリング

  • CloudWatchにサービス単位のメトリクスはある
    • タスク単位やコンテナ単位はない
  • アプリ開発者はアプリコンテナのメトリクスだけ見たい
  • cAdvisorでメトリクスを取得しPrometheus送りGrafanaで可視化

QA

  • なぜECS?なぜkubeでない?EKSは?
    • 運用する人が多くないからできるだけマネージドがいい
    • EKSがECSくらい使いやすくなったら使うかも
      • 今はECSほどマネージドではない
      • 今すぐ移行するというほどではない

「HTML5 Conference 2018」に参加してきました

勉強会メモ
  • HTML5 Conference 2018に参加してきました。

events.html5j.org

  • 全部で30セッション以上あるカンファレンスでしたが、ほとんどが興味のある内容でとても充実したイベントでした。
  • Webパフォーマンスや最新のWebAPIやHTTP/3等、最前線の情報をキャッチアップできました。
  • このカンファレンスは全て有志で成り立っているとのことで、機器トラブル等あっても丁寧に対応していただき問題なくセッションに参加することができました。スタッフの皆さんありがとうございました。

タイムテーブルと資料のリンク

10:00 - 10:50

タイトル 発表者
基調講演 吉川徹、えーじ、岩井将行

11:20 - 12:00

タイトル 発表者
ZOZOのグローバルECのフロントエンドアーキテクチャ設計 権守健嗣
光を超えるためのパフォーマンスチューニング/アーキテクチャ mizchi
TypeScript Evolution 倉見洋輔
持続可能なプロダクト開発のために - フロントエンドと新陳代謝の話 花谷拓磨（potato4d）
ブラウザでARとAIを動かした話 杉井庸一
デザインを共有するための言語化あれこれ 長谷川恭久

13:20 - 14:00

タイトル 発表者
「それ、AMPで作りませんか？」--- RichでResponsiveかつPWAなAMPの作り方 宇都宮佑亮
FIDO認証によるパスワードレスログイン実装入門 合路健人
2018年のHTMLやCSSやAPIとか 矢倉眞隆
組み込みブラウザとMediaの仕様あれこれ 梅田雅士
使い倒そうVisual Studio Code! さっくる（本間咲来）
アクセシビリティ、はじめよう! 〜「できない」から脱出するための20（仮）のネタ🍣〜 山本和泉、太田良典

14:20 - 15:00

タイトル 発表者
Yahoo! JAPANアプリ上で動くWebVIewサービス開発〜Web技術で動くライブクイズ「ワイキュー」〜 石井直矢
PWAの導入で得られた成果と見えてきた課題 宍戸俊哉
Web Components のリアル aggre
TechFeedのつくりかた 2018 白石俊平
VOXELCANVAS：WebGLでのボクセルモデリングツール開発 ~ 開発ノウハウとブラジルの小学校で使ってもらえた話 津田良太郎
「セマンティクスの作り方、これまで、今、そして未来」 伊藤由暁（越智）、桝田草一

15:20 - 16:00

タイトル 発表者
コンパイルターゲット言語としてのWebAssembly、そしてLINEでの実践 Jun、kawasako
Node.js まとめ 古川陽介
Web プラットフォーム再考 ～PWA のもたらす未来の光と影 ～ ものえおさむ、eegozilla、chikoski
Angularを使用したWebアプリケーションの最新設計手法 松本洸
あんずフォト：PlayCanvasでリッチアドコンテンツを開発して発信してみた 宗形修司、津田良太郎
開発体制に合わせたCSS設計 吉川雅彦

16:20 - 17:00

タイトル 発表者
HTTP の今と未来 ー BBR, HTTP/2, QUIC の基礎から 5G 試験ネットワークでのブラウザベース評価試験まで 浅井智也、永井泰裕
webpackのいままでとこれから 廣戸裕大
Angular 製 高機能グリッドのパフォーマンス問題に立ち向かった（ている）話 - IE11、お前もか・・・ - 桐生逹嗣
Reactにおけるパフォーマンスチューニング 辻健人
WebXR: Beyond WebGL 小山田晃浩
さらに便利になった最新版SketchとMaterial Theme Editor 山本麻美

LT

タイトル 発表者
1000万以上のWebページを AMPにした話 Masashi Hirano
slamdata/purescript-halogen の紹介 @e_ntyo
CSS組版の救世主 Vivliostyle @spring_raining
ビルドプロセスから考えるCSSアンチパターン Kenji Imamula

基調講演

テーマ

  • The Web is shifting to the next gear
  • Webの進化がはやい
    • WebXR
    • Web Authentication

仕組みを作る仕組みを、作る仕組みを作る

  • 1ヶ月にWebにアクセスするデバイスの数 -> 50億
  • web is an infrastructure
    • 蛇口をひねれば水が出るのと同じ
    • ブラウザを開けばWebが見られる
  • 最新の技術
    • Video + Picture in Picture
    • WebRTC
    • WebXR
    • WebAuthentication
    • Web Asesmbly + Web Audio
  • 仕様の議論
    • github上でオープンに議論される
    • 各ブラウザベンダが最新仕様のステータスをオープンにしてる
  • Extensible Web Manifest
    • 低レベルのAPIをまず用意するという考え方
  • AMP
    • アプリに制約をもたせることで高速化
      • WebComponentsを活用してる
    • Googleのキャッシュから配信してるためオリジンがgoogleになってしまう
      • -> Web Packagingで解消
  • Web is thhe only platdorm no one owns

光を超えるためのパフォーマンスチューニング/アーキテクチャ

  • mizchiさん

大前提

  • この宇宙では光が遅すぎる
    • 海外と通信すると特に

フロントエンドのキャッシュ設計

フロントエンド技術の目的

  • 小さいスコープ
    • 部分的に60fpsを達成
  • 大きいスコープ
    • 通信を含めて遅延を抑える

16ms以上の世界

  • 構築済みHTMLをCDNで返すと速い
  • キャッシュがいろんな層にある
  • EdgeCacheにキャッシュしておく
    • 参照はキャッシュから返す
    • 更新されたらサーバがキャシュを更新
  • 小規模開発だと
    • CDN: Redis
    • Server: MySQL
    • と置き換えて考えてもいい

先読み

まとめ

  • ネットワークにアクセスしたら負け
  • CDNより先にアクセスしたら負け
  • DBでクエリ発行したら負け

16ms未満の世界

  • 途切れず連続していると感じる時間

最適化

  • 単純にライブラリの量を減らす
    • 展開する時間に1秒とかかかることも
    • ダウンロードの時間だけなく展開の時間も削ることを考える
  • lodashとかmomentとかでかいものを入れない
  • Dynamic Importを使う
  • レイアウト抑制
    • ヘッダーの連続性が重要

マイクロチューニング指針

楽観的UI

  • 常にリクエスト成功したことにする
  • 正常系にネットワーク上の分岐がない場合に使える

クライアントファースト

  • クライアントのデータ処理を優先する
  • サーバは単にsyncするだけ
  • 扱うデータが自己完結するケース
    • ゲームとかツールとか
  • firebase(firestore)と相性良し
  • Webはクライアント改ざんに弱い

Off the main thread

  • UIスレッド以外に処理を逃がす
  • 自然とViewとデータを分離できる

FIDO認証によるパスワードレスログイン実装入門

  • 合路健人さん(Yahoo)

パスワード認証の課題

  • 利便性
    • サービスごとにパスワード
    • 複雑なパスワードの入力
  • 安全性
    • パスワードを盗まれる

FIDO

  • Fast Identity Online
  • 従来は利便性と安全性がトレードオフ
    • FIDOはどちらも向上させる
  • 公開鍵暗号方式
    • 公開鍵をオンラインサービスに登録
  • RP
    • Relying Party
  • 認証器
    • Authnticator

FIDOの特徴

  • 利便性
    • 生体認証なので認証行為が容易
      • 指紋・声紋・虹彩・顔
      • 認証器の多様性
    • パスワードを記憶しなくて良い
      • 本人のみが記憶してる情報 -> 本人のみが所持している情報
  • 安全性
    • ネットワーク上に流れるのはクレデンシャル情報だけ?
    • リスト攻撃を受けない
    • フィッシング攻撃もできない

FIDOの技術仕様

FIDO UAF

  • パスワードレス
  • 主にスマホを利用
  • 生体認証

FIDO U2F

  • パスワード補完型(記憶 + 所持)
  • PCのWebブラウザで利用
  • 着脱式/無線式

FIDO2

  • Webも対応
    • ブラウザでもパスワードレスに
  • Web Authntication API
    • CredentialWebAPIの拡張

まとめ

  • パスワード認証は利便性安全性に問題
  • FIDO認証は公開鍵暗号方式で課題を解消
  • FIDO2

PWAの導入で得られた成果と見えてきた課題

PWA導入したせいか

  • 日経電子版
  • SPAではない
  • PWA化から１年たった
  • パフォーマンス
    • SpeedIndexで2倍
  • ビジネス指標も向上
    • PWA化だけでなくリニューアルによってUXが向上した
  • ヘビーな使い方にも応えやすくなった
    • 再訪の仕組み
      • A2HS
      • Push通知

リリース後の取り組み

CSSのインライン化

  • レンダリングブロックさせない工夫
    • first viewのCSSだけheadに
    • 本題はlazy loading
  • First Meaningful Paintが1秒改善
  • デバイスサイズやユーザ属性によってスタイルが違う
    • マニュアルでメンテしてる

A2HSのタイミング

  • いつホームに追加のプロンプトを出すかABテスト
    • 記事の読了を判定し表示
      • 押してもらえる率は高いが回数が少ない
    • ブラウザ任せ
      • こっち採用

ServiceWorkerの起動待ち問題

  • 起動までに50ms(モバイルは250-500ms)待たされry
  • NavigationPreload
    • sw起動待たずにfetchできる仕組み

速度を維持する取り組み

  • サイトは絶対に遅くなっていく

モニタリング

  • Speedcurve
    • 毎日測定
    • ダッシュボード用モニタを置いて可視化
  • 短期(1w-1m)
    • 特定のリリースでの劣化を検知
  • 長期(3m-1y)
    • 気づいたら遅くなっていたを検知

ツール

  • 導入済み
    • SpeedCurve(webpagetest)
    • PageSpeed Insights
    • Atlas(内製ツール)
  • 導入したい
    • Chrome Experience Report
    • Lighthouse CI

Paformance Badget

  • パフォーマンス関連のメトリクスい対するBadget
    • ファイルサイズ
    • ファイル数
    • 表示時間
  • 数値で定義しオーバーしないようにつとめる
  • 目標とする値をどうやって決める？
    • web.devに記事が上がってる
  • 現実的に取り組める値を設定してやっていくとよい
    • ダイエットと一緒

現状の課題

  • js/cssの最適化
    • devtoolsでカバレッジ取ると8-9割使われてない
      • Named Export
      • Code Splitting
      • Dynamic Import
  • さらなるキャシュ活用とオフライン対応
    • 朝夕刊の一括ダウンロード
      • アプリでは持ってる機能
    • オフライン対応
      • 日本では需要少なめなので後回しになってる
      • BackgroundSyncとIndexedDBでできる
        • RequestオブジェクトごとIndexedDBに入れる
  • iOS Safari PWA
    • 課題が山積み
    • プッシュ通知できない
    • A2HSのプロンプトでない
    • バグ
    • 等々
  • その他
    • 実装当時はキャッシュ周りライブラリなかったので自前
      • workboxで書き直してる
    • ServiceWorkerの更新
      • 前回の更新確認から24時間以上経つと更新確認される
      • importScriptsで読み込まれるファイルのみ変更した場合更新確認が行われない

PWAの今後の展望

  • ライブラリによる抽象化
    • workbox, Next.js, Nuxt.js
  • プラットフォームの整備

まとめ

  • PWA導入でエンゲージメント高められる
  • 速度はUX向上の1手段
  • モニタリング/Paformanec Badget
  • iOS課題多いがServiceWorkerだけでも恩恵ある
  • フレームワーク/プラットフォームがもっと整備されていきそう

Node.js まとめ

Node v11

  • chengelog見ても変更少ない
  • nodeのポリシー
    • small core, less is more
  • Long term support
    • 偶数バージョン
    • 2年間は保障 + 1年間セキュリティ保障
    • LTSあると運用面で嬉しい
      • 新しいバージョンでてもいきなり追従しなくていい
      • VUP戦略を企業毎にとれる
  • V8
    • v8はNode非互換の修正をするときは事前に通知する
    • v8がnodeをforkして確認してる
  • CI回してる
    • PRごとに全CPU・プラットフォームででビルドを確認
  • Stability
    • CPUのプロファイラとれる
    • メモリリークを確認するする仕組み
      • devtoolsでheapdumpとれる
  • paformance priority is high
  • keep v8 fresh
    • 新しい(Stable Chromeに使われてる)v8を取り込むようにしている
  • Worker
    • Threeadを使えるようにするためのもの
    • NodeはWebpackやbabelでの需要が高まってる
      • multi threeadでやりたい
  • llhttp
    • TSからllvm bitcode生成してCからも呼べるようにする
    • 従来のhttp_parserよりも高速化
    • まだexperimental
  • セキュリティ
    • Security Releaseは脆弱が報告される度に修正パッチ
    • ソーシャルハッキング的なことは防げない
      • npm audit, yarn audit
      • 脆弱性があるパッケージ使ってないかチェックできる

Web Standards

  • Http/2
  • ES Modules
    • .mjsはexperimental
  • Promise
    • Nodeの非同期処理
      • callback, Promise, Stream
    • util.promisify
      • callbackをPromise化
    • fs.promises(experimental)
      • Promise返す
    • Promise使えればasync/awaitで×
    • StreamとPromise
      • for await (constt k of readable) { }
    • stream -> callback -> promisifyする -> Promiseとして扱える

Node.js Futuer

  • Node.js Foundation と JS Foundationの統合
  • W3CとNodeの歩み寄り
    • 共通部分をECMAで標準化
  • WebAPIもNodeAPIもECMAもユースケースを求めてる
    • 仕様策定側よりも利用してる開発者の方が知ってる
    • 開発者がユースケースを作っていく

HTTP の今と未来 ー BBR, HTTP/2, QUIC の基礎から 5G 試験ネットワークでのブラウザベース評価試験まで

イントロ

  • 2015/2
    • HTTP/2
  • 2019/XX
    • HTTP/3
  • HTTP over QUIC -> HTTP/3

5Gの世界

5Gにおけるネットワークの進化

  • 4G -> 5G
  • 遅延を小さくすることに特化させると
    • 隊列走行による無人走行を実現し流通効率化
    • 建設機器の遠隔監視制御
  • 大容量に特化させると
    • モバイル以外もターゲットに
    • VRを用いたリアルタイムスポーツ観戦
    • 場所にとらわれないe-Sports
    • 監視カメラの映像解析

ターゲット

  • 3G
    • 音声ネットワーク
  • 4G
    • データネットワーク
  • 5G
    • サービスネットワーク

5Gの実用化

  • 2018年~
    • 実証実験
  • 2020年頃~
    • 5G実現
  • 2022年以降~
    • 5G高度化

開発者にとって

  • Web for 5Gの課題
    • 5Gの性能を活かしきれない場面
  • MEC(Multi-access Edge Computing)
    • クライアントとサーバの間で受け取って処理する
    • 5Gの性能を活かしたアプリ提供が可能に
  • Web屋とインフラ屋でサービスを共創

HTTP/2 & TLS1.3

HTTP1.1 + TLS/1.2の課題

HTTP/2

  • 単一TCP接続上で非同期並列通信
  • ヘッダ圧縮による通信効率向上

TLS1.3

  • 速い
    • 0-RTT
  • 安全
  • 安心

QUIC

HTTP/3

  • Google QUIC -> IETF QUIC
  • HTTP over QUIC -> HTTP/3

「東京Node学園祭2018」に参加してきました

勉強会メモ
  • 東京Node学園祭2018に参加してきました。

nodefest.jp

  • 去年に続き海外スピーカーが多く登壇されNodeのコアなテーマが多くありました。
  • 個人的にはGraphQL系の2セッションの大盛況ぶりがとても印象的でした。
  • Keynoteでは来年からはNodeFestではなくJSConf in Japanとして開催する計画であると発表されました。
RoomA RoomB RoomE
Keynote
古川陽介 		- -
Offline-First Collaborative Data Structures
Mathias Buus 		JavaScriptで機械学習はじめよう
Shuhei Iitsuka 		How I made critical code run much faster
Vladimir de Turckheim
Node.js: The Road to Workers
Anna Henningsen 		Node.jsでつくるNode.js ミニインタープリター＆コンパイラー
がねこまさし 		Accessibility vs latest Web APIs. Can’t we just get along?
Mauricio Palma
JavaScript Class Features: A case study in TC39
Daniel Ehrenberg 		Diagnose your Node.js app
Daiki Arai 		A trillion points with Node.js
Martin Heidegger
Who Takes Out Your Trash
Sanne Kalkman 		State of SEO for SPA
seya 		Navi: painless routing for React
James K Nelson
libuv: What's a Unicorn Velociraptor?
Colin Ihrig 		React におけるパフォーマンスチューニング
辻 健人 		Node.jsアプリの開発をモダン化するために取り組んできたこと
Daiki Yokoi
Leak Hunting: Finding and debugging a memory leak in Node.js
Giovanny Gongora 		WebアプリをNativeアプリにする Capacitor が広げるWebの可能性
榊原 昌彦 		ブロックチェーンアプリケーション開発でのJavascriptの話
Koji Hirano
Look What You MIDI Me Do!
Rachel White 		実践GraphQL for クライアント側
鈴木 亮太 		Angular Universal on Google App Engine
今村 謙士
Visualizing the Decentralized Web
Jim Pick 		Service Workerを用いたキャッシング戦略 〜Wikiアプリケーションを例に〜
飯塚 大貴 		React + Apollo Client (GraphQL) により変化するアプリケーション設計
宮崎 優太郎
Real-Time Machine Learning in JavaScript
Athan Reines 		貢献できるOSSの見つけ方 -完結編-
Masato Ohba 		-
Haute Codeture
Stephanie Nemeth 		Vue.js/Nuxt.js で 実現できた PWA の リアルタイム動画ラップ・バトル・アプリ
lulzneko 		-
LTタイトル 発表者
おまいらちゃんとリソース解放してますか Taro Odashima
食べたいIoT へっぽこまるこ
What developers can learn from Soviet space program failures Andrey Sitnik
power-assert 2 和田 卓人
How to choose the best npm library? Sota Sugiura
Squoosh裏話 Mariko Kosaka

JavaScriptで機械学習はじめよう

  • Shuhei Iitsukaさん(Google)

docs.google.com

JS × ML

  • Tensorflow.jsの例

emojiscavengerhunt.withgoogle.com

landing.google.co.jp

機械学習とは

  • データを活用して有用な予測を行う
  • ロジックで記述することが難しい時にデータからロジックを得るアプローチ

機械学習の実装方法

K近傍法

  • 最も似てるK個で多数決する
  • データが増えると複雑

線形モデル

  • 線を引いてグループ分け
  • 平面で分離できないと対応できない

ニューラルネットワーク

  • 脳細胞のネットワークをヒントにしたモデル
  • 行列演算を繰り返す
  • 調整するパラメータが多い
  • ニューラルネットワークを重ねる -> DeepLearning
    • 膨大な数のパラメータ調整が必要
      • そこでTensorFlow

TensorFlow

  • 計算グラフを使う
    • 微分の計算(パラメータを変更時に誤差がどれくらい変化するかの計算)が簡単になる
    • 誤差逆伝播法

TensorFlow.js

  • TensorFlowのjs版
  • ブラウザからでもNodeでも

なぜJSで機械学習?

  • オンブラウザ機械学習
    • 高速な推論
    • プライバシーの保護
    • スケーリングが容易
    • 学習済みモデルの軽量化が課題

デモ

  • 3×3マスのマルバツゲーム
  • 手書きの○と×を認識させる

https://tushuhei.github.io/tfjs-tutorial/

Diagnose your Node.js app

  • Daiki Araiさん(Yahoo)

Node初学者の悩み

  • 非同期処理が難しい
  • エラーハンドリングが難しい
  • debugが難しい

非同期処理が難しい

  • ブラウザ or NodeやNodeのバージョンによって挙動が違うことも
    • node v11から変わった
for (let i = 0; i < 2; i++) {
  setTimeout(() => {
    console.log(`Timeout ${i}`);
    Promise.resolve(`Promise ${i}`).then(console.log);
  }, 4);
}

エラーハンドリングが難しい

  • 非同期処理の種類によってエラーハンドリングのしかたが違う
    • callback
    • EventEmmiter
    • Promise
    • async/await
  • unhandledRejection/multipleResolvesのdebugは必ずするべき

debugが難しい

State of SEO for SPA

  • seyaさん

qiita.com

SEOとは

  • Search Engine Optimization
  • Google botにインデックスされること
    • Google botにクロールされること
    • HTMLが適切に解釈されること

SPAでのSEOの課題

  • よく言われること
    • Googlebotはjs実行しない/ajax実行してくれない
      • -> そんなことない
  • Chrome41相当のレンダリングエンジンしか持ってない
    • アロー関数等々動かない
  • WebSocket対応していない
  • ユーザの同意を必要とする機能使えない
  • jsを含むページだとRenderQueueに入るから反映が遅い

SPAでのSEOの課題の解決策

  • babel使ってchrome41で動くJSにする
  • メタ情報だけSSR
  • Dynamic Rendering(prerender)
    • prerender.io
    • アクセスしたのがGoogleBotだったらPrerenderServiceがHeadlessChromeがレンダリングしたHTMLを返す
  • StaticSiteGenerator
    • SEOしたいところだけ使うってのもありではないか
    • SEOしたいページで認証通しておきたいとかないだろうし
  • SSR

解決策の選び方

  • 判断ポイント
    • インデックスに信頼性を求めるか
    • メタ情報の対応が必要/不要
    • 頻繁に更新される & すぐにインデックスしてほしいかどうか

React におけるパフォーマンスチューニング

SPAに何を求めるか

  • いろいろなことを求められるようになっている
  • ユーザの操作に迅速に応えることが重要

事例

  • お客さんからパフォーマンスが悪いと問い合わせ
  • Scriptingに時間がかかっていた
    • Reduxの処理だろうと思い調査
    • うまくいかなかった
  • 推測するな測定せよ

調査

何をするか

  • Scriptingの内訳を見る
  • 関数のコールスタックを調べる
  • React内部で何が起きているか調べる

どうやって調べる

  • Chrome Devtoolsを活用する
  • ReactDevTools
    • HighlightUpdate
    • Profiler
  • Network Timing

  • User Timing

    • React内部で計測の処理を入れてくれている
    • redux-action-timing-middlewareと組み合わせ
      • actionごとのパフォーマンスが見られるようになる github.com

  • React Virtualize

    • 画面に表示されてない要素を描画しない

まとめ

  • 推測ではなく測定することが重要
  • 顧客と同等の環境で動作確認しないと気づけない
    • DevToolsの機能で性能を調整できる
  • 定期的なパフォーマンス測定が重要
    • 機能追加とともにパフォーマンスも劣化していく

WebアプリをNativeアプリにする Capacitor が広げるWebの可能性

  • 榊原 昌彦さん

Capacitor

capacitor.ionicframework.com

  • Cordovaの後継
  • HTMLでモバイル/Web/デスクトップアプリを作れる
    • WebViewの中でHTMLを表示している
    • SPAであればいいので任意FWで作れる
  • デザインガイドラインに沿ったアプリを簡単にHTMLで作れる

Cordovaの課題

  • バージョン
  • プラグイン
    • ネイティブAPIをたたくプラグインはほしいのがなければ自作しないといけない
  • デザイン
    • OSのデザインも変わっていく
  • 開発スピード
    • OSSなのでFW自体の開発スピードが遅いことも

Capacitorの特徴

  • コアプラグインとして、よく使われるネイティブにアクセスする機能を持っている
    • Cordova -> Cordova Plugin -> Objective-C/Java -> NativeAPI
    • Capacitor -> Swift/Kotlin -> NativeAPI
  • Native UI Shell
    • モバイルでWebViewの中にネイティブのパーツを出せる
      • 小さいパーツはHTMLで再現ではなくネイティブを呼んでしまう
      • アラートなど
    • Webの時はデザインされたパーツを出してくれる
  • HTMLアプリだからネイティブより遅いでしょ？
    • 速くはないけど遅くはない
    • 遅いから使い物にならないという時代ではない
  • PWAをサポートしてることがCordovaとの違い
    • スマホアプリよりもWebの方が利用率が高いというデータ
    • アプリの新規インストールはあまりされなくなってきている

実践GraphQL for クライアント側

  • 鈴木 亮太さん(Fringe81)

GraphQLってなに

  • 型システムとともにあるクエリ言語
  • Facebookが2015年にRelayとともに紹介
  • HTTPの場合はPOSTのボディにクエリを入れる

Query/Mutation

  • query
    • RESTでいうGET
  • mutation
    • RESTでいうGET以外
  • ネストした情報も一発でとってこれる

型システム

  • データに型を指定できる

GraphQLを使ったプロダクト

  • データ同士の関連が複雑

GraphQLによって解消された苦しみ

サーバ/クライアント間のいけてなさ

  • before
    • API仕様のやりとりがつらい
  • after
    • コミュニケーションの中心がGraphQLのスキーマになった
    • 共有されるドキュメントはコードから自動生成

データ取得の複雑化

  • before
    • エンドポイントがたくさん
    • 一つの画面を表示するのにたくさんのエンドポイントとのやりとり
    • レスポンスを扱うコードへの不安
  • after
    • 一発でデータがとれる
    • 取得したデータのスキーマが保証される

データ取得のパフォーマンスボトルネック化

  • before
    • リクエストの数だけ時間がかかる
    • 使わないデータも送られてくる
  • after
    • 一発で手に入るので
    • 不要なフィールドの値は送られてこない

なぜGraphQL選んだか

  • GraphQLの課題
    • BFFやSwagger使ったりすればGraphQL使わなくても実現できる
    • リクエストが全て/graphqlになる
  • GraphQLだけ覚えればやりたいことできるから
  • クライアントサイドに依存したサーバサイドにならなくていい

GraphQLを使うにあたって工夫したこと

  • Query/Mutationに名前をつける
    • リクエストの文脈がわかる
    • エンドポイントが全部おなじになる問題の対応
  • queryの再利用性を高める
    • fragmentを積極的に使う

React + Apollo Client (GraphQL) により変化するアプリケーション設計

  • 宮崎 優太郎さん(メルカリ)

blog.vwxyutarooo.me

メルカリWeb

ReactとGraphQL

  • GraphQLを使うとReduxがいらなくなってコード量が減る
    • 実際にそうだった
    • GraphQLとApolloClientを使って作ってる

Reducing our Redux code with React Apollo – Apollo GraphQL

Moving from Redux to GraphQL - Speaker Deck

GraphQL

  • RESTの置き換え
  • BFFとして

Apollo

www.apollographql.com

  • GraphQLのクライアントとサーバそれぞれに必要なプラットフォームを提供してくれる
  • Apolloの構成
    • Gateway(ApolloEngine)
    • Library
    • Development

Apollo Client

React Apollo

www.apollographql.com

  • ApolloClientを内包している
    • ReactのHOCとして提供
  • クエリをGraphQLサーバに投げてくれる
    • 結果をHOCに流す

Apollo Link State

  • ローカルステートとサーバからとってきた情報を混ぜて扱える

Redux -> Apollo

  • Redux
    • ビジネスロジック
      • データアクセス
      • エンドポイント管理
      • ステート管理
    • プレゼンテーションロジック
  • Apollo
    • データアクセス
      • React Apolloによって抽象化され書かなくて良くなった
    • エンドポイント管理
      • GraphQLサーバに一回アクセスすればいい
  • GraphQLとApolloの抽象化によってReduxが置き換わった
    • プレゼンテーションロジックが複雑なものはもしかすると難しいかも

まとめ

  • ApolloとGraphQLを使うとReduxでやってたところが抽象化される
    • UIやプレゼンテーションロジックにフォーカスできるようになる

「Meguro.css #4 @ oRo」に参加してきました

勉強会メモ
  • Meguro.cssに参加してきました

megurocss.connpass.com

  • Meguro.cssは#2以来の2回目の参加でした。
  • 実用的な話が多くて特にShadowDOMの実践的な話を聞けてとても勉強になりました。
タイトル 発表者
雑誌風レイアウトをCSS Grid Layoutでリファクタリング @c_re
CSSフレームワークを自作してみた話。 @kokushing
CSS と Shadow DOM @ktsn
outline: none; @yamanoku
Marqueeタグでゲームを作りたい @bug_ojisan
word-wrap周りのベストプラクティスを考えてみた @masahiko888

雑誌風レイアウトをCSS Grid Layoutでリファクタリング

  • @c_reさん

雑誌っぽいレイアウト

前提

  • 既存のflexboxをGrid Layoutに
  • レスポンシブに

苦労したとこ

  • IE11対応苦労した
    • grid itemに指定したmargin/paddingがおかしい
    • grid containerに対するalign-item, grid itemに対するalign-selfが効かない

よかったとこ

  • ゴードが読みやすくなった
  • レスポンシブはモバイルファーストで組んだ方が楽

CSSフレームワークを自作してみた話。

  • @kokushingさん

CSSフレームワーク使ってて

  • 使いづらいなと思うところがある
    • 記述の癖
    • 使わないスタイル
    • 日本語つまってる
    • デザイン好みじゃない
  • -> 自分で作った

自作フレームワーク

UNITS

unitscss.kokush.in

Uny

unys.github.io

  • 柔軟性を意識
  • SCSSを採用
  • スタイルの一括調整
    • メンテナンス性
  • pxではなくremを使ってフォントサイズ管理楽になった

Unim

kokushin.github.io

  • まだ公開してない
  • レイアウト用、テーマ用、カラー用のスタイルに分割
  • 日本語での表示に特化

mono.css

kokushin.github.io

jpn.css

kokushin.github.io

  • bootstrap合わせて使うと日本語が読みやすくなる

CSS と Shadow DOM

  • @ktsnさん

ShadowDOM

  • スコープが区切られたDOMを作れる
    • 外部のCSSは内部に影響を与えない
    • 内部のCSSは外部に影響を与えない
  • CSSが漏れない

使ってみって

  • reset.cssどうする？
    • shadowDOMごとに読み込む
  • 手っ取り早くリセット
    • all:initial;
    • all:unset;
  • テーマ変更
    • CSS Custom Property
:root {
  --text-color: red
}

var(--text-color);
  • 外から自由にスタイルを変えたい
    • ;;part``::themeが提案中

対応状況

outline: none;

  • @yamanokuさん

outline

  • 輪郭線
  • outline: none;
    • フォーカスした要素の輪郭線を消す

outline: none;なぜよくない？

  • 現在位置わからなくなる
  • a11yが悪くなる
  • http://www.outlinenone.com/
  • とはいえデフォルトのフォーカスはいけてない

マウスとキーボードを別にする

  • forcus-visible
  • キーボード操作でフォーカスしたときだけスタイルを当てる
    • 使えないブラウザがほとんど
  • jsライブラリ

github.com

まとめ

  • outline: none;をする前に一旦立ち止まろう
  • 問題なければデフォルトでいいとおもう
    • スタイル変えるならよく考えないといけない
  • いろんなサイトをタブキーで移動してみよう

Marqueeタグでゲームを作りたい

  • @bug_ojisanさん

Marqueeタグ

Marqueeタグの可能性

  • ゲームとか作れそう

  • パラメータは変数ではないので衝突判定とかできない

  • CSS in JSで作り直す
    • remarquee

remarquee

www.npmjs.com

  • 衝突判定したい
  • Reactベースで
  • 横に動くだけで100%追従してるものはない

word-wrap周りのベストプラクティスを考えてみた

  • @masahiko888

word-wrap

  • 固定幅の要素内で文字が横にはみ出させずに折り返したい
  • word-wrap: break-word
  • word-wrap: break-all
  • break-wordでダメな時に安易にbreak-allしてはダメ
  • 考えないと行けないパターン
    • 英字の連続
    • 、。…の連続
    • 、。…の禁則処理

どうしたらよいか

  • 基本はbreak-word
  • 禁則処理が発生しないところはbreak-all

「どこでもKotlin #6 〜Kotlin 1.3の新機能に触れる〜」に参加してきました

勉強会メモ
  • どこでもKotlin #6 〜Kotlin 1.3の新機能に触れる〜に参加してきました。

m3-engineer.connpass.com

  • 最新のKotlinの話やサーバサイドKotlin、Kotlin/Nativeと幅広い話が聞けて勉強になりました。
  • Kotlin/Nativeは気になりつつもあまり情報収集できていなかったので参考になりました。着実に進歩しているものの今はまだ様子見といった印象ですかね。
  • 後は太郎さんのContractsの説明めちゃくちゃわかりやすかったです。
タイトル 発表者
What's new in Kotlin LINE 藤原 聖
コードで見る Kotlin 1.3 M3 大和 康平
8割完成済みのJavaプロジェクトにKotlinを途中導入した話 M3 川俣 涼
Kotlin/Native 「使ってみた」の一歩先へ M3 星川 貴樹
Kotlin Contracts Ubie 長澤太郎

What's new in Kotlin

  • LINE 藤原 聖さん
  • エムスリー技術顧問

Kotlin Conf 2018

  • JetBrainsが主催
  • 今年で2回目
  • 1300人以上参加
  • 65セッション全て動画公開

www.youtube.com

Keynote

  • Kotlin言語設計者のAndrey
Pragmatic
  • 実用主義
  • 開発者が考えたことをそのままコードにできる

Evolution

  • Keep the language modern
  • Comfortable update
  • 言語をモダンに保ちつつIDEの補完でサポート

Kotlin 1.3 Release

  • 10/29リリース
  • Coroutinesがstable
  • Kotlin/Nativeがbeta
  • Contracts, Inline classes等experimental

最新情報

コードで見る Kotlin 1.3

  • M3 大和 康平さん

Kotlin1.3事始め

  • brew install kotlinで1.3入る

Croutines

  • 軽量なスレッド
  • Croutines builder

Inline Classes

  • コンパイル時にオーバヘッドが少なく展開できる
  • static methodとして展開される
  • プライマリコンストラクタのプロパティ1つまで
  • init文を持てない

標準関数

  • Random
  • isNullOrEmpty/orEmpty
  • Array.copyInto
  • ifEmpty/ifBlank

8割完成済みのJavaプロジェクトにKotlinを途中導入した話

  • M3 川俣 涼さん

JavaプロジェクトにKotlin導入

  • 社内でKotlin導入の流れ
  • 新しい技術への挑戦

進め方

  • 新規追加のクラス/テストはKotlinで

メリット

  • コード量の減少で開発効率アップ
    • data class
  • Null安全がいい
    • nullpo事前に分かるのいい

デメリット

  • なかった
  • 強いて言うなら情報が少ないこと
    • qiitaの記事Java + SpringBootは1250、Kotlin + SpringBootは132
  • Javaのコンパイラ周りの知識は必要
    • lombokを使ってるJavaクラスのプロパティを参照できない
    • JavaからKotlinのクラスを参照するとビルドエラー
    • コンパイルの処理順序を知っておくことが必要

Kotlin/Native 「使ってみた」の一歩先へ

  • M3 星川 貴樹

Kotlin/Nativeとは

Kotlin/Nativeの歩み

  • 2017/4登場
    • Cのヘッダーファイルを解釈することできた
  • 2017/11
  • 2018/2
    • MPP対応
  • 2018/4
  • 2018/6
    • JVM, JSのstdlibに
  • 2018/11beta
    • 安定版コルーチンサポート
    • Kotlin1.3

Kotlin/Nativeの使いみち

  • Java資産使えないのに価値あるの？
    • Cのライブラリなら使える
    • iOSならSwift, Objective-Cのライブラリ使える
  • Kotlin stdlibにない機能はどうするの？
    • コルーチン等いろいろ対応されてきてる
  • メモリ管理どうするの？
    • GC独自実装している
    • iOSであればARC値返る
  • 想定される使い道
    • Andoroid, iOS, (Web)の共通モジュール
    • サーバとクライアントのモデルクラスの共通化
    • MVPのMとPをKotlinでVはOSごとのコードで

Kotlin/Native速いの？

  • JVMの方が2倍速い
  • 最適化作業がまだされてないから?

Kotlin/Nativeのこれから

  • MPPで使えるライブラリを使うようにする
  • KotlinライブラリのMPP化
  • iOSエンジニアの理解

Kotlin Contracts

  • Ubie 長澤太郎

従来のKotlin

  • 便利な関数があるのにスマートキャストできない
    • !name.isNullOrBlank()と書くと
      • Nullableな変数をnullでないと確認した後はNonNullで扱いたい
      • 文脈的に明らかにnull出ない場合でもコンパイラがエラーという
      • name != nullって書かないと行けなかった
      • これが1.3からちゃんと動くようになる

Contracts

  • 事前条件
    • 関数の利用者が条件を満たす
  • 事後条件
    • 関数を呼び出した後の状況を関数が保証する
    • ex. List#addしたらlengthが1増える
  • 不変条件
    • オブジェクトが満たすべき状態を維持する
  • Contractsは事後条件の部分
    • しかも静的に

対応してる標準関数

  • 引数がtrueを保障
    • assertTrue
    • check
    • require
  • 引数がfalseを保障
    • assertFalse
  • 引数がNotNullを保障
    • assertNotNull
    • checkNotNull
    • requireNotNull

従来のKotlin2

  • val変数の初期化が絶対成功するはずなのにできない
  • ラムダの中での初期化はは一度だけしか呼ばれないのに分かってくれない
    • これが1.3からちゃんと動くようになる
  • InvocationKind
    • AT_MOST_ONCE
    • EXACTRY_ONCE
    • AT_LEAST_ONCE
    • UNKNOWN

契約DSLまとめ

  • contract: 関数の先頭
  • returns(): 関数が成功したら..
  • returns(Any?): true/false/nullを返したら..
  • callsInPlace: 関数が呼ばれる回数を保障する
contract {
  returns(true implies (arg != null)
}

contract {
  callsInPlace)block, InvocationKind.EXACTRY_ONCE)
}

「Vue Fes Japan 2018」に参加してきました

勉強会メモ
  • Vue Fes Japan 2018に参加してきました。

vuefes.jp

会場A 会場B
キーノート
Evan You 		-
Next-level Vue Animations
Sarah Drasner 		Vue.js と Web Components のこれから
Takanori Oki
Vue Designer: デザインと実装の統合
katashin 		Unit testing a Vuex store
Edd Yerburgh
Atomic Design のデザインと実装の狭間
菅原 孝則 		Nuxt.js 2.0
Sébastien Chopin
A deep dive in SFC compilation
Rahul Kadyan 		note のフロントエンドを Nuxt.js で再構築した話
福井 烈
Vue CLI 3 and its Graphical User Interface
Guillaume Chau 		1年間単体テストを書き続けた現場から送る Vue Component のテスト
土屋 和良

キーノート~ Vue3.0 Updates ~

  • Evan Youさん

Vue3.0

  • より速く
  • より小さく
    • tree shaking対応
  • よりメンテナンスしやすく
  • よりネイティブ向けに作りやすく
    • カスタムレンダラAPI
  • よりあなたのコードの保守性を向上
    • tsxによるTypeScriptサポート
    • HooksAPI(Experimental)
    • TimeSlicing(Experimental)

より速く

  • 仮想DOMの実装を作り直した
    • moutとpatch処理が最大100%向上
    • 後方互換性も保つ
  • ネイティブプロキシを使って高速化
  • コンパイルの仕組みも高速化
    • コンポーネント探索の最適化
    • 依存関係を正しくトラッキングし不要な親子のレンダリングを回避
    • 静的ツリーの巻き上げ
      • テンプレートの静的な部分と動的な部分を区別して最適化
      • インラインで定義してる関数も巻き上げてキャッシュする
  • => コンポーネントの初期化が最大で100%高速化する！

より小さく

  • tree shaking対応
    • 使われていないコードをバンドルされたファイルに含まないようにする

よりメンテナンスしやすく

よりネイティブ向けに作りやすく

  • カスタムレンダラAPI
    • 対象はブラウザだけでない
    • ios/android(WeexやNativeScript)

あなたのコードの保守性を向上

  • リアクティビティAPI
    • observableメソッドでstateの変更を監視
    • リアクティブの画面に反映
  • コンポーネントの再描画をデバッグしやすく
    • renderTriggered
  • TSXによるTypeScriptサポートの強化
    • render関数にtsxを書ける
  • warningメッセージの改善
  • HooksAPI(Experimental)
    • mixinのネームスペースの問題を解決できる
  • TimeSlicing(Experimental)
    • 重い処理があってもブロッキングしなくなる
    • 処理を分離させている
    • 60fps

Vue.js と Web Components のこれから

  • Takanori Okiさん

WebComponsntesとは

仕様

  • Custom Elements
    • 自分でHTMLのタグを作れる
  • Shadow DOM
  • HTML Template
    • 独立したHTMLかたまりを定義できる
    • <templates>
  • ES Modules
    • JSファイルをimport/exportできる
  • HTML Modules
    • HTMLをJavaScriptの中に直接import可能にする仕様

どうやってWebComponentsをVueで作るか

  • VueCLI3のBuildTargets
  • --target wcをつけるとvueのコンポーネントをWebComponentsに変換してbuildできる
  • これで生成されたファイルは単体でWebComponentsとして動く
  • VueからWebComponentsにスムーズに移行できる

なぜWebComponentsを使うのか

-　今のところVueの機能を使ってWebComponentsを作ったほうが楽

メリット

  • 同じコンポーネントをどんなライブラリとも一緒に使える
  • FullScoped
    • VueだけではうまくScopedに振る舞わせられるだけ
    • グローバルなCSSに影響されなくなる

デメリット

  • 属性にString型しか渡せない
  • 外部から渡されるイベントハンドリングが難しい

Micro Frontend

  • サーバサイドのマイクロサービスのようにフロントエンドもマイクロサービス化
  • 外側はVueで細かいパーツはWebComponents

変更に強い柔軟なWeb

  • WebComponentsならScopedなので以下のような変更が楽
    • CSSの変更
    • JSの変更
    • ライブラリの変更
    • DOMの変更
  • Framework移行はとても大変
    • Vueが死んでもWebComponents使ってればmigrationしやすい
  • Web標準であることは強い

今後どうなるか

  • VueはWebComponentsに置き換えられていく？
    • No
    • 共存していくもの
  • WebComponents is to encapsulate HTML elements

まとめ

  • WebComponentsまだ課題もある
  • VueとWebComponentsは共存できる
  • UIをWebComponentsに任せることで負債を減らせる

Vue Designer: デザインと実装の統合

  • katashinさん

今のWebアプリ

デザインと実装が分かれている

  • デザイナー
    • デザイン用のツール
  • 開発者
    • デザインの通りに実装
  • 昔よりUIや設計が複雑になってきたので分業化されてきた
  • 分業することによる課題もある

デザインと実装が分かれることによる課題

  • デザインのファイルと実装するファイルが違うので二度手間
  • 小さな改修でのコミュニケーション問題
  • デザインは静的
  • => みんな解決しようとしている
ライブラリ
  • vuegg
    • 結局プロトタイプでしか使えなさそう

vuegg.now.sh

technical-creator.com

  • SFCが実装かつデザインになるようなツールがほしい
    • そこでVue Designer

Vue Designer

github.com

  • VSCode上で使う
  • VueアプリのプレビューがVSCode上で見られる
    • windowsサイズを柔軟に変えられる
    • プレビューで画面を選択するとそれに該当するコードがハイライトされる
  • SFCが唯一のデータ
    • デザインしたものがVueのコードになる
    • 実装もデザインも同じコード

仕組み

  • html
    • vue-eslint-parser
  • js
    • @babel/parser
    • babelはtsにも対応した
  • css
    • postcss

今後

  • v1.0.0までの展望
    • 開発者が使って便利なものにしたい
    • SFCのプレビューツールとしてでも便利
    • Chrome devtools on VSCode
    • Layouting tool
  • その先
    • npm i element-ui vuetify quasar-framework vuesaxするだけでデザイン使えるように
    • デザイナーと開発者がgithubで同じコードを編集
    • コンポーネントカタログ自動生成

まとめ

  • デザインと実装が分かれてることによる課題がある
    • 統合したい
    • Vue Designer
  • まずは開発者が便利に使えるツールに
  • 将来的にはデザイナーも開発者も使えるツールに

Atomic Design のデザインと実装の狭間

  • 菅原 孝則さん

コンポーネント

  • デザイナーとエンジニアが同じ目線でコンポーネントを設計するのは難しい
  • AtmicDesignでもダメ
  • 知識の分断が大きい
  • 大事にしていることも違う

デザイナーがやってること

  • やってること
    • UXデザイン
    • UIデザイン
    • 他にもいろいろ
  • 大事なのはユーザの反応
    • 綺麗に作ることも大事だけどその次
  • コンポーネントはエンジニアリングの概念

デザインのツール

  • コンポーネント指向のデザインツールはあまり流行ってなかった
    • 最近は出てきた
    • みんな慣れてないだけ
  • 手段が進化したので手法も変わる
    • まだまだツールのサポートが足りない
    • 時間が解決するところもあるだろう
  • コンポーネント指向でAtomicDesign
    • Cしか知らない人にSpringBootでアプリ作れと言ってるようなもの

Design Ops

  • デザインの仕事に集中できるように
  • デザインプロセスをサポートする仕組み組織を作る

まとめ

  • デザイナーがデザインに専念できる環境を作ろう
  • やり方はまだみんな手探り
  • エンジニアがそれをサポートしよう

note のフロントエンドを Nuxt.js で再構築した話

  • 福井 烈さん

Nuxt移行のモチベーション

  • 2013年にAngularJSで実装開始した
    • UI複雑
      • 2way-binding

現状の課題

  • 初期表示の遅さ
  • 技術的制約
    • AngularJSはSSRサポートしてない
    • Railsに乗ったフロントエンド
  • 技術的負債

技術選定要件

  • 要件
    • SSR
    • 学習運用コスト
      • デザイナーもコード書く
        • フロントエンド専任がいない
    • 開発コミュニティの活発度
  • Vueがこれらを満たすので採用
  • さらにNuxtも採用
    • SSRが作りやすい
    • コードの規約がある
    • Webpack等も入ってる

移行計画

  • ベージ単位で移行
  • ドックフーディング
  • 一部のページはNuxt版が動いてる
  • lighthouseのパフォーマンス 3点 -> 41点
    • 現状残っている指摘は画像の最適化

技術

コンポーネント設計

  • Vuex
  • AtomicDesign
    • atomsとmoleculesはvuex参照禁止
    • organismsはvuex参照可
  • Storybook
    • Nuxtとの設定互換がつらい
      • v4で改善

ユニバーサルJS

  • SSRするから対応必須
  • サーバサイドからはwindowやdocumentが見えないから改修しないといけない
    • ライブラリが使ってるとどうしようもない
    • jsdomを使って対応

ファイルサイズの圧縮

  • nuxt build --analyze
  • highlight.js(コードに色つけるやつ)言語絞ってサイズ削減
  • moment.jsをday.jsに
  • lodashやめる

インフラ

  • 当初はEC2 + node + pm2
    • Serverless Frameworkに変更
  • nodeのバージョンがLambdaに依存してしまう

まとめ

  • URL単位で小さく移行するの有効
    • ドックフーディング容易
    • 完全移行までの二重メンテは覚悟いる
  • NuxtはSSR必要なら有用

1年間単体テストを書き続けた現場から送る Vue Component のテスト

  • 土屋 和良さん

コンポーネントのテスト書いてますか

  • UIは変更が多いからテストしない？
    • テストがないと意図しない変更が起きないか不安

コンポーネントの何をテストするのか

  • 外部からみた振る舞いをテストする
    • 自動テストのターゲットは外から見た振る舞い
  • input/outputを整理
  • mount? or shallow?
    • 基本的にmount

どうやってコンポーネントをテストするか

Lifecycleのテスト

  • 他のテストよりは優先度低
    • 得られる安心感は少なめ

Props/VuexStateのテスト

  • 単純なassert
    • どこまで細かくチェックする?
    • 文言変わっただけで書き直さないといけないの面倒
  • SnapshotTest
    • DOMのスナップショットをとって次のテストのexpectedにする
    • CSSもテストしたい
      • -> VisualTesting
  • VisualTesting
    • SnapshotTestの画像版
    • Storybook + reg-suit
  • reg-suit
    • CIのフローに組み込むとこまでサポートしてくれている
      • PRで結果が見えるとか
    • PRのレビューが効率化

reg-viz.github.io

User Interactionのテスト

  • User Interaction
    • 入力
    • クリック
    • スクロール
    • D&D
    • ....
  • 全部やるのは大変
    • 入力、クリックくらいなら簡単
      • そこだけテストしている
  • 簡単なUserInteractionテストは大変じゃない
    • 重要なフォームだけでもやっておくといい

まとめ

  • VisualTestは最高
    • 簡単に作れる
    • レビュー負荷も下がる

「React会 #1」に参加してきました

勉強会メモ
  • React会 #1に参加してきました。

react-kai.connpass.com

  • React Hooksで盛り上がってる中でのReactのイベントということで、最新情報をキャッチアップできる勉強会でした。
  • React会は今後React meetupと合流するということで、Reactコミュニティの盛り上がりにも期待してます。
タイトル 登壇者
typescript-fsaに頼らないReact/Redux camcam_lemonさん
Recomposeとは何だったのか、またはHooksが開けたパンドラの箱についての考察 大岡由佳@oukayukaさん
ReactNative(Expo) + Firebaseを使って爆速でアプリを作る はがさん
React Hooksで遊ぼう yamatatsuさん
Context APIを使ったライブラリを作った dai_shiさん

typescript-fsaに頼らないReact/Redux

  • camcam_lemonさん

Component

Stateful Component

  • interfaceかtypeでprops/stateを宣言

Stateless Functional Component

  • React.SFC<P>で型付ける

Container

  • maoStateToProps
  • mapDispatchToProps
    • reduxのDispatchで型つける

Action

  • actionのtypeプロパティにas typeof xxx
  • typeをただの文字列じゃなくて型として扱える

Reducer

  • Conditional typeのReturnTypeを使ってActionを型定義
  • switch文で該当するものがなければdefaultでnever型で拾う
    • 受け取るActionが一つの時はnever使えない
    • if使う

まとめ

  • tsの機能だけでいい感じに型をつけることができる
  • ActionｔReducerのテンプレを崩さずに書けるのがいい

Recomposeとは何だったのか、またはHooksが開けたパンドラの箱についての考察

  • 大岡由佳@oukayukaさん

技術書店で本出した

  • Reactの本
  • RecomposeとHOCの話も書いてた
  • その数日後ReactConfでReact Hooks発表
  • Recoposeは開発終了今後はReact Hooksでとのアナウンス
  • 嘆いてたらDan先生からDMが来た

Recomposeとは

  • 関数コンポーネントやHOCのためのReactユーティリティ
  • 関数コンポーネントにローカルステートやライフサイクルメソッドが追加される
  • Reduxのconnectなんかがそれ

なぜRecomposeは開発をとめるのか

  • Recomposeの作者がfacebookにジョインしてHooksを作った
    • withStateとuseStateがそっくり

これからどうなるか

  • ReactHooks反響大きすぎて後戻りすることはない
  • HOC, Render Propsもフェードアウトしていくのではないか
  • classコンポーネントもそのうち非推奨になりそう
  • Reduxがなくなることはないのでは
    • connectがuseReduxのようなインターフェースになるのでは

github.com

ReactNative(Expo) + Firebaseを使って爆速でアプリを作る

  • はがさん(FACTBASE)

docs.google.com

サンプルアプリ

Expo

  • ReactNative開発をWeb開発に近づけるプラットフォーム兼ライブラリ
  • アプリのビルドをせずとも実機で動作確認できる

ReactNativeのライブラリ

  • ReactNavigation
    • ナビゲーションライブラリ
  • NativeBase
    • UIライブラリ
  • react-native-swiper
    • 画像のスワイプ簡単に作れる
  • react-native-gifted-chat
    • チャット風UIを簡単に作れる

まとめ

  • OSSを活用すると爆速で作れる
  • Expo使うことでビルドで実機とPCを繋がなくてよかった

React Hooksで遊ぼう

  • yamatatsuさん

React Hooks

  • 三行で言うと
    • Functional Componentで状態を持てる
    • Functional Componentでupdate系のイベントを扱える
    • Consumer無しでContextを使える とかとか

useState

  • Functional Componentでstate持てる

useReducer

  • reducerっぽく使えるuseState

useCallback

  • memoKeyが変わらない限り一回しか実行されない
  • 一回だけ走って欲しいやつに使う

useMemo

  • useCallbackに似てる
  • 関数の戻り値をくれる

uesRef

  • createRef的な

DidMount

  • Dan先生曰くSuspenceを待たれよとのこと

Context APIを使ったライブラリを作った

  • dai_shiさん

ContextAPI

  • React16.3ではいった
  • Reduxの代替になるのではと噂に
  • コンポーネントツリーの階層をジャンプして値を渡すことができる
  • Providerで値を渡してConsumerで値を受け取る
  • State管理できるわけではない
  • npm化した

github.com

React Hooks

  • React Hooksで世界が変わる
  • classでしかできなかったことがなくなる
  • hooks版も作った

github.com

itnext.io

「Spring Fest 2018」に参加してきました

勉強会メモ
  • Spring Fest 2018に参加してきました。

springfest2018.springframework.jp

KFCHall KFCHall Annex KFCHall 2nd Room111
KEYNOTE
SébastienDeleuze(Pivotal) 		- - -
決済システムの内製化への旅 ‒ SpringとPCFで作るクラウドネイティブなシステム開発
槙 俊明(Pivotal)
鈴⽊ 順也(ソフトバンク・ペイメント・サービス株式会社) 		エンタープライズ・マイクロサービスの格⾔
⻑⾕川 裕⼀(Starlight&Storm/⽇本Springユーザ会) 		Spring Data for Apache GeodeでRDBいらずのアプリ開発をしよう！
⼭河 征紀(ウルシステムズ株式会社) 		これからSpringを使う開発者が知っておくべきこと
⼟岐 孝平(⽇本Springユーザ会スタッフ)
Rakuten Travel and Spring
Kalburgi Gajraj(楽天株式会社) 		Spring ♥ GCP ー SpringとGCPの素敵な関係
福⽥ 潔(Google) 		実際のプロジェクトでSpringアプリをKotlinで開発して得た気づき集
⻑澤 太郎(Ubie株式会社) 		Thymeleafさいしょの⼀歩
伊賀 敏樹
Knative:Serving your Serverless Java Serviceon Kubernetes the 12-Factor way
Kamesh Sampath(Redhat) 		Observability with Spring-Based Distributed Systems
Thomas Ludwig(楽天株式会社) 		AmazonCognito使って認証したい？それならSpring Security使いましょう！
内⽴ 良介(コイニー株式会社 ⽇本Javaユーザーグループ) 		SpringBootで作るRESTful Web Service
⼤野 渉(Starlight & Storm/JSUGスタッフ)
Pivotal認定講師が解説！基礎からのOAuth2.0とSpring Security5.1による実装
多⽥ 真敏(株式会社カサレアル) 		500+のサーバーで動くLINE Ads PlatformをささえるSpring
渡邉 直樹(LINE株式会社) 		SpringTools4の機能とその実装
岩塚 卓弥/堅⽥ 淳也(NTTソフトウェアイノベーションセンタ) 		Spring5でSpring Testのここが変わる
平栗 勇⼈(株式会社NTTデータ)
Spring Boot with Kotlin, functional configuration and GraalVM
SébastienDeleuze(Pivotal) 		⼤規模⾦融系SaaSを⽀えるSpring〜活⽤の変遷と新時代のアーキテクチャ〜
⽝塚 裕介(株式会社野村総合研究所) 		Spring Data RESTとSpring Cloud Contract
⼩川 岳史/⼭﨑 ⼤(株式会社タグバンガーズ) 		Spring BootでHello Worldのその先へ〜ウェブDBプレスのSpring Boot特集で伝えたかったこと＆伝えきれなかったこと～
藤野 真聡(ソニーネットワークコミュニケーションズ株式会社)
業務で使いたいWebFluxによるReactiveプログラミング
⾕本 ⼼(Acroquest Technology株式会社) 		- Micrometer/Prometheusによる⼤規模システムモニタリング〜ヤフーインターネット広告システムでの導入事例〜
池⽥ 誠(ヤフー株式会社) 		Angularを⽤いたデザインスプリント開発と設計⼿法
佐川 夫美雄(アシラス株式会社)

KEYNOTE - The State of Spring, Java and Kotlin

  • SébastienDeleuze(Pivotal)

Javaの現状

  • Java8が広く使われるようになってきた
    • 2017/10で75%くらい使われてる
    • 残りはほとんど7
    • 9はLTSじゃないから少ない
  • JavaSE Lifecycle
    • LTSは3年ごと
      • 次は11その次は17
    • 6ヶ月ごとにリリース

Java LTS Version

  • Java8
    • Java8がベースになっていく
    • 2023+までサポート
  • Java11
    • 2023+までサポート
  • Java17
    • 2021リリース予定

SpringとJava

  • v4.3はJava8まで
    • EOLは2020/6
  • v5.0はJava10まで
    • EOLは2019/3
  • v5.1はJava11まで
    • EOLは2019/12
  • v5.2はJava12までサポート

New VM

  • GraalVM
    • High performance polyglot VM

Kotlinの現状

  • 今一番伸びている言語
    • stack overflowやgithubのデータより
  • 1.3がつい最近リリース
    • コルーチンが目玉
    • Kotlin/Nativeがbetaに

Springの現状

SpringFramework5.1

  • v5.1でJava8と11をサポート
  • non-LTSはベストエフォート

SpringBoot2.1

  • v2.1が昨日でた
  • Java11サポート
  • 3rdパーティライブラリアップグレード
  • Spring Data JDBC Starter
  • 起動時のパフォーマンス改善

Roadmap

  • SpringFrameworkのv5.2でKotlinのv1.3をベースにする
    • コルーチンもサポート
  • 公式ドキュメントにKotlinのサンプルコードも含めるようにする

R2DBC

  • Reactive SQL SPI
  • Reactive Streamベース
  • PostgreSQL driver more to come

Spring Data R2DBC

  • Spring Data JDBCに似てるけどこっちはReactive
  • DatabaseClient functional API

GraalVM

  • SpringBootが一瞬で起動するデモ
    • 0.006s?

RSocket

  • ネットワークをReactiveにする
  • facebookを中心に4社で作ってる
  • モデル
    • request response
    • fire and forget
    • request - stream
    • channel
  • クライアント
    • JavaでもJSでもKotlinでもC++でも
  • SpringFramework v5.2から

Spring Fu

  • SpringをFunctionalに書く
  • Faster and Lighter
  • Kofu
    • KotlinによるSpring Fuのconfiguration
    • Kotlin DSL
  • Jafu
    • JavaによるSpring Fuのconfiguration

まとめ

  • パフォーマンスを上げることとReactiveに力を入れてる

決済システムの内製化への旅 ‒ SpringとPCFで作るクラウドネイティブなシステム開発

  • 槙 俊明(Pivotal)
  • 鈴⽊ 順也(ソフトバンク・ペイメント・サービス株式会社)

内製化に至る過程

2016

  • 課題
    • 開発は全てベンダ任せ
    • 開発環境も整ってない
    • 手作業によるミスが起きる
  • 解決策
    • 改善プロジェクト
    • SpringBoot, Selenium
    • github入れたり
    • エンジニアが3人入社

2017

  • 課題
  • 解決策
    • 監視ツール導入
    • FWはSpringで統一
    • jenkins, nexus, sonar

2018

  • 決済システムの内製スタート
    • オンライン決済サービス
    • 加盟店にAPIを公開
    • 複数の決済手段で決済
    • 加盟店(8000件) -> 決済システム -> 決済機関(40件)
  • 求められてたこと
    • スピード感
    • 継続的な改善
    • 監視が容易で障害に強い
    • -> ベンダーに頼ると実現できないので内製で
  • PCF上に構築することに
    • 槙さんがサポート

なぜPCF

  • PCF
    • Pivotal Container Service
    • Pivotal Application Service
      • Cloud Foundry
    • Pivotal Function Service
      • Knative, riffがベース
  • この事例ではPvotal Application Serviceを採用
    • 3つのうちどれが良いかはチーム構成ややりたいことによる
  • チーム体制
    • ops2名 - PCFの面倒見る
    • dev3名 - アプリ作る
  • 12factorに従って作ればPCFを意識しなくてもPCFで動く
  • PaaS vs Kube
    • 開発者視点で
      • いろんなことをやりたくなかった

技術の話

全体アーキテクチャ

  • CI周り
  • PAS
  • RabbitMQ
  • 監視周り
    • Prometheus
    • Grafana
  • ログ周り
    • Logstash
    • Elasticserch
    • Kibana
  • Dev環境とProd環境を用意

アプリのアーキテクチャ

  • マイクロサービスで作ってる
    • API Gateway
      • Spring Cloud Gayteway
    • ServiceA, B, C
      • 決済機関単位で？作成
    • Hystrix入れてサーキットブレーカも
      • 障害があった時に関係ない決済機関も使えなくなる訳にはいかない
    • 決済機関から加盟店への通知はRabbitMQで非同期に連携
      • Spring Cloud Stream
      • Notification Gateway
      • 通知失敗したらDeadLetterQueとして返ってくるので再送する
  • PCFによるAutoscaler
    • 急な負荷に対応する
    • スケールに関してアプリ側が何か意識する必要はない
  • 12factor
    • 環境に依存する設定項目は環境変数に
    • ログはファイルではなく標準出力に
      • 絶対にロストしてはいけないデータはDBへ

CI/CD

  • Concouseで動かす
    • slackに通知
    • github enterpriseと連携
    • pushする -> JUnit実行 -> Sonarに結果送る -> nexusへ配置 -> 開発環境へリリース
      • 本番では自動でバージョンのインクリメントとかも
      • 槙さん謹製の構成(どこかで見たことあるような構成)
  • 負荷テスト、E2Eテストも自動で
    • JMeterで負荷テスト
      • 開発環境で毎日
    • E2Eテスト
  • Javaの複数バージョン対応
    • 複数のバージョンでのテストをConcourseで同時に実行
    • docker使ってるので複数バージョン並列実行を簡単にできる

Observability

  • Observability
    • Tracing
    • Metrics
    • Logging
  • Zipkin使ってる
  • Grafanaダッシュボードでメトリクス監視
    • BOSHで入れるとダッシュボードやアラートがデフォルトで入ってる
    • micrometerの依存追加するだけで使える
  • Kibanaでログを見てる

実際のプロジェクトでSpringアプリをKotlinで開発して得た気づき集

  • ⻑澤 太郎(Ubie株式会社)
  • jkug代表

KotlinでSpringを始める

  • Spring InitializrでKotlinを選べるようになってる

クラスにつけるアノテーション

  • Kotlinのクラスはデフォルトfinal
    • 継承したいならopenってつける必要がある
    • @Serviceするならopenしないといけない
    • Kotlin公式のallopenプラグイン
    • Kotlin公式のkotlin-springプラグイン
      • @Service等々は自動でopenしてくれる
      • SpringInitializrで作れば入ってる
  • アノテーションの解析ないから速い

バリデーション

  • これだとダメ
class Xxx (
  @NotNull val age: Int,
  @NotBlank val name: String
)
  • Javaを意識してこう書かないといけない
class Xxx (
  @field:@NotNull val age: Int,
  @field:@NotBlank val name: String
)
  • デフォルトではもともとnull許容しないので注意
    • ?つけるとnull許容型
class Xxx (
  @field:@NotNull val age: Int?,
  @field:@NotBlank val name: String
)

WebFluxとコルーチン

  • ReactorはAPIとか覚えることたくさん
  • Reactorとコルーチンを組み合わせると書きやすい
  • Reactorの世界とKotlinの世界を処理の途中でいったりきたりできる
    • async/awaitとか使って書く

アノテーションをやめる

テスト

  • Spring Test - WebTestClient
  • AssertJ
  • MockK
  • DbSetup-kotlin

JUnit5

  • @Nestedでグルーピングしやすくなった
  • assertThrows<MyException>って感じで型引数渡せる

AssertJ

  • .isNotNullした後でもnullableな値だと?つけないといけない
assertThat(got).isNotNull
assertThat(got?.name).isEqualTo('test')
  • そもそもデータクラスで比較したほうがエラーのときの情報量が豊富でみやすい

MockK

  • コルーチンは通常特定の場合じゃないと呼び出せない
    • けど、呼び出せるような仕組みがある
  • mock生成は重いから繰り返さないように注意
    • 各テストの前にclearMokcksすればいい

周辺ツール

コーディングガイドライン

  • ktlint
  • シンプルさを保つ
    • Kotlinの思想として簡潔さではなく読みやすさ重視

まとめ

  • Kotlinでも普通にSpringアプリ作れる
  • Javaとの違い意識しないと行けない部分はまだある
  • Reactorとコルーチン相性良し
  • アノテーションやめてKotlin DSL
  • データクラスでテスト結果読みやすく
  • モックはmockKがよい

Observability with Spring-Based Distributed Systems

  • Thomas Ludwig(楽天株式会社)

Observability概要

Observabilityとは

  • ツールと手段を組み合わせてデータとコンテキストから気づきを得る
  • 単純なモニタリングだけでなくもっと深いところまで
    • システムが大きくなると必ずどこかで障害が起きる
  • 最近Observability流行ってるらしい

なぜObservability

  • UXを改善するため
  • 本番に似せた環境があっても全てが同じではない
    • ユーザも違う
  • 自身をもって運用するならサービスの状態を把握しないといけない
  • MTTR(mean time to recovery)が重要
    • 障害が起きた時にどれだけ速く検知して直せるか

分散システム

  • 別のプロセスで並行して処理
  • 複数のプロセスを跨るので難易度が高い
    • 全てのプロセスの情報を見ないといけない
  • スケーリングでそのインスタンスにしかない情報が消えるかも

Observabilityの3要素

  • 3要素かぶってる領域もあれば特化した領域もある
  • どれか一つだけで全部できるというものではない
    • 使い分けるのがベスト

Logging - Events

  • メッセージを残して後でそれを見つけられるようにする
  • 分散システムだと各サービスがログをはくからどこを見ればいいか複雑
    • ログを一箇所に収集して見られるようにしたい
  • Spring Cloud Sleuth
    • ログにIDを振ってくれるのでサービスをまたがってもリクエストの流れを特定することができる
  • 楽天トラベルでは
    • Spring Cloud Config
    • Travel Auto-configuration
      • 独自ライブラリ
      • セッションIDみたいなものを振って同じユーザが何度もアクセスした時に紐付ける
    • ELK
      • Elasticsearch
      • Logstash
      • Kibana

Metrics - Aggregatable

  • 時系列のデータを集計した値
  • 集計した値なのでリクエストが多くてもサイズは変わらない
  • 可視化したい時やトレンドを分析したい時に使う
  • インスタンスが多いとスケールしない
  • Micrometer
    • SpringBoot2から入ってる
    • SLAがあればその値をセットしてアラート上がるようにとかできる
  • 楽天トラベルでは
    • Micrometer
    • Prometeus
    • Grafana
  • Alert
    • あらゆるサービスにアラート入れると多重アラートが発生してしまう
    • ユーザのリクエストを受けるところだけ設定しておくとよい

Tracing - Request scoped

  • パフォーマンス遅延の原因を調査するために使う
  • リクエストの流れがどうなっているか見るために使う
  • Spring Boot Actuator
    • トレーシングの情報がとれるエンドポイントを自動で作ってくれる
Destributed Tracing
  • インスタンスを跨いだトレーシングをしないといけない
  • 一つのリクエストでどのサービスにどれくらい時間がかかったか把握できる必要がある
  • Zipkin
  • Soring Cloud Sleuth: spring-cloud-starter-zipkin
  • 楽天トラベルでは
    • 全てのデータをzipkinに送ると負荷があるのでサンプリングしてる

Putting It All Together

  • 3要素はそれぞれ連携してる
  • 検知 -> 調査 -> 復旧 のサイクルが回せるようになる

500+のサーバーで動くLINE Ads PlatformをささえるSpring

  • 渡邉 直樹(LINE株式会社)

LINEのAds Platform

  • LINEの中に出てる広告
    • LINE NEWSとかLINE Blogとか
  • LINEに広告配信できる唯一のPlatform
  • MAU7800万人
  • 運用型広告
    • リアルタイムに予算やターゲットを変更できる
    • 何を表示するかリアルタイムにオークションにかけて選んでる
      • 全て50ms以内にやらないといけない
  • Real Time Bidding
  • 関係者のニーズを満たす必要がある
    • Advertiser
      • ROI
    • Media
      • 利益
    • Audience
      • UX
  • 指標
    • CTR(Click Through Rate)
      • 簡単な数式
    • CTRを機械学習で事前に予測する

Spring in LINE Ads Platform

SSP(Supply Side Platform)

  • メディア側の情報を管理するプラットフォーム
    • Real Time Bidding
      • リアルタイムにオークションする
  • Spring Boot2
  • CMS側はサーバがKotlinクライアントがNuxt

DSP(Demand Side Platform)

  • ROIが最大化する広告を選ぶ役割
  • 50ms以内に返さないと広告が表示されない
  • Goで作ってる
    • 50ms満たすため
  • G1GCでも数十msかかることある
  • CMS側はサーバがSpringBootクライアントがReact

データの持ち方

  • 広告情報をMySQLに入れてる
    • 毎回取りに行くと50msこえちゃう
    • 基本はメモリに乗せておく
      • 乗らないようなものはRedis

DMP(Data Management Platform)

  • 広告配信する対象を管理する
  • 広告を出す相手の情報があるとより効果的な広告を選べる
  • Look-a-like
    • 似ているユーザの行動をもとに広告を出す
  • 技術
    • SpringBoot
    • Kafka
    • HBase
    • Redis
  • ユーザの操作の度にイベントを飛ばしてそれを受けたらKafkaに書き込む

Data Pipeline/Analytics Cluster

  • 広告配信に関わるデータを収集し格納するプラットフォーム
  • hadoopクラスタ
  • Erasticsearch, kibana

LINEの技術トレンド

Kafka

  • 高速で安定したStreaming Platform
  • queueやjob schedulerとしても利用
  • 各サービスはKafkaに書き込むまでが責務
  • 一度書き込んでおけば誰でも取れる
  • spring-kafkaあるけど公式のkafka_clientおすすめ
    • springの方は自由にバージョン変えられない

SpringBoot2

  • Reactor
    • Reactive Streams
    • Non-blocking
    • back pressure
      • Kafka使ってるからあんまり使ってない
    • Lettuce5
  • kafka
  • actuator + micrometer
    • 使いやすい
    • それまではprometeusにデータ入れてGrafanaで見てた

LINEの開発体制

  • データ
    • 2 Country
      • 日本と韓国
    • 60 Developer
    • 100 Co-worker
  • コミュニケーション
    • 通訳挟んでTV会議
    • 翻訳bot入れてLINEで
    • 気軽に出張も

今後

Spring BootでHello Worldのその先へ〜ウェブDBプレスのSpring Boot特集で伝えたかったこと＆伝えきれなかったこと～

  • 藤野 真聡(ソニーネットワークコミュニケーションズ株式会社)

Web+DB Pressに寄稿した

  • 2018/8号
  • 内容
    • SpringBootの概要
    • HelloWorldの一歩先
  • 伝えきれなかったこと
    • 変化に強いWebアプリの作り方
    • 寄稿したのはプロトタイプレベルだった
  • 今回のない湯

バージョン番号の表示

  • qiitaのAPIを叩くアプリ
  • qiitaのAPIのバージョンを返すエンドポイントを作る?
  • pom.xmlに定義しているバージョン情報に紐づくようapplication.propertiesに定義しておく
  • それをJavaから呼ぶ

モジュール分割

  • プロジェクトフォルダ内に子プロジェクトのフォルダを作る
    • 親プロジェクトも各子プロジェクトもpom.xmlを持つ

ActiveMQ

  • JMS(Java Messaging Service)を実装したメッセージングミドルウェア
  • メッセージをqueueで非同期に処理する

MongoDB

  • ドキュメント指向のDB

Angularを⽤いたデザインスプリント開発と設計⼿法

  • 佐川 夫美雄(アシラス株式会社)

Web Application Design

WebアプリとWebサイト

  • Webサイト
    • 一方向
  • Webアプリ
    • 双方向
  • デザイナーはWebサイト的なものを作る傾向?

Webアプリ

  • html/css/js
  • htmlとCSSはスコープがグローバル
    • モジュール分割もできない

よいプログラム

コンポーネント

  • よいプログラムにするにはコンポーネントを作って組み合わせるとよい
  • Atmic Design
  • 大きなものを作ってそこからパーツを抽出しそれらを組み合わせてページをつくる

Design Sprint

  • デザインカンプ(画面設計書)を作るのが目標
  • WebのUIは細かいとこまで柔軟に作れてしまう
  • イラレで書いたのをXDに貼り付けたレベルでユーザに評価してもらう
    • これをスプリントで回す

Web Application Implementation

WebComponents

  • Custom Elements
    • 自分でHTMLのタグを作れる
  • Shadow DOM
    • CSSにスコープを作れる
  • HTML Template
    • 独立したHTMLかたまりを定義できる
  • (HTML Import) -> 仕様廃止ES Modulesへ
    • テンプレート化されたHTMLをimportできる

JS Frameworkの比較

  • ScopedなCSSを作れるFWを使うべき
  • 3大SPAFW
    • Angular
      • 標準機能でShadowDOM使える
      • まあ全部込みがAngularの特徴だし・・
    • Vue
      • scopedなCSSは標準でできる
    • React
      • 標準機能ではscopedなCSSは使えない？？？
      • styled-components使えばできる
      • 本体を薄くする戦略だし・・・
  • Web標準のShadowDOMにこだわっているのか？
  • だとしても現状polyfill必須だしな

DevOps for Frontend

  • デザインしたものをすぐに確認してフィードバックできるサイクル
  • Github Enterpriseでプロジェクト管理リソース管理
  • クラウドでさくっと環境作ってそこにあげる
    • デモはすぐ見れる
  • Swagger使うとAngularの通信周り自分で書かなくていい
    • Swagger Codegenで生成できる

まとめ

「Node学園 32時限目」に参加してきました

勉強会メモ
  • Node学園に参加してきました。

nodejs.connpass.com

  • 今回は、先日のReactConfから話題沸騰中のReact Hooksについてmizchiさんが解説してくれるということで、とても豪華なイベントでした。
  • 来月のNodeFest2018も楽しみです。
タイトル 登壇者
Node v11 and NodeFest introduction yosuke_furukawa
Node.jsで現実世界の”もの”を動かす話 9wick
React Hooks mizchi

Node v11 and NodeFest introduction

  • yosuke_furukawaさん

NodeFest2018

  • 11/23,24に開催

nodefest.jp

  • ロゴが変わった

Day1: Conference

注目のスピーカー
  • Anna
    • Workerを作った人
  • Rachel
    • Webの中のメディア系のところの話
    • WebGLとかWeb Audioとか
  • Daniel
    • TC39の中の人
    • Class Propertyとか
    • 一日一部屋貸し切り
      • 未知数枠
      • 大物たちが来てディスカッション？
  • Colin
    • libuvの中の人
  • 飯塚さん

Day2: Interactive Sessions

  • NodeとJSのディスカッション
    • 良いとこ悪いとこ改善点
    • 開発者と利用者でディスカッションできる
  • Code and Learn
    • nodeにコミットする
  • Handson
    • SPAとか
    • 海外から来る講師も(未知数)

Node.js v10/v11情報

  • v11はそんなにたいした変更はない
  • v10.0.0 ~ v10.12.0
    • http2
    • ESM
    • Worker追加
  • v11
    • v8のversion7対応
    • url moduleがdeprecated
    • TextEncoder/TextDecoderがglobalになった
    • queueMicrotask APIがexperimental
      • Promiseにタスクを積む

Stream/Promiseの親和性改善

  • for await ofでstreamを逐次処理
  • v10からStreamに追加されたfinished, pipeline APIがPromiseと親和性高い

for await of

for await (const k of readable) {
  data += k;
}

Stream finished API

  • エラー成功にかかわらず終了したらcallbackを呼べるようになった
  • callbackをPromiseにしてしまえばasync/awaitで扱える

Stream Pipeline API

  • before
rs.on('error', errorHandler).pipe(ws).on('error', errorHandler)
  • after
pipeline(rs, ws, (err) => {
  if(err) {
    // ...
  }
}

Node.jsで現実世界の”もの”を動かす話

  • 9wickさん

Nodeでできること広がってる

  • CLI: 一次元
  • Webサーバ: 二次元
  • ものを動かす: 三次元

ものを動かせると何ができるか

  • 現実に鑑賞できる
  • input
    • 音・温度・傾き・土壌・空気
  • output
    • 光・音・モーター・電光掲示板・ロボット

Nodeで動かせるデバイス

rasberry pi

  • 小さいPC
    • node動く
  • IO端子がついてる

arduino

  • PCでなくマイコン
    • node動かない
      • PCで操作する
  • 有線接続
  • IO端子

obniz

  • マイコン？
    • node動かない
      • サーバで操作する
      • インターネット経由で
  • 無線接続
  • IO端子

DEMO

  • clovaでラジコン?を動かす

React Hooks

React Hooks

  • SFCでstateを使う
    • Class使わなくても状態を持てる
  • Dan先生
    • Reduxの作者
    • Reactのコアチーム

reactjs.org

  • ライフサイクルメソッドも使える
    • 毎回走るからComponentDidMount相当のもの作るのは大変
  • Vueでも同じものを作ろうという動きが・・・？
  • recomposeもうメンテされなくなる？
    • 今後はhooksで

今後

  • HOCは推奨されなくなる
  • React.Component -> Function Component

「We Are JavaScripters! @25th」に参加してきました

勉強会メモ
  • We Are JavaScripters!に参加してきました。

wajs.connpass.com

  • WeJSは来月で2周年とのことです！
タイトル 発表者
実践AST FlowtypeからTypeScriptへの移行 @れこ
Node.jsとイベントループ @hiroppy
JSでアニメーションに入門したい @atsuco
ServerlessでIsomorphicにGohanをKetteiしてみた @Seri-Nazu
スポンサーLT: @ブラウザから大容量ファイルを気兼ねなく送る話 Media Do
Google Chromeの履歴情報を抜き出す @camcam_lemon
TypeScriptのトランスパイルTips @sakito
javascriptの参照と値 @brn0227
高階関数の実践: パーサーコンビネータをつくってみた @chikoski

実践AST FlowtypeからTypeScriptへの移行

  • @れこさん(CureApp)

FlowからTypeScripに移行中

  • 中身はmonorepo
  • 量が多いからASTで自動的に変換

FlowとTSの違い

  • Flowは$から始まる特殊な型
  • TSはkeyof
  • 複雑なことしてるほど違いがある

Flow->TS

  • FlowをAST変換
  • babelのコマンドでできる
  • 全ての構文を漏れなくマッピングするのは難しい

AST

  • Abstract Syntax Tree
  • ASTのコードを書き換えるだけでFlow->TSへ変換させることができる
  • PrettierなんかもASTを活用してr

まとめ

  • AST活用してTS変換自動化できた
  • ベースとなる実装があればなんとかなる

Node.jsとイベントループ

  • @hiroppyさん(Dwango, Mercari)

イベントループとは

  • イベントループはメインスレッドで動いてる
    • ブラウザのJSとnodeで仕組みは違う
  • libuv
    • プラットフォームの違いを吸収してくれるやつ
    • 非同期IO

仕組み

  • イベントループのフェーズ
    • timers
    • pending callbacks
    • idle, prepare
    • poll
    • check
    • close callbacks
  • idle, prepare以外は設定されたcallbackが実行される
  • nextTickが一番最初に処理される

まとめ

  • Nodejsはlibvuを使ってる
  • 6つのphaseと2つのtick

JSでアニメーションに入門したい

  • @atsucoさん

アニメーションとは

  • 時間経過に伴いある値を0~100%の間で変化させること
  • 始点、変化量、時間で表される

Webでアニメーション

  • CSSアニメーション
    • 宣言型アニメーション
    • 軽い簡単 -途中で止めたりとかは苦手
  • JSアニメーション
    • 命令形アニメーション
    • 表現力豊か

アニメーションができるJS

  • $.animation()
    • いにしえ
  • Velocity.js
    • 軽い$.animationと互換
  • anime.js
    • 軽い$.animationと互換なし
  • Web Animations API

jsでアニメーション重い？

  • 変化させるプロパティを考える
  • クリティカルレンダリングパス
    • レイアウト
      • 他の要素も影響受けるので再計算されて重い
    • ペイント
      • 他の要素に影響しないので軽い
    • コンポジット
      • opacityは再描画を誘発しない
  • setTimeout()やsetImterval()ではなくrequestAnimationFrame()を使ったほうがよい
    • anime.jsはrequestAnimationFrameを使ってる

ServerlessでIsomorphicにGohanをKetteiしてみた

  • @Seri-Nazuさん(Media DO)

お昼何食べるか迷うじゃないですか

良かったところ

  • Lambdaすごい
    • サーバのこと何も考えなくていい
  • API Gatewayすごい
    • CORSの設定をGUIで一発

まとめ

  • サーバを一秒も考えずに作れた
  • Lambdaガンガン使っていきたい

スポンサーLT: @ブラウザから大容量ファイルを気兼ねなく送る話

  • 泉さん(Media Do)

メディアデュとは

  • 電子書籍の中継
  • 単行本とかだと200-300枚の画像ファイル
  • 画像はFTPで、メタ情報はメールで受け取ってる
    • 出版業界まだアナログ
    • Webアプリ化したい
  • 多くの画像ファイルをどう送るか
    • S3に送ってしまう
    • サーバ負荷気にしなくていい
  • CognitoとS3を使った

Google Chromeの履歴情報を抜き出す

  • @camcam_lemonさん(日本事務器)

ブラウザ何使ってますか？

  • Chromeはいろいろな情報が記録される

History

  • 実態はDBファイル
  • 複数アカウント使い分けても一つのファイル
  • urlsテーブルに閲覧履歴が記録される

Webアプリと連携

  • Historyの情報をWebアプリと連携
  • nodeでHistoryを取得
  • Chromeがファイルを掴んでるからコピーしてから操作
  • データ量めちゃくちゃ多いからそのまま出すと落ちる

TypeScriptのトランスパイルTips

  • @sakitoさん(yahoo)

ts-loader

  • webpackでTSをトランスパイルする時に使う
  • 高速化
    • transpileOnlyをtrueにする
    • HappuPackを使うとトランスパイルと型チェックを並列化できる

awesome-typescript-loader

  • webpackでTSをトランスパイルする時に使う
  • ts-loaderよりts+babelがやりやすい

babelでtsをトランスパイル

  • babelのコンパイラでtsをトランスパイルできる
    • 型チェックは行われない
  • @babel/preset-typescript
  • 一部まだ未対応なので注意

まとめ

  • ts-loader or awesome-typescript-loaderがベター
  • babelを使う時はデメリットを理解して使う
    • 型チェックは別でやること

javascriptの参照と値

参照と値

  • オブジェクトごとにどちらを使うか決まってる
  • 参照
    • Objectを継承したもの
    • 参照は同じものを見続ける
  • 値
    • string, number, boolean

MutableとImmutable

  • 変更できる値とできない値がある
  • string, number, booleanは変更できない
    • stringは内部的には参照渡ししてる

高階関数の実践: パーサーコンビネータをつくってみた

  • @chikoskiさん

高階関数

  • 関数を扱う関数
  • S式
    • 木の書き方の一種
    • (+ 1 2 (+ 3 4 5) (- 4 3 ) (/ 4 2))
  • AST
    • Abstract Syntax Tree

まとめ

  • 関数は部品
  • BNF読めると便利
  • 単機能を組み合わせて複雑な機能を作ってくといい

「MANABIYA #2 - day3」に参加してきました

勉強会メモ
  • MANABIYA #2に参加してきました。

manabiya2.peatix.com

  • 10/19-21まで3日間開催されるイベントの3日目の参加レポートです。
  • day2のレポートははこちらに書いています。
時間 タイトル
0限目 (11:20 - 11:30) 【3-0】オープニング
1限目 (11:30 - 12:10) 【3-1】IoT × AI
2限目 (12:30 - 13:10) 【3-2】Web × モバイル
3限目 (13:30 - 14:10) 【3-3】Special Session：リクルートテクノロジーズ
4限目 (14:30 - 15:10) 【3-4】プログラミング × ブロックチェーン
5限目 (15:30 - 16:10) 【3-5】IoT × セキュリティ
6限目 (16:30 - 17:10) 【3-6】Special Session：キスモ
7限目 (17:30 - 18:10) 【3-7】インフラ × AI
8限目 (18:30 - 19:10) 【3-8】IoT × ブロックチェーン
放課後 (19:30～21:00) 懇親会

【3-1】IoT × AI

登壇者

  • IoT
    • 菅原 のびすけさん(@n0bisuke)
    • 中村 晃一さん(@9_ties)
  • AI
    • 五木田 和也さん(@kazoo04)
    • 中原 啓貴さん

議題

IoTで使うようなコンパクトなコンピューターの中でAIを実装するのと、外(クラウドなど)で実装するのでは、それぞれどんなものを作るのに向いてるのか？
各実例としてはどのようなものがあるのか？
コンパクトなコンピューターの中でAIを実装するには、どんなライブラリ等を使えばいいのか？
最先端の研究事情

最新のIoT × AI

  • ラズパイ上でAIを動かせる
    • リアルタイムに画像認識

youtu.be

  • ARのグラスで見ているものをリアルタイムで3Dで表示させる
    • 熱を持たないとか軽いとか
  • コミュニケーションロボットにAIを入れたいというのが多い
  • ハード界隈でできることとソフト界隈でやりたいことのギャップ
    • 熱問題ファン入れればいいけどマイクにノイズ入っちゃうとか課題も
  • 音声の認識
    • 誰が話してるとか話し始め終わりの検知はできる
    • 文字に起こすのは大変
    • エッジ側で必要なとこ抽出してクラウドに送るとか
      • 音声送り続けると通信量大きすぎる
    • 人間は脳の中で補正をかけてる同じことをしないといけないから難しい

エッジでやるかクラウドでやるか

  • 画像認識の場合全部クラウドに送るのはない
    • 次々送るとコストが大きすぎる
    • プライバシー的にもよくない
  • 画像とか音声はエッジで処理してからクラウドに送るのがいい

【3-2】Web × モバイル

登壇者

  • モバイル
    • 七島 偉之さん(@jollyjoester)
    • 岸川 克己さん(@k_katsumi)
  • Web
    • 古川 陽介さん(@yosuke_furukawa)
    • 宇都宮 佑亮さん(@uskay)

議題

サービスやシステムを作る際、Webアプリとモバイルアプリ、それぞれでは一体何がどう違ってくるのか？
Webとモバイル、どう棲み分けるべきか？何をWebでつくり、何をモバイルでつくるべきなのか？
今後、Webとモバイルを統合していく方向で考えると、どのようなことが困るのか？また、どう作るのがベストなのか？

モバイルとWebの違い

  • 配布の手間の違い
    • ストアからインストールしないといけない
    • リンクにアクセスすればすぐに使える
  • アプリでしかできないこと
    • デバイス機能へのアクセスのしやすさ
    • Webも頑張ってるけど
  • モバイルとWebのUXの違い
    • Webの方がもっさりするとか
  • Webの世界もレスポンスには厳しくなってる
    • RAILモデル
    • Lighthouse

developers.google.com

developers.google.com

  • モバイルでもLighthouseみたいなのあるのか？
    • IDEの機能でできる
  • モバイルのCI
    • AndroidだとCIでビルドとかやりやすい
    • iOSはMacじゃないと
  • パフォーマンスバジェット

html5experts.jp

  • モバイルはUIのコンポーネントが標準化されてる
    • ブラウザはデフォルトのボタンそのまま使うことなんてない
    • submitの動きもそのまま使うことなくてpreventDefaultする

  • storyboardのようなものWebでもないのか

  • iOSはアプリとWebに線を引いてる感じでAndrodはそうじゃないように見える

    • MaterialDesignはアプリもWebも対応
    • ServiceWorker対応のスピード感とか
  • 課金について
    • 価値を感じないと課金してくれない時代
    • インストールは無料にしないと
    • +αで課金してもらう
  • アプリはイニシャルキャッシュがあるWeb
    • インストール時にキャッシュをとってるだけと受け取れば
  • ReactNativeとかFlutterはどうか？
    • 単純ならいいけど結局ネイティブしらないとつらくなる
    • Swift/Kotlinを学ぶことのハードルを高く持ち過ぎなんじゃないか
  • AMP as PWA
    • AMPをSPAFWと同じレイヤーで見るといいかも
  • Webで画像の加工

developers.google.com