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.

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.

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:

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

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:

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

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.

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.

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.

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:

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.

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.

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:

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

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.

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.

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:

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

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.

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:

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

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:

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

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.

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:

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:

There were a few surprises when developing with Dragon Ruby:

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