自分にやさしく学ぶプログラミング

プログラミング学習記録、備忘録

Kaigi on Rails 2022に参加しました!(2日目レポート )

本日は、Kaigi on Rails 2022 の2日目でした!
引き続き面白くためになるトークが満載でした・・・!
以下レポートです。

1日目レポート

Kaigi on Rails 2022に参加しました!(1日目レポート )

2日目の各トークについてのレポート、感想など

入社数ヶ月の newbie が稼働 7 年超の Rails プロジェクトに"型"を導入して見えた世界 by Fu-ga

新人としてプロジェクトへの型導入を進められた経験をもとに、「newbie こそ型定義するべき」というご自身の考えや、型導入を実際にどのように提案していったかなどを詳しく説明されていました!
型自体の恩恵によってコードを読み解きやすくなっていっただけでなく、型定義を通してプロジェクトの全容把握ができていったり、gem の実装を読むことに抵抗がなくなっていったり、興味の裾野が広がったりと、いろいろな良いことがあったというお話でした!
また、型導入を提案するにあたって、小さく少しずつを意識して、できるだけ他の人に影響がないよう配慮したり、型エラーを全て無くすことより型の充実による開発体験向上の方にフォーカスしたりというポイントを説明してくださいました。
Ruby の静的型を気軽に始めるために、とても参考になる発表でした!

sassc-rails を利用している我々は、Sass の@import の非推奨化をどのように乗り越えていくか by Hirotaka Miyagi

Sass の@import は削除予定であり、@use に切り替えていく必要があるというお話でした!
@use は DartSass のみの機能なので、sassc-rails(LibSass を採用してる)を使っている場合は別のものに差し替える必要があるそうです。
また、実際 gem を差し替えてみたところ、一部 scss の記述を修正しないといけないところもあったそうで、それらについても解説してくださいました。
私は@import が使えなくなること自体恥ずかしながら知りませんでした・・・!実際移行する時参考にしたいと思います!

実践 Rails アソシエーションリファクタリング by Kei Shiratsuchi

巨大な Rails アプリケーションの中で使われていたポリモーフィック関連づけを中間テーブルに置き換えるリファクタリングのお話でした!
すでに運用されているプロジェクトであるため、ダウンタイムなしで置き換えていく必要があったので、新しいデータ構造を追加しつつ、古いデータ構造も残してお互いのデータが同期するような状況を作ったり、抜け漏れ防止のために旧データ構造のインスタンスが作られたことを検知できるような仕組みを作って修正を進めているとのことです。
大規模アプリのデータ構造を修正するのはとても大変そうですが、修正手順が詳しく解説されていました。
自分には想像つかない規模のお話な気がしましたが、実践的な内容でとても参考になりました!
と同時に、やはりそういうことが必要になる前に早いうちにリファクタリングしていきたいと改めて思いました・・・!

ルビイストの目で見た PostgreSQL のデータ型 by Andrey NOVIKOV

似ているけどちょっと違う、RubyRails)と PostgreSQL のデータ型の違いを、一つ一つ丁寧に解説してくださいました!
ちょっと理解し切れなかった部分もありましたが、かなり重要で役立つ内容だったと思います。
恥ずかしながら知らないデータ型もいくつかあったので、 PostgreSQL 改めて勉強したいです!
また、現在私が参加してるプロジェクトで JSON 型のカラムがあるのですが、発表の中で JSON をモデルっぽく扱える store_model gem が紹介されていました。こちらもチェックしたいと思います!

モノリシック Rails アプリケーションをモジュラモノリスへ移行している note の事例 by Hiroya Shimamoto

アプリの大規模化により開発効率が低下しており、高凝集・疎結合なシステムにするために、Packwerkというgemを活用する取り組みのお話でした!
Railsアプリのトップディレクトリ直下にpackagesというディレクトリを置いて、その中でpackageごとにapp, lib, configなどを置いたり、依存関係を管理できるようになるとのことで、マイクロサービス化するよりも手軽にサービスを分割していけるようでした。
ファイルの移動だけで分割していけるのとても良さそうだったので、Packwerk覚えておきたいです!

ActiveRecord::Relation ってなに? by osyo

