I was lucky enough to attend RubyConf in San Diego earlier this month, and it was… pretty classy!
The Ruby community is very approachable. Everyone was friendly, happy to talk about their work as well as their side projects. This was my first RubyConf, so it was fun to put faces to names I’d heard about through readings, code snippets, or actual gem creators.
Many of the talks were also fascinating and useful, and I’d like to share my impressions:
Yukihiro “Matz” Matsumoto gave the opening keynote, speaking about visions he developed in earlier conferences and how some of them were implemented first in Ruby 1.9 and others in Ruby 2.0. He then talked about potential futures for Ruby 3.0, noting “programmers need fuel to stay interested.” He threw in ideas about linked concurrency, JIT, and strongly typed Ruby, elaborated on the possibility of a “Soft Typing,” where the type declaration could be used as a documentation to write more developer-friendly code.
Next, I listened to Michael Hartl speak about Enumerable. He started with well-known methods such as .all? .any? .none? .collect .map .select .reject and .inject and then moved on to more advanced ones, like .partition .grep .zip .cycle and .lazy.
Richard Bishop’s talk about concurrency had some interesting outcomes, including the idea that it’s hard to adapt concurrency on old programming languages and that unless a programming language is designed with it in mind, patterns for using concurrency come as a bad complement to the language. Bishop said Celluloid was one of the best libraries for using concurrency, and strongly advocated for Sidekiq (which uses Celluloid) over Resque, claiming Sidekiq was more efficient.
Next up, John Cinnamond was all about enforcing duck typing. He viewed duck typing as a contract that is established before runtime, defining what kind of messages can be passed between objects. This empowered him to write the Lawyer gem, trying to apply things valid in Go (compile time errors) to Ruby as the time errors give valuable feedback to the user. He said that using such a gem to enforce contracts lets you defer some bugs being caught from runtime to test time as the code would not evaluate properly otherwise. Changing contracts would break interfaces at test time, which would force the developer to write new interfaces.
Craig Buchek’s talk on Ruby idioms covered the use of momoization and Hash#fetch. One interesting tip concerned the return of a PageObject after every Capybara method, allowing the developer to chain objects together. I also enjoyed his tip about using the circuit breaker pattern: Basically, don’t keep sending requests if the other end is down (which behaves nicely in an SOA). The last tip I took from him is using the module factory as a means to give arguments to an included module.
Chris Seaton focused on his research project to deoptimize Ruby—allowing developers write code that would make assumptions about how Ruby worked to improve performance, but then fall back to the interpreted language if those assumptions were incorrect. That would let developers allocate variables on the stack instead of the heap, and then reconstruct the heap if some of the assumptions were wrong.
The final talk of the RubyConf’s first day had Betsy Haibel addressing the dos and don’ts of meta-programming—mostly the don’ts. She said that meta-programming was often a misunderstanding of the class hierarchy (hooks, for instance) and suffered from a few common pitfalls: If developers have to implement method_missing, for example, don’t forget to call super, create a respond_to_missing, and cache the method to avoid having to recompute it each time.
In the second day’s keynote, Sandi Metz described the future of Ruby programmers based on the history of scripture. From scrolls to codex to parchment, from the printing press to typewriters to computers, she affirmed that not only do things change, but sometimes they change overnight! Technology could make programmers useless tomorrow, she said. “We have to be ready for this continual evolution,” she said, “by embracing the current moment.”
Next up, Ernie Miller discussed the life of Ruby after Rails. Praising Ruby’s flexibility and user friendliness (“the language serves the programmer, not the programmer serving the language”), he emphasized that the Ruby community—not Rails—is what makes the language so powerful. As Ruby developers move on, he said, they will inevitably port their Likes to other languages and influence them in turn.
Brock Wilcox talked about the gem he created (pry-timetravel) that lets interactive sessions not only step forward but also step backwards, creating a tree of snapshots the application is in. He implemented the gem using Ruby’s Thread class, Signals, and Fork.
After lunch, Charles Oliver Nutter and Thomas Enebo discussed upcoming features in JRuby 18.104.22.168 and the advantages it will have over MRI (including native Java threading, already existent, and the research that went in the JIT). They showed examples of how loops are unrolled and how the Java runtime allows for some optimizations.
Emily Stolfo then described how she wrote a C extension to Ruby. She talked about the multiple object types and how they interfaced from Ruby to C and vice versa. Key patterns she recommended following included reading the README.ext that is provided in Ruby source code!
Justin Searls’ final day opening keynote focused on how we think about open source. Pitfalls include
- Security (the recent Bash vulnerability as an example of the tragedy of the commons)
- Maintainability (you can’t run a bundle update once a year and still have things run properly… Those dependencies get messy and come at a cost)
- Maintainers dropping out (due to illness, death, trolls, moving on, complaints, etc.)
- Single points of failure (what happens if Github, or RubyGems go away?)
- Developers also have to pay attention to the assumptions they make when including a transient (or double transient) dependency: Just because it was forked 1,293 times, that doesn’t make it automatically safe to use.
Laura Frank gave Ruby developers an “intro to Docker.” She walked us through making a Ruby application work on Docker, including the steps it takes to build a container in Docker and ways to manage clusters of Docker containers.
Davy Stevenson’s talk about benchmarking took us from the basics of using the built-in Benchmark, to benchmarks/ips to reach her own gem: benchmark/bigo. Whatever the tools, though, she stressed the importance of correctly setting up the testing environment and the assumptions developers making when using tools:
- Are we testing the same thing each time?
- Are the objects mutating as we test them?
- And many more
“nobody knows nobu” from Zachary Scott told the story of nobu’s history and how he became a core Ruby developer—with more commits than Matz! His contributions include some plus 200 commits just removing white spaces—yes, he probably has a script for that!
Finally, Aaron Quint described how he measures and improves performance in his applications. Developers have to start, he said, by accepting that some performance issues are the programmer’s fault (it’s not always just Ruby being slow). Developers need to benchmark their applications and always be on the hunt for performance improvements. Cache when needed, for example, but not all the time (the request-making could take more time writing to the cache than actually responding). Though he didn’t use New Relic to monitor his application, he probably should have!