A friend sent me the link to this video, and I have to say, this is the most clear and direct explanation of the difference between linear processing and concurrent processing I’ve ever seen. …That, and it’s just darn cool to watch a 1100 barrel paintball gun get fired.

If you’re into reverse engineering biological systems–in my mind, one of the most fun parts about AI programming–this talk by Drew Endy is absolutely a blast. Also be sure to check out the BioBricks project at openwetware.org or download the actual “bricks” at the MIT Registry of Standard Biological Parts.

The BioBricks are sequences of DNA described in a standardized, open-source format where each sequence represents a single, interchangeable part or “device”. A data sheet is provided for each device that describes what it does and what its tolerances and parameters are, etc., similar to the data sheet for an electronics part. Like an electronic component, devices can be combined together to make more complicated structures. When you’re finished designing your device, the sequenced DNA can be inserted as a plasmid into a suitable host cell and used to make all kinds of cool stuff, like this biological film where the bacteria change color in response to light.

Hello World displayed by light-sensitive, color-changing eColi

1. Consistency breeds ease of use. Even if your buttons do some weird thing, as long as they all do the same weird thing users will eventually figure it out. Make the buttons each behave differently, however, and the user is lost forever.
2. Sort data the way it is most likely to be used. The logical sort order for a date is chronological, not alphabetical.
3. When in doubt, the default option should be the least destructive \ most undoable choice.
4. If you have to write an explanation of your code, never assume that the reader has read the same papers you have, unless you told them what else to read–and where to find it–first.
5. Wrong code comments are worse than no code comments.
6. “Copy and paste” errors happen to everyone. Be on the look out for them.
7. If a bug disappears in debug mode, 90% of the time it will be one of two things: 1) you are overflowing memory or 2) you have a thread race condition. At least two thirds of the time, it will be a memory overflow. It is extremely unlikely it is problem with the compiler.
8. Releasing your program compiled in “debug mode” is not an acceptable “fix”. The bug only looks like its gone… it’s still there, and can come back to bite you at any time. Don’t do it, no matter how tempting it might seem.
9. If the program crashes on exit, you probably freed something you didn’t properly allocate, or that isn’t allocated anymore.
10. Leaking memory is bad. Freeing pointers or objects that don’t belong to you is worse. If an object you expect to be free is still hanging around, don’t force it, find out why… “fixing” bugs by patching the symptoms and not the cause makes the code much harder to repair in the long run.
11. If you have an intermittent bug, and your “fix” made it go away and you don’t know why, the bug is almost certainly still there. If you can’t explain it, you didn’t fix it.
12. Good documentation is more important than more features. Write it down, even if it’s just a simple “readme.txt” file… the next person who has to work with your stuff will appreciate it!

More tips? Ideas you would recommend? Post a comment!

From a Zen Kōan:

Gyosan asked Isan, “If a million objects come to you, what should you do?” Isan answered, “A green object is not yellow. A long object is not short. Each object manages its own fate. Why should I interfere with them?” Gyosan bowed in homage.

It’s good advice for programming multi-core, too.

Ambient occlusion is a lighting technique that is commonly used to create soft shadows on objects. Ambient occlusion isn’t used to create the type of shadows that are cast from objects with a light shining directly on them. Instead, ambient occlusion generates the type of deep shadows that appear in the corners or creases of things, where it is hard for the light to reach.

Technically speaking, ambient occlusion is a global illumination technique. However, in common usage of the term it is often referred to as a cheap alternative to global illumination. To clear up any confusion, what most renderers refer to as “global illumination” is actually an amalgamation of several techniques such as radiosity, metropolis light transport, image-based lighting or photon mapping. The actual techniques used differ slightly from renderer to renderer. Some renderers include an ambient occlusion term as part of their global illumination calculation; others do not.

Like most global illumination techniques, ambient occlusion is dependent on the other geometry in the scene. Ambient occlusion on its own generates less realistic lighting than “full” global illumination. However, ambient occlusion is much faster and less complex to calculate than other methods which is why it is still popular among game developers and in production animation.

(Left) Without Ambient Occlusion. (Right) With Ambient Occlusion
Click for larger image.

(more…)