This account is not set to public on notestock.

PC (アイドル) + PC (3Dゲーム中) + 電気ケトル (初期沸騰中) + 加湿器 (定常稼動) + 電気ヒーター (強度2/11) + NAS (ディスク5台に強負荷)
#circuit_breaker_challenge_failed

ちなみにこれも契約ブレーカーではなく部屋の方

あーあ、 5 TB のボリュームの移動が進行していたのに停電による電源断でキャンセルされたので最初からやり直しだよ

マジでラックとかの前に UPS 調達せねばという気持ちになってきた

This account is not set to public on notestock.

じゃあ \verb|foo| とか \verb*|bar| とかなら満足なんか？？ あァん！！？？

突然キレる人こわ

そういえばクォート系を2つ連続させるとエスケープになる ("foo""bar" が "foo\"bar" 相当になる) 言語、近年ではあまり発生してない気がする。 "" が見辛いからか？ (適当)

私からすぐに出せる例は XPath くらいしかないです……

Nor,Mitsukiyo,KARUT / Blue Archive Original Soundtrack Vol.3 ～Reaching for the precious time～ - OTOTOY
https://ototoy.jp/_/default/p/1513867 #ブルアカ

This account is not set to public on notestock.

waffle……

:wafflewaffle:

老人は平成に帰ってもろて

2ディスク破壊に耐える RAID 実はあまり要らなくない？ みたいな考えを振り切って2ディスク冗長な構成へと切り替えているが、まあなんというか弊家で一番多い障害はブレーカー遮断による停電なのでそのうち全 HDD が同時に死にそうな気さえする #homelab

オフサイトバックアップとりたいね。
そのうち6ベイの NAS 買って実家に置かせてもらうか。リモート管理できるから年に二度程度の帰省でも十分にメンテナンスできるだろうし

Amazon.co.jp: Synology NASキット 6ベイ 拡張可 DS1621+ クアッドコアCPU 4GBメモリ搭載 スタンダードユーザー向け 国内正規代理店品 電話サポート対応品 DiskStation : パソコン・周辺機器
https://www.amazon.co.jp/dp/B08HYQJJ62/

しかしなぁ。 -5% で131k円、そのうえ HDD は別料金。うーん……

TOSHIBA 東芝 MG07ACA12TE/JP [3.5インチ内蔵HDD / 12TB / 7200rpm / MGシリーズ / 国内サポート対応]｜TSUKUMO公式通販サイト
https://shop.tsukumo.co.jp/goods/4580376101939/

一番安い TOSHI_A でも33.8k円、これを4つとしても135.2k円。うーん……

Amazon | 【NAS用拡張ユニット】Synology DX517 [5ベイ / SATA対応/Synology DiskStation専用] | Synology | パソコン・周辺機器 通販
https://www.amazon.co.jp/dp/B06Y4J9GR8

DX517 (5ベイ拡張ユニット) も欲しいんですよね。日本だと入手性が異常に悪いけど、だいたい安いときを狙えば60k円でいける

しかしなぁ。たかが5ベイで独立したサーバとしても使えないような拡張ユニットで60k円かけるくらいなら、いっそ今の8ベイのやつをバックアップ機にまわして本命の NAS をラックマウント可能でベイの多いやつにした方が QoL 上がりそうなんだよな。

しかしラックマウントで12ベイ (かつ12ベイ拡張ユニット対応) の RackStation RS2421+ はネット最安で326k円。これはちょっと手が届かない。

価格.com - Synology RackStation RS2421+ 価格比較
https://kakaku.com/item/K0001434796/

じゃあラックマウントを諦めるとどうかというと、箱型の DiskStation 2422+ (12ベイ、12ベイ拡張ユニット対応) が尼で308k円。 RS2421+ (ラックマウント) と18k円 (HDD 1台未満) しか変わらないのであれば絶対ラックマウントの方にするよね。設置と管理が圧倒的に楽だろうし。

Amazon.co.jp: Synology NASキット 12ベイ 拡張可 DS2422+ クアッドコアCPU 4GBメモリ搭載 国内正規代理店品 電話サポート対応品 DiskStation : パソコン・周辺機器
https://www.amazon.co.jp/dp/B09JNRPK2Z/

