Ruby

コードを書くのは楽しいのに、そのテストを書くのは億劫——そんなふうに感じたことはありませんか。「1行だけのメソッドなんて、本当にテストが必要？」と考えてしまうのも無理はありません。あまりに些細に見えますし、テストを追加すれば開発時間は2倍、3倍になります。しかも次にコードを変更するときは、テストも一緒に直さなければなりません。見積もり残り時間がわずかなときには、特に「無駄」に思えてしまうものです。 しかし、そうしているうちにテストカバレッジは20%まで落ち込み、コードへのあらゆる変更が「カードタワーの中段を、倒さずに入れ替える作業」のように感じられるようになります。どこかで何かが間違っていた

Railsアプリを開発していると、別のデータストアを使ったほうが簡単に解決できる問題に出会うことがあります。たとえば、サイト内の質問に答えて獲得したポイント数をもとにユーザーをランキング表示するリーダーボードを実装したい場合、Redisのソート済みセット（Sorted Sets）を活用すれば、実装の大部分をRedis側が担ってくれます。とても便利ですよね。しかし、ここで疑問が生じます。Redisとやり取りするコードは、どこに置くべきなのでしょうか？ NG例：Userモデルから直接Redisを操作する まず思いつくのが、Userモデルに直接Redisとの通信を書く方法です。 class U

大きなRailsビューを小さなパーシャル（部分テンプレート）に分割することをためらう方から、よくこんな質問を受けます。「パーシャルのレンダリングには実際どれくらいの時間がかかるのか？」「パーシャル呼び出しによるパフォーマンスへの影響が、コードの可読性向上のメリットを上回ってしまうのではないか？」と。 そこで今回は、シンプルなパーシャルレンダリングとインラインレンダリングを比較するベンチマークを実施しました。この結果をもとに、後半でトレードオフについて考察していきます。使用したのは、まっさらなRailsアプリケーション（config.cache_classes = true を設定済み）です。

Railsのコントローラーで検索、ソート、フィルタリングを実装するのは、意外と面倒な作業です。ElasticSearchやSolrは強力な検索エンジンですが、小規模なアプリケーションにとっては依存関係が大きすぎる場合があります。 幸い、Railsにはスコープ（scope）という仕組みが組み込まれており、シンプルな検索・フィルタリング・ソートに必要な機能の多くをこれだけで実現できます。スコープチェーンを活用すれば、大きな依存関係を導入したり、繰り返しの多い検索コードを自前で書いたりすることなく、必要な機能を構築できます。 スコープを使った検索 例として、商品一覧をテーブル形式で表示するRE

優れた開発者なら、コードにはテストが必要だとわかっています。ところが現実には、テストが省略されたり、雑に済ませられたり、そもそも書かれないまま終わったりすることが少なくありません。ここでは、多くの開発者が陥りがちな「よくある罠」を5つ紹介します。どれも、テストを書く意欲を静かに削いでいく厄介なものばかりです。 1. RSpec？Cucumber？Capybara？Minitest？どれを使えばいい？ 新しいプロジェクトを始めるとき、「最適なテストツール」を選ぼうと膨大な時間を費やしてしまいがちです。しかし、この種の先延ばしは、本当はどこから始めればいいのかわからないという事実を隠しているだ

DRY原則の価値と、その落とし穴 「Dont Repeat Yourself（同じことを繰り返すな）」、通称DRY原則は、ソフトウェア開発者にとって必読の書籍から生まれた、最も価値のある考え方のひとつです。重複したコードをリファクタリングで取り除くことができれば、より汎用的で、より安定したコードを生み出せます。 しかし、いざコードをDRYにし始めると、いくつかの問題に直面することになります。エッジケース（境界条件）をうまく処理できないコード、一般化されすぎて読みにくいコード、そしてどこにあるのか分かりにくいコード——。DRY化のためのリファクタリングが常にうまくいくとは限らないなら、いつリファ

