Ruby

Railsアプリをいくつか作っていると、自然と自分なりの好みの作業スタイルが固まってくるものです。例えば、Railsコンソールでは常にawesome_printを使いたい、rails newで生成するプロジェクトにはminitestではなくrspecを使いたい、といった具合です。 コマンドを実行するたびにこれらの設定を指定するのは、確かにそれほど大きな手間ではありません。しかし、うっかり忘れてしまうことも多いものです。そして、自分が指示したつもりのことがコンピュータに実行されないときほど腹立たしいものはありません。 $ rails new best_app_ever ^C (ため息...) $

この記事で紹介するアイデアの多くは、筆者のお気に入りのRuby書籍『Confident Ruby』から学んだものです。この記事が気に入ったら、ぜひ本書を手に取って全文を読んでみてください。素晴らしい内容がぎっしり詰まった一冊です。 あなたの current_user メソッドは User オブジェクトを返します。ただし、ユーザーが存在しない場合は nil を返します。また、search メソッドは結果の Array を返しますが、結果が1件だけの場合は、その単一の結果だけを返します。一見すると合理的に思えますよね?むしろ便利にさえ感じるかもしれません。 しかし、こうした設計判断は、やがてコ

先週は、戻り値が一貫しているメソッドについて取り上げ、それがコードをシンプルにすることを紹介しました。しかし、そもそもなぜ適切なリファクタリングを行うとコードが扱いやすくなるのでしょうか？ 良い抽象化と悪い抽象化の違いはどこにあるのでしょうか？ 闇雲にコードを並べ替えるだけで、質の高いソフトウェアが生まれるわけではありません。 こうしたテクニックがなぜ機能するのかを理解できれば、コードのどこに手を加えるべきかが見えてきます。そして、最も効果を発揮する場所で、適切なツールを使えるようになるのです。 ソフトウェア開発における最も難しい問題とは？ 「コンピュータサイエンスにおける難しい問題は2つだ

良質で無料のRails情報は世の中にたくさんあります。しかし、開発スキルが上がってくると、自分にとって役立つ知識を見つけるのが意外と難しくなります。 レベルが低すぎれば、すでに知っていることばかり読むことになります。逆に高すぎると、目が滑り、頭がついていかなくなり、3段落読んだ頃には自分の名前すら思い出せなくなってしまう——そんな経験はないでしょうか。 「中級者向けRailsブログ」といったキーワードをGoogleに入力して、良いサイトがヒットするのを待つだけでは不十分です。欲しい情報にたどり着くには、自分で掘り下げていく必要があります。 見つけて、ふるいにかける まずは「広く浅く」探

APIドキュメントは、APIの基本的な使い方を教えてくれます。しかし、問題が発生したときのことは、ほとんど書かれていません。エラーメッセージは不完全だったり、誤解を招いたり、まったく役に立たなかったりしがちです。そもそも、NoMethodError: undefined method [] for nil:NilClass なんてメッセージを目にしたとき、一体何をすればいいのでしょうか? APIやフレームワーク、ライブラリを学ぶとき、順調に動いているときの使い方だけ覚えていては不十分です。 エラーが返ってきたときにどう対処すべきかも、あらかじめ把握しておく必要があります。 コードの壊し方 使っ

（この記事は以前、メーリングリストの読者向けにお送りしたものです。気に入っていただけた方は、ぜひ登録して続きをお読みください。） Railsエコシステムは動きがとても速く、紙媒体の出版スピードでは到底追いつきません。私と同じように、常にフレームワークやgemの最新バージョンを学びたいと思っていても、質の高い学習リソースは数バージョン前のものだったりします。 しかし、そうした少し古いリソースでも十分に役立ちます。丁寧に編集された本、スクリーンキャスト、チュートリアルほど、ライブラリのAPIや設計思想、全体構造を効率よく学べるものはありません。 たとえば、最高のRails本がRails 4.

メモ化（Memoization）は、アクセサメソッドを高速化するためのテクニックです。時間のかかる処理、つまり一度だけ実行すればよい処理の結果をキャッシュします。Railsではメモ化が非常によく使われており、かつてはメソッドを自動的にメモ化してくれるモジュールまで標準で組み込まれていました。 その後、このモジュールは賛否両論がありながらも削除され、最初に紹介するごく一般的なメモ化パターンを使うことが推奨されるようになりました。しかし、この基本的なパターンではうまく動かないケースがあるのです。そこで今回は、より高度なメモ化パターンを見ていきながら、Rubyの興味深い機能についても学んでいきましょ

