<p>スタディスト 開発部 技術支援ユニットの笹木 (<a href="http://twitter.com/s_sasaki_0529">@s_sasaki_0529</a>) です。</p><p><strong>2021年上半期、およそ6万行の JavaScript コードを TypeScript に置き換える作業を、半年間単独で行いました。</strong></p><p>本記事では、機能開発自体を止めずに、どのように走り切ることができたのか、ふりかえりたいと思います。</p><p>なお、本記事は移行開始直後の登壇資料 “<a href="https://www.slideshare.net/shingosasaki3/vue-typescript">大規模 Vue アプリケーションの TypeScript 移行</a>” をブログ向けに抜粋、加筆、最新化したものになるため、一部内容が重複しています。</p><h3>Teachme Biz と TypeScript</h3><p>弊社が開発している、マニュアル作成・共有システム <a href="https://biz.teachme.jp/">Teachme Biz</a> は、iOS/Android や Windows など、マルチプラットフォームで提供されています。</p><p>その中でも、作成・管理に多く使われている Webブラウザ版は、 JavaScript と Vue.js を主とした、以下のような技術構成となっており、歴史的経緯もあって TypeScript は使用していませんでした。</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*BHzrwXsss2q1OW2ZXlNy3Q.png" /><figcaption>移行開始以前の技術構成</figcaption></figure><p>Web開発における TypeScript の重要性は語るまでもありません。弊社でも、型がないことによる以下の四大リスクを抱え、不具合が発生しやすい上、開発効率が低い状態が続いていました。</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*ThtY8HdoDUIsv8CAXqseqw.png" /><figcaption>四大リスク</figcaption></figure><ul><li><strong>危険</strong>: Null を含むどんな値が入っているか推測しづらい</li><li><strong>無秩序</strong>: コードの自由度が高まり、一貫性のないコードが量産される</li><li><strong>非効率</strong>: エディタの推論が満足に効かず、タイポが起こりやすい</li><li><strong>暗黙知</strong>: 設計に関する情報がコードから得づらい</li></ul><p>上記の四大リスクは、型の力で以下のように解決することができます。</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*6SOA0jTFDSo2CvZsukS8fA.png" /><figcaption>かた の ちから ってすげー</figcaption></figure><p>これまでは四大リスクをだましだまし受け入れ続けてきましたが、長期的なスケールや、Vue 3 へのマイグレーションなどを見越すと、移行は今しかないという判断に至りました。</p><h3>移行範囲</h3><p>移行を決意したとはいえ、どこまでをどのレベルで移行するのかを予め決める必要があります。</p><p>結論から言うと、以下のような方針で移行を行うことにしました。</p><ul><li>.js ファイルは(一部の例外を除いて) 全て移行する</li><li>.vue ファイルは一切移行しない</li><li>strict: true のルールを設定する</li><li>plugin:@typescript-eslint/recommended を使用する</li></ul><p>Vue を対象外としたのは、Vue 3 へのマイグレーションを考慮した時、どのみちコンポーネントの書き直しが発生したり、型の使い方が変わったりと二度手間になりえるからです。</p><p>.js ファイルについては、基本的に全てのファイルを対象とし、 tsconfig や eslint での厳しい設定を付与します。これによって、<strong>implicit any や ts-ignore を使用した、”移行はしてるが全然型安全じゃない”という半端な状態を減らします。</strong> (明示的な any 自体は禁止せず、今後の課題とする)</p><h3>開発チームとの認識合わせ</h3><p>既存コードの TypeScript 移行を進めても、各開発チームが新規コードを従来どおり JavaScript で書いてしまうと、アキレスと亀のような状態になり、移行がいつまでも完了しません。</p><p>そこで、まずは開発チーム全体に、本記事で書かれているような背景とプロセスを共有し、<strong>新規コードは基本的に TypeScript で書いてもらいつつ、既存コードを改修する場合も、可能な限り TypeScript を使う</strong>ように認識を揃えました。</p><p>もちろん多くのメンバーは TypeScript 未経験であるため、相互レビューを強化したり、<a href="https://book.mynavi.jp/ec/products/detail/id=104703">実践 TypeScript</a> の輪読を行うなど、社内への TypeScript の布教を心がけました。</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/391/1*ag-uicHNPyNwpGvoNkBmDw.jpeg" /><figcaption>輪読に使用した書籍</figcaption></figure><h3>移行プロセス</h3><p>移行対象が .js ファイルのみとはいえ、コードベース上のJSファイルは、テストコードも含めると累計で<strong>6万行</strong>存在するため、計画的に移行を進める必要があります。</p><p>充分な時間があるとはいえ、他の開発チームの業務は止めず、なるべく邪魔にならないようにするためには、<strong>移行するファイルと機能開発で修正されるファイルの衝突を、最小限に留める</strong>必要があります。</p><p>そのため、移行用の作業ブランチを切るということはせず、ファイルまたはフォルダ単位で小さく移行し、個別に PR を作成、素早くマージ(≒リリース) するというサイクルを繰り返しました。</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*K-IhOGjFe-tHjxDC_i8M2g.png" /><figcaption>全て master ブランチ向きの PR</figcaption></figure><p>なお、細かい移行順序や工夫点は、<a href="https://uit-inside.linecorp.com/">UIT INSIDE</a> で話されていた LINE 様の事例を参考にしています。 (いつも楽しく聴いてます!)</p><ul><li><a href="https://uit-inside.linecorp.com/episode/55">ep.55 TypeScriptへのマイグレーション対応開始！LINEポイントクラブのリファクタについて聞いてみた。 | UIT INSIDE</a></li><li><a href="https://uit-inside.linecorp.com/episode/77">ep.77 TypeScriptマイグレーション進捗報告！LINE ポイントクラブがかけたリソースと回収状況 | UIT INSIDE</a></li></ul><h3>検証プロセス</h3><p>前述のように、小さく移行してリリースのサイクルを回すということは、それだけ本番環境のコードが頻繁に書き換わるということです。</p><p>開発のリスク軽減のための TypeScript 移行のせいで、新たに障害が起こるようでは本末転倒。ここでバグを出すわけにはいきません。</p><p>幸いにも Teachme Biz の開発環境は、 CI/CD プロセスが充分に整備されています。</p><p>コードをプッシュするたびに、以下のテストが CircleCI 上で実行されるので、基本的には CI が通れば OK と判断できます。</p><ul><li>単体テスト(Jest)</li><li>E2Eテスト(Selenium)</li><li>Visual Regression Testing (Storybook + reg-suit)</li></ul><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*eJc61G6oQFWRD173BGKnkA.png" /><figcaption>内製のE2Eテストレポート画面</figcaption></figure><p>自動テストをパスしても不安の残る改修がある場合、検証環境を立上げて、個別に手動検証を行います。</p><p>検証環境については、実行基盤が kubernetes に移行したこともあり、簡単なコマンドで、インスタントな独立した環境を立ち上げることができます。kubernetes については以下記事を御覧ください。</p><p><a href="https://medium.com/studist-dev/studist-sre-and-kubernetes-49d1de1c4be6">Teachme Bizの基盤をEC2からEKSへ移行した話</a></p><p>ここまでしてなお不安が残る場合、別途 QA グループに相談します。開発者自身では見つけられない、思いつきもしない不具合を、的確な検証で探り出してもらえます。</p><h3>リファクタリング</h3><p>TypeScript 移行に関しては、多くのブログや書籍で事例が紹介されていますが、<strong>リファクタリングを同時に行うべきか否か</strong>という問題がよく上がります。多くの場合、リファクタリングは別枠考えるべきとも言われています。</p><p>以下の事例を具体的に見てみましょう。</p><p><a href="https://logmi.jp/tech/articles/324487">移行のメリットはコストを上回るか？　JavaScriptのTypeScript化で気をつけるべき5つのポイント</a></p><blockquote>4つ目は逆説的なんですが、「リファクタリングとTypeScript移行を同時に行わない」ということです。TypeScript移行に関しては、対象となるファイルがアプリ全体で非常に広いので、リファクタリングとTypeScript移行を同時にやってしまうと、リグレッションテストが落ちたときに、その原因が移行時に意図せず混入したバグなのか、それともリファクタリングの影響なのか切り分けが非常に難しくなります。</blockquote><blockquote>またこちらのほうが大事なのですが、リファクタリングは始めるときりがなくなります。今回変更はアプリ全体に影響する可能性があるので、リファクタリングをし始めるとあれもこれも気になって、いつまでたってもTypeScript移行が終わらないという状況に陥ります。</blockquote><p>全面的に同意です。多くの場合はその選択が正しいと思います。</p><p>しかし弊社では、逆に<strong>リファクタリングをイケるところまでやりながら TypeScript 移行しよう</strong>という方針にしました。主な理由は以下のとおりです。</p><ul><li>前述の検証プロセスが非常に充実しているので、デグレリスクが低い</li><li>自身が専任で TypeScript 移行を行っているため、時間が充分にある</li><li>未来は予想できないため、「あとでリファクタする」で本当にリファクタするとは限らない</li><li><strong>リファクタせずに現行コードに型を付けると、カオスな型が出来上がる</strong></li></ul><p>個人的には最後のが大きいです。<strong>型のない世界で、勢いで書かれたコードは、データ構造を無視しがち</strong>で、その全てに対応する型を定義しようとすると、引きずられておかしな型が出来上がります。また、このタイミングで旧機能の不要コードや、参照されないデッドコードを洗い出すことで、余計な型定義を減らすこともできます。</p><p>そのため、あるべき型を定義し、そぐわないコードを修正するリファクタ作業を同時に行うことで、コード品質自体を高めるというのを目指しました。</p><h3>進捗管理</h3><p>全ての JS ファイルを移行対象にするといいつつ、様々な経緯で移行不可能なファイルも少なくありません。そこで、<strong>半期の間に 70% の移行を完了させる</strong>という OKR を掲げ、それを TypeScript 移行完了のゴールと定義しました。</p><p>進捗率のトラッキングは、masterブランチの各コミット時点での TS ファイルと JS ファイルの総数(及び行数) の比率を計測するようにしました。</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*9ccAaqli-an1Paw9G9d9KA.png" /><figcaption>計測用コードのイメージ</figcaption></figure><p>上記スクリプトを用いて集計し、ペース配分を見ながら、半年間移行作業を続けることで、8月末にちょうど目標に到達することができました。</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*tF05L0gOCPlwl7H5c7RNnQ.png" /><figcaption>7月後半に急激に増加してるのは Storybook コードの一括置換によるもの</figcaption></figure><h3>まとめ</h3><p>本記事では、JavaScript のコード6万行を、機能開発を止めずに、1人で TypeScript に移行することができた要因を整理しました。</p><p>弊社では以下のような条件が揃っていたことから、TypeScript 移行をリファクタリング込みで実現できたと言えます。</p><ul><li>技術支援ユニットという、機能開発から独立した部隊が存在する</li><li>各社の事例を事前に分析し、進め方を決めてから着手した</li><li>期間と範囲を決め、トラッキングしながら集中対応した</li><li>CI/CD によって、自動テスト/手動テストのための仕組みが揃っていた</li></ul><h3>最後に</h3><p>スタディストには、こういった開発基盤の整備に全力を注げる環境が用意されています。今後さらなる事業拡大を目指すためにも、より多くの仲間を求めているので、ご興味がありましたら、ぜひ一緒に働きましょう！</p><p><a href="https://www.wantedly.com/companies/studist">株式会社スタディストの会社情報 - Wantedly</a></p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=90b99b7c8974" width="1" height="1" alt=""><hr><p><a href="https://medium.com/studist-dev/typescript-migration-90b99b7c8974">機能開発を止めずに、6万行の TypeScript 移行を完了させた開発プロセス</a> was originally published in <a href="https://medium.com/studist-dev">スタディスト開発ブログ</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>

スタディスト 開発部 技術支援ユニットの笹木 (@s_sasaki_0529) です。
2021年上半期、およそ6万行の JavaScript コードを TypeScript に置き換える作業を、半年間単独で行いました。
本記事では、機能開発自体を止めずに、どのように走り切ることができたのか、ふりかえりたいと思います。
なお、本記事は移行開始直後の登壇資料 “大規模 Vue アプリケーションの TypeScript 移行” をブログ向けに抜粋、加筆、最新化したものになるため、一部内容が重複しています。
Teachme Biz と TypeScript
弊社が開発している、マニュアル作成・共有システム Teachme Biz は、iOS/Android や Windows など、マルチプラットフォームで提供されています。
その中でも、作成・管理に多く使われている Webブラウザ版は、 JavaScript と Vue.js を主とした、以下のような技術構成となっており、歴史的経緯もあって TypeScript は使用していませんでした。
移行開始以前の技術構成
Web開発における TypeScript の重要性は語るまでもありません。弊社でも、型がないことによる以下の四大リスクを抱え、不具合が発生しやすい上、開発効率が低い状態が続いていました。
四大リスク
危険: Null を含むどんな値が入っているか推測しづらい
無秩序: コードの自由度が高まり、一貫性のないコードが量産される
非効率: エディタの推論が満足に効かず、タイポが起こりやすい
暗黙知: 設計に関する情報がコードから得づらい

上記の四大リスクは、型の力で以下のように解決することができます。
かた の ちから ってすげー
これまでは四大リスクをだましだまし受け入れ続けてきましたが、長期的なスケールや、Vue 3 へのマイグレーションなどを見越すと、移行は今しかないという判断に至りました。
移行範囲
移行を決意したとはいえ、どこまでをどのレベルで移行するのかを予め決める必要があります。
結論から言うと、以下のような方針で移行を行うことにしました。

.js ファイルは(一部の例外を除いて) 全て移行する
.vue ファイルは一切移行しない
strict: true のルールを設定する
plugin:@typescript-eslint/recommended を使用する

Vue を対象外としたのは、Vue 3 へのマイグレーションを考慮した時、どのみちコンポーネントの書き直しが発生したり、型の使い方が変わったりと二度手間になりえるからです。
.js ファイルについては、基本的に全てのファイルを対象とし、 tsconfig や eslint での厳しい設定を付与します。これによって、implicit any や ts-ignore を使用した、”移行はしてるが全然型安全じゃない”という半端な状態を減らします。 (明示的な any 自体は禁止せず、今後の課題とする)
開発チームとの認識合わせ
既存コードの TypeScript 移行を進めても、各開発チームが新規コードを従来どおり JavaScript で書いてしまうと、アキレスと亀のような状態になり、移行がいつまでも完了しません。
そこで、まずは開発チーム全体に、本記事で書かれているような背景とプロセスを共有し、新規コードは基本的に TypeScript で書いてもらいつつ、既存コードを改修する場合も、可能な限り TypeScript を使うように認識を揃えました。
もちろん多くのメンバーは TypeScript 未経験であるため、相互レビューを強化したり、実践 TypeScript の輪読を行うなど、社内への TypeScript の布教を心がけました。
輪読に使用した書籍
移行プロセス
移行対象が .js ファイルのみとはいえ、コードベース上のJSファイルは、テストコードも含めると累計で6万行存在するため、計画的に移行を進める必要があります。
充分な時間があるとはいえ、他の開発チームの業務は止めず、なるべく邪魔にならないようにするためには、移行するファイルと機能開発で修正されるファイルの衝突を、最小限に留める必要があります。
そのため、移行用の作業ブランチを切るということはせず、ファイルまたはフォルダ単位で小さく移行し、個別に PR を作成、素早くマージ(≒リリース) するというサイクルを繰り返しました。
全て master ブランチ向きの PR
なお、細かい移行順序や工夫点は、UIT INSIDE で話されていた LINE 様の事例を参考にしています。 (いつも楽しく聴いてます!)

ep.55 TypeScriptへのマイグレーション対応開始！LINEポイントクラブのリファクタについて聞いてみた。 | UIT INSIDE
ep.77 TypeScriptマイグレーション進捗報告！LINE ポイントクラブがかけたリソースと回収状況 | UIT INSIDE

検証プロセス
前述のように、小さく移行してリリースのサイクルを回すということは、それだけ本番環境のコードが頻繁に書き換わるということです。
開発のリスク軽減のための TypeScript 移行のせいで、新たに障害が起こるようでは本末転倒。ここでバグを出すわけにはいきません。
幸いにも Teachme Biz の開発環境は、 CI/CD プロセスが充分に整備されています。
コードをプッシュするたびに、以下のテストが CircleCI 上で実行されるので、基本的には CI が通れば OK と判断できます。

単体テスト(Jest)
E2Eテスト(Selenium)
Visual Regression Testing (Storybook + reg-suit)
内製のE2Eテストレポート画面
自動テストをパスしても不安の残る改修がある場合、検証環境を立上げて、個別に手動検証を行います。
検証環境については、実行基盤が kubernetes に移行したこともあり、簡単なコマンドで、インスタントな独立した環境を立ち上げることができます。kubernetes については以下記事を御覧ください。
Teachme Bizの基盤をEC2からEKSへ移行した話
ここまでしてなお不安が残る場合、別途 QA グループに相談します。開発者自身では見つけられない、思いつきもしない不具合を、的確な検証で探り出してもらえます。
リファクタリング
TypeScript 移行に関しては、多くのブログや書籍で事例が紹介されていますが、リファクタリングを同時に行うべきか否かという問題がよく上がります。多くの場合、リファクタリングは別枠考えるべきとも言われています。
以下の事例を具体的に見てみましょう。
移行のメリットはコストを上回るか？　JavaScriptのTypeScript化で気をつけるべき5つのポイント
4つ目は逆説的なんですが、「リファクタリングとTypeScript移行を同時に行わない」ということです。TypeScript移行に関しては、対象となるファイルがアプリ全体で非常に広いので、リファクタリングとTypeScript移行を同時にやってしまうと、リグレッションテストが落ちたときに、その原因が移行時に意図せず混入したバグなのか、それともリファクタリングの影響なのか切り分けが非常に難しくなります。
またこちらのほうが大事なのですが、リファクタリングは始めるときりがなくなります。今回変更はアプリ全体に影響する可能性があるので、リファクタリングをし始めるとあれもこれも気になって、いつまでたってもTypeScript移行が終わらないという状況に陥ります。
全面的に同意です。多くの場合はその選択が正しいと思います。
しかし弊社では、逆にリファクタリングをイケるところまでやりながら TypeScript 移行しようという方針にしました。主な理由は以下のとおりです。

