Absolutely. I enjoy it so much that I wonder "do people actually NOT enjoy writing Ruby?" It's usually the first tool I pull out of the toolbox for DSLs, scripts, spikes, one-offs and the like. A lot of the time, the project will happily stay in Ruby unless there's a good reason to use something else. And then I move it - horses for courses.
I programmed professionally in C, C++, C#, Deplhi, and a few other languages well before I had even heard of Ruby.
You have to be careful of what you mean by "does it actually work".
Does the dowsing find water hidden in a random spot or is the dowser tapping into subconscious knowledge about the land to find it. The parent is talking about the latter.
Look up "Ideomotor phenomenon" in your source. It's right above the pseudoscience bit.
Custom tooled leather accessories. I've been tooling leather (and selling some on and off) for years. It's possible to make a living with it, but it's certainly not easy. With the prevalence of fast fashion, people often get serious sticker shock when they see what a hand made item actuallly costs.
I feel much the same way, and for much the same reason. I do, however, have a largish fleet of aliases that I've built up over the years.
The vast majority of them are simple short forms. For example `tf` for `terraform` and `tfp` for `terraform plan`. My brain just naturally thknks of the full command when using the short form and, because of this, I'm not at a loss if I'm logged in somewhere without my aliases.
I've practiced highlighting on and off over the years, but it's never been for memorization. I've mainly used it to separate out critical passages to speed up and simplify future reading.
I know almost no one does this, but the absolute best standup meetings I've experienced have meeting of the just workers, by just the workers, to let just the workers know what's going on around them so they can self-direct.
The addition of management always turns it into a status update.
I'd agree with that. Unless I'm trying to increase the amount I walk, I usually come in under 5K steps a day. It's not at all hard to add a few tasks to get it up to a more reasonable number, and I do, but if I don't intentionally add those tasks, the baseline is very low indeed.
No, we were talking about architechts making decisions that you characterised as poor. I was pointing out that your statement was over-general and that there are many instances where making the informed decision to ignore HA is a completely reasonable thing to do.
By your last sentence, it appears you agree with me.
If you meant to say that your statement only applies to cloud architects who are attempting to maintain an uptime SLA with multi-az/region redundancy, then sure, AWS has lots of levers you can pull and those complaining really should spend some time studying them.
As for legacy applications, I would not have brought up them up at all if you hadn't suggested pushing things into lambdas as a solution to multi-az. Once again, there are many many situations where this is not appropriate. Not everything is greenfield, and re-architecting existing applications in an attempt to shoehorn it into a different deployment model seems a bit much. Unless I'm misunderstanding what you meant.
This has quickly grown to more than adding in a couple of lines! Now I need to architect my legacy app so that I can deploy into lambdas, then I can get resiliency I don't really need!
Not all systems require high availability. Some systems are A-OK with downtime. Sometimes, I'm perfectly fine with eventual consistency. You really do have to look at the use-cases and requirements before making sweeping staements.
Or how about "I'm fully aware, I've done the math taking into account both cost and complexity of implementation and cost of downtime, and I'm probably making fantastic calls based on my actual needs."
I programmed professionally in C, C++, C#, Deplhi, and a few other languages well before I had even heard of Ruby.