= form_for @post do |f| =f.label :body =f.text_field :body =fields_for @category do |c| %> =c.label :name =c.text_field :name
Ruby on RailsでDev環境は使ったことあるけど、test・prod環境を考慮した環境構築をしたことがない人にお勧めの内容です。 サーバー構成図 サーバーの役割 リバースプロキシサーバー(ホスト名:rp01) ロードバランサ機能を使ってWEBサーバ二台に処理を振り分け、アクセスを1台のサーバーに集中させない WEBサーバーを外部から隠せることでセキュリティ面の向上 WEBサーバー(web01、web02) webサーバーを2台用意することでアクセスが1つのサーバーに集中しないため、レスポンスを早くできる マスターDBサーバー(db01m) DB内容をもう1台のDBサーバー(スレーブ)へリアルタイムにコピーし、障害でマスターが停止したときはスレーブに切り替える スレーブDBサーバー(db01s) 読み込み専用のサーバー。書き込みをしない分レスポンスが早くなる マスターの内容を常にコ
Rails4時代の高速テスト環境 Rspec+Guard+FactoryGirl+Spring[NEW!]RailsRSpecGuardFactoryGirlspring Railsのテスト環境の定番といえば Rspec Guard FactoryGirl Spork このへんの組み合わせが定番だったんではないでしょうか。 Sporkでテスト環境をプリロードして、Guardでファイルを監視してガンガンテストを回してと。 今回はこのSporkを最近メキメキと頭角を現してきているSpringに置き換えて よりモダンな高速テスト環境の作り方を説明します。 Springのいいところ このSpringなにがいいって、設定がすごく簡単。 おまけにGuard+Rspec以外にもrails generateやrake routesなど他のコマンドも高速化してくれます。 一度体験したらもう戻れません。 必要
みなさん、こんにちは。 ウェブ・サーバーサイドを担当しています、Railsエンジニアの黒田です。 マネーフォワードも早いもので、サービスインしてから2年以上が経過しました。 サービスをご愛顧してくださっている皆様には、心から感謝しております。 さて、今回のエンジニアブログは「リファクタリング」についてです。 マネーフォワードのように、ユーザーファースト&デリバリー優先で爆速開発を進めていると、サービスとしてはイケてても、コード的にイケてるとは言い難い部分が発生してしまいがちです。 「思いやりのないコード」「可読性が悪いコード」「必要以上に複雑なコード」は、バグ発生率を高め、開発スピードを低下させ、何よりエンジニアの気分を憂鬱にさせてしまいます。。。 マネーフォワードでは継続的かつ積極的にリファクタリングの時間を創る取組みをしていますが、そのなかで今回はRailsのリファクタリングでとても便
id:joker1007 さんに触発されました。 Ginza.rb 21回の発表資料。rails_adminのつらみとオススメgem達。 1年間で10個以上アプリやgemを作っている中でよく使うgemをまとめてみます Railsアプリ(rails new した直後に必ず入れる) annotate https://github.com/ctran/annotate_models modelのソースの先頭にテーブルのスキーマ情報を付加してくれるgem。いちいちschema.rbを見に行く必要がなくなるので超ベンリ こんな感じ # == Schema Information # # Table name: plugins # # id :integer not null, primary key # name :string # title :string # version :string #
Ruby Advent Calendar 11日目 Ruby - Rails開発で有用な便利Gem一覧:2013年版 - Qiita ↑去年のAdventCalendarで書いた上記の記事の2014年版です。 だんだん毎年恒例的になって来ました。 最近はデファクトスタンダードがほぼ固まってきて、かなり毎回使うGemのリストが固定化して来ました。 ※2014/12/11時点 DBアダプタ sqlite3 pg mysql2 この辺りはもう変わらないですね。 RubyやRailsのバージョンが上がっても継続的に開発が続けられているのは素晴らしいと思います。 ログイン認証 omniauth omniauth-twitter omniauth-facebook omniauth-github omniauth-identity (omniauth-githubのリポジトリのURLが変わってました。
はじめに RSpecを使ってテストを記述している際、テストの実行前にデータをテーブルに登録しておきたいケースが多々あるかと思います。RSpec内でActiveRecordを使ってデータを登録することもできますが、複数のテストケースで同じデータを使いたい場合、データの定義は一箇所で行いたいところです。 この様な場合、Factory Girlを使用すると、一箇所でテストデータを定義できます。今回はこのFactoryGirlの使い方について書きたいと思います。 使い方 使い方の大まかな流れとしては、 FactoryGirlが使用できるようにする 定義ファイルにデータを定義する 必要とするテストケースにてファイルを読み込み、データを適時加工して登録する という感じとなります。尚、この定義したデータを「Factory」とも言います。以下、手順です。 1.Gemfile Gemfileに以下を記述し、
require 'spec_helper' describe "HomePages" do subject { page } describe "Home page" do before { visit root_path } it { should have_content(full_title('')) } it { should have_title(full_title('')) } it { should_not have_title('| Home') } end describe "Help page" do before { visit help_path } it { should have_content('Help') } it { should have_title(full_title('Help')) } end describe "Contact page"
はじめに RSpecは難しい、よくわからない、といったコメントをときどき見かけます。 確かにちょっと独特な構文を持っていますし、機能も結構多いので「難しそう」と感じてしまう気持ちもわかります。 (構文については僕も最初見たときに「うげっ、なんか気持ちわるっ」と思った記憶がありますw) しかし、RSpecに限らずどんなフレームワークでも同じですが、慣れてしまえばスラスラ書けますし、実際僕自身は「RSpecって便利だな-」と思いながらテストコードを書いています。 そこでこの記事では、僕が考える「最低限ここだけを押さえていれば大丈夫!!」なRSpecの構文や、僕が普段よく使う便利な機能をまとめてみます。 具体的には以下のような構文や機能です。 describe / it / expect の役割 ネストした describe context の使い方 before の使い方 let / let!
目的 Warden による 認証を行う際のポイントを押さえることを目的とします。 そのためのサンプルの紹介と解説を行います。 Warden は認証の仕組みを提供してくれるもので、認証の方法自体は自分で実装する必要があります。 Rack::Auth による認証とは異なり、認証したユーザの情報はクッキーに保存されます。 クッキーに保存するユーザの情報の制御が可能です。Rack::Auth がサポートしないログアウトも実現できます*1。 Warden は基盤として使われることが多く、Warden を基盤にユーザの管理を含めた機能を提供してくれるライブラリもありますが、 本ページでは直接 Warden を使って認証を実現する方法を説明します。 本サンプルでは Web アプリケーションフレームワークに Sinatra を使っています。 必要なポイントは各節にある表を見るだけで把握できるようにまとめて
Railsで各種ファイルをアップロードしてDBに保存するようなアプリを作成する場合、アップロードしたファイルのmime typeも同時に保存したい場合があります。 例えば、 mime typeでvalidationを行う。 jpg、pngのアップロードは許可するが、gifは許可しない等。 mime typeに応じて異なる処理を行う。 pdfがアップロードされたら各ページを画像として別途保存する。 jpgがアップロードされたらexifの情報を破棄する等。 mime typeの判別するには、最も簡単な方法としてファイルの拡張子で判断する方法があります。 ところがこの方法では、拡張子がついていないファイルに関してmime typeの判別ができません。 また、ファイルの拡張子とファイルの本当の中身が一致しているとは限りません。 jpgの拡張子がついたmicrosoft wordのファイ
Railsアプリケーション構築ガイド¶ 業務でRuby on Railsを利用する人のための、アプリケーション構築ガイド 最終更新日: Feb 03, 2018 Ruby on Railsは、流儀・規則に従うことで効率的なシステム開発が可能となるWebアプリケーションフレームワークです。 レールの上に乗って開発を行っているうちは、 少ないコード量で複雑なアプリケーションを 簡単に実装できる、Railsというフレームワークの強力さ、美しさを体感できるはずです。 しかし、少しでもレールから外れたアプリケーションを実装しようとすると、途端に複雑になるのも事実です。 業務アプリケーション構築の分野では、Railsの流儀とは相容れない実装を強いられる事が多々あります。 レールから外れたアプリケーションをよく考えずに実装すると、 コードが難解になり、システムのメンテナンス性が大きく下がってしまいます。
What is Better Specs Better Specs is a collection of best practices developers learned while testing apps that you can use to improve your coding skills, or simply for inspiration. Better Specs came to life at Lelylan (open source IoT cloud platform) and checking out its test suite may be of inspiration. Better Specs focus on Rails testing, but our goal is to create testing guidelines covering mos
目次 TL;DRテーブル構成 Railsモデル構成has_many, through の定義 belongs_to, through は使えない?1. delegate を使う方法2. has_one, through を使う方法 includes も使うことができるどちらの方法が良いか?参考TL;DRhas_many+throughの逆の関連の定義には: belongs_to+throughは使えないdelegate or has_one+through が使えるhas_one+through の方が効率もよく、 includes も使えてオススメテーブル構成とあるRailsアプリケーションでこんなテーブル構成があったとします。 Railsモデル構成ユーザー(User)は複数の記事(Post)をもっていて、その記事は複数のコメント(Comment)を持っている、という状態です。 clas
Ruby on Rails 7.1.3.4 RDOC_MAIN.md railties/RDOC_MAIN.md Last modified: 2024-06-04 18:21:34 +0000 Welcome to Rails What’s Rails? Rails is a web-application framework that includes everything needed to create database-backed web applications according to the Model-View-Controller (MVC) pattern. Understanding the MVC pattern is key to understanding Rails. MVC divides your application into three laye
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く