Ylan Segal

Managing Versions With Asdf

Three years ago, I switched my ruby version manager from rvm to rbenv. Since then, I’ve been using rbenv without complaint. It just works. I now find myself working on more complex projects, that needs specific version of Ruby, Elixir, Postgres, Terraform and others.

asdf bills itself as an extendible version manager. It has support for every tool I’ve needed to install (so far!). It has an extendible plugin system, for those that want to add even more tools. The asdf-ruby plugin is very similar to rbenv, and uses ruby-build under the hood to install rubies. So far, I haven’t had any issues.

Currently, I am using the following plugins:

$ asdf plugin-list

Each plugin manages it’s own versions:

$ asdf list ruby

Selecting versions can be done either with .tool-versions file, on a per-project basis:

# .tool-versions
erlang 21.0.9
elixir 1.7.3

or through environment variables:

$ export ASDF_KUBECTL_VERSION=1.10.3

It has support for traditional (or legacy) version files like .ruby-version, but I have yet to enable it.

A nice touch is that if a .tool-versions is present, asdf will install any missing tool, if needed:

$ asdf install
erlang 21.0.9 is already installed
elixir 1.7.3 is already installed

So far, I’ve found asdf a great way to manage complex dependencies on a per-project basis.

The REPL: Issue 50 - September 2018

How to teach yourself hard things

Julia Evans writes a great article on how to learn… to learn. In her traditional straight-forward fashion, she describes the method she has used to learn things that are difficult. She breaks the process down into approachable skills that anyone can learn (e.g ask questions, have confidence in your knowledge). I also recommend following her on twitter. She posts comics often about unix tools: I always learn something knew from them.

Distributed Agreement on Random Order – Fun with Lamport Timestamps

If you’ve ever done some digging into distributed computing, you will have heard of Lamport Clocks. In this post, Quentin Duval, details step by step on how to construct an application that uses Lamport’s algorithm for reaching agreement on the order of events across a distributed system.

Upgrading GitHub from Rails 3.2 to 5.2

Working as a Rails developer, I’ve found myself a few times in the same situation GitHub was: Relying on an old version of a framework that has now become a liability, and upgrading is anything but straight forward. In this post, Eileen Uchitelle describes the strategy that GitHub used to upgrade. I especially like the section about lessons learned: It’s one of my favorite things about the software community. The willingness to share with others allows us to learn from each other. Thanks Eileen!

The REPL: Issue 49 - August 2018

Cost of a Join

Brian Davis writes a detailed post of how expensive it is to do join queries in postgres. The details are very interesting, as is the conclusion: Join operations are usually cheap.

Elixir: a few things about GenStage I wish I knew some time ago

I’ve recently started working on an Elixir project that seems perfectly suited to use GenStage. In this article Andrei Chernykh complements the GenStage documentation and explains how to use it in an approachable manner.

What they don’t tell you about event sourcing

Hugo Rocha writes about the pitfalls of using event sourcing. Like most engineering techniques, it is not a perfect fit for every situation. In fact, I believe event sourcing is a sufficiently different paradigm to traditional CRUD applications that it makes it difficult to approach in a iterative manner that other techniques can be incorporated into existing systems.

Why JWTs Suck as Session Tokens

Randall Degges writes a good primer on what JWT tokens are, what security guarantees they give, and what problem they are a good solution for. Namely, using them in distributed systems to reduce inter-service calls to verify authentication (or other claims). As the title not-so-subtly suggests, they are not great as session tokens. Most web frameworks already have this problem solved. There is no need to re-invent wheels that are rolling just fine.

On Taking Notes

For over a year now, I’ve started taking methodical notes as I go about my daily work as a Software Engineer. I find the process worthwhile.


As I work on my daily tasks, I keep a note with my current plan and findings along the way. The very act of writing things down forces my thoughts to be more concrete. Putting my thoughts into words makes my assumptions explicit, often resulting in illuminating any gaps in reasoning. I find this is very similar to “rubber ducking”.


Taking good notes makes it easier to find the at a later time and use as reference. I find that there is no need need for specific tagging and organizing. Simple text search (grep) is enough to find previous content quickly. I find that I now regularly rely on being able to go back to my previous notes.


When learning new tools, writing down specific instructions, CLI commands, etc helps cement the new knowledge. My preferred style of learning usually a mix of learn-by-doing enhanced by documenting the steps I took.

How I Take Notes

  • Markdown: I prefer a plan text format. I favor markdown because of it’s simplicity and support for code blocks with syntax highlighting and checklists. It’s also becoming ubiquitous in many tools I use.
  • Atom: My current editor of choice. A few plugins make it particularly useful: pipe for executing against external commands, wikilink for lightweight linking between notes.
  • Synching: My notes are regular files, so they can be synched with any service (eg. Dropbox, iCloud, etc). I usually don’t need my notes on my phone, but those services makes them available when I do.
  • Daily Note: I usually start a fresh notes each day. It’s like a dashboard of all the things I have going on. It’s pre-populated with the items from the previous workday that were not completed (in Franklin Covey style). It serves as a scratchpad too. I link to notes that are more in depth for specific projects or tickets.
  • Weekly Note: At the end of each work week I conduct a personal retrospective and write down my thoughts. It helps with keeping a big picture of what I am working on and my effectiveness at work.

I’ve found that t first taking lots of notes felt tedious. Now, I feel that it’s very helpful to my daily tasks. I recommend it!

The REPL: Issue 48 - July 2018

Web Architecture 101

The world-wide web is built on top of many abstractions. That is what makes it powerful. As a user, we are typically just concerned with a browser and a “site”. When I first started programming for the web, I learned about HTTP, request and responses. Sometimes, one needs to dig deeper into common architecture patterns. In this article, Jonathan Fulton covers some of that architecture: DNS, load balancers, web and application servers, databases, caching. I found it to be a very useful reference. Note: As is always the case with computers, there are more levels of abstraction to learn: TCP, IP, UDP, TLS, etc.

Scaling the GitLab database

Yorick Peterse discusses some of the scaling issues that GitLab went through and how they resolved them. I find these type of articles very enlightening. Both for the solution they chose and for those that they discarded: Your particular scaling problem might look different, making one of those solutions more attractive.

Queries on Rails - Showcasing Active Record and Arel

Pedro Rolo discusses how to go beyond basic queries with ActiveRecord and Arel. I personally use techniques similar to the ones outlined in the article often. Caution: Arel is considered private API by Rails maintainers. If you decide to use it, there might be some work needed to ensure your code works when upgrading Rails. I’ve never had a significant problem with that, provided that I have good tests around complex queries. I much prefer Arel to using long and complicated sql fragments as strings. I believe those are even more brittle.