Ahora si, en español.

Como ya les comenté en un post anterior, estoy trabajando en mi tesis, un reconocedor de keywords para programas radiales. Por ser una tarea difícil que, entre otras necesidades, incluye el aprendizaje de la herramienta HTK, me dispuse a realizar unas pruebas generando un reconocedor de dígitos en español para lograr entender la herramienta.

Al hacerlo, encontré infinidad de dificultades a la hora de modelar e implementar este sistema, y es por eso que escribí el siguiente tutorial: Reconocimiento de Dígitos en Castellano utilizando HTK.

Los resultados no son perfectos pero son muy buenos para la poca cantidad de datos de entrenamiento que utilice. Así que los desafío a mejorar la implementación y, por qué no, a implementar nuevos sistemas con la ayuda de este tutorial.

Espero que les guste!

Last month I started working on my master thesis in the context of Manas Research. The idea for this research is to contribute with Farm Radio International (an organization that works with many partners in Africa to deliver effective programs to serve smallholder farmers through radio) by helping them with the problem of indexing content using speech recognition.

We plan on solving this problem by using a technique called Keyword Spotting which is used when the program has to recognize utterances of words in large amounts of recorded data.

One could say that for this task, we could use a general-purpose speech recognition system (based on Hidden Markov Models or similar techniques),  but the first constraint we are dealing with consists of thinking that the target language does not have resources for speech processing (as do Spanish or English where a lot of research and software have been developed) since the radio programs will be spoken in less studied languages such as Swahilli.

Therefore, our research will be based on the search of other kind of methods to face the problem.

Hopefully, this research will show us that good results can be achieved in spite of the constraints, and then, we will be able to implement full systems using our studies and algorithms.

Keep you informed .

What does this mean? This means that if you attempt to extract the subject alternative name from the certificate using Ruby’s OpenSSL::X509 library in the usual way, you’ll get a string reading simply “unsupported”.

cert = OpenSSL::X509::Certificate.new(certificate_string)
subject_alt_name = cert.extensions.find {|e| e.oid == "subjectAltName"}
return subject_alt_name.value
 
# On a standard certificate...
# 'email:user@example.com'
 
# On a MS certificate...
# 'othername:<unsupported>, othername:<unsupported>'

Note that the value returned is a string indeed, not an exception; this is because the underlying unix openssl library, which is wrapped by the Ruby one, returns exactly that value.

In order to properly extract the owner’s identification, you’ll need to parse the certificate using OpenSSL::ASN1 and going through the hierarchy. The element you are looking for has key “msUPN”, this is, Microsoft User Principal Name.

cert = OpenSSL::X509::Certificate.new(certificate_string)
subject_alt_name = cert.extensions.find {|e| e.oid == "subjectAltName"}
 
# Parse the subject alternate name certificate extension as ASN1, first value should be the key
asn_san = OpenSSL::ASN1.decode(subject_alt_name)
raise "Expected ASN1 Subject Alternate Name extension key to be subjectAltName but was #{asn_san.value[0].value}" if asn_san.value[0].value != 'subjectAltName'
 
# And the second value should be a nested ASN1 sequence
asn_san_sequence = OpenSSL::ASN1.decode(asn_san.value[1].value)
 
# Iterate through the ASN1 sequence looking for the msUPN key
asn_san_sequence.each do |asn_data|
  # As before, first value is the key
  key = asn_data.value[0].value
  next if key != 'msUPN'
  # And second value contains the actual data, return it if the key was msUPN
  email = asn_data.value[1].value[0].value
  return email
end
 
# Raise if we iterated through the sequence and did not find the key
raise "Extension msUPN not found"

This way, you can set up a solution that works with both Microsoft based certificates and standard X509 authentication certificates.

Please comment if you have found other ways for working with these certificates, I’d love to see other implementations using Ruby’s OpenSSL or any other OpenSSL-based library!

[Many thanks to Ed Magidson for his help in understanding and working with these certificates!]

When you need to do a custom select with a group by you generally do:

Model.select(...).group(...).all

This will create an ActiveRecord instance for each of the results, with accessors for each of the elements in the select clause. This is very expensive compared to just creating arrays of the values as the result of the query.

So let’s do it:

class ActiveRecord::Relation
  def raw
    connection.execute(to_sql)
  end
end

You can use it like this:

Model.select('id, sum(hours)').group('id').raw.each do |id, hours|
  # ...
end

Here’s a sample IRB session showing the performance gain:

irb(main):024:0> WorkedHour.where(work_group_id: 1).select('worker_id, worked_at, sum(hours)').group('worker_id, worked_at').all.length
=> 3369
irb(main):025:0> time = Time.now; WorkedHour.where(work_group_id: 1).select('worker_id, worked_at, sum(hours)').group('worker_id, worked_at').all; Time.now - time
=> 0.314908
irb(main):026:0> time = Time.now; WorkedHour.where(work_group_id: 1).select('worker_id, worked_at, sum(hours)').group('worker_id, worked_at').raw.to_a; Time.now - time
=> 0.044524
irb(main):027:0> 0.314908 / 0.044524
=> 7.072769742161531

