Mike Schaeffer's Blog

Reading Slashdot today, I heard that Jef Raskin has passed away from cancer. If you don't know who Jef is, it's safe to say that you have been influenced by his ideas if you're reading this blog.

Dr. Raskin was one of the first human interface experts to contribute to and be involved in the Apple Macintosh. computer. While it's true that the design took a different direction from some of his initial ideas, he played a major role in defining the user interface ethic of the Macintosh, and consequently basically every other major computer interface.

After leaving Apple, Jef went on to continue his ideas with the SwyftCard and Canon Cat. The best articulation I've seen of his ideas regarding interface design is in his book, The Humane Interface. He has also put a great deal of his work on his personal website.

This is a sad day, indeed.

Larry Osterman has been running a nice series of posts on issues related to thread synchronization and concurrency related issues. It's been full of useful tips and tricks, I particularly like part 2, Avoiding the Issue. That's a technique that's worked well for me in the multithreaded systems I've worked on. Of course, if you're writing SQL Server, etc. I'm sure you can't take nearly as simple an approach.

There's a good definition of the word idempotent over on Dictinoary.com. In a nutshell, the word is used to describe mathematical functions that satisfy the relationship f(x)=f(f(x)): functions for which repeated applications produce the same result as the first. For functions that satisfy this condition, you can rest assured that you can apply the function as many times as you like, get the expected result, and not screw anything up if you apply it more times than you absolutely need. This turns out to be a useful concept for people developing software systems.

One of the most common examples of this is in C-style include files. It's common practice to write code like this, to guard against multiple inclusions:

#ifndef __HEADER_FILE_GUARD
#define __HEADER_FILE_GUARD

// ... declarations go here...

#endif __HEADER_FILE_GUARD

This idiomatic C code protects the include file against multiple inclusions. Include files with this style of guard can be included as many times as you like with no ill effect.

The benefit to this is that it basically changes the meaning of the code #include <foo.h> from "Include these declarations" to "Ensure that these declarations have been made". That's a much safer kind of statement to make since it delgates the whole issue of multiple inclusions to a simple piece of automated logic.

Of course, this is pretty commonplace. More is to come...

Frank Hecker, in an effort to teach himself more about Blosxom has done a cool thing. He has taken the source for Blosxom and annotated it with extra comments to describe what it's doing each step of the way. I don't know if I'll ever use the knowledge to hack Blosxom, but it's still good reading.