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

勉強会メモ

Vue Fes Japan 2023

キーノート

  • Evan you

Rolldown

  • まだearly WIP
  • esbuild代替?
  • Rust?
  • Rspackの人が開発
  • ビルドツール?バンドラー?

社内UIコンポーネントライブラリがエンジニアチームにもたらした本当の価値

chromatic

画面遷移から考えるNuxtアプリケーションをアクセシブルにする方法

A11y

  • Webはそもそもアクセシビル
  • 改正障害者差別解消法
    • 2024/4から障害を持つ人に対する合理的配慮が民間も義務化される
  • VueやNuxtで作られたアプリはアクセシブルになっているだろうか
    • 調査の結果は改善してるが良くない

クライアントサイドルーティングという手法について

  • 通常はサーバでHTML作って返すが、クライアント側でHMTL作って遷移する
  • ViewTransitionsAPI
    • アニメーションつきで遷移できる
    • Nuxtは現在experimentral/対応するブラウザでしか動かない

画面遷移のアクセシビリティの問題点

①何が変化したか支援技術に伝わらない

  • 資格では変化がわかっても支援技術には伝わらないことも
  • wai-ariaのライブリージョンを使う
    • titleの変更を通知する
    • aria-live="assertive" をつけた要素のテキストを変えると読み上げられる
    • 支援技術向けの要素は非表示にするが display: none は駄目

②フォーカスマネジメント

  • ページ遷移したときにフォーカス位置が遷移前の場所になってしまう
  • ページ遷移時にフォーカスしてほしい位置に当たるように制御する
    • 必要に応じて tabIndex="-1" をつける
  • どこにフォーカスを当てるか
    • コンテンツが多い要素にあててしまうと全部読み上げられてしまう(NVDA)
    • 見出し要素に当てるのがいい
    • 見出しがないならスキップリンクへ移動しタイトルを読み上げるといい
    • 上部から始まるようにしておくとよい

③過渡なアニメーションで閲覧阻害

  • アニメーションが原因で体調不良を起こす人もいる
  • 視差効果を切る設定がありその設定による制御ができる
    • prefers-reduced-motion
    • 設定されてたらアニメーションを起こさないといった処理を入れると良い
    • CSSでもmediaクエリで指定できる

画面遷移をWebAPIで解決

  • HistoryAPI
    • 課題はいろいろある
    • vue routerなど使う必要ある
  • NavigationAPI
    • 画面遷移の視点終点とれる
    • スクロール位置やフォーカス位置の復元もできる

Nuxtのa11y

  • ロードマップにa11yが含まれている
    • axe core入れるとか

Nuxt 3でJamstackテンプレートを作るときの考え方

  • まぁし(TAM)

Jamstack

  • JavaScript/API/Markup
  • フロントエンドとデータを分離できる

2023年のJamstack

  • フロントエンドとバックエンドを分離してマイクロサービスを組み合わせて構築していくことそのものを呼ぶようになっている
    • NextやNuxtをVercelやNetlifyでSSRするようなこと

ディレクトリルール

Vue Language Serverから生まれたVolar.jsと、それが秘める可能性

エディタの言語機能

  • 言語機能
    • コード補完
    • リネーム
    • 検索
    • アウトライン
  • Languahe Server Protcol

VueにおけるLanguage Server

  • VueはSFCが独自のフォーマット
    • Vue独自のLanguage Serverがある
    • 今はVue Language Features(Volar)
    • 昔はVeture
  • SFCはvueファイルの中にHTML/JS/CSSがかける
    • 3言語分の機能提供が必要
    • Embedded Language
  • 組み込み言語のLanguage Server
    • ファイルをブロックに分けて仮想的なファイルがあるとみなす
    • 書く言語向けのServiceで処理する
  • templateの中にJSを埋め込める
    • templateの中にもJSの仮想ファイルが含まれている
    • scriptで定義下変数をtemplate内の埋め込みで補完しないと

Volar.js

  • 組み込み言語のツールを作れる
    • Astroやsvelteなども困っている
    • FW固有の最小限のコードを書くだけでLanguage Serverを作れる
    • Language Server以外にもチェッカー(lint的な)なども作れる

「DIST.31 「DIST 6周年記念イベント」」に参加してきました

勉強会メモ
  • DIST.31 「DIST 6周年記念イベント」に参加してきました。

dist.connpass.com

タイトル 発表者
[IDEA]描きながら学ぶかんたんイラスト講座！＋グラレコの仕事がもらえるようになるためにやったこと 湊川 あい
[IDEA]次代のビジュアルブランディングの鍵 柳 太漢
[DESIGN]なぜダメなデザインが生まれるのか 長谷川 恭久
[DESIGN]SPA/PWA時代のWebデザインのお作法 谷 拓樹
[TECHNOLOGY]フロントエンドの技術選定 西畑 一馬
[TECHNOLOGY]品質の岐路に立ったときの実装術 池田 亮
[SOCIAL]特化するということ 中村 享介
[SOCIAL]Web Creation in Society 伊藤 由暁

描きながら学ぶかんたんイラスト講座！＋グラレコの仕事がもらえるようになるためにやったこと

絵にすると何が良いの

  • 脳は文字より画像を好む
    • 五感が知覚しているうち視覚が83%

絵は誰でも書ける

  • 目と口を5種類ずつ用意したらそれだけで25の表情ができる
    • 同じようなものを書いても必ず個性がでてくる

図解の基本形

  • 対比、内包、因果などいろいろ表現できる
  • 図解+感情
    • 図に加えて、だからどうなのかというのを伝えられるとよい

読む人を「楽しませる」

  • 楽しげなものは注目してもらえる
    • 注目した結果。理解が深まる

次代のビジュアルブランディングの鍵

ブランディング

  • 企業が提供する全ての体験を定義設計し個性を作る
  • ブランディングの鍵
    • Story
    • System
    • Science

Story

  • ストーリーがあることで価値をうむ
  • 単に見た目や味だけでは価値は決まらない
    • 背景があることで価値は変動する

System

  • いろんなふれかたがある
  • 点ではなく線面で伝える

Science

  • 情報の触れ方が変わっている
  • 見た目だけでなく五感を刺激する

どのようにビジュアルブランディングするか

  • ビジネスとビジュアルデザインは分けて考えない
    • ビジュアルデザインは古来からある伝えるためのインターフェース
    • リテラルからビジュアルへ
    • ビジュアルデザインは伝えるための重要な道具
  • 流行ってるものに乗っかるとそれは廃れる
    • 長くコミュニケーションをしていく器にする
  • 考えて言語化していくべきこと
    • 顧客に支持される理由
    • これまでの歴史
    • これから目指す未来
  • あとはセンスを爆発させてデザインするだけ
    • ストーリーができたらほとんど勝ったようなもの
  • ブランディングの価値や意図を理解できていると正しく使える

なぜダメなデザインが生まれるのか

注目してもらうためのテクニック

  • 人の集中力は長く持たない
    • 目に入ってもすぐ次のなにかにうつってしまう

情報をわざと見えにくくする

  • unsubscribeを見えにくくしたり
  • 会員登録しなくても使えるのに登録フォームをだしたり

ベストプラクティスを逆手に取る

  • YesとNoのボタンで
    • Noの色をプライマリーカラーにしたり
    • Yesをレッドにしたり

罪悪感を促す

  • Noのボタンを罪悪感ある文言にしたり

偽ｘを設置する

  • 閉じるのxボタンをおいてタップさせる
    • コンバージョン稼ぎ
  • 偽の髪の毛を画像に入れて払わせる

なぜこんなことをやるか

  • いろんな事情がある
    • 食べていくためしかたない
    • 他がやっているからしかたない
  • スキルを持っているとデザインで騙すことができてしまう
    • デザインでどうやって課題解決するのがよいか立ち向かっていかないといけない
    • 上の例のようなデザインにならないようにしていかないといけない

我々に何ができるか

  • PV数
    • 単純に数値が増えればいいだけなのか？
    • 閲覧したからといって読んでるかわからない
    • それによってユーザは満足しているのか？
  • エンゲージメントの定義が変化している
    • ユーザが有益な時間を過ごせてるかどうかを考える
    • インスタではもう閲覧済みのものを知らせくれる
      • 単純にPV数だけを追い求めない
  • 良い見た目 + 課題解決へのコミット

SPA/PWA時代のWebデザインのお作法

  • 谷拓樹さん(サーバーエージェント)

Webとアプリ

  • Webがアプリと比べても遜色なくなってきてる
    • そんな中でどうやってWebをデザインしていくか

PWA

  • Progressive Web Apps
    • オフライン
    • プッシュ通知
    • 独立したUI
    • リンク可能
    • 発見性
    • インストール不要
  • Webの特性とアプリの特性を兼ね備える

SPA

  • 非SPA
    • リンクをクリックするとサーバからHTMLを受け取って表示する
    • サーバサイドレンダリング
  • SPA
    • データだけ取得して画面を書き換える
    • ヘッダーなどを継続して表示し続けられる
    • クライアントサイドレンダリング

状態を持つWeb

  • Design for "Stateful" Web
    • 状態を持つWebをデザインする
    • UIデザインにおいても状態を持つことを意識する必要がある
  • 考えるべきページの状態
    • https://yasuhisa.com/could/article/ui-design-bugs/
    • Blank State(空白)
      • 非同期でデータを取得して0件だったら？
    • Loading State(読み込み)
      • 画面全体だけでなく部分的なローディングも考慮が必要
    • Partial State(部分的)
      • データが部分的に取れているときの状態
    • Error State(エラー)
      • 部分的なエラーも考慮が必要
    • Ideal State(理想)
      • 理想のデータが入った状態
    • この5個だけでなく例外もある

読み込み

  • ローディングをデザインする
    • => ユーザにどう待ってもらうかをうデザインする
  • ユーザは待ってくれない
    • どういったデザインで待ってもらうか
      • ローディング中はオーバーレイする
      • 情報を取得中ですと出す
      • ローディングのぐるぐるのUIを工夫する
  • 旧にオフラインになる体験
    • ブラウザのエラー画面を出したくない
    • ネットワークが切れたらオフラインであることを通知してあげるとか
  • オフライン以外にもいろいろある
    • 低速な環境
    • 速度制限がかかった状態
    • データセーブをオンにしている

フロントエンドの技術選定

  • 西畑一馬さん(to-R)

プロジェクトの周期

  • イニシャル開発 - リリース - 運用フェーズ
  • イニシャル開発
    • リリース日が決まってることも
    • 何が何でもその日にリリース
    • リリースというゴールがある
  • 運用フェーズ
    • イニシャル開発と比べると期限がゆるいケースが多い
    • アジャイル的に
    • 目標はあってもゴールはない
      • 走り続けないといけない

人員の周期

  • 約1~2年くらい
  • なぜ辞めていくか
    • 少しずつ破綻していくシステムにストレス
    • スキルや温度感の差にストレス
    • ビジネスサイドとの確執
    • 飽きた
    • 新しいことがしたい
  • 新メンバーの苦悩
    • ビジネスドメインの理解
    • 既存システムの不満
  • プロジェクトは人に依存するが人は流動的

技術選定

  • SPAで作る必要があるか
    • 静的サイト
    • サーバサイドシステム
    • CMS
    • SPA
  • Developer Experiment
    • 作る人が作りやすいもので作らせる
    • DXが高ければ定着しやすい
    • 採用する人員に高いスキルが求められることにもなりかねない
  • 技術選定はイニシャル開発の前だが長いのは運用フェーズ
    • イニシャルのメンバーに依存した技術選定はよくない

品質の岐路に立ったときの実装術

  • 池田亮さん

fps

  • fps(フレームレート)
    • 1秒間に処理されるフレームの数
    • Webブラウザにおけるfpsは60
    • 50以下の場合ブラウザに無理させてるかも
    • マシンスペックにも依存するから注意
  • stats.jsで可視化できる

負荷対策

リアルタイムぼかしをやめる

  • 雰囲気を出しやすいが高負荷
    • 毎フレーム処理をしないといけない
  • ぼかした画像を用意してクロスフェードして対応

大きすぎるテクスチャを使わない

  • 大きい画像は処理するデータ量も多い
  • 同じ画像でも小さく表示するものは小さい画像を使う

素材は使い回す

  • 素材がたくさんあればデータ量も多い
  • 同じ見た目のものなら使い回すようにする
    • three.jsの場合、geometory/materialを必要なパターン用意して使い回す

リアル表現をしない

  • リアルな見た目を追い求めすぎない
    • たとえば球体を正確な球に近づけるほど負荷が高い

fpsを下げる

  • 擬似的にfpsをコントロールすることができる
  • three.jsの場合、renderするところで制御できる
  • アニメーションのスピードが速いところは違和感出るからどこを下げるか工夫はいる

画質を落とす

  • 画質が高いほど負荷が高い

要素情報の取得は効率よく

  • スクロール連動アニメーション
    • いろいろあるけどブラウザごとの対応がまちまちなものも
  • ウィンドウのリサイズ時に位置などとりたい
    • 負荷が高いから毎フレームはできない
    • 30fps下げて2フレームごとに取得するとか
    • 正しい値が取得できたら取るのをやめるとか
    • 正確性と負荷のバランスを見極める

まとめ

  • リアル表現をしない
  • それっぽく見せる工夫をした表現

特化するということ

特化って何？

  • 特定の部分に重点を置くこと
  • 業務内容を限定して専門化すること
  • 狭い範囲を扱う職業の方が特化する

特化する理由

  • 集中できる
    • 特化するとその仕事を繰り返す
    • ノウハウが溜まって詳しくなる
  • ブランディング
    • 何ができるのかわかりやすい
    • プロフェッショナルにみえる

何に特化するのか

  • 特化するものを間違うと大変
  • 何に特化するか
    • 得意なもの
    • 需要があるもの
    • 自分がいいと思ってるもの
  • やらないことを決めておく

特化したものを変えていく

  • 変えるのは簡単
    • 自分で決めれば変えられる
  • あるタイミングで特化していて時間の経過とともに普通になってくることも
    • 10年前ならJavaScript専門の会社なんて全然なかった
    • 今はたくさんあるのでJamstack専門の会社に変えた

まとめ

  • 全部を取得するのは難しいから特化したところのスキルを伸ばす
  • 特化した人が集まるとすごいものが作れる

Web Creation in Society

Web制作はなんのためにやってるか？

  • 生活のため
  • 自己表現のため

Webサイトは誰が使ってる？

  • ユーザはさまざまな属性をもつ
    • 個性
    • デバイス
    • 閲覧環境
    • 一時的な制限
  • 何かを制限してしまっているかもしれない
    • 性別が「男」「女」しかない
    • マウスホバーでしか開けないドロップダウン
    • 色だけに除法をもたせたデザイン
    • などなど

社会におけるWeb制作において必要なこと

  • ユーザが自由に利用できるようにする
  • ユーザが望む形で利用できるようにする
  • いろんな人にやさしいサイトはいろんな人が使いやすいサイト

まとめ

  • Webサイトはユーザのために作る
  • ユーザは多様である
  • ユーザが自由に利用できるようにする

「Developers Summit 2020（2日目）」に参加してきました

勉強会メモ

event.shoeisha.jp

タイムテーブル

10:00～10:45

タイトル 発表者
チーム・ジャーニー 〜逆境を越える変化に強いチームをつくりあげるまで〜 市谷 聡啓[DevLOVE]
「ともにつくる」を実践するドメイン駆動設計 成瀬 允宣[GMOインターネット]
レガシーコードからの脱却 吉羽 龍太郎[アトラクタ]
エンジニアよ、今こそ社会課題に立ち向かおう！ 関 治之[Code for Japan]
AWS障害で考えさせられた、アプリケーションインフラ構成の注意ポイント 城 航太[サーバーワークス]
佐藤 豊[サーバーワークス]
組織の創造性を高めるために必要なこと 伊藤 直樹[PARTY]

11:05～11:50

タイトル 発表者
新しいHTML<portal>を利用した画面遷移設計 〜PayPayモールとYahoo!ニュースの事例を添えて〜 萩野 誠一[ヤフー]
関 真由美[ヤフー]
守りのモニタリングから攻めのモニタリングへ 大谷 和紀[New Relic]
開発に集中するためのJava on Serverless 下川 賢介[アマゾン ウェブ サービス ジャパン]
エンプラアジャイル導入の守破離 小俣 剛貴[Pivotalジャパン]
安西 結[Pivotalジャパン]
プリンシプル・オブ・"ともにつくる"～ Web Performerを支えるドクトリン ～ 上田 勲[キヤノンITソリューションズ]
職種の垣根を越えるコミュニケーションのススメ 池村 和剛[ゆめみ]
吉田 理穂[ゆめみ]
小川 段[ゆめみ]
戸田 修輔[ゆめみ]

12:10〜12:40

