Austen.Ito.Blog

It seems that 3 weeks after writing Paying Myself First, I have already failed.  Well not completely.

I haven't been writing down my thoughts in blog form because I've been preparing slides for a tech talk at work.  I've been wanting to give a talk about Mockito.  My project is on a transition point so I figured that it would be imperative to give a talk this month before we ramp up again in January.

I suck at public speaking.  That process of reading your audience.  Conveying information.  All of that stuff.  Who needs it right?  Hook me up with my IDE, give me a fridge full of diet mountain dew and get out of my way.  I got things to do.

If only the world worked that way.

Since I'm on this whole, let's work hard and do awesome kick, I've been looking at public speaking as an area to focus on.  After all, if I want to be able to lead software teams, I need to be able to be someone who is able to be informative and also know what the hell they are talking about.  I've done the whole Toastmasters thing before.  I like the concept, but I didn't like the structure and organization of the particular group I was a part of.  So without any outside help, I got to searching on how I could improve my slides and effectively present a technical presentation to my peers.

And the search began.

I found this interesting PDF using the Google: Presentation Tips - How to Give a Technical Presentation.  It's main points were to break up your presentation into distinct beginning, middle, and end sections.  The normal presentation layout, which I totally brainfarted on.  My presentation sections were a mess.  I didn't show any importance, background, or motivation in the beginning.  I had no illustrations to help my audience during the meat of my presentation.  The end was the best part, most likely because the slides came to end.

I finished off my presentation with a "real-world" Mockito example where I tested the behavior of a action class populating a stack.  The action class implemented ActionListener  and would operate on Stack's object interface.  I got good responses from this part of the presentation.  I think that developers had that "ah hah" moment when they could finally see Mockito in action from an IDE.
 
Overall I think the talk went well.  It was very informal and the I was getting a good vibe.  The best part was the fun-ness factor.  I'd have to give it a 9 out of 10.  This was the most fun I have ever had during a tech talk.  One thing I noticed that might have increased the fun-ness factor was the room's size.  Due to scheduling conflicts we had to switch to another room where the developers were comfortably crammed together.  Best move ever.  I think that helped the talk out a lot because it made the presentation feel less like a presentation and more like a discussion.  I think I'll always have my talks in that room if it's possible.

My team has already started to use Mockito to write their unit tests.  The real measure of success will be if the rest of the project's teams will start to drink some of that delicious Mockito Koolaid.  Oh yeah.  A coworker on another project likes the idea of Mockito and believe that he will use it for his tests.  Something interesting I ended up telling him was that:

"If you already write tests, then you know the pain of trying to setup and build the dependencies of the object you are testing.  If you don't write tests then you'll be wondering what's the point".

I hope they get it.

We have come to a crossroads at work.  On the left we have our latest release.  On the right, we have the road leading to future changes, improvements, and success!

Our latest release, lets call it FixLaterReleaseNow or FLRN for short, mainly consisted of developers committing to the trunk.  This caused developers to commit unfinished, broken code to the mainline.  When other developers would update, they would pull the broken code into their local workspace.  I'm not sure if this led to the code rot that manifested itself, but something was wrong.  Very very wrong.

Perhaps there was a problem with our peer reviews.  We had little to none.  The only set of eyes looking at the code were the author's.  In FLRN we used the Jupiter Eclipse Plugin to facilitate our peer reviews. Jupiter is a great tool, but there were two major sticking points for us:

1. Some developers use IDEs other than Eclipse.
2. The turnover from setup -> moderation -> fixing review issues was way too long.  On average it probably took developers 1.5-2 days to complete the process.

I love Jupiter.  I've been talking with Julie, the current maintainer of Jupiter, about how we can improve the plugin.  That talk is for another blog on another day.

There were broken windows everywhere and no clean up crew to whip it into shape.  Something needed to change and fast.  We had no time in the FLRN codebase, but we have some time (a little) in the new release to get moving towards the proverbial Awesome Path.

To get on track we have integrated Crucible, a code review tool from the great people at Atlassian, into our development process.  It's a bit buggy and doesn't integrate with the other Atlassian products as we would like, but Crucible increases our review turnover.  It is much quicker to choose which files to review, comment on the source, and complete the review.  The reviews are persisted so other people can  checkout what happened in the review. What we are noticing is that developers are posting comments on lines of code and the author comes in and comments on his design decision.  You just don't get that kind of immediate feedback when using Jupiter.

