プログラミング

RubyKaigi2019 in 福岡 参加してきました

投稿日:

4/18(木)~20(土)福岡で開催したRubyKaigi2019に参加してきました!!

実はRubyKaigiの存在すら数ヶ月前まで知らなかったのですが、会社の人に「行っておいで」と言われ会社負担で参加できることになりました。ありがたし...。

正直セッション内容はめちゃめちゃに難しくてレポートと言えるほどの内容は書けませんが、こんな感じでした〜と初参加者なりに感想をまとめます。

 

0日目

前日、仕事を早めに上がって名古屋→博多まで移動

雨が降っていたので名古屋市指定ゴミ袋を被せてスーツケースを守るライフハック。

新幹線で3時間少し、意外と近かった。

1日目:

RubyKaigiだー!!!

こんな大きなカンファレンスに参加するのは初めてなので、まず会場の大きさと人の多さに驚きました。これだけエンジニアが集まっていると思うとわくわくです。

意外と女性も多くて嬉しかったです(1/50くらい?)

普通に本名書いてましたが、基本的にみんなハンドルネーム使うんですね...

 

初日は松本さんのKeynoteでスタート。

目の前の舞台に座っている人がRubyを作った、というのが何だか不思議で「わ〜松本さんだ〜本物だ〜」と思いながらKeynoteを聞いてました。

ちなみに会社負担で参加したカンファレンスは後日報告があるので私も真剣です。社内に型大好き人間が多いので、ruby3の型の話題をまとめようかなと思いながらメモを取っていました。

ただ、型がある言語をまともに触ったことが無いのであまり分からない...。そもそもスライドに映っているrubyが私が書いたことがあるrubyとはかなり違い(というかハイレベル)、何度もググりながらメモを取っていました。

もちろん頭と手が追いついていないので、後日上がるスライドを頼りに再度調べてまとめます。ううう。

 

お昼はお弁当か屋外の屋台から選べました。

RubyKaigiは屋台、シャトルバス、朝食サポートなど本当に運営がすごいです。手厚いとかそういう次元を超えています。

2日目に食べた焼きラーメン。初めて食べましたが美味しかったです。

 

午後からのセッションは4部屋に分かれて行われ、私も前日に選んでいたセッションを聞いてみました。当日スケジュールはこんな感じ。

 

できるだけ基本的なものを聞こうと思い、午後初回は「How to take over a Ruby gem」に参加。

しかし!!私は英語のセッションにはすべて通訳が入ると思っていました...。日→英通訳のみだったんですね。

始まったときに「あれ?」と気づき、慌ててスライド見つつ、必死に聞き取ってメモを取りましたが本当に難しい...。

英語は大学時代にかなり真剣に勉強していたのである程度いけるかなと思っていたのですが、日本語でも分からない内容を英語で聞いても半分も分からず焦りました。

「RubyKaigiの公用語は英語」という言葉は冗談ではありませんでした。半分以上のセッションは英語なので英語必須(日本語発表もスライドは英語だった)

 

ここからは私が聞いた各セッションとざっくりメモ

(間違った内容があるかも。そして本当に理解できなかった/英語聞き取れなったものは飛ばしますごめんなさい)

1日目

