Programming Posts

A Production-Ready Rails 5 Email Workflow with Mailer Previews, Premailer and ActiveJob

A Production-Ready Rails 5 Email Workflow with Mailer Previews, Premailer and ActiveJob

Since the introduction of Mailer Previews and ActiveJob in Rails 4.1, the framework has truly set itself apart from others in the comprehensiveness and comfort of its workflow around emails. The framework’s creator, DHH, has espoused a perspective that mailers are views, and accordingly Rails now gives us an email workflow that is nearly identical to that around ordinary controllers and views.

I will walk through my complete email stack and workflow, which I have used very effectively across several production apps.

Validation Contexts in ActiveRecord

Validation Contexts in ActiveRecord

Validation contexts are a little-appreciated but immensely practical feature of Ruby on Rails’ object-relational mapper, ActiveRecord. I cannot count the number of times I have seen hacks around a problem for which a validation context would have been a perfect fit simply because this feature lives a bit under the radar and isn’t in every Rails developer’s toolbox.

What is a validation context, precisely? It is a way to constrain a model validation to a particular usage context for a record. This is similar to what you might achieve with something like state_machine, but far more lightweight.

Less Code
This desk is not mine

Less Code

These days I increasingly feel that I am in a minority in my deep appreciation – love, even – of the heaviest weight of heavyweight dynamic MVC web frameworks: Ruby on Rails. I have worked, now, with many of the more popular frameworks on both the server and client side. Flask, Django, Web.py, React, Angular, Express JS, Sinatra and others. I still come back to Rails.

I belive that, for the overwhelming majority of domains, it is the tool – if weilded with healthy reverence for its conventions and idioms – which leads to the most manageable, consistent, non-redundant and all-around sane codebases.

Rodney Mullen on Hackers and Open Source

Rodney Mullen on Hackers and Open Source

I was at a party several days ago and found myself talking to a bunch of other developers about skateboarding. We realized we had all been really passionate skateboarders through some part of our youth. Later that same night, surfing youtube, I found this TED talk by Rodney Mullen, one of the most important figures in the whole history of the sport. I couldn’t believe it when he turned to the subject of hackers and open source software. So unexpected — and yet so relevant, it turned out, to the broader subjects of the talk.

Pattern Vision Redux

A couple years ago I read an article DHH had posted to 37Signals’ “Signal vs. Noise” blog called Pattern Vision. I love that article not because it is at all profound. It isn’t. Kind of the opposite. I love it because I could have written it. The ways of thinking described in it are overwhelmingly common in the work I come across and live with day to day. Every new codebase I encounter seems to carry some new dubiously-applied patterns, some new collection of less-than-idiomatic directories, modules and classes for me to discover nested within “/app”.

In Praise of the Humble Website

The other day I had an informal talk with a friend about a project we had been offered. I can’t divulge much about the project but I can say that it has, structurally, a lot in common with an ecommerce app. Users shop a class of product and check out, they’ll also be able to use common coupon codes like the ones found on websites like Raise. Work has already been done on this app. The “MVP” that has been built has a wholly decoupled “thick client” browser-based UI built in AngularJS. I have a decent amount of experience with AngularJS as well as the other, similarly popular (possibly moreso) javascript MVC framework Ember.js.

I have seen a trend firsthand in the last several projects I have been offered – and a couple that I have taken on – toward the use of these javascript frameworks and decoupled, thick client architectures. Stunningly, in every one of these cases, the architecture is unambiguously more burden than benefit (much more, in fact) in respect of both development load and user experience.