実家に置くのはどうなったんだよという話に戻ると、4ベイだと2ディスク冗長化したが最期ホットスペアの設定やプール拡張が大層面倒になるし、バックアップする必要がないのをさておくとしても、3ディスクのプールに拡張の余地とホットスワップを考えるとどうしても4ベイでは何かを諦める必要があるので、ちょっとなぁ。

自宅にあるのであれば外部ディスクとか 10GbE LAN 経由で別マシンに一時的に対比してプール削除からの作り直し……みたいな荒技もできるけど、実家で帰省頻度が低いとなると、できるだけ「玉を詰めといて放置、何かあっても事前準備だけで対応」で済ませたい

小さな守備範囲のことをうまくやってほしいし、そのうえで連携しやすければそれで十分という考えなので、何が何でも fediverse サーバの機能だけで人を探そうみたいな感じではないなぁ (個人の感想)。
むろん fediverse 内で完結する形でユーザ発見チャンスが増えるならそれはそれで良いことだし、そのために文脈の RT とかは積極的にした方が良いとは思ってるけど

何でもできるサービス、ひとつの許せない欠点があるだけで他の分離可能な全てまで一緒に台無しになるのでユーザとしても有り難くない

本当はゲームプレイの動画や写真とかも mastodon とは別のサーバから投げたいんですけどね。環境とリソースがまだ整備しきれてないから妥協してるだけで。

そのうち自分用に PeerTube か PixelFed を立てるんじゃないかと思う。具体的なスケジュールは未定だけど。そもそもあれ一人用で立てることを想定してるのかも知らんけど……

Mastodon から動画を投稿するの、専門のサービスに比べて明らかに体験が良くない。できるにゃできるけれども……

なんか他サーバの動画のキャッシングが云々みたいな説明を読んだ覚えがあって、 web クライアントとしての機能が結構重たいのではないだろうかという気持ちになっているのよね……

自分発の動画のエンコードにリソースが必要なのは本質的なコスト負担だから致し方ないとして。

まあ本当に立てるとなったら改めて調べると思うけど。
現状だと全然外出や旅行しないので、写真よりは動画の方が上げるもの多いんだよな多分

PS4/5 に放置してある動画とかもちゃんと NAS 側に移したいし、そもそも PC でのゲームプレイも録画したいし (せっかく GPU に余裕あるんだから)、そういうことを考えているとやっぱり NAS を強くしたくなるんですねぇ…… (そして話題が戻る)

This account is not set to public on notestock.

SQLite の “強さ”、定性的な話はいろいろ聞くけどマルチスレッド性能どうなんだとか実運用でどのくらいから問題になってくるんだとか、そういう定量的なデータを実は持っていないのでどうなんだろうという気持ちがいつもある

たとえば Redmine だか Nextcloud だかが SQLite バックエンドに対応していた気もするけど「開発・テスト用であってパフォーマンスとかスケールの問題が発生しやすいからプロダクションで使わないでね」みたいな警告が当然のように出ていた気がする

それだって何ユーザ/何クライアント/何セッション同時から問題が見えてくるのかとか、どういう壊れ方をするのか (DB 破壊ということはないだろうけど、ライブロックみたいなことになるのか、パフォーマンス異常低下時に強制終了時すると DB 側で保証していないアプリレベルの整合性に問題が出るとかなのか、とか) そういうのが何もわからん。
端的に言って、個人用であれ並列、並行、増大し続けるデータ、みたいなのを真面目に扱わないといけない web サービス用途における真面目な評価を見たことがない気がするし実験したこともない

謎すぎて草。「編集」とかかな？

This account is not set to public on notestock.

あー、フロントエンドを増やして負荷分散したことないから完全に忘れてたけどそういえばそうか

どうせ個人でやっていると DB もフロントエンドも1対1でどうにかなってしまうので忘れがちだが、そういえば DB は web アプリから分離して外に出せるのだった

https://mastodon.cardina1.red/@lo48576/109674802659120416