タイトル 発表者
A retro on agile ー アジャイルをふりかえる Jason Wong[Atlassian]
K8S使ってますか？リテールテック（小売・決済等）でのコンテナ活用例と「2025年の崖」克服に向けたコンテナ導入のススメ！ 程 建強[Rancher Labs]
山澤 一仁[スーパーソフトウエア]
井川 知幸[カゴヤ・ジャパン]
Python基礎試験とデータ分析の例題解説～稟議に使えるPython市場データと試験も紹介～ 吉政 忠志[Pythonエンジニア育成推進協会]
寺田 学[Pythonエンジニア育成推進協会]
全アプリ開発者に伝えたい、レガシーコードから脱却するための具体的な手法、"ルール駆動開発" 松田 絵里奈[レッドハット]
自己組織的な開発チームを如何にして作り上げるか 木利 友一[TIS]
アジャイルのプロセスとデザイナーの変化-開発チームに欠かせないデザイナーになるために- 樋田 勇也[サイボウズ]

13:05～13:50

タイトル 発表者
問題から目を背けず取り組んでいく ･･･ 一休のこれまで 伊藤 直也[一休]
プロダクトを10年運用するチームをつくる 粕谷 大輔 [はてな]
エッジコンピューティング、エッジAIの可能性 中村 晃一[Idein]
日本にJoy,Incを創る！どん底からスタートしたぼくらのジョイインクジャーニー7年間の軌跡 安田 忠弘[クリエーションライン]
アジャイル開発の原則を守りつつ、マルチサイト開発を行なう！ ～ベトナムのメンバーとともにつくる～ 藤村 新[クラスメソッド]
デザイナー/リサーチャー/エンジニアが語る、UXとの関わりかた 松薗 美帆[メルペイ]
山本 興一[スマートニュース]
重田 桂誓[クックパッド]

14:10～14:55

タイトル 発表者
事業グロースを加速させる「分析基盤」の作り方【JapanTaxi/ホワイトプラス事例】
1ヶ月でデータ基盤を整え経営の解像度を変えた話 		森谷 光雄[ホワイトプラス]
伊田 正寿[JapanTaxi]
小林 寛和[primeNumber]
グランブルーファンタジーを支えるサーバーサイドの技術 小松 美穂[Cygames]
大橋 庸[Cygames]
クラウド・ネイティブ時代に最適なJavaベースのマイクロサービス・フレームワーク ～ Helidonの実力を見極めろ！ 古手川 忠久[日本オラクル]
マルチクラウドに向けてNGINX活用促進する為に知っておいてほしいこと 鈴木 孝彰[NGINX (Part of F5)]
AI3分クッキング グティエレス パウロ[Databricks Japan]
テクノロジーとクリエイティブがコマース体験を変革する 河野 貴伸[フラクタ]

15:15～16:00

タイトル 発表者
世界最高の靴売場をシューカウンセラーとともにデジタル変革してみた 鈴木 雄介[アイムデジタルラボ]
河村 明彦[アイムデジタルラボ]
サービスメッシュは本当に必要なのか、何を解決するのか Yasuhiro Tori Hara[Amazon Web Services Japan]
オープンソースのこれまでとこれから 川口 耕介[Launchable]
メルペイリリースとその後一年間の裏側と学び 木村 秀夫[メルペイ]
生涯イチ・エンジニアとして好きな技術でジャンプアップし続けよう - 夢のつづきはビッグデータで 中川 伸一[JX通信社]
クリエイティブとブランディングの関係 山口 義宏[インサイトフォース]
枌谷 力[ベイジ]

16:20～17:05

タイトル 発表者
TOYOTA x Serverless x Microservices 〜 グローバル展開のコネクティッドカーを支えるアーキテクチャとエンジニアリングチーム 浦山 雄也[トヨタ自動車]
松本 崇之[トヨタコネクティッド]
内海 英一郎[アマゾン ウェブ サービス ジャパン]
エッジコンピューティングの時代にサーバーはどこにいくのか、自社製品をハッキングしてもらった話 及川 信一郎[日本ヒューレット・パッカード]
Hackが好きなエンジニアが組織をHackしてみる考えと実践を経てきたヒストリー 萩原 北斗[うるる]
イケてるコードが書けるITコンサル最強説。 知る人ぞ知るエンジニアの楽園。 真野 隼記[フューチャー]
澁川 喜規[フューチャー]
塚本 祥太[フューチャー]
月間約10億件のクラッシュデータから見えたアプリ品質の実態！ エンジニアが仕掛ける、『ONE TEAMで挑む、賢いアプリの品質管理』とは？ 仲井 裕紀[FROSK]

17:25～18:45

タイトル 発表者
キャリアトランスフォーメーションをみんなで考えよう～開発者から事業責任者、役員へのキャリアパスはどうよ～
エンジニアの事業継承
自分のハンドルは自分で握れ
偶然の出来事の流れに身を任せエンジニアからマネジメントの道に進んだ話。 		【司会】岩切 晃子[翔泳社]
石井 智康[石井食品]
市谷 聡啓[ギルドワークス/エナジャイル]
黒田 樹[リクルートテクノロジーズ]
雲の中心で愛を叫ぶ！ クラウド横断パネルディスカッション 濱田 孝治[クラスメソッド]
松村 優大[オルターブース]
高野 遼[クラウドエース]
【司会】近藤 佑子[翔泳社]
IT業界で誰もが輝くために：ダイバーシティを考える
技術書におけるジェンダーと 「わからない」を掘り下げる価値
女性向けテックコミュニティが必要な理由とポイント 		川口 耕介[Launchable]
職業「戸倉彩」/湊川 あい[湊川プロジェクト]
今ものづくりは非エンジニアが面白い！～IoTLT・ProtoOut StudioスピンオフLT 【司会】菅原 のびすけ/土井 勝之[千葉厚生会]
三木 啓司/小池 誠[小池農園]
ななみん/農上 裕子/土田 哲哉[Surface&Architecture]
家族型ロボット「LOVOT」から考えるテクノロジーの裏側とその未来 林 要[GROOVE X]

エンジニアよ、今こそ社会課題に立ち向かおう！

  • 関 治之さん[Code for Japan]

Code for Japan

  • 「ともに考え、ともにつくる」
  • 行政と市民がともに考える
  • Civic Tech

社会課題とテクノロジー

  • 社会課題の解決にはテクノロジーが必要
  • 社会課題解決に対する投資が増えてきている
    • SDGs
    • 社会課題を悪化させるような取り組みには投資がされないようになってきてる
  • Society5.0
    • 政府が掲げている取り組み
    • テクノロジーが必須となるものばかり
    • どっかの大きい企業がやってるんでしょ、ではなく多くのデベロッパーが関わるべき
    • 「正しいものを、正しくつくる」を行政もやるべき

伽藍 vs バザール

  • 伽藍
    • 緻密な計画
    • 中央集権
    • 長いリリース期間
  • バザール
    • 変更を受け入れる
    • 自律的な小さい集団
    • 早めに細かくリリース
  • 市区町村などのシステムは伽藍でそれぞれisolate
    • 行政の仕組みもバザールモデルの形にできるんじゃないか
    • 市区町村同士も連携していけるのでは
    • 市民の意見を取り入れていけるのでは

新しいHTML<portal>を利用した画面遷移設計 〜PayPayモールとYahoo!ニュースの事例を添えて〜

  • 萩野 誠一さん[ヤフー]
  • 関 真由美さん[ヤフー]

Portalsとは

  • ページの体感速度が速い方がよい
  • アプリのような遷移体験をWebでも実現できる

の特徴

<a> <iframe> <portal>
ページ遷移 ○ x ○
ページを表示 x ○ ○

導入事例

  • PayPayモール
    • 検索ページから商品ページへの遷移にPortalsを使用
    • List to Detail
  • Yahooニュース
    • 記事から記事への遷移にPortalsを使用
    • Detail to Detail

Portalsのデザイン

  • ページのつながりをシームレスにできる
  • Portalsを使えば音声の再生を継続したままページ遷移できる
    • iframeではできない
  • アプリの設計に似ている
  • SPAでなくMPAであってもリッチな体験を提供できる
  • 意識しておくといいところ
    • プログレッシブエンハンスメント
    • グレースフルデグラデーション
    • 非対応のブラウザを使ってる人にどう見せるかの考慮も必要

Portalsの実装例

  • JSでPortalタグを埋め込む
    • 非対応ブラウザのための分岐も入れておく
  • アニメーションで全画面化する(この時点ではページ遷移してない)
  • .activate()を実行するとでページ遷移する
    • 遷移が完了するとportalactivateイベントが発火する
  • portalタグに対して引数も渡すことができる
    • event.dataで受け取れる
  • event.adoptPredeccessor().activate()で自分が埋め込まれていたもとのページに戻ることができる
  • window.portalHost.postMessage(...)でportalとして埋め込まれたページから埋め込んでいるページにメッセージを送れる
    • portal内のページのロードが完了してから表示するといった感じで使うといい

Portalsの良い点/悪い点

  • 良い点
    • MPAでもシームレスな画面遷移が実現できる
  • 悪い点
    • 対応ブラウザがまだChrome(Canaryでフラグを立てると有効)のみ
    • インプレッションが埋め込まれたportalが表示した時点でカウントされてしまうのでの計測の仕方に工夫が必要そう

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

  • 中村 晃一さん[Idein]

Idein

  • 機械学習技術 -> 高い壁 -> プロダクト化/ビジネス化 -> 高い壁 -> ビジネスのスケール
  • 高い壁を取り除く会社

エッジコンピューティング

  • クラウドコンピューティング
    • データがデータセンターに集約されて処理される
  • エッジコンピューティング
    • 末端のデバイス状や近くに設置したサーバで計算をする
    • 複数の階層で分散して処理する
    • デバイスだけで計算してしまうものや、エッジデータセンターをはさむものなどいろいろ

エッジコンピューティングがなぜ注目されてる？

  • データセンター・回線のキャパオーバー
  • プライバシーへの関心の高まり
  • 超低遅延化の需要増加

データセンター・回線のキャパオーバー

  • コネクテッドデバイスの急増
    • 今後も増える傾向
  • 計算負荷・データ量の大きいアプリの需要増加
    • 画像を扱うなど
    • DeepLearning
  • 必要最小限のメタ情報だけ送信することで通信コスト削減

プライバシーへの関心の高まり

  • GDPR
  • GAFAなどに個人情報全部吸い上げられるとかならないように
  • 必要最小限のメタ情報だけをクラウドに

超低遅延化の需要増加

  • リアルタイム性が求められる
    • 自動車、ロボット、ドローンなど
  • 5G
    • 無線の区間のスピードがめちゃくちゃ速くなる
    • その先の有線の区間は遅い
      • 5Gを活かし切るにはデータセンターまでつなげない

ソフトウェア産業

  • インターネットエコシステムが物理的なところまで拡大していく
    • 小売、製造業、物流、医療
    • 複雑化する計算機システムをうまく扱う技術やプロダクトが登場する
  • 既存産業から見ると危機的状況と言えるかもしれない
    • ハード -> ソフト・サービス・データ
    • 組み込み -> 配信
    • 売り切り -> サブスク

Actcast

  • Ideinの提供するサービス
  • SDK
    • 安価なデバイスで高速に動くエッジAIアプリを開発できる
  • Dashboard
    • 多数のデバイスからなるシステムの運用に必要なものを備える
  • Marketplace

SDK

  • SDKかませることでどんなデバイスでも動くものを出力できるようにしている
  • 要件が定義できない領域が多い
    • PoCは安価なデバイスでその後はフィットしたデバイスで
    • そういうことをやろうとしたときにソフトウェアが変わってしまうと大変だから

Dashboard

  • Web上から別のモデルをデプロイしたりとか
  • APIでたたけるようにしたりとか

Marketplace

  • SDKとDashboardは無償でStoreの手数料で売上をあげてる
  • デバイスに遠隔インストールできる
  • サブスクなのでとりあえずあり物で動かして、その後遠隔で差し替えるとかがやれる

ユースケース

  • セキュリティ
  • 製造業IoT
  • 小売・決済等- スマート氏r費
  • デジタルサイネージ
  • 受付システム
  • インフラ監視

テクノロジーとクリエイティブがコマース体験を変革する

  • 河野 貴伸さん[フラクタ]

Eコマース

  • 制約が多い？
  • O2O,OMOが求められるのであればクリエイティブもオンラインオフラインの結合が求められる
    • O2O・・・Online to Offline
    • OMO・・・Online Merges Offline
  • 実際に体験してもらう
    • これらをどう低コストにしていくか
  • Eコマース -> コマース
    • リアルとデジタル(OfflineとOnline)の境目がなくなってきてる

デザイナーとデータサイエンティストの共創

  • データを持ってるのでそれを活用していく
    • 1st Partyなデータを持っているのが強い
  • データをクリエイティブに活かす
    • クリエイティブに説得力を持たせる

クリエイティブリバランス

  • ECは作るものが多い
  • どこに力を入れてどこの力を抜くか
    • テンプレートを使えるものはそれを活用していく
  • 商品の360度プレビュー
  • ARで配置してサイズ感を確認

シンボリックエクスペリエンス

  • 視覚だけでなく音や匂いや手触りなども含む
  • Slackの通知の音をきいたらSlackだなってすぐに思える
  • 音なども含んだブランド設計

これからのコマース

  • 日本だけではジリ貧
  • 世界に目を向けないといけない
  • 日本のものを世界に売っていく力が足りていない
  • デザイナーやエンジニアが持っている知見を投入していくことが必要

サービスメッシュは本当に必要なのか、何を解決するのか

アプリの成長

  • 最初は小さなアプリ
  • 成長するにつれて大きくなる
    • うまく動かないところも出てくる
    • 障害が起きると夜中に叩き起こされる人もでてくる
  • ある日マイクロサービス化しよう、と言い出したとき既存アプリはモノリスとなる

モノリスとマイクロサービス

  • Monolithという呼称に込められるニュアンス
    • 関係者調整にオーバーヘッドがある
    • 変更による影響範囲が広い
    • モジュール構造維持が難しい
    • スケーリングが効率的にできない
    • テスト・ビルドに要する時間が長い
  • マイクロサービスに期待される効果
    • 変更による影響範囲の局所化
    • モジュール協会の維持しやすさ
    • 独立したデプロイとスケーリング
    • 自律的なチームによる開発・運用
    • Polyglot(-able)

モノリスの考察

  • 現実世界のモノリスは複雑
    • ALB - EC2 - Aurora だけならシンプル
      • EC2を冗長化したり
      • バッチ処理があったり
      • Redis使ったり
      • S3にファイル置いたり
      • トレーシングのための処理も組み込まないと追跡できない

マイクロサービスの考察

  • マイクロサービスの課題
    • サービス分割の適切な粒度が分からない(正解がない)
    • 依存物との連携を考えるとテストが難しい
    • 影響範囲を自サービス内に収めるのが難しい(使ってる人が使い続けられる状態での改修)
    • サービス間通信の信頼性(Reliability)
      • ネットワークを経由して連携するということは失敗することは考えないといけない
    • サービス間通信の可観測性(Observability)
      • 各サービスでログがはかれるのでシステム全体として何が起きているか把握しづらい

サービス間通信の信頼性(Reliability)

  • ネットワーク経由で通信 = 失敗が前提
    • => 各サービスで防御的実装が必要
信頼性を高める防御的実装
  • 呼び出し先の場所は一定ではないのでダイナミックに場所を特定できるようにしたい
    • サービスディスカバリ
  • 呼び出し先の都合によって一時的な失敗も起きる
    • リトライ
  • 障害などで継続した呼び出しの失敗が起きていたらアクセスしないようにしたい
    • サーキットブレーカー
  • SLOを守るために呼び出し先サービスのパフォーマンスが悪ければ接続を切りたい
  • 呼び出し元システムの不具合で失敗するアクセスばかり受けることを防ぎたい

サービス間通信の可観測性(Observability)

  • マイクロサービス群は外から見ると1つのシステム
    • どこでなぜ失敗したか追えるようにしておかないといけない
可観測性を高める実装
  • ログ/メトリクス/トレース情報の出力
    • 各サービスで出力フォーマットが不揃いだとコンテキストが見えない
    • => 全サービスの出力フォーマットを統一したい
    • => 考え方もスキルもフレームワークも違うので難しいし変更コストも高い
  • 共通ライブラリを作ってとりこんでもらう？
    • アプリに手を入れないといけない
    • 共通ライブラリのせいでパフォーマンス劣化
    • 言語やフレームワークのバージョンに広く対応する？
    • 共通ライブラリのメンテ側も大変
  • マイクロサービス化して疎結合な実装で自律的なチームで開発したかった
    • 共通ライブラリを作ると結局密結合になってしまう
    • => そこでプロキシ

サービスメッシュ

  • 全ての通信を通るプロキシを置いてそこで共通的な処理をする
    • =>これがサービスメッシュ
  • プロキシにサービスディスカバリ、タイムアウト、リトライ、ログ出力など全て入れる
    • 各サービスにマイクロサービス用の実装をいれなくてよくなる
  • EnvoyProxy
    • 代表的なサービスメッシュ
    • OSS
    • CNCFが運営してる
    • 多くの本番実績もある
    • yamlでプロキシの設定を書いて読み込ませる
  • プロキシとアプリケーションの密結合
    • 一貫性と疎結合性のためにプロキシを選択したはず
    • プロキシの設定変更にはデプロイと再起動が必要
    • それぞれのライフサイクルとオペレーションモデルが違う
  • AWS App Mesh
    • Envoyがダウンタイムなしで動的に設定変更できる

　

