Posts

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. ...

So I’ve had this raspberry pi 3 laying around in my closet for a year or a bit more now. While I thought I’d use it for automating something such as monitoring our plants for changes in soil moisture that did not come to fruition. With the start of this blog and the increase in tooling around it, I really needed something to run any sort of CI platform. I tend to host everything under AWS so that everything is under one roof. Issue there is that it might become rather expensive if you start spinning many instances. And CI is something that you might not want to run on the same machine as your services. So I thoguht to myself maybe I can get my jenkins on ec2-nano? That would probably set me back 5$ a month. Then a cheaper option came to mind - why not use the RPI3 for my Jenkins? ...

I will occasionally come across a post like this on Reddit or other social platforms. This post is an attempt to encourage people to try and get their careers in IT started. This is how it all started for me… Initial apprehension of programming After finishing high school, I ended up studying informatics at Vilnius University. The choice was not easy, I was drifting heavily towards economics and physics, as well as considering the more humanitarian part of with focus on business and business management. I basically ended up making a random choice - I ended up in informatics. While I was decent at maths and computers, I would by no means consider myself a competent developer on my uni days. It was really hard and terrifying. Lots of maths on top of maths with only a few lectures focusing on coding. I did like coding but the constant mathematics in day to day uni life was a real killer. By the end of first semester I was highly unmotivated by the lack of coding we were doing. I was a tad lazy, so I did not have any side projects to focus on. At this point in time I started thinking about quitting but peer pressure and my own reluctance to give up came through. I struggled to the sixth semester with little to no will left in studying. I was doing OK at this point. I needed to put little effort into studies themselves to just manage to not get kicked out. I thought I’d finish the degree and definitely not touch anything related to programming. My main concern with programming was that it probably consists of lots and lots of maths that I definitely did not enjoy at that point. I found it boring therefore programming looked boring to me as well. I had no side projects and would describe my skill in programming little more than basic. I should note that by this point I was still living off my parents and had no job. Then one of my classmates who had been working as a developer for a few years offered an opportunity to try and get past an intense course in the company he was working with. I did not know if I was ready for it and certainly felt apprehension for not doing there well either. Nonetheless I gathered my courage and got to the interview. The interview did not go well especially the technical part. I probably answered less than 30% of the questions correctly. One thing I did do and am still proud of is never lied - when confronted with a question I had no clue about I stated that I had no knowledge in the area. Despite my worries, I got accepted. ...

Since this post got quite a bit of traction, I decided to update it by rerunning all the benchmarks as well as adding GO’s fasthttp and Node’s express to the comparison. I came across this blog post on ayende.com. Here Oren Eini tries to see how far he could push a simple ipify style of api on an EC2 by running a synthetic benchmark. He hosts the http server on a T2.nano instance and then uses wrk to benchmark it from a T2.small instance. After reading this, I thought to myself - surely .NET cannot be quicker than GO. I decided to try and make a similar effort and get a little bit of competition going between a .NET implementation with, hopefully, a representative version of Oren’s .NET server made with GO. For GO - I went with 3 candidates gin, fasthttp and iris. I also benchmark Node’s Express. All the tests were performed on the same EC2 instance, with production/release configurations, so variance should be low. I also use the same parameters for wrk as Oren. This is as close as I could get to apples to apples type of comparison. ...