The latest edition of PragPub is out, featuring an article I wrote on embracing the full stack. This is more of a motivator for why you should be more well-rounded as a developer (which then should motivate you to buy my new book :). I cover things from grid-based design to database indexes.

This may seem like an immense amount of learning and work, but it hopefully feels more achievable now. You could get a cursory understanding of these topics in a week. What happens when you do is that you start to take a more holistic view of your application and of how to build features.

Pick up your copy here

New post on the Stitch Fix Tech Blog about how we create Rails-based HTTP APIs using a simple gem called stitches:

With this set of conventions, it was important that developers not feel these were optional features they could leave out to cut corners, so it seemed logical to make it as painless as possible to follow them. The result is stitches, which works as a generator and backing library. It’s not an engine or a DSL or anything complex. It’s just a bit of Rails configuration, designed to be explicit and obvious.

My new Book, Rails, Angular, Postgres, and Bootstrap: Powerful, Effective, and Efficient Full-Stack Web Development is in beta:

As a Rails developer, you care about user experience and performance, but you also want simple and maintainable code. Achieve all that by embracing the full stack of web development, from styling with Twitter Bootstrap, building an interactive user interface with AngularJS, to storing data quickly and reliably in PostgreSQL. Take a holistic view of full-stack development to create usable, high-performing applications, and learn to use these technologies effectively in a Ruby on Rails environment.

I’ve been working on this for quite a while, and pretty excited about it. If you want to really level up your abilities as a Rails developer, this is the book for you.

I haven’t been good at blogging for a while. Most of my writing has been toward a new book (details forthcoming), but I did manage to write up how I see designing service objects for Rails applications over at Stitch Fix’s Eng Blog.

Anatomy of a Rails Service Object:

We’ve given up on “fat models, skinny controllers” as a design style for our Rails apps—in fact we abandoned it before we started. Instead, we factor our code into special-purpose classes, commonly called service objects.

The post goes over six rules of thumb that I’ve found useful, including class design, method parameter, and return values.

Post by yours truly on Sitepoint’s Ruby section, “What You Don’t Get With ActiveJob”:

ActiveJob provides simple solutions to two problems faced by Rails developers when writing background jobs: queueing jobs (via the ActiveJob API) and serialization of ActiveRecord objects (via GlobalID).

It doesn’t, however, help with the third problem: writing resilient jobs that can survive in a production environment.

Giles Bowkett posted a great piece on the deep flaws of Agile processes like Scrum. It’s spot-on with my experience. There’s so many choice quotes, it’s hard to pull just one, but I’ll try. Toward the end of the article:

I’ve never seen Scrum-like frameworks for transmuting the work of designers, marketers, or accountants into cartoonish oversimplifications like story points. People are happy to treat these workers as adults and trust them to do their jobs.

I don’t know why this same trust does not prevail in the culture of managing programmers.

After a job converting JIRA Tickets into Story Points into diffs, I eventually realized that good developers deliver results, not promises, points, or even features. I even wrote an entire book about it.

Thankfully, the team at Stitch Fix has no sprints, story points, velocity, or planning poker. We just solve the most important problem at hand, and move onto the next most important one.