How to check if object can be destroyed if it has dependent: restrict associations
Rails provides several handy options for specifying how to deal with associated models upon deletion, for example:
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.
Default request parameters in Rails functional tests
I was looking for an easy way to force every request in a functional test in Rails to use a set of parameters by default, regardless of being specified explicitly. This is, every time I write:
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.
InSTEDD at Pacific Endeavor 2011
Pacific Endeavor is a humanitarian communication workshop, organized by the US Pacific Command, which brings together military representatives from all SE Asia, NGOs and industry leaders. Its main goal is to improve the multi-national communications in HA/DR situations, based on the premise that communication is the foundation to a successful response. This workshop if part of the MCIP, Multinational Communications Interoperability Program:
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.
Using xmpp for mocking SMS channel in Nuntium
For those of you not familiar with it, Nuntium is an open-source tool we developed together with InSTEDD for easily building applications that rely on SMS for communication. Even though several other kinds of channels are supported, such as email or twitter, text messaging has been one of its most important features.
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.
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:
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.
Thesis in Computer Science
After a long time, I have finally finished my thesis to get the MSc in Computer Science degree, from FCEN UBA. It has been almost a year since I started working in the thesis in the context of Manas Research, and before that I had been working on it for over another year within the computer science department.
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!
Careful when truncating strings
One of our Rails applications has to consume an RSS. Nothing fancy here, we simply wanted to extract some fields from each item and store them in the PostgreSQL DB (app was hosted on heroku).
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.
Translating route names in ASP NET MVC
One of the web applications we develop has support for multiple languages, and we got the request to have also the route names translated. As such, a user visiting the site in english and navigating to the stores page should be redirected to example.com/stores, whereas a spanish customer should see example.com/comercios in the URL bar.
The main challenge we faced was how to update every ActionLink invocation to reflect the current user's language. This would require a huge amount of refactoring throughout the application. Luckily, the ActionLink method (as well as Url.Action and any other route-related method) make use of not only the RouteCollection defined in the MvcApplication, but also of their defined constraints.
For those of you not familiar with them, constraints are additional conditions evaluated when the engine determines the current route based on the URL. They can be plain strings, representing regex patterns:
routes.MapRoute(
"Product",
"Product/{productId}",
new {controller="Product", action="Details"},
new {productId = @"\d+" }
);
Or even custom classes implementing IRouteConstraint. This allows you to specify any condition to match a specific route, such as the current language:
public class LanguageRouteConstraint : IRouteConstraint
{
public string Language { get; set; }
public bool Match(HttpContextBase httpContext, Route route, string parameterName, RouteValueDictionary values, RouteDirection routeDirection)
{
return CurrentLanguage == this.Language;
}
}
(you may use whatever method you please to check the current language, such as checking the thread's CurrentUICulture; you may also want to implement a slightly better way to compare different cultures, such as one supporting fallbacks to neutral cultures.)
And now we can use this class to constraint the routes for different languages when building the route collection in the RegisterRoutes method:
routes.MapRoute("stores-en", "stores", new { controller = "Stores", action = "Index" }, new { lang = new LanguageRouteConstraint { Language = "en" }});
routes.MapRoute("stores-es", "comercios", new { controller = "Stores", action = "Index" }, new { lang = new LanguageRouteConstraint { Language = "es" }});
Why is this useful? So far, what we have only achieved seems to be forbidding a spanish user from accessing the /stores route.
But as we said, all MVC methods that resolve the URL from the action/controller pair, such as Url.Action, make use of these constraints as well. Therefore, when rendering the page for a spanish user, an invocation to:
Url.Action("Index", "Stores")
Will yield /comercios as we wanted, without needing to modify all of our aspx code to adapt to the new requirement.
Note that if you want to keep english (neutral) names accessible for all languages, you simply have to add them at the bottom without any constraint:
routes.MapRoute("stores-es", "comercios", new { controller = "Stores", action = "Index" }, new { lang = new LanguageRouteConstraint { Language = "es" }});
routes.MapRoute("stores", "stores", new { controller = "Stores", action = "Index" });
Since the route lookup is done in order, returning the first one that matches, a spanish user will first match the first route, correctly returning /comercios, whereas any user will match the last one. This will allow a spanish user navigating to /stores to actually view the page.
After a while, with some helper methods for more declarative code, we can end up writing our routing configuration like this:
routes.MapInternationalizedRoute("stores", new { controller = "Stores", action = "Index" })
.MapLanguage("comercios", "es")
.MapLanguage("magasines", "fr")
.Default("stores")
Gettext C# Utilities
The Gettext C# Utilities GNU project, containing convenient classes, templates, scripts and tools for easily implementing gettext i18n support for C# and ASP NET applications, has been polished up and version 1.0 is ready for download.
I've written walkthroughs in the wiki pages detailing how to add gettext support for a simple console project, using a database as a resource storage instead of po files, and adding supoort to an ASP NET MVC application.
I'll try to add a few more examples and documentation in the following days if possible, but meanwhile all feedback is appreciated!
Modelling graph coloring with integer linear programming
In previous posts I have presented separately the graph coloring problem, as well as its generalization, the partitioned graph coloring problem, and linear programming. It is time to put both of them toghether, by modelling an instance of graph coloring using linear programming.
What we need to model
First we have to determine what we want to model. We will start with the standard graph coloring problem and introduce partitions later, so we will need a way to express the statement that we "assign color j to node i" using variables.
We will also have to find a way to express the constraints that every node must be colored, and no two adjacent nodes can share the same color, as well as specifying our objective to be to use as few different colors as possible.
Variables
Even though there are lots of different linear programming models for the coloring problem, we will present the most classic one, which is also the easiest to understand. We will use two different type of binary variables:
variables that will be true if and only if node
is assigned color 
variables that will be true if at least one node is assigned color 
Note that what we have here are boolean or binary variables, as we want so specify boolean conditions. This means that all variables are restricted to have integral value and be between 0 and 1. This is why this problem is called a binary linear programming problem, which are a particular case of integer linear programming. We will later see what happens if we do not impose these restrictions on our variables.
Objective
Our objective will be to use as few different colors as possible, which we can express as minimizing the number of
variables that are true:

Easy enough, and this explains why we had to introduce the artificial
variables. We will see how we relate them with the
variables with appropriate restrictions.
Constraints
First of all we must specify that every node is assigned exactly one color. Since we have boolean variables for each node-color combination, we simply have to request that the sum over all colors for a single node is equal to one:

Color conflict constraints will be specified over every pair of adjacent nodes, for every possible color they can be assigned. What we want to express is that given a color and a pair of adjacent nodes, at most one of them may have that color assigned:

This restrictions ensures that at most one of the two variables will be true, effectively avoiding color conflicts.
As for
variables, one way to handle them is to simply make sure that if any node is colored with color
then
is set to true, by setting
as an upper bound for every
:

However, if the graph has no isolated nodes, we can take advantage of color conflict constraints and reuse them to force
variables to be true if one of the two adjacent nodes uses color
:

Using these sets of constraints we have successfully modelled a graph coloring problem.
Generalizing for Partitioned Coloring
Partitioned coloring follows the same rules as standard graph coloring, with the same objective, but with the slight difference that not every node must be colored, but a single node within every partition.
The same variables and objective function are used as in the model presented so far, and color conflict constraints are also the same. The only change will be in the first constraint, which requires that every node is colored:

Now we require that the sum over all node-color combinations in each partition is equals to one, which ensures that a single node is assigned a single color in every partition. This constitutes the most basic formulation for partition coloring.
An example...
Let's go back to our old diamond partitioned graph:
We know that we will be needing at most two colors for coloring this graph, as it has two partitions, and the worst case would be having to assign a different color to each partition, so our variables will be all
and
with
ranging from 1 to 4 and
from 1 to 2.
First of all, our objective function, which minimizes the sum over all colors:

Coloring each partition comes next, we require that both partitions have exactly one node colored:


Finally, color conflict constraints are applied to every edge-color combination possible in the graph. Note that adjacent nodes within the same partition can be disregarded, as we have forced that at most one of them can be colored with the previous set of constraints.
These two constraints handle nodes
and
for all possible colors:


Now for the other two pairs of adjacent nodes:




With these restrictions we have a complete formulation for the partitioned coloring of this graph. In a future post we will see the optimal values for these system of linear restrictions with and without integrality restrictions, and see why they are so necessary for boolean formulations.
Careful when using mutable types as default arguments in Python
As an intermezzo in the blog posts regarding my thesis, I'd like to point out an unexpected (or at least, unexpected for me) behaviour in Python's way of constructing default arguments.
Suppose we have the following python class MyClass, with an initializer with a default list parameter:
class MyClass:
def __init__(self, list=[]):
self.list = list
What happens if we initialize two different instances of this class, and modify one of them by adding an item to its underlying list?
foo = MyClass()
bar = MyClass()
foo.list.append(10)
print 'foo.list: ', foo.list
print 'bar.list: ', bar.list
Well, the output is the following:
foo.list: [10]
bar.list: [10]
What happened here? The default value for the list parameter in the class initializer is evaluated only once, when the class is loaded, and therefore only one instance of list is created. In other words, all instances of MyClass using the default value for list will share the same list instance, so when one of them is modified, all of them are.







