Kyle Smith

When looking through some particularly convoluted code last week I started to wonder if the code was always that complex or if it was a gradual change as several developers attempted to implement the necessary features.

Perforce, which VMware uses for SCM, as well as other SCM systems let you view or check out prior revisions of a file which is helpful, but isn’t all that interesting because you can’t easily compare the files; you end up looking at them one at a time.

Is anyone aware of a tool that will automatically create slideshows or videos of versioned files?  I think it’d be neat to generate a series of snapshots of a file and be able to flip through them and watch the code itself evolve.

This idea was inspired by the code_swarm experiment conducted by Michael Ogawa at UC Davis.  Be sure to follow the link for some cool visualizations of popular open source projects.

Tags: scm, visualization

I was reading Massimo Banzi’s Getting Started with Arduino over the weekend and came across a wonderful, page-long explanation in the Troubleshooting section that all software developers should take to heart when reading, writing, and using code as it explains the general approach for each quite well.

I won’t reproduce the explanation here due to copyright restrictions, but you can read the page on Google Book Search.  It boils down to this:

1. Try to understand how the parts of the system work and what each component is supposed to contribute to the overall system
2. Determine the component boundaries and what their responsibilities are
3. Test each component individually and gradually build up the system, testing it as you go

I like his explanation so much I think it should be one of the first things drilled into software engineers.  It also seems quite applicable to test driven development as well.

Tags: debugging, learning, testing

Last month while sitting at a Barnes & Noble I picked up and read a copy of Venkat Subramaniam and Andy Hunt’s book Practices of an Agile Developer: Working in the Real World.  The book is a collection of good tips for developers to follow.  One of them in particular, #33, struck a chord: Keep a Solutions Log.

What is a solutions log?

You’ve probably heard of the idea before or seen analogous practices only under a different name: Star Trek had ship’s or captain’s logs, IBMers have runlogs, other engineers have daylogs.  In this case, a solutions log is a personal record of the problems you’ve encountered and the answers you’ve found to them, with the intent of documenting the answer for all time so you’re not burned by the problem again.  If you’re kind enough to post it someplace Web accessible, others won’t get burned either!

I got accustomed to logging my activities (and by extension, the problems I encountered) while working at IBM but have been rather lax about doing the same while employed by VMware.  Periodically I’d scribble notes on a sheet of paper while working but they never quite got organized or put in an easily-searchable form.

Since reading PAD I’ve been maintaining a plain text file with my progress as well as any problems/solutions I encounter.  It’s already proved useful a number of times, especially when engaging in design decisions with colleagues and I know there is a particular reason to not do something.  If you decide to try it out, hopefully you find the practice just as useful.

If you don’t want to buy a copy of the book (or read it in a bookstore), you can download a PDF except of the book that includes this tip from the Pragmatic Programmer website: http://media.pragprog.com/titles/pad/CodeAndDebug.pdf.  You can also find additional information about the book on its official page.

One other tip in a similar vein: if you post a problem to a discussion forum or mailing list, please please please follow up with the solution once you find it.  There’s nothing so frustrating as identifying people that experienced the same problem as you but not knowing how they solved it!

Tags: agile, daylog, pad, solutionlog

Came across another small bug with m2eclipse yesterday when editing an XML schema in a project that used  the Maven plugin for JAXB (jaxb2-maven-plugin).  You may find Eclipse complaining that it cannot build your project because of this error:

An internal error occurred during: “Building workspace”.
Provider org.apache.xerces.jaxp.SAXParserFactoryImpl not found

The underlying problem may be due to classloader funkiness with the embedded version of Maven (since command-line Maven works fine) or some transitive dependency not being handled correctly.

Anyway, the workaround mentioned in this bug on the Codehaus JIRA solved the problem.  The solution is to explicitly add Xerces as a dependency to your POM:

<dependency>
    <groupId>xerces</groupId>
    <artifactId>xercesImpl</artifactId>
    <version>2.8.1</version>
</dependency>

Once you’ve done that, right-click on your project in the Package Explorer and select Maven > Update Dependencies. Eclipse should then be able to rebuild the project.

Tags: eclipse, jaxb, m2eclipse, maven

