Ruby

囲碁の入門書を読んでも「楽しさ」が見えなかった 初めて囲碁を学び始めた頃、私は入門書を何冊か買って読みました。ルールや基本的な戦略は身につき、そこに楽しいゲームがあることも分かっていました。それなのに、どうしてもその楽しさが見えてこなかったのです。 いざ自分で対局する段階になると、混乱してストレスを感じました。盤上には361通りの着手候補があります。その中で最善の手はどれなのか?それどころか、どれが許容範囲内の手なのかさえ分かりません。最初の本で得た知識を使えば、まともな手を100手ほどに絞り込むことはできても、どこから始めて何をすればいいのかは掴めないまま。そして、何より楽しくなかったのです

新しいライブラリや機能を使い始めたものの、ドキュメントを読んでもいまいち理解できない——そんな経験はありませんか?セットアップが難しくてRDocを行き来しながら全体像を掴む羽目になったり、そもそもドキュメントがほとんど存在しなかったりすることもあります。あるいは、実際のコード例をたくさん見ることで初めて腹落ちするタイプの人かもしれません。 助けは必要です。しかし、ドキュメント以外のどこで機能の使い方を学べばいいのでしょうか? お気に入りのGitHub機能 ドキュメントの先へ進んで、ライブラリや機能が現実のプロジェクトでどう使われているのかを見たいときは、GitHubのコード検索を活用しま

Railsでスキャフォールドを生成すると、おなじみのrespond_toブロックが自動的に作成されます。app/controllers/tasks_controller.rb def destroy @task.destroy respond_to do |format| format.html { redirect_to tasks_url, notice: Task was successfully destroyed. } format.json { head :no_content } end endしかし、よく見るとindexなど

ブロックしか受け取らない関数にメソッドを渡したいと思ったことはありませんか？あるいは、呼び出そうとしているメソッドが、オブジェクトのどのスーパークラスで壊されてしまったのかを突き止めたいことは？ こうしたことは、methodメソッドを使えば簡単に実現できます。うまく使いこなせば、依存関係への理解が深まり、何時間もかかるデバッグから解放され、コードをあるべき場所へ導けるようになります。 ラムダのように手軽に扱えるメソッド Rubyには、ブロックやラムダを受け取るメソッドが数多くあります。しかし、ラムダと同じようには、メソッドを別のメソッドに直接渡すことはできません。まずmethodを使う必要があ

RubyやRailsのコンソールを起動する方法はいくつもあります。irb、bundle exec irb、bundle console、rails consoleはその中でも特によく使われるコマンドです。どれも似て見えますが、実際にはそれぞれ動作が少し異なります。 これらの違いを理解していないと、思わぬ問題に直面することになります。ActiveRecordモデルがデータベースに接続できない、requireしたのに意図しないバージョンのファイルが読み込まれる、使えるはずだったライブラリが存在しない――そんな経験はないでしょうか。 どうすれば、適切なタイミングで適切なコンソールを使い分けられる

Rubyのeachは非常に便利なメソッドですが、ひとつ悩ましい問題があります。コレクションが空だった場合はどうなるのでしょうか? [].eachを呼び出しても何も起こらず、単に[]が返されるだけです。それが望ましい動作であるケースもあります。しかし多くの場合、特にUIを構築している際には、空のリストを特別に扱いたくなるものです。たとえば私なら、データがひとつもないときには別のメッセージを表示したいと考えます。 ところが[].eachは[]を返すのであってnilではないため、次のような書き方をするしかありません。 app/views/users/index.html.erb<% if @u

一般に、グローバル変数は避けるべきものとされています。しかし、適切な場所で使えば、コードを大幅にシンプルにできることもあります。 Railsアプリでは、リクエスト中に一度だけデータを設定し、それをアプリのあらゆるレイヤーで利用したい場面があります。リクエストしたのはどのユーザーか?どんな権限を持っているか?どのデータベース接続を使うべきか? こうした情報はコード全体から参照できるべきものなので、あちこちに引数として渡すのはノイズでしかありません。しかし、Rubyのグローバル変数やクラス変数を使うと、今度は別の問題が発生します。複数のスレッドが同じ変数を上書きしてしまい、大混乱に陥り、最悪の