ActiveRecord で where メソッドなど使用した時に返される ActiveRecord::Relation について、その仕組みをライブコーディングしながら説明してくださいました!
「where しただけでは SQL 発行されない」くらいは理解してたのですが、中身を追いかけてみるとメタプロの技術が駆使されてとても複雑なことが行われているようです。
特に、scope は呼び出した時に初めてクラスメソッドとして定義されて使えるようになるというのが驚きでした・・・!
かつてここらへんのコードを自分で追いかけようとした記憶があるのですが、あまりに複雑で全く理解できず、結局あきらめてしまいました。今回、実際に読み解いていく過程を見せていただけたのでとても参考になりました。アーカイブ出たら改めて動画見ながら一緒にコードリーディングしてみたいです!

十年ものアプリのセッションストレージをクッキーから Redis に移行するときに気にしたこと、それでも起きてしまったこと by hogelog

セッションストレージを CookieStore から Redis に変更する際の流れや、発生した問題についてのお話でした!
セッション数 1000 万オーダーという状況でその管理方法を変更するということで、色々検討し準備の上取り組んだにも関わらず、設定の間違いや非ログインユーザーのセッション情報などにより、一発で上手くはいかず苦労されたという内容でした。
私はこれまでセッション関連の詳細実装やインフラまで考慮が必要な場面に出会したことなく、あまりこの辺の知識ないのですが、考えてみれば rails new しただけでインフラなしでセッションストレージ使えるのって凄いことですね・・・。
改めてセッションのこと学び直したい!

今年できたチームの生産性を向上させたプラクティスの紹介 by Yuki Akamatsu

チームのタスク完了率が低い状況を改善するための取り組みのお話でした!
色々試したなかで、設計を議論するチャンネルの開設、ペアプロ、設計ドキュメントの作成という3つのプラクティスが特に効果的だったとのことでした。
ペアプロは常にやらなくても良い、設計ドキュメントはあくまで一時的な「当時の記録」としての扱いにするなど、チームの状況に合わせて柔軟にルールを設定して取り組まれていたのが印象的でした。
おそらく多くの開発チームが同じような悩みを抱えていると思うし、私が所属するチームにも当てはまるお話で、とても参考になる発表でした!

とりあえず抑えておきたい、Rails での「テストの内容」の考えかた by しんくう

自動テストのいいところは「仕様通りに動くことをいつでも確認できる」ということで、それを確認できるテストコードを書くためにテスト技法を活用しようというお話でした!
発表の中では、同値分割法と境界値分析を使ってテストを書く方法が説明されていました。 具体的な例題をもとに説明されていたので、イメージしやすかったです。
テスト技法は個人的に勉強していたものの、実際テストコード書くときにあまり使えていないので、これを機会に普段の開発の中でも活用していきたいと思います!

自分だけの小さな Selenium「Olenium」を作って始める、ブラウザ自動化技術の理論と実践 by ikuma-t

E2E テストなどでお馴染みの selenium のようなブラウザ自動化ツールについて、その仕組みを理解するために自分だけの「Olenium」「OlayWright」を作ってしまったというお話でした!
各自動化技術の概要説明から始まり、プロトコルや仕様の詳細解説のほか、それを活用して作ったブラウザ操作プログラムのデモをしていただきました。
自動化の仕組みって今まで全く気にしてこなかったので完全にブラックボックスでしたが、例えば webdriver の場合は起動してエンドポイントを curl で叩くとブラウザが操作できたりと、思ったよりシンプルな仕組みなんだということがわかりました。
理解するために作ってみるというムーブ、すごく尊敬します!見習わなければ!

All About Queueing In Rails Applications by Nate Berkopec

サービスの速度改善を考える上で、所定の処理を実行するのにかかる時間だけでなく、ジョブがキューの中に存在する時間を計測しないといけないというお話でした!
Sidekiqのキュー、WEBサーバー上のリクエストのキュー、GVL(Rubyのスレッドの話?ちょっとわからなかった・・・)のキューという3つのキューそれぞれについて、その特徴やキュー時間の計測方法などを解説していただきました。
Sidekiqのキューの分け方について、ドメイン(例えばメール配信、データ移行とか)で分割するのではなく、SLAに基づいた分割(例えば30秒以内、5分以内、1時間以内、1週間以内とか)の方が実用的だし、アラートの設定もしやすいというお話があり、なるほどと思いました!
WEBサーバー上の話やGVLについてはあまり理解できなかったので、改めて勉強せねば・・・。

全体を通して

初級者にもわかるお話しからかなり上級者向けのお話まで、色々な発表を通して多くの学びを得ることができました!日々の開発や勉強に活かしていきたいと思います。
運営の皆様、発表者の皆さま、スポンサーの皆様、素敵なイベントをありがとうございました!
次回は物理開催を目指しているとのことで、すごく楽しみです🙌

