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

勉強会メモ
  • PWA Night vol.3 ～PWAのミライや活用方法をみんなで考えよう～に参加してきました。

pwanight.connpass.com

  • 今回はキャッシュ周りの話が多く実践的なノウハウが多かったんじゃないかと思います。開発する時に資料活用させてもらいます。
  • 参加者全員の自己紹介があったので参加者の層もなんとなく分かってそれも良かったです(アカウント名とアイコンと紐付かないのが残念！)
タイトル 発表者
既存のWebサイトをPWA化してみよう～Sevice Worker導入手順解説～ 小椋陽太さん@アシアル
Cache APIに触れる @tiwu_officialさん
RoRをVueJS + Nuxt PWAで置き換えてみた 天野たけしさん@devMeTokyo
最大公約数的なServiceWorker制作から見るPWAの勘所 進藤龍之介さん@NPO法人日本Androidの会
ServiceWorkerのCacheでいろいろと問題が起きた話 biga816さん
Ionic PWA Toolkitについて scrpgilさん

既存のWebサイトをPWA化してみよう～Sevice Worker導入手順解説～

  • 小椋陽太さん@アシアル

PWAとは

  • Googleが推進するモバイルWebのユーザ体験の指針
  • Reliable
  • Fast
  • Engaging

ServiceWorker

  • バックグラウンドで動くスクリプト
  • アプリごとにブラウザに登録される

ServiceWorkerのイベント

  • install
  • wait
  • activate
  • uninstall

SWの更新

  • 全てのタブでアプリを終了すると次に開いた時に更新済みのものが適用される

Cache APIに触れる

PWAの特徴

  • その一つにネットワークに依存しない

CacheAPI

  • ServiceWorkerがキャッシュの仕組みを持ってるわけでない
    • requestのイベントを拾えるだけ
    • CacheAPIがキャッシュの機能を持っている
  • ServiceWorker内でなくても使える
  • 有効期限はない

プロダクトでのキャッシュの使い方

  • 一覧画面で詳細画面のリソースをキャッシュしておくとか
  • 新しいバージョンが来たら古いバージョンを消しておく

RoRをVueJS + Nuxt PWAで置き換えてみた

  • 天野たけしさん@devMeTokyo

PWAの効果

www.pwastats.com

PWAの導入

  • 新しいことをやらないといけないか?
    • 今あるアプリを改良するとKPIや売上があがる
    • 既存のビジネスモデルを変える必要はない

最大公約数的なServiceWorker制作から見るPWAの勘所

PWA4WP

  • WordPressのPWAプラグインを作った
  • PWAはキャッシュが命
    • キャッシュファースト/オフラインファーストの選択
    • キャッシュするファイルの選択
    • キャッシュの有効期限
    • キャッシュファーストとオフラインファーストの組み合わせは今後実装
  • キャッシュするしないの選択が大事

ServiceWorkerのCacheでいろいろと問題が起きた話

  • biga816さん

キャッシュ上限に到達

  • 画像を全部キャッシュしてた
    • 容量上限に達してしまった
  • 上限や期限を設定しないといけなかった

開発環境でのみキャッシュの上限に到達

  • 開発中はAoTコンパイルしてないのでコードの量も大きかった
  • 定期的にキャッシュ削除

キャッシュから動画が再生されない

まとめ

  • 容量上限意識する必要あり
  • 無限に増えるコンテンツはCDN使った方がいい

Ionic PWA Toolkitについて

  • scrpgilさん

Ionic

  • Ionic4はAngular捨ててWebComponentsベースのUIフレームワークになった
    • ReactとかVueでも使えるようになった
  • cordvaからcapacitorに変わった

PWA Toolkit

ionicframework.com

  • ionicチームが出してる
  • デフォルトでいろんな設定やってくれてる
  • スタータープロジェクトが充実

「Frontrend × Bonfire Frontend」に参加してきました

勉強会メモ
  • Frontrend × Bonfire Frontendに参加してきました。

frontrend.connpass.com

  • YahooとAbemaTVの若手社員の入社から現在までの成長についてお話をきくことができました。
  • 「学生エンジニアから事業プロダクトを作るプロのエンジニアに成長できた」という言葉もありましたが、単にアプリ開発をするだけでなくKPIなどを意識して取り組んでいる姿勢が印象的でした。
  • 原さんの発表はノウハウがかなりつまっていたのでスライドをじっくり見返しておきたいと思います。
タイトル 発表者
新卒3年目、ヤフーで学んだ2年間を振り返る 濱田 唯 / ヤフー株式会社
AbemaTV 新卒1年目エンジニア実録 野口 直 / 株式会社AbemaTV
Webフロントエンド&デザインで学んだ2年間を総括 内藤 秀彦 / ヤフー株式会社
こえのブログでのPWA 〜開発現場編〜 原 一成 / 株式会社サイバーエージェント

新卒3年目、ヤフーで学んだ2年間を振り返る

  • 濱田 唯さん / ヤフー株式会社 メディアカンパニー マーケティングソリューションズ統括本部
  • 2017入社 エンジニア入社からフロントエンド

入社して2年

  • 新卒研修(3ヶ月)
  • OJT(3ヶ月)
  • 本配属
  • 広告入稿管理システム

2年での成長ポイント

チーム開発の心構え

  • コードレビューは大事
  • 人が読むことを意識して書く
  • レビューはプロジェクトの雰囲気を作る

設計構成への意識

  • 動けばいいではダメ
    • 大人数で長期で運用される
  • チームごとのルールにのっとったアーキテクチャで開発
    • TypeScript
    • re-ducks
    • AtomicDesign
  • 大事なのは
    • ルールが言語化されてること
    • メンバーが合意してること

新しい技術に対する意欲

  • 自分も議論に参加するために意欲的になった

AbemaTV 新卒1年目エンジニア実録

  • 野口 直寛さん @nodaguti / 株式会社AbemaTV 開発本部

1年目エンジニア実録

  • 配属から1年弱で約560PR10万行
  • 新卒研修:4月-5月
  • AbemaTVに配属:5月
  • 5-8月
    • コミット/PRの粒度に慣れた
    • 担当した機能はレビューもできるようになった
    • RxJS使ったFluxのフローを一通り作れた
  • 8-12月
    • 大きな案件でタスク分解/見積もりしてスケジュールどおり進行
    • プロダクトを伸ばすにはどうすればいいか考え実行
    • Chrome Dev Summitに参加
  • 1-4月
    • ディレクターやエンジニアにヒアリングして曖昧な仕様を固める
    • リリースまで持っていった
  • 振り返り
    • 学生エンジニアから事業プロダクトを作るプロのエンジニアに成長できた
    • どうUXに影響するか、どうKPIに影響するか考えられるようになった

2年目に向けて

  • 技術から事業に貢献できるエンジニア

Webフロントエンド&デザインで学んだ2年間を総括

  • 内藤 秀彦さん / ヤフー株式会社 ショピング統括本部
  • 2017入社 デザイナー入社からフロントエンド

入社から本配属

  • デザイナー研修
  • OJT
  • デザインによるサービス改善
    • サービスの課題を探して解決する
    • 商品数が多いので抽象的なワードで探しにくい
    • 絞り込みのUIを改善
    • ABテスト
    • 何が利いて効果があったか分かるようにするとよい
  • UIパーツのコーディングお作法
    • モジュール単位でパーツを実装
    • SCSS
      • カラーなどは共通化
      • よく使うスタイル軍はmixin

本配属から2年目の終わりまで

CVRを伸ばす改善サイクル

  • CVR: コンバージョン率
  • 課題に対して再現性のある勝ち筋を見つけサイクルを回す

UIパーツの整理

  • 一つのサービスなのに似たような部品がたくさん出来てしまう
    • UIライブラリを作った
    • コードと使い方をまとめたドキュメント

レガシーからモダンな開発環境へ

  • Before
    • PHPではきだしたHTMLにjQueryでDOM操作
  • After(移行中)
    • React/Redux/Next.js

今後

こえのブログでのPWA 〜開発現場編〜

PWAの高速化

  • PRPLパターン
    • Push,Render,Pre-cache,LazyLoad
  • CDNの活用
    • できるだけCDNにキャッシュする
    • originサーバまでアクセスしないから高速

コンポーネント指向

  • WebComponents
    • LitElements
  • 影響範囲を狭めることで捨てやすくなる
  • スタイルのCascadeとShadowDOOMによるスコープをそれぞれ活用する

WebでAudioRecording

  • ブラウザからマイクを利用できる
  • WAVはファイルサイズ大きいのでmp3に変換して使ってる
    • vmsg

開発フロー

  • 餅つき開発
    • 細かい粒度でプルリク
    • 捨てやすいように細かく
  • 最速でプロトタイプ
    • 無駄になることを恐れない
    • リリース前に出戻りになるよりいい
    • Firebase便利

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

勉強会メモ
  • Cloud Native Meetup Tokyo #7に参加してきました。

cloudnative.connpass.com

タイトル 発表者
Telepresence ではじめる k8s 時代のローカル開発 Toshihiro Goto@_shiro16(GMOペパボ)
Consul Kubernetes Integration and Consul Connect Ryo Takaishi@r_takaishi(GMOペパボ)
分散イメージレジストリの検討 〜Beiran & Dragonfly〜 安田 侑史@yupeji(クリエーションライン株式会社)
フルカン ムスタファ@furkanmustafa(Rainlab 株式会社)

Telepresence ではじめる k8s 時代のローカル開発

Telepresenceとは

  • サービスをリモートのk8sクラスタにつなぎながらローカルで動かせる
  • ローカルで動いてるアプリがクラスタの一部みたいな感じで扱える
  • 何がうれしい?
    • build/push/podのimage更新といった手間を省ける
    • ローカルからリモートの他のサービスに接続しながら開発できる
    • ネットワーク経路がデプロイしたときとほぼ同じになる

Telepresenceの使い方

  • brewでおとせる
  • 起動のパターン
    • ローカルで起動したアプリ
    • ローカルデ起動下docker上で動くアプリ

Telepresence導入のポイント

ハマりポイント

  • port80を使う場合
    • 80は使えないので他のポートにする必要あり
  • 1podに複数コンテナある場合
    • defaultのcontainerが置き換わる
    • defaultじゃないのがいいときはオプションで指定
  • dockerを使う場合
    • mountが遅い

参考

Consul Kubernetes Integration and Consul Connect

Consulとは

  • hashicorpが作って
  • Conusulの機能
    • Service Discovery for Connectivity
    • Service Segmentation for security
    • Service Configuration for runtime configuration

Consul Connect

  • サービス間通信の暗号化や認可
  • サイドカープロキシ
  • Consul Connect Proxyの代わりにEnvoyも使える

Kubernetes Integration

分散イメージレジストリの検討 〜Beiran & Dragonfly〜

  • 安田 侑史@yupeji(クリエーションライン株式会社)
  • フルカン ムスタファ@furkanmustafa(Rainlab 株式会社)

背景

  • docker pullするの遅い
  • Peer to Peerでそれを早くする

Dragonfly

Kraken

Origin

  • Seeder
  • マルチクラスタしたときに別のところにデータをとれる

Tracker

  • どのデータがどのチャンクを持ってるか知ってる

Proxy

  • Docker Registry Interface

Beiran

  • 自作のライブラリ
  • peerにイメージ持ってるか聞き回る
  • 隣の人が持ってれば高速にインストールできる
  • dockerコマンドの頭にbeiranをつけて使う

「どこでもKotlin #7 〜Kotlin MPP特集〜」に参加してきました

勉強会メモ
  • どこでもKotlin #7 〜Kotlin MPP特集〜に参加してきました。

m3-engineer.connpass.com

タイトル 発表者
Kotlin/MPPでX-PF事始めのつまづきポイント yashims85 (モバイルファクトリー)
How to publish a Kotlin Multiplatform Library 荒谷 光 (サイバーエージェント)
DroidKaigi 公式アプリのKotlin Multiplatform takahirom (AbemaTV)
Kotlin/NativeのiOSにおけるオーバーヘッド 星川 貴樹 (エムスリー)

Kotlin/MPPでX-PF事始めのつまづきポイント

なぜKotlin/MPP?

  • いい感じにクライアントサイドをリプレイスしたいから

Kotlin/MPP構成

  • Android/iOSのクライアントアプリ
  • クライアントのプレゼンテーションルータ
    • KoRouter
    • VueRouterみたいなもの
  • KoRouter
    • commonMain
      • 成果物はmetadata
    • jvmMain
    • iosMain
      • Native向け
      • iOS
      • 成果物.framework
  • クライアントアプリ
    • commonMain
    • androidMain
      • jvmMainのサブセット
    • iOSMain
    • main
      • AndroidManifestが入ってるだけ
      • 成果物.aar

まとめ

  • 目的によって構成を変えよう
  • なにが同じライブラリかどこかにまとめておくとよい
  • kotlinx難しい

