Tech Demo

1 Comment

So in preparation for Rails Rumble I’ve been researching a lot of sexy little plugins.  We have also had a need to test this plugins to make sure they’ll work not just locally but in a shared hosting environment (the first time you get burned and spend an entire weekend, 16 hours, trying to figure out why something that works perfectly on your local box dies horribly on shared hosts you learn to test everything).  To accomplish this testing we’ve needed a small little app so I can get the bare minimum for the plugins in there.  I’d like to post everything I did while I wait for Lynn to push everything up to test. Mostly this is just a quick run down because someone else has already done a far better job than I could explaining in depth how to install and configure all this stuff. This is also by no means how you should do any of this, this is solely for testing out various plugins and packages.

The plugins, gems, and kitchen sink

What I’ve got up and working on my local box so far is:

  1. Simple Email Notification with ActionMailer
  2. SMS Fu
  3. Twitter4r
  4. Gravatar Profile Image
  5. Juggernaut
  6. BackgrounDRB
  7. GoogleCalendar/ICal

Simple Email Notification

Won’t really go into this, it’s obvious and everyone has done it a million times


  • Clone it
  • Include it
  • Put this code in there:


def index
@carriers = %w(alltell ameritech at&t bellsouthmobility blueskyfrog boost cellularsouth helio kajeet metropcs powertel pscwireless qwest southernlink suncom t-mobile virgin verizon)

def text_message
deliver_sms(params[:pages][:phone_number],params[:pages][:carrier],"Test Text Message")
redirect_to :action => 'index'


<% form_for :pages, :url => {:action => :text_message} do |f| -%>
Phone Number: <%= f.text_field :phone_number %>
Carrier: <%= :carrier, @carriers %>
<%= submit_tag "Send Text" %>
<% end -%>


  • Install the gem
  • require the gem
  • Use the following code


def twitter_message
client = => params[:pages][:user_name], :password => params[:pages][:password])
if client.authenticate?(params[:pages][:user_name], params[:pages][:password])
new_message = client.status(:post, params[:pages][:text_message])
return redirect_to :action => 'index'
flash[:notice] = "Failed to authenticate"
return redirect_to :action => 'index'


<% form_for :pages, :url => {:action => :twitter_message} do |f| -%>
Twitter User Name: <%= f.text_field :user_name %>
Twitter Password: <%= f.password_field :password %>
Text To Post: <%= f.text_field :text_message, :limit => 140 %>
<%= submit_tag "Send Twitter" %>
<% end -%>


Just use the code in your application helper


  • Make sure you have json and eventmachine installed
  • install the gem
  • install the plugin
  • juggernaut -g juggernaut.yml (to make the config file)
  • Use the following code
  • juggernaut -c juggernaut.yml (to start the push server)

Layout (or anywhere you want to use Juggernaut)

<%= javascript_include_tag 'juggernaut/swfobject' %>
<%= javascript_include_tag 'juggernaut/juggernaut' %>
<%= juggernaut(:channels => ['chat', 'notifications']) %>


<ul id="chat_data" style="list-style:none">
<%= form_remote_tag(
:url => { :action => :send_data },
:complete => "$('chat_input').value = '#{}'" ) %>
<%= text_field_tag( 'chat_input',, { :size => 20, :id => 'chat_input'} ) %>
<%= submit_tag "Chat" %>
<ul id="notification_data" style="list-style:none">


- :port: 5001
:public_port: 5001


  • install chronic and packet requirements
  • Clone the code
  • rake backgroundrb:setup
  • ruby script/generate worker notifications
  • use the following code
  • ruby script/background start (to start the backgrounDRB)


:port: 11006
:start: <%= + 5.seconds %>
:end: <%= + 1.year %>
:repeat_interval: <%= 5.minutes %>


class NotificationsWorker < BackgrounDRb::MetaWorker
set_worker_name :notifications_worker
def create(args = nil) 'created worker'

