The Sun Sets

So it looks like the Oracle acquisition is finally going to be approved by the EC so the nerd shop that is Sun will be no more. Everyone is kind of waiting to see what will happen with Java and MySQL, but no one really has any idea what will happen. All of this really makes me wish that Java had truly been open sourced because there is no telling what will happen with the JDK.  As for MySQL, I see no way that Oracle doesn’t kill it.  Hopefully Monty’s branch of MySQL, MariaDB, is strong enough to support the current MySQL community if that happens.  I just wish Sun had found a way to stay afloat because that truly would have been the better option in this scenario.

Resolutions

I have done a lot of thinking the past few days and decided I wanted to share a few New Year Resolutions.

1. Make blogging a priority. I have so many ideas that pop into my head, but I never take the time to think them through and write them down. I want to actually start doing that because I feel I have a lot to offer to the community.
2. Be more innovative. This past year I let myself fall into a pattern where I always do the same thing when I am coming up with solutions for projects. I need to challenge myself to step out of my comfort zone.
3. Finally learn Spring and Hibernate. Like many people, I am in a situation where I am maintaining current and legacy apps that use some older technologies. This means I am basically making fixes to Struts/EJB apps that used to be the standard. The world has moved on to Spring and Hibernate and I have been too lazy follow suit. That will change this year.
4. Become more active in local user groups. Last year I started to periodically attend the Java and .NET user group meetings in my area. I enjoyed them, but I didn’t actively participate in the meetings and as soon as I got busy with work I stopped going. I’d like to start attending more and get to the point where I could actually present something at a meeting.

I know these may be simple, but I figure if I start small I might be able to be an overachiever this year. I really want to accomplish these because I know these will help me become a much better software engineer.

A Float is NOT a Currency

Do not use floats when representing currency.This is just asking for trouble.

Anytime you have to deal with floating point representations you can always get unpredictable results. I cannot count the number of times I have seen the "phantom penny" situations where balances are a penny off and you end up spending half a day with your accountant hat on trying to find where the penny went. You look and look and then you realize that somewhere in the code someone used a float inside the calculation. You change the variable type and your penny "magically" appears.

There are many alternatives in the modern programming languages for representing currency and they should be used. If those are not available, you can always go old school and use the int primitive type to represent currency.

Breaking the Law...

Today I read a great post by Phil Haack on the Law of Demeter. I think I had read about it before, but it never sunk in until today. As I read it I had that uneasy feeling you get when you realize you have been unknowingly doing something you are not supposed to do.

The Law of Demeter is pretty simple:

A method of an object should invoke only the methods of the following kinds of objects:
1. itself
2. its parameters
3. any objects it creates/instantiates
4. its direct component objects

Essentially it means that in languages like Java you should not chain together method calls using the dot operator. A great example of this is detailed in the paper, The Paperboy, The Wallet,
and The Law Of Demeter by David Bock. Bock goes through a perfect illustration of why the Law of Demeter should be followed, with an emphasis on scenarios where not using it can cause null pointer exceptions. Sadly, this is the exact case I ran into recently that would have been avoided if I had followed the law.

I had a client interface that needed to get information contained in an object returned from a different method. The needed information was always to be in the first item in a collection, so I immediately used dot operator chaining to get the iterator for the collection and then the first item in the collection.

Item i = (Item)object.methodReturningCollection().iterator().next();

Looking at that code now I see how naive I was being when I wrote it. I never thought of the scenario where the initially called method would return as null . Of course this was caught in testing, but was fixed by simply using a temporary variable and testing for null. This fixes the problem with the null object, but still goes against the law. What I should have done was to create a method in the called object that returned the information I was trying to obtain in the client code. Then the client would not need to know how to retrieve the information as it should be the responsibility of the called object.

I consider myself a fairly decent developer, but you learn something new everyday. I will now be looking out for this when I am doing refactoring. It's amazing to me how much software development is an ongoing learning experience. I love every minute of it...

New Beginnings

I decided to change the name of the blog to be more relevant to me (and to rid myself of the possibility of getting a stink message from the Dilbert folks if this blog ever picks up any traction). I have some crazy things going on at home right now as I am preparing for a new addition to the family that will be here soon, but I will soon be giving this blog the attention that it needs. I am starting with the look and feel and with that I have already created a new feed for this blog:

http://feeds.feedburner.com/MrWillSoftware

In about a month I am going to turn off the original feedburner feed, so be sure to update any RSS readers you are using.