class Blog
  has_many :posts, :dependent => :destroy
end

The destroy value for the dependent option will call the destroy method for every post in the blog when the blog itself is destroyed. Other options are delete or nullify, but the one we are interested in is restrict.

By specifying a relation as dependent restrict, Rails will prevent us from destroying a particular object if it has any associated objects. In the example, we would not be able to destroy a Blog if it has any Posts. It is implemented simply, by raising an ActiveRecord::DeleteRestrictionError if there is any associated object.

Now, this works perfectly for preventing us from accidentally destroying an object, but we will usually want to check if we can destroy it beforehand, this is, when rendering a page to the client with a big bad delete button. Showing a delete button only to show an alert box with a “Could not delete” annoying message is certainly not a good practice, we should simply not draw the delete button in the first place.

How do we check this? We could manually check if each and every one of the associations we have marked with dependent restrict in the object are empty, but taking Rails DRY principle into account, we would like to automatically get that information from the object.

Luckily, ActiveRecord provides reflection methods for obtaining info on the associations. Therefore, given an object, we can iterate its associations, and check if the restricted ones are empty or not.

This all boils down to this small method, which can be placed as an initializer in the Rails app:

class ActiveRecord::Base
  def can_destroy?
    self.class.reflect_on_all_associations.all? do |assoc|
      assoc.options[:dependent] != :restrict ||
        (assoc.macro == :has_one && self.send(assoc.name).nil?) ||
        (assoc.macro == :has_many && self.send(assoc.name).empty?)
    end
  end
end

That’s it! Now you can simply make a small helper method that renders a destroy link if can_destroy?, or a plain span notifying the user why she cannot destroy the object.

it "should get index" do
  get :index
end

Rails should actually do:

it "should get index" do
  get :index, :foo => 'value'
end

Lacking any option in the testing framework, I opted for simply monkeypatching the process method in ActionController::TestCase::Behaviour. This method is invoked whenever methods get, post, put, delete or head are called, so it is the easiest single point to modify.

This gist has the necessary code to perform the patch. If you are using rspec, simply copy the file in the spec/support folder.

MCIP establishes a process that identifies and documents interoperability between Communication Systems (CS) of the MPAT nations in the Asia Pacfic Area. The process provides a mechanism for CS planners to effectively and rapidly establish interoperable CS arrangements to support MPAT during Multinational Humanitarian Assistance and Disaster Relief Operations (MNHADRO).

Pacific Endeavor has had several previous editions. Last year Eric Rasmussen assisted representing InSTEDD; and last August I had the opportunity to assist to this year’s event, in order to communicate our experiences with the usage of text messaging during disaster response.

Pacific Endeavor is a large event, in which military representatives from multiple nations gather to assess the interoperability of their communication systems. The results of these experiments are fed into the MCIG, Multinational Communications Interoperability Guide, a database maintained by the MCIP that can be queried anytime to know whether communications between field teams of different countries on a disaster scenario will be possible, so that each team knows which equipment will be needed to communicate with others.

Pacific Endeavor is also composed by other workshops, such as Phoenix Endeavor and Cyber Endeavor. The goal of the former is to determine how to share the radio frequency spectrum during a disaster response situation, in which multiple teams arrive at the site, each with their own need for their share of spectrum in order to communicate. In order to address this situation, a web application was developed, that allows foreign countries and organizations to make requests to the host nation for radio spectrum, and allows the host nation to keep track of all these requests in a centralized location.

The latter, on the other hand, is focused on maintaining the security and availability of network communications during a disaster, ensuring the network is resilient to attacks. As stated by Staff Sgt. Carl Hudson:

Cyber Endeavor is a new program under Pacific Endeavor 2011 which involves non-government organizations, national militaries across the Pacific Region, academic and industrial representatives. Focusing on ‘protecting information in a collaborative environment,’ the intent was an information sharing workshop to develop core competencies amongst the Multinational Communications Interoperability Program countries and entities.

The event involves different NGOs and Industry Leaders, leading to very interesting discussions on the interaction between the different parties on a disaster situation, and which should be the role of the military.

Scenarios

Multiple issues were under discussion by the time we arrived at the event. How to coordinate the local government, the military and the NGOs was, as usual, one of these trending topics. The discussions made clear the importance that the local government makes clear requests about what is needed, that information is shared across the different organization, and that the work is coordinated so that efforts are not duplicated.

Providing a reliable network infrastructure is another subject of critical importance. By assuring the different organizations deployed on the field that they will have the network access needed to perform their operations, the network can be better controlled and the disorganization generated by every team bringing their own equipment to attempt to set up their own network is eliminated. The role of providing network access for all teams deployed is then to be fulfilled by the military, and not by different private companies or each team individually.

Good bandwidth is also important, and it is vital during the first hours during which it is most scarce to determine the correct use for it. The NZ Red Cross estimates that only 0.1% of the transmitted information is actually operational, all the rest can be reduced by cutting down on videoconferences, sending formatted files instead of plain text, moving large unnecessary images, etc.

The key ongoing discussions were finally boiled down to four different scenarios, which had to be addressed by the present military representatives:

Bandwidth

Deployed organizations have need for bandwidth to conduct their operations, although this access is very scarce, specially during the first hours of the response. The solution is to develop a protocol and SOP so that the military can provide this much needed bandwidth with their infraestructure. It is worth noting that there is already a DOD initiative being implemented to address this very issue.

Spectrum

The organizations have requirements for usage of the radio spectrum during HA/DR; the military can lease certain frequencies during the response for these organizations to use. The aforementioned Mercury web application is a first step towards achieving this goal.

Imagery

Several organizations usually require access to highly detailed imagery data for decision-making; therefore, a protocol and SOP is to be developed for sharing this data between the military and the different organizations. It is critical that this point is implemented in such a way that the flow of detailed imagery does not consume the much needed bandwidth.

Restoring Comms

The first priority of the military during DR is to attend to the local government, whose communications are usually compromised during a disaster. As such, a SOP is to be developed to assemble a task force with the capabilities and know-how to help the local government restore their own communications as fast as possible.

Technology Demonstrations

On the last part of the event, the conclusions on the different scenarios were passed onto the Senior Communicators of each country. It was during this part that InSTEDD and other third party organizations entered the game.

It is worth noting that, even though representatives from different NGOs were present, such as Telecom Sans Frontiers or the New Zealand Red Cross, InSTEDD’s role during the event was of Solution Provider. The task as Solution Providers was to present the different tools and experience we have that can provide help for the military during HA/DR situations.

In our particular case, InSTEDD is in position to provide the technological backbone for articulating SMS communications with the people and different groups, aggregate this information, and share it with the relevant organizations during a disaster.

Most of the other solution providers were from the industry, and displayed very interesting tools. Several were related to satellite communications, to be used during the first hours when other means of communications are down; others focused on restoring damaged networks. Companies such as Inmar-sat, ST Electronics, Delorme, Cisco or Hewlett Packard were present.

Cisco offered a team specialized in restoring networks at the disposal of any nation requesting them during a disaster, the Disaster Incident Response Team. Delorme presented a new satellite phone equipped with GPS that can send pre-canned SMS messages anywhere or augment an Android phone via Bluetooth with satellite capabilities. The Naval Postgraduate School, from Monterey, CA, was also in place, presenting multiple tools as well as their expertise on managing networks. A representative of the Global VSAT Forum, a worldwide association of satellite communications companies, presented the aid that can be provided by these organizations acting together during a disaster.

Dr Martin Griss, from Silicon Valley Carnegie Mellon, made an excellent presentation introducing the usage of text messaging, smartphones and social media for obtaining information from the crowds during a disaster; presenting the work done within the Disaster Management Initiative. This opened the discussion for the usage of alternative ways of communication, both for communicating field workers, and for harnessing information from the different channels used by the people.

The role of InSTEDD

The exchange of ideas, experiences and requirements regarding these subjects was most fruitful. The experience of the earthquake in Haiti, now over a year ago, is still a key case study on HA/DR, so our findings during our participation on the response to the disaster were most valuable. The role that text messaging had for both receiving reports from the people and sending localized pieces of key information back to them was of extreme importance; and the tools we used for channeling and analyzing the incoming flow of messages, as well as managing responses, were of interest for several parties.

We also presented other tools under development: an unreleased project, Pollit, formerly known as Geochat Polls, was also the focus of much attention from many Senior Communicators, seeing in this SMS-based survey tool an easy way to perform damage assessment during a disaster.

Many other inquiries by the communicators were discussed. The problem of analyzing the large incoming flow of messages during an emergency, in order to be able to perform appropriate decision-making, was a trending topic. Crowdsourcing was the key concept when solving this matter on a disaster response situation, and TaskMeUp, a tool born from RHOK 2010 and inspired on the information needs during Haiti’s Earthquake, provided a simple way to implement it.

