CV with Markdown, Pandoc and GitHub Actions
How I manage my CV
A simple blog about programming and technology
How I manage my CV
Whenever facing a new challenge for implementing a new system or functionality, I try to stick to the mottos don’t re-invent the wheel and use the right tool for the job - I attempt to find the right libraries or software that can be used as building blocks for solving the problem at hand.
You want to parse JSON? Use a JSON-parsing library! You want to validate some data input? Use a validation library! You want to write structured logs? Use a proper logging library and a dedicated log shipping tool! You want to handle complex user authentication in your microservice stack? Use a user authentication service!
Common CI/CD pipelines can consist of an arbitrary number of steps, offering space for a lot of different actions. In this blog post, I will list down what I think should be, can be, and should not be done in a CI/CD pipeline.
What Keycloak is, what problems it solves, and why it is awesome.
Why I think the hate for bloated frameworks is (mostly) unjustified.
How idempotent APIs can make your system more fail tolerant.
How Terraform is changing how we work with IT infrastructure.
There’s many programming languages out there, but none of them are perfect (yet). Here is why I’m sticking to Kotlin for now.
The RGR approach is a methodology derived from Test-Driven Development.
The idea is to structure development in the following phases:
Red
We write our expectations first, usually via an automated test.
Once the test is written, we can run it and see what happens.. This seems a bit useless, we haven’t written any code yet, it cannot pass. But what if it passes because our assumption of the problem, or the implementation of the tests, or the setup of the test cases are wrong?