PWA Night vol.3 ~PWAのミライや活用方法をみんなで考えよう~に参加しました

4/17のPWA Night vol.3 ~PWAのミライや活用方法をみんなで考えよう~にブログ枠で参加しました。 pwanight.connpass.com

各発表の内容と感想等をまとめます。

初めてのPWA開発 あなたのWebサイトがPWAになるまで

speakerdeck.com

PWAとはGoogleが推進する先進的なモバイルウェブのユーザ体験の指針

  • Reliable
  • Fast
  • Engaging
    • ネイティブアプリのように直感的に操作できる
  • PWAでできることの中で以下の三つについて話す
    • ネットワークに接続に依存しない
    • インストール可能
    • 常に最新

Service Worker

  • アプリごとにブラウザに登録され、バックグラウンドで動くスクリプト
  • swのイベント
    • install
      • ブラウザに登録
    • activate
      • アプリを制御できる状態
    • wait
      • 更新の登録待ち
    • unintall
      • ブラウザへの登録を解除

Service Workerが更新された時の流れ

  • すぐにswはインストールされずに待機状態になる
  • ユーザがアプリケーションを終了するとswがアップデートされる
  • そのあと最新のリソースをswが取得する

各場合別の挙動

  • 初回起動
    • アセットをキャッシュ
  • 2回目以降
    • リクエストを監視
    • データをキャッシュ
  • swの更新あり
    • アセットを再キャッシュ
    • リクエストを監視
    • データをキャッシュ

PWAを実装する

  • ネットワーク接続に依存しない
  • 常に最新

    • を満たす
  • installイベントでアセットをキャッシュする

  • 2回目以降はアセットのリクエストを検知する
  • fetchイベントで検知
    • データのリクエストを検知する
    • キャッシュのキーをswのバージョンにしておくことで、swを更新した時に最新のキャッシュを最新にする

Q&A

  1. アプリが使えるキャッシュストレージの容量
  2. ブラウザによってバラバラ

  3. ブラウザ標準のHTTPキャッシュ機能の影響は?

  4. わからない

  5. ブラウザごとの対応状況の違いへの対処

  6. アプリにとって重要な役割を担うような使い方は避ける 必要であれば非対応環境のユーザに向けてその旨と解決方法を伝える方法を考える

Cache APIに触れる by @tiwu_officialさん

「ネットワークに依存しない」とは

  • swがリクエストを傍受してキャッシュしたデータを返す
  • swは

    • プッシュ通知
    • バックグラウンド同期
    • オフライン対応
      • やってくれる
  • respondWith()でレスポンスを返す

    • caches.open()でキャッシュ取得
    • cache.match()でキャッシュが存在するか判定
    • 存在したらreturn responseでレスポンスを返す
  • swがキャッシュの仕組みを持っているわけではない

    • swはリクエストにイベントを貼ることができるだけ
      • => Cache APIがキャッシュを行なっている
  • window、workerスコープで利用できる

    • localstorageと同じ感覚
    • swで結びつけて使う必要はない
    • 有効期限は持てない
    • StorageEstimate APIでキャッシュ使用状況がわかる
    • グローバルにcachesという変数がある

Cache API

  • caches.open()の引数を別にすることで複数のキャッシュを持つことができる
  • メソッド(更新系)
    • put(request, response)
  • 追加系
    • add(request)
  • 取得系
    • match(request, options)
      • options
        • ignoreSearch: クエリーを無視する
        • ignoreMethod: メソッドを無視する
    • matchAll(request, options)
  • 削除系
    • delete(request, options)
  • その他
    • keys

プロダクトでの使い方

  1. 一覧の詳細で必要な静的リソースを読み込む
  2. 古いバージョンを消して新しいキャッシュを作る

まとめ

  • swではなくcache APIによってキャッシュされる
  • LSと使い方似ているAPI
  • 使いこなすとかなり強力
  • ~ネットワークにアクセスしたら負け~