How to publish a Kotlin Multiplatform Library

MPPライブラリのパッケージ構成

MPPライブラリのGradleの設定

  • IntelliJだとKotlinの雛形選べる

まとめ

  • Kotlin1.3からはbuild.gradleは一つで
  • metadataの成果物はcommonのこと
  • androidの配布はreleaseを明示的に

DroidKaigi 公式アプリのKotlin Multiplatform

  • takahiromさん(AbemaTV)

Kotlin Multiplatformを導入しやすい構成に

  • Ktor-Client + kotlinx.serializationを使う
  • Andorid定番のRxJavaなどはMultiplatform非対応
  • Modelで使うクラスはKotlin Multiplatformで使えるものだけにする
  • Klockというライブラリで日時など扱える

Kotlin MultiplatformとDagger

  • Dagger
    • DIライブラリ

Dynamic feature module

  • 必要ないものはあとかダウンロードしてくる

APIの環境切り替え

  • iOSあるからAndroidのBuildConfigだけではだめ

ハマったこと

  • 古いiPhoneだと動かないとか

Ktolin Multiplatform使ってどうだったか

  • Kotlinで書いたクラスやメソッドがXCodeの補完がきく
  • キャストもうまく動いてる

Kotlin/NativeのiOSにおけるオーバーヘッド

  • 星川 貴樹さん(エムスリー)

マイクロベンチマークの結果

ラムダ式の比較

  • inline化するとあまり変わらなかった
  • inline化しないとKotlin遅い

in(contains)の比較

  • kotlinはだいたい遅い
  • contains使うなら定数化するとよい

forEachの比較

  • forEachとfor inとfor in step
  • Kotlinのほうが圧倒的に速い
  • 特にfor inとfor in stepが遅い
  • kotlinでもforEachは遅い

ツールの紹介

AppCode

Hopper Disassembler

相互運用のオーバーヘッド

  • SwiftからKotlinを呼ぶコード遅い
  • Kotlinのクラス生成が遅い

相互運用におけるオーバーヘッド

  • Kotlin/Native内で完結する処理は割と高速
  • Hopper便利

「freee Tech Night #2 「大規模SaaSを支えるフロントエンドの話」」に参加してきました

勉強会メモ
  • freee Tech Night #2 「大規模SaaSを支えるフロントエンドの話」に参加してきました。

freee-tech-night.connpass.com

  • freeeのシステムは歴史があってかなり大規模だということを初めて知りました。
  • 多くのエンジニアで大規模なシステムを開発してい、普段のフロントエンドの勉強会ではあまり得られない考え方を得られました。
    • yarnからnpmに戻した理由なんかは大規模ならではだなと思いました。
    • デザインシステム作って効率的に開発できるようにする、なんていう夢はいろんな人が考えると思いますがそれを実現する段階まできていてすごいと思いました。
タイトル 発表者
会計freee7年目のフロントエンド開発 Takumi Ohashi
会計freee が yarn から npm に出戻った本当の理由 @_kemuridama
デザインシステムの設計とアクセシビリティの実現 ＠ymrl
最新の新プロダクトのフロントエンド事情〜freeeアプリストアの事例〜 横路隆

会計freee7年目のフロントエンド開発

  • Takumi Ohashiさん

会計freee

  • 単一リポジトリで7年くらいやってきた
    • モノリシックなRailsアプリ
    • フロントエンドもそこに含む
  • もともとcoffeeだったのを置き換えていってる
  • フロント/サーバの区分はなくみんなRailsとReactスキルが必須

初期 - 2014年の構成

  • Backbone
  • CoffeeScript
  • 片手間JSだった時代
  • 一つのGlobal変数でデータを共有

2015年- の構成

  • ES2015
  • React
  • babel

現在

  • ほぼReact
  • SPAではなく小さなSPAの集合みたいな感じ
  • ESLint/Prettier
  • Storybook
  • flowtype
  • jest

facebook/flux続けてしまった

  • Reduxではなくflux(アーキテクチャではなくライブラリの方)を使っている
    • 当時はReduxロックインを懸念してより薄いfluxを採用
  • 薄いがゆえにいろいろできすぎてしまう
  • 情報量が少ない
  • コード量が大きくなりすぎてReduxへの移行は厳しくなった

コンポーネントの状態をStoreで管理してしまった

  • 例えば
    • モーダルの開閉
    • ローディング
    • フォームの値
  • UIStoreというのを作ってそこで管理した
  • 非同期処理でAction2つ呼ぶのがつらい

Reactコンポーネントを継承して使ってしまっていた

振り返って

  • 初期の設計や規約がちゃんと整備できてなかった
  • 大規模ゆえに軌道修正が難しい
  • 誰かが横断的に監視し続けるにも限界がある
  • ルールの整備を勧めてる

今後

  • 共通UIコンポーネントライブラリを開発してる
  • フロントエンド委員会も継続的に活動中

会計freee が yarn から npm に出戻った本当の理由

  • @_kemuridamaさん

yarnからnpmにで戻るというブログを書いた

npm vs yarn

npm

  • nodeに内用される
  • officialなパッケージマネージャ

yarn

本当にyarnが必要なのか

yarnの利点

  • 高速インストール
    • かつては20倍
    • npm6ではほぼ同等
  • ロックファイル
    • パッケージが依存するパッケージのバージョンを固定できる
    • package-lock.jsonが登場した
  • ワークスペース
    • monorepoを管理する機能
    • Lernaを使えばnpmでもできる

なぜnpmに戻したか

複数バージョンのyarnが使いにくい

  • プロジェクトごとにバージョン返るのがやりづらい
  • yvmというものもあるけどnodeenvのように使いやすいものではなかった

2つのビルド環境

  • CircleCIによるDockerベースのビルド
  • Jenkinsによるビルド
    • 本番向けのビルド
  • 環境ごとにyarn入れるステップが増えてしまう

エンジニア組織の巨大化

  • npmは最初から入ってるから誰でも使える

npmに出戻るまでの道のり

  • yarn.lockの削除
  • node_modulesの削除
  • npm iでパッケージ再インストール
  • lockの移行は素直に行かないのでE2Eで担保

まとめ

  • npmの課題が解消されyarnのメリットが薄れてきた
  • エンジニアが多いことによるyarn導入コストの増加した

デザインシステムの設計とアクセシビリティの実現

  • @ymrlさん

会社の規模が急激の大きくなった

freeeのWebフロントエンド開発

  • デザイナーが画面モック作ってエンジニアへ
    • sketch
  • そこから先はエンジニア

大きくなってきた頃のWebUI

  • Bootstrapあら独自UIに
  • 要件が複雑化する一方で環境整備の不備が目立つ
    • CSS得意な人あんまりいない
  • 微妙に違う実装がうまれてくる
  • フロント不慣れな人も書くのでめちゃくちゃになってきた
  • UI作るのがつらい状況に

UIの統一的なチーム

  • Atomic Design and GuideLineチーム
  • どのデザイナーでも統一されたUIをデザインできるようにする
  • フロントエンド不慣れでも統一したUIをじっそうできるようにしたい

UIガイドライン

アクセシビリティ

  • 誰でも使えるサービスにしたい
  • 機能がどんどん増えてるので少ない人数でやっていくの大変
  • ESLintでJSXタグをチェック
    • Storybookに対して自動チェック回したり
    • a11yのaddonがある

今後

  • デザインシステムほぼ実装完了
  • サービスへ導入中
  • Sketchライブラリの共有が課題
    • SketchClooudで配布
    • 将来的にFigmaやAdobeXDにするかも
  • SCSS無秩序にオーバーライドされそうで怖い
  • ReactやFlowtypeへのロックイン問題
    • TS対応の検討
    • Vueなど使うプロジェクトがでてきたら・・

「JSUG勉強会 2019その3 LINEにおけるSpringの活用」に参加してきました

勉強会メモ
  • JSUG勉強会 2019その3 LINEにおけるSpringの活用に参加してきました。

jsug.doorkeeper.jp

  • LINEにおけるSpringの活用事例とSpringBootAdminを導入してみた知見についてお話を聞くことができました。
  • 前者について、高パフォーマンスが要求されるシステムにおいてRedisやKafkaを存分に活用して高速化を実現しているとのことでした。
  • 後者について、デモやライブコーディングを通じてSpringBootAdminの機能を紹介してもらいました。Actuatorで取得できる情報が可視化され便利そうだということを知ることができました。また、GUI上から設定変更ができてしまう等セキュリティ的な面で気を使うポイントがあるという知見も得られました。
タイトル 発表者
Personalized content recommender system on Spring 渡邉直樹 (LINE Corp.)
Spring Boot Admin ことはじめ 大沢和宏 (LINE Corp.)

Personalized content recommender system on Spring

-渡邉直樹さん (LINE Corp.)

SmartChannel

  • LINEで一覧の一番上に出てくる広告
  • 新着スタンプとか天気とか占いとか
    • パーソナライズされたものが出る
  • Contents
    • レコメンドを各サービスからかき集めて一時的に保存
    • ランキングして1件選んで配信

Architecture

  • FW/ライブラリ
    • SpringBoot2.1
    • Redis/MySQL/Kafka
      • ユーザのアクセスで直接MySQLをさわらず基本はRedisはさんで高速化
    • mybatis
  • ContentsはRedisに突っ込んでおいてその中から機械学習で表示するものを選定
  • ユーザのクリック等のイベントを受け取ったらとりあえずKafkaにproduceしてる
    • Kafkaによって速度/耐障害性が上がる
  • MLはPythonで
    • Javaとの連携部分はprotocolbufferで

Spring Boot Admin ことはじめ

  • 大沢和宏 (LINE Corp.)

SpringBootAdmin導入のきかっけ

  • 開発人数増えてくると一つのリポジトリで管理するのはつらくなってくる
  • 2,3人で開発できる粒度に切り分けた
  • コンポーネントごとに技術スタックが違っていた
    • SpringBootのバージョン違ったりBootじゃなかったりSpringですらなかったり
  • サーバ台数が多すぎてアラートが飛んだときのプロファイルングが大変

欲しかったもの

  • 適切なバージョンがデプロイされてるかチェックしたい
  • JVMが適切に可動しているかリアルタイムに見たい
  • 適切な設定で稼働しているかあみたい
  • 設定が少ないほうがいい
  • 一元管理できるダッシュボード的なのほしい
  • => SpringBootAdmingが良さそうなので導入

SpringBootAdmin導入してみた

  • 設定が楽
  • Actuatorで取得できる情報を可視化できる
  • slack通知も簡単(自前で実装する)
  • 認証はないがSpringScurityを使えば導入可
  • サンプルが豊富

SpringBootAdminの使い方

  • サーバ
    • 依存関係追加してApplication.javaにアノテーション追加するだけ
    • あとapplication.propertiesもちょっと追加する
  • クライアント
    • 依存関係追加してapplication.propertiesに設定書くだけ
    • actuatorの設定いれればメトリクスたくさんとれる
      • レスポンスの中身とかも見える
  • https://codecentric.github.io/spring-boot-admin/current/

SpringBootAdminを使ってみて

  • git propertiesを使うとコミット情報とかも見えるようになる
  • managementの設定に気を使ったほうが良さそう
    • 不要なActuatorのエンドポイントは閉じる
    • http traceやsessionは流さないほうが安全
  • Securityの設定も適切に
    • UI上から設定変えられたりできちゃうのでそれを塞いでもいいかも
  • SpringSecurityのBasic認証はパスワードの暗号化頑張りすぎてて重くなる

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

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

wajs.connpass.com

  • 今回はいつもより人数少なめでいい雰囲気の勉強会でした！"全員登壇が目標"の勉強会なのでそろそろ初登壇してみたいな・・・とも思いました！
タイトル 発表者
Expo と Firebase Authentication @okamuuu
vueでのcssアニメーションの話 @daitasu
記事作成ツールのフロントエンドをNuxt.js × Atomic Designでリプレイスしている話 @comy
反復処理に速さを求めて @camcam_lemon
無思考型個人開発のススメ @skmt3P
『if文のはなし』 @ticktakclock
勝手に技術書でビブリオバトル「JavaScriptで学ぶ関数型プログラミング」 @sadnessOjisan
On the Evolution and Change of Riot.js v4 @kuwahara_jsr
もっと画像を壊した話 @chikoski

Expo と Firebase Authentication

  • @okamuuuさん

ExpoとFirebaseAuthentication

  • 意外と大変だったので共有
  • SNS認証でログインが必要
  • Firebase Authenticationで簡単にいけるのでは！？
  • RNとFirebaseとOAuthとサーバサイドの知識必要だった

なぜExpo(ReactNative)

ExpoでFirebaseAuthentication

  • Webで使えるメソッドが使えない
  • facebookは簡単
  • googleとかtwitterは大変
  • Expoが手伝ってくれるところもあるけど自前でやらないといけない所も多い

参考

vueでのcssアニメーションの話

  • @daitasuさん

CSSアニメーション

  • @keyframesで始点と終点を指定

VueでCSSアニメーション

  • v-if/-v-showで切り替え
  • vue-transition
    • v-enter
    • v-enter-to
    • v-enter-active
    • v-leave
    • v-leave-to
    • v-leave-active
  • js hookもできる
  • jsライブラリ殿組み合わえもしやすい

記事作成ツールのフロントエンドをNuxt.js × Atomic Designでリプレイスしている話

  • @comyさん

NuxtとAtimicDesign

  • ディレクトリ構成
    • /components配下にatoms等々
    • pagesはそのまま
    • templateは使わない
  • atoms
  • molecules
    • atomsで構成される
    • state持って良い
    • vuexアクセス不可
  • organisms
    • atomes/molecules/organismsで構成
    • 再利用考えない
    • state持つ
    • vuexアクセス可
  • 責務がはっきりしたので肥大化しづらく再利用しやすくなった

反復処理に速さを求めて

  • @camcam_lemonさん

JavaScriptのイテレーション処理

  • たくさん書き方がある
  • どれが一番早いか
  • for inはおそすぎ
  • whileが強い
  • ループ回数増やしていくとforが上回る
  • jQuery謎の安定感
  • mapはだんだん遅くなっていく

無思考型個人開発のススメ

  • @skmt3Pさん

個人開発

  • 余計なことに時間かけたくない
  • Nuxtで規約を設けて開発
  • docker個人PCだと重くて動かない
  • PrettierとLintを信じる

『if文のはなし』

  • @ticktakclockさん

JavaScriptのif

  • 静的型付け言語に慣れている人だとJavaScirptは感覚が違う
  • true/falseで判定する
  • if(str) { ... }!?
  • if(str !== null) { ... }ではないのか!?
  • truthy/falsy
    • 型変換した結果が入る
    • false => false/undefined/null/''/0/NaN
  • 空文字なんでfalsy? => lengthが0だから
  • if文の条件式には何でも入れられる

勝手に技術書でビブリオバトル「JavaScriptで学ぶ関数型プログラミング」

  • @sadnessOjisanさん

知的評論合戦ビブリオバトル

  • 本を持ち寄ってディスカッション

JavaScriptで学ぶ関数型プログラミング

  • ライブラリのインターフェース設計に役立ち
  • 第一級関数
    • 値として関数を使える
  • 作用的プログラミング -関数を実行するために他の関数を呼び出す
  • 関数を組み立てる関数
    • カリー化
    • 実行されるたびに新しい関数を返す
  • 設定を加える関数を作るにはどうしたらいいかあを学べる

On the Evolution and Change of Riot.js v4

Riot

  • Reactの競合みたいな立ち位置
  • Reactより機能は劣るが導入が速い

Riot@4

  • 破壊的変更多い
  • 拡張子が.tagから.riotになった
  • Reactっぽくなってきた
    • ライフサイクルメソッド
    • props/state
  • Vueっぽくも見える
  • まだベータ版なので注意

もっと画像を壊した話

  • @chikoskiさん

JavaScriptで画像を壊す

  • WebCamで撮った画像を壊して表示する
  • ArrayBufferをBlobにしてJPGにして表示する
  • Workerの第二引数に{mode: 'module'}つけるとES Modules使える
  • worker-dom

「UIT#6 進化する React.js」に参加してきました

勉強会メモ
  • UIT#6 進化する React.jsに参加してきました。

uit.connpass.com

タイトル 発表者
Hooks で作る React.FC Takepepe
Page Stack again in React sunderls
現場から届けるReactの悩みと改善 sakito

Hooks で作る React.FC

  • Takepepeさん(DeNA)

サービスフロントエンドアニメーション

  • アニメーションネガティブ要因
    • ただ派手なだけ
    • 予測不能な動き
    • テストつらい
  • 速度 === UXなアプリもあればそうでないアプリもある
  • アニメーションが向かないアプリ
    • 読み物系
    • 遷移が多い
  • 明確なユーザストーリーが描けるものは活用するべき

機能としてのアニメーション

通知機能

  • 利用者が興味がないフェーズ
  • 悪目立ちさせない

補佐機能

認知機能

対話機能

  • 利用者と対話するフェーズ
  • 従順な反応
  • リアルコミュニケーションと同じ

耐火機能

  • 利用者が評価するフェーズ
  • アプリからの要求対価

React Hooksとアニメーション

従来のReactとアニメーション

  • アニメーションは非同期
  • classにする必要ある
  • cssに関する知識がいる

React Hooksとアニメーション

  • Classが不要に
  • メモ化が簡単
  • アニメーションもやりやすくなった
  • useContextで0~1の係数を管理して子に伝播する
  • function componentに気軽に後からアニメーション追加できるのがいい

Page Stack again in React

  • sunderlsさん(LINE)

アプリとWeb

  • アプリとWebどちらがいいか?
    • ユーザは気にしない
  • googleとかinstagramはアプリを推してる

アプリの何がいいのか

  • 速いのがいい?
    • twitterのアプリとWebを比べるとあまり変わらない?
  • アプリの方がトランジションがあってよい
    • Webでもがんばればできる
  • アプリはページ遷移がスタックされてる

現場から届けるReactの悩みと改善

  • sakitoさん(yahoo)

担当のプロジェクト

  • フロントエンド15人
  • BtoB

刷新

  • React + TypeScript
  • SassからEmotion

TypeScript採用前

  • 採用前はJSDocを頑張って書いてた
  • 更新されずに放置される
  • propsを確認するUnitTestメンテ辛い

TypeScriptの採用

  • TypeScript採用で実装スピード遅くなってしまわないか？
    • コンパイルでエラー分かるのが効率的だった
    • 修正箇所がわかりやすい
    • propsのデータがわかるから開発しやすい
  • 使えないライブラリないか
    • そんなことなかった
    • 今どきのReactライブラリはTypeScript対応してる

SassからEmotion

  • ファイルサイズが小さい
  • styled-componentsのようなstyled記法だけでなくCSS Props記法が使えるのがいい
  • コンポーネントとCSSが一対一になったので削除しやすい

ReduxFormからFormikへ

  • ReduxFormつらかった
    • バリデーションは拡張しないとつらい
    • 簡単なフォーム作るには便利
  • Yupというバリデーションライブラリと合わせて使うとやりやすかった

Reduxの構成変更

  • 従来は1ページ1store
    • コピペが乱立
  • re-ducks
    • ducksを拡張していい感じにしたもの
    • それぞれのファイルの責務がわかりやすくなった
    • テスト書きやすくなった
    • そこそこ規模大きめな時に向いてるのかな？
  • Immerを採用
    • ImmutableJSはハードル高い
      • Redux周り以外にも影響ある
    • Storeのデータ構造の操作が見やすくなった
    • 開発メンバー多くてもimmutableな状態を保ちやすい
    • レビューもしやすい

「Frontend de KANPAI! #6-みんなのサービスづくり-」に参加してきました

勉強会メモ
  • Frontend de KANPAI! #6-みんなのサービスづくり-に参加してきました。

frokan.connpass.com

タイトル 登壇者
note を Nuxt.js でリプレイスしている話 石川 大地さん
サービスドリブンな開発 森口 慎哉さん
WebXR Device API 株式会社小山田 晃浩さん
開発を担当した三年間の振り返り takepepeさん
プロダクト開発におけるスキルと肩書 谷口 祐貴さん
体験と設計 フロントエンドエンジニアの二つの責務について potato4dさん

note を Nuxt.js でリプレイスしている話

noteリプレイス

  • AngularJS -> Nuxt
  • Elastic Beanstalk使ってる
    • Lambda使ってたけどaws-serverless-expressでエラー
  • 二重メンテつらいけど徐々に移行してる

サービスドリブンな開発

  • 森口 慎哉さん(株式会社ZOZOテクノロジーズ)

開発体制

  • サービス単位でチームがある
  • やりとりはslackなどでオープンに

フロントエンド環境

WebXR Device API

  • 小山田 晃浩さん(株式会社ピクセルグリッド)

WebXR Device API

  • 2019/2ファーストドラフト
    • GoogleCanaryでも使えない
    • 前はflag立てればいけたけど変わった
  • OpenXR

HitTest

Quic Look

  • iOSの床を認識する機能

開発を担当した三年間の振り返り

技術選定

  • DeNAはVueが多め
    • Reactの知見も作りたいのでReactを選択
  • 型システム
    • ReactならFlow(という時代だった)
    • 今はTypeScript
    • 型があるから長期運用できている
  • フレームワークに知識を載せすぎるとつらくなる
  • 賢いUIは移植が大変
  • ライブラリの作法には乗ったほうがいい

プロダクト開発におけるスキルと肩書

モダンなプロダクト開発のフェーズ

  • Discovery
    • 課題の発見アイデアの探求
    • プロトタイピング
    • デザイン思考
  • Delivery
    • ものを作って届ける
  • どちらに情熱を注ぐか

ユーザ体験を構成する段階

  • 五段階
    • Surface(表面)
    • Skelton(骨格)
    • Structure(構造)
    • Scope(要件)
    • Strategy(戦略)
  • どこに興味があってどこができるか考えてキャリアを考えると良い

体験と設計 フロントエンドエンジニアの二つの責務について

  • potato4dさん(LINE株式会社/ElevenBack)

フロントエンドエンジニアの責務

  • アーキテクトとして持続可能な開発体制を作る責務
  • より良い体験を提供する責務

より良い体験を提供する責務

  • フロントエンドエンジニアが一番インターフェースをさわってる

フロントエンドエンジニアだからこそできること

  • フロントエンドエンジニアは器用貧乏
    • サーバサイドほどアーキテクチャに時間をとれない
    • デザイナーほどUI/UXに時間をとれない
  • どの領域も基礎知識があって掛け算できるのが強み

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

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

nodejs.connpass.com

タイトル 登壇者
汎用木構造データ生成機としてのJSX: JSXをHTML以外に活用する shibukawa
Yahoo!ニュースにおけるBFFパフォーマンスチューニング事例 Mt.Tomo32, @gladenjoy, @oTheRwoRldy
金無し、時間はコマ切れ、リーンにやりたい。そんなチームが使う、リアルな技術選定と、Typescriptの型情報をフロント/サーバーで共有したい需要 @dublook
DCL15秒の見れないサイトを3秒まで改善した話。改善継続中 @mahiguch1
PromiseとNode.jsで解説する Smart Payment Button PayPal 岡村さん

汎用木構造データ生成機としてのJSX: JSXをHTML以外に活用する

  • shibukawaさん

JSX

  • マークアップとViewロジックの分離は関心事の分離ではなく技術の分離
  • JSの中にHTMLを書けてHTMLの中にJSを書ける

HTMLは木構造

  • 他にも木構造のものはたくさんあるので活用できそう

まとめ

  • 構造化データを扱うDSLとしてのJSX
    • 0から言語を作るよりも圧倒的に楽
  • コード量は増えるので付加価値を付けられると使い物になるかも

Yahoo!ニュースにおけるBFFパフォーマンスチューニング事例

  • Mt.Tomo32さん
  • @gladenjoyさん
  • @oTheRwoRldyさん

yahooニュース

  • もともとJavaだった
  • SSRしたくなってNodeで書き直した

Nodeに置き換え

  • そのままではパフォーマンスでなかった

ボトルネックを特定

  • 試したこと
    • console.time/console.tineEnd
    • sjsp
    • node --prof index.js
    • node --process-prof isolate-0xnnnnnnn.log > result.txt
      • => C++のCPU処理が重かった
      • flamebearerによる可視化
    • node --inspect
  • わかったこと
    • axios-cache-dapterによるキャッシュ
      • JSON.parseが重い
    • DIコンテナから取り出すインスタンスがシングルトンでない

axiosのキャッシュパフォーマンス改善

  • 前段にキャッシュサーバなく後段はマイクロサービス
    • JSON.parseが同期なので重い
  • JSON文字列ではなくオブジェクトをキャッシュするように変更

DIコンテナ内のインスタンスをシングルに改善

  • シングルトンスコープでコンテナに登録するように変更

それ以外の改善

  • Clusterモジュールの導入
  • バックエンドAPIへのKeepAlive対応

金無し、時間はコマ切れ、リーンにやりたい。そんなチームが使う、リアルな技術選定と、Typescriptの型情報をフロント/サーバーで共有したい需要

  • @dublookさん

リーンスタートアップと技術選定

  • いきなり作るよりニーズの検証
  • 最初は技術を使わなくてもできることから検証
  • 徐々に技術を使ってスケールさせていく
  • jsonの型がわからなくてつらい
    • TypeScriptを使うことに
  • クライアントもサーバもTypeScript

DCL15秒の見れないサイトを3秒まで改善した話。改善継続中

  • @mahiguch1さん

3年前にリリースしたWeb

  • 気がついたらDOM Content Loadedが15秒かかるようになっていた

