この記事は先日鹿児島市の mark MEIZAN にて開催された鹿児島 Ruby 会議 02 のレポート記事です。筆者 (大倉) は登壇者として参加しています。
このレポートでは全体的な雰囲気をお伝えしつつ、それぞれのトークの内容についてもカバーしています。
鹿児島 Ruby 会議 02 は 2023 年 3 月 4 日 (土) に mark MEIZAN にて開催されました。場所は鹿児島市の繁華街である天文館から徒歩で約 10 分ほどのところにあります。
会場のすぐ近くに桜島に行くためのフェリー乗り場があり、筆者も近くまで行って写真を撮ってきました。
イベントは 12 時から 18 時までで、トークは各 20 分間のトークが 8 つありました。
会場にはコーヒーやお菓子が提供され、休憩時間には参加者の方々がおやつ片手に談笑する光景が見られました。特にお菓子は地元のものが多く用意されており、食べたことがないものばかりで良かったです。個人的には「かすたどん」というお菓子がお気に入りでした。
イベントの終了後には懇親会もあり、地元の方々と各地から来た方々が交じりあって鹿児島の美味しいご飯とお酒をいただきました。筆者は 0 日目に焼酎を飲み過ぎたところ、慣れていないこともあってかかなり酔ってしまったので懇親会では控えめに飲みましたが、やはりこういう場は良いなと改めて思いました。
ここからはそれぞれのトークの内容についてご紹介していきます。なお、表記は全て公式サイトから引用しています。
自社での開発の実例を通して、Rails がスタートアップでどのように活用されているか、そのメリットとともに紹介する内容でした。
各種ライブラリが揃っていて拡張が容易なのはもちろんのこと、Rails Way に従えば中長期的な複雑さをある程度抑制でき、様々な問題に対する知見が多く集まっているのが重要なポイントということでした。
具体例として、GMO レンシュというサービスが紹介されました。GMO レンシュの開発メンバーは 3 人だったものの、サービスレイヤーを非常に限定的な用途にのみ使用するなどできるだけ Rails Way を遵守しつつ、テーブル設計をしっかりと行い、認証や決済のような箇所には SaaS を使うといった工夫によって高速な開発を実現できたそうです。
感想:個人的にも Rails は個人または小規模チーム向けに最適化されていると思っているので、この内容はまさにズバリという感じでした。Rails Way についてしっかり述べられていたのも良かったと思います。
初めて Ruby コミュニティに参加してからイベントのオーガナイザーをやるまでのストーリーが話されました。
Ruby を始めた時点ではなにもわからないので知っている人たちとつながるためにコミュニティに参加し、その一歩先に Rails Girls や RubyKaigi などがあるというお話でした。特に Rails Girls で自信を得たことや Ruby が好きであるという思いを強めたことから、次は発表をしてみたいという気持ちを持って Kaigi on Rails 2022 に初めてプロポーザルを提出するなどの活動を行うようになったそうです。今回の発表が初めての登壇ということで、次回は技術をテーマに発表したいという意欲も持っているということでした。
杉山さんは Rails Girls Tokyo 15th のオーガナイザーでもあるのですが、「誰もやらないなら自分がある」という意気込みでオーガナイザーに名乗りを上げたとのこと。コミュニティへの熱意が伝わるトークでした。
感想:コミュニティはこういう人に支えられているのだなあという気持ちになりました。登壇への意欲も含め、とてもありがたいなと思います。
QUIC というプロトコルを Ruby で実装しているというお話でした。
QUIC というのは HTTP/3 で使われるプロトコルであり、HTTP/2 では TCP が担当している領域を UDP ベースの QUIC が担当するようになるということが紹介されました。その際、HTTP/2 においては TCP と TLS が連携していた部分が HTTP/3 では QUIC のみによって担われる、つまり QUIC は TLS を内包しているということが図と共に示されました。
うなすけさんは一度 QUIC を実装しようとしたそうです。ですが、「やったことをないことをやる」ことの大変さのために挫折し、QUIC の Python 実装である aioquic というライブラリを Ruby に移植するというアプローチに変更したそうです。そして、今は Ruby Association の開発助成に応募することで締め切りを強制的に設定しつつ作業を進めているそうです。TLS の層、暗号化の部分は実装が非常に大変であるというお話でした。
発表時点では 10000 行を超える Ruby コードを書いているそうですが、実装としては Python の移植であるためにインターフェースを Ruby らしくするのが課題であるということでした。また、なぜこれをやっているのかという問いに対して、「そこに Ruby がないから」「Just for Fun」という理由が示されたのはとても印象的でした。
感想:聞くだけでもとても大変そうで、これをやり遂げるのは並大抵の苦労ではないだろうと思いました。自分も技術的にもっと挑戦していきたいなと思わされました。
自作のポートフォリオアプリを作ったその後のお話でした。
そのポートフォリオは”SHADONE”というシャドーイングの練習用アプリで、一度バズって就職活動でも 1 社目で内定を得たものの、就職後に実力不足を感じ、就職活動時に話題になったのは「過去の栄光」と感じていたそうです。しかし、ポートフォリオアプリとしては比較的珍しくメンテナンスを続けており、就職してから 1 ヶ月後には技術を身につけるための実験場として、仕事で学んだことを試す場として SHADONE を使うようにしました。その結果、休日も仕事をしている気分になってしまい楽しくなくなったそうです。
そこで、「なぜプログラミングをしているのか」を問い直し、「仕事ができるからプログラミングが楽しいのではなく、プログラミングが楽しいから仕事ができる」のかもしれないという考えにたどり着き、SHADONE をメンテナンスする理由を楽しむことに変えたということです。具体的には仕事には直結しないような新技術を試しており、かつてのようにプログラミングを楽しいと思えるようになったそうです。
感想:ストーリーがとてもしっかりしていて共感できました。楽しさというのは Ruby やそのコミュニティの核にある価値観だと思うので、それが新しい人にも伝わっていくとよいですね。
マイコンで mruby を動作させるお話でした。
ESP32 というマイコンで mruby を動作させる mruby-esp32 というプロジェクトで mruby を動作させる方法が解説され、その敷居の高さを下げたいという想いが述べられました。そのための具体的な方法として GitHub Actions で mruby-esp32 のバイナリをビルドし、それをダウンロードすればあとは esptools というソフトウェアをインストールするだけでマイコンで mruby が動作するということが紹介されました。
今後やりたいこととしては mrbgems の充実やドキュメントの整備などが挙げられていました。
感想:岡嵜さんは福岡 Rubyist 会議 03 でも mruby のお話をされていて、非常に情熱を感じます。mruby は私も個人的に mgem を作ったりしたことがあり、岡嵜さんが中心となってより盛り上がっていくことを期待しています。
Ruby における自動テストの概要についてのお話でした。
まず自動テストについての概略が紹介された後、自動テストの恩恵や種類、注意点が解説されました。特に強調されていたのは「自動テストはとりあえずやるもの」という点です。
続けて Ruby の世界におけるテストライブラリとして、RSpec などのテストフレームワークや DSL としての Capybara、Faker などのサポートライブラリが紹介されました。さらに良いテストコードの特徴が述べられました。基本的には同じコードであるので可読性を重視することなどがありましたが、RSpec については議論になりやすいこともあるのでローカルな慣習に従うと良いということが強調されていました。
最後にはライブコーディングで今回のトークの内容を復習しつつ、TDD が実践されていました。
感想:筆者のトークですので感想とかはないのですが、特に初学者の方がテストに親しめるといいなと思ってこのトークをしました。
Ruby のパーサについてのお話でした。
Ruby の内側では字句解析と構文解析が行われ、得られた構文木をコンパイルして YARV バイトコードに変換されているということが紹介されました。字句解析はスキャナ、構文解析はパーサというソフトウェアが担当し、スキャナはソースコードから単語を取り出し記号と紐付けること、パーサはスキャナから記号を受け取って抽象度の高い記号に変換し、それにフックして構文木を作成することがその責務であると解説されました。
後半は”1 + 2”というソースコードを元に構文解析が行われる様子を追っていく内容でした。
感想:内容自体が非常に難しい中で、それを理解しやすい形でまとめたトークだったと思います。パーサについて詳しくない人でも付いていくことができたのではないでしょうか。
Rails を高速化するお話でした。
まず Rails の遅さが紹介された後、なぜ Rails が遅いのかは謎であり、ボトルネックもなく全体的にもっさりしていること、パフォーマンスチューニングのアプローチとして Object Allocations の指標に注目するという戦略が語られました。アロケーション数が減れば高速化が達成されるのではないか、という仮説を立て、GC.stat
を使って計測するという手法が紹介されましたが、最終的にはmemory_profiler
という gem を使うことで詳細な情報を取得するようにしたということでした。
細かく生成されるオブジェクトを削っていき、最終的にはrender plain
の速度が 3~4 倍速くなったという結論でした。
感想:最終的にはしっかり速くなっていて、さすがのチューニングという感じでした。色々と小ネタがあったのも面白かったです。
鹿児島での地域 Ruby 会議はこれが 2 回目ということで、鹿児島のコミュニティの良さを感じられたイベントでした。スポンサーとして LT をされた企業も Ruby を普段使っていないところもあるなど、地域の一体感のようなものを感じました。これをきっかけに鹿児島に Ruby がもっと広まればよいなと思います。