Practices Icon

Practices

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

Docker cloudberry.engineering

Dockerfile security best practices

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…

Jonas Lundberg iamjonas.me

Have a feedback loop

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.

Iurii dev.sweatco.in

Why your application should not be responsible for delivering logs

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.

Mat Ryer pace.dev

Passive user preferences with persisted stores in Svelte

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 danielmoch.com

Regarding semantic versioning

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!

Yaron Wittenstein gryphon.dev

Train your own neural network

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.

Andrzej Krzywda blog.arkency.com

An anti-if "framework"

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.

Opensource.com Icon Opensource.com

5 tips for making documentation a priority in open source projects

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.

John D. Cook johndcook.com

The worst tool for the job

John D. Cook:

I don’t recall where I read this, but someone recommended that if you need a tool, buy the cheapest one you can find. If it’s inadequate, or breaks, or you use it a lot, then buy the best one you can afford.

If you follow this strategy, you’ll sometimes waste a little money by buying a cheap tool before buying a good one. But you won’t waste money buying expensive tools that you rarely use. And you won’t waste money by buying a sequence of incrementally better tools until you finally buy a good one.

What follows is an application of that idea to software tools.

Practices reasonablypolymorphic.com

How to write technical posts (so people will read them)

Writing is hard. Technical writing can be even harder. This piece by Sandy Maguire has lots of help in it:

Here’s the biggest thing to keep in mind: your reader doesn’t really care what you have to say. You get maybe four sentences to convince them that your essay is worth their time. If you haven’t made your case by then, you’ve probably lost them to the next tab they binge-opened.

Iurii dev.sweatco.in

Why we ended up with a centralized logging solution

In the process of moving to our ideal logging system, we constantly discussed the pros and cons of different solutions, and each of us defended the requirement close to them or changed the configuration parameters they needed, asked intriguing questions or sent us back to the original set of requirements.

I love write-ups like this one from the trenches where people share their journey to deciding on a particular solution. Every decision has a context and many blog posts gloss over that, resulting in silver bullet-y hand waving. That’s not super useful when trying to make your own decisions. What is super-useful is being able to understand the circumstances in which others made a choice. That way you can decide if your situation is close enough to theirs to make a similar decision… or not.

Opensource.com Icon Opensource.com

Use systemd timers instead of cronjobs

Is it time to migrate away from cron?

Like cron jobs, systemd timers can trigger events—shell scripts and programs—at specified time intervals, such as once a day, on a specific day of the month (perhaps only if it is a Monday), or every 15 minutes during business hours from 8am to 6pm. Timers can also do some things that cron jobs cannot. For example, a timer can trigger a script or program to run a specific amount of time after an event such as boot, startup, completion of a previous task, or even the previous completion of the service unit called by the timer.

Practices johndcook.com

LEGO blocks and organ transplants

This post is so brief that I’ll just quote it in its entirety for you:

People have been comparing software components to LEGO blocks for a couple decades. We should be able to assemble applications by snapping together modular components, just like LEGOs. There has been progress, but for the most part we haven’t realized the promise LEGO-style software development.

Integrating two software systems is usually more like performing a heart transplant than snapping together LEGO blocks. It can be done—if there’s a close enough match and the people doing it have enough skill—but the pieces don’t fit together trivially. And failure may not be immediately obvious; it may take a while to see signs of rejection.

Just as true today as it was when John wrote it in 2011.

 Itamar Turner-Trauring codewithoutrules.com

Your dev environment matters less than you think

I knew I was going to nod my head in approval before I even landed on Itamar’s website:

Imagine you’re training to become a chef. You will need to learn how to use a knife correctly, to chop and dice safely and quickly.

And yes, you need a sharp knife. But when you’re starting out, it doesn’t matter which knife you use: just pick something sharp and good enough, and move on. After all, the knife is just a tool.

The people eating the food you cook don’t care about which knife you used: they care how the food tastes and looks.

After six months in the kitchen, you’ll start understanding how you personally use a knife, what cuisines you want to pursue, what techniques you want to vary. And then you’ll have the knowledge to pick a specific knife or knives exactly suited to your needs.

But remember: the people eating your food still won’t care which knife you used.

I’ll just leave this right here.

0:00 / 0:00