When I read about insoshi on Mashable and TechCrunch this morning, it got my mind buzzing… and immediately my thoughts turned to another Y Combinator startup–Heroku. I’ve been using Heroku for quite awhile now, and both my fondness for Ruby on Rails and my disdain (so far) for Google’s Big Table make it my prototyping engine of choice for the time being. The integration is not perfect by any stretch of the imagination, but here’s a quick and dirty way to get an insoshi install running on Heroku (assuming you have an acccount):

First Steps

1. Download the insoshi tarball
2. Create a new heroku app
3. Import the insoshi tarball (how convenient is it that the heroku app importer wants a tarball!)
4. Run rake db:migrate (this will run a ton of migrations… once complete you can press escape to close the little popup)
5. Run rake install (this will create the default preferences file and the default forum.

Hiccup #1The session variable in Heroku is enormous… so jamming it into the pageviews table causes the app to choke. Solution: well, we’ll just toss out that data for now. I’ll try to come up with a more elegant solution later, but for now the goal is simply getting the app to run. The stack trace points you to Line #30 of app/controllers/application.rb, where the page_view is inserted. Comment out Line #32 (“:session => session,”) and save. If you refresh the app, you should now get a totally blank screen.

Hiccup #2

There seems to be some sort of conflict between the Heroku toolbar and the css of the stock insoshi install. Luckily, this is fixable. Go into your config directory and create a new file, “heroku.yml”. Add two variables and save the file:

toolbar_collaborators: false

toolbar_public: false

Refresh the app again and you will now see the blank install of insoshi! We’re not quite out of the woods yet, though.

Log in to your default account. The email address will be “admin@example.com” and the password will be “admin”. Insoshi will immediately prompt you to change these away from the defaults.

Changing anything on the profile-edit page and pressing submit will take you straight to another rails crash… but this one is a little misleading. Your edits actually went through fine, it’s the redirect that’s crashing. There’s a SQL call on Line #310 of app/models/person.rb that needs to be modified to be compatible. What was originally:

sql = %(SELECT connections.*, COUNT(contact_id) FROM `connections`
WHERE ((person_id = ? OR person_id = ?)
AND status=?)
GROUP BY contact_id
HAVING count(contact_id) = 2)

Should be changed to:

sql = %(SELECT contact_id, COUNT(contact_id) FROM connections
WHERE ((person_id = ? OR person_id = ?)
AND status=?)
GROUP BY contact_id
HAVING count(contact_id) = 2)

Note that actually TWO changes have been made. First change “connections.*” to “contact_id”. Second, get rid of the goofy ` characters surrounding the word connections in the FROM clause. Refresh the page and you should now be good to go on viewing user pages. You may need to kick your Heroku app to get it to restart (I usually just change a single character in the config/routes.rb file and save for lack of a reset button).

Hiccup #4

This one’s a little obscure. Sign out of your account and click on the “People” tab. Click on the one user (”admin”), and rails will complain once more. I haven’t quite figured out WHY this one is breaking, but I did trace it back and toss in a workaround. The error occurs on Line #42 of app/views/people/show.html.erb. If you call Connection.connected?(SOME_PERSON, nil) in the Heroku console, the app will correctly return false. Though you are not logged in, the current_user variable is actually set to “false” as well. Calling Connection.connected?(SOME_PERSON, false) causes it to choke, which is why Rails is throwing errors. Rather than trace backwards further to see why the app was setting current_user to false, I took the shortcut: I installed an block surrounding that block of code… Voila! Did I mention this was a quick & dirty install?

As far as I can tell, that’s it! You should now have a working install of insoshi to go play around with. The session logging is a little broken, but it’s really all you need to start tinkering.

Once we got there, though, we found that we could’ve started working on it weeks ahead of time. Whoops. Undeterred, we stayed up all night programming Bike vs Car. This was an idea that I had a couple of weeks ago (after riding my bike for a couple of weeks). I’d like to ride even more than I have been, but motivation has been a little lacking (some days). When I do ride, though, I tend to hop on Facebook to update my status to something like: “I just biked to work!”

I figured I might not be the only one to do that sort of thing (and since FB is still mostly colege students, biking to class is certainly an option), so it might make a great application. I went ahead and registered the bikevscar domain and then just put it on the list of things I wanted to do. The BarCamp seemed like the perfect excuse.

After we got back from the speakers, we spent a few hours reading up on the Facebook API. Eventually we decided to create our app as a standalone, get it working decently, and then integrate with facebook afterwards. I talked my friend into trying out Ruby on Rails, so I spent a little while configuring the server while she did a couple of tutorials. At around 1 a.m, we actually started programming. I did most of the database and backend stuff while she did most of the HTML and CSS (thank goodness… I hate CSS). We got a reasonable facsimile of a social network put together by presentation time (2:00 p.m.), but didn’t actually get any of the facebook integration done (other than loading a splash screen).

The judging was completely crowd-based, and I think we did a pretty good job of selling not just we’d completed–but where the app could go. We won 1st place. The prize was basically a lot of Java merchandise, a bunch of free programming books, and a few other cool things. The fact that we were able to sell a bunch of people on the app tells me it might have some potential if we ever finish it.

Basically, Bike vs Car is a personal tracking application. Rather than focus on other users, our target user is someone who wants to motivate themselves to ride their bike more often. This isn’t necessarily targeted to the spandex-clad guys on $2000 bikes you see riding to work (motivation doesn’t seem to be a problem with them). This will be a tool for the rest of us. There are several major components to the application:

USERS. We allow users to upload a picture, but we don’t really get any info other than their zip code (which we can then use to calculate average gas prices). Because we’re targeting the site for Facebook, we can just graft our functionality into their already robust inter-user network… and we get to focus on just the functionality we want.

VEHICLES. Though there are many types of vehicles, we’re only supporting the two namesakes for now: bikes and cars. Users can upload a picture of their vehicle, list the make and model, give it a name, and (if applicable) enter what kind of gas mileage they get.

ROUTES. Google maps recently added a great feature. You can get directions from one place to another, alter the route as you wish, and then hit “Save this Route.” Rather than just giving you a link (which has been around forever), they now offer you several different sizes of pre-configured embed code to place the map on your own site. So, rather than scrape Google maps ourselves, we just allow the users to post in the embed code for their route, then give the route a name/description and list the mileage.

Users, Vehicles, and Routes. These are the three essential “nouns” for Bike vs Car. The majority of interaction, though, will come from keeping track of which vehicles you take on which routes. To be fair, not every trip you make is a good candidate for a bike ride. We’re encouraging people to only keep track of trips they make that are ~3-5 miles (or less), with only the driver in the car, and where it’s not going to make much of a difference if they show up a little sweaty.

Once you make one of these trips (on a bike or in a car), the users would then log in to our site (or Facebook, which most of them do already). They would be presented with a list of their most common routes (Work, School, Grocery Store) with bike and car icons next to each. Clicking on one will add a tally-mark for that week. The goal (which will likely be rewarded with some sort of token) will be to choose the bike more often than the car (>50%) for a given week. Based on the MPG of your car, the length of your routes, and the area where you live, we’ll be able to generate an estimate of both how much money you’ve saved by biking and how much carbon you’ve spared the environment.

This is something I would find valuable as a standalone application, but making it a Facebook application is even better. Not only would a user be able to track their own bike usage, they’d be able to track how their group of friends are doing. Or how their network is doing. Or how the entire facebook community is doing. Furthermore, instead of logging in to Facebook to update my status, Bike vs Car could automagically create feed events whenever I bike to work (or let me enter an excuse for why I didn’t).

After spending almost 12 hours straight on it, we’ve got a pretty decent prototype in place. The 1st finish place sort of vets the fact people might go for this, so now it’s just a matter of finding some more time to work on it.

After registering the second domain, I started working on setting up a subversion repository. Being somewhat new with Unix, SVN, and Rails… it’s taken me a couple of days (well, a couple of hours each day for a couple of days) to get everything configured properly. I’ve now got domain #1 working as the development environment, domain #2 working in production mode, the databases set up for both, and both directories acting as a Working Copy. The rough plan is to make all my changes to the Dev environment, commit the changes, then–when satisfied–just roll over to the production side and run an update. It’s a pretty simple usage of Subversion…but hey, I’m the only developer.

All the databases and pages are purely temporary while I play around with rails before starting actual production, so unfortunately I’ll probably have to delete all this stuff and start over from scratch later. I haven’t read up on Capistrano at all, but I might investigate it before wiping everything. Progress on personal projects gets a little slow once you join the real world!

I ended up going with DreamHost for my ruby host… the whole pyramid referral thing kinda creeps me out, but for as cheap as they are (and for only about $25 for the first year)… I really didn’t think I could do better.  They use fastCGI and seem pretty slow and aren’t as cool as the other host I considered (SpeedyRails), but they have the added benefit of hosting infinite domains.  I’ve been really happy with Yahoo’s small business hosting (I’ve had it for around 3 years now — it’s pricey, but stupid-simple), and my biggest complaint has been the inability to host multiple domains (I typically use around 1% of my monthly bandwidth).  So, in other words, because performance isn’t a big issue and I’ve got a couple of other domains I want to play with… DreamHost it is.

I got my rails app, database, and subversion repositories set up without too much trouble.  I haven’t decided if I want to mess with Capistrano yet (might be better to just work on learning rails first).  I got the skeleton app up and running with no problems, so now it’s just a matter of sorting through tutorials until I find one I like.  Dreamhost seems to only support the production environment, so I’m also going to set up InstantRails on my PC.  I already started the “official” ruby on rails tutorial over on the rubyonrails.org wiki, but it seems pretty general.  The ONLamp tutorial will probably be stop #2.

I was also pretty pumped to find this tutorial (although a bit old), which basically details exactly the sort of thing I want to build–well at least the data side.  Maybe that’s why there are so many of these things out there. I don’t really care about the data, though, I just see the data as an excuse to play with rails and flex.

Okay… enough blogging–now back to work.

1. I only want it for myself, but it should support users/logins so I can bone up on mySQL and RoR.
2. I should be able to enter expenses into one widget (like, literally, item by item off my debit/credit card statements) and tag them (with say, “Groceries” or “Movies” or “Entertainment”).
3. I should have another widget for income (which is not going to really change from month to month).
4. Last, I want a debt-widget. I don’t see this as something useful for monthly bills like rent, cable, etc… but something where I can keep track of exactly how much I owe and to who–I just paid off one credit card, but I also just signed up for another one for the TV. The dinette set and the student loans are also financed, not to mention the card I’ve carried through undergrad and grad school.
5. I want to be able to do monthly breakdowns and month-to-month breakdowns, and I want to be able to sort all that junk. For example, I should be able to say (or click on something that says: “Show me how much I spend on movies each month!” Or “Show me how much I spend on groceries vs how much I spend dining out!”

Just having the idea was enough for me–you can instantly see the potential for Web 2.0 tagness, some fun relational databases, and an excuse to do more stuff with Flex. I figured I’d at least do a cursory Google search to see what was out there, though.

Billster seems like it does a lot of what I propose, but not quite. There are a bunch of really fancy Flex charts, but it doesn’t seem to really support the type of sorting I envision. Although it supports keeping track of your earnings vs income, it doesn’t seem to have any support for keeping tabs on your total debt (which I consider to be pretty important). I guess paying off your debt is a lot like trying to lose weight. As long as you write everything down so you can be pissed at yourself when you don’t hit goals, you’re going to make a lot more progress than if you were just wandering around blind, wondering “Hmmm, I wonder when I’ll have that paid off…”

If I don’t get pissed off and scrap the whole thing between now and usefulness, I would eventually want to add another feature–retirement savings! Sure, I’m only 23, and I’ve only been working for a month, but it’s never too soon to start dreaming. I don’t see this as so much of a direct competitor with something like Billster because, mainly, I don’t really care if anyone but me uses it. I’m actually much more interested in sort of self-mapping and self-categorization in general. If I were actually going to try to spin this thing off into something public, I wouldn’t necessarily want to limit it to finance-type things. I used to use Guzzlefish (before its time), and while entering a billion things can be a pain in the ass…it would be kind of cool to chart something like number of DVDs that start with A vs the number of DVDS that start with B over time. Or action vs comedy.

So I guess what I really need is some sort of interface to let users create their own charts. And enter data. And share data between charts. But maybe that’s just dreaming too big.