ESM アジャイル事業部 開発者ブログ

永和システムマネジメント アジャイル事業部の開発者ブログです。

RubyKaigi Takeout 2020 への登壇とスポンサーのお知らせ

ESM Distinguished Engineer の @koic です。

2020年9月4日(金)、9月5日(土) の2日間で開催される RubyKaigi Takeout 2020 に、私 koic は登壇、株式会社 永和システムマネジメント (ESM, Inc.) はスポンサーをします。

rubykaigi.org

RuboCop 1.0 に向けた私の講演について軽く触れておきます。

RubyKaigi 2020 で講演する予定だったテーマをベースに、春以降から夏までに掛けてのアップデートを含めた内容になっています。

これまでインターネット上に出した情報としては、現状で最も RuboCop 1.0 の姿に近い仕様と実装ベースでまとまっているのではと思います。 本編ではRuboCop のアーキテクチャ、それぞれのレイヤーに分けた視点で話をしていきます (レイヤー名称は説明のために便宜的につけたものです) 。

各レイヤーで行われている開発へのバックボーンの話を中心に、最近だと RuboCop コアから切り出された RuboCop AST の話や、RuboCop がどのように Ruby の新構文への解析をサポートしているかといったトピックから RuboCop 1.0 の姿に迫ります。

一方で RuboCop がどういったものかはあまり取り上げていませんので、そちらを含んだコンテンツとしては RubyKaigi 2018 での講演を参照してください。

rubykaigi.org

なお、今回の RubyKaigi Takeout 2020 向けに録音した際の Known Issue としては、Ruby を JavaScript に変換する Opal について逆に言い間違えていたり、Code smell detector の Reek をバグ検出ツールみたいに言い間違えていた部分がありますが、そのあたりは良い感じに「こいつ間違えやがったなw」くらいに生暖かく聞いてやってください。

RuboCop のライトユーザーから、カスタム Cop を作っている RuboCop マニアまで何かしら Takeout してもらえると良いなといったコンテンツを目指して作ってみました。よければ Takeout しに来てください。


株式会社永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと共生しながら成長したいエンジニアと、そんな価値観を共有しながら前に進んでいけるお仕事を絶賛募集しています。ぜひお声かけください。

agile.esm.co.jp

Rails / OSS パッチ会オンライン 2020年9月のお知らせ

2020年9月の Rails / OSS パッチ会を 9月10日(木)にオンライン開催します。

この会をひとことでいうと、日頃のお仕事で使っている Rails をはじめとする OSS への upstream にパッチを送る会です。

会には RubyRails のコミッターである顧問の a_matsuda もいますので、例えば Rails に送るパッチのネタがあるけれど、パッチを送るに適しているかの判断やパッチを送る流れが悩ましいときなど a_matsuda に相談して足がかりにするなどできます。

2020年9月9日追記

明日 (9月10日) の Rails / OSS パッチ会のあと 19:00-21:00 で RubyKaigi Takeout 2020 の感想戦をします。パッチ会の流れでリモートで酒でも飲みながら雑談形式で進めていると思います。パッチ会から参加してもらっても良いですし、感想戦からの参加でも結構です。 よければご参加ください。

(追記ここまで)

以下、前回の活動が関わる成果です。

koic: RuboCop

github.com

kunitoo: RuboCop Rails

github.com

開催時間は 17:00-19:00 となりますがご都合のあう方はぜひご参加下さい。Google Meet あたりのテレビ会議システムを使います。

当日の招待 URL は Idobata の esminc/rails ルームで共有する予定です。

https://idobata.io/#/organization/esm/room/rails

特に募集ページなど設けませんが、上記理由から Idobata のアカウントと (TV 会議システムによっては Google アカウント) が必要になると思います。

RubyKaigi Takeout 2020 の後ということもあり、Ruby 3.0 に向けた話なんかをしつつパッチを書いたりしているかもしれません。

rubykaigi.org

その他の開催方針については以下の Gist に記していますので、ご参照ください。

gist.github.com

実務コードレビューから新卒が得た学び(Developer Experience 編)

2020年度新卒、くさころ (9sako6)です。Rails アプリケーションのプロジェクトにアサインされてもうじき2ヶ月になり、その間に15くらいの Pull Request (以降、PR)を出しました。PR についたコメントは合計400弱、そのうちのある大きめの PR の Conversation 数は200を超えました (bot を含む)。コメントのほとんどはコードレビューによるもので、先輩方の丁寧で熱心な指導の賜物です。

本記事では、コードレビューを通して私が学んだ知識のうち、 DX: Developer Experience (開発者体験)の向上に不可欠だと思うものをご紹介します。

