A practise I always follow while working with tools that generate code is that any code that is generated and not written by me is committed in isolation. This makes skimming through commit logs later easier because generators often generate many files upfront that wouldn’t be edited until much later. So the subsequent commit wouldn’t be littered with changes that aren’t directly related to the actual operation mentioned in the commit message. Also while browsing through commit diffs keeping generated code in their own commits speeds up the reviewing process – because in most cases we already have an idea of what the generated could be, so it can be skipped.
Devise is an incredibly popular authorization gem for Rails. Unfortunately allowing a user to log in through multiple emails is not as straightforward as one might expect. This post outlines a way to do just that.
Rubyzip is pretty much the defacto solution for manipulating zip files in ruby. However an underdocumented feature of this library is that it allows for creating zip files in memory ie. without actually writing anything to a file.
The Single Table Inheritance facility in Rails is quite awesome in that it is simple, minimal and easy to understand. However that simplicity comes with a small price – the type column stores the full name of the relevant class as a string. This becomes especially unweildy if you scope your models inside a module.
SQL Views are a handy feature that allow us to save a query whose results are computed/collated dynamically whenever the view is requested. Because the abstraction provided by a view is semantically close to a table we can leverage ActiveRecord to interface with the view through a proxy model and use it to present the result set through ActiveAdmin interface.
In past developers have often relied on backend-specific toolchains for web application frontends. Some examples would be Rails asset pipeline or the legacy ant based toolchain for YUI. However recently node.js based tooling support for frontend technologies has significantly evolved and it is quite viable to use a node.js based toolchain for managing your frontend projects, even if the backend is not node.js, thus keeping the workflow decoupled from the backend.
While emacs is well known to be a very productive editor, there are a few additional steps one must take to set it up as a development environment for Ruby on Rails. This post outlines my current setup.
One of the biggest promises of Node.js is code re-use across client and server – this post focusses on reusing server side templates on client as well for dynamic rendering.