昨日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

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

8/26 発売！ 『スクラムの拡張による組織づくり』をいただいて読んだ。だいくしーさんの書かれた本。昨日 8/26 発売。すごく読みやすいし、色々と頭の中でぐるぐる考えて面白かった。 gihyo.jp 大規模スクラムに興味がある人にオススメ Scrum@Scale という大規模スクラムのフレームワークの解説を中心にした書籍なので、Scrum@Scale に取り組みたい人や大規模スクラムに興味がある人には、もちろんとてもオススメ。僕は全然 Scrum@Scale のことを知らなかったので本書で入門できて勉強になった。 そして、読みやすい。これから何を説明するのか、なぜこれをここで説明するのか、という著者の意図が各章の最初に書いてあるのが嬉しい。まえがきを含めて、一冊を通しての流れがとても分かりやすいので、まえがきから読むのがオススメ。 まえがきから第6章までを通して読んで「なるほど。Scru

Jestではじめるテスト入門 本日「Jestではじめるテスト入門」がついに発売されました 🎉🎉🎉 peaks.cc CircleCI時代の同僚の伊藤さん @ganezasan が「Jestの自動テスト本の執筆を手伝ってくれませんか？」と声をかけてくれて「これからテストを書きたいって人に向けたJestの入門書を書きたいんですよ！！」って熱く語ってくれて「いいなぁ」と思ったので参加しました。本を書くなんて初めてのことなので、自分なんかに書けるかなぁとドキドキしてたのですが、周りの方々の助けのおかげで、なんとか書き上げることができました。 そして、監修はなんと和田さん @t_wada です。自分が自動テストについて書いた文章を、和田さんに監修していただけるなんて、それだけでとても幸せだなぁと思っていたのですが、「むちゃくちゃ面白かったです！」って言ってもらえたので、もう出版しなくても満足し

アジャイルリーダーシップ を翻訳者の一人であるヒロオカさんにいただいて読みました。ありがとうございます！今の自分にグサッとくる内容でとてもとても良かった。今後の自分の行動も変わりそうです。今日から数日後の11月22日に発売されます www.kyoritsu-pub.co.jp 読みやすかった 著者は SCRUMMASTER THE BOOK を書かれたズージーさん ズージーさんの本自体が読みやすいのと、あと、ユーザベースさんの翻訳が読みやすいのとで、とても読みやすかった。英語の言い回しって日本語にすると分かりにくかったりするけど、そういうのがなくて、自然に読むことができた アジャイルリーダーシップ？ 「アジャイルリーダーシップ」ってタイトルを見たときは、アジャイルなチームのリーダーの話なのかな？スクラムマスターはこうあるべきだよとかって話？と思ったのだけど、読み始めてみるとそうじゃなくて、

config.yml を分割できる Orb を作ったよー Split Config Orb という Orb を作った こないだからちょこちょこ試してたやつを Orb にしたのだ。この Orb を使うと config.yml を分割できる。Orb にしたから簡単に使えるよー！ config.yml が大きいから分割したいー！って場合や、モノレポで複数サービスを入れてるから各サービスごとに config.yml を書きたい！って場合に使えるかなぁって思ってる もしちょっとでも興味があったら、実際に使ってみてフィードバックをいただけると嬉しいです。フィードバックを元にして機能をブラッシュアップできるといいなと思ってます！GitHub の Issue でも Twitter でメンションくれても OK です！ GitHub Issue: Issues · bufferings/orb-split-c

ぼーっと CUE のドキュメントを読みながら CUE という設定用の言語・・・と呼んで良いのかな？のドキュメントを読みながら https://cuelang.org/ 「これ、いろんな機能があるけど、それは置いといて、YAML の合成が簡単にできるのでは？・・・とすると、CircleCI の設定を簡単に分割できて面白いかもなぁ」 と思ったので試してみた。わりとアリかもしれない 今回のサンプルコードはここ： github.com どういう感じ？ こんな感じに適当に分割した設定を ❯ tree .circleci/configs .circleci/configs ├── header.yml ├── job1.yml ├── sample │ ├── job2.yml │ └── mixed\ sample.yml ├── workflow1.yml └── workflow2.yml 1

ちょっと前にツイッターで見かけた、ゆめみのフロントエンドコーディング試験 フロントエンドコーディング試験 「RESAS API を使用して、都道府県別の総人口推移グラフを表示するSPAを作る」っていうお題 React の勉強をするのにちょうどいい題材だなぁって思ったのでやってみた。課題を公開してるってことは「やってみてもいいよ」ってことかなと思ってるんだけど、もし違ったら GitHub のリポジトリーを private にするので連絡ください 1週間でやらないといけないところを2ヶ月近くやってるし、コミットログも特に何も考えずにポイポイ書いたから、全然だめなんだけど、でも、色々勉強になったので、とてもよかった。楽しかったー！ つくったもの こんな感じ これでおわりにするー pic.twitter.com/K8zhrRUp54— Mitsuyuki Shiiba (@bufferings)

