This blog from Brian Ray gives a nice Hello World example. The gist is:

1. Compile with “/Library/Frameworks/Mono.framework/Commands/mcs hello.cs”
2. Run with “/Library/Frameworks/Mono.framework/Commands/mono hello.exe”

TextMate fans can have it even easier. This close-to-anonymous C# TextMate bundle gives us the basics, including syntax coloring and some handy tab-completions. Install it by unzipping it and opening the bundle file. TextMate will install it for you.

To add a Run command, open the TextMate Bundle Editor, select the crisp new C# bundle, and add a New Command to it.

EXE_FILE=`echo $TM_FILEPATH | sed -e 's/\..*$//'`.exe
/Library/Frameworks/Mono.framework/Commands/mcs $TM_FILEPATH
/Library/Frameworks/Mono.framework/Commands/mono $EXE_FILE

Then, write your code and hit Cmd-R to compile and run the current source file. Snap!

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…

Another handy hoop trick is to provide a command-line switch for STDOUT logging. To send output to a file, invoke your tests as normal; to send output to the console, set LOG_STDOUT in your environment to anything, e.g. LOG_STDOUT=yes ruby test/my_test.rb.

TESTLOG = File.expandpath(File.dirname(FILE) + “/test.log”) ActiveRecord::Base.logger = ENV["LOGSTDOUT"] ? Logger.new(STDOUT) : Logger.new(TESTLOG)

Of course, there’s always the lower level logging properties. To turn off the special color markup (who on earth made that the default?!?):

ActiveRecord::Base.colorize_logging = false

To filter the logging output by severity level:

ActiveRecord::Base.logger.level = Logger::INFO

And finally, this line tags the log file (or console output) with a friendly banner whenever the test_helper.rb file is loaded, which amounts to every time you run the tests:

