You can utilize any mailing library in your backend to simply send emails or choose API email providers like Resend or Mailgun.

For spam protection, various providers are available, such as Cloudflare and Google.

> why make it so complex in the first place?

You're completely justified in questioning this, and I resonate with you and all the developers who feel the same way.

This is only an issue if the spec is maintained manually. In my opinion, best practice is to generate the specification from the actual implementation—assuming you didn’t start by hand-crafting the spec in the first place.

If the spec is the source of truth, server and client stubs can be generated from it, which should likewise prevent this kind of drift.

I realize that working with OpenAPI isn’t always straightforward, but most of the friction usually comes down to gaps in understanding or insufficient tooling for a given tech stack.

I loved to use their free desktop app for building API documentations which can be used for scaffolding / generating APIs but for some reason I don't remember right now I had to stop using it.

Probably makes sense to add "relies on AWS" to the criteria we're using to evaluate 3rd-party services.

As a web developer, I love how effortless it is to spin up a static site for free using their Pages or Workers features. Sure, I could rent a small server or even host projects on a home setup, but often I just want something simple, fast, and hassle-free - and Cloudflare delivers that at zero cost.

Has this convenience led me to spend money with them? Absolutely. These days I even rely on Cloudflare for DNS management, simply because their interface and overall experience are far better than what I was using before I found them.

That said, I’m not here to defend the company uncritically. I recognize the valid concerns and criticisms that exist. But no platform is without flaws, and in some situations I simply can’t — or don’t want to — prioritize the idealistic view. Sometimes I just want to experiment and build, and Cloudflare makes that easy.

MDX is great and I like to use it.

As others mentioned, if you use this to attract clients or recruiters, I recommend adding a version for non-technical folks.

As a nerd I'd love to see some more colors like in the themes you can set using Prezto or Oh-My-ZSH (reference: https://github.com/sorin-ionescu/prezto?tab=readme-ov-file#t...).

For the projects I think some click function to open an ncurses-like modal would be cool :)

Another idea: what about adding a light mode?

P.S.: I would also add `rm -rf` and return something like "nice try ^_^"

