Devinにお願いしてソースコードからドキュメントを生成してもらえると面白そうなので実験してみた。Devin Wiki や Deep Wiki もあるんだけど、それとは別に自分で指示を出してコントロールできるのもいいかなという気持ち。 どうせ作るなら自分がドキュメントを読みたいやつがいいなぁと思って、ecspresso が好きだから、ecspressoのソースコードからドキュメントを生成してみることにした。 軽い気持ちでやってみたら、思ってたより苦戦した。すごくいい感じにできたわけじゃないので「この記事をめちゃ信じる！」んじゃなくて「へー、ちょっと参考にしとこっか」くらいが良いと思う。 勢いで書かないと書き終わらなさそうだったので、勢いでざーっと書いた。ので長い。 できあがったもの できあがったものを最初に書いておく。わりと気に入ってる。ただ、生成するたびに色々変わるので、雰囲気で参照する

「数日前に↓のIssueがクローズされたんだよねー。Zod v4が関係してそう。知らんけど」って会社の同僚と喋ったので、ちゃんと知っておくかーって気持ちになった。 ※ 本記事はzod@4.0.0-beta.20250505T195954時点の挙動をもとにしています。正式版で変更される可能性があります。 最初にまとめ z.switchが追加されるとか、z.discriminatedUnionが非推奨になるとかの話はなくなった様子 Zod v4 ではz.discriminatedUnionに識別プロパティを渡さないようになった（渡しても無視される） 共通の識別プロパティを持たずに、各オプションがそれぞれリテラルかenum（ネスト可）のプロパティを持つだけでよくなった Zod v3までのz.unionとz.discriminatedUnion Issueの内容を説明する前に、現行であるZod v

エンジニアとしてチームをリードするときよりも、もう少し広めの範囲をリードするときの話。 1 つのチームをエンジニアとしてリードするときには、ぐいっと引っ張ったり、やって見せたり、そばでペアプロをしたり、直接話をしたり、そういう直接のコミュニケーションでリードできるし、そうしたい。 でも、複数チームの方向性を決めるような旗振りをするときには、そういう直接のコミュニケーションは難しくなる。それに 1 つのチームを見ているときよりももう少し遠くを見ることが多い。 そんなときに意識しているのは「自分が考えてることを見えるようにすること」。 考えてることが見えないと 考えてることが見えないタイプのリーダーは、メンバーとしては動きにくいなって思ってしまう。 責任感が強かったり、自分がリーダーとしてしっかりしなきゃ！と頑張ってたりするから、というのが多いかも。で、いろいろ悩んで、最終的に決まってから「こ

数日前に↓を読んで、なるほどー！ってなったので、なんか作ってみるかと思い MCPサーバー自作入門 なんとなく、npxで実行するより、実行可能ファイルにしてみたいなと思って、Denoに初挑戦。↓こちらを参考にして作ってみた Deno で RooCode 用にローカルMCPサーバーをさっと作る ↓こうなった https://github.com/bufferings/mcp-servers/tree/main/hello 実行可能ファイルはこんな感じで作って ❯ deno compile --output dist/hello hello/index.ts Cursorでそのファイルを設定して { "mcpServers": { "hello": { "command": "~/mcp-servers/hello", "args": [], "env": {} } } } 有効化して 文字列の

すごく久しぶりにブログを書く。3ヶ月ぶりくらい？ ↓この記事を読んで「へー。どういうこと？」ってなったので遊んでみた。 「GITHUB_TOKEN でGitHub Modelsを呼び出せるようになったよ！PAT（Personal Access Tokens）はもう使わなくていいよ！」って書いてある。そもそもGitHub Modelsを知らんかったけど、GitHub Copilotとかで使ってるAIのモデルたちのことかな。 やってみた GitHub ActionsでAIの呼び出しができるよってことだろうなと思って適当に作ってみた。「今日の運勢を教えて！」って投げるだけのGitHub Actions。 「今日は新しいことにチャレンジする絶好の日！」ふむふむー。 コード github.com name: GitHub Models API Example on: workflow_dispatc

HonoとZodとOpenAPIまわりが気になって、Zod OpenAPIのコードをWebStormで読んでたら、WebStormとNode.jsのプロセスがCPUをたくさん消費して、動きが遅くなって困った。メモリもWebStormに割り当てたぶんを使い切っちゃうよーって警告が出てきてた。 なんの気なしにそんなことをつぶやいてたらJetBrainsの@niklas_wortmannがコメントをくれた。 Did you happen to create a YouTrack ticket with some CPU or Memory snapshots? Would love to further look into this— Jan-Niklas Wortmann (@niklas_wortmann) January 18, 2025 ので、たしかにレポート送るのいいか、と思ってYou

