Songbird is an iTunes-style music player that contains an integrated web browser. Songbird detects rich media on pages you visit and integrates them into itself in a number of ways: making them navigable through a "web playlist" reflecting the current page, remembering them in a "web media history" that you can browse and search, and, finally, providing a bridge between the music player and the web browser itself that allows web pages to interact with the playing song and the user's music library.

Why does Songbird matter?

Songbird is to iTunes what Firefox is to Internet Explorer: it provides an open source alternative to an application built as part of a vendor's extremely successful lock-in strategy. And, following in Firefox's footsteps, Songbird aims to introduce a raft of technical innovations into a stagnant space.

The bird. Shown here in a rare non-farting moment.

While iTunes (and especially the iTunes store) revolutionized the music industry on first release, its rate of innovation is restricted by Apple's ability to imagine and implement new features and, even more tightly, by the constricting legal ties the company has woven with the media conglomerates that provide its content. Songbird, on the other hand, is trying to offer an open platform for anyone to build their own innovative applications or competing business models. If they succeed, these lowered boundaries to participation will mean that Songbird's feature count and available content options will zoom past iTunes', inevitably bringing along an ever-growing number of users and, eventually, breaking Apple's monopoly and forcing them to scramble to compete — just as Firefox has done with Internet Explorer.

What can I do with it?

So, in what ways is Songbird open? What can you do with it as a developer? Well, just like Firefox, Songbird is open in a number of ways. First, the code for the player itself is available for download and licensed under the GPL. This means you can modify it, use it in your own applications, print it on your school binder, whatever you want. Secondly, Songbird has a plug-in architecture against which you can develop. The Songbird team calls applications written on this architecture Add-ons and they have access to everything from the player's appearance (for building skins) to the actual data and UI of the application. Finally, and most importantly for us here, Songbird provides web pages with a javascript API that allows them access to the app's sophisticated playback interface and, with their permission, the user's media library and custom playlists. Since this last is by far the easiest to get started with, I'll spend the rest of this post focusing specifically on it.

Setting up a Songbird Javascript Development Environment

One of the hardest parts of starting development in any new environment is getting all the pieces in place to successfully write and run your first line of code. This is especially true in complex runtime environments like javascript hosted in a web page running against APIs in a rapidly developing client. Here are the steps I followed to get there:

• Download a nightly build. At the time of this writing, 0.6 was the latest hotness, but things are moving rapidly.


• Get Firebug lite. Like most Javascript developers, I've become increasingly dependent on Firebug since its introduction. Being able to test out code in its interactive shell and navigate the resulting objects is priceless. Heck, even just being able to log information to the console rather than having to dismiss an endless parade of alert statements is worth the price of admission alone. Unfortunately, because of Songbird's rapid pace of development, there isn't currently a version of Firebug that is compatible with 0.6 (if you come from the future, visit Firebug's page on the Songbird add-on site to see if things have changed). Thankfully, there's another version of Firebug that can reside in the DOM of any given page. It doesn't have all the niceties we'd want (like object navigation) and it's access to the Songbird-specific javascript APIs we'll be spending our time with can be a bit...err...intermittent, but at least it provides a console for logging and some ability to inspect our objects. Once you've downloaded firebug, stick the directory somewhere in your project and create an HTML file with the following in the head tag: <script language="javascript" type="text/javascript" src="/path/to/firebug/firebug.js"></script> You should also set the debug attribute in your opening html tag to "true". Now, when you open your page in Songbird, it'll have a mini version of Firebug running at the bottom of its window. You can log to it and interact with objects (though limits and quirks will abound).

Songbird's Model of the World

Songbird's viewer window explained (full-size version).

The purpose of the Songbird webpage API is to provide the javascript running on a particular page with access to the media-player side of the application. Through it your page can track changes in the currently playing song, manage the "web playlist" (a small iTunes-style song browser that shows up underneath the current web page), and access song listings and metadata for the user's local music library, including reading and creating local playlists — you can even download songs directly to the user's computer. Pretty much the only thing you can't do is delete files.

Songbird presents three main abstractions for working with this functionality: Libraries, Media Lists, and Media Items. Let's start at the bottom with Media Items and work our way up.

Media Items == Songs

