• 0 Posts
  • 60 Comments
Joined 9 months ago
cake
Cake day: February 23rd, 2024

help-circle




  • I don’t know why you’re being downvoted here. I thought a lot of the audience here was relatively informed on what it’s like to work in IT/programming. Where we do what we can to make sure all our updates go well, but things slip through the cracks.

    This was a massive fuckup, but it’s likely not that different than pushing a bug to prod, it just so happens that their prod has such a huge audience. I would hope they have very strict rules about what gets in, but I can also respect that no matter how many processes you put in place to make sure bad things don’t happen, problems can still make it through.

    Crowdstrike should be held to a higher standard of course, because of how impactful these mistakes can be for their software. And it’s pretty crazy that something this bad slipped through. But I wouldn’t jump to criminal negligence here without more information.

    p.s. I’m not saying CEOs / corps should not be held accountable. They should be. And CEOs do have the power to drive the company into criminal acts and they should be held accountable with jail time for that. I’m just saying I don’t think that’s the case here.




  • Microservice from the start may be a lot of overhead, but it should at least be made with that scalability in mind. In practice to me, that just means simple things like make sure you can configure it via environment vars, run it out of docker compose or something because you need to be able install it on all your dev systems and your prod server. That basic setup will let you scale if/when you need to, and doesn’t add anything extra when planned from the start.

    Allocating infrastructure on a cloud service with auto scaling is the hard part imo. But making the app support the environment from the start isn’t as hard.










  • You’re right, I’m not representing the merge correctly. I was thinking of having multiple merges because for a long running patch branch you might merge main into the patch branch several times before merging the patch branch into main.

    I’m so used to rebasing I forgot there’s tools that correctly show all the branching and merges and things.

    Idk, I just like rebase’s behavior over merge.




  • I feel the opposite, but for similar logic? Merge is the one that is cluttered up with other merges.

    With rebase you get A->B->C for the main branch, and D->E->F for the patch branch, and when submitting to main you get a nice A->B->C->D->E->F and you can find your faulty commit in the D->E->F section.

    For merge you end up with this nonsense of mixed commits and merge commits like A->D->B->B’->E->F->C->C’ where the ones with the apostrophe are merge commits. And worse, in a git lot there is no clear “D E F” so you don’t actually know if A, D or B came from the feature branch, you just know a branch was merged at commit B’. You’d have to try to demangle it by looking at authors and dates.

    The final code ought to look the same, but now if you’re debugging you can’t separate the feature patch from the main path code to see which part was at fault. I always rebase because it’s equivalent to checking out the latest changes and re-branching so I’m never behind and the patch is always a unique set of commits.