Turtle sprinting, day 3
It is 0:30 and I’m sipping a duvel beer. I’m still coding as I want
to really restrict the amount of duplicate code that’s repeated in each
and every script. So, with 30 scripts, combining 21 lines of code into 1 line
means 600 fewer lines. Who can say no to that? I’m still working on it, but
I’ve already eradicated quite some lines.
I’m onto my third kind of beer. Oh, and dinner is good, too! This is what
Pieter cooked up:
- Like I said above, I worked on getting the copy-paste stuff that turned up
in every script unified into a couple of short scripts.
- I also did a couple of bug fixes, logging adjustments and optimizations.
- Turtle-urban’s tickets are mostly gone. Trac cleanup time! Lots were
outdated or are just plain fixed with the new setup. Jonas collected test
datasets so that he can build up test cases tomorrow. His aim is to get
turtle much more robust by using several high-level testcases. I’m
personally looking forward to this a lot.
- Pieter has been beating the installer into shape all day: both turtle rural
and turtle urban now install fine. (Rural needs some work on it’s own code,
but the installer is fine). Even uninstalling works.
- I set up the basic buildout for turtle-rural yesterday and this
morning. Coen has been adjusting his rural scripts all day to this new
structure. At the same time, he’s going through the trac tickets left and
right, fixing or closing them. And, as he has to touch every script:
reviewing his own code. Lots of good work happening here!
Wow, I’m happy with how this is all turning out. It was a bit of an educated
gamble how it would play out to switch everything over to properly released
and packaged python packages and to buildout. A gamble? Yes:
- Possible snag: two windows programmers. In practice: no problem at all. Only
small drawback is that they have to open a “cmd” terminal to run
bin\buildout.exe while everything else is done in windows.
- Ouch, I’m injecting quite a couple of new techniques into the mix: buildout, an svn
trunk/tags/branches structure and
setuptools packaging. Oh, and
with four of us at this sprint. Two of us are completely used to such a
structure: how hard are the other two programmers going to scream?
- Well, it turns out they’re not screaming at all. They like it. The whole
process is more predictable and stable. You can actually easily find
every piece of code you’re working on. It all works reliably.
- The switch to buildout means we have a mechanism that collects all the code
in one place. The result: the installer also can find it there. Without
buildout, the installer would be impossible. And without installer the
buildout would be too hard for ordinary customers. All parts benefit.
1:17 and two of us are still coding :-) You just cannot beat the joy of
working cooperatively on a single piece of code during a sprint with a couple
of people. Cooperating this way is fun!