~/.ssh/config - Global Settings

This is part of a series explaining the SSH config I’m using on my machine (OS X 10.11). The config should be portable to most UNIX-based systems; Windows users are on their own. Quick Primer Every time the SSH client is invoked, it looks for settings in ~/.ssh/config (as well as some other places). The same is true for utilities that use SSH as a transport such as scp and sftp.

eb config --> deploy

I learned something useful the other day. We use AWS ElasticBeanstalk (let’s just call it EB) at work for deploying the various components of our SOA. I use the eb CLI tool a lot when working with those EB apps. EB stores the configuration data it needs for each app as a YAML file in S3. One of the commands the eb CLI provides is eb config, which allows management of those YAML files from the command line: eb config list to list the saved configurations in S3 eb config save to download a YAML file that describes the current configuration of the app eb config put to upload a YAML file from local disk to S3 etc.

docker inspect | grep

We’ve dockerized all of the apps the comprise our platform at work. Almost all of the configuration data that our apps need is provided via environment variables. Sometimes I need to verify that the correct configuration was provided for a particular environment variable. I’ve executed the following command enough times now that I figured I should write it down somewhere. # $cid is the target container's ID, and $var is some part of the environment variable's name docker inspect -f '{{range $_, $e := .Config.Environment}}{{println $e}}{{end}}' $cid | grep $var This executes docker inspect with a Go template that will loop through the container’s environment variables (which are stored as a flat array of strings like ["VAR1=value1", "VAR2=value2"]) and print each variable on a new line.

Inverted Switch

Go is great for building APIs. It’s common for APIs to perform some validation on the data structures used in request bodies. some structure Assume we’re handling a request with the following body: { "thing_id": 123, "foo": "fizz", "bar": "buzz", "some_date": "2015-08-09T07:25:43-05:00" } This can be unmarshalled onto the following Go struct: type SomeRequest struct { ThingID int64 `json:"thing_id"` Foo, Bar string SomeDate time.Time `json:"some_date"` } package json will do the heavy lifting to parse the date and convert the JSON numeric into an int64.

~/.gitconfig aliases

I use git from the command line as part of my regular workflow. Configuring aliases saves just a few keystrokes, but those keystrokes add up (My bash history says I’ve executed git commands 121 times in my current shell session, which has spanned about two workdays). I have git itself aliased to g in my ~/.bashrc. git allows aliasing subcommands in the [alias] section of ~/.gitconfig. Below are my aliases in workflow order: Fetch & Checkout To kick it off, I typically git fetch from remote to make sure git is aware of the branches that exist on the remote end.

The mux.Vars Problem

We’ve begun to use github.com/gorilla/mux at work as a router for many of our services. I ran into a snag when writing some unit tests, and learned a bit about the design of mux in the process. A quick detour When I say “unit tests”, I mean this: … a software development process in which the smallest testable parts of an application, called units, are individually and independently scrutinized for proper operation.


TL;DR I wrote some bash functions that are a regular part of my workflow. Check them out Go source I have Go’s source cloned in ~/goroot. Since the source is now managed with git, I can switch between versions very easily, and I can browse the source for Go’s standard library using my editor. To clone the source, I did this: git clone https://go.googlesource.com/go ~/goroot Since this constitutes “installing [Go] to a custom location”, Go will need a few environment variables set: export GOROOT=$HOME/goroot export GOPATH=$HOME/go export GOBIN=$GOROOT/bin export PATH=$GOBIN:$PATH Helper functions I wrote a few helper functions which are basically aliases for commands I execute often.

Collaborative Apps with Go at Citrix

Reposted from the Firebase blog Collaborative Apps with Go at Citrix Tim Gossett and his colleague Steven Berlanga are Backend Developers for the Realtime Platform Group at Citrix. They build services to enable collaborative web and mobile apps. Our team is developing realtime communications technology, and we’re using Firebase for low-latency data sync. Our platform provides a rally point for mobile and web clients to connect and start collaborating. Part of that collaboration happens in Firebase.

route 53

At work, we created an internal API for vending sub-domains of a particular, somewhat popular domain we own. The project is written in Go and wraps the AWS Route 53 API to manage DNS records. We decided to use github.com/mitchellh/goamz, which is has pretty well-rounded implementations of most of the AWS APIs. When using goamz/route53, things were working perfectly when aws.GetAuth was passed credentials directly–i.e., the things I normally set as AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY.


TL;DR I have this cool awsenv function. Check it out Full disclosure: the awsenv function in this post is based on a zsh script my co-worker phemmer wrote. I ported it to bash. Why? I deal with a few different AWS accounts in the course of a day. We use separate accounts at work for our development and production deploys, and I also have a personal account to kick around. AWS has a nice suite of command-line utilities, but there’s one aspect that I don’t agree with: credential management.