はてな・ライブドアと使ってきて、Rails製自作ブログに流れ着いた経緯とか:ミームの死骸を越えてゆけ++

先月から、新しい場所（ここ）でブログを書いてる。ところで僕にはブログ奨学生としてライブドアで書いたブログと、さらにそれ以前にはてなで書いていたブログがある。

両方ともブログサービスとしては日本で有名なもので、機能も充実している。なにより僕の書いてきた記事=黒歴史が溜まっている場所なので、愛着もある。一方このブログはRails+MongoDBで自作したもので（少なくとも今のところ）「テキストを書いて公開する」という最低限の機能しかない。

この記事ではブログサービスを離れた理由、自前でブログを設置するにしてもWordpressやtDiary, Jekyllといった選択肢があるのになぜ自分で作ろうと思ったのか、というあたりをつらつら書く。

怠惰についてと、採用しなかった選択肢

ブログ管理が面倒

はてな、ライブドアといったブログサービスから離れていった理由は、記事管理、というか管理画面(CMS)と付き合うのが面倒になったからだ。

ふつう、ブログの更新は次のような手順を踏む。まず手元でブログ記事を書き、その後ブラウザで投稿画面を開いて、書いたブログをコピペして、書式を整えて、画像をアップしてレイアウトを整えて、プレビューを見て、よしと思って公開。

半年前に転職しプログラムを書くようになってからというものの持ち前の怠惰さに磨きがかかり、この更新のプロセスすら面倒くさくなりブログを書こうかなと思ってもそのたびに気が失せていた。

もちろんTwitterやGist , Qiita - The best way to log and share programming knowledge. のような短文・スニペットを投稿する場はあるのだけど、僕の場合は長々とした日本語を書きたいタチ。日本語テキストを書くときもVim(MacVim)だから、Vimで書いてコピペとかめんどくさい。ファイル編集して、そのままTerminalからブログにアップしたい。

...というわけで、理想に近い形を求め、自前ブログの検討を行った。

Jekyllも、GitHubも、あるんだよ

自前でブログを開設する時に最も人気の選択肢はおそらくWordpressだろうと思う。もちろんこれも検討したのだが、WordpressはPHP製である点がひっかかり候補から外した。PHPを毛嫌いするわけじゃないが、仕事でRubyを使っていて、経験上「学習対象が拡散しすぎるとよくない」とわかっていたので、Ruby製のブログツールがあればそっちを選ぼう、と思って探し始めた。

Ruby on Rails製という視点で探してみると、Mephisto やTypo: the missing weblog engine というRails製ブログシステムが見つかった。Typoの方はTwitter Bootstrapを使ったりして、かなり今風のデザインでいい感じ。それでも、これも結局CMSから更新する「いわゆるブログ」だったので、保留しておいた。

Rails製ではないものの、日本発の (ソースコード)もある。比較的昔から使われているシステムなので運用ノウハウがそれなりにあるだろうし、困ったときコミュニティに助けを求めやすい(日本語でおｋ)というメリットがある。プラグインも簡単に書ける。しかし、やはりこれもCMSから更新するスタイルだったので保留。

というわけで、No CMSの方針で探してみたところ、Jekyll というRuby製のツールが見つかった ( @tfmagician に教えてもらった )。Jekyllの使い方は非常に簡単で、_posts以下にmarkdownもしくはtextile形式で書いたファイルを保存してjekyllコマンドを打てば_site以下に静的HTMLが生成される。あとはレポジトリをサーバにアップして、ApacheやnginxといったHTTPサーバに_site以下のファイルをサーブさせるだけでいい。もしくは、Jekyll自体がWEBRickベースのHTTPサーバの役割も持っているので、単体でも公開することが出来る。

詳しい使い方はmattnさんの記事（Big Sky :: Jekyllで始める簡単ブログ）か、本家サイト（なにこのデザインかっこいい）を見てほしいのだが、僕にとってのメリット/デメリットは次のようになった。

Jekyll
- ○: 最小限の要素からなり、全体を掴みやすい
- ○: 静的サイトのシンプルさを保ちつつ、ブログとして使うための動的機構も備える
- ○: デフォルトでMarkdownが使える
- ×: テンプレートエンジンのliquidにクセがある。ERBかHaml使いたい。。

また、Jekyllをベースにした GitHub Pageというものもある。GitHubアカウントさえ持っていればマニュアルに従うだけで簡単に自分のサイトが作れて、レポジトリ管理もGitHubに任せることが出来るという優れもの。

このJekyllの更新スタイルは僕にとって目から鱗であった。

