In the summer of 2018 I was offered a position at Bisnode that was too good to turn down. In fact, the description of the role read pretty much exactly like the role I had talked to my manager about being my dream role a couple of years before that when leaving Bisnode to try my luck working in the security space building an identity server on standards such as OAuth2 and OpenID Connect for Curity. Having already worked for Bisnode I knew and liked the company and many of the people in the tech organization, so I knew it was a good fit for me. Simply moving back to something that I felt pretty much done with however wasn’t too appealing. So back to the role then.
One of the better named tickets I’ve had the pleasure to work with this season, the “RDS Aurora Postgres root user is a wimp” issue turned out to be quite a challenge. Since resources on the topic online seem scarce to say the least, I thought I’d note them down for others, or if nothing more at least myself should I need to remind myself about this in the future. The original issue was this - doing a routine database maintainenace task some days before I found myself having to delete a few rows in one of the databases created in an AWS Aurora Postgres cluster.
One of the things that’s really improved my workflow in recent years is using pre-comit hooks for git. Tools that help with code quality and style are everywhere these days and obviously help tremendously in both catching bugs as well as enforcing agreed upon style rules. And while these tools should be included as a natural part of any build pipeline, having to wait for the CI/CD server to build your branch and report back on any code quality issues can be both time consuming and annoying. While it’s obvious how to avoid that - by running tests, code quality checks and formatters locally before pushing commits, or at least preparing PR’s - I just constantly forget about it. Pre-commit hooks to the rescue!
Kubernetes 1.19 just released, with a fix for an annoying bug encountered at Bisnode contributed by yours truly. The fix itself is something like 3(!) lines of code - yet, managing to reproduce it reliably - and writing extensive tests to trigger that condition - took weeks of both effort and conversations back and forth with the kubernetes maintainers. Good thing I’m not paid per line of code produced, or I’d probably be the worst paid programmer in the industry.
So a lot of the stuff I’ve been working on lately has revolved around Open Policy Agent (OPA). Though I’m planning a longer writeup on the subject I’ll use this blog to post some of my notes while I exlore this great piece of tehnology.
So, the twenties are finally back! And what better way to start a decade than to try and kickstart that late new years resolution about blogging? Not that it was something I came up with just as the new year approached us - I had started looking at a platform for blogging some months ago already but other things got in the way. Oh well.
subscribe via RSS