Lyndbaum v4.36アップデート

投稿：

adiary置き換え計画始動から連なる、Lyndbaum v4.35アップデートの続き。

今回は改善系の対応を行った。

画面表示時のスケルトン探索処理の効率化

本家と比較したときにパフォーマンスが劣化しているの対応で原因調査をしていたら、スケルトン探索処理の問題が原因だったため、そこを直した。

具体的にはテンプレートエンジンが呼び出しているパーツの探索を効率化した。adiaryのテンプレートエンジンはスケルトンと呼ばれるファイルで管理されており、動的表示のためにサイドバーにあるモジュールや記事、ページのフレームなどの単位でスケルトンが分割されている。

そしてこのシステムは標準スケルトンとテーマスケルトンに分かれており、テーマスケルトンで標準スケルトンを上書きするという振る舞いをしている。Lyndbaumではレスポンシブデザインに適用させるためスケルトンの分割方式を変えていてスケルトンファイルが従来より増えている。

adiary本来の処理では、標準側とテーマ側でファイルがあるかを1つずつ確認していたため、スケルトンファイルの増加によりシステムコールの回数が増えてパフォーマンスの劣化に繋がっていた。今回はこの方式をやめ、何のスケルトンがあるかのキャッシュをあらかじめ作っておき、無駄な探索をしないようにした。

その他細かい無駄な処理を見直し微妙に早くなるようにしている。

FCGIモードでの比較

改修の前後でFCGIモードで極力条件をそろえた状態でベンチマークをとった結果が以下だ。

前提としてadiaryはsatsuki2/satsuki2テーマ、Lyndbaumはlyndbaum/lyndbaumテーマを使っており、記事数もadiaryよりLyndbaumのほうが若干多いため、ベンチマーク的にはadiaryのほうが有利な状況になっている。

またベンチマーク方式はadiary公式の方式に可能な範囲で合わせている。但し計測したマシンについては以下の通りスペックがだいぶ異なる。

構成 製品 備考
OS Ubuntu 26.04.1 LTS
Perl v5.40.1
CPU AMD Ryzen 5 8500G 6C12T 3.5GHz TDP65W
MEM Crucial CP2K16G60C36U5W DDR5-6000 16GB * 2
Storage Crucial P1 CT500P1SSD8JP NVMe SSD 500GB

FCGIモードでのベンチスコア

今回の測定結果としては本家より早くなった。計測はサービスを再起動して即座に測定したが手動操作なので起動経過時間で見ると数秒の誤差がある。

ローカルで実行しているため通信のオーバーヘッドは極めて少なく、極めていい値が出ている。これは本家のベンチスコアも同様だろう。

CMS Ver abコマンド req/s 平均応答(ms)
adiary v3.52b ab -n 2000 -c 100 -l 1184.12 84.451
adiary v3.52b ab -n 100 -c 1 -l 294.8 3.392
lyndbaum v4.35 ab -n 2000 -c 100 -l 1091.55 91.613
lyndbaum v4.35 ab -n 100 -c 1 -l 225.67 4.431
lyndbaum v4.36 ab -n 2000 -c 100 -l 1375.58 72.697
lyndbaum v4.36 ab -n 100 -c 1 -l 291.23 3.434

CGIモードでの比較

CGIを実行する環境がないので、さくらのレンタルサーバー上で動かしているのをローカルのabから叩いた結果になる。さくらのレンタルサーバーにはabが入っていないのでローカルから叩くしかなかった。

テーマや記事データなどはFCGI版と同じ条件でやっている。

また実装の修正と検証に時間がかかった関係で、同一時刻での計測ができておらず、結果は余りあてにならない。一応同じ時間帯にadiaryとlyndbaumの比較はしているが、手間の関係でlyndbaumのバージョンアップ前後での確認は飛ばしている。

Perlのバージョンはv5.32.1だった。

CGIモードでのベンチスコア

リモートサーバーに繋ぎに行っているため-kでKeepAliveを有効にしている。

