RubyKaigi 2019: A speaker’s report

RubyKaigi is still one of the best Ruby events in the world—with top-notch talks, amazing level of organization, and even by the number of attendees. And if you still think that “Ruby is dead” then “you’re just not paying attention.”

#rubykaigi has confirmed it for me: if you think nothing interesting is happening in Ruby, you’re just not paying attention.

— Nate Berkopec (@nateberkopec) 19 April 2019

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 will be finally out for the general public. Stripe wants to open source Sorbet 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 allow to 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 is thinking 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 going more to the Steep and ruby-signature approach, but time will tell.

Love for mruby

Also, there was 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 whole 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.

Running #mruby on a satellite for live (every 10 min) maps to e.g. check the length of the queue for ramen :D #RubyKaigi pic.twitter.com/m4K5O5Mgut

— Benoit Daloze (@eregontp) April 19, 2019

“Determining Ruby process counts” from Nate Berkopec

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 instrumental thought in this talk is 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 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’ve mostly skipped the whole half of the conference before my talk because I just couldn’t stop polishing slides and changing the wording in speaker notes.

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

My selfie right before starting the keynote

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.

Talk itself went more or less smooth—much better than the test run—I even didn’t check my speaker notes much. However, I do recommend writing a whole speech as the speaker notes in advance helps a lot to make your talk sharp and smooth, even if you don’t read them at all at 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:

At the last slide, I’ve put a note that I’ve got a ton of Martian stickers and they will be available along with me at sticker desk on the 2nd floor. Few people caught me in between and asked me some relevant questions, and we have talked with some more people while they were grabbing stickers. In the two following days, people came to sticker desks, 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 worn people. At the end of the conference, all four packs of stickers were gone.

Evil Martians stickers

And many more!

This list isn’t complete by any means–it was just impossible to listen for every talk I wanted in four simultaneous tracks (oh, if I even could to do so). But for most of the talks, there are links to slides available from every 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 have 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?

Half of the conference lunch booths: various Japanese fast food for takeaway or not

Slide templates and visuals

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

Transport and Parties

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

One big free afterparty was held on the first day evening on one of Fukuoka “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 (a few different restaurants prepared their cuisine only for RubyKaigi attendees). There was a whole map of this afterparty, can you believe it?

The official #RubyKaigi party this year was out of scale, the party was literally an entire street of Fukuoka! Pictures from https://t.co/7nQlhnvSCd pic.twitter.com/7E24SU27Bw

— Benoit Daloze (@eregontp) April 26, 2019

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

At RubyKaigi 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.