| @雑談

and the spring goes on...

いつかは別れがやってくることはわかっていたけど、ばあちゃんが死んだ。年明けに具合が悪くなって「一週間ばかり」のつもりで入院したら、末期の肝硬変であることがわかり、入院して3週間で亡くなった。91歳になったばかりだった。

自分にとってばあちゃんは特別な存在だった。親が共働きだったので保育園の迎えにはばあちゃんが来てくれていたし、夏休み冬休み春休みはばあちゃんと過ごす時間が長かった。中学生くらいまでばあちゃんの部屋に布団を敷いて寝てた。

大学を出て病気になり、治療のために実家に帰ってきてからは、ばあちゃんととにかくよく出かけた。竹田の岡城跡の桜、知覧の特攻記念館、久住の紅葉などなど、後期高齢者をいろんなところに連れて回った。ばあちゃんは親と友達の中間のような存在だった。 Flickr にはばあちゃんの写真がいっぱい上がっている。

入院後は休みの度に看病をしに帰省した。写真を見せてやろうと、これまでに自分が撮ったばあちゃんやひ孫たちの写真を大量にプリントして病室に持っていった。家にあった昔のアルバムも病院に持っていって見せた。

ばあちゃんの具合がよくて話ができるときには、ばあちゃんが子どもの頃の話や昔の話を聞いて iPhone に録音した。ばあちゃんの実家は旧士族でそこそこ金持ちだったため、ばあちゃんが赤ん坊の頃の写真があったりした。亡くなる二日前に子ども時代の写真を押し入れから引っ張り出して病室に持っていって見せたらとても喜んだ。

入院中、ばあちゃんは早く死にたいと言っていた。「ばあちゃんはいつ死ぬとじゃろか」と俺に聞くこともあった。みんなに迷惑がかからないように早く死にたいからご飯は食べたくない、とも言っていた。本人には病状は知らされてなかったので、最後まで自分の病気が何なのかは分かっていなかった。しかし助かる見込みはないということは分かっていたと思う(亡くなる前まで意思疎通はできていて、痴呆ではなかったから頭はハッキリしていた)。

平日会社に行っているときにはばあちゃんのことが気がかりで仕事が手につかなかった。自分はいったい何のために実家を出たのだろう。実家を出ずに家にいて地元で働いてればもっとばあちゃんの面倒を見られたし、最初に体調が悪くなったときに病院に連れて行ってもっと長生きさせてあげられたかもしれない。自分がいま置かれている現状を悔やむことが多かった。

火曜日の夜、11時頃ベッドに横になってうとうとしていたら母から電話がかかってきて、亡くなったことを知らされた。結局、死に目に会うことはできなかった。

若い頃は、何を勉強したいとか、どういう仕事に就きたいとか、どんな暮らしをしたいかとか、そういうのばっかりでどこの学校に行くか、どこで働くか、どこに住むかを考えてしまう。ずっと地元に残るということが考えられなかった。しかし実家の近くに住んで、家族が病気のときにはすぐ駆けつけられるのが一番こころ穏やかでいられるのではないかと思うようになった。どんな仕事をするか、どれだけの収入を得るか、どんな暮らしをするか、そういうことも人生の中で大切なことではあると思う。ただそのために自分の両親や祖父母の面倒を見ることが出来ないのは何か違うんじゃないかと考えるようになった。

ばあちゃんが入院している間、阿蘇山がとても勢いよく噴煙を上げていた。まるでばあちゃんの具合が悪くなるのに呼応するかのように黒々とした煙を上げ、阿蘇谷に火山灰を降らせた。葬儀の日は特にひどく、雪と見まごうばかりの灰の塊を降らせていた。

ばあちゃんの死を通じて、自分のルーツを深く考えるようになった。時を同じくして阿蘇の火文字焼きの中止と終了が発表された。子どもの頃、ばあちゃんと一緒に見た阿蘇の火文字焼きがなくなってしまう。ばあちゃんと一緒に阿蘇の習慣が失われたような気がして言い様のない寂しさを覚えた。

