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

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?

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

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

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

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

GitHubの鍵を1Password管理に ちょっと前に、azuさんの記事を読んでSSHの鍵を1Password管理にするのいいなと思ったので efcl.info GitHubのAuthとSigningの鍵を1Password管理にしておいた。 GitHubの鍵を1Password管理にしといた。簡単だった。よいー。https://t.co/Vo2OA230V5— Mitz Shiiba (@bufferings) March 25, 2023 azuさんの記事だと、SSHの鍵以外も色々やってるんだけど、そのへんはまたの機会に。 便利 GitHubにアクセスするときに、macOSのTouch IDを使って指紋で認証するだけでよくて便利。しばらくは有効なので、毎回認証が必要なわけじゃないのも便利。 なんだけど、tmuxで新しいペインとかウィンドウを開くたびに聞かれてしまうのか、有効期限が短い

しばらくしたら次のことを考えたいなと思ってるので、よい仕事や空いてるポジションがあったら教えてください！— Mitz Shiiba@フルスタックエンジニア (@bufferings) December 8, 2022 突然ですが CircleCI を辞めることになりました。そのことについてあまり話すつもりはないのですが、今の気持ちだけ書いておくと、びっくりはしたけど特にネガティブな感情はなく、面白い経験だなぁという気持ちです。 この一年間、色々とあまりできない体験をしてきた締めくくりにピッタリです。この状況を受け入れて、流れに身をまかせて楽しもうと思います。 ということで、こんな機会はあまりないので、次をどうするか、折角だから色々な会社のお話を聞いてから考えたいなぁと思ってつぶやいたら、たくさんのご連絡をいただき、とても嬉しく思っています。ひとつひとつのお誘いや励ましが、とてもありがたいで

観測しようとすると、その観測が影響を与えてしまう感じで、おもしろい 自分の頭の中 この機能をチームで開発するのに、だいたい2ヶ月くらいかなぁと自分が頭の中で思っているとする。もし僕らの知ってる範囲ですべてが収まれば1ヶ月くらいで終わるかもなぁと思いつつ、まぁ、知らない範囲のことがあるだろうし2ヶ月くらいに思っておくのがいっか という感じ。6割ぐらいの自信 チームの中 チームメイトに「この機能いつ出せるかな？」って聞かれることはあんまりないと思うけど、もし聞かれたら「んー、2ヶ月くらいじゃない？もしかしたら、もうちょっと早くできるかもだけどね」ってそのまま頭の中を伝えると思う 聞かれることがあんまりないというのは、そもそも、チームでラフに見積もるから。Tシャツサイズとかストーリーポイントとかを使って「Mサイズだから2ヶ月くらいだね」って話をするだけで済む。「2ヶ月くらいだね」って言ったものは

TDD についておさらいしておきたいなと思ったので読んだ t-wada.hatenablog.jp とても良かった。自動テスト、テストファースト、テスト駆動開発のそれぞれについて、どういうものなのか・効果・注意点が分かりやすく説明されている。たしかに、自動テストは必ず使うけど、テストファーストやテスト駆動開発は状況に合わせてやったりやらなかったりする 書籍「テスト駆動開発」の付録Cと対になっているということなので、付録Cも読みたくなって読み直しておいた。そちらにはテスト駆動開発のこれまでとこれからについて書いてあるので、頭の整理ができてとてもよかった Checking Driven Development 付録Cでは、開発者自身が書く自動テストはテストではなくてチェック、ということについて触れられている。そうだなぁって思う。自動テストでは、自分が考えたとおりに動くかどうかをチェックしている

ぼーっと。最近は、フルスタックすきまエンジニアっぽい。と思ったので、とりあえずタイトルだけ書いて、深く考えずに書き始めてみる 僕は、好きなサービスの周りのことだと、何をやっても楽しいタイプなので、これをやったらチームにとって良さそうかな、って思うことをやってたら楽しい。ただ、そのままどっかに行ってしまうとあれなので、軸足はコーディングに置くように意識してる あと、自分は色んなことを同時に考えられるタイプではないので、たくさん面白そうなことがある中で、最大でも3個くらいしか選べないよなぁと思っている。それ以上手をだしてしまうと、混乱する。だから、今の自分がどのスキマを埋めるのがいちばんいいかなぁってのを雰囲気で考えながら動いてると思う。たぶん 具体的に何をやってるかなぁって考えてみる。色々あるけど、同時にやってるわけじゃなくて、どれかをやってるときは、別のことは横に置いてる コード周り 軸足

