みなさん、技術ブログの運用って面倒じゃないですか？ぼくは面倒です！ ネタを貯めて、記事を書いて、公開する。会社的にも・個人的にも意味があり、 そのプロセス自体も楽しいものです。 大抵の場合、ブログの運用には便利なブログエンジンやブログサービスを使います。 ところが、長期間運用していると、「もうちょっとなんとかならないか？」と思うことがあります。 例えば、以下のようなことです。
- 拡張できない・しづらい
- 使い慣れた言語とエディタが使えない・使いづらい
- 共同作業しづらい(Git & GitHubが使えない等)
もちろん、ブログエンジンやブログサービスには管理が簡単、すぐ使えるなどのメリットもありますが、 それにこだわらない場合はもっといい方法があるはずです。
クラウドワークスでは、Middlemanを使って、軽く・モダンにブログを運用してこれらの問題を回避しています。 この記事では、Middlemanを使うことにした理由をご説明させていただきます。
技術ブログの運用に悩まされている皆さん、これから技術ブログをつくろうとされている皆さん、 ぜひこの記事を参考にして、Middlemanを使ってみてください！
目次
Middlemanとは？
Rubyで書かれた、拡張性が高い静的サイト生成ツールです。 利用者がページのソースを好きな言語で書き、Middelmanがそれをビルド・デプロイします。 ビルドやデプロイの部分はプラグインで拡張することができます。
プラグインがカバーしているものも含めると、以下のようなテンプレート言語・マークアップ言語・プログラミング言語に対応しています。
- Slim
- Haml
- ERB
- SASS・SCSS
- CoffeeScript
また、以下のような方法・サービスでデプロイできます。
- rsync
- ftp
- sftp
- GitHub Pages
- Amazon S3
- Rackspace Cloud Files
- Google Storage
採用の理由
Middlemanには前述のような特徴がありますが、それはさておき、 クラウドワークスのエンジニアブログをMiddlemanで開発・運用することにした理由は、 以下の3つです。
- Rubyで書かれている
- 使い慣れた言語とエディタで記事をかける
- Git & GitHubが使える
Rubyで書かれている
MiddlemanはRubyで書かれています。 そのため、私たちにとっては拡張しやすい、ということが採用の一つの理由です。
拡張しやすい
私達はほとんどの開発でRubyを使っています。 Middlemanを採用すれば、必要な機能が足りなかったとしても、使い慣れたRubyでMiddlemanのプラグインを 開発するなどして対処できます。 そもそも拡張できない、不慣れなPHPを書かなければならない、という自体にはならないので、安心感があります。
使い慣れた言語とエディタで書ける
Middlemanを使う場合、好きな言語やエディタで記事を書くことができます。 ブログエンジンやブログサービスを使うとき、個人的に一番気になるのがここです。 そのブログ特有の記法を覚えたり（とはいえ、最近はMarkdownで書けるブログが増えましたが）、 シンプルなテキストエリアに生HTMLを打ち込んだり、使い慣れないWYSIWYGエディタを使ったりする必要がありません。
脳のコンテキストスイッチが最小化される
私たちの場合、技術ブログの記事は業務の合間に書きます。その場合、記事はサクッと書いたほうが断然いいです。
書くのに手間取ると、業務が差し込んできて、書けないまま数日が立ち、そうしているうちに記憶も色あせて、 余計に書きづらくなり、結局書かないまま数ヶ月すぎる・・・ということが起こりえます。経験ありませんか？僕はあります！ そうでなくても、時期的にホットな内容なら早く書いて、早く公開したいところです。
記事をサクッと書く一つの方法は、脳のコンテキストスイッチを最小限にすることです。 隙間時間があったら、普段の開発で使い慣れたエディタと言語ですぐに記事を書いて公開できれば、それに越したことはないですよね。
例えばブログエンジンなどを使う場合、Haml・Slim・CoffeeScript・SCSSなどは単純には使えません。 手元でビルドして、スタイルの設定ページへコピペ・・・みたいなことをすれば可能ですが、面倒です。
使い慣れたエディタが使えない、使えたとしても、非公式なブラウザ拡張が必要だったり、「自分のエディタは対応してない！」といったことがあります。 エディタで書いてから、ソースをコピペする？ それでもいいのですが、コピペ後に記事を修正したくなったら、またエディタにコピペして戻す、といったことになって２度手間感がありますね。
Middlemanなら、使う言語やエディタは各個人の自由です。私もこの記事はMarkdown + ERB、エディタはAtomで書いています。
Git & GitHubが使える
Middlemanを使う場合、ソースはGitなどで管理できます。 Gitで管理すればGitHubが使えます。
ブログエンジンなどでも、記事の執筆やシンプルな共同編集・レビューは問題無く行えます。 Git & GitHubが使えることによるメリットは以下のとおりです。
- GitHub上で公開前の記事をレビューできる
- 記事が不慮の事故で消えない
- CIと相性がいい
GitHubでレビューできる
クラウドワークスではGitHubを使って、公開前の記事をプルリクエストでレビューするプロセスにしています。 すると、GitHubのプルリクエスト上に公開前の記事に対するレビューコメントをつけて、レビューが完了したらマージ、ということができるようになり、レビュープロセスが可視化されます。 レビュー完了時のチャットへの通知なども、普段の開発でGitHubを使って行っているのと同じように実現できます。
記事が不慮の事故で消えない
Gitで気軽にコミットできるので、うっかりブラウザバックして書きかけの記事が消えたり、エディタで予め書いておいてコピペする必要がありません。
CIと相性がいい
普段の開発で行っているように、ブログもCIすることができます。 MiddlemanプロジェクトはただのRubyプロジェクトでもあり、使われているツールやライブラリ郡もRuby on RailsでWebアプリ開発をしている人なら見知ったものが多い関係で、 CIと相性が良いことが理由です。
クラウドワークスのエンジニアブログの場合、GitHubとWerckerを使って以下のような流れのCIを回しています。
- ローカル環境で確認済みの記事をGitHubへpushすると、Werckerでビルドされる
- Werckerでビルドが通ると、テスト環境(Amazon S3)に自動的にデプロイされる
- 記事のプルリクエストを送る。プルリクエストをマージすると、Werckerでビルドされる
- Werckerでビルドが通ると、本番環境に自動的にデプロイされる
CIでは、例えばHamlやSASSコードにシンタックスエラーがある場合にビルドが落ちてくれます。 それによって問題にすぐ気づくことができ、また明らかに壊れたページを公開してしまうこともありません。 記事を公開するときも、プルリクエストをマージするだけでよいので、 私たちエンジニアは記事の執筆とレビューに集中することができます。 捗ります。
まとめ
クラウドワークスでは以下の3つの理由から、エンジニアブログをMiddlemanで作っています。
- Rubyで書かれている
- 使い慣れた言語とエディタで記事をかける
- Git & GitHubが使える
私たちと同じように、普段の開発でRubyを使っている、エディタや言語にこだわりがある、 GitやGitHubで執筆からテスト・公開までのフローを円滑にしたい・・・ そんな皆さんに、Middlemanをおすすめします！ ぜひ、この記事をきっかけにMiddlemanでブログを作ってみてください。