「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に時間をとれない
  • どの領域も基礎知識があって掛け算できるのが強み