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 、楽しいです。

やっぱりオムニフォーカスすごいね

以前、わざわざメールで iCal のリマインダに登録できるスクリプトを作って、OmniFocus はやめたっていうハナシをしました。

Omni Focus

で、今はどうしてるかっていうと、結局 OmniFocus に戻りました。
なぜ戻っちゃったのかというと、タスクの見せ方の違いというか、考え方の違いかな。
OmniFocus の場合、これから先のタスクをずらっとリストするんじゃなくて、今やるべきことに集中させてくれるんですね。
OmniFocus では、アラートは普通2回来ます。
タスクの開始が可能になったときと、タスクの期限のときです。
この、タスクの開始可能のアラートが結構効果的で、これがくるまではそのタスクのことを完全に忘れてていいんです。

これ、とても重要なことです。
タスク管理で大事なのは、タスクをすべて把握しておくことではなくて、必要になるまで忘れておけるようにすることです。
把握するのはツールに任せておいて、自分は今のことに集中すること。

これは GTD (Getting Things Done) という TODO 管理手法からくる考え方です。
GTD についての情報は、 GTD のサイトとか Wikipedia を見てみるなり、ググってみればたくさんあります。

OmniFocus は、今もっとも GTD に忠実なツールです。
そのため、他の TODO 管理ツールとはちょっと方向性が違う、独特な雰囲気を持っています。
場合によっては、この独自性のために最初とっつきにくさを感じる方もあるようです。
でも、ちょっと使い慣れてくると、この「忘れておける」ということがまるで空気のように、普段は気にもしないけど、実はとても自然で大事なことになってきます。

実際、僕も iCal リマインダーではそれが十分でなくて、なんだか窒息したような気分になってOmniFocus に戻ってきました。

やっぱり大事なものは、失ってみないとなかなかわからないものです。
そんな自然さが、OmniFocus のすばらしさですね。

それからもうひとつ、「忘れておける」ということをより完全なものにするためには、タスクの実行が可能になったときには、確実に教えてもらえるということが大事です。
教えてもらえることが確実だからこそ、安心して忘れておけるようになるんです。

OmniFocus 2 for iPhone



OmniFocus for iPad

で、そのために便利なのが、OmniFocus 2 for iPhone と、OmniFocus for iPad です。
これらはすべて、Omni の同期サーバ経由で同期できます。
同期サーバの利用は無料です。
iOS デバイスのユーザにとっては、iOS デバイスの通知センターが、たぶん一番確実なアラートじゃないでしょうか。

やはり、タスク管理には OmniFocus が一番です。

ところで、つい先日 VoodooPad で GTD というハナシを書いたばかりなんですが、これとの関係はどうなんでしょうか？
はい、今は OmniFocus と VoodooPad の 2 つで TODO 管理してます。
なぜ 2 つ必要なのかとか、これらの住み分けのことについては、また今度、気が向いたら書くかもしれません。

VoodooPad で GTD 2回目

VoodooPad で GTD っぽいことをやってみるハナシの2回目です。

前回は、voodoopad-gtd の導入と簡単な使い方について書きました。
で、ちょっと古いプラグインなので、導入するためにちょっとだけスクリプトを修正しました。

今回は、またちょこっとスクリプトを変更します。

やりたいことは2つ。

1. Markdown のリストに対応
   ページのデフォルトフォーマットが Markdown になっている場合、プラグインが生成する @todo ページ、 @done ページ、および @later ページの内容を、Markdown のリストにする
2. ショートカットキーを変更する

1. Markdown のリストに対応

voodoopad-gtd は、@todo: タグや @done: タグ 、@later: タグをつけた箇所の内容をリストにしたページを生成してくれますが、その内容は単なる改行区切りのプレーンテキストです。

Markdown を使用しているなら、リスト形式にするだけでちょっと見やすくなります。

以下の 3 ファイル全て、同じ箇所を変更します。

• Update @todo List.py
• Update @done List.py
• Update @later List.py