改善1

  • scriptタグ減らす(まとめる)
  • scriptタグにasyncつける
  • cssをpreload
  • 画像サイズ最適化
  • => 5%改善

改善2

  • nodeとgulpとTypeScriptのバージョ投げた
  • 劇的に改善

改善3

  • webpackとReactをバージョンアップ
    • tree shakingがきいたからっぽい
  • 劇的に改善

PromiseとNode.jsで解説する Smart Payment Button

PayPalの実装方法

  • JSだけで実装完了
  • Promise対応
    • リダイレクト処理無しで決済結果の描画が可能
  • 各言語のSDKでサーバサイド実装もできる
  • 読み込むURLのパラメータでオプション指定できる
  • 内部でGraphQLを使って効率化

「Cookpad TechConf 2019」に参加してきました

勉強会メモ
  • Cookpad Tech Conf 2019に参加してきました。

techconf.cookpad.com

タイトル 発表者
クックパッドが目指す、これからのデザインとプロダクトのあり方 宇野 雄
生鮮ECクックパッドマート - サービスの立ち上げから拡大に向けて 長野 佳子
料理の学習体験をデザインする 須藤 耕平
新規サービス開発を加速させる技術とデザイン 藤井 謙士朗
Challenges for Global Service from a Perspective of SRE 2nd season 渡辺 喬之
レシピを解析する！Machine Readable Recipe（MRR: 機械可読なレシピ）の開発 伊尾木 将之
クックパッド動画事業開発のチャレンジ 渡辺 慎也
〜霞が関〜　クックパッドiOSアプリの破壊と創造、そして未来 三木 康暉
スケーラブルなセキュリティ監視基盤の作り方 水谷 正慶
新規アプリ開発を支えるユーザ・決済基盤 宇津 宏一
Re:silience から始めるカオスエンジニアリング生活 小杉山 拓弥
基調講演:なぜ毎日の料理を楽しみにするのか 成田 一生

クックパッドが目指す、これからのデザインとプロダクトのあり方

  • 宇野 雄

Cookpad

  • 毎日の料理を楽しみにする会社
  • 4000万人
  • 71カ国
  • 26言語

クックパッドができてないこと

  • 全社通した横断体験が設計されてない
  • アプリの体験がWeb
  • もっとクックパッドっぽさがほしい
    • 期待値に対するふるまいの享有
    • 見た目は違ってもいい

デザイン

  • 技術の全ては夢物語を現実にするための手段である
  • BTCモデル
    • Business
    • Technology
    • Creative
  • デザインはデザイナーだけが作るわけじゃない
    • 全員で作り上げる
  • Figmaがいい
    • 全員で作り上げてる感じ

生鮮ECクックパッドマート - サービスの立ち上げから拡大に向けて

  • 長野 佳子

クックパッドマート

  • アプリで注文して届けるサービス
    • 家までは届けない
    • 自分で都合のいい時に取りに行く
    • 送料無料
    • 最低注文金額なし

解決する課題

  • 平日買い物できない
  • 受け取りで家にいないといけない
  • 最低注文金額があるのでまとめ買いしないといけない

仮説検証

  • 買い物上手で時間のある主婦が買い物代行
    • 社内でMVP検証
  • Design Sprint
    • 短期間で集中的に検証
  • 今できる最速の方法で検証し仮説の確度を上げる

さらなる改善

  • スマートロックで無人の冷蔵庫
    • アプリで冷蔵庫をあける
  • 販売店との連絡等オペレーションを自動化
  • 今はまだiOSだけ

料理の学習体験をデザインする

  • 須藤 耕平

たべドリ

  • おいしい食べ方学習ドリル

難しかった

  • 上達の定義が難しい
  • 定義できないから何を学ぶべきかわからない

どうなりたいか

  • レシピ見なくてもぱぱっと作れるようになりたい
    • 速さとかではなく対応力

新規サービス開発を加速させる技術とデザイン

  • 藤井 謙士朗

komerco

  • 料理が楽しくなるマルシェアプリ
  • 器とか料理道具を買える
  • 現在はiOSのみ
  • 購入用と出品用のアプリ

開発立ち上げ

  • iOSエンジニア4人
  • デザイナー1人
  • ディレクター1人
  • サーバは専任なし
    • Firebaseを使った
  • スピード感が求められt
    • クックパッドで使ってるアイコン使ったり
    • UIは後から詰めていった
    • 正常系のみ

デザインの享有

  • デザインを考えるよりも享有に時間がかかる
  • Sketch + Absstract + Zeplin + Marvel
  • Figma
    • オンラインで同時に編集ができる
    • 変更履歴も管理できる
    • プロトタイプも作れる

コンポーネント

  • AtomicDesign導入
  • 最小単位に区切って再利用性上げた
  • 管理しやすい
  • メンテしやすい
  • 安心しながらいじくりまわせる
  • Figmaとの相性も良い
    • Sketchだと管理が大変だった

開発スピードの向上

UIガイドラインを作成

  • Figma上に作成
  • 色の定義とかmarginとか
  • デザイナーとエンジニアのコミュニケーションを円滑に

アイコンフォントの作成

  • 画像が複数必要
    • @2x,@3xとか
    • 管理するのが大変
  • アイコンフォントならWebとも共通で使える
  • gitで管理してgithub pagesで公開

アニメーションの導入

  • 気持ちのいいインタラクションと開発工数はトレードオフ
  • Lottieを使った
    • jsonからアニメーションを実行
    • iOSとWebで使い回せる
  • デザインから実装までデザイナーが完結できる

デザインをコード化

  • デザインデータをReactコンポーネント化
  • タップ時の挙動などWeb上で確認できる
  • デザインに関するところは極力デザイナーがやる
    • エンジニアは機能の実装に集中してもらう

Challenges for Global Service from a Perspective of SRE 2nd season

  • 渡辺 喬之

クックパッドのグローバル版

SREの役割

  • SREのユーザはエンドユーザと開発者
  • SREが負担を背負って開発者が快適になるのは継続させることができない

レシピを解析する！Machine Readable Recipe（MRR: 機械可読なレシピ）の開発

  • 伊尾木 将之

レシピのその先

  • レシピの会社ではない
    • 毎日の料理を楽しみにする会社
  • レシピを検索する以上のことができていない
    • スマートキッチンを去年から始めた
  • 自動で調理してくれるもIoT家電もある
    • メーカーに依存する
    • クックパッドのレシピデータを使えないか
      • 人間が書いたレシピを機会が簡単には理解できない
    • => MRR(Machine Readable Recipe)

MRR

  • レシピをグラフ構造で表現
  • 中間ノードで検索

MMRを作る難しさ

  • 材料情報
    • 表記ゆれ
    • 分量の正規化
  • Action情報
    • 焼くとか煮るとか
    • input情報
  • メタ情報
    • 栄養成分

材料名の正規化

  • 醤油だけで200パターン以上
    • 醤油、しょう油、醤油（下味用）
    • 地道に網羅するのは現実的でない
  • 機会がクシュで対応
    • Encoder-Decoder
    • 翻訳でよく使われる技術

分量の正規化

  • おおさじ1、ひとつかみ、2から4人、かぶるくらい
  • BNF
  • 95%の正答率

MRRまとめ

  • スマートキッチンなどさまざまな応用に期待

クックパッド動画事業開発のチャレンジ

  • 渡辺 慎也

クックパッドTV

  • 料理動画事業を切り出した会社
    • 意思決定のスピードを向上するため
    • 独自に採用をするため

cookpad storeTV

  • スーパーの売場にタブレット置いて動画を流す
  • 広告収益モデル
    • 動画の合間に広告も流す

課題

  • 再生数の制御
    • 足りないとクレーム
    • 多いとクックパッドが損する
    • 一定期間で平準化させたい
  • 配信計画、配信比率を出す
    • 正確な在庫から予測できればいいが難しい
    • 実測をもとに計算し変動させていく
    • ログ収集してそれをもとに計算

cookpadTV

課題

  • 大量メッセージ
  • AppSyncを通して配信
    • コメントやスタンプなど
    • 1秒間に何百万のメッセージが送られてしまう
  • メッセージをバッファリングして軽減
    • なるべく遅らせない
    • 順序保証はしない
    • ロストは許容
  • go/gRPC

〜霞が関〜　クックパッドiOSアプリの破壊と創造、そして未来

  • 三木 康暉

クックパッドのiOSアプリ

  • 歴史がある
  • コード量も多い
  • ビルドにとても時間がかかある
    • 1日/1時間費やしている人も
  • Objective-Cが25%残ってる

プロジェクトの改善

  • コードの整理
  • Objective-Cをなくす
  • ビルド時間の短縮

マルチモジュール化

  • キャッシュが効くようになりビルド高速化
  • 古い実装を疎結合化

Xcodeプロジェクトの破壊

  • viper
  • xcodegen
    • yamlからxcodeprojを生成

スケーラブルなセキュリティ監視基盤の作り方

  • 水谷 正慶

セキュリティ監視

  • 防御
  • 検出
  • 対応

なぜ監視

  • 完全な防御はありえない
  • 防御より検出のほうが利用者の負担が少ない

スケーラブルな監視

  • サービス規模が大きくなっても対応できること
  • 監視対象が増えても対応できること

Security as Code

  • ログ収集と分析
  • 検知に係る処理をコード化
    • テストできる
    • アラート判定条件の高い記述力
    • 自動化
    • バージョン管理

アラートの検出

  • S3に転送されたログから検出
    • アラート検出のためのLambdaを実行
  • アラート関連情報の収集
    • それまでの操作履歴
    • デバイス情報
  • アラートの評価
    • リモートワークの人がたまたまカフェのwifiからアクセスしただけとかそういうのを判断

新規アプリ開発を支えるユーザ・決済基盤

  • 宇津 宏一

モバイルアプリ

  • アプリ間で共通の機能がある
    • ユーザ管理認証
    • アプリ内課金

共通のユーザ決済基盤(クライアント)

  • API通信時に自動で再認証
    • 通信時に認証を意識させない
    • 認証失敗時に自動で再認証
  • アプリ内課金
    • iOS/Androidでぜんぜん違う
    • それぞれ処理フローを標準化
    • 例外的な動作も対応

共通のユーザ決済基盤(サーバ)

  • サーバサイドはマイクロサービス化されている

Organized Around Business Capabilities

  • 各サービスはそれぞれが独立したビジネスをやっている
  • そうでなかったら別の構成になっていたかも

Re:silience から始めるカオスエンジニアリング生活

  • 小杉山 拓弥

Chaos Engineering

  • 分散システムで不安定な状態に耐えることのできる環境を構築するための検証
  • Chaos Monkeyというランダムにインスタンスを落とすツール
  • ランダムにインスタンスを落とすことは重要ではない

クックパッドでChaos Engineeringをやる理由

  • なぜマイクロサービス
    • 開発速度向上
    • リリース速度向上
    • 複雑性は増加してしまう
  • マイクロサービスの課題
    • サービス間通信んお状況がすぐにっわからない
    • 連鎖的障害
    • 個々のサービスの状態はわかってもつながりはわからない
    • => サービスメッシュ
  • サービスメッシュ
    • Envoy
    • サービス間通信の状況がわかる
    • タイムアウトやリトライをアプリではなく中央的に管理できるようになった
  • Chaos Engineering

Chaos Engineeringをどう実践したか

  • Envoyの機能で一定割合を503で返すといったことができる
  • Chaos Engineeringが効果的な領域
    • 障害がおきたときにどんな影響があるかわからないもの
      • Network　Fault Injection
    • 障害がおきることを考えたことがないもの
  • 顧客影響が少なからずあると分かっていながら本当にやるか？
    • ステージングでも分かることはあるはず

なぜ毎日の料理を楽しみにするのか

  • 成田 一生

2018年のクックパッド

  • cookpadTV LIVE
  • Komerco
  • cookpad mart
  • Alexaスキルのスペイン語版
  • たべドリ
  • cookpad Do!
  • OiCy Platform / OiCy Taste
  • 投稿レシピ数世界で500万品
    • 国内300万品

毎日の料理を楽しみにする

  • 定款の第2条(ミッション)に追加
    • ミンションを達成したら解散することも記載

料理って必要?

  • からだは食べ物でできている

なぜ毎日の料理を楽しみにするのか

  • 楽しみにしてることは言われなくてもやっちゃう
  • おいしい食材を手に入れられるようにする
  • 料理を楽しみにするスキルを身につけられるようにする
    • cookpadTV LIVE
    • たべドリ
    • cookpad Do!
  • ゴールは遠ざかってる
    • それを近づける方法は楽しくすること

「JAWS DAYS 2019」に参加してきました

勉強会メモ
  • JAWSDAYS2019に参加してきました。

jawsdays2019.jaws-ug.jp

タイムテーブル

10:10～11:00

