• 0 Posts
  • 12 Comments
Joined 3 years ago
cake
Cake day: June 15th, 2023

help-circle


  • Or, if the business is 24/7, make sure they have an explicit on-call policy with designated shifts. (e.g. who is allowed to call you, what is the expected response time, is an issue disruptive enough that it needs resolving at 3am on a holiday, etc.)

    My current job (IT for a non-profit research facility) pays a sweet daily bonus just for having my phone on me, even if I don’t get called over a week, plus double overtime pay when I do get called afterhours. I’ve had 13 shifts over the past couple years, and was called only 7-8 times, 3 of those on the same weekend for the same issue (couldn’t make a permanent fix until the following Monday).

    In any other job, I definitely wouldn’t accept a manager or random coworkers sending me messages out of the blue on a weekend and getting mad when I don’t respond.


  • No, you’re absolutely correct! I meant it more along the lines of the “We take nothing by conquest” rhetoric, which is equally hypocritical considering the reality. I didn’t really want to add an “/s” to the statement… Yes, the US killed a lot of people in Mexican territory, but then they made up a treaty and paid $15mil for half of the land 🤷 (heavily simplified).

    But it’s 2025, and I’m honestly not sure if the geopolitical climate is in a better or worse state than it was 170 years ago. And if not worse on average, it’s definitely widely polarized.





  • Functions in Python can only return a single value. While you are allowed to comma-separate additional values, as you have done, they are combined into a single tuple object that wraps the intended values.

    As such, your splitter function is returning a single tuple containing three strings. Your calculate function is expecting three individual arguments (I’m guessing that the error trace mentions this).

    To get around this, you can use the splat/asterisk operator to “unpack” the items from the tuple:

    a, b, c = *splitter(expression)
    # or, inline
    calculate(*splitter(expression))
    



  • I’ve actually been investigating Postgres cluster configurations the past 2 weeks at work (though we’re considering CloudNativePG+Kubernetes on 3 nodes spanning two physical locations).

    One thing I might recommend is to investigate adding a proxy like PgBouncer in front of the databases. This will manage request differences where write-queries must go to the primary, but read-queries may go to any of the replicas as well.

    It should also better handle the recycling of short-lived and orphaned connections, which may become more of a concern on your stage 3, and especially on some stage 4.