portal shit!

仕事するときはWindowsでもLinuxでもVimを使っているので、最近ではVimが手足のようになっています。エレベーターに乗るときも j k を押そうとしてしまうほどです。しかしMacでコードを書くときはTextMateも使ってしまいます。TextMate Bundleが提供するスニペットや ⌘ + R でスクリプトを走らせる機能とかやはり便利ですね。

しかしVimが手足のようになってる皆さんならお分かりいただけるかと思いますが、Vimmerは口より先に j k を連打してカーソルを動かそうとしますし、Ctrl + u や Ctrl + d による高速スクロール、Visualモードによる選択・一括編集、 # や * を利用した検索なしのテキストエディティングなんて苦痛でしかないわけなんですね。

TextMateでVimのキーバインディングが使えないかなー、あるいはVimの中でTextMate Bundleが使えないかなー的なことを夢想していたら、それを実現しているテキストエディタがあったわけですよ。Vicoってやつでした。春頃チェックしてたんだけど、先日、「TextMate vim keybinding」みたいキーワードで検索していて改めてその存在を知ったので試用版をダウンロードして使ってみた次第です。まんまTextMate + Vimという感じ。

TextMateとの相違点としては、

• Vimキーバインディング（Vimが使えない人には多分使いにくい）
• デフォルトで日本語に対応!!!
• デフォルトでサイドドロワーがついてる
• ウィンドウ分割あり!!!

良くできてる点

• TextMate Bundleが利用できる
• GUIエディタとCLIエディタの長所をうまい具合に統合している。
• TextMate同様、カスタムシェル変数を設定できる。
• 従って ⌘ + R でスクリプトを走らせるときに TM_RUBY という具合にシェル変数を設定しておくことで、RVMのRubyを実行時のインタープリタとして利用できる。

気になる点

• テキストをインサートモード時にバックスペースで削除すると、削除するつもりのない文字を一文字余計に削除する
• .vimrc を見て機能を拡張された状態のVimを使えるわけではなさそう
• upコマンド（テキストが変更されていれば保存する機能）が使えない
• なんとなく動作が不安定

このように気になる点がないわけでもないので、Vicoで書いていたこのテキストを途中でVimに切り替えて書いてしまっちゃった。Vimは .vimrc にごちゃごちゃ書いたりプラグインをインストールして始めて快適に使えるようになるので、キーバインディングだけviライクでもVimそのものの機能を提供してくれるわけではないVicoは、生粋のVimmerからするとちょっと使いにくいところがありますね。

それでも「j k 連打したい！」というVimmerの切実な欲求は満たしてくれますので、TextMate Bubdleは手放したくないというVimmerの皆様にはおかれましては導入をご検討いただければと思います。Mac App Storeで3540円ですが、以下から試用版がダウンロードできます。

www.vicoapp.com

ポータルシットをLokkaで置き換えました。

Lokkaでリプレースしようと決めたのが2月8日なので（たぶんLokka - portal shit!）、5ヶ月弱要したことになります。

今回こだわったのが、

1. P_BLOGから記事本文はもちろん、コメントも移行する
2. 移行スクリプトはテスト駆動で開発する
3. Markdownで本文を書けるようにする
4. 旧記事へのアクセスをリダイレクトする (未実装)

の4点。

TDDデビュー

移行スクリプトについては初めてテストファーストで開発してみましたが、なかなか勉強になりました。やたら長いメソッドを書かないように気を付けたり。長いメソッドはテストしにくいですね。あと途中でLokkaの仕様不足が露呈してコードを書き直したりしたんですが、そういうときもきちんとテストを書いているおかげで、一ヶ所変更したらプログラム全体がぶっ壊れるというような事態を避けることができ、大変良かったです。

herokuデビュー

最初はさくらVPSで運用しようかと思っていましたが、herokuで簡単に使えるのがLokkaの売りなわけですし、heroku使ったことがないのは若干まずいだろと思っていたのでとりあえずherokuで運用することにしました。楽でいいです。失業者が出るレベル。

