:::: MENU ::::
Browsing posts in: HOWTO

Customise your .gitattributes to become a Git Ninja

One of the things I love about Git is that your .gitignore file travels with the repo, so ignore rules remain consistent no matter which machine you are working on.

In the same vein, adding a .gitattributes to your repo allows you to ensure consistent git settings across machine.  This enables the following subtle, but very useful features.

  1. Force line ending normalization inside your repo to LF
    Adding * text=auto causes Git to autodetect text files and normalise their line endings to LF when they are checked into your repository. This means that simple diff tools (I’m looking at you Github) that consider every line to have changed when someone’s editor changes the ending won’t get confused.
    Importantly, this doesn’t affect the line endings in your working copy. By default Git will convert these to your platform’s default when checking code out of your repo. You can override this using the core.eol setting.
  2. Language specific diffs
    When git shows you diff information it gives you some context as to where in the code the diff lives. Using the *.cs diff=csharp setting tells Git to be a little smarter about tailoring this for a specific language. Notice how in the example below Git is telling us the method name where the change occured for th .cs file, compared to the default first non comment line in the file.
  3. Normalize tabs vs spaces
    The filter= attribute instructs Git to run files through an external command when pulling them from / to the repo. One use of this functionality would be to normalise tabs to spaces (or visa versa).
  4. Encrypting sensitive information
    It is convenient to store config files in your git repo, but for public repo’s you don’t really want to expose things like your production db credentials. Using Git filters you could pass these config files through an encryption/decryption step when checking in/out of the repository. On machines that have the encryption keys your config files will be placed in plaintext in your working copy; everywhere else they will remain encrypted.
  5. Useful defaults
    If you use the GitHub Git clients, they add useful default settings. Further, the github/gitignore and Danimoth/gitattributes projects contain some useful defaults.

The more I use Git, the more I realise what a powerful tool it is. And I haven’t even touched on how you can use Git hooks for advanced Git Ninja moves…


Implementing the strategy pattern without an explosion of classes – part 3 of ??

I feel uncomfortable when I see large switch statements. I appreciate how they break the Open Closed Principle. I have enough experience to know that they seem to attract extra conditions & additional logic during maintenance, and quickly become bug hotspots.

A refactoring I use frequently to deal with this is Replace Conditional with Polymorphism; but for simple switches, its always seemed like a rather large hammer.

Take the following simple example that performs slightly different processing logic based on the credit card type:

Its highly likely that the number of credit card types will increase; and that the complexity of processing logic for each will also increase over time. The traditional application of the Replace Conditional with Polymorphism refactoring gives the following:

This explosion of classes containing almost zero logic has always bothered me as quite a lot of boilerplate overhead for a relatively small reduction in complexity.

Consider however, the functional approach to the same refactoring:

Here we have obtained the same simplification of the switch statement; but avoided the explosion of simple classes. Whilst strictly speaking we are still violating the Open Closed Principle; we do have a collection of simple methods that are easy to comprehend and test. It’s worth noting that when our logic becomes very complex; converting to the OO Strategy pattern becomes a more compelling option. Consider the case when we include a collection of validation logic for each credit card:

In this case the whole file starts to feel too complex to me; and having the logic partitioned into separate strategy classes / files seems more maintainable to me.

To conclude then, the fact that languages treat functions as first class constructs, gives us the flexibility to use them in a “polymorphic” way; where our “interface” is the function signature.

And for some problems, like a refactoring a simple switch statement; I feel this gives us a more elegant solution.


Learning functional Javascript through Koans

Given how Javascript interpreters are improving in leaps and bounds; and that it seems to be the only language that will be supported by all web devices; its time to for me to revive my Javascript skilz. Fortunately the tooling has improved greatly; Eclipse 3.6 for Web Developers and JsTestDriver bring a refactoring and a unit test runner to Javascript development.

Interestingly, Javascript seems to have more functional than object orientated characteristics; so it seems reasonable to learn it wearing my functional hat.

I’ve been enjoying learning Ruby syntax via RubyKoans – little tests that teach you syntax and convention as you make them pass

I though I’d create a similar set of Functional Javascript Koans to help refresh my Javascript skills.

Its a bit rough; so please fork and contibute back improvements.
https://github.com/mrdavidlaing/javascript-koans


Why Pair Programming Doesn’t Reduce Productivity

The other day I was asked why pair programming doesn’t reduce productivity; and its taken me a few days to come up with a this succinct answer –

because we’re building a system to release software changes rapidly over a long period of time, not type more lines of code to reach some predefined goal post

The purpose of a software team is to deliver a working software solution that solves customer’s problems over a long period of time.

This would be easy if:

  1. Customers knew what they wanted
  2. Developers knew how to deliver the features
  3. The world remained the same on the day the software is released as it was at the time it was designed.

The trouble is that none of these are true. We have to guess at the right solution, get some real world experience with it, and then optimise when we know more about the problem domain (aka, after we have delivered the feature for the first time).

The way to do this better is to reduce the length of the feedback cycle (think 5 days, not 6 months), and grow a system that can rapidly and repeatedly deliver changes to the software over the life (years) of that software.

Pair programming contributes directly to growing this system by:

  • Facilitating communication about the architecture & design of the system, and ensuring everyone actually understands it
  • Reducing brittleness & bottlenecks caused by one person “owning” a core module
  • Improving consistency and adherence to common standards
  • Catching bugs at the cheapest time to fix them

