Talks at the Virtual Worlds Best Practices in Education 2011 Conference

In a couple of hours I will be talking about the Open Wonderland Development course that I organised through P2PU earlier this year. The time is 7a.m. PST or 2p.m. GMT and everybody is welcome!

This is the master schedule for the whole conference, which is finishing today.

Yesterday was the turn of Roland Sassen from Thinsia Research to talk about Wonderschool, their fantastic project that allows children in schools to use Alice through Open Wonderland. Roland also talked about some new research they are starting, to use Wonderland through thin clients and that sounds really exciting!

After that, Nicole and Jonathan from Open Wonderland Foundation and Wonderbuilders talked about the imminent preview 5 release that we are all waiting for!

As for today, I will be talking about the P2PU course and later on, at 1p.m. PST or 8p.m. GMT, Jon and Nicole will be joined by Kathryn Aten to tell us all about how to learn to program collaborative using Open Wonderland. This is a talk based on Wonderland Wednesdays which are our community weekly meetings in which we've been gathering together to write code collaboratively almost every Wednesday for the last 6 months. Can't wait!

Code retreat in Winchester

I had a quite big post written about the event in Winchester but as a proof of how much I learned in the space of just one day, I went into end of session mode and deleted it!

It was an intense day but very enjoyable. For me, my first code retreat and also my first time pairing with another person in the same room. All my previous pairing experience had been remotely, and I have to say that I did enjoy sitting side by side, but I could not do a fair comparison because I had never met any of these guys before, and shouldn't compare that with the familiarity of knowing the other person, even if only remotely.

Each session was surprisingly different from the previous one, not only due to the rules, but also due to personalities and languages. I must admit that by the end of the last iteration I had already lost a part of my brain. When someone said during the last retrospective that they needed a pint, I couldn't help but think that I'd rather have a bucket full to dunk my whole head in it!

Many thanks to everyone at Eden cause the organisation was excellent, and to all the participants for making it possible. It would've been cool to see @ecomba and @sermoa in a demo session of TDD as if you meant it; I'm sure I could have learned a lot from that. Also I have some concerns about retrospectives, mainly because only the more extroverted types participate more freely. A group of more than 20 people can be frightening for some. But such is life, right?

In any case, the event certainly surpassed all my (high) expectations and I can't wait to attend another one. If anyone is interested in facilitating one in Ireland, please get in touch and I could talk to local dev groups about it.

Learning a new language through testing

I've come across this very interesting talk by Ola Bini on Adopting the JVM in which he talks, among other things, about learning a new language.
I've been trying to learn Ruby for months now, and although it's being quite a slow process, it is kinda working, but the fact that I don't write it often is a big drawback. Ola mentions that a good way to get started, if you happen to write your code in Java, is to test your code with some other language supported by the JVM such as Ruby through JRuby.

A couple of posts ago I recorded a kata in which I was using cucumber and cuke4duke to test my Java code but my step definitions were written in Java, and my unit tests used JUnit. I guess the best way to practice more Ruby would be to write the steps in Ruby, and to use RSpec to drive the design.

A quick search yields the missing piece in the puzzle; JtestR allows for just that, testing (or stretching) Java code using Ruby. I haven't tried it yet, but I certainly can't wait! and the fizzbuzz kata (March's kata in 12meses12katas) looks like the perfect ground to put it into practice. Let's see how it goes!

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.

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!

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:

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: