In April 2026, my fellow Task maintainers and I participated in Session 4 of the GitHub Secure Open Source Fund. This initiative was created by the Github Security Lab with the intention of sharing expert knowledge with maintainers and improving the security of open source projects and thus the supply chain and downstream projects.
You can read GitHub’s blog post about Session 4 of the program on their website.
This was a pretty spontaneous trip. We had discussed the idea of a backpacking-style trip around Europe many times, but still on a high from our trip to Japan, we jumped at the opportunity after spotting that Interrail had a Christmas sale. After some back-and-forth we decided on a route that would start in Rome - to which neither of us had been - and end in Berlin 3 weeks later. On the way, we wanted to see as much as possible, preferring to explore on foot and sample the local food rather than doing too many of the touristy things.
I’ve now been using Visual Studio Code for pretty much all my projects (work and personal) since sometime in 2016 when I switched from the ill-fated Atom. That’s nearly a decade in the same editor! Over the years, I’ve tried numerous alternatives from Goland, IntelliJ, and Fleet to Vim/Neovim and Helix, but I’ve always ended up back in VSCode for the work that really matters.
This is likely due the the vast extensibility of the editor and the size of its community. There is nearly always something that I can’t do as easily in another editor as I can in VSCode. Or if I can, then it takes a remarkable amount of configuration and maintenance for it to work as smoothly. That aside, change is hard and moving to another editor is a big commitment that often comes with a learning curve and a dip in productivity - something that is hard to justify. But with that said - I’m done with VSCode. It’s time to move on and this is why.
Japan has been on my list of places to visit for years, but we always found something more important to spend our money on or found a reason to push it back a year. Well, this year my Wife, 3 close friends and I finally put our heads together and planned our first ever trip.
I’m lucky that my family had the means to go on holidays all over Europe when I was young, so I have quite a bit of experience travelling. But even then, I’ve only left the comfort of my home continent to visit the US, South Africa, Morocco and India. Each of those extra-European trips was a step up in terms culture shock, but I always found a way to settle in. It’s surprising how quickly you can adjust to a country’s customs and traditions if you immerse yourself and this is exactly what I wanted from our trip to Japan.
If you’ve spent much time writing code in Go, you’ve probably come across the functional options pattern. Go doesn’t have named/default arguments and this can sometimes make it difficult to wrap up initialisation logic in a clean way.
The functional options pattern works around this limitation by allowing the caller to pass in a series of functions that modify the object being initialised. This pattern is used commonly in many popular Go libraries such as GRPC and the GCP SDK. However, functional options can be quite a controversial topic in the Go community - Loved by some and hated by others. You’ll notice that the linked packages do not use the typical “function type” approach to functional options. Instead, they use interfaces. This post explains why this is a good idea and how you can use it in your own code.
I’m a reasonably quiet person. The sort of person with a small, but close group of friends. It’s unlikely that you’ll find me shouting loudly across a room or posting regularly on social media. However, I have a deep-rooted passion for science and technology and a love of sharing it with others. If you engage with me in a conversation about anything from your favourite keyboard layout to what happens as you fall into a black hole, we’re going to get along just fine.
Among a small group of friends, it’s not always easy to find an audience for every niche thing I care about. So that’s what this is for. My half-hearted attempt at a blog. Likely to be rarely updated, with plenty of grammatical mistakes and of little use to anyone, but just a place for me to ramble about the things that interest me - and maybe you.
Task has always had variables, but even though you were able to define them using different YAML types, they would always be converted to strings by Task. This limited users to string manipulation and encouraged messy workarounds for simple problems. Starting from v3.37.0, this is no longer the case! Task now supports most variable types, including booleans, integers, floats and arrays!
Lately, Task has been growing extremely quickly and I’ve found myself thinking a lot about the future of the project and how we continue to evolve and grow. I’m not much of a writer, but I think one of the things we could do better is to communicate these kinds of thoughts to the community. So, with that in mind, this is the first (hopefully of many) blog posts talking about Task and what we’re up to.
