「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!
  • ゴールは遠ざかってる
    • それを近づける方法は楽しくすること