mortals wear shoes
I was out on a boat trip just off the coast when we spotted some dolphins. The adults came over by the boat and led us away from where the babies were feeding, which of course made for some great photos. Here are a few - apologies for small file size, but uploading from here is a pain.
From mj:
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.
From Cimota.
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
Here’s the scenario: you’re writing a green field web application. This application will be used to power more than one e-commerce site, which means that it must be easily tailored. You can use any toolset you like, and the requirements are fairly standard (e.g. exporting data to CSV, modern UI, payment gateway, etc.). What do you choose?
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?
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:
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.
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:
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.
I’ve been quiet for a while on the blog, so I thought I’d post a quick update on what I’ve been doing.
Work on Rickshaw has been progressing very well. It’s approaching the Release Candidate stage now, where we go through and deliberately try to break it, try installing it in strange set ups and so forth, in order to make sure it is as robust as possible. I’ve found bugs in Connection Kit which have held me back, and I’ve contributed a couple of patches to it (I’m working on a third, to ensure that .Mac uploads work correctly).
We’re working with Jordan Langille from One Toad Design for Rickshaw’s icon design, and looking at a long-term partnership with Jordan for other projects.
Rickshaw is working fine - I even use it to distribute copies of the latest version to the rest of the Infurious team - and I’m happy with the quality of the main engine. All the rest of the work has been putting the wrappings around that engine. In fact, that puts me in mind for another blog post …
The 7th Ironcoder contest was announced today (for some definition of today - damn those pesky time zones). I think this year I actually feel confident enough to take part, even if I accomplish not very much 
For those who have no idea what it is, each contest selects a theme and Mac OS X API, then gives you 48 hours (real time) to write an app that has both theme and API centrally featured. Check out the Ironcoder site for more info, or take a look at the entries for Ironcoder 5.
Here’s a quick preview of the product I’m currently working on. It’s called Rickshaw and it’s designed for people who like the convenience of sending (large) attachments via e-mail. Using Rickshaw your attachments are stripped from the mail as it is sent and uploaded to your designated server. The attachment is replaced with a URL that allows the recipient to just download what you sent at their leisure.
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)
If I forget myself and accidentally order one I certainly never order a second (I usually drink hot chocolate in Starbucks).
In the UK, all the wi-fi at Starbucks is through T-mobile who charge £30 ($60!) a month to use their hotspots. With a 1Gb download limit.
One of the biggest issues I had back when I was working in a coffee shop all day was that I’d get too comfortable in the chair and not move around as much as I should (eventually I got tendonitis). At least this way I always get up and leave after an hour.