Sooey

2014-11-19 17:17:21 +0900

Rails 4.0でrespond_to利用時にUnknownFormatが発生しないようにする方法。

コントローラーのアクションが以下のようなコードになっている場合、

class UsersController < ApplicationController
  def show
    @user = User.find(params[:id])
    respond_to do |format|
      format.html
      format.xml  { render xml: @user }
      format.json { render json: @user }
    end
  end
end

/users/1.textのようなパスにリクエストがあるとActionController::UnknownFormatが発生する。

通常はその挙動のままで構わないと思うが、要件によっては「不明なフォーマットが指定された場合はすべてtext/htmlを返したい」ということもありうる。そのような場合は、formatanyメソッドを使うことでデフォルトの挙動を指定することができる。

class UsersController < ApplicationController
  def show
    @user = User.find(params[:id])
    respond_to do |format|
      format.any
      format.xml  { render xml: @user }
      format.json { render json: @user }
    end
  end
end

anyメソッドは、any(:xml, :json)のように受け入れるフォーマットを引数で指定することもできる。

format.any(:xml, :json) { render request.format.to_sym => @user }

また、anyメソッドにはallというエイリアスも設定されているので、format.allという指定でもよい。

参考:

2014-11-17 02:33:36 +0900

Herokuアプリにデプロイされている一番新しいコミットについての情報を取得する必要があったため、Platform APIのReleaseを利用した。

Platform APIでの認証はAuthorizationヘッダにAPIキーを指定することで行い、結果のソート条件やページングについてはRangeヘッダで指定する。

以下の例のRangeヘッダの場合は、Releaseリソースについて「versionを降順に1件だけ取得する」という指定になる。

$ curl -n -X GET https://api.heroku.com/apps/Herokuアプリ名/releases \
  -H "Accept: application/vnd.heroku+json; version=3" \
  -H "Authorization: Bearer XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" \
  -H "Range: version ..; order=desc,max=1"

2014-10-05 15:18:30 +0900

A simple guide for DB migrations Craig Kerstiens

PostgreSQLでデータベースが巨大な場合は、NOT NULL制約を持つカラムの追加を以下のようなステップに分割することで、書き込みのロックを減らすことができるようだ。

  1. 新しいカラムをNULL可、デフォルト値ありで追加する
  2. 既存レコードの新しいカラムに値を設定する
  3. 新しいカラムにNOT NULL制約を追加する

これは、PostgreSQLがAppend only logな仕組みなため、UPDATEもDELETEも実際には新しいデータの書き込みであるということに起因しているらしい。

2014-07-19 03:25:13 +0900

jQueryでは、クロスドメインなAjaxを行った際にはリクエストヘッダにX-Requested-Withが付かないようだ。

サーバー側のRailsで

if request.xhr?

といった条件で判定しているような場合に条件が真にならずにはまるので、そのようなケースでは以下を参考に

サーバー側がOPTIONSメソッドによるpreflightリクエストに応答できるようにした上で、jQueryのAjaxリクエスト時のsettingsに

headers: {'X-Requested-With': 'XMLHttpRequest'}

を含めるようにする必要がある。

2014-07-08 11:17:15 +0900

Railsアプリのステージング環境を自動で構築してくれるTeatroというサービスの話。

Teatro

動作の流れは、

  1. GitHubアカウントでサインアップする
  2. 連携させるリポジトリを選ぶ(GitHub側にフックが設定される)
  3. リポジトリにPull Requestが作成されると、自動的にステージング環境の構築が始まる(その際、PRにもコメントがされる)
  4. ステージング環境の構築が完了すると、http://ブランチ名.Organization名-リポジトリ名-トークン.ttrcloud.com/ のようなURLが割り当てられる

といった感じ。

詳細な設定方法やどんなミドルウェアが使えるのかについては、Helpを参照しましょう。

現時点では以下のミドルウェアが使えるようです。

  • PostgreSQL
  • MySQL
  • Redis
  • Elasticsearch
  • RabbitMQ
  • MongoDB

試しに、Heroku上でRails 4.1 + PostgreSQL 9.3で運用しているアプリに対して使ってみたところ、

  • config.ruに日本語コメントがあったのでUnicornの起動時にinvalid byte sequnceで落ちた
  • production.rbconfig.force_ssl = trueしているためhttps://なURLにリダイレクトされるが、そこでアプリのページではなくTeatroのトップページが表示されてしまう(Teatroのステージング環境ではenvironmentがproductionとなる)

といったところでハマりました。特に後者は今のところどうにもならなそうな気がするので検証はそこまで。

TeatroはまだBetaのようですが、お値段はアクティブなステージング環境5個、プロジェクト10個、ユーザー無制限で$50/mo.と、ビジネスで使うならわりとリーズナブルだと思うので、ちゃんと動作するようになったら導入してみてもいいかなと思いました。

以下、試した際のスクリーンショット。

Screen Shot 2014-07-08 at 10.37.49 AM

Screen Shot 2014-07-08 at 10.39.00 AM

Screen Shot 2014-07-08 at 10.44.33 AM

Screen Shot 2014-07-08 at 10.44.42 AM

Screen Shot 2014-07-08 at 10.47.30 AM

Screen Shot 2014-07-08 at 10.48.18 AM

Screen Shot 2014-07-08 at 10.48.37 AM

Screen Shot 2014-07-08 at 10.48.46 AM

Screen Shot 2014-07-08 at 10.48.57 AM

Screen Shot 2014-07-08 at 10.52.24 AM