Rails Developers Meetup #3 で講演した

主催の平野さんから登壇依頼のメールをもらって、二つ返事で回答させてもらったのがはじまり。オファーをもらったときに「育成をテーマに」と言われていたので、主題に悩むことなくストーリーづくりを進めることができた。

rails-developers-meetup.connpass.com

当日のスライドは以下。ここ数年行なっている育成についてまとめるいい機会になったと思う。熱が入りすぎて作り込み過ぎてしまい30分枠のところ40分くらい話させてもらって恐縮でした (るりまへのパッチの話など諸々を結構割愛したけれど、それでも溢れてしまった) 。

www.slideshare.net

余談だけど、英語タイトル『Stairway to The Pragmatic Rails Programmer』は、ご存知 Led Zeppelin の『Stairway to Heaven (天国への階段) 』と本スライドへの引用にもある名著『The Pragmatic Programmer (達人プログラマー) 』を組み合わせたうえ、イベントに合わせて Rails というキーワードを入れたもの。旧新卒氏こと junk0612 に相談してできた名前だけれど、名は体を成すということで最近の育成活動について中々まとまった資料になったのではと思う。

平野さんが当日の Twitter での様子もまとめてくれていて、講演のあとの反響をなるほどなるほどと読むことができました (ありがとうございます！) 。

togetter.com

とても素敵な時間を過ごすことができました。ありがとうございました。

Railsのアップグレードに際して作ったGem

Ginza.rb 第49回の最後のトピックで時間の都合で話さなかった持ち寄りネタ帳として、Railsのアップグレードに際して作った Gem とその背景という形でざっくり記す。

activerecord-oracle_enhanced-adapter-monky_patch_755

https://rubygems.org/gems/activerecord-oracle_enhanced-adapter-monky_patch_755

もともとは、たしか Oracle アダプタ利用での Rails 4.2.0 から 4.2.1 にアップグレードする際に AR の find_by や where でタイムゾーンの時差ずれが起きる問題に対応するパッチを集めた Gem だった。その後、Rails 5 でタイムスタンプ型の変更が入った際に、スキーマの変更を行なうことなく Oracle アダプタを使うことをできるようにという Feature まで持たせて元々の目的を越えた Gem にしてしまった例となる。

例えば、Rails 5.1 でプライマリキーのデフォルトを integer から bigint にみたな話もそうだけれど、アップグレードに際して既存の永続スキーマを変更するのはなかなか重い話になることがあるので、その問題とは切り離してまずはスキーマを除いたアップグレードをできるようにした Gem となる (と書くといい話っぽい) 。

Everlasting

https://rubygems.org/gems/everlasting

Rails 5 で AC::Parameters が HWIDA を継承しなくなったことによるエラーを回避するために作った Gem となる。Rails 4.2 までの Hash として備えていたメソッド呼び出しが残ったまま運用で呼び出された場合に障害となってしまうため、そういった呼び出しの証跡をログに残すに留めて Rails 4.2 までの振る舞いをするようになる。

Screamers

https://rubygems.org/gems/screamers

Rails のアップグレードで RDBMS 型の変換が必要になった際の変換コマンドを提供する Gem で、自分的には activerecord-oracle_enhanced-adapter-monky_patch_755 を消すために作った Gem となる (Rails 5 で RDBMS のタイムスタンプ型の変更に追随する目的) 。特定の RDBMS 型の変換量が多い場合に、手作業で間違えなく行なうことが面倒なため、それ用のマイグレーションファイルを生成するコマンドを追加する Gem として作成した。

これらは主にワークアラウンドを切り出しただけの Gem になるため、これらの Gem すべてが Gemfile から不要になった Rails アプリケーションを目指して行くことになる。

Ginza.rb 第49回

Ginza.rb 第49回 Railsアップグレードの知見を共有しましょうに行った。会場はいつものみんなのウェディングさん。

ginzarb.doorkeeper.jp

y-yagi さんによる Rails のアップグレード手順のお話を中心に、参加者それぞれのアップグレードでの知見が話されたりしていた。

印象的だったトピックを3つ挙げる。

依存 Gem を必要最小限にする

Rails の中の人が見ている Gem (例えば devise) はアプリケーションで余程の手を入れていなければアップグレードの際に問題ないと思うが、そうでない個人 Gem は注意する必要がある (のと、そもそもできるだけ依存を必要最小限にする) 。

非公開 API に依存しない

Rails の公開 API は、ドキュメントが書かれているものであり、nodoc となっているのは非公開 API なのでアプリケーション層で使うものではない。例えば AR の merge! メソッドは非公開メソッドとなる。Ruby の public と private とは別の話であり、Martin Fowler のいう Published Interface かどうかという話がまさにそれだと思う。

config.load_defaults でバージョンを指定する

Rails 5.1 で追加された config.load_defaults は積極的に使って行けると良さそうだと思った (参照) 。

いろいろと知見を得ることができて良い会でした。ありがとうございました。

Git 操作の改善 Tips (2017年上半期版)

git

2017年も下半期に入っていたので、2017年上半期に自身の Git 操作を改善した点を Tip として 3つ挙げてみた。

Tip 1. 作業前に git branch する

作業フローを改善した Tip となる。作業の前に、Pull Request のタイトルになるものを git のブランチ名を付けるというのを以前 kamipo さんに教えてもらった。

作業の前にというのがポイントで、これから行なう作業の目的に対するブランチ名自体が作業メモになる。手元に作業ブランチをいくつか持つような時は、いくらかの時間が経った後でも何がなんの作業を目指していたか分かる。

さらに場合によっては空コミットでやろうとした作業メモを一時的なコミットメッセージとして残せば、git branch -v でやろうとしていた作業が分かって便利。なるほど。

これによって、master 起点での作業途中のものを git stash で凌ぐということが減った。まず何をやろうとしているかゴールを定めて着手するという点からも上手く働くフローだと思う。

Tip 2. リモートに push するときは git push upstream head

作業ブランチを upstream に push する際に、いまいるブランチ名を head という名前で push できることを onk に教えてもらった。実際の話として git push upsteam head の定型句で push できるようになってかなり捗るようになった。

Tip 3. マージ権のあるリポジトリも git remote add upstream <originと同名のURL> しておく

GitHub の OSS リポジトリでの活動では、マージ権 (コミット権) のないリポジトリは fork した upstream に push して、fork 元のリポジトリに追随する時は origin から pull する流れになる。

これは fork をしていない マージ権のあるリポジトリ (特に業務の GitHub だとだいたいそうだと思う) も git remote add upstream <originと同名のURL> しておくという Tip となる (fork ではなく origin と同名の URL という点がポイント) 。

前述の Tip と組み合わせた話として、fork 元からコードを取って来る時は git pull origin <branch-name> として、fork した先にコードを push するときは git push upstream head といった形で、リポジトリを横断して統一した操作にできる。

だいたいの pull ケースは git pull origin master となり、push のケースは git push upstream head の定型で脳と指の筋肉運動への負荷が減って良いと思う。これによってプライベートな業務と OSS で透過的な操作になった。

Rails Developers Meetup #3 への講演ドラフトができた

久しぶりにレイトショーで映画を観るまでの待ち時間で講演準備などしていた。一部過去作からの転用スライドがあるものの、8割以上がスクラッチの新作になったと思う。というか久しぶりの30分以上のロング枠での新作。この流れで3連休中に TokyuRuby会議11 の準備も進めておきたい。

casecmp? が思いのほか遅かった

RuboCop の Cop::Performance::Casecmp cop で autocorrect されるコードとなる str.casecmp('string').zero? がかわいくないので、Ruby 2.4 で追加された casecmp? を使って str.casecmp?('string') と autocorrect されると良いのではと思いパフォーマンスを測ってみた。

gist.github.com

この中では圧倒的に遅かったので RuboCop へのパッチは保留とした。