あひる焼き中野の梓さん
FiberErrorのやつ、シグナルハンドラの中からGtk.mainなりDialog#runなりで新しくメインループを起動している限り解決は無理っぽい気がしてきた。そもそもDelayerという発想自体が1スレッドのイベントループを前提としたものだから、メインスレッドを擬似的にサスペンドするテクとは相性が致命的に悪そう（メインスレッドが止まってるのにメインスレッドでenqueueされたイベントを消費し続けたいというニーズがDelayerの設計思想と噛み合ってない）
結論は結局 https://dev.mikutter.hachune.net/issues/995#note-15 だけど、適切な実装というのが本質的に存在しなさそう
再帰Gtk.mainはGTKのイベントを処理し続けるためのテクなので（だよね？）思想が噛み合ってないは言い過ぎな気がしてきた。再帰Gtk.mainによる擬似yieldと本物のFiberとシグナルハンドラの実装が干渉したことによる悲劇っぽい（が、こう書くと擬似yieldというテクの存在がすべての原因っぽく見えてくる）
そもそも令和時代にもなってダイアログが閉じるのをblocking function callで待ち受ける必要があるのか？人類がGtk.mainを再帰するのをやめれば平和的に解決するのでは？
あずにゃん画像かどうか判定する方法、ascii2dに放り込んであずにゃんタグの付いたpixivが出てきたらあずにゃんです
いつも使ってるインターチェンジが工事で閉じてることを知らずに高速に乗ったためロードトリップさせられた
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の方がいいな
AirTagがBT信号をブロードキャストして、それに気付いた対応機器がAppleに所在を通知する感じなのか？
ブルアカにもアズサというキャラがいるらしく画像がよく流れてくるけど、描いてる人によって見た目にかなりブレがある気がする
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
Yukari Next 3.1.4.2446 (mirage 230430 82f5d26)/exvoice arm64-v8a(May 3 2022 12:44:30)/Google/Pixel 6/13
このアカウントは、notestockで公開設定になっていません。
運転しながらYouTube Musicのおすすめしてくるプレイリストを聞くことで流行の音楽情報を仕入れてる
Protobufを直接データレコードとして使うのやっぱり辛いのでは？の気持ちになっている
文字通りProtocolのBufferだから、スキーマが厳密に定義できる内部ロジックでProtobufが飛び交うとつらい
レコードの振る舞いはフォールバックせず厳密にして、SerDeを複数使い分けることで欠損値やバージョンの処理方法を選べる方がよいデザインっぽい
ONI、世界は縦に広く部屋は横に広がりがちだから基幹配線は縦方向に伸ばして横方向に引き込んだ方がいいのか？
