Last night we ran the fourth Southampton Coding Dojo at the iMeta Offices, those present were:
We ran the session again using the Randori Kata approach, with a slight change to previous sessions. As a team we’re into continuous improvement and one of the problems previously encountered was limiting the leading person in the pair to 5 minutes on the keyboard and then passing onto the next person to take the lead – we were finding with this approach that tests could be slow to complete as the first person may only finish part of the implementation and the next person (although meant to be pairing) would undo some of the code and go off in a different direction and get to the end of their 5 minutes and not have a working test either – So in order to avoid this situation this week we tried to improve the process by saying that the first person had to write a failing test, and then the next person had to implement the code to pass the test (using the Red Green Refactor approach) and then write another failing test before passing the keyboard on. This actually worked quite well and we found that roughly each person was still having 5 minutes a go with the keyboard but we had tests that were passing at the end.
The group decided this week that we would implement the Kata Harry, one of the ideas on the coding Dojo website. The problem is based on buying books and giving the customer the biggest discount possible when buying multiple books.
We started off with writing the rules on the white board, which basically followed the pattern:
- There are 5 books and each book costs £8.
- If the customer buys 2 different books they receive a 5% discount (buying 2 of the same results in no discount)
- If the customer buys 3 different books they receive a 10% discount.
- If the customer buys 4 different books they receive a 20% discount.
- If the customer buys 5 different books they receive a 25% discount.
The dojo website also helped by posting all the test cases which was actually a good job because we thought we had completed the task fairly quickly until we ran into the edge cases – The way we implemented the system was by taking the largest unique set we could find and then applying the discount, and then we took the next largest unique set and applied the discount until we had no books left.
However this solution fell down on the edge case of buying 8 books (2 copies of the first book, 2 copies of the second book, 2 copies of the third book, and a single copy of both the fourth and fifth book). The test case indicated the cheapest solution was to create 2 groups of 4 unique books totalling £51.20, however our solution worked by using the largest groups of unique books and hence created a result of £51.60, one group of 5 unique books (£30) and a second group of 3 unique books (£21.60). In order to pass this test we had to rewrite the calculation, we took a brute force approach whereby we tried with all combinations and returned the cheapest – And because we had all the test cases previously working we knew we hadn’t broken existing functionality when they all passed again. I’ll try and post the code soon on the coding Dojo GIT source repository.
We also had some ideas for the next session, including writing a football fixture list calculator, the BBC has an excellent article on how complicated this can actually become with all the dependencies.
In keeping with the 2 week theme and avoiding the NxtGen Southampton user group meeting the next session will be ran on Wednesday 10th December at iMeta’s Southampton Office. If you would like to attend, its all free and we’re an easy to get on with bunch of people, all we ask is that you register first.