RubyKaigi 2019: A speaker’s report

Adding typing to Ruby and a keynote by Matz

This year the central topic for the whole conference was adding static type checking to the language. Is it necessary? How do we make it better? It seems that Ruby 3 will contain type annotations, but it is still hard to say which implementation will become the most popular. You can learn more from the following three RubyKaigi talks to compare different approaches:

• Yusuke Endoh from Cookpad is working on an automatic type profiler for analyzing non-annotated code: slideshare.net/mametter/a-typelevel-ruby-interpreter-for-testing-and-understanding
• Soutaro Matsumoto is working on Steep, which allows writing annotations in separate .rbi files. Here is his talk about challenges in adding typing to Ruby—duck typing, metaprogramming, and more: speakerdeck.com/soutaro/the-challenges-behind-ruby-type-checking
• Engineers from Stripe are continuing to work on Sorbet, which allows adding signatures to method calls right in the Ruby code. This approach also allows to add runtime type checking when the code is running, as annotations itself are just method calls that replace declared method with wrapper performing type checks for arguments and return a value (much like Python decorators): sorbet.run/talks/RubyKaigi2019/

Also, Shopify, GitLab, and Coinbase are supporting and beta-testing Sorbet, so a lot of hype and momentum are guaranteed when Sorbet is finally available to the general public. Stripe wants to make Sorbet open source later this summer.

Sure, larger companies want to add type checking to the language not because they’re hoping to increase performance, but because they want to improve the maintainability of large code bases. Static checks reduce the number of errors in runtime (especially the notorious undefined method foo for nil:NilClass), enhance code completion in IDEs, and simplify onboarding of new engineers to the mature project.

Wonder what Matz himself thinks about that? Watch this video—it doesn’t differ much from the RubyKaigi opening keynote, at which Matz trolled everyone:

Ruby is bad
I hate tests
I hate type annotations

It seems that Ruby itself is heading more towards the Steep and ruby-signature approach, but time will tell.

Love for mruby

There was also a lot of attention to mruby at the conference, not only in talks (“Practical mruby/c firmware development”, “Non-volatile mruby”, and a lightning talk about using mruby in satellites!), but also because of the mruby exhibit on the 4th floor of the congress center.

It seems that at least in Japan, mruby is not only actively used—but is quite widespread! Try to search Twitter for #rubykaigi mruby to see for yourself.

“Determining Ruby process counts” from Nate Berkopec

This was a talk with a lot of pretty uncomplicated math about how to estimate how many worker processes and servers you need to serve all incoming requests during low and peak times. One key thought in this talk was that you need to watch on how long requests waiting for a free worker to understand when you need to scale your application up or down.

Slides: Determining Ruby process counts.

“Cleaning up a huge ruby application” from Cookpad

Review of available tools that can help in searching for “dead code” (like oneshot_coverage and coverband), as well as a presentation of the (not yet released) cookpad_all gem that allows to track which iseq-instructions were executed on production and which weren’t to reliably tell which code is actually isn’t used. It is still Ruby with metaprogramming and all this stuff, remember?

Slides: Cleaning up a huge ruby application.

Two talks about writing API client gems

The “How to use OpenAPI3 for API developer” talk by @ota42y explains what OpenAPI (ex. Swagger) is. From it you can learn about two gems: the committee gem for validating OpenAPI requests and responses for your API, and the openapi_parser gem that can help in the development of your own client for OpenAPI-compatible API.

The “Best practices in web API client development” talk by Go Sueyoshi was about guidelines that everyone should follow when writing yet another client for some API. Namely:

1. A client should convert params/response from/to Ruby types;
2. A client should refresh access tokens and retry;
3. A client should raise relevant exceptions on various API errors;
4. A client should not cache (it is an application-specific responsibility);
5. A client should not validate params because it’s hard to keep in sync with API (the validation should be done by API);
6. Use keyword args wherever possible for simplicity of further extending;
7. Use faraday (it can convert types in simple cases, e.g., when API returns only the true string). Also, it has several middlewares included: for instance, to log requests as curl copy and paste commands (which is great for reporting bugs to the original API maintainers).

Also, we’re thrilled that our own evil-client gem for creating API clients (the ebay_api gem, for example) encourages the developer to follow most of these guidelines—that means that we’re on the right track.

