タグ

ブックマーク / qiita.com/jnchito (9)

  • 【トリビア】Railsのコントローラに出てくるparamsはハッシュじゃない - Qiita

    はじめに Railsに関するトリビア的なネタです。 QiitaやZennを見ていると、ときどきRailsのコントローラに出てくるparamsをハッシュ(Hashオブジェクト)だと説明している記事を見かけます。 しかし、paramsはハッシュではありません。 確かめてみよう こんな感じでparamsの中身をputsしてみましょう。

    【トリビア】Railsのコントローラに出てくるparamsはハッシュじゃない - Qiita
    Tomosugi
    Tomosugi 2024/01/17
  • 使えるRSpec入門・その1「RSpecの基本的な構文や便利な機能を理解する」 - Qiita

    はじめに RSpecは難しい、よくわからない、といったコメントをときどき見かけます。 確かにちょっと独特な構文を持っていますし、機能も結構多いので「難しそう」と感じてしまう気持ちもわかります。 (構文については僕も最初見たときに「うげっ、なんか気持ちわるっ」と思った記憶がありますw) しかし、RSpecに限らずどんなフレームワークでも同じですが、慣れてしまえばスラスラ書けますし、実際僕自身は「RSpecって便利だな-」と思いながらテストコードを書いています。 そこでこの記事では、僕が考える「最低限ここだけを押さえていれば大丈夫!!」なRSpecの構文や、僕が普段よく使う便利な機能をまとめてみます。 具体的には以下のような構文や機能です。 describe / it / expect の役割 ネストした describe context の使い方 before の使い方 let / let!

    使えるRSpec入門・その1「RSpecの基本的な構文や便利な機能を理解する」 - Qiita
  • 【短命に終わった】国民の祝日.csvをパースして変換するRubyプログラムとコード解説動画 - Qiita

    はじめに 1週間ほど前、内閣府の「国民の祝日」CSVがひどい、みたいな話が話題になっていました。 参考: 【悲報】内閣府の「国民の祝日」CSVがひどいと話題に なぜ「ひどい」と言われていたのかというと、普通のプログラマが期待する「日付と名前が上から下に並ぶCSV」ではなく、「2016年の列 => 2017年の列 => 2018年の列」のように年単位で列方向(横方向)に繰り返すフォーマットになっていたからです。 (しかも一番下に「月日は表示するアプリケーションによって形式が異なる場合があります。」みたいな注意書きが入ってる!) まあ、ひどいと言えばひどいんですが、これを扱いやすいフォーマットに変換するプログラムを作るのはなかなか面白そうだなと思いました。 というわけで、そんなプログラムを作りました! 国民の祝日.csvをパースするプログラム、とりあえずコードは書いた。https://t.co

    【短命に終わった】国民の祝日.csvをパースして変換するRubyプログラムとコード解説動画 - Qiita
    Tomosugi
    Tomosugi 2017/03/02
  • [初心者向け] RubyやRailsでリファクタリングに使えそうなイディオムとか便利メソッドとか - Qiita

    はじめに: 遠回りせずに「近道」を探す RubyRailsを始めたばかりの人は、もっと短く書く方法や便利な標準ライブラリの存在を知らずに遠回りした書き方をしてしまいがちです。 そこで、RubyRails初心者の人によく見かける「遠回り(または車輪の再発明)」と、それを回避する「近道」をいろいろ集めてみました。 2013.11.06 追記 この投稿を書くに至った経緯などを自分のブログに書きました。 こちらも合わせてどうぞ! 昨日Qiitaに投稿した記事は普段のコードレビューの副産物 - give IT a try Ruby編 以下はRubyの標準機能を使ったイディオムやメソッドです。 Railsプロジェクトでもそれ以外でも使えます。(Ruby 1.9以上を想定) 後置ifで行数を減らす

    [初心者向け] RubyやRailsでリファクタリングに使えそうなイディオムとか便利メソッドとか - Qiita
  • printデバッグにさようなら!Ruby初心者のためのByebugチュートリアル - Qiita

    はじめに この記事はByebug(バイバグ)というgemを使ったデバッグ方法を説明するチュートリアル記事です。 JavaやC#のようなコンパイル型の言語ではEclipseやVisual StudioのようなIDEを使って開発することが主流です。 なので、自然とIDEに標準装備されているデバッガを使ってステップ実行したりすることが多いと思います。 一方、RubyではRubyMineのような有料IDEもあるものの、IDEではなくテキストエディタを使って開発している人の方がまだまだ多いと思います。 そうすると、初心者の方はなんとなく「Rubyでデバッガを使ってデバッグするのは無理なのでは?」と考えてしまう人も多いかもしれません。(僕は初心者の頃そう思ってました・・・。) ですが、そんなことはありません! RubyでもIDEを使わずにターミナル上でデバッガを使ってデバッグすることは可能です。 とい

    printデバッグにさようなら!Ruby初心者のためのByebugチュートリアル - Qiita
    Tomosugi
    Tomosugi 2017/01/16
  • RSpecで作ったexampleの一覧をテストの実行なしに出力する - Qiita

    オプションの意味 -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で作ったexampleの一覧をテストの実行なしに出力する - Qiita
    Tomosugi
    Tomosugi 2016/07/15
  • RSpecのletを使うのはどんなときか?(翻訳) - Qiita

    はじめに 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のletを使うのはどんなときか?(翻訳) - Qiita
  • 使えるRSpec入門・その2「使用頻度の高いマッチャを使いこなす」 - Qiita

    はじめに みなさんこんにちは! この記事は「必要最小限の努力で最大限実戦で使える知識を提供する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ってわけわからん」となっている人もこの記事で再入門してみると

    使えるRSpec入門・その2「使用頻度の高いマッチャを使いこなす」 - Qiita
  • テストコードの期待値はDRYを捨ててベタ書きする ~テストコードの重要な役割とは?~ - Qiita

    はじめに みなさん、DRY原則はご存知でしょうか? DRY = Don't repeat yourselfの略で「繰り返しを避けること」という意味ですよね。 良いコードを書くための重要かつ基的な原則なので、みなさんよくご存知だと思います。 ですが、DRY原則はテストコードを書く場合は必ずしも最善にはならない場合があります。 他の人が書いたテストコードを見ていると、テストコードにDRY原則を適用したために、かえって悪いコードになっているケースをときどき見かけます。 この記事ではなぜテストコードをDRYにすると良くないのか、ということを説明します。 追記:タイトルを変更しました @t_wada さんのコメントを受けて、タイトルを見直しました。 「テストコードはDRYを捨ててベタ書きする」 => 「テストコードの期待値はDRYを捨ててベタ書きする」 【注意】この記事は画一的なテストコードの書き

    テストコードの期待値はDRYを捨ててベタ書きする ~テストコードの重要な役割とは?~ - Qiita
    Tomosugi
    Tomosugi 2016/06/06
  • 1