Kaigi on Rails 2022に参加しました!(1日目レポート )

本日は、Kaigi on Rails 2022 の1日目でした!
早速素敵なトークが満載でしたので、レポートを書いてみたいと思います🙌

Kaigi on Rails 2022 とは?

Kaigi on Rails のコアコンセプトは 「初学者から上級者までが楽しめる Web 系の技術カンファレンス」 です。 Kaigi on Rails は技術カンファレンスへの参加の敷居を下げることを意図して企画されています。また、名前の通り Rails を話題の中心に据えるカンファレンスではありますが、広く Web に関すること全般(例えばフロントエンドやプロトコルなど)についてもカバーすることで参加者の知見を深め、また明日からの仕事に役立てていただければと考えています

公式サイト より

トークについてのレポート、感想など

(一部都合により聴講できなかったものは抜けてます)

基調講演:あなたと Rails by Yasuo Honda

Railsのメンテナンスポリシーを解説した上で、Railsへのコントリビュートの一つの方法として、手元のアプリケーションのRailsを最新ブランチに合わせて、バグがあればそれを報告するissueをあげたり、修正PRを送るという方法が紹介されました!
Railsへのコントリビュートってめちゃくちゃハードルが高い印象でしたが、確かに最新のRailsがうまく動かないユースケースを報告するというのは比較的簡単そうです。
メンテナンスポリシーも普段ちゃんと見たことなかったですが、例えば今なら6.1.z以下のブランチではバグ修正はなく、セキュリティ対応のみなどのポリシーが設定されているそうです。
今回のトークをヒントに、いつかコントリビュートしてみたい・・・!

お隣さんの API のデータを Rails らしく、しなやかに扱う by Daisuke Aritomo (@osyoyu)

RailsではAPIサーバーを作成する方法はある程度確立されているが、クライアント側の実装についてはまだ確立されているものがないということで、「いい感じのクライアント(≒外部サービスからのデータ取得などをActiveRecordっぽいインターフェースで行えるようにする)の作り方」を解説していただきました!
まずはAPIクライアントとなるクラスを定義してfindメソッドでデータ取得できるようにするところから始めて、eager loading的なことをするために内部でリクエストをキューイングする仕組みを追加していくとのことでした。
そしてさらに発展させAPIクライアントを本物のActiveRecordにしてしまうことで、has_manyなどのアソシエーションも使えるようにするという方法が紹介されました。
最後のは正直あまりイメージできなかった部分もあるのですが、外部からのデータフェッチをActiveRecordっぽくしていくのは確かに良さそうと感じました!

RBS と Steep で始める型のある Rails 開発とその運用 by Shunsuke Yamada

新しいマイクロサービスの開発にRBSを取り入れるために行なったことや、取り入れた結果どうだったかについてのお話でした。
RBS導入にあたり、コストを抑え恩恵を高めるために、ドキュメント整備や自動化といった工夫を行なったとのことでした(とはいえこれらは普段の開発でも行なっていたとのこと)。
また、RBSを自前のコードのもの、gemのもの、RBS Railsにより生成されるものといった具合に分類し、それぞれのメンテナンス方法なども具体的に解説してくださいました。
導入してみて、思ったより低コストでメリットの方が大きいと感じているとのことでした!
私も早く使っていかねば・・・・  

システム開発を支えるメタプログラミングの技術 by Haruka Oguchi

deviseのコードを実際に読みながら、メタプロで実現されている機能を読み解いていく方法が解説されていました!
deviseは自前のクラス名に応じてcurrent_xxxなどのメソッドを提供してくれますが、それらはメタプログラミングによって実現されています。
発表の中では、こうした機能の定義元の探し方などが説明されたり、devise以外にもメタプログラミングが活用されている事例などが紹介されていました。
メタプログラミングはどうしても怖く感じてしまい、これまで敬遠してしまってましたが、「ユーザーごとにちょっと違う」「項目数などが増減する」みたいな状況を共通化できるのは確かに便利そうなので、もう少し歩み寄ってみたいと思いました!

7 つの入金外部サービスと連携して分かった実践的な”状態管理”設計パターン 3 選 by Shohei Mitani

