FlexibleConfig promotes good OOP design, and the separation of logic and configuration in your Ruby classes.

FlexibleConfig allows you to set class constants cleanly in ruby with the heirarchical structure and clean workflow of YML config, without sacrificing the flexibility and immediacy of ENVironment variables.

You might have read the infamous blog posts titled “Rails is Dead”, but I have seen development teams flounder over and over again when they try and reinvent the wheel using NodeJS on the backend.

The “greenfield” project is known by developers as a productivity Nirvana. It is a beautiful place where there is no legacy, no bugs and endless possibilities. It is also littered with mines.

I’ve recently seen a number of anti-patterns around the creation and early growth new projects, and thought I’d summarize the anti-patterns I’d seen in the past as a guide for developers to avoid these common pitfalls.

ActiveHash is a simple base class that allows you to use a ruby hash as a readonly datasource for an ActiveRecord-like model.

ActiveHash assumes that every hash has an :id key, which is what you would probably store in a database. This allows you to seamlessly upgrade from ActiveHash objects to full ActiveRecord objects without having to change any code in your app, or any foreign keys in your database.

It also allows you to use #has_many and #belongs_to (via belongs_to_active_hash) in your AR objects.

ActiveHash can also be useful to create simple test classes that run without a database - ideal for testing plugins or gems that rely on simple AR behavior, but don’t want to deal with databases or migrations for the spec suite.