When you start developing with Rails, all these operations I mentioned are normally done in the controller. However, as we begin to lighten our controllers we fatten up our models with more and more callbacks. This is a good thing but at times we end up with a load of callbacks in the model that have nothing to do with the model.

To extract all this disparate code which has nothing directly to do with the model, Rails gives us observers.

Inside Observers

In this post, we’ll see how Rails observers work. For this it’s necessary to know how they are used so, if you’ve never used them, you should take a look at the documentation

The Ruby Observable module

Ruby implements some common design patterns in its standard library. One such module is Observable.

The Observable module implements the Observer pattern, also known as Publish-Subscribe. In this pattern, an object (the publisher or source) informs a group of interested objects (the subscribers) when it’s state changes. To accomplish this, we are given a series of methods to register subscribers and to notify them of state changes.

Let’s see an example of the use of the Observable module:

require 'observer'

class SystemMonitor
  include Observable

  def run
    last_free_space = nil
    loop do
      free_space = Disk.free_space
      puts "Free disk space: #{free_space}MB"
      if free_space != last_free_space
        changed
        notify_observers(free_space)
        last_free_space = free_space
      end
      sleep(60)
    end
  end
end

class DiskMainteinance
  def initialize(limit)
    @limit = limit
  end

  def update(free_space)
    if free_space < @limit
      puts "-- Cleaning temp files. #{free_space}MB free"
    end
  end
end

class AlertLowSpace
  def initialize(limit, email)
    @limit = limit
    @email = email
  end

  def update(free_space)
    if free_space < @limit
      puts "-- Notifying to #{@email}. #{free_space}MB free"
    end
  end
end

monitor = SystemMonitor.new
monitor.add_observer(DiskMainteinance.new(700))
monitor.add_observer(AlertLowSpace.new(700, 'peter@example.com'))
monitor.add_observer(AlertLowSpace.new(600, 'john@example.com'))
monitor.run

I think the example is pretty easy to follow, but it’s best if I clarify some details

The Observable module defines a series of methods that you can look up in the module documentation. In our example we use three of these:

• changed(state=true): the state of the object has changed.
• notify_observers(*args): i f the state is true, invoke the update method of each subscriber with the same arguments.
• add_observer(observer): register a new subscriber.

Lets see an execution example of the previous script:

Free disk space: 1011MB
Free disk space: 821MB
Free disk space: 880MB
Free disk space: 625MB
-- Cleaning temp files. 625MB free
-- Notifying to peter@example.com. 625MB free
Free disk space: 730MB
Free disk space: 570MB
-- Cleaning temp files. 570MB free
-- Notifying to peter@example.com. 570MB free
-- Notifying to john@example.com. 570MB free
Free disk space: 716MB
Free disk space: 841MB
Free disk space: 1016MB

ActiveRecord: Publisher and Subscriber

ActiveRecord has two classes involved in event management:

• ActiveRecord::Base: includes the Observable module and notifies the subscribers of al events to which callbacks can be associated
• ActiveRecord::Observer: the base class for all observers and defines the update method

When a model (i.e. a subclass of ActiveRecord::Base) changes its state it invokes, in addition to the callbacks in the class itself, the method notify_observers with the following arguments:

• The name of the event: before_validation, after_save, after_destroy…
• The ActiveRecord object

As we’ve seen, upon invoking notify_observers in the model, update is invoked on all the observers subscribed to the model. In the rails observers, the update method will invoke – if it is defined – the method of the class that has the name of the event notified and will pass as argument the object that has changed its state.

# Send observed_method(object) if the method exists.
def update(observed_method, object) #:nodoc:
  send(observed_method, object) if respond_to?(observed_method)
end

Initialisation of observers in Rails

Now we’ve seen how ActiveRecord::Base notifies observers of events. Nevertheless, we’ve not seen how observers subscribe (as I’m sure you know, via a call to the method add_observer in the module Observable).

When the rails observers call add_observer the constructor of ActiveRecord::Observer is run:

# Start observing the declared classes and their subclasses.
def initialize
  Set.new(observed_classes + observed_subclasses).each { |klass| add_observer! klass }
