Website of David Bryant Copeland

June 12, 2018

Most websites are a mess of decoration, hijacking, dark-UX, and general chaos. Few designs serve the needs of the user. One way
to do that is to embrace websites for what they are, by adopting a form of brutalism for web design:

Content is readable on all reasonable screens and devices.

Only hyperlinks and buttons respond to clicks.

Hyperlinks are underlined and buttons look like buttons.

The back button works as expected.

View content by scrolling.

Decoration when needed and no unrelated content.

Performance is a feature.

If every website adopted these guidelines, the web would be fast and readable, our batteries would have much power at the end of
the day, and we’d all be a lot happier.

May 06, 2018

While I was not the first technical hire at Stitch Fix, I was early enough to make a lot of technical decisions that have had
long-reaching effects on what is now a large engineering team of over 100 developers at a public, profitable company. Over that
time, the good decisions were almost always about being consistent, and the bad ones where the introduction of arbitrary
inconsistencies.

February 20, 2018

As I mentioned previously, non-SSL sites are heading toward being marked as security issues by browsers. If you want SSL and
full control over your website, including a top-notch CDN, AWS provides the tools you need, and it’s not too hairy to get going.
Considering what a nightmare anything SSL usually is, AWS makes it as painless as can be, as long as you are willing to get your
feet wet with some infrastructure, and do a bit of manual scripting.

February 18, 2018

Since Chrome is marking non-SSL sites as insecure soon, I finally got around to moving my site’s hosting from GitHub Pages to AWS. Setting up a static website using CloudFront and S3 is surprisingly easy. I’ll write up how to do it in a future post, but for now, enjoy the sweet security of SSL :)

February 02, 2018

Python famously holds as a value “Explicit is better than implicit”. This is not
something Rubyists (or many functional programmers) value, instead favoring compactness or “elegance”. I believe senior
developers undervalue explicit code that uses fewer features than it could. Compact code that uses many language, library, and
framework features excludes people from understanding and contributing to it, and I believe this is a serious consideration when
writing code. What better judge of a codebase’s maintainability could there be than “fewest concepts needed to understand it”?

January 25, 2018

I’ve been traveling to San Francisco every two months (more or less) for the last five years as part of my job. The hardest part
used to be the traveling and staying in hotels (now it’s that I pack so much activity into such a small amount of time, I barely see any of my San Francisco friends any more). This is about how to make the travel and hotels suck less, and if you are currently
working remotely, or planning to, reducing travel anxiety and hassle should be something you actively address.

January 19, 2018

Engineers often deride anything that’s not writing code as being not “real” work. While this diminishes the contributions of
others, and is generally an unhealthy bravado, it is critical to understand the difference between activities that directly
solve a problem and those that organize said activities. The later, I call “meta-work” and engineers should be very conscious of
spending too much time on it.

January 11, 2018

I’ve added another “problem” to “What problem does it solve?” about serverless architectures, which I think are
the future of distributed systems (though that future isn’t here yet):

The less code you are responsible for running in production, the better. Running an actual server means it’s all on you. Using virtual servers delegates some to your hosting provider. Using a platform-as-a-service like Heroku delegates yet more. A serverless architecture reduces this to what might be the absolute minimum - you are responsible for your code, and everything else is handled by the provider.

There are three big challenges: deployment, vendor lock-in, and testing.

December 11, 2017

In this month’s issue of PragPub, I have an article about Rails, and how it’s still as relevant today as it was when
it came out:

What Rails taught us about agility in 2005 is still applicable today. Rails has also kept up with the times, baking in more conventions around common problems, but also adding more technology to help solve them.

At its core, Rails is still an MVC framework serving up server-rendered pages. This core supports features that developers need today, either to capitalize on new techniques in front-end development, or to allow applications to scale as needs change and become complex. Do you need to run code in a background job? Rails has ActiveJob. Do you need to push changes from the server to your users’ browsers via WebSockets? Rails has ActionCable. Do you need to have a fully-interactive front-end, using the latest CSS processors and JavaScript frameworks? Rails has Webpacker, which simplifies Webpack, which makes all that possible and easy.

And there is testing support for all of it, from unit tests to browser-based system tests, so you can confidently ship your entire app, fully tested, whenever you need to make a change.