前述の検証プロセスが非常に充実しているので、デグレリスクが低い
自身が専任で TypeScript 移行を行っているため、時間が充分にある
未来は予想できないため、「あとでリファクタする」で本当にリファクタするとは限らない
リファクタせずに現行コードに型を付けると、カオスな型が出来上がる

個人的には最後のが大きいです。型のない世界で、勢いで書かれたコードは、データ構造を無視しがちで、その全てに対応する型を定義しようとすると、引きずられておかしな型が出来上がります。また、このタイミングで旧機能の不要コードや、参照されないデッドコードを洗い出すことで、余計な型定義を減らすこともできます。
そのため、あるべき型を定義し、そぐわないコードを修正するリファクタ作業を同時に行うことで、コード品質自体を高めるというのを目指しました。
進捗管理
全ての JS ファイルを移行対象にするといいつつ、様々な経緯で移行不可能なファイルも少なくありません。そこで、半期の間に 70% の移行を完了させるという OKR を掲げ、それを TypeScript 移行完了のゴールと定義しました。
進捗率のトラッキングは、masterブランチの各コミット時点での TS ファイルと JS ファイルの総数(及び行数) の比率を計測するようにしました。
計測用コードのイメージ
上記スクリプトを用いて集計し、ペース配分を見ながら、半年間移行作業を続けることで、8月末にちょうど目標に到達することができました。
7月後半に急激に増加してるのは Storybook コードの一括置換によるもの
まとめ
本記事では、JavaScript のコード6万行を、機能開発を止めずに、1人で TypeScript に移行することができた要因を整理しました。
弊社では以下のような条件が揃っていたことから、TypeScript 移行をリファクタリング込みで実現できたと言えます。

技術支援ユニットという、機能開発から独立した部隊が存在する
各社の事例を事前に分析し、進め方を決めてから着手した
期間と範囲を決め、トラッキングしながら集中対応した
CI/CD によって、自動テスト/手動テストのための仕組みが揃っていた

最後に
スタディストには、こういった開発基盤の整備に全力を注げる環境が用意されています。今後さらなる事業拡大を目指すためにも、より多くの仲間を求めているので、ご興味がありましたら、ぜひ一緒に働きましょう！
株式会社スタディストの会社情報 - Wantedly

機能開発を止めずに、6万行の TypeScript 移行を完了させた開発プロセス was originally published in スタディスト開発ブログ on Medium, where people are continuing the conversation by highlighting and responding to this story.

機能開発を止めずに、6万行の TypeScript 移行を完了させた開発プロセス

<h3>webpack 5 にアップグレードしました</h3><p>スタディスト 開発部 技術支援ユニットの笹木 (<a href="https://twitter.com/s_sasaki_0529">@s_sasaki_0529</a>) です。</p><p>今回は、弊社が開発・運用している <a href="https://biz.teachme.jp/">TeachmeBiz</a> でも使用している、<a href="https://webpack.js.org/">webpack</a> を 4系から5系にアップグレードし、開発体験を向上させたお話です。</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*gdoQ1_5OID90wf1eLTFvWw.png" /><figcaption><a href="https://webpack.js.org/branding/">webpack</a></figcaption></figure><p>webpack 4 -&gt; 5 のアップグレードについては、<a href="https://www.google.com/search?q=webpack+4+5&amp;oq=webpack+4+5&amp;aqs=chrome.0.0l6j69i60l2.1484j0j7&amp;sourceid=chrome&amp;ie=UTF-8">既に多くの事例</a>がありますが、移行の手順や発生する問題というのは、プロダクトの特性や現在の構成に大きく依存するところもあるため、スタディストではどうだったかを改めて紹介致します。</p><h4>TL;DR</h4><ul><li>webpack 4.x から webpack 5.x へのアップグレードはすんなりできた</li><li>ビルドコストを 1/3 削減することができた</li><li>Dependabot から通知される脆弱性のほとんどに対応もできた</li></ul><h4>TeachmeBiz の技術構成</h4><p>TeachmeBiz のフロントエンドは、主に以下の技術構成となっています。</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*cHecQFybaa5w4Ld_dpIUUg.png" /></figure><p>基本的には <a href="https://jp.vuejs.org/index.html">Vue</a> を用いた SPA で、 <a href="https://ja.nuxtjs.org/">Nuxt.js</a> などのフレームワークは使用していないため、 <a href="https://babeljs.io/">Babel</a> / <a href="https://www.typescriptlang.org/">TypeScript</a> を含めた webpack 周りを自分たちで管理しています。</p><p>そのため、以下の webpack 関連パッケージに依存しています。(内、<strong>太字</strong>が特にアップグレードの影響を受けるパッケージ)</p><ul><li><strong>webpack 4.42.1</strong></li><li><strong>webpack-cli 3.3.11</strong></li><li><strong>webpack-dev-server 3.10.3</strong></li><li><strong>webpack-manifest-plugin 2.0.3</strong></li><li><strong>webpack-merge 4.1.3</strong></li><li><strong>hard-source-webpack-plugin 0.13.1</strong></li><li>terser-webpack-plugin 3.0.2</li><li>moment-locales-webpack-plugin 1.1.0</li><li>babel-loader 8.0.6</li><li>css-loader 1.0.1</li><li>file-loader 1.1.11</li><li>sass-loader 7.0.3</li><li>style-loader 0.21.0</li><li>vue-loader 15.6.2</li><li>vue-style-loader 0.21.0</li><li><strong>@storybook/vue 6.2.9</strong></li></ul><p>webpack 5 がリリースされたのは<a href="https://github.com/webpack/webpack/releases/tag/v5.0.0">2020年10月</a>でしたが、TeachmeBiz では上記の通り、多くの 関連パッケージに依存しているため、それら全てが webpack 5 をサポートするのを待つ必要がありました。</p><p>2021年06月、webpack 5 のサポートを含んだ <a href="https://storybook.js.org/blog/storybook-6-3/">Storybook 6.3 </a>がリリースされ、ようやく全てのツールが対応されたことから、満を持してアップグレード作業をはじめました。</p><h4>アップグレード手順</h4><p>今回実施したアップグレード作業は、概ね以下の流れになっています。</p><ol><li>マイグレーションガイドを一読する</li><li>関連パッケージを最新化</li><li>ビルドする</li><li>エラーが出る</li><li>エラーを対処する</li><li>ビルドに成功するまで 4,5の繰り返し</li><li>CI が通るまで 4,5 の繰り返し</li></ol><p>本記事では割愛しますが、弊社には強力な自動テストプロセス(単体テスト、コンポーネントテスト、E2Eテスト、Visual Regression Test) が整備されているため、人力による検証は最後の最後に QA にお願いするだけで、基本的には CI での検証のみとなっています。</p><h4>マイグレーションガイドを一読</h4><p>パッケージを更新するとか、設定ファイルを調整するといった作業に入る前に、公式から案内されている<a href="https://webpack.js.org/migrate/5/">マイグレーションガイド</a>に目を通します。</p><p>いくつか、後述する個々のトラブルシューティングに必須の内容も含まれていますが、全体を通して以下を意識して進めることにしました。</p><ul><li>パッケージは全て最新版を利用する</li><li><strong>— trace-deprecation</strong> オプションなど、警告を出力する設定を常に使う</li></ul><h4>パッケージの一括アップグレード</h4><p>続けて関連パッケージのバージョンを上げます。メジャーバージョンが上がったパッケージだけ抜き出しても、このぐらい上がりました。</p><ul><li>webpack 4.x → 5.38.1</li><li>webpack-cli 3.x → 4.7.0</li><li>webpack-manifest-plugin 2.x → 3.x</li><li>webpack-merge 4.x → 5.x</li><li>file-loader 1.x → 6.x</li><li>css-loader 1.x → 5.x</li><li>sass-loader 7.x → 12.x</li><li>style-loader 0.21.x → 2.x</li></ul><p>また、<a href="https://dependabot.com/">Dependabot</a> から通知される脆弱性通知のほとんどを、これによって解消することができました。多くは開発環境に限定され、緊急度の低い脆弱性ではありましたが、こういったタイミングで潰しておくことで、本当に重要な脆弱性を見逃さずに済むと思います。</p><h4>サポートブラウザを明示する</h4><p>webpack 5 では、デフォルトで ES2015 を含んだランタイムコードを生成するようになりました。そのため、IE11 のようなレガシーブラウザをサポートするプロダクトの場合、明示的にサポートブラウザを指定する必要があります。</p><p>設定方法はいくつかありますが、package.json 内に <a href="https://github.com/browserslist/browserslist">browserslist</a> の定義があれば、それを参照してくれるため、<a href="https://babeljs.io/docs/en/babel-preset-env">@babel/preset-env</a> など他のツールでも参照できるように、ここで一元管理します。</p><pre>&quot;browserslist&quot;: [<br>  &quot;IE 11&quot;,<br>  &quot;last 1 chrome versions&quot;,<br>  &quot;last 1 ChromeAndroid versions&quot;,<br>  &quot;last 1 firefox versions&quot;,<br>  &quot;last 1 safari versions&quot;,<br>  &quot;iOS &gt;= 11.4&quot;<br>]</pre><h4>ビルドキャッシュを有効化する</h4><p>webpack 5 からは、ビルド結果をキャッシュして再ビルド時に差分ビルドだけで済ませることでパフォーマンスを改善する、<a href="https://webpack.js.org/guides/caching/">キャッシュ機能</a>が本体に組み込まれています。</p><p>キャッシュ機能はビルド効率が高まる反面、キャッシュの作り方次第ではビルドに失敗するリスクも含んでいます。Teachme Biz では元々 <a href="https://zenn.dev/sa2knight/articles/7e4d6b43780d9fc47ab1">webpack-hardsource-plugin</a> を用いてキャッシュを使用していたため、リスクよりも効率を優先し、引き続きキャッシュを使っていきます。(development/test環境のみ)</p><pre>cache: {<br>  type: &#39;filesystem&#39;,<br>  buildDependencies: {<br>    config: [__filename]<br>  }<br>}</pre><h4>file-loader / url-loader を廃止し、Asset Modules を使用する</h4><p>webpack 4 以前では、画像ファイルへの依存を解決するために、 <a href="https://v4.webpack.js.org/loaders/file-loader/">file-loader</a> などのローダーを別途設定する必要がありましたが、webpack 5 からは <a href="https://webpack.js.org/guides/asset-modules/">Asset Modules</a> の仕組みを使うことで、ローダーなしで依存解決できるようになりました。</p><pre>module: {<br>  rules: {<br>    test: /\.(png|jpe?g|gif|svg|cur|mp4)(\?.*)?$/,<br>    type: &#39;asset/resource&#39;<br>  }<br>}</pre><h4>プラグインのインポート方法を変更</h4><p>webpack-manifest-plugin / webpack-merge は、メジャーバージョンが上がり、エクスポートされるオブジェクトの構造が変化したため、インポート側も修正します。</p><pre>// 旧<br>const merge = require(&#39;webpack-merge&#39;)<br>const ManifestPlugin = require(&#39;webpack-manifest-plugin&#39;)</pre><pre>// 新<br>const { merge } = require(&#39;webpack-merge&#39;)<br>const { WebpackManifestPlugin } = require(&#39;webpack-manifest-plugin&#39;)</pre><h4>webpack-dev-server の実行コマンドを変更</h4><p>開発用サーバである webpack-dev-server の実行コマンドが変更され、webpack-cli を用いるようになったため、あわせて変更します。</p><pre>$ yarn webpack-dev-server // 旧<br>$ yarn webpack-cli serve  // 新</pre><h4>Storybook を動くようにする</h4><p>Storybook 6.3 から、満を持して webpack 5 が正式にサポートされました。</p><p>本バージョンでは、Storybook 全体をビルドするための Manager Builder と、個々のストーリー(≒コンポーネント) を描画するための Preview Builder が分離され、Preview Builder として webpack 5 が使えるようになりました。(詳細は<a href="https://storybook.js.org/blog/storybook-for-webpack-5/">公式ブログ</a>参照)</p><p>Preview Builder の変更は、専用パッケージを導入します。</p><pre>$ yarn add -D @storybook/builder-webpack5<br>$ yarn add -D @storybook/manager-webpack5</pre><p>builder に webpack5 を使用することを .storybook/main.js に記述します。</p><pre>module.exports = {<br>  core: {<br>    builder: &#39;webpack5&#39;<br>  }<br>}</pre><h4>パフォーマンスを計測する</h4><p>以上の工程を得て、概ね対応は完了したので、 webpack 4 から 5 へのアップグレードによるビルドコストがどう変化したのかを評価します。</p><p>Web 開発における webpack の役割は幅広く、何をもって改善したかを計測するのは難しいですが、今回は以下コマンドによるテスト用ビルドの実行時間を指標とします。</p><pre>$ yarn webpack --progress --color --config webpack/test.js</pre><p>webpack/test.js はテスト用の設定に一部書き換えたものですが、基本的な依存解決ルール、成果物のアウトプットルールは本番と同様になってます。</p><p>実行環境やキャッシュの有無での差異が生じないように、 <a href="https://circleci.com/ja/">CircleCI</a> を用いたコンテナ環境上で、 webpack 4 / webpack 5 のそれぞれのブランチでのジョブを確認します。</p><p>ランダムにサンプリングし、ビルド時間の平均値をとったところ、以下のような結果になりました。</p><blockquote>webpack 4.x: 54秒</blockquote><blockquote>webpack 5.x: 36秒</blockquote><p>正直どのあたりの改修が効いたのかはわかりませんが、実に1/3 ものビルドコストが削減できました。</p><h4>まとめ</h4><p>本記事のように、大きな基盤改善は行わずに、 webpack のバージョンを上げるだけでも、ビルドコストを大きく削減することができました。</p><p>とはいえ、それでも 36 秒もの時間がかかっている事実から、既に TeachmeBiz は webpack で開発をするには大きくなりすぎた印象も受けます。</p><p>そこで、次回は <a href="https://github.com/vitejs/vite">Vite</a> を始めとした、話題の <a href="https://github.com/evanw/esbuild">esbuild</a> を用いた爆速開発環境を構築し、開発環境と本番環境でそもそも基盤を分けるというアプローチにもトライしてみようと考えています。</p><h4>最後に</h4><p>スタディストでは、こういった技術基盤の改善にも力を入れています。</p><p>今後さらなる事業拡大を目指すためにも、より多くの仲間を求めているため、是非ご興味がありましたら下記リンクより、よろしくおねがいします。</p><ul><li><a href="https://www.wantedly.com/projects/676472">BtoB SaaS を扱うマイクロサービス開発チームのWebエンジニア募集 by 株式会社スタディスト</a></li><li><a href="https://www.wantedly.com/projects/676450">BtoB SaaS を扱う動画編集機能開発チームのWebエンジニア募集 by 株式会社スタディスト</a></li></ul><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=3df31da8e7a2" width="1" height="1" alt=""><hr><p><a href="https://medium.com/studist-dev/migration-webpack-from-4-to-5-3df31da8e7a2">webpack 5 に移行しました</a> was originally published in <a href="https://medium.com/studist-dev">スタディスト開発ブログ</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>

webpack 5 にアップグレードしました
スタディスト 開発部 技術支援ユニットの笹木 (@s_sasaki_0529) です。
今回は、弊社が開発・運用している TeachmeBiz でも使用している、webpack を 4系から5系にアップグレードし、開発体験を向上させたお話です。
webpack
webpack 4 -> 5 のアップグレードについては、既に多くの事例がありますが、移行の手順や発生する問題というのは、プロダクトの特性や現在の構成に大きく依存するところもあるため、スタディストではどうだったかを改めて紹介致します。
TL;DR

webpack 4.x から webpack 5.x へのアップグレードはすんなりできた
ビルドコストを 1/3 削減することができた
Dependabot から通知される脆弱性のほとんどに対応もできた

TeachmeBiz の技術構成
TeachmeBiz のフロントエンドは、主に以下の技術構成となっています。

基本的には Vue を用いた SPA で、 Nuxt.js などのフレームワークは使用していないため、 Babel / TypeScript を含めた webpack 周りを自分たちで管理しています。
そのため、以下の webpack 関連パッケージに依存しています。(内、太字が特にアップグレードの影響を受けるパッケージ)

webpack 4.42.1
webpack-cli 3.3.11
webpack-dev-server 3.10.3
webpack-manifest-plugin 2.0.3
webpack-merge 4.1.3
hard-source-webpack-plugin 0.13.1
terser-webpack-plugin 3.0.2
moment-locales-webpack-plugin 1.1.0
babel-loader 8.0.6
css-loader 1.0.1
file-loader 1.1.11
sass-loader 7.0.3
style-loader 0.21.0
vue-loader 15.6.2
vue-style-loader 0.21.0
@storybook/vue 6.2.9

webpack 5 がリリースされたのは2020年10月でしたが、TeachmeBiz では上記の通り、多くの 関連パッケージに依存しているため、それら全てが webpack 5 をサポートするのを待つ必要がありました。
2021年06月、webpack 5 のサポートを含んだ Storybook 6.3 がリリースされ、ようやく全てのツールが対応されたことから、満を持してアップグレード作業をはじめました。
アップグレード手順
今回実施したアップグレード作業は、概ね以下の流れになっています。