end

However, as the documentation states, to use observers, we don’t instantiate objects but instead we configure them in the environment.rb file (config.activerecord.observers_). This is to delegate to Rails the responsibility for initialising the observers.

We’re not going to look at when they’re initialised, but instead how.

The ActiveRecord::Observer class follows the Singleton design pattern. This pattern guarantees that there will be at the most one instance of a class. To achieve this, the visibility of the constructor is changed to private and a method is defined which returns the single instance of the class.

This pattern is also included in the standard Ruby library in the Singleton module. This module changes the visibility of the constructor and defines the instance method.

Therefore, Rails uses the instance method to subscribe the observers to the corresponding models.

Knowing this…

Knowing these details about the implementation of the Publish-Subscribe pattern in ActiveRecord and their initialisation in Rails, we have the technical knowledge to develop our own observers.
We found it necessary to develop our own observers in order to have a single class that subscribes to various models but attending to different events depending on the model.

In the next post, we’ll make the most of what we’ve explained here to look in detail at our observers.

Happy Hacking!

Rails Hackfest is a worldwide competition and this recognition is a (further) demonstration that in Spain and Europe in general, we have talent of the highest order.

Our most sincere congratulations to Ernesto and Juanjo. It’s an honour working with you both.

A while ago, we described our decision to use Ruby on Rails to develop Tractis and stated that we were happy to have chosen rails instead of Java. We also mentioned that, given the deficiencies of Ruby, we opted to employ Java Web Services for the digital signature back end.
Back then we were very happy with our choice of rails and we still are. The framework has given us a lot of agility and it’s fun to work with. Anyone who follows the blog has seen that we even participate whenever possible at Rails events to show our satisfaction.

So, what of the development we’ve done in Java?

Re-reading that post, it sounds like we’re developing in Java because there was no other choice – that if we’d had the necessary Ruby libraries we wouldn’t have any Java code and we’d be even happier. With the appearance of JRuby there are those who ask us if we’d not rather run the application in JRuby on Rails and therefore have access to the Java libraries that we need, eliminating our need for web services.

Without doubt, that decision was not just about frameworks but was also an application design choice.

The design choice: web services architecture

As we said, when we selected the framework, we also chose the architecture. We decided that we wanted to develop various specific applications other than one that encompassed everything, in the pure UNIX style.

The truth is that, looking back, we’re very happy to have opted for a Rails front end but we’re also very happy to have chosen a web services architecture. So, just like when we discussed the advantages of choosing Rails, now we want to share with you the advantages of using web services.

Another buzzword

This type of architecture is fashionable and even has it’s own buzzword: SOA (Service-Oriented Architecture). So you can now have your SOA application, done in Rails with a lot of AJAX.

If, on the contrary, you are like us and you are not motivated by buzzwords, read on

Quality

As we said earlier, the idea to design smaller and more specific applications that make up a larger application follows the UNIX philosophy.

If we stop and think about it, this is the philosophy that makes UNIX so powerful and one of the reasons why we like it so much. You have a load of specific programs: ls, grep, sed, awk… these programs do specific things but they do them very well.

Working with specific applications that have to resolve a concrete problem, we can concentrate much better on the problem at hand. You might think that to achieve task isolation it would be enough to develop libraries instead of applications – and you would be right. Having said that, developing distinct applications connected by web services allows us to have a totally language, framework and deployment-agnostic architecture. If, in the future, there are better tools in C++ or .NET for the validation of signatures, we can migrate just this application without impacting the rest of the system. Developing specific applications we can employ the best tools in each case.

In addition to the improved implementation quality, we have also discovered improvements at execution time – on one hand for scalability reasons which we’ll discuss in the next section, and on the other the flexibility to redeploy or deactivate a specific service without having to shut down the rest of the services.

Scalability

When we talk about scalability, we refer to scalability of technical resources as well as human resources. On the technical side, it’s very simple. At the start, you can have all the services on the same machine and if one becomes a bottleneck, you just move it to a dedicated machine. Additionally, if the service is share-nothing, you can deploy it on as many machines as you need to give a high level of service. This will be clear to anyone who works with Rails

