Alloy Code is thrilled to announce the launch of a new web application. Your Garage Online can help you manage everything from your vehicle's routine maintenance to those major and minor repairs.
Features
Virtual garage to store your cars, including year, color, make, model, license and vehicle identification number data. Searchable repair forms to look up any repair or maintenance record, regardless of when or where it was performed. Comprehensive service history outlines work done by professional shops or in your own back yard.
YourGarageOnline.com was originally conceived as a Rails Day activity, but grew in scope beyond the confines of a single, 24 hour development project. The site was designed, coded and tested over a six week period, as an off-hours personal project and proof of concept application. The finished product serves as a demonstration of the quality and craftsmanship Alloy Code can deliver for our clients.
The site is coded in Ruby on Rails, using RESTful application design and leveraging cutting edge Web 2.0 technology.
So I'm just now able to take a few minutes to reflect on my experiences at the past weekend's Ruby Hoedown in Raleigh, NC. Nathaniel Talbott and Jeremy McAnally did an outstanding job putting together the first in what I hope will be a long series of Ruby-focused events in the southeastern United States.
Rather than recap the entire conference (which has been done elsewhere by more prolific writers than yours truly), I would rather focus on four things I picked up over the 2-day conference.
Stubbing out Ruby's Time class
The pre-conference kicked off with a 2.5 hour workshop run by Bruce Tate, Marcel Molina Jr. and Chad Fowler. Chad, in particular, has been very vocal lately about the importance of developers (and particularly Ruby/Rails developers) giving back to the world. The workshop itself was a fundraising vehicle for the Food Bank of Eastern & Central North Carolina, with 100% of the workshop registration fee being donated. This is an interesting new model, and I'm curious to see where it's going to lead in the future.
So, one of the things I encounter frequently in my classes is needing to test time-specific behavior. Previously, I had been instantiating a plethora of instance variables to check edge cases for Date and Time processing in my tests. My first "a-ha!" moment of the weekend came during Bruce Tate's presentation, when he put up the following code snippet:
Time.stubs(now).returns(groundhog_day_at_noon)
This is going to make a world of difference for me, because now I can create insular, repeatable tests regardless of the time of day at which the test is run.
VOIP has become accessible
Jay Phillips became a new hero of mine when he showed off his Ruby-based Dialplan using the Adhearsion library. After showing us a multi-thousand line Dialplan written in an obscure, telecom dialect, he switched back to his slides and showed us the equivalent code, written in near-human readable Ruby. VOIP has been one of those technologies that I wasn't really paying much attention to, but now my mind is spinning out a whole host of new telephony-enabled website applications faster than I can manage to write them down.
Driving return traffic to a website is a huge deal. Once they sign up for the account, what's the hook that keeps them coming back over and over again? What if Your Garage Online could CALL you to tell you your car was due for service, instead of simply sending you an email? Powerful stuff.
It's time to crack open those dusty C books again
Jared Richardson (who shares my agony of constantly being called "Jerry") gave an energetic talk on using Ruby's C extensions to speed up application performance. I had heard Jared speak back in January at the Rails Edge conference in Reston, VA, on Rails performance and how the search engine Cha-Cha was using Rails in an optimized fashion. This time, in between launching small boxes of candy at unsuspecting audience members, he gave us a great overview of the various methods to include C code to handle low-level, no-magic-required operations directly with our Ruby code. I actually coded along with his his presentation, and wrote more C code in 45 minutes than I'd written in the past 10 years combined.
In particular, RubyInline looks to be an incredibly useful library to write C code directly inside a Ruby class, and have it generated as needed. One caveat, which is particularly visible in the Rails spectrum, is that RubyInline's performance gains are only really visible AFTER the class has been run once and the C code compiled and cached. So, for Rails development, classes which use RubyInline should be housed in #{RAILS_ROOT}/lib, rather than directly in a model or controller, to avoid the code being recompiled on EVERY load.
The Germ of an Idea
This isn't directly something I learned at Ruby Hoedown, but more a general idea that I'd be curious to explore in the future. I've recently picked up Joe Armstrong's Programming Erlang from the Pragmatic Bookshelf. One of the most oft-repeated themes of the conference was concerns about Ruby's performance. If we eschew the idea that everything related to Ruby has to be written in Ruby (and I can thank Jared Richardson for this new mind-set), what if a version of the Ruby VM could be written in Erlang, to execute high performance Ruby in a multi-core environment?
I was sitting next to Brenton Leanhardt on Saturday, who happens to be another member of ErloungeRDU. We talked the idea over for a few minutes, and concluded that while neither of us had any solid idea how to write a Virtual Machine, the idea itself could be worth exploring. This may be a subject I return to in the future...
So I've been wavering for the past couple of days on which Mocking/Stubbing libraries to embrace for my Ruby coding. The Rails core code uses Flexmock, which is a pretty strong endorsement. The OpenID Authentication plugin by David Heinemeier Hansson uses Mocha. The community does tend to look to DHH for cues as to where to follow.
When I saw that the charity Testing Workshop at Ruby Hoedown was going to include information on mocking and stubbing, I became excited. Here was a chance to hear what some industry heavyweights thought about Flexmock vs. Mocha. Bruce Tate managed to discuss Mocking and Stubbing without explicitly naming a preference.
Then Chad & Marcel took the stage with their Test Driven Development approach to recreating Luigi Poker in Ruby. When the mocking question came up, Marcel simply replied (and I'm paraphrasing here), "Jim Weirich write Flexmock. He wrote Rake. He wrote RubyGems. We trust Jim."
Functionally, both libraries support the same operations. It comes down to a question of syntax. But since I've come from a "seat of the pants" PHP background, I don't have extensive mocking experience, so I don't already have a preferred mocking syntax.
Maybe I need to sidestep the question all together. If I switch from Test::Unit to rspec, I can just use rspec's built in mocking and stubbing libraries.
Interestingly, while I was listening to Ezra’s presentation on Merb the first time, I kind of missed the point. The real power and purpose of Merb didn’t start sinking in for me until the second day, when I realized that there was a much bigger audience for a thread-safe, ActionPack-decoupled, performance tuned web framework. The validity of Ezra’s talk was reinforced by others, particularly Bruce Tate, who helped push the point home that Rails was just one stop on the Ruby journey. And, of course, it’s especially timely, considering the current dust-up over Pete’s Swanky Framework…
One of the cool things about starting new applications based on Edge Rails (as opposed to a stable gem version) is that I get access to all the awesome new features right away. Sure, there are a few panic moments when I get hit with unexpected bugs, and I don’t use SVN externals to link to the Rails trunk any more [1], but every now and then, I’m pleasantly surprised by something that I hadn’t previously read about.
I was in the process of adding counter_cache support to an application which had some very deep parent-child relationships, and I needed to generate a migration to add the _count column.
Imagine my surprise when I opened up the newly-created migration file in Textmate, and saw the following:
class AddWidgetsCountToProduct < ActiveRecord::Migration
def self.up
add_column :products, :widgets_count, :type, :null => :no?, :default => :maybe?
end
def self.down
remove_column :products, :widgets_count
end
end
After a little digging, I found this in the Rails Trac: Automatically generate add/remove column commands in specially named migrations. It would seem that Ryan Davis has put together some REGEX magic along with some meta-programming to help out people like me who give their migrations very literal names about what the migration will do.
This is a great little timesaver, but now it has me wondering what other neat features have slipped without my noticing them. It looks like it may be time for me to add the Trac timeline RSS feed to my reader, so I can keep a sharper eye out for these sorts of treats.
[1]: These days, when I start a new project, I freeze a version of edge Rails into the application, that way, I get most of the cutting edge features, and a much lower chance of introducing unexpected trouble every time I type ‘svn up.’ Periodically, I review what’s changed in trunk since I started, and if there’s some gotta-have-it feature, I’ll re-freeze.
