Every week (at least it feels that way) some new drama rears its ugly head in the ruby community. Petty arguments via twitter, one ranting blog post after another, people mocking ideas they consider less than ideal, and even some personal attacks thrown in the mix. There’s so much drama in fact that there is now a site out there that lists it all for the rest of the world to see.

Seriously? Are we all still in junior high?

Just think for a minute about all of the time and energy we are wasting here. Instead of igniting these flame wars, from which nothing productive is ever achieved, we could be growing as a community. We could be bringing up the next generation of software developers. We could be positively encouraging others to build better software. We could be sharing our experiences with others. We could be leading by example.

For a community of people complaining that they’re not treated like professionals, we sure don’t act very professional. If this is the way we behave, can we honestly expect people to treat us with the respect that they treat doctors, accountants, teachers, and members of other professions?

If you want to be treated like a professional, it’s best to start acting like one first.

Take the high road for once. The view is much nicer.

def some_method(required_1, required_2, options={})
  # Do something awesome!
end

some_method("foo", "bar")
some_method("foo", "bar", :option_1 => false, :option_2 => true)
some_method("foo",
            "bar",
            :option_1 => false,
            :option_2 => true,
            :option_3 => "something",
            :option_4 => "something else")

This may not look like much. However, this feature alone is capable of producing some very readable code, and is used extensively in APIs throughout the Ruby ecosystem. Consider for a moment what these APIs would look like if Ruby did not have this capability, which isn’t hard to imagine for those of us with a background in a language like Java. You would either be forced to require that each parameter be specified:

# What is this code doing?  What do the nil values,
# or even the true and false values map to?
some_method("foo", "bar", false, nil, true, nil)

or accept a hash or a request object that contains all of the necessary parameters:

# This is much more readable, but requires that the
# options hash be created on its own line.
options = {:option_1 => true, :option_2 => false}
some_method("foo", "bar", options)

Providing optional parameters via hash key/value paris at the end of a method call produces code that is incredibly readable. You have the names of the attributes right next to their corresponding values! There is no ambiguity whatsoever as to which values match up with which parameters.

It is also very flexible. The order of the attributes in the hash does not matter, like it does for required attributes. And, it is very easy to add new options, or delete old ones.

This approach also makes it easy to specify default values for options that were not specified when calling the method:

def some_method(required_1, required_2, options={})
  defaults = {
    :option_1 => "option 1 default",
    :option_2 => "option 2 default",
    :option_3 => "option 3 default",
    :option_4 => "option 4 default"
  }
  options = defaults.merge(options)

  # Do something awesome!
end

There are however a few minor drawbacks to this approach. The first is documentation. Methods that take a hash of options as a parameter do not convey any information about the valid options in the method definition alone. And, it is possible that the method in question simply forwards the options to another method, sending you on a wild goose chase to determine the set of valid options the code supports.

# Looking for a list of valid option keys...no help here.
def some_method(required_1, required_2, options={})
  do_something_awesome_with_the_options(options)
end

This is why it is so important do document your public API if you are using this approach. Take a look at the ActiveRecord::Associations::ClassMethods documentation. This page documents, in a very clear and easy to read mannor, all of the supported options for each method.

It is also worth pointing out that while this approach is great for optional parameters, it is ill suited for required parameters. Required parameters should be specified outside of the options hash, making it clear that values for the required parameters must be provided. While it’s true that stuffing all of your parameters inside a hash means you’ll never have to look at another wrong number of arguments error again, it will make your code difficult to understand, and easy to misuse.

However, polyglot persistence comes with its own set of drawbacks. One of those drawbacks is the loss of foreign keys, which are very important in maintaining data integrity. Another drawback is that Object/Relational Mapping (ORM) libraries typically focus on a specific database, or type of database. So, writing code that manages relationships between objects backed by different databases hasn’t been nearly as easy as writing code to manage relationships between objects in the same database.

Tenacity’s goal is to address some of these issues. Tenacity is a ruby gem that provides an ORM independent way of managing relationships between models backed by different databases.

