Duct Tape? Who Cares?

OK – I want to make this post as short as possible, since by posting this I am being a hypocrite.

Anyone in the geekosphere will have heard about the “whole duct tape thing” – no, I am not going to link to it.

All I will say is this:

Who cares?

Some of the best software I have used has obviously been hacked together really poorly. Some of the best games I have played have had corners cut to ship on time.

Conversely, I have used rock-solid software that has ticked all the boxes in development. But it’s useless.

Software is NOT about how we build it – it’s about how we USE it.

When the USER is sat in front of the PC, they don’t give a crap about the development methodology used, constraints applied to the project or the fact that Jimbo forgot to wear his wacky tie on Wacky Tie Thursday at the office this month.

Ultimately, what they do care about is:

• It works as expected.
• It doesn’t fail all the time.
• It protects their personal data (even if they don’t know about it).

So can we PLEASE all stop bickering about something that really and truly that doesn’t matter. The main people arguing are NOT going to change their mind, and the people in the middle will do what they feel is right at the time.

We are engineers – we are supposed to build the best possible solution with what we have available.

As for me? I am going to continue improving my craft, learning how I can write better code quicker and delivering projects on time.. I don’t care what camp that puts me in.

Work hard. Play harder.

Remote Pairing

Following on from my first coding dojo, I had an idea that I really wanted to try and push forward. Remote Pair Programming by this, I simply mean pairing up with another developer and working on some code. The key thing being, you are both on your own machine in different locations.

Why Remote Pairing?

The reasons for this are simple:

• It’s flexible – you don’t need to commute, organise a place to go, book offices, equipment – anything.
• It’s cheap – you only really need equipment that 99% of all developers will already have.
• It’s unobtrusive – aside from not cutting into your schedule so much, it also allows you to keep your system configuration (whereas pairing with someone else on their machine means you can lose a lot).
• The focus is the code, not the environment you are working in.

Why NOT Remote Pairing?

• It’s not as personal as working face-to-face with someone.
• Technical issues may arise which cause problems with the remote connection.
• It may require base training in the tools and technologies used (such as Git).
• Things like network latency can be much more noticeable, especially if you are used to a fast pace of work.

My First Remote Pairing Session

So, after a bit of a scout to see who would be up for a remote pairing session, the good Johnno Nolan (twitter) stepped forward as the first available to have a go.

We decided to have a go at Roy Osherove’s TDD Kata 1 since it was scripted and fitted well with our own objectives (I was really interested in seeing how remote pairing worked, Johnno was more into running through the kata and seeing how I worked).

Tools Used

All of the tools we used are freely available (obviously there are some pro things like Resharper used, but they are optional).

• C# and Visual Studio 2008 (IDE).
• Git (source code control).
• GitHub (for remotely sharing the repository).
• MS SharedView (screen sharing – so the navigator can see the driver working).
• Live Messenger (voice comms – we also tried GTalk but it kept crapping out).

Obviously, if you have better tools for any of the above, then please comment and let me know – would be keen to see if we can improve the list.

Getting Started

Now, we were rather slow to get started, and I totally take responsibility for it (two words: Jack Daniels). I woke up a little later than expected and was rather unprepared so had to go through some configuration and setup before we got started.

That said, I would strongly recommend that BEFORE the session you:

• Create a Git repository on GitHub and setup all required parties as collaborators. Then make sure they can push/pull to it.
• Have a quick chat before hand and ensure SharedView and Live Messenger are working good. This could also be a good opportunity to create rough plans and mockups for what work is to be completed in the pairing session.

How We Did It

1. Started working our way through the kata. First driver creates a failing test and then makes it pass.
2. Driver then performs any desired refactoring.
3. Driver then hands to navigator, who then becomes the driver themselves, they then right a “confidence” test. This ensures that 1) the code is definitely good and 2) they have a good understanding of why the code is working that way.
4. Go back to point 1. Rinse and repeat until the code is “to spec”.

