Talk Funnel

“Fat Elvis or Thin Elvis stamp? Let’s flip a coin. Hey, I know…”

Via Photo Basement

Image: Wikipedia

In the early 1990’s, I got involved with a local arts group called George Coates Performance Works (GCPW). The productions combined opera, theater, music, live projection, videoconferencing, and a lot of new technology — mostly donated by companies like Apple and SGI, but also some lab oddities scavenged around Silicon Valley.

In one of the more popular pieces — Box Conspiracy — an actor stood on stage and used a pen-tablet to interactively control a large ‘all-seeing’ 3-D eye that was projected on the screen behind him. Making this work involved hooking up a prototype pen tablet to a wireless modem that was connected to an SGI workstation back in the control room. The SGI used the pen inputs to drive a custom animation program that generated left-eye/right-eye images in 3D. This was then projected onto the screen behind the actor and the audience (wearing polarized 3-D glasses) got to experience the synthesis of live and generated worlds in real 3-D space.

This was way before pen tablets and way, waaaaay before wireless was ubiquitous. GCPW productions were often a combination of artistry and super-high tech. On any given day, opera singers and actors mingled with 3-D designers from LucasArts and NASA engineers. It was an interesting experience.

From a technical point of view, it all had to be hand-rigged, with custom client, networking, and 3-D rendering software, along with private protocols synchronized across multiple platforms. The effect was pretty cool and the show ended up being pretty popular (less due to the special effects, I think, than its timely lampooning of the ‘5000 interactive TV channels’ meme).

The pen-tablet interface always bothered me a little. The thing we really wanted to do was to use the actor’s body as the input to the software and synchronize the movement with the live 3-D scene projected around him. There were a number of technical challenges. The first was how to establish a person’s body position without hindering their movement.

Once we had that, we would need to figure out where the arms and feet stood relative to the trunk. There were a number of Rube Goldberg devices out there, mostly for gaming and 3DVR applications that involved wearing body-suits or harnesses, with heavy wires tracking behind them (the sort of technology later used to generate the fluid motions of the Gollum in Lord of the Rings). The state-of-the-art in motion tracking back then was the Data Glove. Full-body tracking was a pretty tall order, but it seemed like it was an easier problem than tackling the body’s position.

The first step was to see if we could snip the wires. The wireless modem we used with the pen tablet was a lab prototype donated by a hardware vendor (can’t remember their name, but I don’t think they ever commercialized it). It was pretty lightweight and could be clipped to the waist and it could run for a few hours on a single battery charge. All it did was act like a standard RS-232 serial port (remember those?) so you could use it like a pretty long cable and transmit simple position data. The software at the other end could read it and use it to render the imagery.

But then how to establish the actor’s position and movement?

The solution I ended up pursuing (but ultimately abandoning as unworkable) was to combine a gyroscope with a set of accelerometers and a touch-sensor. The touch sensor could establish a ‘home’ position on the stage while the gyroscope and accelerometer (carried by the actor) could record relative position and motion from that point on. A small computer (the pen-tablet?) could gather the data and transmit it through the modem back to the SGI. The whole contraption could be fitted inside a harness or small backpack.

I tried finding out as much as I could about gyroscopes and accelerometers (this is pre-Google). Not much there. Fortunately, there was a big electronics and embedded system trade conference coming up in San Jose, so I headed down to see what I could find.

The problem that ultimately sank the whole plan was a condition called Gimbal Lock. A gyroscope is made of a rotor spinning inside three inter-locking rings, each connected to another via a tiny pin. Sensors on each ring can calculate relative motion in X/Y/Z (aka pitch, roll, and yaw) coordinates. The problem is with those tiny pins. If you move the whole contraption far enough, the spinning rotor eventually comes pretty close to where the pins sit. If you’re not careful and the ring actually hits the pin, the angular velocity of the rotor will send the whole thing spinning around wildly and everything goes bat-shit crazy.

In airplanes, where this technology was mostly used, gyroscopes were often used as part of an Inertial Navigation System and connected to the auto-pilot. If the plane made a sudden motion and the gyro hit Gimbal Lock, it was considered a Very Bad Thing.

The only way to get around Gimbal Lock was to shut the whole gyro down, wait until it stabilized then spin it back up again — a process that could take several minutes since the gyros often ran at thousands of RPMs. There were some techniques to work around this problem (like using a fourth gimbal) but this was not available in the smaller, low-powered gyroscopes.