正直なところ「サクッと書いてサイトを構築する」要件だけならJekyll/GitHub Pageは十分以上に要件を満たしていた。それでも僕はいまいち満足できないようだったので、一体何が不満なのかと考えてみると、

本当に欲しいものは

既存のどのシステムよりも怠惰に使える俺の俺による俺のためのブログシステム
今後モノを作るときに土台となる経験

である、ということに気付いた。「簡単に更新」だとか「No CMS」という方針は欲しい要件の一つに過ぎず、思い通りのものが欲しくて、ついでに将来「思い通りにものを作る」ためのスキルも得たい、という。このように自分とのコミュニケーションにも苦労する有様ですが、なんとか本当に欲しいものにたどり着くことが出来ました。

「ぼくのかんがえたさいきょうのブログ」

自分の満足するブログを作成するにあたり、仕事でも使っている組み合わせのRails + MongoDBで作ることを決めた。

そもそもRailsでブログを作ること自体は非常に簡単で、Railsを一躍有名にした「10分でブログを作る」といったような「N分動画」がわんさか落ちているくらい。これは、Railsの特性上「典型的な構成のWebアプリケーションであれば、デフォルトで生成可能なテンプレートで事足りる」ためだと思う。

例: Ruby on Railsで10分で作るTwitterもどき - ZDNet Japan
公式のRailsプレゼン一覧: Ruby on Rails: Screencasts

典型的な構成ならサクっと作れるということは、裏を返すと、典型的じゃない作り込みをすればそれ相応の手間暇がかかるということ(当たり前だが)。いくら10分でブログが作れると言っても、10分で枠組みだけ作った真白なブログを全国公開するのはさすがに気が引ける。僕もひととおり最低限の形を整えるまで2週間くらい作ってた。

実は一番手間を掛けたのはデザインなのだけど、その過程で、作りたいレイアウトをHTML+CSSで表現するコツがなんとなくわかってきたりして、これはこれでウマウマ。

構成

No CMSの方針のもと、RailsでJekyll的なブログ管理を実現しようとした。

まずは markdownで記事を書き、Rails.rootに置いたpostsフォルダに.mdを保存する。次に「エントリ処理」と書いている部分を実行するわけだが、以下1-4の部分からなる。

markdownファイル名から記事のURLを決定
- 例: 20120207-rails-special.mdというファイルならhttp://DOMAIN_NAME/20120207-rails-special
markdownテキストをMongoDBに保存
markdownからHTMLにrender (Redcarpet)
pygmentsでソースコードのシンタックスハイライト

本番サーバでは、用意したTaskファイルをRakeで走らせている。これはいいとして、ローカルでもいちいちrakeを実行するのが面倒くさい。watchrでファイルの変更を監視して自動的に更新するようにしようと思う。

書式ルール

markdownで記事を書くのだけど、細かく言うとタダのmarkdownファイルではなく、タイトルとかカテゴリなんかも定義してやる必要がある。たとえば本エントリは、次のように書かれたmarkdownファイルによって作成されている。この書式もJekyllをヒントにして定義した。

1行目にh1としてタイトルを書く
タイトルから最初のhrまではYAMLとして解釈される。タグやカテゴリなどのエントリ情報をここで定義。
- published: trueにした記事のみ，一般公開される。ローカル環境ではpublished: falseも含めた全ての記事が見える。
中央が本文として保存され、通常のmarkdownとして解釈される。
hrで本文が区切られ、後はメモ扱い。ボツった断片や公開しない覚え書きを残しておくことが出来る。

という具合。不都合が出てきたら適宜拡張していくつもり。

and miscs.

自由度。

当たり前だけど、自作すると自由度が素晴らしい。ブログパーツは最悪自分で実装すりゃいいわけだし、JavaScript製のパーツがたくさん出回ってるから、むしろ制限なく貼り付けられる自前サーバの方がやりやすい。アクセス解析も、VPSにWebAnalyzerをインストールしたりGoogleAnalyticsを使ったりとがんばればいいわけだし。

ページレンダリングとキャッシュ

↑で「一連の手続きをまとめて実行」と書いたが、実は現在のところ3,4の処理をviewのrender時に実行している。DBに保存したmarkdownテキストからいちいちHTMLを生成している。ここがおそらくボトルネックとなり、最初の記事を公開した後にブログが重すぎる現象が発生したため、個別記事に対してページキャッシュを生成することで回避している。

Redcarpetは素晴らしい