Here’s a tip for a very specific problem I recently encountered when using Maven and the Felix maven-bundle-plugin in Eclipse, and I’m sure it can happen with other plugins. There wasn’t an immediate answer to this problem when I used Google to search for it.

When Maven is running in offline mode (set in the Maven section of the Eclipse preferences), if you haven’t specified a version for certain plugins — like the maven-bundle-plugin — Eclipse will report an error like this:

Project build error:Cannot resolve pre-scanned plugin artifact (for use as an extension): org.apache.felix:maven-bundle-plugin: Failed to resolve extension plugin: org.apache.felix:maven-bundle-plugin:maven-plugin:RELEASE

Maven outside of Eclipse will most likely continue to work fine, but Eclipse will be one unhappy camper.  Your project may even lose its Java nature if m2eclipse is unable to resolve the dependencies.

The solution is to either allow Maven to run in online mode (Preferences > Maven) or add a <version> element to the plugin configuration (see example below). It seems that specifying the version in the pluginManagement section of the pom.xml may not even solve the problem.

<plugin>
	<groupId>org.apache.felix</groupId>
	<artifactId>maven-bundle-plugin</artifactId>
	<version>1.4.3</version>
	<extensions>true</extensions>
	<configuration>
		...
	</configuration>
</plugin>

Once you make one of these changes Eclipse/m2eclipse should rescan the project and fix it.  If it doesn’t get fixed immediately, right-click on your project in the Package Explorer and choose Maven > Update Dependencies and Maven > Update Project Configuration.

Note: I’m assuming you’re using a stable development build of m2eclipse. The non-dev version didn’t have these options when I last checked.

Tags: eclipse, felix, m2eclipse, maven

…it’s what you did while you were there.

Instead of focusing on the candidate’s skills, many companies wrongly focus on what school the candidate received their degree from.  In their minds the better reputation and rank of the school they attend, the better the candidate.  That’s a huge mistake.  There are plenty of good software engineers that come from little-known schools; they just don’t have the luxury of a top-tier school’s brand and reputation to get them in the door.

Aside from actually considering a candidate’s skills and experience, another trait I always look for is whether or not they have a passion for computer science.  Too many of the students (and even new college graduates) I’ve interviewed have had no industry experience (including graduate students!).  They claim to love computer science, but when asked about side projects – things outside of their assigned course work – they all too often have nothing to say.

I like hiring people who made the time to try something without an external force motivating them.  These are the people that are interested enough to explore something they don’t know about and play around with it until they understand it.

In short, look for students that know how to get shit done.

While reading Chip and Dan Heath’s book Made to Stick several weeks ago the following point caught my attention:

Many armies fail because they put all their emphasis into creating a plan that becomes useless ten minutes into the battle.

A similar problem occurs when planning a software development project.  A significant amount of planning can occur and then when the developers start writing code, the plan goes out the window.

So what is the solution?  The Heaths explain the answer to the traditional case: a concept called Commander’s Intent that was developed by the Army in the 1980s.  I had not heard of CI before reading their book, but came across it again today in James Surowiecki’s The Wisdom of Crowds.  For those not familar, here is the explanation from Made to Stick:

CI is a crisp, plain-talk statement that appears at the top of every order, specifying the plan’s goal, the desired end-state of an operation.

The CI never specifies so much detail that it risks being rendered obsolete by unpredictable events.  “You can lose the ability to execute the original plan, but you never lose the responsibility of executing the intent.”

Perhaps in the software development case the notion of CI manifests itself as a release theme or goal?  If this is true, it’s not clear to me how much value it actually provides because there are no details.

With the CI at the top of any order a soldier essentially knows the minimum amount of work that needs to be done.  With a CI in a software project plan it doesn’t seem to define the scope of the release well enough.  Or does it?

Tags: agile, commanders intent, communication, made to stick

Stacy and I ordered Wii Fit from Amazon when it first became available for pre-order back in April and it was finally delivered on Wednesday. We’ve been using it consistently for the last three days and while it’s got some fun activities that definitely get me exercising, on the whole I’m not all that happy with it.

I find that Wii Fit suffers from the same problems as Wii Sports: too many things to acknowledge, poor feedback when trying to learn activities, there isn’t a “play” mode, and the activities are actually fairly short. I’ll explain each in a little more depth.

