yuki

👩🏻‍💻Software Architect 💭 Sunday philosopher 🦀 Occasional @rustlang contributor ⚙️ Co-founder of @rustlang_tokyo 📖 Co authored 『RustによるWebアプリケーション開発』

[yuki @helloyuki_]

よく説明されていてよかった。同僚に薦めたい。最後の「真の不変条件と集約はどこにあるのか」のところはまさにといった感じで、要するにそこをデザインするのが我々の仕事なんだよな。同様に境界づけられたコンテキストもそうで、すべき作業は発見ではなくデザインだと思っている。一方でロールバック周りのわかりやすさ・ミスしにくさの設計は地味に難しくて、どうしようかなと最近思っているけど…😌

不変条件と整合性境界—ビジネスが決める設計判断と実現パターン / Invariants and Consistency Boundaries https://t.co/RlN97vOT33

[yuki @helloyuki_]

文字による要約はここにも載っていて読める！

The programming language after Kotlin – with the creator of Kotlin
https://t.co/y4TyRdStGC

[yuki @helloyuki_]

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
https://t.co/963HjPCfrR

[yuki @helloyuki_]

この手の抽象度高めのアーキテクチャや技術戦略の本に毎度出てくるウォードリーマッピングを使いこなしたいと思って学んでいて、試す機会をずっと伺っている。そろそろ来そうな気がするので実践したいんだけど、いかんせんちょっとハイカロリーで概念理解をお願いするところからスタートなのがネック🥲

[yuki @helloyuki_]

Crafting Engineering Strategyの邦訳出るのか！この本読んだけど、ルメルトの『良い戦略・悪い戦略』に出てくるフレームをよりブラッシュアップしてより使いやすくしてたと思う

エンジニアリング戦略の作り方 - O'Reilly Japan
https://t.co/5CRatst6l7

[yuki @helloyuki_]

で、この考えを少し進めると、Repositoryでトランザクションを開始するデザインは必ずしも棄却できないんだよな。ただし、1集約=1リポジトリならという前提になるけど。定義に厳密に行くならそうした方がエルゴノミックかなと考えている🤔 ちなみに実務ではユースケース相当で開始してるが…

[yuki @helloyuki_]

主には自分の意見に近く、頭の整理にいい記事だった。私は下記の引用の理解なんだよな…🤔 あと、強整合と結果整合（記事の中では弱整合）とはちゃんと区別してディスカッションする必要あるとは思う。

> 不変条件を守るために恒常的に複数集約のアトミック更新を要求しているなら、それは、本来一つの整合性単位として扱うべきものを、設計上は2つの集約として切ってしまっている可能性が高い。

> 強整合の境界は、「常に一貫していなければならないまとまり」として宣言する線引きだ。2つの集約を恒常的に同じ強整合の境界に入れているなら、設計者はそれらを「同時に、不可分に、整合していなければならないもの」だと宣言したことになる。それはもはや2つの集約ではなく、アトミックに更新される一つの整合性単位——すなわち一つの集約だ。

複数集約を跨ぐ処理を1つのDBトランザクションで括る前に読む記事｜j5ik2o https://t.co/W3dgp3xsi4

[yuki @helloyuki_]

社会人以後の英会話はあんまりアドバイスできることがないんだけど（なる前から話せたので…）、強いて言うなら受験英語とは違うので、英語の座学のテキスト開くより英会話に通うのがいいかと思いました。週1時間でもいいので英語のシャワーを浴びるのと日本語への逃げ場をなくすのが一番早いですね😂

[yuki @helloyuki_]

私も外資系(US)経験者だけど、maguroさんに同感で日本のソフトウェアエンジニアは職人的で仕事が丁寧だと思う。一方で仕組み作りというか再現性の高い施策をちゃんと考えて打てるとか、体系的というか包括的な施策をちゃんとやるのが外資な感じは確かにするな。つまりふたつを持てれば無双できるということかもしれない🤔

【外資ITエンジニア対談】日本人が知らない海外のエンジニアと日本のエンジニアの違い https://t.co/dw8eTbrJfI

[yuki @helloyuki_]

わかる😌

> そう捉え直すと、認知特性のラベリングは、もともと設計の問題として扱える領域を、人間の側に押し戻しているように見えてきます。「あなたはこのタイプだから境界の引き方がこうなる」という説明は、確かに摩擦の発生源を可視化はしますが、その境界の引き方が妥当かどうか、という肝心の問いには答えていません。

> 人を分類するよりも、何をどう作りたいかについて対話しましょう。そっちのほうが遠回りに見えて、結果として近くなるはずです。

設計の境界線と、その手前にあるもの｜Kazunori Otani https://t.co/YvljyAI94B

[yuki @helloyuki_]

これ結局深く追ってないけど、invariantsのコメントからおかしくなってるとか全然大丈夫じゃないっぽかった。やっぱりダメかー。ここからはmiri入れて検出して潰しまくるとかなのかな🤔

[yuki @helloyuki_]

I'm super excited to hear the result even if Bun wouldn't merge the Rust version. The migration experience is always valuable for the tech community!

[yuki @helloyuki_]

Zigからほぼポートしたみたいな実装が多くてunsafeだらけでどうなんみたいな話があったのかな。そもそもunsafeで囲われてても結果soundなら問題はないし、Mythosで仮に書いてるとするとinvariantsの保証も人間が書くよりかなり正確そうなので（この前むしろsafe Rustのunsoundness見つけてたくらいだし）、大丈夫なんじゃないかなとか思ってしまうけど🤔

[yuki @helloyuki_]

@giginet かわいい！おめでとうございます！

[yuki @helloyuki_]

ちなみにGoを推す記事も見たし実は動的型付き言語も…という記事も見たし、どれもポジショントークなのは忘れてはいけなそう。私もKotlinでとくにひどいと感じたことはあんまりないし、言語より多分大事なのはrulesやskillsの整備な気はする😌

[yuki @helloyuki_]

Rustは制約や不変条件を型付けでエンコードできるのでコーディングエージェントに最も向いているのではという記事

Rust is the best language for coding agents
https://t.co/IUswq9ZGyI