RoRをVueJS + Nuxt PWAで置き換えてみた by 天野たけしさん@devMeTokyo

moksahero.github.io

みんなが普段使っているサービスは、世界最速のサービス

  • PWA対応済み
  • ユーザの期待値は高くなっている
  • 常にオリンピックを見ているのでそれ以外は県大会レベルに見える
  • 少しでもオリンピックに近づけないといけない

PWA化で実現すること

  • サイトパフォーマンスが上がる
  • PWA StatsはPWAの成功事例がまとまっている

ITのプロジェクト

  • 何か新しいことをやらないといけない?
  • 今あるサイトを改良するとKPIや売り上げが上がる
  • 既存のビジネスモデルを変える必要がない

PWAへ置き換えをした

  • JAM STACK

    • JavaScript -> Vue, React
    • APIs -> GraphQL, REST
    • Markup(静的サイトジェネレーター) -> Nuxt, gatsby
  • 置き換え後の各レイヤー

    • レスポンシブ -> スマホファースト
    • 70-80%はスマホからのアクセス
    • スマホ版が先
    • スマホに特化したUIで作る
    • パソコン版は別で作る
    • SPAよりもパフォーマンスが出る
    • cssのライブラリはBuefyを使用
  • データ取得: RoR->Lambda

    • Lambdaでmodel諸々を置き換える
    • serverlessなのでアクセスに耐えられる
  • インフラ
    • EC2->S3+Cloudfront
    • EC2やめたのサーバー管理費が安くなった
  • ユーザ認証: 独自実装->Auth0

    • ログイン周りの実装がシンプルに
    • custom databaseを使って既存のユーザの移行可能
    • 日本語の対応それなりに必要
  • MySQL RDS

    • 唯一弄らなかったところ
  • 各KPIの改善など

    • リリース後にまたお伝えします

LT-1: 最大公約数的なServiceWorker制作から見るPWAの勘所 by 進藤龍之介さん@NPO法人日本Androidの会

  • wordpressプラグインを作っている方

  • みんなの環境にマッチしやすいPWA

  • PWAはキャッシュが命
    • Cache FirstとOnline First
  • キャッシュの除外
    • キャッシュされてはいけないものを除外する
    • 正規表現で柔軟にURLを指定
  • キャッシュの有効期限
    • 古いキャッシュを一定期間で捨てる
  • キャッシュする|しないの切り分けが大事

LT-2: Service Workerのcacheで色々問題が起きた話 by biga816さん

speakerdeck.com

  • 地下アイドルDAppsを作っていた
  • ionic3を利用
  • SW-Toolboxを利用(今はDeprecatedとなっている)

起こった問題

  • キャッシュの上限を超えた

    • 解決策
      • キャッシュの上限数を決めた
  • 開発環境のみ上限を超えた

    • AoTコンパイルが実行されていなかったのでそのファイルもキャッシュされていた
    • 解決策
      • 定期的にキャッシュ削除した
      • ローカルで開発するときはswをオフにする
  • キャッシュから動画が再生されない

    • safariでのみ問題が発生
    • Rangeリクエストに対しsafariではレスポンスコード200を受け取るとそれ以降そのファイルを読み込まない仕様になっていた
    • 解決策
  • キャッシュ対象はオフラインで最低限参照できるファイルに絞る方がいい

LT-3: Ionic PWA Toolkitについて by scrpgilさん

speakerdeck.com

  • Ionicについて
    • Ionic4 ReactやVueでもかける(Angularをすてた)
  • PWA Toolkitについて
    • デフォルトでworkboxが設定済み
    • などなど盛り込まれている
    • これからPWA始めるなら圧倒的敷居の低さ

Ionic Framework - Pwa Toolkit