変更内容は、こんなかんじ。

  def main(windowController, *args, **kwargs):
-     theList = ""
+     theList = [""]
      document = windowController.document()

    if line.find(tag_name) >= 0:
-     theList += page.displayName() + line.partition(tag_name)[2] + "\n"
+     theList.append(page.displayName() + line.partition(tag_name)[2])
- theList += "\n\n--\nUpdated at " + time.strftime("%d %b %Y %H:%M",time.localtime())
  page = document.createNewPageWithName_(tag_name)
- page.setDataAsString_(theList)
+ separator = "\n* " if page.uti().find("markdown") >= 0 else "\n"
+ page.setDataAsString_(separator.join(theList) + "\n\n--\nUpdated at "
+   + time.strftime("%d %b %Y %H:%M",time.localtime()))
  document.openPageWithTitle_(tag_name)

* スペースの都合で、タブ幅は圧縮してます。

手抜きしてるので先頭に空行が入っちゃいますが、むしろ見やすくていいので、放置です。

2. ショートカットキーを変更する

デフォルトでは "@todo:" 、"@done:" 、および "@later:" タグの挿入は、それぞれ "Control + t" 、"Control + d" 、"Control + l" に割り当てられています。
ところが、Emacs キーバインドを使い慣れてる人にとって、これらはどれも非常に都合が悪いです。
まるで狙ったかのように、多用するキーストロークばかり潰されています。
そこで、ショートカットキーを変更したいと思います。
"@todo:" タグの挿入は、デフォルトでは"@todo"リストページの生成に割り当てられるショートカット "Control + Shift + t" に割り当て、リストページ生成は "Control + Command + Shift + t" に割り当てます。
"@done" タグ、"@later" タグについても同様です。

変更するファイルはそれぞれ2つです。

• TODO
  • Insert @todo.py
  • Update @todo List.py
• DONE
  • Insert @done.py
  • Update @done List.py
• LATER
  • Insert @later.py
  • Update @later List.py

変更箇所は、

  VPShortcutMask = "control"
- VPShortcutKey = "t"
+ VPShortcutKey = "T"
  
  import AppKit

と

  VPShortcutKey = "T"
- VPShortcutMask = "control"
+ VPShortcutMask = "control command"
  
  import AppKit

です。
DONE 、LATER についても、変更内容は同様です。

見れば察しがつくと思いますが、"VPShortcutKey" がショートカットキーの指定で、"VPShortcutMask" がモディファイアキーの指定です。
"VPShortcutMask" に指定できる値は

• "control" 、または "ctrl"
• "command"
• "option" 、 "opt" 、または "alt"
• "shift"

で、スペースで区切ります。
Shift キーについては、"VPShortcutMask" で指定してもいいですが、上記の変更内容のように、"VPShortcutKey" に大文字を指定することであらわすこともできます。
自分で使いやすいショートカットを割り当ててください。

ほんのちょっとした変更ですが、ぐっと使いやすくなると思います。

VoodooPad で GTD

ひさしぶりの投稿ですが、オブジェクト指向ともプログラミングとも直接関係ないです。
Mac のパーソナル wiki アプリ VoodooPad 5 で、 GTD っぽいことをやってみようというハナシ。

今までは Emacs org-mode + MobileOrg + Dropbox で TODO 管理してました。
でも、最近なぜか MobileOrg の Dropbox ログインで

Bad username and password or network error.

なんて言われて(もちろん、Email/Password は何度も確認しました)、 sync できなくなってしまいました。
sync なしでも、org-mode 自体は僕の TODO 管理に最適なんですが、 iPhone で見られないのはちょっと痛いです。
いや、まぁテキストなんだから、見ようと思えばもちろん見られるんですが、フォールディングなしの長大な org ファイルで TODO 見る気にはならないです。

なので、これを機に別のやり方も試してみようということで、以前からメモとしてたまに使ってた VoodooPad を、 GTD にも使ってみたいなと。

