portal shit!

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

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

Lokka で Syntax Highlight するプラグイン（morygonzalez/lokka-pygmentize · GitHub）、これまで Ajax で Syntax Highlight させてたんだけど、HTTP リクエストが増えていけてないと感じたのでサーバーサイドでハイライトが完結するように変更した。Railscasts の #272 Markdown with Redcarpet - RailsCasts を参考にして、プラグインの中で Entry クラスを再オープンした。こんな感じ。

class Entry
  def body
    doc  = Nokogiri::HTML(self.long_body)
    doc.search("//pre").each do |pre|
      code = pre.css("code")[0]
      pre.replace Pygments.highlight(
        code.text.rstrip,
        :lexer   => code[:class],
        :options => { :encoding => 'utf-8' }
      )
    end
    doc.to_s
  end
end

前の実装はだいぶいけてなかったと思うので随分マシになったと思う。あと この Pull Request でレンダリングエンジンに Redcarpet が追加されたので、GitHub と同じように

```ruby

```

みたいな感じの書き方でコードがハイライトされるようになった。便利。

追記1

ちゃんと動いてなかった…。夜直します…

追記2 2013/02/04 0:45

最終的にオープンした Entry クラスのコードは以下のようになった。

class Entry
  alias_method :original_long_body, :body
  def highlighted_long_body
    syntax_highlight(self.original_long_body)
  end
  alias_method :body, :highlighted_long_body

  alias_method :original_short_body, :short_body
  def highlighted_short_body
    syntax_highlight(self.original_short_body)
  end
  alias_method :short_body, :highlighted_short_body

  def syntax_highlight(body)
    doc = Nokogiri::HTML(body)
    doc.search("//pre").each do |pre|
      code  = pre.css("code")[0]
      lexer = if pre[:class].present?
                pre[:class]
              elsif code.present? && code[:class].present?
                code[:class]
              else
                nil
              end
      begin
        pre.replace Pygments.highlight(
          code.text.rstrip,
          :lexer   => lexer,
          :options => { :encoding => 'utf-8' }
        ) if code
      rescue MentosError
        next
      end
    end
    doc.to_s
  end
end

Lokka、結構メタプログラミングが多くて、Entry クラスのインスタンスの body メソッドは単なるゲッターではなく、 index アクションのときと show アクションのときで別々にエイリアスが設定されていて、index アクションのときは Entry#short_body 、show アクションのときは Entry#long_body が呼ばれるようになっていた。アラウンドエイリアス使って力業で解決したけど他のプラグインが同じように振る舞ったら破滅を招きそうな気がする…。それにしても『メタプログラミング Ruby』読んでなかったらどうすればいいか皆目検討付かなかっただろうなー。

最近、会社でリーダブルコードを輪読したり、Fukuoka.rb で Eloquent Ruby を読んだりしていて、メソッドや変数名の長さやコメントについての議論を読む機会があった。

昨日、たまたま 37signals のブログを読んでいたら、Rails の作者である David Heinemeier Hansson もこのトピックについて書いていた。

自分は WEB+DB PRESS で ukstudio さんの書いた RSpec についての記事を読んで感化されて以来、ソースコード中のコメントはすべて悪で、はっきりしたメソッド名、変数名を使えばコメントはいらないという考え方を持っている。DHH もそのような考え方のようだ。

Clarity over brevity in variable and method names – Signal v. Noise

Many programmers have a natural preference for short variable and method names. I doubt many would recognize this preference as a trade of brevity for clarity, but that’s often exactly the result. This is especially true if you subscribe to the ridiculous Church of 80-character Lines. It n…

37signals.com

要点をかいつまむ。

多くのプログラマーは短い変数名やメソッド名を好む。短い命名は明確性や簡潔性を犠牲にしているとみんな気づいてるんじゃないかと疑ってるんだけど、実際のところ短い命名を採用したコードが多い。特に「一行は80文字まで」教の連中に。

しかし最近のプログラミング言語は表現豊かなのだから、短い命名にこだわる必要は無い。

extension を ext と略してあるのを見かけると嫌気がさす。アプリケーション固有の略語を作るのはもっとひどい。そんなの二ヶ月後には絶対忘れてる。

過剰に明瞭な名前は一見するとバカっぽい。処理内容よりもメソッド名の方が長いとかね。でも一発でやってる内容が分かることの前ではそのバカっぽさは霧消する。

最近の Basecamp のコードにはこんなのがある。

def make_person_an_outside_subscriber_if_all_accesses_revoked
  person.update_attribute(:outside_subscriber, true) if person.reload.accesses.blank?
end

