Notices by 日下夏稀 (kb10uy@mstdn.maud.io), page 16

すごい、「なにのんきにパズドラしとんねん殺すぞ」はセーフでこれはダメだったのか

tracing と marching を対比させるときは方程式の解法が解析的か数値的かに焦点があって、ray と path を対比させるときは確率的かどうかをみている感じがある

狭義レイトレーシングの対義語にレイマーチングを配置する派閥もある

cloneclonecloneclonecloneclonecloneclone

「描画するメッシュは同じで位置情報だけ違うのを大量に描画する」というの、「対象カラムは同じでパラメーターだけ違うのを大量に INSERT する」とそっくりだと思いませんか

GPU Instancing になぞらえて Row Instancing みたいな名前で誰か実装してそう

午前中に言及した「prepared statement が RDB サイドでインスタンシングされてほしい」ってのはこれで、プレースホルダーに詰めるデータ全部配列に詰めておいたバッファと VALUES (...); だけの SQL を渡して詰め直しは RDB 側でやってくれるシステムがあったら素敵だよね、と思うわけです

prepare したところでカッコが 1 つだと各行ごとにアプリ側に制御が帰ってきて効率が悪いのはわかるんだけど、それの対処として VALUES の後ろを機械的に増やすのはあまりにも不毛すぎる

あ、もうひとつ不毛な SQL 生成といえば VALUES のカッコを 100 個ぐらい並べて手動でバッチングするやつがある

HENTAI STRANDING

みんな使ってると思ってたのに意外と誰も使ってない機能として TweetDeck からしか操作できないコレクションと Steam のコレクションがある

https://twitter.com/lil_xyzw/status/1506598706224967683

:done: って打ったらイン「ドネ」シアの国旗出てきてじわじわきた

というわけでね

force push を積極的にしない理由思い出した、様々な理由で寿命が長いトピックブランチで途中にレビューが挟まったりしたときに PR のタイムラインが派手に破壊されたことがあったからだ

最初に push するまでは rebase、push したら merge master に統一してる

永遠にカメラが降りていかないのに若干の恐怖を覚える

並列処理の天才9 つの Future を操る

これはよく見つけてきたなhttps://twitter.com/lunasorcery/status/1504900067098046464

#オンゲキ 梨緒ちゃんとゲーセン - Yashinのイラスト - pixiv https://www.pixiv.net/artworks/85657054