マイグレーションガイドを一読する
関連パッケージを最新化
ビルドする
エラーが出る
エラーを対処する
ビルドに成功するまで 4,5の繰り返し
CI が通るまで 4,5 の繰り返し

本記事では割愛しますが、弊社には強力な自動テストプロセス(単体テスト、コンポーネントテスト、E2Eテスト、Visual Regression Test) が整備されているため、人力による検証は最後の最後に QA にお願いするだけで、基本的には CI での検証のみとなっています。
マイグレーションガイドを一読
パッケージを更新するとか、設定ファイルを調整するといった作業に入る前に、公式から案内されているマイグレーションガイドに目を通します。
いくつか、後述する個々のトラブルシューティングに必須の内容も含まれていますが、全体を通して以下を意識して進めることにしました。

パッケージは全て最新版を利用する
— trace-deprecation オプションなど、警告を出力する設定を常に使う

パッケージの一括アップグレード
続けて関連パッケージのバージョンを上げます。メジャーバージョンが上がったパッケージだけ抜き出しても、このぐらい上がりました。

webpack 4.x → 5.38.1
webpack-cli 3.x → 4.7.0
webpack-manifest-plugin 2.x → 3.x
webpack-merge 4.x → 5.x
file-loader 1.x → 6.x
css-loader 1.x → 5.x
sass-loader 7.x → 12.x
style-loader 0.21.x → 2.x

また、Dependabot から通知される脆弱性通知のほとんどを、これによって解消することができました。多くは開発環境に限定され、緊急度の低い脆弱性ではありましたが、こういったタイミングで潰しておくことで、本当に重要な脆弱性を見逃さずに済むと思います。
サポートブラウザを明示する
webpack 5 では、デフォルトで ES2015 を含んだランタイムコードを生成するようになりました。そのため、IE11 のようなレガシーブラウザをサポートするプロダクトの場合、明示的にサポートブラウザを指定する必要があります。
設定方法はいくつかありますが、package.json 内に browserslist の定義があれば、それを参照してくれるため、@babel/preset-env など他のツールでも参照できるように、ここで一元管理します。
"browserslist": [
  "IE 11",
  "last 1 chrome versions",
  "last 1 ChromeAndroid versions",
  "last 1 firefox versions",
  "last 1 safari versions",
  "iOS >= 11.4"
]
ビルドキャッシュを有効化する
webpack 5 からは、ビルド結果をキャッシュして再ビルド時に差分ビルドだけで済ませることでパフォーマンスを改善する、キャッシュ機能が本体に組み込まれています。
キャッシュ機能はビルド効率が高まる反面、キャッシュの作り方次第ではビルドに失敗するリスクも含んでいます。Teachme Biz では元々 webpack-hardsource-plugin を用いてキャッシュを使用していたため、リスクよりも効率を優先し、引き続きキャッシュを使っていきます。(development/test環境のみ)
cache: {
  type: 'filesystem',
  buildDependencies: {
    config: [__filename]
  }
}
file-loader / url-loader を廃止し、Asset Modules を使用する
webpack 4 以前では、画像ファイルへの依存を解決するために、 file-loader などのローダーを別途設定する必要がありましたが、webpack 5 からは Asset Modules の仕組みを使うことで、ローダーなしで依存解決できるようになりました。
module: {
  rules: {
    test: /\.(png|jpe?g|gif|svg|cur|mp4)(\?.*)?$/,
    type: 'asset/resource'
  }
}
プラグインのインポート方法を変更
webpack-manifest-plugin / webpack-merge は、メジャーバージョンが上がり、エクスポートされるオブジェクトの構造が変化したため、インポート側も修正します。
// 旧
const merge = require('webpack-merge')
const ManifestPlugin = require('webpack-manifest-plugin')
// 新
const { merge } = require('webpack-merge')
const { WebpackManifestPlugin } = require('webpack-manifest-plugin')
webpack-dev-server の実行コマンドを変更
開発用サーバである webpack-dev-server の実行コマンドが変更され、webpack-cli を用いるようになったため、あわせて変更します。
$ yarn webpack-dev-server // 旧
$ yarn webpack-cli serve  // 新
Storybook を動くようにする
Storybook 6.3 から、満を持して webpack 5 が正式にサポートされました。
本バージョンでは、Storybook 全体をビルドするための Manager Builder と、個々のストーリー(≒コンポーネント) を描画するための Preview Builder が分離され、Preview Builder として webpack 5 が使えるようになりました。(詳細は公式ブログ参照)
Preview Builder の変更は、専用パッケージを導入します。
$ yarn add -D @storybook/builder-webpack5
$ yarn add -D @storybook/manager-webpack5
builder に webpack5 を使用することを .storybook/main.js に記述します。
module.exports = {
  core: {
    builder: 'webpack5'
  }
}
パフォーマンスを計測する
以上の工程を得て、概ね対応は完了したので、 webpack 4 から 5 へのアップグレードによるビルドコストがどう変化したのかを評価します。
Web 開発における webpack の役割は幅広く、何をもって改善したかを計測するのは難しいですが、今回は以下コマンドによるテスト用ビルドの実行時間を指標とします。
$ yarn webpack --progress --color --config webpack/test.js
webpack/test.js はテスト用の設定に一部書き換えたものですが、基本的な依存解決ルール、成果物のアウトプットルールは本番と同様になってます。
実行環境やキャッシュの有無での差異が生じないように、 CircleCI を用いたコンテナ環境上で、 webpack 4 / webpack 5 のそれぞれのブランチでのジョブを確認します。
ランダムにサンプリングし、ビルド時間の平均値をとったところ、以下のような結果になりました。
webpack 4.x: 54秒
webpack 5.x: 36秒
正直どのあたりの改修が効いたのかはわかりませんが、実に1/3 ものビルドコストが削減できました。
まとめ
本記事のように、大きな基盤改善は行わずに、 webpack のバージョンを上げるだけでも、ビルドコストを大きく削減することができました。
とはいえ、それでも 36 秒もの時間がかかっている事実から、既に TeachmeBiz は webpack で開発をするには大きくなりすぎた印象も受けます。
そこで、次回は Vite を始めとした、話題の esbuild を用いた爆速開発環境を構築し、開発環境と本番環境でそもそも基盤を分けるというアプローチにもトライしてみようと考えています。
最後に
スタディストでは、こういった技術基盤の改善にも力を入れています。
今後さらなる事業拡大を目指すためにも、より多くの仲間を求めているため、是非ご興味がありましたら下記リンクより、よろしくおねがいします。

BtoB SaaS を扱うマイクロサービス開発チームのWebエンジニア募集 by 株式会社スタディスト
BtoB SaaS を扱う動画編集機能開発チームのWebエンジニア募集 by 株式会社スタディスト

webpack 5 に移行しました was originally published in スタディスト開発ブログ on Medium, where people are continuing the conversation by highlighting and responding to this story.

webpack 5 に移行しました

<p>スタディスト 開発部 技術支援グループの笹木(<a href="https://twitter.com/s_sasaki_0529">@s_sasaki_0529</a>) です。</p><p>技術支援グループ(旧 開発基盤チーム) では、開発チームを横断した技術的なサポートや、生産性向上のための仕組み作りを行っています。</p><p>前回、以下の記事にて、弊社でのフロントエンド技術の変化をご紹介致しました。</p><p><a href="https://medium.com/studist-dev/frontend-team-at-studist-a91580d97bb7">移り変わりの早いフロントエンドに対するスタディストの取り組み</a></p><p>今回は、上記記事でも簡単にご紹介させていただいた、<a href="https://storybook.js.org/"><strong>Storybook</strong></a><strong> のバージョンを 5.x から 6.1 にアップグレードしつつ、レガシー化した既存コードの全リプレイスを行うことで、フロントエンドの開発体験を向上させた 取り組み</strong>について、詳細をお話致します。</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*vBsTs3N8I6qOyIE91QM6yw.png" /><figcaption>Storybook 6.1 上で動作する Teachme Biz</figcaption></figure><h3>Teachme Biz フロントエンドの事情</h3><p>スタディストが運営する <a href="https://biz.teachme.jp/">Teachme Biz</a> のWebフロントエンドは、<a href="https://jp.vuejs.org/index.html">Vue.js</a> を用いて実装されており、本記事執筆時点で、<strong>430個</strong>のコンポーネントを内包しています。</p><p>各コンポーネントは、<strong>Atomic Design パターン </strong>を一部アレンジした階層構造となっており、上位のコンポーネントは、下位のコンポーネントを組み合わせて実装されています。</p><p>そのほかにも、ドメイン、データストアに干渉できるコンポーネントの制限など、いくつかのルールがありますが、詳細は以下スライドでもご紹介しているので割愛致します。</p><iframe src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2Fembed_code%2Fkey%2FH0n4m9HU4YWEAM&amp;display_name=SlideShare&amp;url=https%3A%2F%2Fwww.slideshare.net%2Fshingosasaki3%2Fteachmebiz-188542240&amp;image=https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fvuearchitectureforteachmebiz-191030082428-thumbnail-4.jpg%3Fcb%3D1572423947&amp;key=a19fcc184b9711e1b4764040d3dc5c07&amp;type=text%2Fhtml&amp;schema=slideshare" width="600" height="500" frameborder="0" scrolling="no"><a href="https://medium.com/media/4c6e22b26312edff7701cd66d83d1f97/href">https://medium.com/media/4c6e22b26312edff7701cd66d83d1f97/href</a></iframe><p>以上のように、大量のコンポーネントが階層管理されており、設計ルールも細かく整備されている以上、コンポーネントの追加改修を闇雲に行うことはできません。</p><p>Teachme Biz では、これを解決するため、Storybook を用いたコンポーネントのカタログ化を3年ほど前から行ってきました。</p><ul><li><a href="https://medium.com/studist-dev/storybook-with-vuex-7084bea6b509">実践StorybookでVuexに立ち向かう</a></li><li><a href="https://medium.com/studist-dev/storybook-d879178318b2">Storybookの可能性を見せびらかしたい</a></li></ul><p><em>※ 上記関連記事は、一部内容が古くなっております</em></p><h3>旧 Storybook の問題点</h3><p>Storybook によるカタログ化は、Storybook 3.x 系から始まりました。後に 5.x へのアップグレードこそ行いましたが、基本的なストーリーの書き方や、アドオンの活用、運用ルールなどは、依然として 3.x 時代から変化がないままでした。</p><p>そういった状態のまま、プロダクトや開発チームはスケールし、それに比例してコンポーネント数やソースコードの複雑性も右肩上がりに増えていきました。</p><p>次第にレガシー化し、惰性で運用されるようになった Storybook には、以下のような問題が現れました。</p><ul><li>愚直に既存コードをコピペしただけのストーリーが増え続ける</li><li>ストーリーの書き方、方針が実装時期によってバラバラ</li><li>旧バージョンのアドオンに依存したハックが多く、保守が困難</li><li>ストーリー数の増加による、Storybook 全体のパフォーマンス劣化</li><li>スナップショットテストを運用しても、安定しないテストが量産される</li></ul><p>本体のバージョンアップをすれば、既存の仕組みは動かなくなり、既存コードを直そうとすると、旧バージョンであることが足枷になる。その間も ストーリーは増え続けるという、まさに袋小路な状態となっていました。</p><p>こういった状態を抜け出し、惰性ではない、開発生産性を高めるための Storybook 運用を取り戻すべく、 <strong>Storybook 及びアドオンの最新化と、既存コードの全リプレイス</strong>の決意に至りました。</p><h3>Storybook 及び アドオンの最新化</h3><p>着手開始時点では、Storybook 6.0 がリリースされたばかりだったため、以下のマイグレーションガイドを参考に、既存の仕組みが動かなくなることを受け入れつつ、マイグレーションを実施しました。</p><p><a href="https://storybook.js.org/blog/storybook-6-migration-guide/">Storybook 6 Migration Guide</a></p><p>Storybook 6.0 には、パフォーマンス上の課題があり、同じコードでも 5.x よりも遅いという問題がありました。この問題は、続けてリリースされた 6.1 で大きく改善されることがわかったため、α版の段階から採用することで解決しました。</p><p><a href="https://storybook.js.org/blog/storybook-6-1/">Storybook 6.1</a></p><h3>CSF による既存コードのリプレイス</h3><p><strong>CSF(Component Story Format) </strong>は、Storybook 5.2 からサポートされた、 ストーリーを記述するための新しいフォーマットです。</p><p><a href="https://medium.com/storybookjs/component-story-format-66f4c32366df">Component Story Format</a></p><p>CSFは Storybook 5.2 からサポートされていましたが、3.x 時代からストーリーの書き方を変えていなかった私たちにとっては、6.x と同時に現れた新しい概念です。</p><p>従来の storiesOf API 方式では、 storiesOf という、Storybook が提供する API をストーリーファイル側から呼び出すことで、ストーリーの定義を Storybook に知らせます。(<a href="https://medium.com/storybookjs/component-story-format-66f4c32366df">コード引用元</a>)</p><pre>storiesOf(&#39;atoms/Button&#39;, module)<br>  .add(&#39;text&#39;, () =&gt; &lt;Button&gt;Hello&lt;/Button&gt;)<br>  .add(&#39;emoji&#39;, () =&gt; &lt;Button&gt;😀😎👍💯&lt;/Button&gt;);</pre><p>対して CSF 形式では、 ES6 modules に基づき、デフォルトエクスポートと名前付きエクスポートを組み合わせることで、宣言的にストーリーを記述することができます。(<a href="https://medium.com/storybookjs/component-story-format-66f4c32366df">コード引用元</a>)</p><pre>export default { title: &#39;atoms/Button&#39; };<br>export const text = () =&gt; &lt;Button&gt;Hello&lt;/Button&gt;;<br>export const emoji = () =&gt; &lt;Button&gt;😀😎👍💯&lt;/Button&gt;;</pre><p>CSF 形式は、上記のようにストーリーファイル自体が Storybook に対して一切依存しないため、Storybook 以外での汎用的なコンポーネントフォーマットとして期待されています。</p><p>また、名前付きエクスポート時の変数名がそのままストーリー名になるなど、簡易的にストーリーを記述するための仕組みが豊富に備わっているため、少ないコード量で効率的に記述することができます。</p><p>上記の例は React でしたが、 Vue の場合、以下のようなテンプレートを用いることで、均一なコード品質で様々なストーリーを定義することができます。</p><pre>import ComponentName from &#39;./ComponentName&#39;<br>export default { title: &#39;ComponentName&#39; }</pre><pre>const Template = (args, { argTypes }) =&gt; ({<br>  components: { ComponentName },<br>  props: Object.keys(argTypes),<br>  template: `&lt;ComponentName v-bind=&quot;$props&quot; /&gt;`<br>})</pre><pre>export const Default = Template.bind({})<br>Default.args = {<br>  props1: true<br>}</pre><pre>export const Custom = Template.bind({})<br>Custom.args = {<br>  ...Default.args,<br>  props2: false<br>}</pre><p>上記は、 ComponentName というコンポーネントに対して Default Custom という名前の2種類のストーリーを定義します。 Default と Custom は、同じコンポーネントを描画しますが、割り当てる props が異なります。</p><p>また、 <a href="https://storybook.js.org/docs/vue/essentials/controls">addon-controls</a>と組み合わせることで、上記の形式で指定した props を、Storybook 上で動的に切り替えることも容易に実現できます。</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/496/1*EzRg5GYLbMC6JnO8wgCzHA.gif" /><figcaption>CSF を使った props を動的に書き換えるストーリー</figcaption></figure><p>こういった Storybook における頻出パターンを CSF では手軽に書けるようになったため、リプレイス作業が想定よりも大幅に楽になりました。</p><p>なお、CSF 及び Storybook 6 の基本的な使い方については、手前味噌ではありますが、別途記事を投稿しているので気になる方はご参照ください。</p><p><a href="https://zenn.dev/sa2knight/books/aca5d5e021dd10262bb9">Vue と CSF によるモダンな Storybook 6 のはじめかた</a></p><p>リプレイスにあたっては、既存のストーリーをそのまま CSF で書き直すだけでなく、以下のような新しい基準を設け、必要十分なだけ作成するようにしました。</p><ul><li>見た目に大きな変化を与える Props がある場合はストーリーを分ける</li><li>インタラクションに変化を与える Props については考慮しない</li><li>(addon-actions などを用いた) イベント(emit) への対応は不要</li><li>上位コンポーネントと密で、固有の状態を持たないコンポーネントは対応しない</li><li>グローバルストアを参照し、それによって見た目が大きく変わる場合、ストアのモックを活用する</li></ul><p>いずれも見た目の変化に注目しているのは、デザイナーとのコラボレーションや、スナップショットテストでの活用を意識しているためです。振る舞いに関しては E2Eテストを別途管理しているため、Storybook では重要視していません。</p><p>以上のような方針とストーリーのテンプレートまで出来上がってしまえば、残りのリプレイス作業は人海戦術です。方針と手順を開発チームに共有し、少しずつ協力をお願いすることで、252 種類のストーリーを、通常業務を止めずに、2週間程度で完了することができました。</p><h3>CSF を応用した Storybook の活用術</h3><p>前項でご紹介した、CSF を用いることで、ストーリーを描画する以外にも、Storybook を用意に応用できるようになりました。今回は、その中でも以下の二つの仕組みをご紹介します。</p><ul><li>Storybook 内での vue-i18n の locale 切り替え</li><li>Storybook 上での vue-router による画面遷移</li></ul><h4>Storybook 内での vue-i18n の locale 切り替え</h4><p>Teachme Biz では、日本語のほか、英語とタイ語をサポートしており、言語の切り替えはブラウザの設定に基づいて行われます。</p><p>しかし、翻訳漏れの確認や、言語ごとにレイアウト崩れが無いかを検証するために、いちいちブラウザの設定を切り替えるのは非効率です。</p><p>そこで、以下のように Storybook 上のツールバーから、容易に言語を切り替えられるようにしました。</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/664/1*jPL1zujZ_pY_aTG5-h-ljw.gif" /><figcaption>Storybook 上のツールバーから言語を切り替えるデモ</figcaption></figure><p>これまでも同様の仕組みは提供していましたが、 <a href="https://www.npmjs.com/package/@storybook/addon-knobs">addon-knobs</a> を使った、ややハックな仕組みにしていたため、メンテナンスがしづらい問題がありました。</p><p>Storybook 6.0 からは CSF のような宣言的な記述で、 Storybook 全体の設定を .storybook/preview.js に書けるようになり、以下のようなコードを export するだけで、ツールバーに言語を選択するメニューが追加されます。</p><pre>export const globalTypes = {<br>  locale: {<br>    defaultValue: &#39;ja&#39;,<br>    toolbar: {<br>      icon: &#39;globe&#39;,<br>      items: [&#39;ja&#39;, &#39;en&#39;, &#39;th&#39;]<br>    }<br>  }<br>}</pre><p>上記 globalTypes で設定されたパラメータ(≒現在選択中の言語) は、<a href="https://storybook.js.org/docs/react/writing-stories/decorators">デコレータ関数</a>から参照することができるため、 vue-i18n を設定し直した Vueコンポーネントで、ストーリーをラップすることで、選択中の言語でストーリーを描画することができます。</p><pre>(story, context) =&gt; {<br>  i18n.locale = context.globals.locale<br>  return {<br>    i18n,<br>    router: new VueRouter({}),<br>    store: new Vuex.Store(storeOption),<br>    template: `&lt;story /&gt;`<br>  }<br>},</pre><h4>Storybook 上での vue-router による画面遷移</h4><p>Storybook はコンポーネントカタログ用のツールではありますが、擬似的にアプリケーションをStorybook上で動かしつつ、サーバサイドと関わる <a href="https://vuex.vuejs.org/">Vuex</a><em> </em>をモックすることで、サンドボックス上での画面遷移からデータの表示までを実現することができます。</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*h3eIzaEWZ93fy8hZF6x90g.gif" /><figcaption>Storybook の中で縦横無尽に画面遷移する図</figcaption></figure><p><a href="https://medium.com/studist-dev/storybook-d879178318b2">Storybookの可能性を見せびらかしたい</a></p><p>Vuex のモック方法については、上記記事で紹介されている当時の方法そのままなので割愛しますが、<a href="https://router.vuejs.org/">vue-router</a> 用のルーティング設定を元に、CSF を使うことで効率よくページ単位のストーリーを作ることができました。</p><pre>const load = (name, params = {}, query = {}) =&gt; {<br>  return () =&gt; ({<br>    components: { App },<br>    template: `&lt;App :requireAuth=&quot;false&quot; /&gt;`,<br>    router: new VueRouter({ routes, mode: &#39;hash&#39; }),<br>    created() {<br>      this.$router.push({ name, params, query })<br>    }<br>  })<br>}</pre><pre>export const PageA = load(&#39;PageA&#39;)<br>export const PageB = load(&#39;PageB&#39;)<br>export const PageC = load(&#39;PageC&#39;)</pre><p>App は Vueアプリケーションのルートコンポーネントで、いずれのページも App をそのまま描画します。</p><p>異なるのは、それぞれ load 関数で指定されたページ名を使って、 App 生成時に、それぞれのページに遷移させることで、それぞれのページを描画してくれるストーリーを動的に生成できるようになりました。</p><h3>残された課題</h3><p>ここまでの改修で、開発者にとって開発及び検証しやすい Storybook を取り戻すことが完了したと言えます。</p><p>しかし、Storybook と Atomic Design という組み合わせで開発しているにも関わらず、エンジニアとデザイナーの協業がイマイチ出来ていないという課題感が現れてきました。</p><p>この課題解決のためには、<a href="https://www.figma.com/">Figma</a> と Storybook を連動させるといった仕組み的なアプローチから、デザイナーが Vue の世界に踏み込んだり、エンジニアがデザインに関与する、いわゆるクロスファンクショナル化など、色々な策は考えられます。</p><p>いずれにしても、技術支援グループとしては引き続き、技術の力でその足がかりをサポートできたらと考えているため、今後も Storybook の整備は続きそうです。</p><p>スタディストでは現在、手順書作成・共有サービス Teachme Biz を一緒に開発していくエンジニアの仲間を募集しています。本記事のような、課題に対して自発的に技術で向き合える職場ですので是非！</p><p><a href="https://www.wantedly.com/companies/studist/projects">株式会社スタディストの採用/求人一覧 - Wantedly</a></p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=42da05471e7d" width="1" height="1" alt=""><hr><p><a href="https://medium.com/studist-dev/upgrade-to-storybook-6-42da05471e7d">Storybook 6.1 へのアップグレートと、既存ストーリーを全リプレイスした話</a> was originally published in <a href="https://medium.com/studist-dev">スタディスト開発ブログ</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>

