起きていたことと、一時的な解決方法

先に一時的な解決だけ書いておくと主電源を切り、入れ直せば復帰可能だった。

PCの電源ボタンを押下しスリープすると、高確率で復帰できなくなっていた

高確率でとあるが、6回中4回復帰できなかった。復帰できた2回はスリープ後、即座に電源ボタンを押したときであり、それ以外は復帰できなかった。

電源ボタン以外にもキーボードやマウス、NIC(WoL)を通じたスリープ復帰が出来るようにデバイスマネージャーで設定しているが、いずれの手段でも復帰できなかった。

この時の特徴として、普段スリープ時であれば電源ボタンのLEDが点滅しているが、点滅していなかった。また、電源ボタン押下時には一切なにも起こらず、一瞬だけファンが回るような挙動もなかった。

主電源を一度切って、入れ直すと起動自体は出来たが、OS起動中にコンセントを抜いたのと同じ扱いになるため、再起動後はクラッシュから復帰した状態になった。

スタートメニューからスリープに入る操作方法では試していない。

スタートメニューからシャットダウンすると、ブートできなくなっていた

これは一回しか試していないので、一回しか起きていないが、スタートメニューからシャットダウンを選びPCをシャットダウンすると、電源ボタンを押しても起動させることが出来なかった。

この時は一瞬だけファンが回り、その後停止した。何度電源ボタンを押してもブートしなかったが、スリープ時同様に一度主電源を落として入れ直すことでブートさせることができた。

発生時の条件

Windowsのバージョン

Windows 11 Pro 26H2 (OSビルド 26300.9711)

hypervisorlaunchtype

AUTO

電源オプションの電源ボタンの動作設定

電源とスリープ ボタンの設定

シャットダウン設定

恒久的に解決した方法

コマンドプロンプトを管理者権限で起動し、以下のコマンドを流す。

bcdedit /set hypervisorlaunchtype off

戻したいときは同様に以下を流せば戻る。

bcdedit /set hypervisorlaunchtype auto

特に効果がなかったこと

使用しているマザーボード（ASRock Z890 Pro RS）のBIOSバージョンを1.39から3.40まで上げてみたが、特に効果はなかった。

あとがき

10/23にWindows Updateし10/24に対策したが、今のところ再発していない。hypervisorlaunchtypeをautoにするだけで容易に再現するため、恐らくoffにしている限り起きないと思う。これによる影響は不明だが、BCDEditのヘルプによると設定値自体はHyper-Vのデバッグ用にあるらしい。

現状行った機能改修

Lyndbaumからのバックポートしたものを含む様々な対応の話。

公開画面のテーマをLyndbaumの公開画面に合わせた

元々このブログではsatsuki2テーマを改造したlycoテーマを使っていたがレスポンシブデザインに対応していない問題があった。これはadiaryがそれを前提として作られておらず、PCかSPかをUAを見て振り分け、画面を出すシステムだったことや、表示処理の高速化のためにDOM構造を固定しJSで見た目をこねくり回す、良くも悪くもはてなダイアリーのような思想で作られていたことに起因する。

今回は一段階目でテーマのREADMEにResponsive: yesと書くと、UAによるスマホ表示の振り分けをしないように対応した。この機能はまだ試験導入中で、機能的に不足している個所が多々あるので、しばらく手入れしていく予定だ。

また画像ビューアをFancyboxからLythumb-viewerに置き換えることで、jQueryを廃止し、読み込み時のデータ量を削減している。他にもサイドバーやコメント欄のツリー開閉は従来JSで行っていたが、レイアウトシフトを起こす元凶だったため、<details>に変更し、HTMLとCSSで静的に切り替えるようにした。これによってレイアウトシフトとJSの削減を行っている。

他にもスクロール時に目次が追従する機能を今回作成したテーマ側に設けた。私は目次は追従してくれないと不便だと考えており、入れたかった機能の一つだ。この対応では逆にJSが増えているが、仕方がない。

今回の対応によりSPビューだけではなく、PCで画面を狭めたときにも画面が見やすくなり、個人的にはかなり利便性が上がった。何より2年半くらいあったこのサイトについてにある、「レスポンシブデザインにも対応予定ですが、現状は非対応です。」の説明を外すことが遂にできた。

旧画面	新画面

PCビューの新旧比較だとこんな感じ。SPビューはスクショが面倒なので省略。

公開画面と管理画面の分離

adiaryでは公開画面と管理画面を実質的に同じ画面として出すようになっているが、ここも実装上分離した。公開ページのテーマを変えると管理画面に波及したり、そもそも管理画面に公開画面の内容が混ざっていて使い勝手がよくなかった。現状は分離しただけなので画面は変わっていないが、将来的には管理画面らしいものに変えていきたい。

印刷用表示機能の削除

今回の対応で壊れてしまったので削除した機能。

元々はこんな感じで記事カラムの部分にフォーカスした表示がされていたが、Matomoを見ているとBOTが吸い込まれていくだけで使われていない機能だった。今時印刷する人もいない気がするので復活させるかは謎だが、恒久的に削除するかどうかも決めていない。気が向いたら復活させる可能性はある。

バックリンクの表示対応

記事について、別の記事からリンクされている場合に、そのリンクを参照元として表示する機能を足した。PukiwikiやMediaWikiなど、Wiki系のシステムではよくみられる機能だと思うが、ブログではなかなか見ない機能だと思う。

作りとしては記事にリンクを書いたり消したりするとバックリンクDBを書き換え、それを基にキャッシュHTMLを作り、ページが表示されたときにこのHTMLを画面に出しているだけだ。adiaryは画面のパーツをHTMLで持っておき、リクエストが来たときに繋げて表示する方式なのでこうしている。

YARPPのように毎回動的に生成しないため非常に高速に動作する。

対応しているのは今のところ記事のみで、ページには対応させていない。

記事更新時の衝突検知

Pukiwikiには同時に他の人が更新したときに更新の競合を検知し、それを表示する機能がある。これは誤って他人の更新を上書きするのを防止する機能だ。これを導入した。

私は以前から複数タブで同じ記事を開くことがよくあり、何ならスマホでも開いていることがあった。これによって更新内容を衝突させてしまうことがよくあったので、それが起きないように導入した。

仕組みとしては編集画面にハッシュを埋め込んでおき、このハッシュの差で判定している。衝突時にはいい感じに差分を出してくれるので便利だ。

ページにできない名前を、ページの名前に使えないようにした

adiaryでページを作ると基本的にページタイトルがURLになるが、仮に「pub/lycolia/rss.xml」と言うページを作るとhttps://example.com/pub/lycolia/rss.xmlというURLのページが出来てしまう。

こういったページができるとページではなく実際のファイルが表示されてしまう。これでは困るので、衝突するページを作れないようにバリデーションを追加した。

その他

• ログインセッションの有効期限の初期値を180日から14日にし、パスワード変更時などにセッションを消すようにした
• テキストDBのトランザクションの不具合を修正した。途中でエラーが起きると、その後の書き込みが消えることがあったため
• 初期セットアップ用のindex.htmlを復活させた。nginxでうまく表示できる設定を作れたため
• バージョン表記をadiary本家と同じx.yy方式にした。現在はv4.08。内部の処理が数字の大小に依存しており、これに対応するのが主な目的。桁の増減もなんか微妙かなと言うので固定長にしたのもある

この他にも細々とした対応をあれこれ。

あとがき

