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.

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.

The problem is that WTP needed to interact with databases before DTP was available, so its database interface mirrors the functionality in DTP. Although plans exist to merge the two, the timeline for that drags into next year, targeting the yet-to-be-started Eclipse 3.3.

So we’re stuck with both database interfaces, which don’t interact with each other, and don’t share JDBC connection setups. To summarize, DTP offers the more generic Data Source Explorer view. The BIRT reporting tool seems to be the main user of DTP. You can set up a database connection in Data Source Explorer, but it won’t be accessible to any J2EE development you’re doing with the WTP tools.

With WTP, which you need for JSP, JSF, and EJB development, you’ll need to use the Database Explorer view. For example, to set up a MySQL connection, you would open the Database Explorer view, right-click (or Ctrl-click on Mac) the Connections icon and choose New Connection; then select a MySQL database manager on the left. Since no MySQL presets exist yet, go with a JDBC Driver of “Other”. Fill in your MySQL database name, “com.mysql.jdbc.Driver” for the JDBC driver class, point Class location to your mysql-connector-java-3.1.x-bin.jar file, and set the Connection URL to something like “jdbc:mysql://localhost:3306/mydb”. With that, your database connection should be available to all your WTP tools, like JSF, Dali, and so on.

In a later post, I’ll dive into the Dali JPA plugin.

In a nutshell, three of Apple’s marquee developer products correspond directly the three components of MVC:

• The Model is the CoreData framework
• The View is Interface Builder
• The Controller is the Cocoa Bindings framework

And of course, we need a pretty picture, from the CoreData page above:

Kind of a silly epiphany, yes, but very useful for keeping things straight while sifting through the reams and reams of online developer docs, frameworks, IDE features, and APIs. Especially for those of us who are just starting to soak their feet in Mac development.

On the other hand, as soon as you start digging into Java and J2EE, you hit a maelstrom of boilerplate java code and XML config files — all the cumbersome repetition that Rails works hard to minimize. In this department, Eclipse does a good job. It offers top notch code completion (which TextMate as a more general purpose text editor isn’t equipped to handle), graphical editors and a huge selection of plugins.

Finally with this release, the J2EE platform is looking healthy and strong, including brand new support for JavaServer Faces and EJB 3.0-style persistence code generation with the new Dali. The Callisto Project is a worthy effort to gather 10 big Eclipse projects together, test them as a unit, and release them in a single rollout. Eclipse also has a nice upgrade feature that lets you pull the entire Callisto plugin codebase with a few easy clicks. Well done guys!

While Rails will always be more sane and fun than J2EE web development, at least JSF and Facelets is a step in the right direction, removing a lot of the complexity and gritty low-level hackery typically required for Java web sites.

A while back, I threw something together in Java, using the JPilot DB library to parse Palm PRC database files. It was a bit clunky, even at 550 lines of source code (not including JPilot), but it mostly did the job.

Never really satisfied with the Java hack, but lacking the time to improve it, I just let it sit, using it every couple weeks, then not at all. Finally, last night, I sat down with the Palm online docs plus a tech note I found long ago, to see what it would be like to do it as a Ruby script.

Lo and behold, it only took me about 60 lines of Ruby code (only 30 of which is parsing code), from start to finish. I had to fiddle with the pack/unpack specs a bit, but things fell together quickly. I was impressed by how intuitive Ruby scripting was. It was easy to group results by year or by year-and-month, etc., by using a Time object as the hash key (see byyear() and bymonth() methods below). Here’s the source code for the parser…so far.

class Record
attr_accessor :start, :stop
def initialize(start, stop)
@start, @stop = start, stop
end

def to_s
"#{@start} - #{@stop}"
end
end

class TimeDb
attr_accessor :record_count, :records
def initialize(filename)
@contents = File.read(filename)
parse
end

def parse
@hdr, @body = @contents.unpack("a78 a*")
@hdrparts = @hdr.unpack("Z32 nn A4 A4 A4 III A4 A4 II n ")
@record_count = @hdrparts.last

@records = []
for i in 0...@record_count
offset, flags, id = @body[(i * 8)...(i * 8 + 8)].unpack("I c a3")
next if flags == -64

record = @contents[offset..(offset + 14)]
date_time, hour, minute, time_spent = record.unpack("xxx a3 x CC x I")

date_time = date_time.insert(0, 0.chr).unpack("I").first
month = (date_time & 0xf00000) >> 20
day = (date_time & 0xf8000) >> 15
year = (date_time & 0x7fff)

t1 = Time.gm(year, month, day, hour, minute)
t2 = t1 + time_spent
@records < < Record.new(t1, t2)
end
end

def by_year
map = {}
@records.each do |record|
key = Time.gm record.start.year
(map[key] ||= []) << record
end
map
end

def by_month
map = {}
@records.each do |record|
key = Time.gm record.start.year, record.start.month
(map[key] ||= []) << record
end
map
end

end

And here's a sample of code to list all entries by month.

db = TimeDb.new("PC_MyProject.pdb")

map = db.by_month
map.keys.sort.each do |key|
puts "  #{key.strftime("%Y/%m/%d")}n #{map[key].inspect}nn"
end

I'm very pleased with the results. The next step is to write a little Rails app to provide an interactive browser for my PunchClock databases. And after that, tools for creating SuperMemo databases. Fun fun fun....

I haven’t set up an account yet, but I do like the idea. The site also has a nice Cool Factor, since it’s implemented in my new favorite programming language Ruby using my new favorite web framework Ruby on Rails.

Time for a change of pace.

My first breath of fresh life recently was Apple’s Cocoa Toolkit for developing native Mac OS X applications, using the Objective-C programming language. So far so good, but it’s a huge code library with tons of great tools, and it only works on modern Apple systems. Great for my hobby projects, but it doesn’t really help me at my day job.

Enter the Ruby Programming Language, a fully object-oriented scripting language with solid cross platform support (OS X, Windows, UNIX) and a wealth of built-in libraries. I’ve just scratched the surface, but it does seem to light up that special spark that I’ve been missing from Java lately. A change of pace will really help fire me up again at work, and shake off those creeping doldrums. Let’s hope!