def check_notifications
if true 'sending notification'
Juggernaut.send_to_channel("new Insertion.Top(\"notification_data\", \"<li>Sending Notification at #{}<\/li>\");", "notifications")


<ul id="notification_data" style="list-style:none">


  • Install the gem
  • require the gem
  • Use the following code
  • Add to Google Calendar to check your work


def calendar
@cal =

[{:name => 'Meeting', :start =>, :end =>},
{:name => 'Greeting', :start =>, :end =>}].each do |comp|
event =
event.start = comp[:start].strftime("%Y%m%dT%H%M%S")
event.end = comp[:end].strftime("%Y%m%dT%H%M%S")
event.summary = comp[:name]
@cal.add event
headers['Content-Type'] = "text/calendar; charset=UTF-8"
render :text => @cal.to_ical, :layout => false

What you will end up with is a very ugly little app that will look like this:

On Environs

No Comments

Environs Logo

Another project Powered By Geek recently did was an entirely Facebook application called Environs. This was our first real foray into the world of Facebook applications. For the Rails side we used a gem called facebooker this application, we also used RoRBook ( as a base.  Here is the about page written by Lynn about Environs.

You have friends
You are connected to those friends on social services

Because you’re all web 2.0 tastic, you and your friends use, like, a kerbillion social services

We quickly show you what you use, what they use, and where you haven’t connected yet.

Ah, haven’t I already connected with these people already?
Yep… at least once. But while you’re connected to some of your friends through most social services, you’re probably not connected to all your friends on all social services. And maybe that’s the way you like it, which is totally cool.

Also, there might be some apps you’ve thought sound interesting, but you didn’t know if anyone you knew was using them. Which makes sense, because using a social service all by your lonesome is kind of… well, not the point. But we can tell you, hey, 4 people you know are using Brightkite right now. Come on over! You know people here!

Why on earth would I want to do this?
Social services are fundamentally about information. What people like (for example,, what they watch (YouTube) and what they’re doing (twitter). You’ve already decided you want some information on some of your friends. What we do is give you the option of easily expanding the amount of information you can get about those friends. Like, say you follow your friend Mikey on BrightKite, and you know he likes dive bars. Awesome. But what if we told you hes also on flickr, and takes crazy-good photos of taco trucks. You might not have known that, but by expanding the number of services you use to connect to Mikey, you get to learn more about him. Basically, were a match-maker… but for people you’ve already met. Its your choice, though — we give you the option to connect with people on additional services, but you don’t have to connect to anyone on anything.
Screenshot of Environs

Screenshot of Environs

This app was tricky in two ways. First it was the first real Facebook app I have done, which meant there was a large learning curve as things that work just fine with a regular Rails site some times just don’t work with Facebook. Ajax and JavaScript in particular are completely different, and require a “hand roll” approach. This necessitated a lot of trial and error, not to mention the learning curve of what Facebook’s changes to JavaScript effect.

The other tricky aspect of this project was the main aspect of it, the parsing of other services. Each of the other web services (ex. Twitter, Last.Fm, Digg, etc.) have their own format for doing everything. We had to consolidate a parser to read all those varying formats and return the same result set so that it could be displayed. I had done stuff similar to this with iStalkr so I was prepared for gathering and reading all sorts of standard formats (RSS, XML, JSON). How we solved the problem was to create a library module, I initially designed it, but then submitted it to Bruce to help me improve the readability. This is still an ongoing problem, as more and more services are added to Environs I need to investigate their API’s and get them working.

Screenshot of Environs Service Matching

Screenshot of Environs Service Matching

Some services such as Flickr or MySpace are extremely tricky (in fact I’m still working on a way to parse MySpace). This might turn into somewhat of a rant, but services that allow you to set a URL to one thing, but then have a completely different value for tracking users, make it next to impossible for application developers to work with them. Flickr has their login, user id, and url, some queries to their API will accept any of the 3, however others want only the user id. Luckily, Flickr has a way around this because they have an API call that you could provide the piece of the information on the user and have it return the user id. Other services don’t offer this and it makes it a lot harder to get the data we need.

Overall, I think the project turned out pretty well. It’s a work in progress, there are still some services that we need to get working. Also, we’ve got some plans for recommendations that are in the pipelines. It’s a fun project that will only get better in time (at least until someone finally agrees on how to standardize these separate friend’s lists on each site).

On Kiobo

No Comments

So after a good long while in development and being kept under wraps I’m finally able to write about the newest big project I’ve been a part of, Kiobo.  Kiobo’s goal is:

Kiobo helps users enrich their browsing experience by making browsing a more social activity. We enable users to explore and leverage their social graph’s browsing behavior. Users can effortlessly find not only new sites relevant to their interest but also people with similar browsing behavior.

Kiobo, as a development job, was actually a challenge,  as there were a couple of big questions.  “How do you hold every website that a user goes to in a day?”, “How do you keep the database moving day after day, with one person able to submit thousands of records a day?”, and “How do you integrate with Facebook, the social networker’s tool of choice?”  Luckily I had help on this project, in the form of Bruce and Nate who are probably the two most influential developers in my life (both have mentored me at some point or another).  We also received help on the database side of things from Will who hails from the land of MS SQL, but has since started getting down and dirty with our database of choice MySQL.

This project started out because of the semi sucess that iStalkr received, because of iStalkr and the fairly recent bout with maintaining a server that was storing TONs of information I was a little wary to start on a project that had an even broader scope of what it would be tracking.  We spent a good long time designing visualizations, planning out the database schema that would provide the best performance versus ease of use, and working out how all these things were going to fit together since this was by far the most ambititous project we had worked on.  Bruce and I worked primarily on the Rails side while Nate worked on the firefox plugin and visualizations.  The project also spawned an oAuth plugin that Bruce wrote that is actually pretty nice, and that Nate integrated into the toolbar.

This project taught me that with the right database design that databases go from fragile bottlenecks that slow everything down to super speedy efficient ways of storing vast amounts of information.  One of the things that I learned from the problems we had with iStalkr was that storing text fields on large tables is a nightmare waiting to happen.  Luckily with this project we weren’t archiving the internet but were instead just logging where you went which was a lot less data we had to store.  We haven’t quite gotten to the point where we’ve started implementing caching but it is coming up soon.  Luckily I’ve gained quite a bit of experience during this time with working with memcached, page caching and slaving databases, so I feel confident that I’ll be able to improve performance in future releases.

We were able to solve the problem of performance by avoiding just one linked table, and instead going with multiple tables funnelling the information so that what ever the purpose of the query was you could work with the minimum number of records.

Privacy was a huge concern with this project.  Let’s face it, everyone goes to an internet site once in a while that they aren’t proud of it’s the nature of the internet now-a-days, one transposed letter is taking you to who knows where, to see who knows what.  With Kiobo people needed to be able to access and see EVERYTHING that we had on them, and be able to do with that what they like.  This instituted the need for multiple levels of privacy, as well as an easy way for someone to delete records.

Also I got my first crack at the rfacebook gem (which ran into serious problems when we upgraded to Rails2.0) and then the facebookr gem which since then I’ve had a lot more experience with on other projects, such as rorbook.  The facebook implementation started out as only a “link your account to facebook then login with facebook” but quickly grew to a facebook app, along with befriending people who are your friends on facebook.  The facebook implementation isn’t all quite there yet, but we’re working towards getting it there.

As for the business side, well I try to stay out of that as much as possible and luckily Lynn translates it and just tells me the highlights.

Kiobo was a really fun project to get started, and I look forward to hopefully getting a chance to create an HTML based version of the site to go along with the flash based version that is up now (what can I say, I’m prejudiced against flash).