So back to the developers committing broken code to the trunk.  We don't want that.  We want code that has been reviewed by other developers who are working on similar feature sets to be committed to the trunk.  So my question is "How do we setup our branches?".  (Keep in mind that we use Subversion)

We are currently thinking of having two lines.  The trunk, which contains "stable" code that developers can branch off of.  In this context, stable means that the feature is complete and somewhat tested.  There will be bugs, but we will iterate through them as we go.

The second line will be our feature branch.  The feature branch can have many other branches contained in it.  This is where developers can work on their specific features without touching the main line.  In FLRN (Fix Later Release Now in case you forgot) developers would wait on committing their features because they were broken, or there would be a lot of rippling changes throughout the system, or because they wouldn't have any documentation which would cause our build to become unstable.  Now if we force developers to use the "Feature Branch" they can commit at any time without fear of breaking anyone else.

Once the developers are ready to merge to the trunk, we can have other developers review their code.  This seems like a good idea.  Developers can commit early and often without breaking anyone.  They can get their code reviewed by their peers.  Everyone is happy.

Perhaps in the make believe place of No Bugs Land.

Complications arise when more than one developer is touching the same file.  What if two developers finish their features but are using the same file.  Do we merge their changes?  Can we combine their features into a separate branch and then create a review?  That might work.

We definately need some review and merging management.  The problem we want to avoid is having a backlog of reviews.  For example, Developer A might be working on file X.  He finishes and requests a review for it.  Later that day Developer B finishes his feature which includes file X.  He requests a review for his code.  We now have a problem because there are two revisions of file X to review.  If we don't merge both Developer A and Developer B's changes, we will have to review Developer A's changes, merge the changes, then review Developer B's changes.  I feel the Horribleness!

I'm wondering how people handle different code baselines in their development environments.  I'm going to have to do a bit of research, but this article by Jeff Atwood is a good starting point: Coding Horror: Software Branching 

(Edit: It seems that Jeff Atwood got his information from Streamed Lines: Branching Patterns for Software Development)

Do you remember the old Hawaii State Public Library Commericial where kids would say?

I am Hawaiian Chinese.  I am Hawaiian Portuguese.  Please use the library.

Well I'm not Hawaiian, but I've decided that I'm going to give the library a chance.  Up until this point, I told myself that I don't want to use the library.  It's such a hassle.  Waste of time, energy, resources, and space.

I've been reading in personal finance blogs like the The Simple Dollar about the benefits of using the library. A few of my friends have started or are already using the library.  One of even suggested I help to improve the library's borrow/renewal web UI.  An interesting side project.

But I had my doubts.

• I know they don't carry the latest technology books
• Driving to and from the library sucks
• Will they have the book I'm looking for?
• I really like to write in my books
• I'm one of those people that have to have to book just in case there is that one time I _really_ want to find something in a book I bought 5 years ago.
• I bet the hours are inconvenient.

Wow. My last post was back in May. It's been a while since I've made time for this blog thing, but it's been a good sabbatical.  I'm reemerging on the interweb for the third time and hopefully here to stay.  I want to stay committed and vigilant, as we all know how difficult it is to be an active blogger.  My plan of posting twice a week turned into posting once a week, which then turned into not posting.  Plan failure.  But I have a new and improved plan!

One day I had a 6 AM gym session with a friend.  It changed my life.  My schedule used to look like this:

• 9:00 AM   Wake up
• 9:05 AM   Go to Work
• 7:00 PM    Read blogs, Side Project Work
• 10:00 PM  Hit the Gym

I've been reading Clean Code that I listed on my list books to get through. I've read a bunch of code improvement books, but there were a couple chapters that I've gone through that I liked so far.

Writing clear functions

We've all heard that we should write functions that only do one thing. But how many of us really do it? Here is an example of how I used to write code.

