Purpose. It's that little flame.

Purpose from the Broadway musical Avenue Q.  Awesome.

When I first started out writing this blog, I wanted it to be a place where I talked about the happenings in my technical life.  A good start I think.  Sometime this past week, three years into blogging on and off, I noticed something about the blogs that I read.  I'm so dense.  They all provide information that help me in some way.  Whether its explaining how I use a specific technique to improve my career, an interesting idea, or a novel concept, they all exist to lend a hand.

I noticed that a lot of my posts are a bunch of rants on what projects I'm working on, my love-hate relationship with certain technologies, or my personal improvement progress.  Maybe it's time to put a spin on what I blog.  Maybe I should write posts about how activities on projects flick on the lightbulb or create guides for tools I'm using.  Even reviews of tools and books would be helpful.

Maybe I shouldn't care what others think about my blog because part of the reason for taking the time to write things down is to get my thoughts out of my head.  If I really cared about increasing my readership, there are a lot of other things I could do.  Tons of people reading my blog isn't my purpose.

Helping others improve is a noble purpose.  It will be that little flame.    

2010 Things to Get Done

In the spirit of new years I decided to do what everyone else is doing, create a list of things I want to accomplish this year, i.e., my New Year's Resolution.  I remember I created a List of Things I Want to Do way back in 2008.  Let's see how I matched up 2 years later:

• Improve my writing skills
• Ruby/Apache Wicket and Hackystat
• Practice Puzzles
• Play with Python
• Give a speech to a group about something technology

The things I didn't complete are in red.  How sad.  Two years later I still haven't tried out Python.  I think I have improved my writing skills a bit, but I had a blog hiatus in 2009.  Hopefully we will miss that episode this year.  I tried implementing a Hackystat UI using Ruby on Rails in 2008.  Other than mentoring a student for Google Summer of Code 2009, I haven't done any new work on Hackystat.  The Collaborative Software Development Laboratory has started new work in the smart grid energy field.  It's an interesting area with mounds of real-world application potential.  I'm excited to see the direction they take their research.  Perhaps I might find an opportunity to contribute to their work.

I didn't create a list of things to get done in 2009, but I did have a Periodic Resume Update that talks about what I've done and where I'm headed.  It seems that I believed that Openmbp was the direction I was headed in 2009.  That idea has passed and now it's onto new things.  I'm a year older and starting to think about new things.

In the past two years I was concerned with everything technology related.  I wanted to improve my hacking skills and learn new technologies.  Learning new technical skills is important, but I now believe that other aspects of life that should receive attention.  That's what I want to accomplish this year in addition to continuing my technological advancement pilgrimage.  I debated on creating a list by priority, but I decided that everything on this list should get done.  I ended up categorizing the items into financial, personal, and technological goals.

Financial Things to Get Done

• Stick to my budget - I'm a failure at sticking to budgets.  I spend enormous amounts of time tracking where my money is going, set up a budget, and then buy a digital camera.  Or a snowboard.  Or a wine fridge.  Or some other thing that I probably should have saved up for first.  My new strategy is paying myself financially and to use cash when possible.  Paying myself first financially means that I put money away before I start paying my bills or buying frivolous things.  Using cash helps me to be conscious of where my money is going.  Credit cards are evil and they own me.  (Hopefully not this year)
• Save 10% of income - Paying myself first will allow me to accomplish the next two goals.  There are things I want to save up for in the future.  I can't purchase them unless I start saving now.  I think 10% is a reasonable number.
• Save 5% of income for life's experiences - For the past three years I've never saved money to spend on vacations or things I'm passionate about.  I was in the financial bias of saving as much as possible and would feel guilty if I decided to take a trip or spend some cash on something I took pleasure in. No more!  Over the past year I've become extremely interested in personal finance.  So like I always do when I want to find out more on a subject, I look for reading material, i.e. online blogs.  A recurring theme that I found that struck a cord with me was: Spend money on things you value.  After all, money is just a tool to live life.  So this year I resolve to save money for that snowboarding trip or a trek to foreign country.  I'm going to save and spend with no remorse.  I'm going to live this time around.

Personal Things to Get Done

• Continue to pay myself first - I recently wrote a blog paying myself first.  I want to continue to go to the gym in the morning.  
• Read one library book a month - I've been using the library for about a 1.5 months now and I'm going to say that I can't imagine my life without it.  I paid 10 dollars for a new library card and the first books I checked out were worth at least twice the library card fee!  I've found that I won't have the time to read, but I'm saving money instead of wasting it. I can always renew books I failed to read or just return them and check them out later.  The goal here is to continue to read.  One book a month is totally doable.

Technical Things To Get Done

• Play with Python (Really) - It's time to get off my ass off my crappy chair (My home chair.  My work chair rocks!) and learn a new language.  I wouldn't say I'm stagnating since I'm still absorbing Ruby and Rails, but I need to get some new code perspectives into my brain this year.  Python will be welcomed.
• Complete 2 resume updates this year - The periodic resume updates are a good indicator of my current technical and personal development progress.  Stagnation equals Fail.
• Increase my stackoverflow reputation to 1000! - I think I'm the most excited about this thing to get done.  I've been frequenting Stack Overflow(SO) for the past couple of weeks and have decided to join the game.  I want to raise my reputation points to a certain level before the end of the year.  Since it's a game with rules and points, my progress can be measured.  I want to have a goal of 1000 reputation points before 2011.  I'm at 96 right now.  An idea I had to use SO as a learning tool was to try to answer questions in unfamiliar areas.  For example, I'm not a pro Rails hacker, but I want to be.  So my task is to try to answer Rails questions even if they already have answers.  At the end of the day, reputation points don't matter, what I learn does.
• Practice developing with Ruby on Rails - It's still here.  Rails hacking.  It's fun, but I really need to get a move on.  I have a side project that I wanted to deploy by the end of 2009, but I failed.  Let's shoot for the end of 2010.