そういえばこれ最近私が知って驚いたやつです。特定のテーブルでカラムのを型遵守するよう強制する機能。
最後に真面目に触ったときに入ってなかったので気付かなかった

https://mastodon.cardina1.red/@lo48576/103278042934481518

「気付いたら RDB に入ってた機能」シリーズ、他の例としては「気付いたら MySQL/MariaDB が WITH RECURSIVE 対応してた (Postgres と SQLite は既に対応していた (はず))」などもある

This account is not set to public on notestock.

㍂

まあ個人でやる (bot があるとしても大した活動量ではない) みたいな場合は書き込みでロックがかかろうが大したことはないといえばないか。制約と用途がいい感じにマッチしてる用法っぽいな

JSON-LD はマジで地獄だからなぁ……

読めるのと書けるのと書いてもいいのと書きたいのはそれぞれ違うレベルで、「手元で弄れるしバグっても自分でどうにかするから使ったれ！」となるのは「書いてもいい」のレベルからかな

C/C++ とかはあまり書きたくはないがまだ一応書いてもいい枠には入っている (何故なら鉞ブーメランで鍛えた貯金が残っているので C++17 までならまあまあ使える)

20以降はもうわからん。「modern C++ で concept と coroutine と modules 存分に使います！」みたいなアプリやライブラリが出てきたら「バグってても自前でワークアラウンドできる枠」には入れられないなぁ……

Python はアセンブリ言語と同レベルで “読める” (読めるだけで高レベルな解釈ができるとは言ってない) けど、じゃあそれで手元のコードがバグってたからといって自分で直したいかというと絶対嫌なので Python 製のものは多言語の代替があったらそっちに加点してしまう傾向がある (なお競合が PHP の場合は)

原理主義者なので Rust で ActivityPub するためにまず JSON-LD のライブラリを作りかけたが、あれ本当に最悪体験だったのでもうやりたくない

消してないコードがどこかに残ってるかもしれん (万が一再開する破目になったとしても async とかエラー処理まわりの言語規格やエコシステムが進歩しているので最初から書き直すと思う)

まあそもそも「スキーマを実行時に与えてバリデートします」みたいなの本質的に動的型付けなので、静的型付き言語使っても全然旨味がないのよね。少なくともバリデート部分の近辺では。

XML Schema とか RDF あたりもたぶん似たような理由で実装がキツい

その点動的型付きスクリプト言語だと「スキーマが期待通りでなかったら例外送出」みたいなのはそもそも言語ランタイムがやってくれることので、そりゃ実装楽にもなるわな

むしろよく go でできてるなという感想 (いやちゃんとやってないのかもしれんが)

実際 pure ActivityStreams 2 語彙だけならどうとでもなるんだけど (むしろその範囲に限定するなら静的型付き言語の方が performant だろうけど)、 JSON-LD で任意の拡張ぶっ挿せますみたいなのマジでどうすんだ。
アプリなら「知らん！非対応！無視！！」で済むが、ライブラリでそれやるわけにはいかんでしょ…… (やるのか？)

This account is not set to public on notestock.

あれハッシュタグ付けてくれという感想しかない (それをしづらいクライアントしかないのが残念というのは、まあそう)

アニメ実況用twitterクライアント「グローバル理工兄弟」 : 東京工業大学 ロボット技術研究会
http://titech-ssr.blog.jp/archives/1010471361.html

その昔、実況用ハッシュタグを付けて実況する専用のﾂｲｯﾃクライアントを開発したオタクがいてですね

グローバル人材育成推進支援室 | グローバル理工人育成コース Global Scientists and Engineers Course
http://www.ghrd.titech.ac.jp/

グローバル理工人とかいう面白フレーズまじでさぁ

その normalization とか expand とかの部分が一番「この値は配列か文字列やでw」とか「こっちは逆引きしてグラフ作ってなw」とかカオスが噴出してダルい部分なので、その部分をちゃんとライブラリとして括り出すのが静的言語ではただひたすら辛いのかもしれんなと (まあ動的言語でもつらいだろうが)

逆に語彙と構造が既知なものを静的な型に落とし込む場合には静的型付き言語には型情報を利用したコード生成とかでだいぶ楽できる部分があるので、むしろ JSON-LD や AP はライブラリとして切り出さない方が綺麗で高速でメンテしやすいコードになるはず