VoodooPad

VoodooPad なら、 VoodooPad for iOS で iPhone/iPad でも気軽に編集できます。
Markdown も使えるし。

さいわい、VoodooPad に GTD 的な機能を追加するプラグインを作ってくれてる親切なヒトがいました。
ここからダウンロードして入れれば OK 。

どこに入れるかは、ダウンロード元のページにも書いてあるし、同梱の README.markdown にも書いてあるんですが、この情報は古いです。
VoodooPad 5 では、 "~/Library/Containers/com.flyingmeat.VoodooPad5/Data/Library/Application Support/VoodooPad/Script PlugIns" です。

あと、スクリプト自体も古い(バージョン3.5用)ので、ちょっとだけ修正してやる必要があります。

• Update @done List.py
• Update @later List.py
• Update @todo List.py

の 33 行目の

if page.uti() == "com.fm.page":

を、

if page.isText():

に書き換えれば OK 。

使い方は、ダウンロード元のページと、同梱の README.markdown に書いてあります。

一応、簡単に書いておくと

• 何かメモる (すきなやり方で)。
  Take notes (in a somehow chaotic way).
• メモの中にやるべきこと (タスクとか) を見つけたら、それの前に "@todo:" (Ctrl + T で入れることもできる) か、 "@later:" (Ctrl + L) と書く。
  Whenever you find something to be done (i.e: a task) you just add "@todo:" (Control + T) or "@later:" (Control + L) in front of it.
• タスクリストが見たかったら、 Ctrl + Shift + T を押せば、 "@todo" というページ (なければ生成されます) に、今開いてるドキュメント内の "@todo:" タグが全てリストアップされる。 (それぞれ元のページへのリンク付き)
  When you need a task list, hit Control + Shift + T and all "@todo:" tags in the current document are listed on a "@todo" page (with a link to the page where the task is)
• タスクを完了させたら、 "@todo:" タグを "@done:" に書き換える。同梱の"Insert Date"スクリプト (Ctrl + Shift + J) を使って完了日を記録することもできる。
  When you complete a task, replace the "@todo:" tag with a "@done:" tag. I use the "Insert Date" script (bound to Control + Shift J) to record the date.
• 最近完了したタスクをチェックしたいなら、 Ctrl + Shift + D を押せば、 "@done" というページが作られて、 "@done:" のタスクがリストアップされる。
  When you need to check what you've acomplished recently, hit Control + Shift + D, and a "@done" page is created with a list of "@done:" tasks.
• 時間が空いた？それなら Ctrl + Shift + L を押せば、全ての "@later:" タスクがリストアップされた "@later" ページができる。
  Spare time? Hit Control + Shift + L and you'll get a "@later" page with all your "@later" tasks.

ということらしいです。

さて、これからこいつを使ってみます。

気が向いたら、使ってみた感想とか、また書くかもしれません。

正中頸嚢胞の手術と入院

以前、正中頸嚢胞ができたという記事を書きました。

今回は、そこで予告してた、手術と入院生活について報告したいと思います。

• ヒゲソリ準備
• 自分にとってはあっという間。でも家族にとっては...
• 痛いのは夜から
• 回復に向かいはじめればあっという間
• 入浴はできませんでした
• 退院後
• かかった医療費

XBox 360、延命成功!?

ウチのXBox 360が壊れたわけなんですが、ニューマシンが来るのは4/5でまだ半月も先だし、退院祝いにThe Elder Scrolls V : Skyrim買ってきちゃったし、去年から予約済みのマスエフェクト 3だってもう届くし。
せっかく自宅療養中なのにおあずけなのは、やっぱ痛すぎ。

てことで、巷で噂の「温めて冷まして直す」をやってみました。
「タオル療法」とか「タオル法」なんていう名前でも呼ばれてるやり方です。

1. HDDなどの増設ハードウェアをすべて外し、ディスクが入っていないことを確認した上で、本体をバスタオルや毛布などで包み、電源を入れて20〜30分ほど放置します。
2. 包んでいたバスタオルや毛布を取り除き、電源を切って20〜30分ほど放置。

