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

一個前の記事で書いた「記事の更新時に 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 にも色々問題があるのでしょうけどね。

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

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テンプレートを書き換えるんだけど詳細はプラグイン内の記事をご確認くだしあ。

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

ポータルシットを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 の値もリセットされる。人畜無害なテストコード万歳。

| @読書

今日は読書の方法について書いてみます。自分の読書方法をオススメするわけではなくて、他の人の読書方法を知りたいという意図のもと、まずは自分の読書方法を開陳してみる次第です。だめ出しとか突っ込みとかさらにいけてる読書方法があったら教えて欲しいです。

付箋を貼ってる

1116_reading_1.jpg

ここ一年くらいの習慣ですが、読書をするときには重要だと思える箇所や気になった箇所に付箋をつけるようにしています。読書といっても小説は含みません。ここでいう読書とは新書など少し堅めの本を読むことを指します。

本に線は引きたくない

本に直接線を引く人もいます。しかし僕はそれは気が進まない。理由は貧乏性だからで、いつかその本を売るかもしれない。線が引いてあると買い取り拒否されるかもしれない。付箋なら売るときはがせばいいので問題なしなわけです。(といはいえ読まなくなった本を売ったことはないんだけど)

売る売らないは別にしても、誰かに貸したりあげたりしたときのことを考えると、何となく本には線を引きづらいです。特にハードカバーの本には線が引きづらい。ソフトカバーのいわゆる学校の教科書的な本や問題集などにはためらわずに線を引きます。売ることもないしこの手の本はどんどん情報が古くなっていく消費財だから。しかしハードカバーの本は自分の所有物でも簡単に何かを書き加えてはいけないような緊張感があります。

話がずれました。そういうわけで僕は線を引くかわりに付箋を使ってます。

三色ボールペンメソッド

本に線を引く方法で知っているものに斎藤孝さんの三色ボールペンメソッドがあります。「重要」、「とても重要」、「個人的に面白かった」の三種類で色を使い分けるやり方です。

理想的なのは本の内容に沿って色を使い分ける方法でしょう。テーマAについては赤、Bについては青、Cについては黄、といった具合で色を使い分けておくと、後から読み直すときに非常に内容を把握しやすい。

しかしこれはあくまで理想論で、本を頭から読んでいる段階でその本の中に何種類のテーマがあるのかを把握し色を用意していくのは困難。結局三色くらいで、重要度や自分が受けた印象に合わせて色を使い分けるのが現実的なマーキングのあり方でしょう。

付箋の貼り方

1116_reading_2.jpg

僕が使っている付箋は住友スリーエムの『ポスト・イット®ジョーブ 透明見出し』です。プラスチック製のケースに入っていていて、ティッシュみたいな仕組みでぺりぺりと交互に調子よくめくれるところが気に入ってます。下半分は透明になっているので本文の上に貼っても内容が見えなくなることはありません。カラフルな色バリエーションもいい。

しかしながら色が多すぎるのは否めない。6色もあります。3色くらいがベストですね。6色のなかの特定3色だけ用途を決めて使えば良いんだけど、貧乏性なのでついつい6色満遍なく使ってしまう。その結果、折角色つきの付箋を使っているのに色を見ただけで意味を理解できないという非常に残念なことになっております。貧乏性の馬鹿野郎。

読んでいて重要だと思った箇所や個人的に面白かった箇所に付箋を貼りながら読んでいき、読み終わったらブログに感想を書く前にもう一度付箋が貼ってある箇所を拾い読みします。この作業でだいたい本の内容が頭に入ります。

今後の課題としては、もっと付箋の色を抑えて、それぞれの色に特定の意味を持たせてそれを定着させる必要があります。

中途半端な感じですが以上が僕の読書スタイルです。よかったらみなさんの読書スタイルを教えて欲しいです。

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

CakePHP、ちょこっと使ってみるだけのつもりだったんだけど、結構深くつきあってしまった。三つほどCakePHPでサイトつくりました。一つは社内用のウェブアプリケーションで、一つはまだ正式リリース前のものだけど、最後の一個はページビュー5000/日くらいあるサイトで実際に動いてます。ついこの前まで無職だったのに。スゲー。

PHPで素人がつくったサイトは危ないみたいな記事がこの前(というか定期的に)はてブでホッテントリに入ってた(る)けど、セキュリティのこととか分からない初心者こそCakePHPとかでサイトつくった方が楽だし安全だと思った。難しいことはフレームワークがやってくれるので。Bakeすればものの数分でウェブアプリケーションが出来てしまう。もちろんどんなフレームワークにも脆弱性がないわけじゃないだろうから100%安心というわけじゃないけど、少なくとも素人が自分でなんかやるよりも安全だと感じる。