Branded Typeについては、もういろんなところで触れられているから、わざわざ書かなくてもいいよなぁという気持ちがありつつ。でも、せっかく頭の整理をしたから、来月の自分用にまとめておくくらいはやっておこうか、という気持ちになったのでメモを残しておく。それとZodの.brand。 やりたいこと 次の2つの型に対する値を間違えて渡したときに、TypeScriptの型検査でエラーになってほしい。 type UserId = number; type BookId = number; TSの型システムはStructural Subtypingを採用しているので、構造が同じだったら部分型として扱われる。だから、↓こんな風にUserIdを引数で受け取る関数にBookIdの値を渡してもエラーにならない。どちらも同じnumber型だから。 const getUser = (id: UserId) =

年末年始にGhosttyを触ってみてて、好きだなとは思いつつもメイン使いするのはもうちょっと待ちたいなという気持ちになった。 なので、↓以前に書いたみたいにiTerm2 + tmuxに戻すかー！と思って、それならtmuxの使い方をもういっかい勉強するかー！って考えたんだけど。 はて？そういえばなんでtmuxを使ってるんだっけ？ってなった。 もともとは、踏み台からサーバーに入って作業をするときに切断されないようにするためだったな。ついでに複数台のサーバーに入りやすくて便利だなくらいで使い始めたんだった。 もう今じゃ踏み台からサーバーに入ることもほとんどないし、単に複数ペインやタブで操作したいだけならiTerm2だけでよくない？って気持ちになった。 それに、もしまた踏み台経由でtmuxを使いたいってなったら、iTerm2のtmuxインテグレーションの機能を使えばiTerm2の使い方でtmuxが

今朝リリースされた なんとなく楽しみにしてたやつ。わーい。 https://t.co/39Xj39wheA 👻 pic.twitter.com/PH0qejFB4z— Mitchell Hashimoto (@mitchellh) December 26, 2024 使ってみようと思った ちょっと触った感じ、なんとなく心地良いなと思ったので使ってみることにする。僕は今 iTerm2 + tmux なんだけど、これを機に tmux もやめてみて Ghostty だけを使ってみようかなと思っている。 Ghostty + tmux でもいいよなとは思ったんだけど、せっかくなら Ghostty の機能をちゃんと使ってみるかなという気持ち。tmux を全然使いこなせていないから大丈夫（？）。 テーマやフォント デフォルトのままで好きな感じなので、変更せずに使う。ちなみに、デフォルトフォントは Je

私の目標は、読者が午前中に本書を読み始めたら、午後には設計が上達していることだ。 本当にそのとおりだった。読んでる途中で既に自分の設計に対する考えが良い方向に変わってると感じた。とても良かった。おすすめです。 『Tidy First?』 をいただいて読んだ。昨日（2024年12月25日）発売。英語版が2023年11月28日発売だから、たった1年で日本語版が出たということだな。うれしい！はやい！ありがたい！ ソフトウェア設計に焦点を当てたシリーズの最初の1冊ということで、サブタイトルに「個人で実践する経験主義的ソフトウェア設計」とあるように、1人でできる種類のソフトウェア設計について書かれている。続刊ではチームについての話になる予定のようで、それも今から楽しみ。 2周読んだ なんとなく2周読もうと思ってそうした。 1周目は細かい部分は気にせずにざーっと1,2時間くらいで読んだ。全体的にどうい

typescript-eslintのFlat Configについて、自分に今必要そうな部分だけをひととおり確認したので忘れる前にメモを残しておく。 前提 素のJavaScriptプロジェクトをやることは自分はあまりなさそうなのでTypeScript前提 ES Modules前提でいいやと思っているので設定ファイルの拡張子はシンプルに .js にする フォーマッターにはESLintのStylisticじゃなくてESLint外のフォーマッター（PrettierやBiome）を使う前提 基本の設定 https://typescript-eslint.io/getting-started/ の最初に書いてある設定。 // @ts-check import eslint from '@eslint/js'; import tseslint from 'typescript-eslint'; expo

カケハシのスタッフとしてTSKaigi Kansaiに参加して楽しんできた。 スポンサーのランチLTでカケハシのメンバーも喋るからブースを抜け出して見に行ってたら、newmoの大貫さんのLTで「DuckDB Wasmを使ってクライアントだけで処理したよ！」って発表があって、面白いなーと思ったのだった。 kansai.tskaigi.org ので、遊んだ DuckDBは初めて知ったし、Wasmには興味があるので、遊んでみた。GitHub Pagesにアップロードしておいた。11/18の日本各地の最高気温が分かるよ！ https://bufferings.github.io/vite-react-duckdb-wasm/ やってるのは DuckDB Wasmをクライアントで取得して e-Govデータポータルの11/18の最高気温のCSVをDuckDBに入れて そのDBの内容をテーブルに表示 テ

数日前にTypeScript 5.7 RCがアナウンスされてリリースが楽しみだなー！ってところなんだけど、そのさらに数日前に、ウォッチしていたこのPR↓がマージされてTypeScript 5.8.0のマイルストーンに入った。わー！ これが今日のお話。TypeScript 5.8.0でConditional return type narrowingが入りそう。楽しみ！ Conditional return type narrowing? 直訳すると「条件付き戻り値型の絞り込み」かな。引数の型によって戻り値の型が変わる関数を定義したいときに、例えばこんな風に書きたくなる。 declare const record: Record<string, string[]>; declare const array: string[]; function getObject<T extends str

2024-11-11 追記ここから ---- TS 5.8で、その１のインデックスアクセス型の方はサポートされそう。その２の方はその対応が入ってもサポートされない。 追記ここまで ---- 最初にまとめ 現在のTypeScript（2024-09-19時点のバージョン5.6.2）では Generics と Control Flow Analysis は、いい感じには連携しないということを学んだ。 どういうこと？その１ Genericsを使って型安全にやりたいなぁと思って、こんなコードを書いてみてもコンパイルエラーになる。 type Mapping = { a: boolean, b: string, } function getValue<K extends "a" | "b">(key: K): Mapping[K] { if (key === "a") { return true; }

何を言っているんだ？というタイトルだけど、今日はTypeScriptの型で遊んでた。 タグ付きユニオンから型をExtractしたい こういうタグ付きユニオンがあって type MyUnion = | { tag: "a", value: boolean } | { tag: "b", value: boolean } | { tag: "c", value: string } その中の型をExtractしたいときは、こんな風に書ける type A = Extract<MyUnion, { tag: "a" }> そうするとtagが"a"の型を取得できるので、このテストがとおる import type { Equal, Expect } from '@type-challenges/utils' type cases = [ Expect<Equal<A, { tag: "a", value

うちのチームにはPdMが2人いる。そのPdM2人は、お互いの得意を活かしながらプロダクトをマネジメントしてくれている。「PdMやPOは1人であるべき」って言葉を見かけたりするけど、うちのPdMは2人でいい感じにやっていて、このスタイルいいなぁって思う。おかげでエンジニアとしても動きやすい。 そもそも、PdMってやることがめちゃくちゃ多い。ステークホルダーと話したり、ユーザーさんのお話を聞きに行ったり、少し先のことを考えたり、仕様を決めたり、受け入れ判断をしたり、仮説検証のためのKPIをチェックしたり、問い合わせがあったら一次請けをしてくれたり、いろんなことを決断しまくったり。それでいて業界の勉強もしている。 大変だよね。ひとりでさばききれる量じゃないよね。って僕は思っている。 だから、複数のPdMがいるのはとても良い。大変な作業を分担したり難しい決断を相談したりしながらプロダクトのことを考

うれしかった。ので、メモ。 僕のいるチームのプロジェクトで、複数のチームにサポートしてもらいながら進める必要がある、ちょっと大きなものが始まりそうだったから、キックオフ前のキックオフやっとこかーってなって司会をした。オンラインミーティングね。 最初にこの会の目的を説明 今日のアジェンダのページのリンクは事前に共有もしていましたけど、いまSlackにもポストしておきましたー。 まだプロジェクトは始まってないんだけど、事前に調査とかをしたいから質問や相談をさせてもらいたいなと思っていて、そのときに「え？これなんの話？」って戸惑わせることがないように、プロジェクトの概要を共有しとこうと思ったー！だから、この会がうまくいったら、僕らが質問してもみなさんが戸惑わないようになっている！ Bさん、Slackにメモ残してってください。お願いしまーす！ からの、会の流れを説明 最初にPdMから10分くらいで

開発部全体を見てるあのすごい人が、ある1つのチームのマネージャだったらどんな感じなんだろうなぁ？仕事がやりやすいんだろうなぁ？って考えることがある。それが今、僕のいるチームで起こっている。 VPoEの経験もあるいくおさんと、カケハシの同じチームで仕事をしている。いくおさんが1つのチームのエンジニアリングマネージャとしてついてくれているのって、とても贅沢だなぁと思っている。実際に仕事はめちゃくちゃやりやすいし、それだけじゃなくて、僕やチームみんなの心の支えになってくれている。 いくおさんが書籍を出した そんないくおさんが書籍を出した。この本がとてもいい本なので、みんなに読んでほしい。どうしていくおさんと一緒だと仕事がやりやすいのか、なぜ自分の持ってる力が引き出されるのか、その理由がこの本には書かれている。 www.shoeisha.co.jp いやー目標って苦手なんだけど・・・ 目標って聞く

読んでよかった book.mynavi.jp 評判通りよかった そっかーなるほどなぁ。面白いなぁ。と思うことがいろいろあった とはいえ、著者の主張全てに同意というわけではなく「著者はそう考えるんだな。自分は違う考えだな」と考えさせられる部分もいくつかあった 苦手な部分もあった 古典学派とロンドン学派に分けて話を展開しているのはあまり好きじゃないなと思いながら読んだ 定理やマトリクスに当てはめて話を展開する部分があって、いくつかは無理やりだったり話をややこしくしていたりするように自分は感じた。そういう部分は苦手だなぁと思いながら読んだ というのが全体の感想。内容はとてもよかったし、苦手な部分もそれはそれで考えさせられたので、読んでよかった。ってことでパラパラめくりながらメモを書いていこう あらためて意識したい2本 「第4章 良い単体テストを構成する4本の柱」の中の2本が、当たり前のことではあ

この記事を見かけて、やっとむさんだなーやさしく伝えたんだろうなーって思いつつ。「上手くいく」「上手くいってない」って幅がありそうだよなと思ったので、頭の中の整理をしてみることにした。来週の発表の準備が煮詰まっているから気分転換しているだけともいう。 yattom.hatenablog.com やっとむさんの記事を読む 「スクラムで開発を進めている」という状況で 「問題が多い→ならば→スクラムは合わない」のか？という問いに対して やっとむさんの回答は「問題がある→ならば→スクラムは上手くいっている」 と書いてある。「合わない」は「うち（の会社）には合わない」の意味。 最初にことわっておく ふだんからいろいろとお話をされている関係性の中で伝えていて、その前後にいろんなお話をしているんだろうなと想像している。 だから、僕がここで書くようなことは、その関係性の中ですでに共有されていることだと思って

いただきましたー！わーい。脳に収めるぞー！ @haradakiro @ryuzee pic.twitter.com/3Qd6EvPioU— SHIIBA Mitsuyuki (@bufferings) June 13, 2024 明日（2024年6月18日）発売！ www.oreilly.co.jp どう書くのがいいんだろうなぁ？ 複雑なコードと向き合うときは「あー、これはメモを取りながら読まないと迷子になるやつだ」ってなる。最初はわりとキレイに作られていたとしても、機能追加を重ねていくとだんだん読めなくなっていく。 だから「時間が経っても読みやすいコードってどう書くのがいいんだろうなぁ？何かヒントがあるかなぁ？」って思いながらこの本を開いた。先に書いておくと、ヒントはあった。 アウトサイドインのTDD 全然予想してなかったから、おー！と思ったのが、説明をTDDで進めていくってところ。好き

ソフトウェアエンジニアの話ね。想像して遊んでるだけね。 スキルは高い まず、マネージャになってほしいって言われる時点で「仕事を任せられる」というエンジニアなんだろうな。それは、つまりコードを書くことに加えて、プロダクトをなんとかしてリリースする力と責任感をもっていて、それが会社にとってプラスになっている。 だから、チームを任せて同じようなエンジニアを育てて欲しいと期待されている。自分自身も、自分のスキルをもっと会社の役に立てるぞー！とやる気になっている。 任せたい そういう人がマネージャになって、あるだろうなぁと思うのは「どう任せたらいいんだろう？」という悩み。 自分が手を動かせばプロジェクトがなんとかなるのは分かっている。でも、自分はマネージャの仕事があるし、そこは自分の役割ではないし、実際のところ手を動かす時間なんてない。それはメンバーにやってもらわないといけない。 ただ、だいたいの場

単体テストの考え方・使い方を1年ちょっと前に買って、今頃になって少しずつマイペースで読んでいる。著者の考え方が自分とは違う部分があるけど、それはそれでおもしろい。 book.mynavi.jp 第4章を読んだ 昨日いちど第4章を読んで、今日ももういちど読み直した。この章を読み直した理由は、あんまりしっくりこなかったから。でも、別にしっくりこなかった部分については今日は書かない。今日はただのメモ。 この章では、良い単体テストを構成する4つの柱について書かれている。 リグレッションに対する保護 リファクタリングへの耐性 迅速なフィードバック 保守のしやすさ これ自体はとてもよく分かる。単体テストというか、自動テストを考えるときに考えるなぁって気がする。 こんな感じかなぁ 以下、ぼーっとこんな感じかなぁって思った。 UT IT E2E リグレッションに対する保護 ◯ ◎ ◯ リファクタリングへの

昨日TSKaigiに参加してとても楽しかった。そのキーノートスピーカーがDanielで、5.5の新機能を教えてくれた。 ので、今日は↓この記事のInferred Type Predicatesを手を動かしながら読んだ。面白かった。まだ5.5はベータ。 devblogs.microsoft.com Inferred Type Predicatesってどういうもの？ こういう関数を書くと function isString(x: string | number) { return typeof x === "string"; } 5.4までは、戻り値の型は単純に boolean に推論される。 これが5.5からは、Type Predicateに推論される。 何が便利なの？ 何が便利かって、これで型のNarrowingが便利に使えるようになる。 filter が分かりやすいよね。 const s

TDDを実践する中で身につけた「設計に関するスキル」があるなぁと思ったのでメモを残しておくことにする。TDDをやるときのスキルではなく設計をするときのスキル。 染み込んでいる TDDは以前に書いたように（ってもう7年も前か・・・）あんまり使わなくなっている。でも心の中にある。ウェブアプリケーションエンジニアとしての自分にとても大きな影響を与えている。 bufferings.hatenablog.com TDDから学んだ設計に関するスキル 3つ思い浮かんだ まずは動くものを作る 必要な分だけ作る 「ありえない」の処理を考える 注意 ウェブアプリケーションを書くときのことを考えながら書いている。ライブラリやフレームワークのようないろんなユーザーから利用されるものは、今回の話の対象ではない。 1. まずは動くものを作る TDDで実装を書くときは「キレイじゃなくてもいいからテストがグリーンになる（

git-replay というコマンドが追加されたみたいなので触ってみた。とは言っても、自分はあんまり凝ったことはやらないので、細かいところまでは踏み込まずに最低限の使い方ができたらいいなってくらいの気持ちで触った。 github.blog この記事には、こんな風に書いてある↓ git replay exists to address these challenges. It offers an alternative to git rebase that, in addition to being far more performant: Can operate in bare repositories. Can rebase branches other than the currently checked-out one (in non-bare repositories). Can

同僚に「GitHubのMerge Queueってあんまり知らないんだけど、どう思う？」って聞かれて「あー。僕もあれよく分かってないんだよね」って返事をして、ちょうどいい機会なので見てみた 見てみた感想としては、いくつか気をつけておきたい点があるけど、チームの開発の進め方にうまくはまれば便利な機能だな、という感じ（なんでもそうか・・・） Merge Queueって? 2023年の7月にGAになったGitHubの機能 プルリクエストをマージするときに「マージ先のブランチ（ベースブランチ）の最新の変更を取り込んでからChecks（つまりCI）を実行して、それが成功したらマージしといて！」ってお願いできる便利機能。名前のとおりQueueになっているので複数のプルリクエストからenqueueできて前から順番に処理してくれる そうは言われても最初に説明を見た僕は「？？？」状態だった。「なんでこんな機能

ほんとうにハローワールドをやっただけなので、それ以上の情報はないよ！ いっこあるとしたら「Cloudflare WorkersのCLIであるwrangler がBig Surでは動かなくて、Sonomaにしたら動いたよ」ってことくらい 全然知らない技術 この記事を読んで、そういえばHono [ほのー] を触ってみたいんだったなぁと思って（HonoはJSランタイム用の高速なウェブアプリケーションフレームワーク） Next.js + Hono + AWS でイベント駆動なプロフィール交換アプリを開発！ Honoのドキュメントを眺めて https://hono.dev/ JSのランタイムはNode.jsをいつも使ってるから、Bun [ばん]かDeno [でぃーの]を触ってみようかなと思って、どっちも触ったことがないからどっちでもよかったんだけど、なんとなくさっきの記事もそうだったからBunでやっ