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

一個前の記事で書いた「記事の更新時に updated_at ではなく created_at が更新されてしまう」問題、原因はプログラム側にあるのではなく、MySQL の設定の問題だった。

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   |     | CURRENT_TIMESTAMP   | on update CURRENT_TIMESTAMP |
| updated_at      | timestamp    | NO   |     | 0000-00-00 00:00:00 |                             |
| frozen_tag_list | text         | YES  |     | NULL                |                             |
| markup          | varchar(255) | YES  |     | NULL                |                             |
+-----------------+--------------+------+-----+---------------------+-----------------------------+
12 rows in set (0.00 sec)

updated_atcreated_at の設定値が逆になってたのが原因。ALTER 文でカラムの情報を入れ替えておいた。

MySQL に流し込んだ Sqlite3 のデータを dump したやつの CREATE TABLE entries を見ると以下のようになってた。

CREATE TABLE `entries` (`id` integer PRIMARY KEY AUTO_INCREMENT, `user_id` integer, `category_id` integer, `slug` varchar(255), `title` varchar(255), `body` text, `type` text NOT NULL, `draft` boolean DEFAULT '0', `created_at` timestamp, `updated_at` timestamp, `frozen_tag_list` text, `markup` VARCHAR(255));

なんでこれが created_at に対して更新時に現在時間を上書きし、 updated_at は作成時のみ現在時刻が入るようになるのかは分からない。

それにしても日頃 MongoDB ばかり使っていて、データにおかしなことがあるのはほぼ間違いなくコードのせいだと思う癖がついていることが今回よくわかった。データベースのスキーマを見てみるまでに3日くらい時間がかかった。とほほ。

一方でデータベース内のデータ構造のことをあまり考えなくてよく、開発のみに集中すればよい MongoDB はやっぱり便利だなと思った。規模がでかくなったり高速な読み書きをさばかなければならない状況だと MongoDB にも色々問題があるのでしょうけどね。

| @散財

iPad 買った

会社のタブレット端末購入支援制度を利用して iPad 買いました。この場を借りてお礼申し上げます。ありがとうございます。

iPad には否定的だった

iPad、ずっと年寄りとか情報弱者向けのデバイスだと思って無視してた。小金持ちの情弱サラリーマンとか100万以上カメラにつぎ込んでるカメラじじいが飛びついてる印象しかなかった。とにかく入力がしにくそうで、能動的に情報を取りに行くのではなく、受動的にコンテンツを消費することしかできないような印象があった(文字の入力がしにくいと、情報を検索する頻度が落ちそうだから)。そういうのは新聞や雑誌を読む行為とあまり変わらない。余談だけど新聞社などのオールドメディアが iPad 好きなのと関係ありそう。自分たちが思ったとおりにコンテンツを消費させたいという意志を感じる。

なぜ iPad を買ったのか

技術書を電子書籍で読みたかった

最近、技術書を PDF とか ePub とかで読む行為に興味が出てきて(クソ重い技術書持ち運ぶのに疲れた…)、何冊か PDF 版を買ってみて iPhone で読んでみたら耐えられないくらい読みづらくて何らかのタブレット端末が欲しくなり、 iPad を買ってみたくなった。

デジカメで撮ったばかりの写真を見るのによさそう

あと正月とかにカメラで撮った写真をその場で MacBook に入れて見せると親戚一同が喜ぶので、こういう用途にも向いてるかと思った。Retina ディスプレイだし。

買ってどうだったか

読む端末としては優れている

文章を読む端末としては優れている。Reeder for iPad 入れたら読むのがだるくてたまってたフィードを結構消化できた。(Reeder、Mac 版も iPhone 版も iPad 版も買ってしまった。おすすめです。)

Reeder for iPad

また iPhone では無理だった Twitter に貼られている gist (ソースコードの断片)を見ることが出来て便利だった。iPhone では「後で読む」ものを iPad ではその場で読めるのがいい。

写真きれい

Flickr 見るのが楽しい。写真ブログのフィード、かなり未読がたまってたけど、寝っ転がりながら写真を眺めるのが楽しい。寝床に居ながらにして Flickr にアクセスして友達が撮った写真を眺めて回るのもこれまでにない体験だった。

書きにくい

タッチパネルのフルキーボードだるい。フリック入力したい* フリック入力できるそうです。風呂蓋も買ったので斜めに角度つけられるけど、それでも上からのぞき込むようにして文字を入力するのがだるい。

でも革製の風呂蓋はかっこいいのでおすすめです。

iPad Smart Cover(スマートカバー) (Red Cover(革製))

家庭内での共用が難しい

