[rails] sassなtwitter-bootstrapをrailsで使う

いまさらですが、twitter-bootstrapが便利なことを知りました。
これをRails3に適用するにあたり、せっかくsassでCSSも無駄なく書けているので、sassを使いつつ、twitter-bootstrapも使いたい、 という欲求が出てきました。

そんな時は、 bootsrap-sassを使います。
以下、導入手順です。

Gemfile

  gem 'bootstrap-sass'

bundle install

  $ bundle install

app/assets/javascripts/application.js

  //= require jquery
  //= require jquery_ujs
  //= require bootstrap
  //= require_tree .

app/assets/stylesheets/bootstrap_and_overrides.css.scss

  @import "bootstrap";
  @import "bootstrap-responsive";

これだけで、bootstrapがsassで使えるようになりました。
bootstrap_and_overrides.css.scssでは、bootstrap自身がカスタマイズを許容しているスタイル変数、
具体的にはCustomize - Bootstrapにある 変数に対して、

  $bodyBackground: #ddd;
  $textColor:      #333;

のように、オーバライドします。

殊、bootstrapのレイアウト機構は、CSSがスパゲッティになりがちな僕にとっては強力な助けになっています。

参考サイト

• Twitter Boostrap and Rails - RailsApps

[rails] RSpecを使う際のポイント

現在、rails3アプリを開発中です。
テストにはRSpecを使用しています。
RSpecを使うにあたって、僕が注意している2点を書いておきます。
(別にRSpecだから、ということでもないですね・・・)

カバレッジ100％をキープする。

Rubyはコンパイルによる単純ミスの発見ができないため、
くだらないタイポなどが残ってしまう可能性があります。
RSpecとrcovやsimplecovなどのカバレッジ計測ツールを組み合わせて、
一度も通っていないルートをなくしています。

fixturesは必要最小限に抑える。

fixturesによるテストデータはとても便利です。
これに頼りすぎて、なんでもかんでもfixturesとして定義してしまうと、
テストケース間の結合度が密になり、テストのメンテナンス性が低くなります。
僕のチームでは、fixturesは、もっとも単純な正常系ケースを実行するのに必要な量のレコードのみを 定義するに留めて、他のケースに必要なデータはbeforeで作るか、スタブオブジェクトを使って テストするようにしています。

[nginx]Rails3アプリの静的ファイルをnginxに処理させる。

Rails3アプリをnginx+unicornでホストする場合、Rails3内部に持つ静的ファイル(assetsなど)は、 nginxに応答させる方がパフォーマンスが出ます。

それを実現するには、nginxのコンフィグレーションで、次のように記述します。

  upstream rails_app {
      server  unix:/tmp/unicorn_rails_app.sock;
  }

  server {
      listen  80; 
      server_name rails_app.somedomain.com;
      location ~* \.(html|css|js|ico|gif|jpe?g|png)(\?[0-9]+)?$ {
          root /path/to/rails_app/current/public;
          break;
      }
      location / { 
          if (-f $request_filename) { break; }
          proxy_set_header X-Real-IP $remote_addr;
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header Host $http_host;
          proxy_pass  http://rails_app;
      }
  }

[rails]レガシーなDBにつなぐ際のRakeタスク

Railsアプリを開発する際に、レガシーなDBを扱う場合を考えます。
この場合のアプリケーションはDBのスキーマ情報を定義しないため、RSpecを導入してrake specを実行した場合、 schema.rbが空であるため、db系のrakeタスクが動かずに、エラーとなります。
これを回避するために、db系のrakeタスクをアプリケーションで上書きして、 何もしないタスクに置き換えることができます。

アプリケーション定義Rakeタスクファイルとして、

{Rails.root}/lib/tasks/db.rake

を作成し、次のように実装します。

module Rake::TaskManager
  def remove_task(task_name)
    @tasks.delete(task_name.to_s)
  end
end

Rake.application.remove_task "db:create"
Rake.application.remove_task "db:drop"
Rake.application.remove_task "db:fixtures:load"
Rake.application.remove_task "db:migrate"
Rake.application.remove_task "db:migrate:status"
Rake.application.remove_task "db:rollback"
Rake.application.remove_task "db:schema:dump"
Rake.application.remove_task "db:schema:load"
Rake.application.remove_task "db:seed"
Rake.application.remove_task "db:setup"
Rake.application.remove_task "db:structure:dump"
Rake.application.remove_task "db:test:prepare"

