This account is not set to public on notestock.

きたきたきた

ほんまに Tradz 皿でわろとる

1 点差で打ち返したかあ うますぎる

レギュラーステージ、僕でも手が届く範囲の譜面が出てきてピッカピカなので ☆12 の対戦とかとはまた違う面白さがある

KKM 光りすぎ

【BPL S3 IIDX】レギュラーステージ1st 第3試合 TAITO STATION Tradz vs SUPERNOVA Tohoku / 第4試合 GAME PANIC vs ROUND1 - YouTube
https://www.youtube.com/watch?v=V7UjhCAntCQ

そういえば Vket の個人ブースで半透明表現にディザリング使ってるところがあってお～となった

帯域が太かったおかげで半透明重ねまくる表現が使いやすかったみたいな話もあるらしい

逆に机の狭さを異常な廊下の太さでねじ伏せていた PS2

よくあるデスクの例えを引くなら廊下が狭すぎてデスクのデカさと本人の手腕が発揮できないカスの職場……

平均 FPS は 3060 (12GB) のがマシみたいになってもおかしくない気はする

1 日内で 4 回も言ってるのはギルティー

Baqeela

鳥

逆に不透明肌ってなんだろうと考えたときに最初に出てきたのがビッグボーイの人形だった

透明肌 (subsurface scattering の強度が高いマテリアルの俗称)

Vket 水族館のワールドが MSAA の倍率で重くなる説あとでちょっと検証してみたいな(普段 x2 でプレイしてる)

現状の StringLoader/ImageLoader の使用だとビルド時の固定 URL かユーザーに UI で入力させた値しか使えなかった気がする

さっきの BT のやつで思い出したけど Vket のワールド設定が保存されてるやつどうやって設定値を送信してるんだろう

This account is not set to public on notestock.

そんなタイムリーなことある？？ちゅってる
https://twitter.com/chunithm/status/1681136944141721600

mzp さん 10 点フルトラに！？

ZAKOTEMPO、バーチャルセラピー地帯はギアチェンと一緒にサドプラ下げたほうが見やすいかもしれん

jpg→png はだいたいデカくなりがちだけど png→jpg でも画像のパターンによってはデカくなりそう

アルファベット順が飛びすぎな workspace dependencies 見て

proc macro がやってたの！？

個人的に diesel はちょっとガチガチすぎる(あと昔静的解析とちょっと相性が悪かった)かなという思いがあるので sea-query の使い勝手はけっこう気になってる

sea-orm のクエリビルダ単体

それで僕がちょくちょく言及してるのが sea-query です
SeaQL/sea-query: 🔱 A dynamic SQL query builder for MySQL, Postgres and SQLite
https://github.com/SeaQL/sea-query#table-create

安全なクエリビルダと結果行を構造体にマッピングしてくれるやつだけがあればええ(？)

これ

SQLite は単一ファイルに保存されて組み込み向けっぽい割に SQL の準拠度自体は高い(内部的に INT REAL BLOB TEXT だけになるとかカラムの削除ができないとかはあるけど)

まあ SQLite & Postgres vs チーム "M" みたいなところはある

識別子のクォートからして違うのでほぼ無です

ので無難に up/down を書いて最後のマイグレーション時刻を DB 側に保存しておくやつが一番好きだったりする

DSL でテーブル定義とか書くと現在の定義と比較して自動でマイグレーション SQL 発行してくれるやつ自体はあるけど language-specific 度が高いし事故が怖い

stats を充実させたいので周辺情報は多めに持っておきたい感がある

インデックスの張り直し、やることはできてもやらんですむならやりたくない作業の筆頭

domains (domain PRIMARY KEY) と users の domain REFERENCES domains (domain) にした上で (username, domain) で張ればよさそうかなあ

domains テーブル作るのを考えると別に users 側で難しいこと考えなくてもいいなとなった(？)

domains テーブルを作ることがすっかり頭から抜け落ちていた

確かに(確かに)

あとストレージ上で連続だとうれしいのはどっちかと言われるとドメインな気もするんだよねえ……難しい

username の方が cardinality が高いは確かにそうで、username による range が小さくなるので 2 段目の検索は速くなりそう

別に両方張っちゃっても良い気もするけどインデックスデータそこそこ食うのでできれば冗長じゃない方がうれしい。散弾銃にならないので

これも一理ある気がしてきたな(なんもわからん)

ドメイン内全ユーザーに対する操作をやるときにこのインデックスが活用できるはずなので

users テーブルで acct にインデックス張るとき (username, domain) じゃなくて (domain, username) の方が後々便利な気がしてきたな

あの OP もそのうち通じなくなってしまうんだなあ

Vket のブースのギミックで水平軸のハンドルを回すのが出てきて思わず金曜ロードショーのテーマを口ずさんでしまった

昨日コメダ行ったら長靴グラス売っててちょっとほしくなった