Often times we need to unmarshal upstream data with unique constraints. Such as custom data types, or custom parsing of specific formats. Using the standard library could be impractical, and handling long structs manually can be tedious; however there is an alternative.
As my digital documents grows and expands I want to ensure that my documents and data will be available to me far into the future.
One of the challenges of managing all my data is organizing and backing up the many many files I have.
I want to save almost all of my files and documents, but A lot of them I suspect I will rarely access in the future. Or maybe I will never access them. In order to reduce the overall number of files I have to deal with I want to combine and compress these files into an individual archive. Still, I want to ensure that if I ever want to revisit these files they would be safe and accessible even if that is years in the future.
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.
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.
Tmux is a wonderful tool to increase my productivity by multiplexing windows and apps to a single terminal. I use it all the time when working on a project to organize my tools, and quickly switch between them.
One things I do these days is create a shell script to launch, and customize, my tmux session for the specific project that I am working on. This give me quick access to a complex setup, allowing me to jump into a project and get moving quickly.