ただ旧記事（/article.php?id=***）へのアクセスをリダイレクトするつもりで移行スクリプト書いたりしてたんですが、herokuで運用する限りにおいては nginx.conf を編集したりできないのでリダイレクトは実現できなそう。Sinatraで拡張子phpへのアクセスをリダイレクトするという変態的な処理はできないのでしょうか。クエリストリングの扱いがネックになりそう。場合によっちゃ結局さくらVPSで運用するかもです。

加えてherokuは画像のアップロードができないので、画像のアップロード先は別に用意する必要があります。プラグイン使ってAWSをストレージとして利用するとか。JAWS九州の勉強会に二回ほど参加して、Amazonのエバンジェリスト玉川さんの話とか聞いてAWS使わないと来年の今頃は失業してそうな空気を感じ取ったのでそのAWSにも手を出してみたいですね。

まとめ

Lokka、プラグインが簡単に作れるので本体のロジックにほとんど変更を加えることなくいろいろできて楽しいです。Sinatraベースなので困ったことがあったらSinatraのドキュメントを見ると大体なんとかなりそうな感じがします。リストカット感覚でブログ作ったり消してる人におすすめです。

Google Chromeの拡張機能に、Chrome Keyconfig ってのがあります。これはMinibuffer + LDRizeとまではいかないまでも似たような機能を提供してくれるエクステンションで便利に使っていたんですけど、最近、一旦Google Chromeを終了すると前回使用時に変更した拡張機能設定項目の内容が読み込まれないという不具合が発生するようになり、非常に不便でした。

Chrome KeyconfigとTberarelooの組み合わせで、Firefox + Greasemonkey + Minibuffer + LDRize + Reblog Command とほぼ同様の快適さでTumblrが閲覧できるようになるわけでして（Google ChromeでFirefoxのようなReblogしまくれる環境を構築する - Syoichi's Tumblr）、毎回Tumblr閲覧時にChrome Keyconfigの設定画面を開いて設定を変更するのは面倒くさいこと極まりありませんでした。

ちょっと調べてみたところ、以下のような原因でChrome Keyconfigの設定項目の変更内容が反映されないようです。すなわち、Chrome Keyconfigの設定項目の内容を保存しているDBの "ItemTable" というテーブルに "Config" という key を持つレコードと "Keyconfig" という key を持つレコードがあって、設定項目の変更内容は "Keyconfig" に保存されるけどChrome KeyconfigはGoogle Chromeを一旦終了して再起動すると "Config" の方を読みに行っちゃう、ということらしいです。

Chrome Keyconfig の設定が戻らないようにする

Google Chrome のエクステンション、Chrome Keyconfig の設定が、再起動すると消えてしまう事への対策です。 拡張機能の設定ファイルを直接編集することで、解決できました。 * 設定が消えてしまう時の環境 * Windows 7 Home Premium SP1 32bit * Google Chrome 11.0.696.60 unknown * Chrome Keyconfig 1.11.0 1. 拡張機能の ID を調べる chrome://extensions/ にて、"デベロッパーモード" に切り替えると、拡張機能の ID を見ることができます。 この場合、okneonigbfnolfkmfgjmaeniipdjkgkl になります。 ここで、Chrome を終了します。 2. 設定ファイルを編集する C:\Users\

blog.kteru.net

したがってChrome Keyconfigの設定内容を保存しているSQLite3のDBを直接開いて編集してやればよいわけですね。"Config" という key を持つレコードの value を "Keyconfig" の値で上書きしてやればよい。上記リンク先ではWindows環境で、SQLiteを編集するソフトを使って値を変更する方法が紹介されていますが、Macでは以下のコマンドで行けます。

cd ~/Library/Application Support/Google/Chrome/Default/Local Storage  
sqlite3 chrome-extension_okneonigbfnolfkmfgjmaeniipdjkgkl_0.localstorage "update ItemTable set value = (select value from ItemTable where key = 'Config') where key = 'Keyconfig';"
{: .console }

