Ruby

データモデルが複雑になってくると、APIのレスポンスタイムが悲しいことに1秒近くかかるようになることがあります。そんなときの手軽な解決策が :includes です。モデルのアソシエーションを事前に読み込んでおけば（プリロード）、SQLの発行回数を大幅に減らせます。これだけでかなりの時間を節約できます。 しかし、サイトが再び遅くなり、今度はレスポンスのキャッシュを考え始めます。すると新たな問題が発生します。キャッシュからレスポンスを取得したい場合： results = {lawyer_1: 1, lawyer_2: 2, lawyer_3: 3} cached_objects = Rail

ActiveRecordのコールバックは、モデルのライフサイクルのさまざまな段階でコードを実行できる手軽な仕組みです。 たとえば、Q&Aサイトを運営していて、すべての質問を検索できるようにしたいとしましょう。質問に変更を加えるたびに、ElasticSearchのような検索エンジンへインデックスを登録する必要があります。インデックス処理には時間がかかり、緊急性もないため、Sidekiqを使ってバックグラウンドで実行することになるでしょう。 これはafter_saveコールバックを使う絶好の場面に思えます！そこで、モデルに次のように書くはずです： app/models/questio

もし、あなたのRailsアプリが「誰がアクセスしているのか」を一切判別できなかったらどうでしょう？同じ人が2つの異なるページをリクエストしたことすら分からず、保存したデータはレスポンスを返した瞬間に消えてしまう——そんな状態を想像してみてください。 ほぼ静的なサイトであれば、それでも問題ないかもしれません。しかし、ほとんどのアプリケーションでは、ユーザーに関する何らかのデータを保存する必要があります。ユーザーIDかもしれないし、言語設定、あるいは「iPadでも常にデスクトップ版サイトを表示したい」という好みかもしれません。 こうしたデータの保存先として最適なのがsessionです。複数のリクエ

バグ修正に取り組むとき、一見して手っ取り早い変更が必ずしも最善の解決策とは限りません。また、目の前にあるコードはプロジェクトの物語のすべてではありません。安易な修正の先に進むには、なぜそのような設計判断が下されたのかを知る必要があります。つまり、コードの背後にある歴史を理解することが不可欠なのです。そして、自信を持ってコードを変更するために必要な知識を得るには、3つの優れた方法があります。 git blame git blame を使えば、プロジェクト内のすべてのコード行の変更履歴を、その行が最初に書かれた時点までさかのぼって追跡できます。 例として、ActiveJob の queue_

このようなパターンを見たことがある方は多いのではないでしょうか。メソッドの最後の引数として options ハッシュを受け取り、追加のパラメータをそこに格納するスタイルです。 def hello_message(name_parts = {}) first_name = name_parts.fetch(:first_name) last_name = name_parts.fetch(:last_name) Hello, #{first_name} #{last_name} end 残念ながら、この方法ではハッシュからパラメータを取り出す必要があります。つまり、本来やりた

パフォーマンスが重要な機能であることは、誰もが理解しているはずです。実際、多くのパフォーマンス問題は開発段階で発見し、修正することができます。 しかし、本番環境でしか発生しない遅延にはどう対処すればよいのでしょうか？すべてのコード行にログ出力を仕込む必要があるでしょうか？そんなことをすれば、かえって動作がさらに遅くなるだけです。あるいは「もしかしたら直るかも」という小さなコミットを大量に積み重ねて、当たりを探すしかないのでしょうか？ 実は、コードを汚すことなく解析することは可能です。その鍵となるのが rbtrace です。 実行中のRubyアプリをトレースする rbtraceを使えば、次のよう