以上。とても簡単です。

あとは、再度電源を入れてみて、正常に起動するかどうか確認するだけ。

Xbox 360の本体異常の原因のほとんどは、基板上のハンダのクラックや剥がれが原因なので、過熱状態にして一旦ハンダを溶かすことで、くっつけ直すという作戦です。

結果は...なんと、ほんとに直りました！

驚きました。すごいことを思いつく人がいるもんですね。
もちろん、これはちゃんとした修理ではなくて、単なる延命措置なので、例の素敵なXbox 360 スター・ウォーズ リミテッド エディション の予約は取り消しません。
でも、それが来るまでのおあずけ期間が少しでも縮むのは、とても嬉しいです。

今回、僕が参考にしたのは、

とか
ゲーム翻訳者のブログ　～ゲームトランスレーター～ Xbox 360 Towel Trick 【Xbox 360 タオル法】
とかのあたりでした。

まぁ、直ったといっても、次はもう起動しないかもしれない。

いつまたRRoD (Red Ring of Death)状態に戻ってしまうかわからない。

下手したら、最初から直るどころか止めをさしてしまうかもしれないという、危うい民間療法です。

もう無償修理期間は終わってるし、修理不能になっても構わないという状況でなかったら、おすすめしません。

ハードウェア素人の僕でも、少なくとも2つのリスクが考えられます。

• 過熱状態にするということは、CPUやGPUに過酷な試練を与えることになります。
  それで瀕死のXbox 360くんに止めをさしてしまいかねません。
• こんな温度管理なっしんぐなハンダ付けしたら、問題が起こった箇所以外も含めて、全てのハンダが劣化します。
  劣化したハンダは、ほんのちょっとした衝撃でも、クラックや剥がれを起こしてしまいます。
  なので、一旦直ったとしても、再発する可能性はかなり大きいでしょう。

というカンジで、とてもオススメはできないやり方なんですが、ダメモトでいいならやってみる価値はありますね。

2012-3-17 追記: やっぱりダメでした

一時は成功かと思われましたが、結局ダメでした。

• ディスクを入れていない状態でないと、起動しない
• ゲームをHDDに取り込もうとすると、途中でハング
• ゲームをディスクから起動すると、開始後数分でハング
• すでにHDDに取り込み済みのゲームを起動すると、ディスクからの起動時より多少長くもつものの、やはり数分でハング

ということで、ダッシュボードまで起動するようにはなったものの、結局ゲームをプレイできる状態ではありませんでした。
がっつりヌカ喜びさせていただきました。
残念です。

XBox 360が壊れました

正中頸嚢胞の手術を終え、無事退院して来ました。
で、今週いっぱいは自宅で療養することになりました。

さぁ、ゲームでもしながらのんびりしようかなぁと思ってたら、なんとなんと Xbox 360 が壊れてるじゃありませんか。

入院前にDragon Age II (ドラゴンエイジII)をやってたので、さっそく続きをしようと思ったら、スタート直後にハング。
で、再起動したら、今度はダッシュボード表示直後にハング。
再び再起動したら、今度はダッシュボードさえ表示されず、電源ボタン周りの4つのリングライトののうち、右下一つが赤く点灯した状態で、システムエラーE71の表示。
これはハードウェア障害のサインなので、ウチのXbox 360についてる唯一のオプション機器であるHDDを外した状態で、電源ケーブルを挿しなおして再起動してみたら、ついに右上以外の3つのリングライトが点灯した状態、つまりいわゆるRRoD(Red Ring of Death)に至ってしまいました。

仕方ないので、買い替えようと思ってさがしてみたら、イイのあるじゃないですかー。
Xbox 360 320GB Kinect スター・ウォーズ リミテッド エディション。
R2-D2デザインの本体に、C-3POカラーのコントローラ！
おまけに 付き。
ただし、発売は4/5なので、それまで Xbox 360 が使えないのが悲しい。


