portal shit!

寿司はうまい。寿司はうまいので寿司と結婚したいと思う人もいることでしょう。しかし寿司は人間ではないので結婚できない。結果的に寿司屋の娘と結婚することになります。

寿司好きなあなたは、寿司であれば何でも食べたいと思う。だから回転寿司だって、午後8時のスーパーの総菜売り場で半額になっている寿司だって好きなはずです。しかし、寿司屋の娘と結婚したばかりにそういった Guilty Pleasure は御法度となります。

「ああいうの食べるなんて頭どうかしてる」

寿司屋の娘はあなたにそう言います。寿司のことが好きすぎて、でも寿司とは結婚できないから寿司屋の娘と結婚したのに、安い寿司が食べられなくなったことでかえってあなたの生涯寿司数は低下するのです。寿司との距離、これがこの文章のテーマです。

24歳のときに病気になってしまった僕は、入院して治療を始める前、生ものが食べられなくなるからと寿司屋で寿司を食べました。治療の合間に一時帰宅が許されると回転寿司に行って吐くまで寿司を食べたりしました。寿司を食べ過ぎて吐くことで自分の生存を確認していたのかも知れません。

病気を克服した僕は、普通の寿司好きと同じように就職して社会生活を営むようになりました。週に二日休みがあれば、そのうち一日は祖母を連れて回転寿司に行くのは独身男性として当然のことだと思います。寿司を空気のようにすら感じていました。

寿司にもっと近づきたい -- 20代の僕はその欲求を抑えることができませんでした。実家を出て、寿司屋の娘と結婚することにしたのです。しかしこのときの僕は、好きなときに自由自在に寿司が食べられることのありがたみを分かっていませんでした。

寿司屋の娘との結婚が僕にもたらしたのは、寿司との離別でした。寿司と僕はもう二度と交わることもない別々の人生を歩むことになったのです。寿司屋の娘と結婚するとはそういうことなのです。僕は寿司に近づきすぎたのです。

僕は今日、福岡の高寅という寿司屋で以下の寿司を頼みましたが、大トロは寿司屋の娘であるところの妻に食べられました。

代わりに僕は以下の赤身を食べさせられました。

おわかり頂けたでしょうか。寿司屋の娘と結婚するとはこういうことなのです。

あなたが本当に寿司のことを愛しているのならば、寿司には近づきすぎない方が良い。寿司とは適切な距離を保つべきなのです。

この記事は 寿司 Advent Calendar 2013 - Adventar の 9 日目でした。明日は watilde さんです。

公開している 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 = 0 を draft = 'f' に変えてあげればすべての記事を表示できるようになった。

最近 Emacs を触っていることもあってテキストエディター熱が高まっているので思いつきで社内で Vim 勉強会を開催した。

自分は最初はプラグインをいかに使いこなすかというところから Vim を使い始めて（Vim テクニックバイブル的 Vim の活用）、Emacs に手を出したことによる素の Vim の少ないキーストロークでの編集能力の高さ再発見（実践Vim的 Vim の活用）し、Vim の真骨頂は後者にあるのではないかとむさ苦しく語った。

準備不足で資料とか作れなかったのであまり意味わからない感じだったかも知れないけど、話をするために実践Vimを読んだり積ん読になっていたオライリーの Learning the vi and Vim Editors を読んだりして勉強のきっかけを作ることができて良かった。

自分の他に同僚の @monochromegane 氏が Unite.vim の上級活用法 （agとUnite.vimで快適高速grep環境を手に入れる - Thinking-megane）や、氏が EUC-JP/Shift-JIS 対応を進めている ag による Unite grep の高速化などについて話した。カーソル位置の単語で Unite grep する方法^*1なんかが個人的には参考になった。Unite の設定とかはネットで拾った情報のコピペで済ませていたので、実際に目の前で解説してもらいながら使い方の設定をすることで新たな発見をすることができ、大変良かったと思う。