ActiveRecord::Base.logger.info( “#{”=”25} RUNNING UNIT TESTS #{”=”25}\n\t\t\t#{Time.now.to_s}\n#{”=”*70}”)

It looks like this:

========================= RUNNING UNIT TESTS =========================

Mon Feb 12 10:39:50 CST 2007

Have fun, and stay tuned for the next Hoop o’ fire.

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.

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.

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….

(continued)

To get us started, let’s generate stubs for our imaginary SkinnyFeet plugin:

script/generate plugin skinnyfeet create vendor/plugins/skinnyfeet/lib create vendor/plugins/skinnyfeet/tasks create vendor/plugins/skinnyfeet/test create vendor/plugins/skinnyfeet/README create vendor/plugins/skinnyfeet/Rakefile create vendor/plugins/skinnyfeet/init.rb create vendor/plugins/skinnyfeet/install.rb create vendor/plugins/skinnyfeet/uninstall.rb create vendor/plugins/skinnyfeet/lib/skinnyfeet.rb create vendor/plugins/skinnyfeet/tasks/skinnyfeettasks.rake create vendor/plugins/skinnyfeet/test/skinnyfeet_test.rb

The generated test stub is boring as rocks, and completely devoid of Rails-ness:

vendor/plugins/skinnyfeet/test/skinnyfeet_test.rb

require ‘test/unit’

class SkinnyFeetTest < Test::Unit::TestCase

Replace this with your real tests.

def testthisplugin flunk end end

In a test file generated by Rails for a model class, the ${RAILS_ROOT}/test/test_helper.rb file pulls in the Rails environment. In theory, we could reference that application helper file from the plugin, but that’s a bit ugly and dangerous. Our fancy plugin might someday reside in random applications. We have no idea what dastardly hacks they’ve done to their own test_helper.rb file. We certainly don’t want the application test suite to break our plugin test suite.

Let’s be safe and create our own test helper class inside the plugin. The minimum we need is the first three lines of the default generated test_helper.rb file. Note that we have to extend the path to environment.rb by three levels since we’re nested deep in the vendor directory.

vendor/plugins/skinnyfeet/test/testhelper.rb

ENV["RAILSENV"] = “test” require File.expandpath(File.join(File.dirname(FILE), ‘../../../../config/environment’)) require ‘test_help’

Then in each database-hammering plugin test file, replace the require 'test/unit' statement at the top with:

vendor/plugins/skinnyfeet/test/whichevertest.rb

require File.dirname(FILE) + ‘/test_helper’

With this simple change, our plugin gains access to everything we’ve been missing: the application’s database.yml file, the fixtures directory, and the auto-loading feature. We can now start using classes we’ve implemented in our plugin lib directory without bothering with require statements (as long as we follow the proper Rails file-naming conventions).

Also, the fixtures directive should work to load data fixtures into the database for testing — except it’ll grab those fixture files from the default application directory at ${RAILS_ROOT}/test/fixtures/. Instead, we want to create our own fixtures directory inside our plugin, at vendor/plugin/skinny_feet/test/fixtures. To override the default fixture directory (and control other fixture settings), add this to the bottom of the plugin’s test_helper.rb file:

vendor/plugins/skinnyfeet/test/testhelper.rb

class Test::Unit::TestCase self.usetransactionalfixtures = true self.useinstantiatedfixtures = false self.fixturepath = File.expandpath(File.dirname(FILE) + “/fixtures”) end

The disadvantage to loading up Rails for each test suite is that it introduces a significant performance hit. You won’t want to do this for tests that don’t interact with the database.

In its third season, the show has morphed into a stinging allegorical critique of America’s three-year occupation of Iraq. The trouble started at the end of the second season, when humanity briefly escaped the Cylons and settled down on the tiny planet of New Caprica. The Cylons soon returned and quickly conquered the defenseless humans. But instead of slaughtering everyone, the Cylons decided to take a more enlightened path by “benevolently occupying” the planet and imposing their preferred way of life by gunpoint. The humans were predictably not enthused about their allegedly altruistic rulers, and they immediately launched an insurgency against them using improvised explosive devices and suicide bombers.

It’s so frustrating when you can’t tell the good guys from the bad guys.

Since April, operating almost entirely under the radar, the task force has spawned four working groups, recruiting scores of U.S. experts on Iraq and the Middle East to look at military and security issues, Iraqi politics, reconstruction, and the regional and strategic environment surrounding the war.

Although it’s nice to see some serious effort to design a bipartisan policy for Iraq — and some would say that Baker is one of the few heavyweights with enough leverage to change the President’s mind — it’s still a shame that the process is being so methodically buried in secrecy:

It’s hard to know what the commission is really up to because its inner workings are nearly as secretive as those of the White House. Baker has imposed an ironclad gag order on all of its participants. … “[Baker is] very secretive, he keeps his distance, and he compartmentalizes everything, which is not a bad way to organize a political conspiracy,” says another member of one of the working groups.

Furthermore, although Baker is claiming to avoid politicizing the effort…

In any case, the Iraq Study Group won’t issue its report until some time early in 2007. In a recent speech, according to a member of the task force, Baker said that to do something before the November 2006 elections would inevitably politicize the report, something that Baker desperately wants to avoid.

…his deeper and ultimate goals seem to be protecting the 2008 elections.

…if the Democrats win back one or both houses of Congress in November, they would unleash a series of investigative hearings on Iraq, the war on terrorism, and civil liberties that could fatally weaken the administration and remove the last props of political support for the war, setting the stage for a potential Republican electoral disaster in 2008.

The Vanity Fair article goes into great detail about the ongoing NEADS chatter throughout the 100 minutes of the actual attack. The article provides written and audio transcripts of the critical parts, and portrays a situation much different than was commonly reported:

For the NEADS crew, 9/11 was not a story of four hijacked airplanes, but one of a heated chase after more than a dozen potential hijackings—some real, some phantom—that emerged from the turbulence of misinformation that spiked in the first 100 minutes of the attack and continued well into the afternoon and evening.

Although American Airlines flight 11 was later identified as the first plane to hit, the airline conservatively refused to admit it:

“When we phoned United [after the second tower was hit], they confirmed that United 175 was down, and I think they confirmed that within two or three minutes,” Scoggins, the go-to guy at Boston Center for all things military, later told me. “With American Airlines, we could never confirm if it was down or not, so that left doubt in our minds.” … The problem, Scoggins told me later, was that American Airlines refused to confirm for several hours that its plane had hit the tower. This lack of confirmation caused uncertainty that would be compounded in a very big way as the attack continued. (Though airlines have their own means of monitoring the location of their planes and communicating with their pilots, they routinely go into information lockdown in a crisis.)

As a result, NEADS’ remaining two fighter jets were scrambled to chase after this phantom flight 11. Coincidentally, seconds later a third highjacking was revealed (United 93), followed twelve minutes later by a fourth (American 77, which ultimately hit the Pentagon). Meanwhile, NEADS was busy reacting to the false intelligence that American 11 is still on the prowl. The information chaos was worse because NEADS was relying on antique green-blip radar, which was completely unable to locate American 11 earlier when it was first reported highjacked. Also, vague, anachronistic rules about handling modern highjacking cases slowed down the flow of crucial details:

A former senior executive at the F.A.A., speaking to me on the condition that I not identify him by name, tried to explain. “Our whole procedures prior to 9/11 were that you turned everything [regarding a hijacking] over to the F.B.I.,” he said, reiterating that hijackers had never actually flown airplanes; it was expected that they’d land and make demands. “There were absolutely no shootdown protocols at all. The F.A.A. had nothing to do with whether they were going to shoot anybody down. We had no protocols or rules of engagement.”

This info slowdown led to a disturbingly slow reaction from the Administration:

President Bush would finally grant commanders the authority to give that order at 10:18, which —- though no one knew it at the time -— was 15 minutes after the attack was over.

Let’s hope things have gotten better over the past half-decade. Until then, we can amuse ourselves with little green men and outlandish, yet hard-to-dismiss conspiracy theories.