7種類もの外部サービスとの連携を実装する中で得た知見として、状態管理という観点から見た場合の設計パターンを3つにまとめ、それぞれのポイントなどが解説されていました!
パターンとしては、リアルタイム型(決済操作がアプリ内で完結して即時決済される)、事前予約型(アプリ内では支払い予約のみが行われ、後からユーザーがコンビニ支払いなどを行う)、完全非同期型(決済操作は外部サイトにリダイレクトしてそちらで行われる)という3つに分かれるとのことでした。
それぞれ注意すべきポイントがあるのですが、実は事前予約型以外の二つは決済フローの大枠としては事前予約型の一部分とみなせるとのことでした。
トランザクションをどう区切るべきかなど実践的な内容で、とても参考になりました!

森羅万象に「いいね」するためのデータ構造 by Natsuko Nadoyama

WEBアプリとしてよくある「いいね」機能について、いいね対象が異なったり、いいねする側が異なったり(ログインユーザー or 非ログインユーザー)する状況でどういう設計がいいのかというお話でした!
当初はいいねをする側といいね対象の組み合わせごとにテーブルを分けて実装していたものの、結局それらが異なっても「いいね」の振る舞いとしては変わらない上、集計バッチで漏れが発生するなどの問題が生じてしまい、ポリモーフィックを使ってテーブルを共通化するというリファクタリングをおこなったとのことでした。
当初の設計は問題があったものの、実際つくってみたことで「いいね」が単純な構造だったということに気づけたとのことで、やはりまず作ってみるというのも大事なんだなと思いました!

大量塩基配列登録申請システムができるまで by Keita Urashima

研究者が塩基配列のデータ(GB単位の大容量データ)を公開データベースにアップロードしたり、フロントでパースしてブラウザ上に情報を表示するためのアプリを作成したというお話でした!
一般的なWEBアプリに比べてはるかに大きな容量のデータをブラウザ上で扱うという難題に対し「創意工夫とパワープレイ」で乗り越えたというとてもアツいお話でした・・・!
アップロードはActiveStorage のダイレクトアップロード機能で比較的すんなり実現できたとのことですが、ファイルの中身をパースしてブラウザ上のフォームを自動で埋めるような機能を求められ、その実現のために、Streams API、Web Worker、WASMといった技術を活用して工夫を凝らしたとのことでした。
実際デモも見せていただけたのですが、9GBいう大きなファイルを二個同時にアップロードしてもブラウザが固まったリせず、パースも高速(30秒くらい)で処理されていました!
「今まで無理だったもの、諦めていたものを、新しい技術でぶちのめすのがソフトウェア開発の中で最高に気持ちいい瞬間の一つ」と語られていました!
エンジニアとして本当に尊敬します・・・!

実例で学ぶ Rails アプリケーションデバッグ入門 〜ログインできちゃってました編〜 by Masatoshi Moritsuka

フィヨルドブートキャンプ&前職で先輩として大変お世話になった森塚さんの発表です!
業務で携わったアプリで実際に遭遇したホラー話として、「退会したはずがログインできてしまう」という現象について、サンプルアプリを通じてそのデバッグ方法を解説されていました!
コミットごとの動作確認から始まり、source_locationメソッドなどを駆使してwardenの実装まで遡って確認されていました。
原因としては、deviseのcurrent_xxxメソッド使用時に意図せず認証処理が行われていたことだったらしいです。
deviseはよく使ってるだけに怖いですね・・・!よく覚えておこうと思います。
あとsource_location活用していきたい!

3rd Party API on Rails by Tomohiro Suwa

Railsサードパーティ向けのAPIサーバーを作る際の適切なAPIスコープ設計についてのお話でした。
OAuth2.0にスコープというものがあり、それによってユーザーがアクセスできる範囲を制限することができるそうです。
そのスコープの情報をAPIに載せる必要があるようですが、例えばTwitterGitHubなど一般的なサービスではリソース+権限(アクション)で区切られていることが多いとのことで、このようなスコープ設計をするにあたってRailsのcontroller_name, action_nameが便利だったとのことでした。
ちょっとついていけなかったところが多いですが、認証ありの公開APIを作る際はとても参考になりそうな内容でした!

Balance Security and Usability in the Field of 3D Secure by Masato Ohba

WEB上でカード決済を行う際のプロトコルである3D Secureについて、その概要や歴史について解説されていました!
3D Secureの歴史は古く、V1.0が登場したのは20年近く前になるそうです。 当時はまだカード決済に認可の仕組みしかなく、本人認証が行われていなかったとのことです。
しかしv1.0はユーザービリティが低く、普及もいまいちだったらしいです。それが改善されたのが2017年に登場したv2.0で、ここからOTPや生体認証も使えるようになりました(そして今年、v1.0はサポートが終了したとのこと)。
3D Secureによる決済の流れも説明していただきましたが、登場人物が多く、かなり複雑な仕組みになっているようです(登場人物が3つのドメインに分類されるので3D Secureという名前になっている)。
「数千数万の企業がこれだけ複雑なプロトコルに従っていて成立しているのが驚き」とおっしゃっていて、確かにと思いました。
他にも取引のリスク評価のために決済金額などをモニタリングし続ける必要があることなどが説明されていました。
普段よく使っているのにあまり知らなかったカード決済について、少しだけ仕組みを理解することができました!

