AI時代に試したものと所感
技術系のものは Zenn に書いてたので、気づけばこのブログ一年くらい放置していた。苔とか生えてそう。
AI 関係で色々試したり触ってた
世はまさに大 AI 時代なのは周知の事実で、誰もが口を開けば MCP とか Cursor とかの話をしてる。
そういう自分も例外ではなく、ここ最近は色々と触ったり作ったりしてた。 その知見をもとにして仕事でも使う機会も増えてきた。
蓄積されてきた感じがあるので、一回吐き出しておこうかなと思う。
作った / 独自 rules の複製用 CLI ツール
"airules" という名前で、AIエディタ用の個人用 rules を管理するためのCLIツールをDenoで作った。
これはJSRで公開してある。開発はすべて Agent に書かせて、自分ではほぼコードは書いてない。
自分はいまのところ Cursor を課金してメインで使っている。
Cursor では .cursor/rules に *.mdc ファイルを置くと、Agent 実行時に読み込んでくれる。プロジェクトで rules を用意するケースもあると思うが、自分好みでカスタマイズさせたい、ということも珍しくない。
たとえば私の Cursor はピカチュウになっている。
ピカチュウは絶対「ピカチューだよピカ！」とは言わない気はするが、気にしたら負けです。
それはさておき、こういった独自ルールについては、現状 Cursor (0.49) だとエディタ自体の設定で保持する以外の方法がない。
参考: Cursor – Rules
シンプルなものであればそれで良いのだが、プロジェクトや作業の種類によっては、こういった独自のプロンプトの内容を切り替えたくなる。
自分の場合は rules の *.mdc や *.md のみを記録したリポジトリを用意して、そこから都度 .cursor/rules にコピーしているのだが、これが手間に感じてきた。
ということで、ポチポチとファイルを選ぶだけで簡単にコピーされるようなCLIツールを作ってみた、という話である。ファイル単位だけでなく、見出し単位でもピックアップできるようにもしてみた。
正直、独自ルールのファイルはまだそれほど用意していないのだが、今後は "必要に応じていい感じのプロンプトをサッと出せる" というのも一つのスキルになる気がしてるので、これを酷使しながら蓄積していきたい。
作った / Splatoon 3 MCPサーバー
一回は自分でMCPサーバー作ってみないとな、ということで作ってみた。
外部APIなら何でも良かったのだが、せっかくなら自分がテンション上がるものがいいなと思って、趣味というか日課みたいにプレイしている Splatoon のステージ情報を返すMCPサーバーを作ってみた*1。Splatoon3については、サーモンランを全ステで野良カンストしています。
なお、実験用に作ったので運用とかする気はまったくない。
llms-full.txt が便利
MCPの作り方/作ってみた記事は無数にあるのでここでは省略するが、とりあえず Anthoropic が公開している llms-full.txt というファイルが超便利、という情報だけ残しておく。
Building MCP with LLMs - Model Context Protocol のチュートリアルでも冒頭で紹介されてるので、知ってる人も多そう。
ファイル自体は以下で公開されている。
🔗 https://modelcontextprotocol.io/llms-full.txt
これは簡単に言うと、LLM向けのMCP情報がすべて載ってるテキスト、と思えばいいと思う。仕様からサンプル実装まで載ってる。
これを NotebookLM に食わせれば不明点を質問するのも容易。なお、Cursor とかの Agent に読ませる場合、ファイルが大きすぎて上手く読めないこともあるので注意が必要。
自分の場合は https://github.com/modelcontextprotocol/typescript-sdk のドキュメントなども合わせて読ませることで Agent にうまいこと実装させることができた。
失敗 / Cline での学習用プリント作成ツール
CLINEに全部賭けろ を見て「俺も全部賭けなきゃ…!!!」と思ってやってみた。
小学生の娘がいるので、「漢字とかの学習用のプリントを作るWebアプリ」をClineで作ってみようとした。
10ドル上限でどこまでいけるか、というのでトライしてみたのだが、自律型AIエージェントの扱い自体に慣れていなかったのもあって、微妙なものが仕上がって終わった。
それっぽくは見えるが、普通に各所がぶっ壊れていて使い物にはならないし、問題も全然期待通りに出てこない。
プランニングが大事ということを体感した
雑な指示をした場合、Clineはまさに暴走特急と呼ぶにふさわしい挙動だった。一気に完成まで走り切ろうとするのだが、依頼したスコープが非常に大きかったのもあり、終わるまでも長い。そして長くなればなるほど前提となる情報も大きくなり、コンテキストウィンドウと私のクレジットを湯水のように消費して終わった。こいつは人の金をなんだと思ってるのか、という気持ちになった。
そして、やはり一発では全然意図通りに上手くいかない。暴走→止める→大幅にやり直す、みたいなループになってたのが非常に良くなかった。
まず粒度が小さくなる形でプランニングをさせて、かつ段階的に作業をさせるのが重要ということを学んだ。
また、一回のセッションで走り切るのも無理があるので、プランニングは適宜外部ファイルなどに出力し、別セッションで個々のタスク単位で実行できるように導いてやる必要があった。
先に挙げた CLI ツールや MCPサーバーは、このClineでの失敗を活かして実装したので、わりと上手くいった。
お仕事 / Design System & Figma の MCP サーバー
副業でお手伝いしている先で、Ubieさんの以下の事例を参考に、似たようなことができないか検証してみてほしい、という依頼を受けた。
スプラトゥーンのMCPサーバーを作ってて良かった、と思った瞬間であった。
該当の記事自体にはMCPサーバー自体がどういう形で実現されたのか、という情報は無かったので、雰囲気で察してやってみた。（もしかしたら、今ならどこかに公開されてるのかもしれない）
「Design System の情報が一覧・検索できて、サンプル実装とかがわかればええんやろ」と予想し、幸いにも Storybook はきちんと整備されていたので、次のようなツールを持つMCPサーバーを作成した。
なお、後日公開されていた LayerX さんの事例とかなり類似していたので「やっぱこうなるよな」と安心してた。
Figma 上では Design System のコンポーネントと名称が紐づく形でデザインされてるので、これで指示したらうまくいくはずである。
ということで実際試してみたみたが、結果としては、ほぼ完璧なUIが一発で出力された。（さすがに画面は貼れない）
想像していたより遥かに上手く行ったので、これは結構驚いた。
このMCPのユースケースの話になると、毎回「これってMCPである必要あるんか？？」という話になるのだが、実際のところ「現状だとなんかよくわからんけどMCPにしたほうが上手く情報を使ってくれる」という肌感である。
将来的にはMCPである必要もなさそうなので、現段階としては
- とりあえずコスト低くMCPサーバー立てられるなら使っても良さそう
- テキスト情報でLLMに渡せるドキュメントを充実させておく
の2つを意識しておくといいんだろうな、と思った。
いろいろ試してみての所感
完全に個人の感想です。個人ブログなので許されるはず。
テキスト書いといたほうが良さそう
LLM自体もだが、それを取り巻くツールの進化が異様に速い。数週間たつとトレンドが変わっているみたいな印象を受ける。
たとえば、現状自分は Cursor を使ってはいるが、数ヶ月後にもこれを使っているか？と言われると非常に懐疑的である。
Design System の MCP についても、しばらくしたら MCP を使わずともコードベースをまるごと読ませて OK とか、何なら GitHub リポジトリを教えればそれでもう完璧に動くみたいな世界が来るような気もする。
この流れの中でずっと使えるものって何？って考えると、シンプルにLLMに渡す情報そのものでは、という気がする。
積極的にアーキテクチャ情報やナレッジなどは扱いやすい形（Markdownとか）で残しておくのが懸命かなと思う。
ドキュメントや rules を作成する際にも Agent を上手く使えると良さそう。たとえば Cursor なら /Generate Cursor Rules とかを使えば簡単に rules を出力できる。
上手く扱えると間違いなく速い
上手いこと動作をコントロールして扱えると、現状のAI Agent でもかなり効率的にコードを書けるな、という感覚になってきた。
作成したものの一つであるCLIツールの "airules" を例に見ても、これを自分でゼロから作ったらもっと長い時間がかかったはず。
Deno ですべてを作ったのだが、単発のスクリプト程度でしか使っていなかったし、周辺ライブラリの使い方などを調べるだけでも苦労したと思われる。
また、Rust, Go, Node, Deno などでの実装の比較から依頼し、かつ Deno でどういったライブラリが使えそうかのリサーチもさせたが、正直自分で調査したらそこまで深く調べられたかは怪しい。（面倒なので慣れてる Node で作る判断をしたかも）
使ってるうちに「こういう作業は上手くやってくれるんやな」というのがわかってくる感覚があった。
とにかく試してみたほうが良さそう
触り続けてるうちに得た多くの知見が、
「なんだかよくわからんが、こういう感じでやればこういう風に動きやすい気がする」
という、なんともハッキリしないものばかりだった。
頑張れば人に伝えられそうだが、正直なところ感覚的なものも多くて、言葉にして説明されたところで、同じように皆がやれるかは怪しいと思う。
いろんな記事を読んでみるのもいいが、いろいろ試してみて思ったこととしては「いろいろ試してみたほうがいいな」ということです。
(個人の感想) AI 関係のアウトプットのモチベが上がりにくい
少し毛色が変わる話で、まさに所感というか個人のお気持ちなのだが、こういったAI系の「やってみた！」系の記事のアウトプットのモチベーションがなんとも上がりづらいな、と感じている。
過去をふりかえると、AIじゃないものについてはそういうのも気軽に投稿してた気もする。
なんでだろう？と考えてみたのだが、最近は「これ LLM にドキュメント食わせて書かせただけでは…？」みたいな記事も溢れかえっていて、 従来は自分でも書いていた「こういうのを見て、こういう流れでやったよ！」みたいな How to の部分は、完全一致とは言わずとも、7-8割くらいは被ってしまうんですよね。
そうなると、自分が書く記事の差分って何？というのは「おもったこと」みたいな、実体験に基づく部分がメインになってくると。
その部分ってそれほど量無くても書けちゃうので、Xとかで「〜が良かった」みたいなポストをして、それで終わっちゃう傾向にあるのかもしれない。
とはいえ、それはそれであんまり健全では無い気もするので、ある程度溜まった段階でこういった個人ブログとかで吐き出しておくくらいが丁度いいな、と思い至ったのであった。
ともあれ、進化は速いなと思いつつも、なんだかんだ楽しみながら色々試せているので、また色々知見がたまったら記事として書いていきたい所存です。
書評『実践 Next.js ― App Routerで進化するWebアプリ開発』
先日出版された『実践 Next.js ― App Routerで進化するWebアプリ開発 』について、著者の @takepepe さんより献本頂いた。ありがとうございます！
@takepepe さんの実践Next.js本を献本頂きました！ありがとうございます！
— mugi (@mugi_uno) 2024年3月10日
読むぞ〜 pic.twitter.com/mpcWHJJRJq
献本いただいた者の責務として、大変恐縮ではあるが、書評を残させてもらう。
自分とNext.js（App Router）
「実際のところ君はNext.jsとかApp Routerのことは知っとるんか？」という話だが、業務でApp Routerを使ったフロントエンド刷新に関わっているので、それなりには把握しているつもりではいる。ただ、Pages Routerに関してはあんまり触ったことはない。少し趣味や副業で触れたことはあるが、知見がすごいあります！と言えるほどではない。
App RouterそのものはStableになる前（当時はapp dirとか呼ばれてた気がする）から触っていて、その後に追加された機能も全部を触っているわけではないが、一通り情報は追っている。Server Actionとかも使ってて、業務で得た諸々の知見を2023年の末にあったJSConf JPで発表したりもしてる。
PRやコミットログについては、業務上でハマったものとか特に影響が大きそうなものとかは見てるし、挙動が謎な部分はコードを追ったりもしてる（微細なものだけど修正PR出したとかもある）。とはいえ、超熱心に全部追ってるとかではないので、そんな激しい自信があるほどでもない。
そんな感じ。というわけで以下書評です。
App Router 学び始めにこれ読めるとか最高か…？
もうこれに尽きる…。
もう気付けば一年以上も仕事でApp Routerと付き合ってるので、今でこそある程度やれてるけど、当初はほんとに理解に苦労した覚えがある。チームメンバーでNext.js公式ドキュメントの輪読会をやったりしながらコツコツ理解を深めていったけど、それでもわからなかった部分はたくさんあるし、メンバー全員「たぶんこういうことであってるような気がする、たぶん…（沈黙）」みたいな会話をしてた覚えがある。 それがもう本書読めば全部日本語で要点抑えて書いてあるんですから、ここから学び始める人が正直羨ましい。
個人的に、特に理解が難しいと思うのは次のような部分。
- Server / Client Components の概念や設計の勘所
- 動的 / 静的レンダリングの切り替わり
- 4種類のキャッシュ周りの挙動
- Server Actionの取り扱い
- revalidate周り
このあたりを一通りバッチリ解説してくれてるのはとても助かると思う。
公式ドキュメントを読んで概念を理解できても、結局のところ一回簡単なコードを書いて動きを見てみないとピンと来ないものが多い。
例を挙げると、App Router ではfetch() の呼び出しの勘所を把握しないと、キャッシュや並列実行などの恩恵を受けられず、知らず知らずのうちにパフォーマンス面での恩恵を得られなくなったりする。そのへんはドキュメントにも書いてある部分もあるが、結局読んだだけだと本質的な理解は浅いままになって、実務でコード書いてるときに踏んだりする（実際踏んじゃって自分もPRとかでよく指摘されてた）。
一方、本書だとハンズオン形式でコードを書きながら動きを見つつ実践的に進められるので、「こういった書き方だとこういう問題が出るんやな…」というのを体感できるのが大きいと思う。あらかじめ擬似地雷を踏めるという感じ。
AppRouterよくわからんわ…という人から見たらほぼ確実に理解に役立つ内容が盛り沢山だと思う。
個人的に嬉しかったとこ
自分で言うのもアレだが、ある程度すでに知見を持ってる人から見たときにどうか？という点から見ると、ちょっと理解が不安だったところの確認に使えたのは嬉しかった。実務だとParallel RoutesやIntercepting Routesなどは使ってないのだが、そのあたりを改めて確認できたのは助かった。
また、公式ドキュメントだとまだ弱いなと思う部分として、Server Action周りやrevalidate周りがあるのだが、そのあたりも手厚く解説されてるのはとても素晴らしかった。たとえば、Server Actionを触る際にはProgressive Enhancementの考え方を切り離せないのだが、そのあたりも触れられているし、Optimistic UpdateやValidation周りにも踏み込んでいて、「ほらね！簡単にServer側の関数呼べて便利でしょ！」みたいな表面だけの内容にとどまっておらず、まさに実践って感じだった。 revalidate周りも、何をどこでいつ呼べば描画がリフレッシュされるのかの把握が結構難しいポイントで、Server Actionと組み合わせると特に混乱する部分だと思う。ただ、理解できると一気に便利になる部分でもあって、そのあたりが丁寧に解説されているのはとても助かる。
実務でやってて書籍になかった部分で知りたくなるとこ
本書で触れられていないけど実務だと困ることが多いもの挙げるなら、テスト周りかなと思う。
Server/Client Component周りで使えるツールが変わってきたり、そもそもそのままだとテスト自体困難だったりする。テストを意識してコンポーネント設計から検討する必要があるなど、結構大変な部分になる。（大変だからこそ、そこまで書籍で触れてたらとんでもない物量になっちゃって割愛されたのかなという気もしている）
ただ、そもそも大前提としてフロントエンドテスト周りの知識がある程度無いと、Next.jsでのテストにいきなり立ち向かうのは困難なのが実情だと思う。本書より先にテストだけで一定の知見を得てから公式ドキュメントの情報などを参考に立ち向かうと良いのでないだろうか。
そういえばフロントエンドテストに関するいい本があったような…？？
内容がすぐに古くなっちゃう？
雑談してる中で、本書籍に関して「Next.js更新激しいから内容すぐ使えなくなっちゃうんじゃない？」みたいな話を聞くことがあった。
私の意見としては、それは完全には否定できなくて、アップデートによって個々のAPIの細かい挙動はどんどん変わるだろうし、記載されている内容と乖離が出てくることは普通にあり得るとは思う。ただ、Next.js App Router が提供するベースとなる概念まで覆ることは無さそうで、それらは今後更新があってもNext.jsを使っている限りは腐ることは無い気がする。
そういったベース概念こそがApp Routerを理解するうえで一番難解な部分であって、同時に特に大事な部分だったりする。今は公式ドキュメントがある程度整っているので、それをガッツリ読み込めば一通り理解はできるけど、それでも理解が難しい部分や説明がわかりづらい部分もあるため、永遠に不安な気持ちになると思う。 そのあたり、日本語かつハンズオン形式で実践的に学ぶことができるのはとてもありがたく、複数の角度から知見を固めるためのリソースとして大変貴重な一冊だと思う。
あとはそもそもの話でもあるけど、本の内容が古くなることを気にしてたらWeb技術に関する書籍なんて何も買えなくなっちゃう気はする。HTMLの仕様だって "Living" Standard だし。
古くなる前に買って読めば解決だ！
まとめ
- Next.js App Router を理解したくて、 RFC・公式ドキュメントなどを読んで理解できる自信がなければ買っといて損はないと思う
- 買うか悩んでるならとりあえず買っとけばよさそう
- とりあえず今後自分は他の人に学習リソースを第一にオススメすると思う
大変素晴らしい一冊でした。ありがとうございました！
規模感の違う脱レガシーで必要なこと
「レガシー」を保守したり、刷新したりするにあたり得られた知見・ノウハウ・苦労話 by Works Human Intelligence Advent Calendar 2022 の 15日目の記事です。
筆者は過去に、中〜小規模のWebアプリケーションでレガシーフロントエンドの改善作業を業務でやっていた。その経験を元に技術同人誌を作成し、それがきっかけで「レガシーフロントエンド安全改善ガイド」という書籍を出した。
初版から数年経ってしまい、詳細な利用技術などの説明は少し古くなってしまっているのだが、ベースとなる考え方の部分は今でも変わっていないと思う。
一方で自分自身は、その経験が他の環境でも通用するのかを試してみたくなり、転職して一年強ほど大規模なフロントエンド刷新に関わっていた。
あまりにも規模が大きいため完遂を見届けたわけでもないが、現段階でも学びや得られたものは多くあったように思う。それらを踏まえて
- 規模感関係なく必要だったこと
- 大規模刷新で新たに必要になること
について、自分なりに考えてみた内容を整理してみる。
話の内容的に、中〜小規模と大規模の両方で得られた知見をベースに書いているため、多くの人に何かしらの部分でマッチする内容になっているはず（と信じたい）
なお、客観的な数値などに基づく事実ではなく、個人の感覚としての部分も多く書いている。そのため、あえて個人ブログに書く形とした。環境によっては大きく違う意見になる可能性もあるが、あくまでも個人の所感として見て頂ければと。
目次
前提
この記事内で説明する「規模感」については、筆者が経験した次のような規模を想定している
- 中〜小規模
- 改善対象のコード分量が10万行未満程度
- ある程度の時間をかければ、個人で全体を把握できる
- 大規模
- 改善対象のコード分量が50万行を超える
- 全体を把握するためにはかなりの時間と労力を要する
規模感関係なく必要だったこと
過去に経験した中〜小規模のレガシーフロントエンド刷新の経験で得た学びで、大規模になったとしても基本的には同じ考えが必要だと感じた部分。少し違う部分もあったりするが、知っておいて良かった・この考えは変わらず持っておいた方がいいな、と思ったようなもの。
改善自体のリスクを把握する
あらかじめ改善作業のリスクを把握することが重要になる。レガシー＝悪ではなくて、誰も求めてない改善であればやらないほうがいいかもしれないし、やるなら納得のできる理由がいる。メリット・デメリットを天秤にかけて着手したほうがよい。
これは規模感に関係なく同じで、むしろ規模が大きいほうがユーザーを含めた影響範囲も大きくなるため、むしろ重要度は上がるかもしれない。
把握しておいたほうがよいリスクをいくつか紹介する。
改善のリスク: 挙動の破壊
当たり前ではあるけど、バグを埋めたり既存の動作をぶっ壊してしまう可能性はある。もちろんこれによってユーザー影響が出るのは怖い事態だが、さらに「リスクを取るぐらいなら改善作業はやめておこう…」みたいな空気感になる恐れがある。そういった心理的な障壁は組織に染み付いたらなかなか払拭できるものではないと思われる。
現在筆者が経験している環境ではE2Eテストや非常に優秀なQAチームの皆さんの存在があるので、そもそもの振る舞いを根底から破壊するリスクはかなり軽減されている。逆に言えば「これが無かったら…」と考えるとわりとゾッとする。（無かったとしたら、まずはE2Eを書こう！と強く言っていた気がする）
やはり、まずは安全のために何ができるかを考えてから進めるのは規模感問わず大事。
改善のリスク: 中途半端な状態での頓挫
改善は長く続く可能性があり、さまざまな事情により途中で頓挫してしまう可能性がある。
その場合、改善前後のコードが入り混じった状態になる。これはメンテナンス対象が増えるだけで、かえって複雑化した結果になってしまう恐れがあり、これは規模感に関係なく存在するリスクだと思う。
頓挫する理由は、メインのメンバーが退職してしまったり、組織の変更によって改善作業の優先度が下がってしまったり、色々考えられる。ただ、大規模な刷新の場合は期間が長くなることもあるため、そういった「きっかけ」に遭遇する頻度も上がることになる。
改善のリスク: 改善後の状態が共有できていない（自己満足で終わる）
アーキテクチャをまるっと刷新した場合、刷新後のコードベースに触れる人は新しいアーキテクチャを理解する必要が出てくる。これには一定のコストが必要になる。
「技術が変わるなら学習するのはそりゃ必要だよね」という気持ちになるかもしれないが、ここで大事なのは “腹落ち感” で、なぜ変更するのか・何に変更するのか、といった点が納得できているかどうかで、だいぶモチベーションが変わると思う。
このあたりを雑にやると「改善したと思ったら開発コストめっちゃ上がりました」なんてことになりかねない。規模が大きいと人数も増えるため、このあたりの影響も大きくなる。
ちなみに、筆者が過去にやった場合は、事前にADRを書いて認識を確認したり、刷新後も勉強会を開いたりという対応をしていた。
現在筆者が関わっている大規模刷新の環境においては、刷新チームを立ち上げるタイミングで、旗振り役をしてくれている方がきっちりと思想の部分を文書として見える形にし、さらに丁寧にMTGを重ねて共有をしてくれた。また、数ヶ月に１度程度のタイミングで全メンバーが集まって意識を揃える場が設けられている。そのおかげで、個々の小さいチーム単位では目標が変わったりすることはあっても、刷新チーム全体でのベースの思想や目的みたいなところは安定している印象がある。このあたりはあまり関われてなかった部分なので、今は「すごいなぁ」と横で思いつつ、今後の糧にしていきたい。
まずレガシーコードをちゃんと理解する
いきなりコードに触るのではなく、ちゃんとレガシーコードを理解するところから始めたほうが良い。
特に歴史が長いサービスの場合はコードを読み解くのもかなり苦労する。だが、理解できないものは刷新することもできないので、ある程度時間をかけて把握していく必要がある。
また、規模が大きくなると、”レガシーコードの理解” の範疇に人やチームの概念が頻繁に登場してくる印象を持った。純粋にコードを読んで理解すれば良いだけではなく、変更において影響を受ける関係者が誰なのかを意識する必要が生じる。
アジャイル開発においてインセプションデッキを作ったことがあると、その中で「ご近所さんを探せ」という項目があるが、それに近い感覚。プロジェクトに関係するメンバーをきっちり洗い出しましょうね、という話なのだが、規模が大きくなるとさらに重要になってくる印象を持った。
レガシーコードを読み解いていくなかで「これはなぜこんなことに…」みたいな仕様が顔を出すこともあり、関係者が把握しきれていない場合、このあたりが迷宮入りしてしまう恐れがある。
ちなみに、筆者は書籍の中では「できれば理解した内容は資料化もするといいよ」と書いていたが、これもやはりそのまま同じ考えのほうが良いと思った。期間が長いと必然的にメンバーの入れ替わりも一定数発生するため、その際に資料が残っているメリットは大きい。また、新規メンバーに限らず、そもそも書いた本人も数ヶ月とか時間が経つと普通に内容を忘れるので、未来の自分のためにもなる。また、”ご近所さん” に確認してもらうタイミングでも資料はあったほうがよい。
改善で得たいものを明確にする
改善したいということは、何らかの得たいものがあるはずで、それをちゃんと明文化したほうがいい。これは色々あるはず
- 開発速度を効率化したい
- 魅力的な職場にしたい
- ページのパフォーマンスを上げたい
- などなど…
作業を進めていく中で、優先順位をつけて取捨選択する機会は頻繁に訪れる。その際に、自分達が何のためにこの改善作業をやっているかがわかっていれば、判断軸の一つになる。
また、段階的に改善が進んでいったときに、思い描く理想のゴールが見えていれば、それに対してどれだけ近づいたのかもわかるため、モチベーションにもつながってくる。
大規模な場合、チームが複数に分割されることも考えられるため、全体として目指すものが何かをきちんと明文化しておかないと、チームがそれぞれ的外れな方向に進んでしまうかもしれない。
小さく進める
規模感に関係なく、いろんなものを小さくしていくほうがよい。
コードの変更量を例にとっても、１回の変更が大きいほうがコンフリクトのリスクが上がっていく。大規模刷新の場合は複数チームが並行して同じコードベースを触っていることも多く、リスクはより高くなる。
ちなみに、筆者が思っていたより特に重要だったと気付かされたのは “リリースサイクルの短さ” だった。
リリースサイクルが短いことのメリットは多くの書籍などで語られており、もはや誰しもが知るところだと思われるため割愛するが、なによりもメンバーのモチベーションに直結している印象があった。
筆者は大前提として「改善作業はやらなくていいなら誰もやらない」という認識を持っているのだが、これは目に見える形でのユーザーへの価値提供を感じにくいから、というのもある。
ただでさえそういった性質の作業にも関わらず、対応した作業が長期間に渡ってリリースされないと「俺は一体これだけの期間なにを・・・（ここで記憶が途絶える）」みたいなことになる。
ただ、リリースサイクルはサービスの性質によっては簡単は変更できないケースも多い。もし調整できるなら短いサイクルでのリリースとしていくとよいが、厳しければ、自分たちで何らかのマイルストーンを設定し、きちんと進んでいる実感を得られるようにすることが大事なのかもしれない。実際筆者の環境はそんな感じでやっていて、「ここまでできれば実質リリースと同じ」みたいなラインをチームで設定することで、ある程度細かくかつ短いスパンで進められるようにしている。
一度に複数のことをやらない
改善をやってると、その中でいろんなことが目についてきて、複数の改善を並行してやりたくなってくるが、できれば避けたほうがいい。
先に挙げた “小さく進める” と相反してしまうことになり、１回１回の作業ボリュームが増えてしまう。「○○が終わった！」というまでの期間も長くなる。成果の得られない作業が続くのは結構ツラいと思う。
「どうせ改善をやるならついでに○○もやろう」みたいな気持ちで、小さな機能開発やデザインの変更なども一緒にやりたい気持ちになるかもしれないが、脱レガシー以外の作業を一緒にやるのはさらに強い気持ちで回避したほうが良い印象がある。
そもそも脱レガシーとそれ以外の作業では大きく文脈が異なり、関係者も違えば影響範囲も異なる。それを混ぜてしまうと、自分たちが何を目的として作業しているのかを見失ってしまう。また、トラブル発生時に、どちらに原因があったのかの追求も難しくなる。最終的なゴール達成までの工程や手順も同じではない可能性があり、作業プロセスの改善もしづらい。
もちろん作業環境などに応じて背景や事情はあるため、「そうはいってもな…」となるかもしれないが、できるだけひとつに集中して片付けてから次に行ったほうが懸命。
大規模刷新で新たに必要になること
ここからは、大規模ならではで必要になると感じた部分。
「規模が変わるとこういうケースもあるよ」と気をつけておいた方がいいと思ったもの。
チームや関係人数も「小さくする」
先に述べた通り、以前から筆者は「小さく進めましょう」というのを重要視している。一度に進めるものが大きいほどリスクが高まる。修正するコード量からPRのサイズ、作業サイクルやリリース間隔など、さまざまなことに対して言えると思う。
これが大規模なものだと、さらに「チームや関係者の数」という概念が出てくる。そもそも刷新作業に参加するメンバー数が多く、伴って外部関係者の数もかなり多くなる。
一つ一つの作業量を小さくしようと思っても、関係者が多すぎるとそれ自体が困難になる。手こぎボートなら１メートル単位で調節して船を進めることも容易だが、巨大客船ではなかなかそうはいかない。
このあたりは、現在のチームで輪読会などもやったチームトポロジーにおける「認知負荷」の考え方から得られたものも大きいように感じる。
大規模刷新で人数が多い場合、何らかの形で小さなチーム単位で分割し、それぞれがオーナシップを持って動けるようにするのが重要だった。どうしてもコード上での重複などは発生してくるが、体感的にコミュニケーションコストのほうが圧倒的に高い。適切に権限が委譲されていれば、それぞれのチームで責任を持って進めることができ、意思決定が速くなる。
全体を加速させる取り組み
小さい規模の場合、極端な話 “めっちゃ凄い数人がゴリ押しで刷新を終わらせる” みたいなパワープレイもできてしまう。全体像も見えやすいし、終わってみてから「結果的に○○ヶ月で終わりました！」で済むことも多い。
一方で規模が大きいと、24時間365日コードを笑顔で書くようなGODエンジニアでない限り、個人の力で直接的に影響させられる範囲には限界がある。
多くのメンバーが長い時間関わることを考えると、一人がパフォーマンスを出すだけではなく、周りが加速するための取り組みが求められてくる。いままではレベル高い人がパワーで殴れば敵を倒せていたものが、メンバーにバフをかける役割の重要度が上がってくる、みたいな感じ。
具体的なところでは
- チーム間でのコミュニケーションを円滑化させる（ツール導入や会議体をうまく設定する）
- そもそも普段の開発効率を上げる（CI高速化とか）
みたいな部分が該当してくると思う。
筆者がやってみた取り組みとしては、レガシーコードの解読を加速させるために、Chromeで使える DevTools を作ったりVSCode Extensions を作ったりしてた。
モチベーション維持がより重要になる
脱レガシー作業において最悪な事態は何かと考えると、それは「脱レガシーをやる人が誰もいなくなる」だと思う。人がいなければそこで終わりです。
大規模なものは期間も長いし、困難も多い。モチベーションが維持できないとそこから崩れていく可能性がある。「仕事なんだからモチベーションとか甘えたこと言わずにやれよ」と思う人もいるかもしれないが、筆者は「仕事なんだからモチベーションを保つ努力をしましょう」という意見です。
ちなみに、現在関わっている大規模刷新では、わりときっちりとしたスクラムを組んで進めており、それがモチベーション維持にも有効に働いている面があるような印象を受けている。複数チームが存在し、チーム単位でスクラムマスターがいる。
このあたりは、初期段階で社内でのスクラム神みたいな方が入って一通り整理してくれたのが大きかった。傍から見ていて手腕がすごかった。これが神かという感じ。
正直なところ、最初は「脱レガシーみたいな刷新作業とスクラムって相性良いのだろうか？」みたいな気持ちも少しあったのだが、実際やってみると、経験も多種多様なメンバーが長期間に渡って協力して進めていくなかで、チームが消化できるベロシティを測定して進めていくことは結構重要に感じた。ベロシティが数値として見えないと全然現実的な予測が立てられない。
きっちりとバックログとして見積もりを立てて消化していくと、チーム内で一定の目標やマイルストーンも上手く設定できるようになってくる。「こんだけ進んでるぞ！ｳｫｰ!!!」となるだけで、ある程度は楽しくやれる。
「戦略的撤退」が難しくなる
小さく進めていくことの一つの理由として「途中での戦略的撤退を可能にしておく」という点をメリットに感じていた。
脱レガシーは途中で立ち行かなくなる可能性があるため、その際に更なる負債を増やしてしまう可能性をできるだけ小さくする意味でも、「ここまでやったら一旦終わることができる」というチェックポイントを設けるのは一つの手だった。
これは改善が複数テーマにわたる場合には規模感関係なく有用だと思う。たとえば、Lintもテストも型もないようなコードベースを改善する場合、「ひとまずLintは入れた。組織体制が変わってしまったので一旦これで撤退」みたいな判断ができる。やっていることが単純なものであれば、ロールバックも可能かもしれない。
しかし、大規模の場合は、期間も修正量も大きいため “取り返しがつかない” といった凶悪な事態を引き起こす可能性が出てくる。単純な話として、年単位の時間をかけた大勢の手による変更を全部ロールバックできるか？と言われると現実的に厳しいものがある。
一人で隣町まで行っただけなら帰り道も辿れそうだが、みんなで宇宙に行ったら簡単には地球には帰ってこれない。ちゃんと次の惑星に辿り着かないといけない。撤退という選択肢がどこかのタイミングで難しくなってくる。
対応策は何だろうと考えてみたが、アプリケーションを機能単位などでうまいこと分割して境界を作り、影響範囲を境界内に閉じていくことかもしれない。やはり「小さくする」というのは重要になってきそう。あとはもう、具体的でもなんでもない話になっちゃうが、ある程度は「覚悟」みたいなものが必要になるのかもしれない。
「手伝う」には限界がある
これは自分が関わったチーム・組織固有の話の部分もあるが、最初は特定技術分野に特化した横断チームで脱レガシーを「支援」するという形を取っていた。規模が小さければ、支援チームだけで文字通り「手伝う」形でガッと改善対象をやり切ることも可能かもしれない。
ただ大規模になるとこのスタンスでは厳しいものがあることを学んだ。
冷静に考えると当然なのだが、多くの人々が長い期間かけて作り上げた巨大なコードベースに対して、支援チームが片手間でやれることには限界がある。何かやろうにも、どうしても ”チームのできる範囲でできることだけやる” というところで終わってしまう。
現在では完全に刷新チームが立ち上がり、それを手伝うというよりも完全に中に入って一緒に作業を進めていく形を取っている。より踏み込んだ話もできるし、改善作業におけるコードベース以外のプロセスなどの課題点も見えてくるのは大きい違いがあるように感じる。
総合して → 知見やノウハウは対象規模とセット
いろいろと書き綴ったが、総合してまとめるとこれに集約されそう。
脱レガシー作業というのは常に需要があり、流行りの言語やFWを使っていたとしても、時間が経てば結局レガシーになる。脱レガシーは世の中の至る所で実践されており、それらは発表資料やブログ、書籍などで多くの事例が出てくる。筆者が書いた本もその一部でしかない。
それらから知見やノウハウを得る場合、そもそもどういった規模感を対象にした情報なのか留意する必要がある。「3人の脱レガシーチームで、ツールを使うことで1ヶ月で全体を置き換えました。」みたいな情報があったとき、単純に「ツール使えば簡単にできるんや！！」と思ってやってみると、全然思った通りに進まずに事故るかもしれない。
知見やノウハウをそのまま鵜呑みにするのではなく、どういった前提が置かれているのかも注意が必要になる。具体的に幾つか例を挙げると次のようなものがありそう。
- 全体のコード量やユーザー数はどの程度なのか
- サービス性質として、軽微な不具合がどの程度許容されるのか
- どの程度古いコードが対象だったのか
- 脱レガシーで影響を受ける他のエンジニアはどの程度の人数いるのか
- など
なお、これは “既存の情報が役に立たないことがある” という話をしたいわけではなく、”あなたがその知見やノウハウの対象ではない可能性がある” 点に気をつけた方がいいという話。これはまさに筆者自身が自分で書いた書籍と現実の内容とでギャップを感じた部分でもある。
ただ、前提とされている対象に近づくことができれば、知見やノウハウが実践可能になるケースもあることも同時に感じた。中〜小規模の経験に基づくものでも、チームを少人数規模に分割する・機能単位でコードをメンテナンスできる体制を整える、みたいなことができれば適用できる部分が出てくる。このあたりの前準備が必要になることも併せて意識しておくと良さそう。
というわけで、規模感の違いによる脱レガシーの話でした。
だいぶ個人の感想っぽいものを長々を書いてしまったが、誰かの役に立ったのなら嬉しいです。
📝 Vue Fes Japan Online 2022 / 見たセッションメモ
一日セッション見つつメモを残したので、個人ブログに放り投げておく。
殴り書きなので何の清書もしてないし、誤字脱字もチェックしてないです！！！
Keynote | The Evolution of Vue / Evan You
- 0.x系の Pre バージョン時代の話
- ES5のみのFeatureを前提にする必要があった
- 1.0のコードネームってEvangelionだったのか..
- 2015-2016でのコアなライブラリ群の追加が多かったらしい。Vue Router とかVuex
- 大規模SPAアプリケーションの構築の解決狙い
- Vapor Mode
- Virtual DOM への依存がない
- パフォーマンス特化でのプリビルド
- 今後
- Vue2→3の移行期という認識
- 30%が Vue3, 25%が 2.7らしい
- Composition API と script setup は 50% 超えてるらしい
- 暫くは大きな変更がない状態で使ってもらい、変更があっても既存機能は使える状態にする
- Resumable Hydration (Inspred Qwik)
突然 Qwik が出てきてビビるが、未来の新しい姿がチラ見えしてた。
メドピアのサービスにおけるテスト戦略の過去と未来 / メドピア株式会社
- kakari というサービスのテスト戦略
- Rails の MPA & クライアント側で Vue の SPA のハイブリッドな構成
- Jestでカバレッジが50%以下 → 現在はコンポーネント数が倍以上でカバレッジ60%切る程度
- Storybookでの開発とreg-suit
- が、Storybookはうまく運用に載せられず破棄したとのこと
- 計画的なテストやツール導入が大事だよという話だった
Storybookを後々破棄したというのは悲しい話であった。 ただ導入するのではなく、運用周りとかまで考慮しないと上手くいかないのかも。 テストとの乖離があったとのことだったが、そのあたりは composeStories とか使うと少しは軽減できるのかもな〜とかを考えてた。
Evan you に聞こう
- Q: 他FWと比較した場合のVue.jsの良さ
- A: Vueが一番 Approachable。ドキュメントの充実や、とっつきやすさ。Vueに馴染みがないメンバーでも学習コストが低く戦力になれる。
- Q: こういうユースケースでは Vue がいいよ、という例はあるか
- A: ユースケースがわからないような場合にとりあえずVueを使う、というほうがわかりやすいかも。 Progressiveという意味として、小さく初めて大きくする。 Javaで作られてるようなアプリケーションとかにビルドステップなしで導入ができたり、 大規模なJavaScriptアプリケーションにも導入できる
- Q: SFC で JSX のように複数 template を変数化する未来は来るか？
- A: 技術的には可能で、RFCでDiscussionもある。ただ、SFCの場合は影響が大きい。 Closedなシンタックスで作って影響が閉じるようにすれば技術的にはできそう。 将来的に、Discussionの中で有用なユースケースが出てくれば可能性はあるが、それ以上の回答はできないのが現状。
- Q: Options API は今後もサポートされる？
- A: いまのところ大きな変更は予定してない。Options / Composition API 両方いい形に落ち着いている。 Options API に機能が追加されなくとも、裏側では Composition API は使われている。 今後しばらくは Options / Composition API ともに大きな変更は予定されてない。
- Q: ハマっているアニメはありますか？
- A: 実はアニメあんまりみない。漫画は読む。呪術廻戦
- Q: 仕事とOSS貢献を両立するコツは？
- A: 実際Vueを始めたときはGoogleにいて、仕事しながらOSSするのは最悪のワークライフバランスへの近道。 なんのためにOSSをやってるのかで、ワークライフバランスが大事なら趣味としてやるといい。 コミュニティにスタンスをオープンにしておくと気持ち的にも楽になる。 キャリアを意識してフルタイムでやるなら、ワークライフバランスを犠牲にする必要もでてくる。 自分の中でOSSを何のためにやるのか？を把握してやっていくのが重要。
- Q: Nuxt3が未だにRCバージョンだが、VueのLTSに影響を与えることはあるか？
- A: NuxtもVueも独自のタイムラインで動いていて、基本的には関係はない。 Vue2は来年の年末がLTSとアナウンスしていて、Nuxtとすり合わせて調整するなども考えてはいない。 補足すると、Extend Support (延長サポート)というプランを計画している。これはスポンサー企業等向けの有償サポートになる。
- Q: デザイナーはどうOSSに貢献できるか。ドキュメント以外でコントリビュートできるか？
- A: 非常に興味深い質問。いまのところVueにデザインに関する大きなニーズは無い。 ドキュメントもリデザインは終わってる。ただ、イラストレーションがあったらいいな、という話はある。ブランディングも含め様々なテイストがあって一旦話は流れた。 デザインは顧客中心にニーズなども考えて入っていく必要がある。 「プロダクトが好きでやれることはある？」と聞いてみるのは良い。 いきなりロゴをデザインして投げてみるなどは迷惑になることが多い。 プロダクトが求めていることを把握する、というステップを踏むのは良いと思う。
- Q: ViteがDenoで動くようになってきてDenoが整いつつあるが、Vue本体でも準備していくか？
- A: いまのところViteでDenoが動いてるなら動くはずだが、SSRがキーになる。 Cloudflareで動いてる例などを見たことがあり、おそらく動くはず。
- Q: SolidJSにインスパイアされたVaporなど、今後サポートする領域が増えるとリリースに時間がかかるなどの影響がありそうといった懸念があるが、どう考えているか？
- A: 基本は自然な流れだと思ってる。どのプロダクトでもユーザーが増えると速く動けない。 ミッションクリティカルな部分で使われてるケースもあり、責任もある。 Vue2からVue3への新しい書き方の紹介での反応から学んだこともある。 リリースに対して慎重にならざるを得ないのはそうかなと思うが、人が少ないとかそういった理由で遅くなっているわけではない。
- Q: 何があなたをVue.jsに駆り立てるのですか
- A: 情熱やモチベーションはフェーズによっても変わってきた。 最初は趣味で、技術的に新しいことをやってみたかった。 途中から Vue の認知が増え、もっと大きなものになるかも？という野心的な思いがあってやっていた。 今は責任感が非常に大きい。コミュニティの強力がなければVueは今の場所にはない。 今の生活がかかってる、というのもある。 責任感もあるが、技術者として新しいアイデアを見つけるなどバランスにも気をつけている。今Vueに関われて新しい挑戦もできているのは幸せな点。
エモかった。 キャリア意識するならワークライフバランスを犠牲にする判断もあるぞ、と言ってたのは強かった。個々人で判断するならたしかにそれもアリよな。
負債が溜まったレガシーフロントエンド画面を Vue.js でリプレイスした話
- 10年前に生まれた Rails + jQuery のアプリケーション
- 見た目を変えたいのにRailsを触る必要があるなどの課題
- 優先順位つける → 将来的に改善可能性が高い画面から
- 変更頻度はみない。バナー変更などによる変更の可能性もあるため
- StorybookやVRTによる担保
- 一括リプレイスのため、E2Eは考慮から外した
- むずかしさ
- jQuery→Vue.js (命令的UI→宣言的UI)の置き換えの難しさ
- A/Bテストの残骸など、使われているかわからないコードがある
- 実は元々壊れてた場所
- 本体リリースに先駆けて整理した
- Container Component を使い統制を取る
- styleを持たず。バックエンドとのやり取りをする
- script を持たない Layout Component で整理
- 「どうして…？」というコードがあった
- HTMLがAPIで返ってきちゃう
- 既存のAPIのレスポンスに、UI側に制御を委譲するために必要な値(例だとID)を追加することで既存影響を減らす
- APIレスポンスにHTMLが残ったままになるけどいいのか？
- → 将来的に独立化を検討し、一旦はOKという形で進めた
- 目的を明確にしてやらないことを決めるのが大事 + やめないこと
JSからTSへ移行したVue.jsプロダクトの型チェックを漸進的に強化する
- TS化が不完全なVue.jsプロダクトの型チェックをどう強化していくか
- TS & Vue の歴史と現場の話。今はVue.jsのTS対応は充実してる
- LAPRAS … Django & Vue.js。Vue.js SFC が 680ファイル。TS 750ファイルほど。
- TS化が不完全
lang="TS"ではない SFCstrict: trueではない- CI で型チェックできていない
- エディタがエラーで真っ赤になる
- 実行時エラー回避や開発体験・保守性向上に加え、Vue3更新への布石も踏まえ更新をしたい
- Design Doc の作成からやった
- TS化のジレンマ → CIでチェックしたいが、既存コードの型エラーが多すぎて型チェックを強くできない
- 既存の型エラーすべてに
@ts-expect-errorを付与し、型エラーを回避して型チェックを追加する - https://github.com/kawamataryo/suppress-ts-errors
- 既存の型エラーすべてに
- 静的アセットのビルド結果比較
- TS化の進捗を可視化するDashboardを作成
十数万レコードに耐えうるVue.jsプロジェクトを実現するためのパフォーマンスチューニング
- 大量データ(4000人)を入れてみたらめちゃくちゃ重くなった
- 4000 x 40属性で16万件入る
- 初回アクセスですべてのデータを Vuex に格納してるため
- 画面ごとに必要なデータを取ればいいが、修正影響が大きい
- 既存アーキテクチャを変えずにパフォーマンス改善をしたい
- Chrome DevTools を用いた計測から
- Peformance計測から、時間のかかっている処理とメモリ使用量の多い部分を調査
- Object.freeze を利用し、リアクティブを回避
- 大量の"組織"の描画
- まずは計測
なるほどVueコンポーネント
Options API → Composition API でコンポーネント開発はどう変わったか？
- Options API がオブジェクトスタイルで書いていたのに対して、Composition API では関数ベースで書ける
- 置き換えしてみて大変だったことはある？
- 置き換えツール的なものを利用した
- 型については Vue.extend → defineComponent でいけたが、単純に物量のつらさ
- 置き換えツール的なものについて
- SFCを入力に、script部をAST解析してCompositionAPIに変換する
- Options API は複数コンポーネントで共通部の抽出がつらい
- computedの共通化とか。Mixinがあったけど、Mixinつらい
- コンポーネント単位が大きくなりがち
- Composition API ではテストが書きやすくなった
Vueで作るアクセシブルなコンポーネントについて
- STUDIO のアクセシビリティについて
- 詳しい人じゃないとわからない、というのが難しい部分
- Vueならではの大変さ
- Vue特有みたいなものはないが、HTMLの構造を変えないといけないシーンがあったりする
（疲れてしまってこのあたりで少し離脱した。老い）
From Zero to One
- Nuxt Web について
- Nuxt Labs 創業者 Sebastien Chopin によるセッション
- Nuxt は 5200万DL されており、35万以上のサイトで利用されてる
- Nuxt2 と Nuxt3 の比較
- Web Server: connect → h3
- Bundler: Webpack 4 → Vite or Webpack 5
- UI Framework: Vue2 → Vue3
- Routing library: Vue Router 3 → Vue Router 4
- ルーティングが必要ない場合ライブラリごと除去される
- Meta management: Vue Meta → VueUse Head
- Server(less) packager → Nitro
- Hello world アプリケーションで比較した場合、Nuxt2→Nuxt3でサイズが1/3 (30kb程度)
- Next 12 と比較しても小さい
- Nitroが生み出してるコードは何？
- Nuxt3
- Edge Side Rendering
- CDNのノード上で動作させる。制約として、たとえばサイズ制限(5MB)など、Node.js や ブラウザ API は使えない。Nuxt3 はこれらを回避できる。
NITRO_PRESET=cloudflare npx nuxi buildでビルドできる- https://vuefes.nuxt.workers.dev/ でデモを見れる
- Cloud Flareworkers / Vercel Edge / Netlify Edge / Deno Deploy / Lambda Edge などなどで動く
- Nuxt Image (現在はβ)
- Hybrid rendering: Server + SWR + Pre-rendering
- Full static generation
- Component Islands
- Astro の Island アーキテクチャ的な
- PWA
- i18n
- など
- Edge Side Rendering
- 現在 41 のモジュールが存在する
contentモジュールとかが人気
- Nuxt Themes
- Docus と呼ばれるもの
- Nuxt 2.16 も止まったわけではない
- Vue 2.7, Next Bridge(beta) など
Vite 3 and Beyond
- Viteは Vue 3 での推奨になっており、Nuxt 3 でも利用されてる
- Slidev, Vitest など..
- Larabel が Vite をデフォルトで採用した
- Vite 3 の新機能
- Node 12 ドロップ
- ドキュメントが新しくなった
- スターターテンプレートを整理
- CLIも刷新
- 最初のロードに時間がかかってしまう問題について
- 通常は Code Spliting で対応する
- 事前に分析して依存パッケージをesbuildでバンドル
- 2.6 以前は、スキャンと最適化はサーバ起動前にやってた
- 2.9 時点では、並列で処理できるようにはなってたが、プラグインが依存関係を注入するなど、見つからないコードがあると解決に失敗するため、その場合はフルリロードが必要だった。これによって、特定のプロジェクトでは起動が2倍遅くなる
- 3.0 ではこれが改善、かつ依存がキャッシュされるため、2回目以降の起動は特に速い
- ESMがデフォルトに。現状CJSのためのレイヤーは提供しているが、将来的にすべてESMになるのを想定。
- Vue 3.1も既にリリースされてる
- HTMLパーサーを parse5 に移行
- Rollup の新しい機能(Stage)が使える
- バンドルサイズも削減
- Vite 4 の話
- HMR Partial Accept
- ESBuild Deps Optimazation at build time
- デフォルト有効化されるかも
- Rollup 3 への更新
- これは Vite 4 を待たずに更新されるかも
Component Testing
変更時の再ロードがめっちゃ速い。常に画面見ながら開発できるのは体験として良さそう。 ブラウザ起因の不具合とかも起きづらそう。
ただ、途中の激しいメソッドチェーンはちょっと読みづらいかもなぁという感想だった。
今ならPlaywrightでも類似のことができるはずなので、導入検討するならそちらも見たほうが良さそう。
Patterns of VueUse
- VueUse 開発から学んだベストプラクティス
unrefによるrefかどうかに関わらない値の取得- 引数で取る場合には
MaybeRef型が使える - VueUse 9.0
- computed を渡すのではなく、単純な getter 関数を渡すと内部で computed にしてくれる
- "Reactivity Getter" と呼ぶらしい
effectScopeonScopeDisposeを使うことで、一括した破棄処理などができる。onUnmounted時も呼ばれる
effectScope は把握してなかった。
onScopeDispose との組み合わせで、汎用 Composable 作るときにクリーンアップ処理を柔軟にかけるの良さそう。
Peephole
まだ公式じゃないが、実験的に開発している機能などを紹介のコーナー
unplugin-vue-router
- Vue Router の型を定義できるようになってる
- auto complete などが使える
- FileSystemルーティングでのルーティングでの型推論が効く
vue-router/auto- 追ってRFCでユーザーの意見も聞いていく
- パスの絞り込みを行うと、paramsの方も絞り込まれてtype safe になる
pinceau
- (ﾊﾟｯｿ) / フランス語でブラシの意味らしい
- https://github.com/Tahul/pinceau
- CSS in TS framework
- こちらも unplugin 配下らしい
- Nuxt とか Vite とかで使える
- Configuration フェーズと Painting フェーズ がある
- 設定の定義としては、Design System に則って設定する。CSSだけを定義するだけでなく、スクリプトとかも登録する
<style scoped lang="ts">の中でCSSをTSで書く- auto complete が効き、native css のものは使えるし、事前に定義したものも使える
- 設定ファイルから消すと、IDE上ではエラーになるし、型としてもエラーで検知する
- 複数プロジェクトで同じデザインシステムを使ってる場合に、変更を検知でき、堅牢に定義できる
computed style- 関数を渡すことができる
- 関数から
propsを利用したスタイリングもできちゃうし、型チェックも効く
- テンプレートの中でオブジェクトを渡して使い分けることもできる (sm/md/xl とかで設定を分けるとか)
computed style は styled-components みたいだなって思った
reTypewriter
- Typing Simulator
- コードの変更を再生するソフトウェア
- デモでコードを書いたときに誤字もあって、成功するまで収録しなおすのがつらい
- VSCode Extension で使えるようになってる
- 適宜スナップショットを撮る
- 共通部分は再利用するような感じで動く。ホントにType Writer みたいな
- 一度スナップショットを作れば、reTypewriter側の修正で順番を入れ替えたりもできる
- ミスのない発表ができるぞ!!
かんそう
数年前に台風を食らってしまったVuefesのときは本当に残念だな〜と思ってたので、ただの参加者だが感慨深い感じがあった。
仕事でVueは使わなくなってるが、順調に進化しているな〜という印象。 型周りがツラいと言われてた気がするが、今やそんなことはないのでは？という感じがした。
🏏 素振り: React Hook Form
あーはいはい、React Hook Formね、知ってる知ってる（知らない）
そんな状態なので素振りしておく。
React Hook Form
React Hook Form の重要なコンセプトの一つは、非制御コンポーネント (Uncontrolled Components) をフックに登録（
register) し、フォームフィールドの値を検証と収集できるようにすることです。
DOMベースに値を持つコンポーネントを主体に、いい感じにフォーム管理ができるものという理解をした。 自分がReactを書くときは今のところ制御コンポーネントを使うケースが多いので、React Hook Form 向けに脳をスイッチしないといけなさそう。
useForm と register
特に重要なのは useForm と register の2つ
const { register, handleSubmit } = useForm();
<input {...register("firstName")} />
register から UseFormRegisterReturn 型の値が返ってくる。
非制御コンポーネントで必要になる ref や、onChange, onBlur なんかも一通り含まれるので、これをprops適用するだけで一通り input タグのセットアップが終わる。
既存フォームへ適用する際は、register そのものを渡すか、 forwardRef で ref を透過的に扱う。
❓ 状態管理する場合の例として、状態管理への書き込みをonSubmit に仕込んでる。現実問題他のタイミングのほうが多そうだけど、値をサッを全部取ったりはできない？
→ getValues 呼べばok
TypeScript との組み合わせ
useForm に対して型定義を指定するだけだった。
getValues とかもいい感じに型がついた。
バリデーション
❓ バリデーションといえばzodを思い浮かべたけど、連携できるのか？
人類が考えることは同じだった。先駆者の皆様ありがとう
react-hook-form と zod でバリデーションのその先へ React Hook FormとZodを組み合わせて利用する｜食べログ フロントエンドエンジニアブログ｜note
どうやら Resolver という仕組みがあり、バリデーションライブラリであればシームレスに統合できるらしい。
https://react-hook-form.com/api/useform/#resolver https://www.npmjs.com/package/@hookform/resolvers
zod であれば @hookform/resolvers/zod でいける。
FormData と型定義が重複してツラいのかと思ったけど、 z.infer で型に変換すればいいだけだった。
const schema = z.object({
firstName: z.string().min(1),
gender: z.enum(["female", "male", "other"]),
});
type FormData = z.infer<typeof schema>;
<input {...register("firstName")} />
{errors.firstName?.message && <p>{errors.firstName?.message}</p>}
完全に理解したので、ほかのAPIとかをみてみる。
useForm
register 以外で気になったやつを見てみる
formState
フォームの状態に関する色々を含んだ state らしい。
- isDirty で変更されてるか / dirtyFields で変更されたフィールド値
- defaultValues で初期値
- valid かどうか
みたいなものが取れる。
watch
変更に応じて再描画をトリガーさせたい時に使えるらしい。 なんか迂闊に使うとめっちゃパフォーマンスへの影響がある気配を感じた。
reset
リセットするらしい。 コンポーネントのライフサイクル的にリセットが必要なケースでは役に立ちそう。
trigger
バリデーションを発火させるらしい。メソッド名 validate とかじゃないのね
useController
他のフォームコンポーネントライブラリを使う時に、register だと適用できないので、useController を使うことで独自にマッピングできるぽい。
基本的に register を使っておいて、どうしようもないときの手段と理解した。
useFormContext
コンポーネントってフォームも含めてネストするのは容易に発生するので、その時に Context 使っていい感じに子孫に受け渡せる。便利そう。
実際には FormProvider でラップする。
でもテスト書く時とかどうなるんだろ。
useWatch
watch での再描画のスコープをフックの範囲に閉じ込めるものぽい。
迂闊に watch 使うと再描画激して死ぬみたいなシチュエーションで、子コンポーネントだけに再描画範囲を閉じ込めたりできそう。ﾅﾙﾎﾄﾞ
useFormState
useForm で生成される状態のうち、一部の状態のみに絞り込んでSubscribeできるようになる。
FirstNameInput みたいなコンポーネントを作った時に、 useFormState 経由で firstNameだけ購読させれば、レンダリングの抑制ができるぽい。
useFieldArray
配列系のフォームの操作で使える。 みんな大好き ToDo アプリの行操作とかを作ろうと思ったら使いそう。 普段の開発でも登場シチュエーションは多そうな気配を感じた。
所感
便利そう。導入されるケースが多い理由が少し理解できた気がする。 APIも多すぎず、かつシンプルで理解しやすかった。
TypeScriptとの親和性もあって、zodでバリデーション組んだりできるのも良さそうだった。フォームの初期化とかもサクっとできるのはよさそう。
一方で、 useController とかでUIコンポーネントと繋ぎこみとかし始めると結構カオスになっていきそうな気配も感じた。なんでもかんでも便利そうだからと言って突っ込むと死ぬのはお約束なので、まあ自己責任ではありそう。
IE11が去った後に使える機能一覧を確認するサイトを作った
IE11の考慮が不要となった場合に、特定のブラウザバージョン以降で使えるようになる機能一覧を列挙して表示するサイトを作った。
the-world-after-ie-left.vercel.app
リポジトリはこちら github.com
デフォルトでは
以降で使える機能を確認できる。
※ ちなみに雑にVercelにデプロイしてるので、レスポンスが巨大すぎるとVercel自体の制限に引っかかって死ぬことがあるので、落ちる場合は絞り込み用のブラウザバージョンをちゃんと入れてください。
IE卒業式という社内イベント
先日、IE卒業式というイベントが開催された。これ自体は公のイベントで、とてもいい内容だった。
それとはまた別で、社内でも似たようなIEサポート終了に伴うちょっとしたイベントが開催され、その中でLTをすることになった。お題としては「IE11を考慮から外すと◯◯ができるよ！」といったものをリクエストされた。
最初は単純に MDN のドキュメントからいくつかの機能を感覚でピックアップして終わろうかなと思っていたが、実際調べていくと、山のように機能があることに気付いた。
「これはそもそも機能を洗い出すこと自体に何らかの仕組みが必要では？？」という考えに至り、LT用にサイトを作ってみることにした。5分の発表のために私は一体何を。
仕組み
至ってシンプルで、MDNのドキュメントのベースにもなっている mdn/browser-compat-data のデータをもとにフィルタリングして表示しているだけです。
ちなみに最初はリポジトリ内に含まれるデータのJSONファイルを全てパースして、JavaScriptで取り扱いやすいデータオブジェクトを作って、かつ型定義も自分で書いて頑張ってたが、実は mdn/browser-compat-data はそもそも npm パッケージとして公開されており、データも型も全部公開してくれていることに後で気付いて「ｳﾜｰ!!!」ってなった。ちゃんとリポジトリの中を確認しましょうね、という学びを得た。
（ちなみに、意外と自分で書いた型定義は概ね正しかったようで、パッケージ提供のものに差し替えたあともすんなり型チェックがパスしてビックリした）
作ってみて
単純に機能を眺めているだけでも結構おもしろかった。
普通に知らない機能もあったし、Transpile/Polyfillを当然のように使ってたので、たとえば Array.prototype.findIndex とかは「そうか、IEってコレも使えなかったのか...」みたいな気持ちになった。
公開したままにしとくので、興味があれば見てみてください。
おわり
リモートワークスタイルチェック用サービスをつくった #リモートワークスタイルチェック
リモートワークスタイルに関する質問に答えることで、リモートワーク比重・文化がどういった具合かを確認・共有できるサービスを作った。
remote-work-style-check.mugi.dev
こんな感じ↓の質問にぽちぽち答えるだけで良いので、すぐ終わる。簡単。
全部答えると↓のような全てをまとめたいい感じの1枚画像を表示してくれる。
もし忙しくなければチェックをやった上で、結果ページから結果をツイートして拡散してもらえるととても嬉しい。
チェック結果の画像も誰でも自由に使ってOK。
サービス内での項目は以前公開した "リモートワークスタイルチェック" の内容に沿っている。
🔗 リモートワークスタイルチェック · GitHub
🔗 "リモートワーク"の認識ズレ解消のためにリモートワークスタイルチェックを作ってみた - memo_md
チェックに答えた結果を表示するだけではあるので、サービスというと少し大げさかもしれない。
作ったモチベーション
リモートワークスタイルチェック自体は、"リモートワーク" という言葉に関しての認識の齟齬を減らしたいという気持ちがあって作った。
本当にありがたいことに、実際に一部の企業さまがこれを利用してチェック結果をブログなどで公開していただいた。嬉しい。
永和システムマネジメントさん
blog.agile.esm.co.jp
Arentさん
note.com
チェックを通じて、個人・企業の双方で「リモートワークも色々あるんだな」という気づきを一人でも多くの人に与えたいというのが根底にあるので、似たような形でより多くの人にチェック結果をアウトプットして欲しいな〜と思っている。
しかし、実際チェック項目は12個ほどあり、ちゃんと内容を読み込むと結構めんどくさいし、それをさらにアウトプットしろと言われるともっと手間ですよね、というのはわかる。
そこで、カジュアルに誰でも簡単にチェックしつつ、かつ結果を共有できる仕組みが必要だな〜と思い、このサイトを作った。
みんなのリモートワークをより良いものにするためにぜひ使ってみて。
技術的な話
特徴的なところでは次のようなものを使ってる
- サイト自体
- Remix
- Vercel
- OGP画像生成
- Playwright
- petite-vue
チェック自体はさほど難しくないReactアプリをRemix上に構築している。Remixを使わないといけない理由は皆無であり、使いたかっただけである。
OGP画像生成
結果ページやSNS共有のために利用するOGP画像については、チェック結果内容に応じて動的に生成している。
これは、画像を見た目となる要素をHTMLで構築し、それをPlaywrightから参照したうえで、要素のスクリーンショットを撮影することで生成している。Remixの一部ルーティングを画像用に用意しており、そこにアクセスするとPlaywrightが起動して結果を返すようになっている。PlaywrightではローカルのHTMLも開けるので、その際にクエリパラメータを付与し、それをスクリプトから参照することで値を切り替える。
ただ、さほど要素の多くない画像用のHTMLとはいえ、さすがにDOM構築を手でやるのは面倒。専用にビルド環境を構築しても良かったが、せっかくなので触ったことのない petite-vue で作ってみた。 petite-vue は Vue.js の超軽量サブセットで、ビルドなどを必要とせずにすぐにVue.jsの基本的な機能を導入できるものと思ってもらえればよい。
感想としては、まさにこういう用途のためのものだなという感じだった。雑に突っ込めば即Vue.jsが動くので手っ取り早い。余計なファイルも増えない。ただできることもかなり限定的なので、少しでも複雑なことをするとあっという間に破綻しそうなので、使い所は慎重に。
デザイン的なところ
TailwindCSSで気合いで構築した。
猫の画像については、DOTOWN の画像を利用させていただいた。
素敵なかわいいドット絵がクレジットなしで利用させていただける。神である。
そういうわけで、どの程度流行るかはわからないけど、もし暇なら試してみて貰えると嬉しい。
