From the linked article, it was a press release, not just to his employees.
> The incident began Monday when ATI, which supplies graphics cards for all Apple's current models, issued a four-paragraph news release that stated its Radeon processor would be featured in three new Mac models -- none of which were announced by Apple (Nasdaq: AAPL) until CEO Steve Jobs' Wednesday morning keynote address.
Let my geriatric self rephrase this for you and make the point more obvious: "[...] who just discovered [insert latest design pattern trend of your choice] and insists on trying it everywhere"
> Is that an easy mistake to make and a hard one to recover from, in your experience?
If you're alone in a codebase? Probably not.
In a company with many contributors of varying degrees of competence (from your new grad to your incompetent senior staff), yes.
In large repositories, without extremely diligent reviewers, it's impossible to prevent developers from creating the most convoluted anti-patterny spaghetti code, that will get copy/pasted ad nauseam across your codebase.
Terraform as a tool and HCL as a programming language leave a lot to be desire (in hindsight only, because, let's be honest, it's been a boon for automation), but their constrained nature makes it easier to reign in the zealous junior developer who just discovered OOP and insists on trying it everywhere...
Not an opinion on Pulumi specifically, but an opinion on using imperative programming languages for infrastructure configuration: don't do it. (This includes using things like CDKTF)
Infrastructure needs to be consistent, intuitive and reproducible. Imperative languages are too unconstrained. Particularly, they allow you to write code whose output is unpredictable (for example, it'd be easy to write code that creates a resources based on the current time of day...).
With infrastructure, you want predictability and reproducibility. You want to focus more on writing _what_ your infra should look like, less _how_ to get there.
What's difficult with programming isn't the language itself, it's everything else: understanding concepts, algorithms, programming patterns, the science.
It feels a bit like trying to reinvent the language of mathematics. It'd be really inefficient writing math in plain English.
This past month, I have spent a decent amount of hours (7+) trying to setup nix on my mac with nix-darwin, and failed.
Most tutorial out there encourage you to download someone else's configuration to get going. I don't want to do that. I want to understand at its core how this thing works.
I've read the official nix language documentation, watched YouTube tutorials, read 3rd party tutorials, and still couldn't get going with a simple configuration that would install a few packages.
The nix language is also really unpalatable to me. But I could deal with that if the examples out there showed a consistent way of doing things – that's not the case. It seems one same thing can be done many different ways – but I want to know and do it the right way. I would generally turn myself to the official best practices documentation, except nix' is very short and doesn't help much.
I really want to use nix. There's no question about its advantages. But nix just won't let me (or maybe I'm too old to learn new things).
That being said, I'll probably give it another try this month...
> but would fail hard if you intend to support multiple release versions of an app, which happens often in the embedded world with multiple hardware targets, or self-hosted, large enterprise apps that require qualification sign-offs.
I don't have experience in this world, indeed.
But isn't "multiple release versions of an app" just "one application, with multiple different configurations"? The application code is the same (same version), the configuration (which is external to the application) is different.
Your build system takes your application code and the configuration as input, and outputs artifacts for that specific combination of inputs.
Branches are mutable and regularly point to a new commit. Branching is selecting an active line of development, a set of commits that change over time.
That's why git also offer tags. Tags are immutable.
> There's nothing inherently wrong with having per-env branches
There is when you stop thinking in terms of dev, staging and prod, and you realize that you might have thousands of different environments, all named differently.
Do you create a branch for each one of them?
Using the environment name as branch name is coupling your repository with the external infrastructure that's running your code. If that infrastructure changes, you need to change your repository. That in itself is a cue it's a bad idea to use branches this way.
Another issue with this pattern is that you can't know what's deployed at any given time in prod. Deploying the "production" branch might yield a different result 10 minutes from now, than it did 25 minutes ago. (add to the mix caching issues, and you have a great recipe for confusing and hard to debug issues)
If you use tags, which literally are meant for that, combined with semver (though not necessarily a requirement, but a strong recommendation), you decouple your code and the external environment.
You can now point your "dev" environment to "main", point staging to ">= v1.25.0" and "prod" to "v1.25.0", "dev-alice" to "v2.0.0", "dev-john" to "deadb33f".
When you deploy "v1.25.0" in prod, you _know_ it will deploy v1.25.0 and not commit deadb33f that so happened to have been merged to the "production" branch 30 seconds ago.
At [company x] someone wrote a starter guide that tells developers to create a "production", "staging" and "dev" branch for any new repo. We have tons of repositories that follow this pattern.
For many of them, each branch has taken of its own life and could be considered its own completely different codebase. It's a nightmare to manage and it confuses developers on a regular basis.
Don't do this.
If you want to deploy different versions of your software in different environments, use SEMVER and git tags. Don't create 1 branch per environment...
I have since edited that starter guide and crossed out this recommendation.
Totally agree. Though, usually these programmers know how to properly ask a question, make a bug report and/or feature request.
They wouldn't, for example, just barge in an oss project with arguably low value statements like "Python 2 is retiring in thirty months. Calibre needs to convert to Python 3."
> he answers questions from newbies and enhancement requests are far more polite and charitable. His ire seems to be reserved for fellow programmers.
Some programmers (like myself) have little patience for people they consider should know better and are wasting their time. These same programmers are far more charitable to newbies because they know newbies are still learning.
> Remember that this is the guy who said he would personally maintain python 2 because he didn't want to rewrite calibre for python 3 [0].
I read his "I am perfectly capable of maintaining python 2 myself." as "I am perfectly capable of maintaining [calibre running on] python2 myself", which is completely different.
I'm sure some people might also find his answer quite terse and dismissive ("No, it doesn't."), but I read it as a simple statement of facts, using the same tone as the original bug report, which itself is quite terse and imperative "Python 2 is retiring in thirty months. Calibre needs to convert to Python 3."
> The incident began Monday when ATI, which supplies graphics cards for all Apple's current models, issued a four-paragraph news release that stated its Radeon processor would be featured in three new Mac models -- none of which were announced by Apple (Nasdaq: AAPL) until CEO Steve Jobs' Wednesday morning keynote address.