これが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
やばいので2時間くらいサイスタをポチポチしていた模様
なおなんでそんなに時間が経ったのか記憶がない
スタミナ消費しなきゃってバレンタインイベのサイスタ開いたら担当のくそかわ絵来て心臓終わった
# Expected Behaviour
会計は1000円くらい
# Actual Behaviour
会計は2000円くらい
# Steps to Reproduce
1. とりあえず5皿くらい頼みます
2. 追加で5皿くらい頼みます
3. 調子に乗ってポテトを頼みます
4. シメと称して2皿くらい頼みます
5. 会計金額を確認します
6. 泣きます
This account is not set to public on notestock.
This account is not set to public on notestock.
あと試験は2つなんだけど明日の午後にタイミング悪い用事があって睡眠時間の配分どうしようかなになってる
𠮷野家
「マックのバーガー1000円、生ビール1000円」…月収20万円の若者「どう生きていけばいいのか」“最低月収40万円”必須な時代到来か(幻冬舎ゴールドオンライン)
#Yahooニュース
https://news.yahoo.co.jp/articles/3012d3f1c8ae99f159ff13406bff103582b45f30
This account is not set to public on notestock.
試験中に誰かがクソプログラム回してCPUクレジットが足りなくなり、サーバーが落ちて試験が続行できなくなるとかいう前代未聞の試験だった
ごみ捨てでQrio Lockに締め出されかけて心臓止まるかと思った
時計で開けられるので安全(風呂上がりなどに危険なのでマジで気をつけたほうがいい
ところで明日のOSの試験なんですが、普段課題を配布していて明日試験を実施するJupiterのクソ強サーバーが強制メンテで利用できないらしく、課題の復習はできないわ試験の実施すら怪しいわという状況になっているらしく、文明が完全敗北しています、現場からは以上です
完璧主義なので何かを作るにあたってテストもLintもCIも完璧に整備するしあちこちのドキュメントを突き合わせて仕様を確認するしIaCでデプロイする気である
真面目に解決したければエラーで調べたりとりあえずアプデしたら?って言ったりするんですけど、眠いし頭が回らん
なにも考えてないからあんまあてにしないでほしいんだけどDOCKER_BUILDKIT=1つけたら耐えたりしない?
マジで課題意識はあって解決策もちゃんと考えたんだけどあとサービスをリリースするだけってところで一生ゴールできない
うちのサーバーのルール5年前のままでさすがにふざけすぎだしAPIに出る方のruleにしてないの良くないから直すか
Railsアプリケーションのデータに干渉したいならDBに直接触る前にRails Consoleを使ったほうが5万倍幸せになれる
ローマ数字のⅢをⅠを3個で表記されてビビってるんだけど成り立ち考えたらこっちのほうが正しい?
JetBrains GatewayとHyper-VのDynamic Memoryの相性が悪すぎる
例の/dev/zeroで4GBメモリ埋めるコマンド打たなきゃ
せっかく電子書籍でいつでも購入できるのに読みもしない段階から自動購入するのは金の無駄ではなかろうかと思ってしまう
サイバーセキュリティとかいう講義は工学部共通科目のくせに工学部電気系のスケジュールをガン無視して開催するのをやめてほしい(課題の締切が試験とダダかぶりしているばかりか、集中講義ががっつり試験時間中に開催されている)
SerialNameは無条件でつけたほうがいいよ(ProGuardにオブジェクトのフィールド名をMinifyされてDBに保存してたJSONのキーがアルファベット1文字になってしまったTuskyの方を見ながら)
Tuskyのdevelop引っ張ってからタブ変更の感度が落ちてつらい rollbackしようかな
まずいまずい、なんか今日の俺の投稿すごく濃度が高いぞ
もっと頭の悪い投稿をして希釈しなければならない
Minecraftの通報機能、いくらでも偽装できるやんって話になってたけど結局まだ生きてるの?
MastodonのFilters、後方互換を考慮するとクライアントサイドでしょうもな正規表現を構築する羽目になるから頑張って欲しい
そもそもあんなクソ狭いとこじゃなくて正門前の広いファミマを使えばいいのでは?????になった
あと7時間あるし紙2~3枚くらいは書く余裕あるぞ
講義資料切り貼りして印刷するのとどっちがはやいかな
REST APIでも不可能ではない(というか狙ったオブジェクトを更新するだけなら比較的シンプル)だが、オブジェクトをネストして返されるとflattenがしんどい(たとえばstatus APIについてくるaccountオブジェクトみたいな)とか、リクエスト数が爆発するみたいな問題はやっぱり避けられないよね
全てがGraphQLの世界に落ちているとIDのUniquenessとかそれぞれが指定したNodeであることとかが保証されているのでオブジェクトをflattenしてキャッシュストアに投げ込むことが比較的容易(というか技術的に可能に近いとは思うが)
個人的にはフロントエンドがキャッシュストアを持つって言ってひいこら言いながらグローバルストアとか導入しちゃいがちなので嫌いだが、GraphQLの文脈で必要なデータを適宜fetchしてくるデータストア(+ それを読み出す側は直接APIを叩かない)は技術的に素敵だと思う(APIを無視してキャッシュストアを信頼できるデータソースとして扱えるので、透過性が満たされている)ので、そっちはやりたい
MastodonのWebUIで新規フォロワーのプロフィール開いても「フォローされています」が出ないくせにフォロー一覧には居るみたいなわけわからん状況が発生しておりシンプルにcacheが壊れてるんだろなぁと思った次第(当然リログで治る)
最近の広義フロントエンド(including モバイルアプリ)、ローカルでも適切なデータストア持ってキャッシュしろとか言われてるせいでキャッシュ不整合の解決とかだるすぎだよなぁって
起きたら24h装備してるYubiKeyくっつけてるチェーン取れててビビった
暗闇で繋ぎ直したけど
この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にどこまで信頼できる要素を見いだせるかを調査しているので、各アプリケーションが必要なレベルで実装すればいいと思ってるよ
Mastodon、publicKeyがRSAであることは要請していそうだけど鍵の情報量に制約がなさそう
Codespaces、たまにお電話が遠いと思った通りの文字が消えなかったりして絶妙にストレス
あらまぁ
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
おいRailsプロジェクト始めてまだなんも書いてないのに早速モンキーパッチが必要なのはどういうことなんだよ
Twitterモバイルアプリの読んでたとこから確実に復帰できる機能くそ便利でしょ、それと一緒
どっちかっていうとSimpleLoginのメール転送みたいにエイリアスActorを用意してやる必要がありそう
AP Actorのプロキシみたいなことができないかな〜と思ってたんですが、WebFingerで直接やると匿名化効果がなくなるので微妙だなと思いました
当然パッチを当てるのは整形前のコードなので、ここを変更すると決めたらもとのソースを改造するようにしなきゃいけない
昔minifyされたコードを整形を駆使して元のコードと照らし合わせながら解読してパッチを当てる作業をしたことがあるが、ちょっとパズルみたいで面白い