歴史あるプロジェクトのとある技術的負債を隙間プロジェクトの 210 PullRequests で倒しきった話 by makicamel

7年間運用されてきたサービスについて、隙間時間で技術的負債を返却し続けてとうとうやり切ったというお話でした!
具体的には、アプリの初期段階で導入されていたcrud_controllerというものを撤廃したとのことなのですが、多くのコントローラで使われていた上、暗黙的なコールバックなどもたくさんありかなり手強いものだったようです。
やり切るために、修正をスクリプト化して短い時間かつ断続的でも進められるようにしたり、ボーイスカウトルールをあえて破ってでも変更リスクを減らしたり、みんなの関心ごととなるようにレビュー依頼を出して仲間を増やしたり、進捗の見える化や自ら発信して褒めてもらってモチベーションを保ったり・・・と、いろいろな工夫をされたそうです!倒し切ったの本当にすごい・・・!!
リファクタリングとかついつい後回しにしてしまいますが、大きいものはやはり継続してやっていくしかないし、負債が大きくなりすぎる前に返却していくことが大事だと改めて思いました!

1日目のレポートは以上です!明日も楽しみ!

Kaigi on Rails _2022_ newに参加しました!

本日開催のKaigi on Rails 2022 newに参加したので、感想や印象に残ったお話など書いていきたいと思います。

Kaigi on Rails 2022 newとは?

今月21-22日に開催予定のKaigi on Rails 2022のプレイベントです。
本編に向けたタイムテーブル解説やイベントの歩き方の説明に加えて、RailsにまつわるLTが行われました!

感想・印象に残ったこと

タイムテーブル解説

Kaigi on Rails 2022のタイムテーブルを上から見ていき、各トークのポイントや見どころが解説されました。
全部で24セッションあり、内容はRailsによるアプリ開発の一般的な話題から、実際の事例やそこからの知見、チームビルディングに関わるものなど、いろいろな発表がありそうです!
どれも是非聴講したいトークばかりですが、中でも私は

あたりが特に気になるなと思いました!
(・・・いや・・・やっぱり全部気になる・・・!)

LT

5分ごとのLTが9セッション行われました!
どれも素晴らしい発表でしたし、皆さん時間内にしっかり収めててすごいと思いました!!
以下に特に印象深かったものについての感想を書いてみます。

雑Custom Cop作りのススメ by ydah

自分用のRubocopのcopを気軽に自作しようというお話でした!
やり方が解説されていたのですが、Rubocopはもともとcustom copのためのCLIコマンドを提供しており、コマンド実行だけでリポジトリやcopの雛形が作れてしまうとのことでした!知らなかった・・・。
プロジェクト固有の状況というのはしばしばあると思うので、その場にフィットしたcopを用意できたら効率化が進みそうだと感じました。
一般的に使えそうなものはrubocopにPR出してしまうというのもすごくいいなと思いました!

Railsのコードを読むのは楽しいよ by tanaken0515

Railsのto_jsonメソッドに渡せるオプションを調べる際、Method#source_location, Method#sourceメソッドを使うことで簡単にRailsのコードを読んで調査できたというお話でした。
私は大体の場合コードまで追いかけることなく、ドキュメントや解説記事などで把握できる範囲までで調査を諦めてしまうことが多いので、これらのメソッドを活用して、もう少しコード自体に当たる機会を増やしていきたいと思いました!

Unlimited Rails Web Service by komagata

我らがフィヨルドブートキャンプ(以下、FBC)のkomagataさんによる発表です!
FBCの最終課題である自作WEBサービスが素晴らしいものばかりなので紹介したいという内容でした。
5分という短い発表時間のため、実際にご紹介いただけたアプリは2つでしたが、他にもたくさんいいアプリがリリースされてます!
そしてそれらはこちらのページから見ることができますので、この記事をここまで読んでくださった方、是非ご覧ください!

スプラトゥーンから学んだアプリ開発のヒントについて by gogutan

