Another Day In The Code Mines

Time for a reboot...

2011-06-08T01:50:00.000-07:00

Okay, it's now been more than a year and a half since I updated this blog. I need to get back on the horse. Stay tuned for an update soon (really)!

JavaScript by example: functions and function objects

2010-01-24T13:08:00.000-08:00

I've been working in JavaScript a lot these last couple of months, and I feel like I've learned a lot. I wanted to show some of the more interesting aspects of JavaScript that I've had the opportunity to bump into. I'll use some simple examples along the way to illustrate my points.

Note: If you want to follow along with the examples in this blog post (and the followup posts), you'll probably want to use an interactive JavaScript environment. I tend to use Firebug with Firefox when I'm trying stuff out, but there shouldn't be anything in these examples that won't work in the WebKit console in Safari or Chrome, or in Rhino, for that matter.

Functions

A simple function is defined and used in JavaScript thusly:


   function add(x, y) {
       return  x + y;
   }
   console.log(add(3, 5)); // this prints "8" to the console

This does just about what it looks like it does. There's no trickery here (the trickery comes later on). Let's say that we want a version of this function that takes a single argument, and always adds 5 to it. You could do that like this:


   function add5(a) {
       return add(a, 5);
   }

   console.log(add5(3)); // prints "8"

But what if you're going to need a bunch of these one-argument variants on the add function? Well, since functions are first-class objects in JavaScript, you can do this:


   function make_adder(v) {
       var f = function(x) {
           return add(x, v);
       };
       return f;
   }

   var add7 = make_adder(7); //create a function
   console.log(add7(3)); // prints "10"

This is only slightly more complicated than the original example. One possibly subtle point here is that the returned function "captures" the value of v that was passed into make_adder. In a more formal discussion, you'd call this a closure.

PuzzleTwist is now available!

2009-06-07T22:11:00.000-07:00

My latest creation is now up on the iTunes App Store. It's called PuzzleTwist, and it's a puzzle game where you unscramble a picture by rotating the pieces. As each piece is rotated into place, others will rotate as well - some in the same direction, some in the opposite direction. The key to solving the puzzle is to figure out what order to move the pieces in.

One unique feature is that the rules for each puzzle are different - some are simple, some are more complex. A few are so difficult that I can't solve them without looking at the solution.

Once you've solved a puzzle, you can save the resulting picture in the Photo Library on your iPhone, and then use it as the wallpaper image for the phone, or assign it to one of your contacts.

PuzzleTwist also keeps track of the best reported scores, so you can compare your scores versus the rest of the world.

If you're a puzzle fan, you should check it out. Here's the iTunes store link.

On a side note, this application was approved much faster than the previous applications I submitted. Perhaps the App Store review team is coming out from under their backlog.

The eyes have it - a tale of 3 vision problems

2009-05-12T18:24:00.000-07:00

I'm recovering from a head cold today, so rather than try to do heavy programming work, I decided to write up a personal story that I've been thinking about lately, for a variety of reasons.

As anyone who knows me personally can probably attest, I wear glasses and have pretty bad eyesight. Not many of my friends, and probably not even all of my family, know that I have three distinct vision problems, only one of which is actually addressed by my glasses. I'm going to tell y'all about all three, more or less in the order that I found out about them, and the ways in which they've been treated.

Disclaimer: I'm not an eye doctor, nor an expert in human vision. This is all about what my experience has been. It's entirely likely that I'll make at least one glaring error in my use of some technical term. Feel free to correct me.

Chapter 1: Nearsightedness and Astigmatism

Okay, that probably looks like two different problems, but they're both refractive issues, and they're caused by misshapen eyeballs, and so are corrected easily with eyeglasses. If I remember correctly, I got my first pair of glasses in the 5th grade, when I was 10 years old or so.

I was pretty astounded at the difference when I put them on - for the first time, I could see the leaves on trees as individual objects. I asked my eye doctor how bad my vision was compared to the 20/20 that's considered "normal" and got the unsatisfying response that the 20/x scale wasn't really a useful measure for people with strong nearsightedness. Since I can barely find the eyechart on the wall at 20 feet without my glasses, I can now understand where he was coming from.

There was some consternation amongst the various parties involved about how it is that I could have gone without glasses as long as I had without anybody noticing that I was blind as a bat. For whatever reason, there wasn't any mandatory screening for vision problems in my elementary school. I got screened for a number of other potential issues, amusingly including colorblindness, but nobody ever stuck an eye chart up on the wall and had me read it.

The biggest issue was probably a simple (dare I say child-like?) assumption on my part that everybody else saw things more or less the same way that I did. So, since I couldn't see the blackboard if I was sitting in the back row, I assumed that nobody else could, either. And if it was critical to the learning process for us to be able to read what the teacher was writing, the school would have arranged the classroom such that it was possible, right?

It probably didn't help that I was also a bit of a daydreamer and a slacker. I think that when I said I didn't know that we had homework due, my teachers and my Mom assumed that I just wasn't paying attention, when in reality, I might have simply not seen the homework assignment written on the board.

As I get older, and more and more of my friends have children, it's occurring to me that there might actually be something useful for other people to learn from my experiences. I think the lesson here is actually a pretty simple one. Parents, talk to your kids about what their sensory experiences are. If someone had at any point between age 2 and age 10 simply asked me whether or not I could see some distant object, or count the number of birds on a telephone wire, or even tacked up an eye chart on the wall and tested me, I might have gotten into glasses sooner.

Alright, so I got glasses at age 10, which helped a lot with being able to see what was written on the blackboard, probably made it a lot safer for me to ride my bicycle around, and generally greatly improved my quality of life. Problem solved, right? Not so much. It turns out that I had another problem, which went unnoticed for several more years, despite going to the eye doctor regularly.

Chapter 2: Strabismus, or the "turned" eye

My right eye has a tendency to turn outwards and upwards, away from whatever it is that I'm looking at. When I was younger, this happened involuntarily, and fairly frequently. These days, I can do it "at will" which is a pretty great way to weird people out if they haven't seen it before. It still tends to happen spontaneously when I'm tired, or when I'm drunk.

Since my left eye is (evidently) my dominant eye, the turning out of my right eye didn't cause me much difficulty, except in one critical visual skill - depth perception. As best as I can remember, I was hit in the face by a baseball or softball while trying to catch it at least a dozen times during my youth. I was also considered pretty "clumsy" in general by most of my friends.

An interesting aside is that your brain actually uses a lot of other cues besides the convergence of your eyes to judge depth, so it's not exactly true that I didn't have any depth perception. It is true that I had really bad depth perception up close, which is where convergence counts the most - hence my spectacularly-bad performance in the whole "get the glove up in front of the ball before it hits you" task.

This particular quirk in my vision went for quite a while before being discovered. In fact, I think it wasn't noticed until I was examined by a new eye doctor for the first time. The doctor who examined me actually had an intern working with him at the time. When he discovered the eye turn, he called the intern in so he could see how it worked.

Having established that I had this eye problem, the question then became what to do about it. The treatment for this problem varies depending on the ultimate cause, but can include everything from eye exercises, to wearing an eye patch, to surgery. At the time, it was widely believed that any treatment for this condition was essentially useless after about age 10 or so.

The only recommendation from the eye doctor was that they could put a "prism" correction in my eyeglass lenses, which would help reduce any eyestrain I felt from the misaligned eye. As it turned out, the prism correction didn't do very much, either positive or negative, for me, though it did help my eye appear to other people to be pointing in the right direction.

In the years since, I've met several people who've had the Strabismus surgery, mostly as young children, and overall the success rate doesn't seem to be particularly high. I opted not to have the surgery, and it's worked out pretty well for me. I'd say that if you (or your child) have Strabismus, and someone suggests surgery, you'd do well to get a second opinion, and/or try some of the other treatments, before going forward with the surgery.

Chapter 3: Amblyopia, or "lazy" eye

It turns out that if you have Strabismus from an early age, and/or if your eyes have significant differences in their refractive power (which mine do), then you've got an excellent chance of developing Amblyopia, which is where your brain adapts to ignore the input from the defective eye.

