Ask HN: In which areas have you compared 3+ tools and formed strong preferences?

Factor it dev vs. production DB setups, on boarding new developers and growing pains of a startup and having one DB as source of truth with a small performance penalty (and a large cost savings) - it's a no-brainer.

If you want actions and reducers just use the hooks versions for those + Context.

That is exactly why I don't like it. Rather than doing as simple as possible and expanding when needed, you default to the most complex answer. The fact that it can handle anything means you don't need it for everything.

It's worth noting that I access these things most frequently on mobile, so an app (with a clean, ad-free, streamlined UI) is paramount.

Your comment sparked me to seek out whether Wiktionary has an app— and apparently someone has built this iPhone app for a reader view, which at first use appears identical to the desktop view: https://apps.apple.com/ca/app/wiktionary-reader/id984975341

We're currently considering it as a self-hosted process engine to automate technical business processes and to coordinate a few automation systems like jenkins. Crap like, trigger a database restore via system A, wait until complete, update tickets, trigger some data migration from that database via System B, update tickets. Maybe bounce things back to human operators on errors and wait for fixing / clarification. Trigger a bunch of deployments in parallel and report on success.

Systems in this space are either (a) huge, hugely expensive enterprise applications designed to consume all business processes, which is a bit overkill for our current needs (Camunda, SAP, Stackstorm, ...), (b) overfitted onto a very specific data analysis setup (aka: if you don't have hadoop, don't touch it) or (c) overly simplistic and offering no real benefit beyond investing into self-hatred, guiness and making jenkins work.

Airflow seemed like a bit of a decent middle ground there for workflows a bit beyond what you can sensibly do via jenkins jobs.

There's not a lot of writing about this. Folks seem content to fight Airflow's deficiencies. Most of them are too young to know any better. The critiques you'll find are generally written by competitors, or folks adopting a competitor.

Here's the big one I see lots of folks get wrong: do NOT run your code in Airflow's address space.

Airflow was copied from Facebook Dataswarm and comes with a certain set of operational assumptions suitable for giant companies. These assumptions are, helpfully, not documented anywhere. In short, it is assumed that Airflow runs all the time and is ~never restarted. It is run by a team that is different from the team that uses it. That ops team should be well-staffed and infinitely-resourced.

Your team is probably not like that.

So instead of deploying a big fleet of machines, you are probably going to do a simple-looking thing: make a docker container, put Airflow in it, then add your code. This gives you a single-repo, single-artifact way of deploying your Airflow stuff. But, since that's not how Airflow was designed to work, you have signed yourself up for a number of varieties of Pain.

First, you are now very tightly coupled to Airflow's versioning choices. Whatever version of Python runs Airflow, runs your code. Whatever versions of libraries Airflow uses, you must use. This is bad. At one point I supported a data science job that used a trained model serialized with joblib. That serialization was coupled to Python 3.6 and some precise version of SciKitLearn. We wanted to upgrade Python! We couldn't! Don't use PythonOperator. You need separation between Airflow itself and Your Code. Use a virtualenv, use another container, use K8s if you must, but please please do not run your own code INSIDE Airflow.

Second, you cannot deploy without killing jobs. Airflow's intended "deployment" mechanism is "you ship DAG code into the DAG folder via mumble mumble figure it out for yourself". The docs are silent. It is NOT intended that you ship by balling up this mega-container, terminating the Airflow that's running, and starting up the new image. You can do this, to be sure. But anything running will be killed. This will be fine right up until it isn't. Or maybe not, maybe for you it'll be fine forever, but just please please realize that as far as Airflow's authors are concerned, even though they didn't say so, you are Doing It Wrong.

There's a lot that I like and dislike with MongoDB. As a developer, it can be a relatively nice experience. As an administrator, I hate it beyond words. It really depends on your needs, entrenchment and the skills of your staff.

From a migration perspective, the presence of JSONB fields in Postgres, and much of the modern tooling around them, mean that you can even put a highly nested document structure directly into Postgres and have a clear migration path without rewriting code.

