This is a follow up to a previous post where I declared my laptop free of Vista. So to finally answer your question Ryan, its going well.

I've been running Ubuntu Intrepid (8.10) for the past 6 weeks almost every day and haven't had any problems. On the contrary, my laptop is super speedy now, and for whatever reason I swear the wireless works better and faster than it ever did with Vista.

I haven't missed MS Office all that much. I primarily use Outlook in MS Office anyway, and that's not by choice, so like most everyone I use GMail when not at work. When I do need to write an actual document I've found OpenOffice and Google docs more than adequate for my meager needs. In fact Google docs has actually been preferable since some of the docs I've needed to share authorship. I will have to concede that the UI in OpenOffice leaves room for improvement. The icons are hard to see and distinguish from their standard MS Office counter parts.

I've been using Gimp for image editing because it comes preinstalled, but its a little too technical for my needs, and thus difficult to do simple things. Even Photoshop is easier to use IMO. I find Paint.Net superior for my needs so I plan on switching since it will run on Mono. In fact a lot of the winform compatibility testing for Mono has been done using Paint.NET.

I have missed Visual Studio a little, but really what I miss are my ReSharper keyboard shortcuts. I've been primarily using Eclipse since I have been primarily doing Java and Groovy programming in my laptop. Both of these dev environments were quite easy to setup, especially the Android plugin for Eclipse, it works really quite well for editing and debugging. The Grails integration into Eclipse is pretty rough, so I'm looking into buying IntelliJ IDEA since I hear it has really good Grails support.  That and I'm already familiar with the keyboard shortcuts from ReSharper. I use the IDEA shortcuts in Re# which always throws my co-workers off when they try to pair with me.

The command line has been a little tricky to get used to, but has been more consistent between commands than Windows. And the translucent terminal windows are sure purdy. Ray pointed me to a free Ubuntu pocket guide that has helped smooth things over. I now often find myself incorrectly trying to use *nix commands in my DOS prompts at work. Perhaps its time to install Cygwin to iron it the discrepancy?

Not everything has been booz and cigars though. I've had serious issues with Mono, specifically MonoDevelop. The problems of course are my own making. The version of Mono and MonoDevelop packaged with Intrepid isn't quite as new as I would like, so I decided to build my own from the SVN trunk.  That was about 4 weeks ago.  After installing and bulding another 20 prerequisite libraries I finally got MonoDevelop to not only compile and load without crashing, but I also got it to compile and run my first C# app MonoDevelop!

This one goal of getting the latest version of MonoDevelop and Mono running on my Ubuntu box has taught me more about Mono and Linux than anything else I've done.  Despite the hair pulling its been a rewarding journey. I feel like I've earned my first Linux merit badge.

See Dylan, I gots its werking without resorting to a VM and the package manager!

Argh!  I just spent the last hour trying to figure out why I can't configure a Mule UMO (mule-descriptor) using Spring.  I ran into a couple of issues, firstly if you specify a container-context for your bean the life cycle interfaces (like Startable) are ignored.  Next I tried using a mixed Mule-Spring config file, putting the property injection declarations directly in the mule XML file, but I kept getting the following SAX error:

The content of element type "mule-descriptor" must match "(inbound-router?,outbound-router?,response-router?,interceptor*,threading-profile?, pooling-profile?,queue-profile?,exception-strategy?,properties?,bean*)".

Not being that familair with DTDs, what I didn't realize is that the comma between element declarations (as in the error message) means that the sub elements must be declared in the XML file in that order.

Big, fat, DOH!

Apparently the latest log4j alpha release does not contain the new message pattern implementation that I talked about in my previous post.  Currently I'm working on a Logger wrapper that adds this functionality for the time being.

I've been using log4j and log4net as my logging facility for some time now, and haven't thought a lot about it.  I did today though...  I had a junit test with some mock objects that were getting used only if debug logging was enabled.  Do I know the developer running the test has debug logging enabled?  The answer is, the unit test shouldn't care, but how do I get around this in my unit test?

The real issue I was having was that in my class under test I was doing things like log.isDebugEnabled() to avoid a bunch of string concatentation in my logging.  Apparenlty there's a better way to avoid the string concatentation penality and also provides cleaner syntax IMO.

As of log4j version 1.3, there exists a significantly more convenient alternative based on message patterns. Assuming entry is an object, you can write:

l.debug("The new entry is {}.", entry);

After evaluting whether to log or not, and only if the decision is positive, will the logger instace format the message and replace the '{}' pair with the string value of entry. In other words, the paramerized form does not incur the cost of parameter construction in case the log statement is disabled.

Thus, the following two lines will yield the exact same output. However, the second form will perform at least 30 (thirty) times faster in case of a disabled logging statement.

l.debug("The new entry is "+entry+".");
l.debug("The new entry is {}.", entry);

A two argument variant is also availalble. For example, you can write:

l.debug("The new entry is {}. It replaces {}.", entry, oldEntry);

Checked exceptions in Java suck.  The more I use Java, the more respect I have for Anders Hejlsberg.

http://www-128.ibm.com/developerworks/java/library/j-jtp05254.html

"Bruce Eckel, author of Thinking in Java (see Resources), says that after years of using the Java language, he has come to the conclusion that checked exceptions were a mistake -- an experiment that should be declared a failure. Eckel advocates making all exceptions unchecked, and offers the class in Listing 2 as a means for turning checked exceptions into unchecked ones while preserving the ability to catch specific types of exceptions as they are propagated up the stack (see his article in the Resources section for an explanation of how it can be used)."