読んでよかった 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で実装を書くときは「キレイじゃなくてもいいからテストがグリーンになる（

オフラインの勉強会です。ぜひ来てね！ product-engineer.connpass.com （って言っても、ありがたいことに定員オーバーしていて、抽選待ちの状態です。でもよかったら申し込んでくれると嬉しいです！） 仮説検証ループをすばやく回し続ける 僕は、スタートアップで新規プロダクトの開発を担当しています。そのプロダクトを立ち上げるときに「仮説検証のループをすばやく回し続けられるように！」と、いろんな決断をしながら作ってきました。立ち上がってしばらくたつ今もスピードを落とさずに仮説を検証し続けている状態です。↓いまこんな状態 毎週何かしら動くものをステークホルダーに見せて意見をもらっている トランクベースの開発で、毎日本番環境にデプロイしている（ときには5,6回） フィーチャーフラグを使って、リリースをコントロールしている ユーザーの声が届いてすぐに改善をリリースした 機能追加だけ

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できて前から順番に処理してくれる そうは言われても最初に説明を見た僕は「？？？」状態だった。「なんでこんな機能

とても雑記。 チームトポロジーを読んだ。買ったときにはさらっと読んでたので、今回はゆっくり読んだ。 読み直そうと思った理由 以前に読んだときは「まぁ、そうだな。わかる」くらいの気持ちだったんだけど、それから2年くらい経って、チームトポロジーの用語が、少なくとも僕の周りでは、普通に交わされるようになってるなぁと感じたから、読み直そうと思った。 用語をある程度理解しておくと、相手の言っていることがよりよく理解できそうだなと思って。 読み直してみてどうだった？ まぁ、そうだな。わかる。という気持ち。（おい！） それから、用語の整理もできた。4つのチームタイプと3つのインタラクションモード。これで、周りの会話もよく理解できそう。 そして、とてもよかった。これは、自分が成長したってことかな。 DevOpsにピンときてない そもそも、前段にあるDevOps自体には、自分はピンときていない。これまで開発

気分転換といえばGit。ということでGitを触ってた。 僕がGitでよくやる操作があって、それは複数のコマンドを叩いてるんだけど、簡単にできるものが用意されてるだろうなぁとずっと思っていて、やっと調べることにした。自分用メモ。 トラッキングせずにブランチを作りたい リモートブランチをトラッキングするのは、あまり好きではないので、切り離してブランチを作りたくて、こうしてた↓ git switch -d origin/<リモートブランチ名> でDETACHED HEADの状態にする git switch -c <ローカルブランチ名> でカレントコミットから作成するとリモートブランチをトラッキングしない 手元に fastify のリポジトリがあったので、このリポジトリで試すことにする。 ❯ git switch -d origin/next Previous HEAD position was

以前は、DDDでどう実装したらいいかなぁって考えてたんだけど、最近は、そういうことへの興味があまりなくなっている。エンティティや値オブジェクト、集約やリポジトリなど、そのあたりにあまり興味がない。ヘキサゴナルアーキテクチャなども、そんなに考えなくなった。 TypeScriptを使うことが多いので、型でしっかり守るとかカプセル化するとか、そのあたりがどっちでもいっかという気持ちになっていることが影響してるとは思う。TypeScriptでクラスを使おうとはあまり思わないし。BrandedTypeみたいなのを使ってまで型で守ろうとは思わない。 じゃあ何に興味があるんだっけ？って考えてみると、トランザクション境界とユビキタス言語かな。 トランザクション境界 トランザクションの境界を作って、DB（RDBMS）を小さく保ちたいと思っている。DBが大きくなると、すぐに複雑になっていく感じがする。 だから

忘れる前にやっとこかなと思って、続きをやることにした。 bufferings.hatenablog.com やりたいこと この２つでデプロイ時間にどれくらい差があるかなぁってことを見たい NLBあり + Service Connectなし NLBなし + Service Connectあり 今日のコードはここにある github.com 環境を再構築 OpenTofuで作っておいたから楽ね。 ❯ terragrunt apply -auto-approve ... Apply complete! Resources: 18 added, 0 changed, 0 destroyed. Outputs: nlb_dns_name = "<生成されたNLBのDNS名>" はい。できた。 ECSのTask Execution Roleが必要だった 忘れてたので追加。こんな感じ。 ❯ git di

The AHA Stack というものを見かけて「なんだろこれ？」と思ったので、ちょこっと触ってみた。 ahastack.dev Astro + htmx + Alpine.js のスタックのことらしい。アハ！（これが言いたかっただけ） この記事の目的を無事に（？）達成したので、あとはおまけ。Astro + htmx の example で遊んでみることにする。 Astro? Astro 知らなかった。へー。コンテンツ駆動のサーバーファーストな MPA のフレームワークか。面白いな。 docs.astro.build とりあえず空のプロジェクトを TypeScript で作ってみた。 ❯ pnpm create astro@latest astro Launch sequence initiated. dir Where should we create your new project?

