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 :)

Mat, Jon, and Jaana discuss reflection and meta programming. How do other languages use reflection, and how does that differ from Go’s approach? What libraries are using reflection well? What are some examples of bad times to use reflect? What alternative approaches exist? And what are those weird struct tags I keep seeing in Go code?

From the anonymous writers at Stay SaaSy…

Picking your tech stack in an early stage startup is one of the most important decisions you’ll make. Read on to hear about rules of thumb for making these critical decisions.

Rule 1: When It’s Really Early, Just Use What You Know

If you’re still in prototype, less than 4 developers, do-or-die mode, just use what you know. Unless your product has deep technical requirements the only thing you should optimize for is how fast you personally can code. Don’t try something new. Don’t experiment. Write code.

From Kabir Nazir on the AltCampus blog:

One of the things a lot of newbie developers overlook often is the format of their commit messages. Properly formatted commit messages can do so much more than just looking neat…

Use the imperative mood(present tense) when framing messages … Think of each commit in your code as a change that is being applied to your codebase.

Andy Bell recently shared his new CSS methodology oriented towards simplicity and consistency with “a heavy dosage of pragmatism.”

If there’s one thing you can guarantee in tech, it’s that someone, somewhere, will declare that CSS isn’t up to the job of “big projects” and what will undoubtedly be recommended by those same people will be either a JavaScript-heavy approach or some sort of all-in utility class approach like Tailwind.

The problem is, a huge number of projects are websites, so that advice normally doesn’t work for the vast majority of developers. For context, it’s estimated that WordPress powers around 36% of the internet and is still rising. Compare that to a paltry 0.3% of websites that use React, for example. It’s important to keep those figures in mind.

If you’re deep in CSS, you’ll want to read the whole post. Andy goes on to explain the methodology and how he writes CSS, then wraps up saying…

This isn’t a heavily documented, complex methodology. Well, not now, anyway. It’s more of a concept method of organizing CSS just enough to not pull to far away from the “classic” way of writing it. Really, it’s more of a thinking structure.

This was a great question asked this week on Hacker News – 232 comments and counting…

We just had an interesting data loss at work, that was due to data being encrypted at rest. We somehow managed to delete the encryption keys (still figuring out how), which became an obvious problem once our main database instance was rebooted.

Luckily we were able to restore the data, but now I (we) really want to learn what a proper setup would look like.

Max Mulatz:

This is a call for solidarity and a love letter to good commit messages. Read this to find out why it’s worth to care about commit messages and how to get better at writing them.

Distributed systems are hard. Building a distributed messaging system for these systems to communicate is even harder. In this episode, we unpack some of the challenges of building distributed messaging systems (like NATS), including how Go makes that easy and/or hard as applicable.

This post is part of a sample chapter from Essential Tools and Practices for the Aspiring Software Developer — a self-published in-progress book by Balthazar Rouberol and Etienne Brodu.

I estimate that I spend around 50% of my day working in my text editor and my terminal. Any way I can get more productive in these environments has a direct and measurable impact on my daily productivity as a whole.

If you spend a good chunk of your day repeatedly hitting the left and right arrow keys to navigate in long commands or correct typos, or hitting the up or down arrow keys to navigate your command history, this chapter should help you get more done quicker. We will cover some shell features you can leverage to make your shell do more of the work for you.

On a personal level, I probably use some of these up to 30 times a day, sometimes even without thinking about it, and it gives me a real sense of ownership of my tool.

Everyone knows that all code has bugs. Code is written under constraints. Deadlines. Goals other than quality. Imperfect knowledge of the future. Even your own skill as an engineer is a constraint. If we all tried to write perfect, bugless code, we’d never accomplish anything. So how does it make sense to apologize for bugs?

It’s certainly interesting to ponder how to store data for as long as you possibly can, which Drew highlights very well. But I really enjoyed the questions at the end on “actually storing data forever”…

Let’s say you’ve managed to keep your data around. But will you still know how to interpret that data in the future? Is it in a file format which requires specialized software to use? Will that software still be relevant in the future? Is that software open-source, so you can update it yourself? Will it still compile and run correctly on newer operating systems and hardware? Will the storage medium still be compatible with new computers?

Nicholas C. Zakas asks himself these five questions (in order) to make the best decisions possible:

1. Is this really a problem?
2. Does the problem need to be solved?
3. Does the problem need to be solved now?
4. Does the problem need to be solved by me?
5. Is there a simpler problem I can solve instead?

Read on to find out why these questions have become the basis for his problem solving approach.

What is a microservice, and what is a monolith? What differentiates them? When is a good time for your team to start considering the transition from monolith to microservice? And does using microservices mean you can’t use a monorepo?

Lj Miranda explains their architecture decisions with a metaphor I’ve never seen applied to software systems…

In this blogpost, I’ll explain why we need Flask, Celery, and Redis by sharing my adventures in buying McNuggets from Mcdonalds. Using these three (or technologies similar to them) is integral to web backend development so that we can scale our applications.

I love these “why we did X” style posts where folks share their real-world decision making processes and how they played out over time.

Jonathan Chang and Michael Deng share all the details of the systems required to deploy at Slack.

Deploys require a careful balance of speed and reliability. At Slack, we value quick iteration, fast feedback loops, and responsiveness to customer feedback. We also have hundreds of engineers who are trying to be as productive as possible. Keeping to these values while growing as a company means continual refinement of our deployment system.

Almost every week I accidentally get into this logging argument. Here’s the problem: people tend to log different things and call it a best-practice. And I am not sure why. When I start discussing this with other people I always end up repeating the exact same ideas over and over again.

So. Today I want to criticize the whole logging culture and provide a bunch of alternatives.

In short, I use git branches very rarely, preferring to work on my local master branch almost every time. When I want to work on multiple tasks in the same repository (i.e. often), I just… work on all of them on master. I waste no time creating a new branch, or switching to another branch to change contexts; I just start writing code and committing changes, all directly on master, intermixing different workstreams freely. This reduces my startup time to zero, both for starting new tasks and revisiting old work.

If the blog post ended here, you might think Drew is crazy. But he goes on to explain how he uses rebase to clean things up before pushing upstream.

I enjoy hanging out on master quite a bit, myself. However, when I’m ready to take on something “big” or “gnarly” I don’t hesitate to git checkout -b and work from there.

Jerod and KBall are joined by Micro Frontends in Action author Michael Geers to discuss (you guessed it) micro frontend architecture. We ask: what is the concept? How is it similar/different to micro services? Who is it best fitted for? How do you put it in practice? And much more.