Simple thoughts

I just need to rant that (again) I run into a problem with unexpected side-effects of the usually neat feature of implicit return values in Ruby. This (although not really obvious) feature always returns the value of the last executed statement in a method as a return value. But this isn't always as obvious as it sounds. This can cause strange side-effects.

As an example take the Rails callbacks for ActiveRecord. These callbacks like :before_create are typically used to handle data validation. Thus if they return 'false', the process to save the record is canceled.

But now instead of validation you want to ensure that certain other attributes are automatically set depending on other attributes; maybe even boolean attributes like in this block:

class Message < ActiveRecord::Base 
	belongs_to :probe 
	attr_accessible :probe_id, :value1, :value2, :probe_enabled

	before_create :set_probe_enabled 
	private def set_probe_enabled 
		self.probe_enabled = self.probe.enabled? true 
		# if only this would have been obvious... 
	end 
end

Here we simply want to set the boolean attribute enabled? depending on the value of the enabled attribute of the associated probe. Obviously the probe.enabled? can either return true or false. Unfortunately in case of false the whole statement ' self.probe_enabled = self.probe.enabled?' returns false. And if this is the last statement being executed, the whole method will return false. And a false in such a callback will cancel the creation of the object...

Take-away lesson: Pay attention to implicit return values especially in Rails ActiveRecord callback methods when dealing with boolean values.

I don't know if my slightly outdated Rails 2.2.2 is the problem. But unlike in the fixtures for normal unit tests, I can't use ERb for my ActionMailers templates.

Add this method to your ActionMailer::TestCase to let ERb pre-process your fixtures:

def read_fixture(action) 
	a = super 
	template = ERB.new(a.join) 
	template.result(binding) 
end

Developing web applications can be fun and hard almost at the same time.

But when it comes down to testing, it can be a ....

Sure every developer has his favorite environment and develops against it. But his special browser is just a part of the big picture and there are way to many different browsers and versions out there in the wild. Of course you know them all:

• Internet Explorer [ 6 | 7 | 8 with Compatibility View | 8 ]
• FireFox [2 | 3 ]
• Safari [ 3 | 4 ]
• Chrome
• Opera

And those are only the traditional desktop browsers for MacOS, Win and Linux. (Personally I assume, that one browser behaves almost the same on different OS when it comes to the programming model. But this is not necessarily true for layout issues). Note that this list totally ignores the growing mobile market. I don't know yet how to deal with them...

It will get even ridiculous if you could only install one version of a browser at the same time. Yes, IE - most credits go to you! There are some hacks out there to install the Internet Explorer in different versions on one system.

In the past I've simply virtualized my system and got one image for every single browser. Worked, but it always felt like "shooting cannons to sparrows". There is quite some overhead involved to install and actually fire up the VM image.

Why not simply virtualize the browser? That's exactly what Xenocode is doing. Download, run and test. Nice. The seamlessly network integration even make those things like local proxy servers work.

--

January 21st, 2010 at 17:31 | #1Reply | Quote

maybe https://browserlab.adobe.com/index.html is worth a try too…