def shift_records_upward_starting_at(position)
  positioned_records.update_all "position = position - 1",
    ["position >= ?", position]
end

def someone_else_just_finished_writing?(document)
  if event = document.current_version_event
    !event.by_current_creator? and event.updated_at > 1.minute.ago
  end
end

もし十分に明確な命名をしているのであれば、コードにコメントを書く必要がない。コメントというものは往々にして不明瞭な命名をしているコードの中で必要になる。コメント付きのコードはやばい臭いを放っていると思っといた方がいい。

コメントはいらない

リーダブルコードの中にも「名前は短いコメントだと思えばいい」というくだりがあるけど、基本的にあの本には「いいコメントを書け」と書いてあるような気がする。コメントそのものを悪いとみなしていない。

先々週読んだ Eloquent Ruby の Chapter 8. Embrace Dynamic Typing の中では Ruby という言語の特性も踏まえ、コメントはいらないと書いてあった。

例えば Ruby ではメソッド名の最後にはてなをつけてあると Boolean を返すという慣習がある。だからコードの中に「○×を判定し true/false を返します」というようなコメントはいらない。

def is_longer_than?(number_of_characters)
  @content.length > number_of_characters
end

Eloquent Ruby は Chapter 1 でもコメントについて述べている。そこには「コメントを書くべき理由があるコードもある」と書いてある。そのコードの使い方を指南したコメントだ。「なぜそのようなコードを書いたのか」、「コード内で用いているアルゴリズムの説明」、「どのようにして高速化したか」というようなことは書くべきではないと言っている。この辺はリーダブルコードと正反対だ。リーダブルコードでは「なぜそのような実装にしたのか」を積極的に書くように奨励されていた。

ちょっと前にはてブでホッテントリに入ってた、ソースコード内のコメントでコードレビューをやるというやり方は最悪だと思う。売り物のコードの中でああでもないこうでもないと議論するなんて狂ってる。コードが修正されたときに議論の内容まで適切に修正されるとは思えない。下手をするとコメントとコードの内容が正反対になってしまうかも知れない。コードの背景についてはコード内に書かず、GitHub 使ってインラインコメントでやった方が良いと思う。

皆さんはどう思いますか？

自戒エントリー。

自分は Mongoid を使って開発してるんですけど、時間の境界値のテストが不十分で問題に遭遇したのでメモっておきます。

Mongoid には Date 型や DateTime 型があるけど、データベースにデータを保存するときには Time 型に変換されます（MongoDB に Date とか DateTime がないから？）。Mongo Shell で DB の中の値を見ると Time 型の値が入ってる。

だからクエリを生成するときに Date.today はなるべく使わない方がいい。Date.today では時間を 00:00:00 として扱い、月末のデータの取得に失敗する可能性が高いから。Rails console で確認すると、以下のようになります。

pry(1.9.3-p194)> 1.month.ago.end_of_month
# => Fri, 31 Aug 2012 23:59:59 JST +09:00
pry(1.9.3-p194)> Date.today.prev_month.end_of_month.to_time
# => 2012-08-31 00:00:00 +0900

上記は二つとも「先月末の月の終わり」を検索していますが、後者では時間が 00:00:00 になっています。例えば以下のような Mongoid でのクエリでは、8月31日の午前0時0分1秒以降に作成された Document を取得することが出来ません。ナンテコッタイ！！！

Model.where(:created_at.lte => Date.today.prev_month.end_of_month)

「Date.today を時刻の生成の起点にしたとしても、to_time してあげればいいのでは？」と思う方もいるでしょう。確認してみましょう。

pry(1.9.3-p194)> Date.today.prev_month.end_of_month.to_datetime
# => Fri, 31 Aug 2012 00:00:00 +0000

#prev_month メソッドが呼び出された時点のオブジェクトの型は Date 型なので、Date 型に対して時間の操作を行って最後に DateTime 型に

結論

時刻まで考慮した時間の範囲でクエリを作るときは以下に留意すると良いでしょう。

• Date.today は使わない
• DateTime.now か 1.month.ago などを使う

今年の3月くらいから、寿限無の和田さんが発起人になって Fukuoka.rb という勉強会をやってる。毎週木曜の 19:30 からで、ペ社は会場を提供している。勉強会と言ってもやってることは技術書の輪読で、最初は『メタプログラミング Ruby』を読んだ。メタプログラミング Ruby は中級者以上向けの本でなかなかレベルが高く、当初は 30人ちかくいた参加者が回を重ねるごとに減っていき、最後は5, 6人くらいしか参加者がいなかったけれども、歯を食いしばって出席し続けた。簡潔に書ける、美しいコードが書ける、という以上のことができる Ruby の側面を学んだと思う。いまは二冊目の課題図書として洋書の『Eloquent Ruby』を読んでいる。

