If you are using [ActiveAdmin][1] or [formtastic][2] (which ActiveAdmin uses under the hood) and are having trouble rendering a form with an encrypted attribute like with [Strongbox][3] the solution is very, very simple. Perhaps though it is not so obvious.

What you might be seeing is something like this…

Unable to find input class for binary

With the source of the error being

insert_tag renderer_for(:new)

Fix It!

Lets look at this contrived example and assume that the ssn attribute is encrypted by Strongbox on our User model. The ssn column in my experience then should be a binary type in your db/schema.rb. That translates to bytea in Postgresql, and blob in MySQL and Sqlite3.

  form do |f| 
    f.inputs "User" do
      f.input :email
      f.input :password
      f.input :ssn
    end 
    f.actions
  end

All we have to do in order to get out of this hole is to tell...

After spending most of my work day evening installing wkhtmltopdf on my MBP I feel it necessary to at least document my decisions and what actually worked.

I try to use Homebrew for everything I possibly can that does not come with and work natively out-of-the-box with OSX. In the past I have installed wkhtmltopdf from Homebrew (I recently did a clean install on this MBP). From what I can see there is not an officially supported Homebrew formula for this currently available. There are some pull requests that I could install from but after reading through them the future of Homebrew and wkhtmltopdf being friends looked a bit bleak. I’d rather not hang my hat on pioneering developers attempting to convince two parties that are having a philosophical disagreement to make a compromise. There is nothing wrong with the philosophical disagreement that seems to have occurred between the...

Problem

At the time I was working on a project that had two application servers on AWS EC2 running behind an EC2 load balancer. For a reason I never uncovered when I would deploy to one of the application servers the application would become unavailable for a period of time even though the other application server was not interrupted. Therefore the process to deploy the project was to deploy to one instance at a time, modifying the Capistrano recipe at least once for every release. This got old pretty fast. What I wanted was to get prompted with a numbered list of servers upon deployment, enter the corresponding number and have Capistrano deploy to that server only. Then I could swap the servers out on the EC2 load balancer, and run it again this time picking the other server.

The Solution

I looked at a few gems that appeared to provide the desired functionality by extending...

Every time I go to setup a dedicated user in a MySQL database server to support a Rails application I find myself searching the web for the privileges that Rails needs. By the way, if you are hooking to a MySQL database in your Rails application and using the root account to connect the app to the database, you are doing it wrong.

I’ve decided to document them here with a snippet of SQL for easy reference. Below are the minimal necessary privileges needed by Rails to do its thing. I built this list during Rails 3 but I’m not aware of Rails 4 needing any privileges beyond what is below either so it should work as of Rails 4.

• Select
• Insert
• Update
• Delete
• Create
• Drop
• Index
• Alter
• Lock Tables

If your Rails application does anything out of the ordinary additional privileges may be necessary.

Below is how you might setup a user on your MySQL server from the MySQL command line.

CREATE

I am working on an app where I wanted to use ActiveAdmin. The
interesting part is we are using Mongo for the database and chose
Mongoid as the ORM. At this time ActiveAdmin is not natively ORM agnostic. I found this Github Repository demonstrates the necessary patching needed to allow ActiveAdmin and Mongoid to coexist and work cohesively to deliver an admin interface. The critical change is the patch in initializers. Depending on your configuration though you may also need to make some tweaks in app/admin.

In order to maintain compatibility with our hosting environment as well as keep the app fresh and up to date, we put the app on Rack 1.4.1 and Rails
3.2.x. This required upgrading meta_search gem and ActiveAdmin gem.
Afterwards some of the patching that had been done started whipping
nasty errors around.

superclass mismatch for class ResourceController (TypeError)

Here is the...