コードをテスト駆動で書きたいのに、なかなか手が動かない——そんな経験はありませんか?オブジェクトのインターフェースをどう設計すべきか確信が持てなかったり、晴れた夏の日に気を取られたり。「そもそもこのアイデアはテストできるのか?」と不安になったり、単純に今はテストを書きたくなくて先延ばしにしていたりすることもあるでしょう。では、TDDの気分になれないとき、どうすればTDDの恩恵を受けられるのでしょうか? プロトタイピング――捨てる前提で一度作ってみる 「新しいシステムの概念や新しい技術を使う場合には、捨てるためのシステムを作らなければならない。どんなに優れた計画でも、最初から正しくやり

Railsのチュートリアルをいくつか終えて、講座を受けたりスクリーンキャストを見たりしながら、サンプルアプリの模写もこなしてきた——そんなあなたは、そろそろRails開発を次のレベルへ進めるタイミングにいます。 しかし、なぜか行き詰まってしまうものです。初心者向けには膨大な数の書籍、講座、動画があるのに、中級Rails開発者向けのチュートリアルはどこにあるのでしょうか？ 以前とは状況が違う Rails開発者としての「基礎知識を身につける」段階を超えると、学習リソースは急激に減っていきます。なぜなのでしょうか？ 中級Rails開発者になることは、初心者の頃とはまったく別のプロセスです。単に難易度

ポッドキャスト出演のお知らせ 先週、「Ruby on Rails Podcast」にゲストとして招かれました。番組では、このブログやメーリングリストで執筆している記事のこと、書籍の執筆、習慣づくりのコツ、そして多くの人がつまずきやすいポイントなど、さまざまなテーマについてお話ししました。 番組で取り上げた主なトピック ブログやメーリングリストでの記事執筆について 書籍を書くプロセス 習慣を身につけるための考え方と実践法 学習や成長の過程で人がつまずきやすい箇所 その他、Rails開発に関する幅広い話題 Ruby on Railsに関わる方だけでなく、学び方や習慣づくりに興味がある方にも楽し

Railsのi18nライブラリは、見た目以上に強力です。翻訳のためだけに使う必要はありません。表示するテキストと、それを表示する場所を分離（デカップリング）したいあらゆる場面で役立ちます。 Avvoに在籍していた間、私たちはi18nを使ってさまざまな工夫を実現してきました。ここでは実際に役立った学びの数々と、一見「乱用」に見えながら結果的に素晴らしい成果をもたらした、ちょっとクレイジーな活用法を紹介します。 自動HTMLエスケープ ビューにこんなコードを書いていませんか？ <%= raw(t(form.required_field_header)) %> 実はこのrawは不要です。

先週、Rails 4.2の最初のベータ版が発表されました。ActiveJob、Web Console、Adequate Record、そして外部キー(Foreign Key)サポートなど、注目の機能が盛りだくさんで、早く自分のアプリでも試してみたいところです。 しかし、Railsの本当の魅力は細部にこそあります。少し掘り下げてみると、あまり宣伝されていないものの、日々の開発を大きく改善してくれる隠れた機能がいくつも見つかるはずです。 設定ファイルを簡単に読み込める「config_for」 筆者の好みが入っているかもしれませんが、設定ファイルを読み込む仕組みがフレームワークに標準で組み込まれるの

どんなアプリも、実際のユーザーとの最初の接触には耐えられません。ユーザーが使い始めると、必ずどこかでエラーに遭遇するからです。 そのため、本番環境にデプロイした後は、多くのアプリが何らかの方法でエラーを追跡・報告する仕組みを持っています。exception_notification のようなシンプルな gem を使ってもよいですし、Honeybadger や Raygun のような Web サービスを利用するのも一案です。 しかし運用を続けていると、同じ例外ばかりが繰り返し報告されることに気づきます。依存している外部 Web サービスが不安定なのかもしれませんし、ユーザーがメールアドレスを打ち

