StevenHarman.net

A Handful of Git Workflows for the Agilist

Steven Harman — Thu, 12 Aug 2010 15:49:27 GMT

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!

Technorati Tags: git,Open Source,presentation

A Handful of Great jQuery Articles…

Steven Harman — Tue, 22 Jun 2010 18:05:33 GMT

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

General Goodness

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!

Technorati Tags: jQuery,javascript,learning,improvement

Want To Make Money? Make Getting Paid the Easy Part!

Steven Harman — Wed, 07 Apr 2010 16:20:10 GMT

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!

Technorati Tags: business,customers,don't be dumb

Gain New Insights by Visualizing What You’ve Already Got

Steven Harman — Wed, 24 Feb 2010 21:11:21 GMT

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.

Technorati Tags: gource,git,design,visualization

Has Visual Studio caused the end of The World yet?

Steven Harman — Thu, 18 Feb 2010 20:53:54 GMT

If this error dialog is any indication… the end may be imminent!

#FAIL

Let’s just hope this error dialog never makes an appearance in a nuclear energy plant, missile silo, etc…

Technorati Tags: visualstudio,funny

Why don’t we ask “Why?”

Steven Harman — Thu, 18 Feb 2010 17:48:39 GMT

Have you ever thought about just how much time we software folk spend focused on the technologies we’re using, on implementation minutia, and on all of the shiny new solutions we should be using?

Now contrast that with how often we stop to think about the whys?

Why are we being asked to solve fizz-buzz-thing; do we understand the motivation and context behind the problem, or are we fixated on how we’ll build the solution? Are we asking why a problem occurred, or are we merely focused on how we fixed it, this time?

Why don’t we ask “Why?”

Frankly, because we’d rather spend our time in the comfortable arena of how than venture into the sometimes uneasy realm of why.

She didn't want to know how a thing was done, but why. That can be embarrassing. You ask Why to a lot of things and you wind up very unhappy indeed, if you keep at it.

- Captain Beatty, from Fahrenheit 451

Asking why often forces us to face the truth, and that truth can be uncomfortable. We need to have the courage to face those truths and continue to ask why; we must have the courage to pop the why stack.

It’s only by asking why that we’ll gain the understanding, insight, and context necessary to effectively solve the problems we’re faced with, to grow, and to improve.

So, why are you reading this post…? :)

photo credits: http://www.flickr.com/photos/marcobellucci/ / CC BY 2.0

Technorati Tags: courage,agile,XP,lean

YAGNI ain’t what you think it is

Steven Harman — Thu, 07 Jan 2010 19:44:29 GMT

In the software development vernacular the term YAGNI is often used as a device to put down attempts at prematurely adding functionality – things which are only speculatively required. This makes sense given that is basically the definition that Ron Jeffries and our XP forefathers came up with so long ago.

Is that the whole story?

In short, I don’t think so.

I’ve long believed there was more to YAGNI than what had been canonically defined and was commonly understood. However, until recently I was never able to put my finger on what was missing.

While listening to an episode of

Industry Misinterpretations I heard Kent Beck make a subtle point about the need to make progress being more important than the completeness of the thing you’re building at the point you’re building it.

Lending from this Kent’s insight and mixing in much of my own experience, I realized YAGNI is not about delaying building things until you need them; it’s that gaining real experience in the problem domain, while making concrete progress, is more important than trying to achieve a complete solution right now.

Do you think it’s too early to update the Wikipedia article…? hehe!

Technorati Tags: design,XP,agile,programming

OMG, Better Rake (for .net)!

Steven Harman — Mon, 23 Nov 2009 23:29:55 GMT

If you ask me, when it comes tools for writing automated build scripts nothing packs more bang for the buck than Rake. Until recently, using Rake to build .net solutions required a magic concoction of hacked together scripts which rarely exhibited Ruby’s appreciation for beauty nor Rake’s spirit of simplicity.

Luckily our buddy Derick Bailey decided it was time to bite the bullet and start building some real Rake tasks that were special suited for building .net code. The result is Albacore.

Using Rake for .net IRL

I’ve been using Rake to be lazy for a while. And we, the VersionOne dudes & dudettes, have been using it to help automate our CI builds for over a year now. And just last week we started ditching much of our hacky-Rake-script inventory in favor of more concise, tested, and readable Rake tasks via Albacore.

During the migration I’ve run into a few small hitches here and there, but nothing that I couldn’t track down, write a test for, and fix within a couple of tomatoes. In one case I discovered an issue, called Derick to confirm, suggested a fix, and had a new Albacore Gem published within a couple of hours. Hawt!

Albacore already has a decent number of tasks baked in, and the list is growing all the time!

