The next release of todocheck – the tool that helps you track & keep TODOs actionable is live!
First time you hear about it? – check this out first.
In version 0.2.0, the main focus was extending support to new programming languages & issue trackers.
Hence, there are now five new languages supported – R, PHP, Rust, Swift & Groovy.
Support has been also provided for two new issue trackers – Pivotal Tracker & Redmine.
Additionally, one useful new feature is that todocheck now supports passing in your issue tracker authentication token via an environment variable – this will make it a lot easier to integrate the tool in your CI environment!
Finally, you can now specify todocheck’s output to be in JSON format. This provides the opportunity to create IDE plugins or include support for todocheck into linter aggregators.
See the full changelog here & don’t forget to update your binary to the latest release!
Yesterday, I released todocheck – a new kind of static code analyser for annotated TODOs.
Way too often, we let leftover TODOs slip into our main branch, which leaves your coworkers puzzles, looking at it a year from now.
They’re thinking – what did I mean by “TODO: Move this to the users package”? What is the users package? It doesn’t seem to exist anymore.
todocheck helps you fix this by forcing you to mark all your TODOs against an existing, open issue in your issue tracker.
That way, if you, at some point, close the issue, thinking you’re done, the CI pipeline will sparkle in red as there is an open, unaddressed TODO in your main branch.
No longer can developers close a half-baked issue, rushing for the weekly sprint review to say “I’m done!”.
Recently, the Go team announced an updated draft design for their Generics in Go proposal. It goes into a lot of details about why certain decisions were made, implementation details, etc.
In this article, my goal is to summarise the major upcoming changes, as the whole draft design can be a mouthful for many.
I will provide some code snippets to demonstrate the major features as well as give you the chance to experiment yourself with them, thanks to the new Go playground with support for generics.
The Elastic stack (also referred to as ELK) can bring a lot of value to your production services. But it is not that much of value if you don’t use structured logs in your services.
In one of my latest posts, I wrote about what ELK is and why you should care. I also wrote a tutorial about how to integrate ELK with your Go app.
In this article, I will walk you through how to integrate structured logging in your Go services. We will use a sample HTTP service with a few basic endpoints and we’ll use the zap library to emit logs on error/success, which would also include some domain-specific info.
In my last post, I shared how much value the ELK stack could bring for your application in terms of the monitoring capabilities it gives you.
In this post, I will walk you through how to integrate your Go application with ELK, what are the different parts of ELK, how they work and how to create a basic configuration for them.
Let’s jump straight in, shall we?