Rails 4 へのアップグレード時に遭遇した問題 - クックパッド開発者ブログ
技術部の鈴木 (@eagletmt) です。 クックパッドでは8月に本体アプリケーションや API サーバ等で使われている Rails のバージョンを 3.2 から 4.1 へ順次アップグレードを行いました。 アップグレードは主に松田さん (@amatsuda) と私で進めました。 この記事ではアップレードの際に遭遇した問題の一部を紹介します。 MySQL strict mode の有効化 MySQL を使っている場合、Rails 4.0 からデフォルトで @@SESSION.sql_mode = 'STRICT_ALL_TABLES' が最初に実行されるようになりました (Ruby on Rails 4.0 Release Notes) 。 これを無効化するために database.yml で strict: false という設定が用意されています。 しかし、同じく Rails 4.0
rails4 での assets:precompile の高速化 - HsbtDiary(2014-05-29)
■ rails4 での assets:precompile の高速化 rails4 で assets:precompile を有効にするようにしてから、デプロイ毎に precompile しているとデプロイ途中にデザインが崩れたり、そもそもデプロイ時間が5分以上かかるようになってしまってリリースの高速化も何もあったもんじゃないなーということで、技術的に解決しておいた。 rails3 の頃は turbo-sprockets とかあって、こういうのを入れれば変更されたファイルだけを precompile するので、こういう gem あるのかなあと探していたら、そもそも本体に組み込まれているというのを知った http://yetimedia.tumblr.com/post/33320732456/moving-forward-with-the-rails-asset-pipeline ようは p
delayed_job + Rails4 + Capistrano + rbenv - There's an echo in my head
Rails 4（ActiveRecord）でdelayed_jobを使いつつ、それをCapistranoでデプロイする方法のメモ。基本的に本家のWikiに従う。 キューの機能を使う まず必要なgemをインストールしてマイグレーションファイルと実行ファイルを作成する。 # Gemfile gem "delayed_job" gem "delayed_job_active_record" gem "daemons" # デプロイ先でデーモンとして動かすのに必要 $ bundle install $ bundle exec rails g delayed_job:active_record $ bundle exec rake db:migrate 実行ファイルはbin/delayed_jobに作成される。Rails3以前はscript/delayed_jobに作られていたので要注意。 ワーカー
Rails4へのアップデート時に引っかかったポイントいくつか - Qiita
Rails 4.0.0がリリースされたので今参加しているプロジェクトのアプリのアップデートが出来るかを試してみました。 やってみた結果としては、2.3 -> 3.0や、3.0 -> 3.1に比べると大分楽にバージョンアップできる感じです。 たまたま今のプロジェクトで引っかかった問題について、メモがてらまとめておきます。 rake rails:update diffを見ながらconfigファイルを書き換える。 そんなに大きな変更は無い。 rails4からはinitializerに色々移せって感じで、application.rbが軽量化されてるけど、元のままでも別に問題無い。 設定項目の重複だけ注意。 strong_parameters 元々、gemで先行導入して取り入れていたので概ね問題無く移行できました。 attr_accesibleを利用したセキュリティ対策は、外部のgemに分離されてい
Rails 3.2.12を4.0.0にアップグレードした
Rails 4.0.0が出ていたので、3.2.12で動かしているウェブアプリ（このブログ）を4.0.0にアップグレードしてみることにしました。 Rails 4.0: Final version released! http://weblog.rubyonrails.org/2013/6/25/Rails-4-0-final/ (1) GemfileのRailsのバージョンを4.0.0にする coffee-rails、sass-railsも4.0.0にしました。 古いrailtiesに依存していてbundle updateが動かないことがあるためです。 (2) 以下のコマンドを実施。 以下、rake rails:updateの作業ログです。 boot.rbは上書き routes.rbはスキップ application.rb上書き（このアプリに関してはtime_zoneを指定していただけだった
Removing config.threadsafe! | Tenderlove Making
TL;DR: config.threadsafe! can be removed, but for Rails 4.0 we should just enable it by default. A while back a ticket was filed on the Rails tracker to turn on config.threadsafe! mode by default in production. Unfortunately, this change was met with some resistance. Rather than make resistance to change a negative thing, I would like to make it a positive thing by talking about exactly what confi
Rails 4.0: Release Candidate 1 released!
Just in time for the opening of RailsConf, we managed to push out the first release candidate of Rails 4.0. This incorporates no less than 1,368 commits since beta 1. You can see the full list of changes on Github. If you’re interested in a high-level review of what’s in Rails 4.0, please see the announcement we made for beta 1. As last time, please give this release candidate an honest try. This
Rails 4のturbolinksについて最低でも知っておきたい事
Rails 4のturbolinksについて最低でも知っておきたい事 （追記）turbolinksに関するセキュリティ上の懸念について turbolinksとは、ページ遷移をAjaxに置き換え、JavaScriptやCSSのパースを省略することで高速化するgemで、Rails 4からはデフォルトで使用されるようになります。 高速化は大歓迎なのですが、JavaScriptのイベントの起き方が変わるため、Rails 3までの書き方をしているとまず間違いなく問題が起きます。しかも、Rails 4ではデフォルトの機能ですので、最新版を使いたいなら必ず知っておかなければいけません。 本エントリではturbolinksを使うために絶対に知らなければいけないことを分かりやすく紹介したいと思います。 動作 turbolinksの動作は、すごく大雑把に言うと以下の通りです。 リンクのclickイベントをフッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
