Lycolog

なんか書くとやらなくなる気がしないでもないが、一応書いておく。

主に自宅サーバー環境の拡充、特に監視面と、adiaryを置き換えるブログシステムの開発を行っていきたいと考えている。

• 自宅サーバー環境の拡充
  • 監視体制の強化
  • 権威DNSの作成
• adiaryを置き換えるブログシステムの開発
• 出費を抑える

自宅サーバー環境の拡充

監視体制の強化

去年はOpenWrtによる自作ルーターの作成や、Mastodonの運用を開始したり、今ではApacheやMantisBTを運用するなど自宅サーバーはマルチテナントになってきたが、監視体制が足りていないので、これを作っていく。

ログやメトリクスを集めてアラートを出したり、ある程度は自動復旧できる機能が作れたり、パフォーマンス改善に生かせるとよいと思う。

権威DNSの作成

現在はValueDomainの権威DNSを利用してドメインを運用しているが、色々めんどくさいのでローカルでやりたい気持ちがある。このため自前でのDNS運用もやりたいと考えている。

何が面倒かというとValueDomainのAPIはDNSレコードを塊で渡してくるので操作するためにパースが必要だとか、特定条件下でTTLが3600秒に固定設定されるだとか面倒なのだ。

それに権威DNSを持つことが出来れば、出来ることが増えるかもしれないので、是非やっていきたい。

現状の知識としては権威DNSサーバーとしてはBINDが有名だが、BINDが過去のものになりつつある噂を見るくらいの状態だ。

adiaryを置き換えるブログシステムの開発

adiaryの改造に関しては過去何度か挑戦し、上手くいった事柄もあれば、いかなかった事柄もあり、今でも運用でカバーして苦労している部分が多い。

そこでadiaryの代わりになるブログシステムを作りたいと考えている。

重要視しているのは書式互換性と、データ移行の容易さだ。

私は過去に非常に多岐にわたるCMSの移行を経験していて、その都度やたら苦労している。

例えば直近ではWordPress→はてなブログ→WordPress→adiaryと移り変わっているが、はてなブログのWPインポート機能はイマイチ使い物にならず、手動で記事データの移行をする羽目になり、画像が多い記事など、アップロードやパス変換が手間である記事を中心に、多くの記事が失われたし、WordPressに戻るときも同様に失ったので、この二回だけで半数ほどの記事を失っている。

WordPressからadiaryに移行するときは手動と目検の気合で全ての記事を移し替えたが、手作業のミスや、adiaryが非対応の書式があるなどで書式が破綻している記事が今でも何個かあった気がする。先日重い腰を上げてadiaryのMarkdownパーサーを脚注記法に対応させたので、大半はマシになっているはずだが、記事によってはどうにかしようとして変なことをしたような気もしている。

古い過去でいえばMobavleType→Blogn→BlognPlus→SereneBatch→Sb→NuclearCMS→BlognPlus→WordPress→BlognPlus→BlognPlus→WordPressという壮絶な移行をしているが、この時は以降の都度過去を切り捨てていたように感じる。このブログに2018年以前のデータがないのはそういう関係もある。

というので、ブログシステムを移り変わるごとにやたら苦労しているので、次は苦労しないようにしたい。幸いadiaryはシンプルに見えるのでDBスキーマと添付ファイルの構造さえ一致させていれば行ける気はするので、そこまで苦労はしないだろう。きっと。そうだと思いたい（フラグ）

今構想している内容として、仕様面ではadiaryより大分簡素にする予定で、複数ブログ管理やマルチユーザーとかは想定せず、一人のユーザーが一つのブログを運用するという、至ってシンプルな方式にする予定だ。認証認可やパスワードリセットなど、機能のシンプルさはadiaryをリスペクトしていくつもりだ。

技術スタックとしてはPHP + SQLiteくらいの軽さで行こうと考えていて、レンタルサーバーでもキビキビ動くものにしたいと考えている。ライブラリは依存地獄の問題があるので、adiary同様に極力自力で実装していきたい。幸い今はLLMとかいう便利な道具があるので、これは比較的容易にできるのではないかと思ってる。あとPHPは標準機能が便利なので、恐らく広範にカバーできるだろう。

現時点では一旦DBスキーマだけ軽く作っているので、ここから表示部を作りこんでいき、Markdownやadiaryにある書式のパーサーを組み込んでいき、最終的に形にできればと思っている。

まずは動くものが欲しいので、デザイン調整UIとかは後回しにすると思う。

