これがoverwatchの闇
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
# Expected Behaviour
会計は1000円くらい
# Actual Behaviour
会計は2000円くらい
# Steps to Reproduce
1. とりあえず5皿くらい頼みます
2. 追加で5皿くらい頼みます
3. 調子に乗ってポテトを頼みます
4. シメと称して2皿くらい頼みます
5. 会計金額を確認します
6. 泣きます
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
𠮷野家
「マックのバーガー1000円、生ビール1000円」…月収20万円の若者「どう生きていけばいいのか」“最低月収40万円”必須な時代到来か(幻冬舎ゴールドオンライン)
#Yahooニュース
https://news.yahoo.co.jp/articles/3012d3f1c8ae99f159ff13406bff103582b45f30
このアカウントは、notestockで公開設定になっていません。
試験中に誰かがクソプログラム回してCPUクレジットが足りなくなり、サーバーが落ちて試験が続行できなくなるとかいう前代未聞の試験だった
ごみ捨てでQrio Lockに締め出されかけて心臓止まるかと思った
時計で開けられるので安全(風呂上がりなどに危険なのでマジで気をつけたほうがいい
ところで明日のOSの試験なんですが、普段課題を配布していて明日試験を実施するJupiterのクソ強サーバーが強制メンテで利用できないらしく、課題の復習はできないわ試験の実施すら怪しいわという状況になっているらしく、文明が完全敗北しています、現場からは以上です
完璧主義なので何かを作るにあたってテストもLintもCIも完璧に整備するしあちこちのドキュメントを突き合わせて仕様を確認するしIaCでデプロイする気である
なにも考えてないからあんまあてにしないでほしいんだけどDOCKER_BUILDKIT=1つけたら耐えたりしない?
マジで課題意識はあって解決策もちゃんと考えたんだけどあとサービスをリリースするだけってところで一生ゴールできない
うちのサーバーのルール5年前のままでさすがにふざけすぎだしAPIに出る方のruleにしてないの良くないから直すか
Railsアプリケーションのデータに干渉したいならDBに直接触る前にRails Consoleを使ったほうが5万倍幸せになれる
JetBrains GatewayとHyper-VのDynamic Memoryの相性が悪すぎる
例の/dev/zeroで4GBメモリ埋めるコマンド打たなきゃ
せっかく電子書籍でいつでも購入できるのに読みもしない段階から自動購入するのは金の無駄ではなかろうかと思ってしまう
サイバーセキュリティとかいう講義は工学部共通科目のくせに工学部電気系のスケジュールをガン無視して開催するのをやめてほしい(課題の締切が試験とダダかぶりしているばかりか、集中講義ががっつり試験時間中に開催されている)
SerialNameは無条件でつけたほうがいいよ(ProGuardにオブジェクトのフィールド名をMinifyされてDBに保存してたJSONのキーがアルファベット1文字になってしまったTuskyの方を見ながら)
MastodonのFilters、後方互換を考慮するとクライアントサイドでしょうもな正規表現を構築する羽目になるから頑張って欲しい
REST APIでも不可能ではない(というか狙ったオブジェクトを更新するだけなら比較的シンプル)だが、オブジェクトをネストして返されるとflattenがしんどい(たとえばstatus APIについてくるaccountオブジェクトみたいな)とか、リクエスト数が爆発するみたいな問題はやっぱり避けられないよね
全てがGraphQLの世界に落ちているとIDのUniquenessとかそれぞれが指定したNodeであることとかが保証されているのでオブジェクトをflattenしてキャッシュストアに投げ込むことが比較的容易(というか技術的に可能に近いとは思うが)
個人的にはフロントエンドがキャッシュストアを持つって言ってひいこら言いながらグローバルストアとか導入しちゃいがちなので嫌いだが、GraphQLの文脈で必要なデータを適宜fetchしてくるデータストア(+ それを読み出す側は直接APIを叩かない)は技術的に素敵だと思う(APIを無視してキャッシュストアを信頼できるデータソースとして扱えるので、透過性が満たされている)ので、そっちはやりたい
MastodonのWebUIで新規フォロワーのプロフィール開いても「フォローされています」が出ないくせにフォロー一覧には居るみたいなわけわからん状況が発生しておりシンプルにcacheが壊れてるんだろなぁと思った次第(当然リログで治る)
最近の広義フロントエンド(including モバイルアプリ)、ローカルでも適切なデータストア持ってキャッシュしろとか言われてるせいでキャッシュ不整合の解決とかだるすぎだよなぁって
このPRで「ActivityPub implementations will use the account or public key URI as keyId in the signature instead of the acct: URI」という記述があるのだが、なんでActivityPub代表ヅラしてるのかはよくわからない
どっかに文脈があるのだろうか
Add Digest header to requests with body, handle acct and URI keyId by Gargron · Pull Request #4565 · mastodon/mastodon | https://github.com/mastodon/mastodon/pull/4565
HTTP Signatureですらないんだよな、Draftとはいえ
Mastodonが「参考にしたよ!」って言ってるHTTP SignatureではkeyIdは鍵のFingerPrintなどでもよいということになっているが、MastodonはkeyIdがActorのURI(かacct)じゃないとダメ
それはそう
このオレオレHTTP Signatureにどこまで信頼できる要素を見いだせるかを調査しているので、各アプリケーションが必要なレベルで実装すればいいと思ってるよ
あらまぁ
Diff: draft-cavage-http-signatures-06.txt - draft-cavage-http-signatures-12.txt | https://author-tools.ietf.org/iddiff?url1=draft-cavage-http-signatures-06&url2=draft-cavage-http-signatures-12&difftype=--html
というわけでActivityPub-correctnessを尊重するAPを実装するなら自分はpreferredUsernameをuniqueにしながら対外的にはpreferredUsernameのuniqueを強制しない必要があるね
ActivityPubの仕様だとpreferredUsernameはnot uniqueかつOptionalなフィールドなんだけど、acct使ってWebFingerを引く前提だと@preferredUsername@domainをユニークにする必要があるのでpreferredUsernameを重複させられない
MastodonはpreferredUsernameの存在を強制してる(fetch_remote_actor_service.rb#31)んだけど、そもそもWebFingerを全面的に信頼する挙動になってるのでpreferredUsernameをつけない理由がない
これ一つもNiceな要素がなくて泣ける
https://github.com/rails/jbuilder/issues/139#issuecomment-22925138
どっちかっていうとSimpleLoginのメール転送みたいにエイリアスActorを用意してやる必要がありそう
AP Actorのプロキシみたいなことができないかな〜と思ってたんですが、WebFingerで直接やると匿名化効果がなくなるので微妙だなと思いました
当然パッチを当てるのは整形前のコードなので、ここを変更すると決めたらもとのソースを改造するようにしなきゃいけない
昔minifyされたコードを整形を駆使して元のコードと照らし合わせながら解読してパッチを当てる作業をしたことがあるが、ちょっとパズルみたいで面白い