Hanoi Coding Dojo Session 4

My entry @ HanoiLUG Blog (http://blog.hanoilug.org/?p=124)

Last Saturday (2011/05/07) at AUF/CNF center, Hanoi Coding Dojo session 4 was held sucessfully. Due to the former schedule of Hanoi Ubuntu release party, we had to shift our session from 2:00PM – 4:00PM to 1:00PM – 3:00PM. Compare to our previous sessions, fewer people came but it was still a great one!

Unlike usual, Serge did not prepare any Katas, leaving the room in a dead silence for a very long period of time (by that I mean for ages). Everyone was looking at each other with unspeakable feelings. Until Yang (cmpitg), breaking the freezing of fear, proposed a Kata for the session. The problem was named Prime Filter, with the idea of extracting prime numbers from an arbitrary list of integers. The full problem specification and source code can be found at Github[1].

After a short discussion, we decided to use the Prime Filter Kata as a Prepared Kata, presented by Yang, and Common Lisp[2] as the programming language. Common Lisp has an unusual syntax (using prefix notation) and different way of thinking compared to other popular programming languages, so each time Yang wrote some code, he had to state clearly about what he was doing and why he was doing that for everyone to understand. The Kata was being solved in more than an hour, leading to many interesting discussions.

Our first discussion was about solving a problem in BabySteps[3]. Normally, developers write a relatively “big” unit of code once at a time. On the contrary, Coding Dojo’s Kata requires you to write one small unit of code at a time. “One small unit of code” means just a few lines of code with very simple logic, solving a very simple problem. This is not a usual tendency of a developer, which often leads to confusion for newcomers. When thinking of baby steps instead of big ones, developers don’t know whether the way on which they are going would solve the problem. So should we “think big” first and “think small” latter or should we just “think small” and let it show us what goes right and what goes wrong? After a while discussing the question, we decided to use the latter method: think small and let the idea correct our solution. Why? Remember the purposes of Coding Dojo? The point is to learn as much as possible. The former way (aka “think big”) might help us solve the problem faster and easier, but the latter definitely helps us learn much better. The slower we go, the more we can see. The more we see, the more we learn. Not only is this important in theory but also it’s worth doing it in practice. You code would be much better if you take your time learning more about the problem, the solution and your code itself.

The second discussion was about code refactoring[3] as Yang did not do it properly. Whenever you refactor some piece of code, remember the vital point: change the face, not the heart. I.e. restructure the code, rename identifiers, encapsulate data, … but keep the semantics.

And lastly, we had a very interesting discussion about TDD[4] (aka. Test-driven Development) in Coding Dojo[5] and in practice. We had more understandings about TDD, its advantages and disavantages, its uses in practice, why its cost (money, time, …) is worthy. We had taken real world example into the discussion, including the development of Python, eXoPlatform, and OpenOffice.org. Ideas include:

  • TDD is time-consuming at the beginning of the project but time-effective when the project is already in progress.
  • TDD helps developers keep track of the exact features they want to develop. Remember, developers are usually not users, their standpoint is usually different from users’ standpoint. Hence, what they make is not always what users need.
  • TDD reduces the time spent on debugging a complex system since developers are able to know exactly what goes wrong when using tests.
  • TDD helps keeping application backward-compatible.
  • TDD might be used as a good tool to track the progress of a project.
  • TDD is a double-edged sword, being extreme or focusing too much on testing may dramatically slow the project down. It could even lead to a forever-project.
  • Sometimes, tests are so trivial and unnecessary.
  • Not everything can be tested. Not everything which can be tested can be tested automatedly.

“That’s all, folks!”[6]. The TDD discussion ended our session successfully. Thank you all for coming and sharing with us on that day. We really hope to see you again in the next session.

Bonus: JC’s PR for Hanoi Coding Dojo[8] @ HanoiLUG mailing list (see session Links) ;-)

Coding Dojo Session 5 (scheduled):

Links:

  1. https://github.com/HaNoiCodingDojo/Problems/tree/master/Prime_Filter
  2. http://en.wikipedia.org/wiki/Common_Lisp
  3. http://en.wikipedia.org/wiki/Code_refactoring
  4. http://en.wikipedia.org/wiki/Test-driven_development
  5. http://codingdojo.org/cgi-bin/wiki.pl?TestDrivenDevelopment
  6. http://en.wikipedia.org/wiki/That%27s_all_folks
  7. http://bit.ly/jwdRIn
  8. http://bit.ly/jCqYSW

By Dương “Yang” ヤン Hà Nguyễn (cmpitg)

About these ads

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 119 other followers

%d bloggers like this: