On Friday, I took a day off work and went to the software craftsmanship conference 2013 edition held at Bletchley Park. This was very well organised by the guys at Equal Experts. Here is a quick summary in true retrospective style of how it went …
….what went well?
In general, it was an awesome day out! The Bletchley Park setting felt very fitting. I also really liked the hands-on approach of the conference. The emphasis on coding workshops meant lots of interaction with other people and the different kinds of sessions on offer also meant interaction with different kinds of people!
….what went badly?
I can’t think of anything that went horrendously badly …but… I was a little disappointed with the lunchtime tour: They had some trouble with the regular tour guide and a very nice chap was asked to lead the tour at the very last minute. Unfortunately, because of this, it focussed very much on the bits that are very much popular knowledge (Enigma, Turing, Colossus, etc.).
I suppose I could have gotten a bit more of a computing history fix by making it to the later tour of the national museum of computing, but I had to catch a train back. Oh well. I’ll come back as a proper tourist some time!
….what can be improved?
There are three things that I can think of that can be improved – one for me, one for the organisers and one for the talks themselves:
To be more effective at this kind of workshop, I really need to have a better dev setup on my surface. The surface as a machine is powerful enough, but at the moment _I_ take too long to spin up Visual Studio and get the right kind of project, set it up how I want it, where I want, choose source control, etc.
There were – I think – seven sessions to choose from for the day, but at most you could choose two (a morning session and an afternoon session). While this kind of makes sense (a workshop takes a fair amount of time after all), it is a real pity that I missed out on some sessions that I was really quite interested in (TDD in the morning and callback hell in the afternoon).
Both of the sessions I went to started with the words “this is the first time I’m doing this session and you are my guinea pigs”. This is fine of course and I definitely learnt a lot in the sessions. In terms of structure both of those sessions will definitely improve after a couple more iterations.
Right – now that we have done the short Agile version of the conference, I’ll do a quick summary of each of the sessions:
In the morning I went to Phil Parker‘s “Crackathon – securing your craft” workshop.
This was a great session where Phil had prepared a deliberately vulnerable website for us to dig into and exploit: Before I go into any more detail, I should say that this is definitely outside of my normal comfort zone (server side C++) and so my comments may well be a little inaccurate when it comes to describing the vulnerabilities themselves. We split into teams (five or so to a team), got given the site address and were then asked to email loopholes, bad security practices, etc. to a “bounty Email address”. Most importantly, sweets were awarded for finding a vulnerability. Phil then did a great job of walking through the Emails, explaining the various loopholes we found, describing defences against the attacks etc.
A couple of ideas for the next iteration of this session would be:
- Some documentation on the vulnerabilities and defences against them (I had to rack my brains to come up with the bits below and I’m fairly sure it’s at most half of what we went through). Phil mentioned that he had set up some unit tests to ensure that the site still contained the vulnerabilities so an awesome way might be a copy of the site together with the tests. (I appreciate this is potentially a lot of IP to give away).
- From around halfway through the session I found myself torn between wanting to keep digging for more exploits and listening to Phil’s explanations. Maybe a way of structuring this into distinct phases would be cool?
- Dedicate a part of the session to actually implementing defences. (You’d probably need a longer session for this.)
Phil highly recommended the OWASP website and in particular the top ten section of the website. A lot of the exploits that we talked about (SQL injection, cross site scripting, sensitive data exposure / information leaking, unvalidated redirects and forwards etc.) came from the website. Others (e.g. password storage – salting & hashing, Wifi information harvesting with pineapple and Mac’s promiscuous mode, Email authenticity) were a little more general. Quite a number of these I hadn’t heard of before such as using unvalidated redirects and forwards as part of the OAuth standards and XML based DOS attacks. Finally, we talked about some tools such as the OWASP Red Zapper which can be used during normal testing to help with spotting some of these vulnerabilities.
Overall a really great session which I thoroughly enjoyed!
In the afternoon, I went to Jason Gorman‘s “Test-driven object oriented design”.
This was a talk about how the test driven development approach affects your OO design. Really, this was probably a bit too much of a jump in the deep end for me. Effectively, I tried to learn both the TDD and the OO design effect in one step. So – to really benefit from this talk, I should have gone to Emily Bache’s morning session on TDD.
Still – there was a lot to learn here and it has definitely moved the TDD literature on my reading list up a notch.
(Can you tell I did a fair amount of googling around to make sense of this later on?!?)
To arrive at the object hierarchy, he advocated a two-step approach. Figuring out the actions required (in the passive), then figuring out the actors associated with these actions.
For each of the objects unit tests would then be written from the outside in, eventually arriving at a chain of unit tests which make up the acceptance test.
Jason illustrated all of this within the context of a particular user story.
In the workshop part of the talk, we then went through an additional user story with a partner taking it from the user store to the acceptance tests to a simple code implementation.
Beyond all of these new, sexy and exciting ideas & techniques what struck me was that the process felt a little artificial:
In the workshop the user story was completely static because there was no interaction with a product owner. We were our own product owner and really tried to imagine what the product owner might have thought of as important. To me, this really underlined the importance of interaction with the product owner in determining key design features, incidental portions of the design.
Having sounded that cautionary note, we did manage to get through the user story (with a little bit of struggling and a fair number of iterations). In the end, it was good to see how the various techniques fit together.
All in all a great conference. I would thoroughly recommend this to anyone interested in (various forms of) craftsmanship!