(Do note however that Postgres' JSONB overrides the key order of objects to have canonical object identity - it thus avoids pitfall #1 in https://devblog.me/wtf-mongo but legacy code may rely on that behavior.)

MongoDB was great when it worked; I've still never experienced as fluid a workflow as Meteor enabled, where either a client update or a batch process could update a document in MongoDB and it would immediately propagate to every other interested client. RIP - while there's an active community, the Meteor team went on to do Apollo GraphQL, whose real-time support is a shadow of that original developer experience.

That said, on that same project, I can say anecdotally that I was bitten hard by some of the disaster recovery and divergent-oplog issues mentioned in the meme-y https://aphyr.com/posts/284-jepsen-mongodb - granted, the software has improved significantly since then. But I'm of the opinion that a company developing database products can only shift its internal culture so much; such a "cowboy" mentality, one that led to releasing a database product with these glossed-over problems and unreliable defaults, never truly goes away.

Rewrites always require a cost-benefit analysis. Modern MongoDB (you are running a modern version, right?) may have addressed enough concerns that it's the right decision to stick with. But even for document database needs, there's no reason not to use Postgres for green-field projects.

There are many, many companies for which this decision won't matter too much.

I heard that a year or two after I left the company got an Oracle Audit and ended up paying a huge penalty.

The support contract costs more than the "license" if my memory serves me, but its very expensive. If you're doing anything remotely complicated, using their advanced tools beyond a basic RDBMS (replication, clustering, etc.) then you need that support contract.

SQL is the only, only tech thing I love. Other stuff might be fine tools to accomplish various goals but SQL is Good and Beautiful and True.

Anyway the specific thing I'm remembering about cost is a case where a data team I joined had built a (dumb) CI process that ran a whole DBT pipeline when a PR was opened. After a month or so we got a bill for something like $50k.

Snowflake's rack-rate pricing is $2/credit and an XS warehouse is 1 credit/hr. That XS warehouse is, allegedly, an 8-core/16GB(?) instance with about a hundred gigs of SSD cache, from a "c" family if you're on AWS. Of course since your data is in S3 (cache notwithstanding), you're likely to be network-constrained for many query patterns. BigQuery, which is unquestionably faster than Snowflake, proves that this can be done efficiently. But compare to Redshift (non-RA3) or ClickHouse where you have data in locally-attached disks, Snowflake just gets smoked. The only lever they give you to get more performance is to spend more money which is great for their bottom line but bad for you.

The pitch is that because you can turn it all off when you're not using it (which in fairness they make very easy!), the overall costs end up low. Ehhhhhhhhhhh, maybe. It only takes one person leaving a Looker dashboard open with auto-refresh enabled to keep a warehouse constantly online, and that will add up fast. Plus if you are being silly and building DW data hourly, as is popular, it's going to need to be on anyway. (Do daily builds! You don't need more than that!) Point being, the cost model you will get from sales reps makes very optimistic assumptions about utilization, and it is very likely you will be hit with a bill larger than expected. In practice while it is technically easy to control utilization, it is not actually easy because there are humans in the loop.

I told them to please investigate using SQLite with an d3 bucket for storage. Their tools will run about 1x a month on automation, they don't need a full DB.

Due to some unfortunately placed warnings about SQLite in production (context matters too) they were discouraged from this path.

I didn't argue I just said "fine, use aurora" and I'm sure this will bite us in some unforseen way down the road, but that will be Infra issues and then it's my teams job to handle it.

There are some scenarios where there is no 'one tool for everything', like creating a complex OCI image, a VM image using Packer, a VM using Vagrant, configuring a network appliance or configuring an end-user workstation.

Example: super complex OCI images that attach to a CI pipeline would be better served by native packaging tools (like Jib for Java projects), but re-packaging of existing applications might depend on how green the build is. You could do a bunch of shell scripting in a Dockerfile, but once that gets big enough you'll start to need to use functions and perhaps even function libraries that you source in, but at that point you're doing a re-invention of something like Ansible and SaltStack, so depending on existing modules, knowledge, time, experience etc. you might use those instead.

Compare that to non-packaged-deliverable things like network switches and routers; those tend to be long-lived (non-ephemeral) systems, and they tend to have various inconsistent APIs between vendors, models and generations. But you may want to exchange configuration inputs and outputs with other systems so your Cloudflare rules, AWS ALBs, AWS SGs, on-prem Palo Alto firewall and on-prem Cisco switch agree on the configuration, and in such a way that it can be validated and audited constantly and consistently. Not a single named vendor does it all, especially not in a consistent and useful way. But as long as there are providers for Terraform, you can (with Terraform).

Perhaps the best way to describe how I balance it (or try to) is: the more modern the API, the more declarative I'd want to manage it in code. Cloud APIs tend to sit on the most-declarative end of the spectrum and end-user workstations on the least-declarative (or: most-imperative) end.

While I have a couple of personal devices where I could go and customise everything as much as I like, it wouldn't port over to anyone I work with or any system I write software for, or any presentation I give, documentation I write etc.

Being more portable gives be better results overall than being specifically tailored to my preferences. I do default to light foreground and dark background colours wherever I go, but that is supported everywhere as far as I know, and has been the default on many platforms for long enough. (that said, I sometimes consult for complex/crazy situations and whenever you spot an xterm with black-on-white you know it's pain 'o clock).

Are flip phones worth a second look just because my parents prefer them over smartphones?

However, if someone told me their anxiety vanished the moment they switched to a flip phone, they might be worth a second look. Maybe.

Most people do prefer a Phillips screw over a slot screw, or PNG over BMP, but nobody has stated that here because the superiority is clear. If you like BMP over PNG, or MS Teams over anything, then you probably should explain.

There's culture too. I think Telegram, WhatsApp, and Viber, WeChat are all roughly equal. Similar goes for the browsers. Some countries are strongly Viber, while others are strongly WhatsApp, but this is more a product of marketing.

The main issue with Cypress handling this is, from what I understand, one browser per domain which can cause huge memory usage (which Cypress already has an issue with). Once you try parallelising multi-domain tests you run out of memory on developer laptops pretty quickly :(

But yes ultimately you are right, multi-domain is available, it's just those edge cases that get you once you go beyond simpler cases.

Sometimes I edit my markdown files in other editors like Bear (or web interfaces). Sometimes I draw handwritten notes on my ipad and insert them as images.

It all works pretty well.

- Can't disable mouse acceleration via the UI. You have to use the terminal to enter a command to change a setting that sometimes gets overwritten on a system update. You can't disable scroll wheel acceleration at all without using 3rd party software.

- I hate the dock bar. I want each window of an app to be its own entry on the bar so I can easily switch from one window to a specific window with a single click. In MacOS, starting a second instance of an application that doesn't have a native method to do so is a total pain in the ass. Going to the Launcher to start the program just shows the existing instance of the application.

- Shitty defaults in general. Scroll wheel direction is backwards. Scrollbars auto-hide. The screen color shifts throughout the day.

- MacOS is based on UNIX but always feels like it's trying to hide that from you. The "root" user isn't capable of everything. There are directories in your home directory that even root can't access.

- Home/End keys move the cursor to the beginning/end of the document, not the beginning/end of the current line. As someone who uses those keys a lot in Windows, that behavior is aggravating. There IS a way to change this, but it's very non-obvious, and doesn't work in all programs.

- Muscle memory of using CTRL+X/C/V to cut/copy/paste will screw you up as a Mac uses their Command key which is where Alt is on a PC keyboard.

- Finder sucks. You can't cut/paste a file to move it, but you can copy/paste a file to copy it. To move a file in the Finder, you have to open two windows and drag it. The Delete key doesn't delete files.

Often times, things feel different just for the sake of being different and not because the designer thought it could actually improve UI/UX. Apple seems to very much tend to subscribe to the mentality that removing features is a feature.