自分はばあちゃんが91年間住んでいた阿蘇を飛び出してどれだけの価値を生み出せたのだろう。ばあちゃんの死に目に会えなかったことに見合うだけの人生を歩んでいるのだろうか。

| @Mac/iPhone

面白かったので便乗して書きます。

iPod 、大学3年の頃に友達が買って見せびらかしてまわってたのが最初の出会いだった。当時は自分は Windows 使ってて Apple 周辺の事情に疎く、特に iPod を欲しいとも思わなかった。

初めて iPod を買ったのは就職活動に失敗して留年していた頃だ。家の近所をぶらついていて、確か発売されたばかりで結構品薄だったのを偶然発見し、就職活動が終わって始めた居酒屋のバイトでもらった初めての給料で買った。第四世代 iPod のモノクロのやつで、ディスクの容量は 20GB だった。

iPod を買った年の冬に精巣腫瘍になって翌年の正月に病院に行ってがんだと分かり入院・手術した。病院はおそろしく退屈で病人生活を始めた最初の頃はパソコンとか持ち込んだりしてなくて、 iPod で音楽を聴くか新聞を読むくらいしか楽しみがなかった。抗がん剤の治療をするようになってからは、点滴されながらじっと iPod で音楽聞いてた。音楽聞いて抗がん剤の吐き気とかを紛らわせようとしてた。

第四世代 iPod は Apple タイマーが正常に機能して、購入からぴったり一年後に壊れてしまった。 HDD が死んだぽかったので開腹してハードディスク入れ替えたら良さそうだったけど当時はハードディスクもそこそこ高く、海外に旅行に行く直前に(飛行機に10時間以上乗るのに無音はつらかったので)第五世代の iPod を買った。こちらは 30GB のディスク容量で、カラー液晶になっていて写真を閲覧したりもできた。

第五世代 iPod は京都で半年入院してるときに重宝した。この頃は抗がん剤の副作用で耳鳴り・高音難聴に苦しんでいたのでよく音楽を聞いた。あと当時付き合っていた女性にふられたのでコールドプレイの "Warning Sign" をエンドレスリピートしながら京都の寺社仏閣を一人でふらふらと歩いて回ったりした。退院して北海道まで青春18きっぷで行ったときもひたすら第五世代 iPod で音楽を聞いていた。

第五世代 iPod は液晶から壊れはじめた。縦方向に筋が入るようになり、最終的には筋が広がって筋の隙間からのぞき見るようにして画面を見る必要があった。iPhone 3G を買ってからは歩くときは iPhone で音楽聞くようになったので、 iPod はもっぱら車の中で音楽聞くとき専用端末になった。最後はオートバックスの駐車場でドアポケットの掃除かなんかしてるときになくしてしまったっぽくて行方不明になった。

実は最初にインターネットに接続したパソコンは弟が音楽製作用に買っていた初代 iMac のタンジェリンのやつで、パソコンの原体験は Apple にあった。大学ではレポート提出とかの都合上 Windows を使っていたけど、数年ぶりに Apple 製品に触れて再び Apple 熱が高まり、 AirMac Express を買って Air Tunes で音楽聞くようになった。

iPod が画期的だったのは、 iTunes のライブラリと iPod を同期して使うところだった。それまでの MD や既存の mp3 プレーヤーは、プレーヤーに入れたい曲を選択してプレーヤーに移す、という作業が必要だった。昔の iPod の CM に、家の Mac で聞いていた音楽の続きを出かけるときに iPod で聞く、というやつがあったけど、そういう発想は他のプレーヤーにはなかったと思う。最初は馴染めなかったけど、曲のレートや再生回数が iPod と iTunes で同期される便利さに慣れると、 iPod 大勝利だなと思うようになった。2ちゃんねるで SONY のプレーヤーの悪口を吹聴して回るほどだった。