On the human side, a service-based architecture allows us more room to scale our development, meaning we can move from managing a single larger team to assigning a smaller team per service. This way, as we grow and require more developers, it won’t be necessary to have a bigger and bigger team but rather a group of small, agile teams that are in charge of one or more services.

In future posts

In future posts we hope to talk in more detail about the our architecture, the services that compose it and what they are used for.
Bye for now!

• Ernesto Jiménez, who couldn’t attend last year because he was in Finland (although he still won the speed programming contest at the conference) will present the Tractis platform in his talk “Case study: A technical spotlight on Tractis” in which he will give an overview of some of the specific design details of Tractis.

Ernesto will appear again, joining the list of negonators that will give presentations that are not directly related to Tractis:

• David Calavera will talk about the tools that ruby makes available to interact with the atomPub protocol, how to test it’s implementation and an example of the use of the 11870 API.
• Juan Lupión will present Slingshot, the open source alternative for integrating web applications with the desktop using Ruby On Rails.
• Juanjo Bazán will encourage the attendees to contribute improvements to the Rails repository and will explain the necessary steps to add code to the project.
• Ernesto Jiménez will revise the common web security vulnerabilities and will comment on the tools available in Rails to avoid these types of vulnerabilities.

All the sessions look good and the difficulty will be choosing which to attend. For all of you who cannot go to the talks, they will be recorded on video and made publicly available including, of course, the keynote presentantion by Obie Fernández which will close the conference.

• User authentication via Digital Certificates.
• Automated sending of personalised contracts.

