@lindsay.at

Jonathan Coulton: I do think the common thread that a lot of internet culture shares is a kind of hyper-postmodernism. I barely know what I'm talking about here so bear with me, but you know I think there's a kind of humor, in particular, that is unique to the Internet and it has to do with referencing other things in an ironic way, in re-imagining them in a certain way, recycling ideas. Of course this is part of what postmodernism means, but I think there's sort of winky aspect to the things that become really popular in internet culture that sort of sits on top of that standard postmodernism, you know, collage combination of different ideas. Look at LOLCats for example. Which is bizarre and could only exist on the Internet and is, I think a real good measuring device for determining if somebody is part of internet culture or not. You know, they're basically funny pictures of cats, with a caption you know. And so you can say, well that's dumb, that's you know there are lots of greeting cards that are like that. We've had that for a long time. But there's a self-referential quality to LOLCats and it's the language that cats speak, somehow, it's this kind of pigeon language that cats speak and it kind of makes sense. I mean, if you're a fan of LOLCats, the reason you like it is because you see a caption and a funny picture and yes, you are looking at a funny caption of a funny cat picture, but also there's a joke there and it's very hard to explain what that joke is to somebody who doesn't get it. And it has to do with that language that cats speak, that is made up, that somehow a very large group of strangers all seems to agree that this is the language that cats speak. And so, I sound like a lunatic just talking about it. And that is, I think, a perfect example of the things that become popular on the Internet and why, even though I haven't really said why because I don't even know why. 

Thanks to @siracusa for pointing this out. Note that this is a transcript from a video interview, and not necessarily reflective of Jonathan Coulton's prose style or even spelling of “pidgin.” Grr.

Anyway, this segment collided in my brain with what Noel Murray has been grappling with in multiple “A Very Special Episode” columns that I read recently, namely ones on MST3K and especially The Simpsons. This fragment from the former steps a little closer to what's so utterly compelling about referential, highly-specific humor:

That’s reflective of the whole Mystery Science Theater 3000 ethos. The show featured a barrage of pop-culture references, drawing on movies, music, sports, television, commercials, comics, children’s books, and more, with a good mix of old and new. When I watched Episode 403 for the first time, my eyes popped the moment Mike Nelson appeared as Morrissey, because I wasn’t expecting a Morrissey joke in a cheap, science-fiction-y basic-cable show. Nor was I expecting the show to drop references to Goodfellas, Muppet Babies, Ray J. Johnson, Mel Tillis, and perennially disappointing NFL quarterback Jay Schroeder. The writers free-associated, and if their free-associations jarred one viewer’s memory, they’d made a new fan. In some ways, MST3K is the ultimate example of what I referred to in my Simpsons “Very Special Episode” column as “laughing at the known.” Quite often, the references on MST3K were funny to me only because I “got it.” And when they referred to something I’d never heard of, I didn’t laugh. 

And that reminds me of the person who introduced me to Mystery Science Theater 3000. My girlfriend at the time, she mocked my occasionally goofy sense of humor, especially my favorite joke ever. I had the last laugh (and MST3K burrowed its way deep into my heart) when the episode featuring “Wild Rebels” referenced the punchline, “Silly Rabbi, kicks are for Trids!”

Anyway, it all forms part of what the web, blogs, Twitter, and meeting new people are about for me. I've thought of myself as alone-in-my-head for so long (being an oddball geek growing up, discovering my own particular tastes for myself, often by myself) that it's utterly compelling to find a common point of reference. For that reference to make its way through the gauntlet of mass media to broadcast, well, that in itself is laugh-out-loud-worthy. Twitter? Dozens of little points of connection, every day.

DeWitt Clinton's screed on URL shorteners, especially directed at Twitter's usage thereof, is interesting, not only for the actual content (which is broadly true, and fairly sensible), but for the meta-message: Google is increasingly threatened by Twitter as the prime mover in the "Real-time web."

