Rails Developers Meetup 2017

Rails Developers Meetup 2017 に登壇枠で参加してきた。会場は SHIBUYA TECH PLAY さん。

今回のイベントでは自分の発表以外に、銅鑼スポンサーの手配をしたりとかしていた。銅鑼運搬、運用の hisas お疲れ様でした。また平野さん、秒速さんはじめスタッフの皆さんありがとうございました。

当日の発表スライドは以下で、この日記では 5 分で話せるわけないだろうといったこのスライドへのページ解説をしてみようと思う。

speakerdeck.com

1ページ

表紙。最近公開されている Fate Heaven's Fees へのオマージュ。連作の発表2つめだったので、UBW っぽい表紙にした。Keynote で発光しているような文字を作るにあたり次のサイトを参考にした。

Keynoteで文字が光っているようにする方法 (Kanasansoft Web Lab.)

2ページ

当日の GitHub アカウントのキャプチャ。草の継続は t-wada の影響ではじめた Write Code Every Day を続けた結果となる。

ちなみに空白の一日があるが、もともとは草が生えていてコードを書いた日ではなく Bundler 2 の RFC にコメントをした日だった。この頃、GItHub でいろいろメンテナンスをしていそうな気配もあったし、コード以外のコメント分について GitHub がデータマイグレーションに失敗したのかも?

https://github.com/koic?tab=overview&from=2017-07-07

3ページ

ActiveRecord Oracle enhanced adapter の宣伝。ちなみに JRuby でも Active Record の master で動く (と思う) 唯一かもしれないアダプターだと思う。

github.com

4ページ

Rails 5.2 の beta が出ているので使って行きましょうという話と、beta で問題を見つけた場合も master で直っている可能性があるので master のヘッドを指定しましょうという話。

5ページ

マージコミットを抜いた Rails の 2017 年コミットランキング。トップ12のうち会場には最後4人居た。

github.com

6ページ

勤務先の宣伝。その1。

7ページ

RuboCop 0.51.0 という今回話すプロダクトとそのバージョンについて。

8ページ

RuboCop 0.51.0 のチェンジログ。全文は以下。

github.com

9ページ

今回発表の三部作の俯瞰。

10ページ

前作第一部サマリー紹介の入り。

11ページ

Fate Heaven's Feel を観た人へのサービスページ。このページのデザインが映画のどの場面かは劇場に足を運んだ人は分かるかもしれない。

12ページ

物語への入り。

13ページ

日頃の Rails アプリケーション開発が発端で、日頃の何気ない事柄から OSS に繋がりますよという話。

14ページ

はじまりのレビューコメント。レビューコメントには新たな Cop を作る機会がたくさん眠っていると思う。

15ページ

第一部の肝。

16ページ

勤務先の宣伝。その2。この勤務先の社是に対する行動の話が第一部になっていた。

17ページ

OSS とその上に乗っているアプリケーション開発の話。問題があれば upstream に還元して、それをアプリケーションで使うと行った図。

18ページ

15ページ目の話が絵物語ではないという証明。

19ページ

第一部 (サマリー) 完。

20ページ

今日の本題である第二部の入り。

21ページ

第二部の入り。その2。

22ページ

第一部の17ページからの続きの話。

23ページ

発表当日に会場で足したページ。

24ページ

Issue の bug ラベルでおもしろそうなものからやってみるのも良い。RuboCop の Issue の bug だとこうなる。

github.com

25ページ

自分が選んだ Issue 。日頃の活動の中で Rails のイベントにあわせて Railsoptions に関わる Issue の話を選んでいた。

github.com

26ページ

問題となっている Cop について。ドキュメントは以下。

Class: RuboCop::Cop::Rails::HasManyOrHasOneDependent — Documentation for rubocop (0.51.0)

27ページ

自分が問題を直した PR の紹介の入り。

github.com

28ページ

バグフィックスを作るためは再現テストを書くことから。

29ページ

Parser gem による AST の話。ある Ruby コードの AST は ruby-parse コマンドで取得できる。以下は例。

% ruby-parse -e "puts 'hello'"
(send nil :puts
  (str "hello"))

30ページ

自作の Ruby AST Visualizer を使った図。これノードの表現にバグがありますね。。。

github.com

31ページ

実装の話を含めて5分とか無理ゲーなので、実装の進め方のリズムの話。

32ページ

実際に出した PR のキャプチャ。

33ページ

Ted さんからのコメント。別の Cop の既存の問題についての言及。

34ページ

言及のあった Style/PredicateName cop の紹介ページ。RuboCop 0.50.0 の時点では、静的なメソッド定義に対してしか offense を検出できなかった。

Class: Rubocop::Cop::Style::PredicateName — Documentation for bbatsov/rubocop (master)

35ページ

言及のあった def_node_matcher についてのページ。define_methoddefine_singleton_method のような動的なメソッド定義を行なう、RuboCop 内部でマッチする AST を定義する API となる。

36ページ

レビューコメントへの自分のレスのキャプチャ。

37ページ

その PR で解決した問題に対して、レビューコメントが解決の範囲外の話題をしているようであれば別 PR にする提案をして太った PR にするのを避けましょうという話。

38ページ

上述のテキストページ。

39ページ

別 PR にしましょうと提案した PR への入り。InternalAffairs/DynamicPredicateName cop という cop 名で提案していた。ちなみに InternalAffairs という部署は RuboCop 開発向けの cop で名前のとおり内部業務用の cop がいる部署なのだった。

github.com

40ページ

設計を URL で表そうという前世紀へのオマージュの図。その既存クラス。

41ページ

既存のクラスから Extract Method を使った設計の図。refactoring.com 的な表現。

Extract Class

42ページ

前ページの前段を踏まえた機能追加の図。

43ページ

y-yagi さんの jpcal の宣伝。この3連休で作ったのが最初の PR だった。

github.com

44ページ

実際の PR のキャプチャ。

45ページ

PR 改善への入り。

46ページ

pocke さんからの提案のキャプチャ。

47ページ

自分のレスのキャプチャ。

48ページ

pocke さんの提案で一番ここが良いと思った感想のテキスト。

49ページ

再実装した PR の入り。

50ページ

PR のキャプチャ。以下、最終的に取り込まれた PR となる。

github.com

51ページ

UML 表現。

52ページ

config/default.yml による published API の定義について。いくつかのスタイルをサポートする cop について、どんなスタイルがあり、どのスタイルをデフォルトにしているかといった情報なんかは、このファイルを見ると分かる。どういうことかというと、ドキュメントにはまだ漏れがあるからこの default.yml なら確実という意味。

github.com

def_node_matcherdef_node_search は RuboCop 内部用のメソッドなので、次ページの .rubocop.yml のみに記述している。

53ページ

RuboCop 本体の .rubocop.yml による internal API の定義について。

54ページ

最初の PR からの改善で何が良くなったのかの話。

55ページ

はじまりのバグフィックスで出した PR とまったく異なる新機能も RuboCop 0.51.0 に入っている。

56ページ

おわりへの導入。

57ページ

OSS ライセンスをつけて公開している段階は public repository としての公開のステップ。

58ページ

ソーシャルレビューによって創発しあって価値が生み出されていくのが面白い。プロダクトによって関わっている OSS 開発者の顔ぶれも違っていて、それぞれのプロダクトの常連さんや一見さん、卒業生 (が残したコード) など含めてコミュニティというのが形成されている。

59ページ

OSS コミュニティのひとつとして Ruby on Rails というのがある。Rails Developers Meetup と Rails の名前を冠しているいべんということで、ここにきて Rails に回帰した話にしている。

60ページ

Rails Developers Meetup らしく、rubyonrails.org のキャプチャ。

rubyonrails.org

61ページ

rubyonrails.org でコミュニティと書かれたリンクを押してみようというページ。

62ページ

リンク先の Rails Contributor のページ。ちょうど Rails 5.2 のベータも出ていることから Edge のページにしておいた。

contributors.rubyonrails.org

ちなみにこのページ自体も Rails コミッターのシャビエルさんが作った Rails アプリケーションだったりする。

github.com

63ページ

OSS への参加が不安なひとは OSS Gate というコミュニティから参加してみるのも手という OSS Gate の宣伝。

https://oss-gate.doorkeeper.jp

64ページ

タイトルの Enter the OSS world に繋げようとしたまとめ。当日はこのページで銅鑼が鳴ってほぼ理想的な終了タイミングとなった。

65ページ

当日お披露目することのなかった次回予告ページへ。

66ページ

当日話したのは三部作の2つめ。

67ページ

次回予告は三部作の3つめ。

68ページ

三部作の仮表紙。Fate Heaven's Feel に倣って、パート1のサブタイトルは「presage flower」→「presage comment」、パート2は「lost butterfly」→「lost boundary」としているけれど、パート3のサブタイトルは公開されていないので名付けられないのであった。

69ページ

RubyKaigi 2017 で「話を聞きにきただけではなくて、何人かの開発者に話しにきた」と yahonda さんに話した際にもらった印象的な言葉。ちなみにこのときに私が RubyKaigi に行って話したかった開発者は普段会えなかったりなかなかな会えない、yahonda さん、nobu さん、pocke さんだった。

70ページ

Ruby らしく end でおわり。amatsuda のプレゼンテーションへのオマージュ。

rspec-railsでのAR::PendingMigrationError時のバックトレースを消す

元ネタは Rails 5.2 で入る kirs さんによる以下の PR となる。

github.com

たとえば、RSpec でテストを実行しようとした際に db:migrate を実行していないものがあるときの振る舞いが以下のとおりになる。

% bin/rspec
Migrations are pending. To resolve this issue, run:

        bin/rails db:migrate RAILS_ENV=test

これまではこの後に読むことのないバックトレースがだらっとついていたので、ノイズが減って良いと思う。

Rails 標準で採用されていない RSpecRails アプリケーションを開発しているケースでは rspec-rails を使っていると思うが、spec/spec_helper.rb か spec/rails_helper.rb で ActiveRecord::Migration.check_pending! あるいは ActiveRecord::Migration.maintain_test_schema! を使っている箇所があれば、以下のように変更することで同様の対応となる。

-ActiveRecord::Migration.check_pending!
+begin
+  ActiveRecord::Migration.check_pending!
+rescue ActiveRecord::PendingMigrationError => e
+  puts e.to_s.strip
+  exit 1
+end

既存の Rails アプリケーションに関してはこのような diff を入れておくと良い。さらに言うと Rails 5.2 へのアップグレードと独立した話なので、いまからでも既存の Rails アプリケーションの spec/spec_helper.rb に手を入れておけば良いと思う。

新規については rspec-rails のテンプレートの方には PR を出してマージされているので、次の rspec-rails 3.7.3 あたりでのテンプレートからそのようになる予定。

github.com

表参道.rb#29

表参道.rb#29に行った。会場は Sansan さん。

omotesandorb.connpass.com

今年の RubyKaigi で Matz のキーノートで取り上げられていたのが module だったことから、module をテーマにどんな話があるのか興味があって開始時間1時間くらい前に申し込んで行った。

中でも cuzic さんによる名前解決に関してのトークは、細かい振る舞いを暗記できていない事柄で irb なんかで確認しないとどうだったっけ?となっている定期コンテンツだったため復習にとても良かった。

懇親会では明後日の Railsdm の準備進捗どうですか?など確認しあったりしていた (進捗大丈夫です) 。

railsdm.github.io

gitのコミットメッセージをそのままPull Request本文に使う

GitHub での Pull Request のテキストには情報が書いてあるが、git のコミットメッセージだと1行目のタイトルしか書かれていないケースがあるが、個人的には git のコミットメッセージをそのまま GitHub の PR のテキストになるようにしておくと捗る。git のコミットが1つの場合はコミットメッセージの 1行目が Pull Request のタイトル、3行目以降が本文になることを活用した設定について書いておく (複数コミットで 1 Pull Request のときは職人の温かみある作業でうまいことやっときましょう) 。

git のデフォルトだと、コミットメッセージを編集するエディタでのコメント行が # になっている。一方で GitHub の Pull Request で文書構造を作る時は Markdown となるため、見出しに使う # がコメント行としてコミットメッセージから消えてたいへん不便。

そこで自分の場合は、^ を git で使うエディタでのコメント行として扱うようにしている。

% git config --global core.commentchar '^'

若干手を入れていたかもしれないが、差分としてはこうなる。

diff --git a/dot.gitconfig b/dot.gitconfig
index 07e3ef8..a95eae6 100644
--- a/dot.gitconfig
+++ b/dot.gitconfig
@@ -30,6 +30,7 @@
        branch = auto
        interactive = auto
 [core]
+       commentchar = ^
        editor = emacsclient -nw -a ''
        excludesfile = ~/.gitignore
 [diff]

コメント行として ^ を使うようにしたのは、# はデフォルトで Markdown の見出し記法と相性が悪いので最初に対象外とした他、!@ などはコミットメッセージでコード例を記したときに、真偽値を反転する !Ruby だとインスタンス変数を表す @ を忘れた頃に行頭に書いてコメント扱いでコミットメッセージから消えてて泣きそうといった理由。比較的行頭に使わなさそうな ^ を選んだ気がするけれど、このあたりはプラットフォームや経験則に応じて選ぶと良さそう。

昨日 RuboCop に出した PR のコミットを実例に挙げるとこうなる。

github.com

.editorconfigを最小限の設定でリポジトリに入れる

先日、RuboCop JP に立てた Issue に pocke さんが回答してくれた話の流れのひとつで、.editorconfig を Rails アプリケーションのリポジトリで管理することにした。

github.com

プログラミング言語やスタイルといった部分を差し引いた、最小のスタートケースでの適用はこんなところだと思っている。

# EditorConfig is awesome: http://EditorConfig.org

# top-most EditorConfig file
root = true

# Unix-style newlines with a newline ending every file
[*]
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true

福岡Ruby会議02の前夜祭のスライドをアップした

福岡Ruby会議02 前夜祭のスライドをアップするにあたり、SlideShare から Speaker Deck に移住するか悩んでいたけれど、昨晩 Speaker Deck にアップした夢を見たので正夢にすることにした。

speakerdeck.com

あとは onk の以下のツイートも背中一押しの理由のひとつだった。

java-ja忘年会

ランチ時にがんこで並んでいたときにハガレンを予約したのは良いけれど、スライド作っていたら開演時間過ぎてたのでチケット代と共にハガレンをあきらめることになった。そんな折り、太一が java-ja 忘年会0次会のツイートをしていたので合流しつつ夕方からグリフォンでビールを飲んでいたりしていた。本編の忘年会後の2次会でふたたびグリフォンに戻って、日曜日ということで電車のあるうちに閉店したのでまっすぐ帰っていたりした。良い忘年会でした。