Tag Archives: rubyonrails

OpenID and Gravatars

… also known as – please don’t make me fill out those same 6 fields to get into your website!

A few weeks ago I gave an MHVLUG talk on Ruby on Rails.  At the normal dinner outing afterwards one of our members was talking about maybe creating a small rails application where people could share and publish the podcasts they listen to, which I think is a great idea.  (Hopefully they’ll work on it at our web-hack-a-thon.)  But that lead into the inevitable issue of “user accounts”.

Man, I hate having more user accounts.  And if we are going to do this project, I really didn’t want everyone in the LUG to have to have another one.  So I resolved to see what I could do about reusing the MHVLUG accounts in an external way.  It’s actually pretty easy as there is a Mediawiki OpenID extension which lets you go both ways.  You can enable OpenID logins to the wiki, and make people’s user pages OpenID providers.  Rails has a very good openid plugin (plus it’s integrated as part of the restful-authentication-tutorial) so that would make it trivial to write an application that people can log in using their MHVLUG password (the id will be a bit different, but that’s explainable).  While Facebook and Google are still dragging their feet a bit here, Yahoo, AOL, and WordPress.com are all on the bandwagon, so many people already have these ids, they just don’t know it.

That got me following a few threads on OpenID, and looking at WordPress.  It turns out that WordPress also has a good OpenID plugin.  What’s quite interesting about that plugin is that it can make a wordpress instance the OpenID provider for 1 of the WordPress users.  So if you have a personal blog, it means you can now very easily be your own OpenID.  Being able to login in as http://dague.net is quite convenient.

Lastly, I wanted to throw something in about gravatars.  You know how everyone wants you to upload your picture to their website?  Stop the madness!  Gravatars are just keyed off your email address, so if an site has that, they can look you up, and get your profile pic from the gravatar folks.  Newer wordpress templates automatically integrate this.  I did minor adjustment to my template to get this support in there.  I’ve sworn now that Meetup.com is the last people I’m ever uploading a picture for, and that’s just because it’s hard to find complete strangers in a dinner without photos.  Again, there is a good rails plugin for this, so it’s pretty trivial to integrate if you are doing a Ruby on Rails application.

So, if you are a web2.0 hipster, and thinking about making a new service, please don’t make me create a new account, because, honestly, that’s getting close to being a deal breaker for me at this point.  And if you want my picture, the gravatar people have it.  I’m not uploading it for you again. 🙂

Perfect Rails Development / Deployment environment with mercurial and passenger

A couple weeks ago I found phusion’s passenger (aka mod_rails), and it’s great. Passenger compiles an apache module which manages a rails app server for each application. It is on par with mongrel on speed, and so much easier to integrate into an average Linux environment for rails app hosting. Here’s my new standard rails development environment (3 applications right now, with a couple more in the works).

Development with Mercurial

Distributed Source Code Management is the wave of the future, and I can’t say enough good about it. My prefered system is Mercurial (aka hg), which I got to know why working on the Xen project. While git is getting a lot more hype of late, I still think hg is easier to use, and an easier switch for people that know subversion.

Rails makes it very easy to run a server locally for development, so having versioning locally makes perfect sense. I can hack away for days making changes on my laptop until I get to a point where I want the code to see the light of day. Then it is an easy hg push to put my code either into production, or into a repository for sharing.

Deployment with Passenger

is a god send. Getting mongrel to do the right things on init on an ubuntu box was just a pain in the rear end. I like apache, I know apache, having to configure a web app outside of apache sucks. Passenger builds an apache plugin that is an rails app server. You don’t need to know any more than that, because it just works.

Actually, you need to know 2 things, both of which add to passenger’s awesomeness.

  • The rails app will run as the uid of the owner of your environment.rb file. This means you need to take care on how your permissions work on you deployed rails app. This is a good thing, as we’ll see in a minute.
  • You don’t need to restart apache to restart the rails app. You just need to touch tmp/restart.txt in the rails directory, and the app server restarts. This is very handy.

Bringing it all together with Mercurial Hooks

On my box where I’m deploying applications I created a new rails user, with a scrambled password, and just my ssh key to get in. This is the account in which I push production versions of apps to. It means that the rails apps run as user rails, which is ever further issolated than user www-data. You could even go a step further and have each rails app under a different user, but for me that’s overkill.

The .hg/hgrc for one of my local projects looks as follows (with myhostname, myrailsapp, and myrailssite replaced to protect the innocent):

default = ssh://myhostname.org/code/myrailsapp/
production = ssh://rails@myhostname.org//data/site/myrailssite/

Now my push targets are in place.<br /><br />The last bit is adding a set of hooks on the target repository so that on each push the repo is updated, migrations are run, and the app is restarted. I’ve created /data/site/myrailssite/.hg/hgrc as follows:

incoming = hg update -C && RAILS_ENV=production rake db:migrate && touch tmp/restart.txt

And that’s it. Now an hg push production force syncs the remote repo, runs any new migrations, and restarts passenger. A 1 step command, and everything is live.

While I’ve been a huge Ruby on Rails fan for the last year, deployment always sort of sucked with it. Now I’m a very happy camper with this setup which makes for very seemless development of rails applications.