Ruby

AppSignalでは、Rubyアプリケーション向けのエラー追跡サービスを提供しています。アプリケーションが発生させたすべての例外をキャプチャし、発生した瞬間に開発者へ通知します。 例外処理を正しく実装するのは、実はかなり難しいものです。この記事では、Rubyの例外処理の仕組み、不適切なハンドリングが引き起こす問題、そして例外を適切にrescue(捕捉)する方法について詳しく解説します。 例外をrescueする基本 Rubyで例外をrescueすると、エラーが発生した瞬間にアプリケーションがクラッシュするのを防げます。begin .. rescueブロックを使えば、エラー発生時にアプリケーショ

AppSignalを利用するアプリケーションが稼働しているすべてのサーバーは、30秒ごとにサンプルとメトリクスのコレクションをPush APIへ送信しています。各リクエストにはキーが付与されており、このキーをもとにデータがどのアプリケーションから送られたものかを判別します。そのためには、受信したリクエストごとにデータベースへ問い合わせて該当アプリを検索する必要があります。月間300億件ものリクエストを処理している私たちは、AppSignalをより高速に動かすため、常にクエリ数を削減する方法を模索しています。キャッシュを導入したのにクエリは減らなかったデータベースクラスタへの負荷を軽減するため、

2024年2月25日:例のスクリーンショットと古いリンクを更新しました。 アプリケーションを安定して動作させ続けるためには、システムの負荷を監視することが欠かせません。AppSignalのホストメトリクスでは、複数の時間枠におけるシステムの負荷状況を示す「負荷平均(ロードアベレージ)」を確認できます。また、top、uptime、wといったコマンドでも同じ指標をチェックできます。 では、「負荷平均」とは具体的に何を意味し、その数値はどう解釈すればよいのでしょうか?この記事では、システム負荷の仕組みから負荷平均の読み方、そして効果的な監視方法までをわかりやすく解説します。 負荷平均とは? 負荷平均

Russian dollキャッシング以外にも、Railsアプリのパフォーマンスを高速化するテクニックは数多くあります。今回は、レンダリング済みのページをユーザーのブラウザキャッシュに保存できる、Rails組み込みの「条件付きGET（Conditional GET）」サポートについて詳しく見ていきましょう。 👋 なお、キャッシュ以外のパフォーマンスに関する記事も多数執筆しています。Ruby（on Rails）のパフォーマンス監視チェックリストもあわせてぜひご覧ください。 EtagヘッダーとLast-Modifiedヘッダー ブラウザがRailsアプリのページに対してHTTP GETリクエストを

Rubyには、例外発生後に処理をやり直すためのretryキーワードがあります。しかし、その仲間にあまり知られていないredoというキーワードが存在します。retryがブロック全体を先頭から再実行するのに対し、redoはループの「現在のイテレーション」だけをやり直せる点が特徴です。 redoキーワードの基本 以前のAcademy記事で解説したとおり、retryを使うとブロック内のコードを最初から再実行できます。 begin puts Iteration raise Error! rescue retry end この例では、コンソールに「Iteration」と出力した直後に例外が発生

型強制(タイプ・コアーション)とは、オブジェクトの型を、その値とともに別の型へ変換することです。たとえば、#to_sでIntegerをStringに変換したり、#to_iでFloatをIntegerに変換したりするのがその代表例です。一部のオブジェクトが実装している#to_strや#to_intといったメソッドは、一見すると同じ働きをするように見えますが、実際にはいくつか重要な違いがあります。 この記事では、Rubyにおける明示的なキャストと暗黙的な型強制の違いを掘り下げ、それぞれのメソッドがどのような場面で使われているのかを解説します。 まずは、Rubyで値を別の型に変換する際に最もよく使わ

アプリケーション本体だけを監視していても、システム全体の状況を把握できるとは限りません。サテライトアプリ（補助的なアプリケーション）で動作するサービスが、日々の運用に大きな影響を与えることは珍しくありません。データベースサーバーはその代表例です。また、バックアップスクリプトやその他のバックグラウンドジョブも、システムを遅延させる原因になりながら、見落とされがちです。 Node.js向けAppSignal APM、Ruby APM、Elixir APMは、アプリケーション自体を自動的に計測（instrument）します。しかし、デフォルトではAppSignalはこれらのサテライトプロセスを監視し