To me, this feels a bit like fear, uncertainty, and doubt spread about a competitor, attacking the competitor's actions while distracting us about Google's own actions. Most telling was this sequence about precedent:

As a thought experiment, imagine that your email provider suddenly started rewriting all of the URLs in your outgoing emails so they could track every link the recipients click on.

…

But since Twitter is the most popular, and arguably the most influential, of the new wave of micro-blogging systems, I sincerely worry that this is going to establish a precedent that everyone else will feel compelled to follow, since it is clearly an advantage to the network if they can get away with capturing this data. I ask, why wouldn't WordPress or Facebook or Tumblr do the same if they could?

We're supposed to be outraged by the privacy implications here, but the real outrage to Google is that it makes their job harder. Look at Gmail's privacy statement on what they do about you clicking links on email you receive:

When you use Gmail, Google's servers automatically record certain information about your use of Gmail. Similar to other web services, Google records information such as account activity (including storage usage, number of log-ins), data displayed or clicked on (including UI elements, ads, links); and other log information (including browser type, IP-address, date and time of access, cookie ID, and referrer URL).

Yes, Google's asserted rights are over your own use and not with others' use of the links you send. Ask an average user on the distinction, and I think they'd say it's different but not categorically so.

The other part that interested me is the "Safety and Transparency" part for Twitter's links. A major part of Twitter's justification for wrapping every URL (which I'm still personally dubious about) is to protect people from malicious links. Well, that sounds suspiciously like the role Google's stopbadware.org interstitial warning page plays, especially when Twitter doesn't have direct control of how the status message is displayed (it may be via a third-party application or SMS). Is this an argument against URL rewriting, or an argument against anyone else acting as a trustworthy intermediary?

I think Twitter's revelations on its monetisation and platform strategy earlier this year have Google genuinely worried that Twitter is turning into a trusted gateway into the web, and so it gives rise to pieces like DeWitt's, where Twitter is attacked for minimal differences in approach to taking on a threatening gatekeeper role. Google's problem, and DeWitt's myopia in offering solutions ("consider using an html payload"), is that Google is fundamentally of the web, and deals with web pages viewed through browsers. Twitter reaches beyond the web, being deeply embedded into mobile devices, and deals with much smaller units of interest than a web page.

So you say you’re concerned about Apple’s hegemony with the iPad. You’re concerned that the iPad is for media consumption only, and will quash creativity. You’re concerned that it’s a power play that closes off open formats. You’re concerned that it concentrates too much power in the hands of one gatekeeper to your applications. If so, then go away.

Go to the open source world, because there’s no closed-source corporation nimble enough to catch up with Apple on their touch-based OS.

Apple has just grabbed the high ground in this scramble, and some variation of their personal, slate-like computing paradigm will dominate consumer computing’s attention for years – if not decades – to come. The computer is growing up, and Apple thinks they have the key to turning a general purpose computer into a traditional consumer electronics device.

(Incidentally, I can’t name a player in the computer industry that doesn’t share this common goal of ubiquity. Consider Google’s overt actions in the past year. Nearly every major new effort Microsoft has made for well over a decade has been in this direction.)

So, if we accept that Apple will cast a shadow as long as it has with the iPhone, what is to be done? The only alternative I can see is to work on organizing the open source world into offering an effort that could compete.

Forget the tappity-tappity of single touch alone. Reviews of existing best-of-breed single-touch devices suggest that people already demand something more. Apple owns multi-touch (as in, has key interaction modalities tied up in US Patents), and you would do well to look at something else. Pen-based computing has been around for two decades. Go and improve writing recognition. Consider previous user experience successes (such as the Newton and early PalmOS), and integrate the best of their innovations.

What does a responsive pen-based web browser look like? Can you make it swoop and glide like Apple’s offering? Maybe that’s the wrong way to go about it, but you can be sure that consumers won’t accept either long times to refresh a page each time it is moved or the one-line-at-a-time emulation of a user holding down a scroll arrow in a window.

Consider ergonomics everywhere. Apple does. Study people with a pen, clipboard, and some set tasks. How do people act when standing with the clipboard cradled in their arms? When leaning back on a sofa? When poking at it on a table top? How do these three main body positions inform software interaction modalities? Can one UI design accommodate all three? Make sure you can accommodate left-handers easily, now (and others with disabilities).

Once you’ve cracked the basic interactions, make it easy to create an application: be opinionated. There’s already too much flexibility, especially in the open-source world. When presented with a choice, offer the simpler way of doing things. What developers need is a strong vision and the building blocks for making applications. Start with the basics: navigating a hierarchy, filling out a form.

Got that? Congratulations. If you’re very, very good, you might be able to compete with usability of iPhone OS 1.0.

So you say you’re concerned about Apple’s hegemony. So go. Go and run, because Apple has a huge lead.

I'm planning on going to the Music Hack Day in London in two weeks. I'll be waving the flag for The Echo Nest and their fabulous APIs. There's a lot being said elsewhere about it, but I wanted to send out a special welcome to French and Belgian hackers.

The hack day is being held at the Guardian's offices neat Kings Cross, London. That puts it just a couple hundred metres away from the Eurostar terminal in London. So, for precisely the price of a round-trip fare to London, you can hop on an 8am train, get fed throughout the event, housed on Saturday night, and return Sunday evening. Nothing else to worry about. Well worth considering if you're close to Lille, Paris, or Brussels. Oh boy, what I would have given for a weekend like this when I was living in Brussels...

So register right away: the spaces are now filling up fast!

And we can get up to antics like this:

(Which is just the Dissociated algorithm applied to video in synch with the audio, in the latest versions of the Echo Nest Remix API. In my opinion, it moves the image of the subject from being quirky to having serious battles with mental health.)

Prompted by a tweet by Simon Willison on Monday, I was intrigued to hear about the Twitter real-time streaming APIs. In spare moments this week, rather than surfing the web, I found myself looking at how to get a view on the API from within Python which was… not trivial. In fact, none of the standard libraries seemed to handle the API at all: every HTTP access library waited until the stream closed, which was potentially forever.

A little poking and prodding, and I knew Twisted was capable of doing it. However, that seemed too heavy-weight a solution for just hacking about. I discovered asyncore, and despite the fairly thin documentation and examples online, it seemed clear that it could help. By evening I had knocked together something that worked with Twitter’s basic authentication and the proxy at work, which pretty much meant that I had to create my own basic HTTP/1.0 client. Not rocket science — I guess I had done the same thing 14 years earlier in Perl4 — but it took some trial and error, and neither the asynchat library nor any other common libraries did anything to simplify putting together an HTTP request.

I posted things up on github just to get some feedback on whether what I was doing was hopelessly misguided and reinventing the wheel, and — other than hearing it confirmed that Twisted could do this easily — it turns out no one else was doing this in Python. Cool, because they’re nifty APIs. It seems Twitter had turned into quite the target this year, with both Facebook on one hand and Google on another looking to get in on the action. I think the simplicity, transparency, and speed of the API are brilliant responses to things like Google Wave. This is very easy to work with, will keep developers around, and is pregnant with possibilities.

Oh, the speed. The fact that there is no apparent latency — a message that I send through my desktop client will appear in the stream before the miniature posting window even closes — makes this tremendously satisfying to work with.

After returning to the project like a bad rash, aided by encouraging words, github followers, and a primal pleasure in seeing words from all around the world spontaneously crawl up my screen, I’ve got a good chunk of code. It’s not brilliantly engineered, but I really enjoyed the process of it, the way it grew organically while trying it with different applications, such as a twistori clone to track (and highlight) multiple keywords in the Twitter stream.

There’s also fixreplies.py, a read-only client that mines your Friends, Followers, Favorites, and conversations to find people to track all public tweets to and from. While I think Twitter did the right thing in limiting replies, this makes for an interesting adjunct to a main, traditional twitter client. You get the feel for a lot more conversations sliding by. As it’s only text in the terminal, it feels more ephemeral, with far less of a need to catch up on everything.

Mostly as an exercise to see if it could be done, I also turned that client into a double-clickable script in Mac OS X. Click, and it opens up a terminal window, asks you for some information on your account, what sorts of users interest you, and how to find up to two hundred users’ conversations to listen in on.

I do hope that Twitter makes this available for desktop clients and the general public, because it really expands the, er, Twitterverse, and opens up new possibilities in interacting with and getting data from Twitter.

I don't have enough time in a month to get one third of what I would like accomplished. I've been brainstorming in various contexts, and I've decided to start giving ideas away wholesale. I have had no problem thinking up ideas in the past, and don't foresee any problems in the near future. I may as well start putting them out there for anyone to pick up and use.

I spent too long this afternoon browsing through the HTML5 working draft, and found some nice things in there, such as the pre-defined BibTeX vocabulary. At first, it's unsettling that HTML5 can exist in a well-formed XML, a decidedly non-XML form, and every step in between, but given the right tools, that might make for interesting opportunities.

Many forms, one document

For example, from what I understand so far, the following two documents will be identical in DOM5 HTML, thanks to optional tags:

<!DOCTYPE html>
<title>Sample Document</title>
<meta name=keyword content=example>
<h1>Sample Document</h1>
<p>Hello<br>World!
<table><tr><td>a<td>apple<tr><td>b<td>banana</table>
<p id=done>I'm done now.

<!DOCTYPE html>
<html>
  <head>
    <title>Sample Document</title>
    <meta name='keyword' content='example'/>
  </head>
  <body>
    <h1>Sample Document</h1>
    <p>Hello<br/>World!</p>
    <table>
      <tbody>
        <tr><td>a</td>
          <td>apple</td></tr>
        <tr><td>b</td>
          <td>banana</td></tr>
      </tbody>
    </table>
    <p id='done'>I'm done now.</p>
  </body>
</html>

On one hand, it's faintly alarming. On another, it starts to look kind of cool. (On a third hand, is it old news? I don't think HTML5 approaches this in quite the same way that HTML4 could sort of be in XML-ish form.) I could be as terse as is legal when authoring a document, then serialize it to a canonical well-formed XML document, and then use the end product in my XML toolchain of choice, whether for storage or transformation or editing.

