Paperclip, Heroku and Amazon S3 credentials 4

Posted by Slobodan Kovačević on January 24, 2011

Setting up Paperclip to use Amazon’s S3 is as simple as setting :storage => :s3 and providing right credentials to Paperclip by setting :s3_credentials option. Best way to provide S3 credentials is to use an YML file (usually config/s3.yml) which allows you to set different credentials for each environment. For example:

# config/s3.yml
development:
  access_key_id: XYZXYZXYZ
  secret_access_key: XYZXYZXYZ
  bucket: mygreatapp-development
production:
  access_key_id: XYZXYZXYZ
  secret_access_key: XYZXYZXYZ
  bucket: mygreatapp-production

Of course you want to treat s3.yml same as database.yml – i.e. you don’t want to track it with git and you want for each person/server to have it’s own.

However, consider this: you are working on Open Source app in a public git repository and you are deploying it on Heroku. Heroku doesn’t allow you to create files (unless they are in git repository) and you can’t commit s3.yml with your credentials to public repository.

One solution is to define different :s3_credentials hash in one of the environment files or to load different YML file for each environment and generate hash from it. Downside is that you need to have a separate YML file for each environment and/or you need to convert YML to hash. Other solution could be to have separate local branch from which you will push to Heroku. Problem with this is that you have to have a local branch for deploying. This means if there are multiple developers who deploy to production each should have separate local branch.

Much simpler way to deploy Paperclip with different S3 credentials for each environment (with one of the environment being deployed on Heroku; and repository being public) is to create s3.yml file as usual (and don’t commit it to git), but define values only for local environment.

For production deployment on Heroku you can write initializer which will set :s3_credentials from ENV variables.

# initializers/s3.rb
if Rails.env == "production"
  # set credentials from ENV hash
  S3_CREDENTIALS = { :access_key_id => ENV['S3_KEY'], :secret_access_key => ENV['S3_SECRET'], :bucket => "sharedearth-production"}
else
  # get credentials from YML file
  S3_CREDENTIALS = Rails.root.join("config/s3.yml")
end

# in your model
has_attached_file :photo, :storage => :s3, :s3_credentials => S3_CREDENTIALS

and you can easily set persistant ENV vars on Heroku with:

$ heroku config:add S3_KEY=XYZXYZ S3_SECRET=XYZXYZ

(according to Heroku docs)

Share

Rails 3 reading list

Posted by Slobodan Kovačević on March 29, 2010

I’ve been planning to catchup with all the new Rails 3 stuff. To get me started I’ve compiled a small Rails 3 related reading list.

  1. Ruby on Rails 3.0 Release Notes
  2. Active Record Query Interface 3.0
  3. The Skinny on Scopes (Formerly named_scope)
  4. Rails 3 Beautiful Code
  5. Railscasts – rails-3.0 episodes
  6. jQuery with Rails 3
  7. The Rails Module (in Rails 3)

Once I’m done with it I plan to get even more from:

Share

RESTful admin namespaced controller using scaffolding 35

Posted by Slobodan Kovačević on September 17, 2008

Most of my clients prefer to have a separate admin section. In turn, I like to have separate controllers for admin section and front-end in my Rails app. This is not as straightforward as it might seem, especially if you like to use scaffolding for admin controller.

The goal is to get 2 separate RESTful controllers, admin & front-end controller, one model and for admin pages to have scaffolding.

Here is the easiest way I found so far to accomplish this. This example generates categories model and controllers for it.

./script/generate controller admin/categories
./script/generate scaffold category name:string

This will generate an empty controller in admin namespace and a scaffolded resource for front-end controller.

Now we have everything generated we just need to make it work with admin controller and not with front-end.

  • move all templates from app/views/categories to app/views/admin/categories
  • copy all functions from categories_controller.rb to admin/categories_controller.rb
  • add namespace for admin controller in routes.rb:map.namespace :admin do |admin|
    admin.resources :categories
    end
  • in admin/categories_controller.rb replace in 3 places redirect_to calls to work with admin namespace. It will have something like redirect_to(@category), but to work with namespace it needs to have redirect_to([:admin, @category])
  • make similar changes in all templates, i.e. make it work within an admin namespace. You need to make following changes:
    • form_for(@category) => form_for([:admin, @category])
    • <%= link_to ‘Show’, @category %> => <%= link_to ‘Show’, [:admin, @category] %>
    • categories_path => admin_categories_path
    • edit_category_path(@category) => edit_admin_category_path(@category)
    • new_category_path => new_admin_category_path

That’s it. Now you’ll have /admin/categories for all administrative tasks and you have a free controller for front-end actions.

You might wonder why not just generate scaffold for admin/categories… The reason is that you’ll also get a model that is namespaced in admin (i.e. model would be Admin::Category). Scaffolded views also wouldn’t work as it seems that generator doesn’t take into account the fact that you are using a namespace.

Share

SproutCore – a javascript framework

Posted by Slobodan Kovačević on July 03, 2008

SproutCore is a javascript framework which tries to enable developers to build web apps that look and act more like a desktop apps.

It steps away from a classic web app model by moving a lot of app into the browser itself, which then interacts with server via AJAX. As it says on the SproutCore site:

After lots of testing, we have found that the most efficient way to server a SproutCore application is as a …. static web page!

This means that a “simple” static HTML page (which is easily served by Apache) makes browser do most of the work (i.e. server doesn’t have to generate the pages) which frees up server to respond only to AJAX initiated requests.

SproutCore is written in Ruby, but once you build the app it will generate a set of HTML, JS and CSS files, so you don’t need to know Ruby in order to use it. As the site says:

The code you write with SproutCore will resemble a desktop app written in Cocoa more than it will a web application written in Rails.

SproutCore Photos Demo ScreenshotAnother great thing about SproutCore is that it can be hooked up with any backend as long as it can communicate with it using HTTP. It can be anything: Rails, PHP, Perl, Java, ASP…

Actions speak louder than words, so take a look at the SproutCore demos which shows you exactly what it’s all about.

In next few days I will try to build a sample application powered by SproutCore and Rails to see how it goes. I will post my impressions here. After all if it’s something Apple used for Mobile.me – well, it can’t be that bad. ;)

Share