結構な変更を加えたが、コアの処理は変えていないため処理速度は1ms増えたくらいで体感では誤差の範疇である。

まだバックポートできていない機能も多くあるし、SEOやUX的にも不足の部分があり、管理画面もまだ途上だったり、既存テーマをどうするか問題、セキュリティ対応など、様々な課題があるので、ぼちぼち進めていきたいところだ。

と言うか本来書くべき記事も書かないといけないし、adiary以外にもやりたいことがあるので一日の時間が全く足りていない…。

ひとまずadiaryをベースにやっているためLyndbaumの時のように仕様漏れやパフォーマンスについて考慮することが少なく済み、またLyndbaum側で入れた機能についても基本はadiaryの構造に合わせてバックポートするだけなので実装コストが低いのが楽だ。

やったこと

Markdownパーサーの改善

Lycolia/lyndbaumで実装したMarkdownパーサーからExtendsにないものを移植し、ついでに移植元でバグっていた部分を直した。主に直した不具合は次の通り。

• 2 * 3 * 4や*.txt、日本語に挟まれた_が強調として扱われてしまう問題を修正
• リンクの文字に角括弧を、URLに入れ子の括弧を書けるようにした
• <M>のようなHTMLにないタグ名を、文字として表示するようにした
• コードスパンの中の\が消える問題を修正
• 番号付きリストが書いた番号から始まるようにし、リスト内の<p>の付き方や引用も直した
• 表でコードスパン内の\|と、1列目の左寄せが効くようにした
• 脚注で複数の段落と、同じ脚注を複数回参照する書き方に対応した
• 画像や添付ファイルの代替テキスト・titleの扱いを整理した

またほかにも、新しいパーサーでは見出し構文のアンカーをPukiwikiの見出し構文に準ずるものに変更しており# hoge [#anchor_id]形式で生成するようにしている。これはアンカーIDを固定する記法で、見出し本文が変わってもアンカーを変えずに済むようにしている。アンカーIDがなければ自動付与、あれば付与しない、IDは手動指定も可能としている。過去記事については見出し本文をID指定することで、過去のアンカーリンクが壊れないように対応した。あわせて、段を飛ばした見出しが目次に出ない問題も直している。

Lycolia/lyndbaumについて先の記事でも言及しているが、これまでadiaryの代替CMSとして開発していたCMSだ。adiaryにある幅広い機能の網羅的再現が出来ず開発を中断したが、成果物はあり、本来adiaryに欲しい機能ではあったためバックポートを実施した。

かなり機能を入れているため、バックポートは今後もちまちまやっていく予定だ。Lyndbaumの開発のように五日で作りましたという勢いでLLM任せにやると何が何だか分からなくなるため、今回は理解可能な速度でレビューしながら進めてゆく。

バージョンを0.x系から4.x系に転換

adiaryにはデータマイグレーションの仕組みがあるのだが、これがバージョンの数字の大きさによって管理されていた。ざっくりいうと(前回マイグレーションしたバージョン - 新バージョン > 0)の条件が真であればマイグレーションを実施するもので、前回マイグレーションしたバージョンは管理画面で後退させることができ、マイグレーションをやり直す機能がある。

ここでバージョンが0.xだと都合が悪いため、3.x系である本家を追い抜いて4.x系をつけることで解決した。

マイグレーション管理用のバージョンと表に出すバージョンが分離しているため、別に0.x系のままでも成り立つのだが、本家では表のバージョンとマイグレーション管理用のバージョンは同期していたため、運用の都合で合わせることにした。そっちの方が解り易いし、綺麗だからだ。

あとがき

この記事とは直接関係ない話だが、フィードアグリゲーターのrururuがLyndbaumのフィードURLを拾っているようで少し困った。

実はLyndbaumは12時間ほど本番環境に上げて切り戻した経緯があり、その時にRSSについては302リダイレクトを入れていた。恐らくそれが起因となって書き換わっているのだと思う。

現在はadiary-extendsに切り戻しているためLyndbaumは使っていないのだが、動いていないRSSフィードやアイコンを参照されているのが悩みどころだ。

試しにadiary-extendsでも同様の302リダイレクトを掛けてみたが特に更新されなかった。恐らく手動で更新しているのかもしれない。以前、フィードURLが変わると宣言したのが影響している可能性を考えた。ひとまず管理者に連絡する術がないので、rururuの利用者で連絡が付きそうな人でかつ、rururuの運営者と関係がある人物に連絡してみたので、変わるといいなと思っている。

なおrururuくらいしかフィードの読み替えをしてなさそうに見えたため、Lyndbaum→adiary-extendsで生じたRSSフィードURL切り戻しに対する302リダイレクトは既に取りやめている。adiary-extends→Lyndbaumで302して、切り戻しでその逆をして、ややこしい二日間だった。

幾つかの変更は本家にもPRしているが、スパムみたいになってしまったので今後は考えようと思った。

確認環境

リポジトリのクローンと設置

/var/www/に展開すると仮定する。

git clone git@github.com:nabe-abk/adiary.git
cd adiary
cp adiary.conf.cgi.sample adiary.conf.cgi
sudo chown -R www-data:www-data .

設定例

IPv6でSSL化済の設定。fcgiwrapはデーモンとして動いているものとする。

server {
  listen [::]:443 ssl;
  server_name adiary.example.com;

  ssl_certificate     /path/to/fullchain.pem;
  ssl_certificate_key /path/to/privkey.pem;

  client_max_body_size 100M;

  root /var/www/adiary;

  # 実在するファイルはそのまま返し、なければ404
  location /pub/ { try_files $uri =404; }
  location /pub-dist/ { try_files $uri =404; }
  location /index.html { try_files $uri =404; }
  # favicon
  #  システム設定があればそちらを優先、なければデフォルト
  location = /favicon.ico { try_files /pub/lycolia/image/@system/sys-iconfile.png /pub-dist/default-icon.png =404; }
  # adiaryに飛ばす用
  #  /でCGI、/index.htmlでセットアップページに飛ばすための分岐を実現するために、こうしている
  location / {
    try_files $uri @adiary;
  }

  location @adiary {
    fastcgi_pass unix:/var/run/fcgiwrap.socket;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root/adiary.cgi;
    fastcgi_param QUERY_STRING $query_string;
    fastcgi_param HTTPS on;
    fastcgi_param SERVER_PORT 443;
    fastcgi_param ModRewrite 1;
    fastcgi_param Basepath   /;
  }
}

トラブルシュート

ログイン時にhttps://hogeに飛ばされる

上の設定にしたら行ける。公式の設定をコピペしても上手く行かない。

生まれた葛藤

実装を進めるうちに「本当にこれでいいのか」という迷いが生まれてきた。そして、いったん立ち止まって考え直した方がいいのではないか、と思うようになった。

• LLMに丸投げで作らせた、正しいかどうかも分からないまま何となく動いているだけの代物。それでいいのか？
• パフォーマンスはadiaryに劣り、LLMに指摘して直させても、言われた通りにベンチを取ればかえって遅くなっている。それでいいのか？
• なぜ動いているのか自分でも説明できない。それでいいのか？
• そんなものがadiaryの後継を名乗るのは、さすがに無理があるのではないか？

そんな葛藤が湧いてきた。

