I’ve created visualizations for Git repositories before – the one tracked a product from its first commit through launch. And while I still think there is some information and insight to be gleaned from such visualizations, the real reason I like to make them is... I think they're neat.

To celebrate launching the latest incarnation of VersionOne, I made another visualization! This one tracks all changes made in our Git repository that occurred between our last major release (in late February) right through the very last commit that made it into the Spring 2011 release.

Wow… that really sounded like a sales pitch, didn’t it? I hate sales pitches!

Enough of that. Enjoy!

Uploaded with Skitch!

To rebase, or not to rebase… for me its not really a question. I generally prefer a clean, linear commit history. Why? Because merge bubbles make history confusing, noisy, break git bisect.

Don’t believe me? Check out the pretty log to the right. See all those merge bubbles in there? Eww!

The Why?

The workflow that caused those merges was as follows:

1. git pull (to bring local up to date)
2. hackity-hack
3. git commit
4. git pull
5. git push

By default git pull will fetch any new commits from the remote, and then merge any local changes in, resulting in the merge bubbles.

A better approach

I typically use the same workflow as above with one tweak. Rather than git pull, I use git pull --rebase, which will fetch the remote commits, and rebase your commits on top of the new commits from the remote. This is the “re-writing” of history folks often talk about.

Make it better, automatically!

You can tell git to use rebase, rather than merge, in one of two ways, depending on your situation.

To have all future branches automatically use rebase

$ git config branch.autosetuprebase always

You can add the --global switch to have all future branches, in all repositories on this machine, behave this way.

If, however, you have an existing branch, you’ll need

$ git config branch.branch-name.rebase true

Get more info

Be sure to check out the git man pages for more info on what those options mean and when you may or may not want to use them.

You might also want to check out my Git Workflows repository on The GitHubs where you can find a Keynote presentation (or PDF in the Downloads) explaining git rebase vs. git merge. Complete with pictures!

Who here doesn't enjoy a little color in their life? I know I do, especially when used to highlight the syntax of a language - as anyone who's been around me while downing a few pints can attest!

Learning, Io, and Vim

In an attempt to feed our insatiable desire to learn, a few of us at VersionOne are doing a book club on Seven Languages in Seven Weeks. We’re currently working on chapter 2: Io. My current favorite editor is Vim. I wanted syntax highlighting for Io, in Vim.

I found a decent Vim script to get Io syntax highlighting, and then wrote a quick ftdetect script to set Io-related files to use the Io syntax. The resulting vim-io plugin is currently embedded in my dotfiles on the GitHubs, but if there’s interest I can pull them out into a standalone plugin.

Grab it, enjoy it, fork and improve it!

I’ve long thought that Caps Lock was quite dumb. Yes, I’m sure there is some archaic reason it exists, but the truth is I don’t care. I don’t find it useful and am annoyed that it’s taking up valuable room on my Home Row. The more I use Vim the more angry I get at the Caps Lock key.

Making Caps Lock Useful, on The Mac

I long ago remapped Caps Lock to Esc on my Mac – which worked great for TextMate. However, these days I spend the majority of my time in Vim or Zsh (in Vim mode) where I’d much prefer to have Ctrl on my Home Row. Remapping Caps Lock to Ctrl is trivial on OS X; it’s baked in via System Preferences > Keyboard Preferences > Modifier Keys.

Making Caps Lock Useful, on The Windows

To my knowledge, there is nothing baked into the OS that makes this easy, but there are a handful of utilities that will let you remap most keys. I opted for the Lo-Fi route - hacking the registry to remap Caps Lock to Ctrl.

To use it, just download/save the raw .reg file to your Windows box, and the run (double-click, whatever) it.

And there you have it. Good bye, annoying Caps Lock. Hello, useful stuff!

Its one of those stories we’ve all heard before: you spend hours tracking down some odd-ball behavior/bug only to realize its your own stupidity coupled with inconsistencies in browsers that has caused the vein in your forehead to start throbbing. This particular story goes like this:

The Expectation

Assuming you have an HTML form with a textarea field, pressing the Enter key should add a new line inside the textarea. Pressing the Enter key in other form fields will submit the form, assuming you have a submit button, form-action, etc.

The WTF Behavior?

Given the above, Chrome, Firefox, Safari all act as expected. Internet Explorer, however, incorrectly submits the form… WTF?!?

The OMFG Cause

After way too much toil and trouble, the cause of the unexpected, and unwanted form submission was an errant type=”text” attribute on the textarea element. IE was correctly rendering the element as a textarea, but treating it as an <input type=”text” />.