Now, that said, we originally did start with the standard “red, green, refactor” and just bounce back and forward. But we found ourselves naturally discussing what we had done as we “passed the torch”. This then meant that we would often think of new tests and add them. We ended up calling these “confidence tests” since they boosted our confidence in how the code was running.

I found we did spend a long time discussing things – but I think this is mainly because we have never worked with each other. There is a lot to take in, but also a lot to put out. You are no longer hacking away on your own – you need to justify this code that you are writing to someone else now. I think as you get used to work with people, you begin to understand their style etc. Even though we spent a long time discussing, I felt all of it was healthy.

Summary

• I really enjoyed the session and engaging with someone who is obviously passionate about their code.
• SharedView really did shine, it’s very quick and simple to use and the fact that it auto-closes other sharing sessions when you begin sharing makes “passing the torch” a lot quicker.
• Git is awesome! Pushing/pulling the commits back up and down is so easy. We aren’t here to mess about with source control, we want working code!
• I feel pairing is a great way to work & ends up in very clean code. I was more than happy with our (albeit simplistic) resultant code. Especially since at times it “felt” like I was hacking, but once we discussed, we determined it was actually a good, pragmatic call.
• When passing the torch, get back to coding quickly – we often paused to chat and lost our focus.

I am really keen to keep these kind of sessions going – so if you are interesting in doing something, then please comment, or contact me on twitter!

Johnno has posted a great article on his blog over here – be sure to check it out!

Not a Geek on Fire, More a Smouldering Wreck

Last week, I had my first block vacation this year, I booked a week off based about work schedule and for the first time in a long time, I was genuinely really unhappy.

Why the Sad Face?

To be honest, on the Monday, I had no idea – I just felt really crappy and had no idea why. This set alarm bells ringing for me – I am normally a very focused individual so when I feel clueless, I know something is up.

So, I fired up MindMeister and got to brainstorming. I wanted to get to the root of things – and fast. This process took about 3 days for my head to start unwinding, which shows how much of a mess it was!

Work vs. Personal Life

Now, I know many people are a fan of the “work and personal life our separate”. While I agree that work ends when your shift is up, I do believe that work should be personal in that we should be passionate about it, embrace it, enjoy it and want to do better at it.

This attitude can be great when work is going well, but when things are not ideal, it can bring you down. I won’t go into details here but put it this way – I am not 100% at work at the moment. There are many things that I feel need to change both for the company and for me in my own personal development.

I took plenty of time out to:

• List the positives about my job and how I can boost them and make them more positive.
• List the negatives and come up with as many ideas/routes I can to fix them.
• List my core “wants” out of my employer and thought about routes to implement or needs for any change.

This gave me a lot of “food for thought” across the board..

Side Projects

Being a geek, I have been working on a couple of side projects (one of which is Tomato Timer). Since moving to my biphasic sleep pattern I have gone a bit crazy on trying to get other projects up and running.

The problem? I don’t give a crap about any of them.

Sure, of them, Tomato Timer was an interesting idea – but was it worth anything? REALLY? I don’t think so (or not as much as what is was costing me).

Since moving to kanban I have become very focused on value but sadly, I wasn’t really assessing it on things I had already started. This meant that while I have been good at not taking on new things since going to kanban, I have still been chasing my tail with the old.

So, my review didn’t end well for Tomato Timer, here is my current plan:

• I intend to fix a (major) bug that has appeared in Tomato Timer and then get the source code up on GitHub for people to do with it as they wish.
• I have other project ideas that I would like to work with, but these are very focused on technical goals that I would like to meet. Put it this way, you won’t see much more in the way of desktop apps from me for a while!
• That said, watch this space for web bits ;)

Personal Life

Ahh the personal life.. Where to start? What personal life? For the last year and a half I have just been a complete freaking nerd. I have been so focused on studies etc I have let living pass me by. Couple that with the “chasing tail” feeling due to the above – it leaves a real bitter taste.

The truth is this, I miss my friends, I miss my family, I miss ME. I’ve always had a “work hard, play hard”  attitude, but at some point – I stopped playing!

