はじめに Railsに関するトリビア的なネタです。 QiitaやZennを見ていると、ときどきRailsのコントローラに出てくるparamsをハッシュ(Hashオブジェクト)だと説明している記事を見かけます。 しかし、paramsはハッシュではありません。 確かめてみよう こんな感じでparamsの中身をputsしてみましょう。
![【トリビア】Railsのコントローラに出てくるparamsはハッシュじゃない - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/0fa4609eaae16f9c43594663ddf54dbdd1638330/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JUUzJTgwJTkwJUUzJTgzJTg4JUUzJTgzJUFBJUUzJTgzJTkzJUUzJTgyJUEyJUUzJTgwJTkxUmFpbHMlRTMlODElQUUlRTMlODIlQjMlRTMlODMlQjMlRTMlODMlODglRTMlODMlQUQlRTMlODMlQkMlRTMlODMlQTklRTMlODElQUIlRTUlODclQkElRTMlODElQTYlRTMlODElOEYlRTMlODIlOEJwYXJhbXMlRTMlODElQUYlRTMlODMlOEYlRTMlODMlODMlRTMlODIlQjclRTMlODMlQTUlRTMlODElOTglRTMlODIlODMlRTMlODElQUElRTMlODElODQmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtY2xpcD1lbGxpcHNpcyZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTFlNzFmYTEyZmIyZGU2MTQ2ZWMxYjZlZDI4MWQ3MzRi%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTcxNiZ0eHQ9JTQwam5jaGl0byUyMGluJTIwJUU2JUEwJUFBJUU1JUJDJThGJUU0JUJDJTlBJUU3JUE0JUJFJUUzJTgyJUJEJUUzJTgzJThCJUUzJTgzJTgzJUUzJTgyJUFGJUUzJTgyJUFDJUUzJTgzJUJDJUUzJTgzJTg3JUUzJTgzJUIzJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzImdHh0LWFsaWduPWxlZnQlMkN0b3Amcz0wNmZjOTlkZGRjY2I1ODA2NmU3MThkYzhlZmJkYzgwNA%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D999242705ef1ad39404674de0bc35fe5)
はじめに RSpecは難しい、よくわからない、といったコメントをときどき見かけます。 確かにちょっと独特な構文を持っていますし、機能も結構多いので「難しそう」と感じてしまう気持ちもわかります。 (構文については僕も最初見たときに「うげっ、なんか気持ちわるっ」と思った記憶がありますw) しかし、RSpecに限らずどんなフレームワークでも同じですが、慣れてしまえばスラスラ書けますし、実際僕自身は「RSpecって便利だな-」と思いながらテストコードを書いています。 そこでこの記事では、僕が考える「最低限ここだけを押さえていれば大丈夫!!」なRSpecの構文や、僕が普段よく使う便利な機能をまとめてみます。 具体的には以下のような構文や機能です。 describe / it / expect の役割 ネストした describe context の使い方 before の使い方 let / let!
はじめに 1週間ほど前、内閣府の「国民の祝日」CSVがひどい、みたいな話が話題になっていました。 参考: 【悲報】内閣府の「国民の祝日」CSVがひどいと話題に なぜ「ひどい」と言われていたのかというと、普通のプログラマが期待する「日付と名前が上から下に並ぶCSV」ではなく、「2016年の列 => 2017年の列 => 2018年の列」のように年単位で列方向(横方向)に繰り返すフォーマットになっていたからです。 (しかも一番下に「月日は表示するアプリケーションによって形式が異なる場合があります。」みたいな注意書きが入ってる!) まあ、ひどいと言えばひどいんですが、これを扱いやすいフォーマットに変換するプログラムを作るのはなかなか面白そうだなと思いました。 というわけで、そんなプログラムを作りました! 国民の祝日.csvをパースするプログラム、とりあえずコードは書いた。https://t.co
はじめに: 遠回りせずに「近道」を探す RubyやRailsを始めたばかりの人は、もっと短く書く方法や便利な標準ライブラリの存在を知らずに遠回りした書き方をしてしまいがちです。 そこで、RubyやRails初心者の人によく見かける「遠回り(または車輪の再発明)」と、それを回避する「近道」をいろいろ集めてみました。 2013.11.06 追記 この投稿を書くに至った経緯などを自分のブログに書きました。 こちらも合わせてどうぞ! 昨日Qiitaに投稿した記事は普段のコードレビューの副産物 - give IT a try Ruby編 以下はRubyの標準機能を使ったイディオムやメソッドです。 Railsプロジェクトでもそれ以外でも使えます。(Ruby 1.9以上を想定) 後置ifで行数を減らす
はじめに この記事はByebug(バイバグ)というgemを使ったデバッグ方法を説明するチュートリアル記事です。 JavaやC#のようなコンパイル型の言語ではEclipseやVisual StudioのようなIDEを使って開発することが主流です。 なので、自然とIDEに標準装備されているデバッガを使ってステップ実行したりすることが多いと思います。 一方、RubyではRubyMineのような有料IDEもあるものの、IDEではなくテキストエディタを使って開発している人の方がまだまだ多いと思います。 そうすると、初心者の方はなんとなく「Rubyでデバッガを使ってデバッグするのは無理なのでは?」と考えてしまう人も多いかもしれません。(僕は初心者の頃そう思ってました・・・。) ですが、そんなことはありません! RubyでもIDEを使わずにターミナル上でデバッガを使ってデバッグすることは可能です。 とい
オプションの意味 -f d = ドキュメント形式で出力する。--format documentationと書いても良い。 --dry-run = テストを実行しない(Dry run) --order defined = 定義されている順に実行する。spec_helper.rb等でランダム実行を指定していなければ省略可。 出力例 $ bin/rspec -f d --dry-run --order defined ContactsController administrator access behaves like public access to contacts GET #index with params[:letter] populates an array of contacts starting with the letter renders the :index templa
はじめに RSpecにはletという機能があります。 これを使うとインスタンス変数を次のように置き換えることができます。 # インスタンス変数を使う場合 before do @user = User.new(name: 'Taro', email: 'taro@example.com') end it 'is valid' do expect(@user).to be_valid end # letを使う場合 let(:user) { User.new(name: 'Taro', email: 'taro@example.com') } it 'is valid' do expect(user).to be_valid end RSpecを使い慣れている人であれば、おそらくletを使うことが多いと思いますが、初心者の人には違いやメリットがよくわからないと思います。 また、使い慣れている人で
はじめに みなさんこんにちは! この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第2回です。 今回はRSpecのマッチャについて説明していきます。 第1回と同様、今回も「最低限これだけは」という内容に絞り込んで説明します。 使用頻度の少ないマイナーなマッチャ(注:僕基準)については説明しません。 具体的な項目は以下の通りです。 マッチャとは何か to / not_to / to_not eq be be_xxx be_truthy / be_falsey change + from / to / by 配列 + include raise_error be_within + of これからRSpecを始める人はもちろん、何度かRSpecに触れて「うーん、RSpecってわけわからん」となっている人もこの記事で再入門してみると
はじめに みなさん、DRY原則はご存知でしょうか? DRY = Don't repeat yourselfの略で「繰り返しを避けること」という意味ですよね。 良いコードを書くための重要かつ基本的な原則なので、みなさんよくご存知だと思います。 ですが、DRY原則はテストコードを書く場合は必ずしも最善にはならない場合があります。 他の人が書いたテストコードを見ていると、テストコードにDRY原則を適用したために、かえって悪いコードになっているケースをときどき見かけます。 この記事ではなぜテストコードをDRYにすると良くないのか、ということを説明します。 追記:タイトルを変更しました @t_wada さんのコメントを受けて、タイトルを見直しました。 「テストコードはDRYを捨ててベタ書きする」 => 「テストコードの期待値はDRYを捨ててベタ書きする」 【注意】この記事は画一的なテストコードの書き
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く