Posts

I’ve written in the past that this blog is a playground for me to try various tools and play with code around it. Jenkins has been my choice as the CI for it since the start, mostly since it was something I’m used to. However, I’ve also stated that running it on an old laptop with no real backups is a recipe for disaster. I have since rectified the issue by hiding the laptop under a box in a closet but that meant moving away from Jenkins to something that’s lighter and more portable. The choice is the self-hosted enterprise edition of Drone. ...

I’ve recently had my birthday and as a gift decided to give myself a NUC. The intention here is that I could replace the old laptop running Jenkins and Grafana with something that’s a bit more silent and in a smaller form factor. Note that I’m not affiliated with any of the hardware manufacturers in any way shape or form. The planned change The laptop I’ve been using for Jenkins has become rather critical for this blog and a few side projects I’ve got. This meant that I first needed to find a way to migrate everything to a new machine that would be coming. I’ve then focused on rewriting my infra to code with the help of Ansible®. Even though I’m not a super big fan of it I’ve managed to write everything as an Ansible playbook. I did, however, skip the Jenkins and moved towards Drone CI instead. With this complete, I needed to figure out what type of a machine I might want to go for. ...

I’ve written about the infrastructure behind this blog in a previous post and the major issue with it currently is the old laptop I have at home that’s running the Jenkins instance. I really have no way of backing it all up. I’ve asked around a bit and the reddit thread I’ve made pointed me towards moving it all towards Ansible. Since people are using Ansible at work I thought it would be appropriate for me to try it as well. ...

Go comes with great tools for profiling out of the box. It’s one of the features I’ve come to love. I’m not going to go into detail about pprof, but if you need a primer, Julia Evans has a great post about it on her blog. Instead, I’ll try and show a real world example of the optimizations you can make using pprof. I’ll use pprof on mouthful, a gin based server, to see what I could do to make it just a bit faster. It turns out I can detect a rather stupid mistake I’ve made. ...

There are quite a few components to this blog now. There’s an AWS S3 bucket the blog gets served from, there’s a backend service responsible for the mouthful comments, there’s another instance of the service for the mouthful demo page, with another S3 bucket to serve the page for it. There’s also a yet unused service living in the same “cluster” as these two(It’ll get added to this blog soon™). There’s quite a few private github repositories that in unison with a Jenkins instance make this all work. Oh, and everything is running under Docker, with ECS handling all the orchestration for that. For the data stores, I use dynamodb, mysql and sqlite. There’s also some miscellaneous bits and bobs, like the grafana instance that plots response times and uptimes of the APIs. I’ve tried to keep as much as I can inside AWS but due to cost constraints I had to do some workarounds. So how does it all work then? ...

When writing Go code, I often end up with lots of enums that I use to fork my logic in a switch statement. Take this enum: type MyEnum int const ( One MyEnum = iota Two MyEnum = iota Three MyEnum = iota Four MyEnum = iota Five MyEnum = iota )} I’ll then end up with a switch in a part of my code, like so switch myEnum { case One: err := DoSomeOtherStuff() if err != nil { return err } case Two: err := DoSomeMagicalStuff() if err != nil { return err } case Three: err := DoSomeExoticStuff() if err != nil { return err } case Four: err := DoSomeOtherStuff() if err != nil { return err } case Five: err := DoSomeStuff() if err != nil { return err } }} ...

When I created mouthful, I was intending it to be rather light and not feature rich but after getting a few feature requests getting in, I’ve decided to expand it. One of the issues was a request to reuse logon credentials for the admin panel. For that, I’ve needed OAuth. I did not have much prior experience with OAuth, so it did intimidate me a bit. However, after implementing OAuth for mouthful, I can say that nowadays - it’s rather easy including OAuth in your applications as well. It’s also a rather good idea to do so as people behind the providers such as github or facebook are probably going to do a better job than a lone developer like me will at securing your credentials. Anyway, with this post I’d like to show how easy it is to add OAuth to your gin project. ...

I haven’t been blogging much lately. That’s due to the fact that most of my spare time went to creating mouthful - a commenting server that I’ve since switched this blog to. Before that I was using isso. Here’s why I did it. The issue with isso While I really like isso, there’s one problem that kills it for me. Under no load, the backend consumes nearly 50MB of memory on my server. You might say that 50MB is nothing nowadays but I disagree. I’m running everything under AWS t2.nano instances, meaning I only have 500MB of memory to play with. Since I’m running them as docker hosts for my ECS cluster with a few applications on them memory is an expensive commodity. Since I’ve become quite fond of GO, I’ve also looked at commento but at the time of writing it did not have moderation support. I really wanted that. I knew that I could squeeze in the functionality I needed an only use a few MB of RAM. Currently, the commenting service runs with most of the functionality enabled with a stable memory usage of under 7MB. Take this with a grain of salt though, as I do not have many comments or visitors currently. ...

<rant> I absolutely despise OpenApi(well, swagger. I’ll call it swagger since it was that for most of my career). It’s supposed to make the process of creating and documenting an API easier. But does it really?… Here’s what I think about it. Writing the swagger schema is so damn tedious From my experience when someone mentions swagger, you’ll get dragged into design first - code later mindset rather quickly. While it sounds good on paper the practical implications of writing a swagger schema just make me want to curl in a ball in the corner of the office. The swagger schema is so explicit and such a pain to write. We’ve got what I’d call a rather simplistic API by corporate standards at my work. I invite you to “design” it first. The swagger definition for it is 19808 lines long. I’m not kidding. Just think about it. 20 fucking thousand lines of JSON. Good luck designing that. Now, some of you will say “but wait a moment, why not generate the swagger schema from code”. While that does sound like a great idea on paper I really fail to see the point of it. If I document my code properly I can already generate documentation that is not going to be as tedious or as explicit. If the code is undocumented, swagger does not provide any sort of a benefit there. ...

There are quite a few IDE choices for Go. I’m not going to list them all, but here are my prefered ones with the reasoning behind it. The free option VS code is my main IDE as of late. It does not matter if I code Go or Node, I always prefer to go with VS code. I used to use Atom for it’s extensibility and the amount of packages avaialble. But recently, I’ve felt that the quality of packages and the editor itself is better on VS code. That might be due to the fact that it has the backing of Microsoft. Personal experience shows, that open source products backed by huge companies tend to do better over time. It’s no surprised that VS code has exploded recently and the amount of extensions available now is pretty darn amazing. All you need to do is intall a Go extension and you’re ready to… well… Go. While it’s not as fast as sublime or other light weight editors I find it pretty snappy for small to medium sized projects. Microsoft’s intellisense is pretty damn good. Getting delve also allows for debugging inside it, albeit delve itself seems a bit sluggish and unresponsive. That’s probably a general rant of mine with go - the debuggers seem to be rather poor. Despite this, I really love VS code for the ability to support pretty much any language you can think of. ...