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

Friday, July 11, 2008

Pictems!


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

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.

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?

Grr.

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

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:

Hardware:

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

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.

Thursday, December 06, 2007

Programmer's purity test

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:
  1. Programmed a computer?
  2. In ADA?
  3. In ALGOL?
  4. In APL?
  5. In APPLESCRIPT?
  6. In Assembly?
  7. In AWK?
  8. In B, or BCPL?
  9. In BASIC?
  10. In brainf*ck?
  11. 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:

  1. Programmed a computer?
  2. With jumper wires?
  3. In machine code?
  4. ...without a coding sheet or other aid?
  5. ...with toggle switches?
  6. ...from a Hex keypad?
  7. In assembly language?
  8. On punched cards?
  9. In a language whose syntax assumes that you're still using punched cards (eg Fortran, RPG)?
  10. In COBOL?
  11. In C or Pascal?
  12. In Forth?
  13. In Lisp (Scheme, Logo)?
  14. In Smalltalk?
  15. In a 4GL?
  16. In C++?
  17. In Java or C#?
  18. With a scripting language?
  19. In a modern functional language (Haskell, etc)?
  20. 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...

  1. Written a program that directly controlled objects in the physical world?
  2. ...did you ever injure anyone with a bug?
  3. ...other than yourself?
  4. Written software for internal business use?
  5. Written software that was sold at retail?
  6. Written software that sends email?
  7. ...did it ever send thousands of messages due to a bug?
  8. ...outside the organization you were working at?
  9. Programmed in a language of your own design?
  10. ...did anyone else ever use your language?
  11. ...did it become a de-facto standard?
  12. ...or an ISO or ECMA standard?
  13. Written a compiler?
  14. ...not as an assignment for a class?
  15. ..."by hand" (without using lex/yacc or related tools)?
  16. Created self-modifying code?
  17. Written code that modifies some other program's binary?
  18. Written self-reproducing code?
  19. ...without it getting away from you?
  20. Changed the class of an object at runtime?
  21. ...in a language without dynamic dispatch?
  22. Created a program that took longer to run (once) than it did to write?
  23. ...while running on a cluster of computers?
  24. ...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...