chasinglogic

I prefer modal editing. It feels the best to me, but that could be because I learned it.

I had to learn vim back when I was a basic system administrator so when it came time to start doing real coding it was an obvious choice. I also prefer properly open source software, and if possible, non-corporate backed. So it checks all my boxes especially now that I'm not "missing" anything from VSCode.

When people ask me though I recommend VSCode to most normies, I don't think vim is worth it nowadays.

Whenever I see tools like this I always think "that wouldve been great at my old job where we didn't do post mortems"

But nowadays I think if I can automate a runbook can I not just make the system heal itself automatically? If you have repeated problems with known solutions you should invest in toil reduction to stop having those repeated problems.

What am I missing? I think I must be missing something because these kinds of things keep popping up.

For handling secrets we manage helm via Pulumi (previously Terraform) and pass in the secrets to values from Secrets Manager or whatever cloud provider.

I haven't found a good alternative to Helm. Pulumi is probably the best if you wanted to just create manifests their k8s provider is great, but we ultimately want to shift left the kubernetes manifests and helm is pretty ok for that.

As an SRE with a database background this should be required reading for any development team.

The declarative DSL for defining user interfaces reminds of QML and I'm not sure why I would use this over QT really given that Slint seems to have a similarly weird licensing model.

While I can't contest that SCons is comprehensive, I would never recommend it as a source of learning "what to do".

SCons is not idiomatic Python and it abuses things like `eval` which gives it terrible performance.

Source: I used to work for MongoDB and my full time job was to make SCons faster, which I eventually did by making it a Ninja generator (which has now been upstreamed). But the code is still pretty bad.

Using SCons however is much nicer than using make / autoconf IMO, especially now that you can farm the builds out to Ninja.

While there is definitely a higher barrier to entry, once I got comfortable with Rust (and finally stole someones working cross-compile / publish github actions for it) it has surplanted Golang in this use case because it does spark joy for me.

Definitely, it's also important to remember how salaries vs. infrastructure costs show up on a P&L sheet.

Salaries are going to be considered largely immovable and they won't "go down" or show as a lower number on the P&L as a result of your devs getting some time back. Whereas your infrastructure costs jumping up (even by a small amount, esp if you have any amount of scale) will set of alarms, rightly IMO, in the Finance department.

This to me is the real question. I don't see how you could easily create multiple clients if you're practicing what is preached in the article.

You're really tying your server to the browser at that point so things like CLI clients and mobile clients become painful to write (not impossible but ain't nobody got time for parsing HTML when browsers do a perfectly good job of it, not to mention CSS.).

I've felt this way a few times. But whenever I think about building some of my personal apps as desktop only to reduce the hosting burden I remember that I want to access a lot of that data on mobile too and getting sqlite to sync around to my mobile device is a real pain (not to mention now having to build a mobile app to read it).

Web apps are just real convenient on the usage side even if I loathe building them most of the time.

I have a Dell XPS 13 Developer Edition.

I get 5 - 6 hours of real work out of it, 8 when doing nothing major using Ubuntu 20.04, but I have the 4k screen I hear it is a lot better if you have the 1080p screen.