Ugly comments = ugly code

I like the blog entry that Will Kruse found:

http://www.itworld.com/development/84780/if-comments-are-ugly-code-ugly

I associate it with "code hygiene." It basically explains that programming is "detail oriented" and if a programmer isn't willing to take the time to make the comments correct (everything from semantics to syntax to spelling), then chances are they aren't taking the care necessary to make the code correct, either. Lots of evidence of "TODO" items or "Does this work?" comments are an exact indication of code health.

I find this true in the code I write. And it doesn't necessarily equate to the volume of comments. When I really dedicate care to what I'm developing, the quality of the comments tend to reflect the same level of the code quality. (I also tend to be a very pedantic, verbose commenter.) On the other hand, when I slam stuff together, I (being the pedantic verbose type) tend to write long winded comments explaining logic with questions and hints at potential bugs. "Well ... I think this is going to work" and "TODO: finish this," etc.

Interesting food for thought.

Using CollabNet desktop explorers with Team Forge

There are a couple Windows desktop plugins that I've used for working with documents, artifacts, and tasks in Team Forge.

• SourceForge Explorer - Windows .NET application that interacts with CollabNet Source Forge online web application to work with documents, artifacts, and tasks.
  
• TeamForge Explorer - same .NET application as Source Forge explore but updated for new Team Forge naming and feature set.
  
• CollabNet Desktop Windows Edition - a different (also .NET) implementation that seems to share code implementation with the Eclipse edition of the same tool.
  
• CollabNet Desktop Eclipse Edition - plugin for Eclipse for working with code, tasks, artifacts, and Documents.

This can be downloaded from CollabNet:

http://desktop-vs.open.collab.net/servlets/ProjectProcess?pageID=3794
(goes to here: http://www.open.collab.net/servlets/OCNDirector?id=CICDWE1.2)

The latest Desktop Windows Edition seems to be pretty damn good. Best feature: you can edit a document IN PLACE. Click to edit, opens directly into Word, then when you save, it goes directly back to CollabNet. It even asks for a version comment.

HOWTO Ubuntu network configuration in VMware

I've run a couple Ubuntu images on my machine lately and keep forgetting how/where to re-initialize the network settings. The easy answer is:

/etc/network/interfaces

Then rerun the network startup script:

/etc/init.d/networking restart

Bingo. It should reset the networking stuff.

To make this work properly in the VMware image, you need to make sure that "Devices > Network Adapter > Connect has been selected. I typically use "NAT" mode which results in outgoing connections from the VM, incoming traffic from the host OS, but the VM is not reachable by other machines on the network. "Bridged" will allow reachability from the network, but probably requires that you can get multiple DHCP addresses from the same MAC.

First adventure in dirt biking

I get to scratch another item off my personal bucket list. I've always wanted to learn to ride a dirt bike. Last weekend a friend took me dirt biking (think 'motorcycles in the woods') out in George Washington National Forest in western Virginia near Edinsburg, VA. It was a great time. The particular set of trails was called Peters Mills Run and (maybe?) Taskers Gap. More information here: http://atvconnection.com/Resources/ATV_Trail_Guide/Mid-Atlantic-ATV-Trails.cfm

We spent a bunch of time on hard pack clay trails infused with rocks (typical VA terrain). Some of the hills were pure jumbled bunches of rocks (think baseball and soccer ball sized gravel). Some was more of a "loumey" terrain with sand/dirt mix. It had rained a lot, so there were lots of puddles and a lot of general slipperyness. I found my weak points were located in sharp turns with berms that you were supposed to use as banking for turning. I could never get it right and would wash out the front wheel and take a tumble. It even resulted in one very nice over-the-bars tumble when I washed out the front, hit the berm, and went flying.

I have to say -- it was a blast. We only went about 28 miles, but it was fun and very tiring. I road raced motorcycles briefly about 10 years ago, but hadn't been on a bike since then. This was waaay different, but very enjoyable in a completely different way. I have to admit to being a bit bashed and bruised, but generally fairly well off. The friends I went with said I did quite well for the first time out. I attribute that to a combination of previous motorcycle experience, mountain biking experience, and jet ski racing experience. It still resulted in a half dozen spectacular wipeouts, albeit at slows speeds (10-15 mph). Thankfully, the body armor works fairly well. (Note to self: make sure elbox pads are tight enough to not slide up your arm when you hit the ground, leaving big road-rash skids up your forearm.)

I was riding a 4-stroke 450cc bike that worked pretty well for me. (might have been a hond CR 450?) It was nice that it was very torquey and could easily grunt it's way out of low RPM pulls. This reduced my need to shift, which was quite helpful given the fact that I hadn't ridden a bike in 10 years and the clutch/shift/brake/turn/throttle thing was much less natural than I remember it. The clutch was cable driven and VERY stiff for my weak wrist.

On the day after, my forearm is very sore and rashed from my first fall. Otherwise, I've got a small bump on the knee and my quads are getting more sore by the moment. Overall: not to bad for my first experience.

Some notes to myself for pointers:

• Riding standing up is the way to go. It allows the bike to move around under you and react to bumps much better
• When standing (or sitting), keep the pegs in the arch of your foot, not balls. Not sure why, but it works. Definately keeps your calves from tiring, as well.
• Motocross boots are heavy and have NO feel to them. (Shifter or brake) You learn to get more of a feel of whether the brake is working from the way the bike reacts.
• NEVER react by grabbing the front brake. There's not enough traction usually, so it will most likely just wash out the front wheel. Learn to use the back brake.
  
• When in doubt, give the bike blips of throttle. It behaves much better when it has a little momentum.
• Dirt bike leaning/balance is the opposite of road bike. With a dirt bike, you lean the bike over, but stay upright on top of it. Use the back wheel to brake/throttle slide and get it pointed right, then accelerate. (Road bike you slide down inside the bike, keeping it leaning up to get more ground clearance.)
  
• Most of the time, you want to keep your weight forward to avoid wheelying. Expecially going up hills.
  
• The suspension's ability to go over huge rocks and bumps is amazing. Use it.
• When sitting, get forward in the V of the saddle so you are near the center of balance. Tendency is to sit back, which means "wheelie."
• Don't even think about going out without the right gear unless you plan on doing nothing but roads. And frankly, that might not even be wise. More armor is better when you are learning. (heavy boots, knee guards, elbow guards, chest protector, gloves)
• It is waaay more tiring than I expected. That might have been a result of the hill climbs and rock scrambles we were doing which requires quite a bit of concentration and bouncing around.
  
• Camelback is good. Drink a lot.

And finally, remember: you suck. Be humble. The mountain bites back.

Subclipse handles file renaming (refactoring) of Java classes properly

I started playing with CollabNet desktop and particularly Subclipse within Eclipse. Some things I liked.

Refactoring

Subclipse DOES handle refactoring of classes. That is, if you rename a class, it will create subversion events to delete the old class and add the new class. For example, renaming A.java to B.java shows a "Add B.java with copy-from path of A.java." This means that it preserves the version history over time.

To refactor without the subclipse plugin, I had to do the following:

• Use "Rename" to rename the class. This fixes all the code and simply renames the existing file as the new file. (OldClass --> NewClass)
  
• Do a SVN "Update" to get the old file back in the directory (OldClass.java)
  
• Delete that OldClass.java file and rename the NewClass.java back to OldClass.java. SVN should show you that the file has been locally modified.
• Do a SVN Rename to rename OldClass.java back to NewClass.java.
  
• SVN "Check for Modifications" (status) should show you a "delete" of OldClass.java and a "add" of NewClass.java with a copy-from path of OldClass.java

Definately a hassle. It's nice that Subclipse makes it all work properly.

I also noticed that Subclipse and Tortoise SVN seem to "play nice" with checked out versions of code. That is, you can alternate back and forth between using Subclipse and Tortoise to operate on files.

Great stick figure explanation of AES encryption

I really enjoyed this. It gives a great "poor man's" introduction to how encryption like AES works, how it is fast, yet how it is backed up by some really mind-blowing math.

http://www.moserware.com/2009/09/stick-figure-guide-to-advanced.html

HOWTO Include Subversion version identifiers in your Java source code with Eclipse

It's often useful to include version markers in your source code files, especially when it's possible they will be distributed outside the bounds of a version control system. In my case, I'm using Subversion and Eclipse to write code.

Subversion provides keyword substitution for special keywords that are managed by Subversion during checkin an checkout. (See: http://svnbook.red-bean.com/en/1.5/svn.advanced.props.special.keywords.html). These include Date, HeadURL, Revision, Author, and Id (a combination of the others). You can embed these in your text files and SVN will automatically replace them with appropriate values each time. To enable this, you need to do the following:

svn propset svn:keywords "Id HeadURL Revision Author Date" foo.java

Then, you embed a keyword like "$Id" in your file and next time SVN updates your file, it will replace the $Id string with something like $Id: foo.java 148 2006-07-28 21:30:43Z sally $.

To make this easier, you might want to change the [auto-props] section of your config file to automatically set this property any time you create a new java file:

*.java: svn:keywords="Id HeadURL Revision Author Date";svn:eol-style:native

Typically, this is embedded in a comment block. To make this easy, you can include it in your Eclipse file templates so things get pre-populated when you generate new files.

For general purpose insertion in all your Java source files, use Window > Preferences > Java > Code Style > Templates, then edit the "Files" entry and add the following to the template:

/*
*
* $$Id$$
*/

That will automatically insert the "$Id$" tag into any new source file you create.

Another reference:
http://wiki.collectionspace.org/display/collectionspace/Java+Source+Files+-+Beginning+Comments+Block+Template

For more advanced usage, you can embed a string in a variable that gets compiled into the object code and can be used to identify versions of binaries.

For Java, insert a piece of code that looks like this:

// version identifier automatically filled by svn:keywords "Id"
public static final String __class_id = "$Id$";

This will expand when the files are checked in to be representative of the version of code that was committed.

This can automatically be inserted in new classes with code templates, again. Window > Preferences > Java > Code Style > Templates > Code > Class body. (Make sure you use $$ for the dollar signs when you create the template.)

Pitfall: Make sure you have cleanly committed/updated files when you do this. Don't make the mistake of building your modified code that is checked out, then distributing it. Once you commit this code, the version number will bump up and potentially be different.