BillMonk

The founders of BillMonk talk about building a community site with Rails, email as an API, and dynamically generated graphics.

Interviewed by Geoffrey Grosenbach

Transcript

[opening music/poetry recitation]

Geoffrey Grosenbach: This is Geoffrey Grosenbach, it is the Ruby on Rails podcast, here at the offices of BillMonk with…

Chuck Groom: Chuck Groom.

Geoffrey:... and…

Gaurav Oberoi: Gaurav Oberoi.

Geoffrey: They run a site for managing personal finances with your friends, your roommates, all kinds of things. First we will hear all the details about that. Why don’t you start off, Gaurav? What is BillMonk? What do you do?

Gaurav: BillMonk is a site that helps you split bills and track debts. You mentioned roommates? That is a large number of our users, are splitting rent, utilities, groceries, bills like that. Other use cases for our site (popular ones) are going on a road trip, a ski vacation; lots of bills of all sorts that you need to split, and you do not want to think about them when you are on vacation with your buddies.

Half our site is all about splitting bills. It is about dealing with borrowing and lending with friends, taking the pain out of that. The other half is a different sort of borrowing and lending. I will let Chuck talk about that.

Chuck: All right, great. So after launching the money feature, it’s very popular, people started asking, “Hey, I don’t want to just borrow and lend money, I also have stuff that I am borrowing with my friends.” So we recently added the ability to keep track of the collection of things that you own, and also to track when you lend it out, lend a book or a movie or anything to a friend, so you can look at your collection and say, “Oh, here is what I own, and Gaurav is borrowing a particular copy of ‘Prince of Persia.’”

The other nice feature with the library is you can also browse what your friends own; which is great, because then you pretty much end up with an ad hoc community lending library.

Then we also very recently added the ability to make your collection, if you want to, completely public, to show it to friends and family, or anyone on the Internet, what you own, including a badge image that you can put on your MySpace page.

Gaurav: Or your blog.

Chuck: Or your blog.

Gaurav: Both the ideas around BillMonk are about borrowing and lending, and one of the interesting things for us is, we have this social network, you know, you and your friends, and we started with splitting bills among them, and then we layered new functionality on top of that social network. The people you split bills with are the people you trust enough to also lend your things to, let them know what is in your collection. So the two map really well together, and our users have adopted both.

Chuck: The commonality for both of these is, as Gaurav was pointing out, is your friends, people; and perhaps the most important page on the BillMonk site is the drill-down page for a particular friend, where it can tell you, “Hey Chuck, you owe Gaurav ten dollars, and this copy of a book.” It tells you in an actionable, clear way, what actions you take with your friend to settle up and become even.

Geoffrey: Now, can it tell you, “You owe Gaurav $300, but he has your Playstation, so maybe he can just keep that and call it even”?

Chuck: Sort of. We don’t make that kind of message explicit, although it is actually possible to sell the items to your friends. We actually look up our item data from Amazon, so we actually know the Amazon prices of those items, so we can actually propose, when you are doing a sale, the fair market value of your item. So, yes, is the long answer.

We also support multiple currencies, so you can actually owe someone dollars, euros, and they can owe you a few rupees, which is great for the international traveler.

Geoffrey: Oh, so do you do that conversion?

Chuck: We actually keep each currency in a separate bucket, which is good. But then we also offer, if you want to, we do look up that day’s exchange rate for users who want it.

Gaurav: And we do the math for you. So by default we store them in different buckets, but as you enter something you can say, “I am entering it in euros; I want it to be converted to dollars right now.”

Geoffrey: Okay.

Chuck: The reason being, if we do conversions for you people might disagree about what is fair or what is not. We would rather give friends the information they need to take actions, but we ourselves are not taking those actions. We are just giving friends the information so they can make the decisions about which exchange rate they are going to use.

Geoffrey: So you are not a collection service. It is up to them to actually work out the details, you are just giving them the information.

Chuck: Exactly. It is a general philosophy of BillMonk, actually, and this is pretty important, is that everything we do is informal. These debts we are entering are very clearly legally non-binding. It is actually really important, because people are more inclined to use the service if you can enter a bill that you are not exactly sure if the amounts are exactly right, you are just entering it now so you don’t forget, and you can go back and fill the details out later.

