Golang Try() and Programming in the Large
The new try() proposal is counter to the core principles of the Go language, specifically software engineering in the large. The proposal’s stated goal is to reduce the tediousness around handling errors. I believe, that in actuality, it would reduce explicitness, increase complexity, and hinder large teams on large code bases.
try() removes the shape of current error handling, the if != nil
pattern of
error checking and replaces it with a single builtin function, that can be
nested. Using try() would remove the visual pattern that if != nil
imprints
on our code. We now would have to focus more as we read a block of
code, paying special attention to any nested try() statements, to build our
mental model of the functionality we are reviewing. The possible patterns we
need to scan for has now doubled.
Bash: Check for Duplicates
I often find myself wanting to do a series of repetitive tasks for a small set of data. XKCD has a nice guide for when to write a script for repetitive tasks. Unfortunately I find myself with one off tasks that I would never use a script for again. Still I will write a script to automate my task. Part of me thinks I am saving time, but I’m probably not.
A gentle introduction to Golang Modules
Go 1.11 introduced a new concept of Modules which brings first class support for managing dependency versions and enabling reproducible builds. Go previously had no notion of dependency versions, and it has been a long and arduous road to get where we are now. Modules do not just copy the style of other programming language’s dependency tools, rather it introduces a few slightly different concepts intended to enable programming in the large. These require some thought in order to fully utilize the features provided by these new concepts.
TDD: Red Red Green
Testing gets easier the more you do it. I guess it’s like most things in that regard. For me my comfort level has risen as I have forced myself to practice the small steps that make up Test Driven Development. That was the next step in my TDD journey.
If you recall from my previous TDD blog post I was starting from nothing. No experience dong TDD or testing. My uncomfortableness was physical, a mini anxiety attack, a moment of doubt. Each step of the process caused me to pause and ponder on the bigger picture.
DockerCon 2018
This post was originally published here.
You would think the world is falling apart; or rather it seems that way, and I’m only really talking about the world of software. I’ll leave politics out of this. It’s not that the world of software is falling apart; or rather our applications are. What once were gleaming monoliths, monuments to our own achievement are now being hacked and splintered into microservices. Rather this is the natural cycle that our industry seems to follow every few decades. The boom and bust, the macro and the micro. Migrating from one paradigm to another in search of performance, flexibility, and control. Docker is driving home the sharding of the monolith, pushing the composable unit of computation. I see this in my role at Kong as a Customer Success Engineer; working with people who are migrating to, or asking questions about, microservices.
Hugo: Improved static asset cache busting
Previously I was using a quick fix solution to bust cache on my static css files. Briefly, cache busting is a strategy of uniquely naming CSS and Javascript assets to improve page loads, and speed up propagation of changes when updates to the layout are made. More on cache busting.
My previous technique worked as needed but suffered from a couple limitation. I was using random numbers appended to the CSS filename to get a unique filename. However the random number was updated for every CSS file for every change. This means that one small update would force the client to download a ton of CSS that it did not need. The random number was also really fickle. Making updates and reverts always resulted in new file names. This could have been mitigated with a Unix Timestamp, which would allow rolled back files to use the old file name. This is a little nicer, but still a bit ridged.
Peak Design Everyday Messenger Review
The most frustrating part of the Everyday Messenger is that it is damn near perfect; not quite, but almost. The unique locking latch, a thoughtful strap, and quality construction make this bag a great everyday carry.
The Everyday Messenger is intended to be a photographers bag; with the main compartment set to house a camera and extra lenses. The bag is intended for carrying camera gear, but remove the padded dividers and it works for a laptop and “office” stuff.
Firefox to integrate Pocket
I was shocked when I saw news of Mozilla’s Firefox native integration with Pocket; the popular read-it-later bookmarking service. This is the first time I can remember when Mozilla has integrated a commercial third-party service. It feels a little odd.
I understand why they might have done this. My guess is that Pocket is another revenue stream for Mozilla. I can appreciate the need for money; it keeps the employees happy, and the Firefox updates rolling out in a timely fashion. Not to mention funding research projects like Rust and Servo that are very exciting for the future of the web.
Building Go projects with gb
gb
is a new build tool for Go created by Dave Cheney. It address the problem of reproducible builds. Building the same functional binary anywhere at any time is a problem of dependency management. Of knowing exactly which library version to use, and having it at hand. gb
is a radical tool compared to current dependency solutions, which work with the existing Go toolchain and idioms. gb
takes a different approach, it replaces not only dependency management tools, but the Go build tools themselves. Instead of using go build
or go install
you would use gb build
.
Bash: Check for Duplicates
I often find myself wanting to do a series of repetitive tasks for a small set of data. XKCD has a nice guide for when to write a script for repetitive tasks. Unfortunately I find myself with one off tasks that I would never use a script for again. Still I will write a script to automate my task. Part of me thinks I am saving time, but I’m probably not.
TDD: Red Red Green
Testing gets easier the more you do it. I guess it’s like most things in that regard. For me my comfort level has risen as I have forced myself to practice the small steps that make up Test Driven Development. That was the next step in my TDD journey.
If you recall from my previous TDD blog post I was starting from nothing. No experience dong TDD or testing. My uncomfortableness was physical, a mini anxiety attack, a moment of doubt. Each step of the process caused me to pause and ponder on the bigger picture.
Firefox to integrate Pocket
I was shocked when I saw news of Mozilla’s Firefox native integration with Pocket; the popular read-it-later bookmarking service. This is the first time I can remember when Mozilla has integrated a commercial third-party service. It feels a little odd.
I understand why they might have done this. My guess is that Pocket is another revenue stream for Mozilla. I can appreciate the need for money; it keeps the employees happy, and the Firefox updates rolling out in a timely fashion. Not to mention funding research projects like Rust and Servo that are very exciting for the future of the web.
DockerCon 2018
This post was originally published here.
You would think the world is falling apart; or rather it seems that way, and I’m only really talking about the world of software. I’ll leave politics out of this. It’s not that the world of software is falling apart; or rather our applications are. What once were gleaming monoliths, monuments to our own achievement are now being hacked and splintered into microservices. Rather this is the natural cycle that our industry seems to follow every few decades. The boom and bust, the macro and the micro. Migrating from one paradigm to another in search of performance, flexibility, and control. Docker is driving home the sharding of the monolith, pushing the composable unit of computation. I see this in my role at Kong as a Customer Success Engineer; working with people who are migrating to, or asking questions about, microservices.
Hugo: Improved static asset cache busting
Previously I was using a quick fix solution to bust cache on my static css files. Briefly, cache busting is a strategy of uniquely naming CSS and Javascript assets to improve page loads, and speed up propagation of changes when updates to the layout are made. More on cache busting.
My previous technique worked as needed but suffered from a couple limitation. I was using random numbers appended to the CSS filename to get a unique filename. However the random number was updated for every CSS file for every change. This means that one small update would force the client to download a ton of CSS that it did not need. The random number was also really fickle. Making updates and reverts always resulted in new file names. This could have been mitigated with a Unix Timestamp, which would allow rolled back files to use the old file name. This is a little nicer, but still a bit ridged.
Building Go projects with gb
gb
is a new build tool for Go created by Dave Cheney. It address the problem of reproducible builds. Building the same functional binary anywhere at any time is a problem of dependency management. Of knowing exactly which library version to use, and having it at hand. gb
is a radical tool compared to current dependency solutions, which work with the existing Go toolchain and idioms. gb
takes a different approach, it replaces not only dependency management tools, but the Go build tools themselves. Instead of using go build
or go install
you would use gb build
.
Golang Try() and Programming in the Large
The new try() proposal is counter to the core principles of the Go language, specifically software engineering in the large. The proposal’s stated goal is to reduce the tediousness around handling errors. I believe, that in actuality, it would reduce explicitness, increase complexity, and hinder large teams on large code bases.
try() removes the shape of current error handling, the if != nil
pattern of
error checking and replaces it with a single builtin function, that can be
nested. Using try() would remove the visual pattern that if != nil
imprints
on our code. We now would have to focus more as we read a block of
code, paying special attention to any nested try() statements, to build our
mental model of the functionality we are reviewing. The possible patterns we
need to scan for has now doubled.
A gentle introduction to Golang Modules
Go 1.11 introduced a new concept of Modules which brings first class support for managing dependency versions and enabling reproducible builds. Go previously had no notion of dependency versions, and it has been a long and arduous road to get where we are now. Modules do not just copy the style of other programming language’s dependency tools, rather it introduces a few slightly different concepts intended to enable programming in the large. These require some thought in order to fully utilize the features provided by these new concepts.
Peak Design Everyday Messenger Review
The most frustrating part of the Everyday Messenger is that it is damn near perfect; not quite, but almost. The unique locking latch, a thoughtful strap, and quality construction make this bag a great everyday carry.
The Everyday Messenger is intended to be a photographers bag; with the main compartment set to house a camera and extra lenses. The bag is intended for carrying camera gear, but remove the padded dividers and it works for a laptop and “office” stuff.