最近、毎日のようにEMのいくおさん（ @dora_e_m ）とTwitterXでわちゃわちゃしてる。彼のポストを見ていると、ガンプラをつくるかビールを飲むかしかしていないように見えるが、それで合っている。 という冗談はおいといて真面目な話をすると、エンジニアとしての僕は彼と仕事ができている今の時間のことを本当に貴重な時間だと思っている。とにかく仕事がしやすいし、いろいろな気づきを与えてくれるおかげで、自分自身の成長も感じている。 エンジニアリングマネージャとしての知識が豊富でスキルが高いというのはもちろん、人との接し方や日常的なふるまいもとても尊敬できるものなのだ。 そこで今日は、僕が彼とこの3ヶ月間仕事をしていて、やりやすい・尊敬していると感じていることの中から10個だけ簡単に紹介しようと思う。僕からいくおさんへの日頃の感謝の気持ちをあらためて書いておこうと思っただけとも言う（ふだんから

軽くリファインメントをする時間 いまのチームでは、デイリースクラムのあとに毎日15分だけ、軽くリファインメントをする時間をとっている。目の前のスプリントのタスクのことをいったん忘れて、次のスプリントやもう少し先のことについてチームで相談する時間。 そこでは、PdM（プロダクトマネージャ）が「こういうこと考えてるんだけどどう思う？」って話をしてくれたり、エンジニアが「このあたり早めに改善しておきたいんだよねぇ」って話をしたりしている。 こういう軽い相談の場とは別に、もっと深く議論したいと思ったり、要件がかっちりと決まってきたりしたら、別途時間をとって、軽くないリファインメントでしっかりと相談している。 軽いリファインメントが結構好き 僕はこの日次の軽いリファインメントが好き。自分の「技術的な部分の改善をしたい」という考えをふわっとしてる段階で聞いてもらえるし、PdMがプロダクトの機能追加や改

昨日、ゆのんさん（ https://twitter.com/yunon_phys ）が社内の勉強会で「エンジニアリングマネージャとは？」って話をしてくれて、面白いなぁって思いながら聞いてた。 今日は @yunon_phys が社内勉強会で、エンジニアリングマネージャについてお話をしてくれてとてもよかった。こんな話が社内で聞けるのって福利厚生だなぁと思いながら聞いてた。— SHIIBA Mitsuyuki (@bufferings) October 13, 2023 その中で「エンジニアリングマネージャが見ることのできる範囲はめちゃ広いから、すべてを完璧にしようとするんじゃなくて、その場に応じてスキマを埋めるような動きができるといい。組織の成長とともにその動きも変わっていく」ってことを言っていて、これって自分のソフトウェアエンジニアとしての動きにも似たところがあるなぁと思ったので雑にメモ。

いまの会社では、エンジニアどうしの距離が近いので、他のチームのエンジニアと一緒に開発に取り組んでたりする。 のだけど僕からは 「この部分はディレクター（社内でスクラムマスター的なロール）さんから、あのチームのディレクターさんに共有してもらってもいいですか？」 って自分のチームのディレクターにお願いしたり 「この部分はプロダクトマネージャ（社内のプロダクトオーナー的なロール）さんから、他のチームに確認してもらってもいいですか？」 ってプロダクトマネージャにお願いしたりしてる。エンジニアどうしで話をして、お互いに状況を理解しているのに、公式なルートとしては、情報を遠回りさせているのだ。 そんなお願いをすると、一瞬（え？エンジニアどうしで話して認識合ってるのに？）って反応をされるし、僕自身も（大企業っぽいかなぁ？）って思ったりするのだけど、自分の気持ちを説明すると「たしかにそうね。おっけー！やっ

コードを書く仕事をしてると、読むことも多い。読んでる時間のほうが多いかもしれない。いま書かれてるコードを読むことも、もちろん多いし、何年も前に書かれたコードを読む機会も割とよくある。 コードを読むと、そのコードを書いた人の考えや、そのときの状況が感じられて、おもしろい。特に、何年も前に書かれたコードを読むときは、コーヒーを片手に（そのときはこんな感じだったんだろうなぁ）って想像しながら読んで楽しい。 ふと、どういうコードから、自分がどういうことを想像するのかを書いてみようと思った。 前提 今、目の前で書かれているコードを読んでレビューしてるときの話じゃなくて、何年も前に書かれたコードを読むときの話をしようと思う。だから、そのコードが良いとか良くないとか、こうするべき「だった」とかは考えない。今後の自分がどう書きたいかなぁ？くらい。 また、そのコードを書いた人が良いとか良くないとかでもない。