こんにちは、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のバージョンアップに取り組めたことは大変うれしく思います。 こういったことは後回しにすればするほど、ハードルが上がっていく傾向にあるので、常に遅れをとらないようにしていきたいです。
まだバージョンアップ作業は途中ですが、無事全て終えましたらまた本ブログで報告したいです。
--
ユニファでは新たな仲間を積極採用中です。
詳細についてはこちらからご確認ください。
Prerender を Amazon CloudFront で使う
SaaSにおいて「一定期間無料」がペイする条件
ユニファの西川です、こんにちは。
今年の7月からプロダクトデベロップメント本部を離れ、別の新しいことをやってます(何やってるか興味ある方はぜひ面談ご応募お願いします)。
ユニファではCOMFORTABLE ZONEを自ら抜け出ることが大好きな人たちを大絶賛歓迎 & 募集中です。
unifa-e.com
今日は「ある条件に当てはまる時には一定期間無償でSaaSプロダクトを提供する」というありがちな割引やキャンペーン(以下、割引CP)について、
- 割引CPによってどれくらいCVRが上がるならばペイするのか
- 割引CPがペイするには無償期間を何ヶ月以内に収めなければならないのか
…の2点を解析してみたいと思います。
続きを読むCloudFront Functions の使い方を学ぶ
こんにちは、rightgo09 です。今回は CloudFront Functions についてまとめてみます。
続きを読むRust vs Swift - Speed comparison experiment that didn't go according to plan
By Vyacheslav Vorona, iOS engineer at UniFa.
You may have heard of Rust Language, said to be designed for "memory safety and speed". Being an iOS developer, I didn't pay much attention to Rust since we typically use Swift. It by design prevents unsafe behavior in terms of memory usage and is supposed to be, well... swift. However, some time ago I stumbled upon a blog post mentioning Rust as a way to:
- Write cross-platform libraries that can be then linked to both iOS and Android applications (therefore, no need to work on the same stuff twice)
- Delegate weighty jobs to the language that can deal with them faster
So, the second bullet point implies Rust has to be considerably "swifter" than Swift, right? I hope that makes you as curious as myself, as today we are going to compare the performance of two languages using the good old Munchausen numbers calculation and try to figure out who's the fastest here. Fasten your seatbelts (pun unintended).
Disclaimer:
I can't pretend I will do serious research on the topic within the scope of a somewhat short blog post. However, I'm trying to assess Rust's capabilities and figure out whether it is worth it to spend more time studying it or not. I hope you understand :)
