こんにちは、@color_boxです。 仕事でRailsを使っている時にバグに遭遇したのでそれに対してパッチを送りました。
送ったパッチはこちらです。 github.com この記事ではバグ発見からパッチ送信までの過程について書こうと思います。
続きを読む新しいことを覚えてもらうときは実際にやってもらうが大切という話
こんにちは、@aikyo02 です。
今回は仕事で知識の継承とか新しいことをやってもらうときに感じたことを書いていこうと思います。
あるときプロジェクトの私以外のメンバーが次々に入れ替わるという事が起きました。
新たにプロジェクトに入ってくるメンバーは当然プロジェクトのことは知らないので、自分以外のメンバーにも知識を共有する必要がありました。アプリケーションの開発でよく使う部分やコードを読めばわかるようなところは日々の作業で問題なく知識共有が進むのですが、インフラ部分やプロジェクト特有の事務処理等あまり行わないことについては時間がたっても知識共有ができませんでした。
当初はメンバーにアプリケーション開発に慣れてもらうため、そういった部分は私が行っていたのですが、半年くらいたって余裕が出てくると私だけしか知らないことがあるというのはよくないという話が出てきました。(1人しか知らないことがあると休みも取りづらいということもありました)
そこで、ドキュメントを書いて共有会を開いて説明をしましたが、それだけではどうにもうまく行きませんでした。そもそも伝えることが多くドキュメントに書ききれないし、たくさんドキュメントを書いても読まれなくなっていたりメンテナンスされないという問題が私がプロジェクトに入ったときに既に起きていていたのです。
どうするといいかをいろいろと考えた結果、実際にやってもらうしかないと思うようになりました。 やってもらうにはなかなか機会がなかったり、フォローを考えておかなければなりませんが、やっぱり効果は大きかったです。インフラについてはもはや私がいる必要もなくなったかなというところまで知識共有が進みました。
もうひとつ似たようなこととして、メンバーにある機能を任せていたときに当初お客さんに話したリリース時期に間に合わなくなりそうで、私が巻き取ってしまったことがありました。
セキュリティの問題で緊急リリースを行う場合やユーザーの使いはじめる時期が決まっているなどしてリリース日がずらせない場合には仕方のないことですが、このときはそういうこともなかったのでお客さんと話し合って調整すればいいことでした。もっとメンバーに任せたほうがよかったのではないか、機会を潰してしまったのではないかと考えています。
今度はもしそうなっても最後まで任せるという判断をできるようにしたいです。
新しいことを覚えてもらうときは、実際にやってもらうのが一番という話でした。
RubyKaigi Takeout 2020 への登壇とスポンサーのお知らせ
ESM Distinguished Engineer の @koic です。
2020年9月4日(金)、9月5日(土) の2日間で開催される RubyKaigi Takeout 2020 に、私 koic は登壇、株式会社 永和システムマネジメント (ESM, Inc.) はスポンサーをします。
RuboCop 1.0 に向けた私の講演について軽く触れておきます。
RubyKaigi 2020 で講演する予定だったテーマをベースに、春以降から夏までに掛けてのアップデートを含めた内容になっています。
これまでインターネット上に出した情報としては、現状で最も RuboCop 1.0 の姿に近い仕様と実装ベースでまとまっているのではと思います。 本編ではRuboCop のアーキテクチャ、それぞれのレイヤーに分けた視点で話をしていきます (レイヤー名称は説明のために便宜的につけたものです) 。
各レイヤーで行われている開発へのバックボーンの話を中心に、最近だと RuboCop コアから切り出された RuboCop AST の話や、RuboCop がどのように Ruby の新構文への解析をサポートしているかといったトピックから RuboCop 1.0 の姿に迫ります。
一方で RuboCop がどういったものかはあまり取り上げていませんので、そちらを含んだコンテンツとしては RubyKaigi 2018 での講演を参照してください。
なお、今回の RubyKaigi Takeout 2020 向けに録音した際の Known Issue としては、Ruby を JavaScript に変換する Opal について逆に言い間違えていたり、Code smell detector の Reek をバグ検出ツールみたいに言い間違えていた部分がありますが、そのあたりは良い感じに「こいつ間違えやがったなw」くらいに生暖かく聞いてやってください。
RuboCop のライトユーザーから、カスタム Cop を作っている RuboCop マニアまで何かしら Takeout してもらえると良いなといったコンテンツを目指して作ってみました。よければ Takeout しに来てください。
株式会社永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと共生しながら成長したいエンジニアと、そんな価値観を共有しながら前に進んでいけるお仕事を絶賛募集しています。ぜひお声かけください。
Rails / OSS パッチ会オンライン 2020年9月のお知らせ
2020年9月の Rails / OSS パッチ会を 9月10日(木)にオンライン開催します。
この会をひとことでいうと、日頃のお仕事で使っている Rails をはじめとする OSS への upstream にパッチを送る会です。
会には Ruby と Rails のコミッターである顧問の a_matsuda もいますので、例えば Rails に送るパッチのネタがあるけれど、パッチを送るに適しているかの判断やパッチを送る流れが悩ましいときなど a_matsuda に相談して足がかりにするなどできます。
2020年9月9日追記
明日 (9月10日) の Rails / OSS パッチ会のあと 19:00-21:00 で RubyKaigi Takeout 2020 の感想戦をします。パッチ会の流れでリモートで酒でも飲みながら雑談形式で進めていると思います。パッチ会から参加してもらっても良いですし、感想戦からの参加でも結構です。 よければご参加ください。
(追記ここまで)
以下、前回の活動が関わる成果です。
koic: RuboCop
kunitoo: RuboCop Rails
開催時間は 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 に向けた話なんかをしつつパッチを書いたりしているかもしれません。
その他の開催方針については以下の Gist に記していますので、ご参照ください。
実務コードレビューから新卒が得た学び（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!!!
```
加えて、変更理由を意識するとコミットをどんな粒度にすべきか見えてくると思っています。 例えば、リファクタリングと機能追加では変更理由が異なります。前者には「4つのファイルを1つにまとめるため」といった理由が、後者には「ユーザー一覧表の描画を高速化するため」といった理由があるはずです。
したがって、自ずと別コミットに分けるべき変更であることがわかります。機能追加中にリファクタリングしたい別の箇所が見つかったからと言って、1つのコミットに入れないようにします。
逆に、変更理由を意識した粒度のコミットは、git blame や git 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 にパッチを送る会です。
会には Ruby と Rails のコミッターである顧問の a_matsuda もいますので、例えば Rails に送るパッチのネタがあるけれど、パッチを送るに適しているかの判断やパッチを送る流れが悩ましいときなど a_matsuda に相談して足がかりにするなどできます。
開催時間は 17:00-19:00 となりますがご都合のあう方はぜひご参加下さい。Google Meet あたりのテレビ会議システムを使います。
当日の招待 URL は Idobata の esminc/rails ルームで共有する予定です。
特に募集ページなど設けませんが、上記理由から Idobata のアカウントと (TV 会議システムによっては Google アカウント) が必要になると思います。
その他の開催方針については以下の Gist に記していますので、ご参照ください。
みんなでわいわい。「Kaigi on Rails のプロポーザルを考える会」をやりました
最近読んでいる RFC は 791 な @yucao24hours です。
ことし 10 月 3 日に開催される予定の Kaigi on Railsの CFP が、7 月 31 日をもって締め切られました。みなさん、悔いなく提出できましたでしょうか？
利用者数が多い Rails に特化した新たなカンファレンスという事実も然ることながら、オンライン開催となり参加に際して物理的位置に縛られなくなったのもあり、間違いなく多くの方が参加を前提に大注目しているカンファレンスであろうと思われます。
今回アジャイル事業部では、Ruby や Rails 、アジャイル開発に関する講演で数多くの登壇経験がある koic さんのアイディアにより、「Kaigi on Rails のプロポーザルを考える会」というものを実施しました。これがまた期待以上にとっても楽しかったので、その様子をお伝えします。
どんなことしたの？
会の参加の目的は以下のような感じで…
- 実際にプロポーザルを書いてきてクロスレビューする
- 他の人の書くプロポーザルや講演テーマに触発されたい
- それらがどんなものか会自体を社会見学する
登壇に興味のあるメンバーは任意で事前にプロポーザルの下書きを esa に投稿しておいたうえで、当日は Meet でつなぎながら、その esa を見てみんなでクロスレビューをしました（== お互いがお互いにレビューしあう）。
また、プロポーザルを作る過程での悩みごとや迷っていることをその場で相談して、発表方針の改善に役立てることもできました。大勢の観点を交えることのメリットが活きたのではないかなと思います。
会は全部で 3 回開催されましたが、「プロポーザル出すぞ！！！！！１」というメンバーや「みんながどんなことを話してるのか聞いてみたいな」という有志のメンバーがたくさん集まりました。
やってみてどうだった？
わたしの感想としては、なによりもまずこの会自体がすごく楽しくて。
時間の限られた「発表」となると必然的に話題と主旨を distilled することになりますが、それによって発表内容にそれぞれの個性がはっきりと反映されていて、それらを眺めるのがとてもおもしろかったです。
また、プロポーザルと聞くと何となく敷居が高い気がして、自分からは遠いところにある到達点のように感じていましたが、こうしてワイワイ好きな技術の話をすることの延長線だと考えれば実はとっても身近でトライしやすいものなのかもしれない、と思えるようになったのも収穫でした。好きなことの話はいくらでもしたいですからね、たとえば DNS の話とか。
結果として、わたしもプロポーザルを仕上げて提出することができましたので、本当に「プロポーザルを考える会」サマサマです！
成果のほどは...？
気になる実施の成果ですが、最終的に、弊社からはわたしを含め 6 名のメンバーがプロポーザルを提出することができました。
さて、審査の結果やいかに…次回、「スピーカー、決定。」乞うご期待！！！
