Showing posts with label Cloud Computing. Show all posts
Showing posts with label Cloud Computing. Show all posts

Tuesday, June 8, 2010

Casein CMS on Heroku

When evaluating some Ruby on Rails CMSes I mentioned Casein (which I wouldn't really classify as a CMS). Its more of a plugin that provides admin authentication and pretty CRUDification of resources. I'm doing my development staging on Heroku and needed to ensure that it runs on Heroku. Here's a couple of Gotchas!

Gems
Gems on Heroku are installed using a .gems manifest file. 2 gems required: calendar_date_select (>=1.15) and will_paginate (>=2.3.11). Adding these two gems to the manifest will ensure they are installed when you push the application.

calendar_date_select --version '>=1.15'
will_paginate --version '>=2.3.11'

You'd be forgiven for thinking this would resolve the issue, however, there is another reference to the gems as part of the plugin that causes the application to fail. In /vendor/plugins/casein/init.rb comment out the two lines that configure the gem.

#config.gem "calendar_date_select", :version => '1.15'
#config.gem 'mislav-will_paginate', :version => '~> 2.3.11', :lib => 'will_paginate', :source => 'http://gems.github.com'

Caching
As part of the magic the Heroku fairy godmother provides (Building upon the AWS and S3 storage service), the clock strikes 12 when you attempt to write to the file system. Simple, Heroku slugs operate in a readonly context. The caching currently written in Casein, primarily for static resources like Stylesheets and Javascript, attempts to write to the file system. The first instance you will encounter this is on the authentication page. The layout file is in /vendor/plugins/casein/app/views/layouts/casein_auth.html.erb. Change the line:

<%= javascript_include_tag :defaults, "/casein/javascripts/login.js", :cache => "casein_auth_javascripts" %>

to:

<%= javascript_include_tag :defaults, "/casein/javascripts/login.js" %>

That should get you up and running. My next stumble was running the casein:init rake task but as I'm probably not sticking with the platform I may or may not investigate a solution for that.

UPDATE: Not sure what's wrong with the rake task, but the task is not doing much. See /vendor/plugins/casein/tasks/casein_tasks.rake to see what the task does. It runs the migration, removes all existing users and then creates the admin. If you've already run this locally, I'd suggest simply using heroku db:push to transfer your local data to Heroku. Sadly I'm not going ahead with Casein so this is it for me.

Saturday, May 22, 2010

Amazon Web Services Meetup - Melbourne

I recently attended a cloud computing meetup in Melbourne hosted by an Amazon Web Services evangelist. I'm usually quite sceptical of the content of such meetups - I've met my share of salesmen from big vendors in my career - but the community aspect of such a meeting was too tempting to ignore. There was about 35 developers in attendance, mostly rubyists and sys-admin types. In all it was a productive session which had me thinking, when will I put this to use?

It turns out, one of the systems I've previously built has been languishing in neglect because of expensive and unmanageable Java hosting. I used to host a Virtual Private Server (VPS) for about 90$ (AUD) a month. This hosted a Tomcat Server, MySql, mail server and my website (PHP). I found this to be quite an expense, given the demo was rarely accessed - as it is specialised software. Also I had the hassle of cleaning up the data so that prospective clients found a professional demo ready for their use. This also needed to allow for long term trials so cleaning up the database every hour wasn't feasible.

It is a tribute to the maturity of Amazon's Web Services that it has been able to meet my requirements. I am in the process of chronicling the challenges I faced in creating this on-demand demo service.