Notices by KOMIYA Atsushi (komiya_atsushi@mastodon.cloud)

Web サービスのステータスページの存在を有難がるの、エンジニアか IT リテラシー高い人たちだけなんだろうな。ごく一般のユーザはステータスページの存在すら知らないだろうし。

機械学習とか扱うエンジニアを「アルゴリズムエンジニア」という表記で出されている求人をみるとちょっともにょる。

配給された Bluesky の招待コードを他の人に提供する前に2つ目の招待コードが配給されてしまった。

図らずもインバウンド銘柄を長期保有していたがために評価益がおめでたいことになってた。

X の収益化のしくみがよくわかっていないけど、見たくもない投稿が repost されてきてインプレッションしてしまった挙句にその投稿をした人に収益がいくことになると、もはや read-only で X を使うのも止めようという気になる。

日本人はなぜ、何でもカタカナ語句をを４文字に短縮しようとするのか。聞き慣れない、一般的ではない４文字略語が飛び交う環境はなかなかアレ。

ユーザーストーリーでも要件でもどちらでもいいんだけど、統一感のある書き方でかつ MECE に列挙する、というのは意識していないとなかなかできないものなのかな。

@tkihira 僕も jsperf で雑に比較をしていましたが、比較の仕方がよくなかったのか、除算と BigInt + 右シフトの結果に差が出ていませんでした。ベンチマーク難しい…

@hydrakecat ですです。厳密に速度を計測したわけではないのと、あと普通に使う分にはたぶんこの実装で十分な気はしていますが、ちょっと速くできそうな余地があったので再発明してみようかな、と思ったのでした。

なお Base 32 エンコードを (10 ビット消費して) 一度に 2 文字ずつテーブルルックアップで変換する方法を雑に実装して jsperf で速度を比較してみましたが、これは L2 キャッシュに載らなくなるせいか、2 倍ぐらい遅い結果になりました 😇

@hydrakecat 具体的な話をしてしまうと ULID を JS で実装（車輪の再発明）しようとしていて、ミリ秒の時刻 (これは 48 ビット) や 80 ビットの乱数列（40 ビットに分割して 2 つの数値で表現する想定）を Base 32 エンコードするときに右ビットシフト＆ビット AND で処理しようとしたのがきっかけの話題でした。

BigInt を使うという手も考えたが、BigInt は任意精度の整数みたいなので（もしかしたら処理系によっては 2^64 以下の数値の場合に最適化された実装がなされているかもしれないけどそのあたりがいまいち読めないので）パフォーマンスが気になってしまう。