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

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

Kaigi on Rails に koic, 9sako6, yucao24hours が登壇!見どころをご紹介します

ここのところずっと RFC 1912 ばかり読んでいる inexperienced administrator の @yucao24hours です。

10 月 3 日開催予定の Ruby on Rails のカンファレンス、Kaigi on Rails のスピーカー一覧タイムテーブルが公開されましたね。Rails のカンファレンスにぴったりの、汽車とレールを活かしたデザインがとてもかわいい!みなさん、もうチェックしましたか?

kaigionrails.org

わたしたちアジャイル事業部からも複数名がプロポーザルを提出しておりましたが、このたび @koic, @9sako6, @yucao24hours の計 3 名のプロポーザルが採択となり、発表の機会をいただけることになりました🎉

なお、今回のプロポーザルを提出するにあたっては、事業部内の有志のメンバーで集って「Kaigi on Rails のプロポーザルを考える会」を開き、お互いのプロポーザルについてレビューしあいました。 ぜひ以下の過去記事も併せてご覧ください。 blog.agile.esm.co.jp

今回のブログ記事では、登壇が決まったメンバー自らお伝えしたい発表の見どころや、発表をより楽しんでいただくための事前情報をギュッとまとめてお届けします。発表にかける思いの詰まったセルフライナーノーツをぜひお楽しみください。

『TDD with git. Long live engineering.』

発表者

@koic

発表者からひとこと

Martin Fowler, Kent Beck といったパイオニアや Pragmatic Bookshelf などによる出版によって、テスト駆動開発 (とその前に現れたテストファースト) と SCM は現場で広く親しまれるようになりました。

TDD と Git の登場には10年の隔たりがありますが、さらに10年が経過した今日における TDD と Git は有機的な繋がりを持った実践技法となっています。本編ではこれらの歴史と実践を背景に、リファクタリングのリズムに乗った TDD と相性の良い Git コマンドをもちいた TDD with git テクニックを紹介する予定です。

さらに GitHub によって、ブランチの意味合いも「開発トピックのために作るブランチ」「リリースのために作るブランチ」だけではなく「レビューのために作るブランチ」という側面が登場しました。これらによって実現されているソーシャルなリファクタリングと実戦的なコミットの適用についても取り上げます。こちらは、16 年間で 4,200 人以上が開発に関わっている rails/rails リポジトリの運用を参考にし、現場の開発でもちいている Git 術を TDD / リファクタリングと組み合わせて伝えます。

『コードレビュー100本ノックで学んだ Rails リファクタリング』

発表者

@9sako6

発表者からひとこと

本発表では、Rails アプリケーションリファクタリングの Tips をお話しします。 これらの Tips は、実務で開発するなかで歴戦の先輩方にいただいた数百ものコードレビューから学びとったものです。 私の内に秘めておくのはもったいないので、言語化して発表することにしました。

大まかに「commit の意識改革」、「命名」、「分割」、「設計」、「テスト」という観点に分けて、それぞれいくつか具体例を交えながらお話しする予定です。 私のように Rails 歴が長くない方はもちろん、コードレビューや指導をする側の中・上級者の方にも参考にしていただけるのではないかと思っています。

『新ミドルウェア ActionDispatch::HostAuthorization と学ぶ DNS のしくみ』

発表者

@yucao24hours

発表者からひとこと

ウェブアプリケーションのコードを書くことが多い方にとっては、ふだんの開発作業時には DNS のしくみ ―名前解決がどのように行われるのか― を意識する機会はそう多くないかもしれません。(そのせいか、DNS やドメインの世界に関しては「誤解を招く表現」や「事実からかけ離れた説明」がまことしやかに語られているさまが頻繁に見受けられるように感じます。)

かく言うわたしも少し前まではまさに "そこまで意識していなかった人間" で、これらのことについて真正面から向き合って勉強するようになったのはここ半年くらいなのですが、今となっては DNS をはじめとしたインターネット基盤技術について学ぶのが楽しくて仕方ありません。そこから溢れ出た「楽しい!」「おもしろい!」「みんなにも知ってもらいたい!」という純粋な気持ちをこれでもかとばかりにつめこんでプロポーザルをしたためましたので、こうして採択していただけて本当に感無量です。

今回の発表がウェブアプリケーションエンジニアのみなさんにとって、自分のアプリの "外" にちょっと目を向け、ふだんの開発をより広い視野で愉しめるようになるキッカケとなれたら... そして、DNS について正しい知識と理解を広めるための一助となれたらとても嬉しいです。


それでは、3 人の当日の発表にぜひご期待ください!

新しいことを覚えてもらうときは実際にやってもらうが大切という話

こんにちは、@aikyo02 です。

今回は仕事で知識の継承とか新しいことをやってもらうときに感じたことを書いていこうと思います。

あるときプロジェクトの私以外のメンバーが次々に入れ替わるという事が起きました。

新たにプロジェクトに入ってくるメンバーは当然プロジェクトのことは知らないので、自分以外のメンバーにも知識を共有する必要がありました。アプリケーションの開発でよく使う部分やコードを読めばわかるようなところは日々の作業で問題なく知識共有が進むのですが、インフラ部分やプロジェクト特有の事務処理等あまり行わないことについては時間がたっても知識共有ができませんでした。

当初はメンバーにアプリケーション開発に慣れてもらうため、そういった部分は私が行っていたのですが、半年くらいたって余裕が出てくると私だけしか知らないことがあるというのはよくないという話が出てきました。(1人しか知らないことがあると休みも取りづらいということもありました)

そこで、ドキュメントを書いて共有会を開いて説明をしましたが、それだけではどうにもうまく行きませんでした。そもそも伝えることが多くドキュメントに書ききれないし、たくさんドキュメントを書いても読まれなくなっていたりメンテナンスされないという問題が私がプロジェクトに入ったときに既に起きていていたのです。

どうするといいかをいろいろと考えた結果、実際にやってもらうしかないと思うようになりました。 やってもらうにはなかなか機会がなかったり、フォローを考えておかなければなりませんが、やっぱり効果は大きかったです。インフラについてはもはや私がいる必要もなくなったかなというところまで知識共有が進みました。

もうひとつ似たようなこととして、メンバーにある機能を任せていたときに当初お客さんに話したリリース時期に間に合わなくなりそうで、私が巻き取ってしまったことがありました。

セキュリティの問題で緊急リリースを行う場合やユーザーの使いはじめる時期が決まっているなどしてリリース日がずらせない場合には仕方のないことですが、このときはそういうこともなかったのでお客さんと話し合って調整すればいいことでした。もっとメンバーに任せたほうがよかったのではないか、機会を潰してしまったのではないかと考えています。

今度はもしそうなっても最後まで任せるという判断をできるようにしたいです。

新しいことを覚えてもらうときは、実際にやってもらうのが一番という話でした。

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