Antonio Lucca is a software journeyman, thinker and learner, and Scrum Master. He lives in Milano, Italy, at the moment. He is interested in principles and practices that helps making software development sustainable, efficient and fun.

Here’s what he has to say about doing the kata:

The first test cases are the non positional matches, then by some refactoring everything comes up to a linq expression.
The next test is related to a more intriguing case: Avoid counting twice a color that has already a match (the “mm” expected as result for a “yyxb” guess against a “rgby” secret, where the actual result is “mmm”, counting ‘y’ twice).
I commented that test for a while, and then did some refactoring until the base code was ready to implement just the logic needed to let that test pass.
After that I implemented the positional match as a special case of the non-positional match, and then put them together in the Mark method.
The tools that I used are autobuild (from google code), nunit growl addin, and… gvim.

One of the awesome things is the toolset he is using. You should watch it first, then come read how he did it. Here’s a write-up of this:

I have a visual studio solution, but should not be not strictly required, however I didn’t try without having the visual studio solution. (I mean a build file in .sln format, suitable for the dot.net sdk msbuild command line tool).
If you have only the dot.net sdk could work as well, as long as you can modify the autobuil.build nant file, that should be straghforward. however I havent tried yet. the free c# express edition to create solution file may works as well.
Another possibility is avoid reference to the solution and modify the autobuild.build nant file to simply compile the sources via csc compiler.

However this is my configuration:
1- you have a visual studio format solution folder of a project that referenced the nunit assembly (nunit.framework.dll)
2- you have installed the autobuild from http://code.google.com/p/autobuildtool
3- you have nunit version 2.5.5, and nunit growl notification addin, and growl as well
4- you have a output named output (or whatever) where you copy “stuffs” as described in http://timross.wordpress.com/2009/08/04/continuous-testing-in-net/
5- you modify there the autobuild.build file in the output directory to let it reference the solution file of your project (or call the plain source files compilation via “csc”. As I told, I didn’t try)
6- on that file you change the “run-unit-tests” target so that it will call the external command line nunit-console that takes as argument the assembly generated by the build, (usually in bin\debug) redirecting the output on a file. Avoid using the nant2 task because it didn’t work (to me).
7- open two different windows command prompt (cmd). One where you can launch autobuild.cmd, another one simply to show the nunit-console output redirected to the compiled file (dll assembly or .exe). you need to show the file via tail -f. So a tail tool should be available as well, for example having cygwin installed.
8- should be ready. Be sure that growl is running. Create a single failing test and if you launch the (included in autobuild) nant to autobuild.build file it will build the project and execute the tests, and the nunit notification should “growl”. Sometimes modification of the solution file (.sln) can be required, because, for instance the build does not see the output folder for the compiled.
If the point 8 is ok, then launching autobuild.cmd should be able to do everything in background and so any change in any source file of the project will make the solution be rebuilded and test executed and notified in growl and in the output file (accessed via “tail -f”).

If you’d like to contact Antonio, here’s some info:
Hompage: http://tonyxzt.blogspot.com/
Twitter: tonyxzt

Enjoy!

CodeBreaker marking guess revised from tonyx on Vimeo.

