Practices Icon

Practices

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

Dan Abramov overreacted.io

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.

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”

Practices vinaysahni.com

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.

Practices chrisbowler.com

Finding the right name

If you listened to our GitHub Sponsors episode, you know how much I love sweating the details on a name. I’m not the only one. In this insightful post, Chris Bowler shares some of his struggles with the matter:

When working on a new idea, the hardest part for me is figuring out a name and how to talk about the idea overall. Even when the idea is solid and there is interest or demand for it, even when I can articulate the problem it will solve, I often struggle to find a name.

He then gives five exercises he goes through when picking a name, which I heartily endorse (even though I don’t practice all five).

Manuel Vila freeCodeCamp

How to simplify full-stack development with a unified architecture

Manuel Vila, writing for freeCodeCamp:

In this article, I introduce the concept of “unified architecture” that dramatically simplifies the development of full-stack applications.

Indeed, this architecture unifies the six physical layers (data access, backend model, API server, API client, frontend model, and user interface) usually seen in “well-designed” applications into one single logical layer.

It is like going from a 3D world to a 2D world. Everything gets a lot easier.

That “unified architecture” manifests itself as Liaison, which we linked to last week and it caused some… controversy discussion. In this article, Manuel explains why Liaison is different than similar RPC things that came before it. Interesting stuff, to say the least.

CSS-Tricks Icon CSS-Tricks

The rising complexity of JAMStack sites and how to manage them

When you add anything with user-generated content or dynamic data to a static site, the complexity of the build process can become comparable to launching a monolithic CMS. How can we add rich content to static sites without stitching together multiple third-party services?

Every time I get into the nitty gritty of JAMStack implementations with anything but static content sites I end up saying (or merely thinking to myself), “This sounds like a whole lot of work to avoid some server-side rendering…”

This piece on CSS Tricks appears to back up that premonition:

Despite my enthusiasm, I’m often disheartened by the steep complexity curve I typically encounter about halfway through a JAMstack project. Normally the first few weeks are incredibly liberating. It’s easy to get started, there is good visible progress, everything feels lean and fast. Over time, as more features are added, the build steps become more complex, multiple APIs are added, and suddenly everything feels slow. In other words, the development experience begins to suffer.

The good news is there are many smart, talented folks working on solving the various challenges that JAMStack sites face.

Liz Fong-Jones Increment

Code less, engineer more

The new issue of Increment is out and it’s all about team dynamics. This piece by Liz Fong-Jones is 🔥

Effective teams write less software, and writing less software enables teams to be more effective. This may sound counterintuitive at first: Aren’t we all here as engineers to write software? Isn’t our productivity measured in lines of code? To dispel this illusion, we need to stop conflating what we sometimes do with why.

Kubernetes learnk8s.io

Kubernetes production best practices checklist

How do you know if your Kubernetes cluster is production-ready?

If you’re a beginner, it’s hard to tell what you’re missing. The subject is soo vast and it’s easy to lose sight on what’s the right path to production.

And even if you’re an expert, remembering all networking, storage, cluster, and application development best practices is impossible. There are so many.

Here is a curated a list of best practices for Kubernetes that helps you drive your roadmap to production.

Check things off the list and keep track as you go. ✅

Node.js github.com

The largest Node.js best practices list

With 35k+ stars, I might be the last one to the party on this awesome repo.

It is the largest compilation, and it is growing every week - currently, more than 80 best practices, style guides, and architectural tips are presented. New issues and pull requests are created every day to keep this live book updated. We’d love to see you contributing here, whether that is fixing code mistakes, helping with translations, or suggesting brilliant new ideas.

Browser London Icon Browser London

The power of the MoSCoW method

I’ve never heard of this method before, but it’s definitely interesting enough to link up for you:

At its core, the MoSCoW method is simply a prioritization framework that can be applied to any kind of situation or project, but it works best when a large number of tasks need to be ruthlessly whittled down into a prioritised and achievable to-do list.

The general idea is you take a list of tasks/stories/whatevs and place each into one of for buckets: Must, Should, Could, and Won’t. (Somehow this gets shortened to MoSCoW for the namesake.)

If you listened to our recent episode on Agile, you know I’m not a fan of ceremony when it comes to planning practices, but I do think there is some value here if you do it right. Click through for the skinny on how to run a MoSCoW exercise as well as some pitfalls to avoid.

Thoughtbot Icon Thoughtbot

Let's not misuse 'refactoring'

German Velasco:

I find that many people confuse refactoring with any change in code. Sometimes they even use the word to mean huge changes that break the application — “we need a month to refactor this monolith.” I think that in those cases, we are misusing the word refactoring, robbing it of its proper meaning, and ultimately, robbing ourselves of the power to communicate an important concept.

Let’s revisit what refactoring is and what it is not.

Some folks might consider this post semantic pedantry, but I think there’s value in knowing the difference between refactoring and merely changing stuff. Don’t get me wrong, I misuse the term on the regular, but when I’m being more diligent with my word choice I will reach for rejiggering instead.

