I recently read Chad Fowler’s The Passionate Programmer, a book broadly concerned with finding fulfillment through work in software development. The book had an unexpectedly strong impact on me. Many of Fowler’s key points aligned uncannily with recent experiences and observations of my own. One section that leapt out in particular to me concerned practice.
I’ve been lazily running this blog since 2013, though for long stretches I’d find time to post only every few months. Initially I published with a minimal blogging engine I’d written myself in Ruby on Rails. At some point I came across Tom Preston-Werner’s article Blog Like a Hacker in which outlines the many raisons d’être for his static site generator, Jekyll. The thrust of it all is that the tools we use for managing code, such as the Git version control system, are actually uncannily suited to prose writing as well. In fact adopting a programming-like workflow and tooling for your blog alleviates some very real pains that you’ll experience if you use a more ordinary CMS like WordPress.
The jQuery-UJS (“Unobtrusive Javascript”) library has been around since 2010, making it quite old by the standards of frontend tooling, whose pace of evolution is swift. In many contexts, however, jQuery-UJS, along with complimentary Server-generated Javascript Responses (SJR) still surpass more modern frontend tooling and frameworks in metrics that should matter to anybody building a web app with dynamic UI requirements, even in 2016.
The most profound virtue of UJS is probably how palpably it minimizes your overall code surface area. AJAX bindings are made to the specification of certain data-attributes read off of elements in the DOM, which in practice oftentimes means a lot of boilerplate Javascript files you might otherwise have in your codebase you simply do not need. Furthermore, with UJS, most of the custom Javascript that you do execute to implement your rich user interactions is, by necessity, nicely compartmentalized in server-side templates oftentimes only 1-3 lines long, and very clearly named and situated.
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.
Though Cron has been around since the 1970s, it is often still a perfectly viable, incredibly robust way to run scheduled jobs for your web application – in particular if you deploy your app to a single dedicated server or VPS.
Whenever is a command line utility, written in Ruby, that lets you declare your Crontab entries using the very human-readable Ice Cube DSL, and that includes related utilities to actually write out to your Crontab based upon these human-friendly source files. The benefits for your project are twofold. First, you get to define your Crontab entries in a language that is natural to read rather than in the famously obscure and forgettable native syntax. Second, you get to keep your schedule definition within your project tree so that it becomes, in effect, integrated with your application rather than something managed separately with your infrastructure.
I have been away from New York much more this past year than I’m accustomed to and have been trying to encourage myself to take more photos, since it is not a habit I’ve cultivated at home. I thought it would help if I kept a photo log up here on my personal site and so I made ZPhotostream, a simple but featureful-enough photo log app that I could style to my liking and host myself.
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.
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.
Hi, my name is Nicholas and Hacker Notes is my personal blog. It is a collection of practical things I’ve picked up through my work in software, as well as writings on other subjects like seed-stage investing, travel and art. You can read more about the site and me by clicking here