Redcarpetは、MarkdownのC言語実装であるsundownを元にしたRuby gemであり、Rubyで独自に拡張可能なのが嬉しい。たとえば僕は<http://hogehoge.com/::hateb>と書けばタイトルとはてブ数が得られるように拡張してる。ちなみにタイトルの取得にはMechanizeを使ってるのだけど、正直オーバースペックな気がする。curlで取ってきて<title>内を見る、くらいでいいよなあ。

拡張についてはそのうち詳しい蘊蓄記事でも書こうと思う。

数少ない不満としてsundownがそもそもMarkdownのfootnoteが実装されていないようなので、forkして初pull-requestを目指して修正をがんばっている。Rubyに慣れたゆとり脳にC言語は骨です。

ソースコードのSyntax Highlight

ライブドアブログでは記事中にソースコードを書いたとき、どうもしっくりくるデザインにならなかったりしたので、自分で作るブログではラクにやりたいと思って、Qiitaを作ってる @yaotti にちょくちょくアドバイスもらいつついろいろ調べた。

Gist, JavaScriptによる描画時マークアップ(SyntaxHighlighter, etc)などもあったが最終的に選択したのはPygments。Pythonで実装されたソースコードシンタックスライブラリ。

使うためには

HTML内のソースコード部分を処理して、細かーくspanでclass分けする。
お好きなスタイルのCSSをpygmentizeコマンドで生成、ページに適用する。

のふたつの処理をどこかで実行する必要がある。僕は#207 Syntax Highlighting - RailsCastsを参考に、helper部分にその機能を持たせた。app/helpers/application_helper.rbでこんなことをしている。

    def replace_code_for_pygments(html)
      doc = Nokogiri::HTML(html)
      doc.search("//pre").each do |code|
        if code.child.node_name == "code"
          if code.child.attributes["class"].present?
            #TODO: define file name here and display it
            types = code.child.attributes["class"].value.split(":")
            lexer = types[0].presence || ""
          end
          lexer ||= "sh" # default lexer
          code.replace Pygments.highlight(code.text, :lexer => lexer)
        end
      end
      doc.search('.highlight').each do |high|
        high.replace (Nokogiri.make('<div class="codewraps"><div class="codewrap">'+high.to_html+'</div></div>'))
      end
      doc.to_s
    end

描画前のHTMLをNokogiriに食わせて、ソースコード部分を見つけたらPygments.highlightに渡してマーク亜婦させている。当初はAlbinoを使っていたが、pygments.rbの方が速いという情報を貰ったので切り替えてみた。

標準のMarkdownは4個の半角スペースでインデントされたブロックをソースコードと見なすのだけど、Redcarpetの場合は:fenced_code_blocksというオプションをtrueにすれば、3個以上のbackquoteで囲むことでソースコードと認識させることが出来る。

ソースコード本体とは別にメタ情報を含むことが出来るので、言語やファイル名の指定も可能になる。

僕が今使っているのはpygments-style-github 0.4 : Python Package Indexというやつで、pipを使ってインストールすればpygmentizeコマンドの-Sにgithubスタイルを選択できるようになる。

% (sudo) pip install pygments-style-github
% pygmentize -f html -S github -a ".highlight pre" > app/assets/stylesheets/pygments.css

そうそう。yaottiにリクエストしたら、Qiitaでpygmentsを採用するまでに検討した選択肢とそのメリット・デメリットなどを「プログラムのシンタックスハイライト方法の比較 #Ruby #JavaScript - Qiita」にまとめてくれた。thx!

いじょ

まあ自分で作ってはみたものの、文書を公開できればいいや、という大半の人はJekyllで満足できると思う。いまのところオレオレブログツールを一般公開するつもりもない。

要するに何を重要視して何を軽視するかという問題であって、僕にとっては絵文字が使えたりブログパーツが充実していたりきれいでWYSIWYGなエディタ付きCMSよりも、デザインや機能のカスタマイズがしやすく、テキストで記事を書いてからプレビューで確認し、公開するまでの時間が短ければ短いほど嬉しい。そんでもって、理想ブログを追求する行為がプログラミングの勉強も兼ねてればベストなのだ。

僕はわりと後ろ向きな自己責任論者なので、「ブログサービスやツールの制限」のおかげでやりたいことができないよりも、環境としては何でも出来るが「単純に実力が足りないから実装できない」方がわかりやすいし、好みだ。もしくは「いざ実装することを考えたらそれほど重要な機能ではないと気付く」とか。

ライブドアから完全に「移行」するかどうかは決めてないが、しばらくこっちを育てていこうと思う。