Securing containers is a complex task. The problem space is broad, vendors are on fire, there are tons of checklists and best practices and it’s hard to prioritize solutions. So if you had to implement a container security strategy from where would you start?

Database (de)normalization is a tricky topic. Just because you can store some of your data in Postgres’ JSON data type, that doesn’t mean you should. But how do you decide? That’s what I asked Craig Kersteins on The Changelog a few weeks back. His answer was insightful, to say the least.

Ron Perris from Snyk this checklist of React security best practices to help you and your team find and fix security issues in your React applications. I’ll show you how to automatically test your React code for security-related errors and automatically fix them.

We’re joined by George Neville-Neil, aka Kode Vicious. Writing as Kode Vicious for ACMs Queue magazine, George Neville-Neil has spent the last 15+ years sharing incisive advice and fierce insights for everyone who codes, works with code, or works with coders. These columns have been among the most popular items published in ACMs Queue magazine and it was only a matter of time for a book to emerge from his work. His book, The Kollected Kode Vicious, is a compilation of the most popular items he’s published over the years, plus a few extras you can only find in the book. We cover all the details in this episode.

Henrik Nyh has a seriously simple system for removing code that ensures he doesn’t miss anything.

This is one of those things that seems obvious when you do it, but in my experience, many people do it haphazardly.

Daniel Stenberg:

Every now and then I get questions on how to work with git in a smooth way when developing, bug-fixing or extending curl – or how I do it. After all, I work on open source full time which means I have very frequent interactions with git (and GitHub). Simply put, I work with git all day long. Ordinary days, I issue git commands several hundred times.

I have a very simple approach and way of working with git in curl. This is how it works.

At a previous employer I had a boss who I thought was pretty tough. Not to me, but our users. No matter the request his response was always the same, “No.” Eventually, we implemented around 40% of the requests, but the constant rejection of these requests stuck with me. Now that I lead a team I notice myself using the same mindset. “No” isn’t negative, and it’s not dismissive. “No” is a way of protecting the team, the project, and the users.

Knowing the architecture of an application is like passively knowing a foreign language. When you speak it - it’s awkward. Here’s how you go from passively to actively owning a code-base.

I’ve been in the industry for a while and experienced a lot of the “no-code problems” that affect us, programmers. I’m talking about impostor syndrome, comparing yourself to others, that kind of stuff.

I decided to write (and promote!) this article as a way to share my experience with beginners and help them deal with that kind of stuff.

Marc Beinder is building a podcast hosting web application as a part of his senior project while at Lindenwood University. In this brief Backstage episode, Marc picks Jerod’s brain about how we built our platform and challenges we ran into along the way.

8 common security issues when using Docker and how to avoid them. Here’s a sampler:

Avoid curl bashing

Pulling stuff from internet and piping it into a shell is as bad as it could be. Unfortunately it’s a widespread solution to streamline installations of software.

The risk is the same framed for supply chain attacks and it boils down to trust. If you really have to curl bash, do it right…

To handle complex authorization policies, a system should handle both points of view efficiently and naturally, in this post we’ll show how we aimed to do that when building oso, an open-source policy engine for authorization.

A quick post by Drew DeVault on why he believes software must be robust, reliable, stable, and simple.

Jonas Lundberg:

In order to know that you are progressing you need some yardstick to measure against. The most common case is someone better and more experienced (having done the trip to mastery themselves) telling or showing you what you need to improve or if you are doing great. But what if there are no coaches or obvious roads to mastery?

From there Jonas goes on a deep-dive on why feedback loops are important and how you can acquire them for yourself. Oh, and if you need a feedback loop (and perhaps some cheer leading) on your writing, join the #blogging channel in our Community Slack. We have a small group forming.

A deep dive on how UDP and TCP affect log delivery and what that means for your application’s complexity in delivering logs. This is a follow-up post to the one we linked to awhile back on why their team ended up with a centralized logging solution. That piece was quite popular (and quite good), so you may enjoy this one as well.

How do you ship a product on schedule? One useful mental tool is the You Ain’t Gonna Need It heuristic: leave out all the things that seem nice-to-have, but you have no proof you actually need. And when there’s things you do need, consider the follow-up heuristic: You Don’t Need It Yet.

In which I pick on Jamstack a bit to make a larger point that we still haven’t found that Silver Bullet and we’re not going to so let’s put our thinking caps on, make sound choices, and pick the right tools for each situation.

Mat Ryer makes the case for passive user preferences, which is where you store their last used setting for them without asking and then set it as the default the next time they interact with that part of your app. He then goes on to describe how they accomplish this with Svelte. Good stuff!

If you want to hear more about how they’re using Svelte and Go to build Pace, we did a pair of podcasts on the topic earlier this year.

Daniel Moch shared his thoughts on semantic versioning and how he treats external libraries that violate its inherent contract with developers.

So as not to bury the lede, I’ll get to my point: Semantic Versioning is a meta-API, and maintainers who are cavalier about violating it can’t be trusted to created stable contracts. I’ve lost patience for breaking changes making their way to my code bases without the maintainers incrementing the major version of their projects, especially in language ecosystems where Semantic Versioning is expected, and in such cases I’m going to begin exploring alternative options so I can ban such libraries from my projects—personal and professional—altogether.
…
If you work in a language ecosystem where Semantic Versioning is the de facto norm, where violating it can wreak havoc downstream, then please play nice and follow its dictates. Instead of viewing it as a straight jacket, try to see it as an algorithm to determine what your next release number should be. We should all like algorithms!

There is the classic saying that “Practice makes Perfect”. This is partly true because it’s also that “Practice also makes you Permanent”.

Now usually comes the part saying that we need to do Deliberate Practice consistently for many years. The thing is that there is a multitude of ways to practice deliberately. There is no one size fits all formula applicable to all domains. And of course - people are different.

I’d like this article to focus on a single deliberate practice side - I call it the “Train Your Own Neural Technique” technique.

Ahmad Nassri returns to the party for a deep, nuanced discussion around the thoughts he shared in a recent blog post called Solving Solved Problems. We hear about the common issue Ahmad’s seen at software shops of all sizes, learn the anatomy of the total cost of software ownership, and debate what to build and what to buy.

Andrzej Krzywda:

My goal is to help you improve the design of the if/else based codebases. Yes, that probably means creating new method, extracting new object. It might be a bit OOP. If that’s not your taste and you’re fine with if/else then this may not be for you.

He then goes on to refactor a deeply nested Ruby method by extracting some classes that are responsible for their own behavior. This is perhaps a bit rudimentary to long-time OOP folks, but I see a lot of code out there looking like Andrzej’s example method so there’s plenty of people who would benefit from understanding this concept.

Node.js development began a bit like the Wild West, but over time idioms, anti-patterns, and best practices have emerged. Yoni Goldberg’s Node Best Practices repo on GitHub collects, documents, and explains the best practices for Node developers. On this episode, Yoni joins us to discuss.

Jonas Lundberg:

Hands on tips for learning a new codebase within a short time frame enough to be able to say: “Steve’s legacy ends here. I’ll figure it out.”

This is a great piece filled with actionable details and particulars.

1️⃣ Value contributions to documentation just as much as code contributions
2️⃣ Put documentation and code in the same project repo
3️⃣ Make documentation a requirement for a merge or release milestone
4️⃣ Have a consistent contribution process for code and documentation
5️⃣ Have well-documented processes for contributing to documentation

That’s the TL;DR, but each of these is expanded upon in the article.