“Building a game for the Nintendo Switch using Ruby” from Amir Rajan

A whole game built with RubyMotion! The Ruby inside it is not your usual Ruby, but something like “LLVM Ruby,” and it works everywhere: iOS, Android, Nintendo Switch, PS4… And it works at 60 FPS! An interesting fact: they have mostly switched GC off, and run GC manually after computing state for every frame because the only state that persists between frames is contained inside a single OpenStruct-like object. Also, there is a whole text editor and Ruby REPL hidden inside the game. So you can open text editor right on your Nintendo Switch and monkey-patch the game. This is awesome!

Slides aren’t published yet, but you can see how it works in this video.

Unfortunately, the game was later pulled from Nintendo eShop because of the Ruby REPL inside.

My talk: “Yabeda: Monitoring monogatari”

It was my first English talk ever, so I was quite nervous—I skipped most of the first half of the conference before my talk because I just couldn’t stop polishing slides and changing the wording in speaker notes.

The only practice talk that I did in the evening before day X was extra messy: it seemed like there were words in every sentence I couldn’t even pronounce. In addition, my laptop didn’t want to “talk” with the projector (glad that I checked it a day before), so the organizers set up a spare Chromebook for me. Thanks!

My room was #RubyKaigiC—a smaller auditorium for approximately 150 people. I was pumped that people came to my talk despite the cryptic talk name (1 Russian word, 1 English word, and 1 Japanese word) and the English language of the keynote itself.

The talk itself went more or less smoothly—much better than the practice talk—I even didn’t check my speaker notes much. However, I do recommend writing a whole speech as speaker notes in advance; it really helps make your talk sharp and smooth, even if you don’t read them at all during talk time. I’ve even landed a couple of successful jokes! Unfortunately, due to my extra high stress level at the time of the talk, I can’t remember much about it.

Not a single question was asked after my talk, but I guess not asking a lot of questions is more or less a standard practice at Japanese tech conferences, as far as I can tell after attending RubyKaigi in 2018 and 2019.

See my slides on Google Slides or Speakerdeck:

On the last slide, I put a note that I had a ton of Martian stickers and they would be available along with me at the sticker desk on the 2nd floor. A few people caught me in between and asked me some relevant questions, and I talked with some more people while they were grabbing stickers. In the two following days, people came to the sticker desk, and kawaii’d from our logo on stickers and my t-shirt (it is adorable); one of the girls even called it harajukish (原宿っぽい) after the name of Tokyo district with a lot of cute things and weirdly dressed people. At the end of the conference, all four packs of stickers were gone.

And many more!

This list isn’t complete by any means—it was just impossible to go to every talk I wanted in four simultaneous schedules (oh, but if I could have I would have). But for most of the talks, there are links to slides available from their talk page. Click on a keynote title you like on the conference schedule page and scroll down to the “Presentation materials” button.

RubyKaigi organization “wow” moments

Food

In addition to traditional Japanese lunch boxes, this year organizers set up five yatai—street food stalls Fukuoka is famous for (organizers even put them into the conference website—look at the rubykaigi.org/2019 footer). So, instead of taking a bento box you could sit under the yatai curtains and enjoy some ramen, soba, or gyudon. An exciting solution, isn’t it?

Slide templates and visuals

There was a whole pack of logos, backgrounds, and other visuals available at the special page. Creating my template with it in Google Slides was a breeze. I hope that every conference can publish such a thing in advance.

Transport and Parties

Sponsors paid for shuttle buses—and even taxis—from hotels to the venue and back. Thanks!

One big free after-party was held on the first day evening on one of Fukuoka’s “street malls” in addition to a lot of traditional micro-parties from sponsors on other days. Numerous tables were set up with a few points of drink and food distribution (several different restaurants prepared their cuisine only for RubyKaigi attendees). There was a whole map of this afterparty, can you believe it?

Also, yes, the traditional unofficial riverside party was excellent—as always. Conferences are about networking, after all.

At RubyKaigi’s closing keynote it was said that “this is the conference for those who code.” Let’s code awesome things in Ruby, propose talks about them, and, who knows, maybe we will meet at RubyKaigi 2020 at Matsumoto city (and yes, they’re trolling Matz!)

Thanks a lot to the whole team of organizers, Ruby authors, gems contributors, speakers, and attendees. You have made this conference amazing.