4月に勉強会がつらくなって Fukuoka.rb もやってなかったんだけど、またぼちぼち再開していきたいと思った。

*1 以下のようなコードだけどなぜか自分の環境だと期待した通りに動いてくれなくて、Pattern: というプロンプトが出て検索キーワードが確認できるはずなんだけど、何かキーを入力しないキーワードが表示されなくて不便な感じ。

" grep current word
nnoremap <silent> ,cg :<C-u>Unite grep:. -buffer-name=search-buffer<CR><C-r><C-w>

会社の若者、夏期休暇期間中に徳を高めまくってた。

夏期休暇のまとめ - kitak blog

こんにちは、実家のハウスダストで鼻と喉がやられたきたけーです。 こんなかんじで始まったぼくの夏休み。 昼寝してたら夢にあんちぽさんが現れて「夏季休暇こそ自分を高めようと思わないの？」的なことをおっしゃってた— きたけー（USキーボード買った） (@kitak) 2013, 8月 10 ちょっと早いですけど、夏期休暇中に読んだ本とかやってたことのまとめ。 読みたかった本を読んだり、楽しそうなことリストをいくつか消化して楽しめたかんじ。次の楽しそうなことに繋がったので良かった。 読んだ本 ビジョナリー・カンパニー2 - 飛躍の法則 ビジョナリー・カンパニー 2 - 飛躍の法則作者: ジム・コリンズ…

kitak.hatenablog.jp

自分は徳が高まるようなことは特に何もしてない。コード書いてないしプログラミングの勉強もしてない。すこし .vimrc を触ったくらい。

実家に帰ったほかは、家を買おうとしてるので不動産屋に行ったり住宅メーカーに行ったりしてた。

プログラミングの本、『明解! Ruby』が読みかけになってるので読もうと思ったけど読まなかった。『SQL アンチパターン』も必要に迫られて買ったので夏期休暇で読もうと思ってたけど読めてない。

代わりと言ってはなんだけど歴史の本読み始めた。連休前に以下を買った。

大河ドラマとか見るときに日本史の知識ないと厳しいことがあるので Wikipedia 読むんだけど Wikipedia 読みだすと際限ない感じなるので本を買って歴史を勉強してみようと思っていた。丁度日経プラスワンの特集で紹介されてたので読んでみたくなって手に取った。Amazon でも評価高い。

あと夫婦げんかして家を飛び出して向かった天神のTSUTAYAで以下のような本を買った。

どれも古本なので安かった。『「芸能と差別」の深層』は三国連太郎の話が面白そうだったので買った。『夜這いの民俗学・夜這いの性愛論』を買うとき、レジが女の人じゃないなと良いなと思ったけど女の人になってしまって恥ずかしかった。結果的に痔ろうが再発した。

2月に車を買った。スバルインプレッサの中古。車、維持費高いけどやっぱりあると便利だと思う。生活圏広がるし、これまで行けなかった糸島（福岡の湘南みたいなところ）の農産物直売所に行ってうどんを食べたりすることもできる。

子どもが生まれるとやはり車がない生活が原理的に不可能な気がしてくるようになった。子ども服を売っている店はそもそも車でしか行けないような場所にあることが多い。意外と都会の真ん中で子ども服を扱ってる店はない。ユニクロも赤ちゃん服は売ってない。百貨店に行けば何でもあるので都会の真ん中にも子ども服あると言えばあるんだけど、当然のことながら異常に高い。百貨店には庶民が買えるようなやつは売ってない。子ども用品を激安価格で売っているチェーン店に西松屋というのがあるけど、例外なく郊外で営業してる。安く子ども用品を揃えようとしたらどうしても車で西松屋に行くしかない。

