I wasn't suggesting making JSON "REST" APIs (not actually REST, more accurately you might call them JSON data APIs or something). I meant protocols that are specifically meant for RPC, like gRPC, JSON-RPC, etc. Or message queues like RabbitMQ.

Ah yeah I thought you were saying '91 isn't a 90's kid, sorry.

Omaha is a lot less left-leaning in my experience. It's very purple. Lincoln is solidly blue.

I just recently purchased a house in Lincoln. Just quickly looking on Zillow for Omaha and home prices look to be very similar to what I was seeing here in Lincoln. Property taxes in Omaha are also a fair bit higher than Lincoln.

There's other stuff too, like lower crime rate in Lincoln, better/more parks, LPS being generally a lot better than OPS, etc.

I guess it ultimately depends on what you're after. If you want something more big city, then Omaha obviously has Lincoln beat. But for a more relaxed pace of life and for raising a family, Lincoln is where it's at.

Common Lisp isn't a functional programming language. Guile being based on Scheme is closer, but I'd still argue that opting into OOP is diverging from the essence of FP.

If you mean for programming specifically, I... don't, really. At most it would be for a quick sanity check on syntax in a language I don't write often, for which Google is fine. But otherwise I rely on documentation and search features of the various language/tool-specific websites.

No, you divide work so that the majority of it can be done in isolation and in parallel. Testing components together, if necessary, is done on integration branches as needed (which you don't rebase, of course). Branches and MRs should be small and short-lived with merges into master happening frequently. Collaboration largely occurs through developers frequently branching off a shared main branch that gets continuously updated.

Trunk-based development is the industry-standard practice at this point, and for good reason. It's friendlier for CI/CD and devops, allows changes to be tested in isolation before merging, and so on.

I just mean the usual water treatment practices to ensure safe drinking water. At minimum I would expect filtration to be happening since you don't want particulates floating around in it.

I've had snake. It's pretty mediocre and tough.

Sure yeah, but like, I work remote and will always work remote (I live in a city with a pretty mediocre tech scene). On top of that, I work in a non-mainstream programming language (Haskell). So it's hard to envision what I could actually do.

I'm very pro-union btw, it just seems like there are certain things that can sometimes make it more difficult to make happen

I'd say it's definitely worth it. I don't actually use nixos itself, but I do use nix a lot. I have everything I need for work in a home manager configuration, so I can literally just install nix and load up my config and have all programs and configuration of said programs installed and ready to go (on any UNIX system). I started doing this since changing jobs means a new machine, and I got really tired of all of the inconsistencies between machines when bringing over my dotfiles, and having to install a bunch of packages I use every time I changed jobs.

I do want to make the switch from Arch to nixos on my personal machine eventually too, but I hardly spend any time on computers outside of work these days, unfortunately. But the great thing is that my home manager configuration can pretty easily slide right into a nixos configuration, which is what many people do.

That's exactly the same thing. A branch is nothing more than a commit that you've given a name to. Whether that name is your original branch's name or a new branch's name is irrelevant. The commit would be the same either way.

A junior cannot actually do any real damage or cause any actual issue. Even if they force push "over" previous work (which again, is just pointing their branch to a new commit that doesn't include the previous work),, that work is not lost and it's trivial to point their branch to the good commit they had previously. It's also a good learning opportunity. The only time you actually can lose work is if you throw away uncommitted changes, but force pushing or not is completely irrelevant for that.

I try to make it pretty balanced. Dnd isn't really balanced around constantly long resting, and I think resource management is part of the fun. Low level spells are pretty meaningless if you always have high level spells slots to blast through and such.

So my approach is this:

1. Only long rest after my 2 short rests
2. Short rest when reasonable, such as when the party has a good chunk of HP missing.
3. Generally aim for 3-4 encounters per long rest (encounters don't have be combat, can be anything you expend resources on, such as healing or charming an NPC)

So far it's worked out pretty nicely. It makes the game more challenging and rewarding, imo.