積読を増やした
いつも使ってるインターチェンジが工事で閉じてることを知らずに高速に乗ったためロードトリップさせられた
Switchのゲームって本体にインストールして物理ソフトがなくても遊べるようにできる？
このアカウントは、notestockで公開設定になっていません。
DB設計なんも分からないんだけど、many-to-many relationを表現する中間テーブル以外でcomposite primary keyを使ったほうが便利なケースってあるのかな
持ってるカラムの複合で識別できる場合でも、通し番号振っといたほうがhas_oneやbelong_toの対象になったとき参照しやすくて（カラムを1つしか使わなくていいので）便利じゃない？
このアカウントは、notestockで公開設定になっていません。
ネームスペースがあるときは確かに(NS, Name)がキーっぽさはあるが、主キーとしてはやっぱり通し番号があったほうが便利そう。(NS, Name)はUNIQUE制約つきでインデックスを張る
ストレージの最適化とかを考え出すと(NS, Name)で主キーにしたほうが効率のいい配置になる可能性もある気がする……が、どう考えても本当に限界突破したいとき以外に触れるべきではなさそう
FooFactoryの中で依存を全部詰めたFooCompanionみたいなのを作っといて、FooのコンストラクタでFooCompanionを渡せばそれっぽくなるか？ていうかそれならFooFactoryそのものがFooCompanionにもなれば良さそうだな
FooFactoryであってFooのCompanionでもあるクラスを作るとしたらどういう名前がいいんだろう。普通に考えるとFooCompanionっぽいが、FooCompanionが型名になってFooCompanion fooCompanionという見た目の変数宣言が生えるのはなんかきもい
まあFooCompanionのインスタンスはDIで作られるからシングルトンになるし、謎の型名を持つ以外は本当にCompanion objectっぽいんだけど……
まあScalaのimplicit parameterみたいなもんだと思えば、FooのCompanionにアクセスしたい人がFooCompanion型の変数を宣言するのも変ではないか（？）
あんまりうまく行く気がしないな。サービスレイヤのメソッドの第一引数がドメインモデルを取れば実質ドメインモデルのメソッドみたいな見た目になるからそれでいいか……
Javaのrecordのモチベーションがいまいち分からんな。結局Lombokのサブセットじゃない？まあJava単体で見たときにかなり足りてない部品ではあるけど……
Java16、思ってたほどすごくはないのでやっぱりKotlinの方がいいな