コミットへの意識

入社した最初の頃に教わったのは「コミットメッセージには変更理由を書く」ということです。

5W1H のうち、"Why" 以外はコミットそのものを見れば明らかです。しかし、"Why" (なぜ)その変更が必要だったかは、コミットメッセージに含めない限り読み取れないことがあります。コードだけでは伝えられない意図を伝えるために、コミットメッセージには変更理由を書くとよいです。

以下、コミットメッセージの例です。1行目にコミットの説明、2行目に空行、3行目以降に変更理由を書いています。

    Fix a BarPerfTool's error when using foo

    BarPerfTool で foo を使うと RidiculousError が起こるため bar を使う。
    ちなみにこれはドキュメントにも書かれていない。

    ```
    RidiculousError: Use bar instead of foo!!!
    ```

koic.hatenablog.com

加えて、変更理由を意識するとコミットをどんな粒度にすべきか見えてくると思っています。 例えば、リファクタリングと機能追加では変更理由が異なります。前者には「4つのファイルを1つにまとめるため」といった理由が、後者には「ユーザー一覧表の描画を高速化するため」といった理由があるはずです。

したがって、自ずと別コミットに分けるべき変更であることがわかります。機能追加中にリファクタリングしたい別の箇所が見つかったからと言って、1つのコミットに入れないようにします。

逆に、変更理由を意識した粒度のコミットは、git blamegit log で履歴を追う際(コードレビュー時、過去実装を参考に機能追加・バグ修正時 etc.)に混乱がなく、十分な情報をもたらすので DX に貢献します。

手元で作業中のコミットは自由にやってよいと思いますが、PR を出す際は他の人が読むコミットになることを考慮して rebase ないし squash で変更理由単位になるよう整理しておきます。

スローテストへの意識

CI 待ち時間が長くても良いことはないので、テストははやくしたいです。そのためにできるコードレベルでの貢献は、無駄な処理をしないことです。

例として、sleep を挙げます。JavaScript で非同期処理する画面のテストの際、描画が完了していない要素へのアクセスが発生することがあります。 その場しのぎ的に sleep 1 といった決め打ちの待ちを挟めば解決できることはありますが、その分だけ確実に実行時間が増えます。 こんな時、Capybara の matcher は要素が見つかるまでループしてくれます。1 非同期処理を待ちたい時、まずは matcher の使用を検討するのが良いと思います。

# 'やる気スイッチ' が見つかるまでループする。
# ループ時間上限は Capybara.default_max_wait_time
expect(page).to have_content('やる気スイッチ')

他に遅さを生み出すのは、E2E テストです。ブラックボックステストなので価値がありますが、ブラウザをエミュレートする分時間がかかります。そこで、E2E テストではなく、Model 等のテストで済ませられないかを考えます。私の場合だと、E2E テストにはゴールデンパスのテストといくつか不安な点のテストを書きます。そして Model のテストでコーナーケースをつついています。

その他の細かい例として、「不要になったテストは消す」「用意するサンプル数を最小限にする」「ページネーションの閾値を下げてテストする」等が挙げられます。

おわりに

私は入社するまで主に一人での開発しか経験しなかったので、チームでの DX を大して意識していませんでした。しかし、入社してからは先輩方の細かく深い視点に驚かされるばかりです。本記事を通して、実務で開発する際に何を意識しているのか、少しでもお伝えできたなら幸いです。

Rails / OSS パッチ会オンライン 2020年8月のお知らせ

2020年8月の Rails / OSS パッチ会を 8月6日(木)にオンライン開催します (こちらでの案内が遅れて明後日の開催です) 。

この会をひとことでいうと、日頃のお仕事で使っている Rails をはじめとする OSS への upstream にパッチを送る会です。

会には RubyRails のコミッターである顧問の a_matsuda もいますので、例えば Rails に送るパッチのネタがあるけれど、パッチを送るに適しているかの判断やパッチを送る流れが悩ましいときなど a_matsuda に相談して足がかりにするなどできます。

開催時間は 17:00-19:00 となりますがご都合のあう方はぜひご参加下さい。Google Meet あたりのテレビ会議システムを使います。

当日の招待 URL は Idobata の esminc/rails ルームで共有する予定です。

idobata.io

特に募集ページなど設けませんが、上記理由から Idobata のアカウントと (TV 会議システムによっては Google アカウント) が必要になると思います。

その他の開催方針については以下の Gist に記していますので、ご参照ください。

gist.github.com

みんなでわいわい。「Kaigi on Rails のプロポーザルを考える会」をやりました

