The Bark Blog

Turns out it’s a snap to start developing with C# on Mac OS X. The hard work is already done for you. First, download and install the latest Mono framework binary for OS X.

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!

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.

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 »

Seems like a simple question, and after a bit of digging, it does have a simple answer. The latest Eclipse 3.2 release, after upgrading with Callisto, contains two parallel database components. The first one was developed out of necessity for the Web Tools Platform (WTP), to enable a graphical interface for J2EE development. The second one is a more generic project, the Data Tools Platform (DTP), to create a broad interface for interacting with all sorts of data sources. The WTP component supports database-specific connections, while the DTP supports generic data source connections which happens to include databases.

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.

Continue Reading »

While reading up on Apple’s CoreData technology, I stumbled across one of those wonderful pearls of wisdom that seems so painfully obvious in hindsight, and yet never seems to reveal itself in foresight (especially when one is so focused on learning the low-level details). Funny that I’d never seen it before.

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.

At long last, the officially stable version of Eclipse 3.2 is out. Honestly, I haven’t been using Eclipse much lately. TextMate is so much more flexible, clean, and lightweight…ditto for Ruby on Rails.

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.

Tracking hours for a handful of billable projects can be a lot of scribblin’ and calculatin’. So I was pleased to find the PunchClock time tracker application for PalmOS. It’s missing a few features I’d like, but on the whole it does a great job. The main problem is counting hours for my bi-monthly timesheet. PunchClock can show summaries by day, by week, by two-week, by month, and by year…but not bi-monthly. So I’m still stuck with hand-calculating it myself.
Continue Reading »

If you were to write up a master list of everything you wanted to accomplish in life, how many items would you come up with? Five? Ten? How about forty-three? 43Things is a fun little web site that encourages you to list your 43 top goals and share them with 150-thousand pseudo strangers. Stuff like, “Visit London” and “Save someone’s life”…and let’s not forget “Learn the Napoleon Dynamite dance”. It keeps track of how many other people share your goals and lets you surf from list to list. For example, check out the list for “make a documentary film”.

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.

Computer programming is like any other career: you have to give it a kick in the John Henry every once in awhile to keep it interesting, otherwise you risk boredom, stagnation, or worse. That’s how Java feels lately. It has lost its luster, its challenging crackle. The initial discovery and adventure has been buried in a paradoxical swamp of rote boilerplate coding and dizzying Enterprise Specifications.

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!