"How finished an artefact is is an important indicator of its relationship to the world: not just an indication of where it is in its lifecycle, but also one that explains how it should be understood, and that opens a dialogue between the observer and the artefact." Me, on Pulse Laser, talking about unfinished states as conversation tools, amongst other things.
"Virgil is singing arms and a man". I must admit, I prefer "the man", but this is lovely nontheless.
"I’ve always been curious about which drummers use a click track and which don’t, so I thought it might be fun to try to build a click track detector using the Echo Nest remix SDK." Analysing tempo fluctuation on a variety of popular recordings to find out who uses a click track; as you might have guessed, Ringo and John Bonham didn't.
Finally, a decent video of Abel. Ignore the first round, where he gets hammered, and concentrate on the second two: he negates Sagat's ranged game by getting in close, throwing in some careful EX scissor kicks, and massive abuse of linking a juggle into the aerial grab throw.
Some nice tips in here, mainly about blocking access to things and security.
David Hobby goes to Cern, and has a ball. Also: takes some nice portraits.
Useful tutorial on building Pagination, that goes beyond the Pagination library and points out what you need to be doing with the Model, too.
Bandcamp add an automatic way to generate one-time use download codes for music – so bands can promote singles and the like. And then: they add automatic Moo Minicard generation to the mix. Bloody brilliant, and definitely The Right Way To Do Things.
"where dreams become heart attacks" – photographs of revolting, calorie-drenched food "experiments".
05 October 2008
Making things is fun. It’s satisfying to watch things spring forth from nothing, made by your own hands.
The greater the gap between your own capabilities (or your perception of them) and your output, the more satisfying – not to mention bemusing – the process is. That’s why Moo‘s public API is so exciting – using nothing but code, you can create real, physical, things. Imagine that! Objects you can hold that sprung forth out of bits and bytes.
I mentioned last week that I’d worked on extending Ruminant, a Ruby library for interfacing with Moo’s API, to also handle the creation of stickers. I wasn’t doing so purely out of generosity, though; I had a project up my sleeve that I wanted to work on.
I can now show you the results of that project. Why only now? Because now, I have the physical products in my hands. I think it’s really important with something like the Moo API that you only talk about what you’ve made when it’s actually real – no showing off code and saying “oh, they’ll be here soon“. You’ve got to make the things.
Anyhow: now I can tell you what I was up to.
These are two books of stickers, made from of my most recent photos on Flickr. They’re built by taking data from the Flickr API, processing it on my computer, uploading it to the web, and sending it to Moo’s API. This is a single shell command. You fill out a configuration file with the important details – such as your API keys for both Moo and Flickr – and run the file. A short while later, you’ll be asked to pay for your stickers, and off you go.
The fun part of this isn’t the whole one-step thing; it’s what goes on when we process the images. We don’t just print them straight, you see.
Another short aside: making real things out of code is fun because you don’t think it should be possible, and image-processing is actually similarly entertaining, just because it feels like it should be harder than it is. Most “easy” programming comes down to processing text in, and text out. Images seem like they should be harder. In fact, images are now much easier than they used to be thanks to things like GD and ImageMagick. I had a lot of fun playing with RMagick, and it wasn’t difficult at all.
So, what did I make?
The first are what I called Dadaist Photographs. Moo stickers are small; it’s quite hard to see a proper photo on their small dimensions. So why not make something at once very vague, and yet also entirely precise? That’s what these are. The background of the image is the average colour of the photo, determined by summing the red, green, and blue values of each pixel in the image, and then dividing each of those by the area of the image to get the average red, green, and blue values – and then making a colour out of those. In the foreground, we super-impose the title of the photograph in text. This is, as you can tell, somewhat silly. But! It’s a hyper-realistic single-pixel photograph, and ideal for Moo’s stickers. (A quick note – I didn’t quite add enough padding to the text on these. I’ve learned my lesson for next time).
Whilst I was working on that, I had another fun idea. It turned out to be just as easy to build, as it resuses most of the same code as the Dadaist Photographs. This let me abstract lots of things out, and at the same time learn how to write slightly tidier object-oriented Ruby. Anyhow, a short while later, and we had these:
These are less silly, and to my mind more beautiful – they render wonderfully on paper. They are very simple to make. First, we squash the photo down to being a 500×500 square. Then, we take the middle row of pixels in the image, and replace every row of pixels in the image with the middle row. The net result is essentially a “stretched” image, based on a single row from the image. RMagick made this very easy. Like I said, I think the results are very beautiful, and it’s amazing how easily identifiable they all are.
I wrote these by first creating the image processing code. That’s the stuff I was least familiar with, and took the longest to get my head around. Once that was done, it was relatively easy to bolt proper Flickr API import on (thanks to the Net::Flickr gem), and subsequently take my processed images and throw them directly at Moo’s API, thanks to Ruminant. A small amount of tidying, abstraction, and the creation of simple config files later, and we were done.
The only slight catch is that Moo need to get pictures from the public web. I’m running my script locally, because it’s quite processor/memory intensive, so the script SFTPs the pictures to a destination of your choosing before sending them to Moo.
But that’s it. It’s one click. It works most of the time (but with 90 images sometimes chokes a little; still, it’s not hard to salvage that by generating the XML for the order yourself). Because of the processor/memory overhead on rendering the images, I haven’t put this online as a web tool – I’m still thinking if there’s an easy way to do that. This could end up on EC2 one day.
What I’ve done instead is to put it on github, so you can at least see the code to learn from it, and, if you want, download and run your own copy. (If you’re not sure what to do: install git, and then click “clone” on the github page to get the command to type to clone the repository), I can’t guarantee it’ll work on your machine, and I can’t offer any support to help you get it running, but I hope you have fun with it regardless.
So there you go. First, an idea; then, the physical product; finally, the code that makes it all work. This doesn’t serve much real purpose, I’ll admit, but it was a fun making project, and it’s hugely satisfying to see how easy it is to make things out of pictures and paper with code, starting with a simple idea.
I’m not sure if I’ll take this any further – it stands alone quite nicely – but for starters, I’m going to see if I can extend Ruminant to handle other product types – though for various reasons, that might take a little while. If I do anything with it, you’ll hear it here first. In the meantime, I hope this serves as a little inspiration for how easy it is to make fun stuff with Moo, and perhaps that my silly, surreal stickers raised a smile.
26 September 2008
Last night, I took a look at James Darling‘s Ruminant library for Ruby. It’s a little Ruby library that lets you assembled designs and orders and send them to the Moo API for printing. It’s really nicely designed, but it’s only in the very early stages of development; it only supported creation of Minicards.
For various reasons, I’m looking at creating stickers through the API, and decided that it only seemed right to add sticker support to Ruminant.
As of last night, I’ve done exactly that. This is in part down to the joy that is GitHub. I forked James’ original code, and started work on my own Ruminant fork. I’ve added support for stickers, and have issued a pull request so that hopefully it’ll get merged back into James’ branch.
To install it, you’ll need Hpricot installed (
sudo gem install hpricot). Once you’ve done that, you can install it as a gem directly from my Github code. First, add Github to the list of sources rubygems supports:
gem sources -a http://gems.github.com
and then install my gem:
sudo gem install infovore-ruminant
and follow the instructions in the README.
More to come, along these lines…
20 September 2006
So I’m only the umpteenth person to say that I’ve just ordered a whole bunch of MOO minicards. Having seen them from some friends already, I can tell you that the quality is great, the size is lovely, and the colour repro is spot on.
What I find really interesting about them, though, is that MOO describe them not as “business cards” but as “calling cards”. I really like that; it’s an important distinction, and a nice reminder of the origins of what we now call business cards. They’re tools of etiquette, ways of seeking permission to see someone and also permission to engage with them. They’re also a signifier; in the old-fashioned usage (seeking permission to see someone) the card with a name on is presented before the card’s owner is even permitted inside the house.
And, as Wikipedia points out, we exchange business cards to swap not only contact details, but business interests. When I look at the cards I have, even though many of them are from friends, it’s still a reminder of what they do rather than who they are. We all have so many ways to contact us now – mobile, email, IM, VOIP, MySpace – that it makes sense to resurrect the idea of cards precisely for personal usage. No business strings attached, no implicit sell; just me, my name, my number.
That’s why I really enjoyed reading the comments on this Techcrunch post about MOO, which Tom linked to.
“Handing out photographs as business cards is confusing, difficult to read and unprofessional,” writes one commenter – but he misses the point, because these aren’t really intended as “professional” tools. The fact they can be used as business cards is, in fact, a nice side effect, and several commenters in that thread point out the value of photographic cards for trade purposes. But really, they’re just ways to remember who people are, and perhaps how to contact them.
I love the revival of a simple, physical identifier in an age when we’re drowning in digital identifiers that we keep losing. I also love that it’s designed for constant, ongoing delight (rather than just an immediate “wow!”). I guess that comes from the certain satisfaction in pulling out a physical thing you’ve had a part in making. Chris remarks that “the best thing is that each picture has memories and stories attached”. He’s spot-on. Every time you give one away, you’re not only giving away an identifier – my name, my number – but also a descriptor – “here is a photograph I like, which I took, which in part describes me through my taste”.
I’m looking forward to receiving my free set, and then I’ll set about getting some more. Demand will no doubt be huge, but I’m sure Stef and the team will cope. More to the point, I can’t wait to see what else MOO are going to do in this field. There’s so much exciting content around the web (besides text), waiting to be dumped out – I commented on the value of hard copy at Reboot in June. As such, surely there’s never been a better time to be in the print business?