The expedient desirable product is a principle of software acquisition I coined in response to Eric Ries' minimum viable product. Distilled into two accessible sentences, it would go something like this:
Forget trying to stay on-task and don't waste time vacillating over what constitutes the minimum set of features. What do I have the means to make right now and deliver today that will have some value, either to my customer or to improve my own process?
Over the last few days I've made a couple things that scratched two annoying itches, and I share them here for anybody interested.
When I program, I use Emacs. When I write a program in an interpreted language, possibly even another expedient desirable product, I want to use it right away. I continually find myself switching into a terminal window to run the program I'm working on only to find that I have neglected to set it to executable. I stumble and grumble, apply chmod and continue on my way, ever so slightly irritated. Wouldn't it be nice to be able to have the file set to executable before I switch to my terminal?
That's exactly the problem I set out to solve. I took about an hour and a half, which was probably entirely too long. I probably also replicated existing Emacs functionality, but damn it, it's an even bet that it would have taken just as long to wade through the documentation to locate it. The function is trivial, as you can see here. I spent most of my time looking up the relevant functions in the Emacs Lisp reference, but at least I could be sure of my results.
You see, I had specific requirements about how this function ought to behave. For instance, it doesn't make sense to have executable bits set on a file where the read bits aren't set, so I made my function only set executable bits to correspond with read bits. It may be a bit pedantic, but the side effects caused by naïve bit-flipping are sure to annoy me more than the original problem. Plus, once you solve a problem with a piece of code, that problem is solved forever — that is, until the problem changes. I mapped my function to the key sequence C-x ! and it works like a charm.
I don't get out nearly enough, and I manage my social calendar in exactly one place: iCal. There is a local non-profit group I like called W2 that puts on a number of interesting presentations around the intersection of culture and technology, but I keep forgetting about them as they do not present themselves sufficiently in front of my face.
The W2 Web site currently sits atop the white-label yet-another-social-network factory known as Ning. It appears that whomever Mr. Andreessen hired to design the system neglected to provide a convenient way of funnelling the events put on by his customers into a single place, such as iCal. To irritate things further, individual events can be exported to iCal, but not the entire set. This is bothersome.
My first thought with regard to this problem was that the RSS feed for the events would contain the relevant data, neatly parceled out for a simple format conversion. I was wrong. Trying to parse the entries in the RSS feed would have been a nightmare. It turns out that the actual event listings page has more information about the events than the feed. It's paginated to the first ten or something, but that's good enough to me. Either way, it was clear that I ought to turn to my old partner in Web-scraping crime, XSLT.
This little jaunt cost me in the order of about three hours to get right, which I chalk up to the conscious omission of regular expressions from the XSLT 1.0 specification and my nascent understanding of the iCalendar data format, which I picked up for use with another project. I made it, though, and the results are pretty tidy. I haven't tested it outside of the W2 calendar, but I surmise it ought to work with just about any Ning events page, unless Ning customers can mangle their layouts to the extent of a MySpace page or something.
The beauty of writing this scraper in XSLT is that I can run it with xsltproc which ships with libxslt, which is typically found installed by default on any sane Linux or Mac OS X platform, and which handily includes its own HTTP client — so no messing around with pipes and curl or whatever. The final touch for this project was to upload the file to my Web host and install a cron job that more or less ran the following, and to subscribe to the result with iCal (backslashes added for readability, but it will work if you copy and paste it):
xsltproc --html ning-to-ical.xsl \ http://www.creativetechnology.org/events/event/listUpcoming \ > w2.ics
I entreat you to give it a shot if you dare. It might be useful to you too.
There is one other extremely prolific source of social events that I am considering cracking open: Facebook. The problem is, you have to actually go to and endure Facebook in order to look at them. You can't export them to anything useful; you can't concentrate them into a place where you would actually make use of them.
I've toyed around with Facebook's API, but the whole thing sets me on edge. You see, from what I understand, Facebook poisons their query results with bogus data in order to nab people attempting to extract their precious proprietary user-generated information. As much of an albatross Facebook is, it would be a capital pain in the kiester to get k-lined for trying to make their service useful. Consider me chilled.
Chilled, maybe, but not entirely discouraged. As the eminently inspiring Rear Admiral Grace Hopper once said, it is easier to ask forgiveness than to get permission. That said, I am arguably more worried about inundating myself with spammy events than snagging one of Facebook's tripwires, since the signal-to-noise ratio is so painfully low.
It occurs to me, however, that the Bayesian filtering that was once so successful with plain old e-mail spam would be almost perversely useful in filtering out unwanted Facebook events, since the latter typically don't try to obfuscate their content. There is also the issue of logging in to the API, which must be done through a browser. If I find myself having to log in to Facebook every day to keep my calendar generator going, I might scrap the idea entirely. Anyhow, the current status of this little project fits neatly into that of mulling over.
Both are subject to a BSD licence, of course. Enjoy!