みんな大好きスプラトゥーンのお話です!
スプラトゥーン2→3で敗北時のリザルト画面やマッチング中の操作が改善されており、それがWEBアプリケーションの開発にも役立てられそうだという内容でした。
私もスプラトゥーンプレーヤーなのですが、プレイした時全く同じことを思いました!
人気のゲームはUIとかも洗練されてる場合が多いので、WEBアプリの参考にできると思います。
せっかくプレイするなら、そういうところにも目を向けて楽しみたいと思います。
あとスライドがスプラっぽくてすごく良かったです!

全体を通して

間近に迫ったKaigi on Rails 2022に向けて、気持ちを盛り上げてくれる楽しいイベントでした!
私も当日に向けて、気になるトークはしっかり予習して臨みたいと思います🙌
運営の皆様、発表者の皆様、ありがとうございました!👏👏👏👏👏

XP祭り2022 楽しかったです!

本日開催のオンラインイベント「 XP祭り2022」に参加しました!
毎年開催されてるイベントで、私は初参加でしたがとても楽しかったので、印象に残った講演などを書いてみたいと思います。

XP祭り2022 とは?

日本 XP ユーザグループ(XPJUG)が主催しているイベントです。 2002 年より毎年秋に開催しています。 当初は、XPJUG コミュニティのスタッフが企画・運営を行ってきましたが、2010 年より運営自体をオープンにし、実行委員形式をとっています。 実行委員は、毎年公募しています。

(公式サイトより)

印象に残った講演

Takeshi Kakeda - XPの旅 〜 そして全体性へ(基調講演)

日本での XP の起りから現在にいたるまでの流れを、ご自身の体験や当時の考え、気持ちと共に語られました。私はエンジニア歴がまだ2年半程度と浅く、それ以前の業界がどんなだったかなど全然知らなかったので、「アジャイルって十数年前はそんな感じだったんだ・・・!」「あの人って昔はそういうことしてたのか・・・!」と、どのお話もとても興味深く聞かせていただきました。
後半はタイトルの通り「全体性」というキーワードについて説明してくださいました。物事を個別にではなく一つの全体として捉えることが重要という内容で、特に「開発者、プロダクト、顧客は一つの全体である」「個人の内側の自己分離を自覚して統合し、個人としての全体性を獲得する」というお話が印象的でした。
また、講演の中ではいろんな書籍が紹介されました。どれも面白そうだったのですが、私は特に「民俗学の旅」「ザ・メンタルモデル」「アジャイル式健康カイゼンガイド」を読んでみたいなと思いました。

Tomonori Yamagoshi - 初心者スクラムチームが陥っていた、間違ったスクラムの見積もり方法とそれに対するカイゼン

業務にスクラムを取り入れた当初、スプリントプランニングのやり方などで間違って認識していたポイントを説明されていました。「スクラムイベントには、本来PBIの見積もりとスプリントプランニングという2種類の見積もりがあるが、これを混同していた」というお話をされていたのですが、私が所属しているチームでも同じ勘違いをしているかも・・・と感じました。今度共有して改善検討したいと思います。
ただ、最後に「スクラムをしたいのではなく顧客に価値提供したい」ということを話されていて、この点はスクラムのルールに囚われて見失わないようにしたいと思いました。

Junichi Kobayashi / Fu-ga kkbn - オンライン時代のペアプログラミング

同じフィヨルドブートキャンプ卒業生のFu-gaさんが参加された発表です!(Fu-gaさん、RubyKaigiで発表されたばかり & Kaigi on Railsの発表も控えてるのにすごい・・・!)
業務で約1ヶ月間のオンラインペアプロをされたということで、その目的や振り返りの説明の他、ライブで実際にペアプロ風景を見せてくださいました(内容は、RubyによるFizzBuzzプログラムをTDDで実装するというもの)。ペアプロしてる様子がとても楽しそうで、私もやってみたくなりました!
質問の時間があったので、「実際業務でペアプロしてみて、一人でコーディングしたときと比べてスループットに違いはありましたか?」と質問させていただいたところ、「同じタスクを一人でやったりはしてないので単純に比較はできないものの、その場で質問や知識共有できたので効率が良かったり、typoなどのケアレスミスに気づけるというメリットがあった」とのことでした!

全体を通して