トラック タイトル 発表者
A AWSからJAWS-UGに向けてのメッセージ 吉江 瞬さん
沼口 繁さん
亀田 治伸さん
B PythonとSageMakerで始める MLチームのみで完結するAPIの構築事例 武田 研恒さん
B メディアによるAI活用（時事クイズの生成と高校野球戦評記事の自動生成） 佐渡 昭彦さん
C サーバレスで動かすトークン発行プラットフォーム 小池 駿平さん
C AWS Serverlessを活用したサービス監視 清家 史郎さん
D 今日からはじめるCI/CD…のためのAWSアーキテクチャ事始め 山﨑 奈緒美さん
波田野 裕一さん
E 1日でSSHをやめることができた話 ~AWS Systems Manager Session Manager 導入と運用Tips~ 金井 栄喜さん
E AppStream 2.0を活用してユーザ端末に依存しない運用にしよう 那須 隆さん
F 新卒一年目のSREがコンテナをデプロイできるようになるまでの道のり 原田 大地さん
坂田 純さん
G 子育てで覚える AWS Organizations 〜ITエンジニア英才教育〜) 九龍 真乙さん
H Amazon Sumerian によるユーザーインターフェイスへのアプローチ 大井 友三さん
I 「AWS IoTのベストプラクティス」それホント！？ 森本 良平さん
園田 修平さん
J 音声ではじめる新しいオンライン決済サービス体験ワークショップ Okamoto Hidetakaさん
清野 剛史さん
K リクルートライフスタイルでのクラウドエンジニアのステップアップ方法 山田 雄さん
K 今日、これから「JAWS DAYS 2019」で体験できるSORACOMの展示内容を一気に紹介！ 松下 享平さん
K Auth0を使ってAWS上のサービスに対する認証・認可を強化 古田 秀哉さん

11:10～12:00

トラック タイトル 発表者
A AWS環境のセキュリティ運用(設計)をはじめてみよう 臼田 佳祐さん
B Presentation / Demonstration Vit Niennattrakulさん
B talk with demo Thomas Mitchellさん
C 鉄道会社がつくったAI企業 〜クラウド環境はFull AWSではありますがAWSのAIネタはありませんスペシャル〜 虻川 勝彦さん
C 機械学習における AWS を用いたマイクロサービスアーキテクチャ 中川 裕太さん
D EC2 T2インスタンスでつまづきやすいCPUクレジット〜EC2でチャットボット作って運用でハマって学んだ話〜 武田 可帆里さん
D モバイルアプリのバックエンドをEC2で運用している話 勝部 俊介さん
E Well-Architectedな組織を実現するためのチャレンジ　- なぜ、CA W-Aを作ろうと思ったのか – 柘植 翔太さん
F Community Friendship Showcase「うちのコミュがすみません！」 チャラ電Mitzさん(司会)とCommunity Friendshipな人たち
G RDBリファクタリングと異種間DB移行の戦い – Amazon DMSを使った止めずにリファクタリングする手法 曽根 壮大さん
H エッジコンピューティングと機械学習の効果と考慮点 榎並 利晃さん
H SORACOM LTE-M ボタン powered by AWSの活用100連発 片山 暁雄さん
I クラウドからオンプレを管理する！ AWS の Management Tools を使ったハイブリッドアーキテクチャ 大村 幸敬さん
K CircleCI Orbsを使ってAWSへ簡単デプロイ Kim, Hirokuniさん
K ヤプリの完全にモダンとは言いづらいけど、そこそこ攻めてるインフラ環境をもっと良くしたいエンジニアを募集しています。 羽渕 元紀さん
K KDDIにおけるAWS×アジャイル開発 須田 一也さん
松本 健太郎さん

12:15〜12:30

トラック タイトル 発表者
A AWS で作る AI 研究開発のための基盤サービス 山口 陽平さん
B サーバーレスでセキュリティ監視 井原 康博さん
C 情シスでモバイルと機械学習で働き方改革を推進している若手の話 勝部 俊介さん
D AIに興味あるエンジニア集まれー 大田黒 紘之さん
E コンテナベースな次世代型 WAF でよりスマートかつ効果的なセキュリティ対策を施そう 近藤 学さん
F JAWS-UG on ASCIIでどんな記事が読まれてるか気にならない？ 大谷 イビサさん
G 実践！CloudFormation Best Practice ~CloudFormationで始める組織改革~ 村本 雄太さん
H “Spotinst”でEC2をもっと安く、コンテナ運用をより効率的に！ 宮野 真冬さん
I メディア向けデータストアサービスをリリースして直面したツラミ 〜X-Tech後日談〜 村田 靖拓さん

12:30〜12:45

トラック タイトル 発表者
A アールスリーのご紹介 沖 安隆さん
B 顧客が本当に必要だったもの -CIer前日譚- 石田 知也さん
C AWS WAFのマネージドルールって、結局どれを選べばいいの？AWS WAFのことならCSC！ 渡辺 洋司さん
D あらゆるデータを分析・可視化!明日から始められるSumo Logic 加藤 諒さん
E Kinesis→Redshift連携を、KCLからFirehoseに切り替えたお話 佐野 玄さん
F AWSからメール送るならSendGrid一択ですよね 中井 勘介さん
G エウレカのデータミッション kaneshinさん
H Terraformを活用した自社SaaS展開事例について 横井 公紀さん
I 技術力を上げたい！どうやって？ というか技術力って一体何なんだっけ？ – ハートビーツの場合 馬場 俊彰さん
K EC2、コンテナ（EKS、ECR、ECS）、サーバーレス、全員集合！AWSのセキュリティはトレンドマイクロにお任せあれ！ 姜 貴日さん

12:45〜13:00

トラック タイトル 発表者
A Sansanという会社がどのようにAWSと向き合っているのか 間瀬 哲也さん
B ○○さんに似てますよね？ （またか……） 古寺 克行さん
C (Un)Managed Blockchain 高橋 慎一さん
D Amazon DocumentDB（with MongoDB Compatibility）入門 菊池 修治さん
E AWSマネージドサービスをフル活用して医療系システムを構築・運用するためのノウハウ 田中 清さん
F DruvaのEC2、IaaS/PaaS/SaaS データ保護ソリューション 三輪 賢一さん
G クラウド時代のモニタリングといえばDatadogだよね 池山 邦彦さん
H セキュリティ・テストの自動化によるDevSecOpsの実現（デモ有） 伊藤 俊廷さん
I DeepLearningの本番環境にSagemakerを利用してる話 Yoshiaki Otaさん

13:10～14:00

トラック タイトル 発表者
A IoT野郎が語り合う、IoTの今と未来、そしてエコシステム 榎並 利晃さん
片山 暁雄さん
松下 享平さん
辻 一郎さん
B AI/MLシステムにおけるビッグデータとの付き合い方 鈴木 翔太さん
B DevOps On AWS Changhoon Hyunさん
C Welcome to AUSG! (Why University Students is important in AWS Community) Jaehui Kimさん
D 至高の CI/CD パイプラインを実現する5つの約束 ポジティブな Toriさん
D なぜパイプラインが神なのか 小西 宏樹さん
E レガシー化したアプリケーションをAWSを使って3ヶ月で刷新した話 井上 心太さん
E 金融APIでAWSを使う上での利点と欠点 佐藤 維人さん
F 非エンジニアの皆様に贈るAlexaスキル開発ができるようになるまでのリアルな道のり 河本 貴史さん
F 視覚障害学生のチームによるAlexaスキル開発―スマートスピーカーでワクワクしよう― 筑波技術大学Alexa開発チーム
G ハイブリッドクラウド構成ガイド〜 2019年の今ならこう作る 菊池 之裕さん
G オンプレと密に連携が必要な Wi-Fiシステムを クラウドに移行するのは大変だった話 加藤 孝司さん
H GitHub Actionsを使って、ワークフローもプルリクベースで開発しよう！ 池田 尚史さん
I サービスダウンから生まれたSWATチームが手掛けるクラウド移行への道 辰巳 琢弥さん
関藤 寛喜さん
J 講師と対戦 亀田 治伸さん
K Veeam Backup & Replication + AWSで簡単バックアップ、リストアことはじめ 飯尾 旭さん
K 旅行会社のSEがAWSを使って内製化をはじめてみた 磯野 敬汰さん
K 「仮想通貨交換取引所 × AWS」私達と一緒に働きませんか？どうやってAWSを使っているのか話します！ 吉田 裕貴さん

14:10～15:00

トラック タイトル 発表者
A 創業から10年で4,000名規模となったオンプレ製品の会社における、クラウド活用とビジネスの変化 島崎 聡史さん
B 三題噺「F-Secure 基幹システムは Serverless ！あと IoTセキュリティとAWSセキュリティ」 河野 真一郎さん
C 運用自動化支援するクラウドサービス「SIOS Coati」をサーバレスアークテクチャで全部作り直して、本当に良かった話 吉岡 大介さん
D AWSのサーバ管理でsshを使わない管理手段を実現しよう 岸上 健太郎さん
E EC2からKubernetesへの移行をセキュリティから考える 杉浦 英史さん
E freeeにおける Kubernetes監視基盤 河村 篤志さん
F コンタクトセンター業界 波乱注意報！ Amazon Connect の本気を見逃せない 丸山 麻衣子さん
G AWS Transit Gateway を使った新しいセキュリティ手法を試してみた 伊藤 悠紀夫さん
H 【AWSセキュリティ入門】徒然なるままに責任共有モデルの下から上までそこはかとなく解説 大竹 孝昌さん
I 自社基盤で運用していた事業用サービスをAWS Fargate/Lambda等を活用しAWS上で再構築！苦労話もあるよ。 平山 智史さん
東川 寿充さん
K あなたが使っているWi-FiとAWSとの深ーい関係 小松 直人さん
K CI/CD事例をご紹介！〜アプリエンジニアが輝けるAWS事業の魅力〜 棚田 美寿希さん
K 教えて！DI本部長 小松さん！ 小松 哲平さん

15:10～16:00

トラック タイトル 発表者
A AWS x JAMStack で構築・運用するサーバーレスなWeb Front 江藤 武司さん
A 見せてやろう…Serverlessの本当の力を…!! 照井 将士さん
B Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する 村主 壮悟さん
C エンジニアが正しく成長するための、脱昭和&平成ワークスタイル 沢渡 あまねさん
黒須 義一さん
山﨑 奈緒美さん
D EC2からECSへ移行を始めたお話 吉岡 隆行さん
D Kubernetes を使ってエンジニア組織の生産性を上げよう 坂井 学さん
E 商業空間や家庭などの設備がAIやIoTによって制御される未来に関係する技術 Takahiro nakahataさん
F ukkaが取り組む一次産業の課題 〜 日本一遅い農産物の通販 OWNERS をAWSで実現している話 小林 俊仁さん
植本 裕紀さん
F アニメ・漫画 企業でITを活用してオタク業界の未来を変える取り組み　(Anitech) 野田 純一さん
G SaaSを海外展開するために役立つインフラTips 友田 敬人さん
H PenTesterが知っている危ないAWS環境の共通点 ~攻撃者視点よりお届けする狙われやすいAWSの穴~ 洲崎 俊さん
一ノ瀬 太樹さん
北原 憲さん
I 数十億レコードのRDS MySQL5.6を1週間程でAurora MySQL5.7へ移行した時の話 金井 栄喜さん
I 医療ビッグデータをAWSとオンプレ基幹システムで共存運用 小森谷 一生さん
J SORACOM LTE-M Button powered by AWSハンズオン 松下 享平さん
辻 一郎さん
K AWSの運用最適化のためにNHN テコラスがお客様に提案していること 瀧川 真之さん
K JAWS-UGとAWSJの歩み 沼口 繁さん
K AWSへのシステム移行に伴うクラウドマインドへの移行 山下 光洋さん

16:10～17:00

トラック タイトル 発表者
A Kubernetes on AWS/EKSベストプラクティス Yusuke Kuokaさん
B AWS All Stars 浅野 佑貴さん
福井 厚さん
深森 広英さん
関山 宜孝さん
三上 卓也さん
中武 優樹さん
大井 友三さん
菊池 之裕さん
清水 毅さん
高山 博史さん
園田 修平さん
畑 史彦さん
塚越 啓介さん
篠原 英治さん
C Alexaスキルのグロースハック 伊藤 清香さん
C 「Alexaスキルを安心・安全に開発運用するためのAWS自動化ソリューション」 清野 剛史さん
D AWS CLIではじめるコマンドラインライフ 〜 正しい「運用自動化」への第一歩 波田野 裕一さん
E 我々はこうして「AWS本」を書いた！ 〜十人十色〜 大串 肇さん
湊川 あいさん
長村 ひろさん
村主 壮悟さん
mochikoAsTechさん
野田 純一さん
吉江 瞬さん
佐々木 拓郎さん
馬勝 淳史さん
minamoさん
takipone(大瀧隆太)さん
F Build and Scale SaaS product by Serverless technologies. Okamoto Hidetakaさん
F Node.jsでのAWSサーバレスアプリプログラミングを簡単にする技術の研究紹介 木村 功作さん
G いま忙しいですか？AWS で Blockchain な事例を聞きたいですか？ 塚田 朗弘さん
城竹 公仁さん
Jeff Wentworthさん
H 「AWS提案ワークショップ」RFPを元にチームでディスカッションしよう！！発表もあるよ JAWS-UG Sales
I 働くことや学ぶことを見つめ直してみませんか？presented by クラウド女子会 多田 歩美さん
K KUSANAGI for AWSでWordPressを始めとしたCMSを簡単スタート！ 楠木 大三郎さん
K エンタープライズのオンプレWAFをAWSに移行したらこうなった話 小出 淳二さん
K ムシと戦うAI+IoTサービスをサーバレスで作った話 堂端 翔さん

