Bitbutter

Wars, invasions, civil strife and genocide are not caused by religion. Nor are they caused by atheism, rationality or science. Every war in history has been fought for the same reasons - power, influence, control of wealth, control of resources (including human resources). Some people attempt to exercise power by wielding religious belief. Some attempt to exercise power by wielding political ideology. Some attempt to exercise power by wielding money. Some by claiming legal or moral authority. But it's all about power and influence in the end.

.. says AllyF in one of the hundreds of posts in a recent Guardian Unlimited thread. This is a sentiment I've seen expressed many times lately, and i can understand its appeal. There's something elegant about the idea that all the bad behaviour in the world can and should be traced back to, and ultimately blamed on, human desire for power. Maybe it's true, but even if we grant that, it doesn't mean we can't or shouldn't point out much more nearby causes as well.

Continue reading…

I was reading a transcript from a debate in the house of lords. Something that Baroness Andrews said prompted me to reply. I'm posting my reply here too.

My noble friend Lady Massey and the noble Lord, Lord Roberts of Llandudno, alleged that religion is sometimes seen to cause and be at the root of conflict. I say right away that it is not belief that impacts so negatively on us or society more broadly, it is the actions and manifestations by small numbers of people who distort religious texts or hold fanatical views. It is essential that we make, understand and express those differences.

I strongly disagree. There are a number of serious problems with the idea that it is people's distortion of religious texts that leads them to act in anti social ways.

Firstly how can you determine that any of a set of rival interpretations of religious texts is a 'distortion'?

Secondly, taken at face value, the bible contains plenty of justification for 'fanatical' behaviour. To claim the bible as a guide for your life and yet to hold moderate views compatible with modern society is actually more of a distortion than to be interpret the book literally like the fundamentalists do.

Baroness Andrews' charge that certain groups distort religious texts is a non starter. We are outraged by fanatics not because they distort religious texts–religious texts are for the most part appalling guides for how to lead a moral life in the first place–but because their behaviour strongly disagrees with the moral zeitgeist.

Why the reluctance to acknowledge the (to me) plain fact that faith–certainty without evidence–is to blame for religious fanaticism?

Faith can be benign, usually to the extent that it is tempered with skepticism. Faith can also do terrible damage. The more certainty with which an article of faith is held, and the more explicit that article is, the more dangerous that faith makes a person.

Add your thoughts here.

The second Globalize post in as many days. Since I started I may as well through this one out there too, another one for the great Globalized minds of the interweb. I'm regularly bitten by this problem and didn't uncover a satisfactory workaround yet.

Globalize inelegantly flops when you ask it to load the collection attribute of a model instance if the instances in the collection have translated fields.

To illustrate the difficulty I'm having here's a simple Label <- Release -> Artist type data model that you might find on a multilingual music directory site.

class Label < ActiveRecord::Base
has_many :releases
has_many :artists, :through=>:releases
end

class Release < ActiveRecord::Base
belongs_to :label
belongs_to :artist
end

class Artist < ActiveRecord::Base
has_many :releases
has_many :labels, :through=>:releases
translates :bio
# let Globalize handle translation of the artists bio's
end

>> Label.create(:name=>"Huge Ape Recordings")
>> artist=Artist.create(:name=>"Zombie Gunship",
:bio=>"Blah blah, the rest is history.")
>> Release.create(:label_id=>1,:artist_id=>1)
>> label=Label.find(1)
=> #"Huge Ape Recordings", "id"=>"1"}>
>> label.artists
StandardError: :select option not allowed on translatable models (artists.*) from
./script/../config/../config/../vendor/plugins/globalize_extension/lib/globalize/db_translate_ex.rb:31:in `find_every'

I have a feeling (hope) that this kind of thing ought to be possible with Globalize. In either case Google is eerily empty of relevant search results. Can anyone throw any light on this, how are you getting round it?

Localize Models to the rescue

Update: I've just demoed a delightful plugin by Saimon Moore called Localize Models. It's a system that can be used to replace Globalize's model translations. Rather than storing model translations in the main translations table, it uses additional columns with language code suffixes in the model tables. The big relief with this alternative is that there are no restrictions on :select options. Check his page for instructions (NB. The plugin threw errors in rails 1.1.6 but seems to work fine in edge rails).

>> l=Label.find(1)
>> a=l.artists.first
=> # Artist:0x33d4bc4 @attributes={"name"=>"Zombie Gunship",
"bio_nl"=>nil, "id"=>"1", "bio"=>"English bio here."}>
>> a.bio
=> "English bio here."
>> Locale.set(LOCALES['nl'])
>> a.bio="Dutch bio here"
>> a.save
=> true
>> Locale.set(LOCALES['en'])
>> a.bio
=> "English bio here."
>> Locale.set(LOCALES['nl'])
>> a.bio
=> "Dutch bio here"

Lovely!

Update: No, it didn't! Globalize globalize_languages and globalize_countries fixtures were missing from the functional tests, causing the errors I was seeing. Grab the appropriate fixtures from vendor/plugins/globalize/test/fixtures and copy them to test/fixtures. Make sure you include them in tests that need globalize by calling the fixtures something like so: "fixtures :users, :globalize_languages, :globalize_countries". Thanks again to Saimon for setting things straight. My original post follows.

Lately I've been getting enthusiastic about tests in general, and test driven development.

Already being a bit hooked on the satisfying solidity of tested code, I'm keen to introduce tests into the rails projects I'm busy with.

The (otherwise excellent) Globalize plugin is dunking a filthy fly in the testing ointment. My functional tests are failing and it looks as though it's because a class that Globalize defines, Locale, behaves differently in the test environment than it does in development mode.

I think I isolated the problem to the following: Locale.base_language, and Locale.langauge always report nil in the test environment, but behave as expected (returning a string containing the base language and active language respectively) in development mode.

Here's development mode:

computer:~/sites/globalize_demo m$ script/console
Loading development environment.
>> Locale
=> Globalize::Locale
>> Locale.set_base_language('en-EN')
=> #
>> Locale.base_language
=> English

And here's test mode:

computer:~/sites/globalize_demo m$ script/console test
Loading test environment.
>> Locale
=> Globalize::Locale
>> Locale.set_base_language('en-EN')
=> #
>> Locale.base_language
=> nil

I'm posting about this in the hope that a kindly reader can either point out what I'm doing goofily, or verify that this is a problem with Globalize.

I have a brand new mac running OSX 10.4.7 so i thought that it should be relatively straightforward to get a rails environment set up if i found the right guide. It took me a day to get this working. Here I’m documenting what i think i should have done to have it work first time, for my reference for next time. Perhaps its useful for other people too. Continue reading…

I’m starting to notice that getting to work on a rails project after you’ve booted up your mac is a tedious business due to all the applications and processes you need to set off. Here some AppleScripted automation is welcome. There are some very useful guides on this subject already; i’m adding my own variation to the pile. Continue reading…