Fat Modelの倒し方 / how to deal with fat model銀座Rails#21 ( https://ginza-rails.connpass.com/event/173610/ ) の発表資料になります。 Ruby on Rails アプリケーションにおける Fat Model の解決方法を下記の３つに分けて紹介しています。 1. Rails Way …
railsアプリをherokuで動かす
herokuデプロイに必要な作業をダイジェストでお送りします。 ■Gemfilesの追加記述 gem 'sqlite3', group: [:development, :test] gem 'rails_12factor', group: [:production] gem 'pg', group: [:production] ■config/database.yml production: adapter: postgresql encoding: utf8 database: pool: 5 username: password: ■herokuへデプロイ heroku create myapp git push heroku master heroku addons:add heroku-postgresql heroku run rake db:migrate heroku ope
Rails: SOAアプリの結合テスト - ワザノバ | wazanova
http://www.bignerdranch.com/blog/testing-rails-service-oriented-architecture/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 Big Nerd RanchのブログでTravis Douceが、remote_factory_girl と remote_database_cleaner を利用したSOAアプリの結合テストについて紹介しています。 まず、DBをもたないクライアントアプリが、user table を持つホームアプリにHTTPリクエストを投げ、JASONリクエストが返ってくるパターンを例としてあげてます。（概念図） よく見かけるのが、 1) クライアントアプリからホームアプリへのHTTPリクエストをスタブする。 2)
プライマリキーを使った1:1関連でカラム数の多いテーブルを分割する - Hidden in Plain Sight
おそらく多くのソーシャル系アプリにあてはまるRailsのプチ・デザインパターン的な話。 ぼくが今やっているEast Meet Eastには、ユーザごとに数多くのプロフィール属性があります。名前、性別、生年月日、郵便番号、職業などなど、カラム数にしてざっと25個。これを、全部ひとつのusersテーブルに詰め込むのは、コードの見通しという観点からも性能の観点からも、あまりよろしくありません。 なぜならば、ユーザ関連の情報を扱う局面としては主に メールアドレスとパスワードなどを使ってログインする（アカウント情報） プロフィール情報で条件を指定してユーザを検索・推薦する（プロフィール情報） という２つの独立性の高いユースケースにわかれるため、ログイン処理をやってるときにはプロフィール情報はいらないし、プロフィールを検索してるときにはメールアドレスやパスワードをロードするのは無駄です。また、開発やデ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DBスキーマもバージョン管理したい！
