ActiveRecord should have its own command line interface, and so should your rubygem

A common criticism of building applications outside of Rails is the loss of a great, integrated tool chain.

You don’t pick Rails as the engine for powering your API simply for the asset pipeline, you pick it for all the other stuff @macaw pointed out! If you hook up Sinatra and Sprockets, you are without Rails’ ORM, migrations, generators, routing, test infrastructure, plugin ecosystem, and arguably most importantly, the conventions and agility.

There is some truth to that, but it doesn’t have to be that way.

I’m going to pick on ActiveRecord. The internet is littered with posts about using ActiveRecord outside of Rails. Most solutions involve hacking together a Rake file that deals with this stuff. Its a pain.

Rails has already established the convention that database schema management files are stored in the ./db/migrations folder. That same convention could easily be extended to other Ruby projects with an ActiveRecord binary:

$ activerecord migrate --path ./db/migrations

Boom! Now migrations are painless in non-rails applications. You can imagine what a good command line interface could do for ActiveRecord:

$ activerecord help
activerecord init .                      # Creates a db/migrations folder
activerecord create -e development       # Creates database
activerecord migrate -v 200120812051234  # You get it...

An ActiveRecord binary would only be concerned about managing the database; you don’t need all of Rails to deal with that. Sequel, a really light-weight ORM gem, already does this. I recently switched a project over to that because of its migration CLI, amongst other things.

Inspired?

When you build your next gem, give this some thought. Thor makes this really easy. As Rails has taught us, conventions can be a good thing. For a marginal amount of effort those conventions can be made available to a much wider audience.