スタディスト 開発部 技術支援グループの笹木(@s_sasaki_0529) です。
技術支援グループ(旧 開発基盤チーム) では、開発チームを横断した技術的なサポートや、生産性向上のための仕組み作りを行っています。
前回、以下の記事にて、弊社でのフロントエンド技術の変化をご紹介致しました。
移り変わりの早いフロントエンドに対するスタディストの取り組み
今回は、上記記事でも簡単にご紹介させていただいた、Storybook のバージョンを 5.x から 6.1 にアップグレードしつつ、レガシー化した既存コードの全リプレイスを行うことで、フロントエンドの開発体験を向上させた 取り組みについて、詳細をお話致します。
Storybook 6.1 上で動作する Teachme Biz
Teachme Biz フロントエンドの事情
スタディストが運営する Teachme Biz のWebフロントエンドは、Vue.js を用いて実装されており、本記事執筆時点で、430個のコンポーネントを内包しています。
各コンポーネントは、Atomic Design パターン を一部アレンジした階層構造となっており、上位のコンポーネントは、下位のコンポーネントを組み合わせて実装されています。
そのほかにも、ドメイン、データストアに干渉できるコンポーネントの制限など、いくつかのルールがありますが、詳細は以下スライドでもご紹介しているので割愛致します。
https://medium.com/media/4c6e22b26312edff7701cd66d83d1f97/href
以上のように、大量のコンポーネントが階層管理されており、設計ルールも細かく整備されている以上、コンポーネントの追加改修を闇雲に行うことはできません。
Teachme Biz では、これを解決するため、Storybook を用いたコンポーネントのカタログ化を3年ほど前から行ってきました。

実践StorybookでVuexに立ち向かう
Storybookの可能性を見せびらかしたい

※ 上記関連記事は、一部内容が古くなっております
旧 Storybook の問題点
Storybook によるカタログ化は、Storybook 3.x 系から始まりました。後に 5.x へのアップグレードこそ行いましたが、基本的なストーリーの書き方や、アドオンの活用、運用ルールなどは、依然として 3.x 時代から変化がないままでした。
そういった状態のまま、プロダクトや開発チームはスケールし、それに比例してコンポーネント数やソースコードの複雑性も右肩上がりに増えていきました。
次第にレガシー化し、惰性で運用されるようになった Storybook には、以下のような問題が現れました。

愚直に既存コードをコピペしただけのストーリーが増え続ける
ストーリーの書き方、方針が実装時期によってバラバラ
旧バージョンのアドオンに依存したハックが多く、保守が困難
ストーリー数の増加による、Storybook 全体のパフォーマンス劣化
スナップショットテストを運用しても、安定しないテストが量産される

本体のバージョンアップをすれば、既存の仕組みは動かなくなり、既存コードを直そうとすると、旧バージョンであることが足枷になる。その間も ストーリーは増え続けるという、まさに袋小路な状態となっていました。
こういった状態を抜け出し、惰性ではない、開発生産性を高めるための Storybook 運用を取り戻すべく、 Storybook 及びアドオンの最新化と、既存コードの全リプレイスの決意に至りました。
Storybook 及び アドオンの最新化
着手開始時点では、Storybook 6.0 がリリースされたばかりだったため、以下のマイグレーションガイドを参考に、既存の仕組みが動かなくなることを受け入れつつ、マイグレーションを実施しました。
Storybook 6 Migration Guide
Storybook 6.0 には、パフォーマンス上の課題があり、同じコードでも 5.x よりも遅いという問題がありました。この問題は、続けてリリースされた 6.1 で大きく改善されることがわかったため、α版の段階から採用することで解決しました。
Storybook 6.1
CSF による既存コードのリプレイス
CSF(Component Story Format) は、Storybook 5.2 からサポートされた、 ストーリーを記述するための新しいフォーマットです。
Component Story Format
CSFは Storybook 5.2 からサポートされていましたが、3.x 時代からストーリーの書き方を変えていなかった私たちにとっては、6.x と同時に現れた新しい概念です。
従来の storiesOf API 方式では、 storiesOf という、Storybook が提供する API をストーリーファイル側から呼び出すことで、ストーリーの定義を Storybook に知らせます。(コード引用元)
storiesOf('atoms/Button', module)
  .add('text', () => <Button>Hello</Button>)
  .add('emoji', () => <Button>😀😎👍💯</Button>);
対して CSF 形式では、 ES6 modules に基づき、デフォルトエクスポートと名前付きエクスポートを組み合わせることで、宣言的にストーリーを記述することができます。(コード引用元)
export default { title: 'atoms/Button' };
export const text = () => <Button>Hello</Button>;
export const emoji = () => <Button>😀😎👍💯</Button>;
CSF 形式は、上記のようにストーリーファイル自体が Storybook に対して一切依存しないため、Storybook 以外での汎用的なコンポーネントフォーマットとして期待されています。
また、名前付きエクスポート時の変数名がそのままストーリー名になるなど、簡易的にストーリーを記述するための仕組みが豊富に備わっているため、少ないコード量で効率的に記述することができます。
上記の例は React でしたが、 Vue の場合、以下のようなテンプレートを用いることで、均一なコード品質で様々なストーリーを定義することができます。
import ComponentName from './ComponentName'
export default { title: 'ComponentName' }
const Template = (args, { argTypes }) => ({
  components: { ComponentName },
  props: Object.keys(argTypes),
  template: `<ComponentName v-bind="$props" />`
})
export const Default = Template.bind({})
Default.args = {
  props1: true
}
export const Custom = Template.bind({})
Custom.args = {
  ...Default.args,
  props2: false
}
上記は、 ComponentName というコンポーネントに対して Default Custom という名前の2種類のストーリーを定義します。 Default と Custom は、同じコンポーネントを描画しますが、割り当てる props が異なります。
また、 addon-controlsと組み合わせることで、上記の形式で指定した props を、Storybook 上で動的に切り替えることも容易に実現できます。
CSF を使った props を動的に書き換えるストーリー
こういった Storybook における頻出パターンを CSF では手軽に書けるようになったため、リプレイス作業が想定よりも大幅に楽になりました。
なお、CSF 及び Storybook 6 の基本的な使い方については、手前味噌ではありますが、別途記事を投稿しているので気になる方はご参照ください。
Vue と CSF によるモダンな Storybook 6 のはじめかた
リプレイスにあたっては、既存のストーリーをそのまま CSF で書き直すだけでなく、以下のような新しい基準を設け、必要十分なだけ作成するようにしました。

見た目に大きな変化を与える Props がある場合はストーリーを分ける
インタラクションに変化を与える Props については考慮しない
(addon-actions などを用いた) イベント(emit) への対応は不要
上位コンポーネントと密で、固有の状態を持たないコンポーネントは対応しない
グローバルストアを参照し、それによって見た目が大きく変わる場合、ストアのモックを活用する

いずれも見た目の変化に注目しているのは、デザイナーとのコラボレーションや、スナップショットテストでの活用を意識しているためです。振る舞いに関しては E2Eテストを別途管理しているため、Storybook では重要視していません。
以上のような方針とストーリーのテンプレートまで出来上がってしまえば、残りのリプレイス作業は人海戦術です。方針と手順を開発チームに共有し、少しずつ協力をお願いすることで、252 種類のストーリーを、通常業務を止めずに、2週間程度で完了することができました。
CSF を応用した Storybook の活用術
前項でご紹介した、CSF を用いることで、ストーリーを描画する以外にも、Storybook を用意に応用できるようになりました。今回は、その中でも以下の二つの仕組みをご紹介します。

Storybook 内での vue-i18n の locale 切り替え
Storybook 上での vue-router による画面遷移

Storybook 内での vue-i18n の locale 切り替え
Teachme Biz では、日本語のほか、英語とタイ語をサポートしており、言語の切り替えはブラウザの設定に基づいて行われます。
しかし、翻訳漏れの確認や、言語ごとにレイアウト崩れが無いかを検証するために、いちいちブラウザの設定を切り替えるのは非効率です。
そこで、以下のように Storybook 上のツールバーから、容易に言語を切り替えられるようにしました。
Storybook 上のツールバーから言語を切り替えるデモ
これまでも同様の仕組みは提供していましたが、 addon-knobs を使った、ややハックな仕組みにしていたため、メンテナンスがしづらい問題がありました。
Storybook 6.0 からは CSF のような宣言的な記述で、 Storybook 全体の設定を .storybook/preview.js に書けるようになり、以下のようなコードを export するだけで、ツールバーに言語を選択するメニューが追加されます。
export const globalTypes = {
  locale: {
    defaultValue: 'ja',
    toolbar: {
      icon: 'globe',
      items: ['ja', 'en', 'th']
    }
  }
}
上記 globalTypes で設定されたパラメータ(≒現在選択中の言語) は、デコレータ関数から参照することができるため、 vue-i18n を設定し直した Vueコンポーネントで、ストーリーをラップすることで、選択中の言語でストーリーを描画することができます。
(story, context) => {
  i18n.locale = context.globals.locale
  return {
    i18n,
    router: new VueRouter({}),
    store: new Vuex.Store(storeOption),
    template: `<story />`
  }
},
Storybook 上での vue-router による画面遷移
Storybook はコンポーネントカタログ用のツールではありますが、擬似的にアプリケーションをStorybook上で動かしつつ、サーバサイドと関わる Vuex をモックすることで、サンドボックス上での画面遷移からデータの表示までを実現することができます。
Storybook の中で縦横無尽に画面遷移する図
Storybookの可能性を見せびらかしたい
Vuex のモック方法については、上記記事で紹介されている当時の方法そのままなので割愛しますが、vue-router 用のルーティング設定を元に、CSF を使うことで効率よくページ単位のストーリーを作ることができました。
const load = (name, params = {}, query = {}) => {
  return () => ({
    components: { App },
    template: `<App :requireAuth="false" />`,
    router: new VueRouter({ routes, mode: 'hash' }),
    created() {
      this.$router.push({ name, params, query })
    }
  })
}
export const PageA = load('PageA')
export const PageB = load('PageB')
export const PageC = load('PageC')
App は Vueアプリケーションのルートコンポーネントで、いずれのページも App をそのまま描画します。
異なるのは、それぞれ load 関数で指定されたページ名を使って、 App 生成時に、それぞれのページに遷移させることで、それぞれのページを描画してくれるストーリーを動的に生成できるようになりました。
残された課題
ここまでの改修で、開発者にとって開発及び検証しやすい Storybook を取り戻すことが完了したと言えます。
しかし、Storybook と Atomic Design という組み合わせで開発しているにも関わらず、エンジニアとデザイナーの協業がイマイチ出来ていないという課題感が現れてきました。
この課題解決のためには、Figma と Storybook を連動させるといった仕組み的なアプローチから、デザイナーが Vue の世界に踏み込んだり、エンジニアがデザインに関与する、いわゆるクロスファンクショナル化など、色々な策は考えられます。
いずれにしても、技術支援グループとしては引き続き、技術の力でその足がかりをサポートできたらと考えているため、今後も Storybook の整備は続きそうです。
スタディストでは現在、手順書作成・共有サービス Teachme Biz を一緒に開発していくエンジニアの仲間を募集しています。本記事のような、課題に対して自発的に技術で向き合える職場ですので是非！
株式会社スタディストの採用/求人一覧 - Wantedly

Storybook 6.1 へのアップグレートと、既存ストーリーを全リプレイスした話 was originally published in スタディスト開発ブログ on Medium, where people are continuing the conversation by highlighting and responding to this story.

Storybook 6.1 へのアップグレートと、既存ストーリーを全リプレイスした話

概要
この記事はCircleCI Advent Calendar 2020の9日目の記事です。
スタディスト開発部の笹木です。今年に入ってからは開発基盤チームという位置づけで、開発環境の整備や、CI含むテスト自動化周りを担当しています。
本記事では、RSpecのテスト実行時間を半減させ、CircleCIの消費クレジットを大幅削減した取り組みについてご紹介します。(消費クレジットについては後述します)
改善の結果が以下のグラフで、定点観測しているジョブの消費クレジットが、ピーク時の半分にまで落とせていることがわかります。もちろんテストコードを減らすといった本末転倒なことはしていません。
RSpecジョブ実行時の、CircleCI消費クレジットを時系列で表したグラフ
実施した取り組みは以下の通りです。