Michał Kwiatkowski is a software developer from Gdańsk, Poland. He builds RoR applications and in his spare time works on open source projects like Pythoscope (http://pythoscope.org). His interests include programming languages, artificial intelligence and automated testing.

Here’s what he says about this katacast:

I started doing kata after watching Micah Martin’s lecture, about 3 weeks ago. I wanted to start simple, so I’ve chosen a very basic problem from Project Euler: finding a sum of even Fibonacci numbers lower than 4 million. Each day, I tried a new technique or programming language. I studied solutions of others. Finally, I’ve settled on a set of three solutions, which are recorded in this video.

Main theme of this kata is different techniques for iteration which may be used in Clojure. First is a functional-style iteration using built-in “loop,” a second is a solution in a little DSL of sorts, via the “iter” library and third solution is based on lazy streams, inspired by Haskell.

Interesting thing about this kata was that even after solving the problem multiple times I could still make stupid mistakes from time to time, and writing a solution would take me 20 minutes instead of a minute. This shows how it’s important to practice basics of our craft *every single day*. There’s also a great value in approaching a problem from different perspectives. I’ve learned a great deal about the problem itself as well as about the tools I used to solve it. It’s a great way to asses strong and weak points of programming languages.

Even though it includes 3 solutions, this katacast is nice and short. I enjoyed watching it a lot.

If you’d like to contact Michał, you can below:

Homepage: http://joker.linuxstuff.pl
Tumblr blog: http://time-loop.tumblr.com
Twitter: infrared
Enjoy:

Tom Crayford is a student living in Sheffield, UK. His interests are lisp, dynamic languages and tinkering with emacs (and vim sometimes as well).

And, here is what he has to say about the kata:

I’ve been doing this kata as a morning exercise for the past two weeks. Regular practice is something I think many software developers are missing. This was my first real experience with proper TDD, and it has since found its way into every piece of programming I’ve done.

I’ve really enjoyed recording this kata, and have learned a lot. The best payoff has to be learning about TDD, and noticing the small improvements one can do was definitely very satisfying.

Although you might not be able to see it without HD, test failures are highlighted with red underlines in the test code (and errors with orange)

I’m looking forward to putting up some more in the following weeks, as I know that we’ve been slacking a bit over the past month, or so. Don’t worry!

If you want to contact Tom, here’s some info:

Twitter: t_crayford
Blog: www.tcrayford.net

So, enjoy! As usual, if you have any constructive feedback, please leave a comment. If you’d be interested in doing a katacast, please let me know.

String Calculator Kata from Tom Crayford on Vimeo.

After being away for a couple weeks due to conferences and sickness, we present another entry in our “Same Kata, Different Languages” series: the String Calculator in Groovy by Itay Maman. This will most likely be the last of the String Calculator katas for a while, as we’ve been doing them for a long time now; time for something different next week.

StringCalculator Groovy from Itay Maman on Vimeo.

No music, but lots of commentary.

Gary Bernhardt is an independent software contractor in Seattle specializing in the dynamic languages Python and Ruby. A brutal minimalist, he is bent on the destruction of all existing software except Emacs and Vim, the two One True Editors.

Gary’s a fantastic developer with some amazing thoughts on software development. Here’s what he has to say about doing this kata:

I’ve made dozens of runs through this kata, but I chose this one to post even though it has two accidental red bars. They’re nice red bars, though, because they show you just how fast test feedback can be. At one point, I run the tests and they fail unexpectedly. I see the bug, fix it, and get a green bar about two seconds after I fired off the original failing test run. That’s run-fail-analyze-fix-run-pass in two seconds. I think that we should strive for this fluidity in all of our software development and I love doing what I can to help others achieve it.
There’s one section of the kata that I’d like to highlight. Around 3:30, when I begin to make the code reject negative numbers, I come to a point where it says “if there’s a minus sign at all, throw an exception.” Now I’m stuck – I can’t make that check more specific by talking about negative rejection. Instead, I write a test on the other side of the problem – I check for the case when the minus sign is actually a delimiter. The test fails, but the easiest way to fix it is a refactor from the code’s previous state. So, I comment the failing test out, do the refactor, uncomment the test, and now it passes. This is something that I stumbled over while learning TDD – I’d try to plow ahead and fix the failing test case directly, which can be a slow, frustrating process.

Knowing Gary, when he says he did this dozens of time, he isn’t lying. Gary breaks from the norm of using classical music, but I think he’s chosen a great soundtrack that goes great with his style.

If you’d like to contact Gary:

blog: http://blog.extracheese.org/

twitter: http://www.twitter.com/garybernhardt

Feel free to comment. If you are inspired to do your own kata, please let me know. Watch and enjoy,  you are about to see an amazing performance.

String Calculator Kata In Python from Gary Bernhardt on Vimeo.

Currently I am learning Scheme. Due to my lack of knowledge in Scheme I could not write the tests (nor code) for the negative numbers part of the string calculator. I would have loved to get there, but I was reading about exception handling in Scheme and could not get my head around it in a short time to make this Kata work.

I might post in the future a polished String Calculator Kata in Scheme adding this elements.

For now, I hope you like this Kata as much as I did recording it. Special thanks as always goes to Camtasia, without them I would not have recorded the Kata so easily.

Enjoy! And, as usual, feel free to comment. If you are inspired to do your own kata, please let me know; I’d love to work with you on it.

KataCast: StringCalculator in Scheme from Enrique Comba Riepenhausen on Vimeo.

Update!

I have added a git repository with the skeleton of the project in scheme in case you want to fork/clone it and try yourself http://github.com/ecomba/String-Calculator.

Why did I put a “0″ that was automatically green? Perhaps, in my mind, that was a test, as opposed to a design-pressure. I generally say that I TDD my way to the design through writing examples, then write tests after I have the code to catch edge cases, etc. During the process of writing the code, this isn’t always immediately obvious.  However, Roy’s point raises the question of “was the ‘0′ case even a necessary test.” My answer? Probably not.

Wow! This is absolutely true. I was so far along in the implementation, definitely already in the flow, that I didn’t think to drop back to such a simple case. I’d like to claim that I felt ‘this is an invalid input into the system,’ but I didn’t. I just didn’t think about.

So, to answer the question posed above: no, this isn’t one of those cases. This was simply a case of not cleaning up enough. Thanks, Roy, for pointing it out.

Since the String Calculator kata was posed by Roy Osherove, I asked him to take a look at my solution and give me feedback. He was kind enough to write a blog post with some comments. Since he took the time to write them, I thought it fair to weigh in with my responses.

Partial Test: at some point, Corey seems to be writing the tests incrementally as well, in that he writes an empty test that passes, and then fills in the test itself to see it fail (which is usually where I start). I wasn’t sure why he’d do that, but the reasoning could be that he wants to make sure the environment works for the test. since he does it all in Ruby, which is a more forgiving environment for typing errors, this might be it.

Always passing test: very early on, in the second test actually, Corey creates a test that asserts that sending “0” returns “0” – which passes and never fails. That is because by default empty strings as input return zero. I do it a bit differently – i try to start with a failing test that drives more functionality, and if i can find a way to make a test for “0” fail as well to being, i will do it (so that i can ‘test the test’ in TDD style).

This is a great point. The strict TDD cycle is red-green-refactor. I like his point of using a “1″ to watch it fail, then add the #to_i call to make that pass.

Why did I put a “0″ that was automatically green? Perhaps, in my mind, that was a test, as opposed to a design-pressure. I generally say that I TDD my way to the design through writing examples, then write tests after I have the code to catch edge cases, etc. During the process of writing the code, this isn’t always immediately obvious.  However, Roy’s point raises the question of “was the ‘0′ case even a necessary test.” My answer? Probably not.

One of the things that I like to bring up when facilitating Code Retreats is Braithwaite’s “TDD as if you meant it” exercise. This involves only writing the simplest example and the simplest code to force out the abstractions and design. This involves thinking about every example and its place in the design process. I clearly did not do this when I wrote the “0″ case.

Magic inputs: Corey sends in various seemingly random, out of the air numbers as inputs to the tests starting from the third test onwards. For example, to a reader who sees a test that says “sending in 5 returns 5” that reader might ask themselves “why 5? why is 5 so special? should I also use 5 in my tests?”.

A different way: To avoid such confusion i like to stick to the lowest common version of an input that still proves the application wrong. if sending in “1” produces the same result as sending in “5” then my all means i will send in “1”. If the input is 2 digits, I’d send in “10”, “100” and so on. If the input still does not make sense I would put it in as a variable named “SINGLE DIGIT NUMBER” to explain to the reader what is so special or not so special about this value.

This is a good point from Roy. Watching through the performance, I can definitely see how this is strange. I’m not a fan of using “1″, “10″, “100″ as examples, since they feel too similar in structure. However, passing “5″ isn’t much better without an explanation. Perhaps a better case would be to change my example description to “handles single digit number,” rather than “returns 5 for 5.” I like the idea of changing the variable name, as well, for further explanation.

The simplest Test:Corey wrote the tests for inputs with \newline characters without considering the most basic test for this kind: a simple string containing only a new line character (equivalent to an empty string). I agree that not everyone would pick up on this as an idea, since you might feel this is an invalid input into the system. nevertheless, when I teach TDD this is the way i teach the kata. It feels like a more natural incremental evolution of the code and tests, and a good way to send the message that anything can be divided into small increments if you want to.

Wow! Great catch. I was so far along in the implementation, definitely already in the flow, that I didn’t think to drop back to such a simple case. I’d like to claim that I felt ‘this is an invalid input into the system,’ but I didn’t. I just didn’t think about.

Roy’s point about this being a good way to send the message of dividing into ever-smaller increments is great. When I teach people, I often ask them the same question.

Refactor to un-readability: At some point Corey refactors the code that handles delimiter characters into a single line of Ruby code. while it is a form of refactoring, i found that the code after refactoring was much less readable than it was before.

This is a wonderful point. I laughed when I read it, because I had brought up the exact same point not too long ago while reviewing someone’s clojure code. Their response was ‘if you knew clojure better, it would not be cryptic.’ I sometimes accept this as an answer, but only rarely. Within reason, I feel, truly well-written code can be understood with minimal fuss by an experienced developer, no matter what the language.

(update: Tracy Harms has called me on the above statement that some languages are not necessary readable by an experience developer with no prior knowledge. So, I gracefully concede that APL and J are decidedly NOT readable. Of course, after seeing bits of both, I will question whether those languages are readable by ANY developer. just kidding. I still hold that most mainstream, not codified math-based, languages should be readable. )

However, the ‘if you knew x better, you would not think it unreadable’ argument can be valid in some cases. Is this one of those cases? I thought I would take a look at the code and see what I think.

self[0,2] == '//' ? delimiter = self[2,1] : ','

After being away from this code, my first impression is that the indexing is a bit domain-specific, but not domain-specifying. In order to understand this line, you need to know that the first two characters equaling ‘//’ imply that the next character is the custom delimiter. If I were helping someone improve this code, I would ask whether it would be better with something like

has_custom_delimiter? ? customer_delimiter : DEFAULT_DELIMITER

In fact, after reviewing this code, I realize that the clause (delimiter = ) is completely unnecessary and left over from a previous step. Naughty me! This goes to show that mercilessly refactoring your code can sometimes highlight things that you might miss by visually looking at it.

So, to answer the question posed above: no, this isn’t a case of ’if you knew x better, you would not think it unreadable.’ This was simply a case of not cleaning up enough. Thanks, Roy, for pointing it out.

On A Side Note

I want to address the idea of feedback. As I wrote in ‘What are Katacasts,’ a major reason for performing katas is to elicit feedback from your peers. None of us are perfect, and, in fact, most of us continue to seek insight into coding through sharing our ideas with others. By receiving specific and pointed feedback, such as what Roy gave me, it helps us improve both by learning new ideas and being reminded of fundamentals that we might have forgotten. I want to thank Roy for taking the time to provide this.

In fact, I would challenge all of us, myself included, to take the time to provide feedback to each other in the form that Roy did for me. The Software Craftsmanship Manifesto states

Not only individuals and interactions, but a community of professionals.

For me, being in a community of professionals means that we strive to help each other improve. Feedback on code kata performances, either here on katacasts, at a user group or someone’s personal blog, is an essential part of this.

Giordano Scalzo is a Software “jack of all trades, master of none” living in Milan (Italy). He does Software for fun since early ’80s and he’s paid for it since 1997. Got interested in Agile stuff in 2000 and, since then, he tries to follow the principles in everything he do. In the last years moved toward the management part of the develompment, still embrancing all Agile values and spreading them between all people he works with.

Here’s Giordano’s description:

I admit it: do this kata has been an hard challenge; this is the longest Scala program I ever wrote and this is the first Kata I did with objectives: the first was to performe live at Milan Xpug meeting, and the second was to record it in a smooth way. Two different practices that gave me a lot feedback and self consciousness about the way I write code.
Many thanks to Gabriele Lana which arranged an exciting Kata evening at Milan Xpug and to Corey which host me on http://www.katacasts.com.
I’d love to receive any kind of suggestions, about the solution I got and the process I used to reach it.
I think Software Craftsmanship is the most exciting movement in Software Development since the times of Agile Manifesto, and the katas are a wonderful way to sharp our skills.
Finally, I hope you’ll enjoy my performance.

I definitely enjoyed it!

Enjoy! And, as usual, feel free to comment. If you are inspired to do your own kata, please let me know; I’d love to work with you on it.

KataCast: StringCalculator in Scala from giordano scalzo on Vimeo.

Gabriele Lana is a software journeyman living in Milan (Italy). Since 1998 he works as a developer and consultant. In 2000 he started using Agile practices in real time and embedded industries, proving their effectiveness in this domain. Since then he has always applied Agile values and principles to his work, doing coaching and mentoring to many teams in different fields (banking, medical, monitoring, …). He is currently developing products with Erlang, Ruby and Javascript.

blog: http://www.gabrielelana.it

twitter: http://twitter.com/gabrielelana

github: http://github.com/gabrielelana

Here is Gabriele’s description of his kata.

This is the String Calculator kata by Roy Osherove done in Erlang (R13B03), the standard EUnit application for the test execution and vim as text editor (without fancy plugins, only surround.vim). I have performed a few code kata before in a few languages but this is the first one recorded. I have discovered a huge value in recording and watching your own performance, you can spot many little but important improvements (thank also to Corey for pushing me to complete the kata in less than 15 minutes, the initial version took me more than 30 minutes). The obsessive search for the perfect flow could be seen as nonsense, but it’s what you learn in the journey that matters. I would love to receive some feedback and I hope you enjoy my performance.

I really enjoyed watching this one, as it has been a while since I looked at Erlang.

If you’d like to contact Gabriele:

blog: http://www.gabrielelana.it

twitter: http://twitter.com/gabrielelana

github: http://github.com/gabrielelana

Enjoy! And, as usual, feel free to comment. If you are inspired to do your own kata, please let me know.

String Calculator in Erlang from Gabriele Lana on Vimeo.

Oh, and +1000 points to Gabriele for using the music for Monty Python’s Oliver Cromwell song.