出費を抑える

去年は移動の連続やグッズ購入などが多く、出費が非常に嵩んでしまったので、今年はそれらをぐっと抑えていきたい。今年は年初からメインモニタが逝っていきなり金が飛ぶとかいう事故もあったが、特に何もなければ派手な消費は控え、質素に平穏にやっていきたいところだ…。

この記事はadiary改造シリーズ三本目である。

今回はadiaryの私的改造版であるadiary-extendsを0.11.5から0.12.0にバージョンアップした。

何をしたかというと、adiaryを採用したいが…で導入検討以来ずっと懸念事項だったMarkdownの脚注書式に対応した。なんと二年越し。なおまともな動作確認はしていないので、ちゃんと動くかは不明だ。とはいえ、軽く見た感じとりあえず動いてそうなので、いったん対応したということにしておく。

現状では脚注に書いたMarkdownはパースされないのでそのまま出てくるが、今のところ仕様。そのうち直す。多分。

何故やったか？

ミンゲイインターネットの紹介を書くにあたり、古のサイト探究～駄文同盟のID上位100サイトを巡り、今までのネット人生や自サイトの過去を振り返ってみるをリンクしたかったのだが、この記事には破綻した脚注記法が使われており、まさか他のサイトの紹介記事を書くのにこんな状態があってはならないだろうと思い着手した。

どうやったか？

Claude Opus 4.5に9割書いてもらった。

というのもadiaryのコードはPerlで実装されてあり、私はPerlに疎い部分もあるし、パーサー系のコードの理解が難しいためだ。

過去にGPT4やClaude Sonnet 3.5などにトライさせたことはあるのだが、余りにも出てくるコードが使い物にならず、当時は諦めていた。しかしOpus 4.5は極めて性能がいいので、ひょっとしたら今なら行けるのでは！？と思い試してみたところ、大まかには上手くいったので、実装することが出来た。

勿論コピペ実装できる代物ではなかったので、細かいところは手直ししている。

Opus 4.5に任せた流れ

キャプチャでアレだが、こんな感じで出してもらった。最初投げつけてるのはlib/Satsuki/TextParser/Markdown.pmそのものを渡している。

行が破綻していたり、前後の行にあるコードが正しくなく、リンク処理に[]が食われた後に脚注の[]をしようとして失敗したり、正規表現が微妙に間違っていたり、余計なフラグがあったりしたので、そういうのは適当に直している。

あとがき

GitHubのWikiに改造内容をまとめているが、割とそこそこ改造したと思う。

素のadiaryより格段に使いやすくなった。とはいえ、まだ足りないところは多いし、adiaryを保守するのも大変なので、そのうちフルスクラッチで作り直したいところだ。こうやってadiaryに手入れしている現状、その日がいつ来るのかは謎だが…。

ついでにロゴもSVGとPNGで作ってみた。adiaryのオリジナルロゴの改変だが、SVGの書式をMDNで引いて細かいことはOpus 4.5に聞きつつ、手書きしたものだ。

GitHubのリンクは消えるかもしれないので、現時点の版も置いておく。

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 64 64" width="64" height="64">
  <rect x="0" y="0" width="64" height="64" rx="12" ry="12" fill="#899aff"></rect>
  <text x="18" y="52" transform="rotate(-10, 25, 62)" font-family="Meiryo, serif" font-size="64" font-weight="bold" fill="#fff">
    a
  </text>
  <text x="25" y="55" transform="rotate(-30, 50, 50)" font-family="Meiryo, serif" font-size="32" font-weight="bold" fill="#001382">
    ex
  </text>
</svg>

SVGをPNGに落とすのにはSVG to PNG / ものおきを利用させていただいた。縁のアンチエイリアスや透過情報がきちんと保たれていて、非常に便利だった。

関連記事

過去のadiary改造シリーズの記事。

• CMSをadiaryに変えてよかったこと
  • コピペによる画像添付に対応した話
• adiaryを地味に改修している話
  • 去年やった改造の全般的な話

昨今、Googleで検索しても広告まみれの変なサイトや、いかがでしたか？ブログみたいなのばかり出てきて鬱陶しいとか、個人サイトをもっと見たいみたいな声があると感じている。

そこで紹介したいのがミンゲイインターネットだ。このサイトはミンゲイ的なブログをあつめているサイトで、ミンゲイ的なブログとは何かというと、私は手作り感やクラフトマンシップのあるブログだと私は解釈している。正直よくわかっていない。

