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.

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!

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.”

Burk on Books: Inside Steve's Brain

Inside Steve’s Brain by Leander Kahney
Published by Portfolio (the Penguin Group) in April 2008
ISBN: 591841984

“Inside Steve’s Brain” by Leander Kahney is a nice little read (7.2 x 5.4 inches and under 300 pages) that is both entertaining and educational. The Steve in the title is, of course, Steve Jobs and the book provides a look into how he thinks about things like leadership, user experience, product design, and teamwork.

The introduction describes parts of Jobs’ career and private life. The next six chapters focus on his personality traits and how they impact the way he (and Apple) works. The last two chapters describe how it all comes together and enables Apple to do things other companies seem to find difficult to emulate.

Each chapter ends with a list of “Lessons from Steve” and while we may not have the ability to follow all of them ( “Partner only with A-players and fire bozos” – who wouldn’t love to do this!) they are still worth remembering. The book includes a case study of how it all came together with the iPod, and ends with a look at why Jobs (and by extension, Apple) keeps producing closed systems (think iPod, or Mac) while the rest of the industry produces open systems that allow the user to plug in third party hardware. While this is controversial, it does make sense from a certain point of view; doing so allows Apple a tighter integration between the hardware and software, which means a more pleasant user experience with both.

The book is interesting and thought-provoking. Whether or not you are a fan of Steve Jobs and Apple, you must admire the loyalty of their customers base; they must be doing something right. Any of us should be thrilled if our customers felt the same about us. So maybe it’s worth spending a little time exploring the territory “Inside Steve’s Brain.”

P.S. You an go to a page on the book's website (http://insidestevesbrain.com/thebook.html) and see a three minute video of the author talking about the book. Or better yet, download the Introduction and see if it appeals to you before you buy the book.

Learning Java by Leading

Another great way to keep up your technical skills is to lead a certification study group. They say that the best way to learn something is to teach it. While that may be true, I can tell you that you don’t have to teach. I’ve recently found that leading a study group grants many of the same benefits while giving you an out. Since you’re just leading the group, and not actually teaching the topic, you don’t have to be an expert.

Even better, if someone in the group really is an expert on part of the topic, or just knows more about it than you do, you can defer to their expertise without losing credibility. And, that’s a win for everybody. (On the other hand, when I lead a group, I think it is important for me to know as much as possible about the topic so I can answer most of the questions they bring up.)

Certification itself seems to be a controversial topic, but I think that most people would agree that it is a way for interested people to learn more about a given topic. Personally, I think studying for certification is great because it forces me to learn about things I wouldn’t otherwise be too familiar with. For example, way back in 2001 I was studying for the Sun Certified Java Programmer (SCJP) exam (version 1.2 I think) so I had to become familiar with the Java IO classes. While they're useful for working with directories and files, I had no experience with them because at the time I was writing code that ran in an app server.

As I stated above I’m currently leading a study group and we're preparing for the SCJP exam for Java 6. While reading this week's chapter, I ran into something possibly useful and definitely interesting. Like the Java I/O classed in 2001, it's something new to me because I’m mostly writing JEE code and most JEE app servers don't support Java 6 yet. Sigh.

Anyway, we’re using Kathy Sierra and Bert Bates’ “Sun Certified Programmer for Java 6 Study Guide” as our text. It's an excellent book and since Kathy and Bert were instrumental in writing the exam, I figure that after working our way through it we should be covered. This week we’re on chapter 6 which is all about Strings, I/O, Formatting, and Parsing.

The I/O section introduces the java.io.Console class, which is new in Java 6 and lets you read from and write to the command line – if the environment you’re running in supports it. You write information to the console by calling format() and printf(), and you read from it using readLine() and readPassword(). The readLine() method is for retrieving a single line of text from the console. The readPassword() method also retrieves a line of text, but doesn’t echo it to the screen so your password isn’t displayed - which seems reasonable. So far so good, right?