とはいえ、フレームワークで万事オッケーなわけでもなかったりする。ちょこちょこっとカスタマイズするみたいのがフレームワークは難しい。特にCakePHPは規約がすごく重視されるから、データベースへのクエリでちょっと変わったことしようとすると結構難しくなる。というかはまる。サイト内検索をつくろうとして結構苦労した。土台が出来上がるまでは速いんだけど、そこからブラッシュアップさせていくときに結構停滞してしまう。それでも自分で一からつくるよりはかなり迅速に作れるんだけど、規約に縛られるのが窮屈に感じることもないではないですね。

で、タイトルの件なんだけど、真面目にエロサイトを作ってみた【プログラマ編】|ASTRODEO という記事がおもしろかった。はてブで1200以上ブックマークされますが1ゲットは僕です。すごいでしょ。いや僕は全然すごくないですね。書いてある内容がすごい。

確かにエロとかスクレイピングとかまぁきわどい内容ではありますが、僕はCakePHPでこんだけのことをやったということに素直に驚いた。

例えばCakePHPには hasAndBelongsToMany というのがある。ブログ記事があったとして、これが一つのカテゴリーを持つ場合は、 Post テーブルと Category テーブルを結びつけてやるだけでOKなんだけど( Post は一つの Category に所属し、 Category は複数の Post を持つ)、 Tag のような複数持てるし複数に所属する概念のモデルが存在する場合、 hasAndBelongsToMany じゃないとデータの整合性というか組み合わせをきちんと保つことが出来ない。

で、自分はこういうのの組み合わせは手が空いてる人に頼んで人力でやってもらったんだけど、このエロサイトの場合は、動画と動画の関連性の判定をプログラムにやらせてる。150件そこそこのデータの整合性を保つのも大変なのに、10000件とかそれ以上のデータを、しかも自動処理で関連づけるってまじすげーと思った次第です。

エロコンテンツなのに年齢確認がないとか著作権がらみの問題とかスクレイピングでよそのサイトに負荷かけるとかいろいろあるけど、僕は率直にこういうサイトをつくったのはスゲーなと思いました。こんなことまで出来るんだー、っていう素直な驚き。読んでて楽しかったしわくわくした。

今後もCakePHPを使い続ける分からんけど、自分もなんかおもしろいもんつくってみたいなーってすごく触発されました。

蛇足

はてブのコメント欄に「技術的には大したことない」みたいなコメント書いてる人が何人かいるけど、ほんとに大したことないんですかね。データベースを保存用と参照用で分けたり、スクレイピングしてきたデータの保存処理とか結構難しいと思うんだけど。これをすごいって感じるのはピヨピヨプログラマーだけなのかな?

| @雑談

就職した

2009年はいろいろありました。まず就職した! ダサいことに上京して三日で会社辞めて帰ってきましたが。転出届を出すために役所に行ったときに会った同級生と10日後に地元のディスカウントストアで鉢合わせたときのかっちょわるさはなかなかのもんでした。まぁ僕っぽいつったら僕っぽいです。その後いろいろあっていま働いてるところにお世話になることになりました。

CakePHPをさわるようになった

いままでの趣味のプログラミングというかCMSいじりから一歩脱却して、いまはCakePHPでサイトを作っています。フレームワーク開発。開発と言ってもCakePHPはBakeやScaffoldingでものの数分でアプリケーションを作れてしまうので大して高度なことをやっているわけではないのですが、すでにあるもの(WordPressなど)をいじる段階から、フレームワークの助けは借りているものの一応自分でサイトを組み立てていくというステップに一歩前進したかなとは思います。

あとJavaScript。いまんところjQueryの面白そうなプラグインを見つけてきてそれをカスタマイズしてるだけな段階なので、せめて人の助けを借りずになんかできるようになりたいです。デザインは全然できないので誰かに頼るとして、サーバーサイドとクライアントサイド両方ある程度の技術を身につけたいかなと思っています。そんでなんか楽しいサイトを作ってみたい。

Twitterの人たちと会った

仕事以外では2009年はネットで知り合った人と良くお会いした年でした。2007年春にTwitterを初めて、2007年末から2008年前半にかけてはTwitterにのめり込んで、実際に他のユーザーに会うようになったのは地方住まいということもあって遅く、2008年の後半からでした。Twitterはもはや暇つぶしの道具ではなく生活の一部になった観があります。というかネット関係の仕事をしたいと思うようになったのはあきらかにTwitterの影響ですね。

映画をよく見るようになった

あと働き出したことで、平日はがっちり仕事に拘束されてしまうので、週末は必ず一本映画を見るようになりました。無職のときより映画への欲求が強くなったというか。これは良いことだと思います。2009年後半は毎月4〜5本ペースで見たはず。