```html rails new を実行した直後、次に何をすればいいのか分からなくなった経験はありませんか?どこから手をつけるべきか。すべてを1つのアプリケーションに書くべきか、それともサービス指向アーキテクチャ(SOA)を採用すべきか。RSpecを学ぶのに良いタイミングなのか。まずデータモデルをすべて設計すべきか、それとも少数の機能をエンドツーエンドで動かすべきか。プロジェクト開始時には決めなければならないことが山ほどあり、迷って先延ばしをしてしまい、フラストレーションを感じたままアプリを完成させられない——そんなことは決して珍しくありません。 この問題は非常によくあるものです。原因は、

```html 先週は、先延ばしを克服して新しいRailsプロジェクトを実際に始めるための3つの習慣についてお話ししました。これで、目の前の作業量に圧倒されることは少なくなったはずです。しかし、まだ難しい決断が残っています。最初にどのコードを書けばよいのでしょうか?認証機能?Twilioと連携する部分?それとも、フォーラムの投稿レコメンダーエンジンには、そもそもどうやって取り掛かればいいのでしょう? そう、いずれ実際にコードを書く必要があります。そのためには、スタート地点が必要なのです。 良いスタート地点とは何か? まずは数分時間を取って、これから構築するシステムについて考えてみましょう

やりたいことは分かっているのに、コードがなかなか言うことを聞いてくれない——そんな経験はありませんか?インデントが深すぎたり、メソッドチェーンが何重にも続いたり、どこか非対称だったり。原因を言葉にできなくても、「何かがおかしい」という違和感だけは残るものです。 そのまま無視して先へ進むこともできます。バックログにはまだ実装したい機能が山ほどありますし、「それほどひどいわけではない」と自分に言い聞かせることもできるでしょう。しかし、それはもったいない判断です。コードの違和感は、あなたに何かを伝えようとしているサインだからです。 違和感に気づけることが、設計力向上の近道になる コードの「変な感じ」

パーシャルキャッシュ（部分テンプレートのキャッシュ）は、あまり手間をかけずにページ表示速度を大幅に改善できる優れた仕組みです。しかし、アソシエーションに touch: true を付け忘れていたり、テンプレートの依存関係が正しく機能していなかったりすると、キャッシュされたパーシャルが更新されないという問題が発生します。 さらに厄介なのは、開発環境では通常キャッシュが無効になっているため、この問題に気づくのがステージング環境、最悪の場合は本番環境になってからだということです。問題をデバッグするには、開発モードでキャッシュを有効にして現象を再現する必要があります。 そのためには、config/

Rubyで何かを実現したいとき、それに対応するGemはたいてい存在します。いや、正確には「数十個」存在すると言うべきでしょう。中には洗練されていて機能豊富、しかも活発にメンテナンスされているものもありますが、作者が一度だけ直面した特定のユースケースを解決するために書かれたものもあります。選択肢が豊富にあるからこそ、「どれが正解なのか」を見極めるのが難しいのです。そしてこの選択は非常に重要です。プロジェクトに導入してから後悔しても、あとで取り除くのは容易ではありません。 まずは数字で絞り込む 問題を解決するライブラリが必要になったとき、私はまずRuby Toolboxを確認します。Ruby

Rails開発者としてのキャリアの中で、「もうプログラミングなんて辞めてしまいたい」と思わせられるコントローラーに、必ず一度は出会うことでしょう。1つの機能のコードがすべてそこに詰め込まれていたり、15個ものbefore_filterがインスタンス変数を使って暗黙のうちに連携し、決まった順序で呼び出さないと動かない——そんなコードです。そして当然のように、そのテストはこんな感じになっています。 test index do get :index assert_response :success end すごい。これでもうテストカバレッジ100%ですよね？ 目をつぶって存在しないふり

（筆者は今週、シカゴで開催されるRailsConfに参加しています。会場でお見かけの際は、ぜひ気軽に声をかけてください。お会いできるのを楽しみにしています。サイドバーの写真で年配の方が私です。） 読者からの質問：「TDD、どう始めればいい？」 ある読者から、記事へのコメント欄でテストに関する素晴らしい質問をいただきました。 「TDD（テスト駆動開発）のフライホイールを回さなければならないのは分かるのですが、TDD自体にあまり馴染みがありません。RSpecを使い始めるのに最適な方法はありますか？それとも、とにかく手を動かして試してみるしかないのでしょうか？」 そこで私は次のように

TDDについて私はこれまで数多くの記事を書いてきました。そんな中、前回の記事を公開したのが、David Heinemeier Hansson（DHH）がRailsConfの基調講演でTDDに言及した瞬間とほぼ同時だったこともあり、いくつか質問を受けました。DHHのTDDに関する見解に同意しますか？今でもTDDを推奨していますか？もし推奨しないなら、代わりに何をすべきですか？DHHが語ったこと基調講演を見逃した方のために、DHHのエッセイがその要点を捉えています：おそらく、業界における自動化されたリグレッションテストの悲惨な欠如を打破するために、テストファーストという直感に反する破城槌が必要だっ

