Hugo 構築 /

Jekyllに対するHugoの優位点


Jekyll+GitHub Pagesで少しだけブログを運用してみましたが、思うところがあってHugoに変えました。なぜ乗り換えたのか、Hugoがどのような点でJekyllに対して優れていると感じたのかをまとめます。

Jekyllの良くないと感じたところ

まず、Jekyllはいくつかイラッとする点がありました。

1.テーマ選択の自由がない

私はGitHub公式のテーマの中で気に入ったものを見つけることができませんでした。もちろん、GitHub公式以外にもテーマはたくさんあります。じゃあ公式以外のテーマを使おうと考えるわけですが、そうするとまず対象のテーマリポジトリをForkする必要があります。

なぜForkする必要あるかというと、Jekyllではひとつのサイトがひとつのテーマで成り立っているからです。

・・・自分で書いててよくわかりませんが、Jekyllでサイトを構築しようとすると、まず最初にテーマがあって、そのテーマに対してポストを書く、という順番になります。まず最初にテーマ有りきということは、数日運用した後「このテーマ飽きたな。別のテーマにしよう。」と思ったとき、それが簡単ではない、ということなんです。

もちろんできないことはないですが、

  1. まず新しいテーマリポジトリをForkして
  2. それまでの書き溜めたポストを、新しくForkしたブログリポジトリにコピーして
  3. これまで使用していたブログリポジトリをリネームするなり削除するなりして
  4. 新しいブログリポジトリを元のブログリポジトリの名前にリネーム

する必要がある・・・と思います。

それまでに書き溜めた記事は新ブログリポジトリに対してコミットし直すことになるので、過去のコミットログは失われます。気持ち悪いですよね。まぁ、そこはGitなので、サブツリーマージして・・・とすればコミット情報は引き継ぐこともできるでしょうが、かなり面倒です。

ちなみに、GitHubの公式テーマであれば、_config.ymlを一行変えるだけで別のテーマに変更できます。

2.タグページは自分で準備する必要がある

これはないでしょう・・・。公式では「簡単でしょ?」みたいなニュアンスで書いてありますが、新しいタグができる度にタグページを作成しなければならないとは・・・。ちょっと残念です。

余談ですが、Jekyllでは、タグの他にもカテゴリを使用できます。カテゴリ=ポストの配置ディレクトリですので、ポストに対してカテゴリはひとつです。

以下のように配置します。

/
  Category1/
    _posts/
      post1.md
      post2.md
  Category2/
    _posts/
      post3.md

Jekyllでは_postsの下が記事として認識されるので、まずサイトルート直下にカテゴリとするディレクトリを置き、その下に_postsディレクトリを置きます。_postsの下にカテゴリではないというのがミソですね。なんだか直感的でないですし、冗長な感じがするのは私だけでしょうか。

3. Pushするまで変換後の画面を確認できない

Jekyllは静的サイトジェネレータなので、通常はローカルで静的サイト(HTML)に変換して、HTMLをホスティングサービスにアップロードします。しかし、GitHub Pagesでは、サーバ上でJekyllが動いているため、ローカルで静的ページを作らずともコンフィグとMerkdown(またはTextile)のファイルをPushすれば、GitHub Pagesが勝手にHTMLに変換して公開ページとして配置してくれます。

これはいくつかのメリットがあります。

  1. ローカルにRubyやJekyll実行環境を準備しなくていい。
  2. 変換後のHTMLファイルをバージョン管理しなくていい。

ひとつめはWindowsユーザには大きなメリットになると思います。しかし、逆に言うとJekyllの実行環境がないことによりローカルで変換後の画面を確認する術がないため、PushしWebサーバに配置されて初めて確認できることになります。修正が必要になった際はコミットからやり直す必要があります。

ふたつめはGitHubをホスティングサービスとして使うのに変換してできたHTMLファイルをバージョン管理しなくていいという(個人的には)すごいメリットがあります。だって、テーマを変えても変換後HTMLファイルをコミットし直す必要がないので、コミットログが汚れない・・・はずだった。

Hugoのメリット

上記に対してHugoはソリューションを提案してくれます。

  1. Hugoはテーマを自在に変えることができます。当たり前ですが、GitHub Pagesで自動変換はしてくれないので、変換後のHTMLを上げる必要はあります。また、テーマごとに結構オプションが異なるので、テーマを変える際はconfig.tomlを変更する必要があります。
  2. Hugoはローカルで完全な変換後の姿を確認することができます。しかも、ただのHTMLファイルを確認するのではなく、Webサーバとして稼働している状態のものを確認できます。
  3. タグページが自動作成されます!カテゴリも使えますが、一つのページは複数のカテゴリを持てるので、タグとの使い分けがよくわかりません。テーマによってはカテゴリを使用しないものもあります。
  4. 変換が早い。

もうなんていうか・・・ たーのしー! って感じ。

Jekyllのグチばかりになってしまったような気がします。

そのうちHugo+GitHub Pagesでのブログ構築方法について書きたいと思います。

 Hugo 構築

  1. Auto Deploy Hugo by Circle CI 2.0
  2. Build Site by Hugo
  3. Jekyllに対するHugoの優位点