public void mouseClicked(MouseEvent event) {

// Let's do something on a primary button double-click
if (event.getButton() == MouseEvent.BUTTON1 && event.getClickCount() == 2) {
// do something

}

Inline comments are evil. If they aren't updated, which can happen frequently, why not write a method that can't lie. What I should be doing is writing methods with clear names that inform developers of my intent.

Inline comments can be out of date, in the wrong place, or just plain wrong. Method names get updated automatically if you refactor your code and if the method name is wrong, the compiler let's you know.

Here is how the code should look:

public void mouseClicked(MouseEvent event) {

if (this.isPrimaryButtonDoubleClick(event)) {
// do something
}

}

public boolean isPrimaryButtonDoubleClick(MouseEvent event){

return event.getButton() == MouseEvent.BUTTON1 && event.getClickCount() == 2;

}

The code is trivial, but when your methods and classes get larger, readability and intent become increasingly more important. The longer developers have to stop and think about what your code is doing, the more it needs to be refactored. Here is what a developer might be thinking when they read my old code example:

"We want to do something when BUTTON1 is pressed and we click twice". "What is MouseEvent.BUTTON1"? *Stop to read some java docs* "So we get the click count twice. Oh thats a double-click!"

You might think that someone should immediately associate the clause to a double-click, but you might have to stop and think if you aren't familiar with the author's style or are just getting into Java. Context switching causes breaks in concentration. Not good.

In the refactored code, the developer can get to mouseClicked() and read once, "We want to do something when the user's primary button is double-clicked". No context switching, no breaks in concentration. Good.

Writing clean comments

The next thing I read that was interesting was method level comments. Here is an example of my old method level comments that I would write to pass Checkstyle and document what my method exposes:

/**
* Returns true if the primary button is double-clicked.
* @param event the event wrapping the mouse state information
* @return true if the primary button is clicked, false if not.
*/
public void isPrimaryButtonDoubleClick(MouseEvent event){

return event.getButton() == MouseEvent.BUTTON1 && event.getClickCount() == 2;

}

There are three areas of duplication. First, my initial comment duplicates what the method name states. Second, the @return tag says the same thing. Finally, the method signature clearly states what my method does and returns. Since checkstyle requires a @return tag, here is my refactored method comments:

/**
* @param event the event wrapping the mouse state information.
* @return true if the primary button is clicked, false if not.
*/
public boolean isPrimaryButtonDoubleClick(MouseEvent event){

return event.getButton() == MouseEvent.BUTTON1 && event.getClickCount() == 2;

}

I removed the initial comment to reduce the comment duplication. If the method had no parameters, the code will be reduced further:

/** @return true if the primary button is clicked, false if not. */
public boolean isPrimaryButtonDoubleClick(){

return this.event.getButton() == MouseEvent.BUTTON1 && this.event.getClickCount() == 2;

}

It passes checkstyle and reduces the amount of comment duplication. I like it.

It's Google Summer of Code time so I checked out Hackystat and tried to build it from source. A couple hours later, my Hackystat development environment was setup. Ouch.

The hardest part about setting up my environment were all of the tool dependencies. To build

hackystat-utilities, hackystat-sensorbase-uh, hackystat-sensorshell, I needed to the following libraries:

Then I needed to set the following environmental variables:

1. HACKYSTAT_UTILITIES_HOME
2. HACKYSTAT_SENSORBASE_HOME
3. JUNIT_HOME
4. FINDBUGSHOME
   
5. APACHEJCSHOME
   
6. APACHECOMMONSLOGGINGHOME
   
7. RESTLETHOME
   
8. JAVAMAILHOME
   
9. DERBYHOME
   
10. CHECKSTYLEHOME
    
11. EMMAHOME
    
12. HACKYSTATANTSENSORSHOME
    
13. ANTARGS
    
14. PMDHOME

As a developer it would be cool if I could check out the source files and run a couple of ant targets to retrieve the dependencies.

At work I've been experimenting with Ivy to download my project's dependencies. I download the dependencies to the project's library directory via an Ivy ant task and I'm done. There is no need to configure any environmental variables because the build script knows the "Home Folder" of the external libraries.

I checked on the Hackydev Mailing List and found a thread started by Aaron a long time ago called Ivy for Java hackystat dependency management.

I think it would be really useful if it were easiser for new developers to check out the source and start hacking. Integrating Ivy into Hackystat's build system might be a useful project and help to reduce Hackystat's hacking entry barrier.