Rails 7の公開が目前に迫っています。正式なリリース日は確定していませんが、クリスマス前には利用可能になると予想されており、もうすぐそこまで来ています。 本記事の執筆時点での最新バージョンは7.0.0.rc1、つまり最初のリリース候補版(RC)です。Basecamp、HEY、GitHub、Shopifyといった大手企業がすでに本番環境でRails 7のアルファ版を稼働させているため、リリース候補版もかなり安定していることが期待できます。 この記事では、Rails 7がもたらす新機能と変更点について詳しく見ていきます。 Node.jsとWebpackが不要に そう、お読みの通りです!Rai

この記事では、Railsアプリケーションにおけるデータベースのパフォーマンスをテストする方法と、よくあるデータベース性能問題への具体的な解決策を解説します。 Railsアプリケーションを開発する際、データベース操作はデフォルトでActiveRecordが担当します。ActiveRecordは.where、.save、.create、.updateといった直感的なコマンドで、データの取得や登録を手軽に行える強力なインターフェースです。RailsがこれらのコマンドをSQLクエリへ自動変換してくれるのは大きな利点ですが、その裏側では意図しないパフォーマンス問題が発生することもあります。開発者としては

多くのWebアプリケーションは、何らかのデータストア、多くの場合リレーショナルデータベースを使用しています。Webアプリが成功すると、気づかないうちにデータベースへ「データを溜め込む」状態になりがちです。しかし、このデータの溜め込みは、テーブルの行数と保存データサイズの両方における無制限な増大につながります。ある程度までは問題なく動作しますが、データ肥大化を未然に防ぐこと、あるいは防げない場合でもインフラを事前に計画して成長に適切に対処することが非常に重要です。本題に入る前に、アプリケーションがどのように肥大化していくのかを見てみましょう。データは多ければ良いというものではない私たちが手がける

メール送信、定期的なクリーンアップ処理など、ユーザーの待機を必要としない時間のかかる操作には、ほとんどのアプリケーションでバックグラウンドジョブが欠かせません。 Railsの世界には、ジョブキューとバックグラウンド処理をサポートするGemが複数存在します。中でも特に人気が高いのが「Delayed Job」と「Sidekiq」の2つです。 この記事では、Delayed JobとSidekiqについて詳しく解説し、両者をさまざまな観点から比較していきます。 それでは始めましょう! Delayed Jobとは Delayed JobはShopifyのコードベースから抽出されたライブラリで、データベー

「テストが速すぎて困る」という不満を耳にしたことがあるでしょうか?おそらく一度もないはずです。 テストが速いということは、フィードバックも速いということです。ローカル環境でもCIパイプラインでも、テストが早く完了するほど、失敗に素早く気づき、コードを迅速に改善できます。生産性の向上に加えて、遅いテストが開発者を不機嫌にさせることもよく知られています。不機嫌な開発者を好む人はいませんよね。 とはいえ、稲妻のように速いテストスイートを作るのは、期待ほど簡単ではありません。幸いなことに、Rails 6では並列テスト(parallel testing)という強力な機能が標準搭載されました。導入は非常に

Rails開発者が直面するデータベース問題の中でも、データ整合性(データインテグリティ)の問題は最も一般的なものの一つです。適切なバリデーションを行うだけでなく、正しく設計されたトランザクションブロックを使えば、データが部分的に作成・更新されてしまう事態を防ぐことができます。 しかし一方で、トランザクションは設計を誤るとアプリケーションに悪影響を及ぼし、最悪の場合データベース全体をダウンさせてしまうこともあります。 本記事では、トランザクションを扱う際の良いプラクティスを紹介します。どれもシンプルなTipsですが、トランザクションを堅牢で読みやすく、比較的安全なものにする助けになるはずです。

Railsの「電池込み（batteries-included）」なアプローチは、このフレームワーク最大の強みのひとつです。アプリケーションを素早く立ち上げられる手軽さでは他の追随を許さず、その理由のひとつがRailsのジェネレーターにあります。Railsを使ったことがあれば、ジェネレーターにはきっとお世話になったことがあるはずです。新しいアプリケーションを作りたいならrails new。モデルやビューをまとめてスキャフォールドしたいならrails generate scaffold。このほかにも、開発を迅速に始めたりワークフローを効率化したりするためのコマンドが数多く用意されています。しかし、