見た感じは改善してそうだが、通信のオーバーヘッドが入っているほか、CGIの起動時間が重いこともあり、数値の信憑性は怪しい可能性がある。しかしそれでも明らかに遅いように見えたのが僅かに早くなったので満足した。

CMS Ver abコマンド req/s 平均応答(ms)
adiary v3.52b ab -n 2000 -c 100 -l -k 306.69 326.06
adiary v3.52b ab -n 100 -c 1 -l -k 11.16 89.635
lyndbaum v4.35 ab -n 2000 -c 100 -l -k 311.13 321.406
lyndbaum v4.35 ab -n 100 -c 1 -l -k 11.43 87.489
adiary v3.52b ab -n 2000 -c 100 -l -k 263.89 378.945
adiary v3.52b ab -n 100 -c 1 -l -k 5.23 191.33
lyndbaum v4.36 ab -n 2000 -c 100 -l -k 268.2 372.851
lyndbaum v4.36 ab -n 100 -c 1 -l -k 5.43 184.152

ベンチマーク測定元ソース

記事に出したベンチマークスコアの元ネタ
CMS 走行時間 Ver モード 記事数 コメント数 タグ数 並列数 件数 keep-alive 失敗 req/s 平均応答(ms) Connect平均 TTFB平均 50% 95% 99% 最大 ab
adiary 12時くらい v3.52b CGI 766 71 208 100 2000 あり 0 306.69 326.06 4 301 54 2434 4944 5289 ab -n 2000 -c 100 -l -k
adiary 12時くらい v3.52b CGI 766 71 208 1 100 あり 0 11.16 89.635 12 60 87 110 293 293 ab -n 100 -c 1 -l -k
lyndbaum 12時くらい v4.35 CGI 779 70 208 100 2000 あり 0 311.13 321.406 4 294 68 2246 4707 5020 ab -n 2000 -c 100 -l -k
lyndbaum 12時くらい v4.35 CGI 779 70 208 1 100 あり 0 11.43 87.489 12 62 87 106 227 227 ab -n 100 -c 1 -l -k
adiary 12時くらい v3.52b FCGI 766 71 208 100 2000 なし 0 1184.12 84.451 31 13 81 95 127 139 ab -n 2000 -c 100 -l
adiary 12時くらい v3.52b FCGI 766 71 208 1 100 なし 0 294.8 3.392 1 2 3 4 4 4 ab -n 100 -c 1 -l
lyndbaum 12時くらい v4.35 FCGI 779 70 208 100 2000 なし 0 1091.55 91.613 18 9 93 105 143 165 ab -n 2000 -c 100 -l
lyndbaum 12時くらい v4.35 FCGI 779 70 208 1 100 なし 0 225.67 4.431 1 3 4 5 5 5 ab -n 100 -c 1 -l
adiary 22時くらい v3.52b CGI 766 71 208 100 2000 あり 0 263.89 378.945 8 340 80 2866 5532 5800 ab -n 2000 -c 100 -l -k
adiary 22時くらい v3.52b CGI 766 71 208 1 100 あり 0 5.23 191.33 30 96 134 487 1275 1275 ab -n 100 -c 1 -l -k
lyndbaum 22時くらい v4.36 CGI 779 70 208 100 2000 あり 0 268.2 372.851 9 323 59 2070 5642 5814 ab -n 2000 -c 100 -l -k
lyndbaum 22時くらい v4.36 CGI 779 70 208 1 100 あり 0 5.43 184.152 28 91 113 501 734 734 ab -n 100 -c 1 -l -k
lyndbaum 22時くらい v4.36 FCGI 780 70 208 100 2000 なし 0 1375.58 72.697 31 13 69 83 117 130 ab -n 2000 -c 100 -l
lyndbaum 22時くらい v4.36 FCGI 780 70 208 1 100 なし 0 291.23 3.434 1 2 3 4 4 4 ab -n 100 -c 1 -l

