Just wasted a full day on this… Suppose you have a User model, with certain Users being children and other Users being parents. With the following code I intended to delete the parent when the child being deleted is the last child of the parent:

class ChildParent < ActiveRecord::Base
  belongs_to :child, :class_name => "User"
  belongs_to :parent, :class_name => "User"
end

class User < ActiveRecord::Base

  has_many :parents, :through => :child_parents_as_child
  has_many :child_parents_as_child, :foreign_key => :child_id, :class_name => "ChildParent", :dependent => :destroy
  has_many :children, :through => :child_parents_as_parent
  has_many :child_parents_as_parent, :foreign_key => :parent_id, :class_name => "ChildParent", :dependent => :destroy

  before_destroy :determine_parents_to_be_destroyed
  after_destroy :destroy_parents

  private
  def determine_parents_to_be_destroyed
    @destroy_parents = []
    self.parents.each do |p|
      @destroy_parents << p unless p.children.size > 1
    end
  end
  def destroy_parents
    @destroy_parents.each do |p|
      p.destroy
    end
  end
end

This didn’t work – @destroy_parents was never populated. Finally I stumbled on the following sentence, clearly documented in the api for ActiveRecord, yet easily missed: *IMPORTANT:* In order for inheritance to work for the callback queues, you must specify the callbacks before specifying the associations. Otherwise, you might trigger the loading of a child before the parent has registered the callbacks and they won‘t be inherited.

Moving the before_destroy and after_destroy declarations above the associations solved the problem.

The Rails portal I’m working on uses subdomains to distinguish between schools (i.e. schoolname.schoudercom.nl). Access to various parts of the portal is controlled through roles using declarative_authorization. All this using one app and one database. So far so good.

But what if a teacher in school1 is a parent in school2? So, when this user requests a page for school1 (under subdomain “school1″) his role should be “teacher” and when he requests a page for school2 his role should be “parent”.

Sounds simple enough to accomplish,  until you realize that information about the subdomain is not accessible from the User model. And so also not available in method role_symbols that is called by declarative_authorization.

This separation of logic between the layers of the MVC pattern is a basic Rails aspect. Various workarounds can be found on the Internet, some of which involve class or instance variables or usage of Thread.current. For a typical discussion on this subject see this topic, more information about threading can be found in Thread safety for your Rails.

Having read the available information I finally settled on adding an instance variable to the User model and setting this from a before_filter in ApplicationController. Let’s start with the model definitions, showing only the relevant lines:

class User < ActiveRecord::Base
    has_many :user_roles
    has_many :roles, :through => :user_roles, :conditions => 'school_id=#{self.current_subdomain ? self.current_subdomain.id : -1}'
    attr_accessor :current_subdomain
    # method for declarative_authorization
    def role_symbols
        roles.map do |role|
          role.name.underscore.to_sym
        end
    end
end

class School < ActiveRecord::Base
    has_many :user_roles
end

class Role < ActiveRecord::Base
  has_many :user_roles
  has_many :users, :through => :user_roles
end

class UserRole < ActiveRecord::Base
    belongs_to :user
    belongs_to :role
    belongs_to :school
end

The instance variable is current_subdomain. Note that the :condition for the has_many assocation for roles uses single quotes. When declarative_authorization calls role_symbols, which iterates the roles array, the condition is dynamically executed and the roles are filtered based on subdomain. The single quotes will cause the query to be “lazy evaluated” as mentioned e.g. in this blog.
When no subdomain is available (e.g. for the public portal starting with ‘www’) the ‘-1′ ensures that no roles are assigned.

In ApplicationController add a before_filter and two methods that will set the current_subdomain variable for current_user (provided by AuthLogic in my case):

before_filter :set_current_subdomain

def current_subdomain
    return @current_subdomain if defined?(@current_subdomain)
    @current_subdomain = request.subdomains.join(".")
    @current_subdomain = nil unless (@current_subdomain && @current_subdomain.casecmp("www") != 0 )
    if @current_subdomain
        @current_subdomain = School.find_by_subdomain(@current_subdomain)
    end
    @current_subdomain
end

def set_current_subdomain
    ca = current_subdomain
    current_user.current_subdomain = ca unless current_user.nil?
end

This may be trivial for experienced Rails developers, but I decided to blog about it anyway – for people like me who just started working with Rails a couple of months ago it may be useful information.

I like to follow the LinkedIn status updates posted by my connections. They inform me about big projects they work on, about seminars they visit, about job changes and other career-related events. Until recently I was happily following these updates from my iPhone.

That is, until LinkedIn decided to offer a connection between its status update and Twitter. One of the usage scenarios – a Tweet with #in is passed to LinkedIn as status update – makes perfect sense. Once in while you tweet something that is worthwhile knowing for your LinkedIn connections as well: just add #in and you’re done. The second usage scenario however – all Tweets are passed to LinkedIn as status update – turns out to be a pain for those following status updates using the iPhone LinkedIn app. In fact, it just turns into a useless copy of Twitter. You have to wade through 20 Tweets of person X before encountering a single LinkedIn status update of another person, and then another 17 Tweets of the same person X before encountering the next. As people say on Twitter: #fail.

Apart from this practical issue, it usually doesn’t make sense to connect Twitter one-on-one with your LinkedIn status. LinkedIn gives me the career overview of my connections. Careers develop relatively slowly, and so status updates are relatively sparse. That is a completely different model than Twitter, where the update frequency is typically much higher.

So, to be able to see status updates of all my connections on the iPhone LinkedIn app (and not just Tweets from person X) I had to delete the connection. Which makes me very curious: how do you handle this?

Dit bericht is verplaatst naar blog.schoudercom.nl en is nu te bereiken via http://blog.schoudercom.nl/2009/12/19/communicatie-in-beeld/.

