Catálogo de publicaciones - libros

This was certainly a large project, wasn’t it? It’s the kind of project that we could really fill up a whole book with on its own, as we moved into other areas of the application such as supporting reviews, video uploads, and an article review/approval system—and this is just the backend administration system. You can imagine the fun we could have if we roll Rails out to the main site and explore the challenges of deploying a Rails application that handles a pretty fair amount of traffic onto a typical single-server scenario (handling issues such as fine-tuning our database queries and indexes, implementing caching, and of course, monitoring the performance of our application).

In March of 2007, 37signals released their latest product—an online contact relationship manager by the name of Highrise. Highrise is an absolutely fantastic marriage of Rails development and product design that brings a much simpler and relevant paradigm to the idea of relationship management. It brings the focus back on the people—the contacts that we have with them and the things that we need to do to keep those relationships moving forward.

In the last chapter, we took a birds-eye view of Highrise: what it is, what it was designed for, and some of the common actions that we need to understand to use the application. With that simple understanding of how Highrise works, its time for us to begin exploring the fun world of integrating Highrise’s data into our own applications. Highrise was created with the goal that the interface would also be the API, so it falls right in line with the RESTful design patterns we’ve explored in previous projects.

In the last chapter, we took some giant steps towards our final application by building out some of the models that we can use to connect to Highrise via Active Resource. Now, let’s finish things up by putting together a little application that will utilize the data from our Highrise account for all of its data.

This project was a fun (albeit at times frustrating) one to create. Rails 2.0 is going to have a significant number of changes to some of the common ways that we do things within the framework. While these changes might require a shift in the way that we develop our applications, I have to say that most of these changes are going to be for the best. It is a perfectly acceptable thing to break backward compatibility to keep the framework fresh and relevant and drop that “freshman fifteen.”