This week’s pattern is the sidecar. Named after the device that attaches to a bicycle or motrocycle, this architectural pattern describes components of applications that are independent from a main application that have access to the same resources and support the main application much like the vehicular sidecar. Vehicular sidecars were originally invented to allow for safely carrying an additional passenger. Design pattern sidecars in some ways provide support of an “additional passenger” through isolating the different components that may be designed and architected by different teams, for example when a development teams works on an application, and an SRE team works on the monitoring for that application.

I picked up an erasable Rocketbook letter size and some additional .7mm Pilot FriXion retractable gel pins in assorted color inks. Previously, I’ve tried out the Rocketbook that was microwavable. This version allows you to just wipe the page. The notebook comes in some interesting packaging with the pen to one side, and the notebook in the other. As I read the instructions, I realized that I had missed that there was also a cloth in the main packaging.

There are many infrastructure design patterns. In this post, I want to dig into the circuit breaker pattern. This pattern’s name comes from electrical engineering and circuit breakers. Circuit Breakers in Electrical Engineering The power company delivers electricity to your home at a constant voltage (that varies depending on your country of residence). Voltage is the measurement of the force that pushes electrons through the circuit. Current is the rate of flow of the electrons.

Presenter: Carolyn Van Slyck Liveblogger: Jennifer Davis This post was a contribution to the liveblog for GopherCon 2019. Overview It is a joy to build command-line tools that are not only easy to learn, but that other developers are willing to maintain. Often a team’s engineering efforts are spent on the backend, while the cli doesn’t receive the same level of attention. This can result in hard-to-test tools and dumping maintenance of them to whoever most recently joined the team.

My day started with some collaborative community over coffee at the Starbucks in the conference hotel. Our topics of conversation included: Challenges of parenting and finding time for community/conference participation The abstractions of infrastructure of code from chef to terraform Path to development (Gophercon being a gateway to a dev career) Language association paired to roles (i.e., network engineering and Python) Challenges of siloing job responsibility (test and dev) and value of ‘devops’ community/collaboration to repair disconnects IDEs, beyond vim (visual studio code extensions for the win) The value (and cost!