So, creating arrays as results for 3369 objects instead of ActiveRecord objects results in a 7x performance boost.

Despite a lot of tutorials out there on how to write coffee and take advantage of the Rails asset pipeline, there are rather few guidelines on how to properly organize your code using these technologies; so let me outline a few techniques we have been using on some of our projects, such as Verboice and ResourceMap (both of them open source, so feel free to check them out).

Knowing when to execute

One of the key features of the asset pipeline is that all your js code is concatenated, minified and compressed into a single file, with aggresive client-side caching, so that the user only needs to download a single file the first time she visits your site.

However, this will imply that all of your javascript code will execute on every page in your site, unless you do something to prevent it. An easy way to solve this is to simply execute if there is a particular object in your DOM:

if $('#my_div_in_complex_page').length > 0
  class Foo
    ...

Eventually, if you find yourself relying too much on a particular object which indicates a complex functionality is required, you can abstract that to a global function, and use it whenever you need it:

# on a global functions file
@onComplexFunctionality = (callback) -> $(-> callback() if $('#my_div_in_complex_page').length > 0)
 
# when you need to use it
onComplexFunctionality >
  class Foo
    ...

A more comprehensive approach is the one explained here, which allows you to specify particular code to execute for each controller and each action without needing to rely on a particular DOM object or defining an “onFunctionality” function.

Basically, it works by defining functions in a global object with names that match controllers and their actions, such as:

Site.users.index = () ->
  # your code for users/index here...

Modify your application’s template so it renders as data attributes of the HTML body which are the controller and action executed:

<body data-controller="<%= controller_name %>" data-action="<%= action_name %>">

And load that information from an executor function that runs on page load, executing the function that matches the current controller and action.

This approach, although it requires a larger setup, works very well for large applications, in which you have clearly separated behaviours in different pages of your app. Otherwise, relying on a simple check for a certain DOM element is a clean solution.

One class per file

One of the goodnesses of coffeescript is that it isolates each unit of code in a separate context, and makes each function local to that particular context, to avoid those pesky global functions so ubiquitous in traditional javascript. If you want to split the behaviour for a particular page in multiple files, if you are using any of the techniques described above, you will run into the problem that whatever classes you defined in file A.js.coffee within a callback at onCondition, will not be visible within the code you write in B.js.coffee in a similar callback.

If you want a class to be usable outside the context in which it is defined, the key is to define it as an attribute of the global window object, as described here:

class window.Foo
  # your code for the class...

Even more succint, you can use the “@” syntax, as it will always refer to ‘this’, which, when defining the class, will be the global object:

class @Foo
  # your code for the class...

This will allow you to refer to class Foo from any other file in your application easily. But what happens when you need to refer to class Foo before it has been defined, such as when you need to inherit from it? Consider the following case:

# in file A.js.coffee
class @A extends B
  # fails because B has not been defined yet
 
# in file B.js.coffee
class @B
  # is defined after A as this file is processed after A.js.coffee

What you need to do is to instruct sprockets that file B.js.coffee needs to be included before file A. Considering your sprockets application.js file is probably simply doing a require_tree of the entire assets/javascripts folder, you want to keep this file as simple as possible, keeping the directive of including B before A within A or B.

As the require directive in sprockets will include the file only if it has not been included yet, you can simply add a require directive for file B at the beginning of A:

# in file A.js.coffee
#= require B
class @A extends B
  ...
 
# in file B.js.coffee
class @B
  ...

This way, sprockets will execute the following flow:

1. Starts from application.js, reads the require_tree directive and starts processing all files in the tree
2. First file in the tree is A.js.coffee, but begins with a directive to include B first
3. Includes file B.js.coffee, as specified by the directive in A
4. Proceeds to include the contents A.js.coffee
5. Continues processing the remaining files in the tree, skipping B.js.coffee as it has already included it

Also, in the case you want to have a file containing certain global functions or classes, which will be used by other files in your app, you can take advantage of sprockets loading order.

Although you can use a require global directive at the beginning of each of your files, if you keep yout ‘global’ code in the root of your javascripts directory and all page-specific files organised in folders, sprockets’ require_tree directive will first load the files in the root of the directory, and then proceed with the sub-folders.

Another simple alternative is to add a require path/to/globals instruction before the require_tree in application.js, but you will have to follow this procedure for each global or shared file you add.

Wrapping up

There are lots of different techniques you can use to split your coffeescript code in different files and keep it organised. The key concepts to keep in mind when doing so are:

• You have to prepend @ to a class name if you want to use it from a different context
• Be careful when writing code that depends on something defined in a different file, make sure to require it or ensure that sprockets will load it before
• All your javascript code will always execute unless you execute it conditionally based on the HTML being rendered

Hope it helps!

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!