JSON engineering.instawork.com

When XML beats JSON

When demoing Hyperview to new engineers, there’s one comment that frequently comes up about the HXML data format:

“XML, really? It’s bloated and outdated. Why not use JSON? It’s the future.”

These comments imply that JSON is the “one true file format” that should be used for everything, but we don’t believe there’s such a thing. Each format makes tradeoffs in encoding, flexibility, and expressiveness to best suit a specific use case.

The author makes a pretty solid argument that JSON is better for lists, while XML is better for trees.

Twitter Icon Twitter

I bet you could've guessed Equifax's username and password...

Jane Lytvynenko went digging through the Equifax class-action suit and uncovered some absolute gems:

Furthermore, Equifax employed the username “admin” and the password “admin” to protect a portal used to manage credit disputes, a password that “is a surefire way to get hacked.” This portal contained a vast trove of personal information.

Hanlon’s razor often applies in security breaches like these, but I can’t see this as anything but pure negligence by Equifax’s technical teams. There’s more:

Equifax also failed to encrypt sensitive data in its custody… admitted that sensitive personal information relating to hundreds of millions of Americans was not encrypted… Not only was this information unencrypted, but it was also accessible through a public-facing, widely used website.

Filed under you-gotta-be-freakin-kiddin-me

Jon Thornton engineering.squarespace.com

3 kinds of good tech debt

Jon Thornton writes on the Squarespace Engineering blog:

“Tech debt” is a dirty word in the software engineering world. It’s often said with an air of regret; a past mistake that will eventually need to be atoned for with refactoring.

Financial debt isn’t universally reviled in the same way. Your friend takes out a mortgage to buy a house and what do you say? Congratulations! …

The difference is intention. What if tech debt wasn’t always an accident, caused by incorrect assumptions and unexpected circumstances? How would you spend a tech debt mortgage?

We also talked about tech debt in a similar manner on Founders Talk #60.

Jon Calhoun calhoun.io

Why can't we settle on a single application structure in Go?

Go Time panelist Jon Calhoun ruminates on a conversation started on episode 94 of the show:

The goal of this article is it explore why exactly there isn’t a single app structure that is recommended to new Gophers, and the overall goal of this series is help newcomers to Go understand what choices are available to them so they can get started a little easier.

Nikita Sobolev sobolevn.me

The complexity waterfall

When talking about “bad code” people almost certainly mean “complex code” among other popular problems. The thing about complexity is that it comes out of nowhere. One day you start your fairly simple project, the other day you find it in ruins. And no one knows how and when did it happen.

This is a deep-dive into where complexity comes from and finishes with some great advice on fighting it off.

Yegor Bugayenko yegor256.com

Daily stand-up injection of guilt

Yegor Bugayenko:

Only weak managers need daily stand-up meetings to coordinate the team, while strong ones use more formal instruments to organize the flow of information. However, as someone noted, morning meetings are not supposed to be used by managers to coordinate anyone, but “to discuss progress, impediments and to plan.” I’m not buying it.

We had a lively discussion on this very topic on yesterday’s recording of The Changelog. Stay tuned for that episode coming next week. 📻

Polina Gurtovaya Evil Martians

Images done right: Web graphics, good to the last byte

Polina Gurtovaya:

Start taking graphics on the web seriously and boost your applications’ performance by learning the essentials about image formats, both modern and old-school. Dig into SVGs and adopt the latest and greatest tools to optimize your graphical content: both vector and raster. Study the theory behind digital images and how humans perceive them—to improve the experience for your users.

Kubernetes learnk8s.io

How do you rollback deployments in Kubernetes?

You should have a plan to roll back releases that aren’t fit for production. In Kubernetes, rolling updates are the default strategy to release software.

In a nutshell, you deploy a newer version of your app and Kubernetes makes sure that the rollout happens without disrupting the live traffic. However, even if you use techniques such as Rolling updates, there’s still risk that your application doesn’t work the way you expect it at the end of the deployment.

Kubernetes has a built-in mechanism for rollbacks. Learn how it works in this article.

Keavy McMin keavy.com

Thriving on the technical leadership path

Keavy McMinn:

The management path isn’t the only way to be a technical leader. I don’t wish to become a manager; I tried it briefly (73 days to be exact, I counted) and decided managing other people wasn’t where my passion lies. I like being an engineer. In particular, I flourish in a strategic technical leadership role.

This used to be hard to accomplish. It still is, but it used to be, too. 😏

Hopefully we see more engineers like Keavy thriving without having to make the switch to management. Writing about it, talking about it, and showing success stories is a good start towards that end.

Philip Walton philipwalton.com

Cascading cache invalidation

Turns out one of our asset caching best practices (content hashes in filenames + far-future expiry) has a serious flaws in it:

In practice, changes to one of your source files almost always invalidates more than one of your output files—and this happens because you’ve added revision hashes to your filenames.

Philip goes on to explain why this happens and then proposes 3 possible solutions. Good stuff 👌

0:00 / 0:00