CircleCIの料金体系を知る
問題を認識する
CircleCIの利用状況を可視化する
RSpecの実行状況を可視化する
特に遅いテストをチューニングする
FactoryBotの全体最適化
CI上でのRSpec実行時に、Railsのログを吐かないようにする
並列テストをファイルサイズ別から実行タイミング別に変更
CIでの実行マシンのスペックを下げ、並列数をあげる
可能な限りCircleCIのビルド済みイメージを使用する

0. CircleCIの料金体系を知る
本記事では、CircleCIにおける消費クレジット という概念が大きな役割を持っています。
はじめに消費クレジット含め、CircleCIの料金体系についておさらいします。
クレジットとは?
クレジットは、マシンのタイプとサイズ、Docker レイヤー キャッシュなどの有料機能に基づく使用料の支払いに充てられます。
CircleCIには、Free, Performance, Custom の3段階のプランが用意されており、弊社では Performance プランを利用しています。
Performanceプランは下記表のとおり、「ユーザ数に応じた定額課金」と「クレジットの消費量に応じた従量課金」の組み合わせで料金が確定します。
引用元
ユーザ数についてはCIを利用する開発者の数と同じになりますが、クレジットはCIの実行時間、実行マシンの性能、その他オプション機能の利用によって消費量が決定するため、CIの運用方法次第で大きく変わります。
本記事では、CIを1回まわすごとに消費したクレジット量を消費クレジットと表記し、そこに着目した改善を施します。
1. 問題を認識する
まず、なぜCIを改善しようと動き出したかのキッカケについてです。
それまでは漫然とCIを動くまま使い倒し、テストケースの増加に伴い、CI実行時間及び消費クレジットが増え続けていくことを受け入れていました。 正確に言えば受け入れていたのではなく、問題を認識できていないのでした。
そんなある日、CircleCIのプロジェクトページを眺めていると利用状況のページが目に留まりました。
前年度は6,000,000クレジットぐらいだったのに…
「あれ、なんか今月ものすごい消費クレジットがハネてるな…。」
キッカケとしてはそれだけだったのですが、よく見てみると、今月たまたまハネていたのではなく、今年に入ってから急速に増えていき、半年のスパンで見ると大幅に予算を超えていたことがわかりました。
組織がスケールすればテストの総量及びCI実行回数が増えるため、消費クレジットが右肩上がりになるのは自然です。
しかし、それを考慮しても上がり幅が異常だと気が付きました。
2. CircleCIの利用状況を可視化する
アプリケーションのパフォーマンス改善の世界には、「推測するな、計測せよ」という名言があります。
これは、改善すべき対象を闇雲に改善するのではなく、正しく計測、評価し、目標に向かって最短経路での改善を実現しようという話で、アプリケーションに限らずCI周りの改善でも当てはまると思います。
そこで、まずは現状を可視化することがスタートだと考え、実行に移しました。
CircleCIのAPIでは、Insightsという、ワークフロー及びジョブの実行結果のサマリを取得するエンドポイントが提供されています。
例えば、ワークフロー “test” が定義されており、その中のジョブ “rspec” が、masterブランチで実行された場合のサマリは以下のURLで取得することができます。(リポジトリがGithubでホスティングされている場合)
https://circleci.com/api/v2/insights/github/:organization/:repository/workflows/test/jobs/rspec?branch=master
APIを叩くと、以下のように該当するジョブの「ID」「開始日時」「終了日時」「実行時間」「ステータス」「消費クレジット」を取得することが出来ます。
{
  "next_page_token" : null,
  "items" : [ {
    "id" : "30c1a7f0-1234-5678-9012-4dd8d44ef738",
    "started_at" : "2020-08-11T05:52:04.126Z",
    "stopped_at" : "2020-08-11T05:58:32.723Z",
    "duration" : 388,
    "status" : "success",
    "credits_used" : 417
  } ]
}
上記で言う実行時間(duration)と、消費クレジット(credits_used)が評価の対象になります。
このAPIを定期的に叩くスクリプトをGAS(Google Apps Script)で作成、スプレッドシートで自動集計するようにし、現状の可視化を行えるようにしました。
CircleCI利用状況可視化シートの一部
3. RSpecの実行状況を可視化する
続けて、RSpec によるテストについても、どのテストが遅いのかを可視化します。
RSpec には、 — profile というオプションが用意されており、これを指定して実行することで、特に実行時間がかかっているテストケース及びファイルをプロファイリングすることが出来ます。
Top 100 slowest examples (192.87 seconds, 8.2% of total time):
 HogeController ….
 5.61 seconds ./spec/controllers/hoge/hoge_controller_spec.rb:29
 Foo#Bar ….
 3.32 seconds ./spec/models/foo/bar_spec.rb:48
 Hige#Piyo ……
 3.28 seconds ./spec/models/hige/piyo_spec.rb:53
(中略)
Top 100 slowest example groups:
 Hoge#show
 2.59 seconds average (20.72 seconds / 8 examples) ./spec/requests/api/v2/hoge/show_spec.rb:8
 Fuga#export
 2.23 seconds average (17.86 seconds / 8 examples) ./spec/requests/api/v2/fuga/export_spec.rb:12
 Foo
 1.96 seconds average (13.75 seconds / 7 examples) ./spec/models/foo_spec.rb:5
 Bar
 1.8 seconds average (1.8 seconds / 1 example) ./spec/models/bar_spec.rb:6
 contents#index
(以下略)
このプロファイリングは、1回限りではなく、定期実行して改善の進捗を確認したいので、CIで定期実行している、テストカバレッジ計測ジョブに仕込みます。
bundle exec rspec spec/ --format progress —-profile 100
これでRSpec単体で見たときのパフォーマンスも監視できるようになりました。
4. 特に遅いテストをチューニングする
個々のテストコードをチューニングするよりも、実行基盤やテスト全体の最適化をしたほうが効果的。というのは頭では理解していましたが、前項で個々のテストのパフォーマンスを可視化してみたところ、思った以上に極端に遅いテストというのが多数あることが発覚しました。
一部のテストが極端に遅いという状況は、テストの総実行時間に影響を与えるのはもちろん、後述するタイミングデータに基づいたテストの並列化が正しく機能しない問題も抱えています。
極端に遅いテストには、以下のような特徴があったので、費用対効果を考慮しながら、テストの軽量化に取り組みました。
テスト観点において必要以上のデータが作られている
何をテストするのかを明らかにし、そのための必要十分な量のテストデータのみを作成するように修正します。
意図通りのテストが通ることにだけ安心してコミットしてしまいがちですが、テスト実行時のRailsのログを見ながら、不要なデータが生成されていないかをチェックします。
テスト観点が重複している
テスト観点の重複は、あとからジョインしたメンバーが、元々書かれていたテストコードをコピペして量産する場合などに起こりがちです。
多くの場合はコピペでも十分なテストコードでも、テスト観点を明らかにすることで、「このテストケースと、あそこのテストケースは重複しているな」といった判断が出来ます。
テスト観点が多すぎる
テストデータ生成などの前準備が高負荷なのに、テストの観点が多く、 it あるいは example が大量にあるようなテストの場合、その数だけ前準備処理が走ってしまい、テスト全体が非常に低速になってしまいます。
そういう場合は可読性、パフォーマンスとのトレードオフにはなりますが、 Aggregating Failures を用いて、一つのテストケースで複数の観点をチェックするようにすると良いでしょう。 (※これは比較的妥協案です)
5. FactoryBotの全体最適化
弊社では、RSpecによるRailsアプリケーションのテストのためのファクトリに、FactoryBot を使用しています。
これはActiveRecordによる実データの生成を、手軽かつ柔軟に行うことができるツールで、様々な状況のデータを必要とするリクエストスペックなどでは特に重宝します。
しかし、その柔軟さから、一度作られたファクトリは魔法のように動き、どんなデータが作成されるのかが使い手からは想像がつかなくなってしまう場合があります。
以下は実際にあったファクトリコードを模倣したコードになります。
FactoryBot.define do
  factory :folder do
    name { SecureRandom.hex[0..5] }
    trait :with_users do
      after :create do |instance|
        instance.users.create(FactoryBot.create_list(:user, 5))
      end
    end
  end
end
FactoryBot.create(:folder, :with_users) を実行すると、フォルダ及びそのフォルダに所属しているユーザが5人生成されるというファクトリーです。
お気づきかと思いますが、with_users という trait は、「ユーザが5人参加しているフォルダを作りたい」という非常に限定的な条件下でしか活用できません。
しかし、後からジョインし、既存のテストコードをコピーして新しいテストを書くメンバがいた場合、 「ユーザが1人参加しているフォルダを作りたい」 場面でも、この with_users をつい使ってしまいます。
すると、余分な4人のユーザ(及び中間テーブルレコードなど)が作成されてしまい、冗長なテストデータの生成によってテストコードのパフォーマンスがダウンします。(そしてテストは構わずオールグリーンになるため、この事実に気づきません)
上記コードの場合、trait を以下のように改修することで改善できます。
transient { users_count { 1 } } # 指定できるようにする
trait :with_users do
  after :create do |instance|
    instance.users.create(
      FactoryBot.create_list(:user, users_count)
    )
  end
end
transient を用いて、生成するユーザ数を指定できるようにします。さらに、そのデフォルトを1にすることで、意図せず with_users を使った場合も最小の1人のユーザ生成だけですみます。
また、 「ユーザが5人参加しているフォルダを作りたい」というケースでは、意図するユーザが不足するのでテストが失敗し、明示的にusers_count を指定するように促すことで、常に必要最小限のデータ生成で済ませることができます。(テストコードの書き方次第ではありますが)
上記の例はやや極端ではありましたが、このように意図せずにテストデータを大量生成してしまう罠の潜んだファクトリコードが多々あったため、それらを一掃することで大きく改善することができました。
6. CI上でのRSpec実行時に、Railsのログを吐かないようにする
シンプルながらこれが非常に強力でした。
RSpec では、各テストコードを実行するたびに、多量のデータ参照、作成、更新が行われるため、デフォルトの設定では大量のログがファイルに書き出されることになります。
しかし、CIコンテナ上で吐き出されたRailsログを見る機会というのは、非常に稀で、SSHでアクセスしたときぐらいでしょうか。
そんなエッジケース中のエッジケースのために常に大量のログを出力するというのは非効率だったため、config/environments/test.rb に以下の設定を追加しました。
config.log_level = ENV[‘CI’].present? ? :fatal : :debug
これによって、ローカルマシン上でのテスト時にはログを全て出力し、CI上ではエラー情報以外は出力しないという状況が作れます。
(CI は、CircleCI 側がCI上での実行時に注入してくれる環境変数です)
7. 並列テストをファイルサイズ別から実行タイミング別に変更
CircleCI では、一つのジョブに対して、複数コンテナで並列実行する仕組みが用意されています。(テストの並列実行)
これまでは、ファイルサイズによる分割を行っていましたが、 4. 特に遅いテストをチューニングする によって、ファイルごとの実行時間が均されるようになったため、満を持してタイミングデータに基づく分割 を活用できるようになりました。
— split-by=timings でタイミングデータに基づく分割を実施し、RSpec実行時にはRspecJunitFormatter を使ってテストレポートを生成します。
- run:
 command: |
 TESTFILES=$(circleci tests glob “spec/**/*_spec.rb” | circleci tests split — split-by=timings)
 bundle exec rspec — format RspecJunitFormatter -o test-results/rspec.xml — format progress — $TESTFILES
最後のステップにて、テストレポートをアップロードすることで、次回のテストではこのレポート内容に基づいて最適な分割を行ってくれます。
- store_test_results:
 path: test-results
8. CIでの実行マシンのスペックを下げ、並列数をあげる
CI実行時の消費クレジットは、「実行時間」と「実行マシンの種類、性能」によって決定します。
これまでのRSpecの改善によって、「実行時間」は大きく改善しました。続けて実行マシンの種類、性能について考えます。
弊社ではDockerコンテナを利用してCIを回しているので、Docker環境のマシンスペックと消費クレジットに関する一覧表を公式サイトから引用します。
引用元
さて、デフォルトでは Medium が自動的に選択されるため、クレジットは1分間に10消費されます。弊社ではこれまで10並列でRSpecを実行していたので、1コンテナあたり5分かかるとすると、単純計算で500クレジットを消費します。
しかし、現状のRSpecのボトルネックはあくまで DBなどのディスクI/Oのため、リソースクラスによる違い(CPU,memory) の影響を受けているとは考えにくいです。
そこで、以下のようにリソースクラスを Small に引き下げて、並列数を20に増やします。
parallelism: 20
resource_class: small
実際に試してみると、コンテナの性能は半分にしたのに、RSpecのパフォーマンスは半分どころか、せいぜい20%減程度に収まりました。
並列数は倍にしたので、少ない消費クレジットで、テスト全体の実行時間を短くすることに成功しました。
9. 可能な限りCircleCIのビルド済みイメージを使用する
RSpec 自体のステップが高速化してくると、ボトルネックとなってくるのが最初の環境セットアップです。
特に、リクエストスペックを実行するには、各種DBなどのコンテナも別途用意する必要があり、コンテナイメージのプルに時間がかかるようになります。
並列数を20と言わず、30,40にしていきたいのですが、並列数を増やせば増やすほど、環境構築にかかるクレジットの総量は増していき、対して1コンテナあたりのRSpec 実行時間は限りなく0に近づいていくため、相対的に費用対効果が下がっていきます。(消費クレジット量を増やしてもCI実行時間が変わりにくい)そこで、 MySQL や Redis といった単純なDBコンテナイメージについては、CircleCI のビルド済み Docker イメージ を使用することによって、環境構築の一部の負荷を軽減することができました。
- image: circleci/mysql:5.7.17
- image: circleci/postgres:10.1
- image: circleci/redis:4.0.10
とはいえ、アプリケーションを動かすために特化したコンテナイメージは、ホスティングしているDockerリポジトリサービスからプルする必要があるため、根本的な解決には到達していないのが現状です。
(DLC を使うのです…という声が聞こえてきそうですが、1ジョブあたり200クレジットを継続的に消耗するのは現在の規模からすると躊躇ってしまいます…)
まとめ
本記事では、CircleCIの消費クレジットとRSpecの実行時間を半減させるために行った9つの手順を紹介しました。
現状の可視化から始まり、テストコードレベル、実行環境レベル、CI設定レベルまで幅広く調べ、結果につなげることも出来たので、個人的には大変満足し、良い経験が出来たと思っています。
これもひとえに、開発基盤チーム という、「重要だが緊急でない仕事」に集中して取り組める環境があったからだと思います。
そんなスタディストですが、現在、マニュアル作成・共有プラットフォーム Teachme Biz を一緒に開発していくエンジニアの仲間を募集しています。
株式会社スタディストの採用/求人一覧 - Wantedly

CircleCIの消費クレジットとRSpecの実行時間を半減させるために行った9の手順 was originally published in スタディスト開発ブログ on Medium, where people are continuing the conversation by highlighting and responding to this story.

CircleCIの消費クレジットとRSpecの実行時間を半減させるために行った9の手順

