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.

For those of you who aren’t sure, a Genius Playlist is a playlist of music that all “works together” that’s created from one seed track of the user’s choice. Essentially, it’s a shortcut to creating playlists of stuff that suits how you’re feeling at that moment, rather than you having to go to the trouble of creating the playlist yourself.

Whilst I was initially sceptical of how well this would work (I’ve worked in this problem space before, so I know it isn’t awesomely easy), since iTunes gained this feature in v8 I’ve become more and more reliant on it. My reliance has been so great that I’ve expected the feature in all the other music based services I use. For example, when I started using Spotify, one of the first things I did without thinking was to start playing a track that I wanted to listen to and then look for the “genius” button to see what else Spotify would try and play for me. It upset me that this feature wasn’t there. Sure, Spotify and last.fm allow you to play radio stations based on a certain genre, artist or tag, but that misses a piece of perceived control that starting with a chosen song implies.

So, for last.fm’s hack day I decided to hack together a genius playlist creator. After all, last.fm’s API supplies the track.getSimilar method, which pretty much gives all the data you need for a genius playlist.

There were a few hurdles to get through though. First up was playlist creation and playback itself. It turns out that in last.fm-world you can only create actual playlists if you’re a paid subscriber to the service. That’s not a dealbreaker for me, so I paid my £1.50 for a month’s subscription to see how it went. Unfortunately, at that point I realised that whilst I could now create playlists, I could only play them back if they had at least 45 songs in them by at least 15 different artists. Oh, and I could only play them back in shuffle mode. On the website. Not in the desktop app or on the iPhone. Somewhat sub-optimal.

So, I went back to the drawing board. If I couldn’t do playlists how I wanted in last.fm, how about if I found the data I wanted in last.fm and then used Spotify to play it? Unfortunately, Spotify doesn’t yet have an API, so this also proved impossible.

Scratch Plan B then. Thankfully, I did have a Plan 9 available to me – last.fm’s ability to autostart tracks on the website by adding ?autostart to the end of any song page URL. Using this ability, I reckoned, I would be able to create a page containing a list of songs that could then be played in a browser window by loading up the individual song pages in a hidden iframe. Simplicity itsef, and as if by magic it actually worked!

There was, of course, more magic that went into creating Last Genius. Not all songs on the site are available to stream, and of those that are not all of them are full length tracks. Because I was playing the songs in iframes I had no way of knowing when a song had actually ended. I had to make sure that you didn’t end up hearing the same song twice in a playlist. All these things and more were hacked around during the hack day, and in the end I had something that actually worked.

The end result was a bookmarklet that you can stick into your browser toolbar and click to create a genius playlist any time you want. Just make sure you’re on a Last.fm song page and a playlist will be created for you. If you’re not on a song page, lets just say that the system will try and find you some music that it reckons you’ll like.

Last Genius bookmarklet – drag onto your toolbar.

All I ask is that you remember that this is a hack. It’s only tested in Firefox 3 on the Mac, because during a hack day you don’t have time to make everything work everywhere (it’ll probably work elsewhere, I just haven’t tested yet). Because Last Genius has to make quite a few calls back to the mothership to set itself up, it might also take a little while to start up. Just be patient. For what it’s worth, I have plans to improve this over Christmas.

Because this is a toy I want for myself I plan to spend a bit more time making it nicer. With that in mind, if you have any ideas for things that will make it better, please let me know. Likewise, the source code is up on GitHub, so please go fork it and make improvements. Anything awesome I’ll very happily merge back into the trunk.

So, “why didn’t you just run a Subversion repository on your local machine?”, I hear you cry. The answer is simple – I wanted to make sure I had the code backed up off-site and easily accessible from different machines. I also occasionally collaborate with others on the code I write, so having the repository on my local machine that only tends to be on when I have no network connection would be a bit of a non-starter as well.

Now, I’d been aware of git (and also bazaar) for over a year, but had never taken the time to look at them properly. The reason was that whilst I wasn’t particularly happy with the fact that I had to hold my commits in my head until I got home with svn I had been able to work this way and get things done. I was also not convinced by what I considered “fad” Version Control Systems, and I didn’t relish the prospect of moving from one to another. This all changed for me when I watched Robert Lee-Cann’s <head> conference talk about git. Although more in the style of a Barcamp (rather than conference) talk, Leeky’s session was far and away the one that I gained most from over the course of the event. The tipping point for me was that I could, if I wanted to, use git on the train to do intermediary commits and then commit back to svn when I got home. This fitted my mental model, and I was happy.

Of course, things didn’t quite happen that way. I started using git with GitHub as my remote repository for a couple of minor projects, decided I really got on with git in the limited way I was using it and decided to move across wholesale from svn.

Github

A big part of the reason I fell in love with git was GitHub. Ostensibly, GitHub is just a place to publicly store your code, but that word “publicly” is so very important.

One of the things that I wanted to do when I moved from Working With Me to The Code Train was create a sandbox area where I could make my half finished code public and allow people to fiddle with it and use it. Previously I’ve been much more likely to sit on code for months at a time, willing it to become more stable and generalised before pushing it out to the public, meaning that so many of the ideas and hacks I play with don’t make it out into the real world to be fiddled with by others. It turns out that I don’t need to create that special section of my site any more – with GitHub I get it for free! Now, whenever I start hacking on something, however small it may be, I’ll immediately start a new git repository and stick it up onto GitHub.

There are quite a few benefits to working this way:

• I get to benefit from the eyes of people I work with and greatly respect.

  Whilst most of the code I stick up will be hacky in nature having other people be able to look at the things that interest them means that bugs, issues and mis-thinkings are much more likely to get picked up on. I love the idea of code reviews, and using GitHub is yet another, informal, way of allowing them to happen.

• I get to share what I’m working on publicly, which might just help someone, somewhere.

  Just because I don’t think that something is ready for production use doesn’t mean that what I’ve done won’t be useful so someone out there. Whether it’s useful in solving a problem, or they just decide to use it wholesale, that’s all good.

• I get added incentive to improve my code.

  Because there is the opportunity for so many eyes to be watching the code that I’m producing I feel a greater urge to improve it more quickly. I see this as a game that I get to play, and by playing it everyone’s a winner.

  Mike introduced me to Calendar About Nothing which similarly turns writing code into a game. Calendar About Nothing attempts to add incentive to writing code by giving you your own personal calendar that has each day crossed off as you commit public code to GitHub. The idea is to build up longer and longer unbroken chains of committing code to the public good each and every day. As well as the personal incentive of making your chain longer, the site also has lists of people with the longest chains currently and of all time. The longest chain of all time is currently at 59 days. My aim is to make it to 60 days of committing public code which actively makes something better.

So there you go – I’m loving git, and I’m loving GitHub. If you want to check out the projects I’m working on, head on over to my GitHub profile.

Probably the most interesting projects I’m working on right now are:

• WikiSlurp – a tool to pull HTML formatted data out of Wikipedia.

• Multi Level vCards – use your vCard to publish information to the web, allowing only certain people to see your more sensitive data.

• TwitBot – a tool to allow easy creation of bots for use on twitter.

So, what are you waiting for? Get yourself onto GitHub and lets see the code you’re writing! Oh yes, and don’t forget to read what Mike and Steve have to say on the subject of GitHub too.