感想とまとめ

  • PWA対応はwebアプリのUXを改善する為に行うもの
    • アプリのパフォーマンス改善こそがコンバージョン率などKPIの向上に繋がる
  • PWAのiOS対応はやはりどこも苦心されている様子だった
    • iOSの各バージョンがPWAにどこまで対応できているのかまとめとかないんだろうか
  • キャッシュ戦略考えるの楽しそうだけど、すでに動いているサービスのリソースを全部洗い出して適用させていくのはかなり骨が折れそう
    • 新規実装する場合は、初めからキャッシュ戦略を考えながら実装できると良さそう
  • PWAは関係ないけど、serverless framework勉強しようと思った
    • EC2の利用料下げれるの美味しい
  • Hasura GraphQL EngineというPostgreに対応したGraphQL Serverを構築できるエンジンがある
  • Ionic3以前は触って見たいと思わないが、Ionic4は良さそう
    • PWA Toolkitもかなり良さそう
  • PWA Night vol.4 ~PWAのミライや活用方法をみんなで考えよう~もすでに公開されていました
    • 1ヶ月後なのにもうトーク内容が決まってるのすごい

YAPC::Tokyo 2019に参加しました

2019/1/26(土)に開催されたYAPC::Tokyoに参加してきました。

YAPCの噂は昨年入社してから耳にこそしていましたが、参加したのは初めてでした。

Perlを軸としたカンファレンスとのことですが、いろんな技術の話が聞けてお昼に出た幕の内弁当のように楽しめるカンファレンスでした。

(今年は例年よりPerlの話が多かったそうです笑)

感じたことを忘れないうちにまとめておこうと思います。

yapcjapan.org

聞いたトーク

※軽く探して見つかった公開されているスライドだけ載せています。

載せていないスライドで公開されていないものがあれば教えていただけると助かります。

チームが前に進み続けるために僕たちが考えたこと

チームが前に進み続けるために僕たちが考えたこと / YAPC::Tokyo 2019 - Speaker Deck

スクラムを参考にしつつ、自分達にとって最適な開発フローを模索していったという話。

  • 業務・開発フローは「変えることは無条件に正しい」くらいに思って良いと思っています
  • 変化に対応し続けないといけない
  • 手を動かしたものだけが世界を変える

実例を元にした、「前に進み続けるため」の考え方についての内容は非常に説得力がありました。

チーム開発の難しさは入社当時に感じ、いまだに感じ続けていることですが、変化を起こさないことには何も変わらないことを再認識させられました。

結局物理カンバンを使うようになったという話は、最近ポストイットを使って便利さを感じたので共感できました。

(デジタル上の方がいつでも参照できて、永続的に残るので便利だと思ってたのですが、なぜでしょう)

私とOSS活動とPerl

私とOSS活動とPerl

世界はOSS開発者に優しいという言葉はとても実感がこもっていて、素敵な話でした。

自分が必要なものを作ったら、それを他の人にも使ってもらえたというのはたまらないだろうなと感じました。

IntelliJ IDEAのPerl pluginであるPerl5-IDEAは気になりです。

GitHub - Camelcade/Perl5-IDEA: Perl5 plugins for IntelliJ IDEA

Perl to Go

GoでWebアプリケーションを書く流れをPerlを普段書いている人がざっくり掴める話。

Perl MongerがGolangを始める時にはまったところの話では、GoにはCPANのようなライブラリの中央集権的サーバーがないことなど、Goを始める上で前提として知っておくべきことを聞けてとても参考になりました。

(バージョン管理されているライブラリがまだ少なく、管理が難しい、管理ツールがまだ二転三転しているなど)

ライブラリの管理が容易になったらGoでWebアプリケーション書いてみたくなりました。

(Perlから今はGoを書いているという人も多い印象ですよね)

ランチスポンサーセッション

Garudaというサービスについてのトークと20歳で新卒入社してPerlを書き始めた人のトークがありました。

今はPerlで書かれたプロジェクトをGoで書き直しているということでやはりWebアプリケーションをGoによって書くことはメリットが大きいようです。

