bpe : org-mode で Blogger

イマサラですが、2015/6/15 に googlecl が動かなくなったことで、現在 bpe は使用できません。

Table of Contents

• Markdown で Blogger
• org-mode で Blogger

Markdown で Blogger

Blogger は、残念ながら Markdown に対応してないんですよね。

Blogger で 無理やり Markdown を使うために、今までは Tips - MarkdownをHTMLにembedする : 404 Blog Not Found の方法を使ってました。
簡単に言うと、textarea 内に Markdown を書いて、js で HTML に変換するってだけです。

この方法のいいところは、Markdown -> HTML 変換なしで Markdown のまま post できることです。
自分で HTML に変換してから post だとそのワンステップ自体も、後で Markdown と HTML を同期するのも面倒ですから。

この方法の問題は、スマートフォン等のモバイルデバイスでうまく表示できないことです。
そりゃナシだろってくらい致命的な問題ですが、これまではそれを知ってて無視してました。
アリテイに言うと、スマートフォンからのアクセスを捨ててたわけです。
今ではたしかに大問題ですが、その昔はそれほどでもありませんでしたし。
ていうかもっと正直に言うと、すっかり忘れてたんです。
最近ひさしぶりに自分のブログを iPhone で見て、そういやそんな問題あったなと。

それで、そろそろなんとかしなきゃならないなということで、このエントリを書くにいたったわけです。

Blogger で Markdown を使うには、StackEdit というテもあります。
StackEdit は Web 上の Markdown エディタで、入力した Markdown を直接 (Blogger を含む) blog 等のサービスに post する機能があります。

ただ、残念ながら HTML タグが含まれているとうまく変換できなくなってしまう問題がありました。
HTML を埋め込めない Markdown って …。
それに、ブラウザ上のエディタなんて、かったるくって使ってられないですよね。

tumblr なら、 Markdown に対応してるんですよね。
tumblr も使ってる のでそっちに一本化してもよかったんですが、
放置してどうしようか迷ってるうちに、org-mode で Blogger に post するテを発見したので、そっちを採用することにしました。

考えてみたら、Markdown より org-mode のほうが more better ですよね。
Markdown なんて、表現力でいったら org-mode のサブセットに過ぎないし、org-mode は HTML エクスポートくらい普通にできるんだし。
なんでスッとそっちを思いつかなかったのか、不思議です。
とはいえ、Tips - MarkdownをHTMLにembedする : 404 Blog Not Foundを採用した当時は、まだ emacs 使ってなかったのでしょうがないんですが。

ただ、HTML エクスポートができるとはいえ、org-mode で快適に Blog を書くためにはもう一つ条件があります。
HTML への変換のステップをなくすことです。
幸い、変換 -> post を一気にやってくれる elisp を 作ってくれてる人 がいたので、そこは No 労力でクリアです。

org-mode で Blogger

org-mode から Blogger に post するには、bpe を使います。

もし、まだ googlecl をインストールしてなければ、gdata-python-client と一緒にインストールします。
で、いったん

$ google blogger list

でもして、認証を通しておきます。

ここでハマったのが、googlecl が PYTHONPATH に設定したパスを見てくれないことでした。
そのせいで、gdata を import してるとこで落ちてしまいます。
結局、googlecl の shebang のパスと僕の環境の python のパスが違ったという、なんでもないことが原因でした。
brew とかで適当に python をインストールしたまま放置してると、こんな簡単なことでつまずいてしまいますのでご注意を。

あとは emacs の設定ファイルに

