2023年11月9日(木) と 11月10日(金) の 2 日間にわたって開催される RubyWorld Conference 2023 に Platinum スポンサーとして協賛します。
初日のランチタイム 1階・大展示場にて、 ESMスーパーライトニングトーカーズによるショートプレゼンテーション『ESMスーパーライトニングトークス』を行います。
@S-H-GAMELINKS, @fugakkbn, @ima1zumi, @junk0612, @koic, @maimux2x, @mhirata の7人が ESM スーパーライトニングトーカーズとして現地参加し、ブースの出展もしています。そちらもあわせてお越しください。
松江でお会いしましょう。
株式会社永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと共生しながら成長したいエンジニアを絶賛募集しています。
こんにちは！maimu( @maimux2x ) です。
10/27(金), 28(土) の 2 日間、東京の浅草橋で開催される『Kaigi on Rails 2023』に永和システムマネジメントは Gold スポンサーとして協賛しています。
4年ぶりにオフラインイベントへのブースを出展することになり、ブースにてRubyメソッドキーホルダーを配布いたします🎉
キーホルダーは全10種類。 アジャイル事業部メンバーみんなで推しメソッドを選びました！
ブースに設置されているガチャガチャを回していただいて、ランダムに一つを受け取ることができます。 どのメソッドが出てくるかはお楽しみです♪
当日現地参加しているアジャイル事業部メンバーに話しかけていただくとガチャガチャを回すためのコインをお渡しします。 そのコインを持ってぜひ弊社ブースにお立ち寄りください！
アジャイル事業部からは10名のメンバーが現地参加予定です。
名札に永和システムマネジメントのロゴシールを貼っているため、お気軽に声をかけてください！
キーホルダーのデザインは今年5月のRubyKaigiで配布したRubyメソッドかるたで採用されなかったデザイン案を参考に作成しました。 当初はRailsのメソッドをキーホルダーにしようという案があったのですが、Rubyメソッドかるたを受け取っていただいた多くの方がRubyKaigi後にかるたで遊んでくださったり、Rubyメソッドかるたへの思い入れがあるメンバーもいたことから、かるたに使用したメソッドを中心に推しRubyメソッドを選ぶ形を取りました。 また、ガチャガチャのカプセルにキーホルダーを詰める作業は事業部の有志メンバーで行いました。集まったメンバーでワイワイしながらカプセルに詰める作業は楽しかったです！
当日そんな裏話も含め、Kaigi on Rails で聞いたセッションの感想や、日頃の Rails アプリケーション開発について、参加予定の皆さんといろいろなお話ができることを楽しみにしています。
永和システムマネジメントでは、Ruby コミュニティと共生しながら成長したいエンジニアを絶賛募集しています。
2023年10月の Rails / OSS パッチ会を 10月23日(月)に Discord でオンライン開催します。
この会をひとことでいうと、日頃のお仕事で使っている Rails をはじめとする OSS について、upstream にパッチを送る会です。
会には Ruby と Rails のコミッターである顧問の a_matsuda もいますので、例えば Rails に送るパッチのネタがあるけれど、パッチを送るに適しているかの判断やパッチを送る流れが悩ましいときなど a_matsuda に相談して足がかりにするなどできます。
開催時間は 17:00-19:00 となりますがご都合のあう方はぜひご参加下さい。
Discord の Rails/OSS パッチ会サーバーへの招待 URL は以下です👇
先日リリースされた Rails 7.1 や、今月開催の Kaigi on Rails 2023 などに関する話題があるかもしれません。
これからパッチ会に参加してみたいという方や、OSS 開発者間の会話に興味があるので聞いてみたいという方もお気軽にどうぞ。
永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。
2023年10月25日 (水) に東京のMNTSQ様オフィスで開催される『Kaigi on Rails 2023 (非公式) 前夜祭』 に弊社から @color_box が登壇します。
発表タイトルは アジャイルからウォーターフォールへ、そして・・・ です。
アジャイルプロジェクトでウォーターフォールのような動きを要求されてしまった時の試行錯誤や、その時作ったgemについて発表します。
お時間の合う方はぜひ遊びに来てください。
ANDPADさんの予告記事はこちらです。 tech.andpad.co.jp
永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。
2023年10月27日 (金) から 10月28日 (土) に東京の浅草橋で開催される『Kaigi on Rails 2023』の初日 (10月27日) に弊社から @fugakkbn が登壇します。
エンジニアになって半年ほど経ったころ、アプリケーション全体のパフォーマンス改善を任されることになりました。「パフォーマンス改善」という言葉は知っていたものの、どのように取り組めばいいのかはまったく知らず「自分にできるんだろうか…」と不安でいっぱいでした。
しかし、半年以上をかけて取り組む中で、パフォーマンス改善にあたって見るべき情報、進め方、工夫の引き出しなど見えてきた部分がたくさんあり、今ではパフォーマンス改善と言われても臆することはなくなりました。今ふりかえってみると、改善までの行程をつかんでいなかったことが不安の一番の要因だったように思います。
今回は、これからパフォーマンス改善に取り組む、あるいはまだ取り組んだことがないという方のこういった不安を解消できるようなトークにできればと考えています。パフォーマンス改善までの道筋を実例を交えて紹介する予定なので、一例として何かの参考になるかもしれません。
また、僕のトークを聞いて「こういうところも見た方がいいよ！」などのフィードバックをいただけるととてもうれしいので、諸先輩方にもぜひお聞きいただきたいです。
Kaigi on Rails 2023 は残りチケット枚数が限られているようです。参加を悩んでいる方はお早めに。
また、弊社永和システムマネジメントはゴールドスポンサーとして、4年ぶりにオフラインイベントへのブースを出展をします。東京の浅草橋でお会いしましょう。
永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。
世はまさに大パーサー時代。人々はパーサーの海へと繰り出す。 ――― kaneko.y
RubyKaigi 2023 における "the bison killer" による大パーサー時代の幕開け宣言からはや4ヶ月が経ちました。みなさまいかがお過ごしでしょうか。@junk0612 です。
タイトルにも記載したとおり、今回は parse.y をちょっとわかったつもりになれるかもしれない記事です。 あらためて軽く説明すると、parse.y とは、Ruby の文法とその処理内容について定義されたファイルです。難解なことで有名になってしまっていますが、実際に軽い気持ちで手を出して、意味も分からず圧倒された経験がこれを読んでいる方にもあるのではないでしょうか。かくいう僕もそうでした。
ですが、パーサージェネレーターである Bison (== Lrama) の文法ファイルの書き方がわかっていれば、言い換えれば、どこに何が書かれているのかがわかっていれば、理解したい内容の部分に絞って読むことができるのでかなり理解しやすくなります。今回は Ruby の文法構造を例にとってみます。どれくらいわかりやすくなるか、注目しながら読んでみてください。
なにはともあれ、Bison の文法ファイルがどうなっているか、ざっくりとした把握から始めていきましょう。まず、文法ファイルの構造の概要を Bison のドキュメント から引用すると、下記のとおりです。
%{ Prologue %} Bison declarations %% Grammar rules %% Epilogue
一番大きなくくりでは、Bison の文法ファイルを構成しているのはこの4つのセクションだけです。また、各セクションは記号で分けられており、実際に parse.y の内部を検索してみると、この記事を書いている時点の master では
にあります。
この中で文法はどこに書かれているかというと、Grammar rules セクションです。つまり %% の間だけ見ればいいので、それ以外の約 10,000 行を消すことができます。ということで、さくっと消してしまいましょう。消したものがこちらです。
さて、続いては Grammar rules の内部の構造を軽く見ていきましょう。Grammar rules は、下記のような「文法」を任意の数だけ連ねたものとしてできています。
nterm: symbol1 symbol2 symbol3 ...
| symbolA symbolB symbolC ... { action }
| symbolX { action1 } symbolY { action2 } ...
これは、以下の内容を意味しています。
nterm という名前であるnterm は、以下のいずれかの記号がこの順で並んでいるものである
symbol1 symbol2 symbol3 ...symbolA symbolB symbolC ...symbolX symbolY ...{ } でくくられた action を使って、nterm が出来上がった時点でどのような処理を行うかを記述している
nterm として正しいかどうか判定することだけ行う。AST を作ったりはしないaction1 は symbolX を読み込んだ直後、action2 は symbolY を読み込んだ直後に実行されるいろいろ書き連ねましたが、大事なのは Action は、文法そのものとは関係がない ということです。言い換えれば、Action を消してしまっても、Ruby の文法構造は影響を受けないということになります。
今回は文法の理解に焦点を当てるので、不要な Action は消してしまいましょう。数が多いので、もりもり消すことができて、消したものがこちらになります。
どうでしょう？ ここまで消すと、ちょっと読めるかもという気がしてきませんか？
Bison の文法の読み方は上でお話ししたとおりなので、ちょっと読んでみましょう。
stmt : keyword_alias fitem fitem
| keyword_alias tGVAR tGVAR
| keyword_alias tGVAR tBACK_REF
| keyword_alias tGVAR tNTH_REF
| keyword_undef undef_list
| stmt modifier_if expr_value
| stmt modifier_unless expr_value
| stmt modifier_while expr_value
| stmt modifier_until expr_value
| stmt modifier_rescue stmt
| keyword_END '{' compstmt '}'
| command_asgn
| mlhs '=' lex_ctxt command_call
| lhs '=' lex_ctxt mrhs
| mlhs '=' lex_ctxt mrhs_arg modifier_rescue stmt
| mlhs '=' lex_ctxt mrhs_arg
| expr
| error
;
例えばこれは、stmt という記号に対する文法ですが、最初の4行は fiterm tGVAR tBACK_REF tNTH_REF などが何を指すのかよく分からなくても、keyword_alias から察するに alias のことを指していそうだ、というのはわかると思います。同様にその次の1行は undef、その次の5行は後置 if、後置 unless などの後置記法を指していそう、ということもなんとなく推測できると思います。
文法中に現れる各記号は、別の文法の左辺として現れる非終端記号か、実際の文字列に1対1で対応する終端記号のどちらかに必ず分類されます。stmt を例に取ると、keyword_alias は終端記号として parse.y の L1571 に定義されていますし、mrhs は非終端記号として別の場所に文法が定義されています。
このように文法の「展開」を繰り返して、最終的にソースコードの文字列に対応させるまでの文法をすべて記述することが、Bison の文法ファイルの中心的な機能であり、Ruby の文法を理解する上で一番重要なポイントになります。これさえ分かってしまえば、あとは読むか読まないかです。あなたもレッツ読解！
文法部分だけを抽出した parse.y を読んでいると、たまに別の記号と1対1で対応付けるだけの文法があることに気づきます。たとえばこのあたりなどです。
これらの存在している理由は、文脈によって異なる Action を書くためです。主に構文解析時の都合で、たとえば普通の if 式の if と後置 if の if では、読み込んでいる状態が異なるために別の処理をしなければならないということがよく起こります。このときに、別の文法として2つの非終端記号を定義し、片方は特例の処理を実装しておいてもう片方の記号を呼ぶようにしておくと便利に使えます。
ですが、あくまで文法理解の観点から見れば、これらは同じキーワードです。2つある文法を名寄せして1つにまとめてしまっても全体としては変わりません。今回は名寄せしたものは用意していませんが、上にも載せた文法のみのファイルからスタートして、試しにいじってみてはいかがでしょうか。Ruby の文法の理解に役立つと思います (一部の奇特な方には TRICK のネタになるかも？)。
いかがでしたでしょうか。今回は、Ruby の文法理解に焦点を当てて parse.y を読んでいくにはどうするかをご紹介しました。
kaneko.y さんの書いたパーサーやりたいことリストにはいろんな内容があるので、一人でも多くの方に協力していただけると、世界がちょっとずつ良くなっていきます。この記事を読んで「意外といけるかも……」と思った方がいたら、ぜひ ruby-jp Slack の #lr-parser チャンネルへお越しください。加えて、弊社に入社いただければ構文解析器研究部員の肩書きもご用意しております。
永和システムマネジメントでは、パーサをいじってわいわい遊びたい方の応募をお待ちしております。
これからの社会を担っていくことになる世代に向けての Ruby プログラミングコンテストである『中高生国際Rubyプログラミングコンテスト2023 in Mitaka』に、今年もゴールドパートナーとして協賛します。
昨年もゴールドパートナーとして最終審査会に参加しましたが、提出された作品がどれもおもしろくできていて、企業賞をどのチームにお渡しするか楽しく悩みました。今年も、素晴らしい作品が出てくることを期待しています。参加者のみなさんは作品提出期限がまもなくで追い込みの時期かと思いますが、最後まで頑張ってください。
アジャイルと Ruby が実現するソフトウェア開発は、開発者が「楽しさ」を感じられる開発であり、そこにはきっとビジネス価値がある――私たちはそう信じて行動を続けています。同じように、プログラミングを楽しくする Ruby を通じて実現される、中高生の作品を楽しみにしています！
株式会社永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと共生しながら成長したいエンジニアを絶賛募集しています。
