Chris Johnston

I always knew cubicles were bad, but now I have proof. Check this article out by Kathy Sierra called Brain death by dull cubicle. In it she states that a scientist has found that if people are placed in stimulating environments and are learning, then they are able to grow new neurons. If they are stuck in dull boring cubicles, those brain cells start to die. This is actually the second such article that I have read in the last little while about how bad cubicles are.

Places like Pixar and Google definitely have it right when they allow each developer to personalize their work space. I guess I wonder why other places don’t allow this? Is dull some kind of corporate code that must not be broken?

This is my favorite quote from the article:

It would appear that blowing your own mind on a regular basis is not just a good idea, it’s a key part of neurogenesis. One of the conclusions she came to is that “learning heals the brain.” And again, we aren’t talking emotionally or psychologically, we’re talking physical structures. She believes that even those who have been in a stressful environment can undo much of the damage by not just removing the stress, but actively introducing enriching and stimulating things.

This is one thing that I have been thinking about lately. Developer’s need to be given the space to learn and be encouraged to learn and try new things. I love Google’s 20% rule where they allow each developer to work on their own thing for 20% of their time. This amounts to one whole day a week where they can do whatever they want. Some of Google’s best products have come out of this.

My last job I sorta did this and the result was the adoption of Hibernate. Before that they had always written their own JDBC/OR tools. All I did was to take an existing project and convert part of it over to work with Hibernate. This was enough to convince people to give Hibernate a try.

I think if developers are given the space and the time, while at work, to do their own thing, then new and innovative ideas and products will be the result. As Kathy says, developers need to blow their “mind[s] on a regular basis”.

I don’t usually write about Microsoft products, but there was a post on digg.com about the interface for Office 2007 that sparked my interest. I have been mildly following the development of Office ever since I saw a video of a very early version. The video showcased the new UI and the live preview feature, both looked very cool.

I am usually the first person to state that one thing Microsoft is not is innovative, however, with Office 2007, this seems to be changing. It seems that the Office team has decided to try something new, they have decided to remove all menus and use command tabs instead. The tabs allow the user to see all available options and commands associated with an action that the user may wish to do, such as Page Layout. I am not sure how this experiment will pan out, but I have to admire their courage.

Based on the screenshots and video that I have seen, this looks to be a very cool idea. As a user works, the command tabs at the top change depending on what is being done. So if you are editing content in a table, the tabs would show you actions relevant to tables, if you are editing body text, then it would show you, once again, relevant actions. The idea is that instead of having to hunt through menus, the commands you need are directly available when you need them.

Personally, I think this is a very cool idea. It will be interesting to see if they can pull it off.

One aspect of Java programming that I think is very difficult for new developers, myself included, is how to properly handled Exceptions. When do you throw them, when do you catch them and how do you handle them properly within a large system? I found this article, Three Rules for Effective Exception Handling, several months ago and it definitely helped to clear up some of the confusion.

Exceptions in Java provide a consistent mechanism for identifying and responding to error conditions. Effective exception handling will make your programs more robust and easier to debug. Exceptions are a tremendous debugging aid because they help answer these three questions:

• What went wrong?
• Where did it go wrong?
• Why did it go wrong?

When exceptions are used effectively, what is answered by the type of exception thrown, where is answered by the exception stack trace, and why is answered by the exception message. If you find your exceptions aren’t answering all three questions, chances are they aren’t being used effectively. Three rules will help you make the best use of exceptions when debugging your programs. These rules are: be specific, throw early, and catch late.

For me, the second point, throw early, was the most helpful. As soon as you detect a problem, throw an exception and be as specific about what went wrong as you can. In other words, don’t just throw a generic exception if the argument for a method was wrong, throw an IllegalArgumentException instead.

The article is well laid out and well written and definitely recommended for any java developer to read. I found it very usefull.

I have had this article, called Agile Answers open in my browser for the last several weeks. It does an excellent job of answering several questions that keep coming up with respect to Agile development, and more specifically, Test Driven Development (TDD). The four areas that the author deals with are:

• Adding methods ‘just for testing’
• TDD designs are more complicated
• All this test code takes so long to write, we could be finished in half the time without it
• Do the simplest thing for the task at hand

For my X Windows assignment, part of the project was to create a “database” from a flat file and an index file. The flat file had to be an ASCII file in the following format:

Field1: value
Field2: value
Description:
description value, variable length field
.
PrimaryKey: key String

As you can see, the field names are included on each line and the description field can be of any length, with the end being delimited by the period.

My question is this; what is the best way of actually programming this? The way that I did it was to create a struct that contained the data from each field. I limited the length of each field to about 45 characters and the length of the description field to 2000. However, this still means reading in each line using fgets(), stripping out the field name, and strcpy() the data into the corresponding field in the struct. For the description field, I looped until I got a string that was equal to ".\n".

For the index file, I simply read through each record in the file, noted its record count and its search key in an index and sorted the index. This gave me how many records I had to read through in order to get to the one I wanted.

For a small data file this works fine, but due to the lack of random access, it would become hideous for large files. There has to be a better way of managing and programming a data file like this. The problem is that I cannot think of one. Anyone out there have any suggestions?

This past weekend I had the opportunity to play with the new intel iMac at the Apple store. Comparing performance against my wife’s iMac, the new intel ones are definitely faster. I only had time to do a little playing, but with a bunch of applications opened, iPhoto opened within a second and “scrolled like butter”. This is not the case on my wife’s iMac. Now all we have to do is wait for Adobe to get off its but and release an intel native version of Photoshop.

For all you Gnome fans out there, here is a look at GNOME 2.14. I like it. I used to be a diehard KDE fan, but the more work that is done on Gnome, the better it is starting to look. I use it on my Centos 4.2 box. Now if I could only figure out how to turn that spatial navigation thing off. I hated it back in Windows 98 and I hate it in Gnome as well.