月間約10億件のクラッシュデータから見えたアプリ品質の実態！ エンジニアが仕掛ける、『ONE TEAMで挑む、賢いアプリの品質管理』とは？

  • 仲井 裕紀さん[FROSK]

スマホアプリの品質

  • 品質(UX)
    • UI/速度/不具合

アプリの不具合

  • よくある不具合
    • クラッシュ
    • UIが崩れる
    • かたまる
    • 仕様と異なる
  • アプリ品質が悪いと継続率に10%影響が出る
    • エンジニアだけの問題ではない

アプリのクラッシュ

  • 4割以上が週1回以上アプリクラッシュ経験してる
  • クラッシュすると
    • ユーザが離脱する
      • 7割以上の人がクラッシュが原因で使わなくなったことがある
      • 長期的な継続率に10%くらい差が出る
    • 新規ユーザの獲得率を下げる
      • レビュー見てダウンロードやめちゃう
      • レビューに「落ちる」を含むアプリ:☆1.9
      • 一般的なアプリ:☆3.5
    • GooglePlayではクラッシュ数に応じて順位を降格させている
  • クラッシュを放置することは穴の空いたバケツに水を溜めようとしてるようなもの

なぜクラッシュが起きるのか

  • すべての環境でデバッグ/テストできない
    • Android種類多すぎ問題
      • 上位20端末でようやくシェアの3分の1
      • OSと組み合わせると組み合わせが膨大に
    • iOSはVUPみんなするからころころバージョンが変わる
    • OSの不具合もちらほらと
  • 不具合検知の仕組み
    • 正確にエラーを取るのは困難
    • 保存しておいて次回起動時に送信とかが多い
      • クラッシュしたのに次回起動があるのか？
  • クラッシュの対応
    • 情報量が少ないと対応しようがない
      • 端末依存？
      • OS依存？
      • 環境が特殊？
      • ユーザの勘違い？
    • 再現できないとなおせない

クラッシュ問題への向き合い方

  • 以下のサイクルを回す
    1. 自社アプリの品質を正確に把握
    2. クラッシュ率をKPIとして管理
    3. 影響範囲の大きい不具合から効率的に修正
    4. 品質問題の影響範囲を最小限に留める工夫
  • 週1回くらいのサイクルで回していくといい
    • 評価のいいアプリはそれくらいで回してる

自社アプリの品質を正確に把握

  • 不具合を「社内で気づく」に
  • 日常的に品質をモニタリング

クラッシュ率をKPIとして管理

  • レビューとクラッシュ率の相関が見えている
    • 落ちるのレビューがないと1.5%くらい
    • 落ちるのレビューがあると7%くらい
  • 1%以下を目指すと良い
影響範囲の大きい不具合から効率的に修正
  • どの不具合から改善するか
    • 定量的にどれからやるか決めるよい
    • 発生回数など

品質問題の影響範囲を最小限に留める工夫

  • レビュー依頼はクラッシュ率の高いときは出さない
  • 不具合が分かってるならアナウンスすると低評価を防げる
    • 親切心で報告として☆1つけてレビュー書いてくれる人もいる
  • エラーの情報とユーザの情報を紐付けて管理
    • 改善したことを報告できるように

「Developers Summit 2020（1日目）」に参加してきました

勉強会メモ

event.shoeisha.jp

タイムテーブル

10:00～10:45

タイトル 発表者
出勤から企業開発者を解放し、エンジニアの働き方改革を実現するリモート開発環境構築 増渕 大輔[日本マイクロソフト]
起業家的？！エンジニアのススメ 玉川 憲[ソラコム]
最新のブラウザで変わるCookieの取扱いやプライバシーの考え方 古川 陽介さん[リクルートテクノロジーズ]
LINEがプライベートクラウドを選ぶ理由 室井 雅仁[LINE]
UXデザインが大事なのはわかるけどエンジニアの私ができることってなんでしょう？ 安藤 昌也[千葉工業大学]
ITがモビリティを創る：MaaSに向けた技術とエンジニア像 伊藤 昌毅[東京大学]

11:05～11:50

タイトル 発表者
ノーコードPower？だけど開発者だからこそ知っておきたい、Power Platformの使いこなしかた～〜W王子より愛を込めて 廣瀬 一海[日本マイクロソフト]
清水 優吾[セカンドファクトリー]
モノタロウがGCPで挑戦するデータドリブン・ECプラットフォーム〜持続的成長の舞台裏 普川 泰如[MonotaRO]
藤本 洋一[MonotaRO]
CircleCIの3000 万件のワークフローから得られたDevOpsに関する知見 車井 登[CircleCI]
ぼくらの六十日間戦争 ～ｵﾝﾌﾟﾚからｸﾗｳﾄﾞへの移行～ 左近充 裕樹[ブロードリーフ]
doda開発者が語る IoT＆サーバレスでビジネスサイド変革に挑戦した話～イノベ観点のダッシュボタン＆負債から進化したアーキテクチャ～ 上源 勇朗[パーソルキャリア]
アプリケーションやシステムが悪い奴らに攻撃されたらどうなる？ 松岡 正人[日本シノプシス]

12:10〜12:40

タイトル 発表者
Let's Dive in Developer Community! 小田 祥平[日本マイクロソフト]
加藤 健大[テイ・デイ・エス]
Kubernetes未経験者がGKEの本番リリース〜障害対応を経験して苦悩した話 泉水 朝匡[grasys]
noteの決して止まらないカイゼンを支える、エンジニアリングへの挑戦 今 雄一[ピースオブケイク]
サーバーレスなPCI DSS対応クレジットカード決済基盤システムを運用しながら、みんなでわいわいDIYの精神で、新しいモバイル決済サービス6gramを作っている話 田岡 文利[ミクシィ]
常識を破壊するティール組織とエンジニアリング組織論 片岡 俊行[ゆめみ]
音声認識で質の高い議事録を！議事録サービス「GIJI」 川端 光義[アジャイルウェア]

13:05～13:50

タイトル 発表者
我々はZOZOTOWNのクラウドジャーニーを通じて何を学んだのか？ 川崎 庸市[ZOZOテクノロジーズ]
質とスピード 和田 卓人[タワーズ・クエスト]
インターネットが変えた世界・変える未来 伊勢 幸一[さくらインターネット]
創業105年の旅館運営企業が実現した毎週リリースするチームの作り方 藤井 崇介[星野リゾート]
Webパフォーマンスガチ勢が本当に使っている技術 中村 けん牛[プライム・ストラテジー]
若年層におけるプログラミング的思考の学びの場づくりと動機づけ 鷲崎 弘宜[早稲田大学]
齋藤 大輔[早稲田大学]
坂本 一憲[早稲田大学]

14:10～14:55

タイトル 発表者
楽天がモノリス→マイクロサービス & オンプレ→クラウドで経験した光と闇 柳本 浩一[楽天]
新井 庸介[日本マイクロソフト]
Best Practices In Implementing Container Image Promotion Pipelines -知っておくべきコンテナイメージ・プロモーションの方法 Baruch Sadogursky[JFrog]
批評家不要！気がつきゃ全員エンジニアリング。アジャイルなTeamでプロダクトを生み出し続けるスマレジとEBILABの挑戦とこれからの企業の存在意義 小田島 春樹[EBILAB]
常盤木 龍治[EBILAB]
山本 博士[スマレジ]
宮崎 龍平[スマレジ]
ともにつくる「DX」〜事業会社、スタートアップ、グローバル、そして・・・「あなた」〜 福井 勝史[Insight Edge]
Googleにおける「ソフトウェア×インフラ」デザイン〜マイクロサービス・アーキテクトの視点から〜 中井 悦司[グーグル・クラウド・ジャパン]
Salesforceで変わるこれからのアプリケーション開発と開発者の働き方 田中 宏樹[セールスフォース・ドットコム]

15:15～16:00

タイトル 発表者
GitHubやMicrosoftが機能リリースする舞台裏 服部 佑樹[日本マイクロソフト]
田中 裕一[ギットハブ・ジャパン]
Hondaの生産技術屋さんがソフトウェア開発でアジャイルを初導入し組織変革に挑戦 岩根 義忠[ホンダエンジニアリング]
松浦 洋介[NECソリューションイノベータ]
星 直人[ホンダエンジニアリング]
矢田 将[ホンダエンジニアリング]
礼節から育てるチームの健康と信頼性 塩谷 啓[クラスメソッド]
テストエンジニアが教える　テストコードを書き始める前に考えるべきテスト 風間 裕也[ビズリーチ]
なぜ技術力評価会の評価者はペアなのか？ー 8年半で378組の評価者ペアが835回評価した事例からみるペアの効果 ー 小賀 昌法[VOYAGE GROUP]
「厳密な共通言語」としての形式手法 チェシャ猫[ProofCafe]

16:20～17:05

タイトル 発表者
GateboxにおけるAzure AD/AD B2Cを基盤としたID Centricな組織・サービス・プラットフォームの設計 久森 達郎[Gatebox]
コンテナをシンプルに使おう 〜 Cloud Run のすゝめ 2020 冬 篠原 一徳[グーグル・クラウド・ジャパン]
InterSystems IRIS Data Platformで高度なデータ分析のための基盤を整備しよう 堀田 稔[インターシステムズジャパン]
エンジニアはものづくりの夢を見るか - AWS Loft Tokyo 入館アプリの開発事例 - 西谷 圭介[アマゾン ウェブ サービス ジャパン]
今村 優太[アマゾン ウェブ サービス ジャパン]
クラウドサービスとゲーミフィケーション:「TwilioQuest 3」を用いた開発者オンボーディング 池原 大然[Twilio Japan]
少量データで軽量な機械学習の手法について 秋吉 信吾[QuantumCore]

17:25～18:45

タイトル 発表者
俺たち一生楽しい厨二病〜トッキー、ジニアス、漆原の赤裸々トーク〜 漆原 茂[ウルシステムズ]
常盤木 龍治[EBILAB]
ジニアス平井[日本マイクロソフト]
「ITエンジニア本大賞 2020」プレゼン大会 【司会】高柳 謙/【特別ゲスト】永瀬 美穂[アトラクタ]
【特別ゲスト】広木 大地[レクター]
【特別ゲスト】山下 智也[英治出版]
若手エンジニアの登竜門「Developers Boost 2019」優秀セッション再演！
組織にモヤッとしたら聞く話
エンジニア×〇〇 ～職種を「越境」して希少性を出すキャリア～
入社2年目からスクラムマスターとしてチーム改善に取り組んだ話 		蜂須賀 大貴[IMAGICA Lab.]
池上 純平[プレイド]
西山 慧[ヤフー]
エンジニアと人事がともに考えるエンジニア採用
エンジニアと企業、それぞれの立場から見た採用市場の実情
エンジニアが人事と一緒に採用活動する時に考えたいジョブディスクリプション
認識ギャップが不幸の始まり・・・不思議な造語「カジュアル面談」を考える 		【モデレーター】金山 貴泰[うるる]
てぃーびー（田部井 勝彦）[スタディスト]
伊藤 哲弥[LAPRAS]
安立 沙耶佳[ヌーラボ]
梶原 成親[ヤプリ]
チームをつくるモブプログラミング ～内側と外側から語る～ 及部 敬雄[デンソー]
安井 力
あのイベントの裏側が知れる！？カンファレンス運営者LT 西馬 一郎[Backlog World]
島根 義和[JaSST Tokyo]
岸川 孝明[JAWS DAYS]
高橋 慎一[明日の開発カンファレンス]
谷本 心[JJUG CCC]
細澤 あゆみ[XP祭り]
柏岡 秀男[PHPカンファレンス]
【司会】鍋島 英莉[翔泳社]

最新のブラウザで変わるCookieの取扱いやプライバシーの考え方

最近のブラウザ

  • セキュリティ/プライバシー周りの変更が多い
  • Safari
    • ITP
  • Firefox
    • ETP
  • Chrome
    • SameSite Cookie
      • クロスサイトでのCookieの受け渡し禁止
    • Mixed Contentsブロック
      • HTTPSからHTTPのリソース読み込みブロック
    • UserAgent文字列固定化
      • フィンガープリンティングに使われてしまわないように
  • 3rd party Cookieに関してはChromeが一番厳しい対応
    • 他は非推奨に対してChromeは廃止という語気
  • 表示しているページのoriginと異なるなるoriginのCookie
    • これを制限しようという動きが広まってる

Cookieとは

Cookieを使ったトラッキング

  • a.comのページでb.comの広告を見た
    • b.comにアクセスしたという情報がCookieに保存される
  • b.comにアクセスすると過去にアクセスしたことがわかる
  • c.comでb.comの広告を見る
    • 過去にa.comにも行っている人だと紐付けられる
  • Cookieを使うことで広告の最適化などしていた

JavaScriptによるCookieのセット

トラッキング

  • トラッキング全てNGにするとWebの収益モデルが崩れる
  • Cookieでトラッキングするのがダメと言われてる
    • なんでもCookieを使うのがよくない
  • プライバシーに配慮した利便性のいい仕組みが必要
  • Safari
    • Private Click Measurement
      • 広告をクリックしてそこから購入したことをCookieなしで検知できるようになる
      • コンバージョンしたかどうかだけしか分からず何を買ったかなどは削られる
  • Chrome
    • Privacy Sandbox
      • Cross-Site Trackingの再定義
      • 3rd Party Cookieの廃止
      • 新しい方法への移行を表明(まだ何も決まってない)
    • Privacy Budget
      • 個人識別情報を一定数超えたらもう渡さない
        • UserAgent固定も予算制限のため
      • どれだけの情報が個人識別可能なのか
    • Trust Tokens API
      • Botじゃ答えられない問題出して人かどうか判別
    • Federated Learning of Cohorts

どう対応すればよいか

  • Cookieの取り扱い
    • セッションとしての扱いにとどめる
    • Secure属性とHttpOnly属性をつけてサーバで発行する
    • JSでのCookie書き込みは極力減らす

アプリケーションやシステムが悪い奴らに攻撃されたらどうなる？

サイバーインシデントはなぜ起こる

  • サイバーインシデント
    • ある調査によるとビジネス上の課題でサイバーインシデントはトップ要因
    • ソフトウェアの品質がビジネスに直結する
  • サイバーインシデントの要因
    • 悪い人が意図して起こす
    • 悪意のない人が意図せず起こす
  • コード量が増えるとリスクは増える
  • サイバーインシデントによる影響
    • 制御プログラムの不具合によるリコールが増大
    • 生命の危機や社会インフラの停止につながることもある
      • 飛行機の墜落の事故
    • => 攻撃されたときの影響も甚大
  • 現代のソフトウェア開発の課題
    • コード量
      • ソフトウェアはミッションクリティカルなインフラ
    • 複雑度
      • 様々な技術
    • 開発速度
    • リスク

よりセキュアなアプリケーションの開発

  • 解決すべき課題を明確にする
    • どんなものを扱っていて何をやったら何がわかるのか知らないといけない
    • フレームワーク/プログラム/OSS/API/OSなどなど
  • どんな脆弱性を持っていてどういう危険性があるのかちゃんと理解して対策をとる

品質を向上しセキュリティリスクを低減する

  • 脅威モデル
    • 攻撃の入り口
      • 外部から
      • 内部から
        • 事例の7割は内部に協力者がいる
    • アセットの配置を整理
    • 人を想定
    • 管理策を構成
  • Microsoft: STRIDE
  • OWASP: Application Threat Modeling
  • Openid Foundation: OAuth 2.0 Treat Model/IETF RFC6819

noteの決して止まらないカイゼンを支える、エンジニアリングへの挑戦

noteのグロースモデル

  • 作者が集まる -> コンテンツが集まる -> 読者が集まる -> コンテンツが売れる -> 作者が集まる
    • 矢印の数値を監視して数字が落ちているところを補強していく
  • 単一のKPIを追わない
    • バランス良く勝手に伸びるような構造

noteのチーム

  • 基盤チーム
    • グロースモデル全体を活性化
    • KPIの監視
    • プッシュ通知の基盤
  • 機能開発チーム
    • MAX3ヶ月くらいのスパンで主要な機能を開発
  • カイゼンチーム
    • アジリティ重視でPDCAをひたすら回す
    • 長くても2週間くらいのスピード感

noteのデータ

  • noteが成長してきてグロースモデルの状態が把握しづらくなってきた
    • 人も増えて関係者が増えてきた
  • データ活用の機運が高まった
  • データの取得
    • 言葉の定義
      • 離脱とはなんなのか？などなど
  • データ収集のための分析基盤構築

今後何をやっていくのか

  • グロースモデルの発展は継続
  • パフォーマンスの改善に力を入れる
  • レコメンドの向上

我々はZOZOTOWNのクラウドジャーニーを通じて何を学んだのか？

ZOZOTWONのリプレース

課題

  • 時間がかかるリソース調達
  • インフラ構築運用の手間増大
  • システム負荷に波がある
  • セールのタイミングで負荷が大きくかかる
    • 一番使われる量に合わえせてサーバを毎年買い足さないといけない
    • オンプレからクラウドへ