はず、なんだけど、問題は AP が拡張として「JSON-LD で何でもできるから JSON-LD に従って解釈してね」という JSON-LD フルセット持ち込みを許している点で、そのせいで結局 AP をライブラリとして分離しようがすまいが JSON-LD フルセット処理系は必要になってしまう

アルゴリズムいくつあるんだっけ。昔書こうとしたときは expansion から始めたし、たぶん読み込み用に正規化するだけならそれで十分なんだろうな (知らんけど)

expansion, compaction, flattening, あとは RDF との変換か。
で、それらが context processing algorithm を必要としていて、あーあー思い出してきたぞ……

lo48576/json-ld: [UNMAINTAINED] JSON-LD 1.1 implementation in Rust.
https://github.com/lo48576/json-ld

とりあえず供養。どこまで書けてたんだろう

JSON-LD Test Suite
https://w3c.github.io/json-ld-api/tests/

たぶん test suite を回してバグ取りする段階までは行ってた気がするんだよな。それが context processing のテストのつもりだったか expansion のテストのつもりだったかはもう思い出せないけど。

どうやらテスト用のリポジトリは別で用意していてｱｯﾋﾟﾛｰﾄﾞしなかったらしいな

もう unmaintained なリポジトリは zip か tar で固めてしまったから、ファイル検索してもすぐには出てこないや

規格のアルゴリズムが自然言語で書かれていて、努力は認めるけどだいぶ曖昧じゃんという部分が沢山あって……みたいな朧げな思い出が甦ってきてつらくなった

まあ Rust も future とか async とか入ってきたし TryFrom/TryInto も入ってるし、ここらで本当に見切りをつけるか決める最後の挑戦としてもう一度実装してみても……いいのかなぁ

先が長い

実装眺めてたけど expansion が CURIEs の処理くらいしか書かれてないし、たぶんこれ context processing algorithm のテスト通そうとしているところで力尽きたやつだな。たぶん規格が曖昧でテストの失敗ケースから無限に本来の意図を読み取る作業が続いてモチベなくしたんだろう

https://github.com/lo48576/json-ld/blob/24a17f6ef1ceeb1c9b68014959011028417bbffe/src/context.rs#L195-L199

https://github.com/w3c/json-ld-api/pull/208/commits/84de0358e1ce134520b5fd8eeb5102abea794e19

https://github.com/lo48576/json-ld/commit/758a17df1bf64f9ef327b55c44452e7cccde6ae7

実装中に「なんやこれアルゴリズム概要説明で事前に明示されてなかった情報が勝手に後から必要とされとるやんけ！ 関数シグネチャ変更祭りじゃ！！！」となった痕跡を見て全てを鮮明に思い出した

ほんまそういうとこやぞ。

こんな多重の後出し (事前に説明されてないのに詳細ステップ中で勝手に参照する後出しデータ依存、実装してたら規格が勝手に更新されて依存が追加される後出し規格) 食らったら、そりゃ諦めるよな……

まあ当時たぶんドラフトだった JSON-LD 1.1 をやめて 1.0 の実装しろよという話もあるだろうけど、そうはいかなかったんですよね。いろいろ差がありすぎて 1.0 実装を 1.1 に更新するのはあまりにオーバーヘッドの見積がデカすぎて許容できなかった

This account is not set to public on notestock.

たぶんいま Rust で AP サーバを作って動かすことを第一目標に据えるなら、「拡張は知らない語彙に限らず特定の構文以外は無視すると固く決意して、既存実装が吐き出しうる JSON 構造だけをサポートする」という方向が一番正しいと思う

JSON-LD は同じ論理的構造を複数の構文的構造で書けるけど、そこを割り切って特定の構文構造のみをサポートする、それ以外は未知として無視する、という強い決意が必要。

まあ悪意あるサーバやクライアントが「特定の構文では処理されるが別の構文では無視されるような語彙を使ってデータ保持や検査やサーバ間での解釈に不整合を発生させる」みたいな攻撃をすることは十分考えられるけど……

