naildrivin5.com

Website of David Bryant Copeland

Rails Validations vs Postgres Check Constraints

November 15, 2015

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.

☞ Embrace the Full Stack

November 05, 2015

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

☞ Simple Rails Apis With Stitches

November 04, 2015

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

July 29, 2015

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.

Naming and API Design

June 15, 2015

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 way1, Angular diverges in a baffling way that makes explaining it to a newcomer head-scratchingly difficult.

☞ Anatomy of a Rails Service Object

June 02, 2015

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.

How to be a Great Software Engineer in 2 Steps

February 21, 2015

  1. Understand what problem you are trying to solve. So many skip this, or don’t spend enough time on it or don’t even realize that it’s something to do. The main failure of good programmers that I’ve seen is in not knowing what problem they were trying to solve.
  2. Figure out what you need to do to solve the problem before you solve it. This can be anything from skimming the code you’re about to change to organizing your thoughts in a full-blown design document. You have to have a good idea of how you’re going to go about solving the problem in the code.

You can apply these steps to pretty much anything you need to do, from fixing bugs, to implementing features, to writing emails, to holding meetings. If you know what problem you’re trying to solve, and have a good sense of how you’re going to do it, actually solving it becomes a lot simpler and a lot easier to get right.

☞ What You Don't Get With ActiveJob

October 01, 2014

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.

☞ Why Scrum Should Basically Die in a Fire

September 18, 2014

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.