歌上手いかもしれん(ない)
For those who wants information about Yuito, subscribe my English posts only (available on account profile, Mastodon v4 or above).
くだらないこと言ってる人格は わんせた 、コード書いてる人格は kyori
呼ぶときは わせたん でもよし。たんってついてればかわいいので
Manages: https://odakyu.app https://nitiasa.com
Maintains: https://accelf.net/yuito (fork of Tusky)
when these instances down see here: @ars42525 @ars42525
Server Status: https://graph.accelf.net
何回ブリーチしたかわからん髪にパーマとか言ったらアシスタントの間で「優しく外してね」っていう指示が飛ぶクラスの特急呪物になってしまった
アクセス過多でDBが死んだのはほぼ確定、インデックスまで壊れちゃった可能性すら感じる
> バンダイナムコID障害発生につきましてBNIDのメンテナンスを行い、データベースサービスの再起動と増強対応を以下時間帯で行います。
https://twitter.com/bnidofficial/status/1668912548756992000
じゃあどうやって実装しますか?って感じなんだけど、「高い方の割引率を取る」ロジックを作るのは否定的な人も多そう
IFとしてはbox.apply(rate)を複数回呼んで最大のものがbox.resultみたいな感じで返ればよいのだが
これ言わんとしてることはわかるし考え方は嫌いじゃないんだけど、こんなものが通常の手続き型言語のコードとして書かれていたら泣いてしまう
可読性も拡張性もすべてをなげうったコードを書くんじゃない
エスイーが要件定義でやるべきたったひとつのこと(実践編) - Qiita
https://qiita.com/kawasima/items/98b5636db0172d9b5051
なぜ(Twitterの)TLにメールのプロトコルを知らんやつがまだ居るんだ…?って思ってプロフ見たら普通にエンジニアだし謎は深まるばかり
ID基盤を使うゲームが1個増えたらID基盤が壊れた→依存関係の逆転と設計ミス
普段過疎ってるID基盤に見たことない量のアクセス来て落ちた→過疎ってたのが悪い()
むしろ「Name Serverなる物があってresolveHandleを受け取ることで名前空間を定義するんだぜ~」って顔をしているのに「resolveHandleはhandleのドメインに投げるんだぜ~」って言い始めるの、設計の矛盾では?
このresolveHandleで名前解決先をHandleのドメインにしてしまうとICANNルートに依存するので、ここを別のなんらかのホストに固定すればAlternate Name Serverを使うATPソフトの出来上がり
Identity | AT Protocol | https://atproto.com/guides/identity#handle-resolution
PDSは必ずしもName serverと一致しないので、Alternate Name Serverみたいなのが生えれば良さそう
それはそれとして、BlueskyのProductionとStagingはそのうちName Serverが統合されてどっちかが捨てられることになりそう
AT Protocol | AT Protocol | https://atproto.com/specs/atp#glossary