かなり良かった 「良いコード／悪いコードで学ぶ設計入門」を読んだ。読む前は特に書くつもりはなかったんだけど、かなり良かったからブログを書くことにした gihyo.jp どういう本？ この本は、読みやすくて変更しやすいコードの書き方と設計についての入門書 どのようなコードが悪いコードなのか、そこにどういう問題があるのか。それに対してオブジェクト指向設計で、どのように設計してコードを書けば、より良いコードを書くことができるのかを、分かりやすい例でコードを追いかけながら、学ぶことができる 読むと良さそうな人 2,3年目くらいで「もっと良いコードを書きたい！」とか「どんなコードが良いコードなんだろう？」って考えてる人や もうちょっと経験があって、機能追加や改修をするときに苦労をしてきて「どんな風に作ればこの苦労を減らすことができるんだろう？」って悩んでる人には、特におすすめ それ以外でも、今はコー

昨日はトランクベース開発とデプロイについて書いたので bufferings.hatenablog.com この勢いで GitOps とデプロイも書いてしまうー。先に言っておくと、自分は GitOps の経験はない。でも、よさそうだなぁと思う手法なので、機会があれば挑戦してみたい気持ち GitOps? GitOps は2017年に Weaveworks の Alexis によって提唱された手法で、Kubernetes を対象としている Guide To GitOps Git のリポジトリーに入れてある設定ファイルを Single Source of Truth として、Kubernetes のクラスター管理とアプリケーションデリバリーを行う。上記の記事には次の4つの原則が書かれている システム全体が宣言的に記述されていること 正規の望ましいシステムの状態が Git でバージョン管理されている

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

この数年間は、エンジニアとして他のチームに入っていって、そのチームの改善をサポートする、という活動をしてる。 そういうときに自分が意識しているのは「自然とそうなるようにする」ということ。だって、それが例え良い変化だとしても、外からやってきた人から求められてする変化ってすごいストレスだから。 ここに行けたら良さそう、というのが自分には見えたとして、 これが足りない、ああした方がいい、どうしてこんな実装なの？とか、そういうネガティブな指摘をしても、構えられるだけだし、相手のストレスになってしまうし、良いことない。 このチームってこういうところが良いね、あの部分は難しいのによくやってるね、みんなお互いに助け合ってるの良いね、とか、そういうポジティブな部分を伝えながら、できている部分を認めながら、ちょっとずつ前に進むのがいい。 色んなタイプの人やチームやマネージャーがいるから、それぞれに合ったやり

もう今の会社で10年目に突入してしまってた。こんなに長く働くと思ってなかったなぁ。しみじみ。この10年間でほんとに色んなことが毎年変わっていってて、幸せなことに僕はエンジニアとして色んなチームやサービスに関わらせてもらってきた。 そんな中で最近思うのは、組織のフェーズによって求められるものって変わっていくよなぁってこと。そこに、楽しさと、難しさがある。 特に、サービス立ち上げ期と、組織の拡大期では、求められるものが全然違うので、立ち上げ期のメンバーが組織の拡大期にマネージャーをやると悩みそう。だし、いい感じにやってる人たちはすごい。 以下、ふんいき。こんな感じする。全然まとまってなくてざざっと書くけど。 ## サービス立ち上げ期 少数精鋭のメンバーが、持ってるスキルを存分に発揮してサービスの生き残りをかけて取り組むフェーズ。 寝ても覚めてもサービスのことを考えてるような人たちが、自分たちの

## 去年の夏ぐらいからサポートしているチーム で、それまでもちょこちょこモブプログラミングを試してはいたんだけど、3月からは思い切ってそれを基本として開発をするようにした。つまり、3月からは1日中モブプログラミングをするのを毎日やってる。 プログラミングだけじゃなくて、設計も、運用も、テストも、全部モブでやってるので、僕らはそれをモブワークと呼んでる。 ## やっていく中で学んだのは モブプログラミング（モブワーク）は「全員でプログラミングをする」ということではなくて「全員で考えて取り組む」というだけのことだった。 サービスにとってどう動くのが良いかを全員で考える。 目の前のプロジェクトのことだけではなく、少し先を見据えてメンバー間の知識やスキルの共有や、チームがまだ詳しくない分野の学習をすることも含めて、どこにトレードオフスライダーをセットするのが良いかを全員で考える。 ## 全員でプ

今日は娘達とマリオをしたりしながらスキマ時間で、ぼーっとMicronautのドキュメントの3.1-3.5までを読んで手を動かしてみた。 https://docs.micronaut.io/latest/guide/index.html#ioc ソースはここ。 https://github.com/bufferings/hello-mn/tree/20190301-ioc/src/main/java/hello/mn/ioc Javaは11を使ってて、Micronautは1.0.4を使ってる。 ❯ sdk current java Using java version 11.0.1-open ❯ sdk current micronaut Using micronaut version 1.0.4 ## 通常のDI こういう感じでBeanを定義しておいて： public interface

