LINE DEV DAY 2020 frontend
https://gyazo.com/d1eabb78bd5d7c28ad30ae4f88577417
3つのMUST
サービスを落としてはいけない
バグを出さない
エラーハンドリングが大事
開発速度は早く
伸び盛りのサービス
持続性・拡張性のあるコードを書く
型安全性
バグを減らせる
入力補完で開発促進
型はドキュメント
型は設計の基礎
型ドリブン設計
取り組み
XLT
Cross-Language Translation Tool
テキストを管理、テキストをエクスポートするAPI
エクスポートしたものをコミットする
コミットログ自体で管理下に置く
パーシャルアプリケーションをサポートしている
keyに渡すことができる
存在しないkeyを渡すとコンパイルエラー
リテラル型、ユニオン型
入力補完もカンタン
keyを覚える必要もない
コードの生成
型定義
完全なkey
string
パーシャル
残りの文字列の集合
runtimeのコードは共通のkey
テキストの生データをバンドル
ドット区切りしたネストしたオブジェクトに変換
Template Literal Typesが解決してくれる?
Slackでのbotで自動的にプルリクエストを作ってくれる
独自のtypescript-eslintルール
JSXを書く
条件 && JSXの書き方
その条件の時JSXを描写する
Reactがfalseを何も描写しない機能
bugが発生したことがあった
number | undefinedの場合
hoge && hoge > 1
0が入っていた場合どうなるか?
0に評価した
0が来たら0でrender
&&では真偽値に変化されなかった
numberが来ることを弾きたい
typeScript-eslintの独自ルールをつくった
noImplicitAnyを有効化していく
関数の引数を書かないとエラーになる
引数に型注釈を書いていない
関数引数がanyになってしまう
コードの型安全性が壊滅的になる
計算結果がanyになる
any is disaster
新規のプロジェクトはnoImplicitAny有効にするべき
tsc --initでは最初から有効になっている
strictオプションをtrueにする
LINE証券の問題
すでにオフの状態でプロジェクトが始まっていた
仮に時間が取れても正しく動くかのQAの時間
なぜ有効にしていなかったのか
他のプロジェクトからコピーされたものだった
経験者が少なかった
コンパイルが通るようにしたかった
徐々に適応していった
https://gyazo.com/33bb351620601901e19fd59a645409e5
緑:潜在的なエラー数
2019/07は短期決戦を挑んだ
QAには影響ない範囲で行った
半分までしか減らせなかった
CIでdiffがあったTypeScriptにチェックする
自前実装
変更があったものは既存でもチェックする
注意点
レビューは慎重に行う
引数にanyと書いてしまってもエラーを消してしまう
短期決戦は最初に行う
あとが楽になる
上流で型定義はしっかり書くべき
下流に大いに影響がある
LDS - コンポーネントライブラリに限定しないLINEのデザインシステムの変遷
ダバロス アラン
LDSとは?
2019 DevDayでLINEはデザインシステムを作成していると発表していた
1年後
いくつかのプロジェクトに導入されている
まだ開発は続いている
プロジェクト
LDS Messanger
LINE Messangerのため
LDS G
各国のLINEプロジェクトの統一
柔軟性が求められる
とあるコンポーネントはLINE NEWSやポイントクラブに導入されている
だいぶ前より
koromo
コンポーネント集
ビジネス向け
koromo-elemet
最終的に辞めた
ビジネス寄りのコンポーネントだと柔軟性がなかったため
使ってもらうための重要なこと
見つけやすさ
使いやすさ
チーム同士のコラボレーション
Laicon
アイコンライブラリを管理するアプリケーション
Component Sharing Platform
コンポーネント管理アプリケーション
再利用できるものも登録できる
LDS - プラットフォームを跨ぐアイコンアセット管理システムの開発
玉田晃寛
Laiconの管理
サービスではどのようなケースで使われるか
https://gyazo.com/6d5271a108eba1ac70376377c3409010
デザイナーとエンジニアに一貫したアイコンを提供する
大量のアイコンが使用されている
多言語化の観点から必要
名前設計
https://gyazo.com/7c1509da685f08db4fc4ee1121ca86fd
組み合わせで分解する
ルール
https://gyazo.com/4da9e3f8ff88f277e5b6593326465166
Regular, Solidのそれぞれの定義
追加したいアイコンがあるときレビューを行うことができる
人の目とシステムの両面でチェック
ビルドフロー
https://gyazo.com/727ed4221f66ca09c2f4e0816d7da132
アイコンの管理
Laiconに置き換えた
LDS - コラボレーションを促進する創発的なコンポーネントプラットフォーム開発
Petr Mareš
コンポーネントは再利用できるようにしたい
実装済みのものは見つけにくい
再度作ってしまう懸念点
LDS
開発体験があがる
一貫したUIとUXの提供
再利用性・柔軟性のあるコンポーネントをつくるのが大変
デザイナーとエンジニアがコラボレーションする場をつくりたい
専用ライブラリ
ライブラリパッケージ
たくさんのフロントエンドプロジェクトがある
Web Componentsでなんとかなる
コントリビューションが大変
バグは機能追加は時間がかかる
バージョン付けが大変
バージョンのアップデートがある
開発時間が不要
OSSでプラットフォームをつくるか
独自のウェブサービズをつくらないといけない
Sharing Platform
Bit cliで実現
npm
Bitレジストリ
コントリビューション
Bitをセットアップ
コンポーネント定義
コンパイラを設定
バージョンタグ付け
依存性を確認
うまくいったらPlatformでexport
READMEも表示できる
ソースコードがブラウザできる
Playground
コラボレーション
各サービスのエンジニアが自分たちのプロジェクト内で使える
バグ修正をPublishして使えるようにする
LDSチームがリファクタして全てで使えるようにした
ディスカッション
どうしてアクセシビリティ?
富田
もともとWeb制作をはじめたころから
ユーザー自体が変更できる良さ
Design with Web Standard
駅でベビーカーを使う時に不便になった話
不便だなと思って苛立った
自分は胸を張ってそういうものができるのか疑問に思った
橋本
LINE NEWS
デザイン統括
ニュースは皆が教授されるべき
アクセシビリティがおざなりになっていた反省点
同一体験を提供する
コントラスト比に着目した
桝田
キャリアのスタート
CADのセールスマン
テキストサイト生まれ
Web標準
ALSの支援をしている人のWebサイト制作に携わる 視線誘導
Webは誰でもつかえるんだというポジティブさ
伊藤
スポーツ新聞社の中の人
成績表をtableで組んでいた
スクリーンリーダーを利用している人からのお問い合わせ
よくできていると褒めてもらって嬉しかった
セマンティクスになるのがアクセシビリティにつながった
業務上の気付きはSlackで情報共有する
改善、テクニカルなトピック
新聞社ではジャンルが分かれていた
各所で共有していた(草の根活動)
デザインは変えられない問題
号令をかけて直していった(組織パワー)
やらなければいけないよね?という語りかけ
組織とアクセシビリティ、取り組みなど
桝田
マークアップエンジニア
フロントエンドエンジニア
下地
ちゃんとしたマークアップをする意識
品質に昇華していく
評価指標
品質基準をつくる
CDN開発
BFF開発
マークアップとフロントエンド開発が別れている難しさはある?
富田
難しさはある
aタグにhrefが入ってなくてリンクになっていない
デザイン側と対話しながら解消していたりする
マークアップはQAの観点に入っている?
そこまで保証できていない
実験的に動作検証でキーボードだけで実行してみる
組織でうまくできなかった
仲のいい人と一緒にやってしまった
クライアントワーク
伊藤
クライアントからアクセシビリティの依頼はない
勝手にやる
要件定義に混ぜてもらう
設計段階の案件を受けたらワンチャン
アクセシビリティ実装がむずかしければ追加料金の場合(相談)
アクセシビリティに注力するため他を簡略化する
業界のあるべき論、明日からこうやるべきだ
富田
手を動かすのが大事
橋本
ナレッジシェアできる環境をつくる
アクセシビリティに関するナレッジシェアのワークショップ
桝田
ソーシャルグッドの意味から始まってる
プロダクトがアクセシブルである価値、貢献
チームで取り組んだ先に事業貢献できるか
伊藤
LIFF SDK - SDK のこれまでとこれから (LIFF SDK v3) 岡本拓也
LIFF
フロントエンドフレームワーク
プラットフォームとの連携ができる
取り巻く環境
デベロッパー
LINE MINI App
ファミリーサービス
SDK開発は5人
ShareTargetPicker
メッセージの送信
ユーザーアクションの確認
型定義を出している
パフォーマンス問題
余計なトラフィックを読んでる
コア部分
周辺機能
関心の分離を行う
外部で価値の想像ができる?
v3プラン
SDKサポートプラグイン
Web志向に近づける
後方互換性を持つ
来年春に段階的リリース予定
LIFF SDK - DX改善のためのアクション
リン ティンシュ
なぜnpmパッケージをリリースするのか
フレームワークを使う
ビルドツール
依存性はツールで解消
1つのSDKファイルしか提供できない
liff が定義されていないエラーがあった
型定義がない
実行時までわからないのでランタイムエラーになる
npm パッケージ化
補完がされるようになった
タイプエラーが確認できるようになる
JS Docを入れているのでドキュメントを見れる
npmがカンタンにリリースできない問題
型定義が完璧じゃない
interfaceの定義をする
ネイティブクライアントに依存性がある
機能を複数パートに分ける
Web指向になればクライアントに依存することはなくなる
LIFF SDK - Web指向への道
チン カリュウ
プラットフォーマット
iOS , Android
メイン
Web
サブ
皆最新版を皆使う必要がある
他のバージョンとSDKを組み合わせると複雑なマトリクスになる
メインを統一する
コストを削減する
依存を減らす
制約条件を減らす
コミュニティを拡張していく
LIFF UIを開発中
lui-icon
lui-alert
lui-confirm
lui-navigation-back
lui-navigation-bar
lui-orientation-guard
LIFF SDK - LIFFアプリのためのUIフレームワーク
Yang Gong
LIFF UIについて
LIFFアプリケーションのためのUI
モチベーション
旧フレームワークからの移行
重複した実装コストを軽減
UXの向上
メリット
各種フレームワークとの適合
一貫性のある体験
再利用性
一人ひとりの「変えたい」を力に、11人で変化し続ける開発チームができるまで
大槻友諒
チームの課題をどう乗り越えてきたか
サービスの成長にともない2人→11人
フルリモート
裁量労働
雇用形態の違い
自立的なチーム
チームメンバーが変えたい気持ちをもちともに変化していける
最初に変えたい人が思いを伝える
歓迎して一緒に変えていく環境
変えたい気持ち
1. 行動として見えていない状態
放置されてしまう
共有が遅れる
自主性がないと思われる
コードレビューしてもらえない
忙しい、後で見る
仕様について知識が足りない
適任者に任せよう
重要だけど緊急じゃない事案
人によって解釈が違う
コード修正は大変なので早くやるべき
影響範囲や優先順位判断で今すぐにやるべきではない
品質か納期か
複雑な実装ではないのでレビューしてほしい
レビューは余裕を持って出してほしい
互いの考えを伝えていなかった
関係性の問題
行動しやすいように整える
相互理解
まとめ役をやることが大事ではない
信頼をする
どうやって相互理解を深めるか
仕事をすすめる最低限の相互理解
1人1人の違いを理解する
チームの方向性
互いへの期待
やったこと
偏愛マップの提案
価値観や興味を知ってもらう
自己開示
心のハードル
自分からやってみせる
参加しやすい空気づくり
スキルマップ
経験が多いか、好きか嫌いか
モブワークの時間をつくっていた
差分がきになった頃に再開
参加しやすい空気づくり
ふりかえり
観点
チームの方向性の共有
互いへの相互理解
デリゲーションレベル
チームの状態を見極める
半年近く相互理解に時間はかかっていた
進化する Web エコシステムとパフォーマンス
エコシステムコンサルタント
アプリと比較した場合のWeb技術
リーチの強さ
アプリはインストールしないといけない
すぐアクセスできる、ハイパーリンクへのリーチしやすさ
機能をフレキシブルに使えることができる
Prompt
Install Banner
In-feed
Booking or checkout journey
deferredPrompt
Push通知
Quiet notification UI
デフォルトでブロック
ユーザーが選択する
Web APIでできること
Web Share API
Web Share Target API
App Shortcut
getInstalledRelatedApps
Web OTP
WebView
APIで使えないものがある
Chrome Custom Tab
パフォーマンスがちがう
Trusted Web Activity
Digital Asset Links + Chrome Custom Tab
Tool
Bubblewrap
PWABuilder
UX
読み込みが遅くないか
反応してくれるか
レイアウトががたがたしないか
Quick Link
Contents visibility
Singed Exchanges
アドレスはパブリッシャーのまま
LINEのフロントエンド開発を支えるインフラサービスとそのDevOps
吉澤峻行
Verda
プライベートクラウドプラットフォーム
オブジェクトストレージ
CDN
ロードバランサ
Abyss
https://gyazo.com/9184a26010a80eec8ca4a9b2dac4f428
Verrda Object Storage
Story that built Sentry as an On-Premise
Sentryをオンプレミスで運用
フロントエンドに適していなかった
SourceMap
Breadcrumbs
なぜオンプレミスなのか
ソースの外部流出しない
クラウドは使った分料金が異なる
インフラ
web, redis, db, workerのコンテナ
スケールアップしかできない
コンテナを分離してスケールアウトができるように
Postgresql
水平拡張が不可能
トラフィックが増大する場合
各ノードを比較
nGrinder
白石真之
OSS貢献
ソースコード提供
翻訳
ポッドキャスト
ミートアップ
npm trends Bootstrap
CSSツールキットの開発
koromo
BootStrapベース
翻訳作業
1週間で行えそう
サイトの構築
本家をclone
mdを翻訳
HTMLに変換
パブリッシュ
失敗談
10分でかかるはずが30分かかってた
やらない部分を決めて公開
アクセス解析とSEO
Alertが一番上にきてたのでアクセスが有る
example
Search Consoleで計測
バナーで最新のバージョンに誘導
トレードオフ
翻訳7割で公開
タイポ
気づいた時に修正
優先度が高いものに集中
インパクトのない施策はしない、規模感のあるもの
メリット
なんでもできる
周辺知識が増えた
機会が増える
Cypress を使用したビジュアルリグレッションテスト
Wei Yang Yao
LINE Developer Console
開発の問題点
リファクタリング
共有コンポーネント化
CSSを変更
レイアウトの不具合
タオパン
アプリ内ですべてチェックする必要がある
凄い時間がかかる
E2E
コード変更の前後でスクリーンショットを取る
課題
ごくわずかな差でエラーが発生
しきい値を設定
稲置美里
デメリット
マークアップとロジックの2重管理が発生
CSSのスコープ問題
分業でスピードが遅くなるのでは?
分業を選択する理由
UIのこだわりを反映しやすい
JSとCSSを疎結合にできる
並列開発ができる
フロントエンドテンプレート
@linecorp/frontend-template-cli