Ylan Segal

Don't Rescue RuntimeError

I came across some code recently that attempted a long series of steps, and on failure issued a notification. Something functionally similar to:

1
2
3
4
5
def complicated_method
  # Several calls to things that can raise
rescue RuntimeError => ex
  notify_failure(ex)
end

At first instance, this seems appropriate. After all, Ruby defaults to raising a RuntimeError when not using a more specific exception:

1
2
3
4
5
6
7
def boom!
  raise "Hell"
rescue => ex
  ex
end

boom! # => #<RuntimeError: Hell>

There is a subtlety here: Ruby default to raising a RuntimeError, but defaults to rescuing a StandardError. A RuntimeError has a StandardError as an ancestor, which means that any RuntimeError will be rescued from a “naked” raise. However, when we specify RuntimeError as the rescue clause, we might miss a lot of exceptions that we thought we were rescuing, because they don’t have RuntimeError as an ancestor.

1
2
3
4
RuntimeError.ancestors # => [RuntimeError, StandardError, Exception, Object, Kernel, BasicObject]
ArgumentError.is_a?(RuntimeError) # => false
IOError.is_a?(RuntimeError) # => false
TypeError.is_a?(RuntimeError) # => false

Conclusion

When possible, always rescue specific exceptions, to avoid supressing exception. Failing that, rescue StandardError, not RuntimeError. Oh, and don’t rescue Exception.

The REPL: Issue 53 - December 2018

Scaling engineering organizations

Raylene Yung at Stripe writes a detailed post about how to scale engineering organizations. Although in my current role I am not a hiring manager, I find these types of posts very useful for future reference and to see what hiring looks like from the other side. Understanding the system allows you to use it for your benefit.

PostgresSQL: Implicit vs. explicit joins

Hans-Jürgen Schönig writes an excellent technical explanation of implicit vs. explicit joins in Postgres. It mostly jives with my experience: For the most part, the query planner will ensure that the performance is the same. When writing SQL directly, I prefer to use explicit joins. I believe they are more readable.

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.