ところで、正中頸嚢胞で入院してた時の経過については、今まとめてます。
じきに掲載しますよ。

言語はどれも同じじゃない

僕も以前は、言語には得意不得意、向き不向きはあっても優劣はないという立場をとっていました。
でも、はっきり言います。それは間違いでした。ごめんなさい。

例えば、徒歩と自動車で移動する場合それぞれを比べた場合、

• ある程度以上距離がある場合の速度では、自動車のほうが徒歩に勝る
• 旋回性能では、徒歩のほうが自動車に勝る
• あまり距離があると、徒歩では現実的な時間内に到着できない可能性がある
• 数メートル以内の極短距離では、わざわざ自動車に乗るよりも徒歩のほうが速い
• たとえ自動車がエコカーであったとしても、エコ性能で徒歩に勝ることは決してない

のように、いろいろな側面で得手不得手があります。
でも、このような向き不向きのほとんどは、境界条件的な状況でのみ発生するものです。
どちらかを選択する必要があり、また一旦選択したあとで変更するには多少なりともコストがかかるという場合、このような向き不向きが選択に影響する状況はあまり多くありません。

ありていにいえば、「徒歩と自動車のどっちで移動したいですか？」ときかれたら、普通どっちと答えるかってことです。

正中頸嚢胞ができました

何かってーと、首の正面にピンポン球くらいの大きさの腫れものができる病気？です。
正面だから、正中なんだそうです。

わざわざこれをブログに書いたのは、今後同じ正中頸嚢胞になった人に、情報を残しておくためです。
僕自身、今回集めた情報の中で、最も的を射ていて役立ったのが、体験者のブログだったからです。

コンテンツ

• 症状と概要
• 今までの経緯
• 治療のおおまかな流れ
• 費用

データベースホストを微妙にクラウド化するSQLクライアント

データベース名だけ指定すると、複数のデータベースホストの中を探し回って、勝手に接続してくれるSQLクライアントです。
ダウンロード

使い方はカンタン。

groovy Query.groovy -n {データベース名}

これだけで、指定したデータベースに接続しますので、あとはお好みのSQLを実行するだけ。

ssh接続を簡単にするGroovyオブジェクト

ssh接続の面倒なところをカプセル化する、Groovyクラスです。

リモートコンピュータに接続してコマンドを実行するスクリプトを、簡潔に書くことができます。

ダウンロード

※ ちなみに、ファイルのエンコードはUTF-8になってます。
使用する際には、実行環境のデフォルトエンコードで保存し直してください。

使い方はカンタン。

接続先ホスト名やユーザ名、パスワードをセットして、withConnectionのパラメータのクロージャ内で、お好みのコマンドを実行するだけです。

こんなかんじ。

new SshSession(
    host:'RemoteHost', user:'aUser', password:'password', log:writer, hostEncode:'utf-8'
).withConnection{
    execute('ls')
    println message
}

メールからiCalリマインダ登録するAppleScript

信メールの内容を、iCalのリマインダに登録するAppleScriptです。
ダウンロード

使い方はカンタン。
メーラの振り分けルールでお好きな条件を指定して、アクションにこのスクリプトを指定するだけで、準備OK。

grails run-appでGoogle App Engineを起動してみる

前回、永続化APIとしてJPA(Java Persistence API)を選択しました。

で、さっそくgrails run-appです。
app-engineプラグインをインストールすると、フツウにコマンドラインで

grails run-app

を実行しただけで、grailsがのっかった状態で、Google App Engine(以下、GAE)の開発サーバが起動するようになります。
らくちんですね。

ということで、さくっとやってみました。

永続化APIの選択

Google App Engine(以下、GAE)上にアプリケーションを構築する場合、かなりシンプルなものでない限り、なんらかのフレームワークを使うことになると思います。