Phew.  That's a lot to accomplish. Onward!

My Mockito Tech Talk. AKA: Conveying Information and Stuff

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.

When I fixed my slides a bit, I changed my presentation's beginning to grab my audience's attention with some facts about my project's level of code coverage. The middle gave the basic functionality of Mockito such as mocking, stubbing and verifying.  I added some code examples and gave some background on when and why you would want to use Mockito's features.  There were a lot of questions that were brought up during this part of the talk.  Some were of mocking and stubbing use-cases and others were related to project specific usages.  I got a sense of confusion from the audience at this point.  I tried to use the List examples from the Mockito documentation, but that turned out to be a bit too high-level for a presentation.  Most of the developers didn't "get it".

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.

Baselines, Branching and Reviews!

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)

I am Japanese. Use the Library.

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.

So before I even went down to the library I checked their hours: Hawaii Public State Library Hour of Operation

Woah.  They have decent hours.  They are even open till 8 PM on some days.

So I headed down one day after work.

Here is what I found:

• If my book is at another branch, I can submit a request online to ship the book to the branch of my choosing.
• It really doesn't take that much time to drive to the library.
• The selection isn't the greatest.
• They still don't carry the latest technology books.  
• I still can't write in the books.

I was quite pleased with my library visit.  I had to purchase a new library card because I must have thrown my old card away.  When was I ever going to use the library again?  So that was $10.  It was funny because I had a .90 fine... from 2001.  It's been 8 years and they still kept a record of returning a book late.  Damn them.

But it's okay.  I spent $10.90 on my library visit, but I get to have an unlimited amount of books.  The money I save from not having to buy books definitely out weighs the time it takes to drive to and from the library.  If I reserve my books online I can further reduce the time I spend at the library.  Not to mention that I'm saving space because I don't have to store the books.  After years of buying books, I notice that my room is cluttered with books that I've read once.

Even if the library doesn't have the technical books that will keep me up to date, I still can purchase those books online at Amazon.  I add highlighting, notes to my tech books so it's not a huge deal to buy them.  I'm thinking I should try to buy them used instead of new.  I don't need the new, clean version of the book.  The content is the same.

The library is awesome!


It's too bad they don't have any funding.  When I checked out my books, the librarian handed me a flier that told me about their furlough days.  On the other side of the flier there was an article about a fundraiser to support the library.  They are obviously in a financial bind.

I'm not sure how to help them.  I think donations would help the problem, but would it fix it?  Maybe if more people used the library?  Who knows, but I'm hoping the library never goes away.

Paying Myself First

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

By the time I started working on my personal improvement tasks I would be tired and unfocused. I was amazed at how one morning gym session would make the rest of my day was incredible.  I felt great.  I didn't need to have 6 cups of coffee or some sugar to get through the day.  My metabolism was in overdrive.  I couldn't believe how awesome it was to start your day off with a workout.

So I changed my schedule:

• 5:45 AM  Hit the Gym
• 7:45 AM  Read blogs, Learn some cool stuff
• 7:00 PM   Watch video blogs, listen to podcasts, take a break
• 10:30 PM Sleep

Then one morning I found a blog that talked about Paying Yourself First.  What an excellent idea.  I've always struggled with spending too much at the beginning of the month or when I get my paycheck.  This is a great idea.  Pay myself first.

Light Bulb.

My updated scheduled:

• 5:45 AM  Hit the Gym
• 7:45 AM  Write a blog
• 7:00 PM   Read blogs, Learn some cool stuff, Work on side projects, Watch video blogs, Listen to podcasts, Take a Break
• 10:30 PM Sleep

So my new goal is to do some writing before I head to work.  I don't have to write a complete blog or always try to finish existing blog.  My goal is to jot down my ideas.  If I can write down what I'm thinking about I should be able to get a blog out every week.

I honestly rather do my side project hacking in the morning when I'm the freshest, but I don't have enough time between my gym session and when I need to leave for the job.  Once the tasking at work calms down a bit, I should be able to resume my Rails hacking.

A while ago I read an article by Sid Savara, Paying Myself First With My Time.  I didn't buy into it then.  How could I wake up early and start my day like that?  Crazy Talk.

_Best Idea Ever_.

Book Progress

1. Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series) (Finished!)
2. Outliers: The Story of Success (Finished!)
3. Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing Series) (In Progress!)
4. House of Leaves
5. Mentoring: The Tao of Giving and Receiving Wisdom
6. The Bro Code

I enjoyed reading Clean Code. The best part about it was it changed my outlook on method and class construction. My code is _a lot_ cleaner. The last chapter in the book, "Smells and Heuristics", is something all developers should read. I plan on giving it to developers on my company's engineering team.

Next on the reading list is the GoF book. It's interesting to come back to a book years later. A quick scan through the patterns shows me that I have forgotten a bunch. I can't wait to get through it again. The GoF book is great. I'll write more as a I plow through it.

Also Google Summer of Code is ramping up. Time to get to work!