イオシフさんの静的サイトジェネレータの使い方
Qiitaの中で逢った、ような……
大トリはとっても嬉しいなって
静的サイトジェネレーター Advent Calendar 2016に参加してます。
なんだか大トリをやるはめになってしまいましたが、笑ってお読みいただければ幸いです。
もうデプロイも恐くない
私は業務で、そしてプライベートで静的サイトジェネレータのMiddlemanを使用しています。
静的サイトジェネレータは次のメリットがあります。
- サーバ代が安い
- 構成がシンプル
- デプロイが楽
- サイト閲覧時のパフォーマンスがよい
特に、PHPやらMySQLやらを使わずに済むのが大きいです。
いざとなれば、GitHub PagesやAmazon S3で公開できるわけです。
しかも、デプロイはコマンド一発でアップロード可能です。
FTPと格闘したのが嘘のようです。
Bundlerなんて、あるわけない
一方、いろいろと残念なところもあるのですが、特にコードを書ける知識がないとどうにも操れないというのは大きい制約だったりします。
特に、知名度がエンジニア以外に広まっていないというのも地味に大きな問題です。
ここは、業務で静的サイトジェネレータを使おうとする場合、確実に引っかかる点です。
ここで社内政治の調整を怠ると、 「WordPressでいいじゃない」と言われたり 、Ruby界の常識である Bundlerを使わずに入れられたり と痛い目を見ます。
最近のエンジニアの常識では、機能拡張にnpmやRubyGemsなどのライブラリを使います。
しかし、会社のポリシーによっては社内ネットワークでのインストールの制限がきついところも多いです。
場合によっては、開発機すら用意できないこともあります。
その場合は事前調整をしっかりしておかないとあとあと痛い目に遭います。
最後に残ったMac
意外にも、開発をうまく進めるためには「社内ネットワーク外」のマシンの活用が近道だったりします。
私たちが目を付けたのは、社内ネットワークにつながっていないMacでした。
そのマシンを使うことで、開発スピードを倍以上に上げることができました。
なぜなら、Macは本社のIT部門の管轄外であるゆえに、インストールが簡単にできたのです。
こんな構成絶対おかしいよ
アンケートフォームを作る案件でも使用したことがあります。
使用した某クラウドサービスではHTMLでビューを書くのですが、そこに独自タグを埋め込みつつ悪戦苦闘しました。
Reactが使えればよかったのですが、jQueryでがりがりと書きつつ、クライアントサイドのバリデーションを実装するなどいろいろなことをしてみました。
npm、私の最高のともだち
さて、Middlemanに限らず最近のWeb開発で問題となるのがnpmエコシステムをどこまで使うのか、という問題だったりします。
Middlemanでは、v4以降Ruby界で独自に発展したSprocketsというJavaScriptのバンドルシステムに別れを告げています。
それとともに、混沌きわまりないnpmエコシステムの力を借りることになりました。
私が業務で使用しているのはv3でしたが、このnpmエコシステムを利用する方針にしたがってJavaScriptとCSS関係ではgulpとBrowserifyを積極利用する作戦を採用しました。
すべては
npm script => gulp => Middleman
という順番で呼び出す形にしています。
これならMiddlemanから他の静的サイトジェネレータに移っても安心……とまではいきませんが。
え、それなら素直にPug.js使えと？
まあ、ありといえばありなのでしょうが。