↑と、ここまで書いて思ったけど似たような話既にあったよね？

https://mastodon.cardina1.red/@lo48576/102707276281574752

追加の思い出しがあった。
JSON-LD framing algorithm で「特定の構文的構造に変換する」みたいなアルゴリズムが定義されてるのでこれを使うと特定の構造体へと汎用ライブラリでデシリアライズ可能な JSON に変換したりできるんだけど、肝心の framing algorithm の実装に expansion が必要なので結局作業量は減りませんでした、みたいなオチ

https://mastodon.cardina1.red/@lo48576/102128335182378754

爆笑してる

https://qiita.com/yut_arrows/items/16749e02313109071338

> 41以上 やばいやつ。テスト不可能

つらい話はいくらでもできるんだけど、このままだと負け犬の遠吠えなのでちゃんと “勝ちたい” んだよな。クソがクソであることを知り尽くしたうえで貶したい (いやだ……)

俺たちが C や C++ の鉞を投げるとき礼儀正しくやっていたのと、同じことを、 JSON-LD に……うぅ……ウンコ食いたくねえ……

https://mastodon.cardina1.red/@lo48576/101263261736807372

This account is not set to public on notestock.

「GMail 使っても Yahoo! メール使っても au のメール使ってもメール送れるしメルマガ読めるでしょ」くらいでいいと思っている

その中でも、メール送ったら短文 SNS に投稿されるサービスや、写真添付メール送ったらギャラリーに追加されるサービスや、メール送ったらブログ記事になるサービスがあるだけ。

This account is not set to public on notestock.

まあもうメルマガって時代でもないのかねぇ (TL のオタクどもは DLsite やニジエから愉快なタイトルのメールをしばしば受け取っているようだが (?))

「メーリングリスト」は本格的に Slack とか LINE とか Discourse とかにシェアを奪われてしまっていて、もはや古くからある集団に残っているものくらいしかなさそうという印象はある

メルマガは……たぶん実はまだ結構ある。迷惑メールの代名詞だと思われてるかもしれないけど。

近年のサービスはちゃんとメールマガジンをオプトアウトできる……もとい、私はオプトアウトできそうな行儀の良いサービスしか使わないようにしているので、メルマガにそんなに悪印象はないんだよな

私にとって迷惑メールというのは qq.com やそのサーバ経由で独自ドメインとして発射されたメールや、 amazon や楽天等を名乗っているもののヘッダを見ると明らかに駄目な感じのメールとか、そういうやつ

さておき、 follow というのもやっぱり feed 時代まで遡れば subscribe だし、それはメルマガでやってたことなんだよな……と。まずは言葉のマッピングを丁寧にやっていくのが実は良いのだろうか？

This account is not set to public on notestock.

エア鯖とかプレ鯖とか？

それもそれでどうなんだ感あるが

This account is not set to public on notestock.

This account is not set to public on notestock.

This account is not set to public on notestock.

This account is not set to public on notestock.

DS2422+ Drive Compatibility : synology
https://www.reddit.com/r/synology/comments/r2sztb/ds2422_drive_compatibility/

Thinking I need to return my RS2421+ : synology
https://www.reddit.com/r/synology/comments/oc2bac/thinking_i_need_to_return_my_rs2421/

DS2422+ と RS2421+、ヤバすぎる話があるので論外っぽいな。やめよう。

「互換性リスト」にない HDD については警告を出す (←まだわかる)、シリアル番号や温度や S.M.A.R.T. 情報が一切確認できない(←そうはならんやろ)、などの扱いをしているらしく、 NAS でバッドセクタカウントや温度を確認できないなんてのは普通に致命傷なので実質的なベンダーロックインだと騒がれてる。なにせ互換性リストにある HDD はほとんどが Synology 製で、そうでないものは WD の UltraStar (4 TB) しかない始末。
以下は DS2422+ のリンク:

互換性リスト | Synology Inc.
https://www.synology.com/ja-jp/compatibility?search_by=products&model=DS2422%2B&category=hdds_no_ssd_trim&p=1&change_log_p=1

いやぁガッカリですわ

