28/Dec 2015
4 min. read
Overview FluxDash is a dashboard terminal ui that is fully configurable through json files. You can either give it an indivudual json file or a folder and it will read any json file in the folder and attemp to turn it into a dashboard. You can then move between dashboard by pressing . Features Sparklines Sparklines are a simplified single stat linechart that gives you basic trending over time. Example json: "sparklines": { "Height": 1, "lines": [{ "from": "/system.cpu/", "title": "CPU", "where": "", "type": 2, "height": 1, "linecolor": 5, "titlecolor": 0 }, { "from": "/system.mem.free/", "title": "System Free memory", "type": 3, "height": 1 }, { "from": "/system.mem.cached/", "title": "System Cached memory", "type": 3, "height": 1 }, { "from": "/system.mem.buffers/", "title": "System Buffers memory", "type": 3, "height": 1 }] } MultiSpark A set of sparklines that have been expanded automatically based on a influxdb tag.
29/Mar 2015
3 min. read
Overview A common problem people new to Go tend to run into is managing goroutines. Starting a goroutine is easy but how do you guarantee it closes gracefully when you are ready to exit? All code for this example lives here. First, lets create a struct that will manage our goroutine. In this case it’s just going to be one but there are no restrictions here. //App is an example struct that will run goroutines type App struct { wg *sync.WaitGroup //allow us to wait for close done chan bool Data chan string } func NewApp() (app *App) { app = &App{ wg: &sync.WaitGroup{}, done: make(chan bool, 1), Data: make(chan string, 100), } return app With this we can now add a few methods to start and run our goroutine.
19/Mar 2015
2 min. read
Overview After using death for awhile I started to run into issues closing objects. Mainly that some poorly written code would never close and the app would hang and require me to force kill the app. This seemed like a perfect oppurtunity to use go routines and channels to solve a relatively complex threading problem. What I really want is parallel shutdown with an overall timeout that will shutdown even if something fails.
10/Mar 2015
2 min. read
Overview I was looking around and couldn’t find a simple library that would manage application shutdown using signals. I decided to build a simple library to handle application shutdown and calling Close methods on structs when shutdown was signaled. It is called death. Requirements Should only need to pass the signals you want to use for shutdown. Block the application from shutting down until signal was recieved. Optionally pass structs with a Close method to cleanup objects when shutdown is signaled.
2/Mar 2015
1 min. read
I've found it really dificult to find a concrete tutorial for building zeromq for go in windows using MinGW in centos 7. First lets add the epel-release repo. sudo yum install epel-release Now lets install mingw64. For this tutorial I am going to just install all the mingw libraries. sudo yum install mingw64* Now lets download and compile zeromq using mingw. wget http://download.zeromq.org/zeromq-4.0.5.zip unzip zeromq-4.0.5.zip ~/zeromq cd ~/zeromq mingw64-configure configure mingw64-make Now lets recompile go so that it is also using the mingw compiler.
1/Mar 2015
2 min. read
Godeps is a nice simple tool that allows you to manage dependencies in a very easy way. One major drawback though is that it requires you to commit your dependencies into your repository. This is great for simplicity but horrible for code review. Seeing a commit with 26k files changed really makes it hard to review. I’ve found a simple solution to the problem if you use the common go import layout +-- github.com | +-- company | | +-- project If you follow this layout then you can easily extract all your deps into their own repo like so.