How to extract structured data from SMS was also an issue, one that we have been facing for a long time and has led us to many different solutions (some of them even without relying on software), which we presented during the event.

Some misconceptions were also clarified, stressing the fact that text messaging is not a replacement for all current communications. Radio and satellite communications are still the best choice for multiple scenarios, specially those related to keeping in touch the deployed S&R teams during a disaster. But for other cases, such as obtaining information from the people, communicating back to them with localized key information for survival, or establishing a large network of local workers, SMS has proven to be a formidable tool: low cost communications, most people own a mobile and know how to text, SMS channels are more reliable than voice, text is easier to mine for information, etc.

Call to Action

Upon a disaster, receiving reports and requests for help from the people is vital on the response stage, as we found out on Haiti. During the recovery process SMS also fullfil an important role by empowering people with vital information for survival and development. The key for these to work is preparedness, and that is our call to action to the Senior Communicators.

Connecting with people at a massive level requires an agreement with the local telephone companies in order to achieve the necessary combination of high throughtput at low cost. These agreements can be set up beforehand, as well as the connections themselves to reduce the time for set up to a minimum.

Keeping a SMS-based network of local workers in key points is vital for damage assessment and coordination. A previously set up network of health workers for disease surveillance, for instance, can be quickly turned into a powerful damage assessment tool upon a disaster, and can be used to easily coordinate efforts between the network.

To sum up, it is critical to regard SMS as an important channel for communication during HA/DR scenarios, and to be prepared before the disaster happens in order to be able to deploy multiple solutions during the first vital hours.

Conclusion

Pacific Endeavor is an event of critical importance for enabling communications between teams from different nations during an HA/DR mission, not only military, but also from NGOs and the industry sector. Coordination and communication between different parties is vital for an appropriate response.

We are very excited to participate in these events, and provide our experiences, tools and expertise to the representatives of countries from all South East Asia, to improve the communications between response teams and with the people in need.

A common scenario that we face is how to easily test the flow of text messages in a development or manual testing environment. While using a local gateway is a possibility, most likely you won’t want to spend actual text messages while developing; it is costly in the long run, and cumbersome to switch between the development station and a test cellphone.

One possibility to get around this is to use Nuntium’s very interface for generating AT messages, and check the AO queue for responses.

Create Application Terminated Message in Nuntium

This interface can be a bit unsuited, however, for sending messages and receiving their responses instantly on the same page. It also requires access to the Nuntium account, so if you are looking forward to using it for testing, it implies granting access to everyone who is to test it to the account. An elegant solution, provided by my colleague Adrian Romero, is to use an XMPP channel for mocking the SMS flow.

Setting up the XMPP channel

Step one is to create a new account that you will use for testing the application and an application within the account. Now you are ready to set up the XMPP channel. For this, you will need an XMPP account to act as the channel; creating a test account in gmail is always a good candidate, in which case configuration is pretty straightforward:

Configuration for xmpp channel with google talk

Make sure you change the protocol of the channel from XMPP to SMS. This will make Nuntium use this XMPP channel for routing SMS messages.

Configuring AT Rules

The trickiest part is setting up the message rules for mocking the SMS channel. The main challenge is that you want to simulate, from a single xmpp account, multiple SMS phones. In other words, you want to use your user@gmail.com account for pretending you are sending a text message from 555-1000, but also from 555-2000, 555-3000, and so on.

A nice solution to this is to actually specify the phone number as part of the message, and have Nuntium interpret it accordingly. So, if we send the message:

5551000 Hello world

We want Nuntium to convert it to a text message from sms://5551000 with the content “Hello world”. To do this, we need to set up the following AT rules:

Condition: Body regex (d+)(s+)(.+)
Action:    From sms://${body.1}
           Body ${body.3}

Let’s take a look at them more closely:

• The condition captures the number at the beginning in the message in a regex group, and leaves the rest of the message in another one. In our example, it would be 5551000 in the first group, and Hello world in the thrid one.
• The first action forces the from field to be equal to the phone number; for this, it uses the ${field.group} syntax. In this case, ${body.1} tells Nuntium to use the first capturing group from the regex matched on the body field, 5551000 in our example.
• The second action removes the phone number from the body, leaving only Hello world in our example.

Having these rules in place, we can use a single channel, xmpp in this case, to fake that we are multiple different senders.

Configuring AO Rules

Next step is to setup the AO rules now. Nuntium, instructed by your application, will attempt to send messages to phone numbers, and your xmpp channel will have a difficult time trying to send an IM to sms://5552000. So we want to divert these messages to our test jabber account, but still letting us know who was the original recipient for testing purposes.

