A couple of weeks ago, I realised that my public vCard was less useful than it might be. One of the specific reasons that I created it was to make it easy for people to add a bunch of my contact information to their address books when I met them, rather than them having to manually type in a whole load of stuff that was on a business card. It turns out that this is great when that person’s sat at their own computer, but if they’re (for example) using an iPhone then things become a little more difficult.

You see, the iPhone doesn’t like to use MobileSafari to download files. That’s fine in general – you don’t get a filesystem to peruse on the iPhone, so the only way that downloads would be useful is if the iPhone already knows what to do with them. That’s why applications are allowed to register their own custom URL schemes.

Unfortunately, by default the iPhone only registers a few URL schemes for use within web pages – mailto:, tel: and sms: as pseudo protocols, as well as specific URL structures for Google Maps, YouTube and iTunes links. This makes it impossible to do things like adding an address to the Address Book or an event to the Calendar with a single click on a link in a webpage – you just get a message that reads “Download failed. Safari cannot download this file”.

This is clearly a pain. As a phone, it seems reasonable that you should be able to easily add contacts to your Address Book. Unfortunately, either Apple thinks you shouldn’t be able to do this from a webpage or they just didn’t consider it as a usecase.

It turns out that they did consider that you might like to open email attachments though. If someone sends you an email that contains a VCF file then you are able to open it and see its contents. If you then scroll down to the bottom of the file you’re greeted with two options, allowing you to “Create New Contact” or “Add to Existing Contact”. Suddenly a world full of contact adding goodness is opened up to you.

So, what I’ve decided to do with my vCard is a little bit of user agent sniffing in my PHP. Currently I assume that every other device in the world other than the iPhone will do something sensible with the normal VCF file (or the microformatted data that’s on the page itself), so I listen out for the iPhone’s user agent. If I see it then I swap out the link to download the VCF file with one that takes the user to a page containing a form allowing them to enter their email address. Once they do, the VCF file is immediately emailed to them and they can add my card to their address book.

Right now the look and feel of the the email form that iPhone users are directed to could be described as rudimentary at best, but it works. At some point in the future I’ll get round to making it look a bit more pretty.

As a solution, I’m fairly happy with this. Whilst it’s nowhere near as nice as being able to simply click on a link and add a contact to your address book, it does at least mean that it becomes possible to add a contact from a web page. Certainly it’s a better solution than not allowing users access to the content at all. It’s also entirely possible that this solution would work for other filetypes, such as calendar events.

My only concern is that this problem may be in existence in other devices other than the iPhone as well. It would almost certainly make sense to make the email option available to users of other devices as well.

So there you have it – to allow a user to add a contact to their Address Book from a webpage on the iPhone don’t try and get them to download it, let them receive it via email instead.

The first thing to be aware of is that if Safari can display something on a webpage, then Dashboard can display it as well. If you visit a page in Safari and right-click somewhere on the background of the page then you should see a menu item titled Open in Dashboard.... If you select this then you’ll be able to drag to select an area of the page to turn into a dashboard widget. Click the Add button at the top of the window once you’re done, and you’ll magically have created a widget. Now, any time you open up your Dashboard that widget will be reloaded and you’ll see fresh data.

So, that’s how we’ll display the playlist as a Dashboard Widget – we’ll create a webpage that contains the data and then use that as the widget.

If you read the last entry, you’ll know that I like to use AppleScript as a quick glue language on my Mac. It’s pretty easy to use (once you know what you’re doing), and you can hook into many of the apps you use on a day to day basis and do interesting things with them. So, it should be no surprise to hear that I’ll be using AppleScript to get the playlist data out of iTunes. Given that I’ll be displaying this data on a webpage though I’ll be using PHP (because it’s what I know) to write a quick and dirty page that displays the data that the AppleScript provides.

The AppleScript is a little more involved than the one liners we used last time. We need to grab the current playlist and then grab information about its UID, Title, Artist and Album, and before finally finding out what the currently playing track is. Here’s how we do that.

set tracks_list to {}