(require 'bpe)
(require 'htmlize nil 'noerror) ; to fontify source code block on your blog.
(setq bpe:account "your mail address on google blogger")
(setq bpe:blog-name "your blog name")
(define-key org-mode-map (kbd "C-c C-p") 'bpe:post-article)
(define-key org-mode-map (kbd "C-c C-i") 'bpe:insert-template)
;; For Japanese, default is $LANG environment variable.
(setq bpe:lang "ja_JP.UTF-8")

と書けば準備 ok 。

org ファイルを作ったら、上の define-key にあるとおり C-c C-i すればヘッダのテンプレートを挿入してくれます。

こんなかんじ

#+TITLE:
#+OPTIONS: toc:nil \n:nil num:nil
#+TAGS:
#+AUTHOR:

タイトル、タグ、および作成者 (必要ならオプションも) を記入したら、あとは記事を書いて C-c C-p で post するだけですね。

しばらくはこのまま org-mode -> Blogger を使ってみて、もしイマイチだったら 他の elisp を試してみるか、org-mode から Tumblr に post するテもあるようなので Tumblr に引っ越すかも。

テキストエディタ

プログラマの主な仕事は、テキストエディットです。

いきなり断定からはじまりましたが、これは事実です。
プログラマの仕事は、テキストエディット以外にもいろいろあります。
ソフトウェア開発は、とても複雑な作業です。
見積、スケジューリング、進捗管理、要件定義、基本設計、詳細設計、テスト計画、単体テスト、結合テスト、統合テスト … etc。
やるべきことは、嫌になるほどあります。

それでもなお、いやしくもプログラマであるのなら、中心となるアクティビティはやはりコーディングです。
他のすべての作業は、コーディングに十分な時間がとれるように計画し、うまくコーディングできるように準備し、意図通りにコーディングできたかを確認するためのものです。
すべては、コーディングを中心に回っているのです。
まあ、少なくとも本来は。

コーディングという作業は、テキストエディットに他なりません。
プログラマにとって、テキストエディタは画家の筆であり、彫刻家のノミ、写真家のカメラです。
ですから、自分自身に合ったエディタを探すことと習熟することは、生産性や品質に大きく影響します。

今回は、このコーディングのための必須ツールである、エディタのハナシです。

• 僕のエディタ遍歴
• IDE について
• エディタに求めるもの

僕のエディタ遍歴

Emacs

僕の場合、結局 Emacs に辿り着きました。
Emacs は、Emacs Lisp というフルスペックのプログラミング言語を備えていて、これによって非常に高度な拡張が可能になっています。
Emacs 本体も、大部分が Emacs Lisp で実装されています。
このような自己記述的なあり方は、Eclipse などとも共通しますね。
非常に歴史のあるエディタなので、プラグインもかなり充実しています。
そして、これが大事なところなんですが、大昔からあるエディタだからこそ、完全にキーボードだけで操作できます。
手をホームポジションからほとんど動かすことがないため、テキストエディットが高速になり、気が散る機会が減ります。
途中で右手をキーボードから離して、マウスをチラ見して握り、またキーボードに戻って、ホームポジションを指先の感触でさぐるなんていう動作を今までいったい何回繰り返したでしょうか。
そのたびに、視線がディスプレイを離れ、一瞬集中が弱まってしまいます。
一生のうち、トイレで過ごす時間とマウスをまさぐるのに費やす時間の、どっちが多いでしょう。
というカンジで、僕はテキストエディットに関しては、できるだけマウス使わない派です。

Textastic

iPhone、およびiPadでは、それぞれ Textastic Code Editor for iPhone と Textastic Code Editor for iPad - Alexander Blach を使っています。 残念ながら iPhone を使うのをやめたので、現在は Textastic も使ってません。

80以上の言語でシンタックスハイライティングが可能で、Groovy にも対応しています。
また、フリックを使ってほとんどの記号をキーボード切り替えなしで入力することができる拡張キーや、カーソル移動を細かく制御できるナビゲーションホイールなど、コード入力を快適にする工夫がいろいろ cool です。

jEdit

Emacs の前は、jEdit (Macのみで動作する同名の国産エディタがありますが、それじゃないです) を使ってました。
jEdit は、個性的で素晴らしいエディタです。
Java で実装されていて、MAC、Unix、Windows、 OS/2、および VMS で動作します。
現時点で 200 以上のプログラミング言語をサポートしているので、たいていの場面で困ることはないでしょう。
BeanShell という、Java とよく似たシンタックスのスクリプトを採用していて、マクロ機能も強力です。
豊富なカスタマイズオプションと、プラグインマネジメントシステムを備えていて、非常に多くのプラグインが提供されています。
FTP プラグインを使えば、リモートホスト上のファイルを直接編集することもできます。
ただし、今のところ Markdown のサポートは、貧弱と言わざるをえません。
HTML にレンダリングした結果をエディタ内、またはブラウザを起動してプレビューするプラグインがありますが、編集中のテキストをリアルタイムにハイライトしたり、リンクを機能させたりすることはできないようです。
それと、jEdit もかなりの部分をキーボードだけで操作することができるんですが、そのための設定にちょっと時間がかかり過ぎるかんじがします。
また、キーボードで操作できないプラグインも多いので、完全にキーボードオンリーにはなりません。

秀丸エディタ

ずっと昔は、秀丸エディタを使っていたこともあります。
秀丸エディタは、動作が軽快なのが、最大の魅力です。
こちらもまあまあのマクロ機能を備えていますが、Emacs や jEdit のマクロ言語と比べると、いささか見劣りがします。
プラグインシステムはありません。
サポートサイトで、サードパーティ製のシンタックスハイライティングの定義ファイルやマクロのリストを公開していますが、整理なしで羅列されているので、同じことを目的とするものが複数登録されていることがよくあったりして、目的のものを探すのが面倒です。

その他のエディタ

Emacs にたどり着く前には、ターミナルでアクセスしなければならないリモートの Unix 系の環境では、Vim を使っていたこともあります。
当時の僕にとっては、ただ直感的でないだけで、GUI の使えない環境でやむをえず使う代替物でしかありませんでした。
初心者にとっては、本当のパワーよりも直感的であることのほうが魅力的なものです。
たどり着いた先がたまたま Emacs でなかったとしたら、おそらく Vim を使っていたでしょう。

やむをえず使ったといえば、インストールが制限されていて、他に選択肢がないときにさくらエディタを使ったこともあります。
が、そのまま使い続けたくなるような魅力は感じませんでした。

Top

IDE について

IDE といえば、代表的なのは Eclipse と Microsoft Visual Studioですね。
この 2 つでは、僕は圧倒的に Eclipse が好きです。
カスタマイズ性の高さもその理由ですが、プロプライエタリなものにロックインされるのも好きじゃないからです。
このところ、.NET 関連の開発をする機会がないのが幸いです。

最近は、プライベートではもっぱら IntelliJ IDEA を使っています。
けっこう気に入ってきているのですが、まだ使い始めて日が浅いため、これについてはまだ何も言えません。 結局、不満はありつつも IDE は Eclipse に収斂してきました。

こういった IDE のリッチなサポートにすべてを任せるのが、一番だと考えていた時期もありました。
一つの IDE を常に起動しておき、できる限りの作業をそこで済ませます。
それができない場合でも、IDE はバックグラウンドに立ち上げたままにしておき、1 日が終わるまでは、なるべく IDE を終了させない。
OS のデスクトップを作業スペースにするのをやめて、IDE そのものを作業スペースにするわけです。

このやりかたは、ある程度はうまくいきます。
起動の回数を減らすことで、IDE の最大の弱点である起動に費やされる時間を最小限に圧縮し、また IDE にとどまり続けることで、コンテキストスイッチングも軽減することができます。

しかし、やがてはこれにもうんざりしてきます。
やはり、いかんせん遅すぎます。
待ち時間は最小化できても、あれこれいろんなことで、ちょくちょく作業がインタラプトされるのが、次第に耐え難くなってきます。
今まさに頭の中に流れ込んできているインスピレーションを、新鮮なまま逃さず書き留めるにはニブすぎるのです。

IDE のオプションでオフにできるものは、すべてオフにした方がいいという意見を聞いたことがあります。
たしかに、そうすれば割り込みの頻度はかなり下がるはずです。
でも、僕はその意見には懐疑的です。
どんなにイライラさせられるとしても、IDE のたいていの機能はそれなりの理由があって装備されているのです。
すべてのオプションをオフにするのなら、素直にエディタを使ったほうがいいと思います。

IDE の豊富な機能は、魅力的です。
ある面では、その機能が作業の効率を大幅に上げてくれます。
でも、ときにはそれがかえって邪魔になることもあります。
いろんなことができるということは、いろいろ気を散らすネタがあるということでもあるのです。

IDE は、重量級のツールです。
巨大なコードベースの全体を把握し、あっちを覗いたりこっちをいじったりする必要がある場合には非常に有効ですが、範囲を絞って小回りのきくエディタで作業することができるなら、それにこしたことはないのです。
大型船には大型船の、タグボートにはタグボートの役割があるということです。

今は、Emacs と IDE を、場合によって使い分けています。

Top

エディタに求めるもの

さて、このようなエディタの変遷は、僕がエディタに何を求めているのか ー つまり、僕に合うエディタとはどういうものなのかを示唆しています。
今まで、僕はいったい何が欲しくてエディタを変えてきたのか、考えてみるとこういうことなんじゃないかと思います。

• 動作が軽快であること
• キーボードだけで全ての操作ができること
• 多くのプラットフォームで動作すること
• 高いカスタマイズ性
• 幅広い言語に対応したハイライティングやコードアシスト
• 強力なマクロ
• ネットワークごしのエディット機能

多くのプラットフォームで動作するという条件には、カスタマイズした内容のポータビリティも含みます。

この込み入った条件は、最初から明らかだったわけではありません。
長年のコーディング経験の中で、徐々に積み上がってきたものです。
1 つの決まった言語しか使っていなかった時には、幅広いプログラミング言語のサポートなど気にしませんでした。
Windows でしか仕事をしていなかった時には、マルチプラットフォームのサポートには注意を払いませんでした。
WEB アプリケーションのクライアントサイドスクリプトを嫌になるほどいじくりまわしてみるまでは、ネットワークごしのエディット機能にあまり必要性を感じませんでした。

Emacs は、上記の様々な条件を完全に満たしています。
現在、仕事上 Mac、Windows、および Linux を使ってます。
それら全ての環境で、Emacs を使用することができます。
しかも、Mac と Windows では、DropBox 経由で設定を共有しています。 今は github 経由でやってます。
本番環境にあるサーバでは、セキュリティ上さすがにムリですが、それでも設定ファイルを手動で持っていけば、ほぼそのまま利用できます。

そんなわけで、今のところ僕は Emacs + Textastic Code Editor を愛用しています。

ところで、 [Emacs] の素晴らしい能力を十分に活かすためには、プラグインの導入によるカスタマイズが欠かせません。 その点で、Emacsテクニックバイブル　～作業効率をカイゼンする200の技～ はとてもいいガイダンスになります。 [Emacs] に同梱のチュートリアルで、基本的な操作はすぐに覚えることができますので、それから、この本に掲載されているプラグインから使いそうなものを手当たり次第に入れてみるだけで、簡単にロケットスタートできます。 それで物足りなくなったときには、どうやったら他のプラグインを探しだしてインストールできるのかも、この本を読めばすぐわかるようになっています。

Heroku Buildpack Common Lisp を作りました : heroku labs:enable user-env-compile が廃止されたことについて

これです。
heroku labs:enable user-env-compile の廃止に対応するために、heroku-buildpack-cl を fork しました。

heroku labs:enable user-env-compile の廃止について

Buildpack を使うほうの対応は簡単で、単に heroku labs:enable user-env-compile を使うのをやめるだけです。
既に設定していた heroku config:add は、そのままでちゃんと compile プロセスに渡されます。
Buildpack を作るほうでは、 bin/compile の新しい第 3 引数に渡されてくる ENV_DIR ディレクトリから環境変数を読み込む必要があります。
やりかたは、 Buildpack API | Heroku Dev Center
に記載されている、以下のコードを参考にすれば (というか、まるコピで OK) np です。

export_env_dir() {
  env_dir=$1
      whitelist_regex=${2:-''}
  blacklist_regex=${3:-'^(PATH|GIT_DIR|CPATH|CPPATH|LD_PRELOAD|LIBRARY_PATH)$'}
      if [ -d "$env_dir" ]; then
    for e in $(ls $env_dir); do
      echo "$e" | grep -E "$whitelist_regex" | grep -qvE "$blacklist_regex" &&
          export "$e=$(cat $env_dir/$e)"
      :
    done
  fi
}

Heroku Buildpack Common Lisp について

サンプルアプリ
も用意したので、その readme を読んでもらえれば、簡単に動くサンプルが手に入ります。
…だけではさみしいので、以下、日本語で手順を書いときます。

1. もしまだ Heroku のアカウントを持ってないなら、まず Heroku のアカウント を作って、Heroku Toolbelt をインストールしてください。
2. サンプルアプリを fork してください。
3. cd heroku-cl-example してください。
4. Heroku Buildpack Common Lisp を使って、Heroku アプリを作ってください。
   こんなかんじです。
   heroku create -s cedar --buildpack https://github.com/craftsmanship/heroku-buildpack-cl.git
5. Common Lisp の実装を選択してください。
   heroku config:add CL_IMPL=sbcl または heroku config:add CL_IMPL=ccl
6. Web Server を選択してください。
   heroku config:add CL_WEBSERVER=hunchentoot または heroku config:add CL_WEBSERVER=aserve
7. SBCL のソースエンコード問題を回避するには、エンコードを指定してください。
   heroku config:add LANG=en_US.UTF-8
8. デプロイしてください。
   git push heroku master

これだけです。
Cloud で Common Lisp を使いたいと考えている人は、利用してみてください。

プログラミングClojure 第2版

プログラミングClojure 第2版 著者 : Stuart Halloway and Aaron Bedra オーム社 発売日 : 2013-04-26 ブクログでレビューを見る»

Lisp 方言なので、Lisper なら理解するのに苦労はない。
Java を知ってれば、なおよい。
今 (2014/6)、PaaS で最もスムーズに利用できる Lisp 族といえば Clojure というところに、この本の価値がある。

Gaelyk で日程調整アプリ Any Day 作りました

Any Day とは

候補日を設定しといて、参加者に URL を教えとけば、各自の希望日を集められるというものです。

なぜ作ったのか

奥さんに相談されて、そういうサービスをあれこれ探してみたんですが、どのサービスもいまいちマッチしなくて使えませんでした。
なので、もうちょっとだけ自由がきくものを作ろうと。

なにでできているのか

おもに Gaelyk + jQuery + Bootstrap でできてます。

ちっさい

• *.groovy
  251 行 5788 文字
• *.gtpl
  516 行 21042 文字

という、非常に小さな規模です。
行数や文字数を少なくしようという努力は、とくにしてないにもかかわらずです。
アプリ自体ごくシンプルなことしかしてないですが、それにしてもこれほど小さくまとまってるのは、Gaelyk のおかげです。

スピーディ

ここまでに使った時間は、たぶん延べ一週間あるかないかだと思います。
Gaelyk を採用したのは初めてなので、次からは最初の少しの学習コストもなくなり、さらにスピーディになると思います。

ちょっとしたワナ

i18n プラグインがちゃんと使えてたら、もうちょっと早くあがったかも。
ローカルでは普通に動くのに、App Engine 上で動かすと、文字化けちゃってダメでした。
試行錯誤のすえ、けっきょく多言語対応自体を先送りにしました。
どうやったらうまく動くのか、誰か教えて欲しいです。
あと、言われてみれば「なるほど、そりゃそうだ」なんですが、Gaelyk で jQuery 使おうとして一瞬驚いたのが、”$”の扱いです。
Gaelyk の GTPL (スクリプトレットを含む、JSP っぽい出力テンプレート) は、ざっくり言うとファイル全体を GString として扱います。
“$” 文字は jQuery (あるいは類似の JavaScript ライブラリ) を使用すると頻出するキーワードですが、これは同時に GString 中に式を埋め込むために使われる文字でもあります。
Groovy の経験のある方はピンときたかもしれませんが、埋め込み式をあらわすもの以外の “$” は、すべて “\” でエスケープする必要があります。
幸い、このことは検索すればすぐにひっかかってくるこの議論を見れば、すぐに理解できます。
おかげで、それほど時間をとられずすみました。
それ以外は、すごくスムーズに作れました。
以前 Grails で家庭内イントラアプリを作ったことがあって、そのときもさくさくだと思ったもんですが、Gaelyk はさらにすごいです。
サイト規模とかプラットホームとか、ターゲットが違うので単純に比較することはできませんが。
Gaelyk 、楽しいです。