サイバーエージェント社のこちらのイベントに絶対ブログ書く人類枠で参加してしまったので書き起こしたりしておきます（各スピーカー資料、FRESH!をご覧ください）
誰?
- 主にRails,Djangoアプリのサーバーサイドを書くフリーランスエンジニア
- フロントエンド関連ではWebpack,React/Redux,Vue/Vuex,Netlifyなどの導入
- Gitベースの翻訳ワークフローであるGitLocalizeの開発に参加している
- Vue.js, Nuxt.js, WebFundamentalsなどのドキュメント多言語化で導入されている
本編
FRESH!動画配信アーカイブ
『新R25本創刊までの1年』
- FRESH! 16:00
- スライド：新R25本創刊までの1年
- 株式会社新R25 母良田さん
新R25とは
20代の若手ビジネスマンをターゲットに、彼らにとって有益な世の中のトレンドを解説するWebメディア
CSS変数管理
- デザイナと話し合い色やサイズをSketchに起こしてもらう
- 不要な色が増えたりしないようSketchで管理
- cssnext
- 変数一元管理により品質担保できる
- Atomic Design と相性がよい
Atomic Design
- Atoms > Molecules > Organisms > Templates > Pages
- 粒度の定義が難しく、議論・実装で時間を使う
- どれがatoms?molecules?organisms?
- どれをコンポーネント化すべきか？
- ルールをしっかり決める
- 必ずatomsから作る
- atomsが含まれたらmolecules, moleculesが含まれたらorganisms
- 表示の分岐や複雑な処理が多いものは、使い回しがないもの、特定のページでしか使わなくてもコンポーネント化する
- containerが汚れていくのを防ぐため
SSR+SPA
- SSRの課題
- fluxで、store->serverのデータ渡しでRxJSを使っている
-
Rx.Observable.zip- dispatcherに集まってきたデータを
Promise.allっぽく同期させてからSSR -
renderToStringの課題- API responseも全部レンダリングするのでHTMLが大きくなってしまう(1MB超)
- SSRでどこまで表示するか
- SEO,SNSシェア周りに影響が出ないレベルでデータをコンパクトにする
- dispatcherに集まってきたデータを
- SPAの課題
- 画面遷移の表示位置(scroll position)のタイミング制御
-
window.scrollTopは、ブラウザの進む、戻るが入ると複雑化する - 前ページのデータや表示位置をどう保持するか
-
history.scrollRestorationではうまくいかない -
history.replaceStateでhistory.stateにページごとの表示位置を保持して使い回す
-
- レスポンシブ対応
- atomsのコンポーネントごと、デバイスごとにcssファイルを分ける
- media queryで対応しきれない案件は、
window.matchMediaで対応できる - レスポンシブのコンポーネント一元管理との組み合わせ
今後
- AMP対応
- バリデーション、コンポーネント説明
-
amp-bind(setStateのようなもの)を使っていく
『Vue.js+Nuxt.jsでB2Cサービスを作った話』
-
FRESH! 36:16
-
by.S 事業部 若松さん
Lulucos(女性向けコスメレビューサイト)でのJSフレームワーク選定・開発についての話
by.Sとは
- 女性向けメディア
Vue.js + Nuxt.js
- Vue.js利用状況
- 社内はReactがおおい
- 選定プロセス
- サービス要件 認証、絞り込み検索、コメント投稿、レビュー投稿、レビュー結果ビジュアライズ
- ビジネス要求 SEO,表示速度、サイト設計
- 開発要求 開発しやすさ、安定性、運用性、新しい技術への挑戦
- 社内からの提案: Vue.js + Nuxt.js
- ポジティブ要因
- Vue.jsのパフォーマンス
- Nuxt.jsは公式推奨
- SSR+SPAの実現しやすさ
- 充実した日本語ドキュメント
- ネガティブ要因と、選定時の見通し
- Nuxt.jsはrc -> 正式版が出るのは時間の問題
- 拡張性 -> Nuxt.jsをExpressミドルウェアとして使えばだいたいのことはできる
- 中・大規模B2Cでの開発実績 -> 機運は高まっている
- Vue.jsのバックボーンは企業ではない -> 寄付もあるし優秀なOSSエンジニアもいるので大丈夫では？
- ポジティブ要因
採用してよかったこと
- ルーティングがはかどる
- ディレクトリ構成がそのままサイトパスになる
- 複雑な仕様を実現できるか一見不安だが、動的ルーティングもちゃんと対応できる
- 誰が書いても同じようなルーティングになる
- 構成を強制されるが、最低限の機能があるので違和感はない
- urlでtriggerされる処理
- Expressのエントリポイントでリクエスト処理すればできないことはない
- ディレクトリ構成がそのままサイトパスになる
- 拡張性
- Expressミドルウェア
- nuxt-community/express-templateなどを転用
- Redisなども簡単に利用できる
- ビルドが意外にいい感じ
- 共通js・ページ別jsへのファイル分割、prefetchの恩恵
- パフォーマンスが高く、競合サービスを圧倒
-
vue-devtoolsでのデバッグ - document
- ただ、nuxt.jsの日本語ドキュメントは英語に追いついていない
###採用して困ったこと
- ライフサイクルの罠: vue.jsとnuxt.jsのライフサイクルを両方考える必要
- クライアントサイドオブジェクト
window、サーバーサイドオブジェクトcontext.req.urlなどへのアクセスに注意 -
beforeCreate,createdなどはサーバーでもクライアントでも実行される -
process.serverによるサーバー・クライアント判定
- クライアントサイドオブジェクト
- ライブラリの新陳代謝が激しい
- nuxt.jsのupdate時でwarning ->
vue-apolloのupdate -> 大量のコード修正... - こまめなアップデートが、リリース直前などではまらないために重要
- nuxt.jsのupdate時でwarning ->
- hot reloadingが時間かかる
- 無駄なコンポーネントを削るなどの対応
結局どうだったか
- SSR+SPAを低コストで実現できた
『歴史ある巨大システム アメブロに配属された新卒トーク』
- FRESH! 1:01:00
- スライド: 歴史ある巨大システム アメブロに配属された新卒トーク / Ameblo rookies talk
- アメーバブログ新卒 上西さん、柳さん
入社前のフロントエンド経験
- 上西さん
- 大学の演習の運営などでWebアプリケーション運用
- 柳さん
- EC-CUBE運用(Smarty,jQuery)
- C2Cサービス運用(CakePHP,SSR+SPA)
フロントエンド刷新の効果
- 13年続いたフロントエンドが、1年前に刷新された
- 新参者がとっかかりやすくなった
- 環境構築
- 以前はcss,font,image,jsを別リポジトリ管理し両方ビルド・デプロイしていた
- yarnするだけでwebpackでbuild
- 適度な粒度のコンポーネント化
- Atomic Designでの粒度設計は、アメブロではどうなったか
- templates切り替えでページ遷移を表現
- 編集するファイルが分かりやすい
- Reactコンポーネント設計に対応
- Redux関連の問題はorganismsの層でしか起きない
- Reactコンポーネント設計に対応
- componentごとのCSS管理
- CSS Modulesをつかうので影響範囲がわかりやすい
- Atomic Designでの粒度設計は、アメブロではどうなったか
- 大規模でスピード感のある開発
- リリースサイクル
- branch+Circle CI
- 開発サーバーの利用者が特定できる
- ミスによる上書きがなくなる
- 本番デプロイ用リポジトリ
- メインリポジトリのブランチマージ時にtag自動生成
- package.jsonでtag指定してデプロイ
- 全台デプロイでmaste mergeしてデプロイ
- 誰もがリリーサー
- botがリリース担当を決めてくれる
- branch+Circle CI
- Lint修正、テスト実行の自動化
- ESLint+Prettierを
yarn fixコマンドで実行 - 開発時にcode formatを考える必要がなくなった
- ESLint+Prettierを
- リリースサイクル
- 具体的な効果
- 内定者バイト学生が１週間で初PR
- サーバーサイドエンジニアがdesktopバージョンのPC側システムの刷新を主導
今後
- flowtypeをいれたい
- as-is
- raw JS
- 数値か文字列かはっきりしない
- 不要な型判定
- as-is
- 立ちはだかる壁
- organismsでstate管理するため、templateでuserのstateを利用できない
- プラグインの動的読み込みを実現するための黒魔術など
AbemaTV #ホンネテレビ の本音
-
FRESH! 1:18:35
-
スライド: [AbemaTV ホンネテレビ の本音]
(https://speakerdeck.com/ktknest/abematv-honneterebi-falseben-yin) -
株式会社AbemaTV 加藤(@ktknest)さん
#亀田1000万 でのサーバーダウンを繰り返さないための施策
AbemaTVとは
- 20チャンネル
- abema video(オンデマンド)
Web構成
- GCP
- BFF(Nginx->Node.js) APIは別ドメイン
- SPA(non-SSR)
タイムライン
- 2017/5『亀田興毅に勝ったら1000万円』放送 サーバーダウン
- 2017/7『第30期竜王戦決勝トーナメント 佐々木勇気五段 対 藤井聡太四段』放送 障害、Webサーバーダウン
- 2017/9『72時間ホンネテレビ』放送決定
- 2017/11『72時間ホンネテレビ』放送
72時間ホンネテレビに向けた対策
- Webサーバーを死なせない
- 以前のダウン時の問題箇所見直し
- GCP内部のgRPC通信でLB側のタイムアウトの考慮漏れによるコネクション限界突破
- CDN化
- Google Cloud CDN化
- UAによる配信振り分けができなくなったのでUA依存箇所を修正
- fastly移行検討中
- 以前のダウン時の問題箇所見直し
- Android,iOS,Chromecast,AppleTVなどで使うAPI/配信サーバーを死なせない
- Akamai化
- MPEG-DASH/HLSのプレイリストで配信していたユーザー情報・ログに関わる部分へのアクセスがスパイクしていた
- クライアント側でもライセンスなどのUA依存部分やログ・メトリクス送信を改善
- 必須なAPIを刷新
- 番組表を司る巨大なAPI(1MB)に依存していた
- チャンネル一覧などの必須APIをマイクロサービス化
- APIサーバーが落ちても無事で済むように
- 不要なリクエスト(タイミング)削減
- 番組の視聴までを必要最低限のリクエストで構成
- ポーリング間隔の調整
- 解像度コントロール
- 小さい画面は低画質で配信
- 実際のプレイヤーサイズに対応
- Akamai化
- エラー発生時の対応
- エラーハンドリング見直し、レスポンスエラーを考慮する
- 異常系をQAチームが簡単に再現するためのテスト用プロキシツール開発(ServiceWorker経由)
- 最悪ダメでもメンテ画面を必ず出す、Sorryサーバーに切り替えるシミュレーション
成果など
- 72時間テレビ、システム強化でAbemaTV最高視聴更新、サーバーダウン「０」
- 放送中の監視: 72+時間のシフト体制
LTタイム
リアルosushi食べながら片手間でメモとってた
『私がWebComponentsｵﾈｰｻﾝです』
-
@negimic さん
-
Ameba Pay
- 決済基盤を使うためのボタン
- 導入技術: ES Modules, Rollup, Payment Request APIs..
-
1025円以上の決済でエラー
- 1025桁 以上の入力を弾くようにするはずが・・
-
WebComponentsはIE11, Edgeで動かすのが大変
『2017年度の Vue + TypeScript』
- スライド: 2017年度の Vue + TypeScript
- @ktsnさん
- Vue2.5のTypeScriptの型推論がすごくなった話
- もともとTSを使っていたわけではないが、PRを送って型定義できるようにした
- vue-cliでTS pluginがサポートされ、やりやすくなった
- Vue Template内のComponentの関数の引数の型チェックなどができなかったのを、TS経由でできるようにした
- Vue.js2.4->2.5のアップグレードがつらい話（質疑）
- クラスで書いてある既存コードを無理に直す必要はない
『Unit testを書かなくて反省した話』
-
スライド: Unit testを書かなくて反省した話
-
@mki_skt さん
-
フロントエンドイベント告知
- 3/26 Bonfire Frontend #1
-
TDD
- 心理的安全の確保
- JavaのTDDの本を読んだ
- 開発成果物にテストコードを含めること
感想
- フロントエンド恐怖症を克服してきて実運用の話を聞くべきだなーと思っていたので、ちょうどよかった。まだまだ実感のないトピックがたくさんある
- 技術選定やdevs/ops的な話は、自分もバックエンド開発で小規模ながら経験的に繰り返してきたことなので、納得できるところが多かった
- Atomic Designが一大トピックのようだった。何となくイメージはつかめているつもりだが、プラクティカルに進められるかはチームでのデザイン共有の深さや旗振り的な人がどれくらいいるかによりそう。次回開催の頃には業界の運用例やpros/consの議論も増えていそう
- 大規模運用関連はいろいろな課題があるんだなあと参考になるが、業務的な恩恵を直接受けるのは自分というよりは同じような大規模サービス開発者になりそう
- SSR周りはあまり詳しくはないが、フロントエンド・バックエンドの総合格闘技という印象
- Vueのtypeの話だけなんか別レイヤーの濃さがあり、言語系の人は高まりそうな話だった
- よいUXとフロントエンド技術の関係を絡めた話も聞いてみたいけど、別のコミュニティになる？
- フロントエンド他人事にならないように、引き続き追っていきたい