正直なところ、LLMに色々やらせた結果、表面上は動いている。けれど、きちんと要件定義や設計をしていなかったこともあって、細かい部分はうまくいっていない。LLMはコンテキストが膨らむにつれて文句を言い出したり、明らかに誤った判断をし始めたりもする。長く使っていくものを作るにしては、あまりにも拙速な開発だったのではないかと感じている。

今回の変更点

とはいえ作るものは作ったのでそこだけ出していく。

メディアブラウザが実用レベルになった

今回一番手を入れたのがここで、記事に画像を貼るためのモーダルだったものが、ファイルマネージャーに近しいレベルになった。

大分それっぽい見た目だ。フォルダの作成やリネーム、削除にも対応した。

ファイル情報やどこに添付されているかも出せる。

複数選択してD&Dで移動させることもできる。Shiftキーを押しながら一括選択だって可能だ。

ダブルクリックでサムネイルビューワが立ち上がるところも再現したし、サムネイルビューワもFancyboxではなく、自作品にした。

画像以外のファイルのアップロードに対応

これまでは画像と動画しか上げられなかったが、mp3、txt、md、csv、tsv、json、zip、7z、pdfも上げられるようにした。

例えばテキストファイルをアップロードしてプレビューも出来るようになった。

記事中に[file:mp3:~~~~]と書けば<audio>で出力されるようにし、音楽も流せるようにした。

一方でHTMLやSVG、XMLなど、ブラウザがこのサイトのオリジンでスクリプトを動かせるとのことで、これらのアップロードは許容しないようにした。

またTIFFなどサムネイル生成時に任意のコマンドが実行される可能性があるものについてもアップロードさせない対応をした。

追従する目次の作成

Wiki.jsやGitHubにある追従する目次も作った。

うちは3カラムサイトというのもあり、やり方は少し悩んだが、GitHubとWiki.jsの間の子的なUIにして解決した。

執筆まわりの改修

これまではアイキャッチのモード選択と言う煩雑なものがあったが、今回の改修ではモード選択をなくし、WordPressのUIを採用した上で、アイキャッチにする画像選択についてはadiaryの自動選択アルゴリズムと、手動選択の二つを暗黙的に選択できるようにした。

手動で選択すればそれがアイキャッチとなり、それをしなければ最初の画像がアイキャッチとなり、画像がなければ既定の画像がアイキャッチとなる仕組みだ。

本番デプロイの準備

本番デプロイにあたり、必要なドキュメントの整理や、FCGI対応も行った。

さくらのレンタルサーバーでも動作し、家のサーバーでもFCGIとして高速に動作した。

しかしadiaryを超える速度にはならなかった。

その他の細かい変更

他にもこまごまとした対応をしたが、結局のところ虚無になってきた。

アクセス解析を入れられるようにしたり、カウンターを挿入できるブロックを追加できるようにしたりもした。

この記事も、既に使わなくなったことについて書いているので虚無である。

得られたこと

今回の開発は一旦中断することにしたが、セキュリティ周りの対策の知見や、FCGIの作り方など、幾つかの技術的な知識が手に入ったのは有益だったと思う。

また外部のフィードアグリゲーターから画像が直リンクされていることを把握できるなど、中々新しいことが分かった。そんくらいサーバーログ見てろよって話だが…ｗ

あとがき

また今回のCMSは一旦お蔵入りさせるが、作ったものの一部はExtendsにバックポートし、必要に応じて本家にもPRを出しバグの改善が出来たらよいと思っている。

adiary自体の資産が大きすぎて全てを再発明するのは無理があるし、それをするくらいなら必要な部分を直した方が早い。

何故なら私が一番欲しかったものはレスポンシブデザインで、その次が理想のMarkdownパーサー、後はバックリンクくらいで、その他は既に実装してしまっている気がするからだ。

ひとまず作ったCMSであるLycolia/lyndbaumと、FancyboxもどきのLycolia/lythumb-viewerはこの記事で供養しておこうと思う。因みにサムネイルビューワについてはFancyboxに戻してある。理由は単純で、lythumb-viewerより拡張性があり、操作性もいいからだ。

何はともあれ今回の開発はいい勉強と経験になったので、今後に生かしていきたい。

あとこれは下心なのだが、adiary利用者のページからのアクセスが馬鹿にならないほどあり、これも新製CMSへの移行をためらった理由の一つである。

そしてExtendsの方はこれまで通りのんびり育てていこうと思う。

しかしこのネタだけでちょうど新着5件が埋まってしまったのは面白い。

Opus 5.5のトークン使用量はProプランで前週73%、今週24%に収めることができたので、単に作るだけであればProで足りた。もうちょっと、ちゃんと作る場合はやり取りが増えるので溢れたかもしれない。

前回の記事から変わった部分

ログイン中に管理バーを出すようにした

adiaryやWordPressはログイン中に管理バーが出てくるが、それを実装した。

一々ダッシュボード開きたくないし、記事開いてる時はその場で編集画面に飛びたいためだ。

adiaryに乗り換えたときに放棄したWordPressのアーカイブをまだ残していたため、それを参考にUIを作った。中々イケてると思う。

なお当時のWordPressは既にあれこれ壊れており、ほぼ機能していない。

管理画面のリッチ化

流石に以前の管理画面は殺風景すぎたし、なんか使いづらかったのでWordPressリスペクトで作った。

表形式の画面は奇数行と偶数行で色分けしているし、記事編集画面もテキストエリアと背景色の色を差別化して見やすくした。アイキャッチや公開のセクションボックスも色を変えるとより良くなりそうだ。

他にも編集中に間違えて離脱しそうになったとき、確認のダイアログを出して誤った離脱を防げるようにもしている。そこを超えて万一離脱した場合もページそのものは単純なHTMLであるため閉じたタブを戻したり、ブラウザで戻る・進む操作で戻ってくれば基本的に状態は保持されている。

JSフロントでやろうとすると状態管理が偉いことになるが、ここはブラウザの機能に丸投げして楽をしている。因みにadiaryも同じ仕様である。

公開画面のセクション分けと、トップの全文表示対応と、その他諸々

背景が単色で各セクションの境目が見えなかったので、背景色と前景色を分けて見やすくした。

またトップページを抜粋表示から一覧表示に変更した。

他にも記事ページのスタイリングを調整し、現在のスタイリングに近いものにした。近いだけでそこまで似てない。

公開画面のレスポンシブデザイン対応

2024-02-01にCMSをWordPressからadiaryに乗り換えて以来、ずっと達成できていなかったレスポンシブデザインについに悲願の対応をした。

これで遂にこのサイトについてにある、「レスポンシブデザインにも対応予定ですが、現状は非対応です。」の説明を外すことができる。

バックリンク機能の追加

記事から被リンクを受けている記事は、そのリンク元を示せるようにした。これはPukiwikiにもある機能だ。

これでもう手作業で関連記事を書いたり、その更新のせいで無駄に更新日時がアップデートされることもなくなる…。

Fancyboxを廃止し、独自ライブラリに置き換え

FancyboxはjQueryで動いていて、jQueryで動いてるのがこいつだけなので排除したい思いが常々あったが、GPT-6.1 Solにドラフトを書かせ、Opus 5.5に仕上げさせることで形にした。

GPT-6.1 Solを使っていて思ったのは5ターンもすると最初の指示を忘れて暴走し始めることで、これはもう駄目だなと思った。コンテキストが長くなると、その場の指示すらまともに聞き入れてくれないので脱帽ものだった。

この独自ライブラリは既に今のadiaryで動いているブログにも取り込んでいて、fancyboxの排除はCMS移行をせずとも既に達成されている。