<p>こんにちは、スタディスト開発部の笹木です。2019/10/30(水) クラウドワークス様のオフィスにて行われた、<a href="https://cw-engineers.connpass.com/event/146975/"><strong>Vue.jsアーキテクチャリング勉強会</strong></a> に登壇発表してきましたので、その裏側についてお話致します。</p><h4>登壇資料</h4><iframe src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.slideshare.net%2Fslideshow%2Fembed_code%2Fkey%2FH0n4m9HU4YWEAM&amp;display_name=SlideShare&amp;url=https%3A%2F%2Fwww.slideshare.net%2Fshingosasaki3%2Fteachmebiz-188542240&amp;image=https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fvuearchitectureforteachmebiz-191030082428-thumbnail-4.jpg%3Fcb%3D1572423947&amp;key=a19fcc184b9711e1b4764040d3dc5c07&amp;type=text%2Fhtml&amp;schema=slideshare" width="600" height="500" frameborder="0" scrolling="no"><a href="https://medium.com/media/4c6e22b26312edff7701cd66d83d1f97/href">https://medium.com/media/4c6e22b26312edff7701cd66d83d1f97/href</a></iframe><h4>背景</h4><p>私は元々、サーバサイドエンジニアとしてのキャリアを経て、今年から徐々にフロントエンドにも手を出し始めたため、フロントエンドに至ってはまだまだペーペーなエンジニアです。</p><p>そんな私ですが、弊社から1名登壇者を募集しているという案内を見て、他のフロントエンジニアに<strong>高度な情報戦</strong>を仕掛けつつ、今後の糧となることが間違いないという見込みで登壇枠を勝ち取りました。</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/477/0*OkUw4TkIoLqu0J3I" /><figcaption>高度な情報戦の発端となった発言</figcaption></figure><figure><img alt="" src="https://cdn-images-1.medium.com/max/525/1*cNNUM7JeU35GdhVlmN-ZuQ.png" /><figcaption>Go Bold — 大胆にやろう (メルカリさんのバリュー引用)</figcaption></figure><h4>資料作成という名の歴史の勉強</h4><p>さて、登壇できることが無事に決まったわけですが、困ったことにテーマは<strong>vue.jsアーキテクチャリング</strong>についてです。</p><p>私も今年からフロントエンドのコードを書いているフロントエンジニアの端くれ。弊社におけるフロントエンドのアーキテクチャを理解して実践しているつもりではありましたが、<strong>その背景や思想までは全然わかっていなかった</strong>のです。</p><p>したがって、登壇資料を作る以前に、まずは<a href="https://biz.teachme.jp/">TeachmeBiz</a> フロントエンドにおける歴史を知る必要がありました。</p><h4>歴史を知り、思想を引き継ぐ</h4><p>TeachmeBizのフロントエンドアーキテクチャの歴史を知るためには、現在のアーキテクチャの基礎を生み出した、<strong>伝説のフロントエンジニア(当社比)</strong> に協力を仰ぐのが良いでしょう。</p><p>しかし、あいにく彼は既にスタディストを卒業し、現在は他社で活躍しております。直接協力を仰ぐのは難しい状況ではありましたが、幸いなことに彼はフロントエンドアーキテクチャに関する様々な資料を残していきました。</p><iframe src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fspeakerdeck.com%2Fplayer%2F31f9e17cc8fb4b4ca1a652755f772e58&amp;url=https%3A%2F%2Fspeakerdeck.com%2Fkomiyamast%2Fvuetogong-nizou-tutahurontoentorihureisu1nian-jian&amp;image=https%3A%2F%2Fspeakerd.s3.amazonaws.com%2Fpresentations%2F31f9e17cc8fb4b4ca1a652755f772e58%2Fslide_0.jpg%3F487941&amp;key=d04bfffea46d4aeda930ec88cc64b87c&amp;type=text%2Fhtml&amp;schema=speakerdeck" width="710" height="399" frameborder="0" scrolling="no"><a href="https://medium.com/media/3966da2c19b8fde8144840ac8d22c188/href">https://medium.com/media/3966da2c19b8fde8144840ac8d22c188/href</a></iframe><p>上記スライドの他、私のスライドでは以下記事を引用していることを強調しています。</p><ul><li><a href="https://medium.com/studist-dev/ddd-vuex-c47055f6c1ba">ドメイン駆動Vuexで複雑さに立ち向かう</a></li><li><a href="https://medium.com/studist-dev/storybook-d879178318b2">Storybookの可能性を見せびらかしたい</a></li></ul><p>過去の資料やSlack上での発言を整理しながら、現状のソースコードと見比べることで、今までは何となく従っていただけの<strong>設計思想の本質</strong>が見えて来ました。これは単に見聞を通じてキャッチアップできるレベルの話でなく、<strong>勉強会で大勢の前で発表することを前提として学ぶことで、ごまかしのない、圧倒的な学習</strong>になっていました。</p><p>その一方で、知り得た情報を元にどのような登壇資料を作ったら良いかを考えていくうちに、私は一つの結論にたどり着きました。</p><p><strong>・・・もう、既存スライドを再上映すれば良いんじゃないかな。</strong></p><h4>伝説のフロントエンジニア(当社比)の褌で相撲を取るのか</h4><p>既存スライドを使いつつ、一部スクショやコード例を最近のものに置き換えるだけで、その場を乗り切ることは確かに可能でした。</p><p>登壇の日が近づくにつれ、私の中の悪魔が囁くんです。<strong>「既存の資料使い回すだけで登壇実績作れるなんで楽勝っすなぁ」</strong>と。</p><p>しかし曲がりなりにも、私もプロのフロントエンジニア。ここで既存の資料を使い回して、「これがTeachmeBizのアーキテクチャです(他人事)」と言っているようでは、伝説のフロントエンジニアの遺産をただただ食いつぶして劣化させているだけです。他人の褌で相撲を取っている状態で、とてもプロとは言えませんでした。</p><p>さらに私の中の僅かな天使がこう囁きました。<strong>「過去だけを見るのではなく、未来を見るのです」 </strong>私は過去の資料をベースに、現在そして未来を見据えて、資料のフルリプレイスを行うことにしました。</p><h4>今まででなくこれからの話</h4><p>過去の資料を整理することで圧倒的な学びを得た私ですが、その学んだ内容をまとめるだけではなく、伝説のフロントエンジニア(当社比)が関与していない、私自身が打ち出した新たな施策についてもスライドに盛り込むようにしました。以下はその一例です。</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*9ILJigaJD4a8oxXXTb9tRg.png" /><figcaption>タイトルにもアーキテクチャ以上の内容を追加</figcaption></figure><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*ivKFPNUxg9WiZrTy2BUzUg.png" /><figcaption>新たな取組の例</figcaption></figure><ul><li><a href="https://medium.com/studist-dev/sharing-documents-in-pull-request-3409e23ade88">CircleCIとS3とGithub API を用いて、プルリクごとのドキュメントを共有しよう</a></li><li><a href="https://medium.com/studist-dev/internationalization-in-storybook-4be77773494c">Storybookとvue-i18nで多言語確認を容易にしよう</a></li></ul><p>Vue.jsアーキテクチャリング勉強会というテーマからはやや外れた内容も含んでしまいましたが、これは私の意地でもありました。スタディストは伝説のフロントエンジニア(当社比) 退職後も成長し続けているんだと伝えたいエゴです。</p><p>結果的に登壇はなかなかの好評を頂けたようで、懇親会でもその辺りの話の深堀りも出来たので大変嬉しく、ためになる経験になりました。関係者の皆様には大変感謝致します。</p><h4>まとめ</h4><ul><li>勉強会での登壇は自分にとって物凄く勉強になる</li><li>設計思想はその本質を知らないと守ってるつもりでも徐々に破綻する</li><li>プロである自分の成果に拘りを持つ</li></ul><h4>スペシャルサンクス</h4><ul><li>Vue.jsアーキテクチャリング勉強会 関係者各位</li><li>多くの勤務時間を登壇準備に使わせてくれたり、登壇資料のレビューをガッツリやってくれた弊社</li><li>伝説のフロントエンジニア(当社比)</li></ul><h4>最後に</h4><p>現在スタディストではマニュアル作成・共有プラットフォーム<a href="https://biz.teachme.jp/">Teachme Biz</a>を一緒に開発していくエンジニアの仲間を募集しています。</p><p><a href="https://www.wantedly.com/companies/studist">株式会社スタディストの会社情報 - Wantedly</a></p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=73cc2177230" width="1" height="1" alt=""><hr><p><a href="https://medium.com/studist-dev/learning-through-presentations-73cc2177230">勉強会登壇を通じて学びを得まくった話</a> was originally published in <a href="https://medium.com/studist-dev">スタディスト開発ブログ</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>

こんにちは、スタディスト開発部の笹木です。2019/10/30(水) クラウドワークス様のオフィスにて行われた、Vue.jsアーキテクチャリング勉強会 に登壇発表してきましたので、その裏側についてお話致します。
登壇資料
https://medium.com/media/4c6e22b26312edff7701cd66d83d1f97/href
背景
私は元々、サーバサイドエンジニアとしてのキャリアを経て、今年から徐々にフロントエンドにも手を出し始めたため、フロントエンドに至ってはまだまだペーペーなエンジニアです。
そんな私ですが、弊社から1名登壇者を募集しているという案内を見て、他のフロントエンジニアに高度な情報戦を仕掛けつつ、今後の糧となることが間違いないという見込みで登壇枠を勝ち取りました。
高度な情報戦の発端となった発言Go Bold — 大胆にやろう (メルカリさんのバリュー引用)
資料作成という名の歴史の勉強
さて、登壇できることが無事に決まったわけですが、困ったことにテーマはvue.jsアーキテクチャリングについてです。
私も今年からフロントエンドのコードを書いているフロントエンジニアの端くれ。弊社におけるフロントエンドのアーキテクチャを理解して実践しているつもりではありましたが、その背景や思想までは全然わかっていなかったのです。
したがって、登壇資料を作る以前に、まずはTeachmeBiz フロントエンドにおける歴史を知る必要がありました。
歴史を知り、思想を引き継ぐ
TeachmeBizのフロントエンドアーキテクチャの歴史を知るためには、現在のアーキテクチャの基礎を生み出した、伝説のフロントエンジニア(当社比) に協力を仰ぐのが良いでしょう。
しかし、あいにく彼は既にスタディストを卒業し、現在は他社で活躍しております。直接協力を仰ぐのは難しい状況ではありましたが、幸いなことに彼はフロントエンドアーキテクチャに関する様々な資料を残していきました。
https://medium.com/media/3966da2c19b8fde8144840ac8d22c188/href
上記スライドの他、私のスライドでは以下記事を引用していることを強調しています。

ドメイン駆動Vuexで複雑さに立ち向かう
Storybookの可能性を見せびらかしたい

過去の資料やSlack上での発言を整理しながら、現状のソースコードと見比べることで、今までは何となく従っていただけの設計思想の本質が見えて来ました。これは単に見聞を通じてキャッチアップできるレベルの話でなく、勉強会で大勢の前で発表することを前提として学ぶことで、ごまかしのない、圧倒的な学習になっていました。
その一方で、知り得た情報を元にどのような登壇資料を作ったら良いかを考えていくうちに、私は一つの結論にたどり着きました。
・・・もう、既存スライドを再上映すれば良いんじゃないかな。
伝説のフロントエンジニア(当社比)の褌で相撲を取るのか
既存スライドを使いつつ、一部スクショやコード例を最近のものに置き換えるだけで、その場を乗り切ることは確かに可能でした。
登壇の日が近づくにつれ、私の中の悪魔が囁くんです。「既存の資料使い回すだけで登壇実績作れるなんで楽勝っすなぁ」と。
しかし曲がりなりにも、私もプロのフロントエンジニア。ここで既存の資料を使い回して、「これがTeachmeBizのアーキテクチャです(他人事)」と言っているようでは、伝説のフロントエンジニアの遺産をただただ食いつぶして劣化させているだけです。他人の褌で相撲を取っている状態で、とてもプロとは言えませんでした。
さらに私の中の僅かな天使がこう囁きました。「過去だけを見るのではなく、未来を見るのです」 私は過去の資料をベースに、現在そして未来を見据えて、資料のフルリプレイスを行うことにしました。
今まででなくこれからの話
過去の資料を整理することで圧倒的な学びを得た私ですが、その学んだ内容をまとめるだけではなく、伝説のフロントエンジニア(当社比)が関与していない、私自身が打ち出した新たな施策についてもスライドに盛り込むようにしました。以下はその一例です。
タイトルにもアーキテクチャ以上の内容を追加新たな取組の例
CircleCIとS3とGithub API を用いて、プルリクごとのドキュメントを共有しよう
Storybookとvue-i18nで多言語確認を容易にしよう

Vue.jsアーキテクチャリング勉強会というテーマからはやや外れた内容も含んでしまいましたが、これは私の意地でもありました。スタディストは伝説のフロントエンジニア(当社比) 退職後も成長し続けているんだと伝えたいエゴです。
結果的に登壇はなかなかの好評を頂けたようで、懇親会でもその辺りの話の深堀りも出来たので大変嬉しく、ためになる経験になりました。関係者の皆様には大変感謝致します。
まとめ

勉強会での登壇は自分にとって物凄く勉強になる
設計思想はその本質を知らないと守ってるつもりでも徐々に破綻する
プロである自分の成果に拘りを持つ

スペシャルサンクス

Vue.jsアーキテクチャリング勉強会 関係者各位
多くの勤務時間を登壇準備に使わせてくれたり、登壇資料のレビューをガッツリやってくれた弊社
伝説のフロントエンジニア(当社比)

最後に
現在スタディストではマニュアル作成・共有プラットフォームTeachme Bizを一緒に開発していくエンジニアの仲間を募集しています。
株式会社スタディストの会社情報 - Wantedly

勉強会登壇を通じて学びを得まくった話 was originally published in スタディスト開発ブログ on Medium, where people are continuing the conversation by highlighting and responding to this story.

勉強会登壇を通じて学びを得まくった話

<h4>はじめに</h4><p>こんにちは、<a href="https://studist.jp/">株式会社スタディスト</a> 開発部Webグループの笹木です。</p><p>スタディストという社名の由来は <strong>Study(学ぶ) + st(人)</strong>であり、学び続ける姿勢を重要視しています。そのため、社内勉強会のような長期的な視点で組織及びメンバーが成長するための活動を、業務時間内に行っています。</p><p>今回はその中でも、毎週水曜日に有志で行っている、<strong>技術書の輪読会</strong>についてご紹介したいと思います。</p><h4>輪読の対象書籍</h4><p>現在輪読を進めている書籍は、<a href="https://www.amazon.co.jp/dp/4798159298/ref=cm_sw_r_tw_dp_U_x_IVrsDb4S42FE3">OAuth徹底入門 セキュアな認可システムを適用するための原則と実践</a> です。</p><p>本書籍は、OAuth 2.0に焦点を当て、その特性や役割に始まり、実運用上のポイントや起こりうる脆弱性まで、網羅的にハンズオン(JavaScript)を通じて学ぶことが出来る一冊です。</p><p><a href="https://www.amazon.co.jp/dp/4798159298/ref=cm_sw_r_tw_dp_U_x_IVrsDb4S42FE3">OAuth徹底入門 セキュアな認可システムを適用するための原則と実践</a></p><h4>輪読の進め方</h4><p>スタディストでの輪読の進め方は、本書籍に限らず概ね以下の流れになっています。</p><ul><li><a href="#23ba">[事前準備] 参加者は事前に対象書籍の対象範囲を読んでおく</a></li><li><a href="#0052">[事前準備] 腹落ちしなかった点、議論したい点についてメモを取る</a></li><li><a href="#6a43">[当日] 各々の要約した内容の読み合わせを行い、認識の齟齬がないことを確認する</a></li><li><a href="#9548">[当日] 理解を深めたい点について議論する</a></li></ul><p>各手順について、詳しく紹介致します。</p><h4><strong>[事前準備] 参加者は事前に対象書籍の対象範囲を読んでおく</strong></h4><p>まず、各々の参加者は業務時間内に書籍を読み進め、自分なりに理解を深めつつ要約した内容のメモを取ります。</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*Mv52jjACGGCftxGVm41Rsg.png" /><figcaption>1. 参加者は事前に対象書籍の対象範囲を読んでおく(例)</figcaption></figure><h4><strong>[事前準備] 腹落ちしなかった点、議論したい点についてメモを取る</strong></h4><p>一人で書籍を読み進めるだけでは、理解しきれない点が残ったり誤認してしまったりすることがあります。そういった懸念事項のメモを取っておき当日に備えます。</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*2aLj8dna2Vv7gG3JS_Eq6w.png" /><figcaption>2. 腹落ちしきれなかった点、議論した点についてメモを取る(例)</figcaption></figure><h4><strong>[当日] 各々の要約した内容の読み合わせを行い、認識の齟齬がないことを確認する</strong></h4><p>同じ書籍であっても、読む際に注力した箇所は異なります。例えば、人によっては書籍外の文献にあたったメモを残していたり、自分とは異なる解釈のメモを残していたりします。そのため、他の人の要約を読み込むことによって、自分にはなかった視点で書籍の内容を理解できるようになります。</p><h4><strong>[当日] 理解を深めたい点について議論する</strong></h4><p>主に書籍の内容からだけでは読みきれなかった点について、書籍から得た知識を元に、より理解を深めるために議論を行います。議論は主にホワイトボードを使い、参加者それぞれが図を書いたり説明することで、より知識を身近に、深く理解することができます。</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*D-OIjdDx1E5fWgNMSpWeog.jpeg" /><figcaption>4. 議論したい点について議論する(例)</figcaption></figure><p>時には、書籍を用いてハンズオンしたコードについても読み合わせ、理論だけではなくコードに起こした場合にどうなるかの理解も深めます。</p><iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/d0da0408a8914730af9c9ed242009ab4/href">https://medium.com/media/d0da0408a8914730af9c9ed242009ab4/href</a></iframe><p>以上の手順での輪読を、週1回1~2時間行い、1冊の書籍を数ヶ月かけて深く理解するというのが、現在のスタディストでの輪読活動になります。</p><h4>最後に</h4><p>現在スタディストではマニュアル作成・共有プラットフォーム<a href="https://biz.teachme.jp/">Teachme Biz</a>を一緒に開発していくエンジニアの仲間を募集しています。輪読活動のように、目標に向かった自己成長していけるような職場ですので、エンジニアとして高みを目指している方々を大募集しています。</p><p><a href="https://www.wantedly.com/companies/studist">株式会社スタディストの会社情報 - Wantedly</a></p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=b20c21bc0e33" width="1" height="1" alt=""><hr><p><a href="https://medium.com/studist-dev/studist-reading-party-b20c21bc0e33">スタディスト社内では技術書の輪読会やってます</a> was originally published in <a href="https://medium.com/studist-dev">スタディスト開発ブログ</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>

はじめに
こんにちは、株式会社スタディスト 開発部Webグループの笹木です。
スタディストという社名の由来は Study(学ぶ) + st(人)であり、学び続ける姿勢を重要視しています。そのため、社内勉強会のような長期的な視点で組織及びメンバーが成長するための活動を、業務時間内に行っています。
今回はその中でも、毎週水曜日に有志で行っている、技術書の輪読会についてご紹介したいと思います。
輪読の対象書籍
現在輪読を進めている書籍は、OAuth徹底入門 セキュアな認可システムを適用するための原則と実践 です。
本書籍は、OAuth 2.0に焦点を当て、その特性や役割に始まり、実運用上のポイントや起こりうる脆弱性まで、網羅的にハンズオン(JavaScript)を通じて学ぶことが出来る一冊です。
OAuth徹底入門 セキュアな認可システムを適用するための原則と実践
輪読の進め方
スタディストでの輪読の進め方は、本書籍に限らず概ね以下の流れになっています。

[事前準備] 参加者は事前に対象書籍の対象範囲を読んでおく
[事前準備] 腹落ちしなかった点、議論したい点についてメモを取る
[当日] 各々の要約した内容の読み合わせを行い、認識の齟齬がないことを確認する
[当日] 理解を深めたい点について議論する