PythonとSageMakerで始める MLチームのみで完結するAPIの構築事例

  • 武田 研恒さん

データ分析で求められること

  • 検証結果をAPI化して使ってもらうことでで価値が生まれる
  • API構築はスキルセットが違う
  • 本業に集中できずに生産性が落ちてしまう
  • => SageMaker

SageMaker

  • フルマネージドな機械学習サービス
    • 検証からAPI化までを高速化できる

特徴

  • 調査・分析
    • jupyter notebook
  • 開発・学習
  • デプロイ・運用
    • フルマネージド

アルゴリズム

得られた効果

  • MLチームだけでAPI構築完結
  • 検証用コードの改変自由度が高い
  • 過去に作成したエンドポイントへの切り替えが簡単
  • スケールアウトも勝手にやってくれる

メディアによるAI活用（時事クイズの生成と高校野球戦評記事の自動生成）

朝日新聞の研究開発

  • 編集業務の生産性向上
  • 自動見出し生成、自動要約、自動校正
  • 時事クイズ自動生成
  • 高校野球選評の自動生成

時事クイズ自動生成

  • 毎日の大量のニュース記事をもとに自動でクイズを生成

なぜ作った?

  • ニュースを読まない学生が多い
  • 時事ニュースに触れる機会を増やす
  • Qrich

技術革新のスピード

  • 重要語抽出
  • AWS Comprrehendは日本語未対応
  • 東大・横大のOSS「専門用語自動抽出システム」
  • 単語ベクトル
    • 類似度の近い言葉を検出できる
    • 人名地名などの固有名詞は考慮が必要
    • 答えがソフトバンクのときに選択肢で野球チームを候補にしてしまうとか

構成

  • フロントはGCP
    • FirebaseのGmailとかTwitter連携が便利だったから

高校野球選評の自動生成

  • 事実しか書かないものだと記者が書いたものと判別がつかないレベル
    • インタビューした内容とかは記者が書かないと入れられない
  • スコアブックが電子化されてそれをもとに記事を作ることができるようになった

構成

  • EC2一台だけ

今後

  • 2ランスクイズのような稀なパターンがない
  • 変化球を軸にといったようなスコアブックから読み取れない情報

まとめ

  • AIを活用して新しいことに挑戦
  • AWSを含めたインフラやツールは適材適所
  • AWSサービスの進化に期待

エッジコンピューティングと機械学習の効果と考慮点

機械学習を用いた異常検知

  • 製造業
  • 設備のアフターサポート
  • 劣化診断
  • 建設現場の予防保全
  • システム/ネットワークのサイレント障害検知
  • ITセキュリティ

事例

  • タービンに加速度センサーつけて予兆検知
    • データを全部クラウドにあげると量が多すぎる
    • => エッジコンピューティング
  • 食品の外観チェック
    • 画像処理と分類で異常検知

エッジコンピューティングのニーズ

  • IoTクラウドにつながるのは当たり前でどう使おうというフェーズになってきている

メリット

  • クラウドを使うことによるリソースの柔軟性
  • データを集めて共有できる
  • レイテンシの問題
    • 少しでも速く異常検知したい
    • エッジサイドで処理
  • クラウドに依存しない
    • 何かあっても継続するためにエッジコンピューティング
  • データ量の問題
    • 全部クルドに送ると多いのでエッジサイドでも処理

AWS IoT Greengrass

  • ハードウェア上でLambdaを動かせるようなイメージ
  • サーバにつながってなくても動かせる
  • セキュリティ面の機能

至高の CI/CD パイプラインを実現する5つの約束

  • ポジティブな Toriさん
  • 小西 宏樹さん

テーマ

パイプラインファースト

  • いきなりアプリ開発に着手しがち
  • CICDが後回しになって手作業になりがち
  • 理想は一発目のデプロイからパイプラインを通す
  • プロジェクトnewしてすぐでデプロイすること！
    • コンフィグの書き換えとかも初回デプロイの後
    • ブラウザでエラー出る状態でも構わない
    • 最初にパイプラインを通すことが大事
  • 最初からちゃんとしったパイプラインである必要はない

自動化されたパイプラインの維持

  • 要求の変化に応じてシステムも変化
    • 油断すると自動化できなくなる
    • 自動化が難しくなる変更を避ける
  • パイプラインをシンプルに保つ
    • アプリの都合をパイプラインに押し込まない

柔軟なパイプラインの維持

  • プロジェクト似合わせてパイプラインも変化が必要
    • 継続的な変化を受け入れられるようにシンプルに
  • 変化
    • ビジネス要求の変化
    • ポリシーの変化
  • パイプラインもコード化してリポジトリ管理
    • 同じものを再現してそっちで試せる

パイプラインのUXを継続的に改善

  • パイプラインはチームに対して提供するサービス
    • 実行内容やどこで落ちたかなど誰が見てもわかるように
    • 処理時間の維持短縮
    • よくわからないパイプラインは使わなくなる
  • 過渡な作り込みは避ける

パイプラインが唯一のリリース手段

  • パイプラインを通さないデプロイは禁忌
    • 今回だけは手作業でを断固避ける
    • パイプラインを使わない人が出てきてしまう
  • パイプラインを通さない例外
    • ビジネスが危機的状況にある場合だけ

事例紹介

  • 技術
    • Microservices
    • Serverless
    • AWS
  • 運用
    • 機能開発スピード重視
    • 密結合なサービス群
    • チームごとに運用レベルまちまち

現場の課題

  • 無停止デプロイ困難
  • デプロイ時間かかる
  • 人的オペレーションによるミス
  • その場対応の積み重ね
  • 職人が生まれ他の人がやるとまた見する

失敗から学んだこと

  • ビジネス要求は絶えず変化する
  • 一つ疎かにすると大きな技術的負債となり得る
  • 多くの人が見える場で議論すること

ビジネス層に理解してもらうために

  • 常にビジネス層と議論
  • 簡単にYESと言わない
  • 見える化する

CloudNative

  • 疎結合
  • 回復性がいい
  • 管理されている
  • 可観測である
  • 堅牢な自動化
  • 大きな変更を最小限の労力で

EC2からKubernetesへの移行をセキュリティ/モニタリングから考える

  • 杉浦 英史さん
  • 河村 篤志さん

freee

  • クラウド会計ソフト
  • 金融機関と連携
  • 機密な情報を扱っている

なぜマイクロサービス化?

  • アプリが大きすぎる
    • 開発者100人以上
    • 一日2回しかデプロイできない

AWSでk8sクラスタ

  • kube-aws
    • ECSはWorkerノードまで
    • Fargateとの違い
      • プロダクション向けの機能が豊富
    • k8s自分でやらないといけない設定が多い
  • EKS
  • kubectlの嵐つらい
    • eksctl

監視

  • なぜ監視
    • 予防保守
      • 近い将来起こりうる問題をすくい上げる
    • 異常検知
      • サービスの継続に係る障害をすぐに検知
    • 改善指標
      • なにか新しい施策をしてもmetricsがとれていないと効果がわからない

監視システム

  • データ収集
  • ストレージ
  • 可視化
  • 分析
  • アラート

k8sでの監視

  • 監視対象
  • 多様性
    • padが大量かつ多様
    • 個別設定入れていくのは無理
  • 自動スケール
    • ノードもpodも自動スケール
    • 監視システムも自動で追従しないと

ElasticStack

  • Elasticsearch
  • kibana
  • Logstash
  • Elastic Beats

商業空間や家庭などの設備がAIやIoTによって制御される未来に関係する技術

  • Takahiro nakahataさん

設備

  • 設備にはとてもお金がかかる
  • 日々莫大な金額が動いている

新しい技術

  • すでに大きなお金が動いてるビジネス
  • これから大きなお金が動くビジネス
  • これらをつなげる

設備の変化

照明

  • 「明るくする」ことと「伝えること」の2つの役割がある
  • デジタル化されたことで2つを同時に実現できるようになった
  • 例えば
    • 駅のホームで空いている車両がどこか照明で伝える
    • イベントで混雑する中出口がどこか照明で伝える
  • 設備が新たな意味と価値を持ち始めた

Society5.0

  • Society4.0 => 情報化社会
  • Society5.0はその次の時代
    • サイバー空間とフィジカル空間の高度な融合
    • 経済発展と社会課題の解決を両立する
    • 成功の鍵は設備を制御すること

ITと設備をつなげる

  • どうやってつなげる?
  • 既存の設備でつながる?
    • つながらない
    • 改修のタイミングで対応することになる

まとめ

  • 設備をつなげてビジネスにつなげよう
  • 時代がそうなってきた

Build and Scale SaaS product by Serverless technologies.

  • Okamoto Hidetakaさん

Serverlessのバックエンド

  • Auth: Congnito
  • API: API Gateway & Lambda
  • Batch: Lambda & Step Function
  • Front: React & Amplify
  • Netlify
  • Build & Deploy: CircleCI & Netlify
  • Payment: Shifter

なぜServerless/FaaSなのか

  • 巨人の方に乗る
  • 個人情報管理やランタイムの管理など責任を分散する
  • 使った分だけ課金

疎結合ですばやくtry & error

アウトプットの重要性

  • 半年前にやったことは覚えてない
  • どこかに記録しておく
  • できればオープンなところに
    • 間違ってたりもっとよくする方法を教えてくれることも

Node.jsでのAWSサーバレスアプリプログラミングを簡単にする技術の研究紹介

  • 木村 功作さん

JavaScriptの非同期処理

  • 古くはコールバック地獄
  • Promiseの登場
  • async/await
    • これで解決!?
  • まだ考えないといけないことはある

Escapin

  • 独自のライブラリ
  • 非同期処理をより簡潔に書ける

まとめ

  • もっと広く検証する必要あり
  • linterやコード補完も今後対応しないといけない

「PWA Night vol.1 ～PWAのミライや活用方法をみんなで考えよう～」に参加してきました

勉強会メモ
  • PWA Night vol.1 ～PWAのミライや活用方法をみんなで考えよう～に参加してきました。

pwanight.connpass.com

  • PWAだけにフォーカスした勉強会は今まであまりなかったのでとても楽しかったです。毎月開催ということで今後も期待しています。
  • PWAの良さはだいぶ広まってきましたが、TWAにするとアイコンにバッヂをつけられるなど更に便利なところもあるということでもっと深く調べてみたいなと思いました。
  • ネイティブ vs PWAの文脈で語られる場面が多かったですが、対立するものではなく選択肢が増えたということなんじゃないかと思うので、アプリの性質や戦略に応じて使いこなせていけるといいのかなと感じました。
タイトル 発表者
PWAの今とこれから 宍戸さん@Google
PWA はビジネス的に美味しいか？ 橋本さん@パラダイスウェア
リーンスタートアップとPWA～Webサービス立上げ時こそPWAを検討したい！～ 角谷さん@TAM
PWA×CMS活用アイデア 早瀬さん@シックス・アパート

PWAの今とこれから

PWAの効果

  • PWAにすると平均コンバージョン率+20%
    • 統計のデータ
  • スターバックス
    • ブラウザで注文して店舗で受け取る
    • payment request
    • add to home screen
    • デスクトップ版もワンソースで
  • Google Maps Go
    • アプリ版は機能が多くて重い

PWAの特徴

  • 高速な表示
  • 信頼性
  • エンゲージメント性

高速な表示

  • 53%の人は表示3秒遅れると離脱
  • 79%はパフォーマンス悪いサイトに戻らない
  • 表示が1秒遅れるとコンバージョン率7%下がる

信頼性

  • ServiceWorker
    • ブラウザに対して一つ起動できる
    • リクエストをキャッシュしたり加工したり
  • Workbox
    • ServiceWorkerをラップするライブラリ
  • オフライン時はフォールバックページを返す
  • メジャーなブラウザではServiceWorkerは動作する

エンゲージメント性

  • ホームスクリーン追加
  • Androidだとホームに追加のバナーが勝手に出てしまう
    • beforeinstallPromptイベントを拾うことで制御できる
    • appinstalledイベントでインストール完了をひろえる
  • プッシュ通知
    • 通知がほしいと思える場面で許可プロンプト出すと良い
  • ログイン
    • 92%はID/パスワード思い出せないときに諦めてしまう
    • Credential Management API
    • Web Authentication API
  • 支払い
    • Payment Request API
    • ブラウザに記憶させた支払い情報を使ってフォームを統一