iPhoneなどデジモノガジェットにどっぷりつかってるいまだからこそ、自宅でレンタルDVDで映画見るんじゃなくて、外に出て行って劇場でアナログ的に映画見るのが楽しいですね。知らない人と一緒に泣いたり笑ったりする場を求めているというか。映画館に足を運ぶ人が減ってるらしいけど、配給会社は工夫して劇場にもっと人が足を運ぶ仕組みを作って欲しいですね。なんたって劇場で見る映画は格別です。とりあえず映画料金を1200円くらいに値下げしてくれたら人いっぱい映画館に来ると思うんだけどな。

あまり本を読まなくなった

映画をよく見るようになった反面本を読まなくなりました。東京に住んでた頃は電車移動でしたので、電車の中で本を読むということができていたのですが、地方では車で移動するので移動時間に本を読むということがなかなかできません。実は電車の中での読書というのが非常に大切で、読書はなんかとっかかりがないとはかどらないものだと僕は思っているのですが、電車の中での読者がこのとっかかりとして最適で、電車に乗る度に本を開くので読んでいる本の続きを常に意識するようになり、帰宅してからも本をよく開いてました。しかし電車移動中の読書ができなくなると読書のひっかかりがなくなってしまって、僕のような中途半端な人間はなかなか本を開かなくなってしまうのです。加えていまはiPhoneがあるので、ついつい暇な時間はネットにアクセスしてしまう。無職のときはそれでも読書の時間があったんだけど、さすがに朝から夜遅くまで働いてると本を読む時間はとれなくなってますね。いかんなーとは思いつつ、本との距離が遠のいてます。

2009年に見た映画で良かったもの

2009年に見た映画で良かったものを三つあげてみたいと思います。一本目はなんと言ってもクリント・イーストウッドの俳優引退作『グラン・トリノ』。これは素晴らしかったです。アメリカ人になりたいって思わせる、かっちょいい映画でした。次はクエンティン・タランティーノの『イングロリアス・バスターズ』。これも完成度高かったです。映画マニアも一般の人も楽しめるというすごい映画。次が是枝裕和監督の『空気人形』。人間のエゴについて考えさせられる映画でした。次点で『あの日、欲望の大地で』と『そして、私たちは愛に帰る』かな。映画の感想を別のブログに書いているので良かったらときどき覗いてあげてください。

iPhone

2008年はiPhone一色の年でしたが、2009年もiPhoneの年でした。ブログには書いてなかったですがiPhone 3GS買っちゃってるしアップルにお伏せしまくりです。

昨夜、友達に電話して年明けに遊ぶ日程を決めていたのですが、そのときナチュラルにMac見ながらiCalでスケジュールを確認して予定を入れてました。いまじゃこんなこと普通なんだけど、数年前までは手帳に書き書きしていたことを、コンピューター上で入力して携帯電話で確認する、みたいな。スゲー世の中になってきてると思います。一昔前にこんなことやろうとしたらペンタブレット付きのPDAとかパソコンと接続するためのクレードルとか大仰なアイテムが必要だったのにねー。いまはメールとカレンダーはGoogle<->iPhone<->Macでクラウドしちゃっててマジサイコーな感じです。

2010年も適当にがんばります

とりとめもなくぐだぐだ書いてしまいましたが、2010年はもちっと飛躍出来るようにがんばりたいですね。同級生はみんな所帯持って立派になってきてるので、追いつくとまでは言わないまでももう少し年齢相応の働きをしたいです。

| @雑談

三日で辞めた会社は最終的には僕とそりが合わなかったけど、約一ヶ月の自宅研修期間に学んだことはとても大きかった。課題図書が何冊か与えられて未だかつてない超絶スピードでそれらの読書をこなして行った。その中で強く印象に残っているのがデール・カーネギーの『人を動かす』という本。戦前のアメリカで書かれた本らしいけど、いまでも通用する内容だと思う。どうやら企業が新入社員に読ませる本としては割と定番の部類に入るらしい。

これはいわゆる処世術の本だと僕は思った。クレームをつけるとき、何かお願いをするとき、初対面の人に挨拶するとき、ほんの少し心がけるべきことが書かれている。といっても5分くらいで陳腐化するようないわゆるハウツー本的なものではなくて、かなり本質的な事柄が書いてある。

要するに「おべっかを使え」ということなんだけど、アメリカ人とかはお世辞とか言わなそうだし、本音と建前とか使い分けたりしないだろうと思ってたのに、本のメインテーマはおべっか使って相手を気分良くして自分の主張を通せ、という内容だった。何かを人にお願いするときは相手にもメリットがあるようにお願いしないといけないし、クレームを付けるにしても頭ごなしに相手に文句を言っても相手の反発を招くだけで善処を期待することは出来ない、相手の心情をおもんぱかってクレームを付けよう、というわけ。なるほどなー、と思った。

この本の内容はいわゆる性善説に立っているので、あまりにも価値観が異なる文化圏の人に対しては通じないかもしれないけど、少なくとも日本人同士では有効な内容だと感じた。というか、アメリカ人が書いた本なのに内容がきわめて日本的なんだよなー。しかも戦前なのに。不思議です。