Sunday, December 28, 2008

A math problem

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:
,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.

Thursday, November 13, 2008


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:
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?

Tuesday, November 11, 2008

Just In Time compilation vs. the desktop and embedded worlds

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.

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.

Tuesday, November 04, 2008


It's election day today in America. THis is just a quick reminder for all my friends out there to get out and 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.

Sunday, October 19, 2008

Returning to Java, after 10 years away

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.

Sunday, September 28, 2008

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

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

See also Part 1 and Part 2 

Okay, so I've had a chance to play with the XO some more, and I've been thinking about how it might be useful for school kids in the developing world. You can read more about the project and their official justifications for it at the OLPC web site.

But as a computer geek, and an early adopter of the personal computer in my own country (the USA), I thought it might be interesting to look at it from the perspective of my own experience.


I first encountered Personal Computers some time in the mid-to-late 1970's, when they started appearing, in small numbers, in schools, at my friends' houses, and in stores. The first time I sat down at a computer and typed in a BASIC program, I was totally hooked. I experiemented with computers at other kid's houses, played with the systems on display at local stores, and even stayed after school and took summer classes at the local community college to get access to computers.

For the next few Christmases and birthdays, when my parents asked me what I wanted, I only had one answer: "I want a computer!". Unfortunately, it wasn't until about 1982/3 when my parents could scrape together the nearly unimaginable sum of $500 or so to buy me my first computer - a Texas Instruments 99/4a. I loved that thing to death, and it was a major part of my life for several years. I would have been ecstatic if someone had come to me at age 9 or so and said "here is a computer of your very own, to use at school, and to take home with you at night".

I got my first computer-related job my Junior year in High School. In theory, I was hired to do simple assembly and software loading on PCs, but I very rapidly got into more and more programming on a regular basis. You could fairly say that I wouldn't be where I am today without that early access to computer technology.

I went to my 20-year High School reunion recently, and one of the things that struck me was the number of folks who were working in more-or-less high-tech fields, particularly computer software. For a bunch of middle-class midwestern folks, we did really well riding the tech wave. I think that having computers in our schools (and a mandatory computer literacy class in high school) was a major factor there.

Okay, back on track...

So, having access to computers at an early age changed my life, and led to me to a highly-paid job in the technology industry. So what? That's probably not a reasonable goal for a poor kid in South America or Africa, there being no reasonable local high-tech industry for them to move into when they grow up (yet).

But, as the OLPC folks put it, "this is an education project, not a laptop project". So it's not (just) about providing computer literacy, but improving the educational process overall.

One example of this is textbooks - textbooks are surprisingly expensive, and as a result, aren't readily available, or frequently updated, in developing countries. If every child has their laptop, then textbooks can be stored on them, greatly reducing year-to year costs, allowing for more frequent updates, and freeing the students from carting a heavy load of books to and from school.

Or take language instruction - if you live in a developing country, one of the best things you can do to improve your chances at a better career is to learn a major language of commerce - English, Japanese, Chinese, Arabic, or whatever. But if there aren't any native English speakers in your village, who are you going to learn from? It'd be *really* easy to write a basic English primer to run on the OLPC, complete with video of a native English speaker demonstrating pronunciation.

Other features of the laptop are especially geared towards communication. In addition to the ability to access the internet, every laptop has an integrated video camera. In addition to giving the kids another device to experiment with, the teachers can use it to "send a note home" with the child, even if the child's parents are illiterate.

But, aren't there better places to spend the money? Don't these people need food and medicine first?

Yes, that's a common criticism - what's the point of giving children laptops, if they're dying of malnutrition, dysentery, malaria, and AIDS?

First, not everybody in the developing world is starving

In fact, there's no good reason for anybody to go without food, given the surpluses in the USA and elsewhere. If someone is starving out there, it's a political problem (i.e. someone in power doesn't care enough about them to feed them).

Second, who's to say we can't do both?

There are already lots of charities working on addressing basic human needs. The Gates Foundation is working to improve the health and basic welfare of children and adults all over the world. They're vaccinating children, helping small businesspeople bootstrap local economies, etc, etc. Meanwhile, the World Health Organization and UNICEF are doing their part as well. As an exclusively education-focused initiative, OLPC can provide services that aren't being covered by other agencies.

Knowledge is power
Finally, you can easily make the argument that a lot of the problems in the developing world are actually educational problems at the root. One reason that AIDS infection rates are so high in Africa is because of lack of education about the causes of AIDS and how to avoid becoming infected.

Similarly, rampant governmental corruption is not inevitable, but if you don't actually know that things don't work that way elsewhere in the world, how are you ever going to start down the road of cleaning it up?

I'd like to think that hundreds of thousands of schoolchildren running around with laptops that can function as digital camcorders would help bridge the gap of understanding between the folks in the developing world, and us in the "developed" world.

In conclusion
I think that despite the much-publicized management problems with the OLPC project, it's an interesting approach that I hope will have a positive effect on the children that participate. Even if the program as a whole doesn't quite work out as planned, hopefully we'll all learn something from it about how to "do it right" the next time.

Thursday, August 28, 2008

Cleaning out the backlog...

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

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...

Wednesday, August 13, 2008

Julia Child, International Super-spy

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.

Sunday, August 03, 2008

Pictems, three weeks in

"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 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, 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.

Friday, July 11, 2008


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.

Monday, June 16, 2008

The Problem with Magic...

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.

Friday, June 13, 2008

What a week...

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...

Friday, June 06, 2008

WWDC 2008

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).

Wednesday, May 28, 2008

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

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.

Tuesday, May 06, 2008

The intermediate approach...

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];


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.

Wednesday, April 09, 2008

Tolkien is probably rolling in his grave

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.

Wednesday, March 19, 2008

Tuesday, March 18, 2008

Is it my imagination?

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?


Wednesday, March 12, 2008

L. U. A. That spells Moon!

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:

  1. number
  2. string
  3. boolean
  4. nil
  5. function
  6. table
  7. thread
  8. 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.

Monday, March 10, 2008

Leaning towards the left...

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...

Wednesday, February 27, 2008

A fun little puzzle

I ran into this interesting puzzle over at, 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 :-)

Friday, February 22, 2008

Monkey madness!

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.

Wednesday, January 09, 2008

XO Laptop, part 2

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.

Friday, January 04, 2008

XO laptop mini-review

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:


t'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.

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.