Mastering ActiveAdmin

Did you know ActiveAdmin was awesome?

For the last 6 months I tried adapting ActiveAdmin to three projects with pretty different goals. And it was a great success for each of them. However everything comes with a price. ActiveAdmin has excellent DSL but it lacks architectural quality and feature-richness (mainly due to extremely slow development progress).

The main goal of this post is to share my vision of administration frameworks potential we could expect. While ActiveAdmin in my opinion is the first one that finally felt the ground.

Blog post format is not the best one to gather all the issues (while GitHub definitely is) – so I’ll keep it short addressing main of them. After “why I think AA is the true way” introduction I’ll do a bit of interface nit-picking. And that’s probably the most interesting part for you cause you can grab all that tiny improvements and add them to your own AA integrations. Second part on the other hand describes fundamental architecture lacks and possible alternative implementations.

Redistributable Rails applications

Imagine you have a large Rails application that you are going to distribute. That’s might be a new world-crashing CMS or incredibly modern Redmine fork. Every separate installation produced by a consumer requires different configs. Or maybe even some code that will adapt your product for particular needs using amazing internal API.

Clever consumer will also want to store such a “deployment” in his own git repository. And as the last point – he will definitely require a nice way to maintain ability to upgrade your product within required version branch.

How do you achieve that?

Let me share my story first. I manage two banking products: Roundbank and Smartkiosk. They are Rails applications. Every time bank wants to deploy Roundbank-based internet banking I need a way to:

1. Get my core and create a nice new look that will match bank’s design using internal API.
2. Extend core with the transport methods that are required to integrate with bank’s core banking platform.
3. Support it.

First two steps are pretty easy. It can even be a fork on the Github. And then comes third. Release management crashes. Especially if bank has own team that’s involved. Another downside of forks is that your consumer has the whole codebase inside his project. You might not think so but… damn! So provocative! You remember he’s not supposed to change anything right?

Joosy: alternative approach to browser frameworks

Long story short

We created a new JS framework that doesn’t clone anything existing but uses slightly different approach. Joosy we call it.

• Joosy website
• Getting started guide
• Github Repo

Real introduction

Ourdays even a lazy and his grandmother is doing his own JS MVC framework. The reason is simple: we really need it. The problem, on the other side, is that everyone is just cloning Backbone. There is also Knockout and Ember that went a different way. Still not enough to satisfy sophisticated audience. The problems are different. Some may dislike Handlebars. The others won’t fit general API. It’s a matter of taste after all. The options are always good if you choose between something different.

Heimdallr: ORM field-level security

We are currently migrating most of our products to browser-side application. One of the worst issues it raises is proper permissions handling. There are no comfortable ways to implement context-based protection of models (and their fields) within ActiveRecord (Egor, say hi ;). attr_acessible is too weak. CanCan is too abstract (doesn’t go down to fields).

We’ve figured out something awesome to solve this issue. Meet Heimdallr and it’s extension Heimdallr::Resource. They will bring you a peace and security.

Heimdallr

Let’s start from the deeper problem investigation though. Large part of Rails projects equates security to a REST restriction. The bigger projects sometimes fall down to a model to keep code DRY. And to keep your controllers/actions number from getting wild you may fall down to fields.