Rails 4.2のリリースアナウンスには、次期Rails 5に関する興味深い情報が含まれていました。それは「Rails 5はおそらくRuby 2.2を必須とする」というものです。つまり、Ruby 2の優れた機能を本格的に活用できる、初めてのRailsバージョンになるというわけです。 その投稿では、GC対象になったシンボルやキーワード引数が取り上げられていました。しかし私にとって最も興味深いRuby 2の機能のひとつは、Module#prependです。 alias_method_chain の光と影 Railsを学び始めた頃、alias_method_chainには本当に衝撃を受けまし

（この記事は数ヶ月前に私のメーリングリストへお送りしたものです。気に入っていただけたら、ぜひ登録して続きもお読みください！） 先日、自分のアプリのひとつで奇妙な状況に遭遇しました。 たとえば Article モデルがあり、記事はまず「下書き」として作成されるとします。下書きは軽量であるべきです。本文どころかタイトルすらなくても、すぐに作成・編集できるようにしたいはずです。 しかし、記事を公開する段階になると、追加のバリデーションが必要になります。タイトルや本文など、必要な項目がすべて揃っていることを確認しなければなりません。 if 文を並べて自分でチェックを実装することも可能ですが、そ

Rubyを学ぶ前にRailsを学ぶことはできるのでしょうか？ 結論から言えば、「しばらくの間なら可能」です。しかし、アプリがRESTfulなCRUD操作やスキャフォールドで生成したTwitterクローンの段階を超えて成長すると、必ず壁にぶつかることになります。確かに、開発を進めながら自然とRubyを吸収することもできます。ただ、それでは上達までに膨大な時間がかかってしまいます。 Railsをマスターするのに十分なRuby力を身につけたいなら、Ruby単体で学習するのが近道です。 とはいえ、書店にはRuby関連の書籍が山ほど並んでいます。私が最後に本屋を訪れたとき、4つの棚がRubyの本で埋まっ

Rubyのgemは、ほとんどの場合、何も意識しなくても問題なく動作します。しかし、この「魔法のような便利さ」には大きな落とし穴があります。トラブルが発生したとき、その原因を突き止めるのが非常に難しいのです。 gemで問題に遭遇することはそれほど多くありません。しかし、一度問題が起きると、Google検索も意外と役に立ちません。エラーメッセージが汎用的なため、考えられる原因がいくつも挙げられてしまうからです。そして、gemがRubyと実際にどう連携しているのかを理解していなければ、こうした問題を自力でデバッグするのはかなりの苦労になります。 gemは魔法のように見えるかもしれません。でも、少

Rubyを学べる良い場所は数多くあります。しかし、本当の学びとは、単に本を読んだり動画を見たりすることではありません。問題に真正面からぶつかり、行き詰まり、苦戦し、時にはイライラしながら調べて、ふと理解がつながり、いろいろ試して、そしてついに（ようやく！）動くものが完成する——そうしたプロセスこそが学習なのです。 学んだことを実際に使わなければ、知識は定着しません。今回は、私自身が見つけた実践的な学習方法を3つ紹介します。 Ruby Quiz Ruby Quizは、150以上の短くて興味深い問題を集めたコンテンツです。ローマ数字への変換から、ASCIIアートによるダンジョン生成まで、多彩な課題

数週間前、RubyGemsがRubyのロードパス（$LOAD_PATH）をどのように管理しているかについての記事を書きました。しかし実は、RailsはRubyGemsを直接使っていません。RailsはBundlerを使ってgemを管理しています。 Bundlerの仕組みを知らないと、Gemfileに1行追加するだけでコードがアプリに組み込まれる様子は、少し「魔法のように」感じられるかもしれません。いったいどうやって、Gemfileへの記述がアプリのコードとして読み込まれるのでしょうか？Bundler、Rails、RubyGemsはどのように連携して、依存関係の管理を簡単にしているのでしょうか

（これは『Practicing Rails』からの短い抜粋です。こちらから登録すると、第1章を無料で入手できます！） 新しいアプリを開発していて、Railsが自動的にテストファイルを生成してくれたとしましょう。 test/models/bug_test.rbrequire test_helper class BugTest < ActiveSupport::TestCase # test the truth do # assert true # end end コメントアウトを外して、テスト名を決めれば、あとはテストコードを書くだけ。でも、いったい何から書けばい