Dear someone looking for something to do — make this tool for the world: a full HTML5 parser that serializes to well-formed XML. Replace all entities (except the necessary five — or even two) with their Unicode equivalents.

With that accomplished, you probably can make a big splash by also letting it output HTML that current browsers won't choke on and/or conversion to HTML4 that retains semantics by converting new elements to div and span.

I'd really love this tool if implicit sectioning elements in an outline were converted into explicit section elements. Having easily manipulable outlining sections would enable a lot more tools — or allow you to consolidate many writing tools into one.

An archive format?

Why do I care about well-formed XML? Well, did you notice the difference in sizes between the HTML parsing and XHTML parsing sections in the HTML5 draft spec?

Working for years in MPEG made me appreciate why we should strive for data longevity. It might be merely an abstract ideal, but it's one of our primary tasks today to be kind to our future selves. If I come across a document in fifteen years, I don't want to have to look up which elements are void elements in order to parse it. But we owe it to ourselves to archive in a format with more structure than plain text, or even an enhanced text like one of countless wiki formats, Markdown, or Textile.

As I make and break websites and leave them online as a form of digital detritus, I've also been thinking a lot about the maintainability and migrability of data. I'm finding it's easier to setup a new CMS than it is to migrate an existing CMS and its data to another machine. I've even considered migrating out of various CMSes by crawling my own websites. Uck.