fancyboxにはURLにハッシュが付いた状態でページをスクロールしてモーダルを閉じるとハッシュの場所に戻る不具合があるが、これは新製ライブラリでは起きないようにしている。

初版リリースまでに実装する予定の機能メモ

• 記事編集画面もテキストエリアと背景色の色を差別化して見やすくしたが、アイキャッチや公開のセクションボックスも同様に色を変えたい
• テーブルの中身が折れてそうなので確認する
• ページ作成
  • slugはデフォルトでタイトルにする
    • 手打ちした場合のみ変更可能にする
    • 更新時にタイトルが変わった場合も、そのタイトルをslugにする
• メディアブラウザ
  • 複数選択して一括で記事に挿入
  • 選択しているものをD&Dで別のフォルダへ移動
    • 記事のアップデートまではしない予定
      • 記事を書いてそのあとにパスを考えるのはあり得ないオペレーションだと考えている
• タグ
  • 選択しているものをD&Dで別の階層へ移動
    • これは記事側も更新される
• インストールマニュアル
• ハンバーガーメニューの追従
  • 今は追従しないのでスクロールすると消える
• 目次の追従
  • https://wiki.maud.io/ja/akane/guidelineみたいなやつ
  • 現状の3カラムをどうするかは考え直す余地がある
  • SPビューでもアイコンで目次を配置したい
• favicon設定
  • 自動で各サイズのアイコンを作る
  • 既定はpub/assets/logoにある奴を使う
• Ping通知
  • 管理画面からtextareaで宛先を行単位に登録可能
