I’ve finally taken time to migrate all my public code bases over to github. Effective immediately, the subversion repository is deprecated and will likely disappear soon.
Links to everything can be found on the projects page.
0 commentsOnce again it has become time to refresh the site design. Looking back, it appears the last site refresh was in July of 2007—I’m not sure if 5 years on the same design demonstrates longevity and consistency, or if it just means I’m horribly overdue.
Regardless, now everything is nice and shiny. One of the goals of the new design was to do my best to leverage HTML5 and CSS3, including new HTML5 tags and use of many of the newer CSS features. As a consequence, the only image file is the background. Everything else is CSS effects along with a couple CSS fonts.
I also used the refresh as an excuse to experiment with responsive design. I haven’t had a chance to test a wide array of small-screen devices yet, but on the ones I have access to (various iDevices), the site is usable. I’d love to hear your experience, good or bad, on any kind of smaller-screen device.
Other changes include numerous updates to the software stack (Rails 3.2, etc.), better syntax highlighting (now with line numbers!), and improved (in theory) spam filtering.
0 commentsIt’s clearly time that I catch up with the world around me. It’s curious how much can pass you by while you’re consumed with other priorities. Now that some of those have passed, I’m rediscovering several things that got pushed aside.
Among them is hopefully writing at least a little more often here. Apparently, that won’t be a difficult bar to jump over—it’s been 2 1/2 years since my last post. Ack!
Apart from writing here, the process of catching up looks like it will include a bunch of software upgrades (Rails 3 a part of that), a new design for here, and migrating a bunch of stuff to git.
Stay tuned.
0 commentsThis is part 5 of my ongoing series on Ruby on Rails performance. Today’s topic is a bit more complicated that some of the previous parts.
I’m going to explore an alternative to using the method 1ActiveRecord::Base.to_xml.
Before I get into that, I probably should explain why. After all, 1ActiveRecord::Base.to_xml is really easy to use. The alternative I’m going to demonstrate isn’t very easy to use.
The problem is that 1ActiveRecord::Base.to_xml can be really slow—even after making the optimizations I’ve explored in the previous parts to this series. For fairly simple AR objects, this won’t be a problem. However, when you have a deep object hierarchy and need substantial portions of it to be included in the XML response, it becomes a problem.
One instance where I encountered this was a nested has_many tree. That is, the object tree looks something like this:
The XML output is often 100k or more, and representing a few dozen or more total objects.
0 commentsThis is a quick one, but if your Rails app uses ActiveResource as a client, it can be really useful to know something about each ARes request.
ActiveResource actually has some built-in logging of what requests are made, the response size, and how long it took. But, it’s not enabled. The good news is, it’s easy to turn it on.
I like to make ActiveResource’s logging match the rest of my environment — that is, it will log when in development mode and not in production mode.
Add the following to a file in 1config/initializers/:
1ActiveResource::Base.logger = ActionController::Base.logger
Obviously, if you want it to go to a different log file, or function at a different log level, you can create a new Logger instance instead.
The logging output will look something like this:
1GET http://api-server.com/resources.xml
2--> 200 OK (1526 69ms)