I had always known that the vision in my right eye was considerably worse than in my left eye, even when I wore my glasses. I had assumed (there's that word again) that the difference had something to do with the difference in astigmatism and nearsightedness between the two eyes. While that was probably part of the cause, it wasn't the whole story.

It turns out that my brain had mostly adapted to not use my right eye, though I still had some amount of vision from it. My right eye provided some peripheral vision on that side, and was essentially ignored for everything else.

An interesting consequence of this that I discovered sometime in my twenties, was that I actually couldn't read if I covered up my left eye. This was a very strange experience. I could see through my right eye fairly well, and there was an image with shapes on it that I knew I ought to be able to recognize, but I wasn't able to make sense of them, at all.

Chapter 4: What I did about it

It bugged me that my eye was pointing out into space like that, and it really freaked me out that I had one eye that really didn't work at all, so I decided to try to "fix" it. You'll recall that the eye doctor told me that there really wasn't much to be done about this since I was "too old". I figured that if it wasn't going to work, it wasn't likely to hurt to try some things.

And I also figured that you hear about people who suffer traumatic brain injuries of one sort or another, and need to spend years in therapy, while their brain works around the damage. By comparison, working around a mental block on my right eye should be easy, right?

I started working on getting my right eye to point in the right direction. Since I did this on my own, I wasn't following anybody else's accepted eye training program, I just did the things that made sense to me.

I strengthened my eye muscles and stretched them by repeatedly moving my eyes back and forth to the very limits of their motion. Sometimes I'd go left to right, sometimes top to bottom, sometimes in circles one way or another. I did this for a few minutes at a time, working up to about 1/2 an hour or so.

I did these self-invented exercises nearly every night for probably a year or so, before I started noticing an improvement. When I first started, it was relatively easy for me to over-strain my right eye by trying to force it to the limit of its motion. Let me tell you, a cramp in your eye muscles is no fun at all. I still have a couple of positions that my right eye really doesn't like to go into, but the range of motion is much improved.

Concurrent with the work on the eye muscles, I tried closing my left eye when I was performing various everyday tasks - watching TV, shopping, driving (not in heavy traffic!), or just walking around. Doing that was always very tiring, and a bit stressful. I tended to get headaches if I tried to do it for very long.

Sometime after I moved to California, I had a breakthrough - occasionally, I'd briefly get my eyes to align properly as I was going about my everyday business, and the whole world would suddenly snap into 3-D perspective. It was really disorienting the first couple of times it happened, but I soon enough got used to it.

It's a little like those "magic eye" random-dot stereograms. At first, it takes a while to get the knack of getting your eyes to cross by the right amount. Then suddenly, you get it right, and the image jumps out at you. After that, it gets easier to do. Over the course of several more years, I gradually trained myself to keep my eyes pointed in the same place, such that it's now second-nature.

I did go through an irritating period where the convergence of my vision wasn't 100% correct, but I was starting to pick out more detail with my right eye. That caused some double vision and headaches, from time to time. These days, I only have double vision sometimes at night.

Chapter 5: Closing Thoughts

Well, this is already ridiculously long, so I guess I'll save some of the amusing anecdotes I was originally going to include in here for a follow-up post. Mostly I wanted to get the story down so the folks that have heard me wise-cracking about "now" being able to see in 3-D know what I've been talking about.

I also hope that if someone with relatively mild Strabismus and/or Amblyopia comes across this article, they'll be somewhat encouraged by my success in overcoming them, even after having a late start. Everybody's case is going to be different, but personally, I'm glad that I made the effort.

Release early, release often...

2009-04-22T18:54:00.001-07:00

Six Apps In Six Months - or, Why Mark Can't Schedule

That was the plan, anyway - but I haven't been able to keep myself on track. It's really difficult to release something when you're the only engineer working on it. It's hard to resist the temptation to just keep polishing the thing, or try out some new ideas, until you're well and truly past your milestone. Ah, well.

Beta Test Now Open
In the interest of trying to keep the pipeline flowing, I've just released "The Picture Puzzle Game Without an Interesting Name" to a select group of Beta testers. Since I don't want anyone to miss out on the fun of seeing what you get when I'm forced to release something that I don't think is ready, I'll put a link here to Starchy Tuber's Secret Beta page, where you can sign up to Beta test my latest creation.

If you like puzzle games, or if you're just interested in seeing how the sausage is made, the Starchy Tuber Secret Beta program is the place to be!

I reserve the right to limit Beta signups to the first 100 applicants (ha! as if...).

Grr. I just found a typo on the Beta Sign Up instructions. I'll go fix that...

Easter Pictems - a marketing experiment

2009-03-25T09:26:00.000-07:00

I'm trying an experiment. There's a free version of Pictems up on the App Store now, loaded with just the subset of items appropriate for Easter.

This version is called "Easter Pictems", appropriately enough, and you can get it here, if you're curious about Pictems, but didn't feel like ponying up the $2.99 to find out whether you liked it.

I'm hoping that folks will download the free version and like it enough to upgrade to the full version. This seems to be a common tactic among developers on the App Store. Of course, people have to find out about your free app if it's to be of any value as a marketing tool. I'll update this post if anything dramatic happens with sales.

In related news, product #2 is coming along nicely. It's a puzzle game, along the lines of the sliding-squares puzzles you might be familiar with, but with a twist (literally, in this case). For this game, the idea of Free and Pay versions makes a lot of sense, so I'm going to release both at the same time. Here's a preview of the (as yet unnamed) puzzle game:

Obsolescence is a pain in the neck...

2009-03-05T16:16:00.001-08:00

I'm trying to clean out some of the unused/unloved technology around the house. An interesting case that I'm currently working on is Yvette's old laptop. She used this thing back in her college days, and it'd be nice to be able to get the data off it (for nostalgic purposes), then send it to the great computer graveyard.

It's an approximately 20-year old NEC DOS-based laptop, with a black-and-white LCD screen, and a massive 20 MB hard drive. It boots and seems to run just fine, a bit of a miracle in itself, but I haven't yet figured out how to get the data off of it.

You'd think that it'd be relatively easy to copy the data off this thing, but:

1. Accessing the floppy drive causes the computer to reboot.

2. Neither the serial port nor the modem are recognized by the communications software installed on the thing, so I can't transfer data that way.

3. This computer is old enough that those (and the printer port) are only external I/O ports - there's no USB, no network port, and no wireless network ability.

I took the thing apart, and discovered that the hard drive in it is actually an IDE drive. Wow - that's almost a current-generation drive technology. I figured I could just get an adapter, and connect the old hard drive directly to a new system. Piece of cake, right? I've already got a Firewire-to-IDE external drive case, so it ought to be just a matter of hooking things up.

Not so fast. They do make a 44-pin to 40 pin adaptor just for connecting laptop 40-pin drives to an IDE connector, and I can connect that adapter to my Firewire-to-IDE external drive enclosure, and the drive spins up on power-up and everything. However, it isn't recognized properly. Apparently the firewire-IDE adapter doesn't work correctly with this drive. If I had to take a guess, I'd guess that the adapter doesn't support IDE drives which don't do DMA transfers.

It's a bit frustrating to have a drive that I know is readable, and have no way to get the data off of it. I'll probably try another IDE bridge and see if it works with this drive, but if that's a bust, I may be in the market for an OLD PC that I can connect the drive to, copy the data off of it, and then recycle.

There may be a trip to Weird Stuff Warehouse in my near future...

Grr. Blogger hates me.

2009-02-16T12:08:00.001-08:00

It won't even scale images correctly if I use the "upload image" tool. Oh, well. click the image to see the full comic...

A New Kind of Science meets XKCD

2009-02-16T11:51:00.000-08:00

400 pages down, 450 to go. Here's my impression so far, with a little help from xkcd:

Conspiracy Theories

String Theory

A New Kind Of Science

2009-02-07T15:27:00.000-08:00

I'm currently struggling my way through Stephen Wolfram's book A New Kind Of Science. So far, I've made it to about page 200 or so (of 850, not including almost 350 pages of end-notes). I'm not going to review it until (unless?) I've gotten to the end, but so far, I'm not very impressed. This book is really frustrating to read.

For starters, the title of the book ends up getting repeated over and over in the text. It's fairly common when writing about new phenomena or new ideas to assign names to them, for purposes of shorthand if nothing else. But no - phrases like "a new kind of science", or "the new kind of science I've discovered", or "the new kind of science described in this book" appear over and over in the first few chapters. This is really hard to read, and gives the impression of really trying to "sell" the idea that there's some kind of radical new idea here, which, 1/4 of the way in, there is so far no sign of.

It's also really hard to read a book where the author seems to be taking personal credit for well-known results in computer science, without so much as a reference to the work other people have done in the area. There are some references in the end-notes, but the main text doesn't seem to make any kind of distinction between what's new, and what's well-known or borrowed. For someone who isn't familiar with the field, it'd be easy to get the impression that Wolfram invented everything here.

I expected that this book would be fascinating. I've been interested in Cellular Automata since the 80's, and some of the things people have been able to do with the Game Of Life, or the Wireworld CA are pretty amazing. So far, though, there's been a lot of build up for the "big discovery", and some fairly rough-shod introduction to CA theory, but I feel like I'm not making much progress towards any kind of goal.

Yesterday, in an attempt to see whether it's just me that's having a problem with this book, I did a search for reviews of the book. The results were not encouraging.

I'd really like to hear from anybody who has made it all the way through this book. In particular, I'd like to know if I should just skip ahead to the grand conclusion, or slog through the rest of the text.

Well, I'm getting better...

2009-02-03T12:13:00.000-08:00

I updated my Blogger layout to the "new and improved" form of the old layout. I'm not sure how "improved" it is, but I ended up with a hierarchical archive, which makes it really easy to see how many blog posts I've had in any given month or year, over the history of the blog.

As I start my 4th year of blogging, I can see that the trend looks like this:
2005: 3 posts
2006: 12 posts
2007: 14 posts
2008: 25 posts

Last year was the first year that I managed to post at least one blog post a month. That's nowhere near where I thought I wanted to be, but at least I'm getting better at consistently writing. I think the writing has gotten easier for me, as well. I suspect that the quality hasn't gone up much (if at all), but I've effectively trained myself not to edit my posts to death, and I'm no longer taking months to get one paragraph just right for publishing.

So it's a qualified success. Onward and upward!

This week's iPhone SDK sob story

2009-01-24T13:08:00.000-08:00

I have ranted about this before, I know, but I'm a little irritated. Every single time I update the iPhone tools, I run into some crazy issue building code that worked just fine on a previous version.

This week, after digging my office out from under all the mess from moving to a new house, I revisited one of my older projects (yes, Pictems is finally getting an update!). And I ran into not one, but two of these issues. That's not counting the usual Code Signing errors, which I don't even pay attention to - I just click randomly on the Code Signing options until they go away.

(For my friends on the XCode team: Yes, I will file bugs on these issues, once I figure out what's going on. This is not a bug report)

Issue #1: During some early experimentation, I had set the "Navigation Bar Hidden" property on one of my Nib files. It didn't seem to do what I wanted, but I didn't bother to change it back. At some point, a change was made such that it now works. Great, but apparently the change was actually made in one of the iPhone tools, so even if I build my old project, with the SDK set to 2.0, I still get the new behavior. Easy to fix, but it's weird to have to change my "archived" version of my source so it builds correctly with the current version of XCode. If I build my old project against the old SDK, I'd expect to get the old behavior.

Issue #2: One of my resource files has a $ character in the name. One of the XCode copy scripts apparently changed such that it's not escaping the filename correctly, so now the resource doesn't get copied. Amusingly, no error message results - the file just ain't there. Yes, it's dubious to name a file with a $ in the name. But, again, it used to work just fine.

Oh, well. In the bigger scheme of things, I still prefer XCode/iPhone to Eclipse/Android...

A math problem

2008-12-28T14:46:00.001-08:00

Okay, so here's an example of where dropping out of math classes after Differential Equations is coming back to bite me a bit. I'm working on a kind of puzzle, mostly for fun, but possibly to incorporate into a future software product.

At its most basic, the solution process for the puzzle turns out to be solving a system of simultaneous equations. Which is something I learned how to do way back in High School, and for linear equations, I can even find off-the-shelf algorithms and libraries for doing so.

The catch, of course, is that these aren't linear equations. They use modular arithmetic, which is something I understand at a basic level, like anybody who programs for a living probably does, but I don't know where to even start breaking this down to solve a non-trivial version, and Google isn't helping me.

Let's start with a simple linear example:
5x + 7y + 4 = 0
4x + 3y + 1 = 0

Use whatever method you like, and you get:
x = 0.3846
y = -0.846

Piece of cake. Now, what if the equation looks like this?
5x + 7y + 4 = 0 (modulo 16)
4x + 3y + 1 = 0 (modulo 16)

If we want to find a few integer solutions for x and y, how do we find them? I could write a program to just guess every integer between 1 and 1,000,000 for each of the coefficients, and that'd find me a solution, but it doesn't scale well if I have a large number of variables. In the example equations given, there are rather a lot of solutions ([9,9],[9,25],[25,25]...), but I suspect that some other (carefully chosen?) sets of coefficients would have a much smaller set of solutions. Actually, that's kind of the point of the whole exercise.

Anyone out there got some hints for me?
Googling "simultaneous modular equations" got me:
http://en.wikibooks.org/wiki/Discrete_mathematics/Modular_arithmetic#Simultaneous_equations
and
http://www.nada.kth.se/~johanh/rsalowexponent.ps
,both of which are interesting, but not quite what I'm looking for.

For the case where the modulus is 2, addition is equivalent to XOR, and so logic minimization techniques from EE can be used, but it's not clear to me how to move those up to work in a higher modulus.

Synchronicity...

2008-11-13T10:29:00.000-08:00

A couple of posts ago, I said:

Hopefully backsliding on the Java thing doesn't mean I'm about to backslide
on the WoW thing - I can't afford the lost time. I've got to learn about how you
do things in Java again.

Today, I got an email from Blizzard, makers of World of Warcraft:

Mark,
You've been summoned back to Azeroth! Your World of Warcraft®
account has been selected to receive 10 FREE days of game time and a FREE trial of The Burning Crusade® expansion pack.

Weird timing. On the other hand, 10 free days can't hurt, right? right?

Just In Time compilation vs. the desktop and embedded worlds

2008-11-11T17:25:00.000-08:00

Okay, rant mode on. As I was waiting for Eclipse to launch again today, it occured to me that one of the enduring mysteries of Java (and C#/.NET) for me is the continued dominance of just-in-time compilation as a runtime strategy for these languages, wherever they're found. We've all read the articles that claim that Java is "nearly as fast as C++", we also all know that that's a bunch of hooey, particularly with regard to startup time. Of course, if Eclipse wasn't periodically crashing on me with out-of-memory errors, then I'd care less about the startup time - but that's another rant. Back to startup time and JIT compilation...

If you're creating a server-based application, the overhead of the JIT compiler is probably pretty nominal - the first time through the code, it's a little pokey, but after that, it's plenty fast, and you're likely throttled by network I/O or database performance, anyway. And in theory, the JIT compiler can make code that's optimal for your particular hardware, though in practice, device-specific optimizations are pretty minimal.

On the other hand, if you're writing a desktop application (or worse yet, a piece of embedded firmware), then startup time, and first-time through performance, matters. In many cases, it matters rather a lot.

There are a number of advantages to writing code in a "managed", garbage-collected language, especially for desktop applications - memory leaks are much reduced, you eliminate buffer overflows, and there is the whole Java standard library full of useful code that you don't have to write for yourself. I'm willing to put up with many of the disadvantages of Java to gain the productivity and safety advantages. But waiting for the Java interpreter to recompile the same application over and over offends me on some basic level.

On a recent project, we used every trick in the book to speed up our startup time, including a "faked" startup splash screen, lazy initialization of everything we could get away with, etc, etc. Despite all that effort (and unecessary complication in the code base), startup time was still one of the most common complaints from users.

Quite a bit of profiling was done, and in our case, much of the startup time was taken up deep inside the JIT, where there was little we could do about it. Why oh why doesn't anybody make a Java (or .NET) implementation that keeps the safe runtime behavior, and implements a simple all-at-once compilation to high-performance native code? Maybe somebody does, but I haven't heard of them.

For that matter, why don't the reference implementations of these language runtimes just save all that carefully-compiled native code so they can skip all that effort the next time? The .NET framework even has a global cache for shared assemblies. Why those, at least, aren't pre-compiled during installation, I can't even imagine.

Update:
I was helpfully reminded of NGen, which will pre-compile .NET assemblies to native code. I had forgotten about that, since so much of my most recent C# work was hosted on Mono, which does things a bit differently. Mono has an option for AOT (ahead of time) compilation, which works, sort of, but could easily be the subject of another long article.

Vote.

2008-11-04T11:33:00.000-08:00

It's election day today in America. THis is just a quick reminder for all my friends out there to get out and vote.

Vote.

Even if "your guy" isn't going to win.
Even if some irresponsible news organization announces "winners" for your state, before the polls are even closed.
Even if "the election has already been decided" before your state's polls close.

There's a lot more going on than just elections for the Federal Government. Whether you're pro-growth or pro-environment, whether you want to support gigantic infrastructure programs in a time of depression, or if you just want to reduce the cost of parking at the airport, ensure that your voice is heard.

Returning to Java, after 10 years away

2008-10-19T18:58:00.000-07:00

I'm once again writing Java code professionally, something that I haven't done in nearly 10 years (no, really - I had to stop and think it through because I didn't believe it, either). A couple of thoughts did occur to me, after I'd figured out the time frames involved.

I was a little taken aback by the very idea that Java is more than 10 years old. It just seems weird that a new programming language could go from introduction to being a major part of the world's IT infrastructure and college curriculums, in less time than I've been living here in California.

Java sure has evolved a lot in the last 10 years. There have been major changes to the language, the libraries, and the tools. I'd bet that some of my 10-year old Java code would throw deprecation warnings for nearly every line of code...

On the other hand, my final thought is along the lines of "Oh, my god. So much has changed, but Java is still irritating in nearly all the ways that made me crazy ten years ago! What have these people been up to for the last decade?"

Oh, and I was the first person I knew to "quit" Java, much like I was the first person to "quit" World of Warcraft. Hopefully backsliding on the Java thing doesn't mean I'm about to backslide on the WoW thing - I can't afford the lost time. I've got to learn about how you do things in Java again.

One good thing for my loyal readers (if any exist) is that I have a bunch of stored-up vitriol about Java that I can just uncork and pour out, so I should be updating more frequently.

So, what's it good for? (XO Laptop, part 3)

2008-09-28T09:03:00.000-07:00

(I wrote this quite a while back, but was never really happy with how it turned out. Here it is, nevertheless)

Cleaning out the backlog...

2008-08-28T10:32:00.000-07:00

Working it to death...

It occurs to me that writing a long blog post, then saving it as a draft, and sitting on it for months, occasionally tweaking the wording, then putting it back on the drafts pile to languish is exactly the kind of behavior I was trying to wean myself off of when I started this blog.

Bad Mark! No Biscuit!

So, I'm going to go back through the "drafts" folder and either publish or delete everything in it over the next week or so. So, y'all can look forward to lots of sentence fragments and unfinished thoughts over the next few days.

Team Building: cautionary tales

2008-08-28T10:18:00.000-07:00

I happened to read this article over at The Daily WTF, and it reminded me of some previous team-building events I've been subjected to over the years. Don't miss the comments, there are some pretty great stories in there, as well.

What I've learned over the last 20 years or so is that your team either gets along on a day to day basis, or they don't. If management keeps the more dysfunctional members of the group in line, and encourages working together, rather than finger pointing, you've probably already got as coherent a team as you're likely to get, and having them all go go-carting together isn't going to matter.

On the other hand, if the management plays favorites, or allows bullying to go unchecked, or actually engages in a bit of anti-social behavior themselves, no amount of pot-luck parties are going to change that.

Having said all that, here are some of my experiences:
Always remember rule #1: If the activity is competitive, do not divide your larger team up according to their everyday organizational structure - e.g. Marketing vs. Engineering, for example. Do it however you have to (alphebetical by last name?) to make sure that the distribution is essentially random. Inter-group rivalry is exactly what you're trying to eliminate, or should be, anyway.

Athletic Competition: One former employer had a yearly multi-event athletic competition (mostly "fun" events, like a sack race, or water-balloon toss). Any group of interested employees could form a team, and t-shirts were printed up for the event, and medals given out. As you might well imagine, given that this is an Engineering-heavy organization, injuries were fairly common. Over the years, they gradually rotated out the most physically-stressful events, but I think at least one person still gets injured every year - I had a nerve in my hand crushed during the Tug-of-War one year, for example.

The hyper-competitive types still worry way too much about doing well, sometimes dragging other folks into their sphere of influence (I mean really, what kind of person organizes drills for a Pictionary competition?). But overall, it works well, because everybody knows it's just for fun. Since teams are formed on an ad-hoc basis, it has very little of the "you are now part of a team, go be excellent together" aspect of other team-building exercises. Generally, managers don't force their "best" employees to form a team with them, for example.

Okay, so we can't all work at a company that's willing to throw huge amounts of money and time at something like that. Here's some other experiences I've had:

Laser Tag: I have done this a few times, with different teams. There is a bit of a tendency for the more blood-thirsty team members to enjoy themselves a little too much, but at least the chances of physical injury are minimal. The poor losers will whine that "my gun didn't work", or "I totally shot you first", but the rest of us are used to that (they do it at work every day), so it won't be a problem.

Most LT arenas can be set up to report only the aggregate team score, which helps the whole team feel like they're working together (which is the whole point, after all), and cuts down on whining. I highly recommend not getting individual stats for each player - those of us who suck at the game, or just aren't as into it, don't need a reminder of how poorly we did.

Movies: This can be fun, and usually goes over pretty well, but there's relatively little interaction between team members at a movie. Also, consider that some folks aren't going to want to go to any particular movie you might choose, so have a plan for them to have some fun at the company's expense, too.

One thing you can do to make this more of an interactive experience is to combine the movie with a pre-or-post get-together (catered lunch, maybe?) where people can get together and mingle casually - maybe even discuss the movie together. Many movie theater chains have an "events person" to help arrange this stuff.

If you really want to get the biggest bang for the buck, talk to your local theater about renting out an entire theater for your team (if you're large enough), and have the employees choose which movie they want to see, by voting. Or surprise everybody by renting out a theater for the big summer blockbuster movie on opening day.

Pot-luck lunches: You'd better combine this with something else, or you're in trouble. Some of us really like cooking for a group, but for a lot of employees, this just seems like the company trying to cheap out. At the very least, combine the pot-luck with a 1/2 day, or do it for Halloween and combine it with a costume contest, or something. See also: Picnic in the Park, below.

Miniature Golf: This was a surprising (to me, anyway) success. I figured that all the little cliques would go off and do their thing, but we actually had a pretty good mixing thing going on. We played for fun, rather than running some kind of a tournament structure, which probably helped. It's low-impact, so people can chat, and in general, few team memebers are invested enough to get over-competitive.

Bowling: You might want to try to figure out ahead of time if any of the team members are "serious" bowlers - they might not enjoy playing with a bunch of losers who bowl in the low '60s. But in general, this can work out great - bowling is a "do stuff, then wait" kind of activity, so there will be socialization between rounds. Beer helps with that aspect as well, of course.

Picnic in the Park / Beach day: You're probably located not very far from a nice park of some sort. Take all the employees out for the day, and feed them barbeque, or (if budgets are tight) have them pot-luck it, making sure that the basics are covered, using a sign-up sheet. Make sure frisbees and other fun toys are available, and make sure you have some shade. For extra points, make it an "employees and their families" event.

Amusement Park: Yeah, everybody will be really excited about this, but you likely won't see anybody after the initial arrival, unless you have a very large group, or a very small park. You can plan to have lunch together at one of the "group areas", and that'll get everyone in the same place for a while, but as a team-building experience, it's low on interaction.

So, that's my experience, what's yours? I'm particularly keen to hear from folks that have done more strenuous team-building activities, like the ropes course, or paintball...

Julia Child, International Super-spy

2008-08-13T14:56:00.000-07:00

They say "truth is stranger than fiction", and stories like this one prove that beyond any doubt:

By BRETT J. BLACKLEDGE and RANDY HERSCHAFT, Associated Press Writers
24 minutes ago

WASHINGTON - Famed chef Julia Child shared a secret with Supreme Court Justice Arthur Goldberg and Chicago White Sox catcher Moe Berg at a time when the Nazis threatened the world. They served in an international spy ring managed by the Office of Strategic Services, an early version of the CIA created in World War II by President Franklin Roosevelt.

Apparently the CIA is finishing up the transfer of old OSS documents to the National Archives, and the list of OSS employees was one of the most recent things to get approved for declassification.

The article on Yahoo! News has a link to this page, a CIA page describing the history and activities of the OSS during World War II.

Pictems, three weeks in

2008-08-03T15:31:00.000-07:00

"So, where's my update?"

That seems to be the most common question from our Pictems customers lately. I've been running a bit behind my (unannounced) schedule, but I'm still hopeful that I'll have the first update finished and posted sometime this week. Mark K. has done some awesome updated item artwork (see above), and I think I have a handle on the user-interaction problems we had with 1.0, such that the new version will be easier to use.

"How many downloads have you gotten?"

The most common question from my friends and family seems to be "how many downloads have you gotten?", or alternatively, "are you ready to quit your day job, yet?". We don't actually know how many downloads we've gotten overall, since we haven't gotten our first monthly financial statement from Apple, yet.

I did try some hand-waving estimates, based on traffic on the starchytuber.com site. Based on those figures, I figured we had somewhere between 30 and 300 users.

and boy, was I ever wrong...

Apple has just recently given us the last 6 days worth of daily download statistics, and I'm . . . stunned at the number of downloads we're getting. In the last 6 days, we've averaged more than 50 downloads a day. That means we've had as many downloads this week as I was expecting to see from the whole three week period.

Also, despite the fact that Pictems isn't localized for any other language than English, we have downloads from more than 18 different countries. That's pretty astonishing to me, and probably indicates that we'd do a lot better with an application that was localized in multiple languages. I'll have to look into translation costs for application #2.

Where my estimates went wrong

Here's where I think I misled myself and came up with a far too low estimate of our customer base.

"Unique" computers aren't

The "unique hosts" count that our web hosting provider gives us doesn't exactly correspond to the actual number of people that visit the site - someone who looks at the site from home & from work will be counted twice, multiple people hitting our site from behind a web proxy or NAT router would only count as one person, etc. I figured that these would balance out, but I think that the latter factor turns out to have a much greater influence.

Most people will never look at the web site

I figured that some of the people hitting the site would be friends and relatives, and some percentage would be actual customers. I also assumed that some small percentage of people would see the application on iTunes, check out the website, then decide the software wasn't for them.

So I estimated that somewhere between 10-100% of the "website visitors" represented sales. Building on top of the (probably worthless) "unique hosts" number, I compounded the error by assuming every paying customer would look at the site at least once.

As it turns out, I personally have bought something like 10 applications for my iPhone (other photo-related apps for competitive analysis, and a few games), and I've visited the websites for only two of them, once each.

No one signs up for the mailing list

I also had an email address set up so people could ask to be put on a list to be notified of updates when they were available. We've had 6 people (I think) sign up for the mailing list so far. This means that the sign-up percentage is probably substantially below 1%, which was what I figured would be the minimum number that would sign up.

Given that the iTunes App Store will automatically notify customers when an update is available, there's really no reason for them to sign up. I didn't really consider that, but I may just quietly kill off the "updates" mailing list if it never gets above 12 users or so.

So what's your best guess now?

Well, I really don't want to go out on a limb here, but it seems likely that the last 6 days probably don't represent our "best" days, in terms of downloads. They probably aren't the "worst" days, either. If we assume that they were about average, then we've had about 1,100 downloads over the last 22 days. That's not bad at all, by my standards. It's possible that the actual number of downloads is much higher - the first couple of weeks of the App Store being open was probably a bit of a feeding frenzy...

So my current guess is that we'll probaby have sold somewhere between 1,200 and 5,000 copies of Pictems in the first month. If you think you have a better guess, e-mail it to me, along with your t-shirt size, at salescontest@starchytuber.com, and if you have the closest guess, I'll send you a one-of-a-kind Starchy Tuber t-shirt to celebrate your estimation prowess.

So, are you going to quit your day job?

When i was asked "are you going to quit your day job?" for the first time, I decided to sit down and work it out. I figured that if we sold 100 copies in the first month, we'd have lost money on the whole thing, if we had 1,000 downloads we'd actually be making money, and if we had 10,000 downloads in the first month, then I'd seriously have to consider whether it made sense to stay in my "day job", or actually try to make a living as an independent software developer.

I guess we'll know in a week or two if the number of downloads is close to that 10,000 download mark in the sand. Of course, it'd be sheer madness to assume that downloads will continue at the same rate forever, so it'll be several months at least before I'm ready to make that "stay or go" decision.

Hopefully by then I'll have several applications on the store, at different stages in their lifecycles, and at different price points. That should give me a more realistic idea of what the earning potential is. I'll keep you posted.

Pictems!

2008-07-11T02:27:00.000-07:00

Pictems is now available!
Hey, so my first iPhone application is currently available on the iPhone App Store. It's been a tremendous amount of work to get to this point, but now it's out, and I can step back a little and take a deep breath and think about what was good, what was bad, and what I would do differently next time.

We even have a website set up!

So, what is it?
The name "Pictems" is a conflation of "Pictures" and "items". Pictems is a simple application that lets you take the pictures from the photo library on your iPhone or iPod touch, add a variety of fun embellishments to them, and save them to send them to your friends and family.

What's it like writing iPhone applications?

It's pretty great. Having previously written applications using the Cocoa framework on Mac OS X, I was in pretty familiar territory. There are a few little quirks in the iPhone framework, and a number of features are a little clunky, but the tools are eminently useable, and the documentation is already much better than I expected.

For anybody who has experience developing for other mobile platforms, I can tell you that this is a lot more like developing a desktop application than like developing for a traditional embedded system.

What do I like most about the application?

I think we started with a really fun idea, and (mostly) resisted the temptation to throw in lots of features at the last minute. The current version is really stable, and (I think) is easy to use. More importantly, it's fun!

We'll be doing a feature update soon to polish the user interaction model a bit, but at this point, Yvette (my lovely wife and Alpha tester) and I have made literally hundreds of these images, and we're still having fun with it.

What will I do differently next time?

I wish I'd thought through the application "flow" a bit better. Our current design has a bit of a "dead end" in one of the user interactions - you can get in easily, but it's not obvious how to get back to where you were. That's partly a result of a feature that we pulled at the last minute, but I wish I'd paid a bit more attention to the iPhone Human Interface Guidelines.

The next version will be more polished, but I think we got the underlying model right, so it'll be easy to expand the feature set without having to redesign everything from scratch.

I already have plans for a couple more iPhone applications, so I need to start looking into which of those I'm going to add to the Starchy Tuber family of programs first.

The Problem with Magic...

2008-06-16T23:23:00.000-07:00

The problem with software that works as if "by magic" is that when it's broken, you're practically helpless. I just ran into my first instance of that with the iPhone SDK. I can't go into specifics here because of the NDA, but I just spent a really annoying couple of hours trying to resolve a problem where a better-worded error message would have immediately revealed the actual issue.

Hint to API implementers. Saying: "I loaded your file, but **** isn't set correctly" is not at all the same thing as "I tried to load your file, but I couldn't find it, and therefore **** couldn't be set up". Finding a typo in a textfield in Interface Builder by starting from scratch and re-building the whole interface kind of eats into the productivity advantage of using IB in the first place.

Oh, well. At least I didn't have to burn one of my tech support incidents to have someone point out a typo for me. That would have been really infuriating.

What a week...

2008-06-13T13:18:00.000-07:00

Five days, 21 sessions (not including the keynote), and 12 rides on Caltrain up to San Francisco and back. My head is spinning, but my first two iPhone applications are installing and running.

I think I'm ready to go back to work and take it easy for a while. Unfortunately, I think my boss has other ideas...

WWDC 2008

2008-06-06T10:50:00.000-07:00

I'm really excited to be going to WWDC this year, for the first time as an attendee. WWDC is Apple's Worldwide Developer Conference, which is 5 solid days of technical education and on all things related to Mac and iPhone development.

The only other times I've gone to WWDC, it was as an Apple employee, and I spent my time there helping customers with their issues. Not that that wasn't fun - it was probably the most enjoyable part of my time at Apple. But I am looking forward to sponging up mass quantities of information, and asking my former co-workers stupid questions :-)

I know a lot of the Mac enthusiast and rumor-tracking sites are wildly speculating on what new Apple products might or might not be announced at WWDC. I'm only vaguely interested in any possible hardware announcements. I think the most important announcement form Apple in the last 10 years was the introduction of the iPhone - not because the hardware was so special, but because they built it on OS X, and released an SDK relatively soon thereafter.

Hardware is interesting, but it tends to follow a fairly predictable pattern. This year's Macs will be some combination of faster, lighter, and thinner, and there will inevitably be iPhones with more storage, faster network connectivity, and more features.

More interesting to me is that Apple has really started to embrace having a single platform that supports multiple kinds of products. I wrote a whole blog post on that subject a while back, but the fact that Apple can now get a microprocessor for $10 or so that'll run OS X means that they can aggressively move into whatever new kinds of products they want, based on variations of the new iPhone platform. It's an exciting time to be a developer for Apple's platform.

For those of you who'll also be there, keep an eye out for me - I'll be haunting the iPhone sessions, and working furiously to finish up a couple of projects I've been working on, now that I can actually test and debug them on iPhone hardware (my developer certificate arrived just in time for WWDC).

Why you should visit the Computer History Museum sooner, rather than later

2008-05-28T14:06:00.000-07:00

If you live in Silicon Valley, you've probably at least heard of the Computer History Museum. If you're like me, you probably even planned on going "one of these days". There's a very good reason to schedule that visit sometime in the next 10 months or so, though.

A full-scale working model of Charles Babbage's Difference Engine Number Two is currently on display at the CHM until May of 2009. There is only one other like it in the world, at the Science Museum in London, UK.

It's one of the most beautiful pieces of machinery I've ever seen, as well as marking a significant milestone in the evolution of computers. We went down for the exhibit's opening, and actually got to see the machine in operation. I gather that they're not running it all the time on regular days - that's a pity, but seeing as it cost millions of dollars to make, and they're merely borrowing it, I guess I understand that.

It's almost hypnotic to watch, with the carry mechanism rippling up the columns of digits, and hundreds of pounds of brass and steel moving up and down for each step of the calculation.

In addition (ha, ha!) to the Difference Engine, the museum has a large number of other historic computer systems on display, including a Connection Machine, several Cray super computers, and pieces of the SAGE system. Walking through their "Visible Storage" area, a loosely-organized subset of the museum's collection, was fascinating. There's everything from abacuses to supercomputers in there, along with various bits of esoterica that the younger generation wouldn't have seen or even heard of before - drum memory, magnetic cores, etc, etc.

All in all, well worth a visit. The museum is definitely a work in progress, but admission is free, and there's nothing quite like it anywhere else. They also have a regular lunch lecture series, starting up again soon, with discussions of various people and machines in computing history. Since I work right down the street from the museum, I'm planning to try to attend events at the museum more often.

The intermediate approach...

2008-05-06T09:18:00.000-07:00

I've written before about how the shared memory multi-threaded model for concurrent processing is an evolutionary dead-end, and how we'll "inevitably" need to move to some other model. I'm a big fan of message-passing systems, but there are other models that also take advantage of multiple processors without the fiendish complexity of mutex-protected, shared memory threads.

Well, you might have heard that Microsoft (with some assistance from the academic community and hardware vendors) is working on their own solution to the "multicore dilemma". Unsurprisingly, they're not recommending that everybody throw away their imperative C++ and C# code, and adopt an entirely new programming paradigm, like functional programming. Instead, they're implementing a series of tools that make it much easier to get a lot of the benefit of multiple processors, without having to learn a new way of thinking.

Late last year, the first fruits of this work became available. The "Parallel Extensions to .NET" (or Parallel FX) are available from Microsoft as a free download, as a Community Technology Preview (basically, an open Beta). You can read much more about it at Microsoft's website here. There's a great MSDN Magazine article that hits the high points, as well.

One key point in their design is the realization that anonymous functions (they call them anonymous delegates, but that's just jargon) provide a simple way to package up a "unit of work" to pass off to another processor. This is nothing new to the functional programmers out there, I know. But for folks who are firmly rooted in the C/C++ tradition, learning that they can replace:


for (int i = 0; i < 100; i++) { 
  a[i] = a[i]*a[i]; 
}

with


Parallel.For(0, 100, delegate(int i) { 
  a[i] = a[i]*a[i]; 
});

and get a massive speedup on multi-core machines, is likely to be something of a revelation. Parallel FX does some fun stuff under the hood with all those delegate invocations, as well, enabling better work sharing - see the MSDN article for details. I thought this was an interesting hybrid approach, rather than the "all or nothing" approach to addressing concurrency.

For those that are already familiar with OpenMP, it's a somewhat similar model, in many ways. The additional abstraction provided by having an anonymous function does simplify the simple cases, though - the arguments to the function are "private", and everything else is "shared", basically.

One of these weekends, I'll have to take a deeper look into Parallel FX. I did find it fascinating that a single language feature (anonymous delegates) can be leveraged to do so much, though.

Tolkien is probably rolling in his grave

2008-04-09T11:00:00.000-07:00

This is just sick and wrong:
The Friends List Of The Ring

edit 2008/05/06: The original link is gone. Here's a YouTube link.

Most surpising headline of the year

2008-03-19T16:27:00.000-07:00

"Silicon compound superconducts at room temperature"

Unfortunately this turns out to be bad reporting...

Is it my imagination?

2008-03-18T11:27:00.001-07:00

Am I mis-remembering, or did Internet Explorer formerly produce more helpful error messages than this one when failing to connect to a website? Is this another IE7 "feature"? Why would you display the exact same error message for no network connectivity, a DNS failure, and a site that doesn't respond?

Given that it's trivially easy to distinguish each of these three from the other cases, why not at least tell me which is actually the problem?

Grr.

L. U. A. That spells Moon!

2008-03-12T09:25:00.000-07:00

As I mentioned previously, I've been working with Lua recently. I'm really enjoying it. I'd place Lua somewhere slightly to the right of Tcl on my Programming Language Complexity Chart, which probably explains why I found it so immediately appealing.

There are many kinds of simplicity. I think that one of Lua's strong points is that it tries to get the most possible mileage out of each language feature. For example: Lua is dynamically typed, meaning that values have a type, but any variable can hold a value of any type. Lua defines the following value types:

number
string
boolean
nil
function
table
thread
userdata

For purposes of this discussion, we're going to ignore the userdata type, since that's mostly used when dealing with opaque data from the "host" program (Lua being designed to be used as an embeddable interpreter).

Now, this is obviously more types than some other scripting languages, but it's still a fairly short list. Most of the types are fairly self-explanatory - number represents a numeric value, strings are used for text, booleans are used for true and false, nil is the value of an uninitialized variable, and function represents a function.

Tables are an interesting case. Tables are Lua's implementation of the Associative Array, everybody's (or at least my) favorite universal data structure. Once you've got a data structure that can index arbitrary values with arbitrary keys, you can use it for all sorts of things - and Lua does. As the book Programming in Lua puts it:

Tables in Lua are not a data structure; they are the data structure.

Tables are used to implement records, arrays, Object-Oriented Programming features, namespaces (the package system), and a variety of other features. Even global variables are implemented as entries in a table.

One extremely powerful feature of Lua is metatables, which are tables that affect the behavior of other tables. Every table can have a metatable attached to it, which controls the behavior of the table when certain operations are perfomed on it. This is conceptually similar to operator overloading in C++, but again just implemented as a series of entries in a table.

People have implemented both class-based and prototype-based OOP systems for Lua using just a few relatively simple functions that manipulate tables and metatables. That's a pretty good example of the power that's available.

Leaning towards the left...

2008-03-10T22:20:00.000-07:00

This diagram is an adaptation of something I wrote on a co-worker's cube wall. I based this on my own experiences, so it probably reflects my prejudices, especially with regard to the placement of the "Human Limit" marker. It'd be interesting to come up with some kind of objective measure for the complexity of a programming language. Maybe multiply the number of reserved words by the number of operators, or something.

I think that excessive simplicity is one issue that limits adoption of the languages to the left of the diagram. Though I've never heard someone come out and say it, I think a lot of programmers are actually put off by syntax that's too simple. People complain about "all those parantheses" in Lisp, but what really bugs them is that the parentheses are really all there is to Lisp, the language.

I tend to prefer languages with simple syntax. I find that a simple set of rules to remember helps me to focus on what I'm trying to accomplish, rather than how to harness the myriad of tools available to me to actually do the work. I also find that simple languages are paradoxically more flexible. In a language like Lisp or Tcl, it's easy (and more or less encouraged) to extend the language with your own constructs, which are "first class citizens" as far as the language is concerned.

Having said all that, even I have my limits. While Smalltalk is a wonderful system for puttering around with, I don't love it. I think the lack of a more-sophisticated syntax for algebraic expression really hampers the usability of the language.

I'll add some additional commentary tomorrow, especially with regards to where Lua (the most recent language I've learnt) fits on the diagram, and what that implies about Lua...

A fun little puzzle

2008-02-27T12:11:00.000-08:00

I ran into this interesting puzzle over at techInterview.org, which is a site dedicated to the kind of mental puzzles interviewers at certain companies love to ask job candidates. The puzzle is:

A 5*5 array is initialized to all 1s. Each cell can be either 0 or 1. When you flip a cell (m,n) (say from 1 to 0) all its four neighbors(left, right, up and down) flip. You need to change the array into all ZEROs by flipping the cells. How many minimum flips are required?

If I was really clever, I'd insert a Javascript widget here that let you play the game (assuming that Blogger even allows that), but I think the description is probably clear enough.

What was fun about the puzzle to me is that there are a huge number of states that the puzzle can be in, but it's obvious that there just has to be a better way to find a solution than just thrashing around blindly.

I was out sick from work yesterday, and in between naps, I tried working on the puzzle. Unfortunately, I just wasn't able to get much traction on the problem by trying to figure it out logically. Once I got frustrated enough, I resorted to a brute-force search of the solution space, which found 4 solutions, all of which were reflections and rotations of the same moves.

Leaving aside whether it's really very fair to ask for a "minimal" solution to a puzzle that only has one solution, it wasn't until I was copying the solution out of the terminal window that I saw the symmetry trick that makes it work.

Normally, when I'm trying to solve something like this, which just "has" to have a simple solution, I start by solviung a much simpler version, then try to scale up to the original problem as stated. For some reason, that process simply didn't occur to me yesterday. Had I tried starting with a 2x2 matrix and working my way up, I probably would have seen a pattern in the solutions pretty easily, and solved the puzzle by hand in a few minutes.

What did occur to me was that the total number of states, while large, was still well within the range where an exhaustive search would be reasonable. Once I had the program written to search for solutions, I ran it, and it finished suspiciously quickly. It turned out I had a bug, along the lines of using 2^25 instead of 2^26-1 in a critical place. I fixed that, re-ran it, and it still took less than 10 seconds. What the heck?

I tend to forget that the computers we have these days are so darn fast. Despite the fact that I'd done nothing to optimize that algorithm I was using, the PC was cranking along at 1 or 2 billion instructions a second, evaluating the 33,554,431 possible solutions at a speed of a few million iterations a second.

It's easy to think "this computer is so slow", when you're waiting multiple seconds for it to wake from sleep, or for some crazy Java applet to load, but when I see the results of the machine just cranking on some simple calculation, I'm just amazed at the power there.

If you want to see my thought process while I was working on this puzzle, you can read the techInterview discussion here, though my solution is there, so don't read it if you don't want to be spoiled. I'll probably post my code here later, so you can see what kind of C code I write when nobody's watching, and while I'm sick to my stomach :-)

Monkey madness!

2008-02-22T14:12:00.000-08:00

It seems like in every job I take, I eventually end up developing an API, or a programming language, or a macro processor, or something similar. I don't know if this is characteristic of the sorts of jobs I take, or if it's just a reflection of the sort of approach I tend to take to solving problems. I suspect both factors are at play.

My latest foray into tool development started innocently enough. At Zing, we develop software and hardware for portable entertainment devices. Examples would be MP3 players, satellite radios, and portable internet radio streaming devices.

Anyway, one of the guys on the development team suggested that we ought to implement a bit of software to simulate the actions of a user - pressing buttons, spinning the scroll wheel, changing the volume, that sort of thing. Apparently Palm used a similar system (called a Gremlin) to flush out some of the more obscure timing-related bugs in their software.

Our version was called the UI Monkey (after the Infinite Monkey Theorem). The initial implementation was fairly straightforward, generating random user-input events and feeding them into the event queue on the device.

Then someone wanted a way to record and play back events, so we could do some testing automation. That was straightforward enough, though anyone who's implemented UI automation on such a low level can tell you than the resulting scripts are very fragile, in that any tiny change to the UI will break the script.

Once I had the basic framework in place, more requests came in, everything from "can we have the monkey scripts check for success?", to "how about implementing a way to repeat a bunch of actions over and over?". Since the whole Monkey code structure was based on sending and receiving UI events, other features had to be hacked in as "special" events, which each had their own syntax. After I had finished "goto", and had started working on some other features, I decided it was time to take a step back from the ledge and re-evaluate my options.

Despite the great amount of interest expressed in UI automation, nobody else was using the system I'd created. Given the sheer impenetrability of the syntax, I can't really blame them, but it was a little disappointing. I decided it was time to come up with something a little less insane, and a bit more appropachable.

The one thing I was pretty sure of was that I didn't want to implement my own scripting language from scratch. While designing your own language is an interesting project, and gives you a lot of power, it always takes a lot longer than you'd expect, and you're never really done. Implementing a "Monkey library" on top of a more-standard language seemed like a better bet.

I considered using C# as our UI scripting language. Unfortunately, C# requires a fair amount of boilerplate code just to make a basic loadable assembly, and a lot of the folkks that want to do scripting aren';t familiar with the development tools. So, some kind of scripting language seemed to be in order. As it turns out, we already have a scripting language interpreter embedded into our product (which is another story, and a great example of the Law Of Unintended Consequences at work).

So, I threw out all of the crazy hacky code I had been writing, and re-built the Monkey on top of Lua, a light-weight scripting language. Instead of an event recording and playback system, we now have a set of event-related primatives, and a real programming language to call them from, with functions, for loops, if-then-else, and variables. The integration of the Lua and C++/C# code was pretty easy, as well.

XO Laptop, part 2

2008-01-09T09:36:00.000-08:00

Now that I've had a chance to play with it a bit more, a few more impressions. I've been thinking about the "but what's it good for?" question, as well, and I'll have more to say on that later.

Everything is terribly slow

Part of this is because a lot of the UI and the Activities (applications) are written in Python. I understand that the goal of tinker-ability is trumping the desire for a snappy UI, but I fear that children (who aren't after all, known for their great patience) will get bored when they try to do something, and all they get is a blinking icon on the screen for a minute or more.

A co-worker says that he pulled his out of the box, turned it on, tried to use it for a while, decided it was unusable, and put it back in the box. I don't think it's that bad, but performance is definitely an issue.

One of the first things I tried was launching each of the activities, to see what each one was. That lead to the discovery that you really don't want to launch multiple activities at the same time. It was probably 5-10 minutes before the laptop was responsive again. They ought to consider throttling this in the shell, because I'd bet your average 8 year old is going to do just that when they use it for the first time.

Given that Psyco exists, I don't know why it's not installed on the XO to begin with. I couldn't find any indication on the OLPC Wiki that anybody had actually tried it. I'll try building a version and enabling it for a few applications to see what impact that has.

Great wireless sensitivity/range

I haven't had a chance to use the mesh networking features yet (due to lack of another XO, or a School Server to hook up to. But the standard 802.11b networking gets a substantially stronger signal than my conventional Dell laptop does.

Lots of features are still "to be implemented"

Totally understandable, I think. The hardware seems to be pretty well worked out, the software is just lagging behind (and who hasn't seen that on a project?). For example: there are about half a dozen keys on the keyboard for various special features. about half of them do nothing at all. There's a "view source" key combination, which doesn't do anything, presumably because the "Develop" activity isn't finished yet. So much for "easy to tinker", though...

Relatively clean User Interface

I admit it - I'm a fan of minimalist UI "chrome". I liked Nextstep, I liked the old Mac OS, I even liked CDE. The modern UI trend toward glossy reflective surfaces and transparency effects feels like a major step backwards in usability to me.

The OLPC "Sugar" interface is largely monochrome, and very simple. Presumably at least part of this is due to the limitations of the system (especially the requirement to be usable in black-and-white mode), but overall, it's pretty pleasing.

The camera and microphone work well

I can't wait to see what the kids will do with this. It's only camera-phone quality, but I think that'll be a popular feature.

Many of the activities are a little impenetrable

Unfortunately, many of the included activities are a bit hard to get started in. The music stuff is particularly bad. I understand that a full user-manual for these applications is a bit much to expect, but trying to "drive" a multi-track sequencing application without any documentation or online help, and with only icons in the user interface, can get a little frustrating.

Too many programming environments

The standard install comes with Etoys, Pippy, and TurtleArt - development environments for Squeak Smalltalk, Python, and some kind of "graphical" language, respectively. Rather than three different programming environments, I would have liked to see more "out of the box" usable software.

XO laptop mini-review

2008-01-04T21:20:00.001-08:00

My first hours with the XO laptop

Back when the One Laptop Per Child Foundation was running their "give one, get one" promotion, I signed up to donate a laptop, and get one for myself. I figured I could do some good, and get a chance to see what it's all about.

Initial impressions:

Hardware:
It's small - really small. Seems more deserving of the "notebook" designation, rather than calling it a "laptop". It'd probably fit well on a child's lap, though.

The exterior case feels very solidly constructed, and has a built-in handle. It reminds of my original iBook. It does look a little like a toy, but that impression goes away pretty rapidly once you start using it.

The keyboard is a rubber dome "chiclet" keyboard of the sort you might have found on inexpensive home computers in the 1980's in the USA. It's not too hard to type on, with the exception of the "space bar", which seems to be made up of 10 or so individual switches, and my thumb keeps hitting it between the individual switches.
The screen is very clear and readable. I haven't used it in black & white mode very much yet, but it's readable in a (fairly bright) room with the backlight off. Not bad at all.

Software:
The user interface is a little weird, if you're used to a standard PC operating system interface. I think someone who's coming to it with no preconceptions would find it fairly easy to get started.

It's running Ubuntu Linux, but you'd never know it from looking at the UI. Everything uses just one mouse button - none of the right-click, middle-click crap from KDE.

The "window manager" doesn't so much manage windows as screens - most of the applications run in full-screen mode, to make better use of the low resolution screen.

The web browser is plain but functional. I'm using it to type this entry, as a matter of fact. So far the only problem is that the cursor disappears in some text boxes. That makes it a little harder to edit text than it should be. Might be a Blogger Javascript problem, I'll see if it come up elsewhere.

I'll report back with an update after I've tried out the other included applications.

Programmer's purity test

2007-12-06T18:28:00.000-08:00

There's an enormous list of programming languages up on the Wikipedia at Alphabetical List Of Programming Languages

It occurred to me that that'd make for an interesting variation on the classic "purity test". A number of "hacker" and "geek" purity tests are out there, but I haven't seen one specifically for programming. There are way too many extremely obscure languages on that Wikipedia list, though.

If we trimmed out the truly obscure languages, we'd get something like this:

Have you ever:

Programmed a computer?
In ADA?
In ALGOL?
In APL?
In APPLESCRIPT?
In Assembly?
In AWK?
In B, or BCPL?
In BASIC?
In brainf*ck?
In Bourne Shell?

Nah - too boring, and we haven't even gotten out of the B's yet. Maybe we could organize it by generation:

Have you ever:

Programmed a computer?
With jumper wires?
In machine code?
...without a coding sheet or other aid?
...with toggle switches?
...from a Hex keypad?
In assembly language?
On punched cards?
In a language whose syntax assumes that you're still using punched cards (eg Fortran, RPG)?
In COBOL?
In C or Pascal?
In Forth?
In Lisp (Scheme, Logo)?
In Smalltalk?
In a 4GL?
In C++?
In Java or C#?
With a scripting language?
In a modern functional language (Haskell, etc)?
In an object-oriented language without class-based inheritance?

That's a pretty good start, maybe we could add a few questions on how you used these various tools.

Have you ever...

Written a program that directly controlled objects in the physical world?
...did you ever injure anyone with a bug?
...other than yourself?
Written software for internal business use?
Written software that was sold at retail?
Written software that sends email?
...did it ever send thousands of messages due to a bug?
...outside the organization you were working at?
Programmed in a language of your own design?
...did anyone else ever use your language?
...did it become a de-facto standard?
...or an ISO or ECMA standard?
Written a compiler?
...not as an assignment for a class?
..."by hand" (without using lex/yacc or related tools)?
Created self-modifying code?
Written code that modifies some other program's binary?
Written self-reproducing code?
...without it getting away from you?
Changed the class of an object at runtime?
...in a language without dynamic dispatch?
Created a program that took longer to run (once) than it did to write?
...while running on a cluster of computers?
...or a conventional supercomputer?

I seem to have run out of ideas. Suggestions for additional questions would be greatly appreciated. A traditional Purity Test would have 100 questions, so you could easily generate a percentage score.

For what it's worth, I scored 32/44, or about 27% pure. I think that probably indicates that the test is a little too focused on my own experiences. Send me your questions, and I'll work up a better list...

Fear of teaching

2007-11-24T10:32:00.000-08:00

I gave a little presentation or lecture at work last week (on pair-wise testing and higher-level test planning) and I was reminded of one of the great tragedies of my life. I really love to help people learn new things, but actually standing up in front of a crowd and talking makes me physically ill. It's been like this for as long as I can remember, and I've learned to work around it in the work context, but if I had to do this every day I'd be pretty miserable.

Since I knew other people would want to read about it later, especially given that I gave the presentation on the Wednesday before Thanksgiving, I put my notes up on our Wiki. I have a bit of a love-hate relationship with the Wiki. While I love the idea of a single place to look for information, the usability of Wiki markup languages really stinks. It's a bit like Blogger's "plain text" format, in that if you don't care about what things come out looking like, it's alright, but I always spend more effort trying to work around the limitations of the format than I do actually writing the content.

I've learned over the years that there are about three major methods of preparing for giving a presentation. Some people actually go to the effort of writing out everything that they want to say, similar to a speech as given by politician. Some people write nothing down, and ad-lib the whole thing, and then there's the approach I've always used. I usually write an outline that contains all the topics I want to cover, and then I ad-lib the presentation around the outline, making whatever mid-course corrections might seem necessary based on the audience's reactions.

Because I wanted people to be able to get something out of my notes without having to be at the presentation, I filled in the outline with some additional explanatory text. That's very similar to the process I usually use when I write other things (for example, blog posts). I start with an outline, then I replace items in the outline with paragraphs and sentences. Even when I do something more free-form like this post, I have the outline in my head, at least. Revising an outline on the iPhone would have pretty painful...

When I finished the presentation, I got some very positive feedback from the audience, including at least one actual pat on the back, something I had thought of as a metaphor before. Afterwards, I thought a little bit about what I thought was good about that presentation, especially compared to other presentations I've seen lately, and I think it's all about not over-planning or under-planning it. The worst presentations I've been subjected to are of the "guy reading directly from his Powerpoint slides" style. Second worst are the "guy who is totally not prepared or sure what he wants to say" variety. Once again, the happy medium wins out.

The C++ FQA (frequently questioned answers)

2007-10-28T14:02:00.000-07:00

No updates for 6 months, then two in a day...
Via a discussion on Joel On Software, I got directed to this:
The C++ FQA

It's a response, of sorts, to the C++ FAQ. You can read moreabout it on the site, but he basically goes through the questions in the C++ FAQ, and explores what it is about C++ that makes those questions "frequently asked". There is some sarcasm, and some rather insightful commentary on why C++ is so very hard to develop real expertise in.

It would be neat to see something like this done for Java and C#. I think the idea of looking at a language from the standpoint of "why are these areas confusing to so many users?" is an interesting approach.

I have always felt that my resistance to really learning C++ was a failure on my part, but after reading "Effective C++", and with the backing of the C++ FQA, I feel a little better about taking the position that C++ is really far too complex for the good of the people who need to work with it.

You're probably using "unsigned" incorrectly

2007-10-24T23:30:00.000-07:00

You're probably using "unsigned" incorrectly, and that makes me sad.

Chances are that if you write code in C (or related languages like Java, C#, or C++), then you've come across the "unsigned" type, and its relatives "unsigned long" and "unsigned short". If you've written code that uses unsigned types, it's also quite likely that you've used them incorrectly, at least by my standards.

Misuse of "unsigned" in C is one of those things that I keep seeing over and over, with different developers, even folks who really ought to know better. I find it immensely frustrating. If I had to pick one aspect of C that was responsible for more stupid bugs than anything else, this'd be one of the top candidates. Probably not the top candidate - the string-handling functions in the standard library probably win that handily.

Here are my simple rules for the use of unsigned integer types:

Don't use unsigned just because "that value should never be less than zero"
Always compile your code with all warnings enabled
Avoid mixing the use of signed and unsigned integers in the same calculation
Do use unsigned when modelling hardware registers that hold unsigned values
Do used unsigned when performing bit-wise arithmetic

Okay, back to the subject at hand, and let's take a look at those rules, shall we?

Don't use unsigned just because "that value should never be less than zero"

This is by far the most common abuse of unsigned types that I see on a regular basis. It's not even a bad idea, as far as it goes. A majority of the values in a typical program are going to be non-negative by design - sizes, screen coordinates, loop counters, etc, etc. The problem really isn't unsigned values per se, it's how unsigned and signed values interact.

Part of the problem is that constant values in C are signed by default, which means that signed values will creep into your program unless you make a concerted attempt to avoid them. When you compare signed and unsigned values, the results will often not be what you expect. For example:

unsigned four = 4; 
int neg_one = -1; 
if (neg_one < four) 
{ 
  printf("true\n"); 
} 
else 
{ 
  printf("false\n"); 
}

Looking at this code, it's pretty obvious what the programmer intended, but in fact the comparison "neg_one < four" evaluates to false in this case. This is because the signed value will be "promoted" to unsigned, turning it from a small negative number to a very large positive number, before the comparison is made.

In actual cases of this problem in the wild, the declarations will typically be a long way away from the comparison, and it won't be at all obvious what the cause of the problem actually is. I've seen experienced programmers stare at the debugger in disbelief when it seems to be showing them that their program thinks that -1 is greater than 4. An additional complication is that constants in C are signed by default, so you can replace the "neg_one" variable in the example with the constant "-1", and you'll get the same behavior.

A related problem comes with the handling of sizes and lengths. A size is typically going to bea non-zero value, so it "makes sense" to use unsigned variables. The problem is that sizes are often calculated by subtracting one value from another. If you accidentally subtract a larger value from a smaller one with signed variables, you get a negative size, which you can at least detect and handle (with an assert(), if nothing else). If you're using unsigned math, you just get a huge bogus "size", which may or may not be immediately obvious.

Always compile your code with all warnings enabled

Admittedly, this rule is more general, rather than specifically tied to problems with using "unsigned" correctly. Most C and C++ compilers have an option to warn on comparisons between signed and unsigned values, when there's a chance the comparison will be interpreted incorrectly. It's even more frustrating to debug one of these issues when compiling with warnings enabled would have produced a warning message that points to exactly where the problem is, but some yutz has that particular warning disabled.

Of course, they have it disabled because enabling warnings on comparisons between signed and unsigned tends to generate zillions of bogus warnings. That's just a good reason to avoid using unsigned variable, where possible - it obscures the actual problem areas with bogus warnings.

Avoid mixing the use of signed and unsigned integers in the same calculation

Given the example above of a simple comparison going wrong, it ought to be obvious that anything more complex is at least as likely to go subtly wrong in some way. Again, the real problem arises because the declarations of the variables (and constants) will be far far away from the point of the errant calculation.

So, when is it okay to used unsigned types?

Do use unsigned when modelling hardware registers that hold unsigned values

This is most likely how unsigned types got into C in the first place. If you're writing low-level OS or driver code that talks to the hardware, you'll often find that the unsigned int type exactly matches what the hardware is using. This also segues nicely into the next rule...

Do used unsigned when performing bit-wise arithmetic

If you're doing something with fancy binary arithmetic, like an encryption algorithm, or something else where you're using an integer as a sollection of bits, unsigned types are probably what you want. I'd put something in here about using "unsigned" with bitfields, but the bitfield construct in C is pretty useless (and a topic for another rant), so I'll just mention that it's worth thinking about whether you want an unsigned or signed bitfield, if you ever use them.

Unfortunately, you actually can't avoid "unsigned" values

As it turns out, there are types that the standard library uses that are usually unsigned, for example size_t. So, your inteactions with the standard library will occsionally force unsigned values to creep into your program. Still, that's no reason for you to make it any harder on yourself.

New Blender!

2007-05-28T21:22:00.000-07:00

Last week, we got a new blender - a Blendtec Total Blender. Since Yvette started her weight loss program, we've gone through 4 blenders or so. Making multiple shakes every morning wears out your typical bargain basement blender in 6 months or less. We're hoping that the new blender lasts us a whole lot longer. It had better last a long time, it was nearly 10 times as expensive as the last blender we bought.

The Total Blender is based on Blendtec's commercial blenders (my local Starbucks uses Blendtec blenders). It's got a 1500 watt motor, as compared to the 300-600 watt motors in a typical home blender. It's got a very solid square blender jar, and a scary-looking set of ultra-sharp blades. Instead of a set of speed buttons that are labeled with wacky labels like "frappe" and "fold", it's got buttons naming what food you're making - "milkshake", "soup", "smoothie". Each button initiates an automatic program which speeds up or slows down as necessary to perfectly mix whatever you're making. It even stops automatically at the end of the program. Nifty!

So how well does it work? It's incredibly powerful - it crushes ice without even slowing down. It's also very loud at full speed. The instructions that came with the blender were minimal, but it did come with a pretty big cookbook. Apparently, the motor is strong enough to actually grind flour, make peanut butter from whole nuts, etc. On the "soup" setting, the friction of the blending actually makes the soup hot! For simple stuff, like the aforementioned diet shakes, it does the job about twice as fast as our old blender. The jar is super easy to clean, and doesn't seem like it'll get food stuck under the blades like our old blender tended to.

There is one downside that I've identified so far. Have you ever had a blender accident, where an overloaded blender popped the top off and splashed stuff everywhere? Try to imagine what it looks like when that happens with a blender that's 4 times as powerful. This is particularly problematic with hot liquids - the fast start of the blender throws the hot liquid up in the jar, which causes the air in the jar to expand and jet out the top. I think of it as Mount Blendtec erupting. Cleaning shake mix off the ceiling isn't very much fun.

I think I've got the technique dialed in now. I do wish they'd implement a slightly softer start for the low-speed settings, though. All in all, it's definitely a massive improvement over our old, tired blender. I'm going to try some of the recipes from the cookbook. That should help familiarize me with the various cycles. Besides, it's just plain fun to use - it'll blend darn near anything. Speaking of which, if you haven't seen it, check out Blendtec's Will It Blend? for amusing demos of the blender in action.

They're running a contest over at Worse Than Failure

2007-05-02T12:04:00.000-07:00

Worse Than Failure (formerly The Daily WTF) is having a programming contest, with either a MacBook Pro or Sony VAIO laptop as first prize.

For those not familiar with the site, their theme is Curious Perversions in Information Technology. People submit particularly awful pieces of code, or database schemas, or business practices, and the readers of the site make various insightful, witty, outraged, or just plain misguided, comments on them.

The contest: Implement a four-function calculator program (for Windows, or UNIX/GTK). Your program must pass the specified test cases, have a GUI driveable using a mouse, and should cause people who read the code to shake their heads sadly in disgust.

There's much more detail on the contest website, but I thought the idea of the contest was interesting enough to mention. The contest discussion forum is hilarious, as well. Check out this comment:

Mine's too slow right now. It's taking about 45 minutes to add 9876 and 1234, when I was hoping for about three seconds. I knew it was O(n^2), but I was expecting the constant to be a bit smaller. I may need to replace the Mersenne twister with a faster random-number generator.

I have what I think is a pretty good set of ideas for a submission, I'm just not sure that I'll be able to finish in the time remaining (12 days left). I'll probably submit whatever I have by then, even though I almost certainly won't win. I'm looking forward to seeing the other entries, though.

Oops...

2007-05-02T09:05:00.000-07:00

Looks like somebody at Amazon.com accidentally merged two entries in the product database.

Slashdot really irritates me sometimes...

2007-04-10T23:08:00.000-07:00

There's a story on Slashdot about a new idea for a way to enable patching complex microprocessors to work around design defects, or "errata", as they're called in the industry. The basic concept is to include a small amount of configurable logic on a chip, and use it to detect conditions that would otherwise trigger a known errata, and automatically work around it.

This would allow manufacturers to fix design defects in already-manufactured chips, rather than fixing the defects in subsequent revisions of the chips, and leaving earlier customers with the buggy chips they bought (which is what they do now).

Unfortunately, the article that's linked in the Slashdot submission is a little light on details, and the summary is just plain misleading, so the Slashdot comments are completely swamped in responses like: "this is an old idea!", "what's so novel about an FPGA?", "FPGA's are expensive, slow, and inefficient!", and other nonsense.

I actually read the article and tried to understand what it was about. When I posted that it sounded like a good idea, and it'd be interesting to read more about the design, an unregistered Slashdot user provided me with a link to the original paper, which made it much more clear what the whole thing was about.

But nobody else can see that link, because Slashdot's moderation system assumes that unregistered users are less trustworthy, so the comment with the link to the original paper is invisible to the idiots that keep ranting back and forth to each other about what a dumb idea this is, without having any idea what they're talking about.

So, go here, and read the original paper, especially if you've ever had the experience of running into one of these errata before. Hopefully, the folks at AMD, Intel, and IBM will see this, and it'll make it's way into newer designs.

Daylight Saving Time is here...

2007-03-12T13:05:00.000-07:00

[edit: changed the title of this entry, since the old one wasn't quite relevant anymore]

Daylight Saving Time is here again in the good 'ole US of A. This year, the dates for the switch to and from summer time have changed. Naturally, despite the fact that this change has been known about for nearly two years, there was a last-minute scramble by various companies to get "patches" for their software out in time for the new Daylight Saving switchover.

And some of them didn't, in fact, get ready on time. Despite the fact that I (and the rest of my company) installed Microsoft's patches for Windows, this morning all of our meetings in our Outlook calendars are shifted by one hour. And we're not the only ones - I see in the news that this is causing problems all over. If someone's late for an appointment with you today, cut them some slack - it's probably Microsoft's fault.

What was that?

2007-02-27T11:59:00.000-08:00

When I was a young lad I had, shall we say, a more "carefree" attitude towards software development. This is the story of how I learned to be a bit more methodical in my approach to certain types of issues.

The project I was working on was the motion control system for a robot. Now, I should probably clarify that, so you don't get the wrong idea - we're not talking about C3PO or R2D2, here. This was an industrial robot, used for 3-d imaging. The robot itself was made out of slabs of cast iron bolted together, was probably 8 feet tall, 4 feet wide, and ten feet long, and weighed in the neighborhood of 4 tons.

The problem I was having was that the motion control was somewhat unresponsive - you'd move the joystick, and the translation table or the optical head would slowly start to move, and when you got to where you wanted to go, it'd keep on moving for a little while before coming to a stop.

As I was looking at the code, I found what I thought was the problem - I had simply put the wrong coefficient in for one of the control equations, so we weren't getting the proper exponential factor applied to the requested motion. A quick edit and recompile, and I was ready to test the new code.

I started the system up, and very slightly moved the joystick. The translation table started to creep forward. I then pushed the stick over a little farther, and the table accellerated. So far so good.

And then, something very bad happened. When I put the stick back to the rest position, the table didn't slow down. In fact, it kept speeding up. I tried pulling back on the stick, but that didn't seem to have any effect. I managed to turn off the power to the motors just before the table hit the hard stops at the end of its travel.

So this 600 pound cast-iron table slams into the rubber bumpers at the back of the machine, going something like 30 feet per second. The whole machine rings like a gong, and all work in the entire shop grinds to a halt as everybody looks over to see this multi-ton machine gently rocking back and forth. I was really worried that I'd wrecked at least part of a very expensive machine, but a later calibration run showed that the mechanical parts of the robot were just fine.

It turns out that there were two problems in the system - the incorrect exponential on the input side that I'd corrected, and an additional incorrect damping factor on the output side. The upshot of all this is that once the system was up to speed, it took a very long time to slow down, but the bug on the input side ensured that it never got up to more than a tiny fraction of the maximum speed.

The next time I needed to make a change in those calculations, I did a "dry run" with the motors disconnected first...

Just barely better than no backup at all...

2007-02-12T22:33:00.000-08:00

So, the hard drive on my Mac died. Disk Utility won't fix it, Techtool pro just throws up its hands at the 2,000 bad blocks on the drive, etc, etc.

That kind of sucks, but at least I have relatively recent backups to restore from. Or, maybe I actually don't. I've been using the .Mac Backup program to do backups for the last year or so - prior to that, I was just bulk-copying stuff by hand to an external hard drive. The Backup program is a lot more convenient, and makes much better use of the space on the external drive.

I figured that surely, now that Backup is at version 3.1, it'll be rock-solid reliable, right? I mean, once they fixed that awful crashing bug I reported back in the 1.0 days, I hadn't noticed any problems, so everything is OK, right? Well, as it turns out, Backup 3.1 is no more reliable than the old Backup - it just has different bugs. Now, instead of crashing on backing up large numbers of files, it crashes when trying to restore them. If I was given a choice between these two behaviors, which do you think I would have chosen?

The one saving grace is that inside the broken Backup file package is a more-or-less standard Mac OS X disk image file. So, I can mount those files (one from the last full backup, and one from each of the incrementals), and hand-copy the files over from them. Let's hear it for unreliable backup software...

Language matters

2007-01-16T22:58:00.000-08:00

My non-programmer friends and relatives sometimes ask me:
Why are there are so many different computer languages?

My co-workers sometimes ask me:
Why are there so many reference books for obscure languages on your bookshelf?

The answer in both cases turns out to be the same: Language matters. The language you use affects how you think about a problem. Psychologists and Linguists (and Politicians and Salesmen) have known about this for years as it applies to human languages, and it turns out to be true for computer languages as well, of course.

I was reminded of this fact just today, as I was explaning some concepts in Object Oriented Programming to a co-worker who's just coming up to speed on C#, after using mostly C and Perl for several years.

My own first exposure to Object Oriented Programming was back in the (very) early 90's, with Borland and Microsoft's C++ compilers. I'm not sure I ever really "got" OOP in C++, and neither did most (all?) of the people I worked with. We mostly just used C++ as a better version of C.

Fortunately for me, I managed to snag a copy of Digitalk's Smalltalk for Windows not long after that. And suddenly, it all made sense!. Because the Object-Oriented nature of Smalltalk is so "in your face", you can't help but start thinking about things in a new way. The version I got came with pretty decent tutorial info as well, which was also a big help.

I never actually produced any large-scale software in Smalltalk (it was impractical for work projects in terms of performance), but the new way of looking at things stuck with me as I continued to write low-level bit-banging code in C. When I came out to California and worked for NeXT, my Smalltalk experience translated, more or less directly, to Objective-C.

Anyway, back to the discussion with my co-worker. There are a couple of different ways of thinking about "using objects" that I'm familiar with, and I tend to think of them as "The C++ way" and "The Smalltalk way". In some sense, this isn't entirely a fair characterization, but in my experience, the two views are more-or-less endemic in their respective programmer communities, so that's how I think of them.

The C++ view:
An object is a combination of some data, and functions that operate on that data. To perform some action, you call a member function of the object instance that has the data you need to work on.

The Smalltalk view:
An object is a model of some part of your problem domain, and each object has its own set of responsibilities and capabilities. To cause something to happen in your program, you send a message to an object, which may in turn send messages to other objects.

Now, it turns out that these two definitions are actually equivalent, or at least compatible, despite the fact that the C++ definition is entirely focused on the implementation detail, and the Smalltalk definition is entirely focused on the semantics.

When you get right down to the low-level implementation details, "sending a messsage" and "calling a member function" are really the same thing. A couple of CPU registers get loaded with a couple of addresses, and then you jump to a subroutine. Yes, I know it's more complicated than that in the real world, where you've got vTables, and dynamically-compiled methods, etc, etc. Work with me here...

The C++ programmers that I've met usually come to C++ from a background writing software in C. Because C is such a very low-level language, it encourages (or maybe I should say requires) that you understand the low-level details of how stuff works under the hood - memory management, how structures are laid out in memory, that sort of thing. When these folks start using C++, they apply the same low-level filter to things, and they see a class as just a data structure with some functions attached to it. This is in fact technically true, but kind of misses the point.

As I was trying to explain to my co-worker what I didn't like about some code of his that I was reviewing, I ran into a bit of a wall. I knew that something wasn't quite right, but I wasn't able to articulate the problems well enough. I think I finally figured out that it was at least partly a result of the difference in perspective due to our different backgrounds. Once I figured that out, I was able to take the discussion out of the tactical questions like "should I use a Regular Expression here?", and into the more theoretical territory of "is this an appropriate way to model the problem you're trying to solve?", and I think we made better progress after that.

It'll be interesting to see whether my co-worker has the same kind of epiphany that I did, or if he'll pick stuff up more gradually. Given that we're mostly using C# and C++ at ZING, I suspect it'll be the latter. You can write code in C# that looks just like C, with the minimal amount of "classiness" wrapped around it to compile. I suspect it would be easier for most folks to learn a new concept in a language where their old habits are obviously not going to do the trick.

Which reminds me of something else I wanted to write...

So, how was CES, anyway?

2007-01-15T12:00:00.000-08:00

For those who don't recognize the name, "CES" is the Consumer Electronics Show, a yearly trade show for the Consumer Electronics industry.

ZING did really well at CES this year. In addition to the usual behind the scenes deal-making and partner development, we had a couple of high-profile announcements, and one of the products we're helping to bring to market won an award!

SanDisk's Sansa Connect got a "best of show" award from CNET.

What does that have to do with ZING, you ask? We designed the hardware, software, and service infrastructure that makes the Sansa Connect work.

ZING also announced a deal with FON that will allow ZING-enabled players to connect to the FON network. This is great because FON is the fastest-growing WiFi hotspot network out there. They've got an interesting business model, too - share your WiFi bandwidth at home, and get free access to WiFi when you're not at home. Check them out at http://www.fon.com.

For a while there, an at-CES interview with our CEO Tim Bucher was linked from the front page of CBS.com. It's a little harder to find today, but here's a link.

So that's what it feels like...

2007-01-12T10:04:00.000-08:00

It was an interesting experience watching a MacWorld keynote address with a feeling of dread, rather than one of anticipation. Fortunately, Apple didn't announce anything that makes the product I'm currently working on irrelevant, but it was interesting feeling that cold prickle of fear.

The iPhone is very expensive by my standards, but that's always true for Apple hardware. When I worked there, I never really felt like I belonged, in some sense. I never would have bought an iPod when they came out, but the market certainly ate them up. I'll most likely take a pass on the iPhone as well, not least because it's not a clamshell phone. I'm not really a fan of phones that are designed such that I can't sit down with them in my pocket.

The more surprising thing (and frankly worrying, as a competitor) is Jobs' claim that the iPhone is running Mac OS X. Now, we all know that that's not *quite* true - presumably it's been stripped down a bit for the environment. But the key thing is that it's actually got a rational software architecture. One of the things that was a constant drain on the iPod team when I was there was that there wasn't any OS as such on the iPods, and they weren't really built on any kind of common platform.

This made adding new features to the product line, or even fixing minor bugs, a major hassle - between making the changes in 3 or 4 gradually diverging code bases, and retesting absolutely everything anytime we changed anything (no memory protection or preemptive multitasking on those old iPods), we had a hell of a time just getting anything done.

When Apple needs to add a new feature to the iPhone, they'll just have any one of Apple's developers crank out a widget in DashCode, and they can then just make it available for download. If you're any kind of Consumer Electronics company, you really ought to see this as a shot across the bow. Maybe you're not in the mobile phone business, and you don't see how a $500 cell phone is relevant to you.

First, don't expect that the price is going to stay that high for long. Second, think about what's the actual difference between an iPhone and a new wide-screen iPod, or an Apple portable game machine, or whatever? That's right - a couple of minor board changes, and some new application software, and it's whatever Apple wants it to be. They've got an actual PLATFORM for high-end (currently) Consumer Electronics, and the game as we've known it is changing.

Job postings...

2006-11-08T12:20:00.000-08:00

I'm trying to hire some White Box testers to grow my Platform QA Team here at ZING. The job descriptions on our website (and that we've posted to various job boards) don't really do much to interest me in the job, so I'm worried that they're not appealing to the folks I'm trying to recruit, either.

I spent some time trying to come up with something short and sweet that at least answers the basic set of questions somebody might have about us, and about the jobs I have available. This was in the context of emailing a possible candidate that one of my co-workers referred to me.

Here's what I came up with in about 5 minutes between lunch and a meeting -

What we do:The Platform QA team is responsible for:

Writing automated tests
Developing testing frameworks
Executing automated and semi-automated tests, and reporting the results
Participating in design and code reviews with the development team
Creating utilities to improve the Development and QA processes
Evaluating and implementing tools (Static Analysis, Code Coverage, etc) to enhance the testing process

What we’re looking for:

Experience in software testing and software development, either as a white-box tester or software developer
Familiarity with one or more of: C++, C#, or Java
Someone who likes to debug complicated problems
Some experience with API testing is useful, but not required

About ZING:

We’re a Consumer Electronics technology company – we license our hardware and software designs to companies that sell them under their own brand
We’re a pre-IPO startup
Located in Mountain View, California
The first product based on our technology just recently went on the market – the Sirius Stiletto 100 portable satellite radio
Website: www.zing.net (a little short on details, but it’s getting better)

Why you should come work here:

You’ll get to work with a wide variety of cutting-edge technologies
We’ve got a great working relationship between QA and Development
You’ll actually get to write code, report bugs, and see them get fixed quickly

What do you think? Is that a reasonable job description, and what sorts of things strike you as missing? Should I include more information about what the actual job duties are? Or more information about the company?

Any suggestions gratefully accepted. And, should you happen to know someone who's an ace White Box tester looking for a job, send them my way, OK?

A couple of quick links...

2006-09-27T10:11:00.000-07:00

First, the first ZING product is out. Sirius Satellite Radio officially announced the Stiletto 100 yesterday. This is an important new product for Sirius, and the first use of ZING's technology "in the wild". More details coming soon, but you can watch the presentation from the DEMOfall 2006 conference here.

Second, at the Intel Developer Forum, Intel showed off a prototype of an 80-core processor, which they expect to have commercially available in 5 years or less. It's an amusing bit of synchronicity that they announced this a day after my blog post discussing the inevitable adoption of massively-parallel processor designs for the desktop market.

Another thread on . . . threads

2006-09-26T00:53:00.000-07:00

Thanks for reading...

First, I want to thank everybody who read Part I, especially those of you who made comments on it. I'm going to address a couple of those comments and questions first, then proceed to my philosophy of How not to shoot yourself in the foot when writing multi-threaded code in C-like languages.

In a completely non-technical aside, one of my previous articles somehow got listed on both digg and reddit, and now random people on the Internet are making cogent, well-reasoned responses to it, and to my previous posts. I feel like a "real blogger" now. Thanks, and I'll try not to let it go to my head. It's a bit ironic, in that the original purpose of this blog was to help me get over my fear of writing, and now that I know that I have an audience, it's even harder...

Okay, back to threads...

Graham Lee pointed out that Mach threads can in fact be configured to conform to something like the no-state shared model. All you have to do is create a new task, use vm_inherit() to disallow any sharing of memory regions with the old task, and Bob's your Uncle. That's a good point, and something that I might have glossed over. In many cases, you can get a separation of state between threads by doing a little additional work outside the pthreads-style interface.

Reimer Mellin mentioned that the CSP model had been around for quite some time before Occam was invented. That's true - the initial paper describing CSP was apparently published in 1978, whereas Occam didn't hit the scene until 1983 or so, when the Transputer first started to become available. Apparently, Tony Hoare (the inventor of CSP) wrote a book on a more formalized version of CSP in 1985. It's available online, but if you're not a mathematician, it might be rough going. Personally, I find that the more funky symbols used in a piece of writing, the harder it is to read. Hoare's book uses lots of symbols - there's even a six page long "glossary of symbols".

Some Dos and Don'ts

These are in no particular order, and simply represent some different ways of slicing the multi-programming pie. One or more of them may apply to your next project...

Do consider whether you need to use threads at all

Sometimes what you actually want is a separate process, in the heavy-weight, OS-level process sense. If you think about it, one program doing two things at once isn't fundamentally all that different from two programs doing one thing each. Yeah, I know, all that overhead, spawning a whole new process, setting up IPC with named pipes or whatever... But have you ever actually measured the overhead of creating a process, or transferring a few megabytes of data between two processes on the same machine?

I've done a couple of simple, two-process (GUI and background server) applications on both Mac OS and Windows, and you might well be surprised by how well this design works in practice. Of course, if your 'background' process just ends up spinning its wheels inside some hideously-complex calculation, or you actually need to send a lot of data between the GUI and the calculation engine, then you haven't actually solved your problem, and you'll have to do something more sophisticated.

Don't use threads to avoid blocking on I/O

Unless you're programming on some seriously old, backwater OS, you should have other options for your file and network I/O that don't involve waiting for the I/O to complete. This is very dependent on what platform you're using. Try hitting your favorite search engine with the terms "async I/O" or "nonblocking I/O" to read about the various options available. The complexity of these async I/O approaches can seem a little daunting, until you realize that in the simple-seeming "create a thread for background I/O" model, the complexity is all still there, it's just not as easy to see.

Do know what each thread in your program is for

You need to have an identified set of responsibilities for each thread in your system. Without a clear idea of what each thread is responsible for, you'll never be able to figure out what your data-sharing strategy needs to be. If you use UML or CRC cards to model your system, or even if your "design" is a bunch of clouds and arrows on a whiteboard, you need to be able to determine which parts of the system can run concurrently, and what information they need to share. Otherwise, you're doomed.

Don't reinvent the wheel

It's harder than you might think to write code that's truly thread-safe. You'd be well advised to see what's been done already for your language & environment of choice. If someone has already gone to the effort of creating thread-safe data structures for you to use, then use them, don't create your own.

For example, if you're already running your "main" GUI thread in an event-processing loop, consider using that message queue as your communication channel between threads. The .NET 2.0 framework provides a class called BackgroundWorker specifically to address the "trivial background calculation in a GUI app". The design of BackgroundWorker is worth reading about (Google it), even if you're on another platform. It's a nice, simple way to manage a second thread for background processing in a GUI application.

Do consider developing a strategy for detecting and/or avoiding deadlocks

Let's get this out of the way - in any non-trivial shared-memory system with conventional locking semantics, you'll never be able to predict ahead of time whether on not a deadlock will occur. I'm told there's a proof that in the general case, predicting deadlocks is equivalent to the infamous Halting Problem, which you've perhaps heard of before. If you have a reference to a research paper on this, let me know - I'd like to beat some people over the head with it. Despite all that, it's relatively easy to detect when the system is deadlocked.

Don't spawn threads in response to external events

This is really just a special case of know what each thread in your program is for. It's hard enough to coordinate all the concurrency in your program with a static set of threads. Adding in the additional complication of unknown numbers of active threads at any given time is sheer insanity.

Also, given that there's some amount of overhead involved for each thread that you create or have active, scaling up the number of threads as load increases will often have the perverse effect of decreasing throughput by attempting to improve it..

Do consider a message-passing design

I mentioned this in Part I, but you might want to consider using the message passing model, even if you're working in a shared-memory world. The basic rule here is to avoid modifying any global state from within more than one thread. When you send a message from one thread to another, you pass in all the data it'll need to access in order to complete its job. Then, you don't touch those data structures from anywhere else until the other thread is done working with them.

The only real hurdle in implementing this strategy is in keeping up the separation between threads, despite not having any language-level support for the desired partitioning. You need to be really careful to not accidentally start sharing data between threads without intending to (and without having a plan).

Don't hold a lock or semaphore any longer than actually necessary

In particular, never hold a lock across a function call. Now, this might seem a bit extreme, but remember, we're trying to manage complexity here. If you can see all the places where a lock can be acquired and released all at once, it's easier to verify that it's actually acquired and released in the right places. Holding locks for the shortest time practical also shortens the window in which you can experience a deadlock, if you've made some other mistake in your locking strategy.

Do stay on the well-trodden path

The producer-consumer model, thread pools and work queues all exist for a reason. There's a solid theoretical underpinning for these designs, and you can find robust, well tested implementations for most any environment you might be working in. Find out what's been done, and understand how it was done, before you go off half-cocked, inventing you own inter-thread communication and locking mechanisms. If you don't understand the very low-level details of how (and when) to use the "volatile" qualifier on a variable, or you haven't heard of a memory barrier, then you shouldn't be trying to implement your own unique thread-safe data structures.

Do use multiple threads to get better performance on multi-processor systems

If your program is running on a multi-processor or multi-core computer (and chances are that it will be, eventually) you'll want to use multiple threads to get the best possible performance.

Moore's Law, and what the future holds

Welcome to the multi-core era

I can't find the excellent blog post I was reading on this subject just yesterday, but here's an article by Herb Sutter that hits the high points. The bottom line is that you're not going to see much improvement in the performance of single-threaded code on microprocessors in the near future. In order to make any kind of performance headway with the next couple generations of processors, your code needs to be able to distribute load over multiple processes or threads.

The future is now

Desktop PCs with 4 processors are already readily available. Sun's UltraSparc T1 has 8 cores on one chip, and can execute 32 threads "simultaneously", under ideal conditions. Even Intel's Itanium is going multi-core, a dramatic departure from the instruction-level parallelism that was supposed to be the hallmark of the EPIC architecture (but that's a story for another time).

Some time in the very near future, the programs that you're writing will be executing on systems with 8, 16, or more processors. If you want to get anything near the peak level of performance the hardware is capable of, you're going to need to be comfortable with multi-processor programming.

Everything old is NUMA again

It's perhaps a trite observation that yesterday's supercomputer is tomorrow's desktop processor. Actually, I think it's more like there is a tide in processor design, that hits the supercomputer world, then hits the mainstream a couple decades or so later, when the high-performance folks have moved on to something else.

In the 1980's, supercomputers were all about high clock-speed vector (SIMD) processing, which is where the current generation of desktop chips have stalled out. Clock speeds aren't going to massively increase, and the vector capabilities of the Pentium and PowerPC processors, while impressive, are still limited in the kinds of calculations they can accelerate. And the processor designs are so very complex, that it's hard to imagine that there are many more tricks available to get more performance-pre-clock out of the existing designs.

When the supercomputer folks hit their own megahertz and design complexity wall, they went through their own muti-core CPU era, then in rapid succession to massively parallel MIMD systems, then to the super-cluster computers we see these days. It seems reasonable to expect an explosion of processors in desktop systems too, and for much the same reason - the standard SMP shared memory model doesn't scale well.

In particular, cache coherency becomes a major performance issue in shared-memory multi-processor systems as the number of processors increases. The conventional wisdom says that a design where all memory is shared can scale to 4-8 processors. This is obviously dependent on memory performance, cache architecture, and a number of other factors. Perhaps worryingly, this means we're not only at the start of the multi-core era in the desktop world, we're also about one processor generation away from the end of it. Gee, that went by pretty fast, didn't it?

So, what's next?

Going by the "20 years behind supercomputers" model, the Next Big Thing in desktop processors would be massively-parallel architectures, with locally-attached memory. You'd expect to see something like the Connection Machine, or the Transputer-based systems of the 90's. Given the advances in process technology, you might even be able to fit hundreds of simple processors on a single chip (actually, some folks have already done that for the DSp market).

However, the desktop computer market has shown a remarkable reluctance to embrace new instruction sets. So a design using hundreds or thousands of very simple processors with fast locally-attached memory isn't likely to succeed the currently ascendant IA32/IA64 Intel architecture. So where do we go from here? I think Intel is going to keep trying to wring as much performance out of their now-standard two chip, multiple cores per chip design. They can certainly do some more clever work with the processor caches, and with a little help from the OS, they can try to minimize thread migration.

Ultimately that approach is going to run out of steam though, and when that happens, there's going to be a major shift in the way these systems are designed and programmed. Through the multi-core era, and even into the beginning of the massively parallel era which will inevitably follow, you ought to be able to get away with following the pthreads model. You might need to think about processor affinity and cache sharing in ways you don't have to now, but it'll at least be familiar territory.

When really massively-parallel systems start to become more common, the programming model will have to change. The simplicity of implementation of the shared-memory model will inevitably give way to more explicitly compartmentalized models. What languages you'll likely use to program these beasts is an interesting question - most likely, it'll be a functional language, something like Haskell, or Erlang. I've been lax in getting up to speed on functional programming, and I'm going to make an effort to do better. I recommend that you do the same.

Hell is a multi-threaded C++ program.

2006-09-02T18:49:00.000-07:00

What are threads?

Every modern operating system has support for threads, and most programming environments provide some level of support for threading. What threads give you is the ability for your program to do more than one thing at once. The problem with threads is the way that they can dramatically increase the complexity of your program.

First, a little background, so we're all on the same page. In Computer Science, as in the physical sciences, using a simplified model makes it easier to discuss complex phenomena without getting bogged down in insignificant details. The trick of course, is in knowing where your simplifications deviate from reality in a way that affects the validity of the results. While spherical cows on an infinite frictionless plane do make the calculations easier, sometimes the details matter.

When Real Computer Scientists (tm) are discussing problems in concurrent programming (like the Dining Philosophers), they'll sometimes refer to a Process, which is kind of abstract ideal of a computer program. Multiple Processes can be running at the same time in the same system, and can also interact and communicate in various ways.

The threads provided by your favorite operating system and programming language are something basically similar to this theoretical concept of a Process, with a few unfortunate details of implementation.

The New Jersey approach

I couldn't find a definitive reference to the history of the development of threads as we know them today, but the model most people are familiar with arose out of POSIX, which was largely an attempt to formalize existing practice in UNIX implementations.

It turns out that POSIX Threads, Mach Threads, Windows Threads, Java Threads, and C# Threads all work very much the same, since they're all implemented in more or less the same way. The object-oriented environments wrap a thin veneer of objects around a group of extremely low-level functions, but you've got your basic operations of create(), join(), and exit(), as well as operations on condition variables and mutexes. For the rest of this rant, I'll refer to these as "Pthreads", for convenience.

Pthreads are an example of the Worse is better philosophy of software design, as applied to the problems of concurrent programming. The POSIX threading model is just about the simplest possible implementation of multi-threading you could have. When you want to create a new thread, you call pthread_create(), and a new thread is created, starting execution with some function you provide. The newly-created thread is created by allocating some memory for a stack for the new thread, loading up a couple of machine registers, and jumping to an address.

Shared state - two models

In the Pthreads model, all of your threads share the same address space. This makes sharing data between threads very simple and efficient. On the other hand, the fact that all of the state in the program is accessible and changeable from every thread can make it very difficult to ensure that access to all this shared state is managed correctly. Race conditions, where one thread attempts to update a data structure at the same time that another thread is trying to access or change that same structure, are common.

The problem with the all state is shared model is that it doesn't match up very well with what you're generally trying to accomplish when you spawn a thread. You'll normally create a new thread because you want that thread to do something different than what the main thread is already doing. This implies that not all of the state in the parent thread needs to be available to be modified in the second thread. But because of the way threads are created in this model, it's easier (for the OS or language implementor) to share everything rather than a well-defined subset, so that's what you get.

The other major model for multi-threading is known as message-passing multiprocessing. Unless you're familiar with the Occam or Erlang programming languages, you might not have encountered this model for concurrency before.

There are a number of variations on the message-passing model, but they all have one thing in common: In the message-passing model, your threads don't share any state by default. If you want some information to go from one thread to another, you need to do it by having one thread send a message to the other thread, typically by calling a function provided by the system for just this purpose. Two popular variants of the message-passing model are "Communicating Sequential Processes" and the "Actor model".

You can get a nice introduction to the message-passing model by reading the first couple chapters of the Occam Reference Manual, which is apparently available online these days (I got mine by digging around in a pile of unwanted technical books at a former employer). Occam is of course the native language of the Transputer, a very inventive but commercially unsuccessful parallel processor architecture from the UK which made a big splash in the mid-80's before vanishing without a trace.

Why would you want to learn about this alternative model, when Pthreads have clearly won the battle for the hearts and minds of the programming public? Well, besides the sheer joy of learning something new, you might develop a different way of looking at problems, that'll help you top make better use of the tools that you do use regularly. In addition, as I'll explain in Part II of this rant, there's good reason to believe that message-passing concurrency is going to be coming back in a big way in the near future.

Enough rope to hang yourself with

As I mentioned earlier, the Pthreads model implies that all of your program's address space is shared between all threads. Most (all?) implementations allow you to allocate some amount of thread-local storage, but in general, the vast majority of your program's state is shared by every thread. This implies that every thread has the ability to modify the value of any variable, and call any arbitrary function, at any time. This is a really powerful tool, but like all powerful tools, it can be dangerous if misused.

It's extremely difficult to predict what the behavior of even fairly simple code will be, when multiple threads can run it simultaneously. For more complex code, the problem rapidly becomes intractable. In a low-level language like C, you need to know the intimate details of how the compiler will optimize your code, which operations are guaranteed to be completed atomically, what the register allocation policy is, etc, etc. In a JIT-compiled language like Java or C#, it's impossible to even know what machine code will be used at runtime, so analyzing runtime behavior in detail just isn't possible.

An unlocked gun cabinet

I think one of the major problems with Pthreads is that it's too easy to make something that almost works. This then leads to an unwarranted belief that multi-threaded programming is simple. For example, say you've got a simple interactive GUI application, and you think that the application takes too long to calculate something after the user presses a button. The "obvious" solution to this problem is to have your button-press handler spawn off a new thread to perform the long-running operation.

So you try this, and it works perfectly on the first try - the child thread launches, and then calculates away while the main thread goes back to handling the UI. You still need to notify the main thread when the calculation is complete, but there any number of easy ways to do this, and you probably won't have much trouble figuring that out. Gee, that wasn't so difficult, I wonder why people say that multi-threaded programming is difficult?

It's this sort of ad-hoc approach to creating threads that gets people into trouble. They create a new thread to solve one problem, and then another, and then they suddenly realize that thread A and thread M are interacting in a bad way. So they protect some critical data structures with mutexes, and before they know it, they're trying to debug a deadlock situation where they don't even understand how those two pieces of code could interact.

You need to really think about why you're creating a thread, before you spawn it. I'm not going to go so far as to say that creating threads while your program is running (rather than at startup) is de-facto proof that you're doing something wrong, but it's definitely a strong indication that you're not thinking about what your threads are for with any great rigor.

How to not shoot yourself in the foot

... is going to be the subject of Part II. Sorry for the cliff-hanger ending, but I wanted to get at least a little of this published, and potentially get some comments on it, before finishing the rest.

A Cockatoo joke...

2006-08-20T23:33:00.000-07:00

I'm still working on my "why threads are bad" rant, but in the meantime, here's a joke with a Parrot in it...

One day, a Cockatoo walks into an antique shop. The owner walks over and says to the Cockatoo:

"Hello there, can I help you with anything?"

The Cockatoo points his wing at a chair, and says to the shopkeeper:

"What can you tell me about this chair?"

The shopkeeper smiles at the bird, and launches into his best sales speech:

"I must say, you've got an eye for exceptional furniture. This chair is executed in the Lous XIV style, we estimate the manufacturing date to be around 1880, and the fantastic patina of the wood shows that it's been exceptionally well cared-for..."

The Cockatoo interrupts the sales pitch, and says:

"Yes, yes, that is all well and good, but what I really wanted to know is -

how does it taste?"

Now they have two problems...

2006-08-10T20:41:00.000-07:00

Today, I'm going to write a bit about programming. But first, a short detour into the wonderful world of USENET, and the adaptability of certain quotes to any situation...

There's a fairly well known quote (among programmers, at least), that goes like this:

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.
-- Jamie Zawinski

Jamie posted this to USENET back in 1997, and people have been quoting it ever since. I did some more searching, and I found an earlier variation, with citations going back as far 1988. Yes, Google Groups does have (some) USENET postings going back nearly 20 years. The older version is this:

Whenever faced with a problem, some people say `Lets use AWK.'
Now, they have two problems."
-- D. Tilbrook

Cool, so this is apparently one of those all-purpose jokes, much like any ethnic joke. Actually, that could be pretty interesting:

Whenever faced with a problem, some people say "Lets have the American do it." Now, they have two problems.
-- M. Bessey

Wow, that's comedy gold! Okay, maybe not. But it leads nicely into the topic I actually wanted to talk about:

presenting...

Mark's list of the Top Four programming technologies that fit into the "now they have two problems" template:
(in no particular order)

1. Threads
2. XML
3. Singleton objects
4. Regular Expressions

The common theme here is that these are all useful techniques, but are often misused by well-meaning programmers. I've seen more grief caused by misapplication of these technologies than anything else in my career. I'm going to write up a couple of quick rants on each of these subjects. This will be good for two reasons:

1. It gives me something to write about for the next couple of days.
2. I can vent a little about some particularly irritating instances of these things that I've seen.

Like an out-take from The Birds

2006-08-07T23:13:00.000-07:00

Continuing the "Wildlife Adventures in Suburbia" theme from the last post...

As I was driving up to my house Sunday evening, I noticed about a half-dozen or so little Sparrow-looking birds pecking at the sidewalk at the end of my driveway. I thought "that's a little odd, I wonder what they're eating?". As I was gathering up my stuff out of the car, I saw that another ten or so were perched on the fence around my front yard. Curiouser and curiouser...

I went around to the back of the Jeep, got my groceries, and turned towards the house, only to see that there were dozens and dozens of these birds perched on my fence and the gutters of the house, and just hopping around on the roof. at this point, I'm starting to get a bit freaked out. I've seen small groups of birds around the house before, but nothing like this.

Just as the "I feel like I'm in a Hitchcock movie" vibe really started to take hold, one of my neighbors drove by in a rather loud Ford Bronco. Apparently the birds didn't like either the sound or the look of the thing, so they all took off at once - from the street, off my fence and roof, and from the neighbor's yard, where I hadn't noticed that they were also congregating.

In total, probably a hundred of these tiny little birds took off from the ground, coalesced into a swirling cloud, and headed out to Santa Clara, presumably on a mission to freak someone else out.

Not a story about Black Widow Spiders

2006-07-31T22:45:00.000-07:00

On Sunday, Yvette and I were rearranging stuff in the garage in preparation for the roofing guys to come in and tear the roof off way too early in the morning on Monday. During the course of moving all the boxes around and covering stuff up, we managed to disturb a spider. I looked over at Yvette, and I saw a large, globular black spider crawling up her neck. Now, it so happens that Black Widow spiders aren't all that uncommon around here, and from a few feet away, this thing really, really looked like a Black Widow.

I attempted to calmly say "Hold still" so I could brush it off her without her getting bitten, but apparently my eyes gave me away, and Yvette totally freaked out. So she's shaking all of her clothing out and moving around, while I'm trying to get her to stand still so I can find the stupid spider and get it off her before she gets bitten. Mentioning that I thought the spider was a Black Widow was decidedly not helpful. It probably would have been comical if we weren't doing such a good job of completely panicking each other. Yvette managed to get the spider off of herself, and I eventually recovered it. It turned out to most likely be Steatoda grossa, a much less dangerous relative of the Black Widow.

After the incident, Yvette and I talked about what we might have done differently. We didn't really come up with anything, other than possibly running "Spider Drills". I'd just walk up to her and calmly say "Don't move" or something similar, and we'd practice not freaking each other out. I really hated the feeling of the whole thing spiraling out of control like that, with everything I said and did just making the situation worse.

Damned zombie python processes...

2006-07-28T09:26:00.000-07:00

If you're running Mac OS X, and you've installed XCode, try this:

open up a Terminal window, and type
ps -x |grep -i python

Do you see dozens and dozens of processes named (python)? Then you'll probably be interested in the discussion here.

This turns out to be due to a bug in XCode 2.3's distributed builds functionality. There's this sctwistd process that gets launched at startup, and every time you log in and out (even switching to another user counts), it spawns off a couple of python processes that get orphaned from their parent. These zombies accumulate over time, eventually leaving your Mac unable to launch any more programs.

Long story short, if you don't use dedicated network builders and you don't want to fill up your process table with Zombie Python Processes from Hell, perform these commands in a Terminal window, then reboot:

cd /System/Library/LaunchDaemons
sudo launchctl unload -w com.apple.dnbobserver.plist

Now if I can just figure out why Nikon View Monitor is being launched, even though I don't even use Nikon View anymore, I'll be a happy camper. I just don't like running software that I don't need.

One Small Victory...

2006-06-29T23:32:00.000-07:00

Last night, walking back to work from dinner, I happened to pass by the Scientology building in downtown Mountain View. As I passed by, I studiously ignored a Scientology drone as he tried to hand me a pamphlet explaining some of the finer points of L. Ron's philosophy.

As he asked me "Would you like a pamphlet?", I thought to myself "No, but I've got something for you". At which point I loosed the Silent-But-Deadly fart I'd been holding in for two blocks.

Maybe he can use those Dianetics mental control techniques to resist the urge to pass out...

One small victory. Have you farted on a Scientologist today?

Fun with eBay lenses

2006-01-25T14:41:00.000-08:00

I'll need to add a couple of pictures to this post to illustrate, but I just received a lens I purchased on eBay. It's a well-used, manual-focus Vivitar 70-150 "Macro" zoom. I put Macro in quotes because it doesn't appear that this lens gets anywhere near the range of true macro 1:1 magnification. The closest focus distance is a couple of feet.

It's kind of an interesting challenge using a manual lens on the d50. Obviously, the lens is manual focus, but apparently because the d50 also lacks some mechanical linkage to read aperture information, the camera can't set the aperture either, so only the fully Manual mode really works.

So, I end up setting the aperture on the lens, the shutter speed with the camera, and figuring the exposure by taking a test shot and adjusting based on what the histogram shows. I got a couple of decent pictures of Jeremy the Attack Cockatoo before he got bored and tried to eat me.

http://web.mac.com/mbessey/iWeb/Site/Vivitar%2070-150.html

It appears that this lens, at closest focus, gives about a 19cm wide field of view, as opposed to the 17cm I get with the 18-55 lens. Not exactly a "macro" zoom. I wonder if the fact that the lens rattles when I shake it has anything to do with that? Maybe there's supposed to be some additional extension at the end of the range, or something? I may just take it apart and see what I can do.

On the subject of camera lenses

2006-01-12T16:43:00.000-08:00

From an email I sent to a friend. The question at issue revolves around me getting my first digital camera with interchangeable lenses (a Nikon d50). The problem with having a choice of lenses is...needing to make a choice.

I've been thinking about the "how do I know what lenses I need?" question lately...

I was reading online that the conventional wisdom holds that the vast majority of pictures taken with a zoom lens are taken at either the minimum or the maximum focal length. So, I decided to check my own pictures and see if that's true. I found this program online called jhead, which will dump the exposure info out of digital camera JPEG files.I ran my entire iPhoto library through it, and analyzed the results with a Perl script.

I found out some interesting things about my picture taking habits.

Looking at the data for the E-10, which is the camera that I've taken the most pictures with, the distribution of zoom focal lengths look like this. To convert these from the E-10's smaller sensor size to the equivalent for 35mm field of view, you'd need to multiply by about 4.

focal # of pictures
9.0mm 1352
10.0mm 70
11.0mm 57
12.0mm 51
13.0mm 39
14.0mm 43
15.0mm 50
16.0mm 34
17.0mm 103
18.0mm 42
19.0mm 41
20.0mm 49
21.0mm 15
22.0mm 27
23.0mm 11
24.0mm 25
25.0mm 8
26.0mm 35
27.0mm 16
28.0mm 16
29.0mm 15
30.0mm 16
31.0mm 22
32.0mm 34
34.0mm 21
36.0mm 488

The conventional wisdom is confirmed, I guess. It's kind of fascinating to me that it's as lopsided as it is in favor of wide-angle though. I mean, I suspected that would be the case, but I didn't expect that it'd be so extreme.

It also interesting that there's that peak at 17mm (68mm equiv). Unfortunately, iPhoto won't let me search by focal length, but a quick visual scan through the library shows that most of these are relatively close-up shots of people's faces.

So based on the data, what *I* really need is one wide angle zoom lens, one portrait taking lens, which can probably be a non-zoom lens, and one telephoto zoom. Since the E-10 had neither a truly wide-angle or a truly high-magnification telephoto, it's not entirely clear what actual range I need on either end of the scale.

On the wide end I think the decision is easier. I decided to just get the widest wide-angle zoom I could find, which is how I ended up with my 10-20mm (15-30 35mm eq) zoom. So far, that's working out pretty well for me. And now I can shoot a 180 degree panorama in two shots, which is pretty cool...

For portraits, a 50mm lens is pretty close to the 45mm lens my data says I'd want. I'd just have to step a little farther away. 50mm being the "standard" length for 35mm lenses, the basic Nikon 50mm f/1.8 lens is relatively inexpensive at $100 or so. Now, I do have that range covered with my existing zoom lens, but the fixed lens gathers way more light at f/1.8 than the zoom does at its maximum f/5.6 - doing the calculation, that's about 9 times as much light, which will make all the difference in whether I need to use a flash or if I can use available light.

On the telephoto end, I'm at a bit of a loss. I wasn't very happy with the limited telephoto on the E-10, so I'm pretty sure I'll need something considerably longer than the 17-55 lens that came with the d50, which isn't even as good as that. But how far do I need to reach? I don't think I want a lens that absolutely requires the use of a tripod for every shot, and it would be pure insanity to pay over $1,000 for an optically stabilized (VR in Nikon-ese) lens.

One interesting (but not surprising) thing is that almost all of my (semi-Macro) flower pictures are at the far end of the E-10's zoom, as well. They look pretty good at that magnification, so the equivalent focal length on the d50 (which would be about 90mm)would be a good thing to have.

I should just get the 50mm lens, I guess, and maybe get a cheap telephoto zoom and explore what range I need before plunking down the money on a "serious" telephoto lens.

The best-laid plans...

2005-10-23T09:57:00.000-07:00

Okay, so I haven't been updating this as often as I'd like. I guess that's not too surprising, given my "issues" with writing. Of course, that's a major part of why I started this 'blog - to get practice writing, to improve my comfort level.

In that spirit, here's an update. I complained in an earlier post that I felt like my technical skills were deteriorating, and I needed to work on some independent projects to keep sharp. Well, I no longer have that problem anymore. I just started a new job, and there's more than enough technical challenge to go around - I've got to learn a new language (C#), and a new platform (the .NET framework). So maybe my little project will fall by the wayside for now, or perhaps I'll write a .NET gamne instead. We'll see what the next few weeks hold.

Getting my feet wet (again)

2005-08-12T21:34:00.000-07:00

I've decided that I need to exercise my coding muscles a bit more. I've been doing little tiny programs as part of my day job as a software tester, but it's been a few years since I've done any original, from-scratch application development.

Since I've got a Mac, and Cocoa is the environment I'm most familiar with, I'm going to start my new project as a Cocoa application. But what's the application going to be, you ask? Well, I have traditionally started out in any new environment by writing a video game, so why break with tradition?

Now, I just need to choose a basic idea...

First Post!

2005-06-28T14:08:00.000-07:00

Heh, just kidding. But at least with my own blog, I'll always get the first (and last) word on whatever discussion I'm in.

-Mark