March 29, 2007 @ 08:19 AM by nap · 0 comments
With this latest RoR project, we decided for the first time to take a RESTful approach. It's taken me much longer than it should have to come to terms with what that actually meant, but after suffering through the change of mindset, I really do have to say that it feels right. I'm down, you've won me over.
That said, there are always little implementation details that annoy the hell out of you. Little, trivial, stupid things. Things that you know you shouldn't waste precious breath complaining about, things that you annoy your friends about until they ignore you. Things like the use of the damn semi-colon to delimit custom actions for resources in a URI, instead of our old friend the slash.
And then came Changeset 6485, which made everything once again right with the world. Thank gawd that's over. Now I can get back to being productive :-).
March 20, 2007 @ 10:37 AM by nap · 0 comments
If you're in the seacoast New Hampshire area, don't forget to attend tonight's NH Ruby User Group meeting. Click on the link for directions.
Brian DeLacey will be speaking on Security and Cryptography in Ruby on Rails, and there will be some free book giveaways from O Reilly.
March 16, 2007 @ 10:03 AM by nap · 0 comments
If you're new to Rails but not to Ruby, you might be surprised to learn that Rails doesn't use the standard Ruby initialize() method when Model.new is invoked or when a model instance is returned from a find.
If you need to add some initialization code to an ActiveRecord model, use the after_initialze callback instead:
def after_initialize
@thing = SomethingElse.new(self)
@foo = 'bar'
end
March 12, 2007 @ 03:56 PM by nap · 0 comments
We've been hard at work lately, so blog updates have been a little more infrequent than I'd like. But in the meantime, I thought I'd post some books I've been reading. All come highly recommended.
March 04, 2007 @ 07:03 PM by nap · 0 comments
The Ruby Logger is a simple but pretty flexible tool -- hopefully you're already using it. If not, you should be. The default logger message format is pretty barebones though, so I thought I'd take a few minutes to talk about how to make it more useful by monkey patching format_message.
First, make sure to check out TopFunky's Hodel 3000 compliant logger article, posted a couple months ago. Geoffrey's syslog-friendly modification works great when running in production mode. Customized log messages are just as important in the development environment, where we've made our own simple modifications to include the name and line number of the file:
class Logger
def format_message(severity, timestamp, msg, progname)
"#{Kernel.caller[2]}: #{severity.upcase}: #{progname.gsub(/\n/, '').lstrip}\n"
end
end
This little snippet is especially handy if you're using an IDE like IntelliJ that's smart enough to hyperlink the file path. Got an error being logged in users_controller.rb on line 91? Click on the hyperlink and you're there.
It works by accessing the execution stack Array returned by Kernel.caller. caller[0] will refer to the line in Logger#add where format_message is called. caller[1] is most likely going to point to one of the Logger# methods, one of [ debug, info, warn, error, fatal ]. This is the next level down in the stack, where the add method was called from. In most "application-level" code (code we actually write in our application, exterior to the benchmarking messages and such that Rails gives us for free), caller[2] is going to be something in our application code itself, some place that we called logger.info, or logger.error, or whatever, from.
To get this installed in our environment we create a file development_logger.rb, containing the source above. Then, in development.rb (or the initializer block of environment.rb):
require 'development_logger.rb'
This will "monkey patch" the Rails Logger, effectively overriding it's format_message method with our own mojo. Sure, it's not perfect. But it works great for development purposes. A more elegant way to do the same thing would be to subclass Logger and then do something like:
config.logger = DevelopmentLogger.new(config.log_path)
However, this just doesn't seem to have any effect when running script/server, which proceeds as if config.logger is set to the standard (unmodified) Rails Logger. I'm at a bit of a loss as to why. If anyone can explain why setting config.logger seems to have no effect, please (please!) let me know.
March 03, 2007 @ 04:52 PM by nap · 0 comments
Oh, what an IDE snob I've become over the past couple years. I was an advocate of lightweight text editors for dev work for a long time, and was only truly bitten by the "heavyweight" environment bug once I was introduced to IntelliJ, which I can't say enough nice things about. I was obviously pretty psyched when I found out that the Jetbrains team has decided to put some serious effort into a Ruby plugin. It's become very usable in a very short amount of time, and I'm very happy with it, but it's still relatively new and lacking some features.
This new comparison of Ruby / Rails IDEs does a great job summarizing the features in the three leading "heavyweight" IDEs for Ruby / Rails. Definitely check it out if you're in the market for a good IDE. Interestingly, it seems like NetBeans is really giving both IntelliJ and RadRails a real run for their money, being the first of The Big Three to get a reasonable level of code completion working, amongst a plethora of other features.
Although I'll probably download it and take a test drive, I'm pretty committed to IntelliJ at this point, so I'll probably stick it out. But hopefully a little competition will keep things moving along at a good clip :-).
UPDATE: Switched over to NetBeans months ago and loving it! Nice work guys.