今後

  • モバイルのユーザ数がのびてる
    • デスクトップものびてる
  • デスクトップPWA
    • Cross Browser & Cross OS
  • PWAをGooglePlayで配信
    • WebViewではない
    • ChromeCustomTabsを使ってる
    • => TWA
  • TWA(Trusted Web Activities)
    • 開発者が保証されたWebページをAndroidのネイティブと同じように開くことができる
    • Wake Look
    • Badgingも使える

PWA はビジネス的に美味しいか？

  • 橋本さん@パラダイスウェア

PWAのイメージ

  • 従来のWeb -> PWA -> ネイティブアプリ
  • PWA = アプリ未満

PWAのイメージ

  • アプリよりも低工数(開発/運用)
  • 体制張りやすい
  • 後からアプリ化できる
  • 審査が必要ない
  • Google/Apple税も不要

B2B新規事業あるある

  • 課題
    • 要件定義に時間がかかるし仕様変更も多い
    • システム間連携にコスト
  • PWAを使うと
    • 早期に動くものが作れる
    • フロントとサーバを分離しやすい
  • プロトタイプ例
    • Vue + Firebase + twilio(SMSでiOSの通知の代替)

リーンスタートアップとPWA～Webサービス立上げ時こそPWAを検討したい！～

  • 角谷さん@TAM

不確実性の高い世の中

リーンスタートアップ

  • MVPを作る
    • 最低限実用に足る製品を作って成長させていく
  • MVPの種類
  • iOS/Androidアプリで完全版をいきなり作るのではなくPWAで小さく成長させていく

ネイティブあるある

  • 最初だけでなく全てがダブルコスト
  • ちょっとしたことで予算がなくなる
  • 審査があるからスピード感落ちる

PWA×CMS活用アイデア

PWAのメリット

  • 読み込み速い
  • オフラインで動く
  • インストール不要
  • プッシュ通知

PWAの要件

PWAの普及

  • PWAが思ったより普及してない理由
  • iOSの対応が充実すればとても便利になる

PWAを作るサービス

movabletype.net

「Chrome Tech Talk Night #12 ~ #perfmatters」に参加してきました

勉強会メモ
  • Chrome Tech Talk Night #12 ~ #perfmattersに参加してきました。

events.withgoogle.com

タイトル 発表者
Introduction to Performance APIs Shogo Sensui (@1000ch), Merpay, Inc.
Start Performance Budget Shunya Shishido (@sisidovski), Google
Tools for Performance Budgeting Katie Hempenius (@katiehempenius), Google

Introduction to Performance APIs

  • Shogo Sensui (@1000ch), Merpay, Inc.

Lazy Loading

Intersection Observer

  • viewport内に入ってるかどうか検知できる
    • 検知してから(必要になった時点で)読み込む
  • Webkitにも入った(safari!)

Intersection Observer v2

  • 表示されてるかどうかまでチェックできる

Browser native lazy-loading

  • ブラウザの機能ででlazy load
  • lazyload=onという属性
    • imgとかiframeにつけられる

Prefetch

Priority Hints

  • 並列で通信処理するときの優先度の指定
  • importance属性でつける
  • fetchのオプションでもしていできる

Resource Hints

  • ブラウザが暇してるときに読み込んでおく
    • ページを読み込み終わった後の次になにするかにフォーカスしてる機能
  • DNS Prefetch
  • Preconnect
  • Prefetch
    • quicklink
      • viewportに入ったaタグのリンク先を自動でprefetch
      • ネットワーク状況なんかも見てくれる
    • nuxt v2.4はquicklinkに影響を受けて同じような機能を入れてる
  • Prerender
    • chromeは内部で勝手にやってる

Preload

  • リソースからリソースを読み込むことが多くなってる
  • 順番待ちしないように先に読み込ませるようにする

Web Packaging

  • Signed HTTP Exchanges
    • AMPのURLがgoogleになってしまう問題を解決できる
  • Bundled HTTP Exchanges
  • Loading Signed Exchanges

Off The Main Thread

  • 最近のWebは重くなってきてる

Main Thread is busy

  • Loading
    • HTMLとってきて
    • HTMLパースして
    • CSSとってきて
    • CSSパースして
    • Eval heavy JavaScript
    • .....
  • Runtime

Performance metrics are changing

  • サーバサイドだけでなくクライアントサイドの指標も見るようになってきた

DOM manipulation is heavy

  • Virtual DOM
    • 最小限のdiff patch
  • Virtual DOMのdiffアルゴリズム重い
  • Split DOM manipulation
    • React Suspense
    • use requestIdleCallback
    • workerでDOMを処理とか

Off The Main Thread(inner browser)

  • ブラウザの中の処理をメインスレッド使わないように
    • V8の中でやってたり
  • Worklet

Off The Main Thread(web page land)

postMessageが使いづらい

Start Performance Budget

  • Shunya Shishido (@sisidovski), Google

Speed equals Revenue

  • スピードは収益につながる
  • モバイルブラウザだと顕著

Performance Budgetの事例

Pinterest

  • Budget
    • < 200kb JS
  • 結果
    • 44% Revenue

Tinder

  • Budget
    • < 160kb JS
    • <50kb lazy loaded JS
  • 結果
    • TTI = 6s(3G)

なぜパフォーマンスは悪化するか

  • Webはモバイルにおいては遅くなっている
  • リソースのサイズが大きくなってきている
  • チームにパフォーマンス改善の経験がない
  • 仕組みで解決せずに一時的な解決策になっている
  • 継続的なモニタリングをしていない
  • 変化に対する抵抗感

ビジネスとパフォーマンスのバランス

  • 会話の土台としてPerformance Budget
  • 開発者だけでなく周りを巻き込んでいかないといけない
  • 技術でなくビジネス上の課題を解決することを考える

Introducing Performance Budget

  • パフォーマンスの要件の閾値
  • Budgetの範囲内でよいUXを提供していく

Performance Budgetのメトリクス

Budgetの計算の仕方

  • サイトの特性によって変わってくる
  • 2つの方向性で考えると良い
    • Budgets
    • Goals

Budgets

  • いきなりゴールを目指すのは難しいので現実的な値を設定する
  • Budgetに収まった状態で改善を進められると良い

Goals

  • 最終的に目指したい値
    • 現状との比較
    • 競合との比較

20%ルール

  • 20%以上差があると違いを認知できる
  • 競合と比較して20%差をつけられると利用者にも認知してもらえる

ネットワーク

  • 日本では90%が4Gで10%が3Gというデータ
    • 日本向けなら4Gをターゲットとするとよい

3rdパーティスクリプト

  • 3rdパーティスクリプトのサイズも考慮する
    • それを含めてどれくらいのbudgetが残されているかを見る

Performance Budgetの運用

  • 開発に入る前の段階からパフォーマンスについて考えておくべき
  • Budgetが超過したらどうするか？
    • 既存機能を改善
    • 古い機能をを削る
    • 新しい機能を追加しない
  • 開発者だけでなくステークホルダーも含めて考える
  • モニタリングツールは必須
    • 定期的なメトリクスの取得
    • 競合との比較
    • 通知
    • SpeedCurveがいい
  • SpeedDemon
    • 無料なのがいい

Tools for Performance Budgeting

  • Katie Hempenius (@katiehempenius), Google

Understanding Performance Budget toolts

  • Performance Budget = Performance Goals
  • 計測 + CI and/or 通知

Lab Data vs Field Data

  • Lab Data
    • simulated users
    • 例えばlighthouse
    • 開発中に見える
  • Field Data
    • actial users
    • 例えばGoogleAnalytics
    • リリース後に見える

Timing metrics

  • Timing metricsは分散しがち
    • maxとかmedianとか見ていく

Resource based metrics

  • devtoolsで見れる
    • request count
    • request size
  • js/css等どこがボトルネック化見れるといい
  • JavaScript is expensive
    • parse
    • compile
    • excute
  • 27%のサイトは90-99%が3rdパーティコンテンツ

Score based budget

  • 計測ツールを使う
    • lighthouse
    • WebPageTest
  • わかりやすい
  • budgetを設定しやすい

Using Performance Budget tools

bundlesize

webpack

  • hints: 'error'
  • maxEntryoiuntSizeの設定
  • maxAssetSizeの設定

Lighthouse

Google Analytics

PageSpeedd Insights(API & Website)

  • Lighthouse + Chrome User Experience
    • => Lab Data + Field Data
  • First Input Delay(FID)

「Developers Summit 2019(2日目)」に参加してきました

勉強会メモ

event.shoeisha.jp

codezine.jp

タイムテーブル

10:00～10:45

タイトル 発表者
ドラゴンクエストXを支える失敗事例 青山 公士[スクウェア・エニックス]
エンジニアの知的生産術 ビフォー・アフター 西尾泰和[サイボウズ・ラボ]
OSS活動のやりがいとそれから得たもの - PostgreSQLコミュニティにて - 澤田 雅彦[NTT]
プロダクトマネージャーという生き方 熊谷 亘太郎[楽天]
ソフトウェア開発の「今ココ」に適応するために― カイゼン・ジャーニーから見つかった新たなfunと前進への旅路 ― 資料1 資料2 市谷 聡啓 [ギルドワークス]
新井 剛 [ヴァル研究所・エナジャイル]

11:05～11:50

タイトル 発表者
IBM Q - 量子コンピューターの最前線 小野寺 民也[日本アイ・ビー・エム]
メンバーの成長とチャレンジのためにエンジニアリングマネージャーとして大切にしたこと 山本 学[ヤフー]
デベロッパーのためのAzureクラウドネイティブスタック 〜 提供したい価値からはじめる高速＋高可用＋高付加価値ソリューション 川崎 庸市[日本マイクロソフト]
デンソーのMaaS開発～アジャイル開発で顧客との協調・チームビルディング・実装概要～ 佐藤 義永[デンソー]
冨田 進[デンソー]
CI/CDを使い倒して数段上のソフトウェア開発をしよう！ 金 洋国[CircleCI]

12:10〜12:40

タイトル 発表社
モンスターストライクにおける負荷対策 ～エンジニアリングチームの挑戦～ 白川 裕介[ミクシィ]
【導入事例】Lychee Redmineのユーザが語る！トラブル予防としての使い方 稲垣 哲也[フューチャーアーキテクト]
機械学習システムのアーキテクチャ アラカルト ～ BrainPad における実例を交えて～ 太田 満久[ブレインパッド]
外食の「明るい未来」にむけたトレタの新たな取り組み 吉田 健吾[トレタ]
Entertainment x Tech～多くのアーティストとファンを繋ぐ技術と組織～ 山田 真一[エイベックス]

13:05～13:50

タイトル 発表者
3周年に突入するAbemaTVの挑戦と苦悩 山中 勇成（みゆっき）［サイバーエージェント］
エンジニアの皆さんに贈る最速キャリア戦略 松本 勇気 [DMM.com]
ゲームQAを支える技術～前処理・後処理は大変だが役に立つ～ 太田 健一郎[スクウェア・エニックス]
OSS開発スタイルを取り入れて、効率的な開発を！～InnerSourceのススメ～ 田中 裕一[GitHub]
中国・深センのテクノロジー最新事情 資料1 資料2 ちゃんとく[dotstudio]
寺尾 英作[SBクラウド]

14:10～14:55

タイトル 発表者
ゲーミフィケーションエバンジェリストが説く、アプリ開発で見落としがちな「おもてなし」とは～面白さを伝える × 面白く魅せる～ 仲 功児[ナノコネクト]
Site Reliability Engineering at Google 中井 悦司[グーグル・クラウド・ジャパン]
今からでも遅くない!?Azureで学ぶ実用Blockchain 廣瀬 一海（デプロイ王子）[日本マイクロソフト]
太田 寛[日本マイクロソフト]
これをまだ知らない Web エンジニアへ贈る - 私が愛する Elixir/Erlang の楽しさと辛さ - 幾田 雅仁 [gumi]
Less Code & Have Fun! IoTアプリ開発をはじめる際のポイント 山崎 亘[ウフル]
IBM Q 量子コンピューターハンズオン 小林 有里 [日本アイ・ビー・エム]

15:15～16:00

タイトル 発表者
プロダクトをGrowthさせるデータ駆動戦略の基礎知識～DMM.comにおけるユーザーレビュー基盤のKPIツリー公開～ 石垣 雅人[DMM.com]
サーバーレスで最高に楽しめるアプリ開発 江藤 武司[Riotz Works]
「仕事なんか楽しいはずないやん」に反発し「ええと思うなら、やったらよろしいやん」を胸に歩んできた話 中村 洋[ギルドワークス]
ことばだけでは足りません、描いてシェアして伝えていこう！ 高野 明子[Sider]
システムエンジニアは空を飛ぶ夢を見れるのか～普通のSEがドローン系SEになるまで～ 佐藤 明
Kubernetesを短時間で体験。IBM Kubernetesで遊んでみよう！ 斎藤 和史[日本アイ・ビー・エム]
今関 靖一郎[日本アイ・ビー・エム システムズ・エンジニアリング]