画面の向こうから、あの巨大なif文の塊がじっとこちらを見つめている――そんな経験はないでしょうか?「もっとシンプルにできるはずなのに」と思いつつも、ビジネスロジックが立ちはだかって、なかなか手を出せない。開発者なら誰もが一度は悩んだことがあるはずです。 例を挙げましょう。ある販売プラットフォームで、複数のLineItem(明細)を持つQuote(見積書)を作成するとします。ただし、次のような業務ルールがあります。広告(Ad)であれば、同じ内容の明細が重複しても構いません。一方、ウェブサイト(Website)が複数ある場合は、価格を合計して1つの明細として表示しなければなりません。さらに、「ウ

学びたいことは山ほどあるのに、時間はいつだって足りません。しかも、せっかく確保できた時間は、他の用事に奪われがちです。こうした状況では、Rubyの知識を最新の状態に保つのが難しくなります。 本やスクリーンキャストは優れた学習手段ですが、まとまった時間と集中力が必要です。一方で、皿洗い、通勤、犬の散歩といった日常のタスクは、どうしても退屈になりがちです。そうした時間を思考やリラックスに使うのも悪くありませんが、ほとんどの場合、この「退屈な数分」を何か役立つ学びに充てたいと思うものです。 そんなときに最適なのがポッドキャストです。iOSゲームで遊んだり、何度目かのメールチェックをしたりする代わりに

Railsのブログや書籍、カンファレンスの講演を見ていると、モデルを「スリム」にするためのテクニックが数多く紹介されています。 これらのテクニックは確かに素晴らしいものです。モデルは必ず巨大化・複雑化して手に負えなくなる瞬間が訪れるからです。しかし、本当にそこまでやる必要があるでしょうか？　モデルの責務を永続化・アソシエーション・バリデーションだけに絞り込みたいのでしょうか？そもそも、どれくらいのロジックをActiveRecordモデルに残すべきかは、どう判断すればいいのでしょうか？ スリムに。でもスリムすぎず。 Active Recordは、モデルがデータベースのスキーマと密接に対応し

ソフトウェアを開発していると、書くたびにイライラさせられるコードに出会うことがあります。見た目の醜いコードの断片や、どうしても書き方を思い出せず、コードベースの別の場所から例を探してコピー&ペーストすることになる行など。こうしたものは開発の流れ(フロー)を断ち切ってしまいます。だからこそ、それらに気づき、もっと使いやすくすることが大切なのです。 典型的な例：Railsでのカスタム設定の読み込み たとえば、Railsアプリで独自の設定が必要になる場面はよくあります。アプリ固有の設定項目を追加したいときや、利用しているライブラリがconfig/ディレクトリ内の設定ファイルを読んでくれないときな

（本記事は、もともと筆者のニュースレター向けに執筆したものです。同様の記事をもっと読みたい方は、ぜひご登録ください。） Railsコミュニティはテスト、特にTDD（テスト駆動開発）に強いこだわりを持っています。このテスト文化は、Railsの最も優れた点のひとつです。しかし、「テストを書かなければならない」「正しく書かなければならない」というプレッシャーは、初心者にとって大きな負担になることもあります。 これまでまったくテストを書いてこなかった環境から来た人にとって、TDDは特に難しく感じられるでしょう。TDDをきちんと行うために必要な知識を、ひとつずつ挙げてみてください。 どの機能

Angular vs Ember。RSpec vs Minitest。Haml vs Slim vs ERB。新しいプロジェクトを始めるときには、選択すべきことが山ほどあります。それぞれの陣営には熱心な擁護者がいて、意見は真っ二つに分かれます。そして気づけば、4本目のチュートリアルを読んだり、「SassとLessはどちらが優れているか」を巡る30件ものコメント合戦を読みふけったりしているうちに、プロジェクトを始めていたはずの時間を浪費してしまった——そんな経験はないでしょうか。 では、どうすれば「正しい」ライブラリを選び、実際のコードを書き始めることができるのでしょうか。 あなたは大きなプレッ