Influenced quite a bit by Mark Pilgrim's thoughts on The Format, I'm now considering a well-formed flavor of HTML5 as the format for now. It's not as complete as docbook, but the structural elements are sufficiently complete for 95% of use cases for extended text. And it's more compact. And it'll be trivially viewable.

So, the other itch I'd love someone to scratch is to create an author's profile for HTML5. The HTML5 spec describes what is essentially a delivery format. It has worked hard to separate presentation from semantics, and goes as far as it can in doing so. However, there's a lot in the spec that has very little to do with an article or group of articles connected to form a multi-page resource. I would like a canonical version of an article to carry just the data (and metadata) necessary for the article, and nothing more. It should be self-contained and portable.

From an author's point of view, I would like to concentrate on words and structuring those words. No navigation, no scripts, no unnecessary headers, footers, banners, or columns.

That is to say, the canonical format for the ages doesn't have to be the same as what the user accesses — but they could share the same syntax and semantics. If I'm going to have my work mediated by a CMS, then I want it also maintaining a canonical format for each resource, free from the navigation and eye candy that seems to be necessary to get noticed, and free from existing only in a database that creates a lot of inertia for my data. Dokuwiki, as with so many other things, seems to get this right, with its do=export_* modes.

All roads lead to...

That's starting to suggest my next itch to scratch: a CMS that embodies these principles. It can ingest data in various formats (so long as it can be rendered to HTML and potentially carry a little metadata so that an envelope format isn't necessary, it sounds usable to me) and via different channels (REST and some flavor of DVCS feel like my current favorites). It could render these sources lazily, only when the web server misses from a pre-rendered cache, so that most of the rendering machinery stays out of the way most of the time.