Tenacity works by extending popular Ruby ORM libraries to respond to a set of methods that the tenacity core uses to build and manage relationships between objects. By extending the ORM libraries to implement this interface, tenacity is able work with the objects in a generic way, without having to know what database is backing the given objects. This approach also allows you to continue using your favorite ORM libraries. To use tenacity, you simply need to include Tenacity inside your model.

Tenacity is heavily based on ActiveRecord’s associations, and aims to behave in much the same way, supporting many of the same options.

This initial release of tenacity supports belongs_to, has_one, and has_many associations, and the ActiveRecord, CouchRest, and MongoMapper ORMs. However, there is still plenty of work to be done. Feedback, bug reports, and code contributions are always welcome.

Tenacity is free and open source, and can be found on GitHub at https://github.com/jwood/tenacity.

Example

Download

gem install tenacity

Service level testing, or functional testing, has been a hot topic at work recently. It’s no secret that we have a very large SOA at Orbitz, powered by Jini. Services, calling services, calling services…you get the picture. Historically, we have not been the best at automating the testing of these services. That is beginning to change. About two years ago, the team I work on developed a test tool that allows us to interact with our services at a very high level, keeping us out of the nitty-gritty details when invoking a service. It’s a command line based tool with a very simple, intuitive syntax. All of the details are accessible if we need them, but more often than not they just get in the way. In fact, we enjoyed working at this level of abstraction so much, that I wrote a functional test framework (named jwoodunit by my co-workers) that drove service level tests against our services, which were written in this same “language”. It allowed us to pump out service level tests is very short order that were easy to read, and easy to maintain. It has only just occurred to me that what we had created was really a Domain Specific Language (DSL).

We have a fairly large quality assurance team that is made up mostly non-developers. Most of the testing that is done is manual, or driven by an automation tool similar to Selenium. The problem is that the manual testing is slow and not reliable, and tools like Selenium tend to be brittle, since they are based on the layout of the HTML page. It also prevents you from testing any service that is not directly accessible through the web application. So, for my project, I wanted to see if I could take my team’s DSL, clean it up even more (it is still very “programmy”), and give it to our quality assurance team so that they could test our services in a more reliable fashion.

What I ended up with was a very high level, English like DSL that I call Trastel (Travel Service Testing Language). Trastel is implemented in Ruby. In fact, it’s safe to say that Trastel is Ruby. I didn’t implement a new language. I simply took advantage of Ruby’s fantastic meta programming capabilities to extend the language with functionality that is needed by the tests. A example test is worth 1000 words:

search.flights.on("orbitz").where(
   :origin => "ORD",
   :destination => "LAX",
   :departure_date => "2008/12/10",
   :return_date => "2008/12/15"
)

verify_at_least_one_result

foreach_result do
  verify_equal "ORD", origin
end

This does exactly what you’d expect. It searches flights on Orbitz, flying from Chicago’s O’Hare airport to Los Angeles International Airport on 2008/12/10, returning on 2008/12/15. We then verify at least one result came back, and that the origin of each flight is O’Hare. That’s it.

Implementing this test in Ruby was a breeze. Since everything is an object in Ruby, dynamically adding methods to the Object class gives us the ability to create pseudo-keywords, like “search”, and “foreach_result”. Trastel also sets an attribute named @response on the test, so the code that implements the verify methods can just check that, instead of having to specify that your checking the response of the service call. foreach_result will iterate over the @response if it is an array, yielding to the specified code block for each item in that array…giving us an easy way to check each element. The last bit of magic surrounds the “origin” method. “origin” isn’t a method on object. It’s a method on the the type contained in the @response. Thanks to Ruby’s method_missing method, I can forward that method call onto the object in the @response for it to tell me what origin means. Nice and easy.

Another great thing about Trastel is that it sucks in Active Support. Active Support brings with it a wealth of extensions to the core ruby classes, letting us do something like this:

search.flights.on("orbitz").where(
   :origin => "ORD",
   :destination => "LAX",
   :departure_date => 4.weeks.from_now,
   :return_date => 6.weeks.from_now
)

