Not logged in (Log in or Sign up)

unwwwritten

A method to my madness

Sorry for not posting more frequently of late, but between the basement flood and the house renovations, and numerous other excuses, I just have not had the time.

Anyway, here's a few quick things...

  1. Spammers suck. Why do I need to deal with spam in my inbox?

  2. Comment spammers suck even more. Why should my blog have to deal with spammers? I shouldn't have to add filters and moderation to my comments in order to keep blog comments to worthwhile posts only.

  3. github rocks! (still) I'm loving the collaborative aspect of it and the ease with which I can post things I'm working on. I especially love how easy it is to submit suggested changes to someone else's projects - I wish it were a bit easier to merge changes when someone submits them to my projects though, but that's probably my newb-ness with git in general.

  4. vi (vim) is still an awesome editor. However, something still is not quite right when it comes to projects, multiple files, find in project, etc. - I find myself with both vi and TextMate open to manage multiple contexts, for example a find in project in one and editing the unit tests in another.

  5. I suspect a problem if you stumble upon the following pattern in your code...

   1  model.method if model.is_a?(ModelClass)

What's wrong with that? (I can hear some of you asking)

Well... maybe nothing, but it seems that there are at least two better ways to deal with it (in my opinion).

respond_to?

It seems more "rubyish" to me to use respond_to? for this. The point is, if the method exists, call it. Now this may not always be the case, but in the instances I'm looking at it makes more sense and seems way more maintainable.

So, instead of...

   1  # this seems a bit awkward (to me)
   2  user.check_group_membership if user.is_a?(LdapUser)

You would...

   1  # this seems more rubyish (to me)
   2  user.check_group_membership if user.respond_to?(:check_group_membership)

override method

In other cases, it may make more sense, and will probably be more readable if you just let the class worry about whether or not it should do something.

So, for example, if you do this...

   1  class User < ActiveRecord::Base
   2    def check_group_membership
   3      # nothing to do here
   4    end
   5  end
   6  
   7  class LdapUser < User
   8    def check_group_membership
   9      # read groups from ldap server and do something with them
  10      ...
  11    end
  12  end

Then you don't have to check the type or interface at all when you want to invoke it...

   1  # nothing wrong with this, is there?
   2  user.check_group_membership
blog comments powered by Disqus