ここ数ヶ月、プログラミング初心者＆Perl入門者向けの無料勉強会「Perl入学式」のサポーター活動の一環として、公式ブログの更新作業に関わっています。
Perl入学式 公式ブログ
ここで言う「更新作業」というのは、記事を書くことではなくて、執筆担当の人が書いた記事をlivedoor BlogにUPする係、みたいなことです。
え、そんなのべつに、書いた人がやればいいのでは・・と思われるかもしれませんし、僕も今書きながらそのように思わなくもなかったですが、やっぱりそれはちょっと違うのです。
ブログUP係の意味と意義
Perl入学式では、現在ほぼ毎回、各地域での開催ごとに、開催前の告知と、開催後のレポート記事をUPしています。
カリキュラムは隔月で毎年4月から3月まで、年に6回（途中参加・中断もOK）、3地域（東京・大阪・福岡）で開催されており、今年度はすでに5回まで終わっていますので、単純計算でも「5（回）*3（地域）*2（開催前＋開催後）」で計30本もの記事が、昨年4月から現在までにUPされていることになります。
・・と、これも自分で書きながら「すごいな！」と思ってしまいましたが、冷静に考えるとボランティアにしてはちょっとやりすぎなレベルかもしれません。
で、それは自分たちでもわかっていて、今年の4月以降、つまり次期2015年度においては、開催前の告知記事は3地域まとめて1本にしよう、という話も出ているので、そうなれば、現状だと年間
6（回）*3（地域）*2（開催前後）=36本
であるところ、
6（回分の告知）+（6（回）*3（地域分のレポート））=24本
ということで12本も減りますね。
ああ、でも東京は各回補講があるので、+6で30本か？
まあ、細かいことは今後決めていきましょう。
なぜ負担を分散するのか
ということで、もうお分かり頂いたかと思いますが、何しろ記事が多いので、負担分散は大きなテーマです。
というのも、ボランティア（無償活動）というのは、僕も数年間、震災復興支援のボランティアに関わっていたりしたので、多少は経験があるのですが、どうしても一時的にワーッてなって、すぐ消耗して継続できなくなる・・というのがありがちなパターンです。
で、それは全然「悪いこと」ではなくて、思うにすごく自然な、まさに「放っとくとそうなる」という意味で、人間にとっては避けがたく起こりえることなんだと思います。
だから余計に、「Perl入学式は良い試みであり実践だけど、一時的な頑張りによってパッと散るのではなく、無理のない活動パターンをきちんと構築して、着実にその価値を生み出し続けてほしいな」と思っています。
そしてその方策の一つとして、各人の負担がなるべく少なく済むよう、執筆者はMarkdownファイルで執筆するところまでを担当作業として、その先のパブリッシュ作業は僕か校長（@__papix__さん）がやる、という感じに今はなっています。
好循環をつくる
この方式の良いところは、まず執筆者の担当作業を「Markdownでテキストを書くこと」のみに絞ることにより、「誰でも」担当できるということです。
「誰でも」というのは、労力が少ないから、ということでもありますが、同時に、技術的にもハードルがそんなに高くない（エンジニアが技術的な理由でMarkdownを書けないという事はそうそうナイと思われる）ということでもあります。
これがもし、livedoor BlogへのUPまでをセットにしていたら、普段同サービスを使っていない人にとっては、いちいちサインインして、慣れない設定画面を開いて、さらにはいくら本業ではないと言っても、見知らぬ人たちに向けて文章をパブリッシュするわけですから、最終的な見栄えの調整などもある程度は気にしなくてはならず、一言で言って「気が重い」というか「面倒」というか、他人から見れば「あとはUPするだけ」であっても、本人にとってはその「だけ」が地味に大きなコストとなってくることが容易に想像できます。
逆に、この「UPするだけ」を、専任の人間がやったらどうなるかと言うと、執筆者は執筆作業までをやればいいので、比較的簡単に取り掛かることができ、簡単にできることから持ち回り（リレー形式）をしやすくなり、持ち回りができるから一人あたりの作業も軽くなり、また一方のUP担当の方は短いスパンで同じ作業を繰り返すので段々ルーティン化し、一回あたりの負担がどんどん軽くなり、大体同じ人が校正するので仕上がりの精度も一定に保たれ・・と、まあ良いことづくめなわけです。
長くなりましたが、ここまでが前置きです。
HTML変換の実情
さて、上記のような次第でUP担当をやっている僕ですが、具体的に何をやっているのかというと、
- 執筆者がGitHub（のPerl入学式用プライベートリポジトリ）にpushしたMarkdownファイルをgit pull。
- そのまま同Markdownファイル上で簡単に文字校正。（書き手によっていろいろバラつきがあるので、最低限の書式統一やわかりづらい表現を勝手に修正したり）
- 修正完了したデータをgit commit & push （関心のある書き手はGitHub上でどこが変更されたか差分を確認するでしょう）
- PerlのMarkdownからHTMLへ変換するモジュールを通す
- 変換されたファイルをVimのquickrun.vimまたはprevimでプレビュー
- とくに問題なければlivedoor Blogの編集画面で「HTMLタグ編集」を選択し、テキストをコピペ
- カテゴリ等を設定して公開
という感じです。
少し前までは、「4」のPerlモジュールの工程を抜かして、「5」のVimスクリプトで出てきたHTMLページをブラウザから保存して、そのソースを使ったりしてみていましたが、今は上記の「モジュールを噛ませる」フローの方がプログラマブルというか、手軽な感じがして気に入っています。
また、その方式にしてからは、以前なら20〜30分ほどかかっていたのが、直近では10分未満ぐらいで作業完了したりして、この感じで合ってるのかな、とも思います。
（単にルーティン度が増してきた＝慣れてきただけでは、という気もしますが）
具体的にどんなモジュールを使っているのか？
肝心のMarkdown to HTML的なPerlモジュールについて、以前に試したときはあまり上手くいかなかったというか、思ったとおりに変換されない印象があったのですが（だからブラウザから保存、とかやっていたのですが）、最近になってあらためて「やっぱりもっと手軽にやりたい・・じゃなきゃ継続性落ちる・・」と追いつめられるようにトライし直したら、案外どれもこれも遜色ないというか、普通に使える感じでした。
具体的には、以下の記事を参考にしつつ、
- CPAN modules for converting markdown to HTML | NeilB [blogs.perl.org]
- CPAN modules for converting markdown to HTML
しつこくも後者で扱われている9種類を全部手元で検証してみたのですが、上記のとおり大きな違いはあまりなく（正確には「Markdent」で盛大なエラーが出たりしましたが）、最終的には以下あたりがシンプルな仕上がりというか。
DR::SunDown
Text::Markdown
Text::Markdown::Discount
とくには、「Text::Markdown」がある意味一番スタンダードっぽい感じで、また不足もなかったので、今はそれを使っています。
実作業としては、モジュールをcpanmでインストールした上で、
$ cpanm Text::Markdown
手元の作業ディレクトリを以下のように構成しておいて
. ├── in.md ├── md2html.pl └── out.md
in.mdに校正済みのMarkdownデータを入れて、実行ファイル（ここでは「md2html.pl」）を以下のように記述。
#!/usr/bin/env perl use strict; use warnings; use Text::Markdown qw(markdown); my $in = `cat in.md`; my $html = markdown($in); open my $fh, '>', 'out.md'; print $fh $html; close $fh;
で、実行するとout.mdの中にHTMLデータが入るという仕組みです。
さらに実践的に、これを直近のブログ記事で言うと、
これがin.md。
これがout.md。
これがプレビューしてるところ。
これがlivedoor BlogでHTMLをコピペしているところ。
という感じです。
まとめ
ということで、単に普段、MarkdownテキストをHTMLに変換する際、どんなことをしているか、というメモを残しておきたくて書き始めた記事でしたが、例のごとく大仰になってしまいました。
エッセンスだけを簡単にまとめると、以下の3点に収まると思います。
- 負担を分散して継続的に良い実践を行おう
- MarkdownをHTMLに変換する技術、もっとスマート＆洗練された方法があるはずだと思うけど、現状自分にはこれが最大限
- livedoor Blog が Markdown記法をサポートしてくれたらいいのに
以上です！
