haha as if. I mostly do bugfixes, small features, and otherwise most of my PRs are just unit text fixes so that our CI jobs run again (because my colleagues don't seem to care about breaking tests, so I get to fix everyone's tests, so that QA doesn't go postal).
To put it into numbers: my PRs are usually less than 5 files changed, and very little changes in those files.
"Distributed systems" doesn't have to mean some fancy, purpose-built thing. Just correlating between two Postgres databases might be a thing you need to do. Or a database and a flat text file.
I usually just have a uuid4 secondary for those correlations, with a serial primary. I've done straight uuid4 PK before, things got slow on not very large data because it affected every single join.
Your comment heavily implied (to me) scaling databases horizontally. Yes, it's not necessarily "Google scale" either, but it's a ton of extra complexity that I'm happy to avoid. But a Google employee is probably going to approach every public-facing project with the assumption of scaling everything horizontally.
With multiple servers talking to a single database, I'd still prefer to let the database handle generating IDs.
Yeah, there's too much advice jumping straight to uuid4 or 7 PKs for no particular reason. If you're doing a sharded DB, maybe, and even then it depends.
Speaking of Google, Spanner recommends uuid4, and specifically not any uuid that includes a timestamp at the start like uuid7.
The elephants wandered off, and now a bunch of giraffes are drinking from the pond. Some of them even spread their legs wide to keep their feet from getting wet. Very relaxing to watch.
> Some of them even spread their legs wide to keep their feet from getting wet.
I always interpreted the spreadeagle pose of a drinking giraffe to be a way of bringing their head closer to the ground. Do they sometimes not do that?
I worked on creating a card game with a couple of my friends. We kept all of the cards in a Google Sheet, allowing everyone to easily edit or create new cards. Then, I wrote a script to compile the sheet into a card atlas so that it could be consumed by Tabletop Simulator. It worked amazingly well.
The only issue was that I had to run the script myself, since my friends were less technical. I'd probably see if I could setup a workflow in Github Actions to do it for me if I were to do this again.
In Python, every variable is either defined or imported in the file in which it's used, so you always know where to find it. (Assuming you don't do `from foo import *`, which is frowned upon.)
In C++, a variable might be defined in a header or in a parent class somewhere else, and there's no indication of where it came from.
How does this help when trying to determine the parameters a function takes? You have to either hope that the name is descriptive enough or that the function is well-documented. Failing that, you need to read the code to find out.
As far as I understand it, as you have a back-and-forth conversation with an LLM, you have to provide the entire history of the conversation plus your new response each time.
Stateful models, e.g. RNNs, are Markov models too. Sometimes "Markov chain" is used to refer specifically to models with no hidden state, e.g. (decoder-only) Transformers.
reply