Tubeworms are interesting little creatures. These ones came as hitchhikers on my reefer tank. I’m posting this because Facebook downscaled my gif, which is a bit lame. Update: I went back and a higher res version was available. Ah well.
This little gif shows a few stills of the creatures wafting in the current; the camera is also moving, so you can get a sense of depth, like an owl. Don’t look at it too long - you might get seasick.
See also tubeworm anatomy.
As some may know, I take a very personal approach to building my blogs. Only artisinal, hand-crafted blog solutions would do. Most recently, I was on “Ikiwiki” - a Perl answer to the “site builder” idea popularized by Jekyll and Hyde. Needless to say, mindshare on a system targeted at Perl programmers was not really strong enough to keep the system up with the ever-changing standards for publishing content online. Reactive layout for small screens, live refresh, very fast reload - it became too much overhead to maintain, with too buggy indexes, and occasional non-termination when publishing.
There are a number of things you can do wrong with go’s context. Anti-Patterns Passing required arguments a long way Sometimes, you have a function which is very deep into the call stack, and it needs an ID or something which you know is available at a higher level. Resist the temptation to just throw it in the context: this hides what should be an explicit, required parameter. It’s not a bad idea to unit test that your functions work when passed context.
So far in this series, I’ve looked at how to use context for two cross-cutting concerns: logging and performance monitoring. The third is one that somewhat overlaps with the logging, which is dealing with panics. There are a ludicrous number of services out there which let you capture detailed information about what went wrong when you get a panic. I’m going to talk about bugsnag, but there’s no particular reason that another one like sentry would be much different.
Just about any server application with users is an application with impatient users. You need to keep on top of performance of your application. If you have an HTTP handler, you can just go and do some simple timing of start and end of the request and log it. Then you can analyze the logs, and look for slow endpoints. But to dig deeper, inevitably you need to collect information which lets you triage the performance issue.
One of the shiny new toys in go 1.7 is the ‘context’ library. Not shiny as in it is genuinely new (I still tend to import it from golang.org/x/net/context), but given this library has been considered significant enough to make it into the standard library, it must have at least a glimmer in the right light. In the following posts, I’ll show how I’ve found it can be used for good effect for several common problems facing any programmer of services:
It’s been about a year since my “gopiphany” post where I described how I’d fallen in love with go. A year later, and the series of blog posts I planned on writing didn’t materialize on the timeline I thought they would then, but I’m still very excited about go. I did sketch out a lot of posts, and I went to conferences, and it turns out that I’m not the only person to find that there is a significant gap between what the go tutorials cover and what you need to be an effective programmer in go.
There’s many ways to make sure that a service is operating correctly under the hood. Let’s talk about one standard approach - logging - and how context can help you turn your logs into rich sources of insight. Initially, you might start with the built-in log library, and its Printf inteface: package somelibrary import "log" func DoSomethingAwesome(so, param string, wow int) { // ... awesomeness ... log.Printf("did something %s awesome with %v (%d times)", so, param, wow) } This writes to “standard error”.
One of the first ever open source conferences I attended was YAPC::Eu in Amsterdam, in 2001. One talk that stuck in my mind was about testing, and from around that time I made a point of making sure that my work was adequately covered by unit tests. Perl was actually a very early adopter of unit tests, and not many people know that even Perl 1.0 in 1987 had a unit test suite.
Go 1.5 and newer includes support for vendoring. Vendoring is a way of managing dependencies where instead of relying on the install or build process to find the dependent libraries (as with building with C or using system installation directories with a dynamic language), or using some kind of “virtual installation” (eg, python’s virtualenv, perlbrew, etc), you can include the modules you are installing under a path in your library’s source tree.