The letter A styled as Alchemists logo. lchemists Syndication Icon

Putin's War on Ukraine - Watch President Zelenskyy's speech and help Ukraine fight against the senseless cruelty of a dictator!

Published November 15, 2021 Updated December 4, 2021
Logo
RubyConf 2021

This year’s conference took place at the Denver Convention Center which was a hybrid of virtual and live presentations versus last year’s virtual only conference. In terms of travel, I opted to commute via bus which worked out well and turned out better than I had thought.

The following are notes from the conference that I thought were interesting but definitely not comprehensive. With so much content being presented at the conference, it is always difficult to catch everything. I am definitely looking forward to catching up on what I missed once more of the live presentations are posted online.

Talks

The great thing about a hybrid — especially a virtual — conference is that you can catch up on what you missed via the streamed recordings. While the live talks are not online yet, the virtual talks are so many of my notes in this section center around the virtual talks.

Async Ruby by Bruno Sutic

This is a virtual talk which touches upon some capabilities of the Async gem. Async is the basis of several related gems around asynchronous I/O. For example, I use Async to build this site since I pull information from several third-party integrations which speeds up the build process in order to deploy site updates.

This is a great talk if you’ve not been exposed to any of this information yet. It also sounds like this gem has been pitched for inclusion into Ruby which would be neat.

Parallel testing with Ractors: putting CPUs to work by Vinicius Stock

This is a virtual talk which explores using Ractors for speeding up your test suite. Ractors are still experimental but this talk uses them for test suite parallelization purposes. If you’ve not been playing with Ractors this talk might provide additional exposure for you.

Ruby’s new debug functionality by Koichi Sasada

This is a virtual talk on Ruby’s new Debug gem and has been a favorite tool of mine for several months. The Debug gem is part of the Rubysmith gem and I was planning to add it to the Gemsmith gem too but sounds like the Debug gem will be bundled as part of the Ruby 3.1.0 this Christmas which is nice to hear. That said, this gem is still under active development and doesn’t support Ractors yet.

Included in the Debug gem is rdbg which can be used for remote debugging. I’ve not made use of this yet but need to. Generally, I use Debug in combination with Overmind when running Rack-based apps locally but you can use rdbg to debug applications/scripts without prior breakpoints being set which is useful.

There is a quite a lot to learn and level up when using this gem. For example, here’s a snippet where you can use breakpoints to trace through code:

binding.break do: `trace line`
my_message
binding.break do: `trace line off`

I’d encourage you to add the Debug gem to your own projects and check out the product documentation for further information.

Enjoy Ruby Programming in IDE and TypeProf by Yusuke Endoh

This is a virtual talk which delves into the TypeProf for building type definitions of your Ruby code. I found this chart from Yusuke Endoh’s talk quite helpful:

Performance matrix

Of all gems, TypeProf has the strongest type inference but is also the slowest. More work is scheduled for improving speed, though.

Control methods like a pro by OKURA Masafumi

This is a virtual talk which focuses on the power of methods as objects. Good talk if you’ve never metaprogrammed before, dynamically defined a method, replaced a method, or even removed a method. Unfortunately, he makes use of the Tiny Hooks gem which introduces callbacks to methods within your Ruby objects. The implementation is fun to check out but making use of this gem within your own code has me worried since callbacks introduce side effects and side effects are hard to debug, test, and maintain. If you’ve ever worked with ActiveRecord, or with teams that have gone wild adding callbacks to all kinds of models, you’ll know how damaging this practice is. That said, knowing how to manipulate and work with methods abstractly is a good skill to have.

Harness the power of functions to build composable rack apps by Marc Busqué

This is a virtual talk which focused on the WebPipe gem that plays well within the Dry RB and Hanami ecosystems. Check out the project documentation for examples. Enjoyed this talk as well.

Using Monads for elegant error handling by John Gallagher

This is a virtual talk on using monads in your Ruby code and is mostly a high level overview. Definitely worth checking out if you’ve not used monads before and focuses specifically on the Dry Monads which I highly recommend using in your own code.

How to Make a Gem of a Gem by Justin Searls

This is a live talk on building gems. I’ll cut to the chase and say you should ignore this talk entirely. What hurts the most about the content of this talk is seeing a prominent figure in the industry promote bad practices. This hits especially close to home for me because I’ve been a gem maintainer for over a decade now, plus I’m the author of the following meta gems:

  • Rubysmith - A gem for smithing new projects.

  • Gemsmith - A gem for smithing new gems.

Gemsmith is also a decade old as well but still well maintained. In fact, I’m working on another major release of this gem. Anyway, both of the above projects are more advanced, feature rich, and customizable than anything Searls is talking about. Even better, they both promote and teach you about good design and coding practices.

How GitHub uses linters by Joel Hawksley

