As you may be aware from a previous post, back at the end of July, someone drove into the back of my little Seat Arosa. Just before we went on holiday to Canada for three weeks I got the news that the car would not be coming back from the repair shop.
We are now back from Canada, and I am without a car to get me to work. There are other ways of getting there – it’s cycle-able if I set out early enough, and there is a bus (although I have never used it.) However, I still think I need a car. So I have today put a deposit down on a new Citroen C1.
According to the dealer I should get it in about two weeks. I never quite trust such estimates, so I’ll be keeping a close eye on how things progress…
This looks like a neat idea. A presentation technique constrained to 20 slides, each of which gets exactly 20 seconds (with time for questions at the end).
I guess the logic is that of the Haiku or the 30-second TV ad. Setting extreme constraints squeezes out waste, forcing every word and image to pull as much weight as it can.
Pecha Kucha – Simon Brown
This looks interesting. The role of testing (at least, testing beyond unit-level regression testing and TDD) is the subject of much discussion in software development at the moment. Maybe I should actually attend this talk at Skills Matter in London on 18 September.
In The Brain of Gojko Adzic: Agile Acceptance Testing
Back when I was teaching, we had several attempts to improve the learning and teaching experience using student handsets which communicate back to a central system. Within their limits, such trials were generally successful; enough that the college bought several sets.
However, I always felt that the system was was woefully underused. Using such handsets in an entirely teacher-driven way for such tasks as in-lesson progress quizzes is only a fraction of the story.
Why not use them as an anonymous and continuous “backchannel” to indicate a preference that the teacher speed up, slow down, go into more detail, back off, give a concrete example, etc.?
Why bother with tedious register-taking when students can just “log in” using a remote handset?
Why not offer opportunities for learners and staff to anonymously vote on where the lesson goes next or indicate personal goals for a lesson or group exercise?
These are just a few “top of my head” ideas; there must be many more out there but they never seem to make it into practice.
Students Who Use ‘Clickers’ Score Better On Physics Tests
This is an interesting and thoughtful post. The term “business value” is often used in discussions of agile processes, but it can be hard to pin down what it really means.
AGILE IN ACTION: Agile2008: Converting business value into actual money
A discussion of the benefits and disadvantages of single vs multiple returns from a method cropped up today. Unfortunately we became distracted before getting to the meat of the opinions. To help stir up that discussion again, here’s a link to an article (and follow-up comments) from Mark Levison’s blog.
Notes from a Tool User: Multiple Returns from a Single Method
It should come as no surprise that you need to keep your wits about you when you write software. But the wise programmer should also be wary of blithely adopting any kind of “best practice” without considering the implications. Here’s a cautionary tale about a case where doing things as it appeared they “should” be done resulted in a performance problem.
Dangerous generics
I’ve just got back to work after three weeks of driving around Canada with my family. Stepping out of work for such a long time always feels risky, so this Dilbert cartoon from the day I left seems strangely appropriate 
This one made me laugh out loud.
Q: What do you call requirements that are not executable?
A: Specifiction.
via Lasse’s weblog – Another Agile 2008 quote
More research on that old chestnut about everyone being connected, this time based on data-mining of MSN instant messenger records.
Instant-Messagers Really Are About Six Degrees from Kevin Bacon – washingtonpost.com
I’ve never worked on a team with an explicit Agile Coach – I know several people who have worked in that role, just never with me.
With that in mind, this article is an interesting exploration of what the role of “agile coach” actually entails.
thekua.com@work » The Agile Coach Role
A long tract on several aspects of programming language design, tied together (sometimes somewhat loosely) by the concept of “orthogonality”.
Orthogonality
Whenever I bump into erlang (which seems to be becoming increasingly frequent) I seem to follow the same mental journey. First I look at the advantages, then admire the quality of the applications, then I get mired in trying to get my head around the syntax. Eventually I back off and decide to just run whatever app has caught my fancy, but then I spend several hours stumbling around the installation and configuration process. The end result is often that I just shelve the project and move on to something else.
The only real use I currently make of erlang is a Windows installation of ejabberd which forms the reliable heart of my XMPP experimentation.
Anyway, it’s nice to see more take-up of erlang. Here are some examples from InfoQ:
InfoQ: Erlang and Ruby Roundup: Vertebra, Scaling with Fuzed, Github
I guess this a bit old by now, but I hope they continue with this at least for the moment: a roundup of some of the interesting things going on in the Git world.
InfoQ: Git/Github Roundup: Ruby Books, Gems, Gitjour
This is interesting in so many ways. Not only that the Toyota system – long held up as a shining example of lean, sustainable working – can also burn people out, but also that the Japanese have a special word “karoshi” for death by over work. Learning and practising techniques to avoid this situation is vital for any team.
InfoQ: Death of Hybrid Camry Chief Engineer is Ruled Overwork
For more information on Lean, see also this rewcent InfoQ article
A cute story about problem solving and lateral thinking beating big-budget programs, but without any sources cited it can only be assumed to be a mde-up parable.
lixo.org :: Networks Are Smart at the Edges
I’ve certainly seen this in action. Confusion between the idea of a team, and the practice of a bunch of people “working together”. They are quite different things.
thekua.com@work » What do you have more of?
I have been working with Python a fair amount recently, and really miss a lot of the tool features I use when working with Java. In particular, lacking the ability to automatically apply common refactorings and auto-complete obvious code really “cramps my style”. In most cases I have a pretty clear idea of what I want to do, and how I want to get there, but I find that the process of using Python is just more laborious.
I guess that puts me squarely in Ted Leung’s group of “experienced developers” rather than the “early adopters” who are happy to use more generic tools in order to gain the benefits of a new language and its abilities.
IDE’s and Dynamic Languages at Ted Leung on the Air
I had great hopes for this when I saw the title. I normally use TDD (Test Driven Development) exclusively, but have been finding it difficult to get into the rhythm of TDD when developing in Python for Google App Engine. I’m just not familiar enough with the Python unit-test ecosystem. So a general purpose Mock Object framework looked as if it would be a useful tool for the toolbox.
Google Open Source Blog: Check Out Mox, Our Mock Object Framework for Python
Unfortunately, it uses my least favourite approach to Mock Objects: switch the Mock into “record” mode, manually perform a sequence of actions, then switch the mock to “replay” mode and run the real code to compare it against the recorded expectations.
In the Java world this is the approach taken by EasyMock. In a strongly-typed, pre-compiled language such as Java, this is just about excusable in order to gain method call validation in the IDE or compiler. But in a more flexible language I really can’t see the point.
For me, the overwhelming disadvantage of the record-replay approach is that it implies that there is only one complete correct sequence of collaboration calls, and that anything else is an error. In real systems this is simply not true. Some calls might be optional (such as a “getter” which may be cached”); some calls may be unimportant to a particular test; some calls may be happily repeated many times (such as a “hasMore” or equivalent status call); and most importantly, some calls may occur in any order.
Although typical record-reply frameworks try to address some of these issues, every such attempt makes the operation of the framework more clumsy and less obvious. It’s very hard to address the fundamental problem.
In my opinion, a much better approach to mock objects is for the Mock object to simply record all the calls made during the running of the test, and then provide a flexible set of accessors and assertions to apply to the result. That way, whoever writes the test case can also easily write specific assertions, such as asserting that the count of calls to “hasNext” is always one more than the count of calls to “next” without requiring special support in the framework.
Does anyone know of a more sensible Mock framework for Python?
This looks like a really useful idea. A central directory of APIs for software development, organised by function and by language/OS
www.apifinder.com – the essential directory for application programming interfaces