I spend a lot of time on the command line, working with Unix commands. (If you don’t, you can check out my talk Practical Unix for Ruby and Rails). Over the years, I have configured and tweaked my shell to my liking. Most unix configuration is done in “dotfiles”, which are configuration files read by Unix utilities, usually residing in you home directory and named with a
.in front, from which their name is derived.
It turns out that at the top our bash scripts we should be using
#!/usr/bin/env bashinstead of
#!/bin/bash. Jump the link for a good explanation on the UNIX specifications involved.
Steven Leiva writes a supervisor from scratch. I find these king of pieces very useful. They de-mystify some of the technologies, explore what is under the hood and end up enhancing my understanding, making future use much easier.
Last month, I mentioned another article by Richard Schneeman. Now, he is back with another in-depth, nuanced post about how to handle deprecations in libraries. Especially useful for library authors and mantainers, but good knowledge in general. The whole community gains when there are clear conventions around versioning, deprecation, support, etc. @schneems is doing a great service with his recent articles.
Richard Schneeman, writes a well though out post on library versioning. He previously wrote about Semver and now continues on that vein with how it applies in practice for library authors and users. The key take-away is that adhering to Semver and the widespread use of optimistic locking can alleviate a great deal of the pain of maintaining and upgrading dependencies for projects.
Internet security is fascinating. I have read advise that before using
curlto download a file and piping directly to
bash, you must ensure that you know what you are downloading. However, as this post proves, looking at the URL in your browser is not enough. By using a clever trick to detect how data is being pulled from a server, an attacker can present different content when URL is being downloaded and piped to
bash. Security is hard. Really Hard.
Author’s thoughts on what a project’s log of commit messages are: A history of why the code in the repository is the way it is. For the reasons outlined, I prefer never to squash commits when merging.
Zach Holman writes and in-depth post about software deployment, based on his experience at Github - well known for their automated and frequent deployments to their production environment. Most of what is covered is applicable for web applications, but some of the concepts carry over to device applications.
In this post, Joël Quenneville distills the basics of how the core
gitinternals work. In order to illustrate, he reimplements in Ruby the basics of git: Initializing a repository, staging files and committing. This is a case of where powerful abstractions can compose to create a software system with capabilities seemingly far greater than the building blocks it relies on.
In his usual thorough way, Pat Shoughnessy once again explores the internals of PostgreSQL. In this post, he explores how tweaking the configuration has dramatic effects on specific query performance, but doesn’t come for free.
Aaron Patterson, aka tenderlove, knows ruby. He is both a ruby-core and a rails-core member and works on multiple other gems, like Nokogiri. In this post, he explores in depth several techniques he uses for debugging. Getting insight into a running program is a great skill to have. This article will surely teach you more than one trick.
A great introduction to the Erlang (and by extension Elixir) philosophy on how to construct fault-tolerant, highly available systems. If you have never seen a line of Erlang, fear not: After reading this comprehensive article, you still won’t have.