One thing we do a lot of here at DevMynd is read code. Reading code and making sound judgements about […]

One of the things we do for almost every client at DevMynd is evaluate technologies. There are a set of staple technologies and frameworks that we almost always use – Ruby, Ruby on Rails, Postgres, Sidkiq/Redis, jQuery, etc. – but there are almost always project specific needs that lead us to think about other tools. As consultants we've developed a kind of sixth-sense about tools, techniques, and technologies, an intuition about what will work and what will last. The qualities of this intuition can be broken down into four categories: stability, longevity, transferability, and portability.

This is the second post in a series exploring some of the ways we can use the Rails framework more effectively when building large applications. In this edition, we'll be sticking with the ActiveRecord theme from the previous post and look at the effects of the ActiveRecord API on our controllers and views.

In the last three weeks we’ve had two DevMynd clients and a firm that we advise run into major problems. […]

We work with Rails a lot here at DevMynd. We love Rails, but we’re also the first to admit that like any framework it has some tricky bits. Careful use of the framework (avoiding the parts that really cause trouble) can make building complex applications in Rails less frustration-prone. Apps become more resilient to change when these features are used cautiously. This is the first post in a series that will explore techniques for effectively using some of the often misunderstood and abused parts of Rails.