The Root Cause

A quick Git-blame showed that the textarea started life as an <input type=”text” /> and didn’t finish its metamorphosis, leaving behind the errant attribute. Oops!

As we strive to build more humane user experiences it is important to not only consider what data to, or not to, show, but also how we present that data.

An example from our recent Conversations feature is the date and time at which portions of a conversation take place.

Notice the two highlighted areas. The tooltip shows fully-formatted, and much more precise information, with the “less than a minute ago” text being a more fuzzy, human-friendly presentation of the same data.

There is no question that the precise data is valuable, but when it comes to human users of a system, it may not be the most consumable form. The full-fidelity information is still available to the user who cares to engage the application, when he cares to engage it.

Whether its fuzzy dates and time, or using avatars instead of user names, or any number of other examples, the point is to think about the human experience when designing for, well, humans.

A few months back I gave little talk on the darling SCM tool of the Open Source world, Git. After the conference, the organizers asked for a copy of the presentation materials I’d used – something I usually find little value in as the content of a discussion is far more than just the collateral used.

At any rate, I obliged and sent off a PDF… and in the spirit of Open Source, I’ve also opened the talk up for others to use and improve! You can find the source (Keynote presentation, images, etc.) on GitHub – where you can fork and modify the talk to your heart’s content!

Oh, and the PDF is there too.

Enjoy!

… that have helped me improve both my understanding of JavaScript, and my jQuery-Fu.

General Goodness

• Custom events in jQuery open doors to complex behaviors
• Six Things Every jQuery Developer Should Know
• How to Create Your Own jQuery Plugin
• Introduction to Stateful Plugins and the Widget Factory

Some Tools

I’ve also come across of few kick-ass Firebug plugins you won’t be able to live without.

• FireQuery: a Firebug extension for jQuery development
• FireFinder: Finds HTML elements matching chosen CSS selector(s)

You can also check out my del.icio.us feed for my favorite jQuery resources. If you have some favorite article or resources, please link them in the comments!

Remember, learning is a primary input to improving!

At least half a dozen times in the past three days I’ve been so annoyed by the payment process for various goods and/or services that I either didn’t purchase the thing, or had a minor meltdown after the whole ordeal was over.

Why do merchants insist on making it so damned difficult for their customers to get the goods?

A few frustrating examples

Ever been to a sporting event where the beer vendor only accept cash, has no cash-register, and yet insists on charging a partial dollar amount per unit of booze? $6.65 for a beer… really? Just call it $7 and make the math easy for everyone. Or have a cash register at each kiosk. Or, here’s a novel idea, start accepting plastic!

Need to renew your vehicle registration? Just do it online! But be prepared to spend an extra $5 for the convenience of, you know… actually giving them the money now rather than sending a check and them having to pay someone to physically handle the thing.

Two simple rules for making money

If you’re selling something someone wants: make it easy for them to give you their money!

If you’re selling something someone does not want: make them want it!

I don’t know about you, but I like pretty things. Things that engage me. Shiny things. I enjoy seeing the same old thing in new and interesting ways. I suppose I’m just a visual kinda’ guy.

Unfortunately, the desire for visual representation is at odds with the high bandwidth flood of information we’re subjected to these days. Even if we manage to trim the overwhelming flood of information down to a laser-focused stream, it still takes an immense amount of effort to make sense of it.

For example

For years the primary way we’ve looked at the activity or interaction within various source control management systems is via log files. Yep… plain, text-laden, indecipherable logs chock full of entries each a similitude of it’s predecessors.

However, thanks to projects like Processing there may be a change on the horizon. Using tools of their ilk we can build exciting new ways to see and consume the vast seas of data we’re drowning in. By visualizing the data we are able to discover new and interesting patterns, behaviors, and insights.

An example

The video to the right is an example of one such visualization I produced using Gource to analyze the Git repository of one of the product’s we’ve build at VersionOne.

For reference, each branch (line) is a different directory containing files. Each leaf (dot) is a file, and different file types (Ruby, JavaScript, C#, etc.) have different colors. Each contributor is represented by their name and Gravatar.  The colored lines that occasionally connect a contributor to a file are color coded to represent adds (green), changes (orange) and deletes (red).

A few interesting things this visualization leads me to think about are

• how much churn happens in various parts of the code base?
• where are we spending time?
• is new-feature work well isolated? (perhaps an indicator of composition)
• are there specialists within the team?

Do any interesting things pop to mind when you watch the video? Let me know by leaving a comment.