Random Musings of a Developer, Amateur Photographer and Technology Geek

Recently at work I had to help respond to a Severity 1 issue.  This is our worst case scenario, something major is broke in production and is costing the company money.  In the presentation I gave at Twin Cities Code Camp about pair programming I said that often troubleshooting bugs and fixing production issues weren’t the easiest to pair on.  Reflecting on the past couple days I noticed that while trying to fix the issue at hand we were pairing the whole time.  I don’t think we could have accomplished the fix without the entire team using some of the techniques I had outlined in my presentation.

We used two of my local pairing techniques along with two remote pairing tools. Locally we used a mixture of traditional paring and “Divide and Conquer” pairing.

Traditional

With traditional pairing one person is “driving” while the other person “navigates”. As I sat in the driver seat with vim open and tailing a log on production my manager sat next to me helping navigate through the code as we figured out what needed to be modified. I used to think that I liked to work on these high stress issues alone and troubleshoot things with my own process, but now have a different opinion.  Having someone there to limit the amount of thrashing was a major help.

Divide and Conquer

With a major issue there are lots of logs to check, experiments to try, and pieces of a system to update.  This is where we brought another developer so we could divide up the work and conquer the problem.  While I updated configs, he updated our applet code.  By the time I was done getting the configs ready he had the applet built and ready to be pushed out.  We were in constant contact sitting next to each other but were able to work in parallel to finish the one task.

Remote Tools

Working with a team distributed around the world makes troubleshooting major issues difficult.  I was able to keep everyone on the same page by using a combination of a screen sharing tool http://join.me and tmux.  I used Join.me to share a remote desktop session from London.  From the remote desktop I was able to use putty to connect to a tmux session on my own machine.  This way I could show code and logs to the entire team.  Using tmux allowed me to reboot the machine and pick up and start running very quickly.

Using pairing techniques and tools helped us diagnose the problem and solve it.

I recently I had the opportunity to share a passion of mine at Twin Cities Code Camp 12.  I gave a presentation, “Pair Programming Techniques”, where I shared my experiences of pair programing including things I found to great and things that are not so grate. This presentation was one of my favorites as it had a great amount of audience participation. I will attempt to share this information in a series of blog posts.

Pair programming is the act of working on a focused task with someone.  I’ve seen it be a productivity booster, we’ve all had times where we just hit the preverbal wall while working on something.  I always found that explaining my situation to someone else would help me get over this block and get back to work.  Imagine having that person right there working on the task with you. Sure I’ve been in situations where both of us in a pair got stuck but that is a rarity.

While pairing I tend to notice that I am getting a real time review of the code I am writing.  I like being able to discuss code while it is written, giving me a chance to learn and teach all while getting things done.

Pair programming is not the silver bullet, it’s not going to solve all your problems or make your team’s velocity jump a hundred and twenty percent.  It’s not just for twenty something hot shot developers, working at the latest startup.  Even though you have two eyes working on the codebase doesn’t mean bugs are going to get through. Pair programming is like the old saying “measure twice and cut once”, which doesn’t mean you are going to cut every board perfect but it it limits your possibility of a defect.

In todays work place it is common to have people in the office along with remote employees.  Just because someone works remotely doesn’t mean that they can’t pair and have to work alone.  There are advantages and disadvantages to both situations.

Pairing locally has many advantages, most of which have to do with being in a physical environment. When you are working locally you have the ability to better read your pairs body language, you can grab some paper and sketch out some ideas.

Sometimes pairing locally can have some distinct disadvantages too.  There are big things like sickness, working in a very close environment makes it easy to pass things to each other.

Working remotely solves the sickness issue and allows both people to pair and not worry when they have a simple cold.  I have found myself enjoying remote pairing in this situation.  While you don’t have some of the physical amenities that you would in a normal office setting, video chat and screen sharing comes pretty close. I have spent time working remotely at previous jobs and have found that human interaction is something that I need. Pairing remotely gives you someone to talk with, share your ideas and get feedback from.

While pairing remotely is great during the height of flu season, and with video chat and screen sharing you can almost see everything there is still a great deal of communication that needs to take place for the pair to be effective. Bandwidth is a major downfall of remote pairing, I live in a location with a slower DSL connection and I have to prioritize the tools I use when remote pairing.

Look for follow up blog posts about different styles and tools for paring locally and remotely.  I’ll cover some of the techniques I have learned and developed since I started pairing.

