aporem.net

I like this very personal history of reverse engineering and the suggested test driven approach taken by S. Lott as a solution.

The idea is to extract an object structure from procedural code, cover it by unit tests to ensure its functionality and then take on the next piece of code. The question the author puts up, if this really is test driven in the strictest sense. I would not be this picky about it, since reverse engineering is a far more painstaking process than starting from scratch.

Like with computers, multi-tasking is a mere illusion for humans. There are not so many things one can do simultaneously at any given time. So we (computers and humans, especially when in front of the machines) have to simulate it by constantly switching from one task to another and then back again. But these context-switches cost time and energy, giving an upper limit of how well we can put up with more than one thing to do. And in contrast to machines our context switching is dependent on the complexity of the task we want to jump into and of its familiarity with the task we are trying to get out of.

It is then not very surprising that if we cram in our daily schedule lots of different things, little gets done. What is surprising though is that neither the project planning tools nor any of the calendar programs allow to schedule for these context-switches in an easy straight-forward way: there is no benefit in trying to schedule as large chunks as possible for any given task, so they create the illusion that 5 times one hour is as productive as one times 5 hours work!

So back to your schedule and tidy up!

There are quite a few parallel programming environments around: MPI, OpenMP, Ct, HPF, TBB,Shmemm, Portals, ZPL, BSP, CHARM++, Cilk, NESL, PVM, Pthreads, mpC, Tstreams, GA, TPIE, UPC, Titanium, Parlog, Split-C …

This creates a problem of choice for programmers, where one can argue that less choice would be beneficial; that it would allow to focus on improving the remaining languages.

An other argument is that a new and hence “yet another” parallel programming language will solve the problem.

This alone is an example of the problem of choice.

I found this little game which tries to teach dragons to survive with genetic programming the assault of the player.

It’s not working as desired (the dragons don’t team up and chase the player) but this makes it even more interesting. There are several flaws in the setup:

• Genetic programming does not create complexity by and on itself. The less input/initial instructions you pass to your agents, the more thought has to go into the genetic (i.e. reproductional) part of the code.
• The rules must enforce an active behavior. In this case, running away from the player would be a very good option for the dragon, since it is not punished for running, only for getting killed.
• The calculation of the individual fitness has to be tailored to the problem. If a dragon is killed in the first few rounds because it was put right next to the knight, it is considered less fit than his peer at the other end of the game field.
• There is no possibility to learn form encounters with the player: if he strikes, the dragon is slain. The dragon can not come up with a strategy in this short time.

But hey, it’s a good place to start and experiment with the code.

So what is SOA? — beside a neat three letter acronym?

It is the idea to get the business logic and the data separated and available over the network. Basically. But there’s a row about what it really is. — So go, read for yourselves!

Data can be interpreted in unforeseen ways: imagine to hide a picture in the histogram of another!

The idea is great and so is the online tool to generate those.

Years ago, it there was only one way to update the ports tree: by CVS. Then Colin Percival wrote portsnap and greatly reduced the overhead and time it took to make a checkout.

He also wrote the birthday note.

There is a bug in the new version of Microsoft’s Excel: 77.1*850 should give 65,535 but gives 100,000 instead.

Joel Spolsky explains in great detail and, being a programmer on the Excel team in the past, apologetically the inner workings of the program that lead to this behavior.

If you do not want to read the whole article: it’s merely a bug in the way the numbers are displayed, not calculated.

The Tor network provides anonymity, not security nor privacy. They even state this on their website. But people obviously do not know the difference. Bruce Schneier has a nice story to tell about it.

Ovid wants a new perl book. What he really points out is that with the freedom perl gives the programmer, one needs to really grasp the concept of OO if one wants to avoid the pitfalls he mentions. The topics he suggest are essential for any book on OO, not just for perl:

Responsibility-driven design.

The difference between class and instance data/methods.

How inheritance breaks encapsulation.

When to throw exceptions.

Composition via delegation.

Class consumers versus class cooperators.

Why the Liskov Substitution Principle is important.

Polymorphism and allomorphism.