The first thing I thought of while reading it was Horace Dediu’s recent post on Revolutionary User Interfaces. Which discusses how Apple’s major user-input changes have been a major factor in the success of their products. From the Mouse, to the iPod click-wheel, to the iPhone’s current touch interface, the interaction method has been the defining product differentiator.

I have no predictive thoughts on top of that, but it seems unlikely that Apple’s (or others’) teams aren't thinking in similar directions, internally. We already have gyroscopes and accelerometers in our hand-held devices, I wonder what the interfaces would be like with pressure sensitivity? I also wonder what could be done when haptic feedback can accommodate both small scale finger feedback (well) and larger scale gripping-style feedback?

In (something resembling) cooperation with r stevens, the Revenge of the Marker of the Beast has been unleashed:

(The Satanic Sticky Notes are also available separately.)

To see what else we're doing as Laboratory Industries, watch the site or follow @LabIndustries.

Hopefully that panic is followed by things working, hopefully quickly, but I digress.

Step 1 is keeping things working on my own machines. I run Mac OS on all those machines, Debian Linux on the servers. It seems that every Mac upgrade causes its own set of headaches. This time, after upgrading to Lion, the problem was that (after all sorts of other, expected, upgrading annoyances) all my perl code ran as test scripts, but wouldn't run under mod_perl. I would see:

It turns out that when you search for this kind of error, you get a lot of help for how to fix it under Rails. I don't want to steal from any of the numerous posts on how to fix it there, but it took reading through a whole bunch of those to figure out the "correct" solution, and I don't have a particular one to credit with helping me, although they all helped me grok the situation. It also would have been faster if I had known more about how Macs deal with dynamic libraries.

The important thing is that libraries contain within them the paths to the other libraries they work with. You can see these included paths with the "otool" command. In this case it was the perl DBD::mysql file mysql.bundle that was unable to find a library it needed. Specifically the libmysqlclient.16.dylib file: $ otool -L /Users/phillip/Sites/hosting/perl/lib/perl5/darwin-thread-multi-2level/auto/DBD/mysql/mysql.bundle
/Users/phillip/Sites/hosting/perl/lib/perl5/darwin-thread-multi-2level/auto/DBD/mysql/mysql.bundle:
  libmysqlclient.16.dylib (compatibility version 16.0.0, current version 16.0.0)
  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.0.0)

The problem file is the first returned "libmysqlclient.16.dylib" the "mysql.bundle" is looking for. It's looking relatively, and it needs to look or it more absolutely.

The tool to fix this is apparently "install_name_tool". You can use this to change those resulting lines that otool returned.

Now, the actual path of my "libmysqlclient.16.dylib" library is "/usr/local/mysql-5.5.9-osx10.6-x86_64/lib/libmysqlclient.16.dylib". However, I know that there's a "mysql" link corresponding to "mysql-5.5.9-osx10.6-x86_64" and another "libmysqlclient.dylib" corresponding to "libmysqlclient.16.dylib". So instead of using "/usr/local/mysql-5.5.9-osx10.6-x86_64/lib/libmysqlclient.16.dylib" I can use "/usr/local/mysql/lib/libmysqlclient.dylib". Hopefully future mysql upgrades will maintain those symlinks and I won't have to do this again.

The command I need to run, then, is to tell "mysql.bundle" where to find "libmysqlclient.dylib". This requires admin/sudo privileges so it is: $ sudo install_name_tool -change libmysqlclient.16.dylib /usr/local/mysql/lib/libmysqlclient.dylib /Users/phillip/Sites/hosting/perl/lib/perl5/darwin-thread-multi-2level/auto/DBD/mysql/mysql.bundle or, in more generic terms: $ sudo install_name_tool -change "old, bad library name" "new, fully functional path" "really long path to the problem child/library" After changing the relative path to an absolute one, otool says: $ otool -L /Users/phillip/Sites/hosting/perl/lib/perl5/darwin-thread-multi-2level/auto/DBD/mysql/mysql.bundle
/Users/phillip/Sites/hosting/perl/lib/perl5/darwin-thread-multi-2level/auto/DBD/mysql/mysql.bundle:
  /usr/local/mysql/lib/libmysqlclient.dylib (compatibility version 16.0.0, current version 16.0.0)   /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.0.0) and apache is starting happily.

actually, it found more …problems… but they were generic and more easily sorted out. End of the day, everything is happy now. On the computer, at least.

Postscript: the reason this wasn't an issue under my test scripts, run from my home account, is that my "DYLD_LIBRARY_PATH" environment variable contains "/usr/local/mysql/lib" as a path. Apache doesn't run under my account, and its security…stuff… makes it difficult to set a similar path that DBD::mysql will see.

fun?

So I'll be up until the move is complete, and I apologize in advance for all the inevitable breakage.

This will be the 8^th year I've been there, and they've gotten more fun every year. However, I'm not sure there's much that could top last year, which I consider to be incentive for everyone involved to try harder.

As usual, I'll be at booth 1335/1337 with the Dumbrella crew. With me this year are:

• Andy Bell
• r stevens
• Sam Brown
• Jon Rosenberg
• Meredith Gran
• Chris Yates

If I'm feeling inspired I'll get our crappy, outdated boothcam working and post it here, but I make no promises.

Back in my days at theglobe.com, my primary project was our homepage builder. Eventually had some marketing-oriented name for it (uBuilder?), but not for most of the time I was working on it. It originated as a way for users of our web based chat system to upload personal icons, and ended up as a GeoCities competitor.

The big thing, I felt, that made us "better", were that we didn't have complicated URLs based on which "community" your page was in, we just had "members.theglobe.com/username/" style URLs. Also, I think our page building tools were better and more flexible. On the downside, I think at our peak, we had about 1-5% of the traffic that GeoCities did (although over a million page views in a day was a big deal back in 1997, on 1997 era hardware). On the upside, in 1997, the only developer working on this project was me, so our development team was cheaper.

But for fun, here's Jon's page. We made ones for toothgnip and diablo too, but they don't seem to be archived.