DS1821+ + DX517×2 で粘るか、それとも QNAP か NETGEAR のやつを使うか。ぶっちゃけ CPU つきで12ベイほしいので後者に気持ちが傾いている (拡張ユニットではなく本体を買えば、余った本体を実家に置けるため)

Synology Confirms Vendor Lock coming to Plus Series - Starting with DS2422+ : HomeNAS
https://www.reddit.com/r/HomeNAS/comments/qx27bz/synology_confirms_vendor_lock_coming_to_plus/

一応この改悪が入っているのは "12-bay plus-series model used by a lot of SMB and corporate users" な market segment だけっぽい雰囲気もあるんだが (実際事例として上がってる RS2421+ も DS2422+ も12ベイの plus シリーズ)、そうは言っても……その姿勢自体が既に……ねぇ……と

ワイの手元にある DS1821+ (8ベイ) はとりあえずそういうアカン挙動はしてないので、ひとまずは12ベイ以上が駄目そうという理解です

もう少しで DS2422+ をポチるところまで行ったんだが、残念だ

5ベイ拡張ユニットの DX517、イマイチ入手性がよくない。尼にもあったりなかったりする

あと拡張ベイの問題は、ベイを跨いだプールを作れないので、本体の8ベイはデカく使えるけど拡張ベイ側は実質プールあたり最大5ベイになってしまうというところ

まあ6ベイのプールを2つ以上作りたいことがそうそうあるかというと、まあ……ないかも (錬成すればある)

高速ランダムアクセス用 SSD プール、容量重視の HDD プール、バックアップ用プール、で本体+2拡張ユニットを使いきれる感じかな。あくまで例として。

バックアップを同じ本体で LAN を通さず処理できると、 LAN の帯域を食わないのでそれは嬉しい

This account is not set to public on notestock.

そんな無断リンク禁止みたいな平成中盤的挙動してる人まだいるんだ…… (まだというか、安定して一定の割合で生えてくるのか)

べつに web の本質を知れみたいなことまでは言わないけど、他人の行動を無闇に制御しようとするのは支配欲であってそれを矢鱈に表出させてしまうことの醜さはせめて自覚すべきだとは言いたい

NAS 自作、 OS とかアプリくらいまではギリギリどうにかできるとしても、ハードウェアの方がたぶん満足いく水準にならないんだよなぁ

もちろん探せばその用途に特化したケースとかベイもあるのだろうけど

クソなぞなぞ: 最新版がバグだらけだったよ。なぜかな？

RasPi とかの場合だと、 USB セルフパワーハブに繋ぐと接続できるようになったりなどがあった

GnuCash のテンプレでは後者スタイルになっている

This account is not set to public on notestock.

GnuCash は勘定科目を共有しない取引同士の順番をつけられないという欠点があり (利点とも言えるが、後から勘定科目を追加したとき並び替えられない問題がある)、私にとっては対処可能ではあるが割と面倒だった

取引を本来意図した順番で複製して、複製元を削除、とやるといける。たぶん内部的には RDB の行番号順なんでしょう。気持ち悪いし不便だけど理解はできる。

あと GnuCash は UI が日本語入力まわりでバグりがち

This account is not set to public on notestock.

This account is not set to public on notestock.

これ自前で install すると全部 (間接依存ではなく) ユーザの欲求によるインストールということになってしまわない？

apt cache だか何だったか忘れましたが、 autoremove で削除対象になるようにちゃんとマーク付けといたほうがいい気がしますね。その上で autoremove の dry run をして、消えてほしくない根っこのパッケージを列挙していく感じにする。

This account is not set to public on notestock.

This account is not set to public on notestock.

portage は昔は emerge -C で依存を無視した強制削除ができたはずなんですが、いつの間にやらできなくなってましたね (強制削除は不整合が発生してしまいがちなのでそれで良いと思うが、既にある不整合に対処する場合は手動で頑張れということなのかな)

This account is not set to public on notestock.

https://mstdn.maud.io/@unarist/109744052898507072

apt-mark だった

大公開：ArkEdge Space のソフトウェアチームのポリシーと実現したい夢 - ArkEdge Space Blog https://blog.arkedge.space/entry/2023/01/24/113000