This is a live talk I wanted to attend in person but overlapped with the RuboCop workshop I attended instead. As Joel points out in his talk, I agree that you’d get more in depth knowledge by checking out the workshop (I talk about it more below as well). What I do like about this talk is, at the end, when Joel emphasizes the power of linters for letting the bots automate the mundane and tedious so that the code review process can focus on a deeper understanding of the architecture and general direction of the application being developed. Here is my article on code reviews for even greater detail on why this is important.

Joyful Polyglot: Beautiful insights from many languages by Nick Barone

This was one of the few live talks I was able to attend and also the worst. I was so disturbed that I ended up being one of the audience members that pushed back on many of the topics covered in the talk. I also spoke to Barone after the talk to explain where I was coming from and why this is important to get right, especially for those new to Ruby.

The most important aspect of being a polyglot engineer is that you always level up and fold in the best of what each new language gives you into your language of choice. This is how you can solve new and old problems in elegant ways. This talk wasn’t about that at all despite the misleading title. It was more about misguided patterns used in the worst possible way in Ruby. I’ll give a few examples:

  • He used classes without any constructors so there wasn’t any data or state being encapsulated.

  • He used and promoted class variables which are dangerous and even recommended to be avoided by the Ruby core team.

  • He used procs and lambdas within methods as a way to have a collection of methods which could be used as functions but there is an expense to doing this because behavior isn’t being injected and can’t be easily swapped out. Worse, procs and lambdas are amongst the most expensive objects to create when compared to other core classes. Plus, the methods wrapping these procs and lambdas have no connection to the object in which they were defined.

  • He used Method#curry which is definitely a fun way to partially compose functions but Ruby can’t optimize for it and, if used in a hot code path, can be quite expensive in terms of performance.

💡 Much of the above, and more, is written about in my Ruby Antipatterns article so you can follow the link to learn more.

In addition to the above, many of the slides rapidly breezed through the patterns and code snippets discussed without fully explaining what his methodology was for deconstructing them in the first place. I had a hard time keeping up and tracing through what he was explaining. Others I talked to afterwards said the same thing. One person even came up to me after the talk and thanked me for calling Barone out so I don’t think I was the only one alarmed by this presentation.

I would recommend skipping this presentation or, at a minimum, use it as source of reference on what not to do when wanting to write elegant and robust Ruby code.

Finding Purpose and Cultivating Spirituality by Andrea Guendelman

This was a closing keynote, presented live, which was almost as bad as the talk above but more in terms of ramblings and a lot of ad lib around what it means to find your purpose. A lot of people walked out during this presentation.

On the Care and Feeding of Feedback Cycles by Elisabeth Hendrickson

This was the opening keynote, presented live, on the last day of the conference and an enjoyable one. There is a lot to unpack in this talk and centers on maintenance of good feedback cycles but also input detection for which to improve your feedback cycles. I didn’t take the best of notes on this talk but plan to revisit it once it is posted online. I’d recommended bookmarking this talk too.

Achieving fast method metaprogramming: lessons from MemoWise by Jemma Issroff, Jacob Evelyn

Interesting talk worth checking out because of the performance considerations made when building the MemoWise gem. There are a couple of learnings from this talk that stood out to me. The first is using module_eval instead of define_method to improve speed. Example:

module_eval <<-BODY
  def my_method = puts("Implementation details go here.")
BODY

The second is turning off garbage collection when running benchmarks to stabilize/improve results. Here’s an example of what that looks like:

class WithoutGC
  def warming(*) = run_gc

  def running(*) = run_gc

  def warmup_stats(*)

  def add_report(*)

  private

  def run_gc
    GC.enable
    GC.start
    GC.disable
  end
end

Benchmark.ips do |benchmark|
  benchmark.config suite: WithoutGC.new, time: 5, warmup: 2

  # Implementation details.
end

Lightning

Strangely, not a lot of people signed up for the Lightning Talks this year. In fact, this might be the first time everyone who added their name to the list got to speak without being dropped. I managed to speak about Git Lint (slides) but ran out of time even though I had planned ahead. 😅

It was also strange not seeing Evan Phoenix host these talks as he usually enjoys mangling people’s names. Plus, I wanted to thank him for helping me track down maintainers of abandoned Ruby gems since it’s always a time consuming and tedious task when you are trying to help heal the ecosystem.

Workshops

I spent the majority of my time in the workshops this year since I knew it would be possible to catch up on the virtual talks immediately and live talks once they were posted online. At first, the workshops were not being recorded but, by the second day, they were so you might be able to catch up on these later as well.

Fundamentals of Joint Cognitive Systems by Laura Maguire, PhD, John Allspaw

The primary focus of this workshop was to frame work in terms of cognitive load across humans and machines. The example used was a cryptic Nagios alert which many of us had difficulty deciphering. Being on-call with Nagios definitely brings back a sense of dread because it definitely was a terrible system to use for alerts. If you never had to use Nagios, you definitely dodged a bullet in your career. 😂😭

