perlベースの静的サイトジェネレーター : Dapperを試してみませんか？


# 要約

* **サイト構築に「静的サイトジェネレーター」を用いる手法があります。目的によっては非常に有効です。**
* **[Dapper](https://github.com/markdbenson/dapper)は「静的サイトジェネレーター」の一つで、使い方が簡単でわかりやすいです。**
* **本記事では、Dapperでのサイト構築の基本的な流れについて解説します。**

# 静的サイトジェネレーターの勧め

ご存知の通り、ブログやwikiなどで情報発信することは分野を問わず広く行われています。2020年現在、その多くがWordPressやMediaWikiなどの「動的にページを作るソフト」で実現されています。サーバ上では専用システムが待ち受けており、ユーザからのアクセスを受けつけると、要求に沿って必要なデータをデータベースなどから読み取り、その都度その場でHTMLデータに仕立てて返信します。

これとは大きくスタイルの異なるウェブサイト運営手法があります。「静的CMS」あるいは「静的サイトジェネレーター」を利用し、ユーザに見せるべきHTMLデータをあらかじめ全て作り置いておくのです。

静的CMSはサーバ側ではなく手元のパソコン上にインストールします。そしてデータも同じPC上に蓄積していきます。適当なタイミングでこうして蓄積されたHTMLデータをまとめて手元からサーバ側にコピー（アップロード）します。「サーバ」上にはこのHTMLデータだけをおいておき、「動的」ページに必要なPHPやデータベースシステムなどを置きません。

## 「あらかじめ作っておく」メリットはたくさんある

静的サイト構築すなわち「あらかじめHTMLファイルを全部作っておく」方式では、ユーザからの要求にきめ細かく柔軟に対応することは難しくなるものの、それを補って余りあるメリットが享受できます。

* webサーバが行なうのは単純に既存ファイルの内容を読み取って送り返すだけの簡単な仕事なのでレスポンスを高く保つことが出来る。
* セキュリティ上の懸念が低い（データの改ざんや損失の心配がない。データは全てサーバ上ではなく「手元」に残っているので、何かあってもアップし直すだけ）。
* 特別な常駐ソフトのインストールやややこしいサービスの設定が必要なく、ファイルを置くスペースさえあればいいので、レンタルするにしても安価にできるし、引越し作業も楽。

## わざわざ動的に作る意味、なくない？

ここで個人や小規模団体での情報発信を考えてみましょう。動的CMSが実現している「すごい機能」の大半は実のところ無用の長物ではないでしょうか。ユーザー認証、不要。編集履歴の管理、不要。それより「いつでも引っ越したり止めたりできる」・「カネがかからない」などのほうが遥かに重要な要素です。

静的サイトジェネレーターによる運営のほうがそのような要求に適合しています。

参考:

* [ブログはWordPressは辞めて、全て静的サイトジェネレーターに移行したい](https://qiita.com/shinya_sato_qiita/items/03259dc82b7ded62810b)
* [WordPressをやめ静的サイトジェネレーターで高速化した話](https://ics.media/entry/190410/)

# Dapperとは

[Dapper](https://github.com/markdbenson/dapper)は「静的サイトジェネレーター」の一つです。

同類のソフトに比べて、機能がシンプル。取り扱うファイル構成もシンプル。ですのでシステムをすぐに把握でき、必要最小限の内容のサイトを迅速に準備して公開できます。

逆に自分なりの機能拡張を図るのも難しくないでしょう。独自CMSをつくるベースとしても好適ではないかと思います。

「やりたいことだけを最小限の手間で」という方向で、Dapperでのサイト運営を考えてみてはいかがでしょう。

# インストール

Dapperは手元のマシン、つまりwindow10のノートパソコンなどで運用できます。ただ、Dapperはperlという言語で書かれています。Dapper自体のインストールの前にperlを使える環境を整える必要があります。

## perl

Windowsを使う場合は、windows版のperl、Windows Subsystem for Linux(WSL)、MSYS2などのいずれかの準備が必要です。perlのみの追加ならstrawberry perlを、他のテキスト処理用ツールも併用してより高度なことを行ないたいならMSYS2を、さらに高度なオペレーションを行ないたいならWSLの導入を検討してみてください。

インストールには何も難しいところはないので、心配要りません。strawberryとMSYS2は「インストール」作業を伴わないポータブル版を使う手もあります。

なお、モジュールの互換性の関係からActivestate Perlは避けたほうがいいでしょう。

LinuxやMacOSなどのいわゆるUnix-like OSであれば、perlは最初から使える状態にあり何の問題もないでしょう。

参考:

* [自宅でも職場でもネカフェでもperl - Qiita](https://qiita.com/doikoji/items/2280ff1e29b610bd07a3)
* [Windows な職場でみんなで共通の Perl を使ってる話](https://qiita.com/sago35/items/b90742907bc2ebb622c0)
* [Windows Subsystem for Linuxをインストールしてみよう！](https://qiita.com/Aruneko/items/c79810b0b015bebf30bb)

## Dapperのインストール

perlが使える様になったら、Dapperの準備です。perlの標準的なライブラリシステムであるCPANに登録されているので、すでにperlをご存知の方なら悩む必要はないでしょう。[cpan](https://metacpan.org/pod/App::Dapper)から標準的な手順で普通にインストールしてください。

もちろん[github](https://github.com/markdbenson/dapper)でアーカイブを入手してもかまいません。

ただ、いずれを使うにせよスタートアップではgithubのREADME.mbにお世話になることになると思うのでこのページだけはブックマークしておいたほうが良いでしょう。

# サイト作成の準備

まずはとりあえず作業用のディレクトリを作ります。ここでは、`~/dapper`とでもしておきましょうか。
この記事中では、この作業用ディレクトリを「ベースディレクトリ」と仮称することにします。
作成するサイトそれぞれについて、対応する「ベースディレクトリ」が一つ必要です。

```
$ mkdir ~/dapper
$ cd ~/dapper
```

そして、そのディレクトリの中に設定ファイルといくつかのサブディレクトリを作る必要があります。前述の通りにインストールができていれば`dapper`というコマンドが利用可能になっているはずなので、それを使います。

```
$ dapper init
```

すると、ベースディレクトリ直下には一つの設定ファイルと二つのサブディレクトリが出現しているはずです。

まずは、それらを観察するところから始めましょう。

## まずはDapperが拵えてくれたものを眺める

Dapperは、他の多くのサイトジェネレーターと比べて随分単純な構成でファイルを作ろうとします。悩むところがなくて大変結構ですね!

* `_config.yml` - サイト全体の設定（サイト名、ベースURLなど）を書き込むファイル
* `_layout` - レイアウトファイル（テンプレートファイル）の置き場所
* `_source` - テンプレート内に埋め込むべきデータを記述したソースファイル（パラメータファイル）の置き場所 

ここで改めてDapper=静的サイトジェネレーターが何をサポートするのかを確認しておきましょう。ざっくり言うと、それは「**穴埋め問題を解くお膳立てを整える**」です。`Dapper init`は、穴埋めを始めるための最小限のファイルを作り出すのです。

### 設定ファイルにサイト全般の設定を書く

`_config.yaml`はサイト全体の設定を書き置く場所です。中身を見てみましょう。

```
# Dapper configuration file
---
name : My Site
```

これまた単純明快ですね。簡単に推察できる通り、このMy Siteのところを自分のサイト名に書き換えればいいわけです。

このほか、後述のレイアウトファイルで使用する「変数」をこのファイルには自由に追記できます。基本的にサイト内のどのhtmlファイルからも参照されうる事柄はこの_config.yamlに書いておけばよいです。ベースURLや、管理者名、所属組織名、サイト開設日などがそれに該当するでしょう。

### レイアウトファイルは型紙

レイアウトファイルは一般的に言うところのテンプレートファイルすなわち「記事フォーマットを記録するファイル」であり、「型紙」となるものです。サイトごと・ページごとに異なる部分を「空欄」として、ページの枠となる部分をHTMLとして記述したものです。

**穴埋め問題の「問題用紙」に相当する素材といえます。**

今度もDapper initで作られた`_layout/index.html`を見てみましょう。

```
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title>[% page.title %]</title>
  <meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
</head>

<body>

[% page.content %]

</body>
</html>
```

これも簡単ですね。普通にhtmlファイルです。ただ、ところどころに特異な記述がみられます。`[% page.title %]`というのが4行目にでてきますね。これこそが穴埋め問題の「穴」に相当する部分です。指定した変数の値で「穴」を埋めなさいというのが`[% 変数 %]`の意味するところです。

#### 変数

`page.なんちゃら`とあるのは、後述のソースファイルに定義されている変数を参照していることを示します。当該のページのみに特有の値（たとえば記事の表題など）はこの形で定義します。

一方、_config.yamlに定義された変数は、`site.なんちゃら`の形で参照できます。

変数はレイアウトファイルそのものの中でも定義できます。

また、「式」を書くこともできるし、その値を加工する「関数」にあたるものもいろいろ用意されています。

### ソースファイルは記事ごとのデータを書く場所

**穴埋め問題の回答欄に相当するもの**をDapperの世界では「ソースファイル」として用意します。

記事に書き込まれる「本文」をmarkdown形式で書いていくとともに、レイアウトファイルに設定された「穴」に対応する変数の値を書き連ねておくファイルがソースファイルです。

例によって`dapper init`によって用意された`_source/index.md`を見てみましょう。

```
---
layout: index
title: Welcome
---

Hello world.
```

`layout`でレイアウトファイルを指定します。上の例は、このファイルの内容を`index.html`という名前のレイアウトファイルの穴埋めに使いなさいという指示になります。

それ以外は個々の穴埋めに使われる変数です。`title: Welcome`という記述は、レイアウトファイルの`index.html`の中の`[% page.title %]`を`Welcome`に置き換えなさいという指示になります。

以上の記述はソースファイルの`---`で挟まれた行に書かれなくてはなりません。静的CMSの世界では、この領域のことを**Front Matter**と呼ぶようです。

ただ、`page.content`だけは他の変数と性質が違います。この変数の定義にはFront Matterを使いません。　`---`より下に書かれたテキストが`page.content`の値として参照されます。もう一つの重要な違いは、そのテキストはmarkdown形式のデータとして扱われ、適切にhtmlに変換されてから「穴埋め」に使われるという点です。

## 公開用ページを作る

とにかくまずは、たった一つのページを含むサイトを作り、公開寸前の段階まで進んでみましょう。

### レイアウトファイルを適切に作る

上の解説で気づいた方も多いでしょうが、現時点でdapper initが標準レイアウトファイルとして作り出してくれるのはHTML4.01かつラテン文字（≒アルファベット）のみに対応した雛形htmlファイルです。

HTML5が普及して久しい今、HTML4.01の仕様に従う必要性は薄いし、また、この記事を読んでいるほとんどの人は日本語話者でしょうから、日本語が書けるテンプレートに改善しましょう。

```
<!DOCTYPE html>
<html lang="ja">
<head>
  <!-- エンコードの指定 -->
  <meta charset="utf-8">

  <!-- IEで常に標準モードで表示させる -->
  <meta http-equiv="X-UA-Compatible" content="IE=edge">

  <!-- 電話番号の自動リンク化を無効 -->
  <meta name="format-detection" content="telephone=no">

  <!-- viewport(レスポンシブ用) -->
  <meta name="viewport" content="width=device-width">
</head>

<body>

[% page.content %]

</body>
</html>
```

参考:[HTML5で個人的に最低限必要だと思う記述・タグまとめ。head内に何を書いておけばいいのか？](https://wemo.tech/79)

もちろん実際にはCSSなどを大いに作り込むことになるでしょうが、今は省略。必要最小限のテストテキストを公開することだけを目指し、シンプルなテンプレートに留めます。

### 作りたいwebページごとにソースファイルを追加する

dapperで作り出すwebページひとつについて、一つのソースファイルを作ります。
数が多い場合は`_source`の下にサブディレクトリを作ってその下にファイルを作っても構いません。そのディレクトリ構成は、公開用ディレクトリの中に忠実に再現されます。

### Dapperを使わずに作成するファイルの用意

Dapperで都度作り直す必要がない「固定的な内容」のページ（たとえば管理者の自己紹介とか免責事項解説ページとか）は、別途用意してベースディレクトリ直下においておきます。画像ファイルやCSS、JSファイルなども同様です。

### 公開用htmlファイルを作る

準備が出来たら、おもむろに次のコマンドを実行します。

```
dapper build
```

このコマンドは次のことを実現します。

* `レイアウトファイル＋ソースファイル⇢公開用HTMLファイル`の作成。出来たファイルを出力用ディレクトリーにコピー
* 固定的内容のファイルを出力用ディレクトリにコピー

出力用ディレクトリ=ベースディレクトリの`_output`ディレクトリ下のファイルが、サーバ上にて公開されることになります。ちゃんと出来ているか確認してみましょう。

Dapperにはプライベートに使える小さな試験用ウェブサーバ機能が用意されていて、実際に公開したときの状況をシミュレートすることもできます。

```
dapper serve
```

その場でブラウザを立ち上げて、`http://localhost:8000/`あるいは`http://127.0.0.1:8000/`にアクセスしてみましょう。今作ったばかりのページが期待通りに表示されているでしょうか？

### アップロードと公開

ここまでくれば、ゴールはもうすぐそこです。_outputディレクトリの中身をサーバにまとめてアップするだけです。

次の編集の時まで`_output`は大事に保存しておきましょう。これ自体がバックアップとなり、サーバに何かあっても折角のコンテンツが損なわれることはありません。

# より高度な設定と編集にむけて

レイアウトファイルにはずいぶん複雑な記述ができます。たとえば`ifブロック`が使え、変数の値によって記述を切り替えるなんてことができます。`forループ`や`whileループ`も使え、その時になってみないと項目数がわからないリストのようなものにも柔軟に対応できます。

見栄えのよいページ構成にしたければ、レイアウトの中身はさすがにデフォルトのままという訳にはいきません。しかるべきCSSテンプレートを導入すべきでしょう。それらをdapperで使えるように加工する必要がでてきます。

これらのノウハウについては別記事に追々書いていこうと思います。