Ideal Reality

興味の赴くままに
  1. トップ
  2. 投稿
  3. サイトを作り替えました
add_22025年11月18日 0時0分

サイトを作り替えました

サイトを1から新しく作り直しました。

作り直しに至った理由

Wordpressの管理がめんどくさい

以前のサイトは公開するためにWordpressを自宅サーバーでホスティングしていて、それなりに管理が面倒でした。サーバーを立てるのにNginx, PHP, MariaDBのセットアップが必要ですし、移行やバックアップをするにはファイルとデータベース両方を扱う必要がありました。

とりわけ、一度サーバーのSSDが壊れてデータが消えてしまったことがあり、その時取ってあったバックアップが古くていくつかの記事が消えてしまって、それ以降このサイトを維持するのが面倒になってモチベが下がっていました。

あと、Wordpressがアップデートによって高機能になっていき、PHPを書かなくても自由にサイトを構築できるブロックエディタやFSEなどが使えるようになって、一般の人々にはWebサイトを作りやすくなった一方で、僕みたいなテーマやエディタを自作してカスタマイズしながら使っている身からすると、必要のないアップデートが多いし、HTMLに自分は使わない機能のための要素が追加されたりと、色々しんどい部分が多かったので脱Wordpressをしたいと思ってました。

JamstackみたくSSGにしたい

基本的にサイトの内容って記事を編集しない限り変わらないですよね。ただし、WordpressみたいなCMSはデフォルトだとアクセスがある度にDBに内容を問い合わせてサーバー側でHTMLをレンダリングします。
一応キャッシュを設定するとかの対処法はやったし、自作Markdownパーサー側である程度事前レンダリングを構成したりしてましたが、理想を言えば記事を公開したタイミングでHTMLを生成してしまって、アクセスがあった場合にはそれを返すだけにしておきたいものです。
そうすれば、アクセスがあったタイミングでサーバー側で何か処理を実行する必要がなくなるのでページ表示までのレスポンスが早くなるし、セキュリティ的にも強くなります。
サーバーの環境構築と、HTML生成ツールの開発を分離して行えるのも管理が楽になっていいですね。

バックアップ/世代管理を簡単にしたい

一度サーバーのデータが吹っ飛んで直近のデータが消えたこともあり、バックアップ体制の強化は必須でした。というかバックアップしてなくてもなんとかなるシステムにしたかったです。
今はGitHubのプライベートレポジトリが無料で使えるのでそこに投稿内容を置くことができたらよさそうですね。
Wordpressは記事ごとに編集履歴が残っていたのですが、それは全部本番環境のMariaDB上に保存されていました。編集履歴が残ってるのはありがたいけど、本番環境上に積み重なっていくのはちょっと気になりますね。

記事の内容が古くなっていて気になった

古い記事でも消すよりは残しておいた方がいいのはわかるのですが、それでも古い記事が情報が古いまま残っていたり、もっといい方法があるのにそのままだったりするのは気になってました。内容を更新すればいい話なのですが、最新の環境でちゃんとした内容に書き換える手間を考えるとそこまでやる気が出ず、いっそのこと一度全部吹き飛ばしてしまおうと思いました。
前のサイトに存在していて、今でも有用な記事はまた書き直せばいいだろうと。

新サイト構築

当初の予定ではヘッドレスCMSにNext.jsのSSGを組み合わせる予定でした。それがどうしてこうなった

ヘッドレスCMSは使わず

microCMSを使うかStrapiをセルフホストするかで悩んでいました。結局どっちも使いませんでした。

そもそも、Wordpressを使っていた時点でMarkdownパーサーを自作し、独自の記法で表示を色々カスタマイズできるようにしていたので、CMSを乗り換えるとしてもエディタをカスタマイズできることは必須でした。といっても正直なところ、プラグイン作ったりエディタをカスタマイズしたりするのは面倒です。

Strapiを場合はStrapiをセルフホストしておく必要があるし、microCMSだと利用制限や課金などの管理が必要で、その手間も厄介です。

で、色々考えた結果、VSCode上で記事を書いてしまえばいいのではないかという結論に至り、CMS要らないやってなりました。