しばらく Apple 製品使ってないうちに OS X が出ていることを知り、 OS X の GUI の美しさにびっくりした。当時の Windows XP のフォントはアンチエイリアスがきいておらずシャギーだった。 OS X といい、 iPod - iTunes といい、 Mac/Apple の方が Windows/Microsft よりもだいぶ進んでいるなと感じた。 Windows に無理矢理 Osaka フォント入れたりして Mac 化したりしてた。次パソコン買うなら絶対 Mac だなと思うようになっていた。

大学卒業して入院しているときには病院があまりにも暇でノートパソコンが欲しくなったので、 DELL の安いノートとかにしたらと母親に言われたものの、どうしても Mac がいいとだだをこねて PowerBook G4 の 17 インチのやつを買ってもらった。これを使って病院でブログ書いたりしてた。ブログいじりが楽しくて PHP とか少し触るようになり( Mac は簡単にウェブサーバーを立てることができるので病院とかでも PHP のコードいじったりするのに向いてた)、結果的に Web の仕事がしたいと思うようになって今日に至っているような気がするので、 iPod 買ってなかったら Mac を欲しいとも思わなくてプログラミングをやり始めることもなく、何の能力を身につけることもないまま今も親のすねをかじってニートをしていたかもしれない。

| @技術/プログラミング

公開している Lokka の DB (MySQL) のデータを、手もとの Lokka の DB (SQLite) に取り込むときに毎回やり方を忘れるので書いておきます。

今回は MySQL to Sqlite converter という gist のコメント欄に書いてある以下の方法を試した。

sudo gem install sequel
sudo gem install sqlite3
sudo gem install mysql
rbenv rehash
sequel mysql://user:password@host/database -C sqlite://db.sqlite

これでデータを MySQL から SQLite に変換できた。Lokka をローカルで起動してアクセスしてみるが記事が表示されない。DB の中にはちゃんとデータが入ってるし、管理画面から記事一覧を表示するとちゃんと記事が表示される。どうも Post.published[] を返すみたい。

手でクエリを投げてみると