Now comes the interesting bit. The readLine() method returns a String, but the readPassword() method returns a character array. After I read that, I looked up and wondered why the API wasn't consistent. It seemed to me that it would be better if both of them returned a String. Then my eye caught the next sentence and suddenly it all made sense.

Since readPassword() returns a character array, you can do whatever validation is necessary and then overwrite the data with something else to scrub the password from memory. So, why can’t you do the same thing with a String? Think about it for a bit before you read the next paragraph…

That’s right! In Java, Strings are immutable and they’re stored in a special memory pool so the JVM can reuse them; which means that if readPassword() returned a String then the confidential information you took pains to hide from prying eyes could be found by someone sifting through the system’s memory.

Of course, this also means that once you get the password you should take pains not to do anything that would create a String out of it; but you probably figured that out already.

If you're in a study group, or leading one, please leave a comment and let me know what you think about it. Is it valuable? Is it a waste of your time? And what do you think about Java certifications? Are they intrinsically valuable, or does it depend on circumstances?

Thanks for reading this. Y'all come back now, y'hear?

Beating the odds by reading books

In my copious spare time (gained by not watching much TV) I read and review books, technical and otherwise, as a way of keeping up with the rest of the world. (You can read my most recent review here.) Usually I’m working on one or two books at a time (did I mention I love to read?) but I discovered some really interesting books in a short period and now I’ve gotten a little swamped. At this point, I’m reading three books and writing reviews for three others.

I posted one review to DZone.com’s Book Zone last Friday, but you won’t see it in their listing until the zone leader approves it. The other two are not technically technical (they aren’t specifically about programming or software development per se) but they are books I would recommend to developers and architects who need to communicate their ideas with others.

The review I posted is for “Groovy Recipes” by Scott Davis and it is a book I highly recommend for anyone interested in the Groovy programming language. As its title suggests, the book is full of recipes showing you how to get something useful done in Groovy. There’s even a section with recipes for Groovy’s web framework, Grails.

If you’re looking for a new language to learn, or you’d like to improve your skills with Groovy, this is an excellent choice to help you on your way.

“Presentation Zen” is the name of a web site as well as a book, both by Garr Reynolds. I found the web site when I was working on a technical session for JavaOne 2008. While I loved the approach Garr suggested, I was pretty sure I couldn’t pull it off in the time I had left to prepare. I stuck a more traditional approach and swore to myself that I would come back and learn to improve my presentation skills.

This book is full of good information and can point you in the right direction, but you (and I) have to do the work needed to improve - reading alone probably won't cut it. But, if you want to get better at presenting information then this is a great place to start.

The third review I’m writing is for a wonderful little book titled, “The Back of the Napkin” and it’s subtitle “Solving problems and selling ideas with pictures” pretty much lets you know what to expect when you read it. If you’re anything like me and most of the programmers and architects I’ve worked with then you’re probably comfortable sketching a diagram to describe a problem or solution to the people you work with. So why would you want to buy a book about it?

Well, take a look at the website Dan Roam (the author) set up for the book and watch the video on the five focusing questions and the six ways to see and show. That should be enough to get you to place an order for the book today. In case the site’s down or you can’t view the videos, the point is that Dan presents a well reasoned method to figuring out how to visually solve problems and present the solution to other people so they can understand it. From my point of view, getting better at those two things is well worth the price of the book and the time it takes to read it, and you can’t ask for much more than that.

I’ll update this post – or just post a short notice – when the reviews are done and out there. I also post to the Atlanta Java User Groups’ Book Corner so you may see them there first.

Oh yes, the title of this post is my way of thumbing my nose at the "statistic" I've heard concerning the average number of books a programmer reads in a year - which is supposedly zero. I don't know about you, but I'm doing my best to boost that number; and learning a good bit at the same time...

Dang. I just realized I'm going to need a good sign-off phrase to let you know I’m done and didn’t just hit the “post article” button by accident.

A Weekend full of Learning

