👩🏻💻Software Architect 💭 Sunday philosopher 🦀 Occasional @rustlang contributor ⚙️ Co-founder of @rustlang_tokyo 📖 Co authored 『RustによるWebアプリケーション開発』
Joined May 2017
- Tweets 6,150
- Following 324
- Followers 7,168
- Likes 11,202
419 Photos and videos
Jun 13
やっぱworktreeとかを活用した並列的なClaude Codeの使い方にシフトしなきゃと思い、まずtmuxの使い方を見直したい。この記事役に立ちそう！tmux popupでファイルピッカー起動するの、地味に欲しかったやつだ😳
Claude Code × tmuxの個人的活用術 dev.classmethod.jp/articles/…
1
31
306
30,176
Jun 11
これやりたいよね〜って思ってたら、一昨日のAnthropicのカンファレンスで知ったんだけど、Claude CodeならSonnet使いつつ/advisorでOpusを指定すると必要に応じてOpusに相談入れる機能をオンにできる。エージェントはタスクの複雑度の推定みたいなのはすでに認識可能っぽいんだよね🤔
2
12
165
18,916
Jun 11
この記事が詳しく解説してそう。
Claude の Advisor tool を活用して性能とコストのバランスを最適化する
azukiazusa.dev/blog/claude-a…
2
37
2,403
yuki retweeted
Jun 10
高級なモデルが発表されるのは良いんだけど、俺が欲しいのは「タスクの難易度を常時監視して、タスクに対してモデルが貧弱だと検知した場合に一段階高級なモデルにエスカレーションすること」なんだよなぁ
3
13
95
53,271
Jun 9
Code w/ Claude Tokyoに明日行きます！来られる方、会場で〜🙋🏻♀️ Office Hourも用意されていて1on1でAnthropicの人に質問できるっぽいので行ってこようかしら
claude.com/code-with-claude/…
1
14
2,372
Jun 8
いい本だったので書いた✍🏻 サブスクの会計を説明している一冊。エンジニアのキャリアについてどう考えているか、サブスク会計が事業理解にどう役立つか、その他本の内容について考えたことを簡単に書き記しておきました。
『サブスク会計学』
blog-dry.com/entry/2026/06/0…
9
106
13,054
Jun 6
Zigの作者のインタビューの書き起こし記事。そういえばJetBrainsが最近動画あげてたなと思ってまだ見れてなかった。おもしろいー！
コードレビューの本来の目的はメンタリングというのはそうね。Zigは教育プロジェクトで、参加した人がコアチームに加わったり、より優れたシステムプログラマーになって他所で活躍してもらうところまで込み。それを考えるとAI使われてしまうのは目的を果たせないよね、と言っている。
RustとZigはよく比較の対象にあがるけど、「どちらを選ぶかは、「CPUに何をさせたいか」を考えて書きたいならZig」とのことで、これはこれでちょっと興味出てきた。
あと最近はどうやら日本語を学んでいるらしい。動機は「米国生まれ育ちで英語しか知らず、世界の一員でありたくて、ずっと好きだったアニメーションや興味深い文化への思いから日本語を選んだ」とのこと。
全体的にヒューマニズムを大切にしていていいなって思った。あとで元の動画も見よう
ZigがAIを禁止する理由。GitHub離脱、確固たる運営方針。
note.com/naoya_tech/n/ne7c83…
1
17
117
18,141
May 31
よく説明されていてよかった。同僚に薦めたい。最後の「真の不変条件と集約はどこにあるのか」のところはまさにといった感じで、要するにそこをデザインするのが我々の仕事なんだよな。同様に境界づけられたコンテキストもそうで、すべき作業は発見ではなくデザインだと思っている。一方でロールバック周りのわかりやすさ・ミスしにくさの設計は地味に難しくて、どうしようかなと最近思っているけど…😌
不変条件と整合性境界—ビジネスが決める設計判断と実現パターン / Invariants and Consistency Boundaries speakerdeck.com/nrslib/invar…
15
184
12,191
May 30
The Pragmatic EngineerのKotlinの作者が出てるエピソードを見た。おもしろかった！
Kotlinを考え始めた当時はJavaの進化が止まっている時代で、Javaの代替として登場しつつあったGroovyは動的すぎる一方でScalaはちょっと難しすぎ、間のスイートスポットにマーケットチャンスがあるのではと考えたらしい。
Kotlinの作りはじめのころはホワイトボードの前で何ヶ月も言語の形を議論した。たとえばJavaでのペインをリストアップするとか、そこをどう直すとか、あるいはプロトタイプを作ってみるなどしたらしい。半年くらい議論してから実装に移った。
名前は当初Jetにしようかと思っていたが、商標登録されていることに気づいた。RobustaやCeylon(Javaと同じようにお茶から)など考えたけど、最終的にググラビリティを気にした。そこで当時オフィスがあった？サンクトペテルブルクとフィンランドの間にあるコトリン島から名前をとったらしい。
Kotlinの言語機能は最初から狙って「他の言語から借りてくる」つまり巨人の肩に乗る戦略だったらしい。Scalaからはたくさんのアイデアを借りたのと、あと個人的に意外だったのがC#からたくさんアイデアを借りた点だった。C#は当時Javaよりかなり進んでいたらしくて、非常に参考にできたとのこと。
Kotlinに入れられなかったものは2つあって、ひとつがパターンマッチング（whenとスマートキャストで近いものは表現できているが）ともうひとつは三項演算子で、三項演算子を入れなかったのは後悔してるらしい。
最近はCodeSpeakという新しいLLM向けの言語を作っているらしくて、とくにLLM向けの新しいプログラミング言語に対する洞察に富んだ動画でもあり、とてもおもしろかった！
The programming language after Kotlin – with the creator of Kotlin
youtube.com/watch?v=ZggUn2mN…
1
2
16
4,051
May 30
文字による要約はここにも載っていて読める！
The programming language after Kotlin – with the creator of Kotlin
newsletter.pragmaticengineer…
4
1,273
May 25
Crafting Engineering Strategyの邦訳出るのか！この本読んだけど、ルメルトの『良い戦略・悪い戦略』に出てくるフレームをよりブラッシュアップしてより使いやすくしてたと思う
エンジニアリング戦略の作り方 - O'Reilly Japan
oreilly.co.jp/books/97848144…
1
9
44
5,440
May 25
この手の抽象度高めのアーキテクチャや技術戦略の本に毎度出てくるウォードリーマッピングを使いこなしたいと思って学んでいて、試す機会をずっと伺っている。そろそろ来そうな気がするので実践したいんだけど、いかんせんちょっとハイカロリーで概念理解をお願いするところからスタートなのがネック🥲
2
1,120
May 21
主には自分の意見に近く、頭の整理にいい記事だった。私は下記の引用の理解なんだよな…🤔 あと、強整合と結果整合（記事の中では弱整合）とはちゃんと区別してディスカッションする必要あるとは思う。
> 不変条件を守るために恒常的に複数集約のアトミック更新を要求しているなら、それは、本来一つの整合性単位として扱うべきものを、設計上は2つの集約として切ってしまっている可能性が高い。
> 強整合の境界は、「常に一貫していなければならないまとまり」として宣言する線引きだ。2つの集約を恒常的に同じ強整合の境界に入れているなら、設計者はそれらを「同時に、不可分に、整合していなければならないもの」だと宣言したことになる。それはもはや2つの集約ではなく、アトミックに更新される一つの整合性単位——すなわち一つの集約だ。
複数集約を跨ぐ処理を1つのDBトランザクションで括る前に読む記事｜j5ik2o zenn.dev/j5ik2o/articles/59d…
1
19
174
15,844
May 22
で、この考えを少し進めると、Repositoryでトランザクションを開始するデザインは必ずしも棄却できないんだよな。ただし、1集約=1リポジトリならという前提になるけど。定義に厳密に行くならそうした方がエルゴノミックかなと考えている🤔 ちなみに実務ではユースケース相当で開始してるが…
1
837