I have a newer Suzuki Swift - great hatchback. All straightforward dials and knobs (no infotainment system, though it has Bluetooth) and no issues for the 4 years I've owned it so far. It was the cheapest new hatchback one could buy when I bought it.
I don't. I pay for premium services which I use often (YouTube and YouTube music mainly) and am okay with free sites funding themselves by showing me ads
If I'm looking at a for loop, my expectation is that the loop variable will be i. I'm against single letter vars as a general rule but I think this is a fair exception
I'd prefer i to be a description/name of the thing that is being iterated.
If your array is named cars then you can safely assume i will be a car, but depending on the complexity of the code it just adds another step for me to parse, when I could have just named it car to begin with.
That's a simple case where the data being iterated over is clear. When the data is complex, it becomes even more useful to descriptively name i so that you can more easily see what you're working with.
What you are describing, where 1 function = 1 service, is serverless architectures. The "ideal" with any service (micro or macro) is to get it so that it maximises richness of functionality over scale of API.
This does a good job of encapsulating the considerations of an event driven system.
I think the author is a little too easily dismissive of sagas though - for starters, an event driven system is also still going to need to deal with compensating actions, its just going to result in a larger set of events that various systems potentially need to handle.
The virtue of a saga or some command driven orchestration approach is that the story of what happens when a user does X is plainly visible. The ability to dictate that upfront and figure it out easily later when diagnosing issues cannot be understated.
* Some of the article and commentary here read to me like Scrum is being equated with bad management, or a bad relationship with management. If the source of stress boils down to unrealistic deadlines and high workloads, then that problem will persist with a kanban process, or extreme programming, or "yolo free for all".
* A relationship is a two-way street. Yes its certainly possible that your manager is a dickhead, or incompetent, or both - but it is also possible that they don't know how unrealistic their expectations are because you have failed to PUSH BACK properly. A healthy relationship includes saying no, and explaining problems - that is part of a developers job.
* So many developers (my younger self included) WILDLY overestimate their ability to communicate effectively with non-tech people. The idea that you are going to go from having a bad management relationship, to talking to the business directly is... lets say "misguided". I'm still pretty bad at it, but at least I know that I'm lacking here - I'm very thankful for the people who are well versed in stakeholder management (which really is a skill).
There is a core 20% of kubernetes, which is deployments, pods services and the way it handles blue-green deployments and declarative based definitions, namespace seperation, etc. that is really good. Just keeping to those simple basics, using a managed cloud kubernetes service, and running your state (database) out of cluster is a good experience (IMO).
It's when one starts getting sucked down the "cloud native" wormhole of all these niche open source systems and operators and ambassador and sidecar patterns, etc. that things go wrong. Those are for environments with many independent but interconnecting tech teams with diverse programming language use.
For me this is all Kubernetes is. I feel like people are often talking about two different things in discussions like this. For me it's just a uniform way to deploy stuff that is better than docker compose. We pay pennies for the control plane and workers are just generic VMs with kubelet.
But I think for many "kubernetes" means your second paragraph. It doesn't have to be like that at all! People should try settling up a k3s cluster and just learn about workloads, services and ingresses. That's all you need to replace a bunch of ad hoc VMs and docker stuff.
For a lot of company and project I worked on, this is the same conclusion I came to. 99% we only need / want is docker-compose++. Things like 0-downtime deployment out of the box, simple configuration system for replica set and other replication / distribution mechanism, and that is basically it.
I which there was something that did just that, because kube comes with a lot of baggage, and docker-compose is a bit too basic for some important production needs.
Exactly this. Kubernetes has a million knobs and dials you can tweak for any use case you want, but equally they can be ignored and you can use the core functionality and keep it simple.
I can have something with nice deployments, super easy logs and metrics, and a nice developer experience setup in no time at all.
Yeah I found out my work was using kurbernetes. Given its reputation - having never used it before - when I asked if I could set up a server for some internal tooling I was braced for the worst.
What I actually got was a half an hour tutorial from the guy who set it up, in which he explained the whole concept (I had no clue) and gave me enough information to deploy a server, which I did with zero problems. I had automatic deployment from `git push` working very quickly.
To me this seemed like a no brainer. Unless you literally have one service this is waaay easier to use.
Granted I didn't have to set it up - maybe that's where the terrible reputation comes from?
reply