Code dojo for test-driven development

Posted on By Mark Wilson
This content is 11 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Every now and again, I think it would be great to do some coding, to give up this infrastructure stuff (or at least to give up the management stuff) and solve problems programmatically for a living.  Unfortunately, I also have a mortgage to pay, and certain expectations on living standards, so rewinding my career 20 years and starting again is probably not an option right now…

Even so, I took a C# course on PluralSight and, last month, I attended the Code Dojo that my colleague Steve Morgan (@smorgo) was running for some of the developers in Fujitsu’s UK Microsoft Practice.

Dojo is a Japanese word that means “a place of the way” with various explanations including a place where a group of people stay to discipline themselves.  So, it follows that a Code Dojo is a place where a group of software developers come together to be enlightened.

Our Code Dojo focused on a Kata, which is another Japanese term that literally means “form” – i.e. describing patterns of movements practiced solo or in pairs.  In this case, the pattern that we followed was one of Test Driven Development (TDD).  We used TDD to implement a software solution to a given set of requirements but, like all projects, the requirements start off incomplete and there are new requirements received at each stage of the project.

We each took it in turns to write code (even me), with the rest of the group observing and offering help where necessary.  The principle of TDD was used to write unit tests that are machine-executable expressions of requirements.

First, we wrote a test for a single requirement and then attempt to run it.  It should fail because the requirement isn’t implemented so we wrote just enough code to satisfy the requirement (and no more).  The next step is to run all tests and, if any fail, fix the failing tests or the implementation until everything works.  Finally, we refactored the code to make it more maintainable and supportable.

Very quickly, we had grasped the TDD mantra of “red, green, refactor” – i.e. at least one test fails, fix the code to pass the tests, then improve the code but tests must still pass.

The event was over all too quickly, and we ran out of time, but it was certainly worthwhile – and a great education for me.  we used C# and Visual Studio but really you could use any language to apply the principles and I really should give it another go at home.

Steve’s next Code Dojo is today but I can’t be there as I’ll be cycling to Paris as you read this (and, even if I wasn’t, I’d need to be at a management meeting!). Hopefully there will be more soon and I can continue my education…

Publishing to GitHub from Visual Studio

Posted on By Mark Wilson
This content is 11 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Those who follow me on Twitter (@markwilsonit) may be aware that I’m attempting to learn some C# skills in my spare time (what little of that I have).  It’s not my first foray into coding – I have a Computer Studies degree and, in my youth I wrote code in a variety of languages (BASIC, C, Turbo Pascal, Modula-2, 68000 assembler, COBOL, Visual Basic, C++ and probably some others too) but aside from a little bit of C++ on the Arduino and the odd bit of PowerShell, I haven’t done much in the last 20 years.  As my career moves further towards management I’m increasingly convinced it’s technology I enjoy though – and I’m seriously considering a move from infrastructure to software…

Anyway…

I’ve been following a Pluralsight C# course from Scott Allen (@ode2code) and, part way through, Scott uses System.Speech to demonstrate adding references to assemblies.  I had a play, adapting something I’d written earlier to talk to me as well as output to the console – nothing grand – just a bit of fun.  After showing it to my sons, the eldest (who is 9), described it as “epic” (which I understand is pretty good) and I tweeted, only to be amused by a reply which suggested the same library had caused hilarity in Duncan Smart (@DuncanSmart)’s household:

Small world, eh!

I followed the link to Duncan’s code and thought “Hmm… GitHub… I use that for my Arduino code… I wonder if…” – and yes, Visual Studio can publish to GitHub too.  It took some work to suss it out though, so here’s what I did (following advice on StackOverflow)…

  1. In Visual Studio, select File then Add to Source Control (which creates a local Git repository)
  2. On GitHub, create a new reposotory (but don’t initialise it with a README – Visual Studio wants an empty repository.
  3. Copy the HTTPS URI for the new repo, then go back to Visual Studio, open Team Explorer, select Home then Unsynced Commits and enter the GitHub URL before clicking Publish.
  4. You may find that you have to commit the changes locally first, which in my case required creating a local username and supplying an email address.
  5. After committing, the solution should be visible on GitHub.

For reference, I was using Visual Studio Express 2013 for Windows Desktop.

Short takes: Kids coding in C (!); new car; and finally “fit at 40”!

Posted on By Mark Wilson
This content is 13 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Last week I kicked off my new initiative to actually get some blog posts out, despite not having time for all the details…

This week was less event-focused but nevertheless contained a few things that I thought were worthy of note.

Kids coding in C? (Our Arduino)

Last weekend, I was “playing” with my new Arduino proptotyping board, with my sons.  Understandably, my 5 year-old wasn’t too bothered (to be fair, he liked putting components onto the breadboard) but I was amazed to see just how my eldest (who is 7) grasped the programming side of things.  I’m not saying he’s writing C – but just using some example code to flash a set of LEDs in sequence, he asked why he was putting // in front of some lines.  I showed him that each was a function call and he was “turning on and off” different things that the program could do.  Before I knew it, he wanted to chain functions together, before then moving on changing the delay times on the lights.  I thought that the coding side of things would be an uphill struggle but I was really encouraged to see how quickly kids can start to adapt the examples. Hopefully our Raspberry Pi will arrive later this month – and then I’ll get him writing in Scratch or another child-friendly environment!

New toy for Mark

Last November, I wrote about ordering my new car and it arrived on Monday. No longer am I tarred with Top Gear-esque comments about Audi drivers (I did really like my A4 though) – I’m now a sensible, 40-something Volkswagen-driving type! The Tiguan (or “softroader” as my hardcore Range Rover-driving manager calls it) has a towbar too, so I should be able to load the family bikes on more easily and, hopefully, we’ll get out a bit more this spring/summer… which leads me on to the next feature…

Another decade on the clock – and my “Fit at 40” challenge draws to a close

Towards the end of the week I celebrated  my 40th birthday – which marks the end of my Fit at 40 challenge. Having hit my target weight a couple of weeks ago, I’ve managed to hold that off but haven’t managed to push any further yet.  The final numbers are not quite in, but it looks like I’ll have raised just under £2000 (plus gift aid) for The Prostate Cancer Charity – thanks again to everyone who has supported me and helped make me a happier, healthier husband and father to my wife and children!