App Store やフォトストリームなど iCloud 系の機能のせいで Apple ID に紐づけられるし、Twitter や Google のサービスを使う際にもログインが必要なのでやっぱり一人一台の方が使いやすい。家族で共用するのは難しいと思う。

総括

Retina ディスプレイやばい

bfd6d1fb52d6bab76b05d8f6ba6aa777.png (675×343)

タッチパネルで高精細なのが良い。タッチパネルのタブレットはキーボード操作のパソコンよりも目とディスプレイの距離が近くなるので、Retina ディスプレイとの相性が良いのだと思う(図参照)。「読みたい!」「見たい!」という気持ちにさせられる。正直 iPad 使った後に MacBook 開くと文字がぎざぎざに見えて正視に耐えない。Retina ディスプレイやばい。

持って台所に行けるし寝床に持ち込める

コーヒーいれながら iPhone でなんか読むのが好きなんだけど、これノートパソコンでは絶対できない。両手ふさがるから。iPad だったらぎりぎり片手で持てるので、コーヒーいれながらなんか読むということができる。

あと枕元に気軽に持ち込めるのがよい。ノートパソコンは排気口から埃が入り込みやしないかと心配になってあまり寝るとき使う気にはなれないけど、iPad は気兼ねなく寝床に持ち込める。何か読んでて眠りついたときに枕の横にあっても邪魔にならない。

気軽に持ち運べる点がノートパソコンとの決定的な違いだと思います。

これから望むこと

iPad、おおむね気に入ったけどもっとたくさん日本語の本を読めるようになったらうれしい。文庫本とかを自炊なしで iPad で読めるようになったら最高だと思う。岩波文庫の80年くらい前に出版されたやつをリストカット感覚で買って読んだりしたい(カラマーゾフの兄弟も iPad でなら読めるような気がする)。

あと Retina ディスプレイの破壊力やばいので次の MacBook Pro は Retina で出して欲しいです。

追記

調べたところ、iOS 5 からフリック入力できるらしいです。「iPad は情報弱者向けのデバイス」とのたまってる僕こそ情報弱者でした。お詫びして訂正します。

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

Jekyllを使いだしてから気がつくと一年経ってました。いろいろ便利に使えており気に入っております。

PygmentでコードをシンタックスハイライトしたりLSIで関連記事表示したりと結構手を入れてはいたんだけど、いわゆる世間の一般のブログにあるようなカテゴリ一覧表示機能と、カテゴリごとの記事アーカイブ機能がなくて、それを若干不便に思っておりました。

ググってみたところ、プログラマー向けなブログツールなだけあっていろんな方法が出てきました。以下そのまとめ。

カテゴリ一覧

JekyllのLiquid (テンプレート言語) には {{ "{{ sites.categories " }}}} みたいタグがあるんだけど、こいつが意図したとおりに動かない。普通のRuby使いの感覚からすると site.categories ってカテゴリを沢山持った配列になってそうな気がするんだけどこれが違う。

<ul>
{{ "{{ for category in sites.categories " }}}}
  <li>{{ "{{ category.name " }}}}</li>
{{ "{{ endfor " }}}}
</ul>

↑みたいな感じのコード書くと何も表示されない。 site.categoires はHashで、{ "カテゴリ名" => カテゴリ内の記事一覧 } みたいな構造になってる。LiquidでHashのキーを取りだす方法が分からず、どうにもこうにもいかなかったので他の人が作っているプラグインを利用することにした。

↑のファイルを JEKYLL_ROOT/_plugins にコピーする。(_plugins というディレクトリがなければ作る)。そんでテンプレートを変更する。↑のやつを↓みたいにする。

<ul>
{{ "{{ for category in sites.iterable.categories " }}}}
  <li>{{ "{{ category.name " }}}}</li>
{{ "{{ endfor " }}}}
</ul>

2行目のところが変更点です。これでカテゴリ一覧表示ができるようになる。

カテゴリごとの記事一覧

カテゴリごとの記事一覧を表示する方法だけど、こういうのを発見した。

ここの generate_categories.rb を使えばカテゴリ内の記事一覧を作成できる。こんな感じ。

これもさっきのと同じように、JEKYLL_ROOT/_plugins にファイルをコピーする。そんでLiquidテンプレートを書き換えるんだけど詳細はプラグイン内の記事をご確認くだしあ。

| @WWW

IMG_0109

先々週になるけど、福岡に新しくできた アラタナ研究所 のレセプションに行った。研究所の所長であらせられる @rytich さんに招待してもらった。

