It’s not that bad if you need to deploy at least 3 things and for most cases it beats the alternatives. You can get away with a bootstrapped deployment yaml and a couple of services for most scenarios. What should you use instead? Vendor locked app platforms? Roll out your own deploy bash scripts?
Sure the full extend of Kubernetes is complicated and managing it might be a pain, but if you don’t go bonkers is not that hard to use it as a developer.
I picked this up as a first reference as someone who had no knowledge in DSP and it was an absolute gem. Really helped with the mental model for sound processing. This repository has some amazing resources too: https://github.com/BillyDM/Awesome-Audio-DSP
Willing to relocate: not at the moment, but open to discuss depending on the job
Technologies: backend/systems engineer generalist. At the moment I work with Go, Kubernetes and Linux. I’m interested in C, Rust and Python as well. Would work in any programming language.
CV: Upon request via LinkedIn or email. I have a outdated one here [1] without much information about my current employer.
Sharing preferences and opinions on code ergonomics certainly has value for me, and I bet it has to other people too. This is, after all, a developer's forum.
I'm certain your opinion on petunias and your possible distaste for orchids will be welcomed in a flower-news type orange site. :-)
I don't work with it either. But I find that learning the abstraction below where you're working at can be quite beneficial to understanding the constraints of your layer, debug, and solve problems.
E.g.: Learn the basics Transport Layer protocols (TCP/UDP) if you work with HTTP
It's interesting to see how many people in this thread have had negative experiences with OOP. As much as I don't do OOP that much anymore, I think it had a positive impact in me. But like every popular practice, there is a lot of bad patterns you have to navigate through.
Things like depending on interfaces as opposed to concrete implementations; or prefer message passing over direct data access are practices that I learned in OOP that I still value. The "Small Talk crowd" from the first team I worked in and influential authors in the topic (specially Sandi Metz) still have a dear place in my heart for how they improved the way I view software design.
I agree. Hating OOP is somewhat mode du jour, but if you started out from languages like FORTRAN and C as I did, you organised your code around abstract data types and operations to work on them (including mechanisms like passing 'this' as the first arg, composition of structures and common operations). OOP was a completely natural extension.
Like "life isn't fair" and "most vendors have an abusive EULA", if you ever find yourself saying that to defend your side ... you're probably on the wrong side.
Clear communication is good. You should welcome suggestions for how to communicate better. "Try it sometime", as it were.
Thank you for these points. I've made some corrections in the post.
> consider that something like à can consist of either a precomposed "à" code point or an "a" + "` diacritic" sequence
If Unicode provides a precomposed combination doesn't it mean that in fact has a code point for every character? Regardless of offering diacritic combination codes?