This architecture isn't miles away from how Blosxom does things, mashed up with Django's FlatpageFallbackMiddleware. The core could be small, fast, and flexible, working with varied storage solutions and template languages. Really, it seems like the core code for this involves routing, knowing when to render, and how to ingest from diverse sources, and very little else.

This final idea obviously doesn't rely upon HTML5, but thinking about data longevity and what a webpage is naturally leads me back down this road. Ooh. How original. Yet another CMS. Well, yes. But right now, I have to shelve the idea for later anyway — or hope somebody comes along and makes this exactly how I imagine it to be.

Twitter's currently ablaze with talk about the recent change to how @replies are handled on twitter. (Actually, as of this writing, it's ablaze with a shocking number of "RT this if you disagree with Twitter's decision to hide replies to people you don't follow. #fixreplies" messages that cause a massive facepalm.)

While I agree with the change (because for most of my multiple use cases, that's how twitter works best), I feel for the people who didn't use Twitter this way. Their whole way of looking at the social web has been taken away by the elimination of an application preference. That's surely upsetting, and I can't hope to change their minds. But I can try to get them out of their heads and see how the change makes sense for a lot of Twitter scenarios.

I operate a bot, @recomme (which is currently in the shop for maintenance due to another API change that Twitter made with no warning — so my above empathy is real) that feeds on @ replies: send recomme a message, and it tweets back to you, also in the public stream. If you keep your tweet stream private, you must follow @recomme, and it must (auto-)follow you back. The same follow requirements happen if you want to send private messages and receive them back.

This seemed like a reasonable model when I designed it because to me, the sensible way of managing replies was to see only replies to those people you follow and have asserted that you found interesting. @recomme has nearly 4000 followers now. For those people who have kept their settings on receiving replies to people they're not following, that's a lot of eyeballs to reach, especially when anybody can trigger a message from the bot. Fortunately, this has not been noticeably abused by any of the thousands of users. Unfortunately, because of the existence of the all-replies setting, the bot receives nowhere near the number of tweets you would expect from the number of users, I suspect because the social cost of sending tweets to and from the bot are big.

Now, if Twitter stays with hiding replies to people you don't follow, then my vision of an "emergent social network" can happen. People can happily tweet the bot, knowing that people who don't care about music recommendations won't see those tweets or those replies. The people who do care about you and music recommendations do see those tweets, and I think that's a nifty way of opening conversations.

For my own tweets, I struggle with keeping the number of people I follow down, and I have a tough time refusing to read tweets. The "@ replies to people I'm following" setting was an effective filter. Actually, there's a core of twitter users who I know in real life, and I am more keen on seeing all their tweets. (And did so with a secondary account that saw all replies.)

But the real reason why I'm in favor of the recent change is because of new users. Techcrunch actually showed some insight after their typically incendiary headline:

Before tonight I never paid much attention to this train of thought - after all, on Twitter, I can just follow the people I care about and ignore those I don’t. But it’s clear that Twitter is concerned with appealing to a more mainstream audience, and if that takes making a very simple service even more simple, then by golly, that’s what they’re going to do.

What does a new user see after adding a few friends and "recommended users"? Some tweets, but a lot of decontextualized half-conversations. This is confusing and off-putting. I feel guilty some days when I use Twitter as an open IM/IRC channel, having long threads of conversation. For those who follow all of my tweets, I must seem incredibly boring, geeky, trivial and somewhat profane. That's accurate, but it's not what I like to remind people.

I think that seeing this chatty, focused, decontextualized side of Twitter is not a very gentle introduction for newcomers. It might be useful for comfortable users who have been around for a while but follow dozens of people (or for very prolific users who skim or otherwise filter their tweet stream but don't pay particular attention to any users in particular). But for introducing users to Twitter while fighting concerns that it is "trivial," it's a pretty important step to take.

Some ideas that were thrown at me were improving the experience:

Carr0t

I would prefer it on a per-user basis. So I could say ignore @replies from @stephenfry, but get them from @daagaak.

daagaak

It would be nice for API users, bots, etc to be able to specify if a tweet should act like that. I just dislike the list of discovery.

But the truth is, that's all too fiddly. It makes a degree of sense to a "power user" like me, but from a user standpoint, it's a disaster. Too many things to control. The point of the change was to simplify a hard to understand option, something that I stand behind on principle.

On the other hand, Anne said, "Never take options away from a user." Those are also wise words. My gut instinct to make as many people happy as possible would be to grandfather in the feature: keep the option for those who have changed from the default, make it disappear for all others. This creates two tiers of users, though, which is untenable in the long term, especially from the social aspect: these exceptional users have a view on Twitter that is fundamentally different from others, and are likely to use it differently. As such, I think the feature should be phased out. Leave it to clients to support an expanded view of the greater twitterverse.

There's a Twitter truism that's been floating around: "Anyone who tells you how Twitter should be used is wrong." I've tried not to fall afoul of that here, but it's a fine line.

I'm not a programmer. I don't harbor dreams of writing elaborate code that gets lots of users and has lots of programmers follow my lead. But once I get into it, I enjoy hacking on code, and am happiest to have just a few lines of minimal and/or clever code that a few other people with odd tastes might also enjoy making use of. I like to share.

I've been thinking a lot about distributed revision control and online code hosting lately. I've stirred up a few conversations on twitter because of these thoughts, and wanted to lay them out here.

I tried with Git. And I got far enough with it to get into trouble. I eventually made a mess of a few commits on a public (SVN) repository. Since I couldn't make distributed revision control work with subversion, then I ended up learning subversion better (and rsyncing between my private, local branch and the mainline). From the start, I found git to be too far from my own mental model, and too optimized for situations I didn't value (huge code bases, distributed teams of mergers, fast performance and in-place context switching). So I didn't try very hard. That's fine. There were other choices in distributed revision control.

I liked Bazaar from the start, largely on its stated values (easy model, one repo is one directory, concentrate on getting it right before making it fast), and that it got me up and running quickly. It wasn't only from the out-of-box experience, but the excellent documentation on different prototypical users and their workflows, and the fact that there was an easy path to push repositories to a remote server using only sftp .

When I was looking at these solutions, I set Mercurial aside, because it didn't seem to have a lot mindshare at the time, and I had difficulty installing it on the Mac the first time. (Actually, I had problems recently, until I realized that using the Makefile was far less effective than using my oft-incanted 'python setup.py install'.)

It's a bit over a year and a half later, and some of the sheen has definitely gone off bzr for me. There are some little annoyances that have built up over time:

• The admirable striving towards "getting it right" has resulted in many updates to the repository format since I got started, and countless updates to the mainline program. This commitment to keeping the project up to date is admirable, but it's annoying to chase.
• My dependency on the rspush command (I like to have a working copy of my most important repositories on remote machines, and not have to rely on installing bazaar if something goes horrifically wrong) means that I must always install the BzrTools plugin, which multiplies the annoyance of the development churn.
• bzr-svn was extremely unsuccessful for me.

Yes, I know about Launchpad. I've even hosted a now-abandoned project on it. It's an impressive bit of engineering and a wonderful, completely free service. There are numerous interesting projects with a home there . I just don't think any of my near-future projects could have a home there.

As a dilettantish coder , I am drawn to the sorts of odd little projects that one sees on Github. I can easily bookmark a project for later inspection, and do so often. Github's prolific social model clearly works. It knows that its users are developers, and makes every part of its interface geared towards that. I feel comfortable enough with git that I might branch, modify, and push back existing code, but I don't feel comfortable using it to organize a project of my own doing.

Launchpad's hosting, by contrast, feels "heavy." In fact, it feels like a SourceForge clone, where it hides the code away, and concentrates on end users. That's great for users, and sounds very appropriate to the user-centric focus Canonical has. But I don't need a bug reporter and project planning and translations and a knowledge base. I want programmers to see my code and to get my code if they want. I want to provide some context in the form of a README. That's more or less all I need to publish.

On Launchpad, giving a context involves writing text in a web form that's half the size of the form that you are given for telling people how to report bugs. Nothing is integrated with the excellent revision control system other than the code itself — and the code is consistently four (non-obvious) clicks away from the project home page.

I have devised a crude way of making a permanent note of a project's code I want to remember, but it's a multi-step process (involving "subscribing" to a code repository, but disabling all email notices of changes) that I keep forgetting how to do. I'm not saying Launchpad isn't usable: it's not easily usable by me, who likes using the developer-as-user-centric Github model.

(Google Code, as an aside, is nice. It's unobtrusive interface has a nice set of features, and they get out of your way when they're not needed. It's not instant to – for example – assess how fresh a project is from the date of its last commit, but that information is a couple consistent clicks away. I just don't want to initiate a project using subversion, knowing that, given my history, it will reach some state of abandonment eventually: if I'm the only developer, then the SVN repository is essentially locked away in an immutable state forever. I'd rather let people discover my code three years down the line and branch freely.)

So, what am I thinking about now? Despite some encouraging words I heard from a local developer who's on the LP team, I'm very dubious about the prospect of Launchpad bending to my will. It would involve de-emphasizing the work of half a dozen teams in the web interface, all in the interest of Making Things Nicer for Adam. However, building something new up from something minimal might work well. It wouldn't be that hard to expand Loggerhead, the core Bazaar repository-view web app, to include basic social web features. It's a foolish thought for me to have at this time (when I need to put all my available energy into the thesis).

On the other hand, Bitbucket looks like a pretty reasonable Github clone, and from my experience, hg's model is not too far from bzr's. Right now, barring any further developments, I'm considering publishing future projects there. Yes, it would involve changing to hg (Snej's Murky makes that a bit more inviting.) On one level, that's mad, to change my revision control system on account of an social web application (that's an unapologetic clone of a different, wildly successful service). But that's what's important to me right now: if I want to share with the world, I want enough people to see my code and take it home with them. I want it to be easy for me to manage changes and evolve the code for as long as it engages me, then set it free.