During the course of the workshop, they highlighted the fact that companies are never incentivized to care for humans. Some stats were thrown out where the resignation of engineers has gone from 3.5% to 4.5% in the last year and a half. I’m not sure how accurate those stats are or where they were sourced from but doesn’t surprise me since we are in the midst of the Great Resignation.

Lastly, they did share some points on building resilient teams which might be worth remembering if you’ve not come across this before:

  • Psychological safety.

  • Good communication.

  • Shared goals.

  • Efficient conflict resolution.

  • Openness.

  • A culture of learning.

  • All contributions are valued.

  • Autonomy over process.

💡 If you want to dive deeper into the above, I’d recommend reading Drive by Dan Pink.

All comments must be haiku! Custom linting with RuboCop by Scott Moore, Kari Silva

The premise of this workshop was to build a custom RuboCop linter that would ensure all code comments were written in the form of haiku. Writing a RuboCop linter does incur a learning curve so not the easiest to pick up but the information was valuable. We spent the workshop working through several steps of progressive enhancement of our linter where I was writing a lot of these statements:

processed_source
processed_source.ast_with_comments

Towards the end of the workshop, we started getting into node pattern matching using the NodePattern Debugger as a composition/debugging tool. Example:

# Generic pattern
($_def_keyword $_method_name $_args $_method_body)

# Named method pattern
($_def_keyword #my_method $_args $_method_body)

Writing custom Rubocop linters has definitely been on my TODO list for a while and I feel like I’ve got more of starting point now to delve into this deeper. Here is the source code for the project in case you are interested.

How to use flamegraphs to find performance problems by Jade Dickinson

The speaker had a love of flamegraphs and tracking down performance issues but the project used was overly complicated and bloated. It also required Ruby 2.6.6 which was a rude awakening but thankfully I was able to easily swap out with Ruby 3.0.2 to get working. Also much of the database configuration needed tweaking in order to get running locally. I’m always surprised when teams don’t have a bin/setup script that does everything for you. Alas.

I did play with icicle charts (the opposite of flame charts), though. Here’s the workshop repository if you care to take a look.

I also made a couple of tangential discoveries which might be of interest:

Soup to Nuts: Build a video game using Ruby! by Amir Rajan

This was my favorite of all workshops where I got to experience working with Dragon Ruby for the first time to build a game. For the purposes of the workshop, access to Dragon Ruby was free but normally it will cost you $50 to $100 to use on a regular basis. Should you want to explore this space, here are the setup steps:

  • Download the game kit.

  • Read through the documentation.

  • Study the workship repository for code samples. There are a lot of examples which is nice.

  • Create an Itch account (optional) but handy if you want to publish your creations.

There were a few surprises when developing with Dragon Ruby:

  • When checking for the Ruby version being used, the environment will say 3.0.0 but I ran into strange compile errors when using endless methods. This appears to be limitations with Ruby Motion. I do wish the printed Ruby version wasn’t so confusing in this regard.

  • You can record all steps of your game play for debugging and sharing purposes but, sadly, there is no time traveling debugger as found when using Elm.

  • Unless you are a great designer and master of image tools, it’ll probably cost you $30/hour to have someone build assets for your game or $1,000 to $5,000 for a packaged bundle depending on what you need.

Should you want to become an indie game developer, Rajan offered a few words of advice:

  • Think about the obtaining perfect five start review.

  • Always build something small first (good advice in general).

  • When thinking of your favorite game, think about the things you could remove. Would it still be your favorite game?

  • Find your hyper-niche audience because they’ll be more than happy to spend money that strikes a cord with their interests.

Group Chat

Discord was used for group chat instead of Slack this year. I’m not a fan of either but have to say I missed having Slack. Discord was definitely a step down in terms of usability. Even the threaded conversations were not as convenient as threads in Slack. The other problem — and this is not the fault of Discord but any group chat service in general — is that too many people would type reaction replies when you could use an emoji reaction instead. This would have significantly cut down on the noise you had to sift through to find any kind of decent conversation. It’s a tragedy of the commons, in the end, and I’ve written about this before too. It’s why I enjoy using Twist these days for more thoughtful discussion and am trying to build a community, using Twist, around the craft of software engineering in general.

Jobs

There were a lot of companies hiring. The Discord channel must of had twenty or more job postings. I like keeping tabs in this space because it’s always good to see what the rest of the industry is up to. Sadly, many of these jobs are with large corporations. You’d be lost in a sea of engineers with very little impact or moving of the needle. This can be great if you are fresh out of school and need work but not if you have a lot of experience and want to make larger architectural impact. Plus, so many companies are not focused on climate change or innovations in sustainable energy/life. I think only one was but always like seeing more.

Conclusion

While the conference as a whole was a mixed bag, I enjoyed myself. I definitely had fun meeting people I had only ever known virtually, catching up with old acquaintances, and having long discussions with new people in the hallway/lounges.

As mentioned at the beginning of this article, there is still a lot to catch up on that I did miss. I’m looking forward to catching up on the various live recordings once they are posted online.

As for next year, it looks like RubyConf will be held in Houston, Texas.