An office-mate and I wrote a small piece of “social software” a week or so ago. If you prefer, you can call it a “web app,” but at the end of the day it’s just a virtual cork-board.
In the computing lab we try to get a group of people together for lunch. This takes effort and coordination; if you use email, you get around five or six messages just for people to say “I’m eating at 12:30.” Sometimes, people say “I’m in,” or they say “I’m eating at 12:00 because of a meeting,” but really… it’s a lot of mail traffic just to say “Hey! Let’s have lunch together!”
Using LunchApp, you choose the time you’re going to lunch (or coffee, or tea, or dinner, or …), enter a short message, and hit “Submit.” By default, the system username is grabbed, but a number of my fellow PhD students have picked humorous pseudonyms for this kind of thing; normally, I often go by Spock, a carryover from many years ago. Removing your message is simple enough as well: just type “remove” in the message area, and your message is removed.
We’ve been testing it for a week or so now; lunch emails have fallen off considerably, which is good, and we even have one or two people outside the department using it; this is a good sign. We’re about to make one or two updates for usability (defaulting the drop-down to 12:30, etc.) and then we’ll release it to the rest of the department.
If you’re interested in the technical bits: LunchApp uses XML-RPC to post a message to a server. Every few minutes, the app checks to see if anything has updated. While there are better ways to find out about updates, this approach helps guarantee that firewalls won’t be a problem for users (eg. we can’t use a publish-subscribe model when incoming traffic is blocked). The client is written in Java, and uses the Apache XML-RPC library; the server-side is currently written in Scheme using XchemeRPC, but I will likely rewrite that in Perl (using SOAP::Lite) to improve response times and lighten the load on the CGI webserver.
Why XML-RPC as opposed to some other protocol? For example, why didn’t I just use HTTP PUT and GET (a RESTful solution)? In this particular case, using XML-RPC made it very easy to write the client and server quickly; put another way, it allowed us to use libraries on both sides, as opposed to rolling our own solution. The server took no more than 15 minutes to write, and it just worked; the client only took longer because GUI work is that way. However, at no point has the networking and client-server work been a problem. It was far simpler, in this case, than mangling HTTP POST and GET statements between the client and server.