I started stacking up my programming books this morning, and realized how much I’d gleaned from the writing of other programmers. It’s no coincidence if you go looking for answers, you’ll find them.
I’ve started a github repo where I’m holding the notes of this reading, and I’ll be getting all my recommended software books into a nice pretty little list on here. Since I’m in a new book every couple weeks, it should be fun to keep up to date.
Books gave me ideas in software. Writing software helped me learn how those ideas and patterns work. All of the books I will upload are written my likeminded programmers, who tend to agree on the subjects: testing/TDD, refactoring, design patterns, etc.
A few books that shaped me as a software engineer:
Design Patterns - Gang of Four
Clean Code - Uncle Bob
Pragmatic Programmer - Hunt/Thomas
Hopefully me documenting the notes/books I’m reading will inspire others, help them on their software journey. Looking forward to doing some open learning.
In light of my recent post, I thought I’d give some insight into a not-so-small decision I’ve made.
I’m comitting to using the Go programming language professionally.
Now, there’s lots of articles sharing the praise of the Go programming language, and rightfully so. But this article will be more a personal excerpt of my last few months, and how I ended up adopting (in process of) this young systems programming language.
For the last few months, I’ve been writing a lot of game code. I find it challenging, fascinating, and ultimately rewarding when you can write code that impacts gameplay. All of the engines are built in C/C++, and then either expose C++ APIs (UE4), or allow scripting of the engine via C# (Unity).
C++ is great because of its power, bredth of use, and age. The creators are still working on the language, and that means a lot to me. The specification is thoroughly documented and there’s literally enough information to pour over for years (think 1986 release).
Well this led me into…
I write ruby/js most of my days, and I have to say I love statically typed code! It just clicks for me. This article is not about static vs dynamic typing systems. I just want to be clear that my last 3 months have been interesting, as I’ve realized something about myself. I prefer to read code with clearly documented types, and compiled languages favor that.
So, I start getting frustrated writing ruby. I start documenting types more. I even started building a simple ruby TypeChecking mixin to use as I need. Funny right?
I’ve had my eye on Go for awhile now, but never felt the need to make the jump. With my day to day including more C++, I’ve found the need to reevalute the langauge as an option. Here’s why I’ve made the decision:
Go is compiled, and portable
coming from ruby, a big complaint of mine is installing the runtime on a new machine, and then managing that moving forward. Look - I get it - RVM! RBENV! CHRUBY! It’s great. But sometimes I’d like to just download a binary, move it into my path and call it. Especially for devops tasks. Go solves that problem for me.
Go’s also readily available on Windows/Mac/Linux. I can download the installer from their website and be up and running on any OS (i have machines with all 3 installed), and get back to work. The best part is, my vim setup will actually be useful!
Go is built by Ken Thompson (and other CS veterans), so yeah
Vim support is vast
Go HTTP Suppport + Revel
Command Line Utilities
Good Programming Habits
eachblocks before I knew about control flow as a topic in a language. I never really got great at looping over numerical objects, without the range or
.timesoperator. Now, ruby made all of that enjoyable no doubt, but I couldn’t transfer my knowledge of those ruby APIs over to other languages. Shit even ruby abstracts public/private into attr_accessors/readers, and constructors into intialize. You almost never have to import stdlib files in rails, becuase they’re all baked in.
var c string = 'hello'), along with syntactical sugar. Little utilities like their Time hierarchy etc have been a joy to come across.
STD LIB IS SICK!
Overall, I still have a lot to learn about the language of Go, but I’ve had fun writing a few little CLI apps and learning about what real problems I could solve with it. I started taking notes on Go’s 8th birthday, when I realized that was the case. I took it as a sign and committed.
Happy 8th Belated, Go :)
It’s been awhile since I’ve posted something on the blog, and I’ve wanted to fix that. I took some time to reflect on the purpose of this blog and what I’d like it to do. This post details my plans with it moving forward.
This blog and website have always had the purpose of representing me and what I’m working on in technology. While it displays my experience clearly on the homepage, it falls far short of keeping the picture accurate and up to date.
A large part of my free time is gathering research across a wide variety of technology topics. Scattered across a dozen or more areas, I literally have notepads full of potential app implementations, source code reviews, tool evaluations. From esoteric unix tricks to meaningful patterns and practices, it’s there when I need it. Regardless, I wish I would’ve posted that research when I wrote it down, rather than leave it on paper where it’s not programatically accessible.
So moving forward, it’s my intention to post all of my research to this blog and have it serve as the public repository for things I’m learning. Right now that list consists of:
Of course, I’m using ruby/js/vim/bash daily. All of my projects are deployed to AWS. So new research in those areas will always be included.
This post makes it official. Look forward to knowledge!
Recently was running docker containers, and was trying to curl a tar file to unpack a binary.
Ran into the error:
returned a non-zero code: 127
If you’re getting this code, you probably are calling a command that’s not globally available. In my case, I was calling wget/curl – both weren’t installed on the docker image yet.
Just a quick note to self - non-zero code 127 means check your dependencies.
Sometimes you need a quick and dirty way to share a node module. Just ran through this and thought I’d post it.
The easiest way to share a module is via github.
To package your module, set your entrypoint in package.json, and make sure you export the package however you’d like it to be consumed.
Push it up to git like always
To install via cli
npm i git+ssh://firstname.lastname@example.org/<author>/<repo>.git --save
Or add to package.json
This lil post is about a single setting in Vim that you’ll see in just about every modern .vimrc.
“nocompatible” is a mode that I feel most aren’t familiar with, which is seeded in a lack of knowledge on the history of Vim.
Vim stands for Vi (Improved). Essentially all that means is Vim has modern tech built into it, Vi is antiquated and wonky.
Would anyone still prefer vi?
Realistically, they shouldn’t. But plenty of people will have to work with vi day to day, just because their OS or shell can’t (or won’t) run Vi(m).
set nocompatible is described as such in the Vim docs:
This option has the effect of making Vim either more Vi-compatible, or make Vim behave in a more useful way.
You can see all of the the options related to nocompatible here.
Just wanted to illuminate the meaning behind something I see in every .vimrc (including mine), yet most people don’t bother to look up.
Earlier today I was working in a legacy ruby environment, and ran into a system conflict with my local rubies. In short,
libv8 wasn’t installing correctly, and my bundle was broken. This bundler was using
Rake 1.12.5 and
Here’s this problem pretty well documented online:
All of those solutions basically address the sole problem: libv8 version conflicts. But none of them address this through the bundle, all using the gem cli. I needed something I could push to a distributed environment.
The gem failures were based on
therubyracer. I needed to link up the correct system v8 on install.
brew uninstall v8 brew install v8-315
The solutions would lead to tell me something like this:
gem install libv8 -- --with-system-v8 gem install therubyracer -- --with-v8-dir=/usr/local/..
But I needed it via bundle, this I dug into bundler configs.
So to set this up via CLI, heres the command:
bundle config --local build.libv8 --with-system-v8 bundle config --local build.therubyracer --with-v8-dir=$(brew --prefix v8-315)
Which leads to…
--- BUNDLE_PATH: ".bundle/gems" BUNDLE_BIN: ".bundle/bin" BUNDLE_DISABLE_SHARED_GEMS: true BUNDLE_BUILD__LIBV8: "--with-system-v8" BUNDLE_BUILD__THERUBYRACER: "--email@example.com"
Boom… now I am installing legacy versions through bundler.