Showing posts from October, 2009

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

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 m

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, i

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 do

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

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