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.
Breakpointer is great. Took me a little while to figure out how it worked as I was expect something like
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"
breakpoint "going into crashing_function" crashing_function(var1, var2, var3)
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
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
run, etc. When you’re tired of the view from this breakpoint, and are ready to be whisked away to the next one, type
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)
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