Saturday, January 14, 2006

My stereo set is not an FSM!

Ever since my document on Finite State Machine, a small thing has been bugging me. It is my AIWA XS-G3 stereo installation. Because, when I am playing an audio cassette and press the off button, it doesn't switch off immediately. In stead, it stops playing, it lowers the blue transparent door in front of the cassette player, changes the display, and then, and only then, switches off. This process takes about 3 seconds! To describe this system with a Finite State Machine, all these actions would have to be state-exit actions, that should theoretically be instantaneous! Now, there is nothing in this world that takes no time at all, but 3 seconds can be called instantaneous by no stretch of the imagination.

In stead: the transitions of the systems, are states in themselves!

Since then, I have occasionally wrecked by brain to turn transitions into states. And , even though this not easy, I sort of managed, although my solution does not have the simplicity I sought. To understand this, you have to take another thing into account: when a transition takes time, and is interpreted as a series of states, these states may be subject to transitions themselves. For example, suppose the cassette door closes and I keep my fingers in the cassette, and the audio system has a feature that detects this, it should stop moving and break off the entire sequence. Or, may continue later, when I have removed my fingers again. Argh.

Only when I had sort of a way to tackle these things, altough not bulletproof and not sense and simplicity, I could take the time and look at my creation. And then I looked at my audio system and it dawned on me: "no, wait, it doesn't work like that".

My audio system can be implemented much more simple and directly as a Planner. A system that uses hierarchical decomposition. A system that sets goals, like 'shut down', that have subgoals, like 'cassette door closed'. A system that has behaviours to reach these goals, like 'close cassette door', that may be temporarily interrupted by yet another goal, like 'wait until passage is clear'.

Planners are good, planners are powerful, but they lack the complex bottom-up state mechanisms of an FSM that I love so much. So now I should start dreaming of a combination of a FSM and a planner...

Fight guestbook spam

The guestbook of my Andreas website got spammed so much that 2/3rd of it was spam. The spamming frequency increased from once a month to several times a week. It became impossible to clean up the spam manually.

On the other hand, I did not want punish my users by having them type some number before entering there message.

I now use a technique that is just as useful and at the same time does not require any action from the user. When the guestbook is visited, the guestbook form is extended with a (dynamic) secret code. If the user sends the form with his message, the code is sent along. The message processor then checks if this code is the same as the code he expected. Only then the message is allowed.

The code is generated, so that it is different each time. I use a somewhat simple code that remains the same all day. Once you know the code (from the HTML source code), you can spam me all day long :) But the next day the code is different. It is still possible to create a script that creates spam automatically for this site, but I seriously doubt that our spamming friends will go through all that trouble. And if they do, we will, *ping*, enter the next round, and the fight is not lost :)