最近読んでいる RFC は 791 な @yucao24hours です。

ことし 10 月 3 日に開催される予定の Kaigi on Railsの CFP が、7 月 31 日をもって締め切られました。みなさん、悔いなく提出できましたでしょうか?

利用者数が多い Rails に特化した新たなカンファレンスという事実も然ることながら、オンライン開催となり参加に際して物理的位置に縛られなくなったのもあり、間違いなく多くの方が参加を前提に大注目しているカンファレンスであろうと思われます。

今回アジャイル事業部では、RubyRailsアジャイル開発に関する講演で数多くの登壇経験がある koic さんのアイディアにより、「Kaigi on Rails のプロポーザルを考える会」というものを実施しました。これがまた期待以上にとっても楽しかったので、その様子をお伝えします。

どんなことしたの?

会の参加の目的は以下のような感じで…

  • 実際にプロポーザルを書いてきてクロスレビューする
  • 他の人の書くプロポーザルや講演テーマに触発されたい
  • それらがどんなものか会自体を社会見学する

登壇に興味のあるメンバーは任意で事前にプロポーザルの下書きを esa に投稿しておいたうえで、当日は Meet でつなぎながら、その esa を見てみんなでクロスレビューをしました(== お互いがお互いにレビューしあう)。

また、プロポーザルを作る過程での悩みごとや迷っていることをその場で相談して、発表方針の改善に役立てることもできました。大勢の観点を交えることのメリットが活きたのではないかなと思います。

会は全部で 3 回開催されましたが、「プロポーザル出すぞ!!!!!1」というメンバーや「みんながどんなことを話してるのか聞いてみたいな」という有志のメンバーがたくさん集まりました。

やってみてどうだった?

わたしの感想としては、なによりもまずこの会自体がすごく楽しくて。

時間の限られた「発表」となると必然的に話題と主旨を distilled することになりますが、それによって発表内容にそれぞれの個性がはっきりと反映されていて、それらを眺めるのがとてもおもしろかったです。

また、プロポーザルと聞くと何となく敷居が高い気がして、自分からは遠いところにある到達点のように感じていましたが、こうしてワイワイ好きな技術の話をすることの延長線だと考えれば実はとっても身近でトライしやすいものなのかもしれない、と思えるようになったのも収穫でした。好きなことの話はいくらでもしたいですからね、たとえば DNS の話とか。

結果として、わたしもプロポーザルを仕上げて提出することができましたので、本当に「プロポーザルを考える会」サマサマです!

成果のほどは...?

気になる実施の成果ですが、最終的に、弊社からはわたしを含め 6 名のメンバーがプロポーザルを提出することができました。

さて、審査の結果やいかに…次回、「スピーカー、決定。」乞うご期待!!!

Git 2.27.0 から git pull をすると表示されるようになった "Pulling without specifying how to reconcile divergent branches is discouraged." について

最近の趣味はもっぱら L7 より下のお勉強、な @yucao24hours です。

梅雨入りもどこ吹く風の暑いある日、いつものように git pull を実行すると、以下のような警告が出るようになりました。

$ git pull
warning: Pulling without specifying how to reconcile divergent branches is
discouraged. You can squelch this message by running one of the following
commands sometime before your next pull:

  git config pull.rebase false  # merge (the default strategy)
  git config pull.rebase true   # rebase
  git config pull.ff only       # fast-forward only

You can replace "git config" with "git config --global" to set a default
preference for all repositories. You can also pass --rebase, --no-rebase,
or --ff-only on the command line to override the configured default per
invocation.
$ git --version
git version 2.27.0

警告を見ると

Pulling without specifying how to reconcile divergent branches is discouraged.

ということで、「分岐したブランチの解決のしかたを指定しないで pull するのはやめましょう」といったことが示唆されています。

どうして警告が出るようになったのか?

こちらは、2020 年 6 月 1 日にリリースされた Git 2.27.0 で新たに表示されるようになった警告のようで、以下はリリースノートからの引用です。

  • "git pull" issues a warning message until the pull.rebase configuration variable is explicitly given, which some existing users may find annoying---those who prefer not to rebase need to set the variable to false to squelch the warning.

github.com

以下が対象のコミットです。

https://github.com/git/git/commit/d18c950a69f3a24e1e3add3d9fc427641f53e12b

コミットメッセージによれば:

Often novice Git users forget to say "pull --rebase" and end up with an unnecessary merge from upstream. What they usually want is either "pull --rebase" in the simpler cases, or "pull --ff-only" to update the copy of main integration branches, and rebase their work separately. The pull.rebase configuration variable exists to help them in the simpler cases, but there is no mechanism to make these users aware of it.

