The Bark Blog

WFMU presents The Giant Stringed Instruments of The Yi People. If you thought Clamtar was intimidating, behold The Son of Clamtar:

Many people enjoy the sideshow carnival cliche of mammals jumping through flaming hoops. It’s quick, it’s fun, and it invokes a harmless façade of danger. In that vein, this new series of hoop-vaulting articles will push against the bumper-guards of the average Ruby on Rails playground, exploring faux danger and hopefully providing some light entertainment.

This first batch of tips fiddles with unit test logging by tweaking the test/unit/test_helper.rb file. By default, when you run rake test:units from the top level directory of your Rails application, all logging output goes into log/test.log. If that’s not good enough, if you want a different name or location for your test output, the change is easy. Add this to the end of test_helper.rb:

TESTLOG = File.expandpath(”#{RAILSROOT}/log/flamey-test.log”) ActiveRecord::Base.logger = Logger.new(TESTLOG)

If you’re writing a standalone ActiveRecord application outside of a Rails environment, you’ll have to explicitly create and assign a logger yourself. The easiest solution is to pass Logger.new a simple file name.

ActiveRecord::Base.logger = Logger.new(”test.log”)

Unfortunately this will drop the log file into whichever relative directory you run the tests from. What you probably want is to anchor it to the test_helper.rb file (which you’ll also have to create yourself in a standalone application).

TESTLOG = File.expand_path(File.dirname(FILE) + “/test.log”) ActiveRecord::Base.logger = Logger.new(TESTLOG)

A slightly better place is in a log directory, sibling to the test directory:

TESTLOG = File.expand_path(File.dirname(FILE) + “/../log/test.log”) ActiveRecord::Base.logger = Logger.new(TESTLOG)

More tips on the flip side…

Continue Reading »

Lately, five letters have begun to rattle around the Ruby on Rails universe with increasing frequency: nginx (allegedly pronounced “engine x”). This new toy is a reverse proxy HTTP server that can serve as a high-performance, lightweight replacement for Apache. In particular, it works well as a load-balancing front end for a Mongrel cluster running a Ruby on Rails application.

According to one elated nginx user:

The only solution I know of that’s extremely high performance that offers all of the features that you want is Nginx… I currently have Nginx doing reverse proxy of over tens of millions of HTTP requests per day (thats a few hundred per second) on a single server. At peak load it uses about 15MB RAM and 10% CPU on my particular configuration (FreeBSD 6).

Under the same kind of load, Apache falls over (after using 1000 or so processes and god knows how much RAM), Pound falls over (too many threads, and using 400MB+ of RAM for all the thread stacks), and Lighty leaks more than 20MB per hour (and uses more CPU, but not significantly more).

It does seem like a lean, powerful solution for sites that control their entire technology stack; of course, it doesn’t help those of us on shared hosting providers like Dreamhost who must wait for the admins to carefully and excruciatingly evaluate each new service they roll out.

A quick Googlry turns up quite a few articles on nginx:

• “Nginx, my new favorite front end for mongrel cluster” by Ezra Zygmuntowicz

• “High-Performance Ruby On Rails Setups Test: mongrel vs lighttpd vs nginx” and many other nginx articles by Alexey N. Kovyrin

• “(Rails Deployment – Apache – Lighttpd) + Nginx & Mongrel Cluster” by LabRat

• “Time For A Grown-Up Server: Rails, Mongrel, Apache, Capistrano and You” by Coda Hale

• “nginx: the front end solution for rails deployment?” by Dominic Damian

If you’re able, I’d highly recommend checking it out. On the other hand, if you’re one of the poor, lonely stack-impaired minions like myself, maybe you can wring a few drops of vicariousness from the gushy victory stories above.

John Oliver is one of the funniest “correspondents” on The Daily Show, which is in turn one of the funniest shows on television. Last week, Jon Stewart was fretting that no matter what we do, the Bush Administration still claims we’re emboldening the enemy. Questioning the war policies? Emboldening the enemy. Sending a mixed message? Emboldening the enemy.

Thankfully, John Oliver was there to explain what the behoovus is engoing on:

Well, this is an odd, unconventional war. This isn’t like World War II where there were “winners” and “losers”. It’s a new kind of war where enemies can either be emboldened or beweakened. So we have to enscare them to the point where they rebecave themselves. We must disimagine the very figment of misunsuccessiveness. That is what we have to bedo.

Apparently the problem is that too few of us are fluent lectors of Newspeak.

Extending your Ruby on Rails application with a plugin is very simple: run the code generator to create the template code, then drizzle your yummy application and test code into the supplied directories. Rails automatically adds all plugin lib directories to the $LOAD_PATH. Add a class to your plugin and your Rails application can start using it immediately. You don’t even need a require statement. This is the same mechanism that auto-loads model classes in the app/models directory.

This works nicely for the plugin’s lib directory, but what about its test directory? Unfortunately, by default plugin tests are pretty bland. They use the plain unit test suite supplied by Ruby, and not any of the extended Rails test framework. This will leave our plugin’s test classes with no access to fixtures, database.yml configuration, or any of those nice class auto-loading features.

Fear not! It’s easy to wire the full Rails model testing framework into any plugin. Details below….

Continue Reading »