The two arg cd is pretty useful (and, zsh implements it too because cd is a shell feature): if you have parallel directory structure (e.g. the way rails does tests) you can switch from app/b/c/d to spec/b/c/f by doing `cd app spec`
My experience mostly matches this: I think of a piece of development work having three phases:
1. Prototype
2. Initial production implementation
3. Hardening
My experience with LLMs is that they solve “writer’s block” problems in the prototyping phase at the expense of making phases 2+3 slower because the system is less in your head. They also have a mixed effect on ongoing maintenance: small tasks are easier but you lose some of the feel of the system.
This might be programmer-brain, but I find sqlite is pretty nice for things people would use a spreadsheet for. It’s a little bit higher friction, but when I started designing a Improv-like terminal spreadsheet a while ago, I eventually realized I was just reinventing databases.
The Cayenne would not be safer going 35 instead of 40 "regardless of all other variables": it's statistically safer to go closer to the flow of traffic because you're then "at rest" with respect to other drivers (assuming a controlled access road without pedestrian traffic). If the speed limit is 55 and the flow of traffic is 70–80 (as is the case with the Beltway around DC, despite automated enforcement), then going 55 is more dangerous than "speeding". The issue with 100% enforcement is every law assumes certain circumstances or variables and the real world is infinitely more complex than any set of variables that can reasonably be foreseen by law (and laws that attempt to foresee as many variables as possible are more complicated and, consequently, harder for normal people to apply, which is another reason for latitude in enforcement).
I’m not justifying the design but splitting a table with several billion rows is not a trivial task, especially when ORMs and such are involved. Additionally, it’s easier to get work scheduled to ship a feature than it is to convince the relevant players to complete the swing.
Normalization is possible but not practical in a lot of cases: nearly every “legacy” database I’ve seen has at least one table that just accumulates columns because that was the quickest way to ship something.
Also, normalization solves a problem that’s present in OLTP applications: OLAP/Big Data applications generally have problems that are solved by denormalization.
> the effort and cost to download an ad-blocker that automatically removes the prompt to accept/deny entirely is practically zero
It's only zero if you don't need to interact with sites that break when you're running an adblocker. I run an ad-blocker nearly continuously, but there are all sorts of sites where I have to disable it in order to use the actual functionality of the site (and these are frequently sites I _have_ to interact with).
Yeah, there's something of a tension between the Perlis quote "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures" and Parse, don't validate.
The way I've thought about it, though, is that it's possible to design a program well either by encoding your important invariants in your types or in your functions (especially simple functions). In dynamically typed languages like Clojure, my experience is that there's a set of design practices that have a lot of the same effects as "Parse, Don't Validate" without statically enforced types. And, ultimately, it's a question of mindset which style you prefer.
I'm not sure why "954 partners" is surprising: log10(954) is between 2 and 3 so, if you assume Soundcloud uses at least 10 SaaS products to manage data (AWS, Snowflake, Datadog, etc. this number is definitely a low estimate). And then you assume each of those entities process the data through 10 partners of various kinds, it only takes 3 steps out to get 1,000.
I've had a couple outages due to major version upgrades: the worst was the major version update that introduced systemd, but I don't think I've ever irreparably lost a box. The main reason I like nixos now is:
1) nix means I have to install a lot fewer packages globally, which prevents accidentally using the wrong version of a package in a project.
2) I like having a version controlled record of what my systems look like (and I actually like the nix language)
Over time I evolved to Debian testing for the base system and nix for getting precise versions of tools, which worked fairly well. But, I just converted my last Debian box to nixos
fiddlerwoaroof.at.hn