前回は Git-flow とデプロイについて書いたので bufferings.hatenablog.com 今回は、トランクベース開発とデプロイについて考える。LinkedIn, Facebook, Google などもトランクベースの開発をしてるんだね 参照: Agility Requires Safety | Y Combinator トランクベース開発は Git じゃなくてもいいと思うんだけど、この記事では Git 前提で考える トランクベース開発？ 幹（trunk）となるブランチにみんなが小さな変更を加えていくブランチモデル。寿命の長いブランチを作らないようにすることで、マージでつらい思いをしなくて済むようになって、ビルドも壊れないようにできて、ヤッター！というもの trunkbaseddevelopment.com Git-flow みたいに develop ブランチで開発をする

前回 は継続的にデプロイしてるよって話をしたので、その流れで今日からちょっと Git を使った開発フローに対するデプロイについて考えてみたいと思う。まず最初はやっぱり Git-flow からかな。と、その前に 前置き 自分は CircleCI だとどうなるかなぁとか考えながら書いてるけど、どの CI サービス・ツールを使っても大丈夫 自分の頭の中にあるのはウェブ系の自社サービス。スマホアプリとか組み込みとかは経験がないから分かんない どんな風にテストを実行するかみたいな話も面白いけど、今回は CI のことは忘れてデプロイだけ考える どのフローが良い・悪いという話ではない Git-flow ということで Git-flow 。この絵は有名ですね どこが始まりなんだろう？って思ったら2010年のこの記事みたい： https://nvie.com/posts/a-successful-git-br

CircleCI に入って色々と面白いなぁって思いながら毎日楽しんでる。その楽しんでることのひとつに Git のブランチモデルがある。最初はびっくりしたけど、慣れるととても良い 最初に言っておくと、この手法がどこにでも当てはまるとは思ってない。業種や、開発形態、プロダクトのタイプなどによって合うやり方は違う。単に CircleCI には、この手法がとても合ってるなぁと思う トランクベースのブランチモデル タスクに着手するときは、まずメインブランチからそのタスク用のブランチを作る。develop ブランチや release ブランチみたいな長く生きてるブランチはない。そのタスク用のブランチにコミットをプッシュしたらプルリクエストを出す。そして、レビューが終わればメインブランチにマージされる。タスクに着手してからマージまで、はやければ1時間ぐらい。長くてもだいたい2,3日くらい そして、メイン

そんむーさんのこの記事を読んで、すごいなぁかっこいいなぁって思って、そういえば僕も41歳だーって思ったので、書くことにした。軽い気持ちで書き始めたら思っていたよりもとても考え込んでしまった。 songmu.jp CircleCI に入社しました 11年勤めた楽天を離れて CircleCI に入社しました。先週の月曜日の10月18日から Senior Full Stack Engineer として仕事をしてます。大阪の自宅からフルリモートです。 寒くなってきたからちょうど良かったー！ https://t.co/td9lks2qVS pic.twitter.com/9AW6X8CPgH— Mitsuyuki Shiiba (@bufferings) October 20, 2021 次の挑戦をするのに、ちょうどいい時期かなぁ ここ数年は、色んなチームのサポートをするエンジニアをやってました。テ