よく分かっていないので登録基準も理解しないまま自推してしまったくらい、私はミンゲイインターネットがよく分かっていない。分かっていないまま自推してみたら登録基準に達していなかったのが、私のせいで基準が変わって登録されてしまったので良かった。こんな記事を書いた日には消されても不思議はないが、まぁそれはそれとして。

まぁ、そんなこんなで、うちのブログのような個人ブログが多く登録されている。幾らかざっと見た感じ広告があるサイトは見当たらなかった。登録基準的に広告が目立つようなところはないのだろう。見ていて非常に気持ちがいい。

個人サイトの郷愁を綴った記事

個人的に個人サイトの郷愁というか、なんかそんな感じの記事を集めているので、今回の記事に合わせて公開する。個人サイト運営者には響くところもあるのではなかろうか？少なくとも私は響くものがあった。

• 2012-09-11 個人ブログとSNSと「弱虫な表現者」 - いつか電池がきれるまで
• 2022-05-31 pixivの普及で個人サイト壊滅→もしpixivがなくなれば全て消えてしまう…この流れ、何かを思い出さないか…？ - Togetter
• 2023-02-05 絵師たち「みんな凍結されててヤバい！避難先を作りました！凍結されたら絵の投稿・発信・連絡等は…」俺「ｵｱｱｱｱｱｱｱｱ!!!!」」 - Togetter
• 2023-12-20 「いにしえの00年代のインターネットへの憧れ」はわかる気がする - シロクマの屑籠
• 2023-12-26 「昔のインターネットは面白かった」と思っている世代からみた「今のインターネット」 - いつか電池がきれるまで
• 2023-12-26 「昔のインターネットは面白かった」 - いつか電池がきれるまで
• 2024-01-08 "クラフトインターネット"という古き良きウェブへの回帰運動に期待している。 - 世界のねじを巻くブログ
• 2024-02-05 令和の時代に個人サイトをつくる｜itousa
• 2024-03-03 おすすめの個人サイトや個人ブログを定期的にまとめることにした。 - 世界のねじを巻くブログ
• 2024-03-19 個人サイトの再来なるか、趣味の記録に特化したメモブログサービスをMozillaがリリース【やじうまWatch】 - INTERNET Watch
• 2025-03-04 「ぷらら」の個人向けホームページが3月末に終了　古参ネットユーザー「歴史が消えていく」 - ITmedia NEWS
• 2025-07-31 「侍魂」20年ぶり更新、ぷらら閉鎖後ロリポップが引き受け　「ちゆ12歳」が取り上げ話題に - ITmedia NEWS
• 2025-10-09 個人ホームページが「衰退した」といわれる理由と、「Web日記」文化について【フォーカス】 | レバテックラボ（レバテックLAB）
• 2025-12-07 グーグル検索が目指すものと、それでは見つからない個人サイトについて。 - 世界のねじを巻くブログ
• 2025-12-02 ちょっとだけ牧歌的インターネットが帰ってくる季節だよね - フジイユウジ::ドットネット

また、この手のネタだと個人サイトや、インターネット黎明期からの記録を綴った佐倉葉ウェブ文化研究室も非常に蘊蓄に富むので、私は好きだ。

関連記事

過去に個人サイト周りについて言及した記事も添えておく。

• 古のサイト探究～駄文同盟のID上位100サイトを巡り、今までのネット人生や自サイトの過去を振り返ってみる
• 今どき珍しい個人サイト制作支援サイトを見かけた

私はここ数年、電子書籍ではなく、紙の本、つまり物理本を主体的に読んでいるわけだが、そこで気づいた紙の本にしかない良さを書いていきたいと思う。

• 紙の本で良いと思うところ
  • 本が勝手に消えない
  • 本の内容が勝手に書き換わらない
  • 不要な本を忘れられる
  • 一覧性が高い
  • 装丁を楽しめる
  • 同時に複数展開できる
  • 本を読みながらメモを取るのに便利
  • スマホの電池消費に貢献する
  • 運動になる
  • 痛んだり、折れたり、劣化する
• 関連記事

紙の本で良いと思うところ

ここでは主に個人的に思う、紙の本の長所を中心に書いている。

本が勝手に消えない

電子書籍ではサービスの廃止や、著者の不祥事などで配信停止になると、自分の意思に反して本が読めなくなることがある。

サービスの廃止例では電子書籍配信サービスであるエルパカBOOKSは2014年2月24日に配信を停止し、本は戻ってこなかったとされている。

