Practices Icon


Development and business practices, methodologies, workflows, etc.
229 Stories
All Topics

Gus Luxton

How to SSH properly

There are many ways to SSH. Some have more security “risks” than others. Yet, we SSH everyday…but could you improve the security of your SSH infrastructure? Maybe. Let’s find out.

Most people can agree that using public key authentication for SSH is generally better than using passwords. Nobody ever types in a private key, so it can’t be keylogged or observed over your shoulder. SSH keys have their own issues, however, some of which we’ve covered in a previous post about SSH key management.

The next level up from SSH keys is SSH certificates. … With SSH certificates, you generate a certificate authority (CA) and then use this to issue and cryptographically sign certificates which can authenticate users to hosts, or hosts to users….

Shopify Engineering Icon Shopify Engineering

Refactoring legacy code with the Strangler Fig pattern

This is an excellent refactoring story using one of Shopify’s core classes.

As you can imagine, one of the most critical areas in Shopify’s Ruby on Rails codebase is the Shop model. Shop is a hefty class with well over 3000 lines of code, and its responsibilities are numerous. When Shopify was a smaller company with a smaller codebase, Shop’s purpose was clearer: it represented an online store hosted on our platform. Today, Shopify is far more complex, and the business intentions of the Shop model are murkier. It can be described as a God Object: a class that knows and does too much.

They use Martin Fowler’s Strangler Fig pattern to achieve the refactoring. You may recall we discussed this on our episode with Amal Hussein.


Tech debt developer survey results

Umer Mansoor’s Technical Debt is Soul-crushing made the rounds last month and he followed up by adding a survey.

117 software developers from all over the world took the survey. The majority were from the USA, followed by Canada, Australia, Germany, India, Russia , UK and other European countries.

Not a huge sample size, by any means, but the results are interesting and worth scrolling through. This pairs nicely with our episode on good tech debt.

Dave Cheney

The Zen of Go

Dave Cheney’s ten engineering values for writing simple, readable, and maintainable Go code. Some of these apply outside of Go, as well. For instance, Simplicity matters:

Simplicity is not a synonym for unsophisticated. Simple doesn’t mean crude, it means readable and maintainable. When it is possible to choose, defer to the simpler solution.

(Originally presented at GopherCon Israel 2020.)

The Changelog The Changelog #379

Good tech debt

Jon Thornton (Engineering Manager at Squarespace) joined the show to talk about tech debt by way of his post to the Squarespace engineering blog titled “3 Kinds of Good Tech Debt”. We talked through the concept of “good tech debt,” how to leverage it, how to manage it, who’s in charge of it, how it’s similar to ways we leverage financial debt, and how Squarespace uses tech debt to drive product development.

Marco Otte-Witte

How to over-engineer a static page

Marco Otte-Witte:

When we set out to rebuild our own website in 2019, we wanted to use that project as an opportunity to ignore all economic considerations (and reason you could say) and dive deep into what was technically possible. Doing so would allow us to build something that was super customized for our specific needs and highly optimized for performance. We ended up spending a lot of time and effort but are quite pleased with the result.

While we cannot recommend anyone following our example as your time is most likely better spent elsewhere, this post explains the approach we took. I will be covering topics like static pre-rendering and client-side rehydration, advanced bundling and caching strategies as well as service workers.

Highlights added by me because this is a fun read (and no doubt a fun experiment for them), but I also cannot recommend you follow their example. 😉

Smashing Magazine Icon Smashing Magazine

The mythical mythical man-month

Mailchimp CPO John Foreman drops some contra-conventional wisdom in this Smashing Magazine piece:

When I as CPO say, “we’re going to do this thing!” the reply then is often, “OK, so then what are we going to kill?” The Mythical Man-Month turns product development into a zero-sum game. If we want one thing, we must stop another. Now, that’s an actual myth, and I call hogwash.


Minimalism — the most undervalued development skill

If you want a cheap trick to make a difference — here’s one: minimalism. Focus on the bare essentials and get rid of the rest. It’s an easy way to differentiate, because most others are doing the opposite: tons of crap.

This article is brimming with superb advice. The thing about minimalism is that it’s extremely easy to talk about doing, but difficult to put in practice. Those who master it can truly differentiate themselves.

Dan Abramov

Goodbye, clean code

Dan Abramov on the dangers of doing DRY wrong:

Obsessing with “clean code” and removing duplication is a phase many of us go through. When we don’t feel confident in our code, it is tempting to attach our sense of self-worth and professional pride to something that can be measured. A set of strict lint rules, a naming schema, a file structure, a lack of duplication.

First you have to learn the rule of writing software. Then you have to learn how and when to let go of the rules.

Go Time Go Time #112

defer GoTime()

Mat, Carmen, and Jon are joined by Dan Scales to talk about Mat’s favorite keyword in Go - defer. Where did the defer statement come from? What problems can it solve? How has it shaped how we write Go code? How are other languages solving similar problems? And what exactly was changed in Go 1.14 to improve the performance of defer?

Thoughtbot Icon Thoughtbot

5 tips for more helpful code reviews

Lots of good advice in this quick post on Thoughtbot’s blog. I especially like this:

It’s easy to list all the things you think need changing in the pull-request but gloss over all the good things present. If you see something good, say something good! It’s refreshing to receive positive feedback. I find that even simple things like these can go a long way:

  • “I love this method extraction”
  • “These tests look great! 🎉”
  • “Nice catch on this poorly named method! Thanks for changing it”


Best practices for designing a pragmatic restful API

Many of the API design opinions found on the web are academic discussions revolving around subjective interpretations of fuzzy standards as opposed to what makes sense in the real world. My goal with this post is to describe best practices for a pragmatic API designed for today’s web applications. I make no attempt to satisfy a standard if it doesn’t feel right. To help guide the decision making process, I’ve written down some requirements that the API must strive for…

Sooo much good advice in this article. Take this golden nugget, for example:

An API is a developer’s UI - just like any UI, it’s important to ensure the user’s experience is thought out carefully!

Yes! This reminds me of the conversation Mat Ryer and I had on Backstage a few weeks back about designing a Changelog API and how I might go about doing that.

0:00 / 0:00