ブログを立ち上げて、本来なら真っ先に機能面のセットアップを済ませるべきなのは分かっている。けれど、初めて触る管理画面のUIを理解しようとあちこちクリックしているうちに、いつの間にか「見た目」のカスタマイズに没頭してしまう――。 今回はテーマやアクセントカラーの変更といった、簡単に印象を変えられるところから着手しつつ、現代的なAIによる画像生成もフル活用して、自分好みのLook & Feelへ一気に寄せてみた。 1. タイトルとユーザー名の「微調整」 最初は他のブログのようにテーマをタイトルにしようと思って「Trial and Error」と付けてみたけれど、実際にカスタマイズを進めていくうちに、もっとシンプルにしたくなった。結局、タイトルは以前同様にドメイン名（nodoka.org）に戻し、元のフレーズはDescription（サイトの説明文）に回すことで落ち着いた。 また、うっかり「Full name」に本名を入れてしまったら、サイト上の投稿者名やシステムが自動生成するメールの署名など、あちこちに表示されて慌てる一幕も。ここもハンドルネームに修正。タイトルやユーザー名は、初

早速Ghostのインストールを進めていく。 最終的なゴールは、XServerのVPS 2台によるAct/Act運用（ホットスタンバイ）だが、今回は半自動半手動で1台のみにインストールする。 多くのコンポーネントが混在しているVPSのため、Dockerを使わずに済むものは原則パッケージインストールする方針で進めている。 既存のGalera Cluster（MariaDB）やワイルドカード証明書を使い回すが、これらのセットアップについては、また別の機会に。 1. インフラの前提条件 初期状態を伺うためにも、ghost-cliまでをAnsibleで入れて、ハンドキックでinstallを実施する。 Node.jsは既存の共通タスクを流用。ghost-cliはnpmでインストールするだけなので、AIにお願いすればよしなにPlaybookを作ってくれる。Ansibleを流して準備は完了。 * SSL: Cloudflare経由で更新している既存のワイルドカード証明書（Let's Encrypt）を流用。 * WEB: 既存の nginx（リバプロ）を利用。 * DB: 既存の Ga

技術ブログや個人メディアを構築する際、誰もが直面するのがツール選定の悩みだ。「ポータビリティ」を最優先するなら Astro などの静的サイトジェネレーター（SSG）が筆頭候補に挙がるし、手軽さなら既存のプラットフォームで十分かもしれない。 しかし、数ある選択肢の中で私が辿り着いたのは、Ghost という選択だった。今回は、SSGと比較して感じた Ghost の明確なメリットと、あえてこれを選択した理由を「情報の普遍性」と「拡張性」の観点から整理しておきたい。 1. Markdownが担保する「ポータビリティ」 まず外せなかったのが、Markdownフレンドリーであることだ。Astro や Hugo といった SSG を検討した際、最も魅力的だったのは「記事が単なるファイルとして手元に残る」という安心感だった。 Ghost は CMS でありながら、Markdown による執筆を強力にサポートしている。万が一、将来的に別のプラットフォームへ移行することになっても、書き溜めた資産を容易に抽出・再利用できる。特定のサービスにロックインされない「情報の普遍性」を維持しつつ、DB

私の手元には、長い月日を積み重ねてきたWordPressのデータがある。 振り返れば、そこには日々の技術ネタや趣味のまとめと共に、子供たちの成長もまた綴られていた。今その記録を見返すと、当時の記憶が鮮明に蘇り、思わず目頭が熱くなる内容も少なくない。単なるログ以上の、歩みが刻まれた場所だった。 しかし、その更新も数年前のコロナ禍で止まってしまった。生活スタイルが激変し、日常の優先順位が入れ替わる中で、かつてのようにブログへ向かうエネルギーが分散してしまったのだ。 「乗り換え」の対象にならなかったWordPress これまで、他のデジタルツールについては、より進化したもの、より自分に合ったものへと適宜乗り換えてきた。しかし、WordPressだけはなぜかその対象にならなかった。 それは決して「惰性」だったわけではない。WordPressは実によく応えてくれた。時に複数のサイトを束ねる「マルチサイト」として、時に「イベント管理システム」として。必要が生じるたびに、機能を追加することで私のニーズを支え続けてくれた、幅の広い道具だった。 しかし、本当の理由は、書き続けてきた多くの「