各手順について、詳しく紹介致します。
[事前準備] 参加者は事前に対象書籍の対象範囲を読んでおく
まず、各々の参加者は業務時間内に書籍を読み進め、自分なりに理解を深めつつ要約した内容のメモを取ります。
1. 参加者は事前に対象書籍の対象範囲を読んでおく(例)
[事前準備] 腹落ちしなかった点、議論したい点についてメモを取る
一人で書籍を読み進めるだけでは、理解しきれない点が残ったり誤認してしまったりすることがあります。そういった懸念事項のメモを取っておき当日に備えます。
2. 腹落ちしきれなかった点、議論した点についてメモを取る(例)
[当日] 各々の要約した内容の読み合わせを行い、認識の齟齬がないことを確認する
同じ書籍であっても、読む際に注力した箇所は異なります。例えば、人によっては書籍外の文献にあたったメモを残していたり、自分とは異なる解釈のメモを残していたりします。そのため、他の人の要約を読み込むことによって、自分にはなかった視点で書籍の内容を理解できるようになります。
[当日] 理解を深めたい点について議論する
主に書籍の内容からだけでは読みきれなかった点について、書籍から得た知識を元に、より理解を深めるために議論を行います。議論は主にホワイトボードを使い、参加者それぞれが図を書いたり説明することで、より知識を身近に、深く理解することができます。
4. 議論したい点について議論する(例)
時には、書籍を用いてハンズオンしたコードについても読み合わせ、理論だけではなくコードに起こした場合にどうなるかの理解も深めます。
https://medium.com/media/d0da0408a8914730af9c9ed242009ab4/href
以上の手順での輪読を、週1回1~2時間行い、1冊の書籍を数ヶ月かけて深く理解するというのが、現在のスタディストでの輪読活動になります。
最後に
現在スタディストではマニュアル作成・共有プラットフォームTeachme Bizを一緒に開発していくエンジニアの仲間を募集しています。輪読活動のように、目標に向かった自己成長していけるような職場ですので、エンジニアとして高みを目指している方々を大募集しています。
株式会社スタディストの会社情報 - Wantedly

スタディスト社内では技術書の輪読会やってます was originally published in スタディスト開発ブログ on Medium, where people are continuing the conversation by highlighting and responding to this story.

スタディスト社内では技術書の輪読会やってます

<figure><img alt="" src="https://cdn-images-1.medium.com/max/628/1*BUKUWQ3ZX_qhtTg94HGN2A.png" /><figcaption>動的生成されたドキュメントをPRに添付した完成形</figcaption></figure><h4>はじめに</h4><p>こんにちは、<a href="https://studist.jp/">株式会社スタディスト</a> 開発部Webグループの笹木です。</p><p>今回は、<a href="https://circleci.com/">circleci</a> 上で生成したAPIドキュメント及び、静的ビルドした<a href="https://storybook.js.org/">Storybook</a> を<a href="https://aws.amazon.com/jp/s3/">AWS S3</a> にアップロード後、プルリクの<a href="https://developer.github.com/v3/repos/statuses/">コミットステータス</a>にそのリンクを添付するという仕組みを導入してみました。</p><h4>背景</h4><p>弊社が開発、運用している<a href="https://biz.teachme.jp/">Teachme Biz</a> の開発では、APIドキュメントの作成に<a href="https://apiblueprint.org/">api blueprint</a> 及び <a href="https://github.com/danielgtaylor/aglio">aglio</a> を用いており、HTMLファイルに出力して配布しています。</p><p>また、フロントエンドのコンポーネントカタログとして、<a href="https://storybook.js.org/">Storybook</a> を採用しており、こちらは各開発者が開発環境上で立ち上げて利用するというケースが多いです。</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/960/1*2eVFEU4okQpd6F3gTcPpAg.png" /></figure><figure><img alt="" src="https://cdn-images-1.medium.com/max/800/1*oKpaioQ31Fx6Nd6-E1FsVA.png" /><figcaption>ビルドしたAPIドキュメントとStorybook (開発用APIなので一部モザイク)</figcaption></figure><h4><strong>これまでの問題点</strong></h4><p>上記のドキュメントを、従来は開発者が個々人でビルドし、フロントエンド開発に活用したり、それを必要とする人に手動で配布したりするやり方を長らく取ってきました。</p><p>しかし、そのような手動主体のやり方では、以下のような問題が目立ちました。</p><ul><li>参照すべき最新のドキュメントがどこにあるかわからない</li><li>UI変更のプルリクをレビューするたびに、開発環境でstorybookを立ち上げる必要がある</li><li>チームを跨いだドキュメントの配布が難しい</li></ul><p>これらは運用でカバーでも何とかなる問題ではありますが、やはり人間の手を煩わせずに解決させたいというのがプログラマの美徳です。</p><p>ということで、プルリクを出す際に、circleciのビルドが走るので、その中で全て解決しようと試みました。</p><h4>(別案) circleci の Artifact にアップロード</h4><p>はじめは、circleciの<a href="https://circleci.com/docs/2.0/artifacts/">Build Artifacts</a> にアップロードする手法を採用しました。</p><p>Artifactsは、circleciのビルド内で生成した成果物(ドキュメントなど)を、circleci上に永続化する仕組みです。以下のように、CIのビルド単位でファイルをアップロードでき、閲覧/ダウンロード可能です。</p><iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/67d2b5d45ab91e9b4f57916847b8ebb5/href">https://medium.com/media/67d2b5d45ab91e9b4f57916847b8ebb5/href</a></iframe><figure><img alt="" src="https://cdn-images-1.medium.com/max/630/1*IFMwguvDmbiUwAgaqmwW4A.png" /><figcaption>circleciのartifactsにドキュメントをアップロードした図</figcaption></figure><p>しばらくはArifactsの仕組みのお世話になり、以前よりはドキュメントの共有が容易になりました。</p><p>しかし、circleciのArtifactsでは、以下のような問題が残りました。</p><ul><li>URLがビルドごとにランダムに確定するので、特定、配布しづらい</li><li>アップロードしたArtifactsの永続性が保証されていない(いつ突然消えるかわからない)</li><li>Github及びcircleciに対して認証済みのユーザでないと閲覧できない</li></ul><p>Artifactsは非常にお手軽で使い勝手が良い機能で重宝していましたが、このままだと私達のニーズには応えきれないと判断し、別な方法に見直すことにしました。</p><h4><strong>S3へのアップロード</strong></h4><p>まず、CI内で生成したドキュメントを、Artifactsでなく、AWS S3にアップロードすることにしました。</p><p>ドキュメント用の専用のバケットを用意し、ブランチ名がそのままディレクトリ構造になるようにアップロードします。</p><iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/8019a777a82d37071df1f24d40ba682a/href">https://medium.com/media/8019a777a82d37071df1f24d40ba682a/href</a></iframe><p>アップロードしたS3オブジェクトは、S3のバケットポリシーで、オフィス内のIPアドレスからなら誰でも見られるようにします。(リモート勤務の場合も、VPNを通すことで利用可能です)</p><iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/d964d20e4099942abdacb3bb0c19fd55/href">https://medium.com/media/d964d20e4099942abdacb3bb0c19fd55/href</a></iframe><p>また、ブランチレベルでオブジェクトが生成されるので、バケットのライフサイクルを設定し、一定期間ごとに自動で削除されるようにします。(容量が対したことないので消さなくても大した金額にはならないですが)</p><p>これで、本番環境と同レベルのAPIドキュメントを取得したい場合は、以下のようなURLを事前に配布しておけば、常に最新のドキュメントを確認できるようになります。</p><p><strong>https://bucket-name-for-documents.s3-ap-northeast-1.amazonaws.com/doc/master/api/index.html</strong></p><h4><strong>コミットステータスにURLを添付する</strong></h4><p>既にドキュメントはS3にブランチごとにアップロードされているので、レビュー時はそれを参照すれば良いのですが、URLを意識せずにもっと楽に参照したいという欲が溢れてきました。</p><p>「プルリク内から１クリックで見たい」という気持ちが強かったので、今回はGithubの<a href="https://developer.github.com/v3/repos/statuses/">Commit Statuses</a> をAPIから生成し、そこにドキュメントのURLを紐付けるというアプローチを採用しまいた。</p><iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/b02c659081f160b7a568ca5ff275e2df/href">https://medium.com/media/b02c659081f160b7a568ca5ff275e2df/href</a></iframe><p>curlコマンドで直接Github APIを叩いているので、ややコードは複雑になっていますが、やっていることは以下の通りシンプルです。</p><ul><li>CIの環境変数を元に、前段階でS3にアップロードしたオブジェクトのURLを取得</li><li>現在CIがビルドしているコミットに対して、Github APIを使ってコミットステータスを追加</li></ul><p>追加するコミットステータスは以下の２種類です。</p><ul><li>APIドキュメントの生成に成功した旨とそのURL</li><li>Storybookの生成に成功した旨とそのURL</li></ul><p>全てのビルドが成功すると、以下のようにプルリクごとにそのブランチのAPIドキュメントとStorybookへのリンクが表示されるようになり、より手軽に、より細かなコードレビューを行えるようになります。</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/628/1*BUKUWQ3ZX_qhtTg94HGN2A.png" /><figcaption>動的生成されたドキュメントをPRに添付した完成形</figcaption></figure><h3>最後に</h3><p>現在スタディストではマニュアル作成・共有プラットフォーム<a href="https://biz.teachme.jp/">Teachme Biz</a>を一緒に開発していくエンジニアの仲間を募集しています。</p><p><a href="https://www.wantedly.com/companies/studist">株式会社スタディストの会社情報 - Wantedly</a></p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=3409e23ade88" width="1" height="1" alt=""><hr><p><a href="https://medium.com/studist-dev/sharing-documents-in-pull-request-3409e23ade88">CircleCIとS3とGithub API を用いて、プルリクごとのドキュメントを共有しよう</a> was originally published in <a href="https://medium.com/studist-dev">スタディスト開発ブログ</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>

動的生成されたドキュメントをPRに添付した完成形
はじめに
こんにちは、株式会社スタディスト 開発部Webグループの笹木です。
今回は、circleci 上で生成したAPIドキュメント及び、静的ビルドしたStorybook をAWS S3 にアップロード後、プルリクのコミットステータスにそのリンクを添付するという仕組みを導入してみました。
背景
弊社が開発、運用しているTeachme Biz の開発では、APIドキュメントの作成にapi blueprint 及び aglio を用いており、HTMLファイルに出力して配布しています。
また、フロントエンドのコンポーネントカタログとして、Storybook を採用しており、こちらは各開発者が開発環境上で立ち上げて利用するというケースが多いです。
ビルドしたAPIドキュメントとStorybook (開発用APIなので一部モザイク)
これまでの問題点
上記のドキュメントを、従来は開発者が個々人でビルドし、フロントエンド開発に活用したり、それを必要とする人に手動で配布したりするやり方を長らく取ってきました。
しかし、そのような手動主体のやり方では、以下のような問題が目立ちました。

参照すべき最新のドキュメントがどこにあるかわからない
UI変更のプルリクをレビューするたびに、開発環境でstorybookを立ち上げる必要がある
チームを跨いだドキュメントの配布が難しい

これらは運用でカバーでも何とかなる問題ではありますが、やはり人間の手を煩わせずに解決させたいというのがプログラマの美徳です。
ということで、プルリクを出す際に、circleciのビルドが走るので、その中で全て解決しようと試みました。
(別案) circleci の Artifact にアップロード
はじめは、circleciのBuild Artifacts にアップロードする手法を採用しました。
Artifactsは、circleciのビルド内で生成した成果物(ドキュメントなど)を、circleci上に永続化する仕組みです。以下のように、CIのビルド単位でファイルをアップロードでき、閲覧/ダウンロード可能です。
https://medium.com/media/67d2b5d45ab91e9b4f57916847b8ebb5/hrefcircleciのartifactsにドキュメントをアップロードした図
しばらくはArifactsの仕組みのお世話になり、以前よりはドキュメントの共有が容易になりました。
しかし、circleciのArtifactsでは、以下のような問題が残りました。

URLがビルドごとにランダムに確定するので、特定、配布しづらい
アップロードしたArtifactsの永続性が保証されていない(いつ突然消えるかわからない)
Github及びcircleciに対して認証済みのユーザでないと閲覧できない

Artifactsは非常にお手軽で使い勝手が良い機能で重宝していましたが、このままだと私達のニーズには応えきれないと判断し、別な方法に見直すことにしました。
S3へのアップロード
まず、CI内で生成したドキュメントを、Artifactsでなく、AWS S3にアップロードすることにしました。
ドキュメント用の専用のバケットを用意し、ブランチ名がそのままディレクトリ構造になるようにアップロードします。
https://medium.com/media/8019a777a82d37071df1f24d40ba682a/href
アップロードしたS3オブジェクトは、S3のバケットポリシーで、オフィス内のIPアドレスからなら誰でも見られるようにします。(リモート勤務の場合も、VPNを通すことで利用可能です)
https://medium.com/media/d964d20e4099942abdacb3bb0c19fd55/href
また、ブランチレベルでオブジェクトが生成されるので、バケットのライフサイクルを設定し、一定期間ごとに自動で削除されるようにします。(容量が対したことないので消さなくても大した金額にはならないですが)
これで、本番環境と同レベルのAPIドキュメントを取得したい場合は、以下のようなURLを事前に配布しておけば、常に最新のドキュメントを確認できるようになります。
https://bucket-name-for-documents.s3-ap-northeast-1.amazonaws.com/doc/master/api/index.html
コミットステータスにURLを添付する
既にドキュメントはS3にブランチごとにアップロードされているので、レビュー時はそれを参照すれば良いのですが、URLを意識せずにもっと楽に参照したいという欲が溢れてきました。
「プルリク内から１クリックで見たい」という気持ちが強かったので、今回はGithubのCommit Statuses をAPIから生成し、そこにドキュメントのURLを紐付けるというアプローチを採用しまいた。
https://medium.com/media/b02c659081f160b7a568ca5ff275e2df/href
curlコマンドで直接Github APIを叩いているので、ややコードは複雑になっていますが、やっていることは以下の通りシンプルです。

CIの環境変数を元に、前段階でS3にアップロードしたオブジェクトのURLを取得
現在CIがビルドしているコミットに対して、Github APIを使ってコミットステータスを追加

追加するコミットステータスは以下の２種類です。

APIドキュメントの生成に成功した旨とそのURL
Storybookの生成に成功した旨とそのURL

全てのビルドが成功すると、以下のようにプルリクごとにそのブランチのAPIドキュメントとStorybookへのリンクが表示されるようになり、より手軽に、より細かなコードレビューを行えるようになります。
動的生成されたドキュメントをPRに添付した完成形
最後に
現在スタディストではマニュアル作成・共有プラットフォームTeachme Bizを一緒に開発していくエンジニアの仲間を募集しています。
株式会社スタディストの会社情報 - Wantedly

CircleCIとS3とGithub API を用いて、プルリクごとのドキュメントを共有しよう was originally published in スタディスト開発ブログ on Medium, where people are continuing the conversation by highlighting and responding to this story.

