If you’ve waited until now before upgrading to Ruby on Rails 2.0 now you may be in for a little surprise.  As of version 2.02 the default database in Rails is SQLite, arguably because there is no need to for grants or the creation of tables, meaning a simpler setup for n00bs.  If you still want to use MySQL (or any other database for that matter) you have to provide the following:

rails -d mysql appname

SQLite3 and the necessary driver gems come preinstalled on OS X Leopard, but if you don’t have the Ruby bindings installed it’s as simple as:

sudo gem install sqlite3-ruby

You can always change which db your Rails app is using by changing your config/database.yml.

So this Tuesday I had the honour of presenting at Montreal on Rails 2, where I demoed the Acts As Authenticated and Role Requirement plugins.

I think Marc Andre Cournoyer’s review impressed me the most, mainly that “…[it] is an exploit to be able to code a live app in front of a crowd like this.“ It’s a testament to the power of Rails and I’m just glad the Roles portion didn’t bomb the way it had during my rehearsals at home.

I was especially impressed by Chris Scott’s demo of the Ext JS framework. Sorry Darin, but there are some pretty nice features in Ext that will make me want to take a closer look. Terje Tjervaag’s demo of Firebug was convincing enough to make me wonder why I hadn’t already installed it yet. Used it at work today to great effect. You can read more reviews of the night here and here, while photos have been posted on Flickr and videos might pop up on Youtube.

I’m happy to announce that I will be speaking about user authentication at the next Montreal on Rails meetup, scheduled for Tuesday the 4th of September at the McGill MAASS Chemistry building, room 328. The show starts at 18h45 and I think I’ll be the first to present, so come early.

Although user authentication may sound like an advanced topic, it will be aimed mostly at the novice Rails developer as a showcase of how easy it can be to implement advanced features such as user security and roles in a Rails application. I hope to touch on a few items including the excellent Acts As Authenticated, roles and salting. If there’s anything in particular you would like to see, drop me an email.

The integrators at work had a problem recently with a shell script that generates SQL deployment and rollback scripts on the fly based on SQL patches submitted by developers. The problem was that sometimes the name of an object would include a “(” at the end of it (e.g. “FN_RESET(” instead of “FN_RESET“). Here’s a quick solution I whipped up for them:

#if $TEST_END doesn't become an empty string,
#then OBJECT_NAME ends with "(" so we strip it
TEST_END=$(echo "$OBJ_NAME" | grep \($)
[ -z "$TEST_END" ] || OBJ_NAME=$(echo ${OBJ_NAME%\(})
echo “OBJ_NAME is : $OBJ_NAME”

The sharp eye amongst you will notice that this works for FOO( but not for FOO(NANY. If you want to strip everything after the ( and including the ( the you want this:

TEST_END=$(echo "$OBJ_NAME" | grep \()
[ -z "$TEST_END" ] || OBJ_NAME=$(echo “$OBJ_NAME” | awk ‘{split($0,a,”(”);print a[1]}’)
echo “OBJ_NAME is : $OBJ_NAME”

Notice how the grep no longer uses the $ anchor to match a ( at the end of the line? Now if $TEST_END isn’t empty, then we have a ( in our string, so we split on that and return everything to the left (first element in the a[]).

Last night’s Montreal on Rails meetup (their first ever) was a large step up from the Commodore 64 disk swaps of my youth, but probably a lot more significant as far as self improvement goes. A good 30-35 people showed up and the two presentations given were fantastic.

The first presentation topic was improving tests, it was given by Marc Cournoyer and included a hilarious introduction to a somewhat advanced topic. The next presentation was given by Carl Mercier, who introduced the extremely useful HAML, which appears to cut the code in your views by half by generating HTML using a simplified indentation scoped ruby based markup. Very simple and very powerful stuff and I’ll be trying it shortly.

Overall the people who attended the meetup were great and I look forward to the next one. It’s so good to see a vibrant developer scene in Montreal.

Here are some of the links that I bookmarked for the month of July. I highly recommend the 101 meals at the bottom of this list.

Development

• a free service oriented architecture diagram.
• Some simple SQL rules to live by
• Agile Bookshelf: Ten must read books
• Keep your data in the tables!
• Best programmer quotes
• Easing Configuration
• Java Image Servlet example

Web

• Aide RSS: RSS with artificial intelligence
• 10 Things you may not know about the Web Developer Toolbar
• Photoshop: How to do a mosaic effect
• Ten articles all bloggers should read at least once
• The best 80 Photoshop text effects on the web

Leisure

• Top ten under $200 hotels in Europe

Self improvement

• Tact Filters
• Good example of actions to put in a CV
• Why should I hire you? and other favorite interview questions

Food

• 101 Summer Express Meals in 10 minutes or less
• 101 Supper Express Vegan Meals in 10 minutes or less.

I’m in the process of migrating some old Java 1.3 code to Java 6 and I really didn’t like the way exceptions were handled in the code. Before rewriting things I did some research as to what are considered the “Best Practices” when it comes to Java exception handling. Although On Java’s Best Practices for Exception Handling appears to be the most popular article on the subject, I found the most useful information to come from Exception Handling: Common Problems and Best Practices with Java 1.4 (pdf) by Dr. Andreas Muller and Geoffrey Simmons, both of whom work for the German Sun Java Center.

A summary of Mueller and Simmons’ mains points would be:

• Empty catch blocks are bad.
• Meaningless blanket throws clauses are bad. (e.g. catch(FooException e){ throw new BahException(e.getMessage());} )
• Losing stack information is bad, so use exception chaining.
• Exceptions that signal an untreatable situation should be unchecked.
• Checked exceptions signal an exception situation that might be treatable.
• Log an exception to the logfile exactly once.
• The right time to log an exception in Java is the latest possible.
• By chaining exceptions you gain information content while they travel up the call stack.
• Programming exceptions should contain as much information about the state of the system as is available (dump state of objects, session, response, request, etc.)

An immediate benefit from the article was learning how throwing unchecked exceptions for exceptions that are untreatable (such as an SQLException) can help get you out of the antipattern where you need to include a dozen types of exceptions in your method signature. It’s a bit controversial with some of my colleagues but I really think it cuts down on some of the burden that managing exceptions can create, and allows you to consolidate and deal with the exceptions at a more appropriate place.