のえる @noellabo@fedibird.com

@tell_me_fedi_jp たしかBridgy Fedっていうか、ATprotoの仕様で _ をハンドルに使えないために、MastodonやMisskeyの名前に _ を含む場合 - に変換するって話がありました。
https://atproto.com/ja/specs/handle

これ、実際のところ、どう対応すればいいんでしたっけ？
QT: https://fedibird.com/@gimlet_202407/113626799925085032 [参照]

たとえばMastodonについて何かライトニングトークやってって言われたら、5分なら、まぁやってもいいよって即答できるけど、15分喋れとか言われるとそれなりに準備が要るよね。

ちなみに私の基準はスライド1枚1分。

なお、機械翻訳は、逆方向に翻訳して確認するのは必ずやってる。日本語→英語なら、結果の英語→日本語を試すということ。

ここでだいたい一致するのが、いい原文。

Google翻訳にしろ、DeepLにしろ、翻訳し易い原文を与えると翻訳結果が正確で綺麗になるので、そういう工夫は私もずっとしてきた。

生成AIも、そういうのが上手な人が、上手な結果を得てるんだろうね。

パソコンサンデーのおじさん

真顔

支給されるときはボーアリ（？？）

stautsesのdirect visibilityのtextだけ暗号化して保存しといて、使うタイミングでデコードするコードも書けるから、そういうのは一応やる可能性あるけど……実際のところどうかな……。

class Account < ApplicationRecord
encrypts :private_key
end

Railsのコード的にはこれだけだしね。あとは透過的に処理されるので。

暗号フィールドを含むモデルを、同一構造の暗号フィールドじゃない版のモデルにコピーするコード書いて、railsで一回走らせればええんやないかな。そしたら、あとはPostgreSQLレベルで対応できるようになる。

あと、いま検討してる設計でも、暗号フィールドを含むフィールドを別モデルに切り出して小さくしようとしてる。

accountsから秘密鍵などだけ別テーブルに抜き出すとかね。

使わないときにデコードのコストを掛けたくないわけ。

ACTIVE_RECORD_ENCRYPTION_PRIMARY_KEY
ACTIVE_RECORD_ENCRYPTION_DETERMINISTIC_KEY
ACTIVE_RECORD_ENCRYPTION_KEY_DERIVATION_SALT

の3つを定義するようになるので、このキーを失わないようにしておくこと。

パフォーマンスの面からも、全部のフィールドを暗号化するつもりは全然ないので、その点ではあまり心配は要らないと思う。

アカウントの秘密鍵とか機密性の高いものが対象で、適用対象は限られるじゃないかな。

ちょっと設定反映のためにWebプロセス再起動したよ #fedibird #fedibird_info

寒すぎてオポッサムになった [参照]

冷静に考えると、寒すぎて死んだふりするってことだな……

いま一番新しいIllustratorでさ、昔のファイル開くとさ、こういうダイアログ出るんだけどさ、

デフォルトボタンがOKになってるから、エンター押すじゃん？

……キャンセルされるんよ。

（スペースキーとか叩くとOKになる）

たおしても、たおしても、無限に蘇るかのように見える敵（広告）

たぶん、主人公が秘密を見抜いて撃破する

ゲームサントラCDのSEが延々流れるやつ