Well, I think I've said some fairly dismissive things about just about anyone's favorite tool and/or service. I'm opinionated, but I'm ready to learn from those who like to inform and engage politely and productively. I'm not, however, interested in zealots.
So. Thoughts?

Would you pay $849 for a new MacBook? - Apple 2.0:

According to AppleInsider's Kasper Jade, Apple sees the cuts — which could come in the next month or two — as an 'interim solution' to the growing popularity of netbooks, those sub-compact laptops that Steve Jobs once dismissed as 'a piece of junk' but which are flying off the shelves at $299 to $349 apiece.

Another round of wishful thinking via rumour, but I just wanted to point out that what's key with watching Apple here is not the bottom price points, but the interlocking matrix of price points. Over the years, led by their iPod business, Apple has mastered the art of the upsell through models with additional features. I think the turning point was the introduction of the iPod mini, at $249. For 'just' $50 more, you could get a full-sized iPod with nearly four times the capacity.

Take a look at the Mac portable and desktop, consumer and professional lines, and see that the jump from one product to the next is about the same as the jump between models within a product line. Really, spend some time at store.apple.com, and see that the price matrix is just as precise and artful as the company's engineering. The question is not "how low can Apple go?" but rather, "what shift in the prices of existing products will suggest more models in another product down the line where an upsell to the current cheapest product is an easy jump to make?" (Easy, eh?)

