Delivered once every Week. No Spam Ever.

Issue - 45


Worthy Read

This report describes my experience designing, implementing, and deploying a Go API for instrumenting programs with metrics for production monitoring.

Whenever writing any code that may potentially run in a concurrent or threaded context, it is imperative to consider what the implications of running multiple copies of your code at once are. How are you accessing data? Can it cause race conditions? Do you need to lock a resource before you can read or write it?

Embed docs directly on your website with a few lines of code.

Today the Go team is happy to announce the release of Go 1.9. You can get it from the download page. There are many changes to the language, standard library, runtime, and tooling. This post covers the most significant visible ones. Most of the engineering effort put into this release went to improvements of the runtime and tooling, which makes for a less exciting announcement, but nonetheless a great release.

It’s not everyday that you have a cluster of only 4 machines, that are probably much less powerful than my current MacBook Pro, handling POST requests writing to an Amazon S3 bucket 1 million times every minute.

Golang basic examples of Date and Time manipulation functions

Companies like Airbnb, Pfizer, and Artsy find great developers. Let us find your next great hire. Get started today.

A Multi-Master Distributed Caching Layer for Amazon S3.

Go has come a long way, CPU profiling is likely not what you want, Contributing to Go can be daunting.

This is an experience report about the use of, and difficulties with, the context.Context facility in Go.

There are a lot of discussions about Go 2.0 and what should be done in the upcoming major release. Some circulations were about Context. So far I haven’t heard anything optimistic about that. Today I discovered by myself: how quick a newbie (as me) can mess things up using Context. Maybe I reproduce the only case you should not use Context but anyway.

This post was inspired by Peter Bourgon’s great talk, which asked the Go community to talk more about their approaches to using the context package.

I recently started using the really great go.cli library to develop a super simple command line server in Go. When testing this server, however, I needed to figure out a way of starting and stopping it on demand. It is very easy to start a CLI app, just call the Run method with a list of arguments.

So far, we’ve built a blockchain with a proof-of-work system, which makes mining possible. Our implementation is getting closer to a fully functional blockchain, but it still lacks some important features. Today will start storing a blockchain in a database, and after that we’ll make a simple command-line interface to perform operations with the blockchain. In its essence, blockchain is a distributed database. We’re going to omit the “distributed” part for now and focus on the “database” part.

I keep hearing good things about restic. I am redoing my storage solution, and restic seems to tick all the boxes for my personal backups.

In a code review recently, I asked the author to change some of their asserts to requires. Functions in testify’s assert package allow the test to continue, whereas those in the require package end the test immediately. Thus, you use require to avoid trying to continue running a test when we know it’ll be in a bad state.

At Samsara, we make vehicle gateways that provide real-time vehicle telemetry from the engine computer over CAN, data from wireless temperature sensors over Bluetooth Low Energy, and Wi-Fi connectivity. The gateways are resource-constrained computers. Unlike a server with 16GB of RAM, or an iPhone with 4GB, our gateways have only 170MB and one core.

This is a recount of an adventure where I experimented with some Go assembly coding in trying to optimize the math.Atan2 function.


But what happens if the functionality change in the newer version of Go doesn’t cause the source code to fail to compile on older versions, subsequently introducing silent bugs? How do you require developers use a newer Go version, while ensuring the build failure is actionable and informative?

What if your apps handled their own ops? That’s kind of like devops’ final form, right? Its ultimate evolution? The Charizard of devops, if you will.


Projects

cheap-ruler-go - 150 Stars, 4 Fork
A Go implementation of cheapruler.

grava - 47 Stars, 1 Fork
Mapbox Vector Tile Server - Go.

guard - 16 Stars, 0 Fork
Kubernetes Authentication WebHook Server.

rqlite-adapter - 9 Stars, 1 Fork
RQLite adapter for Casbin https://github.com/casbin/casbin .

chiefr - 6 Stars, 0 Fork
Distributed project development model and toolkit.

random - 4 Stars, 0 Fork
Cryptographically secure random strings, ints, and ranges in Golang .

tabular - 3 Stars, 0 Fork
a lib to manage tabular data

goderive - 0 Stars, 0 Fork
goderive derives mundane golang functions that you do not want to maintain and keeps them up to date. It does this by parsing your go code for functions, which are not implemented, and then generates these functions for you by deriving their implementations from the input parameter types.