上記の講演以外にもたくさんの講演(なんと13トラック並列、加えてクロージング直前には怒涛のLTタイムも!!)があり、聴講したものはどれもとても面白かったです(この記事自体、イベント中の「aki matsuno - extreme blogging〜680日ブログを書き続けている理由と継続して得たもの〜」という講演に影響されて書いています)!
また、複数の出版社さんが多くの書籍を献本してくださっており、クロージングではそれらが無料で配布されるという大判振る舞いっぷりでした・・・!私も応募させていただきました🙌
イベント自体がエクストリームを体現していて、「自分もエンジニアとして何かしらエクストリームなことをしてみたい!」と思えるとても楽しいイベントでした。
スタッフの皆様、発表者の皆様、ありがとうございました!👏👏👏👏👏

メモ:Rails で whenever を使うときのschedule.rbの記述

概要

Railsアプリで定期的にrakeタスクを実行するみたいなことをしたくて、wheneverを入れてcronを設定したんですが、wheneverのREADMEの最初の例とか、wheneverize直後のサンプルそのままだと意図通りに実行されませんでした。
schedule.rbに適宜設定を追加すればいいのですが、いつも何を設定すればいいのか忘れてしまう(かつ、設定すべき内容は環境によって多分異なる)ので、備忘録として書き留めておきます。

参考URL

本記事の内容は、下記の記事の内容の複合みたいな感じです。

schedule.rbのサンプル

# Railsモジュールのメソッド使うために必須
require File.expand_path(File.dirname(__FILE__) + '/environment') 

# 使用したいjob_typeに、PATHの設定とrbenvの初期化の記述を入れておかないと、bundleコマンドが見つからなかったり、`Bundler::RubyVersionMismatch`が発生したりする
job_type :rake, "export PATH=\"$HOME/.rbenv/bin:$PATH\"; eval \"$(rbenv init -)\"; cd :path && RAILS_ENV=:environment bundle exec rake :task :output"

# rakeタスク内で日本語を扱う場合(?)、これがないと`encoding::UndefinedConversionError`が発生する
env 'LANG', 'ja_JP.UTF-8'

# デフォルトだとbashが呼ばれるので適宜変えとく
set :job_template, "/bin/zsh -c ':job'"

# デフォルトはproduction環境固定なので、少なくとも開発時はこれ必要
set :environment, Rails.env

# output指定しないとログが見れない
set :output, "#{Rails.root}/log/cron_tab.log"

every 10.minutes do
  rake 'hoge:fuga'
end

みたいな感じにすると意図通りタスクが実行されました🙌

メモ:React 18.0.0 でChakraUIのModalを閉じると他の要素がクリックできなくなった

ChakraUIの勉強してまして、Modalコンポーネントを試していたときにちょっと詰まったところがあったのでメモです。

現象

ChakraUIの公式ドキュメントにあるModalのサンプルを自分のアプリ上に置いてみたんですが、

ボタンクリックでモーダル開く
→ 閉じる
→ 再度ボタンクリックできない
(hoverしても色変わらないしクリックしても何も起こらない、というか画面全体何かで覆われてるようで何もできない)

みたいな現象に見舞われました。

もしかしてChakraUIはReact18まだ使えないのか・・・?と思い、 package.jsonを下図のように変更してyarn installし直したら、Modalを閉じたあとでも他の要素がクリックできるようになりました。 f:id:chihaso:20220408200355p:plain

備考

ChakraUI をインストールした時からブラウザ検証ツールのコンソール上に

ReactDOM.render is no longer supported in React 18. Use createRoot instead. Until you switch to the new API, your app will behave as if it’s running React 17. Learn more: https://reactjs.org/link/switch-to-createroot

の警告が出てはいたので、「対応してないっぽいな」とは思ってたんですが、とりあえず動いてたのでそのままにしてました・・・
やはり警告は無視してはいけない・・・

Rechartsの棒グラフにnullが含まれるデータを渡すと表示がおかしくなる場合の対処法

概要

  • Rechartsで棒グラフ作成時、値がnullであるデータがエリア外に描画される場合がある
  • nullが入りうるような場合は、YAxisのdomainを0が範囲内に入るように設定すると良さそう

参考にしたページ、引用元など

下記に記載しているコードは公式ドキュメントの棒グラフのサンプルをちょっとだけ変更したものです。
また、グラフ画像は同じく公式ドキュメントのcodesandboxのリンク先でコードを実行した結果のスクショです。

経緯

お仕事でRechartsを使ったグラフ描画機能を触っています。
RechartsはReactで使えるグラフ描画のためのライブラリです。
ぱっと綺麗なグラフが描けて、アニメーションもついてるのでいいなぁと思ってるのですが、今回ちょっとした不都合に行き当たりました。
公式ドキュメントにそのような場合についての記述が見つけられず、ちょっと戸惑ったので、解決策を書き留めておきます。

