Posted by Rick DeNatale
Mon, 02 Jul 2007 15:36:00 GMT
I’m working on a team rails project and adding some timezone support. I installed the tzinfo gem and, since I want to make sure that it gets to the production server, I used the freeze_other_gems rake task, which I’d found by doing a rake -T.
I’d never used it before so I googled to find some documentation.
It wasn’t exactly clear, but it turns out that you need to edit the fourth line of the lib/tasks/gems.rake file
libraries = %w(progressbar tzinfo)
The progressbar gem was already there so I added tzinfo.
Then I invoked:
Only to get the error:
rake aborted! undefined method `version’ for nil:NilClass
This problem had been seen by others and commented on. I guessed that the problem was not with my newly added gem, but the progressbar gem which was already listed, apparently by one of the other developers.
The Quick Fix
The first step was to determine the version of the progressbar gem. I looked at lib where it had been installed, and found that it was version 0.3. I then installed the gem, and reran the freeze_other_gems rake task.
Success
Posted in rails | Tags gems, rails, rake | no comments | no trackbacks
Posted by Rick DeNatale
Fri, 22 Jun 2007 14:29:00 GMT
Recently on gluttonous, Kevin Clark announced that
Powerset is going to launch their front-end on Ruby. It seems that they were already pre-disposed to a major ruby comitment having built a sizable Ruby talent pool for their internal applications.
Prior to making the final decision to go all out with ruby for their front-end launch, the did some due diligence which included investigating the facts behind the recent furore caused by an interview with one of Twitter’s developers.
So they went to
Twitter’s lead developer, Blaine Cook to get the straight dope.
Quoting Kevin:
The simple fact is that Ruby wasn’t the source of Twitter’s woes. As it often happens with rapidly growing sites, they ran into architectural problems. Some design decisions don’t hurt until they reach a massive scale and at that point you have to rethink your approach. In an email he writes:
For us, it’s really about scaling horizontally – to that end, Rails and Ruby haven’t been stumbling blocks, compared to any other language or framework. The performance boosts associated with a “faster” language would give us a 10-20% improvement, but thanks to architectural changes that Ruby and Rails happily accommodated, Twitter is 10000% faster than it was in January
That last sounds quite true and corresponds to my experiences in the past with Smalltalk. I used to tell IBM customers that almost all performance comes not from the language but from application design, and that using a dynamic language which allowed the application to be developed in what’s now called an agile development process allows major performance gains through refining, refactoring, and retuning the system as both business and performance requirements get uncovered/discovered.
That’s as least as true of Ruby as it was of Smalltalk 15-20 years ago.
Posted in ruby, war_stories, best_practices | Tags evangelism, performance, rails | no comments | no trackbacks
