タグ

programmingとrailsに関するnyangryのブックマーク (35)

  • if not と unless の使い分け - 本当は怖いHPC

    周辺で話題になったので書いておく。if notとunlessをどう使い分けるか。 検索してみると、青木さんのRubyCodingStyleや、前田さんのRubyコーディング規約などが目に付く。どうやら、世間での標準は、「使えるところではなるべく unless を使い、if not は使わない」ということらしい。 が、僕の場合はちょっと違うので書いておく。他にもこういう人はいるだろうか? 正常処理の分岐にはif not、異常処理にunless 使い分けは簡単明瞭(だと思う)。正常処理の分岐にはif not、異常処理(例外処理)にはunlessを使うというもの。また、if文を使って正常と異常を分岐する場合は、どんなときでも if <正常> else <異常> end となるようにしている。notが入ろうが入るまいが。 このようにする理由はいくつかある。上から順に大きな因子。下に行くほど、いわゆ

    if not と unless の使い分け - 本当は怖いHPC
  • モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう - Qiita

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

    モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう - Qiita
  • 中規模Web開発のためのMVC分割とレイヤアーキテクチャ - Qiita

    TL;DR MVCもレイヤで捉えて関係性の設計をするといいのでは 普通のRubyオブジェクトを積極的に使いたいですね 「パーフェクト Rails」に期待しましょう 長くなって面倒くさくなり、途中から手抜き感が半端ないですが許してください この記事の位置付けなど 7 Patterns to Refactor Fat ActiveRecord Models - Code Climate Blog [翻訳] エリック・エヴァンスのドメイン駆動設計 エンタープライズ アプリケーションアーキテクチャパターン これらの参考文献を踏まえてRailsアプリケーションのリファクタリングをしていて、だいぶ方向性や考え方がまとまってきたので、これからチームに合流する人を想定読者に、Qiitaがどんな感じで作られているのかを文書化したものです。(参考文献の一覧は記事の最後にあります) 内容的には文献[2,3]を踏

    中規模Web開発のためのMVC分割とレイヤアーキテクチャ - Qiita
  • factory_girlの使い方 - Qiita

    テストのときのFixtureとして有名なfactory_girlの使い方をみてみましょう。 まずはModelが一つのときの使い方です。 class User < ActiveRecord::Base attr_accessible :email, :name, :password, :password_confirmation has_secure_password end FactoryGirl.define do factory :user do name "John" email "john@example.com" factory :admin do admin true end factory :japanese_user do name "Tanaka" end end factory :another_user, class: User do name "Nash" emai

    factory_girlの使い方 - Qiita
  • ScaleOut | Supership

    2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 件に関する詳細は、プレスリリースをご確認ください。

    ScaleOut | Supership
  • GitHub - cookpad/rrrspec: Distributed RSpec

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    GitHub - cookpad/rrrspec: Distributed RSpec
  • Capybaraでのフォーム入力を楽にしてくれるGem、formulaic | mah365

    ものすごく大量の項目があるフォームのテストをCapybaraでやるときに、1つずつfill_inとかしてたら死にますよね。永遠に帰れないし、そのテスト保守したくない・・・。そんな人の心強い味方がformulaic(読めない)です。 みんな大好きFactoryGirlでお馴染みのthoughtbot製です。 使い方 RSpecのspec/spec_helper.rbにこんな設定を加えて、 # spec/spec_helper.rb RSpec.configure do |config| config.include Formulaic::Dsl end feature 'New user registration' do scenario 'successfull sign up' do visit sign_in_path fill_form(:user, { name: 'Caleb',

    Capybaraでのフォーム入力を楽にしてくれるGem、formulaic | mah365
  • How We Test Rails Applications

    I’m frequently asked what it takes to begin testing Rails applications. The hardest part of being a beginner is that you often don’t know the terminology or what questions you should be asking. What follows is a high-level overview of the tools we use, why we use them, and some tips to keep in mind as you are starting out. RSpec We use RSpec over Test::Unit because the syntax encourages human read

    How We Test Rails Applications
  • Rails の ActiveRecord モデルテストの書き方ガイドライン - passingloopの日記

    このエントリでは,Ruby on Rails (以下 Rails)の ActiveRecord モデルテストについて,1) どこの何をテストすればよいか,2) どのようにテストを書けばよいか,のガイドラインを示します.このガイドラインは Rails 公式のものではなく,id:passingloop が使っている私的なものです.疑問・質問・批判・間違いの指摘はページ下部のコメント欄までお願いします. はじめに Rails は TDD/BDD サポートが充実した Web アプリケーション開発フレームワークです.Rails で使える Test::Unit や RSpec などといったテスティングフレームワークの使い方に関する解説も豊富にあります.しかし,「どこをどうテストすればよいのか」についての解説は,「使い方」の解説と比較して少ないように思います.もっとも,テスト一般についてどう書くかはアプ

    Rails の ActiveRecord モデルテストの書き方ガイドライン - passingloopの日記
  • RailsのRESTful APIをテストで理解する - ワザノバ | wazanova

    http://www.commandercoriander.net/blog/2014/01/04/test-driving-a-json-api-in-rails1 comment | 0 pointsPivotal LabsのEno ComptonがRailsでJSON APIをテスト形式で理解できるように紹介してくれてます。「Railsアプリをてがけると、いずれ、シングルページアプリ、モバイルクライアントのためにRESTful APIが必要になるだろうから練習用に。」ということで、コードはGithubで公開されています。 GET /movies POST /movies GET /movies/:id PUT /movies/:id DELETE /movies/:id 上記のrouteをサポートするために、Railsアプリ + RSpec + FactoryGirlを用意したら、

  • 自分はこんな感じでRailsアプリを作っております | Oh My Enter!

    Railsを使い始めてX年経ったこともあり、自分なりの開発パターンが形成されていることに気づきました。今日はそれを恥ずかしげもなく晒してみようかと思います。 Gemfile 自分の中で必須のgemたちです。その他はプロジェクトに合わせ適宜追加する感じです。 📄Gemfile source 'https://rubygems.org' ruby "2.0.0" gem 'rails', '~> 4.0' gem 'sqlite3' gem 'sass-rails' gem 'uglifier' gem 'coffee-rails' gem 'jquery-rails' gem 'turbolinks' gem 'jbuilder' gem 'draper' gem 'ransack' group :development do gem 'rack-mini-profiler' end gr

    自分はこんな感じでRailsアプリを作っております | Oh My Enter!
  • Railsでサービスとフォームを導入してみる話 - assertInstanceOf('Engineer', $a_suenami)

    この記事はRuby on Rails Advent Calendar 2013の6日目の記事です。 前日は @tkawa さんの「Favoriteの設計実装はパターンとして使える」でした。 Railsで適切に責務を分割するということ RailsはいわゆるMVCと呼ばれるアーキテクチャパターンにのっとったフレームワークであり、プロジェクトを作成するとデフォルトでmodels/、views/、controllers/などのディレクトリが作成されます。 基的にロジックを記述する場所はモデルであり、ビューには表示処理だけを、コントローラにはアプリケーション上必要な手続きだけを記述するべきであると一般的には言われています。*1 ただ、それを忠実に実践していった結果、モデルが肥大化しメンテナンシビリティやテスタビリティが低下するという問題も多く指摘されています。 これについては4日目に @joker

    Railsでサービスとフォームを導入してみる話 - assertInstanceOf('Engineer', $a_suenami)
  • てめえらのRailsはオブジェクト指向じゃねえ!まずはCallbackクラス、Validatorクラスを活用しろ! - Qiita

    てめえらのRailsはオブジェクト指向じゃねえ!まずはCallbackクラス、Validatorクラスを活用しろ!RubyRails ちょっと煽り気味のタイトルにしてみましたが、Railsで開発する時は意識的にOOPに寄せないとオブジェクトの力が活かせなくなるよってことと、Railsが提供しているクラスの責務を分割することを支援してくれる機能について話をします。 ActiveRecordの性質 Rails開発においては、モデル層にロジックを書いてコントローラーは薄くしろ、というのはしつこく言われているので、概ね浸透してきていると思います。 それに加えて、最近私が結構しつこく主張しておきたいのが、モデル = ActiveRecordでは無いよ、ということです。 ActiveRecordは成り立ちから言うと、ロジックとDBへの永続化をまとめてカプセル化するアーキテクチャパターンから来ています。

    てめえらのRailsはオブジェクト指向じゃねえ!まずはCallbackクラス、Validatorクラスを活用しろ! - Qiita
  • RailsでFactoryGirlを使ってみるメモ [俺の備忘録]

    Google+ボタン はてなブックマークボタン 更新日時: 2014年02月25日(火) 作成日時: 2013年08月06日(火) 前の記事 / 次の記事 Fixtureは充分にイケてると思っているので、基Fixtureで満足なんだけど、 Fixtureにできないことをするために、FactoryGirlを使ってみようと思い立ったメモ。 自分が知らないだけでFixtureできるのかも知れないけど、 DBに保存はしないけど値だけ欲しい時がある。 Rspecで言うと "valid_attributes" である値。 今までは自力で適当にモジュールつくって読み込んでたんだけど、 折角FactoryGirlってgemがあるんだから使ってみようかと思った。 ※ 適当にどんどん追加していったらかなり長くなってしまったので 暇が訪れたらまとめて新しい記事にしたいと思う(2014/02/25) 何年後にな

  • 肥大化したActiveRecordモデルをリファクタリングする7つの方法(翻訳)

    更新情報: 2013/11/19: 初版公開 2021/01/08: 訳文見直し、追記 こんにちは、hachi8833です。今回は、自分が知りたかった、Active Recordモデルのリファクタリングに関する記事を翻訳いたしました。1年前の記事なのでRails 3が前提ですが、Rails 4以降でも基的には変わらないと思います。リンクは可能なものについては日語のものに置き換えています。 なお、ここでご紹介したオブジェクトは、app以下にそれぞれ以下のようにフォルダを追加してそこに配置します。 注記: 以下は使われそうなフォルダを列挙しただけであり、実際にはこの一部しか使いません。 Value Object Service Object Form Object Query Object View Object Policy Object Decorator ⚓ 肥大化したActive

    肥大化したActiveRecordモデルをリファクタリングする7つの方法(翻訳)