この記事は、数ヶ月前にメーリングリストでお送りした内容をもとにしています。毎週このような記事をお読みになりたい方は、こちらからぜひご登録ください。 以前の記事「ちょっとした便利さでプログラミングの流れを守る」では、シンプルな抽象化こそがコードベースを扱いやすく、楽なものにしてくれるという話をしました。 しかし、もし手元にあるのが悪い抽象化だったらどうでしょうか？ 明らかに leaderboard と名付けるべきメソッドの実際の名前を調べるために、毎回APIリファレンスを掘り返す羽目になる。リファクタリングを試みても、ある部分のコードは構造化されたデータを渡してくるのに、別の部分は生のテキ

Railsチュートリアルを終えて、いざ自分のアプリを作り始めると、混乱が始まります。「CRUD以外の一般的なロジックはどこに書けばいいの？」「Twitterからフォロワーを取得する処理はMVCのどこに収まるの？」——そんな疑問です。2人に聞けば4つの答えが返ってくる上、フォーラムのスレッドは気の利いた人たちが何時間も罵り合う場と化すこともあります。いずれにせよ、頭痛が残るだけです。 夢にまで見たアプリを作るには、何らかの汎用的なRails外のロジックがどうしても必要になります。では、コードをどこに置けば、シンプルさを保ったまま済むのでしょうか？ まず手軽に試せる場所 既存のActiveReco

Railsコミュニティは、矛盾するアドバイスであふれています。Minitestを使うべきか、それともRSpec？プレーンなRubyオブジェクトはapp/modelsに置くべきか、app/classesか、あるいはlib/か？ 経験豊富な開発者たちがこうした話題について絶えず議論しているなら、どのアドバイスに従えばいいのか、どうやって判断すればよいのでしょうか？ 秘密はシンプル、「どちらかを選んで従う」 答えはこうです。どちらか一方を選び、それに従って進むこと。 逃げ口上のように聞こえるかもしれません。しかし、これらの議論は本質的に、哲学的な小さな違いをめぐるものです。議論が白熱すればす

せっかく作った自分のアプリ、ワクワクしているはずです。でも、ひとつだけ問題があります――テストが存在しないのです。本来ならテスト駆動開発（TDD）で書きたかったのに、どこから手をつければいいのかわからず、そのまま足止めされてしまった。さて、ここからどう進めばいいのでしょうか？テストゼロの状態から、TDDでアプリを開発できるようになるまで、どうやって橋渡しをすればいいのでしょうか？ まずは、すでにあるコードをテストする 目の前には、テストのない大量のコードがあるかもしれません。しかし、それは今この瞬間にテストを書けないという意味ではありません。まずは既存のコードに対してテストを書き、「コード

日々の細かい作業に没頭していると、全体像を見失いがちです。深く集中しているときほど、小さな積み重ねの先で実際に何を成し遂げたのかに気づかないことがあります。 そこで今回は、昨年1年間の執筆や登壇の活動を振り返りながら、その過程で得られた最も価値のある学びを紹介します。 うまくいったこと 1月10日の「見積もりは目標ではなく、コミュニケーションツールである」という記事から執筆をスタートしました。2014年には合計53本の記事を投稿し、週1本以上のペースを維持しています。4月以降は毎週火曜日に記事を公開するルールを設けました。このようなスケジュールを決めておくと、執筆も計画も格段に楽になります。

奇妙なテスト問題に対する完璧な解決策が見つかった。DEFAULT_HOST定数をオーバーライドするだけで、万事解決のはずだった。 ただし、あの醜い警告メッセージを消すにはwarningsをオフにしなければならない。でもこれですべてのテストが通るようになった。たった数行のコード変更で済んだのだ! ……ただし、ホストをオーバーライドしたくないテストがひとつだけある。まあ、定数を再オーバーライドして、また警告をオフにして、テストの最後に必ずリセットされるようにすればいい。完成まであと一歩、もうすぐそこだ! ただし……ただし……ただし……。 そして数日後、27回目の行き詰まりに直面し、アプリが