How to take over a Ruby gem

  • gemをインストールしただけで データ盗んだり、他のgem壊すのは簡単(bootstrap-sassでおきた)
  • gemのうち1年以上アップデートされていないものはたくさんある
  • 有名なgemのtypoを狙って悪意あるgemが作られている可能性もある
  • gemの依存関係を確認しよう
  • gemのアップデートをする時はできれば差分を見よう
  • 差分を見たいならcoditsu(https://coditsu.io)があるよ

gemインストールする時gem名の直打ちしてたけど止めよ。時々「そんなgemないぞ」と叱られるけど、そこで代わりに悪意あるgemが入ることもあると思うと怖い。

Determining Ruby Process Counts: Theory and Practice

  • スケールしてもユーザーの待ち時間が減っているだけでレスポンスタイムは同じ
  • request queue time(リクエストの待ち時間?)にかかる時間を減らそう
  • average response time x 4 x request arrival rate = ruby process count

会社でNew Relic使った時にこの辺りを少し調べたので聞いてみたけど前提知識やっぱり足りなかった。

Twitterでまとめてくれていた人によると、このruby process countが25%になるくらいが良いらしい。

New Relicのこういう記事も参考になるのかな?

A Type-level Ruby Interpreter for Testing and Understanding

  • ruby3に実装されるかもという型システムの中の「型プロファイラ」のお話
  • 条件分岐するときも両方の分岐をチェックしてくれるのでundefined methodのようなエラーも見つけてくれる
  • 型プロファイラは、コードを見て型の定義(シグネチャと呼ぶらしい?)を作ってくれる
  • 型プロファイラに基づく警告はいつでも正しいとは限らない。また、テストに時間が掛かったり一部メソッドには使えないことがある

今度TypeScriptで初めて型に触れる予定があるので、RubyKaigiも型の話を多めに聞いてみた。でもTypeScriptちょっと書いてみた程度ではシグネチャとか知らない単語が多くて難しい。

この発表の内容はクックパッド開発者ブログにも上がってます。

社内に「型はいいぞ」と推してくる人がたくさんいるので会社の報告会はこの辺りをまとめようかな〜

 

Pattern matching - New feature in Ruby 2.7

  • パターンマッチングとは、あるデータが与えられるべきデータ構造を指定しておき、代入された時にデータ構造をチェックする仕組み

例:

case [0, [1, 2, 3]]

in [a, [b, *c]]

p a #=> 0

end

(*がつくのは多重代入。他にもin [_, _]はオブジェクトを2つ持っていればOKなどいろんな書き方があるらしい)

  • jsonデータの処理とかに使える
    • jsonの形式に沿って書けるので見やすいしコード量が減る
  • 注意: スコープ
  • パターンにマッチしなくてもunlessなどで代入した値がそのまま残る
  • in Time.now == hogeみたいなin中のメソッド呼び出しはできない

パターンマッチングという言葉も初めて聞いた。多重代入や[_, _]みたいなアンダースコアの使い方など、テーマそのものよりも解説中に出てきたrubyの知らない書き方を調べるほうが私のレベルにはまず必要な気がする。

RubyKaigi 2019 Official Party

夜は商店街を貸し切っての交流パーティーに参加!

実は最初「知らない人と喋るの怖い」と言って、1人でラーメン2件ハシゴしてそのまま帰る予定でしたが、宿泊していたホテルのある中洲川端商店街がまさかの交流会会場だったのでそのまま流れで参加してきました笑

 

 

長ーーーーーい商店街の真ん中にテーブルが並び、立ち飲みで食事やお酒を楽しめるスタイル。

RubyKaigiはグループ参加の人が多かったので1人で会話に入っていくの死ぬほど勇気がいりました。迎え入れて一緒に喋ってくれた皆さんありがとうございます。

 

その後、ここで仲良くなった女の子と二人で焼き鳥へ。

店名をメモしわすれたけど、ししゃもの開きに明太子を挟んだ「ししゃも明太」がめちゃめちゃ美味しいお店でした。

 

1日でラーメン2杯、焼酎、焼き鳥、また焼酎。最高。

 

2日目

メドレーさん提供の朝食をいただきました!

海が見えるテラス席でバイキングの朝食だなんて、勉強会だとは思えない〜

バイキングに明太子があるのが博多らしかった。

 

All bugfixes are incompatibilities

rubyを安定運用するためにどうやってエラー修正をしているのかというお話

  • Keynoteということもあり、rubyそのものの修正ってこうやっているのか...としみじみ聞いてた
  • File.read(|cmd...)みたいな書き方するとコマンド実行できたのか!
  • 文法エラーはロード時にエラーが出るので、先にパッチのファイルを読んで対応、という手段が使えない。
  • 誰も使っていないなら修正しない、ずっとあるバグは優先度を下げる→be practical!
  • これは普段の仕事も同じなのかな

How RSpec works

仕事でテスト書いてないのに興味本位で聞いてみましたが、なるほどわからんでした(懺悔)

2日目の英語セッションは本当に聞き取れないものもあり、昼辺りから「テーマが面白そうだけど英語のセッション」と「日本語だからとりあえず聞き取れるセッション(理解できるとは言ってない)」の間で真剣に悩み始める...

知識と英語力、両方大事!

 

Ovto: Frontend web framework for Rubyists

今回一番おもしろかった。

自作フレームワークのお話でしたが、SPAをrubyで書くと聞いただけで興味MAX。

Reduxみたいな感じでaction発行→state変更→view更新の流れをrubyで書き、action、state、compoment(view)はclassに分けているっぽい。

大規模なアプリケーションになったときのパフォーマンスはわからないから実務向きかどうかは...みたいなお話をしていたけど、こんな面白いものを作っている時点でこの人のプログラミング愛の凄さは伝わってきました。

ドキュメントやチュートリアルもガッツリ作られている。

 

Building a game for the Nintendo Switch using Ruby

2日目後半でそろそろ集中力も辛くなってきたので、気軽にタイトルで選びました。mRubyとCでSwitch用のゲームを作ったとのことでしたが、そもそもどちらも理解できず...(あと後ろの方の席を選んだらスライド読めなくて失敗した)

でも実際にSwitchが起動するところから見るとワクワク。自分が書いているのと同じ言語でゲームやSPA作っている人を見ると、プログラミングの可能性を感じる。

Lightning Talks

2日目ラストはLT大会!

時間切れの時に銅鑼が鳴るのと、スライドに「Time out error」が出るのが全力でふざけていて最高(褒め言葉)

私はLTやったこと無いのですが、ぎっしり詰め込んでガンガン話す人、スライドとトークで笑いを取りながら進める人など、5分の使い方が違うのが面白かったです。

印象に残ったのはマネーフォワードの人の元号ネタ。非常につらみを感じる内容で、特に入力されたデータの表記ブレ(平成五年がH5/H05/h5みたいな)とかは最近自分がやった仕事を思い出して「ううう」ってなりました。

 

夜ご飯

ご飯の前に博多パルコのゴンチャへ。

ゴンチャは先日名古屋のららぽーとにも出店しましたが、混みすぎていてまだ飲めてなかった。

初めてなのでベーシックなミルクティー。幸せ!

 

その後は中洲の「天手古舞」で一口餃子と日本酒!

ご飯を注文しようと思ったら、店主のおじさんに「博多では餃子はおつまみだからご飯は置いてないよ」と言われました。ご飯なしだと1皿では足りなかったので、やぶれ餃子とパリ焼き餃子を1皿ずつ注文。

一口サイズのパリ焼き餃子はめちゃめちゃ美味しかったです。スマホの充電が切れて写真が撮れなかったのが残念...。

 

3日目

 

朝食は再びメドレーさん提供のバイキング。博多着いてから毎日明太子食べてる。

Ruby Committers vs the World

タイトルを見ても何が始まるのか全くわかりませんでしたが、一言で言えば松本さんとコミッターさんたちの「アメトーーク!」でした。

登壇者入場前の舞台。ひな壇芸人ならぬ、ひな壇エンジニア

 

メインのトークはRuby3どうする?みたいなお話と事前に来ていた質問への回答コーナー。

「最近松本さん保守的すぎじゃない?」みたいな質問に対し、松本さんが参加者にRubyの今後の方針についてアンケートを取っていましたが「非互換の変更に対しても攻めてほしい」と答えた参加者が多くて驚きました。

(私は自分で自分の首を締めたくないので「このままで良い」に挙手)

トークは本家バラエティのような盛り上がりで、会場もみんな笑いながら聞いていました。松本さんと他の参加者の距離の近さに驚き。

 

Cleaning up a huge ruby application

  • 実行されていない不要コードを消したいというお話
  • 消せるコードを探すためにコードカバレッジ(=どのコードが実行されたかの記録)を使うことができる
  • iseq logger(=rubyコードをコンパイルして得られる命令の集合。つまりどのメソッドが実行されているかという情報)のlogをredshiftに保存。テンプレートがrenderされているかも確認できる
  • oneshot coverage を使えばメソッド内のコードが実行されているかまでわかる
  • 3年以上呼び出されなかったり、呼び出されるメソッドが消されたコードを探して、自動的にissueを発行

ブログにもまとめられていました

今仕事で触っているプロダクトはまだ小さいけど、それでも使われていないコードを指摘されたことがあるので、大規模なプロダクトになると確かにメンテナンスの負担も増えそう。

 

Best practice in web API client development

  • APIクライアントをどう書くか?
  • 1つのアプリでしか使わなくてもgem化したほうが良いのでは
  • API部分の実装がアプリケーションと密結合になるのが良くない
  • 切り離したほうがテスト、メンテしやすい
  • API開発のgoodパターン
    • 依存を少なく保つ(先程の話)
    • ハッシュの引数よりキーワード引数
    • パラメータオブジェクトの導入

API開発はやったことがなくまだ自分にはハードルが高そうだけど、ここもできるようになりたいので聞いてみた。

このセッションで聞いた内容を活かせるようになりたいなーと思って後から読んだ「WebAPIについての説明」というQiitaの記事がわかりやすかったので、まずはここの内容をしっかり理解したい。

Reducing ActiveRecord memory consumption using ApacheArrow

  • ApacheArrowとは? =>データ処理の効率化ツール
  • でもデータ交換(バイト列への変換、転送、復元)は遅いのでここを高速化したい
  • ActiveRecordはDBから返ってきたデータをfieldに返す
  • これをappach::arrowのfiledに返してみる
  • 結果的にexecution timeは減る
  • けどメモリ消費量は増える

ActiveRecordだ〜と軽い気持ちで聞いたらメモリの話がメインで10%くらいしか分からなかった。ツール間でデータの変換が行われているということはとりあえず初めて知りました。

(メモリとかって基本情報勉強したら分かるのかな。やっぱり取っておこうかな...)

 

The send-pop optimisation

  • rubyのmethodは使われない値も返している
  • その戻ってきた無駄な値を捨てる時にsend-popが発生する
  • methodを呼び出す側に、このメソッドは使われたか?を確認してもらう
  • 全ては見れないので、シーケンスを後ろから確認してpureでないものがあったら、その手前に確認するコードを入れる
  • sendは何を返しても良いので残してpopは消す
  • こうしてsend-popの処理を最適化することでRubyの実行が速くなる

最適化へ執念がすごい。でもこういう点も突き詰めてより効率良く動くプログラムを書けることがまさにスキルなんだなー。私はまだ期待された動作をして、かつバグを生まないようにコードを書くことで精一杯だけど、ここまでできるようになりたい。てか、ならないといけないのでは。

 

帰宅!

本当はもう1セッションとClosingがあったのですが、当日中に岐阜県まで帰るためにここで会場を離れました。After Partyも出たかったので、来年はもう1日ホテルを取って参加したい!!

 

会社へのお土産は定番「博多通りもん」

駅ビルで牛タン。博多らしさは皆無だけど美味しかった。

まとめ

初めてのRubyKaigi、3日間はあっという間に過ぎました。

国際的なカンファレンスと聞いていたので少し緊張もしていたのですが、運営の方も登壇者の方も参加者もみーーんな楽しそうで、「文化祭」という言葉がピッタリなイベントでした。

もちろんセッションのレベルはめちゃめちゃ高かったし、運営の方は分刻みの正確さでイベントを支えていて、とても大変だったと思います。

 

真剣にプログラミングをしている人がたくさん集まっていて、エンジニア1年目からここに参加させてもらえて本当に良かったです。

 

昨年9月に転職して社内でバリバリコードを書く人たちを見た時、キャリアの遠い先を見たような気持ちになっていましたが、RubyKaigiに参加して、もっと遥か先を見せてもらえました。

セッション内容のメモを取るので精一杯の状態でCTOはどうして私を参加させてくれたんだろうと思いましたが、エンジニアとしてずっと先を走っている人達の話を聞いて「こういう人達がいる」という事を知ってほしかったのかなと思いました。

 

知識も技術も身に着けて、次はもっとRubyKaigiを楽しみたい!


-プログラミング

Copyright© 言葉の森をてくてくと  , 2020 All Rights Reserved Powered by STINGER.

%d人のブロガーが「いいね」をつけました。