• 0 Posts
  • 23 Comments
Joined 1 year ago
cake
Cake day: July 23rd, 2023

help-circle









  • The only other time rewriting history might be bad is when you’re working on a shared branch, which is the point of not rewriting main. If you are working solo on a branch, its history is only what you merge into main so it doesn’t fucking matter at all. If you’re not working solo, maybe you need to adopt a similar process or look at how you’re not working solo. The only time I touch another dev’s branch is at the PR stage and only for quick corrections or missing knowledge so it doesn’t matter if they rebased before or honestly rebase after before the final merge.





  • Absolutes in programming tend to lead to bad designs. This is more a “I’m gonna stir up some shit on Twitter” post than real wisdom.

    • No microservices usually leads to bloated, tightly coupled logic that ignores business domains
    • No monoliths usually leads to sprawling microservice deployments with tightly coupled dependencies and flavor-of-the-week new ones
    • No Kubernetes usually leads to VPS pets or crazy obstacle courses trying to get SSL termination without a million fucking dependencies in a cloud container orchestration system that isn’t as good as Kubernetes
    • All Kubernetes usually leads to huge SRE costs for a tiny app

    The same shit happened last summer when AWS came out with their “we dropped microservices for a monolith and look at our speed increase” article which ignored good design principles. Sometimes you should split things over business domains so you can deploy and code independently. Sometimes Kubernetes is the best way to handle your scale needs. The stories we normally read are about people doing it wrong (eg AWS making a bunch of microservices inside a domain sending fucking gigs of data between what should have been functions in a single service). Inexperienced folks don’t always know when to move from their minimum viable solution to something that can scale. That doesn’t mean you remove these things, it means you train on when you need them.

    Should we abandon design patterns because singletons or flywheels aren’t the correct solution all of the time?





  • I agree with that. I think that there are people that want that deeper level. Most of your users are not going to fit into that, though. If you’re only supporting your power users, you will eventually wither and die as your power users leave.

    I first bought a book with Red Hat Linux 6 or 7 in the early aughties (pre-RHEL/Fedora split). While I have actively participated in the technical improvements of project since then, I have typically stayed out of the social aspects.



  • Discord performance is inversely proportional to the number of servers you’re in. Until Discord addresses this, it’s a shit tool for this use case unless you participate in a tiny number of servers in one facet of your life. Unlike chat tools like Slack that allow you to focus one server or community tools like forums, Lemmy, or VCSaaS which don’t consume resources when you don’t use them, Discord just tanks everything. Since you can’t easily hop in and out (something community tools let you do because, you know, you’re not constantly polling the server), you can’t self regulate.

    Every single gaming community, coding community, project, store, hobby group, friend group, and professional group (study group too) has their own Discord. It’s a goddamn nightmare because Discord does not prioritize basic community functionality. Voice and streaming kick ass, but I need some server management and resource optimization.