著者の不祥事としては、がおう氏の事件は記憶に新しい。例えば角川書店はイラストレーターがおう氏に関する報道と関連出版物の対応についてで、「Selfe Girl がおう作品集」の紙書籍 回収・絶版／電子書籍 配信停止を発表している。

もし紙で持っていたら消えることはない。配信会社が潰れようと、著者がいかなる蛮行を行おうと、そういった理由では消えない。

もちろん、失火や水没、紛失、盗難などでは消えるが、それは努力によって回避できる内容であり、前述のような自分では制御できない外的要因ではないので除外する。もちろん、その為に本を耐火金庫に入れるというのは極論だし、そこまではいわないが…。

本の内容が勝手に書き換わらない

これは短所でもあり、長所でもあると思うが、本記事の趣旨として長所として捉えていくこととする。

例えばこち亀、こちら葛飾区亀有公園前派出所は重版されるごとに問題のある表現が別の表現に置き換えられている話があり、電子版では最新の紙本と同じ内容になっているという噂がある。

もし紙の本を持っていれば、こういった本来の表現を見続けることが出来るだろうし、複数の版を持っていれば、比較することも可能だ。電子書籍でそのような機能があるものは私は聞いたことがない。

電子書籍にあっても版管理（バージョニング）は資源を食うし、書籍リーダーの開発や版ごとの権利周りも面倒になりそうなので、恐らくまともに一般化することはないと思う。

不要な本を忘れられる

電子書籍は一度買った本が未来永劫本棚から消えることはない。

もし買ってみたけど生理的に受け付けない本があったり、忘れ去りたい本があったらどうだろう？

紙の本なら売るなり捨てるなりすれば視界から消し去ることが出来るが、電子書籍ではカテゴリ分けで視界から一時的に消えた状態は作れるだろうが、所有しているという事実を消し去ることはできないし、多分何かの拍子に見てしまうことがあるだろう。

個人的には見たくない本が並んでるのはストレスだし、Kindleで一覧表示するとノイズとなって目障りだと思っている。これに対し紙の本は邪魔なら処分できる、これは強みだと感じる。

何なら古本として売れば二束三文でも金になるし、安く買いたい誰かのためにもなり、一石二鳥かもしれない。

そして何より、本を処分してまた欲しくなった時の葛藤を味わえるのも紙の本ならではだろう。そんなものはいらないと言われればそこまでだが、私はこういった負の感情こそが人の動力源の一つになりえると思う。

一覧性が高い

電子書籍の本棚を見て、一覧性がいいと思える人はおそらくほとんどいないと思う。もし、いたら申し訳ないが、一度大型書店か図書館に行ってほしい。

例えばKindleではコミックは自動的にまとまるが、ラノベはまとまらないので、一覧表示だと目的の本を直感的に探しづらい。検索しろと言われればそこまでだが、面倒だ。

それと万一歯抜けで買ってしまっている場合、一々まとまっているものを開かないと分からないので、これもイケてない。

もし紙の本であれば順序良く並べていれば歯抜けは一目瞭然だし、背表紙は面積が少ないので、普通に並べていれば、どの本がどこにあるかはパッと見てわかるだろう。

この一覧性の良さは紙の本の利点だし、何より本がずらっと並んでる光景は壮観でいいものだ。

装丁を楽しめる

本の中にはコミックの単行本でさえ装丁を凝ったものがあり、エンボス印刷や、特殊な紙を使ったものが存在する。

電子書籍でも技術的にはモニタに静電気を出すなどして触覚を再現することは可能だろうが、今のところそんな電子書籍は聞いたことがない。そんな端末を作って普及させるのも大変なので、多分当面現れはしないだろう。

同時に複数展開できる

紙の本は本そのものが表示デバイスの役割を担うため、本があればその数だけ同時に複数展開できる。参考書AとBを同時に読む、開いたまま比較するなど造作もないことだ。しかも置く場所の面積が許す限り何冊でも同時に開ける。

電子書籍ではモニタの制約があり、モニタの数以上には開けないし、モニタは基本的にでかく表示も紙の本よりでかいため、いくらモニタがあろうと制約が出てくる。

これは私はKindleの電子ペーパーを10個持ってますみたいな人なら気にならないかもしれないが、まずそんな人間はそんなにいないだろう。

本を読みながらメモを取るのに便利

ここは前述の項目と類似する内容だ。