リプレース戦略

  • リプレース前は超密結合

  • 戦略

  • アクセスを受けるサーバはそのまま(いろいろあるので)

  • そこから呼び出すAPIをクラウド/コンテナ化
    • 負荷の増減が激しいところなので
    • Nginx+SpringBoot
  • マルチクラウド
    • SPOFを回避したい
    • AzureとAWSで
    • 最初にAzure選んだのはID周りがいいから

ZOZOのクラウドジャーニー

  • クラウドは不安定であるという前提で考える
    • 再起動などでサービス断が必要になる場合も
    • リソース共有型相乗り型である場合がほとんど
  • クラウドは責任共有モデル

堅牢性より回復性

  • ダウンタイムやデータ損失を回避してサービスを維持できるシステムに
  • 参照系APIの回復性機能
    • マルチエンドポイント
      • 負荷分散
    • オートヒーリング
      • k8sの機能で
    • APIリクエストのリトライ
      • マルチクラウド間でリトライ+流量割合制御
    • APIリクエストのサーキットブレーカー
      • 無限リトライ防止

クラウドリソースは有限

  • 抽象化してるだけで有限である
  • 想定を上回るような利用をする場合は注意
  • ピーク時にキャパシティ確保失敗した事例あり

クラウドは決して安くない

  • オンプレとはモデルが違う
    • 減価償却モデル/従量課金モデル
    • 長期的にみると割高になることも
  • コスト削減の取り組み
    • アクセス少ないタイミングでDBのコア数を調整
    • リソースの使用率を平準化させる
    • できれば動的にこれをやりたい

学習の基本姿勢

  • クラウドにおいては自己学習が基本
  • Slerやベンダーサポートへの丸投げ方式ではスピード感を保つことは難しい
    • メンターメンティーの関係がちょうどよい
  • 最後は自分たちで闘うという姿勢

Googleにおける「ソフトウェア×インフラ」デザイン〜マイクロサービス・アーキテクトの視点から〜

  • 中井 悦司さん[グーグル・クラウド・ジャパン]

テーマ

  • デブサミで毎回インフラの話しをしてる
  • インフラの次を考える時代になってきてるので今回のテーマにした
  • マイクロサービスアーキテクト
    • SREとペアになるような考え方

GCPの魅力

  • Googleのソフトウェアエンジンと同じ体験を一般のデベロッパーに提供するもの
  • Googleの考え方
    • 世界中の情報を整理し世界中の人ボトがアクセスできて使えるようにする
  • 専用回線によるグローバルネットワーク
  • 社内でコンテナ管理Borg
    • それをOSSにしたのがk8s

GCPを使っていく上での悩み

  • どう組み合わせればいいの？中の人はどうやって使ってるの？
  • Google社内ではマイクロサービスという言葉は使わない
    • 最初に作った検索エンジンがマイクロサービスだった
    • それが当たり前なのでわざわざマイクロサービスって呼ばない
  • インフラの中の話はいろんな論文がたくさんでてる
    • どういう風にサービスを組み合わせるといいかはほとんどない
    • 社内にはあるけど公開できない