よろしければお試し下さい。

二月末に行ったスマートフォン開発環境セミナー(仮)でmasuidriveさんのTitanium Mobileについての発表を見てすっかり感化された。これからはJavaScriptで空を飛べる時代が来ると思った。

ドイツの会社がやってるToDo管理のサービスにWunderlistってのがあって、これは結構かっちょいUIのiPhone/Mac/PC/Webアプリを出してたりする。なんでそんなにマルチプラットフォーム対応できんの？ と思ってたらどうもTitanium MobileとTitanium Desktopを使ってるみたい。だから簡単にマルチプラットフォーム対応できてるわけ。他にもThe Hit Listが一向にiPhoneアプリを出さないのでそれに業を煮やしたSenchaの社員が作ったHub ListっていうアプリもJavaScriptでデスクトップアプリを書いててマルチプラットフォーム対応してる。

しかし、なんかTitanium Desktop使って僕みたいなスキルしょぼい人がアプリ作るときじゃくせい（なぜか変換できない）を突かれて困ったことになる懸念もあるみたい。

はてなブログ

d.hatena.ne.jp

とはいえ、最近プログラム書き始めたばっかでObjective-CとかJavaとか分かんない自分には、JavaScriptでiPhone/Androidはもちろんのこと、MacやWindows、はてはLinux向けのデスクトップアプリケーションが作れてしまうのTitanium MobileとTitanium Desktopにはとてつもない魅力を感じる。

連休期間中にしょぼいのでいいからなんか一個作りたい。

Alfred

Quicksilverのかわりに入れた。インターフェイスはお洒落。

PowerPack（£12）を購入すればディレクトリの閲覧やアクションの選択など、Quicksilver的な機能が使えるようにはなるけど、やはりQuicksilverに比べたら機能は少ない。特にQuicksilverのTriggersに相当する機能（ホットキー）がないのが移行してすぐは不便だった（iTunesの操作はすべてQuicksilverのTriggers経由で行っていたので）。

Alfredは日本語が通る

日本語が通るのは便利だ。例えばAddress Bookの人名検索をするとき。いちいちAddress Bookを開かず、Alfredの入力画面を呼び出して人名を入れるだけで検索できる。こんな感じ。

ただ、日本語が通るためTerminal.appなど、日本語環境で起動したときアプリケーション名がカタカナになってるソフトの起動時に日本語で呼び出さなきゃいけないのが地味に面倒くさい。Quicksilverでは「terminal」と入れれば良いものを、Alfredでは「ta-minaru」と入力した後、スペースキーでカタカナに変換し、さらにリターンキーで確定しないといけない。Terminal一つ起動するのになんでここまで苦労しなければならないのかと泣けてくる。

なんかネガティブな感想が多くなってしまったけど、事実上Quicksilverは開発止まってるし、Mac OS Xのアップデートである日いきなり使えなくなることも考えられるので、Quicksilverに依存しきりの人はランチャーの「次の選択肢」を考えておいた方がいいかも。

Divvy

最初はBreezeというソフトの方をmacZOTで知ってこういうウィンドウサイズ管理ソフトの導入を検討してた。Breeze買おうかなと思ってたんだけど、たまたまDivvyの存在を知ってこっちを使ってみたら、HUDっぽいUIで画面サイズを簡単に変更できるところが素晴らしくて、BreezeやめてDivvyを買った。

RubyKaigiで近くに座ってる人のMacBookの使い方を見てたらやたらSpacesでたくさん画面を作って切り替えながら作業してる人が多かった。

Spacesはメモリの量が少ないMacでやると重いので自分は使ってない。そもそもSpacesで複数の画面を切り替えて使っても、例えばブラウザーを見ながらテキストエディターに何かを入力するみたいな作業が必要なときには頻繁にスペースを切り替えなければならず、大変うざい。

