This is a post that I’ve had floating around in my head for a long time. The title might be a little misleading, but I hope that the content remains somewhat relevant to it in some ways (that will hopefully become clear as you read through).

I want to talk (write?) about how similar powerlifting (or any strength sports, I guess) is to software development.

“You must be mad!”, you’re thinking. You might be right.

Read on if you dare care.

Since I found using yesterday’s lunchtime to write a blog post so good - I’m following that up with another lunchtime blog post.

Yesterday I continued what I think will slowly become something of an anecdotal series on adopting F#, in which I briefly talked about a new service I’d worked on using F# (see Adopting F#, Part II).

Inspired by ‘Does the language you choose make a difference?’ by @simontcousins I’m throwing up a comparison of lines of code.

This post has been a long time coming. I’ve a few floating around in various draft states and some that exist only in my head at the moment. But I’ve decided to use today’s lunchtime to try and drive this one home.

I’ve previously talked about my journey so far with adopting F#, and have decided that as things for me have moved on some since then; it was worth me writing a follow-up.

So what has changed since January?

• Written a new web service in F# and seen it deployed to a production environment
• Spent a day doing some pair-programming to help a colleague learn some more about F#
• Written a few more F# ETL processes that help us slice-and-dice data and move it around
• Written a couple of very little tools in F# that help automate and/or provide self-serve functionality to others.

At work, I’m trying (where I can) to help push process improvement all the time. When things are slow, inefficient and painful I get grumpy. I’m not the only one, and I have the privilege to work with some great people with great minds and ideas. Together we are making, and have made some good progress.

I’ve been meaning to write something about continuous integration and/or delivery, agile methods etc. General development/software processes etc. How to do things right. But I don’t think I am yet qualified to write with any authority on these subjects - so I am going to settle for this…

In my Obligatory New Year Post I highlighted several goals for 2013 - two of which were:

• Make F# my bread-and-butter language - trying to learn better techniques and finesse etc.
• Contribute something real to the OSS community.

Since my time and F#-fu is rather limited at the moment, I decided to bite off something that I thought that I could achieve. Since I love GitHub (which I’ve sort of mentioned before) I thought I’d try and roll my own F# library for talking to their RESTful API.

I came across something of a pain while using the Microsoft Wsdl Type Provider (Microsoft.FSharp.Data.TypeProviders.WsdlService) at work yesterday.

The problem that I was facing was that the Wsdl Type Provider just would not play ball with one of our web services. The reason as it turns out was the fact that it used https and the certification isn’t properly signed.

So when working with the Type Provider in code - using the default method of just pointing at the service’s Wsdl; just doesn’t do the trick. Documentation for a fix was a little thin on the ground - and it wasn’t until I did a #fsharp shout out on Twitter that I got some clues.

A second blog post of the day? Barely - I ran rake new_post at 23:59. Odd. Anyway…

I’ve been thinking a little about my foray into the world of function programming, specifically F# - and thought it might be potentially useful to others how I have progressed from knowing nothing; to the point that I (and others) feel confident that I can ship production code in the work place using the language.

I’m not really going to cover the following:

• Benefits of Functional Programming & F#
• How-2-F#

…largely because there are a great many resources out there for those that want to know more about what it all is, why you should care and how you go about learning it. A great starting place for that sort of information is the F# Software Foundation.

What I will focus on is how I’ve gone from the point of learning, to the point of using.

I spend a lot of time thinking during the Yuletide & New Year period, about a great many things. Most of those things are not really relevant (nor appropriate) for my blog - but couple of them are:

• Review of 2012 - highlights/lowlights and achievments.
• Goals for 2013.

Review of 2012

There are few notable highlights:

• My boy’s first birthday.
• My boy’s first real Yuletide (technically his first was last year, but he was less than a month old).
• Landing a new job.

There are probably more of what I’ll describe as achievements:

• Learned F#.
• Releasing my first bit of production code (a brand spanking new web service) in my new job. A great success and very smooth release.
• Helping our team buy-in to BDD through the success of the above release - and re-affirmed the importance of a test-first approach.
• Starting up the #IWDev User Group - and seeing 6 monthly meet-ups before the end of the year.

Lowlights?

• Losing any (and almost all) focus in the gym.

Goals for 2013

I have a few goals for 2013 - the list is reasonably small because I want to keep it realistic:

• Get a personal best in the gym, in one of the big-3 lifts.
• Make F# my bread-and-butter language - trying to learn better techniques and finesse etc.
• Learn a new programming language, Python.
• Contribute something real to the OSS community.
• Help my colleagues learn/adopt F#.
• Take very active (if not leading) role in process improvement at work - taking us closer to the continuous devliery dream.
• Continue to push the #IWDev User Group, trying to hone my “public speaking” and presentation skills.
• Attend a few larger User Group meets and/or conferences, further afield.
• Complete one course on Coursera.

Test Driven Development (or TDD) seems to mean a lot of things these days. I’ll admit that until recently, my understanding of the term was not entirely solid. I’ll also admit, that I’m still learning a great deal about the term every single day.

I’m going to start of a series of posts that talk about TDD, reaching into my understanding and my experience. The focus will be on the theory and the processes involved. Why they are important and what they relate to. When complete, hopefully this will serve as a great starting point for anyone wanting to know about TDD, and might even help argue a business case to move towards using it.

None of it will be particularly ground-breaking I’m sure, but because writing about a subject helps us understand it - that’s what I’m going to do. So…

I’m going to start with a few assertions:

• TDD is not writing unit tests.
• TDD should involve writing unit tests.
• TDD is not the sole responsibility of a developer.
• TDD should be the responsibility of the organisation.

I’ll cover some of these points in separate posts in time - I want to get on with describing the process of getting your first test in place.

I’ve made the decision to move my blog away from Blogger - towards an open source blogging tool/framework that plugs directly onto GitHub Pages.

Why? I really like GitHub. So naturally I wanted to use GitHub Pages for something. Having successfully done a few tests with that solution out of the box (which uses Jekyll behind the scenes) - I was told about Octopress… which seems to be Jekyll on steroids.

For the time being I’ve moved my 10 most popular posts over (as informed by Google Analytics) and will go to some effort to make sure that the permalinks match up somewhere. When I’m happy I’ll make this one the “live” blog and deprecate the Blogger one… hopefully moving a few more of what I consider to be interesting posts over.