Ruby on Rails v3.2.11 アセットパイプラインとは Rails のアセットパイプライン（Assets Pipeline）は JavaScript や CSS、画像ファイルといった HTML に付随する細々としたファイル達（アセットファイル）を連結したり圧縮することで効率的にアクセスできるようにする仕組み（フレームワーク）です。 アセットパイプラインの役割 アセットパイプラインは以下のような役割をもっています。 1 複数の JavaScript と CSS をそれぞれ１つのファイルに連結する ⇒ ブラウザからのリクエスト数を減らす 2 JavaScript と CSS を圧縮してサイズを減らす ⇒ 文法上必要でない空白を削除したり、変数名を1文字にしたり 3 アセットファイル名にハッシュ値（MD5）を付加する ⇒ ブラウザがファイルのキャッシュ/読み直しを正しく行える 4

はじめに 外部サービスと連携したい！アプリ開発をしたい！際にAPIサーバを作成することがあるかと思います。 今回はrubyを使った色々なAPIの実装方法をご紹介したいと思います。 登場人物 今回は下記の所感、実装方法をご紹介していきます。 リクエスト取得部分 Rails Grape レスポンス部分 Rails RABL Jbuilder 前提 今回は全ての検証で下記のテーブル、URL、出力になるようになっています。 Userテーブルの構成 id name addr1 addr2

はじめに 自分が rails をさわり始めたときはバージョン1からバージョン2に変わるあたりだったのですが、バージョン2が出た年を振り返るとなんと2007年でした。 月日の流れが速い事に驚く中、早く知ってたら良かったのになぁって事をつらつらとまとめてみました。 最近 rails さわり始めてみたよ！って方の参考になれば良いなと思います。 今回は便利な gem とかではなく、素のrailsで出来ることを挙げています。 ちなみにバージョンは以下の環境です。 About your application's environment Ruby version 2.1.3-p242 (x86_64-darwin14.0) RubyGems version 2.2.2 Rack version 1.5 Rails version 4.1.8

RubyとRailsにおけるTime, Date, DateTime, TimeWithZoneの違いRubyRails 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 とされているため、 Timeを使うことを推奨します。 https://docs.ruby-lang.org/ja/latest/class/DateT

この記事の目的 Rails の STI を使うようなケースで、STI の代わりに PostgreSQL のテーブル継承を使ってみる方法を紹介します。 STI とは Single Table Inheritance 単一テーブル継承 モデルクラスを継承で表現し、永続化部分はスーパークラスのテーブル１枚でまかなう STI の実装例（親クラス） class CreateCars < ActiveRecord::Migration def change create_table :cars do |t| t.integer :weight t.string :color t.string :type # STI 用のメタデータカラム t.timestamps end end end

RailsのActiveRecordを使って次のようにすることでSTI(Single Table Inheritance: 単一継承テーブル)を行うことができます。 テーブルにtype(string)カラムを持たせる そのテーブルに対応するモデルクラスを継承したクラスを作成する 例えば、本(Book)とコンピューター(Computer)の商品を扱っており、一部カラムが同じで一部カラムが違うので、次のように１つのテーブルを使い、３つのモデルを作成することで、Rails側でbooksテーブルとcomputersテーブルが存在しているようにBookオブジェクトとComputerオブジェクトを扱うことができるようになります。 これにより、 Product.all # => Book, Computerモデルを含めたすべてレコードをproductsテーブルから取得 Computer.all # =>