• HTTP CLIENT
  • 基本的にHTTP通信はこいつを通す
    • 例外が必要な場合は検討する
  • UAにはソフトウェアバージョンやサイトドメインなどを含める
    • 例：Lyndbaum/0.1-beta5 (+https://blog.example.com)
• 画像以外のアップロード
  • 現状テキストやHTMLとかはアップロードできない気がするため
    • 画像以外はサムネなしでファイル種別の分かるアイコン出せれば良さそう？
    • 初期では単純にファイルアイコンに拡張子書いたSVGでもいいかも
  • アップロード可能な拡張子は設定可能にする
• 記事のフラグ機能
  • 任意のフラグを設定して記事の表示時に何かをする機能、例えばNSFWフラグを立ててブラーや検索エンジン向けのメタ通知をレンダリングできるとよい
• 記法の管理
  • adiaryでは任意のSatsuki構文を追加できるが、新CMSではまだできない
  • WordPressのshortcodeは色々面倒なのでSatsuki構文で行きたい

あとがき

ここに書いていない事でも細々とした修正を重ねていて、既にCMSの新規作成と言うよりは、細かい詰めのフェーズに入っている感じだ。早ければ今月中、遅くとも年内には切り替えられるのではないかと考えている。

切り替えるとadiary利用者一覧に乗せられなくなるのが残念だが、その時点で利用者ではないため仕方がない。

また移行時にはRSSフィードのURLを変える予定なので、RSSを購読されている方々におかれては追々移行の対応をしていただけると幸いである。しばらくはリダイレクトをつける予定なので、すぐに読めなくなることはない。

そういえばLightboxで画像の拡大ができないのでFancyboxを導入していたのだが、Lightbox3が今年の8月に出ていたようで、なんと画像の拡大に対応していた。しかし画像に角丸が付いてたり、画像にUIがオーバーレイしまくりだったり、何とも言えない感じなので、採用は見送った。

かつて画像拡大モーダルの代名詞だったLightboxは、あの時のLightboxのままを記憶にとどめとこうと思った。

前回の記事から変わった画面

管理画面

前回と比べるとメディアブラウザとブログの設定が追加され、基本的な管理機能が揃った。

まだPC前提の画面と言う感じが強く、画面幅を狭めると使いづらい。狭い画面でのメニュー類はハンバーガーメニューにしたいところだ。

記事作成画面

前回と比べるとOGPの設定やメディアブラウザに繋ぐボタンの追加があり、記事の設定がしやすくなった。

しかしメディアブラウザから複数ファイルを一括で入れる機能や、動画やテキスト、バイナリファイルの挿入には対応していない。

画面のレイアウトはWordPressを参考に作ってほしいと途中から指示している関係で中途半端にWordPress感がある。

比較用にadiaryの編集画面はこんな感じ。adiaryのデザインは踏襲せず、どちらかと言えばWordPressのようなレイアウトに寄せていきたい考えだ。理由として1カラムより2カラムの方が1画面に要素を入れられるし、マウスは上下より左右に移動させる方が楽な気がしているからだ。

それに記事を書く場合、本文エリアは文章執筆に集中できるように余計なものがない方がいいと考えている。WordPressは標準だとメインカラムにあれこれ乗っていた気がするが一旦新CMSでは操作系のパネルは右に寄せていきたい。

WordPressのように要素を再配置可能にするかについては未検討。

メディアブラウザ

取り敢えずアップロードされてるファイルの一覧や操作が出来たらいいよねと言うことで作ったもの。これがないブログCMSは知りうる限りない。15年以上前に使っていたPHP製CMSのBlognですら装備していた。

ディレクトリツリーが折りたためない、リネームができないなど、機能的にはイマイチだが、取り敢えず一覧表示とゴミ箱への移動は実装している。

ファイル選択時のレイアウトシフトが邪魔くさいので、これも何とかしたい。たぶんWordPressのレイアウトを参考にする。

ブログの設定

ブログの基本的な設定が出来るようになり、ブログの説明をテンプレートにハードコードしなくてよくなった。

編集の設定（記事投稿の設定）

以前は履歴を積むまでの間隔の単位が「時間」だったが、「分」にした。時間を割った指定がしづらいためだ。例えば0.75時間が45分なのは直感的でなくUXが悪いと思っている。

設計で工夫した部分

ファイル構成やフォルダ階層の一般化

当たり前のこと過ぎて、これが工夫に当たるかどうかは限りなく謎だが…。

adiaryの構成は一見すると何がどこにあるか全くわからないため、これを一般的なMVCアーキテクチャにしてどこに何があるかわかりやすくした。

またadiaryでは画像処理やハッシュ化などに自作処理が多いが、脆弱性やバグのもとになるためPerl標準のライブラリで実現できる機能はライブラリに任せている。

以下のスクショにはないが自動テストも作っており、デグレの検知が出来るようにもしてあるし、一般的な構成にできていると思う。

adiary	新CMS

パスワードのハッシュ化

何をそんな当たり前のことを…と思うかもしれないが、当たり前だからこそ書いている。昨今システムへの攻撃ニュースが相次いでいるが、歴史的経緯や要件の都合で、パスワードを平文で持っているシステムもまだあるだろう。

当然、今回のシステムではハッシュ化して保存しており、アルゴリズムにはbcryptを使っている。

最初はClaude Opus 5.5が提案したPBKDF2-HMAC-SHA256を採用していた。これはLLMが言うならbcryptより新しく強固だろうと思ったからだ。しかし調べたところ今回の要件では特に優位点がなく、Laravelの標準でレンタルサーバーのような貧弱な環境でも広く使われているbcryptに切り替えた。

bcryptは72バイトまでの制約がある軽量なハッシュ化アルゴリズムで、PBKDF2-HMAC-SHA256と比べた場合にハッシュが漏洩したときの総当たり計算コストが高い優位性があるらしい。PBKDF2-HMAC-SHA256も軽量だが、こちらは長さの制約がない代わりに、総当たりコストがbcryptより低いらしい。どっちみち今回のシステムではハッシュが漏れた時点で色々終わっており、ここを比べてもあまり意味がないため、PBKDF2-HMAC-SHA256でも問題ないと言えばない。

なおOWASP Password Storage Cheat Sheetでは、第一候補はArgon2idとされている。bcryptより強固だが、推奨構成（メモリ19MiB、反復数2、並列度1）ではログインが100件同時に走るだけで約1.9GB、1000件なら約19GBのメモリを使うため不採用とした。OWASPもbcryptはArgon2idを使えない環境向けとしており、今回の用途に合っている。まぁ実際にDoS攻撃が来たら、どのアルゴリズムでも耐えられないとは思うが…。

コンテンツページの名前の制約

adiaryではコンテンツページの名前に制約がほとんどなく、記事IDと衝突しないものなら作れてしまう。するとどうなるかと言うと、例えばRSSフィードと同じパスでページを作るとページが表示されずRSSフィードが表示されてしまう。

今回の開発ではこれが起きないように、記事IDに加え、物理パスと衝突しない対策も入れてある。

RSSフィードのフォーマットを見直し

adiaryのRSSフィードでは<category>の中身がカンマ区切りだが、これはRSSの仕様違反らしく、一般的には1カテゴリ1要素になるらしいので、そのように実装した。実際の動作は見ていないがWordPressもリファレンスを見る限りではそうなっているようだ。

これでRSSリーダーに優しくなるかもしれないが確認はしていない。

また<![CDATA[...]]>も使わないようにしている。基本的にないと思うが本文中に<![CDATA[...]]>が入るとエスケープなしでは壊れるし、改行が入る関係で個人的にRSSを読みづらかったりして微妙な気がするからだ。

記事とコンテンツページのURLをadiaryから引き継いだ

posts/123, pages/ほげほげとするのも一つだとは思うのだがページパスが長いとURL直打ちや、記事を書く時のリンク張りが面倒なほか、外部サイトから過去に貼られた被リンクも壊れるので、これは引き継ぐことにした。

WordPressのように書式を変えることも検討したが、こういう機能を増やすと手間が増えるだけだし、利用者としても「どれがいいだろうか…？」みたいな迷いが生じると思ったので、その自由はなくすことにした。変なの付けてもSEOや管理的に不利になって自分の首を絞めるだけと言うのもある。

私はかつて日本語タイトルをパーマリンクにしており、常にタイトルとパーマリンクを同期させていたせいで記事名を変えたときに過去記事からのリンク張替えで地獄を見ている。

あとがき

とりあえず使える状態にはなったが、まだまだ微妙な部分があるのである程度快適に使える状態になったら、このブログをadiaryから新しいCMSに置き換えようと思う。現時点での名前はlyndbaumとしている。

adiaryの次だからbdiaryとか、adiaryが作者名+diaryなのでldiaryにしようかとか、和風にHiyoriにしようかとか色々考えたのだが、lyndbaumの語感がいいなと思ったのでこれにした。

名前の由来としてはサモンナイトにある世界リィンバウムを基にしている。リィンバウムは周囲に他の異世界を取り巻いており、このCMSも将来的にプロジェクト管理やWikiを派生させていく核としたいという構想があるため、その類似点からリィンバウムのスペルであるlyndbaumを名前にした。とはいえノリで付けた言葉に後から意味を持たせたのが現実であるため、深い意味はない。

ロゴも作っており、機界ロレイラル、鬼妖界シルターン、霊界サプレス、幻獣界メイトルパが取り巻くリィンバウムをイメージしている。見た目的には取り巻いていないがそれは見栄えの都合と言うことで…。

真ん中のLYは頭二文字で、各世界を繋ぐ大樹をなんとなくイメージしている（謎）

この着想はピクシブ百科事典のリィンバウムのページにあったイラストから得ている。

GitHubにはすでに公開していて、Lycolia/lyndbaumに作っている。

ここまでのClaude使用量はProプランで73%だったため、かなり余裕がある。但し週の頭に無関係なことに使いすぎていた関係で次の使用量リセットまではお休みとなりそうだ。そしてGPTは完全にイマイチになってしまったので今月限りで一旦解約することにした。

GPTはGPTでWebチャットではトークンが削られないのは便利だし、ダル絡みには悪くないのだが、それで可処分時間を溶かしてもアレなので…。

現状できているもの

網羅的に書き出すと大変なのでざっくり目。

トップページ

前回の記事でもあげたとおりだが、新着コメント一覧も出るようにしている。スクショでは長すぎて見切れている。

レスポンシブデザインを前提にしているためPC/SPによるサーバーサイドの分岐はない。adiaryではUAを見てサーバーサイドから返すHTMLを分岐している。

テンプレートエンジン化しているため、レイアウトはテンプレートをいじれば変えることができる。adiaryやWordPressにあるようなデザイナは未実装。

ページングもできる。

検索

ファセット検索機能により、検索ワード・タグ・年月ベースでの絞り込み検索を実現している。

ページングもできる。

管理画面

各種管理ができる画面。

スクショにある通りのものが管理できる。

記事一覧

記事の一覧。

タグ管理

タグの管理。リネームや親の付け替え、ソートなどが出来る。UIが微妙。

記事の新規作成・編集

最低限投稿できる状態にしている。メディアブラウザはまだない。

adiary互換のMarkdownパーサーは入れており、現時点で使っているSatsuki記法にも対応している。

これはadiaryのplain-textデータとHTMLデータを突き合わせてLLMにリバエンさせて作らせたものだ。Satsuki記法については網羅的に対応できておらず、追加もできない。

複数タブで開いたときに更新が衝突しない機能も実装されているらしいが確かめていない。

ゴミ箱や履歴機能も作っているがスクショ時点では未成のため写っていない。

コメント管理

コメントの確認や削除ができる。

コメント投稿設定

これはadiaryにはない機能で、連投規制や投稿制限などを設定できる。

現状スパム対策はadiaryそのものにスパムIPからの接続を拒否するようにハードコーディングするかnginxで接続拒否するくらいしかないのでこれで楽になる。

記事投稿の設定

記事を投稿する際の設定ができる。

RSS

本文はadiaryのCDATA方式ではなくなり、categoryもカンマ区切りでなく、複数持ちに変わっている。

他にもdocsの値など、細部が微妙に変わっている。LLMが言うには最新のRSS 2.0の仕様準拠でValidに作ってくれているらしい。

まだ作っていないもの

あったらいいな～の山。やるやらはともかくとして、夢は大きく！

• 画像以外のアップロード
  • 現状テキストやHTMLとかはアップロードできない気がするため
• メディアブラウザ
  • 添付ファイルの管理をするのに必要
• マルチセッション
  • adiaryはセッションを一つしか持てず複数端末でアクセスするとログインが排他になり面倒なので、マルチセッション化したい
  • 記事更新時の衝突対策さえできれば問題ない
  • セキュリティが落ちるがログイン時にフィンガープリントを見るなどで変なのがきたらメール通知とかすれば不正ログインには対処できそう
  • セッション一覧画面から既存セッションを殺す機能や、PW変更時に全滅させるなどの対応も必要になる
• テーマ機能
  • 作るかどうかからして未定
• デザイナ
  • テンプレートの手編集がだるいので作りたいが優先度は低い
• マイグレーション機能
  • adiaryからファイルと記事を一体的にマイグレーションできるようにしたい
  • 記事自体は現状でも移行できるがファイルの移行ができていない
  • 添付ファイルについてはパス構造が変わっているため整合を取る必要がある
    • 記事やページのパス構造は維持しているため、内部リンクや外部からの被リンクはそのままでよくしてある
  • adiaryのすべてを取り込むようなことはせず、いったんは自分が使ってる範囲だけ変換できるようにするつもり
  • WordPressやMovableTypeなど、adiary以外からのCMSへの取り込みは想定してない
    • 動作確認や保守がだるすぎるため
    • 気が向けば作るかもしれないが未定
• まともな見た目・快適な操作性
  • 叩き台なので全く作りこんでいない
  • 特にタグの管理機能は使いづらいので何とかしたい
• サイトマップ
  • SEO用のXML
• 処理時間計測
  • Pukiwikiなど、昔のCGIにはよくついてたやつ。adiaryにもある
• 画像エディタ
  • 回転やトリムが出来ると便利だしあわよくばモザイクが掛けられればさらに便利
  • ペイント機能まであれば最強
  • 優先度は低い
• 記事のフラグ機能
  • 任意のフラグを設定して記事の表示時に何かをする機能、例えばNSFWフラグを立ててブラーや検索エンジン向けのメタ通知をするなど
• ログイン時の管理者メニュー
  • adiaryもWordPressもログイン中にページトップに来ると管理者メニューが出るが、まだ作っていない
  • これがないと主に記事の編集が不便
    • 記事を開いたときに編集メニューが欲しいため
• インストーラー
  • なくてもいいが、あるとより良い
  • 公開型のインストーラーはユーザーフレンドリーだが、セキュリティリスクがあるのでどうするか
    • とはいえ大抵のCGIのインストーラーは公開型である。adiaryもWordPressもMatomoも、基本的に大概はそうだ。ttrssはCLIから入れた気がする。
• パスワード変更機能
  • 新規設定は出来るが、変更はまだできない。出来ないと困る
• プラグイン機能
  • そのうち作りたい気はしている
• ページのソート機能
  • 並び変え出来たほうが良い
• OGP周り
  • SNSで共有したときに欲しいよね
  • OGP未設定の時ははてなダイアリーやZennのような奴を出したいと考えている
    • タイトルを画像に変換したやつ
• Satsuki記法の管理
  • adiaryでは任意構文を追加できるが、新CMSではまだできない
• Ping
  • 飛ばせない
• アカウント管理
  • 今のところ作る予定がないが、そのうち欲しい
  • 複数人での編集は想定しておらず、記事の限定公開辺りに使うことを想定している
    • 例えばStripeと連携して、有料記事が作れたりすると面白いかもしれない
    • やるかどうかは未定
• API機能
  • ユーザーを限定してMCPとかを走らせるのに使う想定
  • 公開APIは作らない。連打されると困るので
  • 記事に対してJSONリクエストしたときにJSON出すくらいはやっていいかもしれないが未定（MastodonやMisskeyにはある
• ActivityPub
  • 対応したいとは思っているが、無駄に拡散されても困るので悩みどころ
  • 1万フォローとかされると非同期ジョブがないと大変そうなので、そこらへんも難しそうだ
  • WordPressは対応してるんだっけ？
• VOICEBOX対応
  • 動画配信が流行ってるしあると面白いかなと思っているが、地の文を読ませても微妙なのと少なからずトラフィックを食うのでやるかどうかは未定
  • 個人的には冥鳴ひまりが好き
• あいまい検索
  • あった方がいいケースもあるかもしれないため
  • とはいえelasticsearch乗せるか…？みたいなのは思う
  • CGIには大げさなので、やるとしてもプラグインかな

作らないもの

これは要らないなと考えているモノたち。

• マルチサイト管理
  • マルチサイト管理は面倒なのでやらない
  • WordPressでやると運用が軽く地獄になる奴
  • 現状のadiaryでもバグっており、なんか機能していない記憶がある
  • この機能自体不要だと思う
  • その代わり複数のブログを外側からラップして統括管理するものは別建てで欲しいかもしれない
• WebPush
  • adiaryにはついてるようだが、私はWebサイトに通知は不要だと考えているため付けない（Webアプリにはあってよいと思う）
• 印刷画面
  • ユースケースが思いつかない
  • アクセス解析を眺めているとBOTがここに吸いこまれる傾向が非常にある
• Markdown以外のパーサー
  • adiaryはreStructuredTextやTeXに対応しているが、これは取り込まない
  • Markdownについても私が使っている構文しかサポートしない
    • 仕様上はかなり理不尽なレベルで存在すが、対応していると大変すぎるため基本的にPrettier v3が補正して出てくるやつで私が過去に使ったことがあるものをベースにパーサーを作ることにしている
• トラックバック
  • adiaryには機能そのものがない
  • かつてのスパムの温床であり、今時実装するようなものでもない
• Webmention
  • トラックバック同様の理由で対応しない
  • そもそも他人の抱く感想に興味がない
    • SNSで空リプが増えたのも相手の気分を害さないことが大きいだろう
    • 文脈を共有していない意見と言うのは概して害悪であることが少なくないと思う
• 非公開コメント
  • ブログのコメント欄をメールボックスにしたくないため

切り捨てるもの

過去との決別。

• 非公開コメント
  • かつて運用上非公開コメントを廃止したが、移行時にはこのコメントデータを切り捨てる予定

設計上の理念

設計にあたり重視したコンセプト。

依存関係の最小化

依存関係地獄を防ぎたい。pnpm iもcomposer installもbundle installもpip install -r requirements.txtもしたくない。打つのが面倒だしフックの脆弱性対応とかそういうの要らない。

よくあるCGIのように置いたら動く、というシンプルさが欲しい。流石にPerl本体だけでは厳しいがpure Perlで動けばいいと思っている。なので標準にないCPANモジュールも使わない。

動的生成

回線環境が劣悪な場所で使うことが多いため、レスポンスデータは小さくあってほしい。

静的生成だとどうしても初回リクエストのデータが肥大化しがちだ。登山中やトンネル、人口密集地など電波の悪い場所で検索用などの巨大なJSONが送られてくると困る。

ランタイム保守コストの最小化

ライフサイクルが早く後方互換性を切り捨てまくるPHPは保守が面倒だし、Node.jsもメモリリークの問題があるので避けたい。Pythonはvenvの概念がだるすぎる。Ruby？そんな奴は知らん！

という訳でPerlを採用。Perlは枯れており、構文が腐り果てている関係で相当古代のものが今でも動くし、テストランナーも内蔵されていて便利だ。大概のものが本体にバンドルされている上に、後方互換性も破壊的変更も私の用途ではほとんど気にしなくてよい。とはいえ、Perl 5.32.0を要求バージョンの下限として定めている。

5.40.0でパフォーマンスが上がっているのと、JSON::PPやCPAN::Meta::YAMがアップデートされているらしいので、これを採用したい思いもあるが、5.40.0なんてUbuntu 26じゃないと動かないし、ちょっと早すぎる。とはいえ2024年のリリースなので2年前のバージョンではあるが…。まぁPerlなんてそんなもんだ、古くてなんぼ！

ビルドなし

手元でサッと書き換えれば動くこと。手間なのでコンパイルやビルドはしたくない。TypeScriptやRubyもスクリプトの分際でビルドがあるし、GoやRust、C#.NETは言わずもがなだ。

Perlであれば書き換えれば即座に動く。とても便利だ。

高度なレガシー検索

膨大な記事を抱える本ブログでは絞り込み検索は必須である。ワーディングで記事が見つかれば苦労しないし、あいまい検索で関係ない記事がヒットするのにうんざりするのはごめんだ。

シンプルであること

adiaryはとてもシンプルなので、そのシンプルさは保ちたい。2ペインのMarkdownプレビューやパーマリンクの変更と言った凝った機能は載せない。

adiaryやPukiwikiのようなシンプルなシステムをリスペクトしたい。CGIであることもその一つだしDockerもk8sもMySQKもPostgreSQLもRedisも、変な依存ライブラリも要らない。

あとがき

ClaudeのProプランでも全然余裕で作れるのでOpus 5.5には非常に助けられている。このCMSの開発だけに使っている限りはトークンが尽きる気配はない。何なら開発に入る前に無駄な雑談で週次トークンの25%ほど削っていたが、それでも今の目測ではギリギリ足りる算段である。

他人が使うことをどれほど想定するかも決めていないが、ひとまずは最低限自分が使える程度のものには仕上げていきたい。配布物とする場合CGIなので最低限さくらのレンサバはサポートしたい考えで、現時点でも非機能要件にさくらのレンサバで動くことを設定している。

ある程度出来てきたら、このシステムを核としてWikiやタスク管理などのシステムにも派生させていき、エコシステムを形成していきたいと思っている。

全く関係ないが、気が付いたら記事IDが800を超えていた。記事数は764件らしい。

経緯

2024-02-01にCMSをWordPressからadiaryに乗り換えたが、adiaryには不満も多くあり、過去の記事でも改修ネタをいくつか出していた。

しかしadiaryは結構作りが古いこともあり、手を入れるのが大変という問題があった。そこで私は前々からCMSの新製を考えていたのだが、これが中々腰が重かった。

adiaryの機能一覧を作ろうとして途中で飽きたり、Markdownパーサーを自作しようとして飽きたり、そんなのばかりだった。

しかしそんな日々にも転機が訪れた。それはClaude Opus 5.5の登場とBANされたAnthropicのアカウントを力業で復活させたことである。私は従来のコーディングエージェントには満足しておらず、ぶっちゃけバイブコーディングとかクソゲーのガチャだと思っていた。しかしOpus 5.5はこれまでと明らかに違った。上手く扱えばハルシネーションは少なく、エンタープライズシステムでもそこそこの品質でやってくれる。

実はGPT-5.6 Solもそれなりに出来が良く、ある程度のことはできたのだが、Opus 5.5は次元が違った。かなり自律的に開発してくれて、正直私より出来がいいんじゃないかと思うほどだ。認めざるを得ない、敗北を、みたいな感じである。

エージェンティックコーディングの進化は目覚ましいもので、これまではしょっぱいツールやパッチレベルのものを作るのに活用していたが、これからはまさになくてはならない存在だと、そう感じるほどの進化を遂げている。同時に私の存在意義と職も怪しくなった。

あとがき

弘前日記は書けてないし、他にも書こうと思っている記事があったり、他にもしないといけない事やしたいことがある気がするのだが、ひとまず鉄は熱いうちに打てと言うことで何とか完遂させたいところだ。

現実問題としては並行でいろいろやって、ズルズルだらだら行く可能性もあるが、それはまぁそれと言うことで…。

とりあえず今日やっていて分かったこととして、私は基本的にMarkdownを書くときにPrettierで整形しているため大半の記事は上手いこと正規化されており、微妙な書き方の違いによる崩れなどがあまりなさそうだったというのは幸いだなと思った。これはOpus 5.5が書いた検知ツールをベースに確認している。

それでも壊れているのがあったので直したし、マイグレーションの歴史的経緯によって単純に壊れているものが新たに何個か見つかったので、そこらへんも潰しておいた。

LLMは嘘をつくことがあるが、ツールは嘘をつかないので安心と言う話である。

バグ修正

YoutubeのIDにハイフンがあると正しく出ない問題の修正

https://github.com/Lycolia/adiary-extends/commit/429e54b47a530f4354e45c050f8ad6f0da2fe5e3

以下の問題のパターンが表示できなかったためこれを出来るようにした。

数字リストが2桁になるとコードフェンスのネストが機能しなくなる問題を修正

https://github.com/Lycolia/adiary-extends/commit/5b90f22bb557871f44cbad33ca6b3429e368463c

インデントの処理を直した。元の処理は桁数が増えたことによるインデント幅の増分が取れなかったので、取れるようにして解決した。

修正前	修正後

リストにネストされたテーブルが表示されるようにした

https://github.com/Lycolia/adiary-extends/pull/75/changes/a476eab24cedf3520bdab61b0cf8ee7d76fbe5a6

次のような構文でテーブルが出るようにした。

- hoge
  |col1|col2|
  |----|----|
  |row1|row2|

`` foo ` bar ``が正しくコードスパンにならない問題の修正

https://github.com/Lycolia/adiary-extends/commit/6c95f8edea6e65f93b1a1a4d3917c7ed4bbd2d27

遭遇するたびに<code>で書いてた記憶があるが、しなくてよくなった。

修正前	修正後

チェックボックスリスト周りの抜本的な修正

https://github.com/Lycolia/adiary-extends/pull/75/changes/6dc02a3ffd6e835189d05eaffbc4dcf0a1fb9e16

チェックボックスに構文の文字がそのまま出る不具合や、リストマーカーが出る問題などがあったため、全体的に直している。そもそも使った記憶がなく、本家も使うことをろくに想定していないと思うため、対応する必要性は謎であるが、まぁ取り敢えずほら、構文としてあるし？みたいな？

修正前	修正後

リストで深い入れ子から浅い段へ戻るケースの一部が処理できていなかったのを修正

https://github.com/Lycolia/adiary-extends/commit/4ac398ed30adcd0a10304dc815985ec7af035da3

一部のケースで入れ子が深くならず、浅い段に復帰するときの深さで固定されているケースがあったため、それを直した。

具体的にはこれの最後の奴らが3段目のインデントに全て収束し、4段目のインデントが起きない問題があった。これはどうもケツに3段目がいるせいで、そこに引っ張られていたらしい？

- `-protocol_whitelist "tcp, udp, ..."`
  - カンマ区切りでプロトコルを指定することで、プロトコルを利用できるようになる
  - https://ffmpeg.org/ffmpeg-protocols.html#Protocol-Options
  - SDPファイルを用いてRTPストリームを受ける場合には `"file,udp,rtp"` を指定する
    - file
      - ローカルファイルへのアクセスプロトコル
      - <https://ffmpeg.org/ffmpeg-protocols.html#file>
    - udp
      - UDP
      - <https://ffmpeg.org/ffmpeg-protocols.html#udp>
    - rtp
      - RTP
      - <https://ffmpeg.org/ffmpeg-protocols.html#rtp>
    - なんでfileがいるのかは正直良くわかってない

機能改善

邪魔なヘルプの削除

https://github.com/Lycolia/adiary-extends/commit/196b8d75ecfc4001a192b7b83893f8987bb60f29

adiaryのヘルプはマウスオーバーで出るのだが、出たはいいもののどこかをクリックしないと消えないことがあり、しかも他のUIの手前に出てくるのもあり記事を書いててめちゃくちゃ邪魔だったので消した。

タグ入力をインクリメンタルサーチできるように修正

https://github.com/Lycolia/adiary-extends/commit/07516010985f18506b3b6fafb419fe3fd1d7ab4b

今回の目玉コンテンツその１！！！

タグを探すのが面倒だったので楽にできるようにした。うちは地獄のようにタグがあるので面倒で面倒でもうやってられなかった。そもそも何のタグがあって何のタグがないかもわからないし、限界だった。

変更前	変更後

多重拡張子のアップロードを許容するように変更

https://github.com/Lycolia/adiary-extends/commit/5e4b49f7f9f0a27f9531856aeed3048460da085b

今回の目玉コンテンツその２！！！

photo.edited.jpgのような名前を持つファイルがアップロードできるように対応した。多重拡張子になっているファイルをアップロードしようとしてエラーになった回数は計り知れない。

これまでは恐らくセキュリティ対策で規制がかかっておりhoge.php.jpgと言ったものがアップロードされたとき、Apacheの設定によっては不正にphpが実行される恐れがあった。で、そこを過度に恐れるあまりhoge.edited.jpgみたいなのも弾かれる状態になっていた。

今回はその対策として拡張子以外のピリオドをアンダースコアに改名してアップロードすることで対処している。hoge.edited.jpgならhoge_edited.jpgでアップロードされるみたいな。

記事中の画像からサムネイルを選べるようにした

https://github.com/Lycolia/adiary-extends/commit/1246e9b7fdd115e9cdb9f381a5d0c8bef1be07d5

今回の目玉コンテンツその３！！！

実はadiaryにはOGPを任意設定する機能がない。記事中を文字列検索してパターンにマッチしたものが自動でOGPに設定されるのが仕様だ。

そこで過去にv0.2.0で任意の画像をサムネイル（OGP）に設定可能にしたが、元々あったロジックを流用して実装した関係で、色々煩雑だった。これは特定のフォーマットで入力する必要があるのと、入力ミスで存在しないURLが埋め込まれることがあったためだ。

なので私は手打ちしたときは毎回OGPを手動確認してちゃんと出るか見ていた。しかしこれが面倒だった。なので今回は任意のOGPを選べつつ、入力ミスも起きないスーパーウルトラハッピー仕様にしたわけだ。

この機能の追加に当たり記事中の画像のみを選択対象にしたため、それ以外も設定できる脱出ハッチとして従前の手設定も一応残しているが、個人的に利用した実績がないため、使うことはない気もしている。

記事外の画像を入れる場合は、これまで通りの方法で指定して解決する。

記事に膨大な画像があると膨大に出るが、まぁ別にいいかと言うので放置することにした。

記事から画像が消えるとどうなるかについては試していないが、従前のままなら選択肢からは消えるものの、手設定欄に残っているはずである。動作確認はしていない。

記事のごみ箱と更新履歴機能を追加

https://github.com/Lycolia/adiary-extends/commit/3f5f203624e564015195dd18e2dabacf6955108d

今回の目玉コンテンツその４！！！

記事を誤って消したが戻したいとか、間違えて別の記事で上書きするなどのミスをしばしばしていたので、この対策として復旧できる機能を追加した。

特に過去記事からコピペして別の記事に移植する作業中に移植先と移植元を間違えるなどで頻発していたので、その対策。

履歴はPukiwikiを参考に既定では原則最終更新から3h経過で積むことにしている。ゴミ箱についても、消したけど戻したいということが年に一回くらい起きていたため、機能追加した。

通常の画像構文で<figure>にラップされるのをされないようにした

https://github.com/Lycolia/adiary-extends/pull/75/changes/61d287986ed812126f3b72b0482e2fb9a476ac90

基本的にはセマンティクス違反の解消。但し根絶はしておらず、条件次第で許容している。

今までは<img>の描画時に<figure>でラップしていたため、画像の多い記事は若干軽くなっているはず。

イメージとしてはこんな感じ。

- <figure>
    <a href="..."><img src="..."></a>
- </figure>

その他

その他Markdown周りとして、リポジトリの変更履歴などには書けていないが、恐らく細かい部分が色々改善したはず。正直実装面はClaude Opus 5.5に投げたため、どこまで変わったのかよく分かってない。

取り敢えず使っていない構文の切り捨てを指示したが、差分を見た感じ切り捨てられているかは謎である。まぁ別に使ってない構文だしどうでもいいのだが…。軽く見た感じのデグレはなさそうなのでヨシくらいで見ている。

Markdown処理に関するドキュメントとテストコードの追加もしたが中身は流し見程度しかレビューしていない。

あとがき

更新が多いためマイナーバージョンを12も上げている。そのうち10は一気に上げた。0.30.0->0.40.0->0.41.0->0.42.0みたいな。

Claudeの契約はProだが、今回の対応ではClaude Codeの週制限の25%しか使わなかった。やった規模感のわりに、全然余裕だなぁという感じ。作業時間としては動作確認とレビュー込みで5時間くらい。

この改造版はGitHubで公開しているものの、私以外が使うことは特段考慮していないため、使いやすいかどうかは謎である。少なくともテーマは完全に今表示しているものにロックインしており、他のテーマで使えるような作りにはしていない。

また今回の対応に当たり、古い記事を中心に構文の揺らぎがあったため以下の記事に対して構文の正規化を掛けている。このため、内容に本質的な変化はないがタイムスタンプの更新が入っている。

• ffmpegを使ったRTP配信の備忘録
• AURAが起動しない問題を解決した話
• 【ラグマス】WSのステやスキルとかについて
• Raspberry Pi 4のセットアップメモ
• npmコマンドの作り方
• 実はCGIってCLIアプリなのでは？と思ったので試してみた
• TextInputHost.exeが無限に起動する問題を対処した
• 久々にC#でコードを書いてみたらテスタブルなコードを書くのが難しくて諦めた話
• Windows 11が0xc000000eで起動しなくなったのを直した
• TypeScriptでNode.jsのローカルライブラリを作る
• YAPC::Hiroshima 2024に参加してみた
• Xubuntu環境でThunarを使ってSSHをマウントする
• 今日のサイト改築の話とかadiary改造の話とか
• MSYS2のGitを高速化する

今回は数が多いのでこのように書いているが、普段から巡回で構文が壊れている記事を見かけたらひっそり直しているので、まぁよくあることではある。

現存している記事でadiary移行前からあるものは、モノによってはWordPress→Qiita→はてなブログ→WordPress→adiaryという過酷な移行をたどっているため構文が壊れていることはざらにある。何なら今回の対応ではてなフォトライフの参照構文を一つ見つけ消したくらいだ。

しかしまぁ先日BANされたAnthropicのアカウントを力業で復活させたのが、さっそく効果を発揮してくれて頑張った甲斐があったというものである。それと従前は個人的なプログラマーの矜持的に、AIコーディングに否定的だったり、余り肯定的でなかったこともあったが、使っているうちに使わざるを得ないなと言う気持ちが高まってくるし、もはや使わないということは無理があるだろうなぁと思えてきた。

とはいえ、たまには手でかくと言うのも忘れないようにしていきたい。GTP-5.6 SolやOpus 5.5がだいぶ優秀になってしまった関係で気を抜くと忘れてしまいそうだが、読めるからこそレビューが出来ているし、やらないと忘れてしまうし、ここら辺は難しいところだ。