静的サイトジェネレーター「Nikola」徹底レビュー ― インストールから初投稿まで

はじめに：動的ウェブの幻想

現代のウェブは動的コンテンツ全盛の時代です。しかし、その多くは技術的な錯覚にすぎません。数多くのウェブサイトが動的生成ページを採用しており、リクエストのたびにデータベースからデータを読み込み、画面へ描画しています。インタラクションを一切必要としないコンテンツでさえ例外ではありません。この仕組みはリソースを消費しますし、セキュリティ面でも懸念があります。不正な入力や不正形の命令が、理論上は望ましくない出力を生み出す可能性があるからです。

一方、かつてのウェブは静的コンテンツの世界でした。リンクと画像を含むHTMLページがあるだけで、それ以上のものはほとんどありません。決して悪くない方式で、リソース消費は軽く、サーバーの観点からも安全性は高いといえます。ただし、インタラクションはほとんど実現できず、コンテンツの更新も骨の折れる作業でした。もし、この2つの世界の中間に立つ存在があったら？それこそが、静的サイトジェネレーター「Nikola」なのです。

試してみる：インストールからテストまで

Nikolaのアイデアの本質は、「静的なウェブサイトを動的に作る」というものです。多数のPythonスクリプトがページの作成・編集を支援し、リンクの修正などをバックグラウンドで自動処理してくれるため、変更のたびに手作業で対応する必要がありません。プラグインやテーマを活用すれば、作業はさらに簡単になります。

従来のCMSとの違いは大きく2点あります。1つ目はデータベースが不要なこと、2つ目はサイトを公開する前にすべてをローカル環境でビルドしておくことです。アップロード先のサーバーにあるのは、純粋なHTMLと画像だけです。

私がNikolaに興味を持ったのは、現代においてオフラインでのコンテンツ作成が容易ではないからです。2018年にもこのテーマについて取り上げましたが、皮肉なことに、GUIの利便性とコード直接編集の柔軟性を兼ね備えた最適なツールは、古き良きKompoZerだという結論に達していました。Nikolaはハイブリッドなアプローチを提供します。基本はコマンドライン操作ですが、ビジュアルエディターとブラウザーでのライブプレビューも利用できます。

公式のセットアップ手順（pipとvirtualenvのコマンド）に従ったところ、特に問題なく動作しました。この一連の手順はスクリプト化して自動化することも可能でしょう。セットアップが完了したら、オンラインチュートリアルに沿って最初のデモサイトを作成します。

nikola init --demo test-site
Creating Nikola Site
====================

This is Nikola v8.0.2. We will now ask you a few easy questions about your new site.
（新しいサイトについて、いくつか簡単な質問をします）
--- Questions about the site ---
Site title [My Nikola Site]:

基本情報を入力し終えると（サイトのトップページとして使用するため、取得済みのドメインも必要です）、続いて最初の記事を作成しました。手順どおりに進めたものの、早速つまずくことに。

(nikola) roger@tester:~/nikola/test-site$ nikola new_post -e
Creating New Post
-----------------

Title: Why Badgers Shouldn't Be Allowed to Drive
Scanning posts........done!
[2019-04-07T18:05:25Z] INFO: new_post: Your post's text is at: posts/why-badgers-shouldnt-be-allowed-to-drive.rst
[2019-04-07T18:05:25Z] ERROR: new_post: The $EDITOR environment variable is not set, cannot edit the post with '-e'. Please edit the post manually.
（$EDITOR環境変数が未設定のため、「-e」オプションで記事を編集できません。手動で編集してください）

原因は、EDITOR環境変数を手動でエクスポートしていなかったことです。KDE環境ではKateを設定しましたが、Notepad++を含む任意のエディターで問題ありません。あらかじめ設定しておけば、このエラーは二度と表示されません。

編集体験は少し癖があります。Nikolaは標準でreStructuredTextを意味する「.rst」拡張子のファイルを使用しますが、Markdownなど他のフォーマットも手動で設定可能です。とはいえ、独自の（そしてやや風変わりな）構文を新たに覚える必要がある点は違和感がありました。スタイルとコンテンツの分離も存在しません。

つまり、すぐに執筆を始められず、まず別の言語を学ぶ必要があります。その記述は最終的にHTMLへ変換されますが、CSSクラスはどうなるのか、スタイル指定はどう反映されるのか、素のHTML要素は扱えるのか、といった疑問が湧きます。ウェブサイトを作る人が、実際の構文を自由に制御できないのはおかしな話ではないでしょうか。そうした試行錯誤を経て最初の記事を完成させ、Nikolaにビルドを実行させました。

ビルドが完了すれば、ブラウザー上で変更内容をプレビューできます。自分でカスタマイズするのが面倒な人のために、追加のテーマやプラグインも豊富に用意されています。ここまでは悪くありません。ただ、依然として大きな疑問が残っていました。「その先はどうするのか？」という点です。ウェブサイトに満足した後、FTPでサーバーへ丸ごとアップロードすればいいのか？更新はどう管理するのか？

写真に写っているのは私ではありません。私よりはるかに素晴らしい人物です。

そのほかにも興味深い機能が見つかりました。各種ビルドシステムへのデプロイ、GitHub Gistのインポート、チャートやサムネイルの作成、コードブロックの利用などです。それでも、最終段階に関する説明が不足していると感じました。ユーザーがコンテンツ作成を終えた後、ローカルのビルド環境からオンラインへの公開まで、どうすれば簡単かつ明快に行えるのか。そこが見えにくいのです。

まとめ

本当に考えるべき問いはこうです。もしニコラ・テスラが今日ウェブサイトを開設するとしたら、どんな技術を選ぶのか？Microsoft FrontPageか、GeoCitiesか、それともNikolaか。私はこのコンセプトが好きです。サイトの骨格更新にかかる無駄な時間を省き、ユーザーを本来の作業に集中させる発想に共感します。ただ、アプローチが開発者寄りすぎると感じました。ウェブサイト制作はゲームではありませんが、ハッカーの祭典でもあるべきではないのです。

私にとってNikolaは、より洗練された初期設定、HTMLの直接記述（少なくともコードブロック挿入）への対応、より直感的なプレビューとデプロイの仕組みがあれば、さらに良くなるはずです。答えはドキュメントのどこかにあるのでしょうが、優れたツールとは、シンプルで自己説明的であり、与えてくれるものが要求してくるものより多いものです。最初のページを公開できるまでに膨大な労力を強いられるなら、時間を節約するはずだったツールこそが、節約するはずだった問題そのものになってしまいます。

とはいえ、Nikolaは気に入りました。非常にクールなアプローチであり、今後も注視していきたいと思います。Web 4.0なるものが何をもたらすのか、誰にも分かりませんから。

それでは、また。