- Degree, a general one is good, a specific one related to the job is better (especially in the German-speaking area, I don't know about the others)

- Experience, especially in well-known big companies

They used a trick there to reduce the leverage of employees in IT and created the myth of a "shortage of skilled workers" by repeatedly publishing this in various media, creating fake statistics and ghost job ads. A lot of foreigners jumped in and also the existing workforce, afraid of losing their jobs or not finding a new one, didn't bother to negotiate well anymore and are doing jobs for really bad money (e.g. 50k/year).

Now you add the "AI will replace you anyway" mantra, which initially increases this fear and the willingness of employees to work for low wages.

The effect is a workforce that is well educated and willing to work for food and shelter, no questions asked.

If you're trying to compete, a degree helps, but in the end you may be undercut by someone with the same degree (with better grades) but who takes less money because they don't know their worth.

My opinion: try to get out of Europe, run your own business or find a different career / business opportunity. These are bad times for CS employees in Europe.

However, I do not see a big advantage over Cypress tests.

The article mentions shortcomings of Cypress (and Playwright):

> They start a dev server with bootstrapping code to load the component and/or setup code you want, which limits their ability to handle complex enterprise applications that might have OAuth or a complex build pipeline.

The simple solution is to containerise the whole application (including whatever OAuth provider is used), which then allows you to simply launch the whole thing and then run the tests. Most apps (especially in enterprise) should already be containerised anyway, so most of the times we can just go ahead and run any tests against them.

How is SafeTest better than that when my goal is to test my application in a real world scenario?

> In a world pushing for “reflexive AI usage,” I’m advocating for something different: thoughtful, intentional collaboration with AI that preserves the essence of coding as a craft. > ... > Like Rocky, we sometimes need to step away from the comfortable, civilized environment and return to the old gym – the place where real growth happens through struggle, persistence, and focused practice.

> Because coding isn’t just about output. It’s about the journey of becoming better problem solvers, better thinkers, and better engineers. And some journeys can’t be outsourced, even to the most advanced AI.

But here’s the reality: those ideals feel increasingly out of reach. Business demands and short-term thinking rarely leave room for “intentional” or “thoughtful” work. For many of us, having time to grow as engineers is a luxury.

Worse, it’s often personal. I’ve had to carry the weight for friends in crisis, pretending two people were working just to help someone keep their job. It’s brutal—and sadly, not rare.

As AI gets more buzz, many stakeholders now think our work is overvalued. A quick AI PoC becomes “good enough” in their eyes, and we’re expected to polish it into something real—fast, cheap, and under pressure. Meanwhile, we’re constantly defending our craft against the next threat of being replaced by “cheaper” labor.

When I started out, we cared about clean code and craftsmanship. Now, I feel like I should be taking sales courses just to survive.

Today, it’s all about output. Ship faster or get replaced. Quality only matters when it’s too late—after the person who made the bad call has already cashed out.

I know this sounds pessimistic, but for many of us who aren’t in the top 1% of this industry, it’s just reality.

Thanks for the article, Christian. You’re not wrong—but I think you’re one of the few lucky enough to live that perspective. I wish you all the best, and hope you can keep enjoying that rare luxury. There will be a need for true craftsmen—especially when the rest of us have gone numb just trying to keep up.

The author doesn’t just miss old tech—he explicitly claims “computers were more fun when they weren’t for everyone,” then spends the rest of the piece romanticizing that exclusivity. He presents complexity as a virtue because it filtered people out. That’s not just wistful reflection—it’s gatekeeping framed as culture.

His core argument is clear: computing was better when it belonged only to those with the time, skill, or personality to endure its difficulties. That’s not celebrating subculture—it’s lamenting the loss of exclusivity.

Calling his stance “elitist” doesn’t excuse it—it just acknowledges it without engaging with what that actually means. Self-awareness isn’t the same as critical reflection, and it doesn’t soften the underlying message: resentment toward accessibility, masked as retro affection.

The piece ultimately reads less like love for a bygone era and more like discomfort with the fact that computing has become inclusive.

> Old hardware was simpler. This meant that a single person could learn all, or at least most, of its features by heart.

Sure - and so is plenty of tech today, if you choose it to be. Simplicity is still available, just not mandatory. No one’s forcing you to turn your home into a smart dystopia or drive a car that needs firmware updates.

> Old hardware was limited. Slow processors, low resolutions and cheap sound chips impose restrictions that are fun to overcome with creative problem solving.

That kind of constraint is still available - self-imposed, if necessary. Creativity through limitation isn’t gone; it’s just no longer universal. If you miss it, simulate it. Limitations don’t require scarcity.

> Old computers were offline. No attention economy, no SaaS subscription models. You could learn a piece of software and keep using it for as long as a decade without experiencing any major overhauls.

Great! You can still do that. Turn off Wi-Fi, fire up your legacy tools, and ignore the SaaS world. Nobody is stopping you.

> The Internet was mostly text-based. Things were comparably snappy and focused on human-to-human communication rather than passive content consumption and bloated advertising.

You can still browse text-only sites with a terminal browser. You can still avoid algorithmic sludge and have meaningful conversations-forums, IRC clones, newsletters, you name it.

> Old gits like yours truly where younger back then. We were, believe it or not, at the forefront of technology, instead of struggling to keep up.

Exactly. Some of what you’re feeling is just aging-nostalgia reframed as cultural decay. It’s human, but it’s not a critique of the present.

> It also meant that if someone had a home computer, chances were that they liked the same stuff as you

Communities still exist for people who care deeply - Linux user groups, retro computing forums, hacker conferences. You just have to look past the mainstream.

> Left thusly alone, we were free to do whatever the heck we wanted with our mysterious machines.

You still are. Boot up your Amiga, fire up a dev board, disconnect from the cloud. The tools are still there. What’s missing is the exclusivity.

My final thoughts about the article:

This isn’t just longing for a bygone era—it’s discomfort with the present one, especially its inclusivity. That’s what makes the piece not just nostalgic, but ideologically revealing. I honestly feel a bit sorry for the author, who (at least to me) comes across as a disgruntled old guy, romanticizing a time when being seen as a weirdo also meant being seen as a wizard.

My final thought about your comment:

You say this is a victimhood take, but the real victimhood is in the article - mourning the loss of exclusivity like something was stolen, when really, it was just shared.

Yes, it is controversial for people who do not immediately see what is wrong with it.

This is a very efficient way of letting the reader know that the person has problems, without saying so directly. Sure, it is honest, but it reflects very badly on the character, and that is why it is "controversial" (not really, if you have a balanced personality you immediately know that it is just an ego problem).

Sorry but I had to stop reading there.

Can someone enlighten me as to what advantage a font solution would have for displaying bar charts?

I was amazed to find that a) nobody maintained the project after I left, there were only two minor fixes because their house was on fire, and b) I really took the time to write almost complete documentation on all the important topics, which helped me get back on track faster.

You are absolutely right, and I have experienced this most of the time. The problem is that it is an uphill battle to explain to most stakeholders why you are "wasting" so much time on non-customer facing documentation.

It is hard enough to convince even technical stakeholders (e.g. product owners) to write automated tests.

While at the time I mostly think it's bad, later on it forces them to pay me twice as much, so I guess it's not as bad as I always think in those moments :D

I wonder why they all start their own projects instead of putting their heads together. They could achieve so much more and make a bit more money on the side, while each of them would have to spend less time on it. It would also attract risk-averse companies.

I do wonder though, why do we even need an alternative to Dokku when it seems to provide everything we need?