Performing a kata has really forced me to use and discover new tools. I can pretty safely say that I have never known so many vim commands, I’ve gone from being a tmux novice to a tmux user and I dream in Java. Performing tomorrow will be about more than what I have learnt though. It is a performance, and that had me thinking of how that affects the code I write. One of the key features of clean code is readability, and that’s so important in a kata performance too. You have to make sure that people can follow what you’re doing and why. So I really tried to think about that when coming up with my Fizzbuzz solution and ended up removing the if/else ladder that I usually would use in favour of one line return statements. To me, it just reads better, so I hope it does for everyone else too. I’d like to keep that in mind. Good code does not mean the least amount of code. I know that it is better to have short methods, but where do you stop? You can reduce Fizzbuzz to one line, but why would that be better than four lines? I know that I’d would much rather be able to see what’s going on in my code and understand it at a glance than have to spend a few minuites trying to figure out what something I have written is doing. I’m sure that a pair would appreciate the same thing. For me, that’s one of the main values of readable code. If your code is readable, it is shareable, and what’s not to like about that?

So I spent my morning making sure I had Fizzbuzz ready, or as ready as I could be, for my performance. My afternoon was dedicated to my echo programme. It’s a seemingly simple programme. My problems, I feel, will lie in the tests. So I deferred writing any tests. I set up Travis CI instead and tried to find something to test code coverage, which is harder than I thought for Java, especially Java without build tools. Everytime I thought I had found an easy solution, it turned out to be a plugin for Maven. It seems that there aren’t that many people using vim for their Java, or, if they are, I’m not sure they’re testing their code coverage. If someone is reading this and knows of an easy way to do it, however, please let me know! I’ve used coveralls for Ruby, but to cover a Java program you have to send a post request to their API. Learning how to send and recieve JSON from a Java command line app may be out of scope for this story, but maybe not? Although it does seem overly complicated just to see my code coverage. We’ll see how I feel about it tomorrow.

I spent a long time reading Java documentation and trying to get my head around Java IO, and by the end of the afternoon I was feeling pretty ready to write my first test, but by that time I was getting nervous about my Fizzbuzz performance, so I thought I’d leave it till tomorrow and practice some more. So, until tomorrow…