Ruby on Rails Web Mashup Projects

Ruby is a dynamic, object-oriented programming language that is highly suitable for integrating various pieces of data and software together:

Ruby on Rails is an open-source full stack web application framework built on Ruby. Ruby on Rails follows two basic guiding principles—Convention over Configuration and Don't Repeat Yourself (DRY).

Convention over Configuration is a programming design that favors following a certain set of programming conventions instead of configuring an application framework. Certain commonly used configurations (by convention and not by rule) are pre-set and the framework just works if you follow those conventions. For example in Ruby on Rails, the convention states that a controller for a model object Book will be called BookController and all view pages relating to that controller will be kept in a folder called book.

DRY is a principle that focuses on reducing information duplication by keeping any piece of knowledge in a system in only one place. For example, in ActiveRecord (a major component of Ruby on Rails), schema information doesn't need to be duplicated in complex XML configuration files but is derived from the database schema itself. If the schema changes, the model changes accordingly, without the need to make changes in other parts of the system.

All this translates into a highly productive development framework in which web applications can be developed, deployed, and maintained easily. This framework, coupled with the fact that it uses Ruby, makes it an excellent platform for developing web mashups.

A note of caution here—this book is written with Rails 1.2.x in mind and the projects and examples in this book follows this version. There is no significant change in the projects though, if you choose to use Rails 2.x instead. As of writing, Rails does not work with Ruby 1.9. If you're a complete beginner with Ruby and Ruby on Rails I would recommend you flip through the books mentioned in the information box opposite before plunging into this one.

Web mashups are a new breed of web applications (Wikipedia defines a mashup as a web application hybrid). While most prominent web mashups use publicly available APIs like Google Maps, Amazon ECS, and so on, this is not the only way to do mashups. Significant innovation can be achieved with further aggregation and hybridization of code and data from publicly available APIs, with private data as well as private applications.

The idea behind web mashups is creativity and innovation in new data and services, not just aggregation of existing ones, which most of the older technologies focus on. In comparison with portals, web mashups differ because portals aggregate and dish out content and applications in discrete packages, whereas mashups integrate the data and services together and serve them out as a single application.

An example of this is that while a portal will happily display a map of your current location, your address book, and today's astrology readings in 3 different portlet windows, a mashup will display the astrology readings of 10 of your friends who are closest to you, in an online map occupying the whole browser space.

This integrated and mashed up approach to programming can provide much insight into the way we program applications.

There are an increasing number of applications on the Internet providing an amazing variety of data and services as APIs or data sets for mashups. A quick check on the Programmable Web (http://www.programmableweb.com), which hosts a directory listing mashup APIs as well as mashup applications, shows up service APIs ranging from social networks to sending snail mail through the Internet. You can also get tons of data from hotel bookings to government spending data.

With the wealth of these external data sources, you can build amazing new applications that bring these data and services into meaningful new services. While mashups are not the only way to consume large sets of external sources of data and services, they are probably the most creative. Buzzword aside, anytime you take data or services from another application, you're already doing a mashup.

If you have an existing application already, web mashups can allow you to innovate and create new value to your application by grafting new functionality through the external sources. For example, if you run a reservation application, you can alert your user through text messages from an SMS mashup API, add the date of reservation into his or her Google Calendar account through Google Calendar APIs, and show the location of the venue on Yahoo Maps.

Using mashups you can build new functions much faster and save on the development and maintenance effort. For example, if you are the developer of a facilities reservation system you don't want to spend time mastering the development of a text message sending component, which you normally would have to do if you wanted to have that feature.

Besides development, you can also reduce the maintenance of a feature that is outside your core domain. While this is often critical for startups, it is equally important for larger organizations that want to focus on their core domain. In the example given earlier, you don't want to spend time developing and maintaining a text-messaging component—you'll want to leave it to the text-messaging experts to do their job.

Besides saving on effort, instead of doing it yourself—you might want to leverage on common and popular applications to do the work for you. Effort aside, such applications already have a widespread user base that is familiar with the functionality. You can tap these users to extend your own user base and use the features of these applications to give an easily recognizable interface for your users.

For example, if you want online calendaring features, you wouldn't want to redevelop another Google Calendar. Instead, you would mash up Google Calendar APIs into your application and use their interface to provide something more familiar to your users.

One of the most common complaints you will encounter as you develop web mashups is that you are highly, if not totally, dependent of the reliability of the mashup APIs you use. The two critical aspects of a web application—availability and response time—are not under your control, especially from sources that are provided freely to you.

Unfortunately at this point in time there is no viable way of resolving this completely. The only way of ensuring full availability and response time that meets your own requirements is to not have external dependencies at all. This is not possible of course, because web mashups are all about using external data and services.

However there are a number of ways to work around this issue:

This issue is generally more difficult to accept in mashup applications because should core functionality of the system be compromised, it is difficult to proceed. In any case, catering and planning for backup or alternatives in case of an external source breakdown is a must for all mashups if you intend to go into production.

This problem is related to the first. Besides being dependent on the external APIs for functionality, the larger issue could be that the provider of the external API changes its service partially or completely. This could range from the provider being shut down altogether, to the provider changing its business model or commercial terms and it becoming no longer viable to continue with that provider anymore. Even simpler issues like changes in API parameters and accessibility can potentially cause service outage.

For example, a free service could start to charge a fee (or increase its existing fees) and you can no longer afford to include it in your mashup. Sometimes the service itself is no longer sustainable because of licensing issues or the company behind the service abandons its business model in pursuit of another revenue source.

This problem is more acute in areas where the provider is the only one around. Again, planning for alternatives is important if you intend to go into production because this problem can potentially kill your mashup altogether. Some possible defenses against this risk:

Another problem might not be related to reliability or availability at all. If your mashup becomes commercially interesting, it is sometimes quite easy for your external source API provider to extend their existing functionality to include yours and you to be left with an 800-pound gorilla in your backyard. A related risk is for your users to decide that if they are already using the external provider anyway, they might as well switch over to it completely and bypass your mashup altogether.

Again both risks are more likely for mashup applications since a mashup application's main value is in the creative combination of the external sources. Mashup plugins are less likely to encounter this because your main application already has functionality that should be different from external APIs (or else you might want to ask yourself why you're doing it!).

The main defense against such risks is to continually innovate and possibly include more APIs. A mashup application that combines two APIs creatively is more likely to be made irrelevant than a mashup application that combines three, four, five or more APIs and uses them in a creative way that none of your external providers can match by themselves. Remember that your main advantage in creating a mashup application is that you are able to be the best of breed by combining the best aspects and features of various providers to create a unique service for your users.

At the end of the day, although there are significant risks in creating web mashups, there are always ways of mitigating them. Ultimately it's up to you to decide if the risks are worth taking compared to the services you're providing in your mashup.

This section gives a brief summary of the mashup's functions and objectives. This is normally just a paragraph or two.

What follows after the summary of objectives is a description of the domain background of the mashup's functions. For example, in Chapter 5 we will be discussing how we can create a job board mashup. The domain background section of the chapter gives a simple introduction to job boards, what they are and what they do.

This section provides an overview of the requirements of the mashup we will be creating in the chapter. It lists the requirements and objectives to meet in building the project in the chapter.

This section describes how we will be building the project, the rationale behind the design, and how we approach the creation of the mashup.

This is a major section in the chapter, and it describes the list of mashup APIs that we will be using to create the mashup. In the first few chapters we will also describe how we register for the mashup APIs at the external sources. Later chapters will dispense with this. All of the APIs are either freely available or have trial accounts where you have limited access to the APIs.

This section also describes the various libraries we will be using to build the mashups. This includes open-source libraries as well as libraries included in the standard Ruby distribution. Whenever necessary there will be some discussion on the theory behind the libraries and how they work.

This section is the bulk of the chapter and goes through the step-by-step creation of the project. All necessary code is shown and major steps are described in detail. Each major step is explained in its own sub-section. In some cases additional information is given to explain why certain aspects of the code are written that way.

This section starts with the creation of a Ruby on Rails project and ends with a final completion of the whole project. Most projects are coded in a straightforward manner without much optimization. In some cases I will even go some way out to code the project in a way that a more advanced Rubyist might find not following the 'Ruby Way'. This is intentional as the purpose of the book is to focus on web mashups and not on Ruby or Ruby on Rails, and the code should normally be very readable by any programmer, even those less familiar with Ruby.