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.
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).
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?
I’ve been holding on to a bunch of domain names with plans for all of them, but I’ve decided that I’m unlikely to ever get around to using them, so I’ve decided to put them up for sale.
Rather than use an auction site I’ll be accepting offers by email on stuart at 3ft9 dot com until the end of July. The highest offer at midnight for each of the domains on August 1st, 2010 will win. Anyone making a bid will receive an email notifying them if they’re outbid. If people end up fighting for any of the domains I’ll continue to take bids into August until there’s only one bidder left.
I finally got around to releasing the code for TwitApps on my github account. There is no license attached to this code so it’s in the public domain and anyone is free to do whatever they want with it. I don’t guarantee it will be easy to get working, or that it will work at all on your server, but if you have any questions please don’t hesitate to contact me and I’ll do my best to help.
I’ve not provided much in the way of instructions at this point but I may add some next time I have a spare five minutes.
If you find a use for this code I’d love to hear about it so please let me know.
Enjoy.