ソフトウェアエンジニアに本番コードの重要な部分をレビューしてもらえば、必ずと言っていいほど「リファクタリングが必要な箇所」を複数挙げられます。それにもかかわらず、なぜこれほど多くの品質が低いコードや壊れやすいコード、誰にも完全に理解されていないコードが本番環境で動き続けているのでしょうか?答えはシンプルです。エンジニアがそのコードに触れるのを恐れているからです。リファクタリング作業は課題として認識され、バックログに追加されますが、現在のスプリントに組み込まれることはほとんどありません。理由はさまざまです。コードが何年も前にチームを去ったエンジニアによって書かれたもので、誰も全体像を把握していな

オブジェクト指向プログラミング(OOP)でアプリケーションを開発したことがあるなら、ポリモーフィズムを実際に使ったことがあるか、少なくともその用語は耳にしたことがあるでしょう。 科学やコンピュータサイエンスの教科書に登場しそうな言葉です。調べてみたことはあっても、概念をきちんと理解しないまま実装してしまった、という経験がある方もいるかもしれません。 この記事では、特にRuby on Railsにおけるポリモーフィズムへの理解を深めていきます。取り上げるトピックは以下の通りです。 現実世界におけるポリモーフィズム OOPにおけるプログラミングのポリモーフィズム Railsアプリケーションに組み

こんなシナリオを想像してみてください。あなたはRails開発者で、ここ数日かけて全員が待ち望んでいる素晴らしい機能を開発していました。規模は大きく複雑でしたが、厳密なテストを経ているので、すべてが期待どおりに動作すると確信しています。納期もあるため、そのままデプロイ。すると、瞬く間に大混乱に陥ります。 新機能が原因で、一部のユーザーに対してアプリ全体が動かなくなってしまったのです。理由もよく分かりません。テスト中にはバグは一切出ていなかったのに。変更をロールバックしても、被害はすでに出ています。顧客は不満を抱き、あなたは当面の間、ダメージコントロールと原因調査に追われることになるでしょう。 問

現在、HotwireはRails開発者の間で最もホットな話題のひとつです。Railsで開発をしている方なら、すでに耳にする機会が多かったのではないでしょうか。Hotwireは、ごくわずかなコード量でアプリケーションにインタラクティブ性を追加できるまったく新しいアプローチです。HTMLをそのままネットワーク経由で送信することで驚異的な速度を実現します。つまり、SPA（シングルページアプリケーション）フレームワークに手を染めることなく、レンダリングロジックをサーバーサイドに一元化しながら、高速なページ表示とリッチな操作性を両立できるのです。この記事では、Hotwireの主要コンポーネントと、Rai

本記事では、Ruby on RailsアプリケーションにCapistranoを導入し、クラウドインスタンス(Ubuntu OS)へデプロイする手順を詳しく解説します。ホスティングプロバイダーに依存しない構成なので、任意のクラウドサービスやオンプレミスサーバーを使って、ここで紹介する手順をそのまま再現できます。 アプリのデプロイ後には、AppSignalを使ってデプロイ状況をモニタリングする方法についても簡単にご紹介します。 その前に、まずは「なぜCapistranoを使うべきなのか?」という疑問にお答えしましょう。 なぜRailsアプリにCapistranoを選ぶのか? 近年はデプロイやCI(

メモリリークとは、意図せず制御不能に、際限なくメモリ使用量が増え続けてしまう現象です。どれほど小さなリークであっても、最終的にはプロセスがメモリを使い果たしてクラッシュを引き起こします。クラッシュを避けるためにアプリを定期的に再起動している場合でも(責めるつもりはありません、筆者もやったことがあります!)、メモリリークによるパフォーマンスへの悪影響は残ったままです。 この記事は、メモリリークをテーマにした2部構成シリーズの第1回目です。まずRubyがどのようにメモリを管理しているのか、ガベージコレクション(GC)がどのように動作するのか、そしてリークを見つける方法について見ていきます。 第2回