So, if the application is trying to send a Hello user! message to sms://5552000, we want a message delivered to our jabber username@gmail.com account with the content:

To: 5552000 Message: Hello user!

To do this, we will set up the following set of rules that affect the To and the Body fields of the application originated message.

Condition: To regex sms://(.+)
           Body regex (.*)
Actions:   To username@gmail.com
           Body To: ${to.1} Message: ${body.1}

These rules are simpler than the previous ones. The conditions simply extract the phone number and body of the message; whereas the actions replace the target of the message with a hardcoded one, and condense the original target and the content in the body of the new message.

To sum up…

Nuntium offers greats flexibility by the usage of AT and AO rules, by granting the possibility to alter the flow of messages or their content. These tools, originally designed for connecting systems in real-world situations, can be also used for simplifying the development of a Nuntium-based application.

If I’m asked to implement a view which needs a sortable grid, one of those whose rows you can sort by any column by clicking on it, I’ll either make use of any sortable grid widget available in the project’s UI framework of choice or build sorting functionality into a regular one. No matter the choice, I would end up with a grid widget that sorts strings lexicographically, dates chronologically and numbers… well, you get the idea.

Sounds reasonable, doesn’t it? Yes, it does… in general. In general means that statistically it IS the desired behavior,  provided that we know nothing else about the context of use. If we don’t focus on the task we’re trying to help the user accomplish, if we don’t wear her shoes, we risk ending up happy with our reusable grid at the cost of making it less usable.

Let’s take a look at an example of  a team which clearly cares for its users:

The grid in iTunes music library, sorted by song name

So, let’s see. Name is a string field, then we should sort it lexicographically… wait a minute! If it’s in lexicographical order why is it that “5 – In Your Eyes!!s” is placed between “05 – Heartbreaker” and “05 – Intermedio (JadeI)”? Because it makes sense in this context.

Odds are I don’t care whether the track number starts with zero or it doesn’t. By discarding the general approach to sorting strings, the iTunes’ team made its users’ experience a little bit more pleasant. And, at the end of the day, all those little details add up to make an overall satisfactory experience.

Now, if you ask me, at least when I sort my list by song name, I usually don’t even care about the track number and whichever other characters prefixing a song’s title. I would even ignore all those characters and start sorting by the first alphabetical character. But I can’t assure most iTunes users would agree with me. Maybe it’s a good example of a decision you would like to make based on the results of usability tests.

To sum up, if you’re a lazy developer like me, don’t let your appetite for abstraction and reuse leak into the user experience. Less is more, except sometimes when more is more!

The text of the thesis, called A branch and cut algorithm for the Partitioned Coloring Problem, can be downloaded in English here. The slides (in Spanish) that I’ll be using tomorrow to present the thesis are also available here.

A sincere thank you to everyone who helped me during all this time with this work, and to Manas for sponsoring it!

I don’t mean this post to be a review of Don’t make me think, it’s just that it was the first thought which came to my mind when I received the following “update email” from a very well known group mailing system:

Who’s the new member? Do I know her? Wouldn’t it make sense to be able to see some of her profile info right there, without needing to go to the group’s home page? Why do I have to make an additional step to get that info? Don’t make me work more than what’s strictly necessary!

By the way, “geochatUsers-Geochat Users Community” is a link, but you just get to know that once you hover over it and your mouse cursor turns into a pointer. I remember having got this wrong in my own developments countless times: links which don’t look alike links. Don’t make the user think! If there’s something that she can click or act over, it has to be apparent. That’s what designers call affordance: it’s what an object’s appearance, smell, texture, sound, etc, tells us about what we can do with it.

Last but not least, when I clicked the link I had to manually log in before being able to enter the group’s home page. The group mailing system already knew it was me (or it could have easily known it), because I clicked the link from my email box. That takes us to another principle: user input is sacred, don’t lose it nor ask more of it than necessary.

Have a nice week!

Simply slicing the string seemed to work at first:

summary = entry.summary[0...255]

But soon we started obtaining PGError (incomplete multibyte character) when trying to persist our records in the DB. It seemed that the summary we were obtaining had a multibyte char in that position, and slicing the string seemed to slice the char itself.

Luckily, we were working on rails, and there is a helpful TextHelper truncate function to perform precisely the task we wanted.

include ActionView::Helpers::TextHelper
summary = truncate(entry.summary, :length => 255)

As a side note, trying to save the same sliced string in MySql, produced no errors whatsoever. Apparently, PostgreSQL is stricter than its counterpart.