As well, it also frees you up from fraud. If you are entering non-binding debts then no one can really defraud you, because you can disagree with what they entered.

Geoffrey: Uh-huh.

Chuck: At the end of the day, BillMonk is a replacement for the pen and paper that you use to keep track of things like this. We want to provide a tool that enhances existing behavior. We do not really want to encourage or introduce a whole new sort of behavior and impose it on people.

So if there is a group of friends, and they go and have lunch every day, and they just round-robin deciding who pays, that is a great system and probably not a situation where these people would benefit immensely from using BillMonk. But roommates who end up getting annoyed, because I’m always buying the milk and no one seems to appreciate that, might find BillMonk as a way to smooth out and keep things happy.

So yeah, the reason that people use BillMonk is that tracking stuff with friends is really awkward. It is a common social problem, and really it is based upon information, just, you don’t know really who has been paying how much. We help you do the math of splitting bills, and we just keep a really accurate track of, “Why do I owe you this amount of money?” Friends tell us, roommates tell us, it just completely changes the roommate dynamic and makes everything much more peaceable.

We also hear from couples, too. It is a common problem with couples, making sure that you are staying fair, and one person does not feel like they are always being leaned upon. And more importantly, you feel like, if you have lent someone money, you don’t want to forget. You feel really bad if you have forgotten.

So it is a way to just offload all that stress and just say, “I am tracking it. It’s accurate. Done.”

Geoffrey: Exactly. Even people that you trust, you forgot that you loaned something to them, you’ve loaned it and then a year later that person still has it.

Chuck: Right, which is actually the nicest thing is, also, you are letting BillMonk be the one to remind them. So it is a third party, it’s a neutral third party that is reminding them. So you don’t have to be the bad guy, you can let BillMonk be the reminder.

Gaurav: And BillMonk, with the name and the branding, we tried to go with a sort of soothing, happy, neutral third party: the smiling, serene monk, as opposed to calling the web site LoanShark.com or something like that, which would give it very negative and scary connotations.

Geoffrey: Well we are here in Seattle. There is some big software company kind of close to here. Actually, there are several, but why choose Ruby on Rails when you were going to build a site?

Gaurav: One of the biggest reasons is Ruby itself.

Geoffrey: Okay.

Gaurav: The language, it is a pleasure to write Ruby code. It is very easy to write a lot of code and functionality quickly; and to write something that is maintainable and is going to stick around and be legible down the road. So you could say there are other sort of scripting languages out there, interpretive languages like Python, and why didn’t we pick that instead. Rails was the framework that was big and growing in popularity when we started doing this. Python had a couple, but they were nowhere nearly as popular at the time, and we didn’t know if this was something we could count on down the road, so we decided to stick with Rails.

Chuck: But the overall reason of why we are doing scripting language in a framework in the first place is, of course, speed.

Geoffrey: Speed of development.

Chuck: Speed of development, right. We actually started working around, I think it was August, September, October, that time frame. So we started, and we launched in January…

Chuck Groom:... why we are doing scripting language in a framework in the first place is, of course, speed.

Geoffrey Grosenbach: Speed of development.

Chuck: Speed of development, right. So we actually started working around, I think it was August, September, October, that time frame. So we started, and we launched in January, which is pretty rapid if you think about it.

Geoffrey: Yeah.

Chuck: That would not have been possible without Ruby and Rails.

Geoffrey: Yeah. Now, do both of you do the development or is one the business and ideas and the other is the coding? No?

Gaurav Oberoi: We split everything.

Geoffrey: You split it.

Chuck: It should be explained, by the way, that Gaurav and I come from a background of working at Amazon.com. We were both software development engineers there, too, and most of our coding there was done in C++. Which is great for a system that used to worry about scale as deeply as Amazon does. For a web site like ours, speed of development and maintenance are really the things we have to worry about.

Gaurav: So this was a far superior tool for optimizing for those concerns.