The Rubyenrails 2009 Conference, held in Amsterdam as previous years, has just finished. What was new, what was hot and what’s in it for the customer?

One of the nice surprises was the increasing number of large(r) companies that are using Ruby on Rails, to name some examples: Tele2, Nedap, Ordina. Adoption of Rails varies from usage in one department to being the strategic platform of choice.

This nicely coincides with  the inspiring talk by Jeremy Kemper who observes that both Ruby and Rails are not hypes anymore but are becoming mainstream.

The real-life example omroep.nl (presentation by Bart Zonneveld and Sjoerd Tieleman) illustrates what Ruby on Rails can do for the web development industry. Within 6 months a small team built both the site itself and a custom CMS that interfaces with an existing image library. If anything, this example shows both the maturity of the platform and the rapid development cycles that can be achieved.

Other presentations addressed performance (Bart ten Brinke) and security (Jonathan Weiss). They gave various practical pointers for building a performing Ruby on Rails site and increasing security to block various types of attacks (XSS, Session Fixation, CSRF, Javascript Hijacking).

Customers usually don’t care much which database is being used, as long as the functionality of the website works as desired. Perhaps this will be different for MongoDB (presentation by Michael Dirolf), a new document-based schema-free database. Letting go of schemas is quite a step for anybody involved in modern relational databases but it opens up a huge potential for flexibility all the way up to the end-user. An administrator wants a new User field for sub-departments? With MongoDB at the back this will be trivial. Sure, such functionality is possible with a relational database as well, but requires quite a bit more work.

Last but not least Jeremy Kemper and Yehuda Katz highlighted the improvements that Rails 3.0 will bring. Many excellent changes are of technical nature and invisible to customers but the speed-up of the framework (up to 10x for collection rendering) and the improved support for encoding and time zones will likely have a noticable effect on the (international) user experience.

What is your take on the advantages Rails 3.0 will bring?

Social networking is a hype. Say what? Arguing this is like swimming upstream in the flow of twittering linkedin facebookies. But what’s the alternative? Going with the flow, creating or applying yet another Top-10 of Do’s or Don’ts for This or That Social Platform?

There was a time when a bunch of creative and visionary people started playing with social networking concepts. In no time they became the center of attention, with lots of followers, and were able to make a living out of it. Such entrepeneurs  still exist but the majority of people involved with social networking nowadays are followers and copycats. That’s fine, but unfortunately many seem to believe social networking is just another bag of tricks.

Take for example the authenticity “trick”. The first CEO’s, Vice Presidents, Support Engineers and R&D Managers that started blogging and twittering in an authentic way introduced a new kind of marketing based on intimacy, conversation and trust. The genuine posts written by those early adopters were read and believed  by many potential customers, positively influencing sales figures.

Soon this was picked up by marketeers, massively adopting the new authentic marketing channel (where’s the authenticity in that?). And so it became a trick. In a recent Dutch radio campaign various employees of PricewaterhouseCoopers address the listener and talk about potentially interesting subjects. The point is, however, that these scripts are so obviously produced by a large marketing department trying to imitate authenticity that it is hilarious at best. What started off as spontaneous personal outings has become an industry of professionals offering their customers to help with their authentic advertising. Sounds like a contradiction in terms to me.

Yes, we at Driving the Vortex do read the lists of Top-10 tips about social networking. Then when visiting a customer we forget about it completely and listen to the unique challenges facing them. And if our unique solution involves social networking of some kind (and they often do), then we might apply some of the techniques often encountered as tips. But only to improve the chance of success for our customer, not as a trick upfront.

Vorige week heb ik de DIS 2009 bezocht, oftewel de Dutch Innovation Seminar die in het teken stond van de impact van social networking op organisaties. Algemene indruk: leuke workshops en een betrokken publiek.

De plenaire sessie begon met een praatje van Menno Lanting. Hij was wel vermakelijk maar verder dan algemeenheden kwam het helaas niet. Enne… LinkedIn uitspreken als “linkut-in” was waarschijnlijk onbedoeld grappig.

Monique van Maare, de volgende spreker, gaf inzicht in de sociale keuken van IBM. Het meest interessante uit haar praatje waren de Innovation Jams: real-life voorbeelden van ideasourcing.

Maar de laatste spreker, Bert Mulder, stal wat mij betreft toch wel de show. Met een, mij zeer aansprekende, nuchtere benadering van wat toch wel een hype genoemd mag worden veegde hij de vloer aan met de jubeltaal die zo vaak gebruikt wordt als het over social networking gaat. Van marktwerking en innovatie in de zorg naar neuzelaars, vertellers en netwerkers. Bert zet haarscherp neer hoe bestaande sociale netwerken zoals LinkedIn en Facebook misschien ondersteunende technologie kunnen zijn, maar dat de werkelijke sociale netwerken veel ongrijpbaarder zijn. Bekijk zijn presentatie hier.

Na deze plenaire sessies kwamen de parallelle workshops aan bod. Erg jammer dat je maar naar 2 workshops kon gaan. Er zaten veel interessante tussen, en zelfs de minder interessante werden boeiend door de discussies die ontstonden.

De discussies die mij het meeste bij zijn gebleven:

• Welke kansen heeft de gemeente Amsterdam laten liggen door binnen30minuten zo traditioneel op te zetten en geen ruimte te geven voor echte interactie?
• Wat is de definitie van crowdsourcing?

Deze laatste discussie heeft me nogal verwonderd want wat maakt het uit hoe je het precies definieert als het maar duidelijk omschreven is wat je doel is en hoe je er komt?

Kortom een geslaagd event van de Baak, met een mooie verscheidenheid aan  sprekers en bezoekers. Was je zelf ook bezoeker en wat vond jij ervan?