Nathan Kleyn

Scala by day — Rust, Ruby and Haskell by night. I hail from London.

Hi! I currently work for Intent HQ as Head of Engineering, writing functional Scala by day and Rust by night. I write for SitePoint about Ruby, and I’m on Twitter and on GitHub. You can get in touch with me at mail/at/

10 Things, 1 Year

01 Jan 2016

As a personal challenge to myself, I am going to set myself 10 goals to achieve this year. As we all know, goals are nothing if you don’t set them in stone, so without further ado:

  1. Blog more. Start blogging regularly, and writing for personal enjoyment. Being a better writer makes you a better coder, so embrace it.
  2. Read more. You picked up some books in the later half of last year that have collected dust for some time. Keep up the reading and get back to the old days of reading quietly before bed instead of staring at a screen!
  3. Keep learning more about functional programming. You’ve come a long way and are doing functional programming every day at work and at home. Don’t stop learning: keep looking into new things, and discovering more about the theory behind it.
  4. Do more with Rust. Rust changed everything by challenging the notion that a programming language had to be slow to be safe. Keep writing open source projects in and learning about Rust as often as possible.
  5. Double down on Haskell. Haskell is an amazing language, try to write more with it.
  6. Attend some meetups. Try to attend some programming meetups, perhaps about Rust, Haskell or functional programming!
  7. Start writing creatively again. Once upon a time you used to write for fun, but the pen
  8. Geocache more! Try to find more geocaches this year than last and in the process discover places you would never have found otherwise!
  9. Spend more time with your family. Make sure they know how much you love and care for them, and how important they are to you. Don’t get carried away working or studying and forget to find time for them.
  10. Marry the most amazing girl in the world, Kitty. In July, you’ll say your vows — make the most of it, and make sure she knows how happy she’ll make you for the rest of your life.

Our CI and Builds at Intent HQ

03 Mar 2015

I gave another presentation, this time on how we tackle CI and builds at Intent HQ! The slides are available on Speaker Deck as always!

Distributed ID Generation

25 Feb 2015

I presented a talk on distributed ID generation using Redis Lua scripting as we do at Intent HQ! The slides are available on Speaker Deck and we’re planning on open-sourcing our implementation from Intent HQ soon!

In the meantime, you might find this useful as a guide on the theory and ideas behind generating unique IDs in a distributed fashion.

Using The Lazy Enumerator In Ruby

20 Feb 2015

Recently, I’ve found myself starting to use the new Ruby 2.0 lazy enumerator feature quite a bit. I’d written about the lazy enumerator feature in the past, but had previously never found much time to use it, what with backwards incompatibilities and all making it difficult to use this in production code.

I’m finding there are two main circumstances in which I’m using this feature:

Speeding up multiple iterations

In versions of Ruby without the lazy enumerator, sometimes you have to suffer the penalty of multiple iterations because you need to use multiple enumerator methods:

def do_some_stuff
    .flat_map { |x| do_something(x) }

With a two line sprinkle, you can dramatically change the performance characteristics of this code:

def do_some_stuff
    .flat_map { |x| do_something(x) }

Now you’ll only suffer a single iteration of some_stuff, which can add up to a massive saving if that enumerable object ever gets large! Obviously, the laziness does add a performance penalty, so you need to exercise caution and add the lazy enumeration only when the number of iterations justifies its usage.

Cleaning up code large enumeration blocks

I often find myself wanting to refactor code that does a lot in a single enumeration block, but often refactoring this out to methods can be overkill. Take for example this (extremely contrived) example: { |x| x % 3 == 0 && x % 4 == 0 && x.to_s.size < 5 }

You can end up with this pretty gross “one block to rule them all” style code easily by simply trying to avoid the cost of iterating. This code is but a small taste of the size of some blocks I’ve seen out there, and it can make code hard to read when you try to make one block do too much work.

Enter the lazy enumerator:

  .select { |x| x % 3 == 0 } # Nums divisible by 4
  .select { |x| x % 4 == 0 } # Nums also divisible by 3
  .select { |x| x.to_s.size < 5 } # Nums less than 5 digits long

This gives you an opportunity to refactor your code to do a single thing per line, and do it tersely. You also have the ability to be able to comment each line as you need without introducing local variables, leading to cleaner and more readable code.


In any code where you can use Ruby 2.0+, consider using the lazy enumerable for these use cases. You may find it leads to cleaner, more readable code - and it some cases a hefty performance gain!