Insoshi, Meet Heroku
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
- Download the insoshi tarball
- Create a new heroku app
- Import the insoshi tarball (how convenient is it that the heroku app importer wants a tarball!)
- Run rake db:migrate (this will run a ton of migrations… once complete you can press escape to close the little popup)
- 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: falsetoolbar_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.

Hiccup #3
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 <% if logged_in? %> 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.







I tried to do this but the ‘rake db:migrate’ didn’t do any migrations… and then the ‘rake install’ command gave me this:
install –trace
rake aborted!
uninitialized constant Preference
/usr/lib/ruby/gems/1.8/gems/activesupport-2.0.2/lib/active_support/dependencies.rb:266:in `load_missing_constant’
/usr/lib/ruby/gems/1.8/gems/activesupport-2.0.2/lib/active_support/dependencies.rb:453:in `const_missing’
/usr/lib/ruby/gems/1.8/gems/activesupport-2.0.2/lib/active_support/dependencies.rb:465:in `const_missing’
/mnt/home/userapps/15535/vendor/plugins/insoshi-insoshi-26e9c32db53ea35c31f94dc0c7a558b34faf418a/lib/tasks/install.rake:8
/usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:544:in `call’
/usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:544:in `execute’
/usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:541:in `each’
/usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:541:in `execute’
/usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:508:in `invoke_with_call_chain’
/usr/lib/ruby/1.8/thread.rb:135:in `synchronize’
/usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:501:in `invoke_with_call_chain’
/usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:494:in `invoke’
/usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1931:in `invoke_task’
/usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1909:in `top_level’
/usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1909:in `each’
/usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1909:in `top_level’
/usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1948:in `standard_exception_handling’
/usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1903:in `top_level’
/usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1881:in `run’
/usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1948:in `standard_exception_handling’
/usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1878:in `run’
/usr/lib/ruby/gems/1.8/gems/rake-0.8.1/bin/rake:31
/usr/bin/rake:19:in `load’
/usr/bin/rake:19
(in /mnt/home/userapps/15535)
** Invoke install (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute install
** Invoke db:migrate (first_time)
** Invoke environment
** Execute db:migrate
** Invoke db:schema:dump (first_time)
** Invoke environment
** Execute db:schema:dump
** Invoke db:schema:dump
I am not sure why, it seems like it should work but i don’t know why the migration is messing up.
if you could shoot me an email in response or point me to a fix, that’d be awesome! insoshi heroku sounds awesome to me too! and the words seem to fit well together as well!
The rake:install command is trying to initialize a Preference row into the database–the only way it can do that is if the Preference table exists. =]
I don’t know why your db:migrate would fail–I just tested it on a new app and both worked perfectly.
Thanks for putting this up. Getting a Heroku install of Insoshi was of course on our list, but it’s great to see you got there first! It’s things like this that make me love open source.
No problem! It doesn’t hurt that I was already working on a social networking prototype for Heroku–this will only speed my development time.
figured it all out! is working now, but slowly…
Hey when I run the migrations I get the following error:
rake aborted!
uninitialized constant Crypto::Key::Base64
What do I do?