なんと同研究所には熊本にいた頃からお会いしてみたいと思っていた @shunsuk さんもお勤めであり、お目にかかってご挨拶することができた。

@shunsuk さんのブログ「 で写真が見られるけど、パーティションが全面ホワイトボードのオフィスはとてもかっちょよい。ホワイトボードに↑の落書きを施した後、他の人が書いたのを見てたらウェブアプリケーションのスキーマを書いたとおぼしき走り書きが目にとまった。前の職場で一人でプログラム書いてた頃が無性に懐かしくなった。ああでもない、こうでもないと考えながら、作っては壊し、作っては壊しを繰り返してプログラムを書いていくのがとても楽しかったことを思い出した。

レセプションの最後に若くてイケメンな株式会社アラタナの濱渦社長が「九州から面白いサービスを作っていきましょう」とスピーチしていたけど、すごく楽しそうで羨ましかったし、自分もなんかしなきゃと焦ってしまった。

何はともあれアラタナ研究所オープンおめでとうございます。

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

ポータルシットをLokkaに置き換えたくていろいろやってる。ポータルシットの過去記事をYAMLでエクスポートし、それをLokkaのDBに取り込む作業をやってる。TDD BootCampに参加したので、テストファーストしながらの作業。RSpecでテストコードを書き、ログが正しくインポートできることを確認する。テスト終了時 after(:all) フックで、取り込んだログを削除してる。コードはこんな感じ。ちなみにLokkaはDataMapperをORMに採用してるので以下はDataMapperでの話。

after(:all) do
  Category.all.destroy
  Entry.all.destroy
end

しかしこれでは AUTO INCREMENT の値がリセットされず、テストを繰り返す度に AUTO INCREMENT の値が増えていってうざかった。

DataMapperの機能で AUTO INCREMENT 値をリセットするのってないのかなと5秒くらい探してみたけど見つからなかったので、SQLを直接実行する方法を採用した。

ちなみにRDBMSに採用してるのはSQLite3。SQLiteでは UPDTE sqlite_sequence SET seq=0 WHERE name='テーブル名'; みたいなコードで AUTO INCREMENT 値を任意の値に設定できるみたい。

最終的な after(:all) フックはこんな感じ。

  after(:all) do
    Category.all.destroy
    Entry.all.destroy
    Entry.repository.adapter.execute('update sqlite_sequence set seq=0 where name="entries";')
  end

テスト実行後にはすべてのデータがデータベースから削除されて、AUTO INCREMENT の値もリセットされる。人畜無害なテストコード万歳。

| @Mac/iPhone

お小遣い管理にはCha-Chingを使っていたんだけど、Mac版はずーっとベータ版のままで正式版が公開されず、iPhone版もMac版とは完全な同期を取れないという致命的な欠陥があるため(PayeeとTransaction Titleがごちゃ混ぜになるとか)、iComptaというソフトを使ってみることにした。

iCompta

二週間くらい試用してみたけどわりといい感じだったのでiPhone版とMac版を買ってみた。

Cha-Chingは画面がMac Likeで、iSightで写真を撮ってレシートの内容を保存とか、お金の動きを入力するのが楽しくなる仕掛けがたくさんあった。しかしある期間でいくら収入があっていくら支出したのかが一目で確認できなかった。グラフ表示とかもできない。とりあえず赤字になってないことくらいは分かるんだけど、収入と支出の割合みたいのが分からないので、「今月使いすぎたかもなー」というような使い方ができなかった。

それに対してiComptaはお金の動きがある度にその時点での財産を表示してくれるし、チャートや円グラフも表示してくれて、「どのカテゴリーにいくら使ったか」がわかりやすい。例えば一ヶ月にどれだけ「外食」に金を費やしたかとか、ガソリンにいくら使ったかとか。

またTransactionごとにそのときの残高を表示してくれるので、お金の動きを追いやすい。

正直、見た目のMacっぽさとか入力する気を起こさせるという点ではCha-Chingの方が優れていると思うけど(iComptaは会計ソフト度満点というか、グラフの描画とかがWindowsのアプリケーションっぽい)、いまんところ確実にiPhoneとシンクできてデータを欠損しないのでしばらくこっちを使ってみることにします。

| @散財

しょうみな話、iPadとか友達が沢山いてみんなで遊んだときの写真とかいま撮ったばかりの写真を友達に見せる機会がたくさんある人のためのデバイスで、休みの日は一人で映画館にこもって一日で三本映画見たり、Twitter見ながら松屋でフレッシュトマトカレー食べたり、写真撮るにしても人物写真とか皆無で朽ち果てた建物とかの写真ばかり撮ってる僕には必要ないデバイスですよね。、