YARB

I just got my new GitHub account – yay!

Time to tinker. One thing I’ve done with rails is create a “QuickStart Rails” template that I have checked into svn. It’s got several useful plugins that I use in just about all my rails apps, plus a working authentication system including all the boring, trivial details that come with that like ‘Forgot Password?’ functionality, etc.

Not all apps get the QuickStart rails treatment, but if they involve user authentication, I usually bootstrap the app using QS.

Recently I’ve been working on a Facebook app; following its development, I’ve made a Quick FB rails application template.

Again, this does all of the mundane things that all Facebook apps will require, like an Invitation page:

If you’re interested, you can browse the git repository online.

To bootstrap a new Quick FB app (“fb_foo”) using git, do a:

git clone git://github.com/sbraford/quick-fb.git fb_foo

This will give you a complete Rails 2.0 application structure, plus:

• rfacebook, will_paginate plugins already added
• application.rb configured for you
• User, Friendship models already created—as users add the application, they are automatically associated as Friends within your app
• Invitation widget (like shown above) already included

See config/environment.rb for the list of TODOs once you have cloned the Quick FB git repo:

TODO after cloning the quick-fb git repo:

  1. Create your app's database.  Modify 'config/database.yml'.

  2. Open 'config/facebook.yml' and modify the following:

      key: YOUR_API_KEY_HERE
      secret: YOUR_API_SECRET_HERE
      canvas_path: /yourAppName/
      callback_path: /relative_root/
      sever_host: foo.com
      app_name: Foo App

  3. Modify the relative URL root below.

  4. Open up 'app/helpers/application_helper.rb' and modify the invitation text.

  5. Generate a new secret app key with:

        rake secret

  Copy & paste this into the session config section above. (this might not be necessary for fb apps, but just in case)

Note: to port this over to SVN, I believe you can simply do a:

  rm -rf .git/
  rm .gitignore  # and any other .gitignore files

... and you should be good to go. (copy to an existing svn repo and svn add/import as usual)

Git has been getting a lot of coverage these days.

The technology behind git sounds nothing less than spectacular. But how does git improve day-to-day productivity in this kind of environment?

Time it takes to perform/think about “version control” (in this case, Subversion) in parenthesis.

• Do some hacking for maybe 2 hours. Make a checkin. (15 seconds)
• Svn update on server. (15 seconds)
• Oops, wasn’t 100% right or need to make a quick fix. Check that in. (10 seconds)
• Update production. (10 seconds)

...

Git sounds wonderful if you need to do a lot of intricate braching.

For my development style, that just isn’t the case. I’m also not ashamed to admit that I find Capistrano highly overrated when it comes to managing deployments.

Don’t get me wrong—it’s an excellent tool if you want to add that much overhead to your deployment process, ability to rollback, etc, etc.

Here’s where it failed me:

• in one intricate app, while deploying, there were always several ancillary processes going on in the background. Capistrano would always hang for 5-10 minutes while trying to stop these.
• checkout of the core code takes 5+ minutes (slow remote svn repo or biiig rails apps)—who wants to sit around for 5 minutes when an incremental ‘svn up’ takes 15 seconds?

So—yes, that’s how I “deploy” my Rails applications, and have never had a problem yet. Here is the simple 30 second workflow:

cd /u/apps/foo/current
svn up .
mongrel_rails cluster::stop
# manually make sure all mongrels have stopped, and possibly: rm -rf log/*
mongrel_rails cluster::start

And PZZaaaaaaaam—I’m deployed.

So adding things like git and capistrano would simply slow me down. If you’re deployment cycle takes 1-2 days (for full UI testing, etc—ugh) then by all means, use capistrano, git, whatever. But for the “ultra agile” style, these fancy techniques are overkill, IMHO.