Where do you find people who willingly spend their entire weekend learning about things like Java class loaders, Groovy, Java Server Faces, Google Web Toolkit, Test Driven Development, Alternative languages for the JVM, and other similar topics? Well, last weekend you’d have found about two hundred of them at the 2008 Greater Atlanta Software Symposium put on by No Fluff Just Stuff.

The conference started Friday at 1PM and ended Sunday at 6PM, with breaks for food and sleep. The primary draw was twelve 90-minute opportunities to learn about one of 72 topics being presented by some of the best speakers out there including people like David Geary, Scott Davis, Neal Ford, and Ted Neward.

And if that weren’t enough (Is it ever?), each day had an extra goody; on Friday Jared Richardson presented a potentially life-changing keynote titled "Career 2.0" (keep an eye out for the book), Saturday ended with a choice of BOFs, and Sunday's lunch was followed by an hour-long “expert panel” featuring seven of the speakers holding forth on topics like architecture, testing and SOA.

If you’ve never heard of No Fluff Just Stuff then you’re in for a treat. It’s kind of like a traveling, three-day long, JavaOne. I recommend checking out their web site for a time and place when they’re either someplace near you or someplace you want to visit, then sign up and get ready to learn. It's good for your career.

What's in a name?

Listening to Jared Richardson speak, I knew I had to make a change and I needed to do it tonight. Jared was tonight's key note speaker at the "Greater Atlanta Software Symposium" aka No Fluff Just Stuff. His talk was titled "Career 2.0," and it got me thinking (again) about my career and what I want to do and be.

Jared made a lot of suggestions, and I intend to give some of them a try. One of the many things he suggested was to become a blogger because it's an easy way to share the things we learn with others. He said it's easy to create a blog. In fact, he claimed that it is so easy to get started that on previous occasions some people had actually fired up their laptops and created a blogging account during the second part of his speech.

After I got home I decided to take part of Jared's advice and enter the blogosphere. I went to blogger.com's home page and, since it only required three steps to get started; create an account, name the blog, and pick a template. I have to admit that it did look pretty easy.

I created an account, but then I had to wonder about the folks Jared spoke about. Creating the account was easy, but picking a name was definitely not. I'll admit that it took me a while, partly because all the names I initially wanted were taken; but it's also because I believe names are more important than you may think.

I suggest to you that names conjure images in our minds and can affect both our expectations and behaviors. Let me give you an example.

Many years ago my neighbors had a dog named "Rambo." Care to guess what kind of dog it was? If you've seen the "Rambo" movies, starring Sylvester Stallone, you'd probably thinking that Rambo was a powerful dog with a serious attitude; something like a Rottweiler; and you'd be partly right.

Rambo did have an attitude, but he wasn't big at all. You see, Rambo was a toy poodle. (Yes, I asked about the name. It turns out that when they decided to get a dog, my neighbors had a tough time deciding, so they compromised. She got to pick the dog, but he got to name it.) The point is that we often have preconceived ideas about people and things based on their name, and I wanted to pick a name that would help people get in the right frame of mind for what I was expecting to post here.

The first name I picked that hadn't already been used was "Musashi Flex" and I wrote much of this post for that blog's initial posting. But the next day I found that explaining what the Musashi Flex was, and how it applied to my blog,was more work than it was worth; though fans of Steve Perry's Matador series, it might have grokked it.

So I went back to thinking up a meaningful name and, after sleeping on it, the phrase "mind like a sword" is what I've come up with. It's not the perfect title, but I like it and I like the idea of equating mental sharpness with a sword's effectiveness in battle. (Yes. I am familiar with the phrase "Just like a(n) X to bring a knife to a gunfight", where X is some group you don't want to ba associated with; but "Mind like a bullet" just isn't me.)

I expect to do a few things with this blog:

• Share my ideas on software development.
• Share issues and solutions I run into while working as a software architect and developer.
  
• Provide a place to discuss and review some of the many of the books I read - most, but not all, related to software design and development.

Well, this seems like a reasonable length for my first post. Thank you for your time and attention.

May you live long and prosper!