どうも、新米エンジニアの広告技術部サンドバーグと新卒エンジニアの星です！
今回はじめてのRuby会議とあって、会議での情報量に圧倒されつつも自分がおもしろかった話をいくつかピックアップしてきました。
会場は京都
いつもは東京なのですが、今年の会場は京都でした。
国際会館という自然に囲まれた場所でした。
Keynoteはやっぱりこの人
最初はやっぱりMatzさん 僕も含め会場の全員がRuby3の話を期待していた通りメインはRuby3の話でした。今回は特に「型」の話が中心でした。
MatzさんはRubyの今後の型が未来を示す新しいものになれば良いという話をしてくれましたが、我々Rubyistも Rubyがそういった他のプログラミング言語の先駆けになるようなものになってくれると嬉しいですね。
Ruby3: Sasadaさんの新しいconcurrency model
いきなりconcurrency modelの話に入っちゃいますが、今回のRubyKaigiはconcurrencyがとてもHOTなトピックでした。
Sasadaさん的にはConcurrencyを話すことにおいて, 言語のトレードオフ, 「パフォーマンス」vs「安全性・楽さ」が存在すると強調していました。Ruby3を考える中で、パフォーマンスを上げるために重要になっているconcurrencyを既存のRubyに当てはめると、あまりにもRubyが「楽」なためmulti-threadに対応しづらいと言うことでした。
Rubyのいいところでもあるmutableなオブジェクトはある意味制限がなく「楽」だが、そのせいでレースコンディション、デッドロック・ライブロックなどの問題が自ずと出てきてしまいます。ただ、「パフォーマンス」を追求するためにそれらをなくしてしまうとRubyではなくなってしまう！
そこで新たなコンセプト「Guild」が登場！
そもそもすべてのオブジェクトを対象に安全性を確認するのではなく、一スレッド単位でオブジェクトを保持すれば良いという、一階層上に行った考え。Guild同士はマルチスレッドを前提として作り、Guild内はそもそもマルチスレッドを許可せず、Guild間でオブジェクトを渡す際はそもそもオブジェクトを新しいGuildに受け渡すか、オブジェクトをimmutableな形式で読ませるかのどちらか。Guild内であれば以前と変わらず自由にmutableなオブジェクトがつかえ、マルチスレッドに対応する必要があるのであれば、スレッド単位でオブジェクトを保証する。
ふむ、、
コンセプト自体は思い浮かぶが実際に自分が使うところがいまいち想像できなかった内容でしたが、聞くだけでワクワクする内容でした！Ruby3の 3x faster を実現するには必要な拡張化かもしれませんし、そもそも multi-threadのプロセスに対応するには既存のRubyだと問題が発生しやすいと言うのも事実。
会議内では実際にSasadaさんがGuild間のコミュニケーションを可能にするためのメソッドなど具体的なところまで話していましたが、サマリとしてはこんなところです。
Modern Black Mages Fighting in the Real World
こんな興味をそそられるタイトルの発表はTreasureDataのTagomorisさん
www.slideshare.net
過去の遺産と戦いながら色々な辛い話を、Rubyの黒魔術メタプログラミングで乗り越えたという内容でした。
弊社のシステムにもレガシーと呼ばれるものはあります。もちろんそのシステムがあったからこそ今の弊社があるのですが、メンテしづらいのも事実です。 それを必死に改善しつつ、新しい機能も加えるという仕事は尽きないものです。ただそういった環境だからこそ多くの学びがあったりします。
Railsを使っているとSQLを意識外において開発してしまうことがあります。 ActiveRecordは非常に強力で便利なライブラリですが、ActiveRecordが作るSQLを意識せずに開発することは危険です。 なぜなら、最適化されていないSQLを作ってしまう可能性があるからです。 そういったことを学べたのも、膨大なデータを扱うサービス開発に携われたからだと思っています。
SciRuby
続いては、MrknさんのSciRubyのお話。
最近、機械学習すごく流行ってますよね。ただ、機械学習で用いられるプログラミング言語といったらPythonがほとんどだと思います。 そこで、Mrknさんを中心としてSciRubyという、Pythonで使える機械学習ライブラリをRubyでも使えるようにしようといった活動です。 もちろん弊社の分析チームでもPythonを使っています。しかし、我こそはRubyで分析したいんだという方がいらっしゃれば弊社でぜひ実現してみてください(笑)
DDD
もう一人個人的に注目した人が 2日目にいたスピーカー、Chis Arcandさん。
彼が話していたのはRuby3・Rubyというよりは、コーディング自体の話で、聞けば聞くほど実際に試したくなる内容でした。
その名も、「TDD」ではなく「DDD」
Delete Driven Development
内容自体は複雑なものではなく、ざっくり言うと「死んでるコードを積極敵に消そう！」でした。彼いわく、多くの死んでいるコードは「後々役に立つかも」メソッドや「このスペシャルケースのためだけ」メソッドの積み重で、基本的には探す手順も消す手順も大体決まっているということでした。コードを追加するだけでなく、なるべくレポジトリをクリーンに保ち、時にはコードを減らすだけのプルリクを出すのも良いのだと！
実際のコードの削除手順をざっくり説明すると、不必要なパターンをもつコードを探すためにコードを言語のようにパースし、消す条件に当てはまるメソッドをバンバン消していこうとことです。そして、このためだけに Arcandさんが不要コード削除用のgem 「debride」を用意してくれました。
「debride」自体すごいライトに作られていてまだまだ未完成の状態ですが、すぐに導入でき、チューニングや拡張を前提に作られています。
そこで、実際の仕事に取り入れて試してみました！
Gemをインストールして指定ディレクトリーを選択・実効！
ドォーンといくつかメソッドが早速でてきましたが、なかなか消せるコードが出てこない… メソッドの中身を見ていくと「スペシャルケース」がいくつかあったが、なかなか削除に踏みきれないコードが多かったです。
振り返ると「debride」に何か問題があったわけでもなく、単純にデフォルトの状態での「debride」をつかっても、明らかに消せるコードしか拾ってきてくらないことがわかりました。そもそも消す基準のコードは個人やチームでチューニングする必要があると思いますし、より高度なコード解析は「debride」のようなライトなgemではできないのだろうと考えました。
ただ「debride」を実際に使ってみて不要なコードや、コードの質のメトリックスを自動的に可視化してくれるツールがどれだけ仕事に貢献できるか考えさせられました。 「debride」を気に、ほかのツールをもっと積極敵に取り込み、無駄なコードをじゃんじゃんなくしていきたい気持ちが高まります！
最後に…GunosyでRuby/Railsを一緒にやりませんか？
今回大きなRubyイベントの参加できて色々と学びがありました！
視野がまだまだ狭いことに気づいたのと、Rubyエンジニアでもいろんなタイプの人がいると実感できた気がします。 Rubyistの中には言語理論の変革から、文法的に正しい流れるようなコードを目指す人と様々ですし、より多くの違うRubyの形を見ていきたいと強く思いました。
GunosyではまだまだRubyを書く人が少ないですが、Rubyを活用して開発ができる環境がいっぱいあります！いろんな思想を持ったRubyistが集まればいいなーっと思うので、興味あったら是非Gunosyを見てみてください！
