I’ve decided to take jmp.li down. The code behind it is open source, and I’m open to offers for the domain name. Existing short URLs will continue to resolve for a while but I don’t plan to do any more maintenance on the site.
Why? It’s mostly being used for spam and porn URLs, and that’s not a service I want to provide. I have no interest in marketing the service to compete with the likes of tinyurl.com, bit.ly and the other established sites.
As part of my ongoing conversion from dynamic to static sites using Jekyll, a requirement recently came up to put all static files on the Rackspace CloudFiles service via their CDN integration. The logical solution to this was to write a plugin.
I looked at several ways of doing this, but the best way appeared to be adding a tag to the Liquid templating system. The plugin is up on GitHub and should be pretty simple to use. I’m currently using it on one site I’m developing but expect to be using it on a few more over the next few months.
A couple of hours ago I needed a break from the project I’m currently working on, so decided to flex my Node.js muscles again. This time I’ve developed a really simple but useful server that presents a simple API for resolving short URLs to their final destination.
You can find it on GitHub: https://github.com/3ft9/furl
Here’s the README file…
FURL
FURL is a service written in Node.js to provide an HTTP API for resolving short URLs.
The service is running at http://furl.li/ so feel free to have a play, but please don’t hammer it! Try: http://furl.li/http://is.gd/w
It’s highly recommended that this is run behind a mature web server such as nginx – this is advice from the creator of Node so pay attention Bond!
Configuration
- All configurable variables are at the top of the source file.
Usage
- Call / and it will return the destination URL. If an error occurs it will return a message starting with ERR.
- Call it with /stats to get a JSON response containing various stats.
- Call it with /clean to trigger a cache cleaning operation. This will return the number of objects deleted during the clean.
TODO
- Move the configuration out to a conf file.
- Add the ability to have an hourly per-IP limit to prevent abuse.
- Add the option of using a memcached instance for the cache so it can be shared across multiple instances of the daemon behind a load balancer.
- I’ve not really stress-tested it yet, but the tests I have done show it to be pretty stable.
I’ve recently been transferring a lot of my sites and server-based services over to RackspaceCloud, and part of this meant uploading a fairly large number of files to the CloudFiles service. The web interface sucks for more than a few files so I knocked up this quick script to make it easier. It has already saved me a ton of time so I thought it worth sharing.
Twitter have recently changed the terms of service for their API and it’s caused uproar in the development community. I’ve written up my analysis over on Stut.net.
In a past life I ran an IRC server that formed part of a private chat network, and off the back of that I had developed an IRC bot called Stutbot. One of my clients recently informed me that they want to set up an IRC server to facilitate realtime communication between their remote developers, with some status information being squirted in from various sources. This occurred to me as an ideal opportunity to revive and update that project.
I’ve recently been looking at Node.js with a view to using it on a few projects I have in mind. This evening I have finished my first Node project, and I thought I’d tell you all about it.
Node is an “Evented I/O platform for V8 JavaScript”. It’s server-side JavaScript. The thought of that initially made me nervous, but I soon realised that there’s no reason for JS to be limited to the client-side. This is the same mental block that makes many people believe PHP should only be used for building web pages when it’s more than capable of performing many other roles.
The core concept behind Node is to ensure that nothing blocks. What this means in practice is lots of callbacks and a very thoughtful development process. It was interesting to see my approach to writing code changing such that whether it would block was foremost on my mind.
In order to get to know Node better I decided to rewrite JMP.LI. I’ve pushed the code up to our github account and called it Shurly (insert Airplane jokes here).
Yes, I know it’s March now, but we’ve been busy! 
This new design replaces an off-the-shelf site that didn’t in any way reflect the nature and ethos of the company. This new site is completely different, and we hope you like it. There are a few more changes yet to be made, but the old site was depressing us so we pushed this out as soon as we could.
Let us know what you think.
I was recently asked to answer a few questions for the 37signals’ blog, Signal vs. Noise, and it just went live.
The post summarises the reasons a number of startups are no longer around. I never really considered TwitApps to be a startup, but I was honoured that Matt wanted to include it in the post.
Matt didn’t use all of my answers to his questions, so in case anyone’s interested I thought I’d post them here.
I’ve had the same thought running around my head since putting the TwitApps domain names up for sale yesterday… would people pay for it?