Now we want to talk about some of the things we have ready. However much documentation we write, the best way to understand the capabilities of the API is to see it in action so we’ve decided to create a fictitious company – “ACME” – whose web site (http://acme.tractis.com) will demonstrate everything you can do with the Tractis API.

ACME: Demo of sending personalised contracts to clients

The first example we’ve put on the ACME web site demonstrates the “Contract Management System”. The Tractis API allows you to use this system to automate the creating and sending of totally personalized contracts to your clients. As you’ll see in the demo, with the API you can:

• Personalize the subject and body of the email that the customer will receive
• Personalize the instructions that appear at the top of the contract. This is useful for explaining the steps to follow to the customer (“review the contract and, if you agree with it, press the ‘Sign’ button at the end of it”, ask for additional information, record delivery periods, etc.
• Select the template that will serve as the basis for the contract. You can choose from the example templates or log in and use the templates in your private library.
• Fill in the variables in the template that you’re going to use. Logically this option is only available if the template used includes variables. In this demo, all the contracts sent share the same variables (e.g. Buyer Name = “John Smith”). Of course, with the API, you can personalize the variables in each contract.

Details for “sellers”

Your clients are yours:

1. They don’t have to register with Tractis to sign a contract.
2. They will receive a personalized e-mail with the message sender, subject and body that you decide.
3. They will agree to contracts personalized with your corporate image (logo, colors, instructions).

Details for “techies”

We’re still expanding the API documentation but we can tell you a few things:

• Access: initially the API will be accessible via REST. In the future, we’ll also allow SOAP access.
• Format: The data format is XML. In the current demo, you can see a preview of the XML requests sent to Tractis. Shortly, you’ll be able to see the trace of API requests.

Work on the API continues…what do you need?

In Tractis we firmly believe that the business potential of the internet goes beyond promotion and communication. Now you can negotiate and sign contracts 100% online and with the necessary legal guarantees. The technology and legislation are available right now.

If you believe that your company could take advantage of these types of services, don’t hesitate – get in contact with us. We’ll be thrilled to hear your ideas for using the Internet and digital signatures to speed up and increase your business.

The back-end Tractis services are organized into three groups according to purpose: identity services, document management services and digital signature services.

Externally accessible services

1. Identity services:

• Identity Federation Server: Allows single sign-on to Tractis services. A typical use-case is where a customer of a Tractis organization uses multiple services but only has to identify themselves once (to the user organization).
• Identity and Attribute Authority: Allows the management, certification and verification of attributes of individuals and organizations
• Management: Allows definition of access control on different attributes, according to their nature.
• Certification: Allows connections to 3rd party attribute repositories and the presentation of challenges of the holders of an identity (example: authentication using personal certificates issued by a trusted authority).
• Verification: Allows the lookup of information stated by the user (phone number, address etc.).

2. Document management services:

• Contract Management System: Allows complete contract lifecycle management.
• Long-term Archive: Allows long-term storage of documents, guaranteeing their future reproducibility, integrity and authenticity.

3. Digital signature services:

• Semantic Validation Authority: Verifies the validity of electronically signed documents from a legal and technical point of view. Supports advanced digital signatures based on the AdES format.

The “Evidence Manager” acts above all these services. It stores and preserves evidence for future investigative processes. The evidence manager allows us to show evidence to 3rd parties with regarding the operations performed by the different services.

Internal-only services

As you can see from the diagram, all these services use a series of internal components to guarantees (integrity, durability etc.) all operations performed by the platform.

• Time Stamping Authority: Applies time stamps to electronic documents, permitting demonstration of document content at a given moment in time.
• Trusted Time Sources: Providers of Date/Time information synchronized through multiple channels (i.e. internet, phone…) with official sources of time such as the Real Observatorio de la Armada (Spanish Royal Navy Observatory) – official time in Spain.
• Attribute Repository: Allows storage of user attributes and roles (responsibility, membership of professional organizations…) and makes them available them to the applications that request for them.

Finally, Tractis integrates with Certification Authorities around the world.

Why use this functionality?

We are going to open up the functionality progressively. Initially, we’ll open parts of the “Identity and Attribute Authority” and the “Contract Management System”, which will allow:

1. Authenticating users via digital certificates (Spanish electronic ID card – DNIe – included), free of charge, from your website.
2. Automating the bulk sending of personalized contracts to your customers, asking for their digital signature.

All these services will be offered remotely by Tractis. You don’t need to develop, install, configure or maintain an infrastructure valued in millions of euros that is within reach of only the biggest banks. You only need a Tractis account and to integrate with the API.

Past

Anyone involved in the launch of web applications of an international vocation (i.e. should be available in various languages) will agree that the available options are depressing. The tools are rough, unusable and designed without a thought for the end user (the translator). The current solutions:

• All require translators to request help from programmers to edit files, upload them to the server or to manage the combination of the individual translations into the final version.
• Many are desktop applications that don’t allow online collaboration.
• Many don’t integrate with version control systems and those that do require advanced knowledge (conflicts, merges, updates).
• None is capable of responding to basic questions such as: ‘which text strings have been recently translated?’ or ‘which text strings do we need to translate for the next version?’.
• The management of processes such as assignment, verification and establishment of translation objectives is terrible.

The translator is a bottleneck for the release process and can only work properly when the translation process is performed after development. Slow. Disappointing.

As a result of the first Spanish Rails conference we announced the launch of a new initiative: “Found In Translation (FIT). FIT is an open source project that aims to develope an internationalization software for web applications that overcomes the limitations of current tools. The objective of FIT is to create a tool that makes translators and programmers happy: usable and that transparently supports the existing standard translation file formats.

In our case, managing the translations of Tractis in an efficient manner is critical to our day to day operations. But we’re not alone: habitamos, casabuscador, qype, xing, last.fm, vlex, mobuzztv… Many companies, mainly European, have the same problem. Additionally, in Spain and other countries, it’s important to support all the official languages, and not just when you develop for the public sector.

The majority solve “their” problem with proprietary, internal systems and the “state of the art” doesn’t advance. Without becoming “Infrastructure Software”, “translation” remains clearly an horizontal function – common to all projects but never at the center of the activity. It’s an ideal candidate for open software. It doesn’t make sense for each web application project to develop their own solution. We should join together and combine our efforts to design a solution that benefits everyone. In this spirit, we created a mailing list in December and Negonation appointed me to the project.

Present

Since then, there have been a few advances that I’d like to share with you:

• Codemart, Beluga Linguistics and Negonation have reached an agreement to promote FIT.
• We have an official FIT logo, courtesy of Belén Albeza.
• The mailing list now has 26 subscribers – programmers, designers and linguistics profesionals from around the world.
• We have assigned Rubén Lozano, web designer and Negonator to take charge of the design and usability of FIT.
• We have developed some initial code which I hope will serve as the basis for the future FIT (watch screencast).
• The code has been released under the Ruby license – the license used by the Ruby programming language – which is compatible with the GPL
• The project has been accepted in RubyForge. If you want to access the code and collaborate in its development, follow these instructions, register with RubyForge and send me an email at juanse.perez@negonation.com requesting access.

Future

We’re preparing the documentation to present FIT at the Google Summer of Code 2007. If Google approve our application and you are a student, you might want to sign up and win $4,500. Soon, we will launch a blog to speak about the project progress and we’re discussing some “killer” features such as contextual translation (the translator logs on to the application in “translation mode” and can translate text strings shown in the application by just clicking on them).

We hope that many other translation, programming and web service companies unite and collaborate in the development and publication of this initiative. Lets build a highly usable tool that recognises the objections of everyone and makes it easier to bring web applications to people around the world.

Update 8th April 2007: Have a look at the FIT Demo and the FIT Trac

Today we start a new series of posts in which the Negonation developers will talk of their experiences with Tractis. Their mailing list has been converted into a hive of activity with links, methodologies, focused discussions – valuable ideas that are worth sharing.

The focus of the posts is practical but the intention is not to comment on lines of code, but reflections on our constant search for efficiency in a decentralised and delocalised environment. We want to talk about what we truly believe will make a software development project succeed or fail and about what the majority of companies don’t focus their attention: agility, motivation, self-improving, barriers to communication, clarity in the objectives, application of generic methodologies to teams of unique individuals, programming decisions that impact on the strategy and the business.

And with the difficult task of starting off, we have Luismi Cavallé, one of the latest and keenest Negonators to sign up. Proof of this is the special mention that he received in the latest Glider prizes, despite being on the team a short time. We’ll leave you with him. If you like what you see, take a look at his blog “Putting it together” (RSS), full of “delicious” posts about the art of programming.

Shu Ha Ri is a Japanese term that describes the three stages of apprenticeship of a martial art.Shu means to maintain, protect, obey. In this first stage, the student rigidly follows the teachings of the master. The aim is to reproduce precisely the technique without worrying about the underlying theory. It is important not to mix styles or variants of the art at this point. This is the stage in which you establish the foundations for the rest of the apprenticeship.

Those of us who have practised a martial art will remember this first phase where the objective is, on the basis of repetition, correction and perseverance, to be able to perform the movements and techniques correctly.

Ha means separate, liberate, break. Once the technique has been memorized, the student may begin to question “why?”. In this phase, the student begins to understand the theoretical principles of the technique and starts to learn variants of the art from other masters. All this is integrated into the student’s knowledge and practice of the martial art.

Ri means to go further on, to transcend. In this stage, the student no longer is one since he doesn’t learn except for his own technique. The art becomes personal and he explores new focuses and variations on the techniques adapted to the circumstances.

Alistair Cockburn (signatory of the Agile Manifesto and creator of the Crystal Clear methodology), in his book Agile Software Development, introduces the concept of Shu Ha Ri to explain the learning of software development techniques and methodologies. For Cockburn, the agile methodologies with a name (Extreme Programming, Scrum, Crystal Clear) give a starting point, at level Shu as well as level Ha, so that each development team can reach their own Ri. Understanding that the best methodology is not to follow a methodology and that a successful development process is one that is not established.

At Tractis we understand this well. This is why we refactor continually – not just the code but also the methodology, the process, the manner in which we organise ourselves.

In many aspects, we’re probably at level Shu. We’ve chosen to be agile and chosen Rails as means of reaching our ambitious objectives. Therefore we are trying to learn, apply and memorize the agile techniques (TDD, Refactoring, Continuous Integration etc.) and the “Rails way”, following our ‘masters’.

This is going to require dedication and sweat, without doubt, but we need to do things very well at this stage because the challenges that confront us are going to take us in new directions. We’re constructing software in the post-agile, post-web2.0 era and we’ll only succeed if we have solid foundations.

And this is what we’re trying to do.

The conference was the perfect excuse for us all to meet up: David Calavera, Vidal Carro, Luismi Cavallé. Various collaborators that we’d never seen in person. On Saturday night (25th) we went out for tapas in La Latina together with some habitual reader of this blog . It was great to be together and put a face to many people that we only knew from e-mail, chats and phone/skype conversations. Various negonators participated as speakers and you can download their presentations here:

• Juan Lupión, Distributed Computing in Ruby on Rails
• Juanse Pérez Herrero, Internationalization, Rails y Gettext
• Juanjo Bazán, Rails for Java Programmers
• Manolo Santos, Design of the Tractis online negotiation platform

Ernesto Jímenez, veteran negonator, couldn’t attend because he’s studying the final year of his degree in Helsinki. But that didn’t stop him. Not content with winning the speed programming contest at the campus party this year, he also signed up for the speed programming contest at the conference….and won again. The result: Battleships in RoR (coded under the GPL license), 48 hours without sleep and the prize of a beautiful 80Gb iPod Negonation apart, the presentations on XML support in Rails (by Javier Rámirez of ASPgems), Systems Administration in La Coctelera and The Shaker (by Fernando García Samblas and Alvaro Ortíz of La Coctelera) and Testing in Ruby on Rails by Jean-Michel Garnier were very very good. We’ve talked for some time about Tests on the mailing lists and the presentation by Jean-Michel (the lower photo) in the end convinced us of the need to incorporate them into our development.

Unreserved congratulations to those who worked to make this event a reality. We should do it again.

One more thing…: Launch of Project FIT

We’ve saved the best ’till last. As announced by Juanse Pérez at the end of the internationalisation presentation, we want to start a new project that overcomes the problems currently faced when translating web applications. The translators complain that they need to learn unusable and different applications for each client. The designers want to eliminate the complex management of the translated files and automate the process as much as possible. David Heinemeier Hansson, creator of Rails, afirmed during the videoconference on the Saturday that ‘Internationalisation’ means different things for different people and, therefore he sees the solution as a plugin and not a core part of Rails. This is the right moment. We invite you to participate in a new project: FIT or “Found in Translation”, an open source tool that makes life easy for the designers of international applications and enables translation companies, vendors/integrators of software and start-ups/clients to standardize. We now have a mailing list (fit_project@googlegroups.com). Do we need anything else?

• Juanse Pérez (tractis-translation) will explain about the available tools and the state of the internationalization art in Rails. I highly recommend this if you are developing a web site in Rails that has to be available in various languages. Installation and configuration of Ruby-gettext, i18n, Pootle and several subjects to consider.
• Juanjo Bazán (tractis-setting) will help Java programmers who are interested in, or starting with, Rails. A crash course on the main differences in classes, methods, namespaces, etc. and the “Ruby way” on programming.
• Juan Lupión (tractis-people) will present a project together with JJ Merelo: a distributed processing architecture (ala seti@home) using a Rails application as the server. To prove the concept, they will describe how to implement and resolve a genetic algorithm.
• Manuel Santos (tractis-core) will talk about his experience in the development of Tractis. Architecture, components, platforms (SVN, Trac), deployment (Capistrano) and development decisions in the real world and with a distributed programmers’ group.

All the speeches, round tables and activities look good. There will be several contests and an install party where you will be helped to configure your equipment for working with Rails. David Heinemeier Hansson, creator of Ruby on Rails, is expected to participate by videoconference. Tickets cost €60 (€30 for students and €0 for active Negonation collaborators ) and they include food, coffee and a commemorating T-shirt, as well as discounts for book purchases and hosting. The Rails introductory presentations are free. It’s an event by and for the community. Nobody obtains a profit. For those who can’t attend and for Spanish-speakers from the other side of the pond, all the event’s conferences are in the evening and will be streamed.

Don’t miss it. In the meantime, to take the edge off your appetite…