I have some interesting ideas for the personal plan.. Won’t go into details until I have something more concrete.. But let’s just say “I am cooking up little somethin-somethin” and I feel good about it all.. Really good.. :D

Rob’s Final Thoughts (AKA “The Point of this Post”)

So, let’s try and wrap up my thoughts into a few points:

“Busy” is not always “Productive”

First off, let’s be clear about what we mean by “productive” (or perhaps, what it should mean) – productive is creating things of value. I’ve been going at the grindstone for a long time and I feel that I have produced very little. Ipso facto - I have produced very little. 

Burnout is Sneaky

Burnout is one of these things that you don’t know you have until you stop and you feel everything cave in (both body and mind). During the week’s break, I slept.. A LOT.

I’ve learned from this – I have totally reworked the focus of my weekly review to look out for signs of burnout. I’ve started scheduling/forcing myself to have free time and - having finished reading “Yes Man” (great fun and very thought-provoking) I have started being a bit more open to new opportunities.

Avoid Burnout, But Keep the Fire Burning

Don’t let things like work kill your passion. Find ways to remove/get around issues that are dulling things down and get back into loving what you do. Keep focused on doing what makes you happy. The rest will follow naturally.

Don’t Forget to Play

After getting all this down, I went out for a few drinks with my flat mate. I was already feeling a lot more positive having gotten all my thoughts and feelings down. I ended up seeing a rocking band, meeting some great people and it literally made the last few weeks melt away.

One small amount of good play time can make a lot of lame time go away.. :)

In Summary

This wasn’t intended to be an “emo” post where I just whine (apologies if it came across that way). I just wanted to let people know why I have been so lame recently and why code/technical output here has slowed. I also wanted to cover the obvious key points that I noted in my review.

I hope this post gave you some food for thought..

How happy are you? Are you on a path to burnout? Are you already burned out?

Git: Getting Started with Aliases

Git has very quickly become my tool-of-choice for source control. It’s quick, it’s easy and it’s bloody good at what it does. It allows me to completely forget about source control, not fear things like branching and merging and just get on with writing code.

Git Aliases allow us to create shortcuts for common commands to make it even easier & quicker for us to use. In this post I cover creating simple aliases for common commands/scenarios (or at least those in my working day).

WARNING! Dragons Be Here!

We are going to be changing the Git configuration file! I strongly recommend you start with these by working on a fresh repository’s configuration file before adding the “--global” switch to apply changes across the board! By this, I mean:

• Go to a temp directory.
• Open up the Git bash/shell.
• Type “git init”.
• From this point on, all changes are to be made to this repository only by omitting the “--global” switch. I won’t even add it to the commands so you don’t screw up your system configuration by way of copy-and-paste!

Disclaimer: I am still very much getting used to working with MSYS, so there may be better ways to do things (esp. with the shell commands). I have simply done enough to “get things working”.

The Basics

Adding an alias is pretty simple, it takes the format of:

   1: git config alias.{shortcut} {command}

Where:

• “shortcut” is the alias you would like to use.
• “command” is the command you would like to execute.

Git Status

I often use “git status” to get a brief overview of what’s going on. This is especially after creating projects, generating files etc. so I can ensure my “ignore” flags are set on appropriate files.

Let’s alias it so we can just type “s” instead:

   1: git config alias.s status

Done! Now lets test it:

   1: $ git s

   2: ... {output ommitted}

See how we just type the alias? This is how we will execute future aliases.

Now let’s spice things up a bit by adding some switches to the command..

Commit Early, Commit Often, Commit Easy

Since we want to commit early, and commit often with a message - you do always add a commit message, right? ;)

   1: git config alias.c 'commit -a -m'

We can then commit all unindexed changes using the following:

   1: git c "This is my commit message"

NOTE: This commits unindexed changes (i.e. files under version control that have changes, but does NOT add new files).

