• 0 Posts
  • 90 Comments
Joined 1 year ago
cake
Cake day: July 31st, 2023

help-circle










  • xantoxis@lemmy.worldto196@lemmy.blahaj.zoneRule
    link
    fedilink
    arrow-up
    63
    ·
    27 days ago

    I actually find it really comforting that it’s going back as if it never happened. Don’t get me wrong, I wish the bullet had been a skosh to the right, but hear me out:

    America does not give a shit about Donald Trump. The country doesn’t care if he lives or dies. The media cares a lot, but the country doesn’t think it matters that he almost got shot. He didn’t get a bump. He didn’t get a sobbing tearful day show host wondering if he’s ok. He didn’t even put out a commemorative “Trump got shot” bullet and let’s be real, that’s something he could have done himself. Nobody cares. He’s not important to America.






  • xantoxis@lemmy.worldto196@lemmy.blahaj.zoneRule
    link
    fedilink
    arrow-up
    58
    ·
    2 months ago

    This is how I think about trans men. I’m a cis man, but I never liked men very much, I’ve just never thought of myself as anything else. A trans man–a person who would fight to be this gender? Reminds me that men have value too.




  • I understand what you’re saying about failing early. That’s a great strategy but it’s meant to apply to production software. As in, your product shouldn’t even start up if critical parts are missing or misconfigured. The software should be capable of testing its configuration and failing when anything is wrong, before it breaks anything else. During the development process, failing early also speeds up iteration cycles, but again, that’s only when it’s built into the sw runtime that it carries with it.

    “Fail early” can also mean your product stops working and shuts down as soon as its environment changes in a disruptive way; for example, if you’re using a database connection, and the database goes down, and you can’t recover or reconnect, you shut down. Or you go into read-only mode until your retries finally succeed. That’s a form of “fail early” where “early” means “as soon as possible after a problem arises”.

    You don’t want your development processes to move fast and break things. If your dev and staging environments are constantly broken because you moved fast and broke things, you will ship broken software. The more bugs there are in there due to your development practices, the more bugs you’ll ship, in a linear relationship.

    QA and controlled development iterations with good quality practices and good understanding by all team members is how you prevent these problems. You avoid shipping bugs by detecting failures early, not by making mistakes early.