January 19, 23:46
Todo lists have long been one of the favorite features in Basecamp, so we thought it would be a nice experiment to share that particular feature with the world at large. Free of charge. And Ta-da List was born!
A few user-oriented highlights of Ta-da:
- Extensive use of XMLHttpRequest: Adding new items and checking them on and off are done with remote calls that change their state in the database while simultaneously updating the view using Javascript. This makes it really, really fast to add new items to a list — and you're not restricted by the 10 predefined fields that most apps like this does.
- Loose sharing with unique URLs: Sharing a list with a single or group of buddies is easier than ever as there is no password to remember. Instead, everyone just gets a unique URL that they can bookmark right away. At 32 characters and as a MD5 hash, it's plenty of security for this type of application and much easier to use.
- Collecting all the shares: By allowing you to share any list with any email address, we already got the viral thing going. The barrier of signing up has been postponed until you're hooked, and once you are, you automatically collect all the shares as you signup. This means that they're all available from your dashboard and you can reduce the bookmarked lists down to one URL.
And for the technically inclined:
- Three levels of caching: I implemented page, action, and fragment caching for the Action Pack in Rails so I could be able to use it in Ta-da. And it's working exceedingly well. Lots of pages went from 50-70 req/sec to 400-1100 req/sec due to caching.
- 579 lines of code: That's including models, controllers, and helpers. It's really lean and really readable too. It was great to see just how small you can make an application with a recent version of Rails (especially the 0.9.x series) on a fresh code base. In Basecamp, I'm often working on code that predates the release of Rails, so it's a nice change of scenery.
- Finally FastCGI: Basecamp is still running mod_ruby for various reasons, but Ta-da is fresh out the gate on FastCGI. And what a difference it makes in memory consumption! We're currently running five FCGI processes (which is more than plenty) that come in at about 15MB a piece. On top of that, we got 50 Apache processes at just around 3.5MB a piece. That's just 250MB for the entire setup. Much unlike the situation on Basecamp where we have 40-60 Apache processes of 40MB a piece.
In addition, it seems we're off to a flying start as we blew through 1,000 people signed up in just a matter of hours! And it's getting blogged all over the place. Justin French has a really nice post about how he switched his workflow over. And Tobias Luetke already whipped up a script to integrate Ta-da into your site using Ruby.
Challenge by Chriztian Steinmeier on January 19, 23:54
I can see you're looking for a DHTML Calendar Widget - I've built one, mimicking the one in PalmOS, that you could check out - hvis det var noget...?
Challenge by Matt Albright on January 20, 0:34
I don't understand where the extra memory footprint comes from between fastcgi and mod_ruby. I would think the footprint of a mod_ruby process would be the sum of a dry apache process and the ruby process... do you have any idea why it is so much smaller?
Challenge by David Heinemeier Hansson on January 20, 0:46
The problem is that mod_ruby is married to the Apache process. And since its random which request hits what process, you end up with all the Apache processes holding the entire Ruby image with all of Rails loaded.
This is unfortunate as I think Basecamp could probably get by with 10-15 FCGI processes and then have stripped down Apache processes for serving images and other statics. That way we could have 10-15 FCGI processes at perhaps 35mb a piece. And then another 40-50 Apache processes at just 3.5MB a piece.
Much lower overall consumption.
Challenge by Matt Albright on January 20, 1:05
Oh, right... I was trying to compare apples to oranges... process size for Ta-da vs. process size for Basecamp.
I understand what you're saying now... you can get by with less "fat" processes by having "thin" image serving apache processes.
I thought (actually hoped) you were saying that there was some per-process memory savings to be gained by switching from mod_ruby to fastcgi. Now I realize you were just saying you gould get by with a smaller number of big processes using fastcgi.
Challenge by RonaldMatt on January 20, 14:45
Non-english todo list can't display correctly in browser.
Challenge by Julian "brainbomb" Suschlik on January 20, 17:11
Using lighttpd (http://www.lighttpd.net/) you can decrease your memory-footprint down to 350kB/instance with full FCGI-fuctionality.
http://www.lighttpd.net/ itself uses ruby and rubyonrails.
Challenge by Andrew on January 20, 17:47
Excellent work, as always, David.
I have a question about your use of XMLHttpRequest. It seems like you're using it simply as a mechanism to send data to the server without a page refresh and there's actually no XML involved. Is this correct? If so, why not just do a regular page request and have the server return a 204 (no response) code. I believe that this would accomplish the same thing without any worries about browser compatability (and with less lines of code). Or am I missing something?
Challenge by Dave on January 22, 7:06
Hi,
I found a simple highlight bug. On Mozilla Firefox 1.0, when you reorder the list and move an item, the fading-highlight effect works great, but if you click on 'My Lists' and go back to that same list, the item you just moved is fully highlighted again.
Great job,
Dave
Challenge by Chriztian Steinmeier on January 23, 23:20
Andrew: When creating new items the server returns the ID of the new item, thus a response is needed. Checking items on and off does not require return values though...
Challenge by Mhenry on February 01, 23:45
I have to second the lighttpd (www.lighttpd.net) comment above.
It has a MUCH smaller footprint than Apache does, and is a lot faster at serving static content. Funny thing is, it's also easier to configure.
It's a shame the documentation isn't perfect, but it is getting better.
Challenge by abba on March 22, 9:21
de Mikel-Angelo. Ni decidis uzi kontrau li rimedon, per kiu ni venkis jam multajn gvidistojn -- malsago kaj idiotaj demandoj. Ci tiuj kreitajoj nenion suspektas -- ili tute ne komprenas la sarkasmon. Neniam dum mia vivo mi estis tiel kontenta, tiel trankvila, tiel plena de bena paco, kiel hierau, kiam mi eksciis, ke Mikel-Angelo ne vivas plu. Ni eltiris ci tiun sciigon el nia gvidisto. Li kondukis nin tra mejloj da pentrajoj kaj skulptajoj en la vastaj koridoroj de Vatikano, tra mejloj da pentrajoj kaj skulptajoj en dudek aliaj palacoj; li montris al ni la grandan pentrajon de la Siksta Kapelo kaj freskojn, kiuj suficus por freskigi la tutan cielon, -- preskau cio estis farita de Mikel-Angelo. Ni decidis uzi kontrau li rimedon, per kiu ni venkis jam multajn gvidistojn -- malsago kaj idiotaj demandoj. Ci tiuj kreitajoj nenion suspektas -- ili tute ne komprenas la sarkasmon.
Challenge by free poker on June 21, 9:21
You can also check out some helpful info on free poker free poker http://www.poker-adventure.com/free-poker.html ... Thanks!!!