First off, is anyone else as sick as I am of having to hit the A button all the time to acknowledge pithy little comments from the game or its characters? I want to play the game, not respond to dialog. I find this happening in too many Nintendo-produced titles (Paper Mario, Wii Sports, Mario Kart Wii). I’d really like a “quickplay” mode where it lets me jump right into playing instead of having to specify a lot of options or respond to prompts.

As for feedback, the sports titles are pretty unforgiving when it comes to executing an activity. I got extremely frustrated with some of the tennis and boxing training in Wii Sports. I knew I was doing it wrong, but the game didn’t give any hints as to how I could improve my skills and in the case of tennis, once you miss one ball, it’s over and you need to start from the beginning.

The next gripe is related to the last; many times I really don’t care how well I do on an activity or game, I just want something to help me unwind and play around. The Nintendo titles are too structured, in my opinion. You can’t just head soccer balls endlessly, keep skiing for twenty minutes, or just keep belting out home runs. How many of you prefer unstructured play to rule-driven activities?

My final complaint was the shortness of the sports activities; it’s related to the previous point, but even if I were trying to get a proper workout I find myself spending just as much time navigating through menus and dialogs just as much as I am performing the activities. I get that Wii Fit tries to ease you into exercising and gives you more reps or time when you’ve mastered the basics, but sometimes I just want to keep doing something until I perfect it, instead of having to start anew each time.

Tags: nintendo, structure, wii, wii fit, wii sports

I started reading Fast Company recently and in this month’s issue there was a pretty interesting quotation in an article about Patagonia exploring how green their products are:

Dumain concludes that the benefits of openness outweigh the costs, because the company wants to spur others to action: “Our influence is larger than our impact. If we’re willing to share that information, it becomes exponential.”

That’s a pretty powerful idea, especially when it’s applied across the business and not just to a company’s green activities.  It’s too bad more companies don’t believe in this; sharing information and being more transparent can not only increase your influence, it can also help turn customers into evangelists for your company and products.

Tags: openness, transparency

I’ve been running into a fun bug with Firefox on Linux, Windows, and Mac OS X. Opening a new tab while another one is actively loading content causes the browser to crash.

As a good open source citizen, I was going to go report the bug, but then I saw the Firefox bug submission page. To summarize:

1. Use the latest nightly build of Firefox and create a new default profile
2. Determine which Firefox component is causing the bug
3. Verify that the bug has not already been reported
4. Read the bug writing guidelines

While I’m willing to do some extra steps, like capturing a backtrace, I’m not about to go jump through a bunch of hoops to report a bug that will probably sit there untouched in Bugzilla. So I didn’t bother to report the bug.

When opening bugs the onus should not be on the end user. If you want me to report bugs in your software, you need to make it take only a few clicks. I don’t mind installing debug packages as long as the heavy lifting is done for me (and I refuse to install software that cannot be managed by apt or whatever package management system is used).

There are a number of solutions that people have come up for the easy submission of bugs. Apple and Windows have built-in crash reporters. Netscape had Talkback (which is now unsupported). GNOME has Bug Buddy, and Google has released Airbag (now Breakpad).

Sadly each of these have potential drawbacks. Bug Buddy reports the stack trace, which isn’t useful if debug symbols aren’t available (you can’t tell where the various threads were when the program terminated). Breakpad and the Windows crash reporter send memory dumps, which causes me to worry about what private information is going along with it.

I’m sure others will eventually come up with a good solution to this problem, but the important thing for developers to remember right now is this: your end users have only decided to use your software; they have not agreed to be developers or your guinea pigs. Do not treat them as such, even if the bugs they submit are vague, unreproducible, or not helpful. If you upset your users, they won’t remain so for long! If it’s open source they don’t have a financial incentive to see through like commercial software licensees do.

Update: I think I should issue an apology to the Firefox team. As pointed out in a comment, the page I referenced are suggestions for bug writing. And much of my frustration lies not with Firefox, but with the usability of Bugzilla itself (and not just the Mozilla instance of it). And to be perfectly clear, it was not the Firefox project treating users like guinea pigs. Thanks to Gavin Sharp for taking the time to comment.

Tags: bug reporting, firefox, open source