僕の場合、Grailsを選択することになりました。
すでにGrailsで構築し、稼動し始めていたアプリケーションを、GAEにのせることにしたからです。

Grailsは優れたフレームワークです。
しかし、それでもGAEとまったく関係なく作ったシステムを、後からGAEに適合させるためには、それなりの変更が必要でした。

原因は

• GAEのAPI仕様
• RDBとGAEのデータストアの違い
• Grails、またはそのプラグインの仕様
• それらが合わさったもの

など、さまざまでした。

そこで、GAEアプリケーション開発の一例として、今回必要になった主な変更を、このカテゴリにまとめていきたいと思います。

ユースケース記述が気になりますか？

このブログのアクセスログを見ると、どうもユースケース記述のアクセス数が常に上位にあるようです。

ユースケース記述(図じゃなくて)に関心がある方が多いのでしょうか。
あなたは、どうですか？

ユースケース記述について、より理解を深めていただくために、ちょっと違う視点で説明してみたいと思います。
前回は、一般的なユースケース記述の書き方について、サンプルケースを使って、チュートリアルっぽく説明しました。
そこで、今回は重要なポイントに的を絞ってお話しします。

コンテンツ

1. ユースケース記述の目的
2. ユースケース記述の必須事項
3. でも、結局は

Factory (ファクトリ) パターン

Factory パターンって、Abstract Factory パターンのことを言ってるの？それとも Factory Method パターンのこと？
と疑問に思う方もいらっしゃると思いますが、ここでは両者をまとめて解説します。

誤解をおそれずに言うなら、両者にはたいした違いはありません。
この「たいした」の部分のについては、説明を読んでいただければわかるかと思います。

コンテンツ

• Factory ってなに？
• それをやるとなにが嬉しいのか？
• インタフェースで依存度を下げてみる
• 問題はコンストラクタ
• ファクトリを使って依存をなくす
• ファクトリの可能性
• Abstract Factory と Factory Method の違い
  • Abstract Factory パターンとは
  • Factory Method パターンとは
• Factory パターンの応用

Factory ってなに？

直訳すれば工場ですよね。
まぁ、実際に工場なんですけど、何の工場か？
もちろん、オブジェクト指向のハナシをしてるんですから、決まってますよね。オブジェクトです。

オブジェクトのインスタンスを、生成する工場なわけです。
a クラスのインスタンスを生成するための a ファクトリとか、x クラスのインスタンスを生成する x ファクトリとかなわけです。

それをやるとなにが嬉しいのか？

ファクトリを使用することで、オブジェクトのインスタンスを作る箇所での、依存度を下げることができるのです。

具体的に見てみましょう。
以下では、Java 風の擬似コードを使って説明していきます。

class A {
    // なにかの処理
}

class B {
    method(){
        A a = new A();
    }
}

この擬似コードでは、クラス B はクラス A に依存しています。
"A" というクラスを、そのまま変数の型に使用しているのと、A クラスのコンストラクタに直接アクセスしているからです。
なので、もし同じインタフェースを実装している別のクラスや、A クラスのサブクラスを作っても、クラス B の "method" メソッドを変更しないと、それに対応することはできません。

インタフェースで依存度を下げてみる

とりあえず、依存度を下げるための一歩として、インタフェースを用意しましょう。

interface C {
    // いくつかのメソッド
}
class A implements C {
    // インタフェースCの実装
}

クラスBは、以下のようになるでしょう。

class B {
    method(){
        C c = new A();
    }
}

しかし、これだけでは、依存度はたいして下がっていません。

問題なのは、 "new A();" の部分です。
根本的な問題は、コンストラクタへのアクセスにあるのです。

問題はコンストラクタ

コンストラクタの呼び出しを、コードのいろんなところに散りばめることは、コード全体に接着剤をぶちまけるようなものです。
アプリケーション全体が強力な依存性で接着されて、岩盤のように固く、変更困難になってしまいます。

"new A();" というコードがクラス B に書いてある限り、インタフェース C は依存度を下げる役には立ちません。
コンストラクタの呼び出しを、排除する必要があります。

