In the two months since I published gg 1.0, a project to reduce the
friction in working with Git, I’ve been working to make it more accessible and
easier to install. To this end, I’ve made three big improvements:
A standalone Go library, gg-scm.io/pkg/git, allows any Go program to
interact with Git repositories. (I may end up writing another blog post just
about this — stay tuned!)
Windows support, complete with MSI installer.
An APT repository for Debian and Ubuntu users.
If you’re interested in trying out gg, it’s never been easier: see the
instructions at gg-scm.io. Read on if you’re interested in how to package a
Go program for Windows and Linux.
Today, I released a small library called postgrestest. It spins up an
ephemeral PostgreSQL database in Go. I’ve found it quite useful for writing
tests that use PostgreSQL while keeping the test hermetic and reasonably
fast. In my benchmarks, starting a server takes roughly 650 milliseconds and
creating a database takes roughly 20 milliseconds — a 70% improvement and
90% improvement, respectively, over a postgres Docker container in the default
configuration.
I’m proud to announce the first stable release of gg, my alternative
Git command-line interface! This has been a release over two years in the
making: I’ve battle-tested gg across many different workflows and projects.
It’s saved me tons of time every day, and I hope it can save time for others
too. Download the latest release and try it out for yourself!
I’m excited to announce that I am joining the engineering team at YourBase!
YourBase’s flagship product is a build system that greatly improves the speed of
software development with very little configuration. It brings me back to what
I’m passionate about: improving how people work by making software simpler. It’s
still early days, but I’m excited by the enthusiasm and the respectful,
remote-first culture I’ve found at YourBase. I can’t wait to see what we build
together!
Since I’ve started working at Clutter, I’ve grown to enjoy the
Apollo React Client library. However, I’ve noticed that the client’s
caching behavior can be difficult to understand and cause surprising issues,
so I’ve decided to collect my findings into one easily digestible post. This
post assumes a basic understanding of GraphQL.
The major hidden component of Apollo Client is the cache, which sits between every query and the backend server.
I’m excited to share my hobby project from the last few months: a GraphQL
server library for Go. While it doesn’t implement the whole
spec and might not be ready for production,
I think it’s in a useful enough state to share more broadly. I’ve tested this
library out with some toy projects and the results have been promising: I’m able
to quickly publish a Go struct as a GraphQL endpoint.
Check it out now by reading the docs and adding it to your project with:
It’s been a little over a year since I wrote about using Getting Things
Done (GTD) to organize my life. I wanted to circle back about what
worked well and what I learned over that time.
It’s always interesting to me to compare different approaches to solving the
same problem. Git and Mercurial are two version control systems that came out
at similar times, trying to address very similar requirements. Git came from
a very low-level systems perspective, whereas Mercurial spent a lot of effort
on its user experience. Despite what you might think, their data models are
remarkably similar. It’s from this observation I started my side project —
gg. I found myself greatly missing the experience of Mercurial, but I’ve
resigned myself to the fact that Git is here to stay.
I came across a rather interesting challenge today while working on gg. I am
trying to replicate the behavior of hg pull, and even though I’ve worked on gg
for over a year now, I still haven’t reached a behavior that I’m satisfied with.
I’ve finally realized why, and it boils down to a very subtle difference in the
data models of the two systems.
July 19, 2019 will be my last day at Google. I will have worked at Google
for 6 years, 3 months, and 11 days (even longer since I was an
intern). After a few weeks hiatus, I will be joining Clutter to
work on their storage and logistics services.
Frequently when people discuss what is a “good” Go library, they usually use
terms like “idiomatic” or “the Go way”. These terms are imprecise and make it
difficult to discuss the merits of different API designs. I recently re-read
Don Norman’s The Design of Everyday Things and realized that the same
principles of design discussed in the book can be used to evaluate the design of
APIs.
