こんにちわ、サーバーサイドエンジニアのいいだです。
前回はそうめんのおかずについて悩みながらねこを育てました。今回はハッシュドポテトはそもそもおかずになるか否かについて悩みながら自分専用のブラウザ拡張を作ります。
続きを読むTurboStream experiment on Ruby on Rails
By Domingo Cividanes, backend engineer at UniFa.
With the version release of Ruby on Rails new interesting features comes out. But one of this new features really got my attention: Turbo. Turbo allows to send HTML and not JSON over the wire using minimal JavaScript. I was curious how it worked, so I decided to perform one little experiment with one of our applications, so the experiment is more adjusted to a real-case application, and not a single test case.
Let’s put the experiment in context and define its specifications.
続きを読むReview of CTO Night & Day 2022 in Nagasaki
先日 CTO Night & Day 2022 in Nagasaki に参加させていただきました。
CTO Night & Day は AWS さん主催のCTO向け招待制オフサイトカンファレンスで、2020年、2021年はコロナ禍の影響もありオンライン開催となりましたが、今回は3年ぶりに現地開催となりました。私は2018年の金沢開催から参加させていただき、オンラインも含めると今回で5回目の参加でした。
ちなみに2019年の参加時のブログはこちら。
AWS Fargate のタスクにおけるコンテナ間のファイル共有をバインドマウントによって実現する
こんにちは、rightgo09 です。今回は AWS Fargage のコンテナ間でのファイル共有についてまとめます。
よくありそうな例として、Fargate のタスク内にアプリケーションと HTTP サーバを別のコンテナとして設置したいが、アプリケーションが生成した静的ファイルたちは HTTP サーバに直接配信してもらいたい、という場合を考えます。
続きを読むRailsのプロダクションコードを約１万行削除しました
こんにちは。プロダクトエンジニアリング部の伊東です。
現在、私が所属するチームでは、弊社で一番古くから動いているプロダクトのRubyとRailsのバージョンアップを行っています。
記事作成時点では、バージョンアップ作業の途中ですが、着々と進行しています。 現在、不要なコードの削除とテストコードの追加を完了しました。 今後は、サポート対象となっているバージョン（Rubyは2.7系、Railsは6.1系）までアップデートする予定です。
本記事では、弊社のRuby、Railsのバージョンアップの取り組みについて紹介します！
最初に
弊社のプロダクトのサーバーサイドはRailsで作られています。 Railsは定期的に新しいバージョンがリリースされます。（現在の最新は7系）
新しいバージョンにしないと、新しい便利な機能が使えなかったり、セキリティ的な脆弱性を対応できなくなります。
弊社における最も古いプロダクトは、約９年くらい前に作られています。歴史を感じます。 もちろん現役で動作しています。
RubyやRailsの最新バージョンへの追従が出来ないことは大きな問題でした。 また、当時開発していたメンバーが離脱したりで、現状を正しく理解することが困難になりつつありました。 そのため今回の取り組みはスタートしました。
Railsバージョンアップの工程について
Railsのバージョンアップを行うにあたって、まず最初に不要なコードの削除とテストコードの追加を行うことになりました。
なるべくプログラムのコードが少ない方が、バージョンアップ時の影響が少なくなり問題も起きにくいためです。 そして、テストコードがあると、バージョンアップ時に動作に問題が起きた箇所が特定しやすくなります。
また、作業を行うチームメンバーの内２名は今年に入社していただいた方だったので、この作業を通じてプロダクトの知見を高めることもできると思いました。
本題のバージョンアップについては、なるべく細かくバージョンアップ毎に分けてリリースしたいところですが、 Railsのメジャーバージョンアップ毎に分けてリリースする方針となりました。 プロジェクトの期間とリスクの高さの兼ね合いで、一番バランスが良いところを取れたと思います。
実際にあった失敗 〜必要なコードを削除〜
ある関数が不要かどうかを調べる際、コード内で他に使われているか関数名で検索するかと思います。 しかし、下記のようなメタプログラミングでは、単純なメソッド名検索では引っかからないため、誤って削除してしまうことが起きました。
例
bar = 'test' Object.send(hoge_"#{bar}")
上記のようなコードの場合、hoge_testというメソッド名で検索してもヒットしません。 こういったコードがあるかどうかの見極めは難しいですね。。
今回は、リリース前にQAチームの方々に問題を発見していただき、事なきを得ました。感謝です！
また、再発防止のためにも、関数名で検索してヒットするようにリファクタリングを行いました。
成果
タイトルの通り、プロダクションコードを約１万２千行以上削除に成功し、かなりプログラムの見通しがよくなりました。 こんなに不要なコードがあったのが驚きです。 また、テストカバレッジも約５０％から約９０％に向上しました。（※１００％を目指して現在も追加中）
コード削除後のものをリリースした後も、特に問題は起きませんでした。 適切なリファクタリングが行えて良かったです。
チームメンバーのおかげです！本当に感謝です！ 今年入社したメンバーの実力がすごいのでプロジェクトがとても上手く進んでいます！
今回の取り組みを通じて、チームメンバー内でも既存機能の理解度が増えたのも良かったです。 （平行して運用・保守しつつ）約２ヶ月程度要しましたが、チーム内でも最初にやってよかったと振り返りました。
おわりに
プロダクト開発には、やるべきことがたくさんあります。 プロダクトの新機能追加、不具合改修、etc。
そのためプログラムのリファクタリング、ライブラリのアップデートなどは後回しになりがちです。 それらは技術負債として溜まっていき、やがて不具合の発生を高めたり開発効率の低下を招きます。
今回、しっかりと負債と向き合い、Ruby、Railsのバージョンアップに取り組めたことは大変うれしく思います。 こういったことは後回しにすればするほど、ハードルが上がっていく傾向にあるので、常に遅れをとらないようにしていきたいです。
まだバージョンアップ作業は途中ですが、無事全て終えましたらまた本ブログで報告したいです。
--
ユニファでは新たな仲間を積極採用中です。
詳細についてはこちらからご確認ください。