Lyndbaumテーマで記事タイトルの頭に線を引くようにした

なんとなく記事の境目が分かりづらいなという気がしていたのでマークをつけてみた。本当は横線を上にひこうと思っていたのだが、なんかいまいちだったので頭に縦線を引くことにした。

変更前 変更後

HTTPクライアントをIPv6対応にした

なんとadiaryのHTTPクライアントはIPv4にしか対応していなかった。このため自宅サーバーで自分のドメインに対してHTTPクライアントを実行すると確定で繋がらない問題があった。

IPv6に対応させることでこれを解決した。また拒否IPリストもIPv6に対応させたため、v4.34で行った制限でv6が漏れていた問題にも対応した。

ポートは80か443以外の疎通を許可していないので、妙なポートが疎通することはないが、認証をかけていなければ開けてしまうのでGrafanaやPHPMyAdminとかはちゃんと保護してないと疎通してしまう。そもそも管理コンソールが外から開ける時点でおかしいので、最低でもBasic認証くらいは掛けていてほしいが…ｗ

[&https://]記法でOGカードを出せるようにし、正しく出ないものについても解消した

[&https://]記法で正しく動かないケースがあるの解消。元々この対応をする過程で一個前の課題が浮上したのだが、こっちも不具合とそれとは別の不満があり、直すことにした。

まずこの記法はリンクを書く手間を減らすためのもので、リンク先によってはリッチに出せるものだったが、基本的には[サイトタイトル][https://example.com]のショートハンドでしかなかった。

そしてGitHubを指定するとリッチに出るはずだったのだが、どうにもバグっており[&https://github.com/Lycolia]と書くと<script src="https://gist-it.appspot.com/github/Lycolia"></script>が出力される状態だった。悪意のあるスクリプトが出てきたら即死するところだった。

元の仕様がイケてないのと超ド級のヤバ不具合があったため、リンクカードを出せるようにし、scriptタグが入らないようにした。scriptタグの検査は見た感じ甘そうだが、構造上滅多に入らないと思うので一旦放置している。

あとがき

ベンチマークをとる環境の整備とベンチマークの記録と実際の動作確認やら記事向けに余計な情報を取捨選択するやらなにやらで今回の対応はだいぶ疲れた。正直途中で止めて日曜コミットしようかと思ったが、気合で土曜中にやり切った。

お陰でv4.34アップデートのあとがきに書いたとおり、五年半ぶりにGitHubの草を縦に繋げることができた。このためだけにv4.36に乗せるものを減らしたくらいだ。23時にFixさせると絶対に間に合わないので可能な限り19時、遅くとも21時Fixを目指したが、結局余計な機能をねじ込んでしまいFixは22時になった。それでも何とか土曜中にPRを収めマージしきったので何とかなった。手前で映画鑑賞録なんて書くから…

Go製CGIで触っていて明らかに早かったSerene Bach v4でのベンチマークもとって比較しようと思ったが、データコンバートが面倒なのと、へとへとなのでそこは取りやめにした。そもそもバイナリにスクリプトが勝負しても仕方ない。

CGIはコードが読めて中身に変なものがあっても直せるのが売りなので、それを許さないことで高速化を達成しているものと比較しても仕方がない。

コメント（0件）

グロテスクを観てきた。

投稿： 更新：

映画『GROTESQQQUE-グロテスク-』を観てきたのでその感想。

GROTESQQQUE-グロテスク-のフライヤー

本作を観に行ったきっかけは、このフライヤーだ。特に最下段の金髪のキャラクターが非常に気になったので観に行くことにした。

フライヤーは表紙しか見ておらず、それも文字はタイトルしか読んでおらず、事前知識として本作が三作品から構成されるということを、うっすら認識していた程度だ。三角だったりQQQとQが三つ並んでいるのも、そこを暗示しているかのようで面白い。

全作品に共通するのは舞台が東京で、特に渋谷109や東京駅といったアイコニックな場所をよく出しているところがあるなと感じたところだ。池袋が出てきたような気もしたが、ちょっとここは怪しい。

全体としてはすごく映画らしい映画で、Ep1のエリィアンズの疾走感や、芸術的な表現がありつつもダイナミックな動きは特にスクリーンで観る映像体験として楽しめた。ただその一方で中身が驚くほどなく、たぶんメッセージ性とかはなかった。また作画の品質差が作品によって激しく、音響にも力が入っていないように見えたので、B級作品を集めて、疾走感のある作品に仕立てたような雰囲気を感じた。

Ep1: エリィアンズ

開幕するとまずこの作品から始まる。グロテスクとは一体何なのかというくらいあっさりしたムービーが続くのもあり、個人的には最もグロテスクから遠いハートフル作品に読めた。

主人公がビルから落ちて形を失う、溶ける、銃撃されても穴が開くだけといった描写があるので、ここだけ切り取ればグロテスクなのだが、描写が非常にコミカルなので個人的にはグロテスクというよりはポップに映った。

全体を通して背景の解像度が低く、どうにも低画質の画像を引き延ばしたような画づくりと、パステルでビビッドな色使いから、全体的に平成を意識することが多かった。

また主人公の動きを見ていると、どことなくアラレちゃんのようなノリを感じた。衝動性というか支離滅裂性というか。髪色や眼鏡かけてたり走り回ってるのもそれっぽいと思う。

巨大化して街を飲み込んだり、ものを取り込んで変換して吐き出す、平成ギャル～やや地雷系が出てくる表現からも、どことなく平成を感じる作品だった。

全体的にはバトルがあるものの、ポップでギャグテイストな平和な作品で最もグロテスクから遠い、突き出しのような作品だった。また凄くアートな雰囲気を感じたが、前衛芸術というほど突き抜けていなかったので中衛芸術といったところを思った。

本作は錦織敦史氏が監督から脚本やキャラクター原案、エピソードディレクションまでやっており、美術監督を入れてあるだけあり、非常に完成度が高くなっている。

Ep2: 夜露死駆★少女

いきなり場面が急転し、謎の殺し合いが始まる。導入が唐突すぎて割とかなり意味不明だった。

どうやら昭和～令和のギャルを軸に展開するVRMMOが舞台のようだったが、現実を意識するシーンが少なく、仮想空間性はほとんど感じられなかった。

登場人物はスケバンからガングロギャル、ヤマンバから地雷系少女まで、象徴的なギャルが多かったがなんかどこかのミコッテにしか見えないのもいたような…。

ストーリーの流れは割と謎で取り敢えず、PvPで戦うギャルたちが過去に消えた象徴的アイドルを取り戻すために結束し、結果助けるみたいな流れだけはわかった。

PvPなので人が死ぬという意味ではグロテスクかもしれないが、見てる感じFPSゲームとMMORPGを掛け合わせたような感じで流血はなく、死ぬときは光になって消えていくやつに近かったので、グロさは皆無だった。呪術廻戦のほうが遥かにグロい。

猫の被り物をした「名無し」と呼ばれる少女は設定込みでかなり好きだったし、青髪の剣士も好みだったので、MMO好きとしては楽しめる作品だった。特に被り物をして正体を隠すというのは超かぐや姫！のいろはにも通じるところがあり、かなり好みだ。ただストーリーが激変しまくる上に突拍子もなく話の跳躍があるので、内容としては最もよくわからなかった。

本作だけキャラデザやエピソードに錦織敦史氏が噛んでおらず、全体的に異質になっている。

Ep3: ノクターン〜このグロテスクな夜に〜

遂に三作目、ここの導入は非常にスムーズで分かりやすかった。結論から言うと最もグロテスクな作品だった。サブタイトルにグロテスクとあるだけはある。

3作の中では最も中身があり、ストーリーに深みと重さがあり、考察の余地があると感じたが、何せ1回の上映で3作品やっている関係で尺が短く、どうにも浅いというか、掘り下げ切れていない感じはした。

フライヤーに描かれていたキャラクターの作品でもあり大きな期待をしたが、残念ながらあの美麗作画が出てくるのはごく一瞬の話で、ほとんどのシーンでは作画が地上波アニメの平均値レベル程度に収まっており、だいぶ期待を裏切られた感じだ。

ここのグロテスク要素は、ほとんどの人類が滅びた世界で、吸血鬼と吸血鬼に食われ不死の身体を得た少女たちが身内同士での殺人を目的とした暗澹たる食人行為をはじめとしたSAN値を削られるような精神的なグロさが出てくること、そして何より人を食い、食い返されたヒロインの死があることだ。

本作はPG12がかかっているが、恐らくこのエピソードがその原因だろう。他は些細なもので到底年齢制限など必要なものではなかった。

ただ観ていた中で最も醜く、そして美しいストーリーがあると感じたので、全三作の中では一番好きな作品だった。

本作も監督とエピソードディレクター・キャラクターデザインは錦織敦史氏だが、スタッフリストが3作中最も少なく、このボリュームの差が作画の不安定さを象徴しているように見えた。

あとがき

今回は2024年8月12日ぶりにOSシネマズ ミント神戸での鑑賞となった。2026年11月6日の鑑賞なので、816日、2年2ヶ月25日ぶりだ。

普段は運動不足解消のためと、そもそもミント神戸はアニメをあまりやらないのもありハーバーランドのほうで観ることが多いのだが、ちょっと昨今色々なものが立て込んでおり時間がないため、珍しく家から近いミント神戸での鑑賞となった。運動不足を少しでもなくすため徒歩で向かった。

しかし2年もミント神戸で映画を見ていないのは驚いたし、よくも毎回ハーバーランドまで行ってるなと我ながら感心した。

OSシネマズ ミント神戸からJR三ノ宮駅を見下ろすと駅ビル工事がだいぶ進展しており、地下の構造物がだいぶ分かるようになっていた。これからどうなっていくかが楽しみだ。

コメント（0件）

Lyndbaum v4.35アップデート

投稿：

adiary置き換え計画始動から連なる、Lyndbaum v4.34アップデートの続き。

今回はバージョンが0.1しか増えず、控えめなアップデートとなった。内容としては15ファイルの変更と131行の追加、178行の削除があった。追加行107行はGitHub ActionsのWorkflowファイルなので実質削除が本丸である。

今回の変更

変更内容はページキャッシュ機能の削除のみ。この機能はページが表示されたときのHTMLキャッシュをCMSのメモリに持ち、次回アクセス時にキャッシュヒットさせて返す仕組みだった。

しかし動的要素が返せないなどの問題があり、潜在不具合がありそうなので私は使っていなかった。そもそも使わなくても早いというのもある。

CGIモードでは使えない機能ということもあり、機能削減の一環として削除した。機能が少なければ少ないほど保守が容易だし、必要になれば復活させることもできるため削除した。

今後の機能開発予定

今回の対応は少なかったが、やりたいことはまだまだ多くあり、たぶんこれ以外にも日々湧いてくるのでやることは全く尽きていない。

あとがき

Claudeが出したベンチマークスクリプトでは劣化はないことになっていたが、本家の計測指標で使われていたApache Benchを使うと明確な劣化が認められたので、次はここを潰していきたいところだ。

参考までに計測結果を以下に残す。

計測結果

名前 計測コマンド 並列数 件数 失敗 req/s 平均応答(ms) Connect平均 TTFB平均 50% 95% 99% 最大
adiary v3.52b ab -n 2000 -c 100 -l 100 2000 0 1184.12 84.451 31 13 81 95 127 139
adiary v3.52b ab -n 100 -c 1 -l 1 100 0 294.8 3.392 1 2 3 4 4 4
Lyndbaum v4.35 ab -n 2000 -c 100 -l 100 2000 0 1091.55 91.613 18 9 93 105 143 165
Lyndbaum v4.35 ab -n 100 -c 1 -l 1 100 0 225.67 4.431 1 3 4 5 5 5

計測したマシン

構成 製品 備考
OS Ubuntu 26.04.1 LTS
CPU AMD Ryzen 5 8500G 6C12T 3.5GHz TDP65W
MEM Crucial CP2K16G60C36U5W DDR5-6000 16GB * 2
Storage Crucial P1 CT500P1SSD8JP NVMe SSD 500GB

また、内容はまだ確認できていないがPageSpeed Insightsの結果も作ったので後で見れるよう残しておく。

コメント（0件）

Lyndbaum v4.34アップデート

投稿： 更新：

adiary置き換え計画始動から連なる、Lyndbaum v4.26アップデートの続き。

わずか二日でバージョンが0.8も増えた。直近で散々書いてきた、やることがなくなってきたとは一体何だったのか…。

今回は機能削除とセキュリティ対応、デグレード対応を主に行い、182ファイルの変更と4,659行の追加、4,585行の削除があった。

セキュリティ対応

ディレクトリトラバーサルができた問題を修正

特定の条件で..が指定されたときにCGIのルートフォルダなど本来アクセス出来てはならない場所を操作できる問題を修正した。

ソケットが777で保存される問題を修正

660にし、ユーザーとグループしか見れないようにした。

HTTPSでアクセスされたとき、CookieにSecure属性を付与するように修正

何も属性がついてなかったため。

セッションIDが予測可能だった問題を修正

rand()からPOSIXの乱数器に変更。

有害なタグを使えないように修正

管理者自身が自ら脆弱性を埋め込む可能性があるのを回避した。

これによってよく知らないスクリプトをコピペで記事などに埋め込んだ時に管理者が自滅するのを防止する。

lyndbaum.httpd.plを削除

nginxやApacheにさえ無限の脆弱性があるのにadiaryのhttpdに脆弱性がないはずがないと思って検査したところ無数の脆弱性が出てきたので削除した。

デバッグ用に残すことも検討したが、デバッグ時に脆弱性や不具合にぶつかったときに、その由来がhttpdか本体か区別できないため残さないことにした。

プライベートモードの削除

プライベートモードを突破できる脆弱性がいくつかあったため機能削除した。

プライベートにする場合、サーバー側で認証をかければ済む。

複数ユーザー機能の削除

管理者アカウントのみに限定し、ユーザー管理機能を丸ごと葬った。

これにより編集権限を持つユーザーが管理者やほかの編集ユーザーに攻撃可能になる脆弱性を作りこめてしまう問題など、アカウント機能があることで起こりえる問題が恒久的に消えた。

HTTPクライアントのHTTPS通信で証明書を検証するようにした

別にやらなくてもいいのだがやるようにした。

半年くらい前にQiitaが証明書違反になっているのを見かけたが、こういう場合は正規の通信先でもこけるようになるためOGP取得処理とかがこける。

ファイル名の変更で既存のファイルを上書きしないようにした

リネーム前に存在チェックをかけているため、これが起きることは現実的にはないのだが、原理上起きないようにした。

HTTPS通信でタイムアウトするようにした

今まではタイムアウトしなかったため相手から切られるか、OOMするまで放置されていた。

アップロードしたファイルをリネームすることで本来上げられないファイル拡張子を上げることができた

アップロード可能な拡張子を制限しているのにアップロード後にリネームすることでこの制約を抜けることができた。

これは次のケースで問題が起きることがある。ただし現実的にこれらが起きることはまずない。何故なら管理者の自爆操作だからだ。

  • 悪意のあるスクリプトが仕込まれたHTMLを.txtとしてアップロードし、その後.htmlに書き換えて開くことで同一オリジン攻撃が可能になり、管理権限を乗っ取れる
  • 悪意のあるスクリプトが仕込まれたPHPを.txtとしてアップロードし、その後.phpに書き換えて開くことで任意コードが実行可能になる

書いていて思ったこととして、アップロードできる拡張子の制限という機能そのものをなくしたほうがいい気がしてきた。こんなことをしても無駄な処理とテストが増えるだけなので。

HTTPクライアントに制限をつけた

内部向けのアクセスができないようにし、巨大なファイルをダウンロードしようとしたら止めるようにした。

間違えて内部にいるPrometheusのような管理ツールのOGPを記事に展開しようとしてもできなくなった。

IPv4向けの対応であり、v6向けには特に何もしていない。

v6にして行うと自宅サーバーで自分がホストする別のサービスに繋げなくなるため、v6に対して行う予定は今のところない。

SomeOrigin攻撃対策をした

レンタルサーバーでは*.sakura.ne.jpや*.x0.toなど、サブドメインが異なる他人が多くいるため、HTTPヘッダーを検証し、同一オリジン以外からのCSRF攻撃が起きないようにした、

検索操作時に任意コード実行の脆弱性があったのを修正

このブログには付けていないが、特定の検索機能で任意コードが実行可能だったので対応した。

check_user_dataの型チェックが常に偽になるのを修正

動作的には特に問題がなかったがバグではあるため直した。

ログインの失敗を同じIPからの回数でも数えるようにした

IDに対して行っていると管理者のIDに対してログイン失敗を繰り返すことで管理者を締め出せるため、IPでも見るようにした。

その他

  • HTTP(S)通信で無限リダイレクトしないようにした
  • メールの送信でタイムアウトするようにした
  • wwwのプロセスのumaskを0から002にする
  • indexを一時ファイルに書いてからrenameで置き換え、ロックの後に置き換わっていないか確かめる
  • 空のindexを作り直し、ファイルの書き込みのエラーを返す
  • pkeyを指定したinsertのシリアル値を、indexと一緒に保存する
  • ソケットのパーミッションを変更
  • その他セキュリティ修正をいくつか追加

不具合対応

ファイル名によってアップロード後の操作ができない問題を修正

ファイル操作によってファイル名の検査処理が異なりエラーになっていたのを直した。

その他

  • JSONパーサーが正しくJSONをパース出来ていなかった問題の修正
  • 途中で切れたテンプレートのキャッシュでページがエラーのままになっていたのを修正
  • テキストDBの検索の値を埋め込んだ関数を際限なく保持していたので、1000個を超えたら捨てるようにした
    • OOMが起きる可能性があった
  • ページキャッシュ機能で同じ秒に同じ大きさで書き直されたファイルの古い内容を出し続けることがあったのを修正
    • 現実問題ほぼほぼ起きないと思うが一応対応した

改善

メインカラムが<div />だったのを<main />に変更

Webアクセシビリティ対応。

自動テストの高速化

11ファイル、1,475件、108秒を分割し、テストを並行で走行するようにした。結果、14ファイル、1,476件、26秒に短縮した。1件増えてるのは分割したせい。

機能削除の繰り返しにより最新版では22ファイル、1,290件、20秒にまで減っている。

env.cgiとconf.cgiを統一し、設定を全体的に見直した

分けている意味が分からないため統一した。

また設定の持ち方がカオスだったのを見直し、大半の設定を画面からできるようにし、致命的なケース以外では設定ファイルをいじくらなくていいようにした。

アイキャッチの自動設定機能を廃止

アイキャッチを編集画面で選んだ画像だけにし、自動設定機能を外した。

これはフロントエンドの表示とサーバーサイド側の処理で判定が異なり、画面上の表示と実際の処理が異なっていたほか、コードフェンスの中に画像のパスがあると、それを取り込んでしまうなど問題が色々あって対応が面倒だったのでやめた。

ユーザーが選べば解決するなら凝った実装を排除したほうがいい。ユーザーの手間が3秒増える程度。どうせ選びたいときは選ぶわけだし。

ページトップのOGPを無条件で出すようにした

v0.5.0でOGPの出力条件を削除し、UserAgentに依存させないようにしたの対応漏れ。

ついでにTwitter向けのOGPのサイズをデフォルト画像とそれ以外で可変にする対応を入れているが、私はTwitterをしていないため動作確認してない。

v4.29/v4.33より古いデータからのアップデートサポートを切り捨て

後方互換性維持のために残していた負債実装をすべて削除した。

adiary v3.52devからアップデートする場合、一度v4.29のタグをチェックアウトし、バージョンアップしたのち、次にv4.33のタグをチェックアウトしアップデートし、その後v4.34のタグをチェックアウトしてアップデートすることでアップデート可能。

v4.34時点のタグをチェックアウトするとアップデート処理が消滅しているので、段階的に作業する必要がある。

マルチサイト削除対応で残った残骸を除去

この対応によりv4.29/v4.33以前との互換性が完全に消滅した。

あとがき

今回のコードの変更量はバージョンのわりに少ないがClaudeを使って何回も多角的に調査させたため、木曜の今時点でMax x5プランで28%も使ってしまった。

Fable 5.1も使ってみたが的外れな指摘が多く役に立たず、役に立った指摘はOpus 5.5からのものだった。また、現時点でChatGPTの契約がまだ生きているのでGPT-6.1 Solにも見させているが、GPT-6.1 Solの指摘はClaudeとは全く違う視点から来ているのにクロスチェックに便利だと感じた。但し指摘が的外れであることも少なくなく、有用性としては補助程度に留まった。

ChatGPTの功績を残したのでGitHubの貢献者にCodexを生やすことができた。Codexはv4.27のHTTP通信のタイムアウトをスレッドごとに制御するを担当した。なお私はCodexをほとんど信頼してないのでこれしかやらせていない。

しかしまぁここ一ヶ月のコミットは本当にすごいことになっているのでコーディングエージェントの凄さを痛感する。

前も書いた気がするが去年まではLLMはハルシネーションの塊だと思っていたし、半年前でもまだ私のほうが上だと思っていたのに、もはや太刀打ちできない。私がやっているのはPRを手書きし、この記事を書くことでコードレビューを多少なりとも行い、気になった部分を見たり、わからなければLLMに確認する程度だ。

GitHubの草も珍しく列が繋がりそうになった。

縦に繋がったことは過去に一度しかなく、2021年初頭の話なので、もし繋がったら五年半ぶりの快挙になる。

コメント（0件）

Windows 11を26H2にアップデートしたらスリープやシャットダウンから復帰できない問題が出た

投稿： 更新：

Windows UpdateでWindows 11を25H2から26H2にアップデートしたらスリープから復帰しなくなる問題が出たので対処した話。シャットダウンからも復帰できないケースがあった。

ある程度対処して幾らかマシにはなったものの完全には直せなかった。

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

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

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

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

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

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

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

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

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

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

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

発生時の条件

Windowsのバージョン

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

hypervisorlaunchtype

AUTO

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

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

設定項目 設定値
電源ボタンを押したときの動作 スリープ
スリープボタンを押したときの動作 何もしない

シャットダウン設定

設定項目 設定値
高速スタートアップを有効にする OFF
スリープ ON
休止状態 OFF
ロック ON

ある程度解消した方法

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

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にするだけで容易に再現するため、これが原因の一つであることは間違いなさそうだが、他にも要因がありそうだ。

hypervisorlaunchtypeをoffにしたことによる影響は不明だが、BCDEditのヘルプによると設定値自体はHyper-Vのデバッグ用にあるらしい。

25H2に戻してもhypervisorlaunchtype: autoであれば起きていたため、もしかすると26H2になったときに、この設定が切り替わったのかもしれない。ただ25H2に戻して、hypervisorlaunchtypeをoffにしても偶に再現したため、26H2で何かの設定か何かが変わったままになっているのかも知れない。

或いは偶々このタイミングでハードウェアが故障したのか…。

コメント（0件）