At the conference, I remember asking several vendor reps if they could think of a solution (the booth staff in these types of conferences were always heavy-duty PhDs who could actually answer technical questions). They would ask me what the application was. I remember explaining what I was trying to do, fully expecting them to gently scoot me away to make room for the serious customers. Amazingly, they would all get excited — I like to think it reminded them why they got into engineering in the first place.

They’d sit down with pen and paper and try in-earnest to tacke the problem. Product manuals would be consulted. Charts and scientific calculators would be whipped out. But alas, the universal conclusion was that given the state of the technology at that time, there was no way to put together something that was a) cost-effective, b) not susceptible to periodic locking, c) could be carried by a human being (even in a back-pack), or d) all of the above. But they all agreed that it was a very unique application, seeing as how most of their customers bought their hardware for use in spaceships.

After a whole day of this I gave up on the idea and eventually went with the pen-tablet set-up.

What made me reminisce about all this was my tinkering today with the solid-state accelerometer built into the iPhone. It can tell when you’re moving it around all three (X/Y/Z) axes and has pretty good resolution. The iPhone also has built-in WiFi, so two things out of three I needed to solve that problem — all of which would require a backpack and a sturdy back — are built into this little hand-held device.

The only thing missing is a solid-state gyroscope and a wayback machine so I can go back and use it on that stage.

Photo via CNET

Looks like a lot of people are getting the so-called iPhone developer program ‘rejection’ letters from Apple.

John Gruber points out that developers can already write applications with the existing SDK. But there’s a chain-reaction that emanates from this rejection / delay / waitlist letter (which I got too, for the record). See if you’re not in the ‘full’ developer program, you don’t get a signed certificate.

No signed certificate, no way to upload your app to the iPhone via XCode. No way to upload your app, no way to test it if you are using features not supported in the simulator (I won’t list them since the SDK is issued under NDA, but there are more than a few — including a lot of features game developers would need). In other words, the certificate isn’t just so you can upload your creation to the App Store in the June time-frame.

It’s also necessary to start basic development today.

The only reason I can think of for Apple to have done this is to prevent the flood of apps they’re going to receive down the line, all clamoring to be reviewed and approved for sale on the App Store. But doing it in this way means a lot of developers can’t even get going until June (or whenever the SDK gets out of beta) and that puts them in a bad position competitively against those who do get the certificates. Who knows? It may even create a gray-market in certificates (EBay anyone )

If flood-control is really the reason behind Apple’s move, they can still accomplish it at the point of submission of the app for approval — and while they’re at it explain the rules for who can get onto the store, how long the wait might be to get approved, how does an app get onto the ‘featured’ page, etc. But they really ought to go ahead and issue the certificates now so people can start their development work.

I personally went through the certificate signing process with Thawte a couple weeks ago to get one for an Adobe AIR application. It took about a week and cost $299/yr. Thawte already sells signed certificates for Mac-OS (alongside those for Java, Microsoft, Netscape, VBA, and Adobe). There’s no reason why Apple can’t separate ‘app-development’ certificates from ’sell via App Store’ certificates.

At this point, those developers wanting to use non-simulated/phone-only features and who don’t want to wait have no choice but to go the jailbreak/open-source toolchain route (making Jonathan A. Zdziarksi, the author of iPhone Open Application Development the luckiest / unluckiest / luckiest technical author around).

The trouble is that Apple’s released SDK headers are far more restrictive than what jailbreak tools allow, and finished apps may not use any undocumented APIs. For example, people have ported a ridiculous number of app development tools — Python, Ruby, Apache web-server (!) — to run on a jailbroken iPhone. None of these are permitted under the rules of the official SDK — making it a safe bet that jailbreaking will continue apace even after the SDK is launched.

Remember, if you’re a developer and have to get going on a jailbroken system:

1. You don’t get to use all the cool XCode tools.
2. You have to constantly double-check to make sure you don’t use features not officially released in the SDK, and
3. You may want to stand in line to get your finished application into the App Store approval hopper early (if and when Apple releases those signed certificates).

It looks like there may be a long line of developers forming in the back of the App Store pretty soon. But then again, if you’re an iPhone fan, you’re probably used to standing in line…

Update: Ars Technica misses the point of the delayed/AWOL certificates. They’re not just needed for deployment. For many people they’re needed to start development.

Here’s a solution: Adobe AIR allows self-signed certificates. They’re useful to get things going, but can not be used for deployment. This is probably the way to go for Apple. Put out a self-cert tool for everyone and get out of the way. Then put up BIG warning signs in the 2.0 firmware whenever someone tries to run a self-signed application. That ought to get things going.

