I’m not always hot on the “freemium” type sites that give you a wee tiny bit of functionality for free, but as soon as you want to use it to do something more interesting (or use an expanded set of functionality), it’s a pay service.  Probably because I’m cheap, but also it seems a bit of a tease.  Of course, I use a lot of these type of services myself.  I have the non-pro Flickr, non-pro Evernote, and also non-pro Dropbox in my daily repertoire of tools, and on my list of “stuff to pay for when I have a few extra bucks at the end of the month”.

Heroku, sadly, has turned into yet-another one of these invaluable freemium tools.

For my referee site project, I use two different modes of development.  First is the standard workflow of running “script/server” on my laptop in a terminal window, the default SQLite database that rails 2 uses out of the box, and switching between an editor and a web browser.  Code changes are checked in locally to git.

For “public” code I set up a free account on Heroku, installed a gem, and just use git to push both code and database up to the cloud for public consumption.  I have yet to set up a “real” server for running a rails app.  There are a bunch of different ways to do it if you have your own server such as:

• NGINX
• Phusion Passenger (mod_rails)
• Mongrel

Lets be honest though, unless you’re a sysadmin, and have your own machine, these are a lot to deal with as far as setting them up well.  With “well” being the key word.

There are also some other cloud services and rails specific hosting services:

• Heroku
• Engine Yard

Also a ton of “normal” hosts include Ruby on Rails support by default, but without some of the nicities that Engine Yard and Heroku give you.  These are the services that you use until you get slashdotted/dugg/redditted/fireballed/etc and decide that you need something a bit more “elastic”.

My point though, is that if you just want to get your rails up up and on the internet, and you don’t want to deal with 99% of the stuff that you’d have to mess with if you were setting this up on your own server (ie: a VPS or hosted server).  If you don’t believe me, the documentation and front page makes it very obvious just how easy the develop/deploy cycle is.

It’s not all wine and roses though…

Heroku “Gotchas”

There are a couple of gotchas I found.  On the technical side, something I came across was that because on the backend Heroku uses postgresql as their database, the “heroku db:push” command imports data from the local sqlite database, there’s a chance that something will be inconsistant.  In my case I somehow managed to have an issue with case sensitivity, and while my development SQLite database was called “fields” (and all the convention over configuration knew how to find it and use it just fine) but the postgreSQL database on Heroku was called “Fields”, which was not found by the system.  I had to add a “set_table_name” line to my field.rb file to fix this.  Probably a user error and not a heroku error per-se, but something to watch out for when swapping between two different databases.

The other one is either a good of bad thing.  If you’re like me and use Heroku for a quick and dirty host to show a client without having to run your own server or deal with a bunch of configuration, when the client says “Ok, now lets put it out there for real”, you can just say “Ok, pay some money and we’ll upgrade the heroku account”, and your workflow stays the same, but you get access to all the fun stuff that Heroku wants your credit card to use

I’m sure there are other solutions out there, but none that I’ve found so far as easy and pragmatic as Heroku or Engine Yard.

Code from Level 6

Thanks to the FV.rb last night I discovered Ruby Warrior, a neat and fun way of learning ruby.  It goes like this….

First, head to http://github.com/ryanb/ruby-warrior/tree/master and download the tree by using “git clone“, then simply run “bin/rubywarrior” out of the main ruby-warrior directory that the git clone command creates.  The first run will create a profile and set up the initial part of the “game”.

The “game” is a bit like the old adventure text games, with a simple ASCII “dungeon” that you see your guy move through, and as the levels progress you will encounter monsters, harder monsters, captives to rescue, and so on as you move from one side of the dungeon to the stairs on the other side.  The system is turn based, so you are basically creating yourself a little state machine.  You basically check to see if there’s something in front of you and if not walk, if it’s an enemy, attack, etc.

To do this you end up doing something like this:

1. You look at the README file in the ruby-warrior/beginner-tower/level-001/ directory.  You may have “intermediate-tower” instead of beginner depending on the level you chose during the initial setup.
2. Follow what the README file says and edit the file ruby-warrior/beginner-tower/level-001/player.rb adding code to make your warrior move and fight.
3. Run bin/rubywarrior and see how well your warrior moves and fights.  It will either succeed and allow you to continue to the next level (in which case go to step 1, substituting the right number in the “level-00N” directory), or you will fail, in which case, re-edit the warrior.rb file and try again.

The game isn’t for complete and total programming n00bs, but might be a bit simple for people who know programming, but not ruby   It starts out with simple commands and simple if/then/else control structures.  However, it does make it cool and interesting enough that it has kept my interest for at least until now.

One of the biggest failures I found starting in Rails was the lack of a standard for hosting.  In the mod_perl or php world, the standard apache distribution has everything needed built in to the standard distribution, and you’d be hard pressed to find a hosting system (of any size) that doesn’t have them.

Rails on the other hand, seemed to have a boatload of ways to serve itself.  There doesn’t seem to be a “standard” webserver.  You have mongrel, nginx, phusion passenger (mod_rails), lighttp… the list goes on.  And it doesn’t seem that there’s an accepted “proper” way to do the webserving yet.  Maybe it’s a case of different tools for different cases, maybe it’s just a symptom of a system that’s relatively young (compared to the apache/perl/php world).

(more…)