If you twist yourself into a pretzel enough you can make Bash do all these things. Doesn't make it a good idea.
The biggest problem with depending on Postgres is it's a large complex monolith. Any problem you have only has two possible solutions: 1) spend a ton of time trying to twist yourself into a more pretzely shape to get it to do what you want, or 2) replace that thing you wanted with some external thing.
Both of these waste valuable time on something that isn't providing any business value. They also are entirely preventable/avoidable, by simply not putting all your eggs into one basket.
Basically the whole "just use Postgres" philosophy boils down to: I don't want to learn new things, and I just like making things from scratch with custom code. That's great if you're an engineer and you want job security. But it's bad strategy, engineering, and use of time and resources. Anyone who approves of using Postgres in this way should not be in charge of engineering decisions.
But not as a truism. It's possible to manipulate well enough that people above and below you both believe you are working in their interest, but it's quite hard. Great for job security if you can pull it off.
The only time I have seen a good response from the discovery of a large security hole was when it was by total accident, and the person mentioned it in a public channel by accident. They almost got fired, but the bug got fixed quickly.
Checking out literally turns me into an alcoholic. I can't live like that. I'm not an entrepreneur, I'm just a guy who cares way too much about wanting to do a good job.
I agree though, there is no perfect place; wherever you go, there you are. Still, if you're unhappy, you're not going to be less happy by changing to a better job.
At the wrong gig, with the wrong bosses. I have the misfortune of being at one of those bad places now. I was at a much better place before, where if I went out of my way and saved a couple million, I'd actually be congratulated; boss would even let have the credit.
Never stay at a job where the culture is toxic. Even if the money is better. Nothing eats at the soul like being held down by feckless, petty careerists and control freaks.
"harmful youth marketing" ? Adults are just as dumb as kids, and can actually impact the rest of the world with their dumbness. We should be suing them for harmful marketing, period. I have had adult friends have literal emotional breakdowns because of social media's harmful effects.
It's impossible that all that money could be thrown away by companies without it being dirt cheap to produce the products. And it couldn't be dirt cheap to produce them without exploiting cheap labor and the environment. And it's impossible to sustain without tricking consumers into buying more than they need, and tricking investors that their sales numbers equal their value as a company.
Consumers are the fuel for a machine that pollutes and exploits, and churns out great wealth for a select few. Between 10 and 40 percent of the consumer economy has to be exploitative in order to sustain the return rate. Madness.
> Where do you draw the line between config file format and data serialization format?
It's a somewhat ambiguous concept. But generally speaking, config formats lack features that would be useful for a general purpose, and include features that are useful for a specific purpose. For example, it may lack a data type, but it may have some special characters that denote some string is a regular expression. The main difference being how easy it is for a human to deal with it.
The main purpose of a config format is for a human to tell a program how to operate. It is typically distinct from the actual input data used by an application to create output data. It's like the difference between **argv and stdin.
> You now have to write your own parser, which costs at least a bit of time and is going to be more prone to bugs than a widely-used deserialization library like Serde
Actually I argue the opposite. Parsers aren't compatible between implementations which leads to bugs. Specs aren't well understood by either users or programmers which leads to bugs. A home grown implementation doesn't need to be touched after it's first written, unless you're adding or changing the features of your configuration format.
> Users have to learn the format, and have to mentally switch between formats for each application. I just hate how every homegrown config format uses slightly different syntax, esp. which character starts a comment. With `config.yaml` or `config.toml`, I don't have to guess.
Most users never learn those formats properly, leading to false conclusions like the "Norway problem", which isn't a problem with the spec at all, it's a problem of users never reading the spec and attempting to write it (when YAML was never intended to be human-writeable, only human-readable; read the spec!).
Compare this to a home grown config file which is designed to be easy to write, adds functionality to make advanced behavior easier (without adding an entire Turing-complete DSL), and doesn't overload an existing format with broken and confusing changes (see Ansible's and other bastardized YAML hybrids).
"Simplified config file formats" are often just shitty generic DSLs that still lack functionality to actually make the user's life easier. Roll a custom format and hard things become easier [for the user].
TOML is, indeed, a human friendly config format. Whereas INI is a simple config format.
YAML/JSON/CSV/XML/etc are not config formats at all. They are data serialization formats. If you don't know the difference, you probably didn't get a CS degree, or read or understand the specs.
Config formats should be tailored to the application, because the entire point of a config file is to make it easy for a human to configure one specific application. That's why there are 100 different config file formats for old UNIX programs. For each one, it's vastly easier to use that one config format for that one application, than it would be to force some arbitrary data serialization format to represent what the human really wanted the program to do.
TOML is better than YAML or INI for a config file, but what's best is rolling your own format. It literally leads to better outcomes. The user can express what they want faster, easier, clearer, and the application doesn't have to struggle with alternate implementations of the spec for some poorly defined data serialization format.
I agree. Like, you could build two houses: one out of sticks, the other brick. Depending on who's building it, if they've not built a house out of brick before, it's very easy to make a mistake. Versus someone who's been building stick houses forever will get it right the first time.
Also, brand new software in general is like a new hybrid plant. How does it behave in this environment compared to other plants? Does it attract more bugs? Does it need different care? We don't know yet; it's new.
And even for an old well known plant, if the gardener hasn't gotten to know it yet, it's easy to make a mistake with its care. But a well known plant with a gardener who's grown it before is the most likely to work without issue.
I've been doing reliability stuff for near two decades. The one thing I am sure of is there is no way to just engineer your way to reliability. That is to say, no person, no matter how smart, can just invent some whizbang engineering thing and suddenly you have reliability.
Reliability is a thing that grows, like a plant. You start out with a new system or piece of software. It's fragile, small, weak. It is threatened by competing things and literal bugs and weather and the soil it's grown in and more. It needs constant care. Over time it grows stronger, and can eventually fend for itself pretty well. Sometimes you get lucky and it just grows fine by itself. And sometimes 50 different things conspire to kill it. But you have to be there monitoring it, finding the problems, learning how to prevent them. Every garden is a little different.
It doesn't matter what a company like Fly does technology wise. It takes time and care and churning. Eventually they will be reliable. But the initial process takes a while. And every new piece of tech they throw in is another plant in the garden.
So the good news is, they can become really reliable. But the bad news is, it doesn't come fast, and the more new plants they put in the ground, the more concerns there are to address before the garden is self sustaining.
I would rather cut off a finger than ever use Jenkins again. What a piece of shit. Design from the 90s, maintained by people who can't code and don't care about users, trying to turd-polish it into new tech stacks to justify themselves to the sad old enterprises invested in them.
Circle is decent. It has all the functionality you wish was built into Jenkins, but way easier and better, with no maintenance cost or insane languages to learn. It has some drawbacks but nothing you can't work around. Orbs work fine, they also can be private. Circle's self hosted functionality is... bizarrely stupidly designed, but essentially works.
I would much rather use Drone.io for any new paid CI project. The best functionality, literally as simple as possible, with cloud native design. Extensible, flawless as self-hosted, does everything you need.
> Silently ignoring sub-commands that exit with a non-zero code is not the same thing as "never failing".
Well I meant the former. Very useful for things like init scripts where you would prefer the script do as much as it can to get something online.
> What shell are you using that doesn't support `set -o nounset`?
You're right, this does appear to be in POSIX, so I guess it's fine. But it is unusual to see in my experience.
> You expect people to know the difference between `[[ ... ]]` and `[ ... ]` well enough to know what the bash version is required?
No, I want them to use POSIX semantics until they have to do something Bash-y. Simplicity when it doesn't cost anything extra is best practice.
> Just set your shebang to `#!/bin/bash` and be done with it.
Homebrew, Jenkins, Asdf, etc may provide their own version of Bash that is required rather than the system default, and some systems have no /bin/bash at all. So you should use #!/usr/bin/env bash for Bash scripts and #!/usr/bin/env sh for POSIX Shell scripts. This lets the user override the PATH with their required version of Bash for this script. (and the script itself can check for versions of Bash, and even re-exec itself)
I would agree, with the caveat that Bourne Shell isn't really a programming language, and has to be seen as such to be loved.
Bourne Shell Scripting is literally a bunch of weird backwards compatible hacks around the first command line prompt from 1970. The intent was to preserve the experience of a human at a command prompt, and add extra functionality for automation.
It's basically a high-powered user interface. It emphasizes what the operator wants for productivity, instead of the designer in her CS ivory tower of perfection. You can be insanely productive on a single line, or paste that line into a file for repeatability. So many programmers fail to grasp that programming adds considerations that the power user doesn't care about. The Shell abstracts away all that unnecessary stuff and just lets you get simple things done quickly.
Only if it doesn't matter that the script fails non-gracefully. Some scripts are better to either have explicit error handling code, or simply never fail. In particular, scripts you source into your shell should not use set options to change the shell's default behavior.
"Prefer to use set -o nounset."
ALWAYS use this option. You can test for a variable that might not be set with "${FOO:-}". There is no real downside.
"Use set -o pipefail."
Waste of time. You will spend so much time debugging your app from random pipe failures that actually didn't matter. Dont use this option; just check the output of the pipe for sane values.
"Use [[ ]] for conditions"
No!!! Only use that for bashisms where there's no POSIX alternative and try to avoid them wherever possible. YAGNI!
"Use cd "$(dirname "$0")""
Use either "$(dirname "${BASH_SOURCE[0]}")" or grab a POSIX readfile-f implementation.
"Use shellcheck."
This should have been Best Practice #1. You will learn more about scripting from shellcheck than 10 years worth of blog posts. Always use shellcheck. Always.
Also, don't use set -o nounset when set -u will do. Always avoid doing something "fancy" with a Bashism if there's a simpler POSIX way. The whole point of scripts is for them to be dead simple.
But it's probably not going to go upstream. And probably very little of it will go into other projects. Every time one of these forks gets dropped on the internet, nobody does anything with it, because it goes out of date shortly after it's dropped. Probably a couple specific optimizations will get picked up from it and put upstream. Versus if development had started and stayed in upstream, you wouldn't have to force people to pick through a huge patchset looking for things they personally want upstreamed.
The biggest problem with depending on Postgres is it's a large complex monolith. Any problem you have only has two possible solutions: 1) spend a ton of time trying to twist yourself into a more pretzely shape to get it to do what you want, or 2) replace that thing you wanted with some external thing.
Both of these waste valuable time on something that isn't providing any business value. They also are entirely preventable/avoidable, by simply not putting all your eggs into one basket.
Basically the whole "just use Postgres" philosophy boils down to: I don't want to learn new things, and I just like making things from scratch with custom code. That's great if you're an engineer and you want job security. But it's bad strategy, engineering, and use of time and resources. Anyone who approves of using Postgres in this way should not be in charge of engineering decisions.