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

どっかのサイトは「そういう専用ツールを入れなくても」みたいなのが「容易かどうか」の基準として書いてあった気がする

満員電車ですぐに下ろせるとか……？

トイレとかにある緑色のソープが出てくるやつ、非接触になってくれねえかなあという思いとコスト的に無理そうだよなあという諦観がある

あんなゆるふわなのにゆるふわだとめっちゃ困りそうな数値計算とかでまあまあ使われてるの奇跡だろ

主体が Chat だからじゃない？

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

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 のタイムラインが派手に破壊されたことがあったからだ