Perl on Rails(GUEST: 大仲 能史)

PerlのプロジェクトにじわじわとRailsのソリューションを取り入れていっているお話。

自分も最近副業でRailsを書いているのですが、Webアプリケーションを作る上で必要で役立つ機能全部盛りな感じに感動しています。

どんなWAFでも必ずいつかは下火にはなるのでしょうが、今使っているWAFから次の開発に活かせるものを頭の隅に残しておけると良いのかなと感じました。

自前運用のZabbixからマネージド監視サービスMackerelへ - ソーシャルゲームタイトルのサーバ監視の移行事例

サーバ監視をZabbixをやめてMackerelに以降した話。

監視ルールや設定値などを例を元に話されていたのですが、自分で監視サービスを設定したことがないためかあまり理解できず・・・。

普段はメトリックを眺めるだけですが、どんなメトリックが必要か考えて設定していく力も必要だなと感じました。

ログにやさしいDB設計

ログのDB設計についての話。

ログは、

  • データ分析
  • 問い合わせの事実確認
  • 障害の原因究明
  • 障害の自動検知

のために必要で、そのための要件は、

  • 整合性
  • 網羅性
  • 追跡容易性

ログはなぜ必要なのか、そしてユースケースはどんな時か考えて、それを満たすために必要な要件を考えるというのは、ログを取る上でまず考えるべきことだというのは非常に腹落ちしました。

CPAN Module Hacks

CPAN Module Hacks - Speaker Deck

CPANへのアップ方法やプライベートCPANの作り方などのお話。

meta::cpanはauthorにフォーカスしていて、ダウンロード数などは表示されていないといった話は、ライブラリに対する各言語の思想などが伺えて面白い見方でした。

そして、CPAN TestersのモジュールをいろんなPerlのバージョンや実行環境で実行可能かテストする機構はすごい!

CPAN Testers Reports: Index

Dive into MySQL Error

Dive into MySQL Error (YAPC::Tokyoバージョン) - Speaker Deck

MySQLのエラーの仕組みを考えるお話。

エラーコードの1000, 3000番台はサーバーサイドエラー、2000番台はクライアントサイドエラーなど、エラーコードを見るだけでエラーの原因の切り分けができるというのはとても参考になりました。

レプリケーションスレーブはマスターから見るとクライアントと言えるというのもエラーコードによる切り分けに役立つ考え方でした。

エラーフォーマットやエラーログについての内部実装まで踏み込んだ話もユーモアを交えつつでとても面白かったです。

ここまでMySQLに強い人というのもなかなかいないのではないでしょうか・・・?

Lightning Talks

5分という時間に圧倒的に密度でした。

Perl6の正規表現の問題、npmでPerlのライブラリのインストール、Amazon LambdaでPerlのランタイムを動かす、Perl1をGoで書き直す、Perl入学式のコミュニティの話などPerlの話をこの密度で聞けたのは初めてで、楽しかったです。

Keynote: 松野 徳大

tokuhiromさんがこれまで歩んできたエンジニア人生の一端。

いろんな人を巻き込んで、不満のあるライブラリを作り直してAmon2などを作っていったという話はもちろんすごいのですが、それ以上にエンジニアとしての最高に楽しそうなところが何よりすごい、と感じました。

自分は今の所OSSの開発にはあまり興味はないのですが、後から振り返ってあの時は楽しかったと言えるエンジニア人生を送ろうと思うことができました。

最後に

自分は普段Unityの勉強会に参加することが多いのですが、YAPCは幅広い年代のエンジニアが集っている印象を受けました。

技術的な話だけでなく、いろんな開発者の歩んできた道の一端を聞くことができる貴重な機会だったと思います。

次の開催地は募集中だそうですが、ぜひRubyの総本山のShimaneで開催して欲しいです笑

その時はまたトークのsubmitをさせていただきます!

最後になりますが、運営の方々素敵なYAPCを本当にありがとうございましたm(_ _)m