PostgreSQLのプライマリーキーはSERIALとUUIDのどっちが速いのか実験してみた - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
Rails.root.join("foo", "bar")よりも、Rails.root.join("foo/bar")が良いのでは？というお話 - Qiita
僕はふだん前者のパターンで書いています。その理由は以下のとおりです。 後者のパターンより短く書けるから 'spec/fixtures/sample.csv'のようなパスが、プロジェクトルートから見た相対パスとして、ぱっと認識しやすいから 一方、後者のパターンで書く人の理由を聞いてみると、「実行環境によってはパスの区切り文字が/と限らないから」と答える人が多かったです。 これはおそらく、Windows環境でパスの区切り文字が\になることを意識しているんだと思います。 検証："/"でパスを区切っても、Windows環境でちゃんと動く しかし、後者のパターンで書く理由が「Windows環境を意識しているから」なのであれば、その心配はおそらく無用です。 Windows環境のrails consoleで、先ほどのようなRails.root.joinの2つの書き方を比較した結果を以下に載せます。 （僕
RubyとRailsにおけるTime, Date, DateTime, TimeWithZoneの違い - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 2021.2.11追記：DateTimeクラスは非推奨なクラスになりました DateTimeクラスは非推奨なクラスとなり、DateTimeクラスではなくTimeクラスを使うよう、公式にアナウンスされました。 参考1 But we consider use of DateTime should be discouraged. - matz (Yukihiro Matsumoto) https://bugs.ruby-lang.org/issues/15712#note-4 参考2 DateTime は deprecated とされているた
Railsアプリケーションにおけるエラー処理（例外処理）の考え方 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Railsアプリケーションを本格的に作り込んでいくと、「エラー」とは無縁ではいられません。 しょうもないバグでエラーが発生することもありますし、ほとんど不可抗力ともいえるような大規模なネットワーク障害でエラーが発生することもあります。 エラーの種類がなんであれ、エラーが起きた場合は「原因を素早く特定し、速やかに復旧させること」と「あるエラーが引き金になって、さらに大きなエラーに引き起こさないようにすること」が重要です。 エラー処理を適切に実装していれば、原因の特定や復旧もすばやくできますし、さらに大きなエラーを引き起こす可能性
使えるRSpec入門・その1「RSpecの基本的な構文や便利な機能を理解する」 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに RSpecは難しい、よくわからない、といったコメントをときどき見かけます。 確かにちょっと独特な構文を持っていますし、機能も結構多いので「難しそう」と感じてしまう気持ちもわかります。 （構文については僕も最初見たときに「うげっ、なんか気持ちわるっ」と思った記憶がありますw） しかし、RSpecに限らずどんなフレームワークでも同じですが、慣れてしまえばスラスラ書けますし、実際僕自身は「RSpecって便利だな－」と思いながらテストコードを書いています。 そこでこの記事では、僕が考える「最低限ここだけを押さえていれば大丈夫！！」なR
Rubyでメソッドの定義場所を見つける方法 - Qiita
RubyはModuleで組み込まれたメソッドや、method_missingを利用した「ゴーストメソッド」など、自分の見ているメソッドがそのクラス以外のどこで定義されているのか、分かりにくいケースがよくあります。 特にJavaやC#から移ってきた僕のようなプログラマは、「メソッド = どこかのクラスで定義されているもの」という印象が強いので、「持ち主がよく分からないメソッド」の存在はデバッグ等で苦労させられます。 こういったケースでは、Kernel#methodとMethod#source_locationを組み合わせることで、メソッドの定義場所を見つけることができます。 たとえば、rails consoleでblank?メソッドの定義場所を見つけたい場合は、こんな感じです。
RSpecのletを使うのはどんなときか？（翻訳） - Qiita
# インスタンス変数を使う場合 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を使うことが多いと思いますが、初心者の人には違いやメリットがよくわからないと思います。 また、使い慣れている人であっても具体的な違いをぱっと即答できる人は少ないんじゃないでしょうか？ ネットを調べていたところ、Stack Overfl
「アプリケーションが壊れているのに検知できないテストコード」を書かないようにするための、べからず集 - Qiita
はじめに テストコードを書くことは重要です。 テストコードがないアプリケーションよりもテストコードがあるアプリケーションの方が望ましいことは間違いありません。 ですが、テストコードも書き方を間違えると、アプリケーションが壊れているのに正しく検知できないテストを書いてしまう可能性があります。 この記事ではそんな「アプリケーションが壊れているのに正しく検知できないテスト」のコード例を「〜するべからず（〜してはいけない）」の形式で紹介し、その修正方法を説明していきます。 サンプルコードはRSpecで書いてます（でも他の言語でも考え方は同じはず） サンプルコードはRailsアプリケーションをRSpecでテストする場合を想定したものになっていますが、基本的な考え方自体は他の言語やテスティングフレームワークでも適用可能なはずです。 RSpecのイロハについて先に学んでおきたいかたは「使えるRSpec入
【初心者向け・動画付き】Railsで日時をフォーマットするときはstrftimeよりも、lメソッドを使おう - Qiita
<% @users.each do |user| %> <tr> <td><%= user.name %></td> <!-- 作成日時を表示する --> <td><%= user.created_at %></td> <td><%= link_to 'Show', user %></td> <td><%= link_to 'Edit', edit_user_path(user) %></td> <td><%= link_to 'Destroy', user, method: :delete, data: { confirm: 'Are you sure?' } %></td> </tr> <% end %>
bundle install時に--path vendor/bundleを付ける必要性は本当にあるのか、もう一度よく考えてみよう - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? TL; DR（最初に結論） bundle installをする場合は--path vendor/bundleを付けてプロジェクトごとにgemを管理しろ、という意見をよく見かける。 しかし、pathを指定しないと問題が起きる可能性があるのは、かなり特殊な条件下に限られる（100人いたら100人全員が遭遇するような問題ではない）。 よって、--path vendor/bundleのオプションは、付けたい人が付ければよいだけで、開発者全員に強制するようなルールではない、と筆者は考える。 はじめに bundle installコマンドを実行する
テストコードの期待値はDRYを捨ててベタ書きする ～テストコードの重要な役割とは？～ - Qiita
はじめに みなさん、DRY原則はご存知でしょうか？ DRY = Don't repeat yourselfの略で「繰り返しを避けること」という意味ですよね。 良いコードを書くための重要かつ基本的な原則なので、みなさんよくご存知だと思います。 ですが、DRY原則はテストコードを書く場合は必ずしも最善にはならない場合があります。 他の人が書いたテストコードを見ていると、テストコードにDRY原則を適用したために、かえって悪いコードになっているケースをときどき見かけます。 この記事ではなぜテストコードをDRYにすると良くないのか、ということを説明します。 追記：タイトルを変更しました @t_wada さんのコメントを受けて、タイトルを見直しました。 「テストコードはDRYを捨ててベタ書きする」 => 「テストコードの期待値はDRYを捨ててベタ書きする」 【注意】この記事は画一的なテストコードの書き
コードレビューの極意。それは「自分のことは棚に上げる」こと！！ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに：コードを良くするためなら遠慮は不要 昨日Twitterに投稿した内容が思った以上に拡散されていたので、タイムラインに流れてしまわないようにQiitaにも書いておきます。 内容は上に書いてあるとおりです。 コードレビューはコードの問題点を指摘し、そのコードを良くすることが第一の目的です。 そのため、少しでもおかしいと思った部分は遠慮せずにどんどんツッコむ必要があります。 しかし、レビューする側が「これ、自分もあまりできてないんだよなあ」「お前もできてないじゃん！って言われたら返す言葉もないし・・・」などと思って遠慮してしまうと、
和英辞典・自動翻訳だけじゃダメ！もっといい英語名を見つけるためのTips集 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに プログラマのみなさんはコードを書くときによく英語を使うと思います。 だけど、英語って難しいですよね。 僕自身もそうですが、クラスの名前やメソッドの名前、テーブルのカラムの名前を考えたりするときは「これ、英語でなんて言うんだろう？？」と頭を抱えることが多いはずです。 他にも、トラブルが発生したときにWebサービスのサポートに英語でメールを書いたりする場合もあります。 そんなとき、安易に頼ってしまいがちなのが、オンラインの和英辞典や自動翻訳の類いです。 ですが、和英辞典や自動翻訳だけが適切な英語を探す唯一の方法ではありません。 む
【短命に終わった】国民の祝日.csvをパースして変換するRubyプログラムとコード解説動画 - Qiita
はじめに 1週間ほど前、内閣府の「国民の祝日」CSVがひどい、みたいな話が話題になっていました。 参考： 【悲報】内閣府の「国民の祝日」CSVがひどいと話題に なぜ「ひどい」と言われていたのかというと、普通のプログラマが期待する「日付と名前が上から下に並ぶCSV」ではなく、「2016年の列 => 2017年の列 => 2018年の列」のように年単位で列方向（横方向）に繰り返すフォーマットになっていたからです。 （しかも一番下に「月日は表示するアプリケーションによって形式が異なる場合があります。」みたいな注意書きが入ってる！） まあ、ひどいと言えばひどいんですが、これを扱いやすいフォーマットに変換するプログラムを作るのはなかなか面白そうだなと思いました。 というわけで、そんなプログラムを作りました！ 国民の祝日.csvをパースするプログラム、とりあえずコードは書いた。https://t.co
脱初心者を目指すVimmerにオススメしたいVimプラグインや.vimrcの設定 - Qiita
はじめに: 「素のVim」から「プラグイン付きのVim」へ Vimを使い始めた当初、僕は.vimrcの設定だけで実現できる機能に限定した方が「ポータブルなVimスキル」になる気がしていたので、プラグインは全く使わずに「素のVim」を使っていました。 しかし、Vimを使って実務でRailsを開発し始めるとそんなことも言ってられなくなりました。 やはり素のVimだけでは限界があります。 Vimを使って効率よくRailsを開発するためにはプラグインに頼らざるを得ません。 ネットの情報などを参考にしてあれこれプラグインを入れてみましたが、これは手放せないというプラグインもあれば、思ったほど使わなかったというプラグインもあります。 今回の記事では前者のような「これは手放せない！」と僕が考えているプラグインに限定して紹介していきます。 また、後半ではプラグインを使わない.vimrcの一般的な設定につい
モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう - Qiita
はじめに 他の人が書いたコードを読んでいるときに時々気になるのが、英語の間違いです。 特に動詞、名詞、形容詞の使い分けが間違っていたりすると、かなり違和感を感じます。 そこで今回はモデル（＝クラス）やメソッドに名前を付けるときの基本的な原則をまとめてみます。 また、英文法的に正しい品詞が選べるようになるための習慣についても最後に説明します。 想定する言語/フレームワーク この記事の説明ではRuby/Ruby on Railsを想定しています。 ただし、基本的な考え方は他の言語でも同じように使えるはずです。 モデルの名前は名詞にする 例: 「支払い情報」を表すモデルを作りたい場合 × Pay ○ Payment 「支払う = payか。よし。」でモデルを作ってはいけません！ payは動詞で、payの名詞形がpaymentです。 Payモデルではなく、Paymentモデルを作りましょう。 例:
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[初心者向け] RubyやRailsでリファクタリングに使えそうなイディオムとか便利メソッドとか - Qiita![[初心者向け] RubyやRailsでリファクタリングに使えそうなイディオムとか便利メソッドとか - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/249ed01c25c90041262b1d6ee5f63251c599e09f/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-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUU1JTg4JTlEJUU1JUJGJTgzJUU4JTgwJTg1JUU1JTkwJTkxJUUzJTgxJTkxJTVEJTIwUnVieSVFMyU4MiU4NFJhaWxzJUUzJTgxJUE3JUUzJTgzJUFBJUUzJTgzJTk1JUUzJTgyJUExJUUzJTgyJUFGJUUzJTgyJUJGJUUzJTgzJUFBJUUzJTgzJUIzJUUzJTgyJUIwJUUzJTgxJUFCJUU0JUJEJUJGJUUzJTgxJTg4JUUzJTgxJTlEJUUzJTgxJTg2JUUzJTgxJUFBJUUzJTgyJUE0JUUzJTgzJTg3JUUzJTgyJUEzJUUzJTgyJUFBJUUzJTgzJUEwJUUzJTgxJUE4JUUzJTgxJThCJUU0JUJFJUJGJUU1JTg4JUE5JUUzJTgzJUExJUUzJTgyJUJEJUUzJTgzJTgzJUUzJTgzJTg5JUUzJTgxJUE4JUUzJTgxJThCJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz03MWU1YjI0ODg2Nzk2Yjc1NjQ3MGYxZGMwODFhZWI5NQ%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBqbmNoaXRvJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1mNTU2ZjY3NThlYzg3YzNkYzgyZTgwMjMxNThkODRhZA%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4g5qCq5byP5Lya56S-44K944OL44OD44Kv44Ks44O844OH44Oz%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%25231E2121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3Ddc2cfad7310a4b39fea0e0c80eaba4a5)
【アンチパターン】全部nil(null)かもしれない症候群 - Qiita