福岡でやってる Ruby の勉強会、何回か出たことあるけど、Rails ハンズオンみたいな初心者向けの内容だったり技術より精神面を重視した内容だったりで個人的には消化不良な感じがあった。また開催が不定期で、プログラマ同士の情報交換がしにくいと感じていた。

Fukuoka.rb は原則的に毎週開催で、扱う内容も初心者よりというよりは中上級者向けで、本を読みながら喧々諤々とした議論も繰り広げられるし、自分はあまり参加しないのだけど勉強会の後はみんなで飲みに行ったりもする。業務で感じていた疑問を詳しい人に尋ねたり情報交換しやすい。

個人的には、中学生の頃に通っていた隣町の塾を思い出す。自分は田舎に住んでいたので、都会の塾に行くだけでレベルの高さに驚くとともに刺激を受けて、都会っ子に追いつこうと勉強を頑張った。Fukuoka.rb は参加者のレベルが高く、なかなかついて行くのが大変なのだけど、確実に Ruby 力が高まっていると思うし、出てて良かったと感じる。

Asakusa.rb や Yokohama.rb のような Ruby コミュニティをずっとうらやましく思っていたけど、これらに近い Ruby コミュニティが福岡にできつつあると思う。時々は Ruby コミッターの @nagachika さんも参加している。福岡在住の Ruby プログラマで腕に覚えがある人は、是非毎週木曜日に天神プライムビル8階で開催されている Fukuoka.rb にお越しください。面白くしていきましょう。

hsbt さんが会社に入ってから大きく雰囲気変わった。hsbt さんは並の寿司を上にぎりとかにランクアップするパワーがあると思う。IRC とか Ustream ごしにその存在感を感じる。こういう人がメンターだなんて今年ペ社に入った新卒エンジニアはとてつもなくラッキーだったと思う。世の中には訳のわからない Java の研修を延々受けさせられてる新卒 SE さんもいるのに、ペ社の新卒エンジニアは WEB+DB PRESS に寄稿するような人から最新シャレオツ Rails 開発事情をたたき込まれたのだ。下手をすると中途で入って実サービスに投入されてる経歴不詳の怪しい30過ぎのおっさんよりも良いコーディングマナーを身につけているかもしれない。新卒エンジニア氏一名が自分の部署に配属されることになったので、来月自分は戦力外通告を受けて気がついたらハローワークに日参しているかもしれない。

なんか hsbt さんばかり持ち上げてしまったけど antipop さんも Webistrano をさくっと Rails 3.2.5 で動くようにしたりとかすごい。技術力ある人は技術力に比例して行動力が高い気がする。やらなきゃと思ったこと、読まなきゃと思った技術書を一晩とかでさくっと実装・読破してしまう。そういうところが並のエンジニアと大きく異なる点だと思う。

あるモデルがあって、#save が実行されたときに同一モデル内で複製したインスタンスも一緒に保存したかった。一個目の #save が走る前にコールバックメソッドを使って複製したインスタンスを保存するようにした。コードだと以下のような感じ。

class Model
  before_validation :method_one
  before_create :method_two

  def method_one
    ...
  end

  def mothod_two
    Model.reset_callbacks(:validation)
    Model.reset_callbacks(:create)

    @model = Model.new
    @model.save
  end
end

なんで reset_callbacks 呼んでるのかというと二回コールバックメソッドを走らせないため。一回目の #save （コントローラーから呼ばれる）が呼ばれたときだけコールバックメソッドを実行して、二回目の #save （モデルのコールバックメソッド内で呼ばれる）では実行したくないから。

しかしここではまってしまった。なんとコールバックメソッドで複製したドキュメントを DB 内で確認すると created_at が空になっている。なんじゃこりゃ。

どうも reset_callbacks(:create) がいかんかったみたい。ORM が実行する create 周辺のコールバックメソッドも軒並みリセットされてしまう模様。

そういうわけで以下の様にして解決した。

class Model
  before_validation :method_one
  before_create :method_two

  def method_one
    ...
  end

  def hoge
    Model.skip_callback :create, :before, :sell
    Model.skip_callback :create, :after, :send_notification
    Model.reset_callbacks(:validation)

    @model = Model.new
    @model.save
  end
end

callback、便利だけど奥が深い。ちなみにこれら skipp_callback とか reset_callbacks とかは ActiveModel や ActiveRecord （僕はMongoidで開発してます）などの OR マッパーのメソッドではなく、 ActiveSupport::Callbacks のメソッドだったりします。ActiveSupport も奥が深い。