Inside Frontend #1に参加しました
2/25(土)にこちらのイベントに参加しました。
場所はヤフーさんのオフィスのある東京ガーデンテラス紀尾井町 紀尾井タワーで開催されました。 フロントエンドのこういったセミナーに参加するのは初めてだったのですが、とても実入りのあるセッションばかりで大変勉強になりました。 参加したセッションでメモしていた内容と、アップされていたセッション資料を紹介します(随時追記) (特にいいと思った点は赤字にしています)
セミナーB1 Web over ServiceWorker by @Jxck_
- Web vs PC APP
- ここ最近の主戦場は Web vs Mobile
- Service Workerとは?
- ライフサイクルの違い
- WindowとSWは違うライフサイクルで動く
- 最近のUpdate情報
- Foreign Fetch
- 1クライアントに対して1コントローラだったが、
- 1stPartyだけでなく3rdPartyのアプリのSWも起動できるようになった
- SWの責務の切り分けをSW単位でできるようになった
- Navigation Preload
- SWが起動していなかった場合、起動するまで待つ必要があったが、
- レスポンスを返した後にSWを起動できるようになった
- Foreign Fetch
セミナーB2 Web フロントエンドにおけるコンポーネント化のアプローチ by @1000ch
- これまでの振り返り
- CSSのスタイルガイド
- workフローに組み込んでいるだけで、何を解決すればいいのか本質的に見えてなかった
- コンポーネントとはいったい何なのか
- これまでの問題点
- コンポーネントの管理手段の問題
- クライアントサイド実装の溝問題
- 技術的課題
- 協業実践に向けた方針
- 職能同士の歩み寄り at 現場
- 一方通行な開発にならないための説得材料の提示
- 開発上のメリット
- 品質上のメリット
- 先人に学ぶ
- 説得材料の交換
- 開発上のメリット:再利用性・保守性
- 品質上のメリット
- お互いの作業を小さく分担
セミナーB3 Refactoring CSS: 管理されたカオスへの道のり by @hiloki @cssradar
- リファクタリングとは
- 保守しやすく拡張しやすくする
- CSSにおけるリファクタリングには難しい場面が多々ある
- UIの変更頻度と変更速度
- 影響範囲の広さ
- テスト書くことが難しい
- リファクタリングはいつするのか?
- リファクタリングはどうやるか?
- リファクタリング中はそれだけをする。外部的振る舞いを変えず、内部的振る舞いのみ変えることが重要
- 問題は小さく砕いて解決する
- CSSは影響範囲が大きくなりがちなので、小さくする
- 元のソースコードは消さない
- .RF_*というプレフィックスをつけるテクニック
- class=”RF=” + …
- テストして問題なければ削除する
- all: initial; を使ったりとかもする
- ドキュメントを書こう
- リファクタリング中にどんな処理がやってきているか分かってきたら積極的にコメントを残そう
- ドキュメンテーション ≠ スタイルガイド
- リファクタリングのコツ
- まとめ
所感
どれも刺激的な内容だったのですが、得にセミナーB3のCSSのリファクタリングの話でのコメント技は衝撃を受けました・・。
CSSのコメント。すごい #insideFE pic.twitter.com/KFnnPupjJX
— かわかみ (@saruyama_monki) 2017年2月25日
セッションの合間に行われていたAMA(Ask Me Anything)がすごい良かったと評判だったので、もう少し参加しておけばよかったという後悔はありましたが、全体を通して大変満足した内容だったので次回もぜひ参加したいと思いました。
当日の内容は #insideFEでも見ることができます。
CircleCIからESLintの指摘結果をPull Requestにコメントする
先日、CI/CD NIGHTにて「CircleCIで結果をSlackに通知してみる」という内容でLTをさせていただきました。
発表資料はこちら。
元々CircleCIからSlack通知するまでの連携で終わる予定でしたが、後半のスライドにあるようにCircleCIから直接ESLintの指摘結果をPull Requestにコメントできるsaddlerなるものを見つけたので、せっかくなので試してみました。今回はその内容を紹介します。
What's saddler
saddlerとはRubyのパッケージでLint結果をPull Requestにコメントしてくれるものです。今回はこれを利用し、ESLintのチェック結果をPull Requestにコメントするものを作成しました。
利用手順
今回はGitHubとCircleCIの連携を利用しており、ESLintを実行する必要があるため
を前提としています。設定方法は、先の資料の前半部分に記載しています。
どんな感じに見えるの?
下記のようにlint結果がコメントされます。
run-eslint.shの作成
こちらを参考にしました。
Androidのコードを自動で解析し、GitHubのpull requestにコメントする - Qiita
#!/bin/bash set -v if [ "${CIRCLE_BRANCH}" != "master" ]; then # Circle-CI # echo gem install gem install --no-document checkstyle_filter-git saddler saddler-reporter-github echo "********************" echo "* select reporter *" echo "********************" if [ -z "${CI_PULL_REQUEST}" ]; then # when not pull request REPORTER=Saddler::Reporter::Github::CommitReviewComment else REPORTER=Saddler::Reporter::Github::PullRequestReviewComment fi echo saddler git diff --name-only origin/master \ | grep '.*\.js$' \ | xargs node_modules/eslint/bin/eslint.js -f checkstyle \ | checkstyle_filter-git diff origin/master \ | saddler report --require saddler/reporter/github --reporter $REPORTER fi
echo saddler
下記の流れになっています。
- masterとのdiff取得
- jsファイルをgrep
- eslintの結果をcheckstyle形式にフォーマット
- saddlerからPull Requestにコメント
circle.ymlの設定
先ほどのshを実行するために、circle.ymlに下記を追加します。
※shを実行するために実行権限を付与しています。
test: override: - chmod a+x run-eslint.sh - ./run-eslint.sh
GitHubのトークンをCircleCIに設定
さいごに
「CirclecI ESLint pr」で調べてもなかなかマッチする記事がでなかったので、何かの参考になればいいなと思います。GitHubでソースコードを公開しています。
https://github.com/yNakahira/circleci