Practices Icon

Practices

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

The Changelog The Changelog #420

The Kollected Kode Vicious

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.

Daniel Stenberg daniel.haxx.se

This is how I git

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.

Dylan Paulus dylanpaulus.com

Start with "No"

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.

Vitor Paladini DEV.to

How I manage impostor syndrome, fear of failure, and other common programmer problems

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.

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.

0:00 / 0:00