-
"LICEcap can capture an area of your desktop and save it directly to .GIF" Like Skitch but spitting out animated gifs; I'm really interested in animated gifs as a documentation format.
-
"I thought: what if there were an all-text Myst MMO?" And then: Zarf built it. Or rather, is building it. A super-interesting experiment in what a MOO for the Tumblr and Twine generation might look like; I'd be fascinated to see the Twine community spin up a server or ten.
-
"Connecting the Twine to a WiFi network is elegant and features a lovely twist: you flip the Twine on its “back”, like a turtle, and it makes its own WiFi network available. Connect to this from your computer, and you can then give the Twine the necessary credentials to log on to your home network, and once you’re done, flip it back onto its “belly” again and it will be ready to use. I really loved this simple, physical interaction." Oh, that's lovely.
-
So far: much happier with this than I ever was with Sparrow; the shortcuts are the ones I need, and it handles plaintext. So going to try living with it for a bit.
-
Wrapping sidekiq into your unicorn process; might be useful for a prototype I have in mind.
-
"…if you're in a public-facing room of the house, then who owns the stuff in that room? (A lot of Gone Home pivots on this question, of who owns which spaces?) To help you figure that out, objects frequently overlap each other: something that belongs to one character might sit on top of a leaflet they picked up, which sits on top of a letter they received. It uses these spatial connections to emphasize the narrative connections between things and what they symbolize." Robert Yang, as expected, is shrewd and fascinating in his take on Gone Home. But I really liked this point: in many ways, it's a really interesting game to view from a material culture perspective – the way spaces are used, and personalised, and (in a home people have just moved into) what are the _first_ things they have unpacked? And so forth. It's a good game about actual, honest, *stuff*, and the way it represents us.
-
"Sheetsee.js is a JavaScript library, or box of goodies, if you will, that makes it easy to use a Google Spreadsheet as the database feeding the tables, charts and maps on a website. Once set up, any changes to the spreadsheet will auto-saved by Google and be live on your site when a visitor refreshes the page." This is good.
-
"All it takes to get a website going for a repository on GitHub is a branch named gh-pages containing web files. You also don’t need a master branch, you can have a repo with just one branch named gh-pages. Here is what I think is really cool, if you fork a project with just a gh-pages branch, you’re only a commit away from having a live version yourself. If this repo being forked is using sheetsee.js then everyone is a fork, commit and spreadsheet away from having a live website connected to an easy (a familiar spreadsheet UI and no ‘publish’ flow because Google autosaves) to use database that they manage (control permissions, review revision history)." Very smart.
-
Hosted statistics tool with attractive interface and smart API. Not cheap for its single-tier plan ($99/mo), but looks like it might be worth a poke.
-
"We need to be armed not only with outrage at the intrusion but with the opinion that every financially motivated imposition is a missed opportunity to enhance the city we live in. Services on our streets are always in change, post boxes and pay phones are becoming antiquated, but there is a real and exciting potential for these spaces to become something else, something human, something exciting and most importantly, something for us." Cracking post from Ben about Renew's bins, some of what we learned in Hello Lamppost, and how people do – and could – engage with the cities they live in.
-
"As serious intellectuals often do, we spent hours discussing these questions, what data we would want to collect to answer them, and even how we might go about collecting it. It sounded like a fun project, so I wrote a program that takes video captures of our Mario Kart 64 sessions and picks out when each race starts, which character is in each box on the screen, the rank of each player as the race progresses, and finally when the race finishes. Then I built a web client that lets us upload videos, record who played which character in each race, and browse the aggregated stats. The result is called Kartlytics, and now contains videos of over 230 races from over the last year and change." Yes, it's a plug for manta, but it's also a nifty piece of engineering.
-
"Termshows are purely text based. This makes them ideal for demoing instructions (as the user can copy-paste), making fail-safe "live-coding" sessions (plain text is very scalable), and sharing all your l33t terminal hacks." Really lovely: record terminal activity, upload it to a URL, share it with others, dead simple. And the client playback is all javascript. Lovely.
Running scripts on startup with your Raspberry Pi
09 August 2013
I’m working on a hardware project at the moment that’s more complex than a basic microcontroller-build that I could have implemented with an Arduino. So I’ve been using a Raspberry Pi as the centre of the project, and writing my code in the high-level languages I’m most proficient in. (In this case, Ruby).
As the project nears completion, it’s really important that the device doesn’t manifest as a computer in any way: it’s just a physical object. To that end, I’d like all the software inside the miniature computer to run at startup without any manual intervention.
My Pi is running Raspbian – the Pi-focused version of Debian – so, fortunately, there’s a tool easily available to do that for us: upstart.
We’ll write an upstart configuration for our script, which will turn our script into an upstart service, which we can then start at login.
First, let’s install upstart:
sudo apt-get install upstartThis will issue some warnings, because – on my install – it was replacing the traditional init.d setup. Don’t worry; everything will continue to work.
Once you’ve installed upstart, reboot your Pi, either from the command line or with a power-cycle.
Let’s now make an upstart config file. Here’s a very basic one:
Put this code into /etc/init/myscript.conf. You should then be able to run the script by typing sudo start myscript, and kill it with sudo stop myscript. And, of course, you’ll discover it’ll start automatically on startup.
That’s a very simple example, with no dependencies. But that won’t work for the script I’d like to use. In this example, I’m running a Ruby script (using the Pi Piper library) that blinks an LED attached to GPIO Pin 17. That script needs to be run as root to get access to the GPIO pins, and it needs to reference the directory’s Gemfile. Upstart scripts are run as root, so that’s not an issue – but we need to set up the environment correctly. That’s not so hard:
As you can see, we just have to export the BUNDLE_GEMFILE variable so that Bundler will know where the Gemfile is located.
Also, you’re going to have to make sure that all references to files in your code are done with absolute paths. That wasn’t a problem with the simple shell script example, but becomes an issue with more real-world type code – especially the program I’m ultimately running, which has various includes, dependencies, and data files to load. An obvious place you’ll run into this with Ruby is when setting up the $LOAD_PATH.
Rather than starting my Ruby script
$LOAD_PATH << 'lib'
I had to do this:
$LOAD_PATH << File.expand_path(File.dirname(__FILE__)) + '/lib'
And similarly, any other references to file loading will need to be absolute – and, ideally, derived using tricks like File.dirname(__FILE__) rather than through hardcoded paths.
Anyhow: it took me a while to piece together, but now that I have, it felt worth writing down – because I’ve now got reasonable complex computation-backed hardware working in an entirely headless enclosure – and one that’s resilient to power-cycling.