We still do all of the heavy lifting (creation of the service request, execution of the remote service, etc) in Java, using JRuby to get the Ruby code to play nice with the Java code. But, the DSL serves as an excellent means to collect the data needed to drive the test, call the Java code to invoke the service with that data, and verify the data in the response matches what was expected. It successfully keeps the person writing the test from having to know anything about actually invoking the service. Writing tests at this level of abstraction also shields us from the majority of service API changes that may come our way.

With all of the benefits that I can already see with this still very immature DSL, I’m kicking myself for not considering DSLs more seriously in the past. They have been around quite some time, and have had many well know developers singing their praises. I’m looking to see what other problems I’m currently facing that could be solved a little easier by letting me code a little closer to the domain. Had I know that it would be this simple, maybe I would have tried it a long time ago.

Kind of a funny side note about this project. I recently found out that a couple of co-workers of mine spend some of their spare time working on Planypus, which is a site for making plans with your friends. Sounds familiar! I was talking to them, and it turns out that Planypus started the exact same way that the Diners Club webapp started, as just a way to organize dinner outings with friends. They however took it to the next level and threw a business plan around it. I’m just not that business savvy I guess :)

It wasn’t until later that I found out that Bugzilla and SMTP Authentication do not get along (although I see that there is a fix in the pipeline). Bugzilla supports SMTP, but without authentication. It also supports sendmail, but my ISP isn’t too keen on people running their own mail servers, making the use of sendmail difficult. Since my ISP has a SMTP server for me to use, I figured I would use that. But, authentication is required on that server.

I toyed around with some ideas in an attempt to keep me from hacking the Bugzilla code. One involved parsing the data/mailer.testfile file (where mail is sent when the “testfile” mail option is set) for the To address and the email body, and sending the email via a custom script. But, that brought up some interesting race conditions if multiple users made a change that triggered an email at approximately the same time. We would need to periodically read that file to send the email, wiping out the contents afterward to avoid resending the same messages. If the timing was right, we could potentially wipe out a message that was never sent.

I took a look at the Bugzilla code, and found the module that was responsible for sending the email. The code was clean, and pretty easy to follow, even though I know very little perl. I found the point in the module where it calls out to the Mail Transport Agent to deliver the mail. I figured I could easily insert a call to a script to deliver the mail, using SMTP Authentication. That is exactly what I did. I modified BugMail.pm to include the “system” call below.

sub MessageToMTA {
    ....

    # --- Begin New Lines ---
    system('send-bugzilla-email.rb', $msg);
    # --- End New Lines ---

    $mailer->open($headers->header_hashref);
    print $mailer $body;
    $mailer->close;
}

$msg is a variable that contains the SMTP message to send. That message includes the To address, the subject of the email, and the body of the email. In other words, everything we would need to send the mail ourselves. I then wrote a ruby script to parse the message, and send the email. Here’s the script.

#!/usr/bin/ruby

require 'net/smtp'

from_address = 'username@my_isp.com'

# Break the message up into an array of strings
message_array = ARGV.first.split("\n")

# Pull out the To address and the subject
message_array[1] =~ /^To: (.*)$/
to_address = $1

message_array[2] =~ /^Subject: (.*)$/
subject = $1

# Delete some crap that we do not care about
4.times { |i| message_array.delete_at(0) }

# Combine what remains back into the body
body = message_array.join("\n")

message =  "From: Bugzilla <#{from_address}>\n"
message << "To: #{to_address}\n"
message << "Subject: #{subject}\n"
message << body

# Send the email
Net::SMTP.start('smtp.my_isp.com', 25, 'my_isp.com', 'username', 'password', :login) do |smtp|
  smtp.send_message message, from_address, to_address
end

File.open('/var/log/bugzilla_email.log', 'a+') do |file|
  file.puts("\n-----------------------------------------\n")
  file.puts(message)
end

Although not ideal, it does the job. And, if I do say so myself, it works quite well. I’ll be looking forward to upgrading to the new version of Bugzilla once it supports SMTP authentication. In the meantime, this will keep things rolling.