RWCスポンサートークで構文解析器研究部のスーパーLTした

RubyWorld Conference 2023 に参加した。オフライン参加の現地参加は4年ぶり。聖地「やぁ」や、かつて @kakutani に教えてもらったうどん屋の「のび太」がなくなっていたりと変化はあったものの、久しぶりの松江も楽しめました。

勤務先の永和システムマネジメントでは「ESMスーパーライトニングトークス」というタイトルで、1人80秒のスーパーライトニングトークスをスーパーライトニングトーカー名義の @m_pixy, @ima1zumi, @maimux2x, @fugakkbn, @koic, @junk0612, @S-H-GAMELINKS で開催しました。当初スポンサートークとしての企画ギリギリを突いてみた感じではあるものの、終わってみればスポンサートークのあり方について可能性を引き出せたんじゃなかなとそれなりに自負しています。

ちなみに ESM スーパーライトニングトーカーズといった名義提案は私がしたもので、元ネタは『パーフェクトRuby』の Ruby サポーターズです。それぞれ名前付けによって、当日まで発表内容と発表者を遅延できる抽象化技術ですね。

自分のスーパー LT は以下。

いくつかテーマを考えた中で、この後の構文解析器研究部の部員への流れとなる話にすることにしたのが今回。実は話の全体像は「大阪Ruby会議03」の飲み会で話をした「構文解析器研究部の生い立ち」がベースになっています。

少し真面目な話、プロジェクトやセクション間でメンバー交流が断絶気味になるというコンテキストは、いろいろな組織で見られているものだと思っていて、「GC研究部」も含めたこういったアングラな部活動はそういった課題を解決する『組織パターン』としても昇華していけるものでは！？というような壮大なストーリーがその裏にはあったりします。そんな感じで松江行きの移動で『組織パターン』を読んでいたりしたのですが、いずれにせよ80秒で収まる話ではないので機会があれば、それはそれでまた今度。

組織パターン

組織パターン

Amazon

RubyWorld Conference の公式 X でも、構文解析器研究部の部員募集中とアナウンスしてもらってありがとうございました。入社するともれなく入部資格が手に入るので、ぜひカジュアル面談希望などお声掛けください。

RubyWorld Conference 15 周年おめでとうございました。また来年。

『JavaScript Primer』を読んだ

『JavaScript Primer』を読んだ。Web でも読めることは知っているものの、それなりにページ量が多いので Kindle で読もうということで電子書籍版とした。そして、書籍や記事で重要なのは誰が関わっているかというところで、実績と信頼の azu さんが著者のひとりということで優勝の一冊。

JavaScript Primer　迷わないための入門書 (アスキードワンゴ)

JavaScript Primer　迷わないための入門書 (アスキードワンゴ)

Amazon

いわゆるモダンな JavaScript を手広くおさらいしたいという場合にオススメで、痒い所に手が届く親切な説明がされていて著者の温かみを感じるコンテンツです。

自分の場合は健康に良くないことは分かりつつ、就寝前にスマホ Kindle で読むことがあり「動かさないとよく分からん」「この場合はどんな挙動？」という気になりについて、iSH という iPhone アプリを使って動作検証を見たりする。

ish.app

iSH は Alpine Linux となるので、apk で Node.js のパッケージをインストールして iPhone アプリのターミナルで動かすことになる。Node.js に限らず apk でインストールして遊ぶこともできる。RubyKaigi 2023 でキックボクサーがデモに使っていた際には「おお」となったのも記憶に新しい。

個人的には、JavaScript ランタイムにおけるイベントループの非同期に関する動きについて、『ハンズオンNode.js』の2章あたりで、process.nextTick() や queueMicroTask() の動きとあわせて補完しておくと理解が深まると思う。

ハンズオンNode.js

ハンズオンNode.js

Amazon

JavaScript 本は何冊か読んでいるけれど、これはタイトルどおり『JavaScript Primer』としておすすめ。

互換性を重視する (ため古い機能を捨てられない) 言語でのプラクティスには、右手に ES6 以降の知識、左手に『リファクタリング 第2版』ということで、発見があるうちは何度でも Primer しよう。

リファクタリング 既存のコードを安全に改善する（第2版）

リファクタリング 既存のコードを安全に改善する（第2版）

Amazon

大阪Ruby会議03に登壇した

大阪Ruby会議03 に登壇しました。大阪開催の地域Ruby会議での登壇は、もしかすると2015年の関西Ruby会議06のLT以来8年ぶりかも？

今回はまつもとさんの GVL の話と、同僚のこばじゅんのパーサーの話とそれに対する Lrama 作者の金子さんのフィードバックなどなどを楽しみに参加していました。実際想像以上にいろいろと楽しめました。オフラインイベントありがとうございました！

regional.rubykaigi.org

私の当日の発表スライドは以下です。会場が4:3のプロジェクタだったので結果的に16:9と4:3の2バージョンを作っていて、Speaker Deckに公開しているのは16:9バージョン。

ざっくり話すと Ruby のユーザー視点での、1.8 から 3.3 (開発版) までの感想や出来事といったもの。発表後に金子さんから「スライド2枚戻して」と言ってもらったのは最高のご褒美でした。

イベント全体のテーマが「Rubyで笑おう」だったところ、笑い要素とか難しいなあと思いながら作っていたものの、結果的に結構笑ってもらえたのではと思います。MINASWANありがとう。大阪Ruby会議03ありがとうという気持ち。

この記事では、onk からもらった以下の感想への Ruby 3.3 (開発版) 向けの話を補足で書いておきます。

Ruby では bundled gem 化というのが進められていて、この記事を書いている時点での Ruby 3.3.0dev でも、以下のように base64, bigdecimal などなどが Ruby 3.4 での bundled gem 化に向けて Ruby 3.3 で警告されています。

github.com

この変更に対するユーザーとしての遭遇は、Ruby 3.3.0dev で実行した時に以下のような警告が出るというものです。警告元のパスが gem のパスになっている場合は、その警告元 gem へのプルリクエストの機会になっているかもしれません。

/Users/koic/.rbenv/versions/3.3.0-dev/lib/ruby/gems/3.3.0+0/bundler/gems/rails-a8871e6829e5/activesupport/lib/active_support/core_ext/object/json.rb:5: warning: bigdecimal will be not part of the default gems since Ruby 3.4.0. Add bigdecimal to your Gemfile. Also contact author of to add bigdecimal into its gemspec.

この警告を gem 側として解決するプルリクエストの例は以下になります。

実際のところ gemspec にランタイム依存を足す (あるいはテストで使っているだけの場合は Gemfile への依存追加を足す) だけというよりは、対象 gem が Ruby いくつかまでサポートしていて、bundled gem に向けて警告される gem がバージョンによって持っている非互換に当たらないかどうかも見ていくことになります。

例えば、以下は私の方法だと考慮が不十分で、Jeremy Evans がより良い解法で直してくれています。

github.com

こんな感じで、現在進行形の bundled gem に向けた警告は OSS エコシステムに参入する機会にもなると思いますので、Ruby 3.3.0dev を使って警告を見かけたらパッチを送ってみましょう。よくわからんという方は、勤務先で毎月開催している Rails/OSS パッチ会などで聞いてください。次回は 2023年9月28日(木) の開催です。

blog.agile.esm.co.jp

それでは、ハックを続けましょう！

vscode-rubocop 0.6.0 をリリースした

vscode-rubocop 0.6.0 をリリースしました。rubocop -A 相当の安全でないオートコレクトのトリガー実行を可能にしています。

github.com

vscode-rubocop を使う際に、editor.formatOnSave を有効にしてファイル保存時のオートコレクトは rubocop -a で安全に行い、安全でないオートコレクトは意図的に LSP から rubocop -A としてトリガー実行するといった使い方が想定ケースです。以下のように F1 キーからのコマンドパレットから選択してトリガーできます。

github.com

要件としては rubocop.formatAutocorrectsAll 実行コマンドを LSP サーバーに追加した RuboCop 1.56.0 以上が必要です。つまり RuboCop を 1.56 以上にアップグレードしてください。

github.com

実は vscode-rubocop 0.3.0 で editor.formatOnSave によるオートコレクトを安全かそうでないかを設定できる ようにしているのですが、常に安全なオートコレクトのみ、あるいは常に安全でないオートコレクトのみが保存時に連動するよりも、保存時のオートコレクト連動と意図的なオートコレクトのトリガーをわけて使う考え方もあるだろうという機能です。

作り込み過ぎかもしれないなあと思いながらも、rubocop -a と rubocop -A に関連する安全性については度々イシューに上がるので提供しておくことにしました。

大阪Ruby会議03に登壇します

来月 2023年9月9日(土) に開催される、大阪Ruby会議03 に『A Practitioner's Journey from Ruby 1.8 Era to Present』というタイトルで登壇します。

regional.rubykaigi.org

プロポーザル提出した講演概要を引用すると「Ruby 1.8 時代から現在の最新開発版である Ruby 3.3 まで、Ruby のバージョンアップによってどのようなイベントがあり、当時の仕事でのアプリケーション開発あるいは OSS エコシステムでどのような出来事やコードへの変革があったか温故知新をお話しします。」です。

ということで、現職ベースで 20 年近く前の Before Rails 時代の Ruby の状況が起点なので思い出していくのが大変かと思っていましたが、先日スライドを作っていたところ、案外歴代 Ruby バージョンをアプリケーションレイヤーやエコシステムレイヤーで使ってきて面白かったことやお仕事で遭遇した際のツラみ (!) を覚えて (いたりいなかったりして) いて、サクサクと筆が進んでいたので既に大体できているのではという感じです。

個人的にはタイムテーブルでジョーカーさんと同じコマという点が、2020年の Kaigi on Rails 以来というのも楽しみにしています。

この大阪Ruby会議03 には、勤務先の永和システムマネジメントから同僚の @junk0612 構文解析器研究部員も登壇します。お楽しみに。

大阪 心斎橋で会いましょう。

vscode-rubocop 0.4.0 をリリースした

vscode-rubocop 0.4.0 をリリースしました。Layout cop のみを有効にする rubocop -x を LSP で実現できるオプションを追加しています。

github.com

もし日頃から rubocop ではなく rubocop -x を使っている人がいれば、rubocop -x による高速フォーマッターとしての RuboCop 組み込み LSP として使えるようになります。

vscode-rubocop 0.4.0 にアップグレードのうえ、layoutMode と editor.formatOnSave を有効にすると実現できます。

github.com

要件としては layoutMode オプションを追加した RuboCop 1.55.0 以上が言語サーバーとして必要です。つまり RuboCop を 1.55 以上にアップグレードしてください。

github.com

ふだんからフォーマッターとして限定した rubocop -x ではなく、リンターもろもろを含めた rubocop を使っているようであれば、特にこれまでどおりのままで layoutMode の設定は不要です。

勤務先の中期経営計画発表会だった

2017年以来の in-person での中期経営計画の全社集合で福井に行っていた。これにあわせて、Ruby メソッドかるた永和杯や LT 会など事業部独自で前乗りイベントを行っていた。

Ruby メソッドかるたを使った第1回永和杯は @kakutani のツイートにあるように @ima1zumi が優勝。熾烈な決勝戦で見ていて面白かった。ちなみに自分は予選敗退だった。

LT の方はそれぞれのメンバーが行ってきたことや、これからのことを話すもので自分は以下のスライドでの話をしていた。

会社としては3年を中期とした計画となっているけれど、3年も先を見通すのはソフトウェアの見積りと計画づくりで人類にはなかなかに困難なことを「知っている」し、事業 (プロダクト) で課題があればできるタイミングから解決していけば良いと考えているので、そんな感じでのエンジニアリングマネージャー業の話を中心にトークしていた。そんな中期という意味では、「流出 > 流入」の事業課題を「流入 > 流出」という形へ @m_pixy と戦略的に解決したのはひとつの重点事業課題に対する成果だったと思う。

あと @amatsuda に「LT があるのですごく良い話をしてください」と雑にお願いしたら、すごく良い話をしてくれてありがたかったです。ありがとうございます。

世の中は常に移ろい行くので、引き続き襟を正す思いで「楽しさにはビジネス価値がある」環境を整えていく所存です。