Geoffrey: I met someone a few weeks ago from Amazon, of course, there are a lot of people who do work or have worked at Amazon here, but they expressed doubt about Ruby because there were not any installations of Rails that were on 1500 servers all working together, like there were at Amazon; but it has taken them years to get to that point. Do you think, in five or ten years, could Ruby run on that kind of a setup, or is that a very specific thing?

Chuck: It is really hard to say, and I’m sure they are always testing sorts of things out, and I would not be surprised if they had an internal Rails development sandbox to play with. Knowing Amazon, they would probably be more inclined to try to build an infrastructure system like Rails, themselves, so that they could really tweak it for their needs. Again, this is pure speculation. Ruby is actually a language I would strongly encourage Amazon to use. I think it is actually easier for developers to code it and maintain. The legibility is so important.

Gaurav: And core business logic, where you are really not dealing with lots of transactions, and performance is necessary, this is just far superior.

Chuck: Yeah. The other thing is size of deployments, too. You have to worry, at a place like Amazon, about the size of your binaries, pushing them out and keeping them in sync. If you do everything statically linked with C++ you are going to get very, very large deployments.

Gaurav: And very long build times.

Geoffrey: Yes, OK.

Chuck: Ruby helps a lot with that, too.

Gaurav: Yeah.

Chuck: There is no compiling; you just deploy it and there you are.

Gaurav: The other thing is, Amazon’s architecture, and this has recently been public with, I think, an article that was published with [xx], is service-oriented architecture. So it is not like your end Ruby instances will all by talking to one giant database. They will be making calls to services within the company that store various forms of data, and massage it, and get it to a point where end consumers can do something useful with it. Ruby, really, the power there and Rails would be the MVC and front end and downloading, really, as opposed to doing a lot of data crunching or reading directly from the DB.

Chuck: Well I think the active part would be good for back end services too. Like Rails, at least.

Gaurav: Yes.

Chuck: Pulling that into a Ruby install itself would be a big win. The other thing about Amazon, I said this, was they also have a lot of Java, too. The reason I think Amazon is a great place to think about this in the future is that Amazon really encourages to have each team being fairly independent in its technology choices. So it is probably likely that one team will try out, you know, a small team will try out Ruby, and it will sort of gain within the company. We will see, “Oh, this team was able to this really quickly, they are winning, let’s go forth with that.”

I know they have some concerns about the way that Ruby itself is architected, though. There are some issues with Ruby if you run it at an extremely high scale, like if it runs out of object IDs. That sort of issue. So Amazon, of course, will have to look at this carefully, as well as security issues. You would have to do a full security audit, which will take time.

So for a really big company, these are the kinds of things which will just add a lot of overhead to getting it out there at the production level.

Geoffrey: Even today, I think yesterday and today was the first Ruby Conference in Japan, and it was announced that the next major version of Ruby, which depends on YARV and Virtual Machine, not until 2007. It seems a little far out. I was hoping it would be a bit sooner, but there are a lot of sites handling a lot of hits already with the current Ruby, so I am sure it will keep running until then.

Chuck: Oh yeah.

Gaurav: Yeah, and I think a lot of the constraints that sites hit have to do with things other than that language itself. How you design your database, your database access, does seem to be some of the first bottlenecks that people have.

Geoffrey: Now that is going to be a big point of contention as well. Did you guys feel like using the database to its full capability was how you wanted to design it, or did you use more of the built-in, 100 percent Ruby methods for constraints and validating data?

Gaurav: That is a great question. We diverged from using everything in Active Record for database access. Some of the common places we did that are so we have objects that are dependent on each other. I think the classic example is a blog post has comments. That sort of thing. In Ruby, you can use associations to automatically load these comments and save them. There are several situations in our code where we have decided not to stick with associations, and write our own logic on when and how stale data is written to the disk, or when it is read from the DB.

Geoffrey: OK.

Gaurav: That helped us write more interesting and complex policies on when we should do this, and also some transformations on the data right after or before we read or write it.

Chuck: It is only in a few places where we really have to. Other places, we go with the conventions. So our typical rule is, we do not really confine it to any performance or policies, we go with the conventions off of Active Record; but there are some cases where we have extremely complex models and policies associated with them, where we really have to control it at our end.

