RubyConf 2020
RubyConf 2020 | Alchemists

  


  
    
        

        
          


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.

Table of Contents

Talks

Opening Keynote by Yukihiro Matsumoto (Matz)
Automatic GC Compaction in MRI by Aaron Patterson
The Humble Hash by Ariel Caplan
Enough Coverage To Beat The Band by Kevin Murphy
Improve Your Technical Writing by Noel Rappin
The State of Ruby 3 Typing by Soutaro Matsumoto
Ruby Performance Q&A by Scout APM
Ractor Demonstration by Koichi Sasada
Automation Engineering with Serverless Compute by Kevin Lesht
The Minaswan::Interview by Jesse Spevack
Reversibility and Structure by Kent Beck
Upgrading GitHub to Ruby 2.7 by Eileen Uchitelle
Coaching Through Coding by Mercedes Bernard
Mach 2.0 at Scale by Nickolas Means
Closing Keynote by Aniyia Williams


Random Learnings
Conclusion



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.



Will require a scheduler for switching between fibers.


Does not use multiple cores.


Light-Weight Scheduler Issue


Ruby
Concurrency Final Report





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




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:



Julia Evans - Been a reader for a while and does have lots of quirky
illustrations that accompany what is being learned. Most relevant to the above, is
how do you
write simple explanations without sounding condescending?


Maggie Appleton - An inspiring site that uses illustration to
better explain technology, anthropology, and programming concepts.


Science
Fiction Books - This was suggested as books that do a good job of getting the technical aspects
right.





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.



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.



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:

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. 😉



💡 If you've enjoyed what you've learned here, consider hiring us because we can bring decades of software engineering experience, solutions, automation, and much more to your team. 🚀

        
      
  

  