いいね

まじかー……

This account is not set to public on notestock.

This account is not set to public on notestock.

This account is not set to public on notestock.

This account is not set to public on notestock.

This account is not set to public on notestock.

This account is not set to public on notestock.

なぜ Release Candidate になってから変更をガン積みするのか、ｺﾚｶﾞﾜｶﾗﾅｲ

そういうのは RC より前のマージウィンドウを用意して入れたいものを先に集めるとか、 alpha や beta で準備してからほぼ固まったリリース候補を出すとか、やりようがあるでしょ……

バグ修正とデザイン欠陥への対処とドキュメント補強以外のものが RC 以降に追加されるのおかしいから……

そういえば複式簿記でクレカの2回払 (利息なし) ってどう管理するのがいいんですかね。現状普通にクレカ用の勘定科目に全部まとめて突っ込んでるんだけど、これだと来月の支払いなのか再来月の支払いなのかの区別がクソ面倒なんですよね

事前に来月と再来月の支払いの項目を作ってそこに加算していきつつ将来の合計が0になってればokみたいな運用をしているが、1回目と2回目の金額配分を誤っていても合計は0になって気付けないのであまり良くないと感じている

hogeカード:2023-02 みたいなサブ科目を作ってそっちに流して、毎回の引き落としごとにクローズする、みたいな方向がいいんですかね

This account is not set to public on notestock.

えー、そうなの…… >beancount

フォーマット的にはそんな印象ないけど

アプリ側の問題だったりする？

3.2. GnuCash勘定科目 https://www.gnucash.org/docs/v4/ja/gnucash-guide/accts-types1.html

たぶん GnuCash のデフォルトテンプレではクレカが特有の負債になってるけど、本質的にはたぶん同じことをしている？

ちゃんと勉強しないと駄目かなぁ

This account is not set to public on notestock.

This account is not set to public on notestock.

https://github.com/mastodon/mastodon/pull/20808
感覚を伝えるために例を挙げるなら、これとかも「新機能」ではないもののバグ修正というほどのものな気はしないので、 RC に入ってからやるようなことか……？ という感じです (まあ最終的にコミッターが正義なのはそれはそうだが)

feature か fix かで言えば feature だよなぁと。

あと RC 期間中でも dependabot の怒涛の更新が入っていくのはどうなんだ。
まあこれは release branch を切らず main で RC メンテしちゃってるせいだろうけど

まあブランチングのポリシーは人それぞれなので議論したところで合意に至るのも難しいし、コミッタや primary author が押し通すことになるのも仕方ない面はあるとは思う

現状の管理はこうなっている。
10099 や 6066 が 5099+5000 と 3066+3000 に分かれていることが読み取れないし、ミスると整合させるのも大変。支払予定額と実際の額が合わなくなって明細を最初から見ていくことになるので。しかも分割が来月の分にも影響するので。
(画像は順に 負債:クレジットカード:Aカード と 資産:流動資産:普通預金:A銀行 のもの)

で、それをこうやって管理する方が安全なのではないか、というのが最近の所感。ただこの方法が “正しい” のかはわからない。もしかするととんでもないデメリットがあるかもしれないし。

(画像は順に 負債:クレジットカード:Aカード:2022-04 と 資産:流動資産:普通預金:A銀行 のもの)

https://mastodon.cardina1.red/@lo48576/109744485223785796
たぶん最初に挙げた方のやり方が「買掛金」の普通のやり方なのだと思うんだけど (自信なし)、2回払いがあると不便だなぁと。

これが利息なしであっても特定の品や名目で36回払いとかになると、さすがに専用の勘定科目を用意するんだけど、2分割程度で複数決済をまとめて、しかも月ごととなると……

クレカ引き落としを跨いだ返品・返金とかもどこから戻すねんみたいなのもタイミング次第でまあまあ面倒 (先月の決済分の一部が今月分の支払いと中和したり)

かといって費用の方から戻すと、買って売ったのと意味的に区別つかないし。
まあそういう区別をするためのものではないのかもしれないが、実際「手に入っていないのに入手したことになって計上される」というのは一時的であれ結構気持ち悪いものがあり