とのことで、 pull --rebasepull --ff-only のふるまいを期待しているにも関わらずそれらの指定をしないまま pull してしまったユーザが、意図しないマージコミットを作ってしまうケースを避けるための警告のようです。

git pull のふるまいを紐解いてみる

git pullを実行したとき、Git はまず git fetch を実行し、そのあとに current branch に対して 事前に git fetch で取得したヘッドをマージするように git merge を実行します。

このとき、Git の設定ファイルの中で pull.rebasetrue もしくは false と明示的に設定されているか、 実行時に --rebase などのオプションが指定されていれば、リモートブランチとの差があったときにはそれらに従って差分が解決されます。

従来は、 pull.rebase の設定がなくて且つ pull 実行時のオプションも指定されなかった場合にはマージコミットを作って解決するというふるまいだったのですが、慣れないユーザがこれを意図しないふるまいとして困らないように、今回の修正をもって明示的に差分の解決方法を Git に教えてあげる方針となったということのようです。

(Git に慣れていないころ、 git pull をしたら突然エディタが開かれてマージコミットのコミットメッセージを編集するよう促され、何が起きたかわからずびっくりした方もいらっしゃるのではないでしょうか。ちなみにわたしはそうでした。)

なお、git pull の詳しい動作については、公式ドキュメントをご覧ください。

git-scm.com

どうするとよい?

先の警告メッセージにもあるとおり、pull したときにリモートブランチと差があった場合のふるまいとして、以下のいずれかの設定を用いて指定するようにすれば警告は消え、Git の意図する状態となります。期待するふるまいにあったものを選びましょう。

git configの公式ドキュメントの pull.rebase の説明 にもありますが、 rebase の動作をじゅうぶんに理解しないまま pull.rebase 設定を使って暗黙的にリベースに関する指定をしておくことは危険な場合があるとされています。ちなみに、わたしは暗黙的な動作によって影響を把握しきれないといけないので pull.rebase false にしましたが、社内には pull.rebase true にしている人もいますし、後述の pull.ff only にしている人もいます。どのような設定が良いかは各自の理解度やユースケースに合わせて決めましょう。

--rebase したいときは実行時に明示するスタイルがいい

こちらを設定すると、デフォルトの pull の挙動のままになります。

$ git config pull.rebase false

実行時の --rebase なしで pull --rebase になってほしい

$ git config pull.rebase true

差分があったら fast forward してほしい (fast forward できないときは失敗してほしい)

$ git config pull.ff only

なお、ここで指定する設定内容をすべてのリポジトリにおいてデフォルトの設定にしたい場合は、 上記の git configgit config --global とすることでグローバルな設定とすることができます。

先ほどのコミットのコミットメッセージにも

This will inconvenience those who never want to "pull --rebase", who haven't had to do anything special, but the cost of the inconvenience is paid only once per user, which should be a reasonable cost to help a number of new users.

とあるように、Git を使い慣れている方々にとってはちょっと冗長に感じられるかも知れませんが、一度設定すればその後は気にしなくてよくなりますので、シュッと設定してしまいましょう!

Rails / OSS パッチ会オンライン 2020年7月のお知らせ

2020年7月の Rails / OSS パッチ会を 7月2日(木)にオンライン開催します。

この会をひとことでいうと、日頃のお仕事で使っている Rails をはじめとする OSS への upstream にパッチを送る会です。

会には RubyRails のコミッターである顧問の a_matsuda もいますので、例えば Rails に送るパッチのネタがあるけれど、パッチを送るに適しているかの判断やパッチを送る流れが悩ましいときなど a_matsuda に相談して足がかりにするなどできます。

以下、前回の活動が関わる成果です。

amatsuda and kamipo: Rails

github.com

koic: Faker

github.com

okuramasafumi: RubyGems

github.com

unasuke: Itamae

github.com

yahonda: ActiveRecord Oracle enhanced adapter

github.com

今回、全体の話題としては RubyKaigi 2020 の中止や、Ruby 2.7.2 でのキーワード引数の分離への警告の動向などがありました。

esa-pages.io

discuss.rubyonrails.org

開催時間は 17:00-19:00 となりますがご都合のあう方はぜひご参加下さい。Google Meet あたりのテレビ会議システムを使います。

当日の招待 URL は Idobata の esminc/rails ルームで共有する予定です。

idobata.io

特に募集ページなど設けませんが、上記理由から Idobata のアカウントと (TV 会議システムによっては Google アカウント) が必要になると思います。

その他の開催方針については以下の Gist に記していますので、ご参照ください。

gist.github.com