Workout for your brain

with the holidays approaching, we can expect the average programmers to code less and eat/drink/play/sleep more. to keep our precious brains in good shape, give it a workout by solving this puzzle.

Instructions:

A family of six (parents, 2 daughters and 2 sons) got lost in the forest. they were hungry and ate some magic mushrooms they found under a tree. the mushrooms caused the dad to think the daughters were evil witches and the mom to think the sons were pesky microsoft marketers. to make matters worse, they bumped into an escaped serial killer while they were high on the mushrooms. fortunately, an off-duty policeman happened to be "hiking" in the woods and saw them. he dropped his sack of mushrooms and went to the family's rescue from certain death.

now the eight of them need to get out of the forest. they came to this river, but there was only 1 raft capable of carry a maximum of 2 persons. your job is to help all of them cross the river while respecting these conditions:

• only the mother, the father or the policeman can operate the raft
• the sons cannot be left alone with the mother without the father's presence
• the daughters cannot be left alone with the father without the mother's presence
• the fugitive cannot be left alone with anyone without the policeman's presence

Click on the big blue circle at the bottom right to start [open in new window].

* flash file removed, click here *

The Eight Fallacies of Distributed Computing

by Peter Deutsch (sent to me by roy)

"Essentially everyone, when they first build a distributed application, makes the following eight assumptions. All prove to be false in the long run and all cause big trouble and painful learning experiences.

1. The network is reliable
2. Latency is zero
3. Bandwidth is infinite
4. The network is secure
5. Topology doesn't change
6. There is one administrator
7. Transport cost is zero
8. The network is homogeneous"

I do make those assumptions when I go distributed but, fortunately, I don't just go distributed for every project I design. for instance, I rarely implement a distributed system to save just a few seconds on operations like UI, data transfer, etc. I only do it for heavy hours-long calculations that can be divided and localized. I employ passive distribution where tasks are not pushed onto the nodes, they are put in a job pool and the nodes just pick from there. a job is only specs for a product (low bandwidth), the logic is preinstalled on the nodes. when a job is not finished within a specific time, it is rendered obsolete and a new job of the same specs will be created with a longer timeout. therefore, items 1, 2, 3, 5, 6 and 7 are taken care of. item 4 is only important if security is an issue. so the only thing I have to ensure is item 8.

Deustch made very good points, and I believe those issues are what naturally drove me to build the kind of distributed systems I do.