ADS specializes in using Ruby on Rails to build advanced, scalable, database-backed web sites for organizations of all sizes. Find out more at our website.

I was working on a fix for a mail_receiver model that implemented ActionMailer’s receive method. I was seeing a problem while it was trying to parse out sub-parts from a mime multitype message, where it wasn’t capturing the content correctly for multipart/alternative. The existing code was pulling the message text as so:

def get_multipart_body(mail)  
  types =  mail.parts.collect(&:content_type)
  if types.include?("multipart/alternative")
    body = mail.parts.find { 
      |m| m.content_type == "multipart/alternative" 
    }.body
  end
end

What fixed it was this:

def get_multipart_body(mail)
  types = mail.parts.collect(&:content_type)
  if types.include?("multipart/alternative")
    # we need to dig down a level to get the sub-parts
    m_part =  mail.parts.find { 
      |m| m.content_type == "multipart/alternative" 
    }
    sub_types = m_part.parts.collect(&:content_type)
    if sub_types.include?("text/plain")
      body = get_text_plain(m_part)
    else
      body = get_text_html(m_part)
    end
  end
end

So with ‘mail’ being a TMail object (which ActionMailer uses to parse email into its constituent parts), the sub-parts can be retrieved by calling mail.parts.find to get the sub-parts of the message.

Now technically, there can be an unlimited number of nestings within parts (check out RFC 2046 for the nitty-gritty details). The fix above only goes one level down. I considered doing a little recursive method for handling it, but ran out of time. Still, I’ll keep that idea as an exercise for future interest.

What happens when you throw a couple newly-forged step siblings together and tell them to get along? You might see a little of the interaction like what we’ve been seeing between Java users and Ruby users lately — a little tete-a-tete back and forth about who is better because they’re bigger and older and well established, and who’s better because they’re small and fast. But at the end of the day, they simmer down and realize that they get a lot more done if they just work together.

All programming languages are really just tools with which you write software. The mark of any good tool is the level of transparency it attains while being used. The less time you spend thinking about how your tool works and the more time spent on creating something with it, the better it is. This is one reason why Ruby is so attractive — because it’s considered a natural language programming language, and it is (relatively) easy to understand, even for the non-programmer.

That being said, there is a balance between ease of use and power of the tool when used at a more proficient level. Here is where Java has excelled. It has been in use for quite some time, and in that time has been improved, amended, and built upon to create large and complex systems.

Now, don’t think I’m saying Ruby or Rails are lightweights, or won’t be able to achieve the same power. Rails is *new* and has brought more attention to Ruby. With any new or emerging technology, it takes time for the collective user base to start to realize just what can be done with that tool. What comes first are the questions of how it can better solve existing problems. Next, as challenges are solved, a new perspective is gained. We can then use that new perspective to cast light on both existing and emerging challenges. It is then that we start to see the real power of that tool/technology/language, and what it can accomplish.

So what I’m getting to is this: there is no single, all-powerful tool which will solve all problems, all the time. New issues are continually emerging which require new perspectives. What we need to do is break out of our sandbox, and join our neighbors to build better castles. Perhaps JRuby is the bridge between Ruby and Java that will do just that. Why choose when we can work together? This, my friends, is what programming is about.

Happy coding!

- Naomi Butterfield