Yesterday, I speculated as to how Apple might try to manage the flow of iPhone apps wanting to make their way onto the App Store.

Seems like one way to do it is to throttle it at the inlet.

Yeah, that’ll keep the developers enthused.

Mike Cane raises a number of good questions about the impending rollout of iPhone/iTouch apps.

My personal belief is that initially there will be a lot of overlapping productivity apps across the board: ‘to-do’ list managers, note-taking apps, etc. as well as a flood of games, all vying for attention. It’ll be like the grand opening of an FAO Schwartz, where the glitter and noise will overwhelm the senses.

It’ll take a while for consumers to digest what’s out there — and my guess is there will be no clear early winners. To help pave the way, look for a spate of early vaporware announcements by companies trying to mark off the territory and grab early mindshare.

There will be early leaks to media, lots of photoshopped screenshots, and ever-escalating grand promises. But that will also bring out a whole slew of copycat pre-announcements by others not wanting to give up the fight too soon. We’re already starting to see that in the gaming market — with early “we intend to develop games for the iPhone” press releases by Gameloft, Namco, PopCap, THQ, Freeverse, Harmonix, and of course, EA (with Spore) and Sega (with Monkey Ball).

What’s strange about this market is that the ecosystem around a consumer device usually starts small, since there aren’t that many units out there. Then as word spreads and applications mature, platform sales move beyond the early adopters and a whole information infrastructure falls into place to help people find and support apps, which brings in a larger mainstream audience, and the upward cycle continues.

With the iPhone, the early adopters were all lined up the day of the release outside the stores. We’re now into the larger mass-adoption curve — with an estimated 10 million iPhones/iPods out there by the June AppStore launch. Yet none of the customary information pipelines of magazines, blogs, TV shows, and review sites are in place yet. Yes it’s early, but watch for pre-emptive announcements of iPhone-related magazines and buyer’s guides in the next few weeks.

My guess is that as the launch date grows near the volume will go up as well. Developers will pre-announce their product offerings hoping to start gathering mind-share and building up excitement even before the App Store launches. But they can’t do it too soon, since that would allow competitors to pre-empt the pre-announcement with their own PR-ware.

Developers have been questioning the need for the $100 million iFund. You can bet some of that money is going to find its way into the pockets of media in the form of early advertising for software and brand-building. All this for software that can’t be bought yet. Under normal circumstances, all this would be yawn inducing. But hey, this is the ecosystem that will form around a company that pre-announced the phone itself by nearly half a year (and the app store by three months). You’ll be laughed out of town if you wait until there’s actually something ready to ship.

Once the store launches, it’ll be pretty chaotic for a while. Apple is going to have to come up with some sort of policy to decide which apps are going to get featured on the iTunes front page. Will they take advertising from developers? Will it be based on user-reviews? An editorial staff? They are going to be in a uniquely powerful position here. A front-page token announcement and you’re practically annointed in Myrrh.

Much of this will depend, as Mike points out, on Apple clearing out the backlog of ‘approved’ applications and issuing those certificates (a topic that already has some people in the developer community worried).

Another question will be that of pricing. Jens Alfke has floated the idea of $0.99 applications (to mimic the iTunes music sales). It’s customary on the desktop to have a ‘try before you buy’ period. Since Apple is going to be in charge of distribution and licensing, they’re going to have to be the ones providing the infrastructure for timed trials.

The thing is, they never implemented it with iPod games, choosing to keep the game prices in the sub-$5 casual gaming level and they haven’t announced anything of the sort for the iPhone App Store. Maybe they will by June, but if not, you may end up with a flood of users entering the App Store, browsing around confused and not knowing what’s worthwhile to buy, not knowing where to turn for advice, then taking a look at the ‘take it or leave it’ price tags, and walking out to wait yet again for the early adopters to take the first plunge.

As a small developer hoping to have a small part in this ecosystem, I hope it doesn’t happen. It’s still early and the traffic jam can be averted.

SmileyChris had a post up recently on setting up bash aliases for Django. He uses the classic alias command which works for one-line shortcuts. I got inspired to put mine up too, but if you want to do something more elaborate, bash gives you this handy scripting language along with ’shell commands’ so you can do something a bit more involved.

What I tried to do with these shortcuts was to create a set of mini-commands that quickly do what you need to do when developing Django. It might help someone out and squeeze an extra 2-3.5 microseconds each time you run a Django command. Hey, it all adds up.

