Rails Rumble '08

1 Comment

Rails Rumble was an amazing experience.  I think I slept about 6 hours over a 56 hour period and while I became grouchy I don’t think I ever stopped having fun.  The fun stopped after the first day of voting.  Starting during the second day of voting I <3 Games plummeted in the rankings.  I am not really sure what happened to cause this fall.  I am not the most objective person but in testing some of these other apps I’ve run into some real problems that I don’t understand how something that doesn’t quite work could be ranked higher than our app which I think is about 90% done.

Problems with voting

  • With any voting system there are always ways to game the system.  The OpenID requirement for Rails Rumble voting would make gaming rather easy I would think.  Without a captcha or email validation it would be fairly easy for a machine to sign up for voting as many times as it wanted.
  • Voting with most people for Rails Rumble is only based off of a glance, there is very little actual signing up to use the app going on.
  • No way to explain what your feelings about the app were.

I think if some of these issues were addressed I would feel a little better about the voting system.  I think the 8 random apps a day idea was a good one that helps prevent the event from becoming an popularity contest.

Gaming the system is always going to be a problem.  Bots can be created that get around almost every system to stop them, but when the systems are few and far between to stop them they can have a field day and can dramatically skewer results.  I do know a few people who aren’t bots that just said “Oh, well I’ll just give every other app 1 star across the board” and it shows.  Rather than 3 stars being the “average” value for an app it is the high value.  I know there won’t ever be a 5.0 over all app, but we’re talking about 2.9 being the high value and 1.6 being the low value.  That is a lot of 1 and 2 stars over the 4 or 5 stars.  On a scale of 1-5 then 3 should be the average, that should be “this app is unremarkable, there is nothing wrong, but nothing right either” instead if we keep going along the way we are currently going then 2.9 is going to be the winning score, which using the normal averages would mean that it is slightly below average, and while I’ll be the first to admit none of these apps are above average against an application where you have an unlimited time frame and tons of QA testers.  If you keep in mind that every single one of the apps was designed in 48 hours by 1-4 people I would have to say a great many of them are above average.

One of the problems I have with the voting system is that the results tend to be skewed towards pretty on the front page apps.  Powered By Geek didn’t exactly cater to this, we hid a lot of functionality after sign up, but we did put a little video up explaining about the app.  The real problem I have is the number of people who aren’t even signing up who are voting on the app.  I know for a fact that our login/signup process works because we had a guy dedicated to testing that procedure during the actual competition and I’ve created about 10 accounts as well with my numerous Open IDs and as regular users.  Looking at our numbers we’ve had 79 users sign up, and when you take into account all my test accounts that is about 70 users total who have signed up and yet we have 240 votes on our site.  That is a 1:4 ratio of people who actually looked at our site vs people who just voted either after looking at our home page or without looking at the site at all.

I’m wary to point my finger at people and point out flaws as to why they shouldn’t be at their position, however some of the apps I tested had main functionality broken and yet they are sitting in the top 30 spots.  Testing is almost nonexistent, a friend was testing other sites and uploaded a picture that he figured would disappear after a while but instead it was on there for over 24 hours.  The site only had slots to show 5 pictures that means that it took over a day to upload 5 pictures on the site.

My final real problem is that there is no way to tell why people voted one way or another.  I think a short description on why they are voting one way or another would help everyone involved to understand what people liked and what people disliked about the app, not to mention it would make it easier to tell when someone was gaming the system.

Overall I think the Rails Rumble brings an awesome service to the community.  48 hours with the right motivation (competition) is really useful as it can really get an interesting idea or product built.  Not to mention it helps bring you together with friends towards a common goal.  I really just wish everyone could come away from it feeling like the voting wasn’t just a game.

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

SMS Fu

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

Controller:

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

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


View:

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

Twitter4r

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

Controller

def twitter_message
client = Twitter::Client.new(:login => 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'
else
flash[:notice] = "Failed to authenticate"
return redirect_to :action => 'index'
end
end


View

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

Gravatar

Just use the code in your application helper

Juggernaut

  • 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']) %>

View

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

juggernaut_hosts.yml

:hosts:
- :port: 5001
:host: 127.0.0.1
:public_host: how_the_public_accesses_your_site.com
:public_port: 5001

BackgrounDRB

  • 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)

backgroundrb.yml

:backgroundrb:
:ip: 0.0.0.0
:port: 11006
:schedules:
:notifications_worker:
:check_notifications:
:trigger_args:
:start: <%= Time.now + 5.seconds %>
:end: <%= Time.now + 1.year %>
:repeat_interval: <%= 5.minutes %>