マイクロサービスWebアーキテクチャ

  • Web3層アーキテクチャ
    • クライアント - Webサーバ - Appサーバ
  • マイクロサービスWebアーキテクチャ
    • クライアント - reverse proxy - BFF - 同期系サービス(n個) - 非同期系サービス(n個)
    • BFFで外部に見せるAPIとサービス実装を分離
  • Googleにおけるマイクロサービス基盤の構成
    • Magleb - GFE - (grpc) - 同期系Borg Job(n個 - 非同期系Borg Job(n個)
    • だいたい同じ
    • GCPのサービスに置き換えて考えることもできる
  • スクラッチで新しく作るならこれでできるかもね

既存アプリのマイクロサービス化

  • マイクロサービスのメリット
    • スケーラビリティ
    • サービス単位での開発デプロイ
    • 新異能のリリースを安全に素早く
      • 依存関係を気にせずに特定機能の改修に集中
      • チームごとの独立性、並行開発並行リリース
    • 何か改修する時に色んな所に手を加えなくて良いのがメリット
      • 人間がマイクロサービス単位で捉えられるので理解しやすい
      • トラブルシュートもやりやすくなる
      • 他のチームと合わせて開発リリースするのは大変
  • マイクロサービスのデメリット
    • サービスの独立性を確保した設計を初期段階で行うのは難しい
    • 将来の機能拡張なんて予想できない
    • サービス全体をリファクタリングする瞬間はどうしてもでてくる
  • 既存アプリがMVCで実装されている場合
    • 特定のコントローラーを外だししてみよう
    • 既存モデルの参照を必要としない機能を外出ししてみる
      • 既存モデルの参照が必要な部分は残す
  • オンプレ塩漬けの場合
    • BFF作って既存システムを抽象化して機能単位でリプレース
    • 既存クライアントは廃止して新規クライアントからBFFを叩く
    • 塩漬けオンプレがサービスの一つととらえることができるようになる

マイクロサービスによるシステム設計

  • アプリケーションの機能を適切に分割する作業
    • BFFで外部公開する機能とサービスとして内部実装する機能の切り分け
    • サービス感の連携方式
  • それぞれのマイクロサービスを実装する方式を考える作業
    • 実行プラットフォーム
    • xxx

Hondaの生産技術屋さんがソフトウェア開発でアジャイルを初導入し組織変革に挑戦

  • 岩根 義忠さん[ホンダエンジニアリング]
  • 松浦 洋介さん[NECソリューションイノベータ]
  • 星 直人さん[ホンダエンジニアリング]
  • 矢田 将さん[ホンダエンジニアリング]

登壇者

従来

  • プロジェクト制だとカットオーバー後の変化に追従できなかった
  • OneTeamでやっていくには属人化を防がないといけない
  • 動くソフトウェアこそが要求を洗練させる最善の方法

アジャイル開発

スクラム開発スタート

  • 振り返りに力を入れた
  • 自ら考えるチームへ
    • 各スプリントで課題を何か一つでも解決させようとした
    • いつでもNowが自己ベスト

スクラムマスターから7つの質問

  • 最初からチームとして成立していた？
    • さまざまな部門の人がかかわっていた
      • それぞれ優先するものが違う
      • 同じ方を向くことが難しかった
  • PO/SMはどうやって決めた？
    • 入社したての人を選定
      • 新しいことをやるなら新しい人がいい
  • チーム編成は何が一番大切？
    • ロールに対してどんな期待値があるのか
    • 同じ方向を向くために価値観をあわせる
  • ベロシティって上がらないし周りに見せにくいどう管理したらいい？
    • xxx
  • ベロシティを下げるプラクティスってどうなの？
    • モブプロやペアプロ
    • どういった課題にたいするアプローチか共有してやってくといい
  • 開発チームに全て委ねるって怖いのでは？
    • 開発チーム以外も含めてみんなで議論して進めていったから大丈夫だった
  • チームの成長を促す方法ってどんなことをすればいいの？
    • 学びのスピードフィードバックを得るまでのスピード

不確実性のコーン

  • 最初はウォーターフォールでやろうとしてたから仕様書があった
    • 突き合わせてみたら25%程度しか必要なものは残らなかった
    • 不確実性のコーンが実証できた

今後の展開

  • 対象を広げる
    • 他のプロジェクトでも
  • フェーズを広げる
    • 運用段階でも
    • DevOpsを回せるように

少量データで軽量な機械学習の手法について

  • 秋吉 信吾さん[QuantumCore]

リザーバコンピューティング

  • 特徴
    • 簡単かつ高精度
      • 少ないデータでも十分な精度を出せる
    • とにかく速い
    • 安価
  • もともと物理学
  • 特徴抽出で活用する
  • 線形分岐不可能な問題を分類できるようになる

なぜリザーバコンピューティング

  • 市場規模
    • 2030年に国内AI市場2兆円超え
  • データの質と量
    • データ不足/ユーザからの利用許諾
    • データクレンジング/偏り
  • 軸
    • バッチ処理 <-> リアルタイム
    • パーソナル/少数データ <-> ビッグデータ
    • リアルタイム + パーソナル/少数データが空いている
  • ターゲット
    • 個人に合わせる必要がある分野
    • 環境に合わせる必要がある分野

活用例

  • スマートウォッチ
    • 加速度データ
    • 泳法判定など
  • 画像データ
    • 骨格情報抽出/骨格の動き波形
    • モーション判定など
  • 振動データ
    • 振動センサー
    • 寝姿勢はんていなど

課題

  • ビジネス上の課題
    • なぜうまくいくのか説明するのが難しい
  • 技術的な課題
    • 音声などノイズが多いものは難しい

エンジニアと人事がともに考えるエンジニア採用

  • 【モデレーター】金山 貴泰さん[うるる]
  • てぃーびー（田部井 勝彦さん）[スタディスト]
  • 伊藤 哲弥さん[LAPRAS]
  • 安立 沙耶佳さん[ヌーラボ]
  • 梶原 成親さん[ヤプリ]

転職透明化ラボ

  • 採用担当者と求職者の間の情報の非対称性
    • 採用担当者の知識を求職者へ還元する取り組みをやっている
  • 今回はエンジニアと人事との間

エンジニアにとって採用はなぜ重要？

  • 会社にとって重要なのはわかる
  • 個人にとって何が嬉しい？
  • 給料
    • 優秀な人を採用できると事業が成功して自分の給料が上がる
  • 職場体験
    • コミュニケーション能力の高い人が入って組織内の関係性が良くなると職場体験が向上する
  • キャリアアップ
    • 自分にはないスキルを持った人が入ってきたら新しいスキルを教えてもらえる
  • 直接的ではないが大きな影響がある

エンジニアと企業、それぞれの立場から見た採用市場の実情

  • 伊藤 哲弥さん[LAPRAS]

エンジニア側から見た採用市場

  • 超売り手市場の実態
    • IT人材が不足している
  • エンジニアの質
    • 課題解決型から価値創造型へ
  • 一極集中の構図
    • n数の企業から1候補者に送られてスカウトメールの数
      • 1企業:22%
      • 2-5企業: 50%
      • 6-10企業: 18%
      • 11-20企業: 8%
  • Laprasに53万人エンジニアが登録してる
    • スカウトメールを受け取ってるのは1%
  • 企業の採用要件も特定の技術領域に集中してる

企業側から見た採用市場

  • エンジニアが採用に関わるべき背景
  • ディスコーズを形成することが重要
    • TechBlogなど
  • エンジニアは採用担当と面談したいと思っていない
    • 技術のわかるエンジニアと話したい
  • エンジニアのキャリア
    • Engineering Manager
    • Tech Lead
    • Product Manager
    • こいったキャリアを目指すのであれば採用に関わるべき

まとめ

  • IT市場は今後も超売り手市場
    • ただし引く手あまたの人とそうでない人がいる
  • 人事がエンジニア採用のフロントに立つことの弊害
    • エンジニアも協力していく必要性

エンジニアが人事と一緒に採用活動する時に考えたいジョブディスクリプション

  • 梶原 成親さん[ヤプリ]

ジョブディスクリプション

  • 具体的な職務内容
  • 必要とされるスキルなど
  • 企業側の情報開示のひとつ
  • 業務の内容や進め方までイメージできたら最高

書いておきたいポイント

  • やってほしい職務
  • 採用している言語技術関連ツール
  • 応募資格(前提条件)
  • 歓迎要件

書いてあるとなおよいもの

  • 仕事の進め方
    • 案件開始から終了まで
  • 仕事で関わる人
  • 直面している課題
  • 採用している背景

いいジョブディスクリプションの書き方

  • いろんな会社のJDを読みまくる
    • 30くらい見ると良いものと悪いものが見えてくる
  • 現場の課題をヒアリングしてそれが欲しい人材ということ

認識ギャップが不幸の始まり・・・不思議な造語「カジュアル面談」

IT業界市場

  • エンジニアが足りない
  • 企業の側から声を掛けていかないと人がとれない
  • => カジュアル面談

カジュアル面談

  • 面談？面接？
  • Wantedlyが作った用語という説
  • カジュアル面談ブームで困ったこと
    • いきなり志望動機を聞かれる
    • 逆パターンもあって興味あるからメール送っただけでなぜ採用しようと思ったか聞かれることも
    • 両者の認識齟齬が起きる

ヌーラボでは

  • 面談の定義を決めて候補者に伝える
    • 候補者と企業のギャップを埋められるように何を話すか決めておく
    • 興味があったら応募してくださいと一回相手にボールを渡す
  • 選考フローを設計ししゃないで共有する
    • 面談の前後で採用担当者と面談担当のエンジニアで認識合わせの打ち合わせをしてる

「LINE API × Tech API Vol. 2 Powered by AWS」に参加してきました

勉強会メモ
  • LINE API × Tech API Vol. 2 Powered by AWSに参加してきました。

linedev.connpass.com

  • 日本ではスマホアプリがなかなかインストールされなくなっていて、スーパーアプリからミニアプリを使うという流れが中国(WeChat)で進んできているとのことです
    • 先日のPWA Night Conferenceの基調講演でも同じような話ありました
  • その流れからのLINE内でミニアプリを作るハンズオンをやりました
    • LINEという誰もがインストールしているスーパーアプリに乗っかってしまえという発想で説得力ありました
タイトル 発表者
LINE APIでAWS上でアプリを作ろう 2020！ 比企 宏之さん(LINE)
サーバーレスでの分散トランザクション Taewoo Kimさん(クラスメソッド)
AWSでつくるLIFFアプリ 松永勇太さん(ACCESS)
LIFF meets AWS serverless 鈴木哲詩さん(AWS)

LINE APIでAWS上でアプリを作ろう 2020！

  • 比企 宏之さん(LINE)

日本のアプリ事情

  • なかなかインストールされない
  • ホーム画面も埋まってる
  • 通知も見てくれない
  • 使ってないと気付いたらアンインストールされちゃう

中国のアプリ事情

  • WeChat Mini Program
  • WeChat上にアプリ(Mini Program)があってそこから開く
  • WeChat Mini Programのアクセス
    • QRコード
    • 公式アカウント
    • GPSで近くの店舗に対応したもの
  • 日本のスーパーアプリ
    • 決済アプリが次々スーパーアプリ化を表明

LINEの状況

  • LIFF
    • LINE内にWebアプリ
  • LINE MINI App
    • LIFFをミニアプリとしてパブリッシング
    • すでにいくつも公開されている
      • 「ホーム」->「サービス」

LIFF

  • LINE Frontend Framework
  • HTMLやJSで作れる
  • LIFF UI <-> LIFF SDK <-> クラウドサービス
  • LINEのトーク画面に3段階の大きさで表示できる(全画面も)
  • LINEの通知使える
  • 端末変えても情報引き継げる
  • Share TargetPicker(3月上旬リリース)
  • ミニマイズウィンドウ(4月以降リリース)

サーバーレスでの分散トランザクション

  • Taewoo Kimさん(クラスメソッド)

マイクロサービス

分散トランザクション

  • 全部成功するか全部失敗するか
  • マイクロサービスで実現したい
    • Distributed Saga
  • AWS Step Functions
    • どんな順番で処理をするか定義できる
    • 失敗した場合はこういう分岐とか

AWSでつくるLIFFアプリ

LIFFアプリをデプロイする

  • AWS CDK
    • プログラミングするだけでCloudFormationが作れる
    • GUIでやらなくていい
    • TypeScript
  • 構成
    • S3にReactアプリ配置
    • CloudFront経由でアクセス
  • LIFFをReact+TSで作る
    • LIFFの型定義は野良のしかない
    • liff-type

LIFF meets AWS serverless

  • 鈴木哲詩さん(AWS)

Chalice

  • マイクロフレームワーク
    • サーバーレスアプリをPythonで作る
  • AWS公式のフレームワーク
  • Lambdaを使う上で考えること
    • アプリ作る
    • どうやってLambdaにデプロイ
    • Lambdaはどのサービスへのアクセス権限を持つ
  • ChaliceとAPI Gatewayを組み合わせる
    • chalice deployでデプロイできる
    • IAMロールの設定勝手にやってくれる
    • chalice invokeで叩くこともできる
    • S3へのアップロードをトリガーにみたいなこともできる

ハンズオン

「PWA Night CONFERENCE 2020」に参加してきました

勉強会メモ
  • PWA Night CONFERENCE 2020に参加してきました。

conf2020.pwanight.jp

  • GoogleやMicrosoftの中の人にも登壇していただき最新の情報を紹介してもらえて勉強になりました
  • 通常版では何かのテーマにフォーカスすることが多いですが、こういった機会で改めてPWAの現状を認識できたのも良かったです

タイムテーブル

時間 タイトル 発表者
13:10- 基調講演：Edge of the web えーじ
14:05- スケーラブルPWA 〜こえのブログ最新事例〜 原 一成
Webでできる体験を考える会 折原 レオナルド賢
14:40- 日経電子版のモバイル/PC版統合と今後の取り組み 酒井 宙幸
ScrapboxでのServiceWorkerとCacheの活用 飯塚 大貴
15:20- Why PWA should be on strategy map for eCommerce companies in 2020. Patrick Friday
PWA x PlayCanvasについて 羽賀 流登
15:55- AMP + PWAで実現するストレスのないページロード 清水 智公
進化するHTTP 奥 一穂
16:35- PWAに取り組む前に知っておきたいSPAとSEO 関 憲也
まもなくやってくるVue.js 3 川口 和也
17:10- Taking your web app offline (in a good sense) Maxim Salnikov
Unlocking new capabilities for PWA 吉井 健文
18:00- エンディング講演：PWA on Windows 物江 修

基調講演：Edge of the web

PWA

  • 2015年にGoogleのエンジニアがブログで紹介したのが最初
  • 個別の技術は前からあったがPWAとくくることで広まった
  • 従来のWebとは違うものという印象を与えてしまって面も
    • Webの進化の流れのひとつでしかない
    • 今あるWebに少しずつ追加していくことができる

PWAのいいところ

  • ホーム画面に追加した簡単にアクセスできる
  • アプリストアからもインストールできたらいいのに
    • Progressive Web Apps in the Microsoft Store
      • PWAのアプリを見つけたら自動でMicrosoft Storeにのせられる
      • オプトアウトとかもできる
    • Googleは？
      • TWA(Trusted Web Activities)

TWA (Trusted Web Activities)

  • 特徴
    • AndroidアプリにPWAを埋め込むことができる技術
    • ブラウザとストレージが共有できる
    • Google Play Storeにのせられる
  • Webとストアでどう違うか？
    • OYOの例
    • コンバージョンはストアの方が高い
    • ログイン率も高い
  • Google Playの規約とかどうなるの？
    • 規約に沿わないといけない
    • ストアからインストールしたアプリから課金などしたら手数料も必要
  • どうつくるか

developers.google.com developers.google.com web.dev

Project Fugu

www.chromium.org

Origin Trials

developers.chrome.com

  • Webの機能は性質上必ずどこかのブラウザベンダーが先行する
  • URLをホワイトリスト化して特定のURLだけ通常のChromeでも使えるようにする

BadgingAPI

web.dev

  • インストールしたPWAにバッヂを付けられる
    • 通知何件的なあれ
  • navigator.setAppBadge(42)みたいな感じで実装する
  • FireFoxからも好感触らしいので広まってくるかも

Shortcuts

github.com

  • ホーム画面のアイコン長押しすると特定の機能に直接アクセスできる
  • Microsoftから提案
  • web app manifestで定義することになる

Web Share

web.dev

  • Webページをアプリに連携して共有したい
  • インテントを送るためのAPI
  • navigator.share

Web Share Target API

web.dev

  • 他のアプリが送ってきたインテントを受け取って何かしたい
  • web app manifestに受け取るURLなど書く
    • そこで受け取れるのでその後の処理を実装する

web.dev

SMS Receiver API

web.dev

  • インドなんかはほとんどのサービスが電話番号で認証
    • SMSでワンタイムコードを受け取って認証
  • OTPを入力するのを簡単にするAPI
  • GoogleがAppleと交渉して進行中
  • Appleの提案
    • autocomplete="one-time-code"

github.com

Clipboard API

web.dev

  • クリップボードに追加された画像も扱えるようにする
  • パスワードコピーしてて勝手に扱われるようなことあったら困る
    • ユーザの許可がないと扱えないように

Contact Picker

web.dev

  • アドレス帳の情報を扱うAPI
    • ユーザにWebに渡したい情報を選んでもらってそれを扱う
    • ネイティブアプリだとまるごとサーバにアップロードなんてあるけどWebではそんなことはできないように

Native File System

web.dev

  • File System APIというのもあった
    • Chromeだけで使えた
    • 特定の領域のFileだけを使える
  • OSのファイルシステム全てにアクセスできる
    • ユーザが選んだファイルであればどこにあるものでもアクセスできる

Web Authentication

developers.google.com

  • デバイスと公開鍵暗号方式を組み合わせてセキュアな認証を実現する
  • セキュリティキーなどがキーペア生成して公開鍵をアプリへ
  • スマホを認証器として使うと生体+所持の2要素担保できる
  • サーバ側の実装複雑にはなるけど今後広まってきそうな技術

Whats comming next?

Privacy Aware Web

  • プライバシーをより大事に扱うという流れ
  • Third party cookies
    • First party
      • アクセスしてるサイト
    • Third party
      • アクセスしてるサイトでないところ
      • リソースをとりにいくときにCookieが送られてしまう
      • それを制限していく
    • iframeで埋め込んだページへのアクセスなんかも制限されることに
    • ソーシャルログインによるID連携も壊れてしまうかも
    • SameSite属性のデフォルト値が変わる
      • Chrome80から
      • 新しいCookie設定Set-cookie: SameSite=None;Secureの準備を始めましょう
    • https://developers-jp.googleblog.com/2019/11/cookie-samesitenone-secure.html

MiniApp

  • アプリの中にアプリをインストールできるエコシステム
  • WebViewでWebアプリの中にアプリをインストールできる
  • この機能を持ったアプリをスーパーアプリと呼ばれる
  • 仕様の標準化が進んでいる

https://w3c.github.io/miniapp/white-paper/w3c.github.io

まとめ

  • PWA is just a branding Believe in the web
  • Many new powerful features are coming to the web
  • Get ready for the privacy aware web and mini apps ecosystem

スケーラブルPWA 〜こえのブログ最新事例〜

PWA

  • UXにフォーカスしたWebアプリ
  • 好ましくない例
    • ローディングが長い
    • 意図しないレイアウトの変更
    • モバイルなのにPC版の画面
  • Googleの定義
    • Reliable
    • Fast
    • Engaging

PWAの事例

  • こえのブログ
  • 喋った内容を投稿して公開できるサービス
  • Webで実現している
  • 音声のファイルが重い
    • wasmで処理
    • WebWorkerを活用
    • IndexedDBに保存

工夫したところ

  • Single Origin with HTTPS
  • App Strategy
    • すでにAmebaのアプリがあるけどWebで
    • 試験的なものなので素早く提供したかった
    • アプリに入れるとアプリ自体のサイズがかさんでしまうという懸念もあった
  • Polyfill
    • 最新のブラウザには最小限のファイルを
    • 古いブラウザにはpolyfillを含んだファイルを
  • パフォーマンス
    • 速くて困ることはない
    • Googleでは速度が遅いとそれを表示するようなことも検討
  • キャッシュ
    • CDN
      • できるだけ長くキャッシュして速く返せるように
      • DBの値が変わったらすぐに更新できるように
      • キャッシュヒット率98%
    • クライアントキャッシュ
      • ServiceWorkerでCacheAPI使ってキャッシュ
  • Perf Budget
    • 最初ははやくてもだんだん遅くなってくる
    • LightHouseなどで継続的な計測
      • 点数よりもメトリクスが重要
      • 競合と比較
        • 20%はやいと体感できるレベルで違う
    • 目標値を設定
      • FCPやTTIまでの時間
      • リソースのファイルサイズ
      • この数値(予算)を超えないようにしていく
      • 超える場合は予算を増やしたり改善を目指したり
    • CIで回して変化があったらすぐに判断できるようにする
  • Writing Tests
    • unit testing
    • visual refression tesingしてる
  • Accessibility
    • color contrast
      • 屋外で見づらいとかみんな関係あるところ
    • Accessibility Tools
      • Accessibility TreeというChrome拡張
      • VisBugというChrome拡張
    • キーボードのAccessibility
      • どこにいるかoutlineが表示されてるか
      • modal開いた時にそのなかで操作できるか
    • prefers-reduces-motion
      • アニメーション無効化してる人にはその対応も
    • DarkMode
      • prefer-color-schemesで切り替え
  • Wake Lock
    • 無操作でも画面が暗くならないようにする機能

日経電子版のモバイル/PC版統合と今後の取り組み

日経電子版リニューアル

  • 2010/3創刊
  • 2019/10トップ画面を中心にリニューアル
  • PCとモバイルの統合

モバイル版とPC版

  • モノリスな構成
    • middlewareできゃっしゅなど
  • 2017年モバイル版のみリニューアル
    • サーバサイドをマイクロサービス化
    • Fastlyでルーティング

課題

  • PC版とモバイル版でアーキテクチャが変わった
    • 開発チームが分断
    • なにかするために両方でやらないといけない
    • 業務知識も分散
  • PC版パフォーマンス低下
    • 10年運用しているとパフォーマンス低下は避けられない
  • デザインと機能の一貫性
    • PC版とモバイル版でカラースキームやコンポーネントが統一されていない
    • どちらかにあったもう片方にない機能

課題の改善

  • 目指す姿
    • Fastly + マイクロサービスで統一
    • 高いパフォーマンス
    • 生産性の高いチーム
    • 一貫性のあるデザイン機能
  • 統合プロジェクトの第一ゴール
    • トップ画面の統合
  • パフォーマンス
    • できる限りサーバーサイドでレンダリング
    • 新規のコードはTypeScriptで統一
      • 既存部分も徐々に移行
    • handlbarsをやめてpreact(サーバーサイドでしか使ってない)
    • WebComponentsを採用
      • コンテンツの性質上動的なものが少ないのでFWは重厚すぎる
    • ServiceWorkerフルスクラッチから徐々にWorkbox
  • リリースは無事できたが思っていたよりパフォーマンス上がらず
  • パフォーマンスのモニタリング
    • SpeedCurveだけでなくLighthouseCIも導入
    • CIでCircleCIからLighthouseを動かすようにする
      • 手動でやるのではなく自動で常に計測できるようにしたかった
    • 本番環境では引き続きSpeedCurve
  • 投機的なprecacheは外れることもある
    • その失敗は通信量保存料などコストになる
    • CTR(クリック率)に基づくprecache
    • 実際成功率がどうだったかも見て改善していく

AMP + PWAで実現するストレスのないページロード

Webにアクセスするユーザが求めるもの

  • 例えば乗換案内ならどういう経路がいいのかが知りたい
    • 検索がしたいわけでもないしページが表示されるのを待ちたいわけでもない
    • ローディング速度が遅いとユーザは離れていく

パフォーマンスの計測

  • Lighthouseで計測
  • 指標
    • 8種類
    • Largest Contentful Paint
  • ロードのタイミング
    • lazyload
  • 重いライブラリを削る

AMP

  • AMP
    • HTMLフレームワーク
    • AMPが提供するHMTLタグ(WebComponents)がある
    • Reactなどを使ってても部分的に使うこともできる
  • VanillaJS
    • すべて自前で
  • JS Library(Reactなど)
    • データのバインディングなどライブラリがやってくれる
    • その分お作法にのっとらないといけなくなるので自由度が多少減る
  • AMP
    • JSを書かずにタグを書くだけで最適化されたものをつかえる
    • その分JS書けず自由度が下がる
  • AMPにないコンポーネントを使いたくなったらどうする?
    • <amp-script>
    • 自由度はさがるがJSを書くこともできる
  • AMPはローディングを最適化する上での１つの手段として使える

AMPとPWA

  • AMPはPWA対応している
    • <amp-install-serviceworker>
    • 設定周りもいい感じにやってくれる
      • 自分で書くこともできる

AMPとPWAによる最適化

  • AMPを使うと
    • DCL-FCPが速くなる
    • DCLはあまり変わらない
  • AMP + PWA
    • DCLまでが早くなる
    • Cacheを使うことでダウンロード時間短縮

まもなくやってくるVue.js 3

  • 川口 和也さん(PLAID)

Vue

  • 2016/10: v2.0
  • 2020/Q1: v3.0

Vue3.0

  • 変更点たくさんある

Vue3.0の新機能

コンポジションAPI

  • 関数ベースで提供されるAPI群
  • テストがしやすくなる
  • コードの見通しがよくなる

サスペンス

  • 非同期処理を効率的に扱う
  • 並列で複数通信して完了したらコンポーネントを表示するといった場面で効果的

Vue2.0からの変更点

Single File Component

  • スコープ付きCSSの仕様変更
  • Vue独自の拡張擬似クラス
  • >>>や/deep/はしばらく警告出すけど廃止

まとめ

Unlocking new capabilities for PWA

  • 吉井 健文さん(DeNA)

PWA

  • デバイスにアクセスするローレベルなAPIも出てきている

Web NFC

  • NFC Tagに書き込んだりできる
    • 動画や音声なども保存できる
  • 今はAndroidのChromeでflagを有効化すると使える
  • 使うためにはpermissionが必要
    • 端末の設定で無効化されていることもあるので注意
  • Media Recorderで情報を記録する
    • 大きい情報はNFCに記録できないのでindexedDBなどに入れておく
    • NFC Tagの一意なIDがとれるのでそれをキーにするとよい

デモ

vimeo.com

github.com

エンディング講演：PWA on Windows

新しいEdge

  • Edgeの種類
  • 最新のEdge
    • ダウンロード
    • WindowsUpdate
      • 日本では2020/4/1以降
      • Enterpriseなどは自動更新されない
    • 古い方と共存は基本できない
  • レガシーEdgeとの違い
Rendering Engine JS Engine
旧 EdgeHTML Chakra
新 Blink V8

WindowsにおけるPWA

  • 従来
    • UWPでラップしてストアからインストール
  • 今後
    • ブラウザからインストールできる
  • PWAの動き
    • タスクバーへピン留め
    • スタートメニューに追加
    • データ上限なし(キャッシュいくらでも入る
    • ミニマルUIで戻るや検索や印刷ボタン出る
    • 認証情報の継承
    • 通知の受信(開発中)
    • プロセスはタブ単位に見ることができる

MicrosoftによるPWAの取り組み

Microsoft Store

  • Microsoft StoreからPWAを配布できる
    • セルフパブリッシング
      • 開発者アカウント作って申請
    • 自動インデックス
      • BingがクロールしてPWAを検出すると勝手に配信
      • manifest.jsonがちゃんと書かれてるかチェックされる
    • 現状ストアから落としてきて動くPWAはEdgeHTMLなので注意
  • ストアに公開して何が嬉しい？
    • ダウンロードした人の属性などひろえる
    • アプリ内課金
    • プロモーションの機会

PWA builder

www.pwabuilder.com

  • 非PWAアプリに対して設定ファイルなどを生成してくれるサービス
    • PWA化したいページのURLを入力するとマニフェストを生成してくれる
    • アイコン画像もアップロードすることで必要なサイズを生成してくれる
    • 設定ファイルの内容もGUIで指定できる
    • ServiceWorkerのコードも生成できる

「JAMSTACK Meetup #1 with microCMS」に参加してきました

勉強会メモ
  • JAMSTACK Meetup #1 with microCMSに参加してきました。

re-build.connpass.com

タイトル 発表者
Janstack × microCMS実装編 柴田さん(microCMS)
Nuxt.js + microCMS + Netlifyでコーポレートサイトをリニューアルした話 カンボさん(Re:Build)
WordPress（Shifter）をHeadlessCMSにした自社サイトをGridsomeとNetlifyで作ってる話 阿部さん(necco)
Jamstack で開発してすると、今までのつらみ😇がなくなって、ちょっとコストも下がる話 shota_coffeeさん
GitHub Actionsで始めるお手軽Jamstack 西畑一馬さん(トューアール)

Janstack × microCMS実装編

  • 柴田さん(microCMS)

Jamstackとは

  • Webサーバに依存しないサーバーレス
  • 事前にビルドした静的ファイルをCDNで配信
  • APIはJS経由で呼び出す

Jamstackのいいところ

  • 静的ファイルをホスティングするだけでいい
  • APIコールはビルド時のみ
  • 高セキュリティで高パフォーマンス
    • 静的ファイルをCDNで配信するだけだから

microCMSとは

  • 日本製HeadlessCMS

microcms.io

  • 技術構成
    • AWS Amplify
    • サーバーレス
    • React

microCMSのいいところ

  • 開発者と非開発者が使うけど双方に使いやすく
  • GUIでAPIを作成
    • 項目を選択して入力フォームを作る
    • 入力して投稿した内容をAPIで取得できる
  • 権限管理もできる(有料プラン)
    • APIの構成(記事の入力フォーム)の作成までできる権限
    • 記事の投稿だけできる権限
    • 記事の下書きのみできる権限
  • 画像の加工もURLで対応できる
    • サイズとか

Jamstackの実装(Nuxt)

  • 主な静的サイトジェネレーター
Rest API GraphQL
React系 Next.js Gatsby
Vue系 Nuxt Gridsome
  • 動的なコンテンツ
    • ビルド時にAPI叩いてURLを生成
    • ブログ記事一覧をとってきて、みたいな感じ

まとめ

  • Jamstackは速くてセキュアで安い
  • microCMSすごい
  • 実装はちょっとむずい(SPA詳しければできちゃう)

Nuxt.js + microCMS + Netlifyでコーポレートサイトをリニューアルした話

  • カンボさん(Re:Build)

JAMstackの実装

  • コーポレートサイトをJAMstack化
    • レスポンス速度が向上
  • Nuxt + Netlify + microCMS
    • NuxtをNetlifyにデプロイ
    • ビルド時にmicroCMSを叩いてデータを取得
  • GitLabのmasterにプッシュされたら自動でビルドデプロイ
  • microCMS
    • APIのクエリがいろいろあってドキュメントも親切(日本語)
    • APIのレスポンスのプレビューも見られる

WordPress（Shifter）をHeadlessCMSにした自社サイトをGridsomeとNetlifyで作ってる話

  • 阿部さん(necco)

Jamstackのいいところ

  • コンテンツとフロントエンドの開発を分離できる
  • 非エンジニアがどんどんコンテンツを更新できる

構成例

Jamstack で開発してすると、今までのつらみ😇がなくなって、ちょっとコストも下がる話

  • shota_coffeeさん

CMS導入事例

  • JS
    • Nuxt
    • Next
  • API
  • hosting
    • Netlify
    • Firebase
  • 変更可能性のあるものは全てAPIにする
    • 編集者はコンテンツを気軽に変更できる
    • 開発者は何も待たずにサクサク開発できる
  • コミュニケーションコストが大幅に下がった

GitHub Actionsで始めるお手軽Jamstack

  • 西畑一馬さん(トューアール)

Gatsbyのいいところ

  • GatsbyのImage
    • 画像をいろんな形式いろんなサイズにビルドしてくれる
    • LazyLoadしてる間スケルトン出してくれる

Jamstackのデプロイフロー

  • 一連の流れ
    • pushしてコンテナでクローンビルドされてデプロイされる
  • コード管理
  • CI
    • GitHub Actions
    • GitLabCI
    • CircleCI
    • Jenkins
  • ホスティング
    • Netlify
    • now
    • S3
    • FirebaseHosting
    • GitHub Pages
  • プレイヤーが多くてややこしい

「Mercari x Merpay Frontend Tech Talk vol.4」に参加してきました

勉強会メモ
  • Mercari x Merpay Frontend Tech Talk vol.4に参加してきました。

mercari.connpass.com

タイトル 発表者
Pros and Cons of SSR and JAMStack @_sskyu
NoCode で CMS と連携するデザインツールを作っている話 @miyaoka
TypeScriptで型安全に入門したい @atsuco_02
Web Assembly と画像・動画 @Leonardo_engr

Pros and Cons of SSR and JAMStack

  • @_sskyuさん

SSRパフォーマンス

  • キャンペーンページのSSRのパフォーマンスがでない
    • NuxtでSSRしてる
  • Podをスケールして負荷に耐えていた(20Pod)
    • 単純なLPを配信したいだけなのに...
  • 負荷試験してみた
    • コンテンツの量でrpsに差が出た
    • SSRしない範囲を増やすと多少改善できた

nuxt generate(JAMStack)

  • nuxt generate
    • NuxtでhtmlをSSR時ではなくビルド時に生成する
  • 課題
    • nuxt generate時にuseragentがとれない
      • ios/android/web/appのwebviewで画面が違う
      • navigator.userAgentはSSR時はとれない
      • v-showでisAndroidとか使えばSSR時はotherになるけどクライアント側で正しい値取れて画面出せる

JAMStackに移行

  • キャッシュレスキャンペーンでJAMStackに移行
    • 2019/10/1-2020/6/30に出してるキャンペーン
  • 移行手順
    • JAMStack環境作る
      • 旧版と並行稼動
      • 社内のみからアクセス
    • 本番にデプロイ
      • テスト
    • 本番有効化
      • 切り替え
  • staticなファイルなので全てFastlyで配信
    • 以前はk8s上のNodeから配信
  • URL
    • 旧版と同じオリジンにおいた
    • 新版のURLにネームスペース付けた
      • そのままだとassets読み取れないけど相対パスで指定するようにして解決

Pros and Cons

  • SSR
    • サーバを運用してる
    • オンコール体制
    • スケールアウトでコスト増
  • JAMStack
    • 静的なassetを配信するだけなのでオンコール不要
      • ぺらいちなサイトに向いてる
    • 管理画面のようなサイトは不向き
  • パフォーマンスの比較記事

developers.google.com

NoCode で CMS と連携するデザインツールを作っている話

  • @miyaokaさん

Studio

  • GUIでWebページが作れるサービス
  • やってるユーザの操作に応じてstate更新して画面に反映してるだけ
    • 操作してる人からするとGUIだけで画面が作れちゃう
  • 課題
    • 静的なサイトはこれでできる
    • 動的なデータの概念がないので動的なサイトが作れない

動的ページを作る

CMSと連携

  • zero configで使えるようにしたい
    • 独自で作った
  • CMSで作ったコンテンツをデザインに注入できるように

TypeScriptで型安全に入門したい

  • @atsuco_02さん

型安全に入門したい

  • 型安全の良さを理解したい

環境構築めんどくさそう

  • CodeSandboxで環境構築いらず

TypeScriptって何者？

  • TSはJSにコンパイルされるスーパーセット
  • コンパイル前に型チェックが行われる
  • 値に対して型が決まると実行できる操作が明確になる=型安全
    • 型があると操作が限定される=>意図せぬエラーが防げる

JSとTSの方の違い

  • JSにも型ってあるよね
  • JS
    • 実行時に型を判別
    • 自動で型変換される
  • TS
    • 実行前に型を判別

TSの型の良さ

  • 型を明示的なので可能な操作が明確
  • 暗黙的な変換がされない
  • コンパイル時にある程度エラーがわかる

Web Assemblyと画像・動画

  • @Leonardo_engrさん

JavaScriptだけで画像加工

github.com

  • PWAのアプリが増えてきている
    • 画像加工のような処理もクライアント側でやりたい
  • ImageMagickにできることならだいたいできる
  • 画像を比較してdiff出せたりする

JavaScriptだけで動画をエンコード

  • ffmpeg.js
    • あまりメンテされてない

github.com

  • スマホの処理性能上がってきてる
    • リアルタイムで画像にエフェクトとかアプリだとでてきてる
  • WebWorkerと組み合わせて使えるように用意してくれてる

「#webbundle_study」に参加してきました

勉強会メモ

  • webbundle_studyに参加してきました。

web-study.connpass.com

タイトル 発表者
Web Packaging: Web Bundles @horo
WebPackaging Spec @jxck

Web Packaging: Web Bundles

  • @horoさん

Web Packaging

  • Webリソースをひとまとめにする技術
  • W3Cで検討されている仕様
  • その中にWeb Bundles

Web Bundles

  • HTTPリソースをまとめるための仕様
  • .wbn
  • 近くにいる人にwbnをシェアすることもできる
    • アプリで
    • USBで
  • ファイルがローカルにあるので表示がはやい

Web Bundleの作り方

www.npmjs.com

Subresources Web Bundles

  • linkタグでwbnからとってくると指定できるようになる
  • htmlごとbundleするのではなくcssとかjsだけbundleするようなシーン

Page Web Bundle

  • 同一originでなくても同一originのようにロードできる
  • アセットがたくさんあるような場面で使うイメージ

Save as Web bundle

  • ページを右クリックからwbnで保存できるようにする
  • 印刷して保存するような雰囲気
    • cacheにアクセスしたりとかはできない

TWA

  • PWAをPlayストアにAndroidアプリとしてあげられる
  • 動きとしては特定のURLを開く
  • 課題として初回アクセス時オフラインだと表示できない
    • Web Bundleでかいけつできるのではないか

WebPackaging Spec

WebPackaging Spec

  • SXG
  • Web Bundles
  • Loading

Web Bundles Spec

  • どういう風にbundleが動くかしか定義してない
  • arrayをcborというフォーマットでバンドルする
  • index/response/signetureなどどこに入ってるか決まってるから全部パースしなくても欲しい情報をとれる
    • zipとかだとそういうことできないからわざわざwbnを使ってる
  • どのaccept-type来たらどのcontent-type返すかとかハンドリングできる
    • 多言語用意しておいてaccept-languageによってどれ返すか制御したりとかが想定ユースケース
    • 配布することも考えると多言語全て入れておいた方がいいかもとかっていう話も
  • bundleしてる各ファイルに対して署名しないといけない

Serve Web Bundle

  • HTTP
Content-Type: application/webbundle
X-Content-Type-Options: nosniff

「年の瀬に振り返る Figma & React コンポーネントでのサービス開発」に参加してきました

勉強会メモ

spacemarket.connpass.com

タイトル 発表者
Figma・Storybookでのコンポーネント運用から考えるデザインシステムとの付き合い方 伊東 将太
2019年の Atomic Design コンポーネント設計 原口 渉
パネルディスカッション 横井 麻里乃 / 小林 春彦

Figma・Storybookでのコンポーネント運用から考えるデザインシステムとの付き合い方

  • 伊東 将太さん

FigmaでUIコンポーネントを運用

  • どんなコンポーネントがあるか視認性を高めたい
  • 操作感を確かめられるようにしたい
  • AtomicDesign
    • Atomsはデザイナー
    • それ以降は実装しながら
  • デザイナーとフロントエンドエンジニアの協業が楽になった

運用していく中で

デザインシステム

  • デザイン原則
  • ガイドライン
  • カラーパレット
  • アイコン
  • パターンライブラリ

Storybook

  • コードでデザインシステムを可視化できるのがいい
    • より本番に近い状態

まとめ

  • プロダクトの方向性を明確にして開発効率/一貫性を向上したければ取り入れる価値ありそう

2019年の Atomic Design コンポーネント設計

  • 原口 渉さん

マークアップ

コンポーネント推進PJ

共通コンポーネントの反映

  • せっかく用意してあるのに使われていないページがあった
    • 同じコンポーネントｗｐそれぞれで実装しているため修正もれやデザインのばらつきが起きる
  • 共通ライブラリを変更したら利用者も更新されるようにした

コンポーネントの粒度と命名規則の策定

  • 明確に決めてなかったので作業者によってばらついていた
  • 似た見た目でもコンポーネントを分ける
    • 再利用性は副次的なものと考えた
  • OrganismsとMoleculesの基準
    • 単体で意味を成せばOrganisms
  • 命名規則
    • Page名を接頭辞につける

課題管理フローの策定

  • JIRAで可視化

プロダクトとStorybookの状態が異なる

  • 本番だけ反映されてStorybookが更新されていないことがあった
    • storiesのファイルを先に書くようにした？
    • 定期的にチェックするようにした

まとめ

  • デザイナーとエンジニアで共通の認識を持つことができた
  • デザイナーと連携とりやすくなった

パネルディスカッション

  • 横井 麻里乃さん
  • 小林 春彦さん

なぜAtomicDesign

  • photoshopのファイル数が150超
    • 管理しきれなくなった
  • もともとデザイナーとエンジニアで別リポジトリで同じようなもの管理してた

組織的なコンポーネント運用の課題

  • リリース優先でコンポーネントをきれいに運用することは後回しになりがち
    • Atomsだけはきれいに管理すると決めている
  • 同じ設計ルールで誰でも作れるようにする工夫が必要
    • 自動化とか仕組み化をしていきたい

なぜFigma

  • いろいろ変遷してる
    • コミュニケーションがしやすいからFigmaにした
    • Figmaにコメント書くとSlack連携できるように

「【We Are JavaScripters! 3周年記念】 WeJS Festival !」に参加してきました

勉強会メモ
  • 【We Are JavaScripters! 3周年記念】 WeJS Festival !に参加してきました。

wajs.connpass.com

  • WeJSの3周年記念のイベントに参加してきました
  • 自分が初めてWeJSに参加したのも2017年7月に開催された9thなのでもう2年以上前です。勉強会に行き始めたころなので懐かしいものです。
発表枠 タイトル 発表者
初心者LT はじめてのユニバーサルJavaScript @りゅーそう
初心者LT A story about making a cli twitter client with typescript @azawakh
初心者LT styled-components の ` ←について @kimizuy
初心者LT 逆算して考える広告ライブラリ @ta__ho
初心者LT Node.js/serverlessでおこなうDX改善 @Ayami Otani
通常LT おさらいVue Composition API Morita_Masatoshi
通常LT Lighthouse CI入門 @yinm
通常LT Reactの歴史 @mqtsuo02
通常LT 執筆の進捗を支える技術〜Could RunでBot作ったらとても便利だった件〜 @kyasbal
通常LT angular歴3ヶ月がAngularと本気で向き合ってみた @EmiYaegashi
Demo LT PlayCanvasでできたこととデモ @sushucorn
Demo LT TensorFlow.jsとobnizで作る笑顔あふれる職場 @boiyama
Demo LT Ma_gician ＜Vue にはできないこと(2)＞ @StewEucen
Demo LT 今日から始めるWeb USB @takanorip
Demo LT Joy-ConをJavaScriptでプレゼンリモコンにした話 @mascii_k
Short Session Introduction to ReasonML @Naturalclar
Short Session JSXでつくる宣言的プレゼンテーション @mottox2
Short Session JSでの時間の使い方の話 @chikoski
Long Session Behind the scene @brn227
Long Session Babel plugin を作って AST と Babel を学ぶ(ライブコーディング) @mki_skt

Introduction to ReasonML

  • @Naturalclarさん

Reason

  • State of JS 2018
    • 半分は聞いたこと無い
    • 使ってる人の満足度は高い
  • Reactの作者Jordan Walkeが作っている
  • Ocamkを別のSyntaxで書いたもの
  • 強力な型
  • BuckleScript
    • JSにトランスパイルする
  • 特徴
    • JSのように書ける
    • React書ける人は馴染みやすい
  • 利点
    • ビルドが高速
      • 規模が大きくなっても数秒
    • バンドルサイズが小さい
      • 結果が自明なものはトランスパイル時に変換してくれる
    • Prettier完備
      • もともとはReasonのフォーマッターが優秀でそれをJSでも使えるように作ったのがPrettier
    • 型安全性
    • エラーメッセージがわかりやすい
  • gentype
    • tsxを生成したりできるライブラリ
    • 徐々に移行したいときはこれを使うといい
  • reason-react-native
  • reason-native

JSXでつくる宣言的プレゼンテーション

  • @mottox2さん

KOBIT

  • GoogleAnaryticsと連携するとPowerPointのレポートができるサービス
  • PowerPointはzipされたxmlの集合体
  • レポートなのでmarkdown to pptxでは表現できない

課題

  • コードから生成後の見た目が想像しづらい
    • JSXで宣言的に書く
  • 座標計算が大変
  • JSXからSketchを生成するReact Sketch.appを参考に

仕組み

  • react-test-renderer
    • JSXをObject化できる

github.com

JSでの時間の使い方の話

  • @chikoskiさん

JavaScriptの実行タイミング

  • どんな順番で呼ばれるの？
    • addEventListener
    • requestAnimationFrame
    • requestIdleCallback

EventQueue

  • タスクはキューにたまっていく
  • キューの中の処理でスタックがたまっていく
  • いろんな処理が全て同じキューに溜まっていく(メインスレッド)
  • Chromeのdevtoolsのperformanceでタスクキューを見れる

実行の順序

  • Dont yield
    • 普通のJSの処理
  • Microtask
    • awaitとか
  • requestAnimationFrame
  • Inter-frame
  • requestIdleCallback
    • CPUが暇な時に動く

Worker

  • 全部メインスレッドでやるのをやめようという話もある
  • UIスレッドをわける
  • Worker
    • EventQueueをもう1つ作る
    • 並列に実行される
    • コンストラクタの第2引数に{type: module}でESModulesも使えるようになる
    • postMessageはJSオブジェクトなら渡せる
      • コピーして渡される
        • 処理時間は無視できる程度
  • Comlink
    • postMessageを抽象化してくれる
  • SchedulingAPI
  • 無限ループを書きたい時
    • priorityを設定できるようになる仕組みも考えられている
    • それを使えばブロックしないようにできる

Behind the scene

  • @brn227さん

Scriptのクリティカルパス

  • HTMLをparse
  • リソースをfetch
  • V8が実行

Resource Fetch

Scriptタグの種類

  • ClassicScript
    • 普通のscriptタグ
  • ModuleScript
    • ESModleに対応したscriptタグ
    • import/exportを解決できる
  • Async
    • scriptタグの順番待ちが発生しないロードも実行も非同期
  • Defer
    • ロードは非同期だけど実行は順番を待つ

Connection

  • HTTP1.1だと同時接続数の上限がある
    • 大抵のブラウザは6まで
    • なので非同期で同時にたくさん取りに行っても上限を超えると待たされる
  • HTTP2だと1つのコネクションで複数のやりとりできるので解決される

Fetching

  • ブラウザキャッシュがあるかチェック
    • ETag
      • リソースに対して一意に発行されるハッシュ
      • Cache-ControlとETagを組み合わせてキャッシュを使うか決める
    • ServiceWorker
      • リクエストをインタラプトできる
      • ChacheStorageに入れておいてそれを返すことができる

最適化

  • Preload
    • link rel=preload
      • 事前にリソースをリロードさせておける
  • Compress response
    • gzipではなくBrotliを使うと更に圧縮率高められる
  • CDN
    • 地理的に近いところから取得
  • webpackプラグイン
    • Workbox
    • sw-precache
  • Code Splitting
    • 必要なものだけを取得できるように

Futuer

  • HTTP/3 Quic
    • Transport層を置き換える
  • Priority-hints
    • linkやscriptにimportance属性が追加される
    • highがついてれば優先的に取得する等
  • WebBundle/WebPackaging
    • Webのコンテンツを1つにパッケージングして配信
      • 画像でも動画でも全部
      • request/responseとか証明書とかも
      • Webサイトまるごとpackagingして配信して使える

Parsing

  • fetchしたscriptをASTに変換するフェーズ
  • parse処理は重い
    • ページする度に全部parseしてるとおもすぎる
    • 最初は関数と行数だけparseしておく
    • 呼び出されると関数の中身までparse
  • parseも全部メインスレッドで動いている
    • parseが始まった段階でHTMLの表示がとまる
    • deferとかasyncをつけると変わる

Streaming

  • Streamingで逐次取得しながらparseする

bundle size

  • 50-100KB目安に分割するとよい
    • モバイルとかも考えると
    • CPU/メモリ使用量がかかる

Transpile

  • 古いブラウザようのコードは新しいブラウザにとっては無駄なコード
  • ブラウザに応じて調整すると無駄なものを減らせる

JSON.parse

  • objectにこれをつけておくと遅延してparseされるのではやくなる

Polyfill

  • CoreJS全部入れちゃったりすると無駄が多すぎる
  • polyfill.ioを使って必要なものだけにするといい

Futuer

  • Binary AST
  • ASTで直接配信する
    • ブラウザごとに共通仕様ができればいける

Babel plugin を作って AST と Babel を学ぶ(ライブコーディング)

  • @mki_sktさん

AST

  • Abstract Syntax Tree
  • プログラムの構造を示したデータ
  • JSではJSON
  • 仕様はESTreeに準拠
  • AST Explorerを使うとJSのコードがどう変換されるか見られる

astexplorer.net

Babel

  • JSのコンパイラー
  • もともとは6to5だった
    • ES6 to ES5
  • そこからいろんな機能が追加されていった
  • 新しい構文で書いたJSを古いブラウザでも動かしたい時に使う

構文変換

  • TS/JSX/JSなど -> Babel -> JS
  • 変換のフェーズ
    • Parsing
    • Transformation
    • Code Generate
Parsing
  • @babel/parser
  • コードをparse関数に通すとJSONで出力される
  • acorn
    • 軽量なJS parser
    • webpackで使われてる
Code Generate
  • @babel/generate
  • ASTをJSに変換する
Transformation
  • @babel/traverse
  • constとletをvarに変えるといった変換を行う

ライブコーディング

github.com

「JSConf JP(Day2)」に参加してきました

勉強会メモ
  • JSConf JPに参加してきました。
  • 2日目の参加メモです

jsconf.jp

タイムテーブル

時間 タイトル 発表者
11:00- 時間はただの幻想である… JavaScriptにおいては Jennifer Wong
InversifyJSを用いたレイヤードアーキテクチャの構築 奥野 賢太郎
Vue.js で D3.js を使ったインタラクティブなデータの可視化 Shirley Wu
11:30- ストリームの人生 Dominic Tarr
Build and scale multiple Voice application by using TypeScript Hidetaka Okamoto
13:00- Web の体積 Jxck
正攻法はあるのか !? 泥臭く戦った Node.js バージョンアップ一部始終 Masato Nishihara
パスワードは90年代の代物だ Sam Bellen
13:30- JavaScript, Rust and Wasm Walk into a Ramen Shop ... Irina Shestak
Migration from React Native to PWA ohbarye
npm i -g @next-and-beyond: Building the future of package management Claudia Hernández
14:15- JSConf Panel Talks Jan Lehnardt and Yosuke Furukawa
GraphQLを用いたECサイトにおけるパフォーマンス改善 澤井宣彦
Minimum Hands-on Node.js 栗山 太希
14:45- 悪用された npm パッケージの分析 Jarrod Overson
JavaScriptのままでTypeScriptを始める 高梨ギンペイ
15:30- Browser APIs: 知られざるヒーロー達 Rowdy Rabouw
Your benchmark may not guide a real application performance Tetsuharu OHZEKI
16:00- Anatomy of a Click Benjamin Gruenbaum
JavaScriptとSwift/JavaをつなげるCapacitorと、これからのWeb Frontned. 榊原昌彦
Recruit Speed Hackathon 新井 智士
16:45- AIとJavaScript による生物認識 Jonny Kalambay
大規模アプリケーション開発でのElm実践 海老原 圭吾
17:15- Pika: レジストリの再創造 Fred K. Schott
最新のWeb技術でIoT開発をする 木戸 康平

InversifyJSを用いたレイヤードアーキテクチャの構築

  • 奥野 賢太郎さん

密結合とは

  • 修正を加えた時にその影響箇所が見つけづらい状態
    • 予期しないところに影響が及ぶかもしれない状態
    • DBの構造
    • 外部サービス
    • APIの構造
    • 画面の構造
  • 例
    • 画面の入力フォームの構造のままテーブル設計してしまった
    • 画面の構成変えたけどDBいじる余裕ないから無理やり対応することに・・・
  • 抽象化する中間の層が必要

レイヤードアーキテクチャ

  • DDD
    • Domain Driven Design
  • MDD
    • Model Driven Development
  • Repository

DIP

  • InversifyJS
    • DIの機能を提供するライブラリ
    • constructor injectionできる
    • TypeScriptで書いた方が相性が良い
  • TSyringe
    • Microsoft製
    • InversifyJSと同じ感じのやつ
    • 好みではあるけど登壇者はこっちの方が好き
  • レイヤーごとにmodel objectを用意する
    • バグが起きたときの影響範囲がわかりやすいように寿命を短くするとよい
  • value objectを作るようにする
    • バリデーションはconstructorで
  • knex
    • ORMapper

Build and scale multiple Voice application by using TypeScript

  • Hidetaka Okamotoさん

スマートスピーカーのバックエンド

  • 音声/言語処理系の知識がなくても開発できる
    • Speach To Textや自然言語処理はサービス側の責務
    • バックエンドには処理後のJSONが送られる
  • Webhookの開発と同じような感じ
    • SlackやLINEのbotに近い
  • 文脈を覚えておくためにDBも持っておくことが多い

Alexa開発

  • ask-adkを使う
  • スキルが増えると起こる課題
    • スキルが増えるとLambdaも増えるからruntimeの更新など面倒
    • 同じような処理がいろんなスキルに存在してしまう
  • 多機能な1スキルか単機能な複数スキルか
    • 単機能なスキルの方が使いやすい
    • でも見つけてもらうのが大変かも
  • ServerlessFrameworkを使うと便利
    • 全部yamlで管理できる
    • runtimeのアップデートなども設定かえるだけ

まとめ

  • VUIはWebhookライク
  • in/outのフォーマットが一定のためTS相性良し
  • 汎用FWがまだない

正攻法はあるのか !? 泥臭く戦った Node.js バージョンアップ一部始終

  • Masato Nishiharaさん

背景

  • Node6を使ってたが2019/4にEOL
  • Node8は2019/10にEOLだったので一気に10に
    • 10のEOLは2021/4

やったこと

  • Node変更差分確認
  • 依存パッケージの変更差分確認
  • 全機能テストを複数回

パッケージの差分

  • 依存ライブラリのリリースノート全部見たりするのは現実的でない
  • Node10に対応しているか明記していないものもあった
  • =>全機能テストで動けばよいとすることに

全機能テスト

  • ブラウザバリエーションもあるので大変
  • 1回目で不具合を出して対応して2,3回目もやった

リリース後

  • CPU100%にはりつくトラブル
  • スレッドの切り替えをする処理が多発していた
    • Nodeはシングルスレッドじゃないのか？
    • 内部的にはマルチスレッドで動くところもある
    • libvuの中でマルチスレッドを利用している
  • このケースでは原因はDBサーバだった
    • 障害のあったサーバからDBサーバへのアクセスが遅延していた

まとめ

  • こまめに上げるようにするとよさそう
  • コアな部分だけでも自動テストはあった方がいい

Migration from React Native to PWA

  • ohbaryeさん

React NativeからPWAへ

  • iOS/Andorid対応のRNアプリをiOS/Android/Web対応のPWAにする
    • 後者のiOS/AndroidはWebViewでPWAを表示する

なぜReactNativeだったか

  • プッシュ通知など使いたいからスマホアプリがいい
  • iOSエンジニアがいなかった

BYOD化

  • 端末を用意してインストールして渡してた
    • 端末配布をやめてBYOD化することにした
    • Android版の提供も始めることにした

マルチプラットフォーム対応

  • iOSで動くのにAndroidで動かないとかがかなりあった
  • JSのエラーなのかライブラリの中身が悪いのかネイティブのレイヤーが悪いのか

パッケージ管理

  • ReactNativeはnpmでライブラリ管理してるがその先にiOS/Androidのライブラリがある

ビルドデプロイシステム

脱ReactNativeの選択肢

  • PWA
  • Nativeで書き直す？
  • Flutter
  • => ブラウザで見たいという要件もあったのでPWAで
    • React使った

通知

  • Push Notificationの実現
    • AndroidはWebでも使える
    • iOSはWebViewとして使うのでネイティブの機能を使う

WebViewで苦労したこと

  • キャッシュのレイヤーが増えることに注意
  • WebViewのキャッシュを無効化するメソッド用意したりとか

PWAで供料したこと

  • Android ChromeだとアイコンにつけるバッヂはまだExperimental
  • フォアグラウンドでの通知がAndroid PWAだけ挙動が違った

テスト

  • cypressでintegrationテスト書いてる
  • ReactNative時代はスナップショットテストとかやってた

運用してみて

  • Webなので即時反映されるのでいい

まとめ

  • チームメンバーのスキルセットにあった技術選定が大事
    • 開発できる = 運用できるではない
  • モバイルアプリに近い体験要求されてもWebでもできるかも

GraphQLを用いたサイトにおけるパフォーマンス改善(ECサイトを題材に)

  • 澤井宣彦さん

背景

  • 歴史が長くページ遷移が遅い
  • 全社のリブランディング
  • ページ遷移の改善
  • 技術スタックの改善

リニューアル

  • フロントはReactをTSで
  • Backendは既存RailsをAPI化
  • API定義はGraphQL
    • トップページをリッチにしたい構想
    • フロント側に自由度をもたせたいから

パフォーマンス改善

計測

  • 実機で行うテスト
  • 合成環境で行うテスト
    • PageSpeed Insighrsを使った

ボトルネックの特定

  • ChromeのAudit
  • Opportunitiesの改善項目

改善

フロント側の改善
サーバ側の改善
  • APMを活用
    • 既に入れていたDataDogを活用
  • N+1のDBアクセス問題
    • batch-loader(rubyの場合)などを使って対応するようにする
QueryとSchemaの改善
  • ページングのない配列のrequest
    • 関連するレコードが全件取得されるので性能が劣化
    • ページングをつけて件数指定する
    • schemaのlinterで未然に防げそう
  • 全く使ってないデータを取得している
    • queryを消せばよい
    • なぜ画面に紐付いてないqueryが書かれてしまうか
    • FragmentとColocation
    • Fragment
      • queryを部分的に切り出したもの
      • 再利用できる
      • 部分定義できる
    • Colocation
      • Fragmentを集約して1つのqueryにまとめる
    • Reactコンポーネントの階層とqueryの階層をあわせるようにする

今後

  • Cacheの活用を検討
    • リアルタイム性が低いコンテンツもある
    • ゲストユーザは同じものが基本的に表示される
    • CDNのレイヤーでHTML/responseどちらもできるはず

JavaScriptのままでTypeScriptを始める

  • 高梨ギンペイさん

TypeScriptのいいところ

  • JSのスーパーセットであること
  • 型を持つこと

Typed-JavaScript

型がつくと何ができるようになるか

  • バリデーションできる
    • 関数を呼ぶ時にどんな引数を渡さないといけないか？
      • ドキュメント見る？
      • 動かしてみる？
      • 型があればすぐに分かる
      • エディタが対応してればその場でわかる
  • エディタの補完がきく
    • 自分で作ったAPIの補完も型を用意しておけば補完される
    • 標準関数なんかもググらなくてもその場で候補がでる
  • リファクタリングがしやすい
    • 変数名後から変えたり型を後から変えたり
    • 変更漏れがあればコンパイルエラーになってくれる

使い方

  • tsconfig.json
    • allowJsをtrueで.js対象になる
    • checkJSをtrueでjsもチェック対象になる
    • noEmitをtrueで型チェックだけするようになる
    • checkJSをfalseにしてチェックしたいファイルにコメントで@ts-checkつけるでもいける

まとめ

Your benchmark may not guide a real application performance

  • Tetsuharu OHZEKIさん

ソフトウェアのパフォーマンス

  • 遅いソフトウェアより速いソフトウェアの方がよい
  • どのように速くするか
    • Dont't guess, measure
  • ベンチマークを使う

ベンチマーク

  • シナリオに沿ったベンチマークになってますか？
  • 一般的な指標はベンチマークの1つでしかない
    • Lighthouseだけやってればいいわけではないケースも多い

JSの最適化

  • 一度の実行だと数ミリsecで差がわかりづらい
    • じゃあ数万回実行しよう
    • =>それでいいの？
      • 何度も実行されるとJSVMが複数レベルで最適化してくれる
      • その処理は何度も呼ばれるような処理なのか？

どのように改善を進めるか

  • プログラムを速くするには遅くなるようなことをやらないことが重要
  • CIとしてベンチマークを計測して継続してプロットするといい
    • 容易に起動できて再現可能であるようにする
    • 細かい上下は必ず起きる
    • 長期での傾向をチェックする

まとめ

  • パフォーマンスを改善するにはリアルなシナリオが必要
  • 闇雲に測定するのではなくリアルなシナリオに基づくこと
  • ベンチマークテストをテストケースの1つとして追加し実行できるようにすること
  • まずはどのように使われていてどのように速くなると嬉しいのか調べるところから

JavaScriptとSwift/JavaをつなげるCapacitorと、これからのWeb Frontned.

  • 榊原昌彦さん

Capacitor

  • Webでアプリを作ってWebViewで表示できる
  • ネイティブの機能にアクセスできる
  • デスクトップアプリとしても作れる

Capacitorの使い勝ったあ

  • @capacitor/core
  • @capacitor/cli

iOS

  • SwiftをどうやってHTML/JSにつなげるのか
    • npx cap init
    • WebViewを100%表示されるものができる
    • Poddileでnode_modulesの中から引っ張ってきてる
  • HTML/JSがどうやってSwiftにアクセスしているか
    • ブリッジがwindowオブジェクトに値を埋め込んでる
  • Androidもだいたい同じ

UI

  • iOS/Androidそれぞれガイドに沿った見た目にできる

「JSConf JP(Day1)」に参加してきました

勉強会メモ
  • JSConf JPに参加してきました。
  • 1日目の参加メモです

jsconf.jp

タイムテーブル

時間 タイトル 発表者
13:00- Opening talk yosuke furukawa
13:30- The State of JavaScript Raphaël Benitte and Sacha Greif
14:15- 「繋がり」の可視化 Nadieh Bremer
WebAuthnで実現する安全・快適なログイン Eiji Kitamura / えーじ
JavaScript AST プログラミング: 入門とその1歩先へ Takuto Wada
14:45- 「オープンソース」の定義 Henry Zhu
覚醒するアクセシビリティ Lena Morita
4年分のプロシージャルなJS Andy Hall
15:30- Building and Deploying for the Modern Web with JAMstack Guillermo Rauch
Wrap-up: High Performance JavaScript Sho Miyamoto
JS開発者のためのSEOテクニック Martin Splitt
16:00- Write What Not How Jorge Bucaran
How to Boost Your Code with WebAssembly FUJI Goro / @gfx
Playing Pokémon Together with Node.js Samuel Agnew
16:45- Deno - JavaScript の新たな道筋 Kitson Kelly
Streams APIをちゃんと理解する 加藤 健志
You might also like... Maria Clara
17:15- Headers for Hackers Andrew Betts
Make it Declarative with React Toru Kobayashi
Web Accessibilityのすゝめ Nazanin Delam
18:45- 予測的 Prefetching によるパフォーマンス改善 Praveen Yedidi
18:55- Web Components era phase 2 Yoshiki Shibukawa
19:05- Cache Me If You Can Maxi Ferreira
19:15- Node.js でつくる Node.js - WASM/WASI ミニミニコンパイラー がねこまさし
19:25- React アプリのライセンス違反について dynamis

The State of JavaScript

  • Raphaël Benitte
  • Sacha Greif

JavaScriptの歴史

stateofjs.com

stateofcss.com

ES2019

  • Array.flat()
  • Object.formEntries()
  • Optional Catch Binding

フレームワーク

  • React
    • 使ってる人多いしそのほとんどがまた使いたいと言ってる
  • Vue
    • Reactよりは少ないけどのびてる
  • Svelte
    • 使ってる人は少ないけど学んでみたいという人は多い
  • Gatsby
    • 横ばい
  • Next.js
    • のびてる
  • ホスティングサービスも充実してきている
    • Netlify
    • Now
  • TypeScriptは60%くらいの人が使っている

WebAuthnで実現する安全・快適なログイン

  • Eiji Kitamuraさん

パスワードの問題点

  • Weak
  • Forgotten
  • Reused
  • Stolen

パスワードどうやって盗まれるか

ハックされる確率

  • キーロガーだと通常の40倍
  • フィッシングだと500倍
    • パスワード以外の情報もとられているケースが多いから
  • 被害の80%がフィッシング

パスワードが盗まれないようにする対策

  • 2段階認証
  • ワンタイムパスワード
    • SMS
    • フィッシングには弱い
    • 短時間有効なパスワードでもその場で送られたら意味がない
  • そこでWebAuthn

WebAuthn

  • これまでよりも強力なブラウザの認証
    • EdgeもFFも対応
    • Safariは部分的（でも時期に対応するだろう）
  • ハードウェアの鍵を使う(Authenticator)
  • 公開鍵暗号を活用した方式
  • Authenticatorにキーペアを作らせる
    • 公開鍵をサービスに送ってRegistrationする
  • 秘密鍵で署名をしてそれをサービスに送る
    • サービスは公開鍵で検証
    • 同じハードウェアを持っている人であると証明できる
  • 鍵はWebサイトのオリジンと紐付いて生成される
    • フィッシングに強い
    • たとえ盗んでも成功しない

二要素認証

  • ハードウェアをもっているという認証 + 記憶による認証
    • 多要素と多段階は違う
    • 記憶、所持、生体といった要素を複数組み合わせるのが多要素認証
  • セキュリティキー
    • PCに接続するとブラウザにポップアップ出る
    • ジェスチャーをすると署名を生成して送ってくれる
    • 名前をつけて登録する
      • キーをなくしてしまったら消せるように
    • SMS Codeも強いけどセキュリティキーの方が強固
  • 署名をサーバに送って登録されているものと同一であることを確認する
    • このサーバをFIDOサーバと呼ぶ

Authenticator

Roaming Authenticator

  • Authenticatorの1つにセキュリティキーがある
    • U2FかFIDO2に対応しているAuthenticatorであれば間違いない
  • R持ち運びできるからoaming Authenticatorと呼ばれる

Platform Authenticator

  • デバイスに埋まってるから専用のものを買わせる必要がない
  • 指紋認証などで使うことも多いけど端末のロックNoなども同等の扱い
  • Local User Verification(LUV)
    • ローカルで生体と所持の二要素認証する
    • スマホで生体認証とかするとこれが実現できる
    • 生体情報はデバイスにしかないから安心(だからLocal User Verification)
      • つまり新しいデバイスに替えたら再登録が必要

再認証(Re-authentication)

  • お金を払う手前とかで再度認証させるやつとか
    • ログインしてる状態でもう一度認証を求めるやつ
  • Pixel4の顔認証はまだ使えないけどChrome79から使える

参考

  • https:/goo.gle/FIDO
  • WebAuthnのコードラボもある

覚醒するアクセシビリティ

アクセシビリティ

  • 蔑ろにされることが多い
    • 不便と思う人を低く見積もりすぎ
    • 誰でも使えるようになることのよさを知らない
  • 障害者/健常者という区別がよくない
    • 環境や状況によって不便に感じることは誰でも起こりうる

Webにおけるアクセシビリティ

  • Webは世界中どこからでもアクセスできる
    • ブラウザの拡張などでカスタマイズできる

広義のアクセシビリティ

Wrap-up: High Performance JavaScript

  • Sho Miyamotoさん

intro

Layers

  • JavaScriptのレイヤー
    • Product
    • Runtime
      • Node
      • ブラウザ
      • Electron
    • Engine
  • JavaScriptの実装
    • サーバサイド
    • クライアントサイド

RuntimeとEngine

  • RuntimeとEngineどう違うか
    • Engine
      • parser/compile/execute
      • JIT/VM
    • Runtime
      • Engineが埋め込まれている
      • プラットフォームそれぞれのGlobalObjectを持っている
      • EventLoopをオーバーライドしてる

Optimization

  • 最適化
    • Product-level
      • memo化
      • キャッシュ
    • Runtime-level
      • 非同期
    • Engine-level
      • インラインキャッシュ
  • 効果
    • Product > Runtime > Engine
  • Micro Optimizationをするな
    • 自分でやらなくてもエンジンがやってくれる

Optimization

Server Side runtime

  • Node.js
  • イベントループ
    • 処理に時間のかかる動機処理があるとループをとめてしまう
    • 非同期でできるものはそうした方がよい
  • StreamAPI
    • Fileの読み出しとかを効率的に行える
    • Streamでないと情報を全てメモリにおいてそれを扱ってとなってしまって効率悪い

Client Side Runtime

  • ブラウザでJSが動くまで
    • fetch -> load -> parse -> compile -> execute
  • できるだけCodeCachingを使う
    • 次使う時にcompile済みになってるようにする
    • 頻繁に使われるものはServiceWorkerでcacheするといい
  • ESModules
    • ブラウザ上でimport/export
    • Preloading scripts
      • 実行はしないけどparseとcompileをしておいてくれる
  • idling
    • Idle Until Urgent
    • requestIdleCallbackを使うとCPUとかが暇な時に実行してくれる

Engine

  • V8
    • たくさん使われた処理ははやくとれるようにとか最適化してくれる
  • Inline Cache
    • Objectにどんな情報があるかを予め用意しておく？
    • ヒットしたらはやい

How to Boost Your Code with WebAssembly

  • FUJI Goroさん

WebAssemblyとは

  • ブラウザに搭載するバイトコードとその処理系仕様
  • JVMに近いけどランタイムはない

WebAssembly前夜

  • EmscriptenによってC/C++をJSにコンパイルすることができていた(2012)
    • ただし動作が非常に遅い
  • WebAssemblyに仕様議論開始(2015)
  • ブラウザにMVPレベルのサポート完了(2017)

WebAssemblyの価値

  • ブラウザにおいてはJSとできることは同じ
  • JSよりも速い
    • それが圧倒的価値
    • JSだと遅くて現実的でないことが可能になる
  • Cよりは数倍遅い
    • 安全性のために未定義動作(UB)をなくしてるから
    • この安全性が大きな利点

WebAssemblyのサポート状況

  • IE11以外は使える
    • 9割くらいのシェアのブラウザで使える

WebAssemblyの事例

  • eBayの事例
    • バーコードスキャナ

tech.ebayinc.com

言語ごとの速度イメージ

  • 1倍: C, C++, Rust
  • 3倍: Java, C#, Go, Swift
  • 5倍: JS(V8), Dart
  • 50倍: Ruby, Python, Perl, PHP
  • WebAssembly
    • WasmをV8で動かすと5倍の中では速い方

Streams APIをちゃんと理解する

  • 加藤 健志さん

StreamAPI

  • Readable Stream
  • Transform Stream
  • Writable Stream

Readable Stream

  • 読み込み可能なストリーム
  • データを分割して少しずつ読み込むことができる
  • fetchAPIのレスポンスのbodyは実はReadableStream

Writable Stream

  • 書込み可能なストリーム
  • pipeTo()を使うとReadableStreemのデータをそのままWritableStremに書き込める
  • 書き込み時にPromiseを返すと解決するまで待つので順序を保証できる
  • 分割されたデータを1つずつ順番に書き込むことができる

Transform Stream

  • 変換ストリーム
  • WritableStreamに書き込まれたデータをTransformStreamで変換してReadableStreamで読み込む
  • ReadableStreamからpipeThrough()でTransfirmStreamに渡してpipeTo()でWritableStreamに書き込める

バックプレッシャー

  • キューに空きがなくなったら通知して止めてもらう
  • Underlying Source
    • Push Source
      • 自発的にenqueueする
    • Pull Source
      • リクエストに応じてenqueueする
  • QueuingStrategy
    • highWaterMark
      • キャパシティを設定する
    • size(chunk)
      • 何をもってキューのサイズを決めるか

Streamsの今後

  • 5Gが来る
    • これまでボトルネックとされていたことが改善される

    • 大容量のファイルを配信できるようになる github.com

      - クライアントがボトルネックになる
    - Streamが役立つ！

Live Demo

「Mercari x Merpay Frontend Tech Talk vol.3」に参加してきました

勉強会メモ
  • Mercari x Merpay Frontend Tech Talk vol.3に参加してきました。

mercari.connpass.com

タイトル 発表者
Creating Serverless CMS from Scratch @sottar_
Vue.jsでのCSS設計 @tacamy
The Challenge of Web re-architecture using GraphQL and Apollo @lightnet328
Practical tips for making a global EC site @yayoc_

Creating Serverless CMS from Scratch

  • @sottar_さん

キャンペーンのページを作るまで

  • 従来のフロー
    • PMからどんなターゲットでどんあんことをしたいか伝えられる
    • デザイナーがコードを書く
    • フロントエンドエンジニアがレビューする
    • PMに返して問題なければリリース
  • 課題
    • デザイナーがコード角の大変(pug/css)
    • フロントエンドエンジニアがレビューするの大変
    • 一文字とか一部分変えるだけでもGitHubでフロー回さないといけない
  • キャンペーンページ作るのに時間かかる
    • 一ヶ月に1,2本くらいしか作れない

CMSを作った

  • コンポーネントを作ってCMS上で組み合わせるようなものがほしい
  • 必要なページ
    • キャンペーンの一覧ページ(過去に作ったものとか)
    • 編集ページ
  • なんでOSSを使わなかったか
  • 考えないといけないこと
    • 権限周り
    • セキュリティ
    • 履歴管理
    • プレビュー
    • => いろいろあるけどまずはMVPを作ってさわってもらう

アーキテクチャ

  • S3にCMSページの静的ファイルを配置
  • Cloud Storageにキャンペーンページを置いておいてそれをdynamic importして表示
  • GCPとAWS混ざってる
    • 基本はGCPを使ってる
    • 社内版GitHubPages的なものをS3で作ってる
  • 認証はAuth0

Vue.jsでのCSS設計

  • @tacamyさん

コンポーネント

  • 機能が自己完結する
  • 再利用できる
  • Vueではscopedをつけると擬似的にスコープをもたせることができる
    • ShadowDOMとは違う

Scoped CSSの留意点

コンポーネントの命名規則

ディレクトリ構成

  • assetsの中にscssに変数とかmixin
    • 実態はcomponentsの中
  • 階層が深くなりすぎないようにした方がよさそう
  • 細かすぎる分割はパフォーマンスにも影響
  • 最初はシンプルに作って規模に応じて変更していくと良さそう

The Challenge of Web re-architecture using GraphQL and Apollo

  • @lightnet328さん

メルカリWebにリアーキテクチャ

  • 新しい技術で作り直してる
    • TS
    • Next
    • React
    • Apollo
    • GraphQL
  • ページごとに部分的に公開している

GraphQLとApollo

  • なぜGraphQL
    • スキーマはドキュメントより実装と乖離するリスクが小さい
    • クエリの可読性高い
  • なぜApollo Clients
    • リモートデータの取得管理を任せたい
    • キャッシュによってリクエストが減る
  • なぜApollo Server
    • BFFとしての役割
      • スキーマをフロントエンドのために整理
      • ロギング
      • 認証
      • 将来的にgRPCでマイクロサービスに接続
      • クライアントが1つのエンドポイントだけ知ってればよい

Practical tips for making a global EC site

  • @yayoc_さん

UNIQLO Global EC

  • 特徴
    • 22カ国
    • O2Oもサポート
    • 機能が国によって異なる
  • これまで
    • 国ごとに異なるアプリ
    • クライアントヘビー
  • これらを解決させるプロジェクト
    • 1つのコードで複数の国対応
    • パフォーマンスはやく
    • a11y
    • コンシューマだけでなく管理画面のUXも改善
  • ページによってSSR
  • 国別にリダイレクトリライト

グローバルサイト構築

URL構造

  • /:country/:language
  • countryなかったらCDNの国
  • languageなかったらAccespt-Languageの言語

SEO

  • GoogleBot以外も考慮
  • JSレンダリングしてくれなかったのでHTML返した方が無難(SSR)

CMS

パフォーマンス

  • 毎日WebPAgeTest/Lighthouseを国別で実行
  • Performance Budget
    • total 200kb
    • chunk 80kb
  • webpack-bundle-analyzer
    • バンドルファイル内の内訳を可視化

ローカライゼーション

  • i18n- webpack-plugin
  • エントリーポイントを分けている
  • ルーティングベースでコードスプリッティングしてるから余計なのは入らない
  • 一部プレースホルダーで出し分け
    • 単数系/複数形とか
  • 決済フローなんかは国によって異なったりするのでコンポーネント出し分けてる
  • minificationで不要なものは削除される

a11y

  • ビジネスサイドからの要件も強い
  • Lighthouseでスコアとるだけでなくそれ以外の項目もチェック
    • 画像説明
    • CSSなしで動くか

画像

  • 一般的に画像が大きいほどコンバージョンは高い
  • CDNでWebPに変換してサイズ圧縮
  • プレースホルダーおいてリフロー防ぐ
  • 遅延ロード

BFF

  • マイクロサービスへのAPIリクエストを束ねる
    • クライアントヘビーな実装軽減
    • クライアントが扱いやすいような構造に整形
  • キャッシュ
    • max-ageを見て設定
  • ロギング
  • HMAC認証をサポート

「PWA Night vol.10 ～PWA × 技術～」に参加してきました

勉強会メモ
  • PWA Night vol.10 ～PWA × 技術～に参加してきました。

pwanight.connpass.com

タイトル 発表者
とある個人開発PWAのSEO奮戦記 大岡由佳さん
PWA×クラウドゲーミング おりばーさん
コードサイズの大きなプログラムのロード時間：WebAssemblyの場合 @chikoskiさん
うわさのJAMStackでPWAをさわってみた のまどまんさん
Monaca × PWA × 3D VMT-Yamashitaさん

とある個人開発PWAのSEO奮戦記

  • 大岡由佳さん(@oukayuka)

Mangarel

  • 個人でPWAなアプリを作った
  • Googleで検索しても3件しかひっかからない
    • 1万ページ以上存在してるのに
    • 最近のクローラーはJS解釈してくれるんじゃなかったのか・・
  • Problem
    • ページがインデックスされない
    • タイトルや詳細が個別に表示されない
    • コンテンツがレンダリングされない

ページがインデックスされない

  • サイトマップを作って送った
  • 正常に処理されましたと返ってきたけど
    • 認識はされるけどExclusionに入ってる
    • 内部リンクされてないのが原因？
  • ページを増やして内部リンクを増やした
    • 少しずつインデックスされるページが増えてきた！

タイトルや詳細が個別に表示されない

  • React HelmetでHTMLヘッダを上書き
    • ブラウザからは書き換わってるけどGoogle上では変わってない
  • CloudFunctionsで動的にヘッダを書き換えた
    • ボットからのアクセスの時だけ発動するように

コンテンツがレンダリングされない

  • SearchConsoleで試してみたらFirestoreからデータをとってくるはずがとってこれてない
    • ページによっては運がよければ表示される
    • レンダリングに時間がかかると諦めてるっぽい
  • Lighthouseで計測したらパフォーマンス50点台
  • TreeShakingした
    • ビルド時に不要なコードを削除
  • CodeSplitting
    • 初回のレンダリング時には必要なJSだけロードしそれ以外は遅延ロード
  • Lighthouse60点台
  • 無限スクロール

PWA×クラウドゲーミング

  • おりばーさん@Black Inc.(@oliver_diary)

クラウドゲーミング

OOParts

  • 開発してるクラウドゲーミング
  • ゲームをWebブラウザでアクセスするときの残念なところ
    • アドレスバーが邪魔
    • 余白がもったいない
    • アクセスするまでの導線が長い
    • => PWA化で解決！
  • 他にも
    • 起動時の初期表示が速い
    • アプリと違って審査いらない
  • PWAとクラウドゲーミングの相性抜群

コードサイズの大きなプログラムのロード時間：WebAssemblyの場合

  • @chikoskiさん

WebAssembly

WebAssemblyのいいところ

  • JSあるのになぜWebAssembly?
    • エコシステム
      • 他の言語の資産を使える
    • パフォーマンス
      • 速いけどそれだけじゃなくてブレが少なくて安定感が高い
  • 音声ファイルの扱い
    • ファイルサイズでかいので圧縮してmp3にして扱いたいとか
    • でもJSだけではできないのでWebAssemblyが役立つ

WebAssemblyの注意点

  • コンパイルするとjsとwasmが出力される
    • ファイルサイズがでかい
    • キャッシュを活用する
    • ネイティブのコードはブラウザにキャッシュされる
  • キャッシュにのったコードをいかに使い続けるか
    • 不必要なコードの変更をしない
      • ドメインとファイルを対応づけて保存されている
      • コンテンツが変わったら破棄されてしまう
    • URLを変更しない
      • クエリも変わらないように
    • ステータスコードを正しく返す
      • 200が返ると新しいコンテンツが来たと認識する
      • 変わってなければ304を返す
    • wasmのファイルを小さくしすぎない
      • 小さすぎるとキャッシュが破棄される(150kb以下くらい)
    • 最適化オプションをつける
    • システムライブラリをシェアする
    • application/wasmをつける
      • 全部のデータをダウンロードする前にある程度溜まったらコンパイルするという動きをしてくれる

うわさのJAMStackでPWAをさわってみた

  • のまどまんさん

JAMStack

  • 動的なデータコンテンツを取り扱う静的サイト
  • 事前に静的ページを生成しておく

JAMStack作ってみた

PWA化してみた

  • GatsbyにPWAのプラグインがある
  • キャッシュ使ったらパフォーマンス上がった
    • コンテンツがユーザ単位などで頻繁に変わる場合はキャッシュが活かしきれないかも

Monaca × PWA × 3D

  • VMT-Yamashitaさん

Monaca

  • ハイブリット開発環境
  • PWAのテンプレートがある