The process of writing a unit test usually follows a certain set of steps. First, we set up dependencies of the unit under test. Next, we execute the unit of logic under test. We then compare the results of that execution to our expectations. Finally, we tear down any dependencies and restore the environment to the state we found it so as not to affect other unit tests. In Go 1.
Modules are the future of package distribution in Go. They’re in preview mode now, but in 1.13, they’ll be on by default. For projects that only use public dependencies, they work without a hitch. I’ve found that some additional configuration is necessary if you want a smooth experience using private modules. What follows are my experiences setting up both my local environment to fetch private Go modules and a Docker build environment.
Gophers from around the world descended upon Denver, Colorado for the fifth annual GopherCon last week. It’s been fascinating to watch GopherCon grow up over these past five years to its largest attendance yet. More people are using Go, in interesting new ways, and while we all wait for the videos to be released, I wanted to share a few highlights. When available, links to the Sourcegraph Live Blog for each talk mentioned have been included.
When I first saw Angular's automatic dependency injection, my mind was blown. It was reminiscent of the awe that I had when I first saw the magic methods ActiveRecord defines on your models in a Rails application. As I've been spending plenty of quality time with Angular lately, I thought it would be fun to try to bring Angular's automatic dependency injection over to Ruby.
There is certainly no shortage of blog posts explaining how Angular's dependency injector works, but in order to build one in Ruby, it's vital that we understand how it works.