In exploring the modern front-end ecosystem for my new book, I’ve gotten to experience some truly difficult configuration formats (Webpack) and to work around aspects of Rails that aren’t configurable (Sprockets). Configuration is hard, and it’s an overlooked part of the user experience often designed to make the software library author’s job easier at the expense of ease-of-use.
It doesn’t have to be this way.
Craig Kerstiens wrote a great short blog post about writing more legible SQL. It’s a great read on an important topic—SQL can be very hard to read and modify—but I don’t think he goes far enough about “one thing per line”, so I’d like to show how I write SQL.
The second edition of Rails, Angular, Postgres, Bootstrap is in beta.
There’s a lot of new content, mostly around Angular 2.
Of particular interest is that we aren’t using the Asset Pipeline, but are using Webpack. I tried hard to get Angular 2 working with Sprockets, but as Giles Bowkett points out in a recent post, Sprockets is not a modern tool for modern JavaScript.
The current beta is about 75% complete and includes:
Angular 2’s setup was painful, but it’s a much nicer framework than Angular 1, and requires a lot less plumbing and decision-making than React (based on my limited experience with React).
The skills you learn in this book will let you solve a wide variety of problems quickly, cleanly, and efficiently, using modern and powerful tools.
Note: if you bought the first edition, stay tuned—I’m not sure what accomodations will be made
This is a series of posts about why I recommended the changes I did for Rails 6, in my imagined keynote for Rails 6.
In this one, we’ll explore why I think having explicit support for creating non-model service objects would be a good thing.
This is a series of posts about why I recommended the changes I did for Rails 6, in my imagined keynote for Rails 6.
In this one, we’ll explore why I recommended changes that encourage a more resource-based design.
This is a series of posts about why I recommended the changes I did for Rails 6, in my imagined keynote for Rails 6.
In this one, we’ll explore why I recommended the removal of jQuery, and the change from CoffeeScript to ES6.
This is a series of posts about why I recommended the changes I did for Rails 6, in my imagined keynote for Rails 6.
In this one, we’ll explore why I recommended the removal of per-view CSS and the inclusion of an “OOCSS”-style framework.
In my imagined keynote for Rails 6, I imagined a lot of wacky new features for Rails. My Rails 6 had lots of big changes, and I thought it might be interesting to dig into why I think those changes are useful for Rails.
Getting configuration from the UNIX environment is a hallmark of 12-factor application design, and is a great practice. Problems arise, however, when your code is littered with direct references to it. This is because the UNIX environment is a very poor database, but we need to treat it as a better one.
I gave a talk at RailsConf ‘16 called “Can Time-Travel Keep You From Blowing Up the Enterprise”. The talk is really about scaling Rails on a growing team, and attempts to stop the discussion around “monolith vs microservices” by showing how a team can take hold of its destiny.
It’s also the exact way Stitch Fix engineering evolved, and while we have some large Rails apps, none are the monstrosities I’ve seen elsewhere.