Why I do use them instead of Factory Girl or other solution like that? Well, fixtures can be much more closer to real data than mocks from Factory. How come, You ask? Fixtures are imaginary data exactly like mocks from other sources!

My answer is: that depends how You create fixtures. If You create them by hand, indeed they are disconnected from real world (like all mocks).

What is Your real data/mocks ratio? CC by hsing

But I prefer to extract fixtures from real (production) database. That way I can easily pick entries created by users which are edge cases. The only trouble is with creating fixtures. For some time I’m using modified extract_fixtures rake task. I have added some conditions to extracting process - SQL condition to select only particular records and adjusted syntax to recent rake.

This is useful especially when You are about to take over application code which has no tests. Extracting real data is quick way to start write integration tests (in such case they have are most efficient - time invested and application code coverage).

How to extract fixtures without pain?

Now I want to share with You next improvement to this recipe. Old fixtures can be left unchanged (as long You don’t use ERb to spice them up).

Rake task load old fixtures file and add new records as selected from database by arguments You are providing. More - it keeps old fixtures names so all Your tests using some_table :fixture will work (but don’t You dare to create attribute called fixtures_old_key_value :)) ). As a bonus attributes in Your fixture file will be sorted by attribute name!

OK some examples (written by hand not real YML files I hope there are no mistakes ;)) :

cat test/fixtures/entries.yml
one:
  attr1: value
  attr2: value
  created_at: 2009-09-10 11:22

rake extract_fixtures[entries,1,"created_at<'2009-09-01'"]
cat test/fixtures/entries.yml
one:
  attr1: value
  attr2: value
  created_at: 2009-09-10 11:22
  id: 1
entries_2:
  attr1: value from DB
  attr2: Also value from DB
  created_at: 2009-08-01 22:11
  id: 2

All is clear? In file there was fixture named :one, after rake task we have added new one selected from database, new fixture has name TABLE_NAME_ID, old fixture has unchanged name.

You can add DISCARD=true and old fixtures will be well… discarded :)

Rake task take following arguments:

1. table name
2. limit number of records extracted from database
3. WHERE condition

Rake has one limitation - it treats all commas as arguments separators, so it is not possible to use IN operator. Instead of rake extract_fixtures[entries,10,"id IN (1,2,3)"] write rake extract_fixtures[entries,10,"id=1 OR id=2 OR id=3)"].

You can download rake task file: http://nhw.pl/download/extract_fixtures.rake

This approach is especially useful when something wrong is happening and trigger is unknown. Placing many logging directives can provide data for analysis what could be a reason.

CC by Admond

Default Rails logger has one serious flaw which makes logs on production sites almost useless - messages are not grouped in calls. If You have many processes of Rails running and logging to single file, some requests will be processed in parallel and You have log entries mixed. With default log format there is no way to say which entry is from which process.

Since Rails 2.0 we have ActiveSupport::BufferedLogger, but it solves other problem - number of disk writes and file locks - You can set after how many entries log will be flushed to disk.

AnnotatedLogger

Here comes AnnotatedLogger for a rescue. The idea is to take each message and prefix it with PID of Rails process. As long You don’t run Rails in multithread mode, this is unique ID which will make log entry distinguishable.

class AnnotatedLogger < Logger

  def initialize *args
    super *args

    [:info, :debug, :warn, :error, :fatal].each {|m|
      AnnotatedLogger.class_eval %Q|
      def #{m} arg=nil, &block
        pid = "%.5d:" % $$
        if block_given?
          arg = yield
        end
        super "%s %s" % [pid, arg.gsub(/\n/,"\n%s" % pid)]
      end
      |

    }
  end
end

Now in Rails::Initializer.run do |config| section of config/environment.rb define AnnotatedLogger as default Rails logger:

 config.logger = AnnotatedLogger.new "log/#{RAILS_ENV}.log"

Of course You can add other data to log entries (timestamp?). Here is an example of log entries:

24551:Processing SearchController#processing (for [FILTERED] at 2009-09-15 15:11:24) [GET]
24551:   Session ID: df260892836fc619ec666f894e7d8e88
24551:   Parameters: {[FILTERED]}
24542:   Airport Load (0.216460)   SELECT * FROM [FILTERED]
24542: Completed in 0.24903 (4 reqs/sec) | Rendering: 0.01298 (5%) | DB: 0.22554 (90%) | 200 OK [FILTERED]
24551:   Search Columns (0.004711)   SHOW FIELDS FROM [FILTERED]
24551: Rendering template within layouts/blank
24551: Rendering search/processing

Without PIDs You would expect that Airport Load entry is part of SearchController#processing for session with ID df260892836fc619ec666f894e7d8e88. In reality this is output from processing different request.

What else?

This how I do deal with logs from Rails application. Do You have other ideas how to make logging more usable not only in development environment?

PS
I have just other idea - probably You could use BufferedLogger with disabled auto flushing and patch ActionController to flush manually all entries after request was processed - then all messages would be dumped in single block.

In such case integration tests are way to go, since they provide most bang of Yours bucks - each written test could cover many parts of application.

I had to create test for testing download some data in CSV format (have You said binary? :) ). With default matchers from Webrat You won’t be able to write effective assertions - and that why I’m referring to such file as binary.