tell application "iTunes"
    tell current playlist
        tell tracks
            set tracks_list to get {persistent ID, name, artist, album}
        end tell
    end tell

    set tracks_list to tracks_list  {persistent ID of current track}
end tell

get tracks_list

In this script we first we create an empty list to put all our data in, then we add lists of track IDs, names, artists and albums to it, then we add a single item of the currently playing track’s ID. It’s not the most elegant of data structures to use once we get to play with it in PHP, but it’ll do. Running this from the commandline using osascript -s s playlist.scpt (the -s s means “print the output in a recompilable form”) gives us something like the following (respaced for clarity):

{
    {
        "0D7D716D221B623B", 
        "688E193B9F7F7EE3", 
        "05BFA94137C9691F"
    }, 
    {
        "Fashion Is Danger", 
        "Fabulous", 
        "Never Gonna Give You Up"
    }, 
    {
        "Flight of the Conchords", 
        "High School Musical Cast", 
        "Rick Astley"
    }, 
    {
        "I Told You I Was Freaky", 
        "High School Musical 2", 
        "Fantastic 80s"
    }, 
    "688E193B9F7F7EE3"
}

Now that we have a data structure, we can actually do something with it in PHP. Unfortunately, as far as I’m aware there’s nothing built into PHP that’ll read this structure. Fortunately though, this structure is pretty damn close to JSON. If we were to replace the twiddly brackets with square ones then PHP’s json_decode would return a data structure and we could do something with the data. Hooray. It’s a hack, but it works, and it’s what I did. A simple str_replace later and I had data. You can see the code, such as it is, in my github repository.

The eagle eyed amongst you will notice that I’m not directly calling osascript from my PHP script though, and am instead going through an intermediary shell script that nukes DYLD_LIBRARY_PATH before running the AppleScript. The reason for this is that on the machine I’m running the script on I’m using MAMP for my web stack, and that does funny things with DYLD_LIBRARY_PATH under Snow Leopard apparently. So, I have to nuke it.

And that’s all there is to it. Visit the webpage you’ve created to display the data, let it show you what’s playing and then turn it into a dashboard component using Safari. I get to control iTunes on a remote machine and I don’t have to keep a VNC connection on it. This makes me happy.

My situation is that my iTunes music library is stored on my MacMini that lives in my living room (connected to and powering my TV experience). However, most of the time I spend using my MacBook Pro, which spends most of its time in the office upstairs a fair way away from the MacMini. Because I spend most of my time at the laptop, it’s nice to have music available for me to listen to on it. Of course, if I just wanted to listen to music then this would be a very short blog post – I could use iTunes to share the library from the MacMini and listen to the music upstairs, or I could use Spotify or Last.fm. The problem with these as solutions are that I make heavy use of Smart and Genius Playlists in iTunes to generate playlists of music to listen to. Using iTunes’ sharing feature doesn’t allow me to rate tracks in the originating library (even with iTunes 9’s “Home Sharing” feature), and it also doesn’t generate extra playcount in the originating library for the things I listen to. This means my Smart Playlists don’t update in the expected way, and I become a sad panda. Likewise, Genius Playlists don’t work in a usable way when using a shared library, so this doesn’t really work for me.

What I wanted was a way to play my music using the MacMini downstairs, but have the music erupt from the speakers connected to my MacBook Pro. As it turns out, there’s an app for that – Airfoil. This lovely application hijacks audio from one device and sends it out across the network to multiple other devices of your choice, all in sync. So, immediately I was able to use OSX’s Screen Sharing app to connect to my MacMini, start some music playing in iTunes and then have Airfoil pipe it out to my MacBook Pro. It was a solution that was sheer elegance in its simplicity. Yes, you have to wait a second or so after pressing play before you hear anything come out of your speakers, but that’s down to Airfoil making sure all your devices are in sync before it starts to do anything. All in all, it’s brilliant. It costs $25, but that’s a small price to pay for this functionality for me.

The only problem is that in playing music on a different computer than the one you’re on, you’re playing music on a different computer than the one you’re on. So various things, like media keys on your keyboard don’t work in the way you expect. So, whenever I was wanting to do simple things like pause my music I was having to go into Apple’s Screen Sharing app, log into the MacMini and then press the pause button in iTunes. Not ideal. So, I wrote a quick AppleScript in Apple’s Script Editor:

tell application "iTunes" of machine "eppc://macmini-2.local" to playpause

Yup, that’s a really simple AppleScript. Something I wasn’t aware of until a couple of days ago is that it’s possible to run AppleScript that runs AppleScript on a different machine. All you have to do is go into System Preferences, open the Sharing panel, and enable Remote Apple Events. The first time you try to run an event on the remote machine you’ll be asked to enter your credentials on the local machine, which you can save to your keychain for auto-use in the future. Now, if I run that AppleScript then iTunes on the remote machine will toggle its play state, and consequently on my local machine. Awesome.

It’s just as easy to write other scripts as well. For example, to advance to the next track, just change playpause to play (next track).

But we’re still not controlling iTunes on the remote machine with just a keypress. If you’ve got something like Quicksilver installed on your machine then you should be able to simply hook the script up to a key combination of your choice. I don’t currently have Quicksilver installed on this machine (and wasn’t about to install it just for this), so I had to find another alternative. What I’m currently using is FastScripts Lite, a free app that adds an icon to your menubar that contains menu items for any AppleScripts you put in a certain directory. The nice thing about FastScripts is that it also allows you to enter a keypress combo for any of these scripts by going into its Preferences pane and double clicking on the Shortcut field next to the relevant script. I’ve got playpause bound to ctrl-up, next track to ctrl-right and previous track to (you guessed it) ctrl-left. Now I can easily change what I’m listening to with a quick keypress, and I’m happy.

Well, I’m almost happy. I still need to have Screen Sharing open so that I can see what’s actually in the playlist that I’m listening to. There’s a solution to that as well though. All I needed do was create a script that calls some AppleScript on the MacMini, grabs the current playlist info and then outputs it into a web page. I could then use this page as the basis of a Dashboard widget and I’d only ever have to press F12 to see my current playlist. And that’s what I did. To find out how I did it though, you’ll have to read the next post!

The way I do this is to use a “hot corner”. In OSX you can set up your Mac to perform different tasks when you move your mouse up to any one of the four corners. If you open System Preferences, then Exposé and Spaces and make sure you’ve got the Spaces tab open you’ll see an Active Screen Corners section at the top of the window. I have the bottom right hand corner set to Start Screen Saver. Because I have set Require password to wake this computer from sleep or screen saver in the Security section of System Preferences, when I throw my mouse into the bottom right hand corner of the screen it automatically locks itself for me.

It’s a simple solution that works well for me.

Another way you can lock your machine is to use the Keychain Access application (/Applications/Utilities/Keychain Access.app). If you load this and then open Preferences you’ll see a Show Status in Menu Bar option on the General tab. If you tick this you’ll see an unlocked padlock appear in your menu bar. From now on if you want to lock your machine you can click on the padlock icon and then select Lock Screen. I personally don’t use this solution because it requires more dexterity than just throwing the mouse into a corner of the screen, but it’s another option that you might lie to use.

So, there you have it — two different ways of locking your Mac’s screen under OSX.

So, using the wonders of GreaseMonkey, that’s what I did with a spare half an hour yesterday evening. The demoter script I wrote is very simple — it looks for the first element on the page with a class of “projects”, then checks the last changed date of each of the projects contained within. If any of them contain a date that’s more than a month old then a quick appendChild of the original node onto the new “demoted” list moves it across. A heading is added before the new “demoted” list to explain what this new list contains, and we’re all done.

So far I’ve noticed one “bug” with this script. Normally, when GitHub displays information about a project, it’s the last changed date of the project that’s displayed. Unfortunately, if the user has forked a repository, it seems that the date displayed is when the repository was forked rather than the last time it was edited. Even if the fork happened months ago, and since then the user has made many edits themselves it’s still the fork date that’s displayed. You can see this in action on Brad’s profile page on the “homedir” project.

