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.

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.

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.

Stutbot has been through many rewrites since the first version. Initially he was written in PHP, the I rewrote him in C++, and most recently Python. Continuing that tradition I have started rewriting him again, in node.js.

As always the code is up on our github account.

The project has always supported a plugin architecture in al of its implementations and I was excited to see what node had to offer in this regard. After a number of iterations the final architecture is broadly similar to the original PHP implementation, with the added bonus that you can reload the plugins on the fly — or you could if I hadn’t broken that earlier today!

So far I’ve not implemented many of the plugins the previous versions have supported, but now the architecture is there it’s fairly trivial to extend. Stutbot can currently do the following…

• Be a magic 8-ball
• Tell you the date and time
• Dance, but not boogie
• Respond to a ping
• Play hangman

It’s the last of these that I’ve spent most time on. Games are started via a private message, and there can only be one game per channel at any one time. The current state of the games is persisted across bot restarts. I chose to focus on this plugin because it demonstrates how to use most of the bot features.

I’m currently working on an Unfuddle plugin which will allow the developers to get info on their project without needing to load the web interface. I’m also hoping I can hook into Unfuddle’s support for callback URLs on git repositories, so Stutbot can post commit messages to an IRC channel.

Beyond that I have a list of plugins I’ve previously implemented in other languages that I will build as and when the need or desire arises.

Is there anything you’d want an IRC bot in your dev channel to be capable of?

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).

The current service is implemented in PHP and uses a simple disk-based key-value store. It uses no other libraries beyond PHP and runs to about 400 lines of code not including templates. To match this environment I have not used any external libraries save for a module to access MongoDB. Not including templates, the Node version runs to around 600 lines of code.

I normally work very hard to ensure code reuse and elegant design, but given that one of my primary goals was to build a fast service I have made sacrifices in that area. Two things I definitely wanted to retain was some sort of simple templating and the ability to use different data storage backends with minimum fuss. I managed to include both while retaining decent performance.

Templates

There were two issues with performance with the templates. The first is having to load the templates from disk every time they are needed. This was easily solved by preloading them into variables during startup.

I initially had the files being loaded in sequence, with the callback for each triggering the next. The callback for the final file then kicked off the data initialisation. This only happens at startup so I decided to simplify the code and allow the data module to initialise while the files were being loaded. This leaves a very small chance that upon restart people might get served a page containing the default text, like this:

Loading...Loading...Loading

They’d see it three times, once for each of the header, index and footer templates. The window of risk, however, is extremely tiny.

The replacements in the templates are handled by simply replacing all instances of %%var%% with the variable value. Templating at its simplest!

Data providers

The other thing I wanted to include was changeable data providers. This was not rocket science and simply loads the module specified in the configuration file. If a module exports a variable called data which implements init, shortenURL and get and they do the same job as the existing MongoDB module, everything will work fine.

The one major compromise I had to make is to have the data module actually generate the next short URL. While not the end of the world this doesn’t sit right with my brain. I could have used a callback to have the main code do it, but this seemed like even more ugly so I’ve left it as it is.

The main reason for this is that the data module, by necessity, handles the atomic selection of the next short URL to be used. The fact that the current implementation is not actually atomic is neither here nor there; it should be! I can live with it until I can come up with something better.

Summary

Hopefully I’ll get some time to do a bit more testing on this code, iron out some rough edges, and make it production-ready. If I do then I’ll definitely consider putting it in to replace the existing JMP.LI backend.

I also want to implement a MySQL data provider that optionally uses memcache to cache keys. It would also be interesting to experiment with adding a simple, internal cache to the Mongo provider to save round-trips to the server, where it would also queue up updates to the hit stats and use periodic batch writes instead of doing it on-the-fly. I also want to sort the race condition in that module which means figuring out how to execute an increment operation using the mongo driver.

So that’s that. Another late night of writing code all in the name of learning comes to an end. Fun.

No, seriously… FUN!

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.

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.

Why didn’t TwitApps take off the way you hoped? Or did it?

It did, far more so than I’d hoped. When I shut the service down there were over 4000 active users and was growing every day.

If you had it to do over again, what would you do differently?

I wrote TwitApps Replies in response to Twply (see here and here for more info).

It was a technical exercise for me, not an attempt to create a product. The second tool, TwitApps Follows, was written in response to the bad press Qwitter was getting for being unreliable and essentially useless. I considered the whole thing to be a toy project for a long time and it took me a while to realise that people were starting to rely on the service.

So what I’d do differently is to either treat it like a proper product from day one, or make it clear to users that it was just a toy and should be used as such. A lot of the code I write outside of paid work comes under the heading of toys or technical exercises, and it’s rare that any of them gain the number of users TwitApps was fortunate to attain a relatively large number of users in a fairly short amount of time but it definitely taught me to be more careful in future.

Other lessons you learned?

Once you’ve established a free service, and that service has other free competition, it’s very difficult to monetise it.

It’s not easy to come up with unique features for something as simple as a notification service for new replies and follower changes.

It’s also very hard to change people’s impression of what something is once they’ve decided for themselves.

Why did you grow tired of developing for the API?

There were a couple of reasons, the first of which was the constantly changing rules. I developed TwitApps during a period of great change in the API, especially around the social graph parts. Keeping up with the changes, both in the API and in the access policies, made maintenance of the tools fairly intensive for a toy project.

It became difficult to juggle the time demands of supporting TwitApps with the requirements of a full time job, several contracts and the need for downtime. In the end something had to go and it was clearly going to be the bit that wasn’t earning any money.

What advice do you have for those considering starting a startup?

Make sure you know what you’re getting into, and what commitment your users are going to expect from you in terms of continued service.

If you want press coverage, do something worth being covered. The original version of TwitApps Replies was written in about 4 hours following my reading a post on TechCrunch about Twply. Once completed I emailed them to let them know it existed, and because it was a hot topic that day they covered it. If what you’re doing is not noteworthy don’t expect anyone to note it!

Anything else surprising/interesting about the whole TwitApps experience?

Twitter is a fantastic service, a platform with awesome potential, and a fundamental conflict between internal goals and the desire to support a rich developer community. I’m amazed Twitter themselves have not implemented some form of email-based replies notification, and I wouldn’t be surprised if it arrives at some point in the form of a paid upgrade.

The Follows tool is definitely going to arrive at some point, but probably in a less granular fashion. They have already hinted that follower analytics form a significant part of their upcoming commercial offering.

What do you think is the best way to finance a startup?

Personally I would not take any money from anyone else to start a company, but that’s probably because I’m a control freak! Seriously though, I would approach any project from the view that if I start small and prove the concept, then I can develop it further. I’d wait as long as possible before bringing more cooks into the kitchen than absolutely necessary.

What are you working on now?

Right now I’m contracting for a number of companies and looking for interesting projects to get involved in. I’m also working on launching myself as a professional photographer.

The reason I shut it down is because it no longer held any interest for me, but that would change if I could get some meaningful revenue from it. I know a lot of people really liked the services, and a number of people have said they would be happy to pay for it, so I think it’s worth gauging the level of interest out there.

So, my proposal is that I get version 2 finished and put the site back up. I charge a monthly fee, let’s say £5 for arguments sake, and that gives you access to all the tools on the site (currently Replies and Follows). Existing subscribers would automatically get access to new tools I develop for the site.

Please give me your thoughts about this. If there’s enough interest (enough to pay for the hosting and my time) I’ll bring it back, better than ever!