I am currently trying to get the damn thing to perform a “git add .” followed by the “git commit -a -m” and read in the message argument passed - but having issues!

Either someone smarter than me will let me know how this is done, or I will crack it!

Reverting Changes

One of the main points of source control is that it gives us the freedom to mess with our code in a safe environment, where we can roll back changes if required.

Let’s set up a alias to revert the “HEAD” revision (last committed changes).

   1: git config alias.r 'revert head'

NOTE: The use of the single quotes - otherwise only the “revert” is added to the configuration file.

Resetting Working Copy & Cleaning

WARNING: This will lose any uncommitted changes and newly-created files without prompt! Exercise caution using this!

What if we have not been crazy enough to commit the changes? Here we need to use “git reset --hard” switch to bring the working copy right back to the HEAD revision. But, if files have been added, then we need to clean those up as well.

This is where the ability to chain commands together in an alias come in handy. This alias is a little different because we prefix with “!” which actually performs a shell command (hence the need to add the “git” too). More on this later..

   1: git config alias.hr '!git clean -f && git reset --hard'

Viewing the Log, Nicely Does It

Being a big fan of “commit early, commit often”, my commit messages tend to be short. So when reviewing the log, I just want a nice one-line output so I can skim-read the changes. Let’s clean up the log output:

   1: git config alias.l 'log --oneline'

We then get much nicer output using:

   1: $ git l

   2: 1982f99 Revert "Added More Code"

   3: bc66931 Added More Code

Shelling Out, Editing Excludes in Your Editor-of-Choice

As promised! Sometimes the Git commands just might not cut the mustard - so you might want to shell out to another command. This is easily done by prefixing the command with "!".

For example, You may often need to update your "excludes" file to prevent non-source files from being put under version control - so why not alias your fave editor:

   1: git config alias.ex \!\"c:\\program\ files\\notepad++\\notepad++.exe\"\ .gitignore

NOTE: There are a lot of escapes in the above which makes it look messy. Off my head I don’t know any way to clean this up - if you do, please comment!

Update: Following a comment from Mark, doubt was placed in my mind about the use of the “exclude” file, so I had a quick search and came across this. Therefore, to ensure that everyone gets the benefit of the ignore settings you create, place them in a file called “.gitignore”. The snippet above has been updated to suit.

Displaying Branch History to Screen

A nice switch I came across when first getting started was “graph”, which can be applied to the “log” command to get a nice ASCII-art-esque display of the branch history, let’s add an alias for “branch display”

   1: git config alias.bd 'log --graph --pretty=oneline --all'

Do you have any aliases you use on a regular basis? Did you find the above helpful?

Work hard. Play harder.

The Coding Dojo: My First Time

So there it was, my first time.. A little scary, a little intimidating and seemed to be over in a flash..

I just got back from my first ever Coding Dojo. In short, a coding dojo is:

A meeting where a bunch of coders get together to work on a programming challenge. They are there have fun and to engage in deliberate practice in order to improve their skills.

“Deliberate Practice”?

Deliberate practice is basically making sure you do things right rather than doing them to get the work done. When at work, we often need to be pragmatic and cut certain corners in order to meet deadlines/budgetary requirements and all the other crap that actually comes with writing software for the real world.

This often means that some practices may be neglected. Coding dojo’s aim to put us in an environment where we can work to those practices, improve them and then integrate them into our working processes (at much lower cost).

My First Experience

The problem we were trying to face was simulating the numbers round from the Countdown TV Show. Now, the code to generate the numbers that represent the problem was completed in a previous dojo, so we were tasking with creating the solver.

First off, wow.. This is actually a pretty tough problem! Here are my thoughts:

Deliberate Practice

Seemed to pretty much go out the window.. We found ourselves running down the rabbit hole rather than stepping back, re-evaluating and then writing appropriate tests. There seemed to be a hell of a lot more code in “production” rather than in tests – and one thing I have found is that when TDD-ing at work/home, my test code is normally about twice the size of my production code.