So how to do it? Here is a quick tip

Use Webrat’s response_body to get raw body returned by application. Like that:

click_link "Get me some CSV data"
ret = CSV.parse response_body
assert_equal(
  2,
  ret[2][5].to_f,
  "In third row and sixth column You should have 2 and there is #{ret[2][5]}"
)

Validations are one of those features. They are methods which provide easy way to check if model is valid and protect consistency our data in database. Sounds good, but this is bullshit.

What AR really is ;) (c) CC sekimura

Active Record validations are prone to race conditions. Period. It does not make any sense to rely on them if You really have to have consistent data (I’m referring to unique constraint and validates_uniqueness_of). The only way to go is to have constraints put on database level. Or write a lot workaround code in Rails. Error prone as well.

What is race condition? Race condition (or race hazard) is when outcome of some operation depends on timing between other operations.

Let’s take for example creation of two records where one attribute should be unique. How does work validates_uniqueness_of?

First it checks in DB (via SELECT) if there already is record with such value as unique attribute. If there is no such record then it run INSERT command to create new record.

Now imagine two processes are trying to create such record in the same time. Since SELECT and INSERT are separate operation it is quite possible (remember we have two processes trying to do the same thing at once):

1. Model.save in PROCESS 1
2. Model.save in PROCESS 2
3. SELECT FROM PROCESS 1 (result - no record in DB)
4. SELECT FROM PROCESS 2 (result - no record in DB)
5. INSERT FROM PROCESS 1
6. INSERT FROM PROCESS 1

Now guess how many records will be created? :))

What is takeaway from this rant?

ActiveRecord brings to table a lot improvements which each developer loves, but there is no silver bullet. Such race condition can happen (unless You run one Rails process in non-threading mode, but this is not very useful setup :D) even on low traffic application.

If there is really some business need which requires You to have unique data You have to implement some constraints on database level.

Use AR, since it is wonderful tool, but when used properly. Or maybe - know shortcomings of tools You do use.

Avatar /tmp/stream.1170.0 is not recognized by the 'identify' command.

most probably Passenger does not have setup environment and is missing a path. On FreeBSD identify is placed in /usr/local/bin and AFAIR this path is not included by default in PATH. As result Passenger can not find this utility.

You can try to setup environment for Passenger (Apache?) or just add in appropriate environment (in my case it was production.rb):

Paperclip.options[:command_path] = "/usr/local/bin"

If You are new to design patterns and want to know why it is worth to learn this stuff I recommend You watching this session from this year’s GORUCO (GOtham RUby COnference):

>> Model.all.to_json :include =>:association
TypeError: wrong argument type Hash (expected Data)
	from (irb):13:in `to_json'
	from (irb):13

If You want to get in JSON collection with some associations You have to do it manually:

    @companies = Company.all, :include => :address
    render :text => "[ %s ]" % @companies.collect{ |c|
      c.to_json(:include => :address)
    }.join(","),
      :content_type => 'application/json'

ERROR 1114 (HY000) at line 1052: The table 'searches' is full


It was MySQL 5.0, without cluster configuration. Google lead me to answers related to cluster setup, so I got quickly frustrated. It would be good for MySQL to provide some database of most common reasons for errors reported by MySQL.

This time reason was quite trivial - there was not enough space on file system to upload database. Why? I was changing MySQL setup to innodb_file_per_table. Since when doing such change You won’t get back space allocated to old database in file ibdata1 in mysql directory. Since database was not so small there was not enough space to create new database.

Waiting... Waiting... (c) Tony the Misfit

So, when You need to optimize Your test suite, test_benchmark is a way to go. Just install Rails plugin and after rake test You will get 10 slowest tests and timing of all test in test.log. Now You know where to look for a good place to start and not to wait too long…

So let’s start with MySQL and it’s collations. I have wrote about them few months ago. Few days ago, I had finally installed Linux on my notebook (last two months I was running Linux from USB drive). And it seems that there were some minor changes in my environment. I was working on CARtoteka, and when I was running migrations they were stopped in half with error like :

Mysql::Error: Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and
(utf8_general_ci,COERCIBLE) for operation '=':
SELECT count(DISTINCT  companies`.id) AS count_all FROM `companies`
LEFT OUTER JOIN `addresses` ON  addresses.company_id = companies.id
WHERE (city = 'Poznań' and moderated)

What the heck? I have doublechecked I have set connection collation and other - utf_general_ci as I could expect.

After some digging I have found what was a cause.

MySQL support different collations for each table and even for each column in tables (of course only for text types). But this can lead to problems with defaults.

When Rails does create new tables and sets character set as UTF8, it does not select default collation for table. That means MySQL will use connection collation, and if it was not set by You then huge chance that it is again unforgettable Swedish Chef or latin1_swedish_ci in other words.

What to do?

If You can fall back to previous versions You can create tables with new defaults.

To make sure You are not depended on connection settings You just provide collation information when creating table. Just add :options to create_table specifying UTF8 as character set and utf_general_ci as default collation for tables :

create_table :tags,
   :options => "DEFAULT CHARACTER SET=utf8 COLLATE=utf8_general_ci" do |t|
      t.column :name, :string
end

If it is not possible, then You have to use SQL and ALTER TABLE.