Sunday, February 27, 2011

Roman Numerals Kata

Last month I joined an initiative by a group of Spanish Agile followers called 12 meses 12 Katas. The idea is that each and every month during 2011, we will be practising a Kata, and sharing our code through github, and for those adventurous enough to record themselves, also through this vimeo channel.

There is a ton of resources in the net about what a Kata is and why are they important so I will not get into that, but I would like to stress the last bit of pragmatic Dave's definition:

"[...] remember that the point of the kata is not arriving at a correct answer. The point is the stuff you learn along the way."

After having practised the February Kata a bunch of times, I wanted to write a bit about the process and reflect on my own deliberate practice and learning journey during these last couple of weeks.

When I first saw the Kata, I thought it was going to be easy peasy. Yes, totally missed the point; it's not about the problem but about practising it, but in any case, I was so very wrong! It turned out to be a lot more complex than anticipated, and I even thought for a couple of days that I was having some type of programmers block. Sticking to strict TDD didn't help much either, when you are not as used to use it as you first thought!

I went through 3 different solutions:
The First solution was very complex and it was very influenced by Maths. I was tracking all this positions for different numbers, and had a ton of if branches and all that. Messy!

Then I saw a recursive solution to the Kata. YES, I SAW IT; call it cheating if you want to, I couldn't care less. When I saw the simple solution, it made me think...Why did I start coding without thinking a bit about the problem itself. I should have a look at the relations among numbers, which ones are the special cases, and so on. In a nutshell, the Domain is very important, even in small projects. That was Lesson one for me, hope it sticks!

I'd say it has to do with our nature or background as scientists. That initial thought of 'I can do this with a bit of math', yields an answer, but it is too complex, not so difficult to write, but long, and difficult to maintain. A quick but thorough look at the domain shows that the cases can be simplified if you play a bit with them. Special cases such as 4, 9, and all numbers terminating in any of the two, can be easily automated.

So I started working on a recursive solution. At first I wrote a recursion with a wonky base case, and it worked anyway on one direction (arabic to roman), but it did not for the opposite. There was a mix here of problems with copy by value in Java, and objects and primitives. If it hadn't been for the primitive case, I wouldn't have noticed the flaw in the recursion. Which leads me to think that test are great, but obviously not a silver bullet! You still have to get the algorithm right! Another example of this can be seen in my video, when I mix up L and D in the tests themselves! So Lesson two is: no silver bullets. 

Recursion can feel easy at times, but when it is easy to write, it makes you wonder if there is another way. And in fact there was. In this case a simple loop could yield the same results as the recursion, and that was my last solution.

I feel that I have a better understanding of what Katas are good for, after practising them deliberately for the last couple of months. When you are in the job, you just go to the point, and choose a collection, or refactor to an iterative process, but you don't get to dig out more information. Doing the kata in my own time, I consider that spending some of it in the details of how to choose that collection, or when to refactor is far more beneficial. This is something I had read about before, but never experienced by myself. Lesson three: deliberate practice is necessary.

What else did I learn/review this month?
- review of Maps in Java (mainly due to the fact that I needed order in my collection). Although I started the kata with arrays (some people will say that it was faster and all that), I decided to go for a map in the end, cause having two different arrays (one for arabic numbers and one for their roman counterparts) was not expressing the intent of the mapping. 

- review of recursion and refactorings applied to the recursion itself. Interesting to find out that most newish compilers will automatically substitute a tail recursion for an iteration for you, so if the intent of the algorithm is clearer with the recursion, I will definitely go with that form from now on.

- I wanted to use cucumber for acceptance testing so finally got to set up cuke4duke to run cucumber features on Java programs. It is so much fun!

- Writing cucumber features has reminded me (yet again) of my little knowledge of regular expressions. Also brings up the fact that writing features is a lot harder than reading somebody else's. Hopefully if I use them more, both things will stick in my brain, at least the basics anyway!

- Lastly, it has been quite strange to watch my kata after recording it. Does not feel like it is me (especially due to my supersonic typing up speed! Nah, it's fake, I've doubled up the speed cause the Kata was far too long!). It's definitely the case that what you think you are doing and what you actually do are two different things. The more I see it, the more I'd like to change things. But I think that that is good anyway!