## 前編はこちら bufferings.hatenablog.com 前編では「1. チーム」と「2. スプリントの内側」の話を書いた。後編は「3. スプリントの外側」と「まとめ」のお話。長くなったー！ ## 3. スプリントの外側 お試しスプリントで小さく試してみたときとかは良い感じなんだけど、いざ実際にやり始めてみると「あれー。ここどうしたらいいんだろう？」って悩むことが結構あった*1。そういうのってスプリントの外側の話が多い。その中のひとつが「長いプロジェクト」。 ## 3-1. 長いプロジェクト 絵の大きな円の部分。毎回リリースすることができないような長いプロジェクトの場合はフェーズの切り分け方を考える必要がある。 ### フェーズの切り分け方 右側の付箋みたいなのじゃなくて、左側の網掛けみたいなので進める。最初の頃は、右側みたいに進めたこともあるけど、これだと開発やテストで得た

「スクラムフレームワークを使用する具体的な方法。僕の場合。」というタイトルでスクラムフェス大阪で発表してきました。楽しかった。今回のは説明がある方がいいかなーと思ったので、スライドをアップロードするんじゃなくてここで紹介してみることにする。長くなりそうなので、今日は前編。 ## TL;DR 計画を持った開発のサイクルと、それとは異なる周波数の様々なイベントを、どううまく組み合わせて開発を進めるか。それを、自分の現場で自分の仲間と探していく道のり。 ## 全体像 左上が「1. チーム」、左下が「2. スプリントの内側」、右半分が「3. スプリントの外側」。この3つを紹介。正解やオススメというわけではなくて、自分たちの現場ではこういうやり方をしている、という紹介。 ## 1. チーム ビジネス・デザイン・開発の3つの組織に分かれている。そんな中で、どんな風に協力しながら開発を進めているか。 #

## 2月23日に発売予定 解説を書かれた及部さんからいただきました。ありがとうございます！ 今日届いてたのでどんなことが書いてるのかちょっとだけ読んでみようかなーって思いながら、あーわかるーとか言いながら読んでたら、サクッと読み終わってしまった。おすすめです。 books.rakuten.co.jp ## 読んでみてどうだったか？ 良かった！ 僕はこれまでに、何度かモブプログラミングを小さく実験してて「ふーむ。これは良さそう」と思ってて。ついに先週は「一週間ずっとモブプログラミングをする」という実験をして、このチームに合ってるなーと感じたので、組織として正式に導入する相談を進めてるところ。 この本には、そんな僕達が学んだり、悩んだり、試行錯誤したり、実感したりしたことの多くが書いてあって、笑った。先に読みたかったわ。 ## どういう人におすすめ？ こういう人かな： モブって何が良いの？っ

## RSGT2019の発表の準備をしてる タイトルは「ちゃんとやってるのになんかうまくいかないスクラムからの脱出」。 confengine.com ## 「スクラム現場ガイド」を読み直してみてる ちょっと頭の中がこんがらがってきたので、気分転換に「スクラム現場ガイド」を読み直してみてる。面白い。読んでて気づいたんだけど、副題が「スクラムを始めてみたけどうまくいかない時に読む本」だから、僕の発表のテーマと同じだ！ books.rakuten.co.jp ## どこか違う世界の話 読みながら、言ってることは分かるなぁと思いつつ、でも、物語には違和感がある。というのも例えばある人が「ペアプロ嫌だな」と思っていたとして僕の周りでは「仕事を失いたくないから」と拒まれることはない。どっちかってと「自分のスキルが見られるのが恥ずかしいから」ぐらいな感じ。環境や文化の違いなんだろうな。物語は全体的にそう

後輩主催の社内ハッカソンが楽しかった。 ## 大阪ハッカソンやろうよ 楽天テクノロジーカンファレンス大阪のスタッフをやってた後輩が10月末のうちあげで「大阪支社で部署を超えてハッカソンをやったら面白そうだと思ってるんですよねぇ」っていうので「ふーん。じゃ、来月でいいかね。3人くらい『ハッカソンを開催したい！』と強く思う人を来週中に集めたらできるよ。僕はメインスタッフというよりは、サポートという感じで関わろうかな」って話をしてたのが、先週開催された。想像以上に面白かった。 ここは @yohhatu メソッド。僕「よーさん、また今度飲みにいきましょうよ」yohhatu「ええなー、来週いつあいてるの？」。 ## 目的 「最近は大阪支社の開発部も100人を超えてるし部署も分かれてるから技術的な交流が少ない。色んなスキルを持ったメンバーがいるのにもったいない。そういう場を作りたい」というのが彼のアイ