Canadian software engineer living in Europe.

  • 10 Posts
  • 275 Comments
Joined 3 years ago
cake
Cake day: June 7th, 2023

help-circle






  • I feel much the same way, and I can only offer my own rather fatalistic take on it. Maybe it helps.

    Yes, the world is on fire, and yes most of our leaders are owned by billionaires who are speed running fascism, but you aren’t. You (and I, and many others) see this for what it is, so we all have to make a choice: stand up or lie down.

    You can lie down of course, most do. Some out of apathy, some fear, many ignorance. It’s a simple, but short and painful life. You can also stand up, but it’s a brutal and thankless job. Progress is measured in centimetres and in my experience it takes at least a dozen people working together to move the needle even a little bit: a social justice defended here, a bike lane installed there. It’s slow and gruelling work but it’s the only way that needle moves without resorting to violence.

    Join a local action group. I’ve joined the Green Party here in the UK, but when I lived in Canada I was with either them the NDP. Small parties have the advantage of not being corporately controlled, but as a result they need a lot of volunteers. You can find real purpose there.

    It doesn’t have to be strictly political either. Lots of groups are single-issue activists and they can be very effective. Years ago I worked with the Toronto Public Space Committee, and those were some of the best years of my life

    It’s hard work, but the victories, however small will be shared with like-minded people. You’ll be ridiculed by family and despised by many others, and you probably won’t win… but “we don’t fight fascists because we will win. We fight fascists because they are fascists.”

    The way I see it, if the world is going to hell, I don’t want to look back on my role in it and wonder why I didn’t at least try to push back. So I do crazy things, like run for seats on city council. I lost by just over 100 votes in my ward a few weeks ago, but I also helped get six other Greens into council and that’s not nothing.

    “If nothing you do matters, then all that matters is what you do”.


  • My girlfriend’s dad had hundreds of movies on VHS, pirated from cassettes he’d rented in the past and copied at home by chaining two VCRs together over coaxial cable.

    Software was wild pre-internet. My buddy had Windows 95 on 42 3¼" floppies that we copied onto additional sets of 42 floppies that we kept in heavy boxes and then painstakingly installed onto computers belonging to friends and family around the neighbourhood.

    I also had a whole bunch of audio cassettes that contained music I dubbed from radio, other cassettes, and later CDs (burning your own was at first, impossible, and later, expensive).

    I’m 46.






  • I’ve used FluxCD in the past and have looked into ArgoCD, but honestly, I’ve not seen any big benefit from either to be honest. I use k8s both at home and at work, and in both cases, we do “imperative” deploys: you run helm install ... either directly or via the CI and stuff is deployed.

    So for example at my last job, our GitLab CI just had a section triggered exclusively for merges into master that ran helm install ... for all three environments. We had three values.yaml files, one for each environment, and when we wanted to deploy a new version, the process was:

    1. Create a tag for our release version (ie. 1.2.3) and push it to the repo. This would trigger a build and push the resulting image into the container registry.
    2. Push an update to the repo with the new tag set in the appropriate Helm values file. If we wanted to deploy 1.2.3 to development but not yet to staging or production, then the tag: value in each of the environment files would look like this:
    • k8s/chart/environments/development.yaml: tag: 1.2.3
    • k8s/chart/environments/staging.yaml: tag: 1.2.2
    • k8s/chart/environments/production.yaml: tag: 1.2.2

    Once that change is pushed, the CI will automatically apply it with helm install ... and make sure that all three environments are what they’re supposed to be.

    As for dependent services, that should all be in your Helm chart so they’re stood up and torn down together. The specific case you mention about “Service A” being dependent on “Service B” but stood up before “Service B” is ready is a classic problem, but easily solved:

    The dependent service (“A” in this case) should have an entrypoint that checks for everything else before starting. Here’s what I’m using right now in a project:

    #!/bin/sh
    
    while ! nc -z "${POSTGRES_HOST}" 5432; do
      echo "Waiting for postgres..."
      sleep 0.1
    done
    echo "PostgreSQL started"
    
    touch /tmp/ready
    
    exec "$@"
    

    I’ve even got some code that checks that all the Django migrations have run first for the same situation. The Kubernetes philosophy is that any container should be able to die at any time and be eventually be brought back up and that every container needs to be prepared for this. Typically this means that your containers should operate on the basis of “if I can’t work, die, and hope the problem is solved by the time Kubernetes redeploys me”.