Next.jsは使わず

Next.jsのSSGにする予定だったんですけど、これも使いませんでした。

Routing周り色々いじってて思ったのが、別にこんな色々やってくれる必要ないんだけどなーということ。シンプルにTypeScriptで生成したReactのコンポーネントをHTMLにして保存してくれればそれでよかったというか、むしろそれ以外やってくれるのは邪魔だなと。
そうなるとNext.jsも要らないという判断になり、最終的には preact-render-to-string でHTMLを生成する形になりました。

Markdownよりも表現力を高く

Wordpress上で使っていたMarkdownエディタはそのまま使えないので作り直しになるわけですが、どうせならここも改善したいですよね。

Markdownは書きやすく、文法も単純なので簡単にパーサーを作って独自の文法を追加できるのが利点ですが、それでも自由に拡張していくには限界があるように思います。
特に、Markdown自体が再帰的な文法構造を扱えないのは欠点で、そういった場合にはHTMLの文法に頼ることになって途端に書きづらくなります。 details summary なんかが典型例ですね。

そういうわけで、Markdownパーサーを作り直すのではなく、専用のマークアップ言語を自作することになりました。

レガシーブラウザは排除

IEやChromiumじゃないEdgeはもう対象から外していいですよね。以前のサイトを構築したタイミングではまだIE11が5%くらいシェアあったので、完全に対応とはいかないまでも画面が崩れない程度にはIEでも表示できるように色々手当をしていましたし、なるべく古いブラウザで使えるCSS/JSの機能だけを使っていました。

今はブラウザが自動更新されるのが当たり前ですし、古いブラウザを使い続けている人に対してリーチする理由もないので、新しい機能でも積極的に使うようにしました。Baseline 2023くらいまで使ったような気がします。

というわけで、1から作り直したサイトが今表示されているものになります。色々大変で着手してから3週間くらいかかってしまった。その上、実のところこのページを公開したタイミングではまだ画像を貼れなかったり、コードのシンタックスハイライトが効かなかったりと未完成な部分も多いのですが、とりあえず公開しちゃって残りの実装は記事を書きながら調整していく予定です。

2025年に自分のWebサイトを持つ意味

AI時代に技術ブログを公開する意味はあるのか

昨今はLLMの進歩がすごいです。調べ物をするにもGoogle検索よりもChatGPTに頼ることの方が多くなっていて、Webページを開かなくても調べ物ができる時代です。
じゃあ技術ブログを作る意味がなくなるかというと、そうではないと思います。

プログラムの書き方やAPI仕様をまとめるのは無意味

そういうLLMに質問すればいい内容なら書かない方がいいです。LLMに公式ドキュメントを読ませるのが一番確実です。

AIはやり方を教えてくれても手を動かしてくれない

AIはやり方を教えてくれます。コードも書いてくれます。
ただし、実際に試すのは人の手が必要です。AIがやり方を教えてくれたとしても、AIはその手順を実際に試して動作確認しているわけじゃないので、AIの言う「こうやればできます」よりも人間が言う「こうやればできました/失敗しました」の情報に価値があるケースが常に存在すると思います。

知識整理のためのアウトプットは大事

アウトプットする行為は自分の知識を整理することにつながるため、AIの有無に関係なくやった方がいいです。その方が後々の自分のためになります。

ZennやQiitaでいいのでは?

全くもってその通りです。だから技術ブログの公開のために自分のサイトを運用することはオススメはしません。
とはいえ、あえて出来合いのものを使わずに自分で作ってみることは学習の面では非常に有用です。だからみんな自作OS本とかやるわけですよね。それと同じ感覚です。
技術的興味を持って、Webサーバーの構築に興味があるなら自分でサーバーを立ててみるのがいいと思います。

というわけで、なんとなくサイトを作り直した経緯をダラダラと書いてみました。しばらくはここでのアウトプットを頑張るつもりです。続くといいな...

共有

この記事が役に立ったならば、シェアしていただけると嬉しいです。

関連する投稿
関連する投稿はありません
プロフィール
Hiroki Kawakami

サイトを作り替えています