一発でアプリケーションウィンドウサイズを変更して左にブラウザー、右にエディターみたいな使い方が出来たら便利だ。DivvyやBreezeならこういうことが出来る。Breezeの場合はウィンドウサイズと位置をあらかじめ登録しておかなければいけないけど、DivvyはHUDポップアップウィンドウを呼び出して、ドラッグで好きなようにウィンドウサイズ・位置を変更できる。こんな感じ。

13インチのMacBook Proは1280×800という解像度のため、データを参照しながらのテキスト入力などでは生産性がいまいちだけど、Divvyなどを使うことでセカンドディスプレイがなくてもデータを参照しながら効率的に入力作業を行うことが出来る。大変素晴らしい。

職場が変わって仕事ではWindows漬けだけど、Windowsにはこの辺の作業を快適にしてくれるソフトが少なくて、改めてMac良いと思う。Terminal内での操作感は基本的にUNIXやLinuxと同じだし。Macで仕事できてる人たちが本当にうらやましい。

最近車の調子が悪く、お金は全然持ってないけど「新しいPOLOいいよなー」とか思ってYouTubeでPOLOの動画見てたらこんなの発見した。

1950年代のアメリカにPOLOがタイムスリップしたら、というストーリー。勝手に翻訳してみます。

不良連中行きつけの喫茶店の前に赤色のニューPOLOが駐まってる。

男A: 「ダセェ」

男B: 「レッド！」

店内に入るとカウンターに現代からタイムスリップしてきたとおぼしきなよっとした男が座ってる。

男A: 「おいお前、外に駐まってる赤いブツは何だ？」

ナヨ男: 「あたらしいPOLOだよ。」

男A: 「POLOォ？」

ナヨ男: 「かっこいいだろ？」

男A: 「かっこいいィ？」

不良一同爆笑

男A: 「思い知らせてやる必要がありそうだな」（ここの訳適当）

で、結末はご覧の通りです。

ちなみにPOLOはアメリカでは売ってないので、このCMはヨーロッパとかオセアニア向けということになりますね。1950年代のアメリカ人がアホっぽく描かれてて興味深いです。

FreeBSDでVimを起動しファイルを編集したあと、 :q でVimを終了させてるのに元のコンソールに戻らなくてなんか嫌だなーと思っていた。MacもUbuntuもDreamHostのDebianもVimを閉じると元に戻るのに、職場の本番環境のFreeBSDだけこれなの。ファイル編集前のコンソールの履歴とかを見たいこともあるので、Vimが終了したら元の画面に戻るようにしたいと随分長いこと思っていたんだけど、たったいまようやく出来たのでメモっときます。

ちなみにVimには restorescreen とかいうオプションがあるらしく、必死で.vimrcにこの設定を書いてたけど、これはなんかWindowsのVim専用のオプションらしいのでマカーやUNIXユーザーの方はこれを設定しても無駄です。

情報元は フルスクリーンアプリを終了したときに元のコンソールの状態に復元する - 技術メモ帳 というページ。

FreeBSDの場合、 /etc/termcap ってのの中にフルスクリーンアプリを終了したときにコンソールに戻るかどうかを設定する場所があって、こいつを変更すればよいらしい。

しかし自分はこのサーバーでroot権限を持ってない。なので cp /etc/termcap ~/.termcap したあと chmod 644 ~/.termcap して vim ~/.termcap し、自分の使ってるターミナルの環境に合わせて設定を変更してやるとOK。

僕の場合はMacの純正ターミナルを、シェルはzshで使っている。 echo $TERM してみると xterm-color と表示されるのでxterm-colorの設定が書いてあるところをいじった。

くわしくは上のリンク先を見てもらうといいんだけど、とにかく te ってのと ti ってのがあって、これをMacの場合は te=E7E[?47h 、 ti=E[2JE[?47lE としてあげればいい。そんでシェルの設定ファイルに export $TERMPATH=$HOME/.termcap と書いてやり、一端ログアウトして再ログインするとめでたくVimを終了したときにコンソールが復元されるようになります。