モンキーパッチ。Rubyを初めて触ったとき、その強力さに驚かされることでしょう。コアクラスに直接メソッドを追加できるのですから。Time.now.advance(days: -1)と書かずに済み、1.day.agoと書ける。これこそが、Rubyを読み書きする楽しさの源泉です。しかし……。 パッチがHashを書き換えたせいで、奇妙なバグに遭遇する。 実際にどのコードが実行されたのか分からなくなり、壊れたときにデバッグできない。 そしてついに気づくのです。すべての問題は6ヶ月前、たった5文字コードを短くするためにEnumerableをモンキーパッチしたあの時に、すでに生まれていたのだと。

Railsアプリの中には、bundle update railsコマンド一つでアップグレードできるものもあります。 しかし、そうはいかないタイプのアプリを持っている場合はどうでしょうか? 移行作業が億劫で、そのままRails 4.0や3.2のまま放置してしまったアプリのことです。 スムーズなアップグレードでも、苦労するアップグレードでも、この記事の手順に従えば、できるだけスムーズにRails 4.2へ移行できます。さらに、その過程でRails 4.2の新機能を最大限に活用する方法も学べます。 まずはアップグレードガイドを読む Railsのアップグレード作業は、必ず公式の「Railsアッ

社内で別チームに移ったばかり、あるいは転職した直後。お気に入りのオープンソースアプリでバグを見つけ、初めてプルリクエストを送ろうとしている——。ところがgit cloneしてapp/modelsを開いた瞬間、完全に迷子になってしまった。ディレクトリ構成はいつも使っているRailsと同じなのに、コードの中では方向感覚がまったくつかめません。この見慣れないRailsアプリを、最短ルートで学ぶにはどうすればいいのでしょうか? まずは「プロジェクトの用語集」を作る Playerとは何か?Sessionは?AccountとUserとProviderの違いは? アプリごとに使われる用語やメタファーは

『Practicing Rails』好評発売中!2月13日(金)まで25%オフで購入できます。 コードを書いていると、頭の中に絶えず疑問が浮かんできます。「このメソッドはどう呼べばいい?」「どんなオプションを受け付ける?」「引数に数値の代わりにオブジェクトを渡したらどうなる?」——そんな具合です。 こうした疑問は、あなたの生産性を着実に蝕んでいきます。すぐに答えがわからないと、何をしていたのか忘れてしまいます。フロー状態から強制的に引きずり出され、元の作業に戻るまで30分もかかることさえあるのです。 では、スピードを落とさずに必要な答えを見つけるには、どうすればよいのでしょうか? 高速

Railsを圧倒されることなく着実に学べる書籍、『Practicing Rails』がついに発売されました。しかも、木曜日の午後11時59分（太平洋時間）までなら、25%オフで購入できます。 ご購入はこちらから：https://www.justinweiss.com/practicing-rails この本が生まれた背景 これまでの執筆活動の中で、多くの方から同じような声を聞いてきました。「入門書や動画でRailsを一通り学んだのに、チュートリアルレベルのアプリから一歩も先に進めない」と。 楽しいはずの学習が、実際にはただのストレスになっていた。どこから手をつければいいのかわからない。

あなたのGitHubのコントリビューショングラフは真っ灰色になっていませんか？オープンソースプロジェクトに取り組めば解決できますが、ゼロから始める必要はありません。便利なサイドプロジェクトを作る最も簡単な方法は、すでに開発中のアプリケーションからコードを切り出すことです。実は、Rails自身もそうやって生まれたのです！ では、何を抽出すべきかはどうやって見分ければいいのでしょうか？また、普段の開発ワークフローを壊さずにgemへと変換するにはどうすればいいのでしょうか？ 抽出したいコードを見つける アプリの奥深くには、そこにあるべきではないコードが潜んでいます。アプリがなくても単体で機能す

初めての本番アプリをローンチする準備が整い、外部サービスとの連携を始める段階に来ました。しかし、まだすべてを接続する作業が残っています。開発マシンを複雑にすることなく、本番環境でサービスを設定する最良の方法とは何でしょうか? まずは環境変数で環境を整えよう 本番アプリを設定する際、現在のベストプラクティスは環境変数(ENV[REDIS_HOST]のようなもの)を使うことです。 では、なぜ環境変数なのでしょうか?主な理由は次の3つです。 本番用のキーを誤ってコミットするリスクが減る うっかりgit pushで重要なシークレットキーを含むファイルをリポジトリにプッシ