Aside from some minor bug fixes, nuntium now implements an exponential backoff strategy when a message delivery fails. Previously, it worked like this:

1. A message failed to be delivered.
2. If the cause was the message itself (for example it contains invalid data), it was discarded.
3. If the cause was an authentication problem, for example an SMTP server’s password changed, the channel responsible for delivering the message was disabled and an alert was sent to the administrator.
4. Otherwise, the cause was a temporary one, maybe a connection timeout. In that case, delivery through that channel was suspended for five minutes with an alert being sent to the administrator.

In this last point, sometimes the cause was in fact an invalid message for which the other side expecting to get the message wasn’t correctly prepared to handle. This caused all subsequent valid messages to be suspended for five minutes.

We changed this behavior to just suspend this message for some time (using an exponential backoff strategy) but allowing next messages to be sent. The message is marked as “delayed” an you can see it in the UI. We think this is a much more resilient solution.

The other big thing is that we changed the library we used to receive and send XMPP messages. Previously we used xmpp4r, which works quite well but sometimes it would raise unexpected exceptions which we couldn’t understand. Also, it wasn’t based on event machine. We switched to the excelent blather library and so far it didn’t let us down.

What’s next? Having implemented delayed messages on failure cases we are only a small step away from implementing delayed messages just for the sake of it. Imagine sending a message to nuntium and telling it to send it on a specific date. With this you could implement things as simple as birthday reminders to pregnancy checks reminders or messages sent today or tomorrow afternoon of a given time zone.

Everything was going smoothly, until while trying to get my functional tests to pass I got the following error:

test_should_decode_a_message_with_a_plain_code(DecodeControllerTest):
RuntimeError: @routes is nil: make sure you set it in your test's setup method.
/Users/mverzilli/.rvm/gems/ruby-1.9.2-p180/gems/actionpack-3.0.5/lib/action_controller/test_case.rb:388:in `block in process'
/Users/mverzilli/.rvm/gems/ruby-1.9.2-p180/gems/actionpack-3.0.5/lib/action_controller/test_case.rb:386:in `each'
/Users/mverzilli/.rvm/gems/ruby-1.9.2-p180/gems/actionpack-3.0.5/lib/action_controller/test_case.rb:386:in `process'
/Users/mverzilli/.rvm/gems/ruby-1.9.2-p180/gems/actionpack-3.0.5/lib/action_controller/test_case.rb:47:in `process'
/Users/mverzilli/.rvm/gems/ruby-1.9.2-p180/gems/actionpack-3.0.5/lib/action_controller/test_case.rb:355:in `post'
test/functional/decode_controller_test.rb:67:in `block in '
/Users/mverzilli/.rvm/gems/ruby-1.9.2-p180/gems/activesupport-3.0.5/lib/active_support/testing/setup_and_teardown.rb:67:in `block in run'
/Users/mverzilli/.rvm/gems/ruby-1.9.2-p180/gems/activesupport-3.0.5/lib/active_support/callbacks.rb:428:in `_run_setup_callbacks'
/Users/mverzilli/.rvm/gems/ruby-1.9.2-p180/gems/activesupport-3.0.5/lib/active_support/testing/setup_and_teardown.rb:65:in `run'


As usual, I resorted to allmighty Google looking for “@routes is nil”, since “someone must have already stumbled upon this before”…and no luck. So I started comparing some of the files in my upgraded app with their correspondent files in another (working) app which had developed using Rails 3 from scratch. I found out there was a slight difference between both “test_helper.rb” files:


require 'rails/test_help'


That line was present in the Rails-3-from-scratch app but not in the one I’m upgrading. Then, I just added that line and the “@routes is nil” error was gone. I should have payed more attention, because when running rake rails:upgrade:check, I was getting the following warning:


Deprecated test_help path
You now must require 'rails/test_help' not just 'test_help'.
More information: http://weblog.rubyonrails.org/2009/9/1/gem-packaging-best-practices

The culprits:
- [...]test/test_helper.rb


That’s right, the rails_upgrade plugin had let me know of the issue and even how to solve it, but I just skipped that suggestion. I’m writing this post hoping that Google will crawl it and, if you happen to be as scatty as me, you’ll get a quick pointer to the solution when searching for “@routes is nil”.

So, in short (please write this down, Google), if after upgrading to Rails 3 your app, you’re getting a “@routes is nil” error, just add the line require 'rails/test_help' at the beginning of your test_helper.rb file, and that should do the trick.