Friday, November 21, 2008
run all rails tests in rcov and aggregate results
rcov is great, but it was bugging me that it would give me a separate list of results for my unit and functional tests. They overlap, so I'd like to see the overall test coverage all at once. Turns out it's easy to do, as explained here. The only thing they don't explain there is where to put the code--it should go in your project at: lib/tasks/rcov.rake
Labels:
rcov,
ruby on rails,
testing
Thursday, November 20, 2008
problems migrating from sqlite to mysql
So in moving Project Unblowuppable to a production server, I had to switch from sqlite to mysql. Rails makes the config changes trivial, but I ran into a few glitches.
The first was with my :decimal db columns. Apparently sqlite doesn't require the use of scale and precision, so you can have something like this:
Well, it turns out mysql requires scale and precision, so the above line gives you a 'decimal' with zero decimal places, aka an integer. This caused me some pain and day of debugging, but the fix was easy once I figured out the issue:
The second issue was much stranger, and I hate to admit I still don't fully understand what happened. (Once I fixed it, I felt my time was better spent continuing development rather than doing forensics to satisfy my curiosity.) This is a highly condensed version of what I had:
This code worked fine using sqlite. When I switched to mysql, suddenly it started putting an array into the hash key as a single hash entry, rather than separate hash entries with integer keys. So when I looped through the hash, it was calling find_by_id with an array, which was doing a SQL IN query and returning multiple results.
Really, this code didn't need a hash at all--what I wanted was a set, but I didn't know at the time Ruby had a set available. (Using a set was actually the way I fixed the problem.) I'm still not sure what happened here, and I really don't know why switching from sqlite to mysql would cause it.
The first was with my :decimal db columns. Apparently sqlite doesn't require the use of scale and precision, so you can have something like this:
t.decimal :column_name, :null => falseWell, it turns out mysql requires scale and precision, so the above line gives you a 'decimal' with zero decimal places, aka an integer. This caused me some pain and day of debugging, but the fix was easy once I figured out the issue:
t.decimal :column_name, :null => false, :precision => 8, :scale => 2The second issue was much stranger, and I hate to admit I still don't fully understand what happened. (Once I fixed it, I felt my time was better spent continuing development rather than doing forensics to satisfy my curiosity.) This is a highly condensed version of what I had:
possible_hits = Hash.new
for x in X.find_all_by_n_id(n_id)
#hash should have one entry per q_id
possible_hits[x.q_id] = true
end
possible_hits.each do |q_id|
q = Q.find_by_id(q_id)
end
This code worked fine using sqlite. When I switched to mysql, suddenly it started putting an array into the hash key as a single hash entry, rather than separate hash entries with integer keys. So when I looped through the hash, it was calling find_by_id with an array, which was doing a SQL IN query and returning multiple results.
Really, this code didn't need a hash at all--what I wanted was a set, but I didn't know at the time Ruby had a set available. (Using a set was actually the way I fixed the problem.) I'm still not sure what happened here, and I really don't know why switching from sqlite to mysql would cause it.
Labels:
bugs,
mysql,
project unblowuppable,
ruby on rails,
sqlite
Sunday, November 16, 2008
installing mysql gem
I've been using sqlite for a while, but was trying for the first time today to deploy Project Unblowuppable to a 3rd party server. Finally figured out all the Capistrano issues (made more complicated by the fact the domain hasn't finished transferring to the new hosting provider), and also had to make the switch to mysql for production. Switching to mysql was actually a piece of cake--mad props to Rails for that! Capistrano, well...the jury's still out. Very slick once you get it working, but therein lies the rub.
Unfortunately, once I got it deployed the app started to have all kinds of weird issues. Formatting problems (stuff that should be handled by CSS, so I don't know what the issue is) and some other issues that could be caching problems. I haven't run in development mode before, so I decided to try that on my MacBook Pro dev machine. Oops--first problem was that I'd set my database.yml up to use mysql in production, but didn't actually have mysql on this machine. So I installed mysql, and tried to install the mysql gem (sudo gem install mysql), but kept getting this error:
As always, after repeated prayers to The Oracle, I found something that worked. The fix is just to use this command to install:
Unfortunately, once I got it deployed the app started to have all kinds of weird issues. Formatting problems (stuff that should be handled by CSS, so I don't know what the issue is) and some other issues that could be caching problems. I haven't run in development mode before, so I decided to try that on my MacBook Pro dev machine. Oops--first problem was that I'd set my database.yml up to use mysql in production, but didn't actually have mysql on this machine. So I installed mysql, and tried to install the mysql gem (sudo gem install mysql), but kept getting this error:
ERROR: Error installing mysql:
ERROR: Failed to build gem native extension.
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby extconf.rb install mysql -- --with-mysql-include=/usr/local/mysql/include/ with-mysql-lib=/usr/local/mysql/lib/
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lm... yes
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lz... yes
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lsocket... no
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lnsl... no
checking for mysql_query() in -lmysqlclient... no
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers. Check the mkmf.log file for more
details. You may need configuration options.
As always, after repeated prayers to The Oracle, I found something that worked. The fix is just to use this command to install:
sudo gem install mysql -- --with-mysql-config=/usr/local/mysql/bin/mysql_config
Labels:
mysql,
project unblowuppable,
ruby gems,
ruby on rails
Monday, November 10, 2008
Fix for rcov crash
After migrating to the new MacBook Pro, rcov started giving me grief. My unit tests would run under rcov fine, but my functionals would blow up with this lovely error:
Oh. Of course, right? Well, as always I consulted The Oracle, and she didn't fail me. There were a number of pages of people having this same problem, but this one had a solution that worked for me. Many thanks to Sylvestre Mergulhão!
(eval):1: [BUG] rb_gc_mark(): unknown data type 0x24(0x1ba523c) non objectOh. Of course, right? Well, as always I consulted The Oracle, and she didn't fail me. There were a number of pages of people having this same problem, but this one had a solution that worked for me. Many thanks to Sylvestre Mergulhão!
Labels:
rcov,
ruby on rails
Friday, November 7, 2008
Numeric problems with Ruby
This is another thing that's bitten me a few times recently, where comparing numbers in Ruby doesn't quite work because of precision oddities. As usual, I found a blog post with some information and workarounds.
Labels:
ruby,
ruby on rails
Thursday, November 6, 2008
Using logger in Rails tests
By default you can't use the logger in Rails tests, which can make debugging tricky and cause errors when the code you're testing has logger calls in it. I figured there was a fix for this, and here it is!
Basically you just add this to your test_helper.rb:
And then use the logger as usual. Props to Robby on Rails!
Basically you just add this to your test_helper.rb:
def logger
RAILS_DEFAULT_LOGGER
end
And then use the logger as usual. Props to Robby on Rails!
Labels:
ruby on rails,
testing
Monday, November 3, 2008
Another potential new multiple sclerosis drug
An article from Slate about research on another potential MS drug.
Labels:
multiple sclerosis
Subscribe to:
Posts (Atom)