Geoffrey: OK, so sometimes instead of just using the built in “belongs to” or “has many, ” you will write your own so that it will be more optimized.

Chuck: Right. Optimized as well as, the other thing too, is you want to be very, very careful as to what the policies mean. So you want to make sure that sometimes if it is really, really vital to the functioning of your site that it is all right there, you own that logic, if it is really, really important.

Geoffrey: A lot of people are worried, “Oh, all these kind of functionalities built in! I have to use it, I cannot diverge from it.” But no, there is no reason.

Chuck: Well that’s the beauty: you can always overlook what you don’t like. You can write, well, “As a personal experiment I just want to write a very small app and not use Active Record. It is not something that I would do consistently, but just to kind of see, how flexible is the framework without all the rest of the pieces that are built in?”

Gaurav: I think one of the most powerful things about Rails is really Active Record.

Geoffrey: It is. Biggest amount of code in the framework.

Gaurav: Exactly. It is the biggest time saver, too. It gets you up and running the fastest.

Geoffrey: Yeah.

Gaurav: We are big fans of it in general. So another issue for Rails with us is documentation. It is a young framework, there is a lot of documentation, but not enough at the same time. So, dealing with some more advanced features, sometimes you do not know exactly how it works, and you need to put in a little bit of time experimenting and playing with it, so you know the boundary conditions and how these features are working internally. And at times it is just not worth spending the cycles to do that experimentation.

Geoffrey: Well getting back to the site, BillMonk, you have some interesting technological and user-facing features. For example, you can send an SMS from your cell phone and follow some different commands, and you can actually add items into your account from your cell phone. How does that work, and why did you think that was important?

Chuck: Actually, when we launched the site we thought this was going to be the killer feature; and our users love this feature. I think, actually, it is not THE killer feature, there are lots of killer features, as it turns out. The idea is, with the cell phone, you can report bills when you are on the go, which is really important. You are in a restaurant, you just want to report, “Hey, I paid for my friends. I…

Chuck Groom:... feature, and our users love this feature. Well I think, actually, it’s not the killer feature, there are lots of killer features, as it turns out. But the idea is with the cell phone, you can report bills when you are on the go.

Gaurav Oberoi: Which is really important, because you’re in a restaurant, you just want to record, “Okay, I paid for my friends. I want to stop thinking about it, deal with it later, ” if you are on a road trip with friends, if you are at a bar with friends.

Chuck Groom: You lend twenty bucks to a friend, you remember right there. Use your cell phone. Everyone always has a cell phone, and now you can send text messages directly to a computer, and let the computer then, use the computer system to tell you.

So our grammar is as simple as, let’s say I went to dinner with two other people and ran up a $90 bill. The grammar for that would be: ninety-space-three-space-dinner. There was a $90 bill, three people total, for dinner. You send that to us and we record it, and we respond saying, “We got your message. You are owed whatever your share is out of that amount.” Then you can go back later, online, and fill in the details. There are also ways to go back and forth and add the other people right then and there. Hugely useful, hugely popular. You see it especially with the lunchtime crowd, people going out together.

Gaurav: And vacationers.

Chuck: And vacationers, right. Now one of the things we did in order to launch quickly, and because we were very, very small, is we do not actually directly interface with the carriers. This is mostly for people in the U.S. People in the U.S. with cell phones can send SMS messages to an email address. So you send your text messages to an email address, which is the BillMonk domain, and then we can respond to that message which we receive as an email. Really super-easy interface there.

The way that other companies, like you might have seen Google or text groups, is they buy a short code, an SMS short code, five digits, and you can send your SMS message to that short code, and then it gets it directly routed to their computers. A lot easier experience for the user. I would like to go that direction in the future. Unfortunately, it requires a fair bit of money to both register that short code, a monthly fee to maintain it, and you also have to build relationships with all the carriers.

Gaurav: They all have to approve the application. It is a cumbersome and expensive process.

Chuck: Yeah, and individual carriers can actually reject it later if they do not like what you are doing with that service.

Geoffrey Grosenbach: Wow, so some will carry it and some won’t if there is that issue.

