naildrivin5.com

Website of David Bryant Copeland

On Slow Test Suites and CI Servers

November 21, 2017

A few people on Twitter were talking about developers that run their entire test suite only on their continuous integration (CI) server. The idea was that this was a sign of low quality tests, low quality code, or an otherwise bad process. In the past, I felt this way, and “breaking the build” (by checking in code that had failing tests) was viewed as bad. I don’t believe this any longer, and now feel like it’s a critical ability for a high-functioning team to have. Not that it isn’t important to identify low quality tests or code, but what exactly is the value of having a fast test suite?

☞ The JavaScript Ecosystem and Interoperability

October 12, 2017

One of my biggest learnings creating Webpack from Nothing was just how poorly the tools of the JavaScript ecosystem interact and interoperate. Many popular tools are impenetrable monolithic systems that only do half of what you need and are extensible only through dense plugin mechanisms.

The last chapter is an attempt to describe this problem in detail and offer some solutions.

I was surprised at how counter-intuitive each step ended up being—I can totally see why there are so many blog posts describing how to set it up. From a test runner that can’t run tests, to a system that supports presets, but includes none of them, I was faced with many choices along the way, but also faced with completely opaque systems whose behavior and failure modes were unpredictable.

It focuses on Webpack and Karma, which I found very difficult to make work together:

Webpack and Karma’s interoperability is completely opaque to the user. This means that you have no way to know how the tools are working or even observe them working together without debugging into the source code.

If you didn’t make it all the way through the entire Webpack site, this last chapter is worth a read.

☞ Webpack from Nothing: WTF is a Webpack?

October 02, 2017

In writing my latest book, I struggled with the JavaScript module bundler ecosystem, in particular Webpack. There are many (many) blog posts telling you how to set it up that all amount to “Don’t ask questions, just put this JSON in your project.” I hate that. I need to know why things work and what is required to get something to function.

So, I started from nothing, and added Webpack and its various friends only when my project had a real problem to solve. I was surprised just how little configuration was required, but also how painful it was, how broken the abstractions, and how terribly integrated the tools in the JavaScript ecosystem are.

Join me on the journey and you will learn a lot about Webpack, JavaScript, and why it can be so frustrating to live in this ecosystem.

During your journey through this site, you’ll use Webpack, Karma, Jasmine, Babel, and many different plugins and extensions, all to get a very basic development environment working. There will be little handwaving. We’ll add tools and configuration only when needed to solve a specific problem.

Stacktrace Typography

September 13, 2017

I’m not obsessed with typography, but I have a healthy respect for it. I talked about typography and source code a while back and I’d like to revisit the subject, but focus on dreaded stack traces. Stack traces happen when your code hits a situation it can’t handle, and most programming languages give you a giant vomit of files and locations that are nigh unreadable. Can we apply typographic principals to them to help us better understand why our code fails?

Four Reasons Developers are Unproductive

July 17, 2017

We all feel unproductive at times, and we can be sure that our bosses, clients, or co-workers feel we are being unproductive at times as well. And, because developer productivity is so hard to measure or talk about, it can feel frustrating to be in a situation where you are feeling or perceived to be unproductive. Rather than dwell on these feelings or postulate new broken ways to measure productivity, I want to talk about the reasons a developer might be unproductive. With some self-awareness, you can improve your situation.

Rails, Angular, Postgres, and Bootstrap is Done and in Print!

June 25, 2017

What started as a quick update to Rails, Angular, Postgres, and Bootstrap to add support for Angular 2 ended up being a pretty big rewrite on account of Rails 5.1 and Webpacker. And the book is better for it! I can’t overstate how well Webpacker works at allowing a Rails application to have a modern front-end.

In my imagined Rails 6 keynote, in “Front-End 2.0”, I imagined a lot of changes around the front-end, and while the exact features I listed didn’t come to pass, the underlying problems they solve are addressed by Webpack and Webpacker.

Webpacker basically creates a canonical, simple configuration for Webpack that allows for easy extension. It can totally replace the asset pipeline and allow Rails developers to use all the modern front-end tools in wide use elsewhere in the industry.

Although my book has Angular, Postgres, and Bootstrap in its title, Webpack is the key feature that allows the front-end to work so well. Without doing anything other than running two Rake tasks, you have a fullly-featured asset pipeline that supports ES6, TypeScript, and Post-CSS.

The unit testing was not as easy, but the book also has you set up Karma and that worked great as a test runner. The application you build in the book really feels full-stack and modern.

If you want to know how to create a modern, productive Rails application, buy the book now. It’s complete and in print.

☞ I'm Co-authoring Agile Web Development With Rails

May 11, 2017

Hot off the presses is the latest beta of the seminal Agile Web Development With Rails, where I’m joining Sam Ruby as co-author. I’m really excited to be working on this classic book, and doing my part to keep Rails relevant to web developers.

The beta features sections on Webpacker and system tests, new in Rails 5.1. Much more to come as the beta progresses!

☞ Patterns of Service-Oriented Architecture

May 09, 2017

Fresh on the Stitch Fix Engineering blog, the first in a several-part series on the patterns we use in our service-oriented architecture. From the intro:

Over the last four years, we’ve gone from a team of two developers and one Rails app, to almost 80 developers managing 40+ applications. These applications are a mixture of user-facing and headless services. While our technical architecture isn’t perfect, we’ve had relatively few major problems. Part of the reason for that is that we’ve done a decent job of identifying and re-applying patterns to solve similar technical challenges.

The first pattern is also up: Asynchronous Transaction