The last thing on earth the web needs right now, is another blog/blog post about another developer stumbling his way up the admittedly short Rails learning curve. Still, here a few tips, especially for the newbie Rails and OS X hackers.

Use Breakpoint

Breakpointer is great. Took me a little while to figure out how it worked as I was expect something like gdb, while breakpointer is really more of a evolutionary punctuated equilibrium from the scattering ‘print’ statements through out the code style of debugging. Instead of

print "going into crashing_function"
crashing\_function(var1, var2, var3)
print "after crashing_function"

You say

breakpoint "going into crashing_function"
crashing_function(var1, var2, var3)

And when breakpoint is reached you’re dropped into an irb shell, and can inspect those variables, call methods, and generally re-write your code on the fly.

What you can’t do is step. So if you’re interested in what is going on in crashing_function you’ll need something like

def crashing_function(var1, var2, var3)
   breakpoint "start of crashing function"
   ...
   breakpoint "end of crashing function"
end

But how you ask does a web app bring up an interactive shell? In your Rails script directory (where generate and server are) you’ll find breakpointer. Simply run it, and it will attempt to connect to a dRB server that Rails in development mode brings up behind the scenes. You’ll see

No connection to breakpoint service at druby://localhost:42531
       (DRb::DRbConnError)
Tries to connect will be made every 2 seconds...

Now go hit your web app over on localhost:3000, and when you reach a breakpoint you’ll see your app hang, and the little spinning loading icon go on and on and on. This is your clue to switch back to the terminal where you ran breakpointer

There instead of ‘No connection’ you’ll see

Executing break point "start of crashing function" at 
      ./script/../config/..//app/models/crashme.rb:15 in `crashing_function'

That is: you’re breakpoint, the file, and the name of the function. From here you can do things like

puts var1
var1.inspect
self.some_state.inspect

And lots more stuff which I haven’t really started playing with. What you can’t do is next, step, run, etc. When you’re tired of the view from this breakpoint, and are ready to be whisked away to the next one, type

exit

SecurityError (Insecure operation ‘write’ at level 4)

What if all that doesn’t happen. What if your browser doesn’t seem to go into a spinning death spiral but instead promptly pops up the error message like SecurityError (Insecure operation 'write' at level 4). The default answer is you need Ruby 1.8.2 instead of Ruby 1.8.1. “But”, I hear you say, “I’ve already got Ruby 1.8.2”. At which all the wise heads on on #rubyonrails will nod sagely, and says, “Yes, grasshopper, but you are a Mac user, and have the wrong 1.8.2.”. Basically the .dmg was silently upgraded, and you’ll need to re-download and re-install it.

Living With Your Model / Using CocoaMySQL

I’ve been using MySQL for 8+ years now, and to say I’m pretty comfortable with the mysql command line client is an understatement. (though I’ve never tricked it out like Jeremy) That said, working with Rails where a significant portion of your applications logic is inferred directly from the database means you spend a lot of time living in the database. And so for the first time ever, I went looking for a graphical MySQL client, and found CocoaMySQL. It works well with a lot of room for improvement, but my one critical tip for you is, if you’re working with a dataset of any size, go to Preferences and make sure to check “Limit results to 100 rows” or you’re going to be dealing with a bad case of the spinnies. (and unlike the breakpointer tip, this is not desirable)

gem_server

How do you get a neat, JavaDoc-y looking document site like rails.rubyonrails.com? As far as I can tell you don’t. But the next best thing is gem_server. Just run it from the command line, and it will bring up another instance of WEBrick, this one on port 8808, browse to it, and boom, you’ve got docs for all installed gems. (admittedly all versions of all installed gems, which gets a little ugly)

Thats what I’ve picked up so far, most of it unfolded fairly rapidly, but if I can pass along the accumulated wisdom of a couple of hours, there you go.

update: a recipe for generating Rails docs with Rdoc