小さな機能を実装し終えて、コミット前に統合テストの一式を回そうとします。画面にドットが並んでいくのをじっと待っていると…… ......FF.... :( テストの実行が終わるまでにはまだ数分かかります。しかし、ここで実行を中断してしまうと、どのテストが失敗したのかまったく分かりません。 失敗内容を確認するために、本当に最後まで待つしかないのでしょうか? Ctrl-Tが救ってくれる! Macを使っているなら、テストの失敗を早めに確認する方法があります。 テストの実行中に Ctrl-T を押してみてください。 すると、現在どのテストケースが実行されているのか、そしてそれがどれくらいの時間動き続け

Railsでは、IDがわかっていればデータベースから複数のレコードを簡単に取得できます。 Person.where(id: [1, 2, 3]).map(&:id) # => [1, 2, 3] しかし、取得したレコードを別の順序で受け取りたい場合はどうすればよいのでしょうか？たとえば、検索エンジンが関連度の高い順にIDを返してくるようなケースです。その順序を保ったままレコードを取得するには、どうすればいいのでしょうか。 同じく where を使って次のように書いても、うまくいきません。 Person.where(id: [2, 1, 3]).map(&:id)

最近、Rubyをアップデートしていくつかのプロジェクトをアップグレードしました。その作業の中で、これまで知らなかったRubyGemsの便利な機能をいくつか発見しました。本記事では、その中から特に実用的な3つのテクニックを紹介します。 実行ファイルが古くなったとき 以前はrvmを使ってRubyのバージョンを管理していました。しかし、前回マシンをセットアップした際、rvmなしで運用してみることにしました。BundlerがあればGemsetは不要ですし、Homebrewを使えばRubyを常に最新に保てるからです。 この運用方法はうまく機能します。ただし、Rubyをアップデートした途端に問題が発生しま

テストが不十分なコードを扱うのがどれほど辛いか、経験したことがある人も多いでしょう。バグを1つ直すたびに、新たなバグが5つも生まれる。そして、たまたま動いているように見えても、それが設計どおりの挙動なのか、単なる偶然なのか、確信が持てません。 一方で、小さな機能を1つリリースするために、200個ものテストを書いた経験はありませんか。カバレッジ100%を達成するために、すでに問題なく動いているコードを何度も作り直す。せっかくテストを厚くしたコードほど、かえって読みにくくなっている気がする。そして最悪なのは、アプリ開発そのものに疲れ果ててしまうことです。 どこかにちょうどいい落とし所があるはず

あなたのRailsアプリは遅くなっていませんか？ 本来シンプルに表示されるはずのビューの読み込みに数秒かかるなら、原因を掘り下げて調査すべきサインです。 原因としては、データベースへの呼び出しが多すぎたり、処理の遅いメソッドがあったり、あるいは誰かがコードに仕込んだまま忘れられてしまった無駄なループだったりします。 アプリの遅さの原因を突き止めるためのツールは数多く存在します。以前このブログでもrbtraceについて紹介しましたし、New Relicのrpm gemもアプリの高速化に役立ってくれました。 しかし、私がパフォーマンス問題の調査に最も愛用しているツールは、それ以上のことができるので

Railsアプリを開発していると、膨大な数のgem(ライブラリ)を使うことになります。中には「まるで魔法だ!」と感じてしまうものもあるでしょう。しかし、その魔法は一体どうやって実現されているのでしょうか? 実は、ほとんどのgemが行っていることは、あなたにも決してできないことではありません。それは単なるRubyコードなのです。ときには複雑なRubyコードであることもありますが、そのコードを探検してみれば、魔法の正体が少しずつ見えてくるはずです。 まずはソースコードを見つける gemの仕組みを理解したいなら、何よりも先にそのコードを見つけなければなりません。 特定のメソッドについて詳しく知りたい

Railsコンピテンシーチャートをご覧になったことはありますか？ CodeFellowsのBrook Riggio氏が作成したこのチャートには、現代のRails開発者が知っておくべきすべての概念がまとめられています。一度見てみましょう。 恐ろしいでしょう？まるで200本もの触手を持つ怪物が、あなたに襲いかかろうとしているように見えます。 Railsの学習が尻込みしたくなるのも無理はありません。SQLやデプロイメントのような一部の分野は、それだけで独立したキャリアパスになり得ます。アプリケーションアーキテクチャに何年も費やしても、専門家だと実感できないかもしれません。 しかし、このチャートは正

RubyでAPIラッパーを作るとき、必ず「設定（コンフィギュレーション）」という課題に直面します。ユーザー名とシークレットキーが必要な場合もあれば、ホスト名だけで済むケースもあるでしょう。 設定のやり方にはいくつかのアプローチがあります。では、どれを選ぶべきなのでしょうか？ 手軽だが落とし穴もある「グローバル設定」 まず考えたいのは、サービスをアプリ内のどこからでもすぐに呼び出せる状態にしておくことです。そうしないと、APIを1行使うために3行もの設定コードを書く羽目になってしまいます。 定数やクラス属性を使えば、設定をグローバルにできます。 config/initializers/produ

Railsの根幹にある考え方はもう理解できている。動くコードを書くことにも自信があるし、コードの質、リファクタリング、優れたテストの書き方、オブジェクト指向設計についても学び始めているところだ。 このあたりまで来ると、「自分はちゃんと理解できている」「エキスパートへの道を着実に進んでいる」と感じられるようになるはずだ。振り返れば、ここまで来た道のりの長さが見え、自分の成長ぶりに満足できるだろう。 それなのに、なぜこんなに「遅い」と感じるのか？ テストや保守性、設計を意識するようになった途端、何かを出荷するのに以前よりずっと時間がかかるように思えてしまう。 そもそも、高品質なコードを素早く

Railsを学ぶための本、動画、ポッドキャスト、オンライン講座は数え切れないほど存在します。そのすべてに目を通す時間がある人はいないでしょう! では、まったくの初心者がRubyとRailsを学ぶには、どのリソースから、どの順番で手をつけるのがベストなのでしょうか? 書籍とWebサイト プログラミングがまったく初めてなら、まずChris Pine著「Learn to Program」から始めるのがおすすめです。この本は、知っておくべきプログラミングの核心的な概念を丁寧に解説してくれます。すべてのサンプルコードがRubyで書かれているため、RubyとRailsを学ぶ予定の人には特に最適な一冊で

本記事は、Soonsang Hong氏のご協力により韓国語版も公開されています。 Railsのスコープ（scope）を使えば、条件に合ったレコードを簡潔に取得できます。 app/models/review.rb class Review < ActiveRecord::Base belongs_to :restaurant scope :positive, -> { where(rating > 3.0) } end irb(main):001:0> Restaurant.first.reviews.positive.count Restaurant

「保留中」「承認済み」「フラグ付き」のいずれかの状態を持ちうる質問。あるいは「自宅」「会社」「携帯」「FAX」(もし1982年なら)のどれかに分類される電話番号。 こうしたデータが必要になるモデルは少なくありません。いくつかの候補の中から必ず1つの値だけを持つ属性であり、しかもその値のセットはほとんど変わることがありません。 純粋なRubyで書くなら、ここは単純にシンボルを使う場面です。 PhoneNumberTypeやQuestionStatusといったモデルを作成し、belongs_toの関連でこれらの値を保持する方法もありますが、そこまでする価値はなさそうです。YAMLファイルに押

この記事は、Dohyung Ahnさんのおかげで韓国語版も公開されています。 以前の記事へのコメントで、Thom Parkinさんが素晴らしい指摘をしてくれました。 素晴らしいアドバイスですね。ただ、非常に重要な[最後の]ポイントが一つ抜けています。オープンソースなのですから、ドキュメントが不十分だと気づいた機能の詳細を調べたら、その内容をドキュメントに反映してプルリクエストを送るべきです。そうすればコミュニティ全体が恩恵を受けられますし、貢献者として「コーダーとしての信用」を得られることさえあります! この指摘を挙げてくれたThomさんには感謝しています。それほど重要なことだか

Railsアプリのデプロイ方法を調べると、Apache、Unicorn、Puma、Phusion Passenger、Nginx、Rainbowsなど、数多くのソフトウェア名が登場します。どれも「Railsのデプロイ」関連に見えますが、実は重要な違いがあります。それが「Webサーバー」と「アプリケーションサーバー」の区別です。 それぞれが何者で、システムのどこに位置するのかを理解できれば、デプロイはぐっと分かりやすくなります。とはいえ、この区分は必ずしも明確ではありません。 Webサーバーとは何か?アプリケーションサーバーとの違いは?片方だけで運用できるのか?そしてRackはどこに入るのか