As I mentioned earlier, the kata was a bit long for a video so I have sped it up! Generally katas are recorded with a piece of classical music as background. I've chosen a piece from my extensive collection, which pretty much means that it was the only 1 out of 6 classical tracks in my itunes that was long enough for the video!!! Hope you enjoy it!

Roman Numerals Java + cuke4duke (Double speed) from Josmas Flores on Vimeo.

Saturday, February 26, 2011

Refreshing is the word! The practice of programming

I am having a ball reading The practice of programming by Kernighan and Pike. I read some controversial opinions on the web about the book, ranging from praise to the most ferocious critiques, but I definitely situate myself with the former group.

The authors express their intent in the preface, and their goals are simplicity, clarity, generality, and automation, and in my opinion, they do a fantastic job of it. The book must be read from a historical perspective, as it was written in 1999, but the basics are there, and it is a fantastic refresher for topics such as data structures, algorithms, design, and implementation ideas.

I agree with some of the opponents that a few sections are very outdated (historical perspective, right?), and a lot has changed since then, especially in the realms of automated testing and replacing debugging (to a certain extent) with tests. Also, wouldn't be such a good idea to be building Java programs with Vectors and un-parameterised Hashtables. But I am thoroughly enjoying the book. Even the fact that most examples are written in C has made me go back and review what all those weird symbols such as * or & mean. Hadn't implicitly used a pointer in a while, let alone allocating or freeing up memory!

If you liked books such as Code Complete or Clean Code, you will definitely enjoy this one too!

Tuesday, February 15, 2011

The importance of Cell Messages in Open Wonderland

Last week at the P2PU Open Wonderland meeting I tried to explain why Cell Messages are important. I did not do a good job of it so for that reason I decided to record the following two screencasts. In the first one I explain how you can get two (or more) clients running on the same machine. That gives a good starting point for the second one, an overview of the importance of Cell Messages.

The cell used in the video was developed following the Developing a new Cell tutorials part 1 to 3. Part 4 is the one that deals with messages, and would make the shape update properly in all the clients connected.

How to launch more than 1 client in the same machine:

Cell Messages and its importance for client communication:

Saturday, February 12, 2011

Open Wonderland, High level Architecture - the story of the system

I would highly recommend Michael C. Feathers' 'Working effectively with legacy code' to anyone who cares about code, how it is written and how to deal with complex and (automated) untested systems.
Although the word legacy might evoke images of Fortran or COBOL procedures, the definition in the book refers to any kind of system that does not have an automated suite of test to rely on when making changes.

It was in this book where I read about the concept of telling the story of the system. According to the author, you need at least two people for this technique to be effective. One asks the other; What is the Architecture of the system?
The other will answer the question in just a couple of sentences, using only a few concepts, and targeting individuals with no prior knowledge on the system itself.

So I asked Jon Kaplan if he'd be so kind to put this into practice with Open Wonderland and this is the result:

Wednesday, February 9, 2011

Connecting Open Wonderland to external services

I've been working on a tutorial about how to connect Wonderland to (and from) services on the Internet (webservices).

I am a big fan of REST so that's what I chose for the first tutorial that can be found in the community wiki.
The  code for the module can be found in my github account: REST sample module, and this is a screencast showing what you can expect from the module:

As per the utility of this module, as it stands it is quite limited, but what I am trying to show here is that it is very simple to connect to external sources, and in the same way that this very simple module sends information to be stored in an external database, other REST communication could be as easily programmed, be it integration with services such as twitter or facebook, or learning management systems such as moodle or sakai.

You can see some similar examples by Bernard Horan in Wonderblog and his youtube channel.

Client communication is not the only way that Open Wonderland can communicate with external services and I have started documenting this topic in this page. Please feel free to contribute; help will be much appreciated.

Tuesday, February 1, 2011

Workarounds and Tutorials

I have been working a bit on the community wiki, adding content and some workarounds for problems that have been mentioned in the list. Here are a couple of links:

A tutorial to explain components, which is a work in progress, and I would really appreciate some help with it. It uses the tooltip component as source code.

A workaround for the scripting component editor window, that does not seem to get along well with Windows boxes. This is the ScriptingComponent module in modules/unstable.

I would quickly like to mention a new module that allows scripting in a different way that the already existing module does. EZScript is being written by Ryan, and it can also be found in modules/unstable. It's only a couple of weeks old, and in almost incubation phase, but looks really promising. Looking forward to playing with it a bit more!