AssemblyInfoTask – Generate an AssemblyInfo.cs file. Currently only supports C#
ExpandTemplatesTask – expand template files with #{setting} markers, using YAML configuration files as the data
NCoverConsoleTask – Run code coverage analysis through NCover 3’s NCover.Console
NCoverReportTask – Check code coverage and get detailed reports through NCover 3’s NCover.Reporting
NUnitTask – run NUnit test suites
MSBuildTask – Build a Visual Studio solution (.sln) or MSBuild file
Rename Task – Rename a file
SftpTask – Upload a file to a remote server via secure FTP connection
SQLCmdTask – Run scripts and other commands through SQL Server’s “sqlcmd.exe”
SshTask – Run a command on a remote system via a secure shell connection
ZipTask – Package your build artifacts into a .zip for easier distribution
source data

Contribute!

As we move more and more of our custom stuff over I’ll continue to add features to Albacore, enhancing the great work the core team is doing. In fact, I’m already planning a NAnt task to help those folks in the process of migrating from an existing NAnt-based build script to Rake. Look for it soon!

Resources

Albacore on GitHub
Albacore Wiki
OMG Rake! – The original post which first inspired many to use Rake with .net

Technorati Tags: rake,ruby,.net,open source,albacore

Reading Code is Key to Writing Good Code

Steven Harman — Wed, 18 Nov 2009 22:32:57 GMT

As humans we seem to have an innate desire for structure in our lives. Structure permeates through our societies; it’s found within our families, education systems, governments, etc. I suppose it’s no surprise then that we also seek to force structure upon the work that we, as software developers, do.

The problem is the work we do isn’t structured. It is not deterministic. There is no grand blue print, process, nor methodology that we can follow to pay dirt.

We live in a chaotic and complex world that is itself continuously changing and adapting.

Software product development is a creative activity taking place in the midst of that complex and adaptive world. So doesn’t it make sense that we, as software developers, might benefit from admitting that we are indeed doing creative, unstructured, adaptive work? I sure think so!

Looking outward for inspiration

I’ve recently been looking outward to other creative professions and trades for inspiration and insights into how they work. One thing I’ve realized is that those folks spend an immense amount of time studying and seeking inspiration from the work of others both within and outside their own field.

For example, a musician doesn’t just sit in his garage all day, banging out albums. He listens to and is influenced by the music of many other musicians. An author doesn’t simply site down and write manuscript after manuscript. She spends countless hours reading the classics, studying the words, flow, and style of other authors. The same thing goes for painters, actors, architects, etc. And all of these people are constantly immersing them selves in works outside their area; musicians reading Hemingway, singer/song writers studying Salvador Dali, painters listening to Mozart, cats and dogs living together…

How arrogant of we programmers then to think that we won’t, or don’t, benefit from reading code written by – gasp – someone else!

Read, learn, and be inspired

In my experience we spend a great deal more time reading code than actually writing it. Whether it be the code you wrote just a few minutes ago or something you’ve inherited and are now maintaining, you’re reading it. Of course, that’s only considering the motive of reading code because you’re currently working with.

The greatest motivator for reading code is the opportunity it provides for learning and serving as a source of inspiration. Reading code exposes you to techniques, view points, styles, idioms, and algorithms that you may not have otherwise come across.

In my own career it was by reading code written in Ruby that I first started to develop an appreciation for beauty and aesthetics in code. It also opened me to new ways of thinking about problems and exposed many pains and frictions with the techniques I had been using to that point.

Where to start?

I realize it’s probably obvious, but I’m going to say it anyhow – a great way to start reading other’s code is to pull down an Open Source project and dive in. Of course, that’s not to say that all Open Source code bases are necessarily examples of great code… so you might also want to leverage your network to find examples. Or, use your Google-fu to see what others are reading. Or maybe check out:

Katacasts by Corey Haines and Chris Parsons
The Weekly Source Code series by Scott Hanselman
other suggestions… leave a comment and I’ll update this list!

Technorati Tags: programming,improvement,open source,code

Signing 3rd Party Assemblies without Recompiling

Steven Harman — Thu, 01 Oct 2009 17:54:15 GMT

We recently ran into an issue where upon pulling some new 3rd party dependencies into our product our CI pipeline broke! I when I say broke, I mean it came to a screeching halt!

We were totally unable to compile in Release mode due to the new dependencies not being strongly named and signed. The error message in the build log was

CSC : error CS1577: Assembly generation failed -- Referenced assembly 'MvcContrib.FluentHtml' does not have a strong name

Sign it yourself!

Eric Hexter, of the MvcContrib team, pointed me to a thread explaining how to strongly-name and sign the assembly without having to recompile it. After a few failed attempts, I ended up using the IL Disassembler and Assembler to get the job done. The template for a single DLL follows.

   1:  > ildasm {path\to\assembly}.dll /out:{path\to\assembly}.il

   2:  > move {path\to\assembly}.dll {path\to\assembly}.dll.orig

   3:  > ilasm {path\to\assembly}.il /dll /key={path\to\SigningKey}.snk

The second line could really just be a delete, but whatever. The point is, the third line is going to output a new DLL of the same name as the original, so get rid of the original first.

After that, I committed the new assembly into our source tree, the CI build pipeline kicked off, and we were back to green!

Technorati Tags: .net,trick,security