16:20～17:05

タイトル 発表者
Webサーバー利用だけではないNGINXソリューション 田辺 茂也[NGINX]
無意味なアラートからの脱却 〜 Datadogを使ってモダンなモニタリングを始めよう 〜 池山 邦彦[Datadog]
GKEとIstioで構築するクラウドネイティブ・アプリケーション - What, Why, Where and How to use Istio? 福田 潔[グーグル・クラウド・ジャパン]
タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング 森廣 隆行[リクルートテクノロジーズ]
セキュアな環境でDevOpsを実現する厳選ツール 根本 竜也[マクニカネットワークス]
上田 展生[セガゲームス]

17:25～18:45

タイトル 発表者
エンジニア人生と定年退職、人生100年時代のエンジニアの生き方 よしおかひろたか[東京大学大学院]
Webアプリのチューニングバトル「（社内）ISUCON」の魅力と楽しさ 資料1 資料2 資料3 櫛井 優介[LINE]
古川 陽介[リクルートテクノロジーズ]
南 直[Wantedly]
とにかく明るい！「Fun! Done! Learn!」でデブサミを振り返ってみましょう！ ヴァッサー ジャンバティスト[yamaneco]
安井 力
川口 恭伸[アギレルゴコンサルティング]
有野 雅士[アトラクタ]
エンジニア採用パネルディスカッション――困難きわまる人材確保、だが成功する方針・施策とは 【モデレーター】市古 明典[翔泳社]
小野 和俊[セゾン情報システムズ]
松尾 奈美[リクルートテクノロジーズ]
三木 明[Repro]
アウトプットのススメ　～技術同人誌・LT登壇・Podcast～ おやかた
ariaki
hekitter
mochikoAsTech
KANE
長村ひろ
erukiti
私たちはどんな課題を解決すべきなのか？ - 自然災害救援のために開発者ができること「Call for Code」 戸倉 彩[日本アイ・ビー・エム]
関 治之[コード・フォー・ジャパン]
小和田 香

デンソーのMaaS開発～アジャイル開発で顧客との協調・チームビルディング・実装概要～

アジャイルチーム

  • 2年前にアジャイルチーム発足
  • 今では6チーム
  • プロジェクトが終わったら解散ではなくチームに対してプロジェクトをアサインしている

mobi-Crews

  • 採用技術
    • Beanstalk
    • Terraform
    • Docker
    • Rails
    • CircleCI

開発の立ち上げ

開発の進め方

  • 次スプリントのバックログにready/not readyの印をつけておく
  • カンバンの一番上は改善タスク
    • 改善することでその後の作業が効率化されるはずなので一番先に
  • プランニング
    • 速くて2時間長いと3,4時間
    • スプリントのサイクルは1週間
  • スプリントレビュー前日の午後は開発チーム内でレビュー
  • 動くものを見せることが大事
    • 出来てないからドキュメントでデモとかやりだすとダメ
    • 全部出来てなくても見せる
  • メンバの追加はせずにスコープ調整が理想
    • そうもいかないことが多い
    • 複数チームにして拡大
    • POは個別に割当

インフラ

  • コード化する
    • Terraformを採用
  • 横展開可能なテンプレート化
  • 極力マネージドサービスを使って負担をへらす
    • Beanstalkを採用

リリースが近づいて

  • 課題
    • 監視
      • 必要なメトリクス洗い出して横展開
    • 性能
      • 性能評価環境を要しし定期的に測定
    • セキュリティ
      • 外部機関と連携して評価
  • プロジェクト横断のチームを結成
    • SREチーム

3周年に突入するAbemaTVの挑戦と苦悩

AbemaTV

  • 特徴
    • 無料
    • 会員登録なし
    • 24時間
  • 2015/10 開発開始
  • 2016/3 仮開局

プロジェクト横断のチームを結成

  • 開発メンバー
    • 当初14人 -> 今90人超
  • Web/iOS/Android/新デバイス/Streaming Client
  • プロジェクト管理
    • クライアントは2週間のスプリントで開発リリース
  • 勤務体制
    • 週一リモート推奨

アプリケーション

GCP

  • 高機能L7ロードバランサ
  • GKE/K8s
  • ネットワーク帯域に対するコストの安さ
  • ログ収集サービスの充実

言語

  • CAのバックエンドはではJava -> Node -> Go
  • Goを採用

アーキテクチャ

  • Microservices
    • 約80サービス
    • コンテナ化でリソース有効活用
    • サービス間通信はgRPC
    • Gateway Pattern

  • Go + Microservicesの課題

    • パッケージ管理
    • Goのバージョン管理
    • 共通ロジックどこにまとめるか

      データベース

  • MongoDB

  • シャーディングによる分散とレプリカセットで冗長化
  • コネクションプール管理

キャッシュ

  • In-Memory
  • Redis
    • 開発当初GCPでマネージドなものがなかったから
    • セッション管理
    • ロック目的
    • ネットワーク負荷軽減

構成管理

  • Terraform
    • インフラ構築を自動化
  • Packer
    • マシンイメージの作成起動

ネットワーク

クライアント/サーバ間通信

  • gRPCも検討したが
    • 当時http2での通信に対応してなかった
  • 通信フォーマットはProtocol Buffers

CDN

  • Akamai Media Delivery
    • 映像配信に特化したものが少なかった
  • Cloud CDN

開発支援

CI/CD

  • Codeship
    • バックエンドのテストやイメージの作成
  • Deploykun
    • 内製のchatopsツール

モニタリング

監視

  • bugsnag
  • Google Cloud Monitoring
    • GCE/GKEの挙動監視
  • Slack連携
  • PagerDuty
    • インシデント管理ソリューション
    • SREチームで1次対応

ログ

  • アプリログ
    • Goの標準出力にJSONで出力
    • GKEのfluentdで収集
    • StackDriver Loggingで表示
  • アクセスログ
    • 当初はfluentd
      • Goとの相性
    • CloudPubSubとBigQueryへ変更
      • Streaming Insterterの運用管理
      • BigQueryのStreaming Insertのキャパシティ
    • => 今はCloud Dataflow + Apache Avroへ変更

メトリクス

  • Redis/MongoDBはStackdriver
  • 各アプリはPrometheus + Grafana

今後

  • サービス規模の拡大
  • さらなる安定化の追求
  • 既存システムの老朽化対応

目指すアーキテクチャ

  • 配信レイヤーの全二重化
    • サーバや回線等ユーザの直前まで全て
  • チャンネル別リソース
    • RedisやMongoDB等のリソースをチャンネルごとに分ける
  • 実績と予測に基づいたオートスケール
    • 過去実績や時間帯をもとにオートスケールさせたい

Site Reliability Engineering at Google

Googleについて

  • 担当していないサービスでも全てのコードを見ることができる
  • 目指すところ
    • 世界中の情報を整理し世界中の人ボトがアクセスできて使えるようにする
  • 世界中専用回線でつながってる
  • 世界中のデータセンターに巨大なk8sクラスタっぽいものがある
    • 標準化されていてどこも同じ
  • ミドルウェアのレイヤも標準化されている
  • GCPは社内で使われていたものをオープンにしたもの
  • プロジェクト外のソフトウェアもコード修正・改善案を自由に出せる

SRE

  • リリースしたサービスをいかに安定して運用し続けるか
  • システムを運用するだけでなく安定運用するために必要なソフトウェア開発をあわせて行うチーム
    • => Site Reliability Engineering

50%ルール

  • 50%以上をシステム安定に関わるプロジェクト活動にあてる
  • 障害対応等々は50%以下にする
  • 障害が多い/マニュアル作業が多すぎて50%ルールが厳しくなるシステム
    • 開発側に突き返す
    • システムを改善する

SREが見る範囲

  • 運用範囲
  • 運用範囲外
    • 小規模で重要度が低いアプリ
    • 安定運用できてるシステム

SREの活動原則

SLO

  • 何を持って「安定」というか
  • Service Level Objective
  • システムの安定稼働の目標値
  • エラーバジェット
    • エラーバジェット = 1.0 - SLO
    • 消費状況をモニタリング
    • エラーバジェットがなくなりそうになったら新機能の開発はストップして改善に注力

Toil

  • 労力のかかる作業の削減

Postmortem

  • 障害対応が終わった後の文書
    • 発生要因
    • 反省点
    • 改善点
  • 個人を非難する内容は絶対に書かない
  • 障害報告ではなく未来につなげるための知見とする

プロダクトをGrowthさせるデータ駆動戦略の基礎知識～DMM.comにおけるユーザーレビュー基盤のKPIツリー公開～

データ駆動戦略とは?

  • データドリブンで戦略を組み立てる
  • 不確実性につい良い組織にする

なぜデータ駆動戦略?

  • 直感に頼るとプロダクトバックログが肥大化し開発者を圧迫する
  • データがないとなぜうまくいった/いかなかったが分からない

データ駆動戦略のなにがいいか?

  • プロダクトの状態を可視化できる
  • 意思決定を高速化できる
  • 意思決定を定量的に共有できる
  • 未来を予測して戦略を作れる

どうやってデータ駆動戦略?

DMM.comのデータ駆動戦略

  • SoEとSoRな領域がある
  • 40種類以上のサービス
  • ドメインごとにスクラムチーム
  • データアナリストがPOを支える

データ分析基盤

  • データを提示できないといけない
    • 分析しやすいデータ分析基盤が必要

優れた指標

  • データが駆動する
    • データを見ることで次の行動につながること
  • 3つの土台
    • 比較できる
    • わかりやすい
    • 比率や割合である
  • 4つの指標
    • 定量的指標と定性的指標
      • 主観的/科学的数値
    • 虚栄の指標と本物の指標
      • 次の行動につながる/つながらない
    • 先行指標と遅行指標
      • 未来の予測/変動後の数値
    • 相関指標と因果指標
      • AとBが関係/Aが起こるとBが起こる
      • 因果関係を探すために相関関係のある数値をを観察

開発プロセス

最後に

タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング

背景

  • 入稿システムはリボンモデルの根幹の部分
  • ディフェンシブで既存システムに手を加えるのではなく新規で作ることが多い
  • 急激な性能劣化
  • リプレイスでは時間がかかりすぎる

性能改善

  • 過去の技術的負債を分析し改善
    • 泥臭い作業で改善を重ねた
  • 品質の担保
    • 本番データと突き合わせて確認
    • オフショア使って力技で

まとめ

  • リビルドリプレイスに頼らなくても効果は出せる
  • システム単体で最適だったとしても経年劣化を考えるとそうでない

Webアプリのチューニングバトル「（社内）ISUCON」の魅力と楽しさ

ISCONの誕生

  • 2011年の夏
  • tagomorisさんが発起人
    • 「言い訳できない環境で1番を決めたい」
  • 当時のライブドア

名前の由来

  • 当初lpc
  • パフォーマンス遅いと椅子投げるといっていた
    • ISU
  • Iikanjini Speed Up Contest

概要

  • 制限時間8時間
  • 与えられたWebアプリを高速化する

今年のISUCON

R-ISUCON

なぜR-ISUCONはじめたか

  • ISUCONで勝てない..
  • 過去出題している人たちが強い
  • やってみると方向性が変わってきた

本家ISUCONとの違い

  • 本家は出題する会社がそれぞれお題を出す
    • 会社の特色が出る
  • リクルートなりの問題を作った
    • 本家はバックエンドの要素が多いがフロントエンドの要素も入れた
      • CSS/JSをあえて重くしたり
    • 社内で実際に起きたり困ってたりすることをお題に
  • 本家は8時間だけどR-ISUCONは合宿で1泊2日
  • 教育的な側面も強いが障害振り返り的な側面も強い

これまでの振り返り

スピードハッカソン

  • 仮想サービスでなく本物のサービスでISUCONする
  • 実際のサービスでの制約を度外視して試せる

PIGICON

IMOCON

その後

  • みんなに学んでほしいことをコンテキスト形式にする流れができた
  • 実際のアプリにも効果が出せた

新卒研修でISUCON

  • Wantedlyで新卒研修でISUCONした
  • パフォーマンス改善は学ぶのが難しいし実践できる機会が少ない
    • ISUCONで体験してもらう
  • 幅広い技術にふれてほしい
    • 高速化にはあらゆるスキルが必要

新卒ISUCONの運営

  • 問題と環境があればできる
  • 問題
    • Webアプリとベンチマーカー
  • 環境
    • アプリを動かす環境
    • スコアボード
    • 場所

今後

  • 企業横断での新卒ISUCONとかできると面白うそう