正常に表示できる場合

RechartsではデータをObjectのArrayとして渡します。
例えば下記のようなコードを実行した時、

import "./styles.css";
import React from "react";
import {
  BarChart,
  Bar,
  XAxis,
  YAxis,
  CartesianGrid,
  Tooltip,
  Legend
} from "recharts";

// これがグラフに表示されるデータ
const data = [
  {
    name: "Data A",
    value_1: 1000,
    value_2: 1500
  },
  {
    name: "Data B",
    value_1: 2000,
    value_2: 2300
  },
  {
    name: "Data C",
    value_1: 3000,
    value_2: 2800
  }
];

export default function App() {
  return (
    <BarChart
      width={500}
      height={300}
      data={data}
      margin={{
        top: 5,
        right: 30,
        left: 20,
        bottom: 5
      }}
    >
      <CartesianGrid strokeDasharray="3 3" />
      <XAxis dataKey="name" />
      <YAxis />
      <Tooltip />
      <Legend />
      <Bar dataKey="value_1" fill="#82ca9d" />
      <Bar dataKey="value_2" fill="#8884d8" />
    </BarChart>
  );
}

下図のようなグラフが表示されます。
Y軸(縦軸)は0から3000までのグラフ。左から右へ、Data A, DataB, Data Cの系列が並んでいる。

わかりやすくていいですよね。

値がnullのデータがあると表示がおかしくなる

ところが、ある状況下で表示がおかしくなる場合があります。
その状況というのは、

  • 渡されたデータの中に値がnullであるものがある
  • 他の値が全て負の値である

という場合です。

コード内の変数dataをこの状態に書き換えてみます。
まず、全て負の数にしてみます。

const data = [
  {
    name: "Data A",
    value_1: -1000,
    value_2: -1500
  },
  {
    name: "Data B",
    value_1: -2000,
    value_2: -2300
  },
  {
    name: "Data C",
    value_1: -3000,
    value_2: -2800
  }
];

するとグラフはこうなります。
Y軸(縦軸)は-3000から-1000までのグラフ。左から右へ、Data A, DataB, Data Cの系列が並んでいる。Data A のvalue_1は値が-1000で軸の最大値と等しいため、棒が表示されていない。

この時点でもちょっと嫌ですが、さらに一部の値をnullにしてみると、

const data = [
  {
    name: "Data A",
    value_1: null,
    value_2: -1500
  },
  {
    name: "Data B",
    value_1: -2000,
    value_2: -2300
  },
  {
    name: "Data C",
    value_1: -3000,
    value_2: -2800
  }
];

グラフはこうなります。
Y軸(縦軸)は-3150から-1350までのグラフ。左から右へ、Data A, DataB, Data Cの系列が並んでいる。Data A のvalue_1はなぜかY軸の上端より上に飛び出して棒が表示されている。

軸の外側になんか生えてしまいました。

なぜこうなるのか?

この現象自体への言及は見つけられなかったですが、公式ドキュメントのYAxisの説明によると、Y軸の最小最大をdomainという属性で指定できるようで、これを指定しない場合、デフォルトでは 0 ~ auto の範囲が設定されるようです。
察するに、

  • デフォルトでY軸の範囲は0始まりで正方向に自動で伸びる
  • この範囲外のデータが入ってきた場合、軸の範囲が auto ~ auto に切り替わる(範囲外の値も非表示とはならない)
  • データの中に値がnullであるものが含まれる場合、それは0として読み替えられる。ただし軸の範囲調整が正常に行われず、棒グラフがエリア外に飛び出す(エリア外の0に向かってグラフが伸びる)

という感じになっていると思われます。

どうすればいいか?

Y軸の範囲調整がうまくいっていないようなので、こちらで明示的に指定すれば良さそうです。
その際、0がエリア内に収まるように調整してやります。
例えば上のデータを表示したい場合は、

<YAxis domain={['auto', 0]}/>

のように、YAxisのdomain属性を設定します。
すると、グラフは下図のようになります。
Y軸(縦軸)は-3000から0までのグラフ。左から右へ、Data A, DataB, Data Cの系列が並んでいる。Data A のvalue_1は表示されておらず、すべてのデータが軸の範囲内に表示されている。

軸の外側に飛び出していたものが消えてくれました。

まとめ

というわけで、Rechartsを使用する場合、nullが含まれるデータを渡す場合は軸の範囲設定をしないといけない場合がある、というお話でした。
Recharts、今後も使い倒していきたいなーと思います。