> Also, serious off-topic question to the motorcycle enthusiasts here: how do you cope with the fact that your weekend leisure ride is often a massive noise disturbance for hundreds of people and animals?
AFAICT, the noise is the point. The people with loud vehicles (and this includes the rattling bass and coffee can mufflers on low-end econoboxes) are selfish assholes, desperate for attention, often compensating for a failure in another part of their lives. "Loud pipes save lives" has zero data to back it up.
> a cruise, but a cruise with ~30 other people, not ~6000.
This is the sort of thing that tempts me - an enchanting vision, like something out of "Death on the Nile", only minus the death. Just a small floating hotel that takes you to interesting places, not a floating amusement park combined with buffet.
> An embedded Lisp that supports a true REPL would be a god-send.
I might be misunderstanding your requirements; "embedded" can mean so many things these days. But what do you think of ECL (https://ecl.common-lisp.dev/main.html)?
> I don't want half finished changes forever committed to history.
This is exactly why I hew to squash+rebase. As I like to put it "I don't care about every little sneeze a developer had." Git has spoiled me with this, where I have the power to commit to my private repo anything I damn well please, but in the end I can clean things up and keep the central repo clean and bisectable[0].
Any VCS that doesn't offer these (squash, rebase, bisect) is a complete non-starter for me.
> Most definitely sharp edges, and your bevels, matter when you are really pushing it, especially if you are racing, and most especially if you are on extremely hard or even water-injected snow.
I have to ask, as someone into alpine touring and ski mountaineering (but not racing), what difference would backcountry skiing make to this advice? I imagine you'd need sharpening more often, due to twin factors of A) more rock and hard ice and B) really wanting that control on ungroomed (ie, icy) slopes at high angles.
I don't consider myself "really pushing it", but would like to have every ounce of control I can get when heading downhill. I'm enough of a beginner that I will often side-slip or even just hike completely down a slope I don't like the looks of.
> So what people do is instead of carving perfectly, they deliberately slip to create some friction and slow themselves down.
As an amateur alpine tourist who is deathly afraid of that feeling of "loss of control" from incredible downhill speeds, this is exactly what I do.
That said, I'm here reading because I want to know if the heuristic for sharpening changes when A) one is mostly off-piste (rock, hard ice, etc) and B) really want those edges sharp for ungroomed (ie, icy) slopes.
> I think interesting take on the same idea I saw lately was "Every Dead Body on Mt. Everest Was Once a Highly Motivated Person". It seems not that new but still.
I mean, everyone dies. Not that I'm elevating Mt. Everest climbers, but at least they're aspiring for something.
Now, if the message you're trying to get across is it takes more than motivation, and life is rife with failure, that I can get behind. But "don't try, there's no point" is the laziest, most self-serving twaddle ever to be uttered (and no, it's not Nihilism either).
Honestly, for public facing read-only websites, it's perfectly fine to redirect HTTP to HTTPS. There's just too many cases where you aren't going to get everyone to put "https://" on the front of URIs when they put them in docs, flyers, etc. You're lucky if you get "http://"!
The API security thing, yes, that makes sense. Personally, I run a number of servers for small groups where the sensitive stuff is SSL only - you won't even get an error going to port 80, other than the eventual timeout. But for reasons above, I cannot just turn port 80 off, and it's perfectly safe redirecting to 443.
> Show me a program that has no bugs and I'll show you a program that does nothing at all!
"Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work."
> I find some people just give feedback poorly and equate that to others not taking feedback.
Too true! I find it helps if I think of it as an engineering problem: "what can I say that will make these people not commit the same error again?" A bit dehumanizing and manipulative, but can be super effective at shifting away from blaming and belittling (almost never works), and towards mentoring.
Always, always assume this is the case - it might frustrate you to no end, but until you have conclusive evidence something is "wrong", it's best to ignore it and toodle along with whatever you're supposed to be working on (I always encounter these head scratchers when working on legacy code, my tasking being something unrelated).
To play Devil's advocate, I'd like to point out that many of these egotistical assholes are "trying" to "help" - by "trying" I mean their communication skills are poor, and by "help" I mean they are trying to encourage people to improve. I know, I've been one of these assholes. What I've tried to do to be less of an asshole is leverage my empathy and hone my communication skills. But I also recognize the anger and frustration with things that seem like they should be no-brainers - and recognize that what we despise in ourselves is often what we attack others for.
Nobody's perfect, but there are ways people can get better. Or just take advantage of tools that can help automatically catch these sorts of errors. This is precisely why people create regression tests and set them up to run in the CI/CD, to reject changes that break them.
As for being less of an asshole, no shortcuts with that - just exercise your empathy, put yourself in their shoes, take a deep breath, then go to bed. Tomorrow morning, if you still feel the need to pen a blog post, maybe write out a technical solution without assigning blame.
This is awesome! While I'm nowhere near being able to leverage this right now, I am currently going through the painful process of "databasing" raw documents into SQL, and I can tell you that perhaps the hardest part is getting the schema correct; as you put it "natural language can often be ambiguous". Even worse, is just the squishiness of things never originally intended to be specified for software.
Communication always has been, and continues to be, the hardest part of software development.
> it sounds like you're describing the possibility of calculating his expected weight gain based on how much he ate and how much he exercised, and I don't think that's possible.
This is a joke right? This is exactly how you calculate expected weight gain/loss.
> Remarkable the hand waving people go through to excuse dishonesty because they want to believe it so badly.
What I find remarkable is how badly people want to ignore just how bad fast food is for you. They'll use anything to dismiss completely the whole debate.
AFAICT, the noise is the point. The people with loud vehicles (and this includes the rattling bass and coffee can mufflers on low-end econoboxes) are selfish assholes, desperate for attention, often compensating for a failure in another part of their lives. "Loud pipes save lives" has zero data to back it up.