System.Exit

ruby-debug ってのをちょこっと使ってみました。
結構お手軽で便利かもしれません。

ていうか、デバッグツールとしては rails の breakpointer みたいなのでとりあえず十分なんだけど、あれって rails 以外で単体で使ったりできないのでしょうか。
ま、ruby-debug を使えば似たようなことできるのでいいんですけど。

インストールと起動

以下のような感じでインストール。

gem install -y ruby-debug

そしたら以下のようなコードを書いて実行してみてください。

require 'rubygems'
require 'ruby-debug'

a = "hoge"
debugger # デバッガ起動
puts a
a = "hage"
puts a

すると debugger って書いてあるところで止まります。
このときプロンプトにこんなのが表示されると思います。

(rdb:1) 

この状態でいろいろデバッガのコマンドを実行することができます。
とりあえず「help」コマンドを実行してみてください。
なんかいろいろ表示されると思います。

例えば、「p」コマンドで変数の内容を出力したり、「list」コマンド でソースを表示させたりできます。
あと、まだ実験段階らしいのですが、「irb」コマンドで irb のセッションを開始したりできるようです。
irb の方が（僕が）慣れているのでいいですよね。

参考: Ruby On Rails ピチカート街道 - デバッグ初体験03【ruby-debug v0.9.3 マニュアルお気楽翻訳】 -

デバッガの起動方法として、rdebug コマンドと使うというやりかたもあります。
ruby コマンドの代わりに rdebug コマンドでプログラムを実行します。
こんな感じ。

rdebug debug_test.rb

ruby-debug の利点

ていうか、ruby にはもともと標準のデバッガがあるわけですが、それと比べた場合の ruby-debug の利点って何なんですかね。
挙げるとしたら以下の点ですかね。

1. debugger メソッドにより、breakpointer みたく任意の場所でデバッガを起動できる
2. irb セッションを起動できる

1 に関しては、プログラムに「require ‘ruby-debug’」ってのを書かないといけないという煩わしさがあります。
あと、まあ、まだ使い方を調べただけで実際にそんなに使い倒してないので正直なんとも言えませんが、なんかこう、デバッガって言うと取っ付きにくいイメージが（僕の中では）ありますが、ruby-debug は（僕の中では）比較的取っ付きやすい気が（なんとなく）します。

これも参考になるかもしれません。
Local Insanity » Ruby Debug Basics [screencast]

ruby-debug の基本的な使い方のスクリーンキャストです。

Rubyist Magazine 出張版 正しいRubyコードの書き方講座―RubyistのRubyistによる、Rubyistとそうでない人のための 青木 峰郎 毎日コミュニケーションズ 2007-03 売り上げランキング : 16689 Amazonで詳しく見る by G-Tools

思ったより読みやすかった。
Web だと文章量多くて読むのしんどかった（なので全部は読めてなかった）けど、書籍としては各章ちょうど良い分量だと思った。
しかも説明が丁寧で非常にわかりやすかった。
青木さんの本は他にも「ふつうのHaskellプログラミング」とか読んだことあるけど読みやすかったなぁ。
プログラマとしての好奇心を十分満たしてくれる内容だったなぁ。

以下、僕的ポイント。

• 標準ライブラリの便利なメソッドを積極的に使うべき。
• module_eval でいろいろできる。でも乱用はだめ。
  

  module_eval {|mod| …. }
  モジュールのコンテキストで文字列 expr を評価してその結果を返します。
  Rubyリファレンスマニュアル - Module.module_eval

• method_missing メソッドをオーバーライドすることで、未定義のメソッド呼び出しに対する処理を実装できる。
• define_method メソッドでメソッドを定義できる。
• dRuby 使ってみようなぁ。
  dRuby
• 「エラーメッセージを出力するときは warn か $stderr.puts を使う」
• プログラム引数の解析には OptionParser が便利。
• rdefs という青木さん作のツールが便利そう。
  指定したファイルにどんなクラスとメソッドがあるのかを調べる為のツール。
  以下から入手可能:
  青木日記 2006-09-09
• 「inhelited はそのクラスを継承するクラスを定義したときに Ruby インタプリタが呼ぶメソッドです。」
  使う機会はほとんどなさそうだけど、マメ知識的な。
• RSpec 使ってみようかなぁ。
  RSpec-1.0.8: Home
  角谷さんによるチュートリアルの日本語訳:
  File: TUTORIAL.ja

  <<< 追記
  角谷さん曰く、上のチュートリアルの日本語訳よりも以下のるびまの記事を読んだほうが良いとのこと。参考にさせていただきます。
  Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)
  >>> 追記

• 設定ファイルの書き方いろいろ。
  Ruby の場合は Ruby スクリプトそのものを設定ファイルとして使えばほとんどの場合は事足りるんだろうけど、それにもいろいろやり方があるみたい。
• File#flock(File::LOCK_SH) でファイルに共有ロックがかけられる。
• スーパークラスのメソッドを呼ぶ際に「super()」ではなく「super」とだけ書くと、引数がそのまま渡される。
• 正規表現リテラルに o オプション（その正規表現を最初の一回だけコンパイルするオプション）を付けることで処理を高速化できる場合がある。