CircleCIとS3とGithub API を用いて、プルリクごとのドキュメントを共有しよう

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*owXK4x2saGcuXMWGMhDO0A.png" /><figcaption>Teachme Biz開発で使用しているstorybook例</figcaption></figure><h3>はじめに</h3><p>こんにちは、<a href="https://studist.jp/">株式会社スタディスト</a> 開発部Webグループの笹木です。</p><p>先日、スタディスト開発部合宿(下記記事参照)の一環で、 <a href="https://storybook.js.org/">Storybook</a> 上で表示言語を切り替えられるようにし、UIの多言語検証を容易にする取り組みを行ったのでご紹介しようと思います。</p><p><a href="https://medium.com/studist-dev/%E9%96%8B%E7%99%BA%E9%83%A8%E3%81%AE%E5%85%A8%E6%A5%AD%E5%8B%99-%E5%85%A8%E4%BC%9A%E8%AD%B0%E3%82%921%E9%80%B1%E9%96%93%E6%AD%A2%E3%82%81%E3%81%A6%E3%82%B9%E3%82%BF%E3%83%87%E3%82%A3%E3%82%B9%E3%83%88%E9%96%8B%E7%99%BA%E5%90%88%E5%AE%BF-1%E3%82%92%E3%82%84%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%9F%E3%82%89%E6%83%B3%E5%AE%9A%E4%BB%A5%E4%B8%8A%E3%81%AB%E3%83%AA%E3%82%BF%E3%83%BC%E3%83%B3%E3%81%8C%E5%BE%97%E3%82%89%E3%82%8C%E3%81%9F%E8%A9%B1-e880525d7a5b">開発部の全業務/全会議を1週間止めてスタディスト開発合宿#1をやってみたら想定以上にリターンが得られた話</a></p><h3><strong>背景</strong></h3><p>弊社が開発、運用している<a href="https://biz.teachme.jp/">Teachme Biz</a> のフロントエンドは<a href="https://jp.vuejs.org/index.html">Vue.js</a>で実装されており、UIコンポーネントをカタログ化する<a href="https://storybook.js.org/">Storybook</a>での開発を基本としています。</p><p>弊社でのStorybookの活用例として、以下のような記事もありますので、ご興味がありましたら、ぜひご覧頂ければ幸いです。</p><ul><li><a href="https://medium.com/studist-dev/storybook-d879178318b2">Storybookの可能性を見せびらかしたい</a></li><li><a href="https://medium.com/studist-dev/storybook-with-vuex-7084bea6b509">実践StorybookでVuexに立ち向かう</a></li></ul><h3>現状の問題点</h3><p>Storybookの活用は、プロダクトであるアプリケーションを起動すること無く、UIコンポーネント単体での動作確認を可能とする上、UIコンポーネントのデザインをチーム間で共有する上で強力な武器となっていました。</p><p>しかし、デザインを共有する上で、痒いところに手が届かない問題が一つ見つかりました。それは多言語化です。</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*M6linRNDNl3rEwVNnjCeUA.png" /><figcaption>Teachme Bizでの多言語対応</figcaption></figure><p>Teachme Bizでは、現在(2019/06) 日本語、英語、そしてタイ語の３言語をサポートしています。それぞれの言語は、同じ意味を表す文言でも、一つの単語で表現できなかったり、文字数が大きく異なったりするなど、デザインにも大きな影響を与えます。</p><p>また、Teachme Bizでは、多言語化に<a href="https://kazupon.github.io/vue-i18n/">VueI18n</a>を使用しており、以下のようにブラウザの言語設定を元に、言語設定の切り替えを行います。</p><iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/17c3a75176dfb13a9c198de87e953eb6/href">https://medium.com/media/17c3a75176dfb13a9c198de87e953eb6/href</a></iframe><p>そのため、言語ごとのデザイン崩れが生じていないか、適切な翻訳文が設定されているかなどを確認するためには、都度ブラウザの設定画面を開き、言語設定を切り替えた上でリロードする必要がありました。</p><p>これではスマートではありません。せっかくのstorybookがあっても、一々ブラウザの設定を変えて画面をリロードしてを言語数分やって、翻訳の確認をしていたら日が暮れてしまいます。</p><h3>Storybook上で動的に言語を切り替える</h3><p>そこで、Storybook上では、ブラウザの言語設定に関係なく、画面上から言語を切り替えられるような仕組みづくりを行うことにしました。</p><p>完成形からお見せしますと、以下の通りです。</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*RZ3t1q77HpHuHAM8mDWdEw.png" /><figcaption>デフォルトでは日本語だが</figcaption></figure><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*dV1fouFQZ1l4KHxNIR-VKg.png" /><figcaption>画面右側のlocaleを切り替えることで、即座に言語が切り替わる</figcaption></figure><p>言語の切り替えには、Storybookのaddonである、<a href="https://github.com/storybookjs/storybook/tree/master/addons/knobs">Knobs</a> を活用しました。Knobsの本来の役割は、画面上からUIコンポーネントのプロパティなどを動的に変更し、UIコンポーネントの振る舞いを検証することが出来る優れたアドオンです。もちろん本来のKnobsの用途としても日々活用しているので、今回は既存の仕組みに言語の切り替え機能を追加したという形になります。</p><p>ベースとなるコードは以下になります。(実際はもう少し複雑なので簡略版となってます)</p><iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/6e9694a2d3a60ac14299a9e50898fb94/href">https://medium.com/media/6e9694a2d3a60ac14299a9e50898fb94/href</a></iframe><p>addDecoratorは、Storybookで表示するコンポーネントをラップする<a href="https://storybook.js.org/docs/addons/introduction/#1-decorators">Decorator</a>を追加する関数です。これによって、Storybook上の全てのコンポーネントを、<strong>&lt;story&gt;</strong>というラッパーコンポーネントでラップして描画します。</p><p><strong>&lt;story&gt; </strong>には、<strong>storybookLocale</strong> という、現在選択中の言語情報(ja, en, th)をpropsでも持たせます。<strong>storybookLocale</strong>の設定値は、<strong>Knobs</strong>の<strong>select</strong>を使うことで、画面上のセレクタから指定できるようにします。</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/362/1*eY-Ws88PwBH2NzoE9eL2kQ.png" /><figcaption>storybookLocale</figcaption></figure><p>そして、storybookLocaleの変更をwatchし、変更があるごとに、VueI18nのローケル設定を動的に変更します。propsが変更されることによって、コンポーネントの再描画が走り、新しく設定された言語でコンポーネントが描画されます。これによって、画面上が動的に言語を切り替え、素早く多言語のデザイン検証を行えるようになりました。</p><h3>最後に</h3><p>現在スタディストではマニュアル作成・共有プラットフォーム<a href="https://biz.teachme.jp/">Teachme Biz</a>を一緒に開発していくエンジニアの仲間を募集しています。</p><p><a href="https://www.wantedly.com/companies/studist">株式会社スタディストの会社情報 - Wantedly</a></p><p>Storybookを活用した開発にご興味がある方、お待ちしております！(サーバサイドやネイティブアプリの人も大募集中です)</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=4be77773494c" width="1" height="1" alt=""><hr><p><a href="https://medium.com/studist-dev/internationalization-in-storybook-4be77773494c">Storybookとvue-i18nで多言語確認を容易にしよう</a> was originally published in <a href="https://medium.com/studist-dev">スタディスト開発ブログ</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>

Teachme Biz開発で使用しているstorybook例
はじめに
こんにちは、株式会社スタディスト 開発部Webグループの笹木です。
先日、スタディスト開発部合宿(下記記事参照)の一環で、 Storybook 上で表示言語を切り替えられるようにし、UIの多言語検証を容易にする取り組みを行ったのでご紹介しようと思います。
開発部の全業務/全会議を1週間止めてスタディスト開発合宿#1をやってみたら想定以上にリターンが得られた話
背景
弊社が開発、運用しているTeachme Biz のフロントエンドはVue.jsで実装されており、UIコンポーネントをカタログ化するStorybookでの開発を基本としています。
弊社でのStorybookの活用例として、以下のような記事もありますので、ご興味がありましたら、ぜひご覧頂ければ幸いです。

Storybookの可能性を見せびらかしたい
実践StorybookでVuexに立ち向かう

現状の問題点
Storybookの活用は、プロダクトであるアプリケーションを起動すること無く、UIコンポーネント単体での動作確認を可能とする上、UIコンポーネントのデザインをチーム間で共有する上で強力な武器となっていました。
しかし、デザインを共有する上で、痒いところに手が届かない問題が一つ見つかりました。それは多言語化です。
Teachme Bizでの多言語対応
Teachme Bizでは、現在(2019/06) 日本語、英語、そしてタイ語の３言語をサポートしています。それぞれの言語は、同じ意味を表す文言でも、一つの単語で表現できなかったり、文字数が大きく異なったりするなど、デザインにも大きな影響を与えます。
また、Teachme Bizでは、多言語化にVueI18nを使用しており、以下のようにブラウザの言語設定を元に、言語設定の切り替えを行います。
https://medium.com/media/17c3a75176dfb13a9c198de87e953eb6/href
そのため、言語ごとのデザイン崩れが生じていないか、適切な翻訳文が設定されているかなどを確認するためには、都度ブラウザの設定画面を開き、言語設定を切り替えた上でリロードする必要がありました。
これではスマートではありません。せっかくのstorybookがあっても、一々ブラウザの設定を変えて画面をリロードしてを言語数分やって、翻訳の確認をしていたら日が暮れてしまいます。
Storybook上で動的に言語を切り替える
そこで、Storybook上では、ブラウザの言語設定に関係なく、画面上から言語を切り替えられるような仕組みづくりを行うことにしました。
完成形からお見せしますと、以下の通りです。
デフォルトでは日本語だが画面右側のlocaleを切り替えることで、即座に言語が切り替わる
言語の切り替えには、Storybookのaddonである、Knobs を活用しました。Knobsの本来の役割は、画面上からUIコンポーネントのプロパティなどを動的に変更し、UIコンポーネントの振る舞いを検証することが出来る優れたアドオンです。もちろん本来のKnobsの用途としても日々活用しているので、今回は既存の仕組みに言語の切り替え機能を追加したという形になります。
ベースとなるコードは以下になります。(実際はもう少し複雑なので簡略版となってます)
https://medium.com/media/6e9694a2d3a60ac14299a9e50898fb94/href
addDecoratorは、Storybookで表示するコンポーネントをラップするDecoratorを追加する関数です。これによって、Storybook上の全てのコンポーネントを、<story>というラッパーコンポーネントでラップして描画します。
<story> には、storybookLocale という、現在選択中の言語情報(ja, en, th)をpropsでも持たせます。storybookLocaleの設定値は、Knobsのselectを使うことで、画面上のセレクタから指定できるようにします。
storybookLocale
そして、storybookLocaleの変更をwatchし、変更があるごとに、VueI18nのローケル設定を動的に変更します。propsが変更されることによって、コンポーネントの再描画が走り、新しく設定された言語でコンポーネントが描画されます。これによって、画面上が動的に言語を切り替え、素早く多言語のデザイン検証を行えるようになりました。
最後に
現在スタディストではマニュアル作成・共有プラットフォームTeachme Bizを一緒に開発していくエンジニアの仲間を募集しています。
株式会社スタディストの会社情報 - Wantedly
Storybookを活用した開発にご興味がある方、お待ちしております！(サーバサイドやネイティブアプリの人も大募集中です)

Storybookとvue-i18nで多言語確認を容易にしよう was originally published in スタディスト開発ブログ on Medium, where people are continuing the conversation by highlighting and responding to this story.

Storybookとvue-i18nで多言語確認を容易にしよう


 Chart.js 3 について
Chart.js 3 は、 Canvas を用いたグラフ描画ライブラリとして人気の高い Chart.js の最新バージョンで、 2021年4月にリリースされました。
v3 は従来の v2 と比べ、以下のような大きな改善が行われています。

webworkers を用いた並列レンダリングなどによるパフォーマンスの劇的向上
細分化されたモジュールを必要十分に import することによるツリーシェイキングの有効化

moment など、日付操作用のライブラリへの依存の撤廃
CSSインジェクションの廃止
膨大な数のバグフィックス

ただし、多くの破壊的変更を...

Vue2 / Vue3 でも Chart.js 3 を使いたい


 概要
Babelの主要プラグインの一つである、@babel/plugin-transform-runtime に関して、雰囲気で使わずに理解を深めるためにまとめた内容です。
概ね上記公式ドキュメントに書いてある内容を要約しただけになります。

本記事は2020年5月に個人ブログに書いてた内容を移動したものです。最新の状態とは異なる可能性があります。


 バージョン情報
以下で動作確認済み


Node v12.16.3

@babel/core v7.4.5

@babel/plugin-transform-runtime v7.4.5

@babel/runtime@ v7.9....

	 @babel/plugin-transform-runtime を理解する(Babel 7)


 概要
以下の gif のように、 URL のクエリパラメータと、Vue コンポーネントの状態(data) を同期させる mixin を作ったので備忘録。


 前提

vue 2.6.12
vue-router 3.0.2
TypeScript は不使用


 コンポーネント側

      
        component.vue
        export default {
  mixins: [useURLQuery],
  data: () =&gt; ({
    hoge: '',
    fuga: 0
  }),
  urlSyncedData: {
    ...

概要
以下の gif のように、 URL のクエリパラメータと、Vue コンポーネントの状態(data) を同期させる mixin を作ったので備忘録。


 前提

vue 2.6.12
vue-router 3.0.2
TypeScript は不使用


 コンポーネント側

      
        component.vue
        export default {
  mixins: [useURLQuery],
  data: () => ({
    hoge: '',
    fuga: 0
  }),
  urlSyncedData: {
    ...

Vue コンポーネントの状態と URL クエリパラメータを同期させる 

以下のような、 addon-controls を使った Storybook の CSF ファイルがある場合、 args は対象コンポーネントの props の型であってほしいが、当然 any になってしまう。

      
        todo.stories.tsx
        import { Todo } from './Todo'

export default {
  title: 'Todo',
  component: Todo
}

const Template = args =&gt; &lt;Todo {...args} /&gt;

export cons...

以下のような、 addon-controls を使った Storybook の CSF ファイルがある場合、 args は対象コンポーネントの props の型であってほしいが、当然 any になってしまう。

      
        todo.stories.tsx
        import { Todo } from './Todo'

export default {
  title: 'Todo',
  component: Todo
}

const Template = args => <Todo {...args} />

export cons...

React × TypeScript × Storybook で、CSF の型を付ける


 概要
コードフォーマッタの Prettier (v2.2.1) でコードを整形しただけで、Web上でのデザインが崩れてしまった事例を紹介します。

 元 HTML

      
        
        &lt;body&gt;
  &lt;div class="content"&gt;
    &lt;div class="div-a"&gt;A&lt;/div&gt;&lt;div class="div-b"&gt;B&lt;/div&gt;
  &lt;/div&gt;
&lt;/body&gt;


      
      オリジナルの HTML は div 内に...

概要
コードフォーマッタの Prettier (v2.2.1) でコードを整形しただけで、Web上でのデザインが崩れてしまった事例を紹介します。

 元 HTML

      
        
        <body>
  <div class="content">
    <div class="div-a">A</div><div class="div-b">B</div>
  </div>
</body>


      
      オリジナルの HTML は div 内に...

Prettier で HTML を整形しただけでデザインが崩れることがある

Storybook は、UIコンポーネントをサンドボックス上で動作させることで、デザインや振る舞いを開発環境を立ち上げずに確認できるUIカタログを作成するためのツールです。

本書では、現状(2020/10/26 時点) 最新版である Storybook 6.0.7 と、 Vue 2.6.11 を用いて、 CSF(Component Story Format) によるUIカタログの作成を行います。

内容のベースは公式ドキュメントのままですが、日本語で噛み砕きつつ、全体を俯瞰するよりも、ハンズオンでステップアップ学習できるような構成を心掛けています。

また、 CSF を使ったストーリーの定義や、 Storybook 6 特有の機能を用いるため、Storybook を初めて使う方に限らず、以前から使用しているが、最新の使い方をキャッチアップしたいという方にもオススメです。

なお、筆者は業務で Storybook 6.x を活用した Vue アプリケーション開発の生産性向上の取り組みを本業で行っており、その事例などについて以下ブログで紹介しております。
https://medium.com/studist-dev/upgrade-to-storybook-6-42da05471e7d

Vue と CSF によるモダンな Storybook 6 のはじめかた


 バージョン情報




version




node
12.16.3


@babel/core
7.9.0


@babel/preset-env
7.9.5


@babel/cli
7.8.4


browserslist
4.12.0




 @babel/preset-env とは
@babel/preset-env は、 babel プラグインのプリセットのことです。
そもそも babel の本体(@babel/core)は、「JSコードを入力として受け取り、ASTに変換後、何らかの変換処理を行い、変換後のASTから再度JSコードを出力すること」が責務であり、 何ら...

@babel/preset-env (Babel 7)をハンズオンでちゃんと理解する


 概要

      
        
        &lt;template&gt;
  &lt;div class="hoge" data-test="Hoge"&gt;
&lt;/template&gt;


      
      上記のdata-testのような、テストでは使いたいけどプロダクションコードには反映させたくないような属性を、vue-loaderの設定でプロダクションビルド時には除外し、以下のようにします。

      
        
        &lt;template&gt;
  &lt;div class="hoge"&gt;
&lt;/te...

概要

      
        
        <template>
  <div class="hoge" data-test="Hoge">
</template>


      
      上記のdata-testのような、テストでは使いたいけどプロダクションコードには反映させたくないような属性を、vue-loaderの設定でプロダクションビルド時には除外し、以下のようにします。

      
        
        <template>
  <div class="hoge">
</te...

vue-loader 15で、vue テンプレート内の任意の属性(data-testなど)を除外する


 概要
hard-source-webpack-pluginのREADMEの内容を要約しながら、実際に挙動を試した話。
(本記事はWebpack 4.x 向けです。 5.xからはまたキャッシュ周りの仕組みが変わっているように思えるのでご注意ください)

 version



ツール
バージョン




node
12.16.1


webpack
4.42.1


hard-source-webpack-plugin
0.13.1




 HardSourceWebpackPlugin について
HardSourceWebpackPlugin は、Webpackによるビルド時に中間...

Webpackのビルドをhard-source-webpack-pluginで高速化する


 概要
以下のようなモジュールの階層があるときに、ChildモジュールからParentモジュールのVALUEを参照したかった。

      
        
        module Parent
  VALUE = 'PARENT'

  module Child
    VALUE = 'CHILD'

    def self.parent_value
      # 'PARENT' がほしい
    end
  end
end


      
      
 Rails(activesupport) が使える環境なら簡単
流石に Module#parent 的なメソ...

Rubyでモジュールの親モジュールを取得する


 概要
dayjs は、JavaScriptで日付時刻周りの操作を簡易的に行うためのライブラリで、同カテゴリで覇権を取っていたmoment.jsが開発終了することから、その移行先として注目を集めている。
本記事では、dayjsの特徴やmoment.jsからの移行作業などと言ったことは割愛し、単純にdayjsによるよく使うTipsを紹介する。

 バージョン情報



ツール
バージョン




node
12.8.2


dayjs
1.9.1




 Tips

 dayjsを使う
CommonJSの場合

      
        
        const dayjs =...

dayjsの使い方とよく使うTips


本記事は webpack-dev-server v3 に関する内容となっており、 v4(またはそれ以降) とは一部オプションが廃止される、設定方法が変わるなどの差異がありますのでご注意ください


 はじめに
webpack-dev-serverは、webpackを用いたプロジェクトにおける開発用サーバで、ブラウザのライブリローディングを提供します。
それによって、ソースコードの編集時に、webpackによる差分ビルドが実行されると、ブラウザがwebpack-dev-server経由で更新差分を受け取り、リアルタイムに変更内容を確認しながら開発ができるようになります。
webpack-...

webpack-dev-server のオプション全部試した


 概要
vimを日常的に使っておきながら、バッファの仕組みをロクに使わずに、1ファイル1プロセスで編集したまま長い時間が経過してしまった人 に贈る、バッファ機能の基本的な使い方を紹介。
iTerm2 を始めとするターミナルツールで画面分割をすることで、複数ファイルの編集を容易に行うことも出来るが、バッファを使った複数ファイル操作に慣れることで、関連するvimの機能やvimプラグインをさらに活用することができるので、使う使わないは一旦考えずにやってみよう。

 とりあえず複数ファイル開こうや
作業用ディレクトリに以下の3つのファイルを作る。内容は Ruby のコードだが、コードそのものは...