Unintuatively, it also tends to ensure that developers actually spend longer working on the software by:

  • Reducing “wander time”. You are less likely to get sidetracked into email, facebook or some interesting blog article when pairing.
  • Reducing “stuck time”. Two perspectives on a problem have twice as many solutions to try out

These articles go into more depth:

To conclude, pair programming would be a unproductive if developers had the perfect solution is their head, and programming was just the task of typing that into the computer to release a single perfect version of the software.

But in the real world we we’re in the business of creating a system that can rapidly deliver changes to the software as it narrows in on, and adapts to the best solution to the problem at hand. And to do this, pair programming excels.


CI for Flex 4; running FlexUnit4 unit tests and FlexMonkey4 acceptance tests with Maven and FlexMojos

The FlexMojos project is a great way to bring your Flex application under a grown up continuous build system like Maven.

Getting FlexMojos 3.6.1 working with Flex 4, running Flash Builder 4’s version of unit tests and FlexMonkey4’s version of acceptance/UI tests is pretty tricky.

Hopefully this sample project – http://github.com/mrdavidlaing/flexmojos-sample along with this screencast will save someone else the pain I went through to get all these playing together.

Howto add new component to FlexITP from David Laing on Vimeo.

Patches welcome – just clone the git repo make your change, and request a pull.



The Pomodoro Technique – Scrum in the small

Over the past month I’ve been experimenting with the pomodoro technique of time management to great success.

The technique is surprisingly simple; yet I’ve found it contains a wealth of physical and emotional benefits. To give some context; I’m using it as a programmer as part of a agile scrum team. I typically program using TDD techniques. That being said, I don’t see why it wouldn’t be applicable in most “desk” based jobs.

A pomodoro is a unit of focused, uninterrupted time; measured by an egg timer. For me, 25 minutes works well.

At the beginning of my work day, I write a collection of tasks that I think I achieve during the day onto a fresh piece of paper. (my todo list). I estimate how long I think each task will take in units of a pomodoros. Next to each task I put a number of boxes; one for each pomodoro unit. I make sure not to have more pomodoro units than I achieved yesterday; and I try to make sure that I’m estimating tasks based on how long similar tasks actually took me in the past.

Then I wind up my egg timer, place it visibly on my desk and begin the first task. The ritual of winding up the timer, placing it down and hearing it tick helps me to drop into the zone of full concentration – and let my team know that they shouldn’t interrupt me.

Brrrriiinng. Pomodoro up, finish the current test and stop. Cross out one of the boxes on my todo list. Get up and leave my desk; stretch, drink some water, focus on something far away to relax the eyes, go and speak to anyone who came past during my pomodoro time & was waived away.

Then back to the desk, reassess which is now the most important task to get one with, and start the next pomodoro.

At the end of the day I transcribe the results of my todo list back to a records sheet; update our project management software (VersionOne); and leave, satisfied that I achieved what I set out to do.

I’ve found that running my day like this greatly increases my job satisfaction & efficiency.

Firstly; I’m breaking my addition to hopium, and setting myself up to fail every day. I used to live in this lala land called – I have 8 hours of productive work time each day. The empirical reality shows that I usually do 5 – 8 pomodoro units / day – so much more like 3 – 4 hours. The rest gets gobbled up by meetings, emails, conversations. So its no wonder that I used to achieved half what I thought I would each day; and left work feeling disappointed.

Secondly, having a forced reset every 25 mins really helps me to stop falling down rabbit holes. I’ll often be trying to solve a problem with a specific technique that just isn’t working, and if I’m not careful I can spend a whole afternoon bashing my head against a wall. With the forced breaks, I’ll often find that when I sit back down to the problem, I’ll have a flash of inspiration for a much simpler way to solve it, or realise that I don’t even need to solve it in the first place!

Thirdly, being reminded to get away from my desk frequently really helps physically. I’ve experienced much less “mouse shoulder” and dry eyes.

The technique is also really helpful when pairing; keeping meetings from rambling; keeping focussed on one task (rather than having to check email or twitter every 10 seconds) and getting going on a large daunting task.

If you struggle with hopium like me; I’d really encourage you to give the Pomodori technique a try for 2 weeks, and let me know how you get on in the comments to this post.

Brrriiinng :)

Resources
www.pomodorotechnique.com


Howto uninstall a broken MSI

I’m busy creating an MSI installer package at work; and managed to get my system into a bit of a knot.

Basically, my custom action crashes on uninstall – so when I try to remove the broken MSI, it throws an error and rolls back the uninstall process.

AAARGH! How do I remove the broken MSI now that I’ve fixed the bug?

Fortunately MSKB supplies this helpful little tool:

Windows Installer CleanUp Utility

Simply run, select offending MSI, and it will forceably remove any MSI registration from your system.

Got me out of a pickle; and will hopefully do the same for you.



Try/Catch for SQL!?

Thanks to Nick Sertis for this trick – who knew TSQL could do try/catch statements!

Very useful when you need to write data manipulation scripts for production databases.

BEGIN TRY

    BEGIN TRAN

        --Some SQL


    COMMIT TRAN

END TRY
-- Catch the errors on the inserts
BEGIN CATCH

    ROLLBACK TRAN
    SELECT ERROR_MESSAGE()

END CATCH