disobey.com

60 Blank White Cards is dead; long live Video Underbelly.

It has taken me 11 years, I think, to come to a simple conclusion: I prefer building resources over services. I define a "resource" as content you may be able to interact with; a "service", on the other hand, is primarily something you interact with, with content as complementary. When Disobey first started in 1997, it was all resources: I held high the mantra of "content is king", and produced as much of it as I could. As I became a programmer, I moved closer to services, building software that re-purposed content in ways the user desired. Most of my modern-day Perl scripts continue to do this. While the years wore on, though, I think I found myself building software for the sake of building software - why I rewrote Case Tracker, I don't really know.

Services tend to have shorter lifespans than resources: when everyone is making map APIs, social networks, and photo and video sharing, they crash and coalesce into one, stranding Site B's complementary content or sub-services when Site A takes the cake. Good content, however, good information, tends to be copied and passed around, living forever, never requiring a specific API or site or service.

I'd still like to make 60 Blank White Cards (perhaps as a Noteworthy or Lexicon; interested?) but, when it's over six months after launch, will anyone really remember it three years later? Will it even still be operational? When I'm working on something else and a new vulnerability is found, do I really want to drop everything to upgrade and then ensure it still runs with API changes I haven't been monitoring for years? Especially when no one cares about it anymore (save me, aghast at the idea of removing it from the net entirely)? When no one else but me can provide an upgrade path, do I really want to keep doing so ten years down the line?

Resources last longer than services because they tend to stand alone - there's little custom code involved when your entire intent is to just make content. One could lament "well, hey, you're using MediaWiki, and you've got to upgrade that continually!", but the difference is that that's pre-packaged software, much like PHP, Apache, Linux, and ever upwards - other people depend on it, so it'll just get done. Custom code for a project that has a finite life-span, or has been made irrelevant by new advances, just doesn't have the same life-support.

Years ago I asked where was my Lord of the Rings? Fiction, content with no custom code, tends to have a finite life-span for the author, but never for the reader. A service may have an intended finite life-span for the programmer, but when your goal is to make something available forever, technology and software just doesn't work that way. Whilst my goals for 60 Blank White Cards were to create a large body of interactive fiction, it was too ensorcelled inside custom, and nearly non-reusable, code whose public (or open sourced) release would actively prevent the mystery necessary for a game of its type. This is quite different from, say, Ghyll, which required no custom code, but was still an immense and enjoyable game of fictional tendencies. 60BWC's content was what I wanted, but there was too much "maintenance always required" to make it work. I was building a service with content as complement, and that's as bad as adding puzzles "just because" that's what ARGs are supposed to have.

I want to build resources that require little technology to operate and that are still important years from now. If that just means a reader is enjoying an encyclopedia last authored in 2005 and which, at any moment, could be expanded upon by the sole act of writing, I'm OK with that.

Video Underbelly took a few weeks to finalize some ideas, but is already "up and running", awaiting new and improved content. It is a resource for films that are often disregarded as unimportant or with no redeeming qualities. This is exactly why the site exists: it is a resource that needs to be retained, not a service that could be replaced. Its existence continues through mere copy and paste, not APIs or upgrades. It doesn't require six months of planning for the next "feature" or the next "version" - it just requires little trickles, each week, applying continuous torture to the rocks that line its shores. You never notice a rock being rounded - you only appreciate the patience it took to get there.

I'd much rather be trickling at creation than treading water with maintenance.

From NewScientist:

The historical documents hint that the Hittites – whose empire stretched from modern-day Turkey to northern Syria – sent diseased rams to their enemies to weaken them with tularemia, a devastating bacterial infection that remains a potential bioterror threat even today, says the review.

The Arzawans took the sheep to their villages and used them for livestock breeding. Soon after, though, they began to suspect a link between the appearance of the animals and the terrible disease ravaging their communities ... "They started wondering 'Why do these rams start showing up on the road?'" says Trevisanato. He believes that among the Hittites, "somebody must have had the bright idea" to send diseased rams over to their Arzawan enemies.