This became painfully obvious as we kept running up against roadblocks – TDD aims to overcome this by always solving the simplest problem next. I will say however is that conceptually the numbers round is a simple problem, but the logic process is actually kinda difficult to unwind.

Red > Green > Refactor

TDD-er’s out there live and breathe this. Before writing production code, there must be a failing test. We then get the test to pass. Finally, we refactor the code (and test code) ensuring we do not break the tests. Rinse and repeat until your code is done.

Put bluntly, we were absolutely crap at honouring this! I think it would probably be best to have someone nominated as “overseer” or “Uncle Bob” who is there to beat you with a stick when you don’t stick to the plan.

The Lovely Hotseat

It was amazing to see how much input people gave, and then froze up when the keyboard came to them. I personally found it a very interesting experience. Much like giving a presentation, simple things suddenly become much more difficult when all eyes are on you. This is probably something only experience will overcome – but it’s definitely a roadblock. I think having a chance to build rapport with the group will help also.

Summary Thoughts

Overall, a good session – but I think the format (or at least the way we implement it) needs some work.

Honestly though, I found the single most powerful positive from it was simply sitting down with a bunch of other passionate developers and chewing the fat on a problem. IMO a “good” developer will eventually come across new practices and always work on improving their “A-game” due to the natural inquisitiveness of our nerdy breed. :)

However, the ability to problem solve and look at things from a wide variety of angles can be VERY difficult to hone. Having someone else there to just throw it in your face makes the process a whole lot easier!

On the whole, a positive experience. A few (expected) teething issues but nothing that makes me feel bad about it. Looking forward to attending another soon!

Obviously, the above is based on extremely limited experience. So as a reader, I would take it with a pinch of salt. I am always a fan of “don’t take my word for it” – find out for yourself!

Things I Would Like to See

• Ideas/spikes before and after the dojo, checked in to a shared repository to spark discussion to get the ball rolling quicker.
• More talking from the person in the hotseat and more listening from the spectators.
• Planning before the keyboard gets to you, perhaps writing ideas for tests, or working with your partner on tackling an implementation segment together.
• Stricter adherence to the “deliberate practice” principle.
• Somehow sharing code across machines and allowing developers to use their own environment.. I really missed all my snippets/key configs etc. Provided you are working to agreed code standard, it seems silly to deprive a developer of what feels right for them. The speed at which Git (and other DVCS’) can commit/pull/merge should make this easy.

Have you ever been in one or more coding dojo’s? What are your experiences/thoughts?

Work hard, play harder.

Visual Studio: Unknown Build Error (HRESULT 0x80131515)

If you are receiving this really informative error message in Visual Studio and looking for a solution, I hope the following can help you. I spent wasted a fair bit of time trying to figure this out. Funny thing is, it’s actually quite common in the post-XP(i.e. Vista and Windows 7) era (I’ve had it myself several times now)..

The Cause

After much digging, it turns out the issue is caused by the file blocking placed on downloaded assemblies. For example, I had the following after downloading the binaries for Autofac and adding it to my project:

Error    1    Unknown build error, 'Could not load file or assembly 'file:///c:\{Project}\lib\Autofac.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)'     {Project}

To Fix

The good news, is this is pretty easy to fix (as are most problems when you know the cause!).

Open up the file properties dialog (right click in Explorer > Properties) and then you will see the security warning:

This file came from another computer and might be blocked to help protect the computer

That’s what we are after – click the “Unblock” button. Click “OK” (or “Apply” > “OK” if it makes you feel better). Flick back to VS and fire up another build and all should be right in your world and you can go back to cutting code (you don’t need to close/reopen project etc).

WTF’s/Questions to Note

• Considering how many assemblies we devs download from the Internet, how has this not been more common?
• What is with the language in the file properties? “The file might be blocked?” – If Windows doesn’t know, who does?!
• What operation is VS trying to perform that is “not supported” – one would assume that an IO error of some kind is occurring – why it not at least saying “error reading file” to at least point us to the file?

Hope this helps people and saves them some time!