部屋の隅っこで書く技術ブログ

中の人は20代後半Web系エンジニアです。テーマは闇鍋ですが、マネジメント、Ruby/Rails、ブロックチェーンの話題が多めです。

【平成Ruby会議01】「ActiveSupport::Concernで開くメタプログラミングの扉」で登壇しました #heiseirubykaigi

f:id:expajp:20200105013919p:plain

早くも新年二発目の記事です。実家にいると時間があって良いですね。

12/14に行われた平成Ruby会議01にて、「ActiveSupport::Concernで開くメタプログラミングの扉」というタイトルで登壇してきました。

heiseirb.github.io

主催者・スタッフのみなさん、お疲れさまでした。そして、ありがとうございました。
また、聞きに来てくださったみなさん、ありがとうございました。
それから、前日に練習につきあってくださった同僚のみなさんにも最大限の感謝を。

おかげさまで、無事にトークを終えることができました。

発表について

発表スライドはこちらです。

speakerdeck.com

大雑把に内容をまとめると、

  • ActiveSupport::Concernは美しい仕組みで実装がシンプルで凄いので推してる
  • この凄さを体感することで、メタプログラミングの良さを感じてもっと使ってほしい
  • メタプログラミングRubyを使い続ける理由になるので、初心者が増えているチャンスを活かしてコミュニティに人を増やしたい

という感じです。

特に伝えたかったこと

ActiveSupport::Concernの導入によって、よりオブジェクト指向に忠実かつRailsらしく書けるようになった」というところです。

これによって、

  • CoCを実現してRailsらしいコードになった
  • 世界規模でDRYを実現した
  • よりRubyらしく書けるようになった

の3つを実現しているのです。

しかも、コードは「一つのことを、うまくやれ」1というUNIX哲学に沿っている。脱帽です。

まあ、この辺の内容は導入されたときに散々言われていただろうなと思いますし、何周遅れの議論だよという話なのですが、Rails4がリリースされた2013年というとRubyの「る」の字も知らない学生だったので許してつかあさい……

なぜこのテーマを選定し、CfPに応募したのか

きっかけは、@netwillnet さんのこのスライド

speakerdeck.com

blog.willnet.in

と、社内の読書会で「メタプログラミングRuby」を扱い始めたことです。

ActiveSupport::Concernのことそういえばよく知らないな、と思っていたところにちょうどメタプログラミングRubyが届いて、個別に章が割かれていたので興味を持って読み進めました。

その結果、これはすごい、と思ったので理解した内容をOtemachi.rb#21で話したのでした。

enechange-meetup.connpass.com

ただ、このときはちゃんと理解できている感じがしなかったし口頭での説明に限界を感じていました。

ですので、ちょうど「どこかでちゃんとスライド作ってもう一度話そう」と思っていたところに、平成Ruby会議01があった2、という感じです。

ただ、「タイミングが良かった」以外にも、

  • 普段の平成.rbの内容を眺めると、マネジメントやキャリアの話よりも、技術の話の割合のほうが多そう(という勝手な予想)
  • 参加者の年齢層やキャリアが幅広そうな「平成Ruby会議」に合ったテーマを見つけられ、特に「初級者卒業」に話題を寄せた
  • 自分は「美しい仕組みが好き」なので、その感情を載せるとトークに説得力をもたせやすかった

ことから、ぶっちゃけた話、かなり自信をもってCfPを出すことができました。

ただ、自信持って出したことで逆に「もし採択されなかったら何が悪かったかわからない、どうしよう」と不安だったので、採択のメールをいただいたときにはホッとしました笑

他の登壇者の方のトークについて

2トラックなので必然的に半分は直接聞けていないわけですが、聞いた中からいくつか抜粋して感想を。

全員のスライドを埋め込むと表示が重くなるため、リンクを張るのみにしておきます。

What is expected?

What is expected? - Speaker Deck

Rubyコミッタ、@yui-knkさんの基調講演。 CRubyのパーサにおいて、「expected tokensをどう知るか?」というお話。

yaccは学生時代に単位を落としてからのトラウマなわけですが、どこかで仲良くならなきゃいけないんだろうなあと思っているところにこの話。 Default Reductionという仕様は初めて知りましたが、素人目にも諸刃の剣に映りました。これに強く依存しているというのは、職人芸化が大きく進んでいるということでは……?

Railsで事業立上げのリードエンジニアになるために

新規プロジェクトのリードエンジニアになるために - Speaker Deck

ほたて(@purunkaoru)さんのトークrails newから開発を軌道に乗せるまでにすべきことをパターン化する、というお話。

恥ずかしながらrails_template初めて知りました。試行錯誤を形として残すにはこの上ない方法ですね。 また、ほたてさんはTwitterの予約投稿をつかって講演中に資料がTLに上がるという手法を使っていて痺れました。

Good to know YAML

Good to know yaml - Speaker Deck

前職の同期でもある@Y_MITSUBOSHIさんのトークyamlがPsych::Nodesでどのようにparseされるか調べ、それを使って重複したkeyを検出するgem'Yamcha'を作るお話。

Yamchaはピンポイントを刺しにいくgemで、日々の負債との戦いの中で生まれたことがなんとなく想像できました。 ネーミングが素敵です。

Ruby力を上げるためのコードリーディング

20191214_heisei_ruby_kaigi - Google スライド

kinoppyd(@GhostBrain)さんのトーク。 RubyMineを使って実際にコードを読んでいく、プレゼンではなくライブコードリーディング。

実はActiveSupport::Concernを題材にしようとしていたとのことでしたが、僕のトークがあったために急遽Sinatraになったようです。 懇親会でごめんなさいしたら「対応できるんで大丈夫です」と超イケメンな回答が返ってきました。

コードリーディングはゴールを見定めにくいのですが、本人に聞いてみたところ「ActiveRecordは同人誌を書くために読んだ」「別にそれがなくても、使っている道具を理解できているメリットが大きいので読む」だそうです。

真のREST

真のREST

@tkawaさんのトーク。 Roy T. Fieldingの博士論文で書かれた本来のRESTを元に、誤解を解いていくお話。

真のREST APIについて「拡張性」と「インターネット規模」を両方満たしていないといけない、ということにハッとしました。 概念として覚えている言葉と、慣習として使っている言葉の間に齟齬があっても、正確に定義を覚えていないとなかなか矛盾には気付けないものです……

Breaking Change

Breaking Change - Speaker Deck

RuboCopとActiveRecord Oracle Enhanced Adapterのコミッタ、@koicさんの基調講演。 破壊的変更が行われる背景、行われた場合の影響、そしてそれへの対処を、実体験を中心に紐解いていくお話。

破壊的変更への対処のところの「一芸は開発を加速する」がものすごくかっこいい。 技術的な意味での「一芸」、やらなきゃ手に入らないのは当然として、全体像を把握しようとしてしまうために身動きが取りにくくなってるのは反省しないといけないかも。

まとめ

  • ActiveSupport::Concernはやっぱりすごい
  • 自信のあるCfPだったので通ってよかった
  • 他の方のトークで自分に足りない部分が浮き彫りになって懇親会でやり方も聞けた

2019年最後、実りの多い勉強会でした。


  1. 機能は大別して2つですが、「モジュールの凝集度を上げる」という単一の目的という認識です

  2. もともと開催は知っていてCfPを出す気は満々だったのですが、全くテーマは決まっていなかった