They break out the infrastructure and make it P2P. This could shift the responsibility for uptime to others and allow them to host their own options for advertising or value-added services. Maybe even license the software out so there are a bazillion twitter servers out there. This would be the method by which Twitter could sneak up and murder Instant Messaging in it’s sleep. I tweeted recently that Twitter was not Broadcast IM. But, of course, it is.

Reminds me a bit of Zed’s UTU project.

To speak to some of the other points that mj makes (and bear in mind I’m only a recent Twitter user), I think that Twitter could monetise easily enough. There is definitely a stigma against running adverts on your website - I know I don’t do it on any of the sites that I run, even though I know I would make some money. But consider the sorts of users who use Twitter a lot - they are the same sorts of people who are happy to pay $10-$25 for an app to allow them to use Twitter more easily.

Twitter haven’t charged anything for their API or the right to use their service as a platform for making money, which no doubt has earned them a lot of kudos and is probably another reason for the large uptake. I’m certain that a portion of those people who use their service every day, n times a day, would be willing to pay that $10-$25 for improved services. I think mj is right with things like being able to add pictures, having URLs automatically “tinied”, being able to make their own look and feel to posts and so forth. Would it make enough?

I don’t know how many users Twitter has, but I’m willing to be that all of the active ones fall squarely in “Early Adopter” (if you subscribe to the Crossing the Chasm metaphor). In using the Twitter site, I’ve been a bit underwhelmed by it’s functionality. Keep the free service, improve it gradually, but innovate like crazy in a pay-for service.

One possible ego-stroking mechanism. Make it such that you must be on the pay-for service if you have more than 100 people following you.

None of them are particularly spectacular, but I felt I should let people know a bit about what I’ve been working on. I’m also working on a website for a Cyprus property investment company, which should be done in the next couple of weeks.


cat ~/.zshist | awk '{a[$1]++} END {for(i in a)print a[i] ” ” i}’ | sort -rn | head -10

2870 ls
2444 cd
659 vi
348 rm
254 svn
232 ssh
206 telnet
182 whois
180 egrep
179 sudo


1. Off-the-shelf e-commerce engine
2. Open-source e-commerce engine
3. Build your own

So, it seems you’ve got three options (anyone think of a 4th?). Of course within each of these options there are any number of competing solutions, especially in “build your own”, where you could potentially use any language, web server, etc.

I think with any software developer, the preference is to build one’s own. That way you get ultimate flexibility and intimate understanding of the code, which makes it easier to expand and customise. The downside is that you have more work up-front in order to get running.

Off-the-shelf (i.e. commercial) software tends to have a lot of features that your accountant and fulfillment department would like, and often gives you the ability to customise using one of a few popular languages or their own pseudo-language. The real advantage is that you can have a store quickly, or so you might think. Often, shoe-horning your data into their proprietary and closed-source format makes this option longer and more expensive than building it yourself.

All of which leaves open-source engines. You can be up and running quickly (like with commercial apps) but you have access to the source code if you decide you need to change things the way you want them. Potential downsides are lack of support and lack of particular features you might need (e.g. a particular payment gateway).

So, which would you choose?

write the simplest code possible to show one thing working end-to-end

This can be as horrible and hackish as needed. I regularly hardcode things like URLs, integers, strings, file names/paths: whatever is needed just to show that the idea works. E.g. for Rickshaw, I started off by always sending a file called rickshaw.png, which just got removed and replaced by a URL - the URL in the e-mail was hardcoded to be a reference to http://localhost/~aidan/rickshaw.png, and I happened to have the file in that directory. The whole workflow appeared to work, even though none of the upload magic was there. I proved out two concepts though:

• that attachments could be manipulated after sending
• that the resulting e-mail still made sense

2. Add to it

write the next most important bit simply, then test it all

This can be harder than you think. Not the writing, but choosing what bit is the next most important. For me, I wanted to have that file be written dynamically. The important thing is to keep it small - do it, test it and be happy with it. Some things lend themselves to automated testing: some don’t. I’m a fan of test-driven development, but I don’t get hung up on ensuring coverage - look at Microsoft Windows Vista: excellent automated test coverage, crappy user experience. Test manually where it makes sense, and automatically where needed.

3. Repeat step 2

You go from your tasks being “remove hardcoded URL and replace with URL generation code” to “Add application icon” and “Build website to sell app”. One step at a time, doing the most important thing at any given time.

Rickshaw had no user interface for quite some time - it was just a plug-in that was copied from the command line. Eventually that was good enough that a UI for configuring it was the most important thing. Then a button that tested the configuration before using it. Then some code to install the plug-in. License keys. Usability enhancements. And so on.

None of this is new or original - it’s all common sense, especially if you’ve worked in an agile development team before. The great thing about working this way is you see results early on. I had a working prototype of Rickshaw which did “uploads” to localhost (using NSData writeToFile:atomically) within a week, and real uploads within three weeks. The downside is that you feel very close to finishing at an early stage.

If you consider the entirety of what’s needed to build an app as being 100% of the effort, I’d lay out the effort required for different parts as something like this:

• Hack to prove concept: 5%
• Prototype to prove hack: 15%
• Making prototype robust: 30%
• Getting it ready for users: 50%

Open source projects are one of the first three stages (corresponding roughly to ‘alpha’, ‘beta’ and ’stable’ projects). The last stage takes just as long as the first three, and it’s the reason why commercial Mac apps (in particular) are better than open source apps for Linux - as much time has been spent getting the application to work well for users as has been spent getting the application to work for the developers.

If you’re developing an app for any platform, ensuring you spend the time in that last stage is what will make your work stand out.

This product is primarily aimed at people who have to work with large files and need to send them to multiple recipients - avoiding issues with mailbox quotas, mail server file size limits or file type restrictions and so on. More details about how to use the product will follow, but here’s a quick video showing it in action.

Enjoy! (also available as a QuickTime movie)

syntax error before ‘AT_NAME’ token

The problem is that you are missing an @end in some file that you’ve #imported, probably a header file. This error also shows up as “parse error ...” in some versions of Xcode (took me a while to track down with Google as a result).

Getting started

If you are about to use subversion, your administrator has probably given you a URL for your repository. This could have a number of forms, but for our purposes they can all be treated identically - I’m going to use the fictitious URL http://example.com/svn/repo/trunk/project. The repository (as you probably know) is just a central store for all the files for a given project, along with version information. The first thing you’ll do is create a working copy of the repository on your computer.


svn co http://example.com/svn/repo/trunk/next_big_thing


Subversion will spit out some information about what it’s doing - ignore that for now. What’s happening here? It’s very simple.svn is the subversion command line application. The co command is short for checkout, which tells subversion to go the URL supplied and bring back a copy of the latest version of what’s there. This will create a directory (or folder if you prefer that term) with the same name as the bit after the last / of the URL - in this example: next_big_thing. That next_big_thing directory is your working copy of the repository.

Everyone who works on the Next Big Thing project will need to perform this same sort of checkout to their local computer. What lives in a working copy? Any sorts of files that you like: documents, source code, images, etc.

Editing and changing your working copy

Go ahead and fiddle with stuff in your working copy - you can do anything you like because none of it will affect anyone else until you commit your changes back to the repository. Put some files into the directory, edit what’s already there, delete some as well - you can get it all back the way it was very easily. But first, let’s take a look at what’s changed (yes, that means you actually do have to go and change some things in your working copy: go on, I’ll go get a cup of coffee while you’re doing that … ready? OK, good). Run this command (from within your working copy - anywhere will do, but the top-level folder is best):

svn status

You should see a list of the changes you’ve made, with one of three characters beside them. Don’t worry about anything else that is spat out at this point (if anything).

? foo.txt - a file you’ve added that subversion doesn’t know about (yet)
M bar.txt - a file you’ve changed (M stands for merge, which is what happens to this file if you commit your changes)
! baz.txt - a file you’ve deleted

Adding files to a repository

You’ve put some files into your working copy, but there’s another step that needs to happen before they can be committed to the central repository.

svn add mynewfile.txt

Naturally, you substitute “mynewfile.txt” for the name of your actual file. This tells subversion that you want to add the file to the repository the next time that you perform a commit (which we’ll get to in a moment). Why is this step necessary? There are any number of reasons why you wouldn’t want to automatically commit any file in your repository. The most common is probably that many programs create backup or temporary copies of files in a directory while you’re working on them - it wouldn’t be good to clutter up the repository with cruft. Subversion itself creates temporary files when there’s a conflict (yes, even in version control there is conflict - I may do another guide on how to deal with that).

Likewise, to delete a file you need to use:

svn delete myoldfile.txt

otherwise subversion gets confused. When you use add and delete, you’ll get a different status beside your file when you run that command - it’ll be A and D respectively (instead of the ? and ! that we saw above).

Holy crap! I didn’t want to do that!

As I mentioned above, it’s easy to get things back the way they were. If you want to back out any changes you’ve made to the whole project, do this in the top-level directory:

svn revert

You can also use svn revert myfile.txt to revert individual files (or directories).

Committing to the repository, and getting updates

So, now you’ve made all the changes you want to make, it’s time to commit them back to the central repository. This is where all the actual version control magic actually happens. Run this command from the top-level directory of your working copy:

svn commit

The first thing that will happen here is that a text editor will start up (usually vi). Enter a comment describing your change and then save and exit (in vi that means typing ZZ in command mode).

This will take all the changes you’ve made and upload them into the repository, commented with what you wrote. Now the next time someone runs svn co ... all your changes will be visible to them. If someone else has also committed some changes, you can get the latest version with (from the top-level directory):

svn update

You will probably need to run the update command before you do a commit so that you have the latest version of the repository before trying to change it. Any time you (or anyone else) runs svn commit, the version number of the repository goes up by one. In this way, it’s easy to tell the state of every file in the repository at any particular point in the repository’s history, and it’s how you avoid having one person overwrite all (or worse: some) of the work done by someone else.

What’s changed?

You can see the changes that people have made by using

svn log

Be careful with running this in the top-level directory of your working copy - you’ll get every commit message for the project since the first revision. Usually this is run on an individual file to see the history of that file.

And I’m spent …

That’s it - you now know the absolute basics of subversion. For more detail, I suggest reading the online Subversion Book. Any questions, comments or inaccuracies can be sent my way.