In my case, I keep the directory for all my Django projects in a single ’source’ directory so I can quickly jump in and out of them. The shell commands makes that assumption too. If your projects are all over the place, you’ll have to tweak things — but I’d suggest doing some housekeeping and moving everything to a common directory to help keep things neat and tidy.

To use these, copy the lines to the bottom of your ~/.bashrc or ~/.bash_profile. If you don’t see one of these in your home directory, remember that most *nix shells ignore files starting with a ‘.’ (period) so you’ll want to do something like:

% ls -al

To see all your files in the current directory. If you really don’t have one, then create a .bash_profile and put the following lines inside. You’ll want to customize the first four environment variables to point them to directories in your system. The ones there are samples, but once you set it up once, you’ll never have to worry about it again.

A minor caveat: These have been tested on a Mac OS-X Leopard. YM-will-most-likely-V. On with the code.



# Django shortcuts

# CHANGE: to directory where you installed Django sources.
DJANGOROOT=/dev/djangoproject
export DJANGOROOT

# CHANGE: to admin bin scripts directory under Django.
# This should work for the svn version.
DJANGOBIN=$DJANGOROOT/django/bin
export DJANGOBIN
PATH=$PATH:$DJANGOBIN:
export PATH

# CHANGE: to TCP port for testing.
# You go to http://localhost:8008 to hit the test sever.
DJANGOTESTPORT=8008
export DJANGOTESTPORT

# CHANGE: to base directory where you keep your Django projects.
DJANGOPROJECTBASE=~/Work/django
export DJANGOPROJCTBASE

# ---------------- Django shell commands ------------------

function django() {
  echo "dadmin - Basic django-admin"
  echo "dproj  - set up (show) default django project"
  echo "dsrc   - jump to Django projects home directory"
  echo "dls    - list current projects in Django projects home directory"
  echo "dcd    - jump to current project directory"
  echo "dstart - start a new project in the home directory"
  echo "dapp   - create a new application under the current project"
  echo "dsync  - Run syncdb and synchronize model with DBMS"
  echo "drun   - run current project in test server"
}

function dsrc() {
  cd $DJANGOPROJECTBASE;
}

function dls() {
  ls $DJANGOPROJECTBASE;
}

function dadmin() {
  python django-admin.py $*;
}

function dstart() {
  src;
  python django-admin.py startproject $*;
}

function dproj() {
  if [ $# -eq 0 ]
  then
    if [ $DJANGOCURRENTPROJECT ]
    then
      echo "Current project is: $DJANGOCURRENTPROJECT";
    else
      echo "Run 'dproj ' first";
    fi
  else
    if [ -d $DJANGOPROJECTBASE/$1 ]
    then
      DJANGOCURRENTPROJECT=$1;
      export DJANGOCURRENTPROJECT;
      DJANGO_SETTINGS_MODULE="$DJANGOPROJECTBASE/$DJANGOCURRENTPROJECT";
      export DJANGO_SETTINGS_MODULE;
      echo "Current project set to: $1";
    else
      echo "Project directory '$1' doesn't exist."
    fi
  fi
}

function dcheck() {
  if [ $DJANGOCURRENTPROJECT ]
  then
    cd $DJANGO_SETTINGS_MODULE;
    return 0;
  else
    echo "Run 'dproj ' first";
    return 1;
  fi
}

function dapp() {
  if [ dcheck ]
  then
    python manage.py startapp $*;
  fi
}

function dcd() {
  dcheck;
}

function dsync() {
  if [ dcheck ]
  then
    python manage.py syncdb;
  fi
}

function drun() {
  if [ dcheck ]
  then
    python manage.py runserver $DJANGOTESTPORT$*;
  fi
}

To get a reminder of how it all works, just type

% django

To see a list of current projects, use:

% dls

To start a new Django project, just go:

% dstart projectname

To set the current active project:

% dproj projectname

This checks to make sure the project exists under the base project directory. To quickly jump to the current project directory, you use:

% dcd

To create a new application under the current project use:

% dapp appname

Then you add the appname to your project’s settings.py file and you’re good to go. Once you’ve defined your model, run this to sync up the database and the model:

% dsync

And every time you want to run the test server for the current project, just run:

% drun

And assuming you didn’t change the DJANGOTESTPORT variable above, in the browser you go to:

http://localhost:8008/

or if localhost isn’t defined in your /etc/hosts file, you can also use:

http://127.0.0.1:8008

Under Windows, the easiest way to run this is to install Cygwin and then run bash from there.

Good luck.