タグ

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

  • これでもう怖くない!?Rails 4.1からRails 5.0にアップグレードする手順を動画付きで解説します - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに みなさんお待ちかねのRails 5.0が先日リリースされました。 これまでRailsを使って開発してきた方は、おそらく既存のRailsアプリケーションではRails 4系を使っているんじゃないかと思います。(Rails 3以前の方もいるかもしれませんが・・・) しかし、中には「Rails 5にアップグレードしたいけど、やり方がよくわからない・・・」と困っている方もいるんじゃないでしょうか? そこでこの記事ではRails 4.1で作ったサンプルアプリケーションをRails 5.0にアップグレードする手順を説明します。 (この記事

    これでもう怖くない!?Rails 4.1からRails 5.0にアップグレードする手順を動画付きで解説します - Qiita
    manimoto
    manimoto 2019/01/15
  • サヨナラBetter Specs!? 雑で気楽なRSpecのススメ - Qiita

    はじめに RSpecって結構「RSpecらしく書くこと」を求められたりします。 たとえば、describeやcontextでしっかりグループを分けましょう、再利用するデータはletやsubjectに切り出しましょう、ひとつのexample(it)の中でテストするのはひとつの項目だけにしましょう、等々の方針です。 よくあるのが「Better Specsを読んで、こんなふうに書くようにしましょう!」っていうパターンですね。 Better Specs しかし僕の場合、最近は「そこまでがんばってキレイにしなくてもいいのでは?」と考えるようになってきています。 その結果、テストコードがだんだん雑になってきています。 というわけで、この記事では最近僕が実践している「雑なRSpec」の書き方を紹介します。 備考 この記事は以前自分のブログに書いた内容を加筆・修正したものです。 「雑なRSpec」以外の話

    サヨナラBetter Specs!? 雑で気楽なRSpecのススメ - Qiita
    manimoto
    manimoto 2018/06/01
  • 【初心者向け】テストコードの方針を考える(何をテストすべきか?どんなテストを書くべきか?) - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 「テストコードを書きましょう」とはよく言われるし、テストコードが大事だってことも理解できるんだけど、何をテストしたらいいの?どんなテストを書いたらいいの?と迷っている初心者プログラマさんは意外と多いのではないでしょうか? そんな方たちに向けて、この記事では僕が普段意識しているテストコードの方針を紹介します。 おことわり 来であれば具体的なコード例も豊富に入れたいところなのですが、かなり時間がかかってしまうので、いったん文章メインで記事を公開します。 もしかすると、そのうちコード例も一緒に盛り込んだ「リッチバージョン」を公開す

    【初心者向け】テストコードの方針を考える(何をテストすべきか?どんなテストを書くべきか?) - Qiita
    manimoto
    manimoto 2018/06/01
  • rspec-rails 3.7の新機能!System Specを使ってみた - Qiita

    はじめに 先日、RSpec 3.7がリリースされました。 参考: RSpec 3.7 has been released! 上記ブログの中で「今回のリリースはRailsのSystem Testの統合機能をいち早く使ってもらうためのリリースだ」と書いてあります。 実際、ブログの中で触れられている新機能は「System Spec」機能の追加だけです。 というわけで、この記事はrspec-rails 3.7で導入されたSystem Specの紹介と使い方の説明をしていきます。 実行環境 この記事は以下のバージョンを対象にして書かれています。 rspec-rails 3.7.1 Rails 5.1.4 Ruby 2.4.2 selenium-webdriver 3.6.0 Capybara 2.15.4 Chrome 62 ChromeDriver 2.33 サンプルコード この記事で使用したコー

    rspec-rails 3.7の新機能!System Specを使ってみた - Qiita
    manimoto
    manimoto 2017/12/30
  • 【アンチパターン】Arrange、Act、Assert(AAA)を意識できていないRSpecのコード例とその対処法 - Qiita

    # トレーニングジムの予約システムを開発していると仮定してください describe 'キャンセル処理' do let(:user) { create :user } let(:reservation) { create :reservation, user: user, start_at: '2017-08-10 10:00'.in_time_zone } context '24時間前をすぎるとキャンセル料が発生する' do before do travel_to '2017-08-09 10:00'.in_time_zone reservation.cancel! end after { travel_back } let(:billing) { user.billings.first } it { expect(user.billings.count).to eq 1 } it {

    【アンチパターン】Arrange、Act、Assert(AAA)を意識できていないRSpecのコード例とその対処法 - Qiita
    manimoto
    manimoto 2017/09/14
  • コードレビューの極意。それは「自分のことは棚に上げる」こと!! - 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にも書いておきます。 内容は上に書いてあるとおりです。 コードレビューはコードの問題点を指摘し、そのコードを良くすることが第一の目的です。 そのため、少しでもおかしいと思った部分は遠慮せずにどんどんツッコむ必要があります。 しかし、レビューする側が「これ、自分もあまりできてないんだよなあ」「お前もできてないじゃん!って言われたら返す言葉もないし・・・」などと思って遠慮してしまうと、

    コードレビューの極意。それは「自分のことは棚に上げる」こと!! - Qiita
    manimoto
    manimoto 2017/07/15
  • (あなたの周りでも見かけるかもしれない)インスタンス変数の間違った使い方 - Qiita

    (2021-8-28追記) この記事の改訂版を書いてみました。改訂版の方が易しい内容になっているので、プログラミング初心者の方はこちらを参考にしてみてください。 はじめに:「引数があるよりは、ない方が良い」? 先日、同僚の西見さん(@mah_lab)がこんな技術ブログを書いていました。 インスタンスメソッドとクラスメソッドはどのようにして使い分けるべきか?(Rubyの場合) 同じ内容を僕だったらどういうふうに書くかな~?と思って、ちょっと書き始めてみたんですが、わかりやすく実践的な説明をするのは意外と難しく、内容も西見さんのブログとほぼ同じになりそうだったので、途中で断念しました。 というわけで、インスタンスメソッドとクラスメソッドの使い分けが未だにあやふやだという方は、ぜひ西見さんのブログを読んでみてください! ・・・なんですが、1点だけ気になる点がありました。 それはインスタンスメソッ

    (あなたの周りでも見かけるかもしれない)インスタンス変数の間違った使い方 - Qiita
  • Rails開発におけるwebサーバーとアプリケーションサーバーの違い(翻訳) - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 先日スタック・オーバーフローでこんな質問に回答しました。 webサーバー、アプリケーションサーバー、Rackといった仕様や概念と、WEBrick、Unicorn、Pumaといった実装の関係が頭の中で結びつきません 質問者の方はwebサーバー、アプリケーションサーバー、Rack、Unicorn、Pumaと言った用語や概念の理解がこんがらかっているように見えたので、このあたりをきれいに説明している記事を探していたところ、以下の記事を見つけました。 A web server vs. an app server - Justin We

    Rails開発におけるwebサーバーとアプリケーションサーバーの違い(翻訳) - Qiita
  • 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アプリケーションを格的に作り込んでいくと、「エラー」とは無縁ではいられません。 しょうもないバグでエラーが発生することもありますし、ほとんど不可抗力ともいえるような大規模なネットワーク障害でエラーが発生することもあります。 エラーの種類がなんであれ、エラーが起きた場合は「原因を素早く特定し、速やかに復旧させること」と「あるエラーが引き金になって、さらに大きなエラーに引き起こさないようにすること」が重要です。 エラー処理を適切に実装していれば、原因の特定や復旧もすばやくできますし、さらに大きなエラーを引き起こす可能性

    Railsアプリケーションにおけるエラー処理(例外処理)の考え方 - Qiita
  • [初心者向け] RubyやRailsでリファクタリングに使えそうなイディオムとか便利メソッドとか - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

    [初心者向け] RubyやRailsでリファクタリングに使えそうなイディオムとか便利メソッドとか - Qiita
  • モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう - Qiita

    はじめに 他の人が書いたコードを読んでいるときに時々気になるのが、英語の間違いです。 特に動詞、名詞、形容詞の使い分けが間違っていたりすると、かなり違和感を感じます。 そこで今回はモデル(=クラス)やメソッドに名前を付けるときの基的な原則をまとめてみます。 また、英文法的に正しい品詞が選べるようになるための習慣についても最後に説明します。 想定する言語/フレームワーク この記事の説明ではRuby/Ruby on Railsを想定しています。 ただし、基的な考え方は他の言語でも同じように使えるはずです。 モデルの名前は名詞にする 例: 「支払い情報」を表すモデルを作りたい場合 × Pay ○ Payment 「支払う = payか。よし。」でモデルを作ってはいけません! payは動詞で、payの名詞形がpaymentです。 Payモデルではなく、Paymentモデルを作りましょう。 例:

    モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう - Qiita
  • 1