schema.rbじゃなくてstructure.sqlでスキーマ情報を管理しよう
先日開催された関西Ruby会議05に参加された方お疲れ様でした。色々な方とお話出来て非常に楽しい1日でした。
さて、「No Sugar 〜私はどのようにしてRails開発に貢献したか〜」という発表をされた @kennyj_jp さんから懇親会で面白い話を聞くことができました。
schema.rbでスキーマ情報を管理するのは限界があるのではないか?
先日私がリリースしたpg_index_where について失礼ながら意見を聞いてみました。ポイントはスキーマ情報をdumpする処理について現在の実装方法で正しいのかという点。
そもそもユニークインデックスにwhereを付けるようなRDB固有の命令については、Rails標準のschema.rbで管理し続けるのは限界があるのではないかというお話でした。
Railsの設定でdump方法を変更できる
次のようにapplication.rbの一部をコメントアウトするとschema.rbではなくstructure.sqlというSQL文が出力されるようになります。
# Use SQL instead of Active Record's schema dumper when creating the database. # This is necessary if your schema can't be completely dumped by the schema dumper, # like if you have constraints or database-specific column types config.active_record.schema_format = :sql
ちょっと動きを確認してみましたがcreate indexにwhereを付けた場合も正しくSQLが作成されてました(あたりまえか)。
このオプションを有効にした場合、元々あったschema.rbは削除してもよさそうです。
使用しているRDB固有のスキーマ定義を設定してて、schema.rbに正しく出力されないとお嘆きの方は設定を変更することをオススメします。
AWSのSESでDKIMを設定する(さくらインターネットのドメイン管理編)
AWSのSES(メール配信サービス)を使うのは簡単なのですが、そのままの設定だとメール差出人の欄に
amazonses.com 経由
と表示されてしまいます。
これを防止するためにDKIMという仕組みがあるのですが、さくらインターネットのドメイン管理画面でCNAMEを設定する時にハマったのでメモ。
SESの設定画面でDKIMの設定画面を開くと「CNAMEをこう変えてくださいよ」という設定が表示されると思います。
Route53を使っていればボタンひとつで設定完了なのですが、私はさくらインターネットでドメイン管理をしているため次のように設定しました。
ポイントは2つ。
- CNAMEを登録する際にDNSチェックは「しない」を選択する。
- CNAMEのValueの最後に.(ドット)を付ける
しばらくするとSESで認証されると思います。
Command + カーソルキーでウィンドウを動かしたくない
最近Parallels Desktop でWindows8を使っています。デフォルトのキー配置も概ね満足なのですが、Visual Studio等のエディタでCommand + カーソルキーを押すとカレントウィンドウが画面の端にへばりついてしまいます。私は次のように設定を変更してます。
- メニューのParallels Desktop -> 環境設定 -> ショートカット
仮想マシンの「構成」にショートカットキーの設定があるわけではないので注意です。
PgIndexWhereをRubyGems.orgでリリースしました
PostgreSQLでユニークインデックスを指定するときwhereを指定したい話の続きの続きです。
こんな感じでRailsのMigrationファイルで:whereが指定できます。
class AddIndex < ActiveRecord::Migration def up add_index "customers", ["code"], :name => "customers_idx01", :unique => true, :where => 'deleted_at is null' end def down remove_index "customers", :name => "customers_idx01" end end
これをやると何が嬉しいかは以前の記事「acts_as_paranoid + ユニークインデックス」を御覧ください。
RailsのModel側だけでバリデーションを設定するより、DB側でもユニークインデックスを設定しておいたほうが安全です。PostgreSQL + acts_as_paranoidの人は是非導入してみて下さい。
3日目
Rails Gems realize RESTful modeling patterns(Toru Kawamura氏)
一般的によく使われているgemに着目して良いリソースデザインを取り入れるというお話。
Gemを作ったりAPIをデザインするときに参考になるお話でした。
以下はメモ。
Railsのresourcesは設計しやすい、理解しやすい 。
/users/1
いろいろな書き方がある中でこれをRailsは選択している。
これを書いてれば同名のcontroler,model,viewが存在する(可能性が高い)ので共同の開発者に理解されやすい。
「制約が自由をもたらす」(DHH)
発表では以下のGemが作り出すresourcesを例にあげていました。
- devise(認証系、モデル無し)
- Authlogic(認証系、モデル有り)
- Ransack(検索)
- wicked(ウィザード)
Gemを作る人はResourcesのパターンも考えること。
Casual Log Collection and Querying with fluent-plugin-riak(Kota Uenishi氏)
fluentdのデータをRiakに入れてSQLで検索するというお話。
fluentd + mongodbという運用パターンが多い中で別の選択肢があるのはいい感じ。
以下メモ。
- RiakはBashoが作った
- サービスやりたい人たちが安眠できるDB
- DocumentDBっぽいかんじ
- なんでもかんでもriakにいれてOK.
- fluent-plugin-riakがある
- Mohairを使えばSQLライクに検索することができる
Complex Event Processing on Ruby and Fluentd(tagomoris氏)
アプリごとに異なるメトリクスをどうやってログから判断するかというお話。
norikraのデモはインストールから行われており、非常にイージーにスタートできそうな感じ。
以下はメモ。
- ストリーム構成とバッチ処理のハイブリッド処理
- norikraを使えば過去n分間のデータの集計がリアルタイムでできる
- 今のところデータの永続化はされない
Fight with Diversity(田中哲氏)
dbmというデータベースのライブラリをリンクするための設定ファイルextconf.rbのお話。
Matzの「多様性は善」という言葉に立ち向かうという内容。
「まぁ、あんまり使ってる人はいないんですけどね」とご自身も言われていたとおり、私は使われていないのならRubyから切り離せばいいのにと思ってしまいました。でも結局メンテし続けているということはご自身でdbmを使われたいのかなと。
最近のMatzの言葉に「最も大切なのはモチベーション」というのがあります。これだけの困難を乗り越えてまでdbmを使われたいというモチベーションがもたらすパワーは素晴らしいと思いました。
2日目
High Performance Rails(Issei Naruta氏)
クックパッドでRailsアプリケーションの高速化を担当されている@mirakui氏のお話。
以下はメモです。
- レスポンスタイム200msが速い、遅いの指標
- ログのレスポンスタイムを見るときにX-Runtimeを見るべき。この値はアプリケーションサーバーの最も外側に位置するRackが計測しているので実測値に近い
- チューニングの大前提は「Rubyに処理をさせない」。特にActiveRecordオブジェクトの生成が重い
- ルーティングはcontroller名、アクション名を指定せず名前付きルートを使ったほうが高速
- スロークエリはArproxyを使ってfluentdに記録している
Continuous gem dependency updating with Jenkins and Pull Request(NAGAE KENSUKE氏)
刺身ブーメランさんの依存したGemのアップデートをJenkinsで行おうというお話。
技術的な点だけでなく
- 人力で依存性を解決するという「やる気」に依存する作業は長続きしない
- メール通知だと「義務感に欠ける」
など心理的な面を強調していたのが印象的でした。
Jenkins氏のアイコンがついたユーザーからプルリクを送るというのはとてもいいアイデアだと思いました。
Concerning `Applications'(諸橋恭介氏)
moroさんのAcitveSupport::Concernのお話。
以下はメモ
- AcitveSupport::ConcernとはRubyのmoduleを拡張してるもの
- Rails4ではConcernの置き場所も決まっている
- 共通処理をまとめる。名前をつけてその性質を切り出す
- ただ分けるだけじゃなくて、リファクタリングすること
- refinementsを使えばベースクラスを汚染すること無く 機能を拡張できる
このお話を聞いた後、テンションが高くなった私はホテルでプロジェクトのコードをリファクタリングしてModelの共通処理をConcernに切り出しました。今までは独自の方法で動的に作成されてたメソッド群が本来のレールに乗った感じ。月曜日にテストしてマージするのが楽しみだ!