-
The REPL: Issue 41 - December 2017
Trying to Represent a Tree Structure Using Postgres
Pat Shaughnessy writes a great 5 part series on using tree structures inside Postgres to store hierarchical data. In this first post he covers on why using a tree structure makes sense. In later parts he will cover the basics of the LTREE extension, how to install and use it and how it hooks into the Postgres internals.
Building a Distributed Log from Scratch
Brave New Geek writes the first part of a promised series on building a distributed log from scratch. in this post he focuses on storage mechanics. If you interested in why using a log is a good abstraction for distributed systems, see the referenced article The Log: What every software engineer should know about real-time data’s unifying abstraction.
Distributed systems for fun and profit
Mikito Takada writes a short e-book about distributed systems at a high level, covering scalability, availability, performance, latency and fault tolerance. The implications of different levels of abstractions, time and ordering and different modes of replication are part of the fun. Warning: After reading you might find yourself going down the rabbit hole resaearching Vector Clocks and CRDTs (convergent replicated data types). See you there.
-
The REPL: Issue 40 - November 2017
Redis Streams and the Unified Log
In this article, @brandur writes about the unified log concept and how to use Redis streams (coming soon) to build a foundation for a unified log. He covers what a unified log is good for, compares it to Kafka and provides code examples that tie everything together. This is great quality writing. I highly recommend you read the other articles on his blog. They are worth it.
CLIs are reified UIs
This articles provides some perspective about CLIs vs GUIs. The author makes a convincing argument, that CLIs make the interaction with the computer clearer, because they are more visible. This brings easier interaction because of the ability of copy, pasting, editing and so on.
Brilliant Jerks in Engineering
Brendan Gregg breaks that the implications of having a brilliant at engineering team member that is also a jerk. He breaks down the jerkiness into selfless and selfish. The post is thorough and found myself nodding along to many of the described behaviors and the problems that they cause.
-
The REPL: Issue 39 - October 2017
Floating Point Visually Explained
Sooner or later every software engineer runs into issues with floating point arithmetic precision. Fabien Sanglard explains how floating point numbers are stored and how the approximate real numbers. The post talks specifically about numbers in C, but the lesson is applicable generally.
API design: Choosing between names and identifiers in URLs
Martin Nally covers the ins and outs of using human-readable names or ids in URLs. Both have their place, even in the same systems.
10 new features in Ruby 2.5
Ruby 2.5 is expected to be released this Christmas, like it always does. Here are a few new features that will be included. There are no major changes. The language is relatively mature now and the core teams seems to be focused on performance improvements.
-
Pipe Atom Text Into Any Command
On my day-to-day software engineering tasks, I sometimes have the need to pass the file or selection through another program and replace it with the output. The uncomfortable workflow on my Mac is:
-
The REPL: Issue 38 - September 2017
Developing with Kafka and Rails Applications
In this article, Sam Goldman gives an overview of how Blue Apron uses the
ruby-kafka
gem to produce and consume Kafka topics from Ruby. In addition, he shows how to leverage docker and docker compose to create a local development environment, which would otherwise be relatively complex since it needs 4 different supporting services (zookeper, Kafka broker, a schema registry and a REST proxy).Introduction to Concurrency Models with Ruby
This post (part 1) and it’s follow-up (part 2) explain the different ways to work with concurrency in Ruby. It covers Processes, Threads, the GIL, Fibers and more abstract models like Actors, Sequential Processes, Software Transactional Memory and the new proposal for concurrency in Ruby: Guilds.
Using Atomic Transactions to Power an Idempotent API
@brandur writes a detailed post on how to treat HTTP API requests as transactions and build them in a way that they are idempotent – they can be called multiple times, without affecting the result. The author does a great job of covering the database, MVC framework code and even how to work with background processes. The diagrams illustrate elegantly how race conditions can occur and how to mitigate them.