"I have had to learn the simplest things last, which made for difficulties."
—Charles, Olson, "Maximus, to Himself"

i saw that quote at second read the other day, and it reminded me of what is probably the primary problem with being self-taught at a discipline. personally, lately, i've wished that i had more exposure to classic computer science coursework. teaching myself programming is fun and rewarding, but sometimes i spend entirely too much time banging my head against the wall solving a problem that has either already been solved by someone whose code i could reuse, or, worse, going at the problem in entirely the wrong way and kludging up the solution something fierce. how can i avoid this?

when teaching oneself something it is all too tempting to jump in with both feet and, throwing caution to the wind, experiment wildly until it works. while it may "work", one should then ask oneself: "does it work well?", "does it fully accomplish what it should?", "does it have any unintended side-effects?", and "could it be done in such a way as to make it better?" ('better' as used here could mean faster, more usable, more understandable, more sustainable, etc.)

tempting as it might be to use new skills to tackle one's most pressing pet project, it is more prudent to start small. do something useful and do it well; don't get too greedy at the start. when done correctly, small projects can be reused in larger endeavors: either by applying one's now-honed skills, or by incorporating old work into newer work.

in closing, i present two odes to simplification from the band The White Stripes:

( Little Room )

( Little Acorns )

i made some observations using amstracker and excel. i'm still trying to figure out if AMS is directly reporting acceleration, or if some processing is done on the numbers before they are reported. any thoughts on this if you have experience with this, or insight from the data in the spreadsheet?

when i take the mean z reading from the AMS while the powerbook is at rest, i get 49. i realized that that should be due to the force of gravity. when i divide 49 by 9.8 (the force of gravity in meters/second^2) i get 5. so, it seems, for the z axis (and possibly the x and y axes as well), i can get the acceleration in meters/second^2 by dividing by 5. i might be able to do something useful with this!

ideas so far:

• a widget that shows what direction is up (for when the user is very drunk).
  
• a widget that shows airline cockpit gauges for pitch, roll, and possibly rate of descent.
  
• an etch-a-sketch widget where you tilt to draw, and shake the laptop to erase (like a real etch-a-sketch)—tilt-a-sketch?
  
• a superball widget, that does nothing except accurately move a bouncy ball around your screen according to the laws of physics.
  
• finally, possibly a useful one: a dead-reckoning navigator that overlays the user's position on google maps given a known starting location.

( never shake a duck )

for anyone with access to an atari 8-bit computer (or emulator):

A POKE CHEER

Here's something you probably didn't know was tucked away inside your Atari.

10 S=53760:POKE S,230:POKE S+1,175:POKE S+2,231:POKE S+3,175:POKE S+4,229:POKE S+15,3
20 FOR X=0 TO 255.49 STEP 0.135:POKE S+8,X:NEXT X:GOTO 20

Lloyd Burchili
Newcastle,
New Brunswick
Canada

from antic magazine, volume 4, number 8, december 1985

try it, it's fun. i remember being impressed back then, and i'm still impressed by this bit of silliness.

EDIT: for those lacking a real atari 8-bit or emulator (thanks to jerronimo:
check out an mp3 i encoded. it loops like that until the program is killed. the click-click-click-click at the start is me typing "run" after i started the recording. the extended wave at the end is because sound output locks up in Atari800X on the mac when the menubar is accessed. the output seems occasionally choppy because it was real-time sound synthesis done in BASIC, on a motorola 6502 running at 1.79 MHz. it's not just the emulator, it sounded choppy on the real thing too. good demo, eh?