でも、どこかしらでクラスを明示してコンストラクタを使用しなければ、オブジェクトを生成することはできませんね。
リフレクションでも使えば別ですが、それはそれで、多用するのは問題があります。

ファクトリを使って依存をなくす

コンストラクタの呼び出しが避けられないのなら、いっそ一箇所にまとめて隔離しましょう。
それがファクトリってわけです。
ファクトリを使うと、たとえばクラス B はこうなります。

class B {
    method(){
        C c = CFactory.newInstance();
    }
}

クラス A は、インタフェース C を実装しているとします。 CFactory は、newInstance() メソッド内で、クラス A のインスタンスを生成して返します。
クラス B からはクラス A のコンストラクタ呼び出しは排除され、CFactory の newInstance メソッド内に隠蔽されました。
これで、クラス B はインタフェース C を実装しているものならなんでも、変更なしに扱うことができます。

このクラスには、もはやクラスA の存在を匂わせるものは一切ありません。
実際、これが擬似コードでなく実装コードだったとしたら、この時点でクラス A のインポートステートメントも削除することができ、A というクラス名はもはやクラス B のソースから一切姿を消してしまうはずです。
このように、ファクトリを使用すれば単に依存度を下げることができるだけでなく、依存をまったくのゼロにすることができます。

ファクトリの可能性

上記のコードで出てきた CFactory は、単にコンストラクタを隠蔽しているだけでなく、実は大きな可能性を秘めています。
newInstance メソッドは、実際にクラス A を返すこともできますし、クラス A のサブクラスを返すこともできます。
あるいは、インタフェース C をインプリメントしているものの、クラス A とはまったく関係がないクラスを返すこともできます。
どのクラスを返すかは、クラス B とは関係のない、別のところで決めることができるのです。
クラス B を作ったときには想定していなかったクラスを、あとから追加して newInstance メソッドで返すようにすることができます。
これぞまさに自由!
実装上の自由というのは、依存性がゼロになったときにだけ生まれるものです。
インスタンス生成に自由をもたらすことが、ファクトリの目的です。

Abstract Factory と Factory Method の違い

この 2 つは、いずれも言わずと知れたデザインパターンの代表格です。
ですが、これらの違いのわかりにくさが、なんとなくファクトリ全体をとっつきにくいものにしているような気がします。

名前が似ているだけでなく、同じ目的を達成するためのテクニックセットの、それぞれ交換可能な 2 つの部品というような関係です。
なので、その境界がどこにあるのかについて、混乱しやすいのではないでしょうか。
でも、わかってしまえば結構簡単なものです。

Abstract Factory パターンとは

ここまでで書いてきた擬似コードの全体像を見てみると、こんなかんじですね。

interface C{}

class A implement C {}

class CFactory {
    C newInstance(){
        return new A():
    }
}

class B {
    method(){
        C = CFactory.newInstance();
    }
}

クラス B は、クラス CFactory にクラス A のインスタンスの生成を委譲しています。
実は、これは Abstract Factory パターンそのものです。
ファクトリのクライアントとなるオブジェクトが、ファクトリオブジェクトにインスタンスの生成を委譲するという関係が、Abstract Factory パターンです。

Factory Method パターンとは

ファクトリは、オブジェクト生成に自由をもたらすとは、すでに言いました。

では、実際に生成されるオブジェクトが切り替わるように変更してみましょう。

interface C{}

class A implement C {}
class Z implement C {}

abstract class CFactory{
    abstract C newInstance();
}

class AFactory extends CFactory{
    C newInstance(){
        return new A():
    }
}

class ZFactory extends CFactory{
    C newInstance(){
        return new Z():
    }
}

class B {
    method(){
        C = CFactory.newInstance();
    }
}