などなど。

いやー、今日は二日酔いでした。
飲み過ぎました。
酒に飲まれましたね。

ところで、これ読みました。

あなたはコンピュータを理解していますか? 10年後、20年後まで必ず役立つ根っこの部分がきっちりわかる！ (サイエンス･アイ新書) 梅津 信幸 ソフトバンク クリエイティブ 2007-03-16 売り上げランキング : 906 Amazonで詳しく見る by G-Tools

積読しつつちょっとずつ読んでて、最近ようやく読み切りました。

いやー、面白い本でした。
例え話が非常にわかりやすい。
ちゃんと理解しているようでいて、実はぼんやりとしか理解していなかったりしたところがかなり鮮明になった気がします。
表現の仕方だけでずいぶん理解の「質」みたいなのが変わってくるんですね。
とにかく例え話がどれもおもしろくて、しかもわかりやすいんです。
あとがきから引用します（強調は原文ママ）。

難しいことを難しいまま説明することは、ある意味とても簡単です。だって、自分だけが理解していればいいのですから。難しいことを、知らない人にどれだけやさしく説明できるか？　いかに本質だけを取り出してたとえ話にできるか？　それができる人こそ、真に理解している人だと私は考えています。逆にいえば、比喩で説明できない人は、頭の中でそれがちゃんと整理されていません。

まったくその通りだと思います。

同じメソッドを続けて何回も呼びたい時ってないですか？
gsub を何回も呼んだリだとか。

えーと、例えばこんなようなコードを書いたりしたことないですか？

puts "hoge".gsub("h", "H").gsub("o", "a").gsub("e", "eee!!!!") #=> Hageee!!!!

ありますよね。
「gsub」を何回も書いててかっこわるいですね。
どうせ同じメソッドを続けて呼ぶんだから、「gsub」と書くのは一回きりにしたいですよね。

そこでこんな関数を考えました。

class Object
  #
  # 同じメソッドを引数のバリエーションの数だけ呼び出します
  #
  def send_c(name, *args_list)
    result = self
    args_list.each{|args|
      result = result.send(name, *args)
    }
    result
  end
end

ちなみに、メソッド名「send_c」の「c」は「continuously」だかなんだかの「c」。

こんなふうに使います。

# 使用例
puts "hoge".send_c(
    :gsub,
    ["h", "H"],
    ["o", "a"],
    ["e", "eee!!!!"]
) #=> Hageee!!!!

うん。
便利便利。

…

これ、役に立ちますかねぇ。。

立体パズルなんか買ってみましたよ。

スヌープキューブ 学研 売り上げランキング : 6727 Amazonで詳しく見る by G-Tools

昨日はこれで遊んでました。

まあ、とりあえず解けました。
半日くらいかかりましたけど。

初期状態がこんなで、

これをこねくり回すとこんな形になります。

手順:
立方体に変形する手順を以下に載せておきます。
※自分で解きたい人は見ない方がいいです。

1. 
2. ひっくり返す。
3. 
4. 
5. 
6. 
7. 90度回転させる。
8. 
9. 
10. 完成！（＾ｏ＾）／

プログラミングって、要は「会話」なんなんだと思います。
プログラムを書くことを通していろんな人と会話するわけです。
会話の相手は、プログラミング言語やライブラリ、フレームワーク等を作った人達や、その他いろいろです。
プログラマーは、相手の意図をできるだけ正確に読み取る必要があります。
それが上手くできないと、ちゃんとしたプログラムは書けないと思います。

具体的に言うと、HTML の仕組みとかスタイルシートの仕組みとか、なぜそんなふうになったのかとか、そういったようなことをきちんと理解している必要があるということです。
そういった諸々の仕様は、誰かの意図があってそうなったわけですよね。
その意図をちゃんと読み取らないとだめなんです。

…

ああ、なんか、当たり前のこと言ってますね。

愚痴:

「それ、プロとしてどうなの」と言いたくなるような、そんなプログラムを最近たびたび見かけます。
ま、僕自身もそんな偉そうなこと言えるレベルにはまだまだ達してませんが、そんな僕から見てもあきらかに「ひどい！」と思えるような、そんなプログラムを書いてしまう人が世の中にはいるんですね。
プロとしてまだまだ未熟な僕ごときに「プロとしてどうなの」というようなことを言わせてしまうような人は、本当にプロとしてどうなのかと思いますよ。
自分が作った部分がとりあえず動けばそれでいいんですかね。

ひどいプログラムを見た時は、まず何よりもその人の美的感覚を疑ってしまいます。
インデントがちゃんとそろっていなかったりだとか、意味のわからない変数名がたくさんあったりだとか。
あと、不要なコードが削除されずに放ったらかしになってたりするのも許せないですね。

まったくもう。

と言いつつ、ダメプログラムをガシガシ直していくのは楽しくもあります。
テストしながら慎重に作業を進めていく必要がありますが。
自分の新しい実装でシステムが正常に動作するとかなり嬉しくなりますね。