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/elsebased 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 withif/elsethen 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.
Leszek Zalewski:
The impact of COVID-19 is multifaceted. Our infrastructure team observed an exhaustion of our server resource pool for auto scaling due to a drastic traffic increase! Learn how we achieved 2× faster application run with only 1/3 of the servers by tuning auto scaling rules and switching to Puma threads.
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.
You can use this set of guidelines, fork them or make your own - the key here is that you pick a style and stick to it.
This is a great guide, but the 🔑 is definitely in the highlight above. Consistency is tantamount to readability.
Eduards Sizovs:
People rarely talk about it, but in many companies, code review makes developers feel like sh%t. This is a practical guide on how to create a code review process that developers love.
Click through for 8 recommendations from Eduards on making code review an effective, encouraging, and positive activity.
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.
This is a 5-part series about the zero-trust networking paradigm:
The process and thinking described in this series are the direct output of developing the same system for the Ziti open source project.
Dave Kerr joins Jerod to discuss the various laws, theories, principles, and patterns that we developers find useful in our work and life. We unpack Hanlon’s Razor, Gall’s Law, Murphy’s Law, Kernighan’s Law, and too many others to list here.
So you are building a client-side web app for that next big project and wondering: “Which router should I use?”. Here is the thing: you don’t need any, and you will understand why shortly.
Intriguing!
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.
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.
An analysis by Marco Otte-Witte of the typical problems that arise when scoping and planning software projects as well as some techniques to address and overcome them, reducing uncertainty, risk and frustration.
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.
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.
Patrick DeVivo:
Caring less about code doesn’t mean caring less about its outcome. In fact, putting the outcome before the implementation can really unlock you to think about the problems that “matter.” The value your software delivers, not the software itself.
We take a listener request this week and discuss how we evolve alongside (or opt out of) the ever changing JavaScript syntax. Arrow functions and variable declarations take center stage, but a wide range of new(ish) JS syntax and features are discussed.
Then Feross shares his new app, Nick talks fiction books, and Jerod switches coding fonts.
This article compares six static tools to validate and score Kubernetes YAML files for best practices and compliance.
One of the challenges with YAML is that it’s rather hard to express constraints or relationships between manifest files.
What if you wish to check that all images deployed into the cluster are pulled from a trusted registry?
How can you prevent Deployments that don’t have PodDisruptionBudgets from being submitted to the cluster?
Alexander Sulim:
A short story that suggests to challenge your initial ideas. Because sometimes it’s possible to achieve more by actually doing less :)