新しく生成したいクラスは、4 行目で追加した Z です。
A クラスと同じくインタフェース C を実装しているので、クラス B はまったく変更することなく、このクラスを扱うことができます。
生成するインスタンスを切り替えるためには、if 文などの条件分岐を使用することもできますが、条件分岐が増えることはコードの複雑性の増大に直結してしまいます。
なので、ここではサブクラスによって切り替えることにします。
そのために、クラス CFactory を抽象クラスにして、サブクラス AFactory と ZFactory を作りました。

AFactory はクラス A のインスタンスを生成し、ZFactory はクラス Z のインスタンスを生成します。

今回は CFactory クラスにはじめて階層構造をもたせたので、変更範囲が広いですが、次回からは CFactory クラスのサブクラスを作るだけで対応できるようになったことが、おわかりいただけるでしょうか。
このように、親クラスであるファクトリが、実際のオブジェクトの生成をサブクラスに委譲するのが、Factory Method パターンです。
これは、Template Method パターンの一つの例でもあります。

これによって、CFactory からもクラス A への依存が取り除かれました。
クラス A に依存するのは AFactory だけ、クラス Z に依存するのは ZFactory だけ、というように各インスタンスに対応するファクトリサブクラスの中に、依存性が閉じ込められたわけです。

さて、ここで再び問います。
これはなにが嬉しいんでしょうか？
たしかに依存関係は最小限に圧縮されたわけですが、シンプルに

class B {
    method(){
        if (/* なにかの条件 */) C = new A();
        else C = new Z();
    }
}

と書けばわずか 2 行で済むのに比べると、ものすごい量です。

でも、ちょっと待って下さい。
これは単なる擬似コードなので、できるかぎり見やすいように、シンプルに書いたものです。
たしかに、このような極シンプルなケースであれば、ファクトリよりただの条件分岐のほうがベターな場合があります。
しかし、実際のアプリケーションのコードでは、こうはならない場合がほとんどでしょう。

Factory パターンの応用

例えば、プログラミング向けテキストエディタの、シンタックスハイライティングを実装するとします。
キーワードやリテラル、コードブロック、コメントなどシンタックスの種類はたくさんありますが、どれもプログラミング言語ごとに内容は違います。
このたくさんのシンタックスを、それぞれオブジェクトであらわすとしたらどうでしょうか。(実際にそれが最適解かどうかは別としてです)

プログラミング言語というのは、移り変わりが激しいものです。
日々生まれては消えていくし、昨日は誰も知らなかった言語が今日はメジャーになっているかもしれません。
もし、条件分岐でいちいちオブジェクトを切り替えていたとしたら、アプリケーション全体に渡って同じような条件分岐が散りばめられることになります。
条件分岐を採用してしまったら、新しいプログラミング言語に対応するのは、非常にコストがかかる仕事になります。

こういう場合、全てのシンタックスオブジェクトの生成を一手に引き受けるファクトリを用意するというのも、効果的な手段です。
対応するプログラミング言語 1 つに対して、ファクトリのサブクラスを 1 つ (または 1 セット) 作ります。
こうすることで、ファイルタイプやユーザの選択によってファクトリが切り替わると、ハイライティングルールが一挙に切り替わるようにできます。
新しい言語に対応する場合に必要な作業は、新しいファクトリを 1 つ作ることと、新しいファイルタイプにそれを関連付けること、そして選択オプションを追加することだけです。
それ以外の既存のオブジェクトについては、全く心配する必要がありません。

他にも、例えばユーザのロールによって、表示の内容やアクセスできる機能のセットを切り替えるようないわゆる権限の実装や、ルック & フィールの切り替えなどでも、ファクトリを利用することができます。

また、OS やミドルウェア、フレームワークの種類によってアイソレーションレイヤ全体を切り替えるようなファクトリを用意することで、ポータビリティの大幅な向上を実現するというような、大規模な仕組みにも応用することができます。

2013.02.13

Abstract Factory パターンと Factory Method パターンの違いの説明をわかりやすくするために、大幅に改訂しました。
また、ファクトリの応用についても触れてみました。