「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は廃止という語気

3rd Party Cookie

  • 表示しているページの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アプリの中にアプリをインストールできる
  • この機能を持ったアプリをスーパーアプリと呼ばれる
  • 仕様の標準化が進んでいる

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のコードも生成できる