namespace :db do
  desc "do nothing."
  task :create => :environment do
    puts "This task does nothing."
  end

  : 以下、全てのタスクを空に。
end

rake -Tを実行すると、db系タスクが上書きできていることが確認できます。 これで、レガシーDBを扱うアプリケーションでも、DBを変更する危険もなく、 RSpecもスムーズに実行することができます。

mongodbの設定 - mongodb.conf

mongodbの設定は、mongodb.confで行います。
aptを使用して、

  $ sudo apt-get install mongodb-10gen

でmongodbをインストールすると、
/etc/mongodb.conf
が作成され、また、インストール時に作成される起動スクリプト
/etc/init.d/mongodb
は、このmongodb.confを参照しています。
ここでは、mongodb.confでの設定項目を纏めます。

ここからは、 Configuration File Options の内容を訳しつつ、まとめてみます。

Settings

verbose

Default: false
標準出力やlogpathのログファイルに出力する内部レポートの出力量を調節する。

v

Default: false
verboseの代替形式。

vv

Default: false
出力やログの情報をさらに増やす。

vvv

Default: false
出力やログの情報をさらに増やす。

vvvv

Default: false
出力やログの情報をさらに増やす。

vvvvv

Default: false
出力やログの情報をさらに増やす。

quiet

Default: false
出力を制限したquiteモードで、mongodまたはmongosインスタンスを実行する。
このオプションは、

• drop、dropIndex,diagLogging,validate、cleanのデータベースコマンドの出力
• レプリケーションの活動
• コネクションの受け入れ完了イベント
• コネクション切断イベント

を抑止する。

port

Default: 27017
mongodとmongosインスタンスが待ち受けるTCPポート番号を指定する。 Unix-likeなシステムでは、1000より小さいポートへのアクセスは、root権限が必要。

bind_ip

Default: 全インタフェース
アプリケーションが接続するmongodやmongosインスタンスがバインドするアドレスを設定する。
どのインタフェースを指定しても構わないが、パブリックなアクセスが可能なインタフェースを指定する場合は、 然るべき認証を実装するか、ファイアウォールによる制限でデータベースとの連携を保護すべき。

mongodにバインドするIPアドレスは、カンマ区切りで複数指定することもできる。

maxConns

Default: システムの制限(ulimitやFD)に依存。このオプションを設定しない限りMongoDBは制限しない。
mongod、mongosが受け付ける同時接続数を指定する。この設定値がOSで設定している最大接続数を超える場合は、無効になる。

このオプションは、コネクション切断ではなくタイムアウトするような複数のコレクションを生成するようなクライアントを相手とする場合に特に有効。maxConnsを設定した場合、誤接続がシャードクラスターの各要素に伝播しないよう、コネクションプールのサイズ、または総コネクション数よりも若干大きくなるようにする。

objcheck

Default: false
不正なBSONデータセットがデータベースに追加されないよう全てのクライアントからのリクエストを検証する場合にtrueを設定。mongodはリクエストのオーバーヘッドの観点から、この機能をデフォルト無効としている。

logpath

Default: None(i.e /dev/stdout)
全てのログ情報を記録するファイル名へのパスを指定する。

未指定の場合、mongodはログを標準出力に出力する。logappendがtrueでない場合、プロセスが再起動されるたびに、ログファイルを上書きする。

logappend

syslog

pidfilepath

keyFile

nounixsocket

unixSocketPrefix

fork

auth

cpu

dbpath

diaglog

directoryperdb

journal

journalCommitInterval

ipv6

jsonp

noauth

nohttpinterface

nojournal

noprealloc

noscripting

notablescan

nssize

profile

quota

quotaFiles

rest

repair

repairpath

slowms

smallfiles

syncdelay

sysinfo

upgrade

traceExceptions

Replication Options

replSet

oplogSize

fastsync

replIndexPrefetch

Master/Slave Replication

master

slave

source

only

slavedelay

autoresync

Sharding Cluster Options

configsvr

shardsvr

noMovePranoia

configdb

test

chunkSize

localThreshold