The letter A styled as Alchemists logo. lchemists
Avatar of Brooke wrapped in a grey scarf and wearing a black jacket with a red zipper against a slightly blurred background of fall colors of mainly orange leaves. Brooke Kuhlmann
Published November 20, 2020 Updated October 10, 2021
Logo
RubyConf 2020

Due to COVID-19, and a rough year for humanity in general, I was looking forward to hanging out with fellow Rubyists even if virtual. The team behind managing and hosting the event did an excellent job in making it a fun and welcoming experience. Kudos!

I’ve been enjoying the virtual format for conferences this year and hoping this becomes more of a mainstay for future conferences. During Slack conversations, people had mentioned taking a hybrid approach where people could attend in person but there would also be a way, for people who couldn’t travel, to also experience the joy of Ruby remotely. I like this idea a lot.

If I had one complaint, I would have wished the service for hosting the event was an all-in-one platform. Instead, you had to jump between multiple services:

  • Crowdcast - Used for streaming both live and pre-recorded presentations. I do have to say I enjoyed being able to rewatch parts of a presentation after it was over since it only took a few minutes to become available. Even better, you could jump over to a track you didn’t attend and catch up on it at double speed. ⚡️

  • Slack - No complaints here. Although, it would have been nice to have the Slack experience embedded within Crowdcast.

  • Zoom - Necessary for some of the workshops and sponsored events. This was unfortunate as I’ve written about my dislike for Zoom before and we should do better as an industry in this regard.

What I was hoping for was more of an experience like Hopin. I had experienced an event on their platform earlier in the year and really loved how you could hop between reception, the main stage, chats, sessions, expos, and other networking activities.

With all of the above said, the following are notes captured from the conference that caught my interest. It wasn’t possible to attend all of the talks live but, as mentioned above, being able to catch up on them after the fact at double speed was a nice bonus. Enjoy and may the following be of use to you.

Talks

For access to all recorded talks, check out the RubyConf YouTube Playlist. Each video is linked to in my notes below where possible. In the case of workshops and/or sponsorships, those sessions were not recorded and I only have my notes to share in those situations.

Opening Keynote by Yukihiro Matsumoto (Matz)

The biggest takeaway from this talk was the emphasis on concurrency becoming more of a first class feature in Ruby.

  • Async Fibers - For I/O heavy tasks.

  • Ractors (Ruby Actors)

    • Uses an isolated object space and limited object sharing.

    • Requires immutable objects.

    • Requires deeply frozen objects.

    • Classes and modules will be shared by default but you will need to handle with care since they can be mutated.

    • Each ractor will have it’s own Global Interpreter Lock (GIL).

    • See Ractor Documentation for further details. Well worth the read.

  • Ruby Signatures

    • Ruby will ship with RBS to support type signatures.

    • IDEs can use these type signatures for code completion.

  • Pattern Matching - Will no longer be an experimental feature in 3.0.0. 🎉

  • Better JIT

    • This might include a multi-layer or lightweight JIT on top of the existing JIT.

  • Macros

    • This would be something like Rust’s macros, for example. Matz mentioned this briefly, so not sure what the full plan is.

Automatic GC Compaction in MRI by Aaron Patterson

Aaron’s talk dives into a his work around GC.compact which was added in Ruby 2.7.0 to move objects around and update references in order to keep memory smaller and well organized. The goal is to make this process more concurrent. I had seen an earlier version of this talk when Aaron spoke at our local Boulder Ruby Meetup group but was nice to watch again in a more polished format. While this isn’t recommended for production, at least not yet, Aaron does recommmend turning this on for your continuous integration builds.

As an aside, Aaron used macOS Instruments to benchmark Ruby. Instruments comes with a GUI tool for digging into the results. Neat.

The Humble Hash by Ariel Caplan

I wasn’t able to attend this talk live but caught up on it after the fact and ended up having a few conversations with Ariel afterwards.

In the talk, he made a good points about using primitives (i.e. String, Symbol, Numeric, etc.) for hash keys which is a good rule to live by. Even an Array or another Hash can work. The important aspect of any key is that object equality must be obvious.

He also mentioned using default values and even the lesser used and powerful default proc for Hash construction:

example = Hash.new "test"
example[:a]  # => "test"

example = {}
example.default = "test"
example[:a]  # => "test"

For default proc support, check out Hash.infinite and Hash.with_default support baked into my Refinements gem or study the source code directly. Hashes are definitely powerful. 🎉

That said, I hadn’t seen this variant where a hash is used for memoization which is worth consideration:

def expensive_cacluation_example(argument)
  @expensive_cacluation_example ||= Hash.new do |a_hash, value|
    a_hash[key] = do_expensive_calculation(key)
  end

  @expensive_cacluation_example[argument]
end

Here’s another variant using instance variables (non-hash):

def extract_fees_by_type(type)
  instance_name = ['@extract_fees_by_type', type.to_s].join('_').to_sym
  instance_variable_get(instance_name) || instance_variable_set(instance_name, fees.select { |fee| fee[:type] == type })
end

Enough Coverage To Beat The Band by Kevin Murphy

Great talk that reveals Ruby’s native Coverage library which powers gems like SimpleCov and Coverband.

See here for presentation notes to learn more.

Improve Your Technical Writing by Noel Rappin

This was a two-hour workshop on technical writing. I’m always eager to get better as a writer and communicate complex subjects in a manner that is easy to digest so was looking forward to learning more in this space. The following are notes from attending the workshop:

  • The reader should always be able to understand something they were unable to do before.

  • Writing is a great way to solidify and provide concrete evidence of your expertise.

  • When writing, you want to communicate in a way that makes ideas travel.

  • Always best to write just after you have learned something and when you still have that learners mindset.

Noel had a suggested process for tackling writing endeavors which is a nice starting blueprint but definitely take the time to explore and deviate as best works for you. Starting with any process helps you unblock and focus. The following focuses on tackling the problem, your perspective, and the reader’s perspective:

  • Problem

    • Be careful not to focus entirely on the solution. You want to illuminate why this is important to the reader.

    • What does the reader already know? Make a list and think about what you can and can’t assume.

  • You

    • What is your goal to get across?

    • What value do you bring to the piece that is unique to your perspective?

    • What makes your perspective different?

  • Reader

    • You are telling a story, like the hero’s journey, where someone doesn’t know how to do something and now comes back with the skills needed to perform the task.

    • You want to set up the problem, goal, and get the reader ready to want to learn how to solve the problem.

    • Each step should build upon the previous step. The trick is doing this well to where the reader is also thinking the same thing right about the same time you reveal the solution.

  • Avoidances

    • Don’t use metaphors in technical writing due to confusing people from different languages/cultures.

The following are examples of technical writing that mix the use of diagrams, charts, doodles, etc. to convey a point along with good writing prose:

The State of Ruby 3 Typing by Soutaro Matsumoto

There are a collection of gems/projects you’ll want to know about to get started adding type checking to your Ruby code:

  • RBS - Provides a language to help you describe the structure of your Ruby programs.

  • TypeProf - Depends upon RBI and helps infer types from your Ruby programs. The documentation is sparse but the idea is you could use this gem as a tool for bootstrapping the addition of types to your Ruby programs.

  • Steep - Depends upon RBI and helps enforce adding type declarations to your programs.

Alternatives

  • Sorbet - This is Stripe’s answer to type checking and will, supposedly, support a subset of RBI.

  • RDL - At first, I had not recognized this gem. Then, after digging through my notes, I remembered I had come across this gem back in 2016. There is even a corresponding Strange Loop Presentation. At the time of this writing, there hasn’t been any further activity or development on this project, though.

Example Implementations

  • Gem RBS - Uses incompatible semantic versioning to provide types for existing gems. This also means the versions defined in this project might not match with the actual gem versions. My initial impression is that this seems a bit kludgey and a potential source of much confusion.

  • Strong JSON - Provides an example of a gem built with type signatures. Pay special attention to the files in the sig folder.

Example Syntax

Generics

Array[Integer]
Hash[String, Array[Integer]]

Unions

String | Symbol
Array[String | Integer]
Integer? # <== Integer | nil

Interfaces

interface _IntegerConvertible
def eval: (String) -> untyped
def to int: ()
  -> Integer
end

Untypes

def eval: (String) -> untyped

Command Line Interface (CLI) Usage

rbs prototype rb lib/**/*.rb
rbs prototype runtime -r goodcheck

It was mentioned that Matz believes type annotations will be outdated in the future and doesn’t want types written in Ruby code. I’m not sure I fully understand what this means, though.

Ruby Performance Q&A by Scout APM

Popped in to check out the Scout APM demo and thought the following features were interesting:

  • Shows each deploy in the timeline.

  • Detects N+1 queries.

  • Shows backtraces and each backtrace is clickable back to the source code.

  • Supports highlighted events which can be sticky across multiple views.

Ractor Demonstration by Koichi Sasada

Ractor, short for [R]uby + [Actor], was previously known as Guilds. With the new name, ractors are meant to provide a solution for concurrency and parallel programing in Ruby by making support easier than it has been in the past (i.e. Threads).

A main performance benefit of ractors in when parallelization requires coordinated communication. In situations, where you already parallelize without any communication, the performance benefit isn’t so clear or at least that was what I was able to gather from the Slack discussions that followed after the talk.

During the chat, Richard Schneeman mentioned the following which is important to note:

If you boot all your processes and load Rails, or you load Rails and then fork your processes, either way you have to wait the same amount of time to boot Rails, the difference is: in one scenario all your cores are doing work and the other scenario only one core is doing work.

It’s also worth noting that the current Ractor implementation is quite strict in that all code must run in a ractor. This also means that attempting to run a Rails controller action in a ractor would be difficult and big leap at the moment.

There was also a question about C libraries being thread safe and this is an important restriction which is being enforced in this Ruby Issue if you want to learn more.

For more on this make sure to check out Koichi’s slides as well as the current documentation on this subject.

Automation Engineering with Serverless Compute by Kevin Lesht

One of the takeaways here was with using Dynamo DB to trigger Lambda events for insert, delete, update, etc. I’m not sure I want to immediately start using Dynamo DB but knowing that there are hooks for Lamda functions is interesting.

The Minaswan::Interview by Jesse Spevack

Jesse’s talk was all about encouraging a kinder interviewing process because Matz is nice, so we should be nice. He spoke from personal experience where he spent ~16 hours of unpaid labor to craft a sample application followed by technical grilling and a whiteboard exercise. I’ve felt that pain before and have no desire to go through that ever again, let alone force that experience upon someone else.

The technical chops of a candidate is one piece of the puzzle but there is so much more to this where the whole process should be a two-way street in which the interviewee and interviewers are on equal ground, evaluating each other through the entire process. The work should be paid too.

Anyway, I’ve written about this at length here. It’s not a short read but sums up what Jesse is trying to achieve and a whole lot more!

Reversibility and Structure by Kent Beck

Kent had a new acronym, MCETMEC, for one of his more popular quotes:

Make the change easy, then make the easy change.

I’m not entirely sure that makes the phrase any easier to remember, though. 😅

During the talk, Kent made several statements which would have been nice to dig into further but I never saw him show up in the corresponding Slack channel:

  • Instead using the term Roadmap in software engineering, use Compass instead since the path is constantly changing and realigning.

  • Code Reviews should consist of behavior changes or structural changes, never both.

    • Structure changes can be fast tracked.

    • Behavioral changes require a bit more inspection and are slower to process.

  • Our tools should be focused on latency instead of throughput. In other words, how can we get the quickest feedback when developing software so our thought process isn’t interrupted. We need seconds, not minutes, to maintain that flow.

Make sure to check out the presentation when it’s posted as much of what he discussed sounds like it’ll be captured in future book he’s been working on.

Upgrading GitHub to Ruby 2.7 by Eileen Uchitelle

You might already be aware of this, because this has been mentioned in Ruby Issues, and elsewhere but one outcome of this work was an enhancement to Warning#warn to allow categorization. For more on this, check out Eileen’s slides.

The best part of this talk, at least for me, was the corresponding Slack discussion where I learned from Yusuke Endoh that you can use colorized/editable IRB without having to set this in your .irbrc:

IRB.conf[:USE_READLINE] = true

By removing/disabling the above line, you can install the following and immediately make use of the IRB multi-line/edit feature:

gem install reline irb

It also helped that the gem author of Reline published a new version as we were chatting to make the above possible. I’ve been wanting this for nearly an entire year from when Ruby 2.7.0 was first released last December!

Coaching Through Coding by Mercedes Bernard

This was a solid presentation and I liked her breakdown of mentorship and coaching. Her slides are here if interested.

There were some great Slack discussions around this talk on topics such as Git Commits, Git Linting, Code Reviews, and more. I’m linking to my content since I’ve spoken on this often in the past which is a slightly different flavor of what Mercedes was speaking about but I have a lot of experience on this subject as well.

Mach 2.0 at Scale by Nickolas Means

Nickolas wasn’t able to his regularly scheduled talk so fell back to a previous talk that was still enjoyable to watch a second time. Forcing yourself to step away from the grindstone and zoom out to the bigger picture is good advice. We could all benefit from doing this more.

Closing Keynote by Aniyia Williams

Inspiring and highly motivational way to end the conference. Really enjoyed her talk and her Five Rules which tie in well with the Oath, Mission, and Values of this site:

  • Fuck the status quo.

  • Reshape the role of markets.

  • Design with human nature in mind.

  • Seek to minimize harm to others.

  • Figure out what part you’ll play.

We all know the world is quite broken now and her notion of Compassionate Capitalism is a nice way to frame how to move forward. There is way more to this than what I’ve captured here so I strongly encourage you to check out her slides to dive deeper. I know I’m going to be spending quite a bit of time digging into her resources.

Random Learnings

While hanging out in the various Slack channels, I stumbled across random learnings that I’ve collected below in case they are interest.

  • Roundsy - During the first day of the conference, a dedicated channel and event room was set up for people to randomly gather and meet each other. In the past, I’ve been a bit skeptical of services like this (i.e. Slack Donut) which have yielded a less than pleasant experience to say the least. With Roundsy it was fun to meet people before and after the the conference because you’d be randomly thrown into a pool of people for ~15 minutes which is a nice amount of time chat. At time’s end, you’d be immediately bounced to a new group of people. I couldn’t help but think this would be a great way to setup office hours so-to-speak where people on your internal team could know to hang out and meet more people in the company as a whole. It was a nice experience and I recommend checking it out for yourself. It is currently free to use.

  • iruby - Provides an in-browser REPL loop for Ruby presentations and live illustrations. You might want to check out this example to understand more.

  • Rubyist - Currently in Beta but allows you to write Ruby that will run on iOS which is built on top of mruby and a few other gems.

  • Ruby Next - A transpiler and a collection of polyfills for supporting the latest and upcoming Ruby features (APIs and syntax) in older versions and alternative implementations. Supports mruby too. I’m a bit sad this exists because supporting legacy software leads to bad working environments, burning money on expensive consultancies to fix what these teams neglected, slower adoption of new ideas/patterns, etc.

  • Slack’s Conversations API - Learned, in a side channel, that Slack is deprecating their Events API in favor of the Conversations API which appears to have outstanding issues.

  • Thinking Shop - A shop and site for getting you to think outside of logical fallacies, bias, etc.

  • SA Ruby Coders - A Ruby meetup in San Antonio, TX that might be looking for speakers.

  • Ruby User Group Berlin - A Ruby meetup in Berlin, Germany that might be looking for speakers.

Conclusion

I always walk way from every conference I attend full of new ideas and this one was no different. I’ll be digesting and processing all of the above in weeks to come. Not to mention preparing for the Ruby 3.0.0 release this Christmas!

Oh, and RubyConf is going to be hosted in Denver, Colorado next year. 😉