家でコースっぽく料理をするための技術
人間タスクスケジューラーになろう.
今年のクリスマスは我が家で同居人と家でプチコース料理をしました. 写真はないです.
お品書きは以下の通り
既製品はローストビーフだけです.
さてこの品数をちょうど良いタイミングで出し続けるための技術をまとめていきます.
前準備
素材を買う. コース料理に大事なのは高級感です. 高級感を出すためのコツは素材にこだわることですね.
身近でちょっと良い素材を買うために大事なのはデパートの生鮮食料品売り場に行くことです.
今回肉に少しこだわりたかったので丸井今井の地下に入っている柿安に行きました.
三重の会社なんですね.
こういうところはグラム単位でお肉を売ってくれるのでざっくり予算と食べたい量で選びましょう. 例えばハンバーグの場合一人当たり130g~180gの範囲で頼むといいですね.
仕込み
料理は仕込みが9割です. って誰かが言ってたような気がするんですがこれはマジでした. 実は料理における調理工程ってローストビーフとか長時間かけて焼いたりする工程を除いてメインの工程って数分で終わるんです. じゃあ何に時間がかかるかって？
食材を切ったり, 玉ねぎを炒めてキツネ色にしたり, ソースを作ったりそういうのに時間がかかります.
ということで各メニューごとに, あとは火を通すだけ くらいまで作り込んでおきます.
個人的な経験に基づきますが, 野菜⇨魚⇨肉の順番で仕込むと良かったです
マグロとアボカドの和風ポキ
味をなじませたかったので出す前に味付けまで済ませますが, アボカドを賽の目に切るのと, マグロの柵を賽の目に切るので２工程に分けました.
温野菜とオーロラソース
使った野菜がスナップエンドウとブロッコリーだったのでどちらも
ここで大事なのが火が通る時間を調べておくことです.
これを見る限り, ポキを食べ終わって鍋を沸かし直し野菜を入れ直してもいい感じのタイミングになりそうなことわかります. ソースは作っておきましょう. スナップエンドウやブロッコリーは食べやすいように筋等の硬いところをここで取っておきます.
もう1つ大事なことがありました, 食べ始める前にお湯を沸騰させておきましょう. 前菜で出したので湯を通すまでに温め直す時間が短くできます.
- ローストビーフとマッシュポテト
ローストビーフは既製品なのでマッシュボテトを作ります. マッシュポテトは潰して裏漉しまでを先にやっておきます. 火が通るのに10分近くかかるのでどの野菜を切るよりも先にこれの準備をします.
今回マッシュポテトにバターを入れているのですが, 食べる直前にポテトを温め直して混ぜ込みます. 固まったら悲しいので
- 黒毛和牛と白老牛のハンバーグ
今回つなぎや具材として肉以外に炒めた玉ねぎ, 卵, パン粉を少し入れています. 一番時間がかかるのが炒めた玉ねぎです. 狐色に綺麗になるのに時間がかかります. ポテトの仕込みと同じタイミングで始めていくとちょうど良いです.
- たらこパスタ
たらことバターと味付けをしてボウルに入れて冷蔵庫にinです. 終わり
- スイートジャガイモ
マッシュポテトのあまりにバターと砂糖を足して焼くだけです. 仕込みは終了.
ここまでで自分は片付けと一緒にやったので1.5hくらいかかりました.
食べる&調理
食べて, 終わったら次の調理をします. 最後のパスタは少し早めに準備しておくと良いです. 麺が茹で上がるのに8分とかかかるのでね.
以上, 皆様の2026年の家庭料理が豊かになったら嬉しいね.
横転した時，どうするか
北海道の冬道はよく滑ります。
そう，車が横転するくらいに。
車が横転したら
単独事故・同乗者なし・身体への影響なしが前提です
- まず車のエンジンを切ります（意外と判断迷いますが，エンジンがかかったままだとオイルがエンジン内に周りエンストないしは火災等の二次災害の危険性があるので切りましょう
- 脱出方法を考えます。今回は助手席側のドアを内側から開けて縦に外に出ました
- 車の上に乗り，周りの地形を確認し，安全に降りれる場所を探します。
- 車から出る際に携帯，財布，免許証，毛布ないしは上着（大事！）を持てるなら持って出てください。
- 周囲の状況を確認し，他の車等が来ない場所まで移動し警察に通報してください。
連絡する先
上からの順番で電話をかけましょう。あなたがスリップを起こしているとき他の誰かもスリップを起こしているかもしれません。 そういった場合警察やJAFが来るのに1時間近くかかります。もっとかかるかもしれません。 車から離れ暖かい格好をして待ちましょう。
保険は手厚い方が良い
今回あいおい同和損保（以下、あいおい）の保険に入っていました。あいおいの保険はJAFと連動しているらしく、手配したJAFと連携してレッカー手配まで行ってもらいました。
今回横転したのは北海道は網走端野線緋牛内付近でしたが札幌自宅付近までの距離は約300km~350kmです。
レッカー費用が1kmあたり約800円だったため、それだけで240,000円近くかかります。が、あいおいの保険では上限30万円まで保証がついたので、高速代込みで若干足が出るくらいで済みました（確か370km前後だった記憶）
車の保険料月それなりの値段がしますが、道内長距離ドライバーの皆様におかれましてはなるべく手厚い保証をば...
最後に，スズキの軽自動車はすごいぞ
この後横転状態から戻った車ですが、右前輪の軸が歪みうねりながらタイヤを回していたにも関わらず車は自走できていました。 エンジンかけっぱで１時間以上横転していてもエンジンはかかります（かといって動かし続けたら問題は出るかもしれないですが）
以前、TopGearというイギリスの自動車番組で日本車（トヨタ車）をできる限り酷い目に合わせてそれでも動くかという「Killing a Toyota」という企画がありました。がこれ最終的に高層ビルのてっぺんから落としても動いたんですよね...（最後のPartだったはず
まあそんなこんなでスズキの軽自動車というか国産車ってすごいですよね、12万円で買えたのがラッキーでした
次の車どうしようかな〜20万円くらいでもう少しいい車がないか探そうと思います
追伸
前から車が突っ込んできそうな時は足をあげてください。ダッシュボードに挟まれずに済むので被害が減らせるそうです（北見のJAF隊長より）
ぺちおだは なんかいきても だいまんぞく（字余り）
ちょうど1ヶ月前くらいに参加したPHPカンファレンス小田原2025の参加レポです。 いまだに参加ブログで何を書くべきか迷うので、思ったことを書いていくのがいいかなと勝手に色々書いていきます
PHPerじゃなくても毎年参加したくなるカンファレンス
普段ほぼPHPを書かない非PHPerの僕ですが、去年PHPカンファレンス小田原 2024 に参加してよかった〜〜〜の気持ちが強かったので今年の参加を去年発表されてすぐに決めました（当日その場でカレンダーに入れたのを覚えています）
カンファレンスイベント運営の側に立つこともあるんですが「同じイベントにまた来たい」の設計って難しいですよね。 例えば会の雰囲気が良いからまた来たいっていう理由に着重きを置きたくなった時、それは主宰の人が作る雰囲気なのか、運営チーム全体が作る雰囲気なのか、対象とする技術のコミュニティ文化が醸し出す雰囲気なのか、主宰の雰囲気になると属人化しちゃうな…とか、じゃあ運営チーム全体でその雰囲気作りどうしようね？みたいな話が生まれてくるなと。 ぺちおだチーム(勝手にチームと呼んでる)のスコープがどこまでかわかりませんが、実行委員長含めスタッフ陣が同じ方向を向いて運営やホスピタリティの向上に取り組んでいそう！勝手ながらに去年感じたことを思い出しています。このチームが作るカンファレンスならまた何度も参加したいぜ！！！みたいな感じ。
個人的にチームで雰囲気作って、そこが文化になるみたいな経験を積んできた側の人間ではない自覚があり、憧れ的なものを抱いているかもしれません…
行くと決めてから定期的に運営チームの状況がTwitterで発信されていて、集まって打ち合わせしたり、企画を考えていたり、顔合わせしたりみたいなのを見ていて、カンファレンスは1日で終わっちゃうけどそこまでの道のりは1年近くかかってるんだなぁ(それはそう)としみじみ思いました…
完全に受け手側の、消費者としての意見になってしまいましたが、すごいなぁ(語彙力)と感じるばかりでした…
DAY1 の話
今回は前夜祭は参加せず、前日夜から小田原入りしていました。本当は前夜祭から参加したかったものの仕事とか有給とか体力とかいろんな関係で、前日夜入りにしました。
とはいえアジフライと太刀魚食べて、スナック無駄に行ってJAWS UG 札幌の皆様と日高屋で締めて終わりでした。
日高屋行ったエピソードで、誰も頼んでいない清酒の話があるんですが上手にエピソードトークできる自信がないので誰かに聞いてください…
行くまでに写真とかは撮ってなかったんですが、羽田から小田原に行く時に超絶怒涛の激長中央線に乗り、都会ってちげえ〜〜〜〜ってなりました。切り離しの移動に数十秒かかるって何？😕何両編成？？の顔をしてました
—-
DAY1はオープニングから参加し、セッションも見て、お昼も食べてスポンサーブースも見て小田原市のことを知って大満足大会。特にぺちおだ大合戦は内容もさることながら参加者を楽しませにきている…楽しまなきゃ！！の気持ちでした
HTTPステータスコード百人一首むじい〜〜〜〜 Web技術者として0.01人前くらいな自覚を持って生きようと思います
味噌ラーメンで血糖値大爆発
写真がない。普段写真を撮らない人間の末路です。
おだわランチで書かれていた味噌ラーメンのお店、麺場 田所商店 小田原店にいきました 札幌民として味噌ラーメンを食べねばということで、ほぼ北海道出身のPHPer+αでお店に突撃
ラーメンとチャーシュー丼セット＋餃子で店員さんに頼んだところ、「大盛りにされますか？」と聞かれ自分が何を頼んだか忘れ反射で「はい」と答えたため、炭水化物大満足、胃袋拡張、血糖値大爆発、大睡魔、爆睡と…
個人的良かった話
PHP・セッションの話をします。
PHPと旅する OSI 7階層 / Vaddy
普段Webフロントエンドエンジニアとして生きていることが多く、HTTP以外のプロトコルに想いを馳せる機会はほとんどない生活を過ごしています。とはいえ、僕らが普段使うブラウザだってなんらかの形やなんらかのライブラリを通してHTTPより下層のプロトコルをおしゃべりしていて、ブラウザに詳しくなる上で大事な知識だなとも考えていました。
というわけでその辺りの理解を深めたいと思いつい先日、 ［作って学ぶ］ブラウザのしくみ | 技術評論社 を購入したのですがそれのきっかけもこのセッションでした。
その上で（ほぼ）全部PHPで実装するという腕力にも感動しながらセッションを聞いていました。TLS / SSL周りの開発は本当に大変そう...
低レイヤを知りたいPHPerのためのCコンパイラ作成入門 / tomzoh
このセッションで出てくるEBNF、トークナイザー、パーサー、コードジェネレーター、ASTといったワードは元々知っていたものの実際にそれらの知識を使って手を動かした経験がない状態でした。持論ですが「知っている」と「やったことがある」の間には大きな差があると思っており、地に足ついた経験の獲得には手を動かさなねばと常日頃考えています。そんな中、一通り「やったことがある」人の「やった結果」を断片的にでも知れると、これの通りにやれば「やり切る」までのハードルが下がる...やりたい...となっていました。知見の共有大感謝すぎます...
小田原 万葉の湯 最高
今年の懇親会が万葉の湯で大変よかったです。
今回の外出では小田原・小田原・東京・福岡・福岡・宮崎・東京・東京の日程で移動をしていたのでここでHP回復ができたのは僥倖でした。
小田原万葉の湯、いつ来てもいい湯。
来年はないらしいけど
今年は自分が実行委員長としてフロントエンドカンファレンス北海道2025の開催に携わるところもあり、開催に向けて気が引き締まりました。ありがとうございました！
来年ないよ！と宣言するのもかっけ〜と思いました（またやるのかな...？） 辞めるのも止めるのも大変、あげた手を下げるのは勇気がいる…
「生きのこる」を考えたカンファレンス in 生きのこるカンファレンス
こんにちはムキムキマッチョマンです
昨日3/9に生きのこるカンファレンスに参加してきました。
まずは運営の皆様、登壇者の皆様ありがとうございました
今回の参加でしっかりと未来を見据えて考えることの重要性を考えました。
我らが北海道のブログ魔神、貴島さんの登壇もさることながら @micchiebear さんの登壇でも「いかによく生きのこるのか」を考えました
https://note.com/_tetrapod/m/m7c057ac10b4a
まだまだ若輩者ですが「還暦の新人」「シニアアクティブエンジニア」のお二方の話を通して、普段考えない先のことを強く考えました… 普段あと先考えずに動くガワの人間の自覚はあるんですが、もう少し未来のことを考えてもいいかなと…
転職ドラフトさんのアンカファレンスで @ogi_chotodake_se さんの育児•子育て･生活の話を聞き将来設計の助けになったのは大変助かりました
ちょこちょこセッションを聴きつつ、いろいろ遊ばせてもらってましたがいかに今の自分が無計画かを良い意味で自覚する機会になりました
今個人的に一番やりたいことが150万円で当別にガレージを建てるなんですが、考え直した方がいいかなと思いました
改めてとてもいい機会になりました 自分の人生を見つめ直す機会というのはそうないと思っているんですが「はぁぁ」という声を2025年で一番上げた自覚があります
はしもつ観光
おせわになりました。ワードウルフありがうございました。来年は勝ってくださいね。
VercelとNeonの相性が良すぎてクイックにDB付きのサービスが作れてしまいそうな話
こんにちは。ムキムキマッチョマンになりたい人です。心も体もムキムキマッチョマン。 フロントエンド領域でのムキムキマッチョマン目指して頑張っています。 この記事は技術記事の皮を被った、IT知識トレーニングの記録です。
はじめに
とあるWebサービスを作りたい！となって今作っています。多分リリースしなさそうだけど。 現在の勤め先が東京・中野のちょっと株式会社という会社でして、実はここが国内唯一のVercelのパートナー企業なんですね。 というわけでチラホラその恩恵に与るものの、実際問題として中の人の知識量とオレの知識量の差がデカすぎることに気づきましてVercelを触ろうと思ったわけです。
Vercelは「front-end cloud」という名称を掲げていて、フロントエンド開発のデプロイメントと開発体験の向上を目指したプロダクトになっています。 とは言ったもののVercel KVやVercel Storageといったストレージ・永続化用のサービスもいくつかあったりします。
個人的な意見ではありますが開発体験を向上させるVercelが永続化層の体験も向上させているのか？が気になり触ってみた話になります。
（ちなみにVercel PostgresとVercel KVはそれぞれNeonとUpstash KVに機能が引き継がれます）
今回はあくまでも個人開発を想定とした話をします
Neonについて
NeonはSeverlessにてPostgres SQLのデータベースを提供するサービスです。 実際にデータベースとして有用かどうかは門外漢なところもあり言及を避けます。
残念ながら最寄りのリージョンはsingaporeです
Vercel x Neonをやってみる
VercelではかつてVercel Postgresとして提供されていた仕組みの代替としてNeonとの連携機能が使えます。 VercelのMarketplaceからNeonが連携できるとのことでした.
Vercelダッシュボードから「Storage」を選び、「Create Database」からNeonを選択できるようになっています。
（すでに連携済）
以下で基本の設定をし（ap-northeastがあってもいいのに...）
データベースが作成できます
いいところ
Vercelの環境変数と紐付けられる
以下は連携後のVercelの管理画面ですが、実はここの.env.localをプロジェクト連携によって環境変数をvercelの管理下にボタンの数クリックで実行ができちゃいます。
具体的には管理画面下部の「Connect Project」で反映させたいEnvironmentsを選択。
「Connect」を押してvercel env pull .env.development.localを押せば完了です。
便利ですね〜
Neon側にもbranchingに近い機能があり、環境を分けられる
Neonでは１プロジェクト=１データベースで、その中で環境を分けられます。 実際に深いところまで使えていないのでまだわからないところは正直ありますが、少なくとも初期設定がここまで簡単だと今後も使いたいなぁと思っています。
最後に
簡単な記事になってしまいましたが、改めてこれらの機能を使って最速でサービス開発ができるの意外とVercelくらいなのでは？の気持ちになっています。 もちろんfirebaseやsupabaseがあるのはもちろんですが、フロントエンドエンジニアとしてこういった機能を持ったVercel素直に嬉しい〜〜になっています
引き続き使っていくのでまたブログをあげようというつもりです
Web考古学 探訪 W3C Mailing List ー メーリングリストアーカイブの歩き方
こんにちは。ムキムキマッチョマンになりたい人です。心も体もムキムキマッチョマン。 フロントエンド領域でのムキムキマッチョマン目指して頑張っています。 この記事は技術記事の皮を被った、IT知識トレーニングの記録です。
今回は、久しぶりのWeb考古学のシリーズです。 Web考古学の詳細は以下の記事をご覧ください。
Web考古学を通してフロントエンドへの迷いを断ち切ろうーNetscape 3 / IE4.5をMacOS 9.0.4 on macOS 14で動かすー - ムキムキマッチョマン
はじめに
古いWebの仕様やそれができた経緯を知るときに役に立つのが各標準化団体が公開しているメーリングリストのアーカイブです。 標準化の流れにおいて、会議のお知らせや議事録の共有・議論、意思決定などは基本的にはメーリングリストで行われています（当時パブリックに参加でき、お互いがコミュニケーションの取れるツールがメールしかなかったから？）
ちなみに標準化や標準化の流れについて、IETFの場合については以下の資料が参考になります。 インターネットプロトコルの標準化
少し古いものですが以下のような資料もあったりします。 国際標準化活動の基礎知識と実践的手法 - NTT Docomo テクニカルジャーナル
2002年生まれの自分が、いざメーリングリストを読もうとなったときにわからなかったこと今は若干なんとなくで読めるくらいまでには来たのでそこに至るまでに必要だった知識をおさらいしていきます。
メーリングリストを読んでみよう
さて、早速ですがメーリングリストを読んでいきます。色々なものがありますがかつてHTMLの標準仕様を定めていたW3CのHTML WGのメーリングリストアーカイブを見ていきます。
https://lists.w3.org/Archives/Public/public-html/
上記のURLがアーカイブのURLですが、アクセスすると以下のような画面になります。
これだけでは分かりづらいのでまずは一覧画面から整理していきます。 画面上部、ここにはいわゆるメーリングリスト全体のメタ情報が含まれます。 ここは大きく使わないのでスルーします。
では画面下部に注目してみます。
ここには検索ボックスと３つのテーブルヘッダーがあります。それぞれperiod,re-sorted,messagesがあります。
それぞれ解説すると以下の通りです。
period- 何年何月のメールが含まれているか
re-sorted- 特定条件下でメールを読みやすく整理したもの（詳細後述）
messages- メールの件数
それぞれにリンクが含まれているので、例えば「September 2024」をクリックすると以下のような2024年9月のメールがまとめられて出てきます。
re-sorted を使いこなす
メーリングリストはメールのつながりである以上、一般的なメッセージングツールと比べてかなり情報の整理が難しいです。
そこでw3cのアーカイブではメールを特定条件下でグルーピングの上整理してくれています。それがre-sortedです。
試しに返信や転送を１つのスレッド（Slackのスレッドと同じ）方式でまとめるby threadにアクセスしてみると以下のようにメールのタイトル（Subject）を起点にその後のメールがスレッドのように連なって表示されています。
同様にメールの作者でグループ・ソートするby author、同じタイトルでまとめるby subjectもありました。
個別のメールの見方
ここまででメーリングリストアーカイブ一覧の情報がなんとなくわかってきたと思います。 次は、個別のメールの見方を確認していきます。
今回は例として2007年 3月31日の「E-mail subscription and RSS」のメールを見ていきます。 以下のようにメールの本文とまたたくさんのメタ情報が書かれています。
From / Date / Toあたりまでは皆さんわかるかと思います。
さて掘り下げます。以下の部分に注目してみてみます。 大きく「This messages」と「Related Messages」が表示されています。
This messages
この項目は今表示されているメールに対するアクションや情報をまとめています。
- Message Bodyをクリックするとメール本文の位置までカーソルを移動してくれます。
- Respondをクリックすると該当するメールに返信できるようになります。
Related messages
次のこちらの項目では、今表示されているメールに関係するメールへのナビゲーションが記述されています。
Next message | Previous messageは名前の通り、メーリングリストの関係ない１つ前と１つ後のメールを表示してくれますNext in threadこれがかなり大事で、同じスレッド内の次の投稿を表示してくれます（この場合は返信）replies該当メールの返信を表示してくれます
以上
というわけで実はここまででメーリングリスト、読めてしまいます。 苦手だなと感じるそこのあなたにもぜひ読んで、Web技術や知見の深掘りに役立てていだければと。
ESLint Pluginを書くのに必要な知識、あるいは強力な制約で得られるものについて
こんにちは。ムキムキマッチョマンになりたい人です。心も体もムキムキマッチョマン。 フロントエンド領域でのムキムキマッチョマン目指して頑張っています。 この記事は技術記事の皮を被った、IT知識トレーニングの記録です。
はじめに
フロントエンド開発において、コーディング規約やいろいろな制約を持たせたいときに重宝されるのがLinter、静的解析ツールです。 静的解析ツールではソースコードを実行などせず解析し、文法上の間違いや表記の統一の問題を見つけ、場合によってはそれの解決まで行ってくれます。
2024年現在様々なLinterがある中で、ESLintはプラグインを中心としたエコシステムを形成し色々ありながらもまだシェアを保っています。 今回はそのESLintプラグインを使う話です。
制約と誓約
リスクはバネ!! 制約と覚悟が大きい程念は強く働く!!
ー クラピカ / HUNTER x HUNTER
制約と制約は少年ジャンプ連載の漫画「HUNTER x HUNTER」に出てくる概念で強い縛りを設けそれの対価として自身の強化など大きな利益を得るという仕組みの話です。
詳しい話はすでに自分よりも詳細にかつわかりやすく書いていただいてる方がいますのでそちらを紹介させていただきます。
近いものでいえば同じく少年ジャンプ連載の漫画「呪術廻戦」にて「縛り」という概念が出てきます。
信じる信じないの話ではない これは〝縛り〟
誓約だ
守らねば罰を受けるのは俺 身に余る私益をむさぼれば報いを受ける
ー 呪術廻戦
前提
- 業務開発やチームでの開発を想定しています
- 制約や縛りがない環境を理想とした上での話をします。
- 自由闊達にプログラムを書き合い、お互いで議論し合いながら高めあう。１つの理想の形だと思います。
制約をより強くすることで得られるものも大きくしたい
より具体的な話をしていきます。
制約と誓約は「縛りを設けるとそれに応じて強化など利益が得られること」でした。縛りも同様です。 これの原理自体は正直自分も詳しくないのすが...
ここからは制約を強制させる仕組みを用いて「制約と誓約の効能」を最大化したいという話をしていきます。
制約を強制させる仕組み
フロントエンド開発の場合、一般的に配列の中身を走査した上で操作を加え新たな配列を作る時にはmapを使う方が良いとされています。
仮にこれをルールとした時にそれをコードレビューの際に都度指摘したり、ペアプロやモブプロの時に教えていてはキリがないです。
一般的にそうと言われているから知識として持っておくべきという話があるかもしれませんが、それは個人に期待しすぎな気もします。
これらを解決するために静的解析ツールでそもそもエラーとして扱ってしまい、書く側に正しい形で強制させようというのが自分の提案です。 静的解析ツールは事前に文法的な間違いや書式の統一（末尾カンマやインデントなど軽微なもの）をさせるためのもので、本来用途からはややズレた使い方ではありますが。
詰まるところ目指したいのは「ソースコードの様式・書き方を強力にLinterで強制（あるいは矯正）すること統一され、コードの品質が優らずとも劣らない状態を作ること」です
コードで表現できない制約は制約たり得ない
配列の中身を走査した上で操作を加え新たな配列を作る時には
mapを使う方が良い
これは一見成立しているように見えて、制約として機能していません。 例えば以下のような場合、これらは制約を無視するしかなくせっかく設けたとしてもプログラムを書く側の裁量で判断できてしまいます。
- for of を使いたい場合はエラーを無視するのが良いのか？
- 逆に
mapを使うべきでないケースは？
強制力を働かせたい制約なのに、その強制力が弱まるような定義の仕方はうまく機能するはずがありません。
曖昧な表現を避けて制約がなすべき条件を明確化して整理しそれらを強制する＝制約をコードとして表現するのが良いでしょう。
コードとして制約を強制できる仕組みESLint Plugin
ESLint Pluginではコードを静的解析した際にその解析結果を使って独自のカスタムルールにて強力な制約が設定できます。
本題：ESLint Pluginを書くのに必要な知識、あるいはASTNodeの話
ではESLint Pluginを書こうとなった時に実は関連するドキュメントが充実してないことに気づきます。 その中でどう情報を集め、どうルールを書いていくかを残り書いてきます。
公式ドキュメント
ESLint 公式のcreate pluginではjsを利用して、プラグインそのものを記述する方法が紹介されています。
Get staredくらいにはちょうどいいんですが、実際にプラグインを開発していく際にどうコードを読み解き分析するかの部分についての説明はほとんどありません。
eslintのrule実装を見にいく
一番わかりやすい参考資料はeslint本体のルール実装です。 例えば識別子にundefinedを使うことを禁止するno-undefinedのルール実装を見てみましょう。 （※undefinedというグローバル変数に別の値を入れて等価演算子をバグらせることなどができます）
eslint/lib/rules/no-undefined.js at main · eslint/eslint · GitHub
/** * @fileoverview Rule to flag references to the undefined variable. * @author Michael Ficarra */ "use strict"; //------------------------------------------------------------------------------ // Rule Definition //------------------------------------------------------------------------------ /** @type {import('../shared/types').Rule} */ module.exports = { meta: { type: "suggestion", docs: { description: "Disallow the use of `undefined` as an identifier", recommended: false, frozen: true, url: "https://eslint.org/docs/latest/rules/no-undefined" }, schema: [], messages: { unexpectedUndefined: "Unexpected use of undefined." } }, create(context) { const sourceCode = context.sourceCode; /** * Report an invalid "undefined" identifier node. * @param {ASTNode} node The node to report. * @returns {void} */ function report(node) { context.report({ node, messageId: "unexpectedUndefined" }); } /** * Checks the given scope for references to `undefined` and reports * all references found. * @param {eslint-scope.Scope} scope The scope to check. * @returns {void} */ function checkScope(scope) { const undefinedVar = scope.set.get("undefined"); if (!undefinedVar) { return; } const references = undefinedVar.references; const defs = undefinedVar.defs; // Report non-initializing references (those are covered in defs below) references .filter(ref => !ref.init) .forEach(ref => report(ref.identifier)); defs.forEach(def => report(def.name)); } return { "Program:exit"(node) { const globalScope = sourceCode.getScope(node); const stack = [globalScope]; while (stack.length) { const scope = stack.pop(); stack.push(...scope.childScopes); checkScope(scope); } } }; } };
ASTへの理解
これらコードを見ていく上で出てくるのが「Statement」や「Declaration」という単語です。 これらを理解していく上で重要になるのが AST（抽象構文木）です。 ASTはプログラミング言語のソースコードを木構造で表現し、式や文、宣言などを構造化しJSONで表現するものです。 一般的なASTであれば式をexpression、文をstatementと表現します。
詳細はこちらの記事をご覧ください。
実際のコードで具体的にどんなASTが出てくるのかは大まかに以下のツールで試すこともできます。
estreeパーサー
AST自体は標準仕様がなく、パーサーによって最終的に出力される構文木や対応している構文に差があります。 ESLintではestreeと呼ばれるパーサーを利用しています。 ちなみにtypescript-eslintの場合は一度TypeScriptのASTを出力した後それをestree互換にしており２段階でパースしていたりします。
ESLintプラグインを０から作るなら参考にしたいテンプレート
@kotarella さんという方が作ったこのGitHubリポジトリでは、ESLintプラグインの開発環境のガイドラインとしてTypeScriptを使ったものやテストのサンプルなどが含まれています。 3年前が最終更新ということもあり、実際使う場合はやや調整の必要がありますがかなり参考になるでしょう。
最後に
ESLintプラグインを使ってみたい人向けなのか、ESLintプラグインはいいぞの記事なのかがわかりませんが、こんなとこで。
