Posts

This will be a tutorial in how to implement websockets in Go using the excellent gorilla/websocket package. We will build a backend server in Go that accept json from the user and pushes that data on the websocket channel; the frontend will be a simple html file with inline javascript (for simplicity sake) that connects to the go backend and listens on data and updates the html in realtime. Brief Description of the Websocket Protocol The quick explanation on wikipedia on websocket goes like this: ...

Sensu is a decent monitoring platform compared to nagios, since the configuration is more flexible (and a lot more config mgmt friendly) and the platform is also easier to scale and customize. In this post I will demonstrate how easy it is to configure cusom handlers on checks and how to send notifications to a chat. Setting it up What I’m trying to accomplish is the following: ...

Microservice architecture is a common architecture pattern that favors small services that’s independantly deployable which communicates with each other most often with a HTTP api. This architecture pattern has been very popular in our industry and is heavily favoured in opposition to build big monolithic systems that are hard to develop in cooperation and deploy. However the microservice architecture pattern does come with some downsides - it’s a lot harder to understand the communication model, i.e which services is comminicating with which service. And it’s a lot harder and daunting to find out exactly where in the chain latency is introduced. ...

I recently did some investigations at work on how to keep documentation up to date. I guess we’ve all been in the situation that the documentation we have is drifting from how the actual systems/applications look like. I believe that it’s easier to keep the documentation close the the actual code, e.g by README’s in markdown, than by have them as separate confluence pages that no one remembers to keep up to date. If you are using Confluence you can create/update documentation by using the REST api, however Confluence does not accept markdown so you have two options; ...

Both devs and ops care a lot about logging. For devs it gives them a way to peek into the behaviour of the application once it’s running and way to debug, and for ops it’s the first thing they go to for troubleshooting incidents in production. Because logging is such an important troubleshooting source it’s really important that we can change logelvel on the fly when the default loglevel aren’t showing us enough information. Unfortunaltey, from my experience, this is something we’re really bad at - I can remember numerous occasions where we had to disable the node from the loadbalancer, change the loglevel, then restart the application, enable the node in the loadbalancer and repeat this dance for the x number of nodes. Turns out it’s super simple to implement changing loglvel at runtime. ...

I’ve recently been working with the new pipeline plugin dsl in Jenkins 2.0 and the more I work with it the more I like it - I truly believe that it’s the next generation of pipeline as code even though it has several limitations and gotchas that I will describe. A brief history of pipelines and job generation in Jenkins Pre Jenkins 2.0 was simply not designed for complex Continuous Delivery pipelines. What the community created with plugins such as Build pipeline plugin and Delivery pipeline plugin was basically a hack, sewing together separate jobs by passing parameters to them. While functionally it was basically just a big ugly hack underneath with lots of overhead. ...