I haven't been excited about PHP in a long time. A long time. We've recently started using Ruby at work (notably: Spree, for ecommerce), but it's prompted me to start using Rails to get stuff done on personal projects. It's what runs Emoji Rodeo's backend (more on that another day!), it runs the Pokémon lookup thing, and it now runs some stuff on this site. For specific URLs, I'm using Nginx to proxy to Unicorn and serve up some stuff that I just don't have the stomach to even bother trying in PHP any more. I have been writing PHP for around fifteen years now, and I still have to look up the order of parameters for in_array. Not even joking; I couldn't tell you with confidence what they are, and I know how to use tar and rsync without looking at manpages. It'd be a total guess (and I usually get it dead wrong).

This weekend, I made two things I've wanted to make for quite some time. They serve very little real-world purpose, except to feed my love of lists, APIs and site scraping, but they're made now.

• Films - parsing data from Plot into a format I can share with people who (for some reason) don't use it.
• Music - parsing my music-based Twitter alt into something that doesn't rely on Twitter's perverse interface.

I suppose, the next logical step is to move this blog over to Rails, but I honestly cannot be bothered with that. WordPress is fine when you cache the hell out of everything and don't attempt anything other than using it as a blog. It's a little frustrating to have to update it every 45 minutes, but I can live with it for now.

As a post-script, can we talk about how incapable humans are of following a standard once it's been created. I use pretty much three sites on @upsettingsounds: YouTube, Bandcamp and Soundcloud. YouTube and Soundcloud have two slightly different implementations of oEmbed (one refers to it as application/json+oembed and the other text/json+oembed). How hard is it to just pick one?! I hate humans.

I wrote a blog post over on our highly corporate company blog which has two whole posts on it. It's a post about how we record scores from ping pong games and what we do with the data. Scintillating stuff.

The only reason I mention it is there were two title options for it and I couldn't not use this one for something.

Panic released Coda for iOS (henceforth: Coda) yesterday, and it looks pretty excellent (Panic are very skilled at making things look good). However, for a lot of people, it will be missing something huge - any kind of environment.

At Buffalo, for most projects, and certainly all new projects, we work with something like Capistrano for deployment (no CI, sorry) with at least two deployment environments: staging and live. This approach will make working with Coda very difficult, because it needs to connect to a remote environment to do anything of use. Your local environment in Coda is effectively an empty file system with a text editor. No Git, no RVM, no Composer, no pip, no NPM. But most people are going to need that to get anything done. So you're going to need an environment to connect to so that you can do something with the changes you make. For this, I recommend at least one VPS (when our stacks vary, they tend to conflict. YMMV) on which to do your dev work.

The way you'll use Coda is to connect to your dev VPS, download the file you want to edit, make changes, upload it, and if that change is good, you'll then commit on your VPS and push from there. Because things will be set up as a full dev environment, you'll also be able to run your deployment tasks directly from the app, which is great. If you have an iPad and a keyboard, this could pretty reasonably replace your laptop for dev work.

However, I don't think that Panic is putting enough emphasis on the need for this extra step. They say "it's truly pro", and it can be, but they don't really give you any indication of what you'll need to achieve a decent working environment. For some people, having to add the monthly costs and time maintaining your environment to make this viable will be too much, and I think everyone needs to be aware of that before they take the plunge.

If you are interested, I recommend using Linode (referral link) but people seem to love Digital Ocean (referral link) too.

Next to the rpi for a size comparison

Tessel finally arrived. I say "finally" but I believe it still isn't ready. Mine's going back in the box for a couple of months until it's a bit more stable.

Using JavaScript was not a smart choice for this, in my opinion. NPM is a terrible joke on OS X and it's one of the main downfalls of the Tessel currently.

With that said, the guys who make this are supporting issues very quickly and effectively. I just have very little interest in fighting this thing to get it to not work. Ten years ago, maybe, but I have better things to do.

I strive for minimalism when using computers. Less software, less processes, less distraction. I have a block colour as my desktop background. I don't install superfluous software, no matter how beautifully-crafted. My computer is a tool (well, my OSX partition is anyway), not a game, so I treat it as such. If you rely on your computer, treat it well. Know where everything is and know what's installed at all times. If something becomes surplus to requirements, remove it.

I use Dropbox as my cloud sharing weapon of choice. I share folders with friends and colleagues, and all of my screenshots are saved to a sub-folder of my public folder so that I can easily share them with anyone. This workflow might seem inherently insecure, but I don't tend to screenshot things that are particularly secret; whether that's a result of my screenshots having been public for so long, I don't know.

You can easily change your screenshots directory from your Desktop to your Dropbox folder by opening a Terminal (/Applications/Utilities/Terminal.app) and running the following command: defaults write com.apple.screencapture location /Path/to/Dropbox/Public/Screenshots

I like to have them in their own folder as I use Public for other things and don't want it becoming overrun with screenshots. I don't delete images; occupational hazard.

You can now close your Terminal window and go back to ignoring it if it scares you. I know a lot of people are uncomfortable with it. Once you're saving screenshots to that directory, you can download the Automator Workflow. Unzip and open with Automator. You'll be asked if you want to install it. If you trust me, click install and the workflow is copied to the correct directory and opened for you to edit (you're going to need to edit).

You should be presented with a screen that looks a little something like this:

We're only interested in the first box, where you've got some config to edit.

dropbox: The path to your Dropbox folder. screenshots: The path to your Screenshots folder. Must be relative to $dropbox. dropboxuid: Your Dropbox User ID. Go into your Dropbox Public folder, context-click (right click, thanks Apple) > Dropbox > Copy Public Link. Your User ID is the big number in the URL copied. bitlyuser: Your bit.ly username. bitlyapikey: Your bit.ly API Key can be found at the bottom of this page.

You may not care if your URL gets shortened. If this is the case; find the following block of code in the first box: short=curl -m 4 -0 "http://api.bit.ly/v3/shorten?login=$bitlyuser&apiKey=$bitlykey&format=txt&uri=$encoded" if [ -z $short ] then     short=$url fi echo $short

And replace it with: echo $url

Now you'll just get the Dropbox Public URL copied to your clipboard; not bit.ly (which bit.ly will probably prefer if you take a lot of screenshots!)

I'm making the following assumptions about your system:

• You have Growl.app installed. If you're not sure, open System Preferences and look for a pane under "Other" called "Growl".
• You have Dropbox installed
• You have changed your Screenshots path (using the method above) to be within your Dropbox Public folder
• You have OSX Lion installed. I don't see why it shouldn't work on Snow Leopard, but I haven't tried and I can't.

If you satisfy those criteria, you should have success with this workflow. It is, however, offered with no support and I will accept no responsibility if you break your computer playing around in the Terminal because it looks like The Matrix or trying to update Ruby (system Ruby works fine) or something. If you're friendly and would like some help, please ask on my Formspring and I'll try to help. I'm by no means an expert at Automator, bash or zsh scripting or AppleScript but I can get things to work. I suck at AppleScript so badly that I had to paraphrase the AppleScript portion of this Workflow from here.

Yes, Perkins, I've heard of Cloud.app.