例えば出先で本を読みながらメモを取る場合、紙の本があれば紙の本を読みながらスマホのメモ帳にメモするだけなので手軽だが、もしスマホしかなかったら、頻繁に電子書籍リーダーとメモ帳を切り替えることになり大変煩わしい。

スマホの電池消費に貢献する

紙の本は電池がいらない。電子書籍リーダーも電子ペーパーなら実用上気にならないだろうが、スマホで読もうとすると、どうしても気になるのがバッテリー残量だ。

ただでさえ色んなことに使うので電池残量が心配なスマホの電池を保てるのは便利である。特に長く読む場合はなおさらだ。

運動になる

紙の本は重いので、持ち歩いていると少なからず運動になる。きっと1mmくらいは体を鍛える助けになっていると思う。

また、本棚の本を整理するときなども、多少なりと運動になるだろう。きっと、多分、恐らく。

痛んだり、折れたり、劣化する

一見するとデメリットと思えるかもしれないが、紙の本は傷んだり、折れたり、黄ばんだり、汚れがしみ込んだり、時として破れたり、何かと劣化する。しかしこれもまた一つ良いのではないかという話だ。

例えば、この本は四隅が痛んでおり丸くなっている。これは私がゾンビランドサガの聖地巡礼をするときに、この本を持ち歩いていたことに起因するからだが、逆に言えば使い込んだという記憶を本に持たせることが出来るともいえるだろう。

経年で日焼けした本も、本棚の中で時を過ごした証拠としてみれば、それは風情がある。詫び寂びというやつだ。

例えば漆塗りでは時間経過による光沢の変化を育てるという文化がある、それと同様に本も育てることが出来るといえる話だ。これはピカピカの新書と、くたびれ色褪せた本では後者のほうが確実に重みがあるのと同じ話だ。

平たく言うと味が出るということだ。電子書籍から味が出るかと言うと、精々モニタについてる埃や、スマホの皮脂の味しかしないだろう。

関連記事

• 本棚を買った
• 少女漫画を紙で買ってみた感想
• 紙の本が減ってきている
• 紙の本が減ってきている2

漆器椀をカジュアルに使っていると、内側の底の漆が傷んでくるので、これを抑制する方法について。

写真だとややわかりづらいが、この汁椀は底の漆が光沢を失い、白っぽくなっている。これは剥げているわけではないが痛み始めている。

これはレトルト味噌汁とかを作るときにお湯をそのまま入れていたことに起因する。漆器の特性として熱に弱いというのがあり、熱湯を直接注ぐと漆塗装が剥げてきやすい。

そこでどうやってこれを防ぐかだが、熱湯を入れないのが一番単純な方法になる。とはいっても、それでは普段使いの器として使いづらいので、回避する方法を考えた。

まず、漆器がどのような条件に弱いのかという点についてだが、千鳥という漆器商が漆の耐熱温度についての記事で検証した内容では以下のようにあった。

90℃、95℃、100℃と三段階に分けて試したのですが、90℃、95℃では、4点いずれにも変化は見られませんでした。
しかし100℃では、4点すべてに、長さ5ｍｍ程度の筋が数本～十数本現れました。

つまり100度だと危険な可能性がある。また記事の内容を読む限り95度以下が推奨されているようだった。

基本的にポットやケトルから器に湯を注ぐ場合、ある程度の高さから注ぐため、多少は冷えた温度になると思われるので、湯温95度が注がれるときの温度くらいが耐えられる限界だと考えると無難だろう。つまり保温中の電気ポットなら基本90度なので問題が起きることは少ないと思われる。

ではケトルではどうか？ケトルは基本沸騰させ保温しないので100度近くなる。かといって95度まで下げるのも手間だ。

そこで私が考えた方式としては、まず器に水道水を軽く張っておき、その上にレトルト味噌汁などを載せ、その上から湯を注ぐことを考えた。

水はこの程度張っておけばよいだろう。この水を緩衝材として利用するわけだ。

そして水の上に具をのせる。

そして具の上からお湯をかければ摩耗が少なくなるのではないかと考えた。

この方式で三ヶ月くらい続けているが、今のところ摩耗が止まっている気がするので、それなりに成功していると思う。

また連続で調理する場合は、ケトルの湯は温めなおさずにやっておくと多少温度が下がるので、より器に優しくなるだろう。

この方式で調理する場合、中身が熱くなりすぎないので食べやすいのもメリットだ。100度近い湯で作ったインスタント味噌汁なんかは熱くて食べるのが難しいので、こういう風にすると塩梅が良くなるとすると、一石二鳥でもある。