Tuesday, February 24, 2009

Burk In Books: 97 Things Every Software Architect Should Know



There's a new book available from O'Reilly titled "97 Things Every Software Architect Should Know: Collective Wisdom from the Experts" and though I'm very excited about it, I won't be reviewing it here. Actually, I'd like to post a review, but you probably would not trust it because I'm one of the "experts" who's "wisdom" was collected for the book.

The book is primarily a series of short articles on various topics that software architects deal with in the real world. All of the articles were contributed under the Creative Commons, Attribution 3, license - which means it's essentially an open source book. In fact, the 97 articles in the book are available online for free at the 97 Things web site. O'Reilly also has a preview available on their website so you can see the cover and what the articles look like in the actual book - unfortunately, my articles are toward the end of the book and the preview stops much earlier.

I recommend going to the web site and reading an article or three. If you like it consider buying a copy of the book. I say that not because I get royalties - I don't. Nor did I get paid for the initial writing. I'm suggesting you buy one or more copies because I want the book to succeed so O'Reilly will be encouraged to do more books in the same style; collecting contributions from community members who have something interesting to say and making them available.

The whole process of trying to come up with useful bits of information and explain them in an interesting way - before somebody else beat you to it was fun and challenging and I'd like to do it again. So please go take a look then come back and let me know what you think of it.

{Note to self: Come up with a good sign off line.} <- Yes I meant to leave that there. It's motivational. Burk

Windows XP running slower than usual

If you've noticed that your XP box isn't as perky as it usually is, this post may be just what you need.

This morning I was running a build that normally takes about seven minutes, but when I checked on it - expecting to see everything had compiled properly - I found it had hardly begun. What the...? So I pulled up the Windows Task Manager, I saw that instead of using 20 to 50% of the CPU, the java.exe (we use ant so it shows up as java.exe and not javac.exe) process was putting along at single digits with an occasional sprint up to 16%.

Looking at the list of running Processes, I noticed a few I didn't recognize. Since this is a company box, I wasn't too surprised but I figured I'd do a little research on what was out there. As it turns out, I hit a homer with the first thing I looked up - a little beastie named cidaemon.exe.

Turns out it's used by an Indexing service from our friends at Microsoft and it had somehow gotten turned on. When I Googled the name I found this page on Microsoft's Help and Support site which told me how to turn it off. I followed the instructions and suddenly java.exe was back to it's normal (relatively) speedy self.

If you're seeing a similar problem on your XP box, bring up the Task Manager, click on the Processes tab and look for something called "cidaemon.exe" under the Image Name column. Note: If the items aren't in alphabetical order you can click on the Image Names label and they will be.

If cidaemon.exe is out there don't just click the End Process button to kill it, or the next time you reboot it will be back. Instead follow these instructions from Microsoft and you'll be set.

That's all for now, I've got some code to write.

Friday, February 13, 2009

I'm speaking at ITARC 2009!

Just letting you know that I am speaking at this year's ITARC 2009 in Atlanta, GA which is a software conference put on by the International Association of Software Architects also known as IASA. For more information about the IASA, take a look at their website.

I'll be speaking about the importance of User Experience design, why we, as architects, need to be familiar with it, and how to improve the user experience of the software we design. The talk itself is scheduled for Friday, February 27th from 11:20 - 12:20 and the title is "The Layperson's Guilde to Building Better User Experiences. 

If you'd like to learn more, take a look at the agenda. Or, better yet, just register for the conference and experience it for yourself!

http://www.iasahome.org/web/itarc/116#BurkHufnagel

Thursday, February 12, 2009

Mini Java Puzzler

I was working on a project and needed to get a Long value from a String. I know the Long class (like the other wrapper classes for primitives) has static methods that do just the thing , so I started typing in my IDE and trusted that I’d find one that worked. As it turns out there are several methods that do similar conversions. Here’s a list of the candidates:

 Long.decode(String nm)
Long.getLong(String nm)
Long.parseLong(String nm)
Long.valueOf(String nm)


So, given that each of these takes a String and returns a Long, what does the following code return? (Notice that the getLongValue() method returns a primitive long:

    public long getLongValue() {
Long value = Long.getLong("23");
return value.longValue();
}

Here’s the list of possible answers:

 A) 23L
B) 0L (zero)
C) It depends.


Before you continue reading, what do you think the right answer is… OK, that’s enough thinking. Let’s take a look at the possible answers and see what seems likely.

Now it seems reasonable that Long’s getLong() method should return the value of the String as a Long, so answer ‘A’ looks pretty good. Then again, if it were that easy why would I bother posting this. Answer ‘B’ doesn’t seem very reasonable - unless getLong() isn’t really converting the value of the String. So that leaves answer ‘C’ as the primary suspect. If you’re familiar with Josh Bloch’s Java Puzzler talks from JavaOne, you’ll probably go with ‘C’ because it is kind of vague and that makes it a safe bet.


And you’d be right. The correct answer is ‘C’.


It turns out that Long.getLong() doesn’t try to convert the value of the passed in String directly. It looks for a System property with that name, retrieves the value associated with it, and converts that. So what the getLongValue() method returns depends on the value of the System property “23″. So, what if there is no System property “23″? In that case, the method throws a null pointer exception because Long.getLong() will return a null. Ouch!

I found this the hard way. I needed to convert a String and picked a likely method from the list provided by my IDE. I was greatly surprised when my unit test failed, so I looked up the JavaDoc on it and realized my mistake.


There are a few morals to this story:

   Unit tests are your friends.
Use the JavaDoc, and make sure you write some
for people using your code.
Hurrying can cause unexpected delays; but those
can become fodder for a blog post.


Until next time, I leave you with the traditional Java Puzzler farewell,
“Don’t code like my brother.”