I really wanted to write while I was on our trip but didn’t find any time to.  It was a nice trip to Phoenix and I was able to spend time playing with my camera.

Here are a few shots from my trip.

Last night I had the opportunity to present again to the Mad Railers group here in Madison. My talk was titled “Writing, for love and money”. I took others along the journey I had while working on Web Development Recipes and some tips I learned from Brian Hogan, who is one of my co-authors and mentor over the years.

Some of my main points where:

• Write every day (http://750words.com/)
• Decide who your audience is
• Help your reader get to the next level
• Get feedback from your friends, family and co-workers
• If you want to get published, find a publisher you respect
• http://pragprog.com/write-for-us
• Docbook is a great way to get started https://github.com/napcs/docbook

The other day a co-worker was talking about moving some of his sites to a cheap static web host.  Most of the sites were either blogs, or CMSs that don’t change very often and don’t really need the overhead of a dynamic system.  I thought back about a script I had written to do this a year or so back.   The meat of the script was around a wget call which spidered a page, and then converted all the links to work with the new static documents.

wget --mirror -w 2 -p --html-extension --convert-links -P folder_to_save_to http://mysite.com

So with this simple shell script you can specify where you want to save the converted site by replacing “folder_to_save” and then substituting the site you want to clone/mirror in for “mysite.com”

There you have it a simple way to clone a dynamic site to a static one.

November is PragProWriMo or Pragmatic Programmers Writing Month.  Prags is promoting writing by tagging along with National Novel Writing Month.  They have setup a forum http://bit.ly/tTQgLF to help people track their writing progress and get feedback and support from other writers.

Since I just finished working on Web Development Recipes for Prags I want to keep my train rolling and keep writing.   So this month rather than working on a new book I am going to try and write every day.  My posts may come out in large groups since I will be on vacation 2 weeks out of this month but I’ll try to keep up the writing.

Recently after doing a Code Retreat with Cory Haines I found myself really wanting to work on my Ruby fu.  I was inspired by the idea of practicing my trade everyday in some simple exercises that  allow me to focus on parts of the language to really learn it well.

So I decided to pick up the Ruby Koans which I was introduced to a year or so ago but never thought I needed that.  I always figured I could just keep learning by using Ruby for my projects, but then I realized that I was just using the same few parts of the language to build my apps.

Following the craftsman analogy, I was using the same saw and hammer because they are comfortable.  I didn’t take the time to learn about the pneumatic framing nailer because I already had a way to pound in nails, but boy does it make building things easier.

So if you are new to Ruby or have been using it for awhile I really recommend you find some exercises to keep your skills sharp and explore new parts of the language. I really think the Ruby Koans are perfect for this, I see them being easy to get started and with enough substance that even seasoned developers will pick up new things.

Today marks a new accomplishment in my career.  I am a published, professional author.  Today we released the beta of Web Development Recipes a book for anyone interested in expanding their knowledge of Web Development.

I worked on this book with several very intelligent and amazing co-authors: Brian Hogan, Chris Warren and Aaron Godin.

So head over to http://pragprog.com/book/wbdev/web-development-recipes and pick up a copy, or two, or three!

This morning I decided to try out a new pairing setup.  What I did was setup a machine that can be accessed by both developers and installed tmux.

Tmux works like screen where it creates sessions that you can attach multiple users to.  It also allows you have a few open buffers so you can do things like have one buffer open for Vim and another to run your Rails Server.

So we have taken advantage of the ability to attach multiple users to a session and then had each developer attach via ssh from their local machine.  We haven’t configured tmux beyond the basic install but it seems to be working good.

One nice thing is each developer can SSH back into their local box from a separate buffer and have access to files on their local machine if need be.

-CJ

Last night I had a chance to present to the Madison Ruby on Rails Club.  As the meetings are always a good time, I did really enjoy giving my “Testing any Website with Selenium and Cucumber” talk. You can get the Slides Here.

The talk revolves mostly around getting to the point of using Cucumber to drive your browser based behavior tests.  I feel strongly that at this point in time Sauce Labs is also the easiest way to run those tests.

If you want to get started writing tests head over to my git hub page and grab the “Cucumber Test Harness” project.  Then get yourself an account at Sauce Labs, they give you 200 minuets a month of free testing time. Then follow the readme in the Test Harness project and start testing websites.

Thanks again to everyone that came out.  Remember to please rate the club meeting on the Meetup.com page and also I would appreciated feedback on my SpeakerRate page.

-CJ