So I’m sitting in my office, bashing away at my keyboard, when a small parcel arrives on my desk. I wasn’t expecting anything, I’m new here so it wouldn’t be work-related, it wasn’t just a letter but a small parcel containing an object quite clearly in the third dimension. Who on Earth would be sending me 3D objects in the post to my work!?
I looked at the address label to verify it was definitely for me. It was.
Then I noticed the Mathworks logo stamped in the corner. I have no dealings with Mathworks, other than using their software Matlab while I was a student. Most people who know me know I’m a huge fan of Matlab. But I don’t think they know that. Surely they have no reason to write to me, never mind send me 3D objects in the post.
I opened up the parcel to find a Mathworks-branded Rubik’s Cube. I’d seen one of these before – the week before on Twitter @MATLAB posted a picture of one of these:
I think it’s great. It’s an interesting puzzle (another addition to my collection of cubes) as each side contains a different picture made up of the 3×3 grid on each side, rather than just matching colours. Also I noticed that once I solved it the first time, the centre pieces were the wrong way round. This is something I’ve never considered before because on a normal cube, you just have to get the pieces on the right side. You would know if a corner or edge piece was wrong because then the colours wouldn’t be the same on each side, but the centres – I always assumed they didn’t rotate relative to the corner and edge pieces! But I’d never noticed because there’s no orientation to the centres on normal cubes.
I had a play and couldn’t figure out a fool-proof method of solving the centres, so I put it down, carried on coding (in PHP, not Matlab) and left it for me to figure out on the train. I managed to do it on the train back to work the next morning, but then messed it up again trying to explain to Mike how I’d done it! I played with it some more that weekend, and became a bit more aware of how the middle-centres moved when you did the final step using my solving method (switching the 4 centres on the top layer around), and can usually solve it using a technique I developed, but it’s far from perfect and seems a bit of a hacky solution. Maybe with more inspection I’ll figure out a general solution for the centres.
Anyway – huge thanks to Mathworks for the prezzie – I love it! Also I appreciate the human touch applied here.
I think I deserve it, anyway – the amount of PR I’ve done for them by telling everyone how awesome Matlab is for the last 3 years or so!
I managed to persuade Kris, a friend I used to work with, to come along – it’s his first experience of this sort of thing, so I’m really glad he got introduced to the world of XP and TDD. Ash was there, Mike brought a friend along who’s also new to agile, and there was a decent crowd of about 23 attendees which was great to say we were expecting snow that afternoon. The day was led by Mark with *ahem* assistance from Jim.
We started by pairing up and solving a decimal to Roman numerals problem using TDD. I did mine with Kris to get him up to speed with what TDD was all about. We used a rather amateur if/elif construct in Python to solve for numbers up to about 20, but it was a good way to get in to the mood and to show Kris the methodology of thinking up a feature, writing a test, writing the code to implement the feature, testing it, refactoring and moving on to the next feature. The emphasis of the day was on ‘release early, release often’ which is a really good attitude for software development. As Facebook founder Mark Zuckerberg said in his letter to the shareholders:
Hackers try to build the best services over the long term by quickly releasing and learning from smaller iterations rather than trying to get everything right all at once. To support this, we have built a testing framework that at any given time can try out thousands of versions of Facebook. We have the words “Done is better than perfect” painted on our walls to remind ourselves to always keep shipping.
The next session was the opposite conversion, Roman Numerals to Decimal, which I managed to do quite well in a pair with Mike’s friend, a PHP dev with no experience of TDD. We did the kata in Python and solved it by looping through the characters from right to left, looking up the value of each character and adding it to the total. If a character of lower value than the previous character was found, its value was subtracted rather than added. I thought this solution to be suitable for any numeral using characters the program knew about. Within the set time we had tested up to 20 but it was failing on 14, which made no sense to me. I tried to debug but found no problems so I left it to inspect later. I got chance to take a look at it later on and with a few handy tips from Michael (assertEquals more useful than assertTrue) I managed to spot the mistake causing it to evaluate 14 wrong. I was right to think the solution was good for all, though, as using the value characters up to M (1000) and adding some more tests for higher numbers in the hundreds and thousands, all tests passed.
The third pair session was the now infamous Ordered Jobs Kata by Martin. I did this kata in Ruby with Michael. Ruby’s not one of my preferred languages like PHP or Python but I do like the chance to work in it for exercises like this (and I’m sure I’ll be doing more of this as I’m now living with a Ruby dev). I’ve had a go at the Ordered Jobs kata once before but didn’t complete it, so it was interesting to have a fresh attempt. We got off to a really slow start when we hit the first sign of difficulty (introduction of dependencies), and took quite a while working out a strategy for holding the input data and making sure dependencies were completed before the other jobs, and realised that although our first solution was technically sound, that the test failed because of the order we asserted in the test. We re-jigged our code to make the test pass and moved on. Speaking to Ash about this later, he pointed out that we’d have been better to specify several smaller pieces of the test separately, i.e. number of jobs in input must match number of jobs in output; all jobs in the input needed to be in the output once; and each of the dependencies individually needed to be listed before their respective dependants. We continued through the next stages and progressed rather well on to stage 6 which we just managed to pass by the end of the session. It turned out we’d managed to get the furthest in the room with that one, despite our slow start.
After lunch we had a bot battle of rock-paper-scissors-waterbomb-dynamite wherein we had to program a ‘player’ to play against a bot on a server built by Jim. It needed to be in C# so each of the .NET developers in the room split off and we joined them to make teams of 3. Kris and I teamed up and our strategy took a while to get going as we had many problems whenever our bot got loaded on to the server we seemed to get disqualified or just fail to take its move. However once all buggy issues resolved we devised a method of logging the opponent’s name and each of its moves. This allowed us to determine what had gone on in each round, what strategies other players (or the pre-programmed bots) were taking, where we won and where we lost. We made a few subtle changes to our attack and added some different approaches when we faced particular known opponents. A fun afternoon which resulted in us coming second to Mike’s team in the final round (although the bots won overall). Interestingly, Mike’s team was the only team running proper tests…
After we left the Madlab we had an extensive drinking session which involved geeky hilarity and many OHs on twitter. Huge thanks to Mark and Jim for making the event happen – and to the Madlab for hosting it.
The ternary operator is a shorthand way of writing an if/else statement where a particular action occurs in both cases, but the value associated with that action depends on the condition stated.
For example, the traditional if/else construct (C/Java/JavScript syntax):
can be rewitten as:
This in itself is a huge benefit to clean, concise code. I use it wherever possible. Here’s an example in PHP:
A particularly cool Python example utilising the idea of a function of a comprehended list:
If you want to return/echo true or false depending on the condition, there is no need for the ternary operator as a shorter operator is available: simply echo the boolean result of the condition, i.e. rather than:
This will produce the same output:
There are various other implementations of this idea in different languages, but the reason for this blog post is because while talking about these with my colleague Mike and I came up with an interesting manipulation of this on the train to work the other day. I had a program which incremented a value by 1 if and only if a condition was true:
In my opinion this is good because it’s on one line, but bad because the else 0 should be unnecessary. Unfortunately Python requires an else here. The obvious alternative doesn’t use a +0 but requires 2 lines:
Anyway, the thing we thought of was to increment by the integer value of the boolean, i.e. 1 if True, 0 if False:
Evaluating a condition, say x>0, returns True or False, which when added to an integer is equal to 1. Another implementation of this is to multiply the value of the condition by a scaling factor: