タグ

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

  • Railsアプリケーションにおけるエラー処理(例外処理)の考え方 - Qiita

    はじめに Railsアプリケーションを格的に作り込んでいくと、「エラー」とは無縁ではいられません。 しょうもないバグでエラーが発生することもありますし、ほとんど不可抗力ともいえるような大規模なネットワーク障害でエラーが発生することもあります。 エラーの種類がなんであれ、エラーが起きた場合は「原因を素早く特定し、速やかに復旧させること」と「あるエラーが引き金になって、さらに大きなエラーに引き起こさないようにすること」が重要です。 エラー処理を適切に実装していれば、原因の特定や復旧もすばやくできますし、さらに大きなエラーを引き起こす可能性も少ないです。 また、ソースコードも比較的シンプルに保てます。 逆にエラー処理が不適切だと原因の特定に時間がかかったり、異常なデータがどんどん増えてさらに大きなエラーを引き起こしたりします。 ソースコードにも無駄に複雑な処理フローや条件分岐がたくさん出てきて

    Railsアプリケーションにおけるエラー処理(例外処理)の考え方 - Qiita
    youko03
    youko03 2022/06/20
    “エラーをrescueしたときは原因の調査に役立つ情報(少なくともメッセージとバックトレース)をログに残したり、エラー通知サービスに通知したりすること”
  • RSpecの入門とその一歩先へ ~RSpec 3バージョン~ - Qiita

    はじめに 有名な初心者向けのRSpec入門記事として、和田卓人さん(@t_wada)の「RSpec の入門とその一歩先へ」という記事があります。 僕もRSpecを全く知らなかった頃に参考にさせてもらいました。 今読んでもとても素晴らしい資料なのですが、RSpecのバージョンが古く、現状の書き方とマッチしなくなってきているのが少しもったいないところです。 そこで、この記事では和田さんの記事をRSpec 3バージョンに書き直してみようと思います。 各イテレーション(RSpec 3バージョン)へのリンク 第1イテレーション(記事) 第2イテレーション 第3イテレーション ソースコードのURL https://github.com/JunichiIto/rspec3-for-beginners/tree/end_of_iter1 記事のライセンスについて 記事は クリエイティブ・コモンズ 表

    RSpecの入門とその一歩先へ ~RSpec 3バージョン~ - Qiita
  • 【翻訳】ActiveRecordにおける、ネストしたトランザクションの落とし穴 - Qiita

    🙅‍♂️この記事の内容は実際のコードに適用しないでください!! (2022-10-5追記) この記事の文でトランザクションに joinable: false というオプションを付けることが推奨されていますが、 joinable: false は内部APIなので指定してはいけない、というのがRails開発チームの見解のようです。 https://github.com/rails/rails/issues/39912#issuecomment-665483779 https://github.com/rails/rails/issues/46182#issuecomment-1266550987 joinable: false を付けるとコミット実行前にafter_create_commitコールバックが呼ばれるなど(参考)、思いがけない別の問題を引き起こすことがあります。 というわけで、

    【翻訳】ActiveRecordにおける、ネストしたトランザクションの落とし穴 - Qiita
    youko03
    youko03 2021/07/13
    “Railsは内側のトランザクションを「なかったことに」して、自前のトランザクション処理だけを使うのです。しかし、内側のトランザクションで発生させた例外はそこで捕捉され、外側のトランザクションには通知されま
  • 【Railsトリビア】blog_path(@ blog)の代わりにblog_pathと書いても自動的にidが補完される - Qiita

    たとえば、RailsのViewファイルとして次のようなblogs/edit.html.erbがあったとします。 <h1>Editing Blog</h1> <%= render 'form', blog: @blog %> <%= link_to 'Show', blog_path(@blog) %> | <%= link_to 'Back', blogs_path %> 5行目のblog_path(@blog)は/blogs/10のようなパスを生成するヘルパーメソッドです。(ここでは@blog.idの値が10だった場合を想定) このようにblog_pathの引数には通常、@blogのようなActiveRecordのインスタンスを渡すと思います。 ですが、blog_pathは次のように引数無しで呼びだしてもエラーにはなりません。

    【Railsトリビア】blog_path(@ blog)の代わりにblog_pathと書いても自動的にidが補完される - Qiita
    youko03
    youko03 2021/06/21
  • テストコードの期待値はDRYを捨ててベタ書きする ~テストコードの重要な役割とは?~ - Qiita

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

    テストコードの期待値はDRYを捨ててベタ書きする ~テストコードの重要な役割とは?~ - Qiita
    youko03
    youko03 2021/01/07
  • privateメソッドをレシーバ付きで呼び出せるケース - Qiita

    (2022.6.4追記) 以下の情報はRuby 2.4時代の情報である点にご注意ください。 Ruby 2.7以降ではふつうのprivateメソッドもself付きで呼べるようになるなど、最新のRubyでは仕様が若干変わっています。 なお、拙著「プロを目指す人のためのRuby入門 改訂2版」ではRuby 3.0に対応して、こうした新しい言語仕様についても詳しく説明しています。こちらもぜひご覧ください。 はじめに この記事は書籍「プロを目指す人のためのRuby入門」に掲載できなかったトピックを著者自らが紹介するアドベントカレンダーの17日目です。 文に出てくる章番号や項番号は書籍の中で使われている番号です。 今回はprivateメソッドをレシーバ付きで呼び出せるケースを説明します。 必要な前提知識 「プロを目指す人のためのRuby入門」の第7章まで読み終わっていること。 privateメソッド

    privateメソッドをレシーバ付きで呼び出せるケース - Qiita
    youko03
    youko03 2020/12/24
    “セッターメソッドの場合はprivateメソッドでもself付きで呼び出すことができます” まじか。
  • 【Opal】娘のために作ったRubyプログラムをブラウザ上で動かしてみた - Qiita

    はじめに この記事はRuby Advent Calendar 2020 19日目の記事です。 さて、突然ですが、最近僕の娘がハイキュー!!というアニメのカードを集めるのにハマり始めました。 このカードは1枚110円で、全部で55種類あります。 当然ながら娘は全種類集めたい!と言います。 僕が調べた範囲では特にレアカードの設定はないようなので、「どのカードも出てくる確率は同じ」と仮定した上でカードを買い続けたら、いったいどれくらいの枚数を買うことになるんだろう?と思いました。 そこでRubyを使って簡単なシミュレーションプログラムを作ってみました。 require 'set' class Simulator NUMBER_OF_TYPES = 55 def self.simulate set_of_cards = Set[] all_types = (1..NUMBER_OF_TYPES).

    【Opal】娘のために作ったRubyプログラムをブラウザ上で動かしてみた - Qiita
    youko03
    youko03 2020/12/19
    “単純に時間だけにフォーカスすれば、使い慣れたRailsで作ったり、シミュレータをJSで全部書き直したりした方が圧倒的に速かったと思います”
  • 【初心者向け】テストコードの方針を考える(何をテストすべきか?どんなテストを書くべきか?) - Qiita

    はじめに 「テストコードを書きましょう」とはよく言われるし、テストコードが大事だってことも理解できるんだけど、何をテストしたらいいの?どんなテストを書いたらいいの?と迷っている初心者プログラマさんは意外と多いのではないでしょうか? そんな方たちに向けて、この記事では僕が普段意識しているテストコードの方針を紹介します。 おことわり 来であれば具体的なコード例も豊富に入れたいところなのですが、かなり時間がかかってしまうので、いったん文章メインで記事を公開します。 もしかすると、そのうちコード例も一緒に盛り込んだ「リッチバージョン」を公開するかもしれません。 この記事の前提条件 この記事ではあくまで、「今現在、筆者が仕事で書いているテストコードの方針」です。 そのため、状況が異なると適用しづらい方針も出てくるかもしれません。 筆者は以下のような現場でコードを書いています。 月額定額で、お客様と

    【初心者向け】テストコードの方針を考える(何をテストすべきか?どんなテストを書くべきか?) - Qiita
    youko03
    youko03 2020/08/14
    “「このコード、テストなしでリリースするのはちょっと不安だな」と思ったら、それがテストを書くトリガー リリースするときに「ちゃんとうまく動きますように」と祈ってる自分がいたら、テストが不足している証拠
  • [初心者向け] RubyやRailsでリファクタリングに使えそうなイディオムとか便利メソッドとか - Qiita

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

    [初心者向け] RubyやRailsでリファクタリングに使えそうなイディオムとか便利メソッドとか - Qiita
    youko03
    youko03 2015/03/29
  • 1