notifications_worker.rb

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

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

View

<fieldset><legend>Notifications</legend>
<ul id="notification_data" style="list-style:none">
</ul>
</fieldset>

ICalendar

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

View

def calendar
@cal = Icalendar::Calendar.new

[{:name => 'Meeting', :start => Time.now.beginning_of_day, :end => Time.now},
{:name => 'Greeting', :start => Time.now.beginning_of_day-1.day, :end => Time.now-1.day}].each do |comp|
event = Icalendar::Event.new
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
end
@cal.publish
headers['Content-Type'] = "text/calendar; charset=UTF-8"
render :text => @cal.to_ical, :layout => false
end

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

Rails Rumble

1 Comment

Powered By Geek will be participating in Rails Rumble 08.

I’ll be working along side Lynn Wallenstein, Nathan Ostgard and William Harris to create a Rails application in 48 hours.  We’re super excited, and I’m going to try and keep a log of what is going on to post it (we’ll see how well that goes).

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 (http://github.com/lwallenstein/rorbook/tree/master) 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, del.icio.us), 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).

Initiation by fire – part 3

1 Comment

Beginner mistake number 3:

Associations.  If you’ve worked with relational databases at all you probably know the concepts one-to-one, one-to-many, and many-to-many, and you’ve probably cried your self to sleep on a numerous occasions writing join statements that probably are longer than some children’s books.  Every Rails developers learns the basics of Rail’s model associations.

class User < ActiveRecord::Base
has_many :items
end

That little bit of code will let you automatically find all the items that have the same user_id as the users id.  Powerful stuff!  However, what most beginning developers don’t learn is the additional things that you can do with the model associations.  Find you’re doing a query to get all the user’s active items all the time?  Well why keep writing the query when you can make it an association and then call it the same way as user.items?

has_many :active_items, :class_name => 'Item', :conditions => ["status = 'Active'"]

Now you can find the user and do  user.items AND user.active_items.  This saves a ton of typing and testing, since the query is always going to be the same, you can test once and then not worry if you misspelled ‘Active’ the 30th time you wrote the query.  Also in case you’re crying foul because :class_name came out of nowhere, all it does is tell what model to use to relate it to.  Rails normally does this for you because you’re creating a relationship with the same name or pluralization of the name of the model.

Many-to-many… alright you can stop wincing now.  Yes, many to many relationships are powerful, and useful for certain situations however they make for nasty SQL statements and even nastier code implementation.  However with the has_many :through they can act just like a one-to-many relationship.

class User < ActiveRecord::Base
has_many :roles, :through => :users_roles
end

class UsersRole < ActiveRecord::Base
belongs_to :role
belongs_to :user
end

class Role < ActiveRecord::Base
has_many :users, :through => :users_roles
end

Now you can retrieve the user and get the user’s roles, or retrieve the role and get the users.  Or you can even retrieve the user and then get the user’s roles, then take one of the roles and get all of the users with that role.  Pretty neat!

The fun doesn’t stop there.  If you have a group of items linked to the user, and you don’t want orphaned items when the user decides to close up shop and delete his user account then you can even add a line to the model telling it to get rid of all the users items when the user is deleted.

has_many :items, :dependent => :destroy

If you are feeling really crazy you can even take associations one step further and write an association that uses another association.  For example you have standard association then tell your next association to go through your standard association

has_many :admin_memberships, :class_name => 'Membership', :dependent => :destroy, :conditions => ['admin = 1']
has_many :administered_groups, :through => :admin_memberships, :source => :group

Now I know I threw another curve ball in there with :source.  That, like :class_name, tells it what model to use except you use it with :through associations, once again the reason you hadn’t seen it before is because Rails is normally pretty smart about these kind of things and will attempt to use the :through value as the model unless you specify something else using :source.

Finally lets move on to what, in my opinion, is the coolest thing you can do in a model.  Polymorphic relationships, which by the way as soon as you say that to a nontechnical boss, they’ll most likely leave you alone because the word alone is enough to scare off the un-technical.  What does this association with the power to scare off bosses actually do?  Well lets say a user has multiple things associated with them that you want to dynamically load.  A picture can either be of an item or a knickknack.  Sure you could define them all as associations, but why limit yourself?  You want to find them without having to think about what you’re findign.

class Picture < ActiveRecord::Base
belongs_to :resource, :polymorphic => true, :dependent => :destroy
end

class Item < ActiveRecord::Base
has_one :picture, :as => :resource
end

class Knickknacks < ActiveRecord::Base
has_one :picture, :as => :resource
end

Now on your picture table you’d add resource_type and resource_id so they can be associated.  Now by finding a picture and calling picture.resource will return the associated item or knickknack.

However by doing all these neat associations you run into what web developers call the n+1 query problem.  You have all this power at your fingertips and you’re generating a sql query every time you try to call an associated items.  Fear not, for Ruby on Rails has already foreseen your dilemma.  Ruby on Rails has something called eager loading, which is where you can banish those nightmares you’re still having about the 5 page join statement you wrote last year.  By adding :include into your user find Rails will magically generate that giant join statement for you and load up your associations via that statement.  No fuss, no muss, you get easy to read code and you can even eager load records from your eager loading.  First lets look at the normal code.

@user = User.find(params[:id], :include => :items)

Now to find a user, load all the items, and then load the item’s picture

@user = User.find(params[:id], :include => {:items => :picture})

That will generate a giant SQL join for you and will let you call something like user.item.first.picture without even having to think about all the magical SQL that needed to be generated.

Initiation by fire – part 2

2 Comments

Beginner mistake number 2:

Names and idioms. One thing I learned about the Rails community is that all the good developers secretly wish that they were English majors and Math majors at the same time. I know it sounds silly, but Ruby devs will call you down for using a crazy model name while at the same time praise you for using a complex idiom that nobody can read unless they understand the idiom. One of my first forays into RoR development was a site called LongTimeLost (http://longtimelost.com). This is also the first site where I started working with other Rails developers and learning what is acceptable and what isn’t when building a Rails site. After a developer took one look at my code he immediately noted that ‘looking4people’ is a horrible name for a table, and at the time I couldn’t understand what he was talking about, no one but us was going to see the code, what did it matter what I named things (I admit now looking back on my choice for a table name I’m quite embarrassed). It turns out in Rails naming is important. Rails does so much magical box stuff based on what you name things, have a table called users in your database? Well the way to search it with active record is User.find. The naming also affects how easy it is to read parts of your code. Looking4Person.find really isn’t good reading and Rails above most else should be readable.

The dichotomy of Rails though, is idioms. Idioms, which can cut multiple lines of code into one line. For example, probably the most popular idiom takes this code:

if foo=’bar’
puts ‘a’
else
puts ‘b’
end

And turns it into:

puts (foo==’bar’ ? ‘a’ : ‘b’ )

Clean, elegant, and if you don’t know the idiom, you have no idea what it’s doing. Thus is the way of idioms. The best place to keep up to date on idiomatic code is http://therailsway.com/. There is no hard and fast way to learn them, mostly they come by seeing them, saying “Wow, that is cool, what does it do exactly?” and then remembering it so you can impress others later.

Naming on the other hand does have a hard and fast way to do it. For the most part imagine what you are going to name your objects in sentences and ask your self if they make sense the best ways are the associations (which I’ll write about later) and the find method.
Looking4Person.find (a good example of a bad name)
User.find (a good name)
Now with the associations:
A User has_many Relationships
A Group belongs_to Admin
A User has_many Friends through Relationships (the has_many :through will be talked about later)

Variable names also should also avoid camel case like the plague. Camel case, while the standard for languages like Java is something that will make an experienced RoR developer’s blood boil. And I’ll give you an example why, which is easier to read:
a) authenticationMethodGoesHere
b) authentication_method_goes_here
The answer is obviously b, it looks more like English and is far easier to read at a glance, which is what Rails developers love.

Initiation by fire – part 1

1 Comment

Starting off as a Rails developer I ran into some problems coming from a Java/C++ background. Until Rails I more learned the languages for fun and something to play with in my free time, however by doing this I picked up some bad habits. I’ve worked with one of the top Ruby developers out there and learned to mimic his style and question his choices in code. I’ve learned a lot in the last year and a half I’ve been coding and now am even leading up a development team and teaching them the ins and the outs of Ruby.

Beginner mistake number 1:
For loops. I’m not so sure how the books teach it now but when I was initially learning Ruby all the books showed loops as

for item in collection

This is really easy to read, and will make developers from other languages feel a little more at ease with the language (it’s got the word for in there, and everyone knows what a for loop is). However you’ll quickly learn that using those for loops is really only for beginners. The real power of the for loop in rails doesn’t even have the word for in it. The real power comes from each.

collection.each do |item|

Not only is this also easy to read but it gives you so much more control over what you are doing. Want to pass in a counter variable? Simple

collection.each_with_index do |item, counter|

Or maybe you just want to get the keys from a group of hashes.

collection.each_key do |item_key|

There are many more possibilities, and by using each you are learning the style of what is probably the most powerful module in the Ruby language the enumerable module.