With Delicious Library 2 releasing sometime this holiday season, I may actually start using it for my library catalog. What has stopped me in the past was its lack of expandability - with no AppleScript support, I couldn't add in new data scraping functionality myself (though, if I were truly bothered, I'd've done custom imports). Thankfully, Delicious Library 2 fully supports AppleScript and I'm hoping I'll be able to hook into new item creation, as I'd love to store my comic and magazine collections (and maybe even weirder things like collectible card games, but that'd be ReAaALly stretchin' it).

With the prospect of doing comic importing "the right way" (meaning "type in a title and have it Work" vs. "prepare an external file for importing"), I decided to see if I could get the current release, version 1.6.6, doing "the right thing" the wrong way - getting it to Work via an amalgamation of hacks. I succeeded, but I'm not going to spend a lot of time walking through this: I'll assume you're willing to wait until version 2 is out and this all gets rewritten properly (hopefully... if it's not possible, this hack will be fleshed out in more quality-assured detail).

To get this going, you're going to need:

• The ability to modify the normally hidden /etc/hosts file.
• The built-in Apache web server enabled (via System Preferences > Sharing).
• Leopard. There's a 99% chance it'll work on Tiger too, but I'm not checking.
• The comic book ID you'd like to import from the Grand Comic Database.

Be forewarned: this is a hack in the earliest stages! I'm sure there are plenty of things that can go wrong (like DL loading up the wrong URL for grey arrow clicks, bad scrapes from GCD due to unexpected formatting, the ability to add in other "matching" items from other Amazon sites, release dates that expect the exact day, etc.). I'm hoping all this stuff can be cleaned up a bit more in DL2, but DL is pretty tightly tied to Amazon's Web Services, so pulling data from other sources may always be kludgey like this.

Step 1: Intercept Delicious Library Lookups

The first thing we're going to do is tell Delicious Library to use Amazon Japan for data lookups (in Library > Preferences > Load Details From). I chose the Japan site because I don't think I'll ever legitimately visit there (much less use its Web Services), and the first step of the hack involves redirecting all requests sent to that site from your computer back to your computer. This will trick Delicious Library into thinking it's communicating with Amazon Japan, but instead, it'll be communicating with a script we'll install down in step 2.

To redirect all our Amazon Japan traffic, you'll need to edit /etc/hosts with an authenticating text editor (like BBEdit, or sudo vi, or whatever). Add the following to the bottom of the file, making sure that the whitespace between the two columns is created with a tab:

  127.0.0.1       webservices.amazon.co.jp

Once you save the file, you should be able to access http://webservices.amazon.co.jp/ within your web browser and see that it is most definitely not the Amazon site - it should be whatever page you would normally see if you loaded http://127.0.0.1/ (by default, Apache's "Seeing this instead of the website you expected?").

Step 2: Responding to Delicious Library Lookups

Next, we have to install our script to respond to these lookups. If you attempted to add an item to your Library now, you'll notice that it should still work - it appears DL will default to Amazon US if there are no relevant results on your selected site (Japan, now being redirected back to your computer). The first step to responding correctly is creating a new directory at /Library/WebServer/Documents/onca/. Within this directory, we're going to create a text file called xml which will contain our custom script for loading comic books. This path mimicks the Amazon Web Services lookup that DL requests.

The new file will need to be set to 755 (chmod 755 /Library/WebServer/Documents/onca/xml) so that it is executable. We'll also tell Apache to let this script be executable from the web; to do so, add the following to /etc/apache2/users/username.conf and then restart the web server with sudo apachectl restart:

ScriptAlias /onca/ /Library/WebServer/Documents/onca/

Neat trick? Want me to keep going and get it working in DL2? Send me a buck or two!

Comics.org will be our comic book data source. We'll return data only if we actually find a comic book on that site... otherwise, we'll return nothing, which will force Delicious Library to use Amazon US for your regular scanning needs. Replace your xml file with this final version (renamed to xml), then run through the steps below:

• Find your comic on the Grand Comic Database.
• Get the comic ID from the URL (such as 13825 for Batman #111).
• Add a new item to DL, and add the comic ID to the "Find by #" field.
• Preface the comic ID with "B0" and then a series of "x"s until it turns into "Find by ASIN".
• For Batman #111 (13825), you'd use B0xxx13825.
• Click the "Find by ASIN" button.

If everything works, you should see something like:

There's plenty more to be done; I just hope I can do it better in DL2.

I am a judge in Adrian Hon's newest project, Let's Change the Game. From his announcement:

... together with Cancer Research UK, I’m launching a new project, Let’s Change the Game, that will develop an ARG whose aim is to raise money for cancer research. Like other serious games, the ARG will also educate people about cancer and raise awareness of it, but unlike other serious games, its success will be measured directly on how much real change it can cause, through fundraising.

Let’s Change the Game is a competition where teams from anywhere in the world can submit their own game designs. The team behind the winning design, as chosen by judges who include Sean Stewart, Rhianna Pratchett and James Wallis, will then be invited to develop the game. They’ll have guidance and advice from the judges, plus the full resources of Cancer Research UK; that’s over 600 stores, monthly TV ads, hundreds of races and live events, and mailings going out to over 20 million people. It could be the biggest ARG, ever - and we’re giving new designers the chance to create it.

Teaser 3 is up, previewing the 60BWC achievement system:

An achievement whore is the moniker taken by those who strive to earn every Xbox 360 achievement possible. For those unaware, every Xbox 360 retail game ships with 1000 points that can be earned by mundane, impossible, odd, or merely random gameplay. These points accumulate into a total gamer score that represents all the games you've played. To "ace" a game means you've earned all the points possible: ace your first five games and you'll have a total of 5000 points. Achievement whores obsess for days and weeks over the smallest point value or most useless task, in an ever-deepening delirium to see their scores climb ever higher. Some receive the scorn of fellow whores as they cheat their way forward with game saves and other nefarious activity.

There's new teaser content over at my newest project 60 Blank White Cards, including ruminations about one (of four) inspirations for the game, as well as some very early sketches from our resident artist. Check it out!

Perplex City was an alternate reality game (ARG) with purchasable, but optional, puzzle cards, as well as a cash prize for the first player to find the stolen Cube. While other ARGs have toyed with physical items earned or found by players, as well as "prizes" (like playing Halo 2 before anyone else), none have yet replicated Perplex City's particular approach. I tend to think this is for two reasons: the mystery and the money.

NPR reports:

Pirate ships exist mostly in legend, but a real one - the Whydah - was discovered off Cape Cod by Barry Clifford in 1984. It's the only authenticated pirate ship ever found, and just like in legends, it was laden with treasure. Clifford and his team have just recovered a new collection of artifacts from the ship ... "The pirates testified in court in Boston, and their testimonies were recorded," Clifford said. "They said that the treasure was laid in one heap, that the money was kept in bags, in chests, between decks. And there was about four to five tons just from the Whydah."

The NewScientist reports:

A fungus that is devastating amphibian populations around the world is a relatively new disease that is spreading rapidly ... Worse, not only is the fungus being spread by infected water, it may also be transmitted in the form of spores carried on the wind or birds' feathers ... B. dendrobatidis was formally identified as a frog-killer in 1998, though it has been found on museum specimens dating back to the 1930s. It affects frogs on every continent they are found and is considered one of the three major reasons - along with habitat destruction and trade - for the decline in global amphibian populations since the early 1980s.

A new game entitled 60 Blank White Cards, coded in Drupal and by the well-known Morbus Iff, has just launched its teaser site which alludes to "cash prizes", "prize-winning points", and offers up the requisite word puzzle for those ready to learn more. Take a look-see, sign up for an account, solve the puzzle, and wait for the next update!

The BBC reports:

Researchers from St Andrews University have shown that the animals intentionally modify or repeat their signals to get their messages across ... [T]he researchers set up a situation where six captive orangutans were presented with a keeper who had treats, such as bananas, and blander food, such as leeks or celery. The animals gestured to attract the keeper's attention so the tasty treat would be passed to them.

Professor Richard Byrne, author of the study, states:

[W]hen the keeper pretended to fail to understand the original gesture and gave the wrong food, the orangutans stopped using the gestures they had used before and started using some different gestures ... And when the keeper half understood and gave the orangutan part of the treat, the orangutans started to repeat the same gestures that they had used, but they would repeat them even more enthusiastically.