前回のモデルのテストでは、姓、名、姓（カナ）、名（カナ）という4つの属性に対して、「空であってはならない」という仕様をRSpecで記述し、テストしました。 しかし、これほど簡単な仕様にしてはテストコードが複雑でしたね。 今回は、このテストコードの簡素化がテーマです。 妥当なオブジェクトのテストを追加 前回書いたテストコードの最終形は次の通りです： require 'spec_helper' describe Customer do %w{family_name given_name family_name_kana given_name_kana}.each do |column_name| specify "#{column_name} は空であってはならない" do customer = Customer.new( family_name: '山田', given_name: '太郎'

今回は、Ruby on Rails のモデルクラスに対するテストの書き方を解説します。 Customer モデルの仕様 この連載のサンプルアプリケーション Sinope がいったい何を目的とするものなのかまだ決まっていませんが、仮に「顧客（customer）」という概念が必要で、そのために Customer という名前のモデルを用意するものとしましょう。 このモデルの主な仕様は以下の通りです： 姓（family_name）、名（given_name）、姓フリガナ（family_name_kana）、名フリガナ（given_name_kana）が必須入力項目。 それぞれ40文字以内。 姓と名で許される文字の種類は、漢字、ひらがな、カタカナ。 姓フリガナと名フリガナはカタカナのみ。ただし、ひらがなでの入力も受け付けて、カタカナに自動変換する。 いわゆる半角カナは全角カナに自動変換する。 今回は

ActiveRecord の attribute 更新方法ってどんなものがあって、それぞれどんな違いがあるかご存じですか？ 案外色々とあったので表にまとめてみました。リファレンスやソースコードを参考にしつつ、Rails 4.2 でテストしています。 単一の attribute 更新 メソッド 保存 バリデーション(*1) コールバック(*2) readonly チェック(*3) updated_at の更新 補足 使用例

なぜTransactionが必要なのか Transationの目的は、あるいコードブロックにあるSQL文の変更を、全部成功することを守るための存在である。Transactionにより、データの統一性を保ことができる。銀行などの受け入れと引き出しの処理には必要でしょう。二つの処理の中一つが失敗すると、コードブロークにあるSQL処理を全部ロールバックされるのが、Transactionの特徴である。 ActiveRecord::Base.transaction do david.withdrawal(100) mary.deposit(100) end Transationのロールバックが発火条件 Railsでは、ロールバックが発火するには、「例外」が必要である。これがTransactionを使うときのもっとも重要なことである。 例えば、Railsでは #update_attributeは例外を

RailsのWebアプリケーションを英語化(多言語化)をサポートしてくれるGem「i18n」の紹介です。 🎂 i18nのベーシックな使い方デフォルトの言語を日本語にするには、config/application.rbの次のように指定します。

# URLへリダイレクト(アクションはconfig/routes.rbを参照) redirect_to URL # indexアクションへリダイレクト redirect_to action: 'index' # usersコントローラのindexアクションへリダイレクト redirect_to controller: 'users', action: 'index' # usersコントローラーのshowアクションのid=8へリダイレクト redirect_to controller: 'users', action: 'show', id: 8 # 前ページへリダイレクト redirect_to :back # indexアクションへstatusコード404でリダイレクト redirect_to action: 'index', status: 404 # indexアクションへstat

ローカルの環境で単体でのテストの場合はパスするのですが、 一括でのテストの場合に、たまにエラーになるケースがあります。 環境は下記のような感じです。 ruby 2.1.3 rails 4.1.8 rspec 3.1.0 rspec-core-3.1.7 capybara-2.4.4 poltergeist-1.5.1 phantomjs 1.9.8 config.order = 'random'にしています。 randomでない場合に一括実行すると必ずエラーになるのでrandomにしています。 テストコードは、具体的には以下。その他にも同じようにランダムにエラーになる箇所があります。 scenario '顧客を新規追加する', js: true do visit new_customer_path tab = first('#new_customer') # Ambiguous match

Rspec/Capybara で poltergeist や capybara-webkit を使ってJavascriptを含めたテストを行っている場合にランダムにテストが失敗することがある。(Random fail) ###主な原因の一つは テストの実行中にAjaxを発生させてAjaxが完了する前にテストが終了し次のテストが同じDBを参照しようとした時に起こる。 この問題の一つの解決策は Ajaxが終了していることをテストの最後に確認すること。 THOUGHTBOT, INC. の記事に一つの解決策を紹介している。 ソースコードはこちら # spec/support/wait_for_ajax.rb module WaitForAjax def wait_for_ajax Timeout.timeout(Capybara.default_wait_time) do loop until

はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第4回です。 今回はCapybaraを使ったフィーチャスペックについて説明します。 ただし、今までの記事とは異なり、フィーチャスペックのイロハよりも「Capybaraの使い方」に重点を置きます。 なぜなら、僕個人の経験からいって、フィーチャスペックで困るのは「このブラウザの操作って、どうやってコードで表現するの？？」というケースが大半だからです。 それ以外は第1回～第3回の内容をそのまま応用できるので、特に「フィーチャスペックだから困る」ということはないと思います。 今回は説明する主な項目は以下の通りです。 フィーチャスペックの基本 ページの移動や画面のクリック、フォームの操作など 画面やフォームの検証 画面の操作や検証の応用テクニック その他

1年以上経過しており情報が古い可能性があります 環境 MacOSX 10.11 RSpec 3.3.2 Capybara 2.5.0 事前に見るべきリファレンス capybara-readme-ja 事象 テストは通っているが、どうもボタンを押せていない。ということが少なからずある。 例えばFacebookのログインページのボタンである。 % rspec xxtest.rb Run options: include {:focus=>true} All examples were filtered out; ignoring {:focus=>true} Randomized with seed 2062 アカウント登録フロー Facebookでのログイン Top 1 slowest examples (30.18 seconds, 100.0% of total time): アカウント

HelperでviewをDRYに Helperとは、viewをよりシンプルにDRYに書くためのモジュール。view以外もhelpできるけど、基本的にはviewをhelpしてくれるものだと抑えましょう。 例 <%= form_tag %>とか<%= link_to %>とか...。Railsを書いていてこれらを使ったことがない人はいないでしょう。 こいつらはrailsがデフォで準備してくれてる便利なヘルパーたち。そのシンプルさDRYさは言わずもがな。 helperを作ろう デフォで用意されてるhelperは汎用的なもの。自分のアプリで繰り返し登場するコードや、viewのコードを汚くしてるものには、helperを定義してSimpleにDryにしてあげよう。 使用例1: 繰り返し出てくる文言 あんまりhtmlに繰り返し使う文言はベタ打ちしたくないよね。変更があったら全ていちいち変えなきゃいけない

※追記: fields_forにかんして、新しくこちらの記事にまとめたので是非一緒に参照してください。 form_tagとform_forの使い分け Railsにおけるformを理解するために、最初に理解すべきなのがこの違いです。 Railsのform_for/form_tagの分け方の意図としては、 form_for: 任意のmodelに基づいたformを作るときに使う form_tag: modelに基づかないformを作るときに使う ということです。 つまり、あるuserモデルに基づいたuserを作成するときはform_forを使い、 そうではなく、検索窓のような何のモデルにも基づかないformを作りたいときはform_tagを使うのが原則です。 具体的に何が違って、その用途はどう分かれているのか。 結論としてform_forはモデルオブジェクト扱う上で便利 post先のurlは不要

bundlerについて分かってる風になっていたので、一度整理します。 特徴 ・Gemパッケージの種類やバージョンの管理 ・複数PCで必要なGemパッケージをインストールする仕組みを提供 ->チーム間で同一の開発環境を簡単に構築することが可能に。 運用方針 基本的に、gemコマンドでインストールするのはBundlerのみで、その他のgemパッケージは、Bundler経由でインストールするという方針。

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