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

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

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

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

要点をかいつまむ。

多くのプログラマーは短い変数名やメソッド名を好む。短い命名は明確性や簡潔性を犠牲にしているとみんな気づいてるんじゃないかと疑ってるんだけど、実際のところ短い命名を採用したコードが多い。特に「一行は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 使ってインラインコメントでやった方が良いと思う。

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

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

だいぶ前の記事では Jekyll は Git の hook を使って公開してると書いてた。

しかし記事の本数が増えてくると、 jekyll コマンドで生成した静的なファイルも Git でトラックするのがだるいと感じるようになった。ので Rakefile に以下のような task を追加して、公開先のサーバーに rsync でファイルを転送するように変更した。

desc "Publish"
task :publish do
  path = File.expand_path("_site")
  if system("rsync -avz --delete #{path}/ portalshit:sites/tech.portalshit.net/_site/")
    puts "Your blog was successfully published!"
  else
    puts "Something went wrong..."
  end
end

だいぶデプロイが手軽になった。

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

I know why you came here. BECAUSE IT'S HARD TO FIND CONTENT IN GITHUB WIKI!!!

Here is a solution.

My colleague Tomohisa created a nice userscript. It provides you an ability to search GitHub Wiki in pretty easy way.

Install the script from his GitHub repository. It's compatible with Firefox (with Greasemonkey, of course), Google Chrome and Safari (with Nijakit).

Then you will find search box on right above "Page History" button.

1.png (640×457)

2.png (640×457)

Now search all the wiki content with github-wiki-search.user.js!

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

Mac の iTerm 2 皆さん使ってますか。コンソール中に現れた文字列をハイライト通知できたりしていろいろ便利らしいですね。でも僕は使っていませんでした。なぜか。

Ctrl + Shift + J によるかな入力変換ができないから。

これが非常にだるかった。宗教上の理由や国外在住でJISキーボードが手に入らないなどの理由のためやむなく英語キーボードを使っている方、おられると思います。そういう人はだいたい Ctrl + Shift + J で英数 -> かなの入力変換を行っていると思いますが(Command + Space の切り換えもできなくはないけどだるいですよね…)、iTerm 上では Ctrl + Shift + J で改行が行われてしまうため、このような操作が行えていませんでした。かなから英数入力に切り替える Ctrl + Shift + * も同様、むなしく ' などが表示されるだけ。標準の Terminal.app ではできるのになんでやねん。

iTermでの日本語入力 - 初学者の箸置 なんかを参考に Send Hex Codes 0x4a するようにしてみたりしたのだけどうまくいかなかった。

しかし先ほど仕事をさぼって iTerm の設定項目を確認していたら以下の設定で使えるようになったのでここに書き記しておきます。

iTerm で Ctrl + Shift + J でかな入力変換する方法

↑のように、iTerm の Preferences -> Profile -> Keys で Ctrl + Shift + JCtrl + Shift + * の項目を追加し、メニューから "Do Not Remap Modifiers" を選ぶだけでオッケー。かな英数の切り換えが快適に行えるようになる。困っている方お試し下さい。

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

社畜なのでVドメインからMドメインにドメインの管理業者を変更した。そしたらDNSの設定やらなんやらを忘れていて、tech.portalshit.net が死んでた。最近は技術っぽい内容も www.portalshit.net に書いてるしここの存在意義が微妙になってきた。Jekyll、便利ではあるんだけど、rbenv で Ruby のバージョン上げるごとに gem install jekyll gsl とかやるのが若干めんどくさく感じられるようになってきてしまった。ただ記事を書くためだけにそこまでやりたくないかも。

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

Qiita の Kobito、入れてみた。いい気がする。

プログラミン関連のメモとかは Evernote に書いてきたけど、正直かなりだるかった。シンタックスハイライトできないし、タブ幅とかこちらで指定できないし、コードを入力した部分を選択して固定幅フォントを指定する手間とかもだるかった。

Qiita は基本的に Markdown で書くっぽい。

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

自戒エントリー。

自分は 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.now1.month.ago などを使う