そもそも子ども用品はかさばることが多く（おむつ、ミルクなど）、電車＋徒歩で行けるような場所に店があったとしても買った品物を持ち帰るのが非常に難しい。以前、電車とタクシーで西松屋に子ども用品を買いにいったことがあるけど、子ども用の風呂桶などが大きすぎて手で持ち帰ることができず、同じ市内なのに宅急便で家まで配達してもらって送料が2000円くらいかかった。そのほかにも駅からタクシーでショッピングセンターをはしごしたりで、一回の買い出しで交通費・送料だけで5000円くらいかかったことあった。

また公共交通機関での移動は公共交通機関に都合を合わせないといけないのが辛かった。地下鉄のホームから地上への上り下りや高速バスの乗り降りは結構きつい。時間も電車やバスに合わせないといけない。子どもがうんこしたからといって高速バスで移動している最中におむつを替えるわけにもいかない。車ならこういう問題があらかた解決される。

以上のような理由で車を買った。

車はカーセンサーとかで調べて実物を見に行ってから決めた。中古車屋は非ディーラー系とディーラー系の両方に行った。非ディーラー系は飲み物を出してくれたりゆったりとしたソファがあったりして店の作りは贅沢だと思ったけど、車の値段が詐欺っぽかった。車検付き80万円という価格につられて行ったのに乗りだし価格は+40万必要で120万円からになりますとかそんな感じだった。これはアホらしいと思ったのでここでは買わなかった。

ディーラー系の中古車屋はしょぼかった。店はプレハブで車を見に行っても飲み物とか出てこなかった。しかし詐欺っぽいところはなくて、何も言ってないのにカーセンサーに載っけてる値段より安い値段出してきたし、窓にバイザーつけてくださいとか ETC 付けて下さいとか色々言ったら無料でやってくれた。スバル保証みたいのも付いたし、怪しい中古車屋よりネットに出てる値段は高いけど最終的にはディーラーの中古車屋で買うのが良い気がした。

新車とかは一生乗れないと思うので死ぬまでディーラーがやってる中古車屋で車を買って乗り継いでいこうと思います。

一月くらい前から 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_at と updated_at は datetime 型になるらしい。なので以下のような 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/ 以下にアホみたいにファイルが出来ていくの嫌だと思っていたけど、スキーマ変更に気がつかずコードをデプロイしてウェブアプリケーション停止みたいな自体は防げると思った。

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

Mountain Lion な Mac （MacBook Pro Mid 2009）で MacVim （kaoriya版） から quickrun を実行すると以下のようなエラーが出て困ってる。

⚡ Traceback (most recent call last):
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.py", line 62, in <module>
    import os
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/os.py", line 398, in <module>
    import UserDict
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/UserDict.py", line 83, in <module>
    import _abcoll
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/_abcoll.py", line 11, in <module>
    from abc import ABCMeta, abstractmethod
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/abc.py", line 8, in <module>
    from _weakrefset import WeakSet
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/_weakrefset.py", line 5, in <module>
    from _weakref import ref
ImportError: No module named _weakref

CUI の Vim で quickrun してもエラーは出ないし、会社で使ってる Mac （Mountain Lion MacBook Pro Early 2011） の MacVim （同じくkaoriya 版）で quickrun やってもエラーは出ない。

どうやらこの辺が関係ありそう。リンク先には ujihisa さんバージョンの quickrun ではなく thinca さんバージョンのやつを使えばエラーは出なくなる、とあるけど、自分が使っている quickrun は thinca さんバージョンのやつで、どうすればいいかさっぱりわからない。

MacVim が想定する Python とパスが通ってる Python のバージョンが違うのが問題なような気がする（調べてみたら、Python は 2.5 と2.6 と 2.7 がインストールされていた。なんでこんなに入ってるの…。パスが通ってるのは 2.7 らしい）ので、とりあえず MacVim を kaoriya 版から Homebrew のやつに変えてみることにする（brew install macvim）。brew でインストールするとコンパイルを行うので、パスが通ってる Python を利用するようになるはず。

と思ってやってみたら案の定、エラーはでなくなった。