OctopressからHugoへ移行

ブログの静的生成システムをOctopressからHugoへ移行した。

2012年からだからOctopressは4年使っていることになるのだが、最近では記事生成の遅さにいらつくことが多く（かといってisolate/integrateを使うのも面倒くさいし）、加えてパッケージではなくレポジトリでしか公開されていないのでアップデートがしにくい上、最近ではどうもプロジェクトの動き自体が鈍いようだったので（いつまでたっても3.0は公式リリースされないし）、思い切ってHugoへ移行してみた。ふだんはPythonを使っているので最初はPelicanを考えたのだが、まあ流行り物ということで。PelicanもHugoもDebianのパッケージになっているので導入は楽である。ドキュメントもテーマもそこそこ揃っている。まあテーマに関しては、現状質量共にOctopressや他のポピュラーなブログ・システムには及びもつかないが…。

記事コンテンツはしょせんMarkdownなのでそのままコピーしても大したことはないと思うが、Octopressとは日付のフォーマットなどが微妙に違うし、画像など静的なコンテンツもあるので、Hugoに用意されているJekyllからのインポータを使うとよい。

$ hugo import jekyll octopressdir/source hugodir

とかすると、octopressdirの内容が適当に変換されてhugodirに入る。当然Octopress固有のタグ等は使えないので、あとは適当に手で直す。特にcatgegoriesは使えないのでtagsにしないといけない。ちなみにHugoはMarkdownのプロセッサにBlackfridayを使っているので、例えばGitHub Flavored Markdownとは微妙に文法が違う。

HugoはTOMLだけではなくYAMLも理解するので、サイト全体の設定はOctopressの_config.yamlをある程度流用できる。まあこの際すべてTOMLで書き直した方がよいと思うが。日本語主体のブログであれば、config.tomlに

languageCode = "ja"
hasCJKLanguage = "true"

あたりを入れておくとよい。enableRobotsTXT = "true"も指定しておくとrobots.txtを自動生成してくれる。

Hugoは特に指定しないとfront matterのtitleを記事URLに使うのだが、タイトルが日本語というかマルチバイトの場合アレなので、urlかslugを自分で書いて直接指定することになると思う。Octopressと同じURLを維持したい場合は、個々の記事のfront matterに

url = /blog/2016/08/21/migrated-from-octopress-to-hugo/

等とフルで書くか、config.tomlに

[permalinks]
  post = "/blog/:year/:month/:day/:slug/"

と書いた上で、記事のfront matterで

slug = "migrated-from-octopress-to-hugo"

のように書けばよい。

テーマに関しては、とりあえず

$ git clone --depth 1 --recursive https://github.com/spf13/hugoThemes.git themes

として既存のものを全部落としてきて、hugo --theme テーマ名でいろいろ試してみるとよい。テーマ名はthemes/以下のディレクトリ名。細かなカスタマイズはconfig.tomlの中で[params]ブロックの中に書くことになるが、パラメータはテーマ依存が多いので、最終的にはテーマの中を覗かないとどうにもならないだろう。

で、あとは

$ hugo

でコンテンツが生成される。生成結果はpublicディレクトリ以下に入るので、この中身を好きなところへ持っていけばいいわけですね。ちなみにカバー画像等はstaticディレクトリ以下に入れればよい。このへんはhugo import jekyllを使えば勝手にやってくれる。

なお、フィードのURLはatom.xmlではなくindex.xmlになるので注意。

動的プレビューは

$ hugo server

としてhttp://localhost:1313にアクセスすればよい。-wオプションをつけなくてもファイル更新には自動追従するようだ。

今から思えばOctopressはrakeタスクがよくできていて、大概のジョブを手軽にこなすことができたのだが、現状Hugoはいろいろと手動である。例えばデプロイは、Octopressの場合適切に設定すればあとはrake deployかrake gen_deploy一発だったが、私のように相変わらずレンサバに置いている場合、rsyncあたりを使って

$ rsync -azr --delete -e ssh public/* server.example.org:/path/to/wwwdir

とかすることになる。本来はGitHub Pagesに置いてWerckerでも使えということなんでしょうが…。

スピードに関しては、55記事あるうちのサイトの場合、timeで測定すると

となる。何だこれはという速さ。