So let's speculate irresponsibly. If the current white MacBook model goes down to $849 (which is already a leap because Apple doesn't cut prices lightly, as they know it's hard to turn back), as the linked article proposes, then it would support netbooks at $749 and $649. Or maybe "MacBook Minis" at $599, $699, and $799. Adding one product line doesn't get you close to the mythical $349 that people are wishing for.

Wait, should that be "MacBooks Mini"?

I haven't been writing on this blog. Never mind why not. I have, however, been writing on this site, trying to fill in the CMS's content a little more.

I wrote a couple pieces on work I have done with The Echo Nest Remix API. It wasn't planned, but it ended up being a good way out of a writing logjam I had found myself in. It was prompted, of all things, by a tweet by a colleague. Was there a place that explains it all? Actually, no, there wasn't.

It's not the finest literature, but I hope that my overview at least communicates my enthusiasm for the project. I've been talking about the principles behind Remix for years and years, but never found quite the right framework for giving those ideas shape. Why, yes, of course multimedia descriptions can be used to drive changes to the underlying media.

My favorite way of thinking of Remix is that it makes each song its own API: each song offers queries into its own features, and can return any number of transformed versions of itself, all of which are sensitive to the original song’s musical features

That sentence wasn't written off the cuff: it distills the essence of my current personal research.

I had meant to write about some further examples, but instead got sidetracked and spent some time looking at automatic documentation methods. It turns out that epydoc is pretty useful software. I had never used the reStructuredText markup language before, either. Although I found it to be a bit heavy on the "ant turd tokens," it was surprisingly usable, especially for code documentation.

So the second release I made last week was of the API documentation. I'm not completely comfortable with where it's hosted, but I did design the URL to be stable and long-lived, if it needs to be. In editing and polishing the documentation, it definitely helped me understand things better, and appreciate that this is turning out to be one formidable bit of software.

The third release was the one I had been planning from the beginning. I had hoped to let the world at all in one go, but the enthusiasm behind them (my own and from the people to whom I showed early versions) was too great for things to wait for my explanation of the Dissociated Mixes.

I knew I wanted to tell people about these mixes after the surprising results I got from writing a code example that illustrated what a sorting operator could do. A bit of thought, and the card metaphor came about. I wanted to make it as accessible as possible to a general audience, but also give enough detail to people who were technically minded—whether about technology or about music. Although the other documentation has gotten some attention from developers, I'm really enthusiastic about this piece for a general audience. It also approaches a silly topic with a fairly straight face. Sounds familiar…