A Media Item is a single song or video in your Songbird library (at this point, I'm just speculating about the video part, though the generic name is certainly tantalizing and I know that Songbird does have some form of video support; however, I've only worked with songs, and from here on I'll assume that a Media Item is really a song). Media Items provide access to a raft of metadata such as "trackName", "artistName", "duration", etc. See the full list of Media Item properties for everything that Songbird makes available. You can read these attributes and set them. Interestingly, metadata properties are namespaced so you can create your own solely for use by your application, or even attempt to get a community of developers to standardize around new attributes for a particular domain.

One important thing about Media Items is that they don't necessarily have to correspond to a song with a locally available media file. Just as your iTunes library can contain songs whose actual mp3 files are elsewhere (like on an external backup drive), Media Items can be associated with files that are not currently available or with no file at all. Unlike iTunes, Media Items in Songbird can also be associated URLs that point at online mp3s.

Media Lists == Playlists

The next step up the ladder is Media Lists. These, as you might expect, are collections of Media Items, i.e. playlists. They have a name which is a handle for finding them (and also what shows up in the app's sidebar if you add them to the Main Library). You can find out which Media Items belong to a Media List and you can add and remove them. Media Lists are ordered stacks, so there's some functionality for managing the position, uniqueness, and suchlike of individual Media Items and for iterating through the full set.

Libraries

At the top of this whole shebang are Libraries. Libraries represent the permissions and interaction scope associated with a Media List or group of Media Lists, i.e. in which part of the application they'll be visible and which chunks of code will have access to them. There are three types of Libraries in Songbird — the Main Library, the Web Library, and the Site Library — and one other entity (the "Web Playlist" mentioned above) that sits in the same spot as a Library and behaves almost exactly like a Library, but isn't technically a Library. Things will get clearer quickly if we talk about the purpose of each type of Library, so let's dive right into that.

Libraries: the Main Library

First up, we've got the Main Library. The Main Library contains all the Media Items on the user's computer. Remember, since Songbird can provision audio for Media Items from public URLs and can include local Media Items for which the file is not currently available (the Missing Backup Drive scenario), this is not limited to files actually "physically" present. Reasons to talk to the Main Library include: wanting to create a new playlist on the user's computer that will be available after they browse away from your site, wanting to see what songs the user already has in order to make content recommendations, getting a list of all the local playlists a user has created and what songs are in them, etc. By default websites are blocked from accessing the Main Library at all unless the user has changed their "Web Integration" preferences to allow general access or to allow it for your website in particular. If you attempt to access the Main Library of a user who has limited access to their Main Library, Songbird will prompt them to permit or deny the action; the javascript API includes callbacks to make your code aware of the user's response to this prompt.

Libraries: the Web Library

Next up, we've got the Web Library. The Web Library contains all the Media Items Songbird has extracted from the webpages the user has visited. When you navigate to a URL that contains links to music files, Songbird discovers these links and gives you an iTunes style playlist representation of them at the bottom of your window (the Web Playlist). The Web Library is everything that's ever shown up in this playlist. It's every song from every webpage the user has ever visited within Songbird. This list of songs is made available to the user as the "Web Media History" and is an incredibly useful feature — if you spend any significant amount of time reading mp3 blogs or browsing band sites your Web Library will rapidly become populated with most of the music you've ever heard about, even in passing. This makes it an extremely rich collection to search against and idly browse. I can only imagine all the cool apps you could build if you had access to the entire mp3 blog browsing history of your users...obviously recommendations (for both music and blogs) come to mind, but you could probably also build some kind of very kick ass client-resident distributed spidering operation, or something else extremely neat that I can't think of off the top of my head. As you'd expect, the Web Library is under exactly the same access restrictions as the Main Library.

Libraries: the Web Playlist

Now we start to move into the Libraries that belong more to our individual websites than to the users themselves and over which we therefore have more control. The first and most visible of these is the Web Playlist. In the normal course of events (i.e. while browsing sites that aren't cool enough to use the Songbird API), the Web Player simply reflects any mp3s or other media files Songbird happened to find on the page. However, with the API we can control just about every aspect of the Web Playlist from the tracks that populate it to what pieces of data show up in each of its columns. I mentioned above that the Web Playist is not, strictly speaking, a Library. This means that it doesn't offer quite the same API as other Libraries — it only contains a single Media List; it doesn't have its own access controls separated from those of the Media List assigned to it; etc. — however, I include it in this list because, in the javascript, it lives at the root of the 'songbird' namespace as a sibling to the other Libraries and it offers an API that is largely (though not entirely) parallel to the others.

Libraries: Site Libraries

Lastly, we come to Site Libraries. Unlike the other Libraries we've covered so far, Site Libraries don't directly control the display of tracks to the user. Instead, they are simply an application-specific namespace for storing Media Lists. In other words, they let your javascript build Media Lists that are available only to users visiting particular pages on your domain (controlled via a scoping mechanism much like the traditional robots.txt syntax). Once you've got a Media List safely inside your own private Site Library, you can then display it in a Web Playlist, save it to the user's Main Library, or simply keep it invisible and use it to swap out the currently playing song. In fact, if you don't actually use a Site Library to manipulate any part of Songbird's UI (for example if they're just a convenient way to store your app's internal data), you don't even need the user's permission to create them. Site Libraries are a little harder to grok than the other varieties since they lack visible representation, but you'll quickly get used to working with them as they're the main place you'll be storing all the Media Lists you build. If you're still confused as you come away from this paragraph, you can just think of Site Libraries as a private place to store the Media Lists you compose without having to display them to the user in any way.

Some code samples

Let's make this whirlwind conceptual tour more concrete by looking at some examples. I'll show you the code to accomplish some basic tasks and then explain it in terms of the concepts I've outlined above.

Putting songs in the Web Playlist

I cribbed this example from the Songbird wiki. It simply creates a media item from an mp3 URL, assigns the item to a media list that is scoped to the domain of the current page, and tells songbird to display the media list in the web playlist. The song won't actually appear anywhere visible to the user until the last line of code in this sample. Once the web playlist receives the media item, it'll scan the URL for metadata and fill in the track display based on what it finds.

Set a property on a media item

If you set a property before adding the media item to a list and displaying it, Songbird will trust your metadata assignment and not override it based on the results it finds on the attached mp3. There are parallel methods for getting the values of any already set properties. You can set properties on media lists in the same way.

Download a media items' file to the user's computer

In addition to providing access to the various libraries, the songbird object allows you to do a whole raft of useful things such as download an mp3 from the web into a local media item (as shown here), getting access to information about the currently playing track, controlling which track is playing, etc.

Get all the local playlists

This code asks the main library for a list of its playlists. When that first line of code runs, requesting access to the main library for the first time, Songbird will prompt the user for permission. In order to iterate through the results of getPlaylists, we have to call the special enumeration helper, hasMorePlaylists. This is a common pattern with collections of Songbird objects, there's often custom enumeration code that be somewhat counter-intuitive compared to standard array iteration.

Additional Resources

These examples only scratch the surface of what you can do with songbird. For more examples and more documentation, visit the Songbird webpage-api docs and the Songbird wiki entry on Webpage API integration.

The Songbird team hangs out at #songbird on irc.mozilla.org. They are quite friendly and open to helping out if you're confused or run into issues. I'd also like to thank them specifically for answering my large raft of questions as I was learning this API. This guide wouldn't have been possible without them.

An intro to routing and controllers.

I wrote recently about getting started with Merb. Yesterday, after having refer to my own post to remember how it all worked, I started on a new Merb app as part of the Great Grabb.it Rewrite of 2008. I very quickly ran into another area of Merb that's a bit thin on documentation: Controllers. After some googling, some fiddling, and some brainstorming in the #merb irc channel I managed to figure out enough of the basics to get things up and running.

Right now, Merb's sweet spot seems to be as an API server, which is exactly how we're planning on using it. This usage means that while there might be a little bit of model integration for access control, most of the job is in routing URLs and data formatting. That means we'll be spending most of our effort in config/router.rb and in our controllers. Specifically, we'll need to know a lot about how Merb provides responses in various formats depending on the request url, i.e. it's equivalent to Rails' respond_to method. Let's start by laying out our requirements and then I'll show you how I translated them into Merbish.

For this app, I needed to take URLs within a namespace and route them to a single controller setting various params based on the rest of the request path. In other words, I wanted to provide URLs like: http://myapp.com/music/artist.jspf and http://myapp.com/music/artist/title.mp3 where the first url would give you a playlist of all of an artist's tracks in JSPF (Javascript Shareable Playlist Format) and the second would provide an mp3 of the song with the given title by the given artist.

So, the first thing I needed was a series of routes that would recognize all URLS starting with /music and then grab the path after the first slash into an :artist param and the path after the second slash into a :title param. Finally, it would need to look for a format after the dot and pass that through as well if available.

It turns out the best way to do this in Merb is with nested routes, thusly (inside of the Merb::Router.prepare block in config/router.rb): r.match('/music') do |music| music.match("/:artist.:format").to(:controller => 'music', :action => 'artist') music.match("/:artist/:title.:format").to(:controller => 'music', :action => 'track') end

This is pretty self explanatory if you're familiar with Rails routes, though it is probably worth noting that an early version of this I tried which eschewed the nesting in favor of including the /music part of the path in each route separately seemed to have problems detecting the format correctly (though it is more than likely the cause was driver error on my part rather than anything that Merb might do differently in that situation). There's pretty thorough documentation on Merb routing if you need more specific help and that's definitely not the case for the Controller APIs, so let's tackle those right away.

Now, how do we consume those URLs in our application? We need a controller, thusly: class Music < Application provides :jspf def track display Track.new params[:artist], params[:title] end def artist display Artist.new params[:artist] end end There's two main things going on here that distinguish Merb's controllers from Rails': the 'provides' class method and the 'display' method we're calling in each action. These two methods work together to let us return our data in the right format on every request. And, while they might look confusingly different from the familiar Rails respond_to block at first, they turn out to make things much cleaner, eliminating the need to redeclare common formats over and over in each controller method.

So, here's how it works: provides sets up a list of formats that we're willing to consume and then display makes sure that we provide the right one for each request. When a request comes in ending in .jspf, display calls to_jspf on the object that gets passed to it (in this case new tracks and artists). If we wanted to provide javascript, xml, html, etc. we'd just add those symbols to provides' arguments and then make sure the objects we passed to display could respond to to_xml, to_html, to_etc with the right data (there's an additional option for html of using a template in the views directory that Merb can automatically detect; that case works just like Rails; also: html seems always to be installed as a format regardless of whether or not you pass :html to provides).

While this should be enough to get you up and running writing Merb controllers, there are a few other details worth noting. First of all, if you want to provide alternative formats besides, js, html, xml, and the usual suspects (like we do here with jspf), you'll need to register a mime-type. We configured that by adding a single line to config/init.rb: Merb.add_mime_type(:jspf, :to_jspf, %w[application/application/jspf+json]) There's lots of other additional information about the request available to your controller actions as well, such as content_type. Secondly there's other options besides display for returning content from your action. Calling "render" will attempt to automatically detect a template with the right format in the appropriate views directory. And you can always just render a raw string. Again, more details are available here.

There's the beginnings of a great open source book being written by some folks on GitHub: Life On The Edge With Merb, DataMapper & RSpec.They've done a pretty solid job covering the basics of app initialization, modeling with the DataMapper ORM, and testing with RSpec so far, but their section on Controllers is blank so far. If someone wants to pick up the thin thread I've laid down here and run with it, that would be a great place for more documentation to accumulate.

A few months back Chad Fowler asked me to coordinate the lightning talks for this year's RailsConf. It turned out to be a rolicking good time! We had 36 speakers in three sessions over three days — more than half the number of official talks! Topics ranged from announcements of new plugins (man, there are a lot of these suckers out there!) to demos of cool sites (Shared Copy certainly blew some minds) to rants and harangues (Ryan Davis never disappoints in this regard).

Below, I've attempted to summarize each of the talks and provide appropriate links where I could find them. The results are based on my sketchy notes while keeping time (and preparing my own talk) and so are definitely less than definitive. If you spoke and I got some of your details wrong, drop me a comment and I'll make corrections. If any speakers want to send me links to their slides, I can add those as well.

Thanks to everyone who participated — audience and speakers alike — and thanks to the RailsConf orgnaizers for letting me put this together.

Friday

• Jon Garrin - Gatekepeer Plugin
• Max Baumann - Varnish as a Page Caching Alternative
• Prabode Weebadde - Paging: Pro-Paging
• Four Hewes - "Designers: Will you respect me in the morning?"
• Scott Chacon - Git + Lighthouse
• Chew Choon Keat - Shared Copy
• Luke Francl - Fan Chatter Stadium
• Gleb Arshinov - Keyboard Shortcuts for the web
• Ryan Davis - Write less code

Saturday

• Max Warnock - RDF framework
• Josh Goebel - Pastie
• Greg Borenstein - RAD: Ruby Arduino Development
• Matt Conway - Rubber for managing EC2 with Capistrano
• David Lowenfels - Scrum Ninja
• Jeremy Seitz/Mike Hill - geo search w/sphinx (PrimoSpot.com: find parking spots in NY)
• Rich Cavanaugh - acts_as_reasonable
• Ryan Jarvinen - Earfl: Voice Flickr
• Brian Chamberlin - RailsBrain ajax docs
• Eric Mill - ohnomymoney.com: Wesabe integration
• Matthew Deiters - Content Management DSL, DSL Engine

Sunday

• Dan Chak - Active Resource Kool-Aid
• David James - Method Trails
• Michael Slater - buildingwebapps.com
• Noel Rappin - iPhone on Rails
• Robert Thau - Permissioning in ActiveRecord
• Loren Johnson - Resful Workflow Plugin
• David Woodward - REST with Rails and ejabberd
• Jon Dahl - How Not to Present at RailsConf
• Brian Durand - Performance Plugins
• Jacob Dunphy - KABLAME!! (check a git or svn repo to find out who didn't write tests)
• Ben Mabey - RSpec Story TM Bundle
• Chad Wooley - Geminstaller
• Aaron Campos - Automator
• Joannou Ng - NSTableViewFTW
• Mark Anderson - Jive Pages Plugin

In the most recent On the Beat, Celia Hirschman advocates for the Musician's Union to take a more active stand for musicians' rights online. In a world where only 42% of internet users say they pay for music, she argues, the Union has a responsibility to advocate for musicians' "right to be paid for their efforts anytime their music is played". She notes the failure of legislative attempts to extract revenue for musicians from peer-to-peer file sharing, mp3 blogs, and CD burning and lays the blame at the feet of the Union as the primary organization that represents musicians.

I agree with half of this argument. The Musician's Union has been embarrassingly lax in fighting the real battles that matter for artists in the modern music distribution landscape. What has the Musician's Union done to stop the labels from cheating artists out of revenue from iTunes downloads? How about to stop them wasting their shrinking budgets on glamorous perks and inflated short-run corporate profits rather than developing new artists with the possibility of long and successful careers? Or what about to force them to hire people who can figure out new business models that fit the new technology?

None of these battles receive the slightest mention in Hirscman's critique of the Union. She ignores the losses artists have suffered by being forced into vastly inequitable relationships with labels and instead highlights the ways in which the industry has failed to fully extract revenue from new forms of music consumption and fandom.

This wrong-headed focus on enforcement over transformation is symptomatic of the problems plaguing the record industry as a whole. Hirschman's catalogue of Union failings closely resembles a punchlist of RIAA complaints and talking points. Focusing on missed revenue from new forms of fandom while the music industry's entire distribution and profit model sinks into irrelevance is like getting upset over a spilled glass of champagne on the deck of the Titanic.

This mistake derives directly from the principle that Hirschman articulates in the piece: that artists "have the right to be paid for their efforts anytime their music is played." This same idea was proposed recently by Peter Kirn at Create Digital Music:

Recorded music has value to consumers. And, in business, if something has value somewhere, it's a business.

This is a core principle of the industry's thinking right now and it is obviously, palpably false. In middle school, when a friend played me Sebadoh off of a walkman that he'd smuggled to school, transforming me in a single moment into a lifelong fan of indie rock, was that "theft"? Should Sebadoh have gotten paid? When I worked at a local patisserie I used to play my favorite CDs throughout my shifts and would often write the band names and album titles down for intrigued customers. Should the shop have had to track and regulate everything we played so they could pay royalties to the artists?

This last is something of a trick question since enforcement of this kind of public performance royalty is something for which Hirschman specifically lauds rights-enforcers like ASCAP:

If you walk into a restaurant, nightclub or boutique and hear music playing, chances are very good a performance-rights organization have demanded compensation. These rights societies literally go door-to-door to insure their members get paid for music

Hirschman could not have this issue more wrong. ASCAP contacted the patisserie while I worked there saying they'd observed us playing music controlled by their members and we had to either cut it out, sign up for a very expensive pay service they were offering, or face a lawsuit. The business owners felt like they'd been shaken down by the mafia. Their response was to stop playing ASCAP music altogether and instead to put together a library of local music which we had explicit permission from the artists to play without royalties. Maintaining this library was a lot of work and we rapidly fell back into the old system of playing whatever we wanted, including ASCAP music, without permission, but now in an environment of greater fear and resentment. I would bet that a similar story holds for most places you actually visit beyond corporate chains: if you walk in and hear good music playing it is either local or in explicit defiance of an ASCAP threat.

And this story is a parable of what's wrong with focusing on enforcement. Enforcement alienates consumers and tastemakers. It tarnishes the reputations of artists and the organizations that should represent them. It forces natural music consumption and sharing patterns underground. Possibly worst, enforcement distracts artists and the industry itself from solving the huge existential issues that they face.

There is one piece of information from Hirschman's piece, however, that does hold out hope for the music industry if they do ever overcome these distractions and decide to face the real challenge of transformation: 42% of internet users pay for music. That's an enormous number. How many internet users pay for news? Or search? Or social networks? I don't hear anyone in these businesses complaining that their industry is in decline. That's an enormous number and it reflects the incredible amount of passion that exists for music online. If the industry can't find a way to transform that passion into a functional profitable business, it won't be because because the users outfoxed their enforcements efforts. They'll have only themselves to blame.

This release also includes a patch to fix a problem with type-compatibility between RAD's var system and some Arduino function return values courtesy of David Michael. David also gave what looks like a great talk about RAD at NYC.rb: Ruby Meets Worlds, which includes a really nice example of using the observer pattern to communicate with an Arduino over a serial port that portends really well for one of the exciting things we've been talking about on the RAD Google Group: an interactive serial console.

"The enemy isn't Microsoft. The enemy is non-use"

For the past month, watching Hillary Clinton and Barack Obama — two relatively noble politicians who largely want the same good things for this country — say and do silly things to each other over the most superficial of disagreements in an atmosphere of ever-increasing animosity, I've been experiencing a disgust that was strangely familiar. All month I struggled to place where I'd felt this particular variety of nausea before, what other phenomenon oozes this same poison. And then I figured it out: it's the old Open Source vs. Evil Corporation flamewar. It's Slashdot all over again.

I won't alienate 40.4 percent of you by telling you which side I think is which since the key point is this: when two groups with basically the same objectives spend their best energy beating on each other those objectives are guaranteed to stay largely unaccomplished.

And just like every day that Obama and Clinton spend attacking each other leaves less hope for those good goals the two candidates share, every flamewar, every easy attack on Microsoft, every knee jerk reaction against a company that charges for its software leaves less attention available to solve the problems we all share of data interoperability, scaling, user friendliness, etc.

It's a fine thing to stand up for important values like openness and freedom, and, gosh knows, we have real disagreements on some topics that deserve to be debated vigorously, but the constant mutual harassment and posturing actually make these debates harder to resolve.

Both sides are guilty of this and we pay a measurable cost for it.

On the Open Source side, we tend to rule out technologies that reek of big corporate support even when they might be the best choice for the job and on the corporate side they tend to be too cautious, holding off on new ideas until they're blessed by the vendor of choice.

For example, I recently had a good old fashioned geek out with Rory Blyth, a college friend who went on to work at Microsoft. We spent a few hours having two of the oldest, least productive, and most fun coding conversations around: static vs. dynamic typing and SOAP vs. REST, as well as one new one that's shaping up to acquire a similar status: relational vs. document databases. While we seem to have an unbridgeable spiritual divide on the first topic, we each managed to convince each other, at least a little bit, on the last two. Rory did a strong job arguing in favor of the value of SOAP APIs for client implementors because of the strong level of automation and framework/IDE support that they enable and convincing me that at least some of my RESTful bias is inherited unquestioned from my community. Likewise, I managed to overcome Rory's profound SQL Server loyalty to convince him that relational databases, which were designed to perform original relational algebra in order to resolve a query with an unknown answer, are a bad architectural fit for most web applications which simply use them for object persistence. He left eager to check out CouchDB and I left resolved to explore Ruby's SOAP options.

This is exactly the kind of outcome that gets crowded out of most online discourse by the flamewars and name calling. The animosity and ugliness pushes us deeper into our own camps, just as moderate politicians tend to head to the extremes of their own party during a hard fought primary.

Well, the primary's over. I hereby declare it to be the general election. There's a world out there with real problems. From global warming to the growing international food crisis to the war on free speech, the world faces serious challenges that can only be overcome by radically great technology, the license it's released under be damned.

• added first significant documentation
• fixed require 'yaml' bug in makefile.rb
• added examples directory to the website
• applied Brian Riley's SWSerLCDpa patch
• experimental libraries system in vendor/libraries
• enhancements to the rad command: can set project config.

I setup a Ruby Arduino Development Google Group for discussion amongst the growing group of contributors and users of the project. We've already got some fun stuff brewing there including someone working on a serial console, so drop by if you've got questions or want to participate.

Also, big thanks to Brian Riley of Really Bare Bones Arduino supplier Wulfden.org. His patch here for SWSerLCDpa support hopefully marks the start of a great collaboration to get a bunch of important Arduino libraries ported to RAD including OneWire and I2C. Plus, he sent me a totally awesome data logging kit to play with!

Last, but definitely not least, I presented about RAD at Dorkbotpdx 0x01 last week. I was fortunate enough to be in the good company of Ward Cunningham (who gave an amazing talk about his biologically-inspired Cybords project) and many others. Jared from Dorkbotpdx shot video of the event which is now online. I did two demos, the basic blinky-LED hello world and a more advanced assembler sketch that drove a 7-segment LED and serial output (my segment starts at about 4:46):

Watch the rest of the videos from the event here: Dorkbotpdx 0x01 on Vimeo.

Spent a while today getting up and running with Merb, the minimalist modular alternative Ruby framework from Ezra and the good people at Engine Yard. Merb has been in a bit of chaos these recent months as it's gone through a major reworking to acheive a whole new level of performance as well as honest-to-goodness modularity, including choosing your own ORM and templating system. I've been watching Merb's development for some time waiting for it to get to a level of stability that looked safe enough to dive in; their most recent release, 0.9.2, combined with pressing needs in a few exciting new Grabb.it features, made today the day.

My first day with Merb has been mostly great, but the one thing I found really sorely missing was a tutorial on how to get started. In all fairness, the Merb team promises left and right that copious documentation will be coming as they settle down to 1.0. In the meantime, I thought I'd pitch in for any brave early adopters out there with this Guide to Installing Merb and ActiveRecord.

Acquire and Install the Source

So, my goal here was to get from 0 (no Merb on my machine whatsoever), to running a hello world for accessing the database from an existing Rails project using ActiveRecord from within Merb. The first step was to acquire the source. One of the downsides to Merb's modular architecture is the complexity involved with installing it (again, all relevant disclaimers here about how the merb team will, I'm sure, be working to simplify and improve the process as they reach 1.0). At least for now, you actually have to get your hands on three different packages: merb-core (the base of the framework, a requirement), merb-more (has more advanced features like the command for actually creating a new app), and merb-plugins (this is where things like ORMs and templating systems live). Let's do that: $ git clone git://github.com/wycats/merb-core.git $ git clone git://github.com/wycats/merb-more.git $ git clone git://github.com/wycats/merb-plugins.git That'll get us the bleeding edge trunk version (about which more here).

Now that we've got the pieces, we need to install them, thusly: $ cd merb-core ; rake install ; cd .. $ cd merb-more ; rake install ; cd .. $ cd merb-plugins/merb_activerecord; rake install; cd ..

Create a New Project and Configure it for Active Record

We've got all the pieces; it's time to create our project and get it setup to use ActiveRecord. Go to the place you want to create your app and do this: $ merb-gen app my_app This is equivalent to the 'rails' command and will create your project directoy with most of what you need. But since a basic project in Merb is assumed to be simpler than a basic project in Rails, you'll quickly notice that you don't have a models directory. Since we're actually going to need a model if we want to connect up to a database with ActiveRecord, go ahead and create that directory and create a file inside if for your model just as you would in Rails, for example my_resourece.rb, which could look like this: class MyResource < ActiveRecord::Base end

We'll probably want a controller as well, so create a new file: controllers/my_resources.rb: class MyResources < Application def show r = MyResource.find :first render r.some_method end end Notice that all Merb controllers inherit from Application just like Rails controllers inherit from Application::Controller. The naming choice there is kind of interesting because it reveals Merb's controller-centric history and philosophy (remember that the framework doesn't assume that we need models by default; it turns out there's a lot you can do with just controllers).

Since we're using ActiveRecord, we'll obviously need to tell Merb that we want it to go ahead and actually load AR as our ORM. Go into config/init.rb in your project and uncomment the line that says "use_orm :activerecord".

We're almost there! These last few steps will feel familiar from setting up a Rails app: letting the framework know about our route and database configuration. To set up your route, open up config/router.rb and, inside the 'prepare' block, add a line like this: r.resources :my_resources Merb's routes work pretty much like Rails's, but with a few more advanced features some of which are explained in the comments at the top of that file. If you need something other than standard RESTful routing, read those.

Finally, all we've got to do is configure database access and we'll be ready to roll. In Merb this looks exactly like Rails, in fact, I simply copied the database.yml file over from the Rails project that usually manages the db I wanted to access, dropped it in config/databse.yml and it worked straight out of the box.

Ok! If you've made it this far, then you're probably more than ready for the big reveal. In you project directory do this: $ merb The server will start and you'll get a few log messages in your terminal that look like this: $ merb ~ Loaded DEVELOPMENT Environment... ~ loading gem 'merb_activerecord' from ... ~ loading gem 'activerecord' from ... ~ Connecting to database... ~ Compiling routes... ~ Using 'share-nothing' cookie sessions (4kb limit per client) ~ Using Mongrel adapter Once that settles down, browse to http://localhost:4000 and you should see the Merb welcome screen. Go to your expected url to see the result of your handiwork: i.e. http://localhost:4000/my_resources/7

If this works, you're officially up and running with Merb and ActiveRecord. If not, you'll see one of Merb's very stylish error screens and it'll be time to go to #merb on irc.freenode.net where all the friendly merbfolk hang out and are more than willing to help.

Inline Assembler

I'm starting with this new feature not because it's necessarily the most import or most broadly useful, but just because I think it's the sexiest (which probably says something sick about me, but there you go)! RAD now offers a class method to all sub-classes of ArduinoSketch for writing routines in assembly language. You give the method three arguments: the name of the routine, its signature, and the assembly code you'd like to consitute its body. Here's an example script showing the method in action: class AssemblerTest < ArduinoSketch serial_begin def loop serial_println product(10,4) end assembler( :product, "int product(int a, int b);", <<-CODE product: mov r18,r24 ; move a to another register ldi r24,0 ; clear running sum, used to coalesce product ldi r25,0 ; sum = 0 .loop: tst r18 ; is a = 0? if so, we're done breq .end mov r19,r18 ; copy a andi r19,1 ; is a % 2 == 0 breq .skip add r24,r22 ; add b to sum adc r25,r23 .skip: lsr r18 ; divide a by 2 clc rol r22 ; multiply b by 2 rol r23 rjmp .loop .end: ret .size product, .-product CODE ) end As you can see, the body of the assembly code is simply passed as a string to the 'assembler' method. In this case, all I'm doing is implementing multiplication of two integers. RAD takes your assembly code, adds some architecture-specific headers and other boilerplate, writes it to a source file, and makes sure that the compiler knows to compile it into object code and link it into your project during the build process.

I'm an asm newbie and I found that the hardest part of getting started learning the stuff was bootstrapping an environment where you could actually run your code and see the results. Hopefully this addition to RAD will smooth that process for people in a similar situation. Now all you've got to do is put your assembly code in an ArduinoSketch model like the one above, upload it to your Arduino, and read the board's serial output (for example by attaching to it with screen). You can be writing (and debugging) your first assembler routines in seconds.

It's worth noting that this feature wouldn't have been possible without Reed College math professor Jim Fix teaching me the basics of AVR assembler and the avr-gcc build process. Thanks, Jim!

Software Serial Support

This feature came in as a patch from Scott Windsor. Scott was working on hooking up his Boarduino (an Arduino-compatible clone from Lady Ada) to a GPS module and a Serial LCD both of which require serial connections. Thankfully, Arduino provides a SoftwareSerial library for doing serial connection on any of the board's digital i/o pins. Scott's patch gives you really convenient access to this functionality, thusly: class MySketch < ArduinoSketch output_pin 13, :as => :led software_serial 6, 7, :as => :gps serial_begin def loop digitalWrite(led, true) serial_print(gps.read) end end As you can see, he configures ports 6 and 7 as a software seria connetion called "gps" and then he simply says "gps.read" to read the data his device is sending over that connection. Scott also implemented "print" and "println" methods for outputting to serial-connected devices such as his LCD, which work in the same way.

I was especially psyched to see this patch since I haven't gotten to work with any devices that communicate over software serial yet, which had meant that I couldn't really test and add this functionality myself. I'm planning to get my hands on some of that soon and so I'm excited to play with the clean simple API Scott's provided here.

Fixed Hardware Serial Support

In previous releases of RAD, hardware serial support had been, uh, perfunctory. The trouble stemmed from the wide variety of functionality hidden behind Arduino's elegant serial API. Serial.read(), Serial.print(), and their brethren do subtle things to act correctly when called with different arguments, from integers to individual characters to full strings (or arrays of characters, as C would have it). The result was that RAD's versions of these methods would sometimes do strange things like returning ASCII-value integers when sent characters. That should no longer be happening. For example if your run the following sketch: class SlowTypewriter < ArduinoSketch serial_begin def loop serial_print serial_read end end and attach to the serial output with screen, you'll see the characters you type successfully roundtripping to the Arduino and coming back with their encoding preserved. It's the world's slowest typewriter!

A Panoply of Small Features, Tweaks and Bug Fixes

Including, but not limited to:

• Made 'rake make:upload' default to skipping the prompt for reseting the board. The older NG boards that require the reset are getting rare and I recently modded mine to no longer require it. The reset is still available as an option by editing the "physical_reset" option in config/hardware.yml.
• Added support for HIGH/LOW and ON/OFF constants. This is a nice feature of the Arduino API that I hadn't been able to sneak throug the RubyToC translation stage until now.
• Support for variables that are not local to the loop method. It's a common desire to be able to initialize variables outside of the loop method of a sketch so that they will not be constantly re-initialized with each run, for example to define environmental constants or initialize counters. Since RAD replaces the Arduino setup functions and global declarations with ArduinoSketch class methods (such as output_pin), this wasn't previously possible. As of this release, you can use the 'vars' method to initialize variables in this scope thusly: class VarTest < ArduinoSketch vars :a => :int, :b => 7, :c => "hello" def loop a = 1 serial_print a serial_print b serial_println c end end This will produce output like:

  17hello
  17hello
  17hello
  17hello
  [...]
  

  As you can see, the vars method takes a hash where each key is the name of the variable you'd like to initialize and the value and be either a type (rendered as a symbol, i.e. ":int"), or an actual value if you want the var to be initialized to something (i.e. "hello").
• Changed default Arduino location to be /Applications/arduino-00010, which seems to be where most people (now including me) have it.
• Plus too many small bug fixes to list here!

What's Next?

There's all kinds of things big and small on the immediate roadmap for RAD. There's the administrative: putting the RAD source on Git Hub, adding sorely needed documentation to the core ArduinoSketch methods, organizing an email list for the growing group of people wanting to be kept up-to-date on the project, etc. There's the lofty: I've got the beginnings of a plan for putting building a testing and simulation framework on top of RAD that would let you run your sketch against a software version of the Arduino hardware while developing (with a visualization/interactive app built on Shoes!), etc.

And then there's your contribution: send me your patches and RAD can become whatever your want it to! As always, if you've got any questions, ideas for contributions, or run into any troubles running RAD, feel free to email me: greg [dot] borenstein [at] gmail [dot] com or comment here; I'd especially love to see/hear what projects people are building with RAD. Happy hacking!

Ok, I'll say it: I think JavaScript is cool. One of my favorite effects of the move to the modern AJAX-oriented web application architecture has been the opportunity to move ever more functionality into the client. At Grabb.it, we like to say, "Anything you can implement in JavaScript is free." Instead of running on our servers, the JavaScript portion of our app runs on a distributed grid of thousands of machines maintained for us by our users. Also, despite the reputation given it by the Browser Wars, JavaSript is incredibly fun to develop in: it's lightweight and extremely flexible in a unique way that somehow forces you to constantly keep your code very closely tied to the data it's manipulating.

The one big downside to JavaScript is its runtime environment. Not only does code running in the browser confront a Gordian Knot of browser compatibility problems, but it's also irretreviably isolated from interoperating with other application code. While javascript libraries (like the inestimable jQuery) are increasingly proving the Alexander's sword of the browser compatibility Knot, the issue of lack of application interoperability is only just beginning to get serious. As JavaScript's innate advantages lure more and more application code into the browser, the question will be unavoidable: How do you get modules implemented in JavaScript to interact with those built in other languages that live in more traditional environments? How do you avoid duplicating all functionality that you put into the JavaScript portion of the application so that you can call it from outside the browser?

This week, trying to solve exactly these types of problems, I discovered a tantalizing avenue towards addressing some of these questions: browser automation from the command line and from scripting languages. Here was my situation.

As part of an upcoming Grabbit project, I've built a a highly interactive data browser for our customers. The JavaScript running on that page makes a series of JSON GET requests to gather all of the necessary information to compose its display and it makes a few AJAX POST requests to report back to the server on certain bits of status. But now, I wanted to trigger those POSTs programatically on a schedule rather than waiting for customers to trigger them. The dilemma is that I'd already written this relatively sophisticated JavaScript application that makes all the necessary requests, implements the business logic, and knows how to POST in the data. I had two options: redo all of that work again in my server-side application (ick!) or figure out a way to trigger this JavaScript code by automating its runtime enviornment (the browser).

After a half day's research, here's what I discovered: there's a Firefox extension that allows other applications to establish JavaScript shell connections to a running Mozilla process via TCP/IP. It's called JSSH. Once you've got JSSH installed and running in Firefox, you can open a telnet connection to the browser that allows you to automate it using JavaScript commands to do things like load new pages or even manipulate the DOM on pages you've loaded. You can then automate this interaction using any scripting language with a telnet library. For the remainder of this post, I'll provide step-by-step instructions for running JSSH and for automating it with Ruby.

Install JSSH

The easiest way to install JSSH is to download the JSSH.xpi and open it with Firefox which will offer to install the extension (if you're interested in compiling Firefox with it from scratch or installing an existing binary, you should read these instructions).

Start Firefox with JSSH

Once you've got a copy of Firefox with JSSH installed, you'll need to run it. You can do this by providing the correct options when launching Firefox from the command line. On Mac OS X, that looks like this: /Applications/Firefox.app/Contents/MacOS/firefox -jssh & The "&" at the end of that line will background your command so it doesn't take over your terminal session.

Telnet into the JavaScript Shell

Once Firefox is running, we can use telnet to log into JSSH like so: $ telnet localhost 9997 Trying ::1... telnet: connect to address ::1: Connection refused Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Welcome to the Mozilla JavaScript Shell! >

Load a URL from JSSH

Now that we're in, we can tell Firefox to load pages for us, thusly: var w0 = getWindows()[0] var browser = w0.getBrowser() browser.loadURI("http://www.urbanhonking.com/ideasfordozens") And that's it! If the JavaScript application I wanted to run lived at "http://urbanhonking.com/ideasfordozens", we'd be done. That command would load the page and Firefox would interpret and run the JavaScript it found there.

Now, all we've got left to do is make it so that we can trigger this process from our application code. So, we'll...

Automate the Process with Ruby

Like any good scripting language, Ruby has a telnet library, which means that once we've got an instance of Firefox running with JSSH enabled, we can talk to it from Ruby whenever we want. Here's an example script that logs into the telnet shell and loads a series of URLs one at a time: require 'net/telnet' my_urls = ["http://urbanhonking.com/ideasfordozens", "http://atduskmusic.com", "http://grabb.it", "http://pdxpopnow.com"] # start telnet session with the Firefox javascript shell and setup browser object puts "starting telnet session" firefox = Net::Telnet::new("Host" => "localhost", "Port" => 9997) firefox.cmd "var w0 = getWindows()[0]" firefox.cmd "var browser = w0.getBrowser()" # load each page my_urls.each do |url| puts "loading...#{url}" firefox.cmd "browser.loadURI('#{url}')" sleep 10 # so that the browser has time to load even if the page is slow end firefox.close

Further Research: Screen Scraping JavaScript Heavy Sites

What else might this rickety bridge we've built to the JavaSript runtime environment be good for? One thing that immediately occurs to me is: screen scraping for sites with a lot of JavaScript. Another side effect of the rise of rich JavaScript applications has been to create intractable problems for people trying to do screen scraping. If the data you want is not in the page's HTML when you request it in the first place but is only written in later when the page's JavaScript runs then traditional spidering and screen scraping techiques will fail to find it. Freebase, the open database application built by Danny Hillis and his team, for example, uses a highly dynamic interface for presenting its data that is almost entirely based in JavaScript. Or, on the low-brow side, MySpace uses JavaScript throughout the forms in its interface to help with date picking and such. If you wanted to scrape or automate interaction with either of these sites, you'd need access to a runtime environment that could execute JavaScript.

I haven't really tackled this problem with JSSH, but I do have some leads. For example, here's how you get the html of the document: > browser.contentDocument [object XPCNativeWrapper [object HTMLDocument]] > domDumpFull(domNode(browser.contentDocument)) <HTML><HEAD><META content="text/html... If you want to explore this avenue further, one of the best places to look is Firewatir, a project to add Firefox support to the WATIR browser testing framework. They do lots of click-by-click automation and checking for results, so I'm sure they've figured out approaches for a lot of what you'd confront when screen scraping. The JSSH documentation itself is useful and clear but not the most in depth.

Happy automating! Let me know what you discover...

Of course, I've been making them for awhile now, e.g. Largehearted Goat and The NY Times Explains the Ratings. At first, creating a new SSS is a satisfying experience. You have a whacky idea and withing a few hours, you've registered a domain, written some simple code, and put something up. But, over time, each one gets to be more and more of a burden. My ideas, at least, have involved sites that need to be constantly updated with new information over time. Since I've always implemented these sites with simple ruby scripts that run on my local machine and then upload the static finished versions of the sites, this has meant keeping an eye on unreliable cron jobs and, sometimes, hand maintenance. And, over the years, I've wondered if there was a better solution.

Today, I took the first steps towards finding one. It turns out that good-ole CGI scripts — so foreign to those of us who's main experience has taken place in the age of sophisticated web frameworks like Rails — make a great basis for SSS development. What follows is a basic introduction to writing and running CGI scripts with Ruby. I'll focus on Dreamhost as a deployment target since it's the service I have access to for this kind of thing and also the issues that arise there are probably not that dissimilar from what comes up with the other shared hosting services that are the natural habitat of SSSes.

Step One: Get Ruby and Rubygems up and running

If you plan on keeping your SSSes extremely spartan simple, you might be able to skip this step. Dreamhost accounts come with an old version of Ruby already installed. If you don't need to install any custom gems for your scripts or control anything else about your ruby environment, you can skip straight down to the step two. However, if you plan on doing anything the least bit more sophisticated — from installing one individual gem all the way up to using Rails itself — you've got a bit of work to do beforey you can get started on the fun part.

Being far from an expert on unix build process and dependencies, I followed Nate Clark's excellent instructions for building Ruby and Rubygems on Dreamhost with just a few discrepancies. My biggest note is that the version of the Ruby source to which he links is out-of-date. I changed his line for download the Ruby source to: $ wget ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.6-p111.tar.gz But, don't trust me! The most recent version of Ruby changes all the time and you can always find the most recent version of Ruby at ruby-lang.org. The one other thing worth noting that I discovered was that in any of the compilations make may die by timeout (Dreamhost kills processes that last longer than a given interval, a major pain point we'll be returning to in a moment when we try to install individual gems). It won't always be clear that a timeout was at fault so if you see a 'configure', 'make', or 'make install' command die mysteriously, just go ahead and try again.

Step Two: CGI Hello World with Ruby

Now that we've got Ruby and Rubygems installed, the first thing we want to do is to just run a basic 'hello world' CGI script to make sure that we've got things configured correctly. Here are the steps:

1. Log into dreamhost over ssh.
2. Navigate to the desired directory within your web space.
3. Create a new file, e.g. test.cgi.
4. Fill it with the following content (if you skipped Step One and are using the build-in DH Ruby, the first 'shebang' line should read: "#!/usr/bin/ruby" instead of what is shown): #!/usr/bin/env ruby require "cgi" cgi = CGI.new("html3") cgi.out("text/plain"){ "Hello World #{Time.now}" }
5. Change the permissions of that file by running: $ chmod 775 test.cgi

Step Three: Install Gems by Hand

Now, if you plan on doing anything more interesting than displaying the date, the odds are you're going to want to take advantage of Ruby's great and growing weatlh of libraries made available as Gems. Unfortunately, the RubyGems server system running at RubyForge has lately become incredibly slow. In order to find packages and detect dependecies, the default 'gem install' command has to communicate with that server and so becomes subject to the ruthless Dreamhost killing of long-running processes. In my experience, trying to install gems on Dreamhost will universally end in frustration: $ gem install feedalizer Bulk updating Gem source index for: http://gems.rubyforge.org Killed What to do?

Fortunately, in addition to using the RubyForge server to search for gems, it's possible to install them directly from .gem files if you can find them for your desired packages. For example, when building a recent SSS I wanted to use Feedalizer — a great library that scrapes web pages and automatically creates RSS feeds from the resulting content — so I hunted down the .gem file via the RubyForge website, downloaded it, attempted local installation, and then (when that failed) chased down the sources for the dependencies (in this case just Hpricot) to follow the same process. To give you a taste of things here were the gory details:

Installing Feedalizer: $ wget http://rubyforge.org/frs/download.php/13797/feedalizer-0.1.0.gem $ gem install feedalizer-0.1.0.gem which threw an error complaining about the need for the Hpricot dependency, so: $ wget http://code.whytheluckystiff.net/dist/hpricot-0.5.140.tgz $ tar xzf hpricot-0.5.140.tgz $ cd hpricot-0.5.140 $ rake gem $ gem install pkg/hpricot-0.5.gem The 'rake gem' step there is necessary because _why only makes the source directory available for direct download rather than an explicit .gem file. After this completes successefully, return to the 'gem install' step for Feedalizer above (be sure to the return to the directory into which you dowmloaded the Feedalizer .gem before running it).

Much bumpier than the smooth ride normally provided by 'gem install', but it'll get the job done. You could clamber your way down similar rutted paths for most any other gem you needed for you script.

And that should be more than enough to get you started. If you run into any troubles, dive into the comments here and on the other blog posts linked for help. Also, if anyone has any experience using lightweight persistence strategies in this context, I'd love to hear about them, espcially if they're file-system only; a lot of my scripts requiring saving records and I tend to use a rickety YAML-based system for them that could stand improving.

Note: Thanks to The Pug Automatic for inspiring me to start down this path in the first place.

I know what you're saying: 'Web snippets? Isn't that a Dashboard feature? Personally, I'd be perfectly happy if Dashboard never launched again!' I know, I know; before figuring out this little trick I felt similarly. But, believe it or not the combination of Sandy and web snippets has actually made Dashboard useful to me for the first time since its inception. So put your well-deserved Dashboard skepticism aside for a moment and listen up.

Now that you've been using my first two tips for awhile, Sandy's starting to know about a lot of your appointments and all your other little tidbits, but what's the best way for her to give you easy access to them? Sure, you can query Sandy for individual bits of information when you're on the go, but there are some things — like your calendar and TODO list — that you've just got to have close at hand in full. Creating web snippets out of Sandy's monthly and tag views is the best way I've found to accomplish this.

A 'web snippet' is simply a chunk of a web page that you select from Safari. Safari then creates a Dashboard widget that will be constantly kept up to date with the current content of that little bit of the web. What we want to do is to create web snippets out of the pages on Sandy that have our most relevant information. For my part, I've settled on the Monthly view and the view for my @computer tag (more about that in a minute). Here's how I got those created:

1. Login to IWantSandy.com/home.
2. Click on Daily Digest > This Month (the 'This Month' link under the Daily Digest drop down).
3. Click the web snippet icon as shown above.
4. Drag the highlight box around the yellow pad part of the screen containing your reminders. Sometimes, the box will lock onto individual sub-portions of the page making selection easier, but you can also drag its corners around as well.
5. Click the "Add" button in the top right.
6. Dashboard will launch. You're done.

Now, you'll have a custom-made widget with all of your reminders for the month available anytime you invoke Dashboard.

So, how do I use this? And what's so great about it? Couldn't I just visit Sandy's perfectly nice website anytime I wanted to view my stuff?

I've made two Sandy-related widgets: one for my appointments for the month and one for my items tagged @computer. I use the @computer tag in a GTD-ish manner to specify TODO items that I can accomplish at my computer (click on the image below to see a larger version):

Each of these uses demonstrates a different big advantage of accessing Sandy from Dashboard. The key is: the AJAX bits of Sandy's interface still work here, so I can edit items and mark them as done directly from these widgets.

For example, when I complete an item from my @computer TODO list, I simply click the 'x' next to its entry in the relevant widget and the item gracefully fades away never to return:

Similarly, I can edit details of appointments if they change, simply by clicking on an item from my monthly calendar. The first click pops up a box with some more details:

Clicking 'Edit' brings up a form where you can change everything from the date to the description to when you want Sandy to send your reminder:

Each of these web snippets really starts to feel like a tiny little custom desktop client for a single specific bit of Sandy's functionality.

One of the big lessons I've learned from my attempts at doing GTD has been the importance of putting your inboxes and other TODOs directly in your path, someplace you'll stumble over them in the course of your normal daily operations. And these little applications are a really lightweight way to do just that, eliminating nearly all the friction involved in maintaining and making reference to my lists and reducing the opportunity for fiddling to a minimum.

In that time, I've covered topics from art to Ruby on Rails to a series of eccentric projects. And you all have responded, writting 286 comments for an average 1.45 comments per entry. My posts have been picked up by BoingBoing, 43 Folders, and many others.

Anyway, I've got lots of exciting stuff in the works including a series on the basics of microcontroller architecture and assembler programming, a few ideas for phsycial/ubiquitous computing projects, and a few other non-tech projects starting up as well.

So stay tuned and keep those comments coming…

As a follow up to my last post on mobile communication with Sandy, here's a trick I use to communicate with her when I'm sitting in front of my computer.

My favorite super-fast way to tell Sandy about new reminders is nearly identitcal to the famous Quicksilver append trick. In that legendary tip, Merlin Mann advised combining Quicksilver's raw text entry option with it's ability to append information to existing text files in order to quickly add items to lists for tracking everything from TODOs to groceries. My Quicksilver-Sandy technique is almost exactly the same, but here, instead of popping our text on the end of an existing file, we're going to have Quicksilver stick it in an email and send it off to our favroite fictional personal assistant.

If you're experienced with Quicksilver, you can probably figure this out for yourself, but for the rest of you here are the gritty details:

1. Invoke quicksilver.
2. Hit period so the first pane goes into text mode.
3. Type your message to Sandy (i.e. "reminder thrusday meeting with mikey").
4. Hit tab to bring up the second pane for selecting an action.
5. Type "e", "m" (enough for Quicksilver to pick "Email To...(Send)" as the action). Caveat: Make sure you have the "Email To...(Send)" option checked in Quicksilver's Actions preference pane or it won't be available.
6. Hit tab to move to the third, "indirect object", pane.
7. Type "s", "a" (enough for Quicksilver to select Sandy from your contacts (obviously, this presupposes that Sandy is amongst your contacts — which happened for me simply from emailing her a lot; I don't use Address Book).
8. When all three panes look right, hit enter.
9. There is no step 9.

That's it. Just like the tips for mobile Sandy communication, I really like this way of telling Sandy about my stuff because it reduces for adding new information so much that it makes it easy for me to actually achieve the "ubiquitous capture" the GTD geeks are always talking about.

Next time, to complete my trifecta of Sandy-related posts, I'll talk about how I access the info that Sandy's storing for me using the new Dashboard "web snippets" feature so that it's always easily available to me.

Until recently, the one part of my interaction with Sandy that hadn't left me totally satisfied was the ability to add tasks and reminders from my phone. Since I've been a straggler in the iPhone stampede, the main interface I use to get data to and from my phone is SMS. It was a synch to teach Sandy to send reminders via SMS, but I had never been able to close the loop on sending new information to Sandy via text.

It turns out the problem was mostly me. There are actually two different ways to get setup to send your reminders to Sandy from SMS: via the secondary email address and via Twitter. Both of these are relatively easy to setup and have different uses depending on the context. Here's what I did to get them working:

Setting Sandy up with SMS

1. Login to iwantsandy.com
2. Navigate to the settings page.
3. Under the heading "Secondary email address", enter the email address that your carrier redirects to your phone via SMS. For Verizon users this will take the form <YOUR PHONE NUMBER>@vtext.com and other carriers have similar services. If you don't know what yours is, try sending a text message to your own email address and seeing what the from address turns out to be.
4. Once you save your settings with your phone's email address, Sandy will send you a message with a link to confirm the address. When the message arrives in your phone — it will be in the form: iwantsandy.com/confirm/<SHORT CODE> — visit the url in the browser.
5. That's it, you're ready to go! Add Sandy as a contact on your phone (enter the address listed as "Sandy's Email Address" as her email address) and you can send her info in just a few clicks any time.

Setting Sandy up with Twitter

1. Go to Sandy's Twitter page and click the button to follow her.
2. Go to your Twitter settings page on Sandy.
3. Tell Sandy your Twitter account name.
4. She'll send you a direct message on Twitter with a confirmation code.
5. When that message arrives, return to your Twitter settings page on Sandy and enter the code in the box.
6. That's it. You're ready to go! You can now send Sandy a Twitter message in the form of "d s remember that I left my cell phone at the bar" from anywhere you can send Twitter messages: Twitterriffic, the web, IM, by texting to 40404, through the Twitter API, etc. Note: they use "s" as Sandy's Twitter name because it's fewer characters to type on a phone.
7. Sandy will respond to your Twitter message telling you what she gleaned from it.

While both of these processes are somewhat lengthy to describe, they each only take a minute to actually execute. And the result of doing so, at least for me, was a major imrpovement in not forgetting things. Instead of writing things down and then sending them to Sandy later when I return to my computer, I just tell her about them immediately when they come up. Plus, now I can access all the stuff I have Sandy store from anywhere. If I want to know what errands I'm supposed to do while I'm out doing them, I just text/twitter "lookup @errands" and Sandy replies with everything I've tagged as an errand.