Ylan Segal

The REPL: Issue 52 - November 2018

Datomic: Event Sourcing without the hassle

I’ve never used datomic, but I’ve seen many references to it, especially when reading about event sourcing. In this article, Val Waeselynck explains at length why Datomic is better suited to fix the pain of doing event sourcing with traditional databases. I found it very interesting, even if I am not doing any event sourcing or considering Datomic.

Post-REST

In this post, Tim Bray expands on what he thinks that industry is moving to, to address REST shortcopmings (e.g. latency, coupling, short life).

  • Winners: Messaging and Eventing, Orchestration, and Perssisten Connections.
  • Losers: GraphQL, and RPC.

Building SQL expressions with Sequel

Janko Marohnic compares the ruby libraries ActiveRecord to Sequel. They are not strictly equivalent, but I believe the comparison is fair because they both provide a way to interact with a database. I found Sequels syntax very appealing. Duly noted for future use.

Let's Encrypt and NearlyFreeSpeech.NET

At the time of this writing, this blog is hosed on NearlyFreeSpeech.NET, and delivered securely over TLS with a certificate from Let’s Encrypt. I previously wrote about how I obtained the first certificate and how to renew it. The process is now even easier, because NearlyFreeSpeech.NET automates the setup and renewal for it’s members.

The process could not be simpler:

  1. ssh into your account
  2. Run tls-setup.sh
  3. Profit!
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
$ ssh YOUR_USERNAME@ssh.phx.nearlyfreespeech.net
# ...
[\h \w]\$ tls-setup.sh
Creating base directory for Dehydrated.

To use Let's Encrypt you must agree to their Subscriber Agreement,
which is linked from:

    https://letsencrypt.org/repository/

Do you accept the Let's Encrypt Subscriber Agreement (y/n)? y
# INFO: Using main config file /usr/local/etc/dehydrated/config
+ Generating account key...
+ Registering account key with ACME server...
+ Done!
# INFO: Using main config file /usr/local/etc/dehydrated/config
 + Creating chain cache directory /home/private/.dehydrated/chains
Processing ylan.segal-family.com
 + Creating new directory /home/private/.dehydrated/certs/ylan.segal-family.com ...
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting new certificate order from CA...
 + Received 1 authorizations URLs from the CA
 + Handling authorization for ylan.segal-family.com
 + 1 pending challenge(s)
 + Deploying challenge tokens...
 + Responding to challenge for ylan.segal-family.com authorization...
 + Challenge is valid!
 + Cleaning challenge tokens...
 + Requesting certificate...
 + Checking certificate...
 + Done!
 + Creating fullchain.pem...
 + Installing new certificate for ylan.segal-family.com...
INFO: Enabling TLS for ylan.segal-family.com
e5: OK (ylan.segal-family.com)
e6: OK (ylan.segal-family.com)
e1: OK (ylan.segal-family.com)
e4: OK (ylan.segal-family.com)
e2: OK (ylan.segal-family.com)
e3: OK (ylan.segal-family.com)
OK: Setup was fully confirmed.
 + Done!
Adding scheduled task to renew certificates.
success=true

That is it! No more manual certificate renewal. Thank you NearlyFreeSpech.NET!

This is a great example of how far we’ve come. It used to be very expensive to have a TLS certificate for a small website, because of the cost of the certificate and the usual extra hosting cost to use TLS. The renewal process was complicated as well. Let’s Encrypt has changed that: It is now free to obtain a certificate. They are shorter-lived than traditional certificates, which in turn makes them more secure by requiring renewing often. They have also invested in an API and tooling to make it easy to setup and automate renewal, so that more of the internet is now encrypted. Thank you Let’s Encrypt!

The REPL: Issue 51 - October 2018

The Architecture No One Needs

Greg Navis discusses why he thinks single-page applications (SPAs) are almost always worse than traditional, multi-page web application. I tend to agree: Most of the time, it adds engineering complexity for not much benefit. I think this is particularly the case when using Elixir and Phoenix, since their performance is spectacular. Phoenix Channels already provide a way for updating content on a page without reloading, and the upcoming Live View promises to make it even better.

Elapsed time with Ruby, the right way

This post by Luca Guidi explains with great detail how calculating elapsed time in Ruby can have it’s pitfalls. The TLDR:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
## Don't do this:

starting = Time.now
# time consuming operation
ending = Time.now
elapsed = ending - starting
elapsed # => 10.822178


## Do this:
starting = Process.clock_gettime(Process::CLOCK_MONOTONIC)
# time consuming operation
ending = Process.clock_gettime(Process::CLOCK_MONOTONIC)
elapsed = ending - starting
elapsed # => 9.183449000120163

Automate Repetitive Tasks with Composed Commands

In this post, the [[Atom]] team explains how you can create composed commands from existing commands already available in your editor. This feature seems great for automating tasks. I haven’t composed any commands of my own just yet, but I think this is a great addition.

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:

1
2
3
4
5
6
7
8
$ asdf plugin-list
crystal
elixir
erlang
kubectl
postgres
ruby
terraform

Each plugin manages it’s own versions:

1
2
3
4
5
$ asdf list ruby
  2.4.3
  2.4.5
  2.5.1
  2.5.3

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

1
2
3
# .tool-versions
erlang 21.0.9
elixir 1.7.3

or through environment variables:

1
$ 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:

1
2
3
$ 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!