Hendrick's Gin

The other day I finally gave in to impulse and bought a bottle of Hendrick’s gin. I’ve only tried it a couple times, so this was my first chance to really play with it and figure out how to use it.

I didn’t like it (but keep reading, it gets better). I tried using it to make my standard slutty dry martini recipe, which is along these lines (I don’t measure):

• 5-6 Large (or 7-8 small) olives with pimento filling
• ½ oz Olive brine
• ¼ oz Dry vermouth
• 5-6 oz Frozen gin (I keep it in the freezer)
• Dash of wormwood bitters (homemade by soaking wormwood in grain alcohol for a couple months)

It didn’t taste right. I like my martinis rather salty and dry, and despite going a bit heavy with the olive brine it wasn’t much of either. I couldn’t put my finger on why it didn’t taste right, but it was not like any of the martinis I’ve made with various London dry gins (Plymouth, Beefeater, Gordon’s, Bombay, Bombay Sapphire, and probably a few others).

The bottle came with a cute little pamphlet written in the style of the Powerthirst video. It focused on how Hendrick’s has cucumber in it, and that it works best when you play to that. Okay, let’s try something a little different:

• ¼ oz Dry vermouth
• ~2 oz Frozen gin (didn’t want to make too much, in case it was nasty)
• 3-4 Dashes of cucumber bitters (from Cecil & Merl)

Ugh! The slutty martini was just sub-par, but this was actually bad. I finished it only because it’s hard to justify dumping any of a $40 bottle of liquor, but by the last few sips I was basically shooting it and hoping the taste wouldn’t linger.

Tonight I decided to try something a little different, though. Going back to the traditional dry martini, I realized the olive was probably the problem; they aren’t exactly cucumber-like. But how to emphasize the cucumber…

Ohh, what about pickle brine and cucumber vodka? So this is what I mixed:

• ½ oz Pickle brine (from McClure's dill pickles)
• ½ oz Effen cucumber vodka
• 3-4 drops Dry vermouth
• ~3 oz Frozen gin
• Dash of Cecil & Merl cucumber bitters

Perfect! It’s like a pickle shot (½ oz pickle brine plus 1 oz cucumber vodka in a shot glass, very refreshing on a hot day) crossed with a martini. I had been wondering how I would get rid of the Hendrick’s; now I am wondering how long it will last.

Bazel and Golang

As a Google software engineer, I use the internal Blaze build system every day. As far as build systems go, it’s really good. So I figured I’d give Bazel a try, since it’s basically the same thing.

Basically.

The part I guess I forgot about was that it isn’t supported and developed by teams of paid engineers all the time. That said, it’s actually not bad. It just feels incomplete after coming from Blaze.

I’m partway through setting it up to build an existing project in Go, which is just barely supported. The documentation is minimal and unclear, but I think I can help out.

Here’s how to take a $GOPATH-type workspace and make it work with Bazel without mucking up all of your project paths, and without symlinking parts of one workspace into another. Because that’s actually what the documentation tells you to do, and it feels wrong to follow it.

First, install Bazel. I’ll wait.

All done? Oh, you don’t like this writing style? Neither do I. I’ll stop now...

Next:

1. Go to your $GOPATH (the parent of bin/ pkg/ and src/) and clone the Bazel repository:
   git clone github.com/bazelbuild/bazel
2. Now we need to make some changes under src/:
   cd src/
   ln -s ../bazel/tools .
3. Write a WORKSPACE file:
   cat >WORKSPACE <
   load("@bazel_tools//tools/build_rules/go:def.bzl", "go_repositories")
   go_repositories()
   EOF
4. Write a BUILD file:
   cat >BUILD <
   load("@bazel_tools//tools/build_rules/go:def.bzl", "go_prefix")
   go_prefix("")
   EOF

I’m not sure why the tools symlink is necessary; it may be a bug in the Go rules. They can’t seem to find their automatically-added dependency without it.

And that’s it, besides for writing BUILD files for each of your packages. I do have one more tip for that part, though: Write your BUILD files in the parent directories of your packages. If you do this:

src/github.com/me/mypackage/BUILD:

load("@bazel_tools//tools/build_rules/go:def.bzl", "go_library")

go_library(

name = “mypackage”,

srcs = [“mypackage.go”],

visibility = [“//visibility:public”],

)

Then when you use that package from Go, you’ll need to double the ‘mypackage’ part:

src/github.com/me/pkguser/BUILD:

load("@bazel_tools//tools/build_rules/go:def.bzl", “go_binary”)

go_binary(

name = “pkguser”,

srcs = [“pkguser/pkguser.go”],

deps = [“//github.com/me/mypackage”],

)

src/github.com/me/pkguser/pkguser.go:

package pkguser

import (

“github.com/me/mypackage/mypackage” // Redundant, eh?

)

But if you write the BUILD file one level up, the names work out as you would expect:

src/github.com/me/BUILD:

load("@bazel_tools//tools/build_rules/go:def.bzl", "go_library", “go_binary”)

go_library(

name = “mypackage”,

srcs = [“mypackage/mypackage.go”],

)

go_binary(

name = “pkguser”,

srcs = [“pkguser/pkguser.go”],

deps = [“:mypackage”],

)

src/github.com/me/pkguser/pkguser.go:

package pkguser

import (

“github.com/me/mypackage”

)

On the other hand, your BUILD files will be longer mix together multiple unrelated packages if you do it this way, so you’ll need to decide what is best for your own project.