Short of GitHub exposing the actual last edited date on the page itself there is one other possible possibility for getting hold of a last edited(ish) date. For each of the project activity sparklines, GitHub makes a call back to the server to grab a chunk of parseable data. It might be possible to grab hold of that data using GreaseMonkey, but that’s a problem I leave to the enterprising reader. If you do solve the problem, please do fork my code and send a pull request — I’d love to have this solved in the script.

If you fancy having this “Inactive Repository Demotion” functionality on GitHub, all you have to do is download the script. Oh, and whilst you’re at it, don’t forget to follow the repository so you can be told of any updates or bugfixes.

EDIT:

As it turns out, I should probably be a little more explicit about how to install the script. First, download the entire repository as a zip or tgz. Open it up, and then open the script up in Firefox. The GreaseMonkey script will then install.

The answer? Make a video!

For this make you’ll need to have a copy of QuickTime Pro. Yes, I know you have to pay for this, but it works quickly and makes good quality videos. If you don’t want to use QuickTime Pro, there are other free alternatives available (I’ve had MEncoder mentioned to me), but I’ve not used them myself.

Making a video out of sequenced images is easy with Quicktime Pro – just make sure your images are all in one folder, select a photo from that folder using the File/Open Image Sequence menu option, choose a frame rate and wait.

Of course, things aren’t quite that easy. For one thing, Quicktime Pro doesn’t actually work with full folders of images – instead it works with sequences of images within a folder. So, if you selected horse1.jpg as the initial photo then only images matching /horse\n+\.jpg/ would be sued to create the resultant video. Likewise, if the images were named in the format YYYMMDD-hhmmss.jpg then the video created would only contain images for a certain day, due to that pesky dash.

Unfortunately, that was the original filename format autocamcapture used. It doesn’t use that format any more, but all you early adopters will need to rename your images. Thankfully, that’s pretty damn easy to do. Just enter the following:

cd ~/Pictures/autocamcapture
for file in *.jpg; do mv $file `echo $file | sed 's/-//g'`; done

Your images will suddenly all be in the format YYYYMMDDHHMMSS.jpg and Quicktime Pro will happily register them as all one sequence.

So, that’s all there is to it. Have you been using the autocamcapture script? Yes? Then go make a video and add it to the autocamcapture pool on Flickr.

It turns out that you can increase the number of tracks returned by the feed simply by adding a limit=somenumber parameter to the URL. So, for me to grab the last 20 songs that I’ve scrobbled, I would ask for:

http://ws.audioscrobbler.com/1.0/user/NeilCrosby/recenttracks.rss?limit=20

I use this as a way of getting a decent sampling of my recent tracks to use on NeilCrosby.com, as I found the default 10 was too limiting since my “Stream of Consciousness” stream normally covers a few days worth of information, whereas my last 10 tracks would only cover an hour or so of data.

So, here’s how to do it:

1. Create a directory /Applications/autocamcapture – this is where the executables we’ll be using will live.

2. Create a directory ~/Pictures/autocamcapture – this is where the automatically generated images will live.

3. Download CamCapture and put the executable in /Applications/autocamcapture

4. Open the “Script Editor” application and enter the following:

   set commandPath to "/Applications/autocamcapture/"
   set commandName to "camcapture"
   set outputImagePath to "~/Pictures/autocamcapture/"
   set outputImageName to do shell script "date +%Y%m%d-%H%M%S"
   do shell script commandPath & commandName & " " & outputImagePath & outputImageName
   

5. Save this file as /Applications/autocamcapture/autocamcapture.scpt

6. Open a terminal window, and run crontab -e. Add the following cron job:

   *      *       *       *       *       osascript /Applications/autocamcapture/autocamcapture.scpt
   

7. Now, once a minute a cron job will be fired off and a picture will be taken and placed in your ~/Pictures/autocamcapture directory.

The obvious question to go with this is “but why would you do this?”. Frankly, originally the answer was just “because I can”. I carried on doing it though because in amongst all the dross that inevitably gets taken some interesting photos do occur. Try it out yourself, you might snap something fun.

These are the slides I put together for my talk:

If you just want to download the Code, go right ahead. If you want to know more about the project, read the WikiSlurp Project page.