I’ve been playing a bit with Swift and iOS on my free time. Being a TDD affictionado I was happy to find Cory Foy’s article on Test-Driven iOS Development with Specta and Expecta. Although it is actually for Objective-C it was an excellent introduction on how to get started with TDD in that environment.
Debugging memory leaks with Valgrind and GDB
While debugging memory leaks in one of my 
private projects, I discovered that GDB and Valgrind can actually operate together in a very nice fashion.
GDB is capable of debugging remote programs, like for embedded device software development, by using a remote protocol to communicate with a proxy within the device.
Valgrind is an almost necessary tool if you are working in an environment of dynamically allocated and returned memory. It follows each allocation in your program and tracks it to see if it is returned properly, continue to be referenced or is lost in space, which is a ‘memory leak’. And as any leak, given enough time you will drown, in this case require more and more memory, until either you program is eating up your whole computer, or you get out of memory. Continue reading “Debugging memory leaks with Valgrind and GDB”
Before extract, make the code exactly the same
Removing duplication is maybe the simplest and most important fight against code smells there is. And for many cases it is fairly easy if you are using something with reasonable refactoring support like Eclipse. Just mark one instance, extract method/expression, replace second instance with call. Done!
But there is not only duplication, but also near duplication. And I find that, for me, there is much more mental resistance to get to grips with this type. What you should do, and I try (at least for a brief moment), is to make the two sections of the code *exactly* identical first. Then the duplication is just an instance of the above case, and just as easy to fix.
But sometimes I just can’t see how to change them to be exactly the same. I need some glasses. And actually it shouldn’t be so hard to help me out here, but so far I have failed to find that help.
I want to be able to mark two regions in my editor, ask it to mark anything that is different. There are one million diff-tools that works on two (or more!) files, repositories or directories. Why is there no region diff in Eclipse?
Suggestions?
Assert-first, Backwards directed, Completion assisted Coding
Testdriven development, TDD, is a well-known technique to be able to focus on the tiny next step of specific functionality to implement. My experience from watching a number of coders in our Dojo’s, and from my own work, is that even though focusing on the test is the idea, it is easy to get side-tracked. All the little details that need to be set up before arriving at the assert statement at the end of the test are distracting. Instead of focusing on the feature the coder starts thinking about which variables are needed, their names, are there any constant values, which handy functions do we need to write. This sequential mode of coding is particularly obvious in more inexperienced programmers and splits the focus. Trying to keep many details in your head at the same time as trying to maintain the direction of the test is hard.
I’m a mediocre programmer and I have a hard time keeping all the details in my head. I need help to focus on what is to be achieved. TDD has been a tremendous help and is my safety net. But to get one step further I have started to use a technique, or rather coding style, that starts with writing the assert-statement first. Yes, just the assert. This helps me think about what the test should actually test before I think about how to set up the test. Let’s call that “Assert-first coding”.
In the same way as for the assert statement in the test, you can start with the end result in the production code. E.g. the return statement in a function is the required goal. Once the return statement is in place we can think about, and implement, what is required to get statement to compile. Step by step we can work our way backwards until we have the complete function. Let’s call that “Backwards directed coding”.
Espescially in typed languages and with modern IDE:s like Eclipse, it is possible the use the Code Completion and Quick Fix features to quickly and easily fill in the gaps and create the pre-requisites to get the assert or return statement to a runnable state. Let’s call that “Completion assisted coding”.
If you combine these techniques you get a style that could be called “Assert-first, Backwards directed Completion assisted Coding”, ABC;-) Thanks, Joakim Holm for the name. (I initially called it “ACBC”.)
I’ll get back with some screen captures to show what I mean.
Agile Languages?
Occassionally there is discussion about if computer languages can be agile, and if so, which. I belong to the group of people that think that it is only people that can be agile, and it is more a feeling than a matter of practices and techniques. So, of course there are no agile languages!
But today I listened to an Agile Toolkit podcast with Dave Thomas (“PragDave”) talking about different topics with Bob Payne. When Dave pointed out that programmers really need to learn a multitude of programming languages, and gave some examples, my thoughts wandered back to my language and compiler designer days. And suddenly I realized that there actually are agile languages. All the lazy-evaluating, functional languages are agile, or at least follows one of the most important agile principles, YAGNI. They do not compute anything that is not absolutely necessary, and when necessary, only computes exactly what is needed, with precision and timely delivery.
Bowling Kata “solution”
One of the most famous katas (excercises) for TDD (test-driven development) is the Bowling Kata. There are some sites that describe the Kata, which has the following “stories” as input:
- A bowling machine want to report the number of pins the player strikes down for every roll the player does
- A bowling player want to see the resulting score of a completed game
It is actually a rather simple Kata, but never the less allows for demonstration and training of some TDD tasks and strategies. But of course you need to know the bowling rules…
We have used the Bowling Kata for our Coder’s Dojos, and have learned a lot from it. The following is a recording of one of my solution to it :
Fifth Dojo, and still learning…
Today we ran the fifth Coder’s Dojo. Still the same Bowling Kata in Java and Eclipse (oh, I love that IDE!). This time we where only four, which allowed each of us a lot more driving time, which was fun.
This time we managed to get through the whole Kata, and even found some time to discuss one of the issues bothering some of the participants already from the start, namely error checking. Andreas and I went down that path while on the flight from the Agile Business Conference 2006 and had some learning to share. The main point being that error checking, like checking for score() being called before the game is finished (remember, the user stories actually calls for the game being finished) has to be made explicit, obviously driven by a user story (the user in this case being what ever actor is interested in such a message).
But, the most interesting thing was that we where very explicit about doing a refactoring to get a design which is better suited to fit new functionality into. I think we actually made a few steps better than Uncle Bob’s original. That feels nice 😉
Coder’s Dojo Sweden is open!
Yesterday Andreas Larsson and myself hosted the first ever Coder’s Dojo in Sweden. If you have never heard about it before you can visit its home page and explore more.
It was an interesting experience. Having run through the Bowling Kata a number of times, both together and by ourselves, we still found that discussing with people was a learning experience since many of the attendees did not have the experience we did. And as always, talking about something forces you to be clear in a way you don’t need to otherwise.
My personal insight with the Kata the way we played it out (inspired by Uncle Bob’s presentation of it) was how strong the urge to create new classes is in all of us. Andreas and I fell into that same hole when we did the Kata in Oulu the night before XP2006.
I also discovered that I had insights that I where not aware of with regards to the brittleness of testcases; that you should be careful to test the intended behaviour, and not the design. E.g. when doing the first test case for the Bowling Kata, don’t test that the score of the created (presumed empty) game is zero. That’s implementation! The required behaviour (and the only thing that should be tested) is that calculating the score, after all the rolls of the game, should give the correct result.
And of course, you can find a lot of thinking on the BDD (Behaviour Driven Development) on the web.