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 へのパッチは保留とした。

OSS Gate東京ミートアップ2017-07-13

会場係兼任で今月も参加した。

oss-gate.doorkeeper.jp

当日の模様というか雰囲気は、たまたま三脚とカメラを持ち合わせていた yasulab さんがアップされた動画をどうぞ。

今回は継続して参加するメンバーが少しずつ増えてきて良いなと思う回だった。

did_you_mean 1.2.0-alpha を見た

Ruby 2.3 で標準添付になった did_you_mean について、Ruby 2.5.0 に向けたマイルストーンのひとつが実装されていたので見てみた。

github.com

以下のように rake タスクでタイプミスした場合にサジェストがされる機能が加えられている。

Before

% rails db:migrat
rails aborted!
Don't know how to build task 'db:migrat' (see --tasks)

(See full trace by running task with --trace)

After

% rails db:migrat
rails aborted!
Don't know how to build task 'db:migrat' (see --tasks)
Did you mean?  db:migrate
(See full trace by running task with --trace)

did_you_mean 側で prepend を使って Rake を拡張している実装はなるほどだった。