naildrivin5.com

If you regularly work with web technologies, you’ve no-doubt pulled your hair out dealing with the technologies used for front-end development (and, let’s be honest, back-end development, too :). Almost everything about front-end work feels terrible, from the weakness of JavaScript as a language, to the myriad half-documented tools that all somehow manage to do less than make, to the absolute bizarre notion that we are building user interfaces with technologies designed to write term papers.

But why are these experiences unpleasant? I would argue simply that they don’t fully meet our needs as programmers. And we can think about those needs as a hierarchy, each need building on the need below it.

My talk from Full Stack Toronto, called “Rails, Postgres, Angular, and Bootstrap - The Power Stack” is up, where I make the case for using not just using a CSS framework, an MVC framework, a middleware framework, and an amazing database, but for using Bootstrap, Angular, Rails, and Postgres and using them together.

Today through next Tuesday, all three of my books are on sale for 40% off, with the code turkeysale2015:

• Rails, Angular, Postgres, Bootstrap: Powerful, Effective, Efficient Full-stack Web Development ($14.40 for the beta ebook!)
• The Senior Software Engineer: 11 Practices of an Effective Technical Leader ($15!)
• Build Awesome Command-Line Applications with Ruby 2 ($13.20 for the ebook!)

Just use code turkeysale2015 at checkout to get 40% off!

Before using Postgres, I would have to rely heavily on Rails validations to ensure data integrity—MySQL simply doesn’t provide the tools to do this. This always felt wrong. Outside of rogue processes connecting to the database, there’s also application bugs and, well, the ActiveRecord API itself: update_attribute skips validation! That means it’s hard to rely on Rails validations for data integrity, but there isn’t a great alternative for creating a great user experience.

Postgres has the answer: check constraints. As we’ll see, check constraints are tool for data integrity and work much better than Rails validations. But Rails validations are still a great tool for user experience.

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.

In September 2011, I interviewed at Instagram. While I didn’t ultimately get/take the job¹, the experience had a pretty profound effect on me as a developer.

What I learned during the interview process (which was really enjoyable, and became the basis for my ideal technical interview process) was just how much two engineers with relatively little experience could accomplish.

A tenet of design is that things that are the same should be obviously the same, and things that are different should be obviously different. This is the most basic way to create consonance and contrast, and is a great rule of thumb when designing anything. While Rails diverges from this in an annoying way¹, Angular diverges in a baffling way that makes explaining it to a newcomer head-scratchingly difficult.

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.