この記事を読んで、自分が後輩をサポートするときはどうするっけなぁって考えてみた。例によってあんまり深く考えずに勢いで書く。誰にでもどこにでも当てはまるもんじゃないと思う。僕のいる環境の話ね。 note.com 信頼する まずは、信頼する。頑張ろうとしてるとか、良いものを作ろうとしてるとか、自走したいと思ってるとか。そういうの。例えばもし「頑張ろうとしてないように見える」場合、「頑張ろうとしている」という部分を信じてるから、その気持ちが行動につながるまでの間のどこかに妨げとなる何かがあるはずって考えて、それを見つけて取り除いていく。 対話 自分の期待を共有する 「自走できるようになってね？」ってだけ言って待ってるのってめんどくさい。僕はめんどくさいことが嫌い。楽をしたい。てか、言うだけでできるならもうなってる。それよりも、今何ができているか、次の一歩は何か、目指したいのはこういうところだよ、

を言葉にしてみようと思った。僕のいる場所での話。ステークホルダーに対する窓口としてプロデューサーがいて、僕が開発チームのリーダーをしてるようなとき。 ## 状況を把握する システムトラブルが発生すると場が混乱してることが多い。色んな情報が混ざるし、色んな人から問い合わせが来たりするし、窓口になってくれているプロデューサーからの説明も省略されていることが多い。このときに一番避けたいのは、ミスコミュニケーションによって本当の問題を見失って無駄な作業をしてしまうこと。 なので、まずは落ち着いて状況を正確に把握する。ちょっとでもはやく解決したいから、その断片的な情報を元に調査に入りたい気持ちになるけど、ぐっとこらえて全体像を把握する。 コミュニケーションで特に気をつけるのは、相手や自分の中にある思い込み。思い込みがあると喋るときには（当然分かってることだよね）と言葉を省略してしまうし、聞くときには

## ローカルでk8s ちょっと試してみたいときとかに、ローカルでk8sを動かしたくて。以前だとMinikubeとかDockerについてくるk8sとかを使ったことがあるけど、今だとまた何か出てるかな？と思ってたらこういうスレッドを見つけた。 K3s, minikube or microk8s? : kubernetes Minikube Microk8s K3s Kind Desktop Docker K3d Kubeadm が紹介されてた。へー。と思って、なんとなくk3dが面白そうかなと思ったので試してみた。 ## k3d https://github.com/rancher/k3d 紹介されている一覧の中にあるk3sをDockerで動かしてくれるのがk3dということみたい。Dockerを動かすプラットフォームをDockerの中で動か・・・す？こんがらがる。 僕はUbuntu使ってるんだ

AよりB、CよりD 今後の方向性を決める判断の中で「Aという技術ではなくBを採用する方がが良さそうです」とか「既存システムのCは良くないからやめてDを使うようにしましょう」とか。最近、何人か全然別の人からそういう話を聞く機会があった。 AよりBが良さそう？ 「僕はAの方が良いと思うんですけど、Bの方が良さそうだと思う理由を知りたいです」って聞くと「Aはこういう部分に問題があると思います」って言われて話が噛み合わなくて、しばらく話をして気づいた。 この人、Aを触らずに想像だけで喋ってるんだ。ってことに。なので、実際に動かして見せてあげると「あぁ、それならAの方が良いですね」ってなった。 「興味があるだけなんですけど、僕も知らない技術だったので少しドキュメントを読んで実際に触ってみて機能を確認してからAの方が良いなと思ったのですが、どうして触らずに想像だけでAは問題があるって断言したんですか？

最近ちょこちょこ相談されることがあって、直接のスキルではないけど、こういうのもスキルだよなぁって思ったので、思いついた順に書いてみる。5個になった。 ## 1. 問題を切り分ける力 「これがなぜか動かない」って相談されたときって、いくつかの要素が絡んでることが多い。 なので「ここは明らかに問題ないでしょう」という一番土台のところからチェックを始める。そうすると「え？そこは問題ないと思いますよ？」って言われるので「うん、それを『問題ないと思う』じゃなくて『問題ない』って断言できるようにしようと思って」みたいな会話をよくする。 可能性をひとつずつつぶしていくと「ここだなぁ」って場所が見つかって、そしたら、もうあとはそんなに難しくない。ひとつずつ確認していくのって遠回りに見えるけど、結局その方が確実ではやいと思う。 ## 2. 想像と事実を切り分ける力 ↑と絡んで、想像や思い込みなのに、「ここは