sqlite> select * from entries order by created_at desc limit 1;
             id = 960
        user_id = 1
    category_id = 5
           slug = eye-pro-is-shit
          title = Eye-Fi Pro を買ったけどクソだった
           body = [hitode909さんの日記](http://hitode909.hatenablog.com/entry/2013/05/24/093749 "hitode909の日記")...
           type = Post
          draft = 0
     created_at = 2013-10-06 07:28:00.000000
     updated_at = 2013-10-06 13:11:23.000000
frozen_tag_list =
         markup = redcarpet

draft = 0 なので表示されそうなもんなんだけど、よくよく調べてみると SQLite には Boolean 型がなくて、DataMapper は SQLite に Boolean 型のデータを保存するときは t/f の文字列で保存するみたい。これは盲点だった。

結局 draft = 0draft = 'f' に変えてあげればすべての記事を表示できるようになった。

| @散財

hitode909さんの日記を読んでたら Eye-Fi を買ったと書いてあって、hitode909 さんのツイッターに iPhone のカメラではなく GR とかで撮影したと思われるやたら高画質なラーメンの写真が投稿されるようになってた。自分も同じようなことやってみたいと思って Eye-Fi を買った。

iPhone 3G が出た当初から、というか iPod がカラーになったばかりの頃から、一眼レフで撮った写真をその場ですぐ iPhone とか iPod に取り込んで人に見せたいという欲求があった。しかしそれを実現するためには訳の分からないアダプターを買って常に持ち歩いたりする必要があってそんなガラクタを持ち歩くのは耐えられなかったので導入しなかった。

Eye-Fi 自体には以前から興味があったけど、普通の SD カードと比べると高すぎたので微妙だと思っていた。しかし上記のようなカメラの写真を iPhone に取り込む機能に加え、Eye-Fi Pro を買うと GPS ユニットなどがなくてもジオタグを写真に付加できると知り、高いなぁとは思いつつも古い SD カードが不調だったこともあり、えいやっと購入してみた。しかし期待したような効能は得られなかった。というか買うならジオタグ付与できないバージョンの Eye-Fi Mobile で充分だった。

Eye-Fi Pro と Eye-Fi Mobile の機能の違いだけど、概ね以下のような感じらしい。

機能 Eye-Fi Pro Eye-Fi Mobile
カメラからスマートフォンに転送
ジオタグ付与 ×
RAW 対応 ×
Wi-Fi でパソコンへ転送 ×

Pro の方が高機能で良さそうに見えるんだけど、ジオタグ付与も RAW 対応もパソコンへの転送もかなり微妙だった。というのもカメラからスマートフォンへ転送する機能(「ダイレクトモード」と言うらしい)を利用すると、ジオタグが写真に付与されない仕様らしい(撮影してもジオタグがつきません。 | Pro X2よくある質問 | サポート << Eye-Fi Japan)。ジオタグを付けられるのは、周囲に Wi-Fi の無線がいっぱい飛んでる場所で撮った写真を、Wi-Fi でパソコンへ転送する場合のみとのこと。自分としてはカメラからスマートフォンに転送してくれる機能が一番欲しくて Eye-Fi を買ったので、それを犠牲にしてジオタグを付与する意味はない。

ダイレクトモードを使うか Wi-Fi 転送するかは、Eye-Fi の設定用のソフトを Mac にインストールして設定を行い、Eye-Fi カードに覚えさせる必要がある。つまり出先ではダイレクトモードでカメラからスマートフォンに転送し、Wi-Fi のある自宅では Wi-Fi を経由してパソコンにデータを転送させるというような使い方ができない。となると Wi-Fi でパソコンへ転送する機能も使えるようで使えないということになる。

使ってみて分かったのだけど、ダイレクトモードでは Eye-Fi カードが Wi-Fi ネットワークを作成し、iPhone はそのネットワークに接続して画像のやりとりをする。一方、自宅で Eye-Fi から Mac に Wi-Fi 転送する場合は、Eye-Fi は自分でネットワークを作成するのではなく、自宅の Wi-Fi ネットワークに参加して Mac と画像をやりとりするかたちになる。従ってダイレクトモードと Wi-Fi 転送を両立させることができないようだった。

加えて Eye-Fi の RAW 対応が微妙で、Nikon RAW (.NEF ファイル)はダイレクトモードで iPhone に取り込むと非常にサイズの小さいサムネイルの TIF 画像に変換されてしまい、まともに閲覧することができない。なので結局自分は一眼レフ側で RAW + JPEG を保存するように設定し、 Eye-Fi では JPEG 画像のみ転送するような設定にしている。

この辺の事情は以下のブログに詳しい。

以前だったら何かものを買う際は事前に徹底的にリサーチしてから買っていたのに、iPhone 5 を買ったときの記事に書いたように、おっさん力が高まってきてよく調べもせずデジタル製品をほいほいと買ってしまって後悔することが増えた。こうやって情弱おじさんになっていくのだろうなと危機感を強めている。

まとめると、Eye-Fi Pro はゴミなので買ってはいけない。カメラからスマートフォンへの転送が目的な人は Eye-Fi Mobile で充分。ジオタグ目的の人は Eye-Fi Pro なんかに手を出すよりもちゃんとした GPS ユニット買った方がいい。

一眼レフで撮った写真を iPhone に取り込んで、給料日に焼き鳥屋に来てビールを飲んで感極まってる様子などをツイッターでなうすること自体は楽しいので皆さんもやると良いですよ。

| @雑談

d4990c64f75ca38b6b416a9037adfed5.png (802×562)

Ruby 関連のことを検索していて Shopify の中の人のブログにたどり着いた。なかなか面白いことが書いてあった。

この人は去年の 11 月に iPhone 4 を落として割ってしまったらしい。すぐに iPhone 5 を買おうとしたのだけど、思いとどまって一月ほど iPhone なしで過ごすことにしたそう。自分がどのくらい iPhone に依存してるのか知りたかったのだとか。そしたら意外と良かったらしい。以下超訳。

iPhone があった頃は常に Facebook、Twitter、Email、iMessage、携帯、HipChat、Skype や対面での会話と心が安まらなかった。プッシュ通知を切ったとしても空き時間にメールチェックしたり Twitter や Facebook を見てしまう。常にオンライン状態で、どこにいてもどこにもいないような感じがつらかった。iPhone がなくなったらコンピューターの前にいるとき以外は目の前の友達や同僚のことだけ気にしていればいい。スマートフォンは作業と作業の合間の、さっきまでやっていたことと次にやるべきことについてに省みるべき時間を、ぼーっとゲームをしたり Twitter を見るような用途に費やす手助けをしていることに気がついた。スマートフォンがなくなってからアングリーバードやったり、Facebook を見たりして無為に時間を過ごすことがなくなり、やるべきことに集中できるようになった。

スマートフォンをやめて Nokia レンガ(昔ながらの携帯)で過ごすにあたって、心配してたのが以下の三点だった。

カメラがない

旅行するときはいつも iPhone で写真をとっていたけど、カメラは人に借りれば良いかも知れない。ひょっとするとなくても事足りるのかも知れない。

音楽がない

歩くときは気分を紛らわせるために音楽を聞いていた。しかし本当に音楽を聞きたいときはパソコンの前に座れば良いことに気がついた。音楽なしで歩いてもしんどくないし、周囲の物事に心を巡らせる良い機会になった。

地図がない

iPhone の Map は多用していたけど、方向感覚に自信があったのでどこかに行くときに地図を見るのをやめてみた。そうすると出発前に入念に準備が必要になった。外国に行くときは紙の地図を使った。また本当に迷ったときは人に道を聞けば良いし、尋ね先の人に電話して道を尋ねれば良い。

3ヶ月ほどスマートフォンなしで過ごしてみて、期待していなかった以下のメリットに気がついた。

よく人に電話するようになった

iPhone の頃はメールを多用していてほとんど電話をかけていなかったけど、古い Nokia の携帯だとメールを打つのがつらくてしょっちゅう電話をかけるようになった。同世代の人に電話をかけるとびっくりされる(みんなメールしか使わないから)。携帯の根本機能と会話の楽しさを再発見した。電話した方が話が早く済みそうな場合や深い話の時はメールではなく電話しか使わないようにしている。

携帯の存在を気にしなくなった

鞄の中に適当に携帯を突っ込んで出かけるようになった。ポケットに何も入ってなくて気楽になった。眠る前に携帯がどこにあるか探さなくていいし、安い携帯だからキズが入らないように気を付ける必要もない。心配事が減るのはいいことだ。

上に挙げた懸念事項は正しかったが、それなしでもやっていける

確かに色々不便だがなくてもやっていけることに気がついたし、スマートフォンを持たないことによって得られるメリットがあることもわかった。

“携帯を二週間に一度しか充電しなくて良いのは気が楽” というあたりはなるほどなぁと思った。寝るとき、出かけるときに iPhone を探さなくて良いのも羨ましい。随分楽だと思う。

自分もスマートフォンを使うようになってから Twitter 中毒が重症化し、移動中に本を読むということがまったく出来なくなった。iPad ではなく Kindle がいいと思ったのもネットを見る機能が付いてなくて読書に集中できそうだから。しかし結局手元に iPhone があると Twitter を見てしまう。この人みたいに思い切って落として割ってしまうのが良いのかも知れない。

| @技術/プログラミング

一月くらい前から Lokka の master ブランチを自分のブログ用のブランチに merge してサイトをデプロイすると謎の白画面が出るようになっていて困っていた。現象は極めて謎で、ローカルの開発環境(RACK_ENV='development')では見られず、本番(RACK_ENV='production')だけで発生した。HTTP ステータスコードは 1054 が返ってきたりする。なんか変な gem でも入れてしまったかなと休みの日に動作検証したりしていたんだけどついぞ分からなかった。

SQL 弱者なので気がついてなかったんだけど、2月15日の commit で Site モデルに新しいフィールドが追加されていた(Add default markup in admin/site/edit · 2243dc5 · lokka/lokka ※この機能便利すね)。なので bundle exec rake db:migrate しないといけなかったわけだった。ローカルで動いている開発環境(データベースは SQLite)では Migration なんて行ってないんだけどエラーは出なかった。本番は MySQL で動いていて、こちらでだけエラーが出るようだった。

しかしいざ migrate しようとすると失敗する。

bundle exec rake db:migrate
Upgrading Database...
rake aborted!
Invalid default value for 'updated_at'

のようなエラーが出る。updated_at のデフォルト値がおかしいらしい。このときのテーブルの構造を見てみると以下のような感じだった。

mysql> desc entries;
+-----------------+--------------+------+-----+---------------------+-----------------------------+
| Field           | Type         | Null | Key | Default             | Extra                       |
+-----------------+--------------+------+-----+---------------------+-----------------------------+
| id              | int(11)      | NO   | PRI | NULL                | auto_increment              |
| user_id         | int(11)      | YES  |     | NULL                |                             |
| category_id     | int(11)      | YES  |     | NULL                |                             |
| slug            | varchar(255) | YES  |     | NULL                |                             |
| title           | varchar(255) | YES  |     | NULL                |                             |
| body            | text         | YES  |     | NULL                |                             |
| type            | text         | NO   |     | NULL                |                             |
| draft           | tinyint(1)   | YES  |     | 0                   |                             |
| created_at      | timestamp    | NO   |     | 0000-00-00 00:00:00 |                             |
| updated_at      | timestamp    | NO   |     | CURRENT_TIMESTAMP   | on update CURRENT_TIMESTAMP |
| frozen_tag_list | text         | YES  |     | NULL                |                             |
| markup          | varchar(255) | YES  |     | NULL                |                             |
+-----------------+--------------+------+-----+---------------------+-----------------------------+

調べてみたところ MySQL の Mode が NO_ZERO_DATE になっている場合、MySQL は timestamp 型のフィールドのデフォルト値に 0000-00-00 00:00:00 みたいな値を設定することを許さないらしい。 mysql - Invalid default value for 'create_date' timestamp field - Stack Overflow

検証用に別にテーブルを用意して bundle exec rake db:setup してみたところ、以下のような構造のテーブルができた。

mysql> desc entries;
+-----------------+------------------+------+-----+---------+----------------+
| Field           | Type             | Null | Key | Default | Extra          |
+-----------------+------------------+------+-----+---------+----------------+
| id              | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| user_id         | int(11)          | YES  |     | NULL    |                |
| category_id     | int(11)          | YES  |     | NULL    |                |
| slug            | varchar(255)     | YES  |     | NULL    |                |
| title           | varchar(255)     | YES  |     | NULL    |                |
| body            | text             | YES  |     | NULL    |                |
| markup          | varchar(255)     | YES  |     | NULL    |                |
| type            | varchar(50)      | NO   |     | NULL    |                |
| draft           | tinyint(1)       | YES  |     | 0       |                |
| created_at      | datetime         | YES  |     | NULL    |                |
| updated_at      | datetime         | YES  |     | NULL    |                |
| frozen_tag_list | text             | YES  |     | NULL    |                |
+-----------------+------------------+------+-----+---------+----------------+

created_atupdated_atdatetime 型になるらしい。なので以下のような ALTER 文を実行した。

mysql> alter table entries modify column created_at datetime, modify column updated_at datetime;
mysql> desc entries;
+-----------------+--------------+------+-----+---------+----------------+
| Field           | Type         | Null | Key | Default | Extra          |
+-----------------+--------------+------+-----+---------+----------------+
| id              | int(11)      | NO   | PRI | NULL    | auto_increment |
| user_id         | int(11)      | YES  |     | NULL    |                |
| category_id     | int(11)      | YES  |     | NULL    |                |
| slug            | varchar(255) | YES  |     | NULL    |                |
| title           | varchar(255) | YES  |     | NULL    |                |
| body            | text         | YES  |     | NULL    |                |
| type            | text         | NO   |     | NULL    |                |
| draft           | tinyint(1)   | YES  |     | 0       |                |
| created_at      | datetime     | YES  |     | NULL    |                |
| updated_at      | datetime     | YES  |     | NULL    |                |
| frozen_tag_list | text         | YES  |     | NULL    |                |
| markup          | varchar(255) | YES  |     | NULL    |                |
+-----------------+--------------+------+-----+---------+----------------+

これで最新のコードをデプロイしても真っ白画面になることはなくなった。以前遭遇した更新時に created_at の値が更新されてしまう問題 もフィールドの型が timestamp だったのが原因なのだと思う。SQLite から MySQL への移行は一筋縄では行かないことが分かった。

DataMapper はソースコード内の記述内容から動的に Migration を行えるけど、ActiveRecord みたいに $APP_ROOT/db/ ディレクトリに Migration ファイルを作ってくれたりしないので DB スキーマの変更が必要なことに気がつきにくい。便利だけど不便な感じがする。Rails で $APP_ROOT/db/ 以下にアホみたいにファイルが出来ていくの嫌だと思っていたけど、スキーマ変更に気がつかずコードをデプロイしてウェブアプリケーション停止みたいな自体は防げると思った。

ブログ書こうと思ってパソコン開いて「ついでに最新版の変更を取り込むか」とかやるとデプロイできなくなったりして書きたかった記事が書けず残念な感じになる。はてなブログでブログ書いてて画面が真っ白になったらひとでくんさんに不具合報告して直してもらえば良いので楽だと思う。

| @Mac/iPhone

先日、自宅の MacBook Pro (Mid 2009) 内の MacVim kaoriya で quickrun が実行できないと書いた(Homebrew で入れた MacVim だと quickrun できる)。どうも Python が原因らしいことがわかっていた。

Mac に入っている Python のバージョンが古いのかなと思い(でもそれだとなぜ CUI 版の Vim で quickrun できるの説明がつかない)、 Homebrew で Python を入れてみた。なんか symlink を作成できなかったとかエラーが出たので brew link --overwrite python とかやってかなり無理気味に入れてみた。しかし相変わらず MacVim kaoriya から qiuckrun を実行すると MacVim が落ちる。

そもそも会社の MacBook Pro や自己所有の MacBook Air ではこのような現象は起こらないため、この Mac に入ってる Python が異常なのでは? と思い至った。

確認してないのでテキトーなんだけど、おそらく、この Mac に入ってる Python は 32bit OS 用のやつが入ってたような気がする。というのは /usr/local/bin にあるいくつかの symlink が以下のように 2008 年に作成されたファイルを指していたから。

https://resources.portalshit.net/930-pythons.png

かつて NOKIA の携帯を使っていたときにゴニョゴニョするために Mac OS X 用の Python パッケージをダウンロードしてインストールしていて、それが 32bit OS 用のバイナリだったために問題が発生しているのかも知れないと思った。試しに python.org から 64bit OS 用の Python パッケージをダウンロードしてきてインストールしてみたら無事 MacVim kaoriya で quickrun できるようになった。

CPU が Core Solo、Core Duo の Mac だったら 64bit でしか動作しない Mac OS X (Lion 以降の OS)をインストールできないのでこんな問題には遭遇しないのだろうけど、自宅の MacBook Pro は Core2 Duo なので 32bit OS でも 64bit OS でもインストールできてしまうためにこのような問題に行き当たってしまったのだと思う。

あと OS のアップグレード時にアーカイブインストールではなくクリーンインストールを選んでいたらこのような問題には遭遇しなかったかも知れない。写真や音楽などだけ TimeMachine から復旧するようにして、Mac をアップグレードするときは OS そのものはまっさらな状態でインストールする方が良いということが分かった。アプリケーションもいまは Mac AppStore があるので昔より前の環境に戻すのが難しくない。

ただ Adobe 製品のライセンス認証解除とかは OS のクリーンインストール前にぬかりなく行っておかないとシリアルキーが通らなくなって死ねそう。

そういうわけで、Snow Leopard 時代から Core2 Duo CPU の Mac を Mountain Lion まで Upgrade して使っていて MacVim の quickrun が動かない人は Python をインストールし直すことを試してみてください。