Chuck: Yeah. It’s a great user experience, but it involves a whole lot of business work, and when we were launching the site we had to focus on development. So we are quite open to doing SMS short codes in the future. We just weren’t ready for it when we launched.

Another option is also just to reserve a normal phone number, and do it as a sim card on the outside.

Gaurav: So the way it works is, we have a daemon process that is sitting and watching our mail queue. A message arrives, it reads the mail, parses it, and then our Rail stack has a web service API that it exposes to this daemon internally. So the daemon parses the message and then shoots it off to the API saying, “A new bill just came in. Here is who it came from, so here is who paid, ” and some other details. Then that goes through the same business logic that is being used on the front end, that we get to re-use, and goes and gets dumped into the database.

Geoffrey: Okay, so you are using your own API internally to communicate between the different things.

Chuck: Yeah, actually, yeah. So internally we are just using XML-RPC to communicate between multiple processes, which I highly recommend that everyone do if you have services that need to talk to each other.

Geoffrey: Okay, more than REST or SOAP?

Chuck:... or SOAP, any of those kinds of…

Geoffrey: Just as services.

Chuck: All those sorts of things, they are all cut from the same cloth, but using web services through an http-like protocol saves you a whole lot of pain.

Gaurav: It also means that our live stack servicing the web site, a) we are reusing a lot of this logic so we are not duplicating business logic and little applications on the side. We can also set it up to do a little bit of throttling, as well as retries. You can build a fairly stable system where, if the stack is down because we aren’t balancing it, or the mail daemon goes down, everything else still continues to work.

Geoffrey: Now, Action Mailer has some things built in where you can receive mail, but you are using a separate system.

Chuck: Indirectly, yeah. Here’s what we do, is we actually built our own system. Action Mailer is a great system once you have the mail object, once you actually have the email itself. Getting the email actually to mailers turns out, at least when we were looking at it; it might have changed, turned out to be sort of a horrendous pain. The way that it was recommended in the docs when I was looking at them, XM or go to Procmail, to spawn off a new process for each new email that comes in, hand it off to a Ruby process, which its action invokes Action Mailer. Which can be kind of heavyweight if you have a high volume of email coming in.

Geoffrey: So you had a new process for every one that is… yeah.

Chuck: So what we actually do is we keep Action Mailer in the Rail stack, and you just create a daemon which is just aware of looking at the local directory of spool files.

Gaurav: This is a little Ruby program that does not use Rail.

Chuck: It’s really easy. It doesn’t peek too deeply into the mail message itself. It does a little bit of spam-checking, it can block people if we need to, and then it sort of bundles up the message itself and just throws it onto the wire for the Rails app to actually use the Action Mailer on, and then do the interpretation of business logic on.

But it is really smart. If the Rails app is down it will keep the message locally and retry.

Geoffrey: Okay.

Chuck: So it’s really nice. You let XM do what XM does, just drop the mail off; the mailer is the one responsible for making sure that it gets to the Ruby app; and then the Ruby app just handles the business side of it, it does not handle the actual messy system logistics of moving messages around.

Geoffrey: And you are not duplicating code anywhere, because the Rails web service is handling all that.

Chuck: The nice thing is, also, you can make your mailbox an actual different physical machine than the Rails box. So it also allows you to scale in the future by creating a box dedicated just to mail if you wanted to.

Geoffrey: That’s brilliant. I’m using something remotely like that and I should try that, because it seems like with big attachments, photos, files, whatever, sometimes just the built-in would just kind of croak on that. So some other kind of accomodation could handle not only more emails at once, but bigger individual emails.

Chuck: It should be pointed out, too, that we actually use email for two different things internally. One is messages that you can send to the service, and then the other of course is just our support queues. We really like it when customers contact us, and then we actually use this stack to deliver the message reliably to, we have another app which we use for tracking customer contacts.

Gaurav: Right. So what Chuck is describing is, there is an application that Chuck and I monitor all the time, and it just says, “Here are the latest open messages in your queue, ” and then either of us can click on it, lock the message, respond, and it will keep track of the whole thread, as well as any annotations we put in there. It allows us to do extremely fast and diligent customer support. It was written in Rails, I think Chuck wrote it in a couple of days, one day.

