静的サイトジェネレータ「Yogurt」について
昨日まとめた日本製CSSフレームワークの中でYusuke Ishiguro (Kokushin)氏が制作したマークダウン形式に対応したドキュメントページ向けの静的サイトジェネレータ「Yogurt」が気になったので少しいじってみました。
デモサイトを編集してもいいの？
デモサイトにアクセスするといきなり編集できますが、少しこわいのでGitHubから落としていじってみます。
ここからサイトを作成するまでの流れはMOONGIFTの記事に詳しいです。
ひととおりいじったあとでブラウザのCookieを消したら編集したデータが飛びました。
ローカルにあるYogurtのファイルはビルドされた日付のまま上書きされた様子ではありません。
このことから、デモサイト上でガンガン編集してしまっても問題ないものと思われます。
一見すると共同編集サイトなのかな？って雰囲気ですが、ウェブアプリってことですね。
PROJECT
PROJECTがひとつのサイトって意味らしいです。
トップページでNEW PROJECTをどんどん増やせますが、書きたい項目ごとにPROJECTを作成しても意味がないってことですね。
DOWNLOAD
編集してプレビューしてサイトが完成したら右上のDOWNLOADボタンをクリックします。
プロジェクト名でZIPが落ちます。
ZIPを開くと中に入っているのはエントリー名のHTMLとsetting.jsonだけです。
エントリー名のHTMLを開くと、プレビューしたものと全く同じサイトが表示されます。
ソースを見るとKokushin氏制作のCSSフレームワークUNYがオンラインで読み込まれているようです。
そのためHTMLファイルだけでプレビューしたものと全く同じサイトが表示できるのですね。
IMPORT
ダウンロードしたsetting.jsonを開くことで編集中のプロジェクトを復元することができます。
ただし、ベータ版ということで挙動が不安定です。
1. Cookieを消去していない状態での復元
トップページにダウンロードしたものと同じプロジェクトがある状態での動作検証です。
JSONの冒頭にIDがあり、IDに対応したプロジェクトに記事が復元されます。
気をつけなければならないのは、プロジェクトAでプロジェクトBのsetting.jsonを開くと、プロジェクトAは何の変化もなく、プロジェクトBに記事が追加されます。
何の警告もないので、同じ動作を繰り返すとプロジェクトBを開いたときに大変なことになります。
この辺はベータ版なので仕方ないことですが、編集中のデータはCookieを消さない限りはローカルに保存され続けるので、下手にIMPORTを使わないほうが無難といったところでしょうか？
2. Cookieを消去した状態での復元
トップページにダウンロードしたものと同じプロジェクトがない状態での動作検証です。
プロジェクトAでプロジェクトBのsetting.jsonを開くと、プロジェクトAの記事が消えて、プロジェクトBは復元されませんでした。
プロジェクトAの記事はダウンロードしてなければ復元できません。
この動作検証ではデフォルトが吹っ飛んだだけですからまたCookie削除すれば元通りになりますけど…
これはダウンロードしたファイルを別のブラウザに持っていっても作業が続行できないってことでしょうか…
作業状態を復元できないと、結局HTMLファイルを修正することになるので、静的サイトジェネレータとしての存在意義が揺らぎますね。
動画・音楽の埋め込み
できません！
ためしにSoundCloudのEmbedを貼り付けてみましたが、HTMLがそのまま表示されてしまいました（しかもはみ出してる…）。
記述するものはマークダウン形式じゃないとダメみたいです。はてなダイアリーやはてなブログみたいにHTMLとマークダウンを混在させられないようですね。
で、これは誰得なのか？
静的サイトジェネレータってのは、要はデータベースを使わないブログが作りたい人向けのツールですよね。
Yogurtの場合、オンラインサービス（ウェブアプリ）なので、完成したサイトをFTPでローカルからサーバーにアップするところはサポートされません。
最低でもそのへんの知識がある人向けのモノなので、静的サイトジェネレータの中では使いやすい部類に入るとは思うけど万能ではないって感じでしょうかね？
データの保持に関してはブラウザのCookieに依存する形なので持続性や再現性の面で問題があり、個人利用に制限されてしまいます。
複数人で更新するブログには使えないわけです。Publiiもそうでしたが、どうにも静的サイトジェネレータって複数人での運用が想定されてない気がします。
この複数人っていうのはクライアントとウェブ制作会社ってこともあるわけで、ユーザーサポートとかも厳しくなってしまうわけですよね。出向して直接当該PC上で直さないといけなくなる。
みんなWordPressの代用になるデータベースを使わないブログを探していると思いますが、結局仮想サーバでWordPressを立ち上げて記事を書き、プラグインで静的サイトをジェネレートしたほうが手っ取り早いという結論になってしまうようです。
惜しい！！
シンプルなテキストサイトを作る分には使えそうな雰囲気です。