Chuck: One day.

Gaurav: One day, and then we used the mail daemon and basically said, “Now listen to the mail queue for the help queue, and as soon as a message comes in, XML-RPC this new Rails app and say, ‘Here is a new message.’” So it is actually a nice bit of software that we might consider open-sourcing.

Chuck: Yeah. The other nice thing about the mailer daemon too, of course, is that it runs in user space, so you do not have to worry about running it as the XM user. That’s nice too.

Geoffrey: Okay, so it’s a little more secure.

Chuck: It’s a little bit more secure, definitely.

[short interruption to straighten out whose coffee cup is whose, and who is paying for the coffee they are drinking]

Geoffrey: So you are also using graphics in an interesting way, so people can actually post a graphic of their collection, or at least part of the collection, on MySpace or other sites, and not have to use JavaScript or some of those other things that are being blocked by some of the major social sites like that. How do you do that?

Chuck: Okay, so I’ll start and Gaurav will get into the actual logistics.

The library itself, which is where you can keep your collection of stuff, you can actually enter items in two ways. You can describe it yourself, and you can tell us, like, if its a book we will ask you for the title and author, for example; or you can actually just search, we have the interface to search on Amazon for the item and add it that way. The thing about searching on Amazon is typically it tends to be faster, and you get all the rich item data from Amazon, including pictures of the actual item in question. Most people, like, I think 90 percent of our…

Chuck Groom: We actually have the interface to search on Amazon for the item and add itthat way. The thing about searching on Amazon is it typically tends to be faster and you get all the rich item data from Amazon including pictures of the actual item. Ninety percent of our items are Amazon items.

Geoffrey Grosenbach: OK.

Chuck: But the nice thing about adding it yourself is if it isn’t on Amazon or you don’t want to use Amazon, you don’t have to.

So the idea is, that most people have collections and they’re proud of their collection and want to show it to people. People have a sort of pack rat mentality.

[xx] and it’s like, look what I own. Which is great. We love that kind of user. We wanted a way to let people publicize on MySpace or their blog, what they own. It’s an easy to get a snippet showing stuff that they have. The idea is that they would automatically go to BillMonk and grab a couple of their items at random and show them on those pages.

Now the problem was, there was no way for us to actually have this code for dynamically generating that system on those other services because Java typically is not enabled.

Guarav: [xx] iframes? So you can’t even have a window where we have the logic on our end.

Chuck: So you’re kind of constrained. We decided the easiest way was to have a link to an image on BillMonk. BillMonk is serving up an image and we would actually render into an image we store locally in cash and periodically update a picture which looks like a tiny graphic showing ” Here’s what So and So owns. Go to BillMonk.com and see the rest of their library.”

Guarav can talk about the actual rendering aspect of that.

Guarav: Some of the constraints were, if you’re requesting an image, you should get a response back from our server ASAP because we don’t want your blog to load slower because of this image on BillMonk.

Furthermore, we also don’t want our rails app to be spending a lot of cycles actually generating these images and in case something goes wrong through the process, we have Apache threats that are stuck and not able to serve other requests down the road. So we designed a system whereby a request comes in for an image, we have an action and a controller that intercepts this request. At that point it says, Is there an image for this that exists on disk right now? If there is, return it. If there isn’t, make an Eximo[sp]RPC column to another application that we have sitting on a different box, when many more cycles were processing. It receives it and says I’m now going to spend my own time generating this image. Then it will be available here on the file system. We basically return a pointer to that file system.

Chuck: So the idea is that you always synchronously return an image which you have at hand. Asynchronously saying ” Hey should I return a new one?”

Guarav: What happens is, we also roll the dice everytime you send a request to us, we’ll roll a ten-sided die and say” Is it time to regenerate a new one, return what’s on disk as well as well as send a request to generate a new one so that something new appears on the blog next time.

Geoffrey. : OK.So Rails has a kind of cashing mechanism built in which requires that one server is going to do the graphic and the cashing in but you kind of split that out so that one server can be generating the graphics and the other one can hand it off and continue happily surfing up the rest of the web page.

Guarav: Exactly.

Chuck. : So Guarav, you should talk a little bit about how the graphics themselves are actually generated and what we would have liked.

Guarav: What we’re using is Ruby libraries for image magic. When a request is made, we basically go to your library and say” Find five random books that you have, make calls to Amazon to fetch these graphics on to disk and using image magic libraries, piece the book covers or DVD covers together, write the titles next to them, stick it all into a nice little badge format with a BillMonk header and footer and dump the whole image to disk. The image magic libraries are nice enough that you can actually do all of this in memory and do one disk write. So you’re really processor bound, which is nice, as well as network bound, to fetch the five images from Amazon. But you can do some interesting cash in there. Some of the other things we are considering down the road for badges are using something like flash, where we’ll actually move away from using this whole image setup, but flash has its own expenses associated with it.

Chuck: What would have been ideal is if there was a way to render a web page, so we could actually create our own internal web page, and actually sic gecko at it and say render this into a jpeg. There’s one company that does this but it’s proprietary. It’s an open source application just begging to written. Or just a plug-in actually. Here’s a chunk of html, render it with gecko and dump it to a disk as a jpeg and have it available.

Guarav: Browsers are so good at, HTML is a language everyone understands, they’re so good at rendering beautiful things. If there was an easy way to just dump these images, I think there would be lots of applications for it.

Geoffrey: Then you could just use a regular Rails template, you could render the HTML, and that would get piped off to some little graphics [xx]

Chuck. : That would be dreamy and I think it’s an application that’s just ripe to be written.

Guarav: Well email us if you guys are interested in it.

Geoffrey: Well thanks. That’s very interesting. I already have signed up for BillMonk, but I’m going to have to use it a little bit more, now that I know the people that made it and all the features. You got a couple thousand people using it so far, but it’s still early, still young.

Chuck: We have 7500 users using it.

Geoffrey: Wow.

Guarav: We have 30 different currencies actively in use, so it’s very worldwide. It’s interesting how that happened. We’re growing and beginning to focus more on marketing, so we can get the word out.

Chuck: That is something. Guarav, the currency thing is really important for anyone creating one of these applications to consider, is that you will have a humongous user base across the world, not just in the United States, so you really should design your application keeping that in mind. We don’t support multiple languages, but just having multiple currencies was a feature our users begged for, we delivered on and they really responded to.

Interesting thing, the biggest, in terms of volume of receipts user, outside of the US is Singapore.

Geoffrey: Singapore? So people do a lot of social borrowing and lending in Singapore.

Guarav: Looks like it.

Chuck: And also the people using the Euro are the next biggest group.

Guarav: Most interesting currency, I think, is from Kazakstan, the Tangay[sp]. We had someone writing in saying, ” Can you please enable me?” We have a couple of users out there.

Chuck: One of the weirder things we did is, we also added support for virtual online game currencies, like World of Warcraft Gold.

Geoffrey: So you can borrow and lend.

Chuck: Our thinking was, it’s pretty easy for us to add currencies and these are things that perhaps friends really are borrowing and lending gold in World of Warcraft, why not track it on BillMonk? Some people are actually using these for borrowing and lending stuff for weapons and whatnot. Some people also use it in terms of tracking with friends, general favors owed. [xx] Sometimes perhaps you use it for real dollars, sometimes for something else. We don’t know, we don’t care, just as long as it makes people happy, we offer it.

Geoffrey: Now Chuck, to me you’re famous because a couple years ago, I played your game called Spiked for the old Mac and you just had two little planes flying around, you had to try and bump another one into a big spinning spike in the middle. Any kind of integration planned with Spike?

Chuck: With BillMonk?

Geoffrey: With BillMonk.

Chuck: (laughing)There’s actually going to be a sort of secret web page, like an easter egg, where you can play an online version…No, no.

Guarav: Whoever wins, eats all the debt.

Chuck: Spike, I wrote that actually when I was in the end of high school, started college. Two-player game, same computer. Lot of fun. Wish I had more time to write video games.

Geoffrey: I tried to download the source code, but that server is no longer up, so maybe I’ll have to get a copy.