This book describes how the web development framework, Ruby on Rails, can be used to create small applications and, in particular, applications that form the key components within business solutions. It uses the example of a customer contact application to work through the process of solution creation; also providing a practical description of the steps required. This book not only covers the coding techniques, but also explains how to build a development environment, configure host servers, and develop the application over and above its original scope.
One could ask when picking up this book: "Why another book on Rails?". In the last couple of years there have been a number of excellent books published, describing this new web development framework. There are books that introduce the framework and walk people through developing their first Rails applications. Other books describe how to add specific functionality to existing applications. References for the language and syntax also exist. So why do we need another book?
There are two answers to that question. The first is that there is a lack of material in the middle ground. That is, there is a wealth of material on how to get started with Rails, both in print and on the Internet. Then there are the latest books that address the needs of the experienced developer, who requires information to supplement the online source code documentation. What is less obvious is where a developer finds the information to move them from the beginner who has built his first application, to the experienced Rails aficionado who can get the most from the detailed advanced literature.
This book is aimed at developers who have just started out with Rails, have worked through the basic tutorials, and built their first applications. These developers, who feel pleased with the achievement of building their first Rails application, now ask the question, "What do I do next?"
However, there is another target audience; developers who are looking for more than just another book describing a 'web development tool'. These are the developers who recognize and want to exploit the unique attributes of Rails that make it the ideal tool to address a vital business requirement.
This book, therefore, is also aimed at developers who want to find out how to rapidly build small, easily deployable, easily supportable, business applications. They come to this book not because they necessarily want to write Rails applications, but because Rails is the ideal framework to build their business applications.
Buy an off-the-shelf solution.
Pay a developer to build a bespoke solution.
For many problems these are still the best options. However, when dealing with specific, small, everyday problems, both have drawbacks.
Off-the-shelf solutions tend to be plentiful when trying to address the usual run-of-the-mill problems. However, when it comes to overcoming a small, specialized problem it can be difficult to find an appropriate off-the-shelf solution. They are often designed to work for everyone, but do not seem to work for you. The result is change in the working procedures to fit the application, instead of being able to find the solution that neatly slots into your existing business process.
Another issue with buying an off-the-shelf solution to address every small problem, is a proliferation of applications that do not communicate with one another. Often, data that may be useful elsewhere in the business is locked up and inaccessible within a number of independent applications.
Bringing in a specialist developer to create an application also brings in its own problems, the most obvious of which is cost. For major business developments, this cost is justifiable, but for many small problems it is not. Another problem is supporting and developing the application after it has been rolled out. Often further development requires bringing the developer back in at additional cost or finding an alternative developer, who will spend much of their time working out how the bespoke application works. As for fixing faultsâcustom applications tend to have custom faults. The knowledge bases available for off-the-shelf applications will not exist for your unique application.
If you can develop the application yourself, with a framework that is easy to use and encourages you to follow good practice, you can overcome these problems. You will be able to rapidly develop and deploy solutions that are tailor-made to address the current issues. Working to a clear, well defined framework, will make it easier to write a code that you can return to six months later and understand. This makes support and future development easier. As the development staff used is in-house, costs will tend to be lower, and it will be more likely that the developer will be available to fix problems.
The common response to the problem of gathering, tracking, or manipulating data within an active business is to use spreadsheets. These bring their own problems, particularly apparent when one tries to share the resulting files with multiple users spread around the company. Trying to control data change and user updates is difficult. The usual result is multiple copies of files spread about the company, with some not being the same as others.
Attempts to manage these separate copies tend to add complication to the spreadsheets, making them more likely to fail and more difficult to support. For example, you might add a macro to automate a process within a spreadsheet, only to find that the macro does not run on all the computers because of a missing dependent file.
The answer is to centralize the data and then distribute tools that allow users to view, manipulate, add, and report on the data. In networking terminology, the central resource is the server, and the distributed end-user interface, the client.
The server part of the solution is a database: a central data storage system. In many ways, this part is easy. There are many database systems available, from personal desktop databases like Access and Open Office's "Base", to large corporate systems such as Oracle and Microsoft's SQL server. Many such as MySQL, PostgreSQL, and SQLite sit in the middle ground, providing excellent low cost database solutions for most everyday requirements, and are particularly suited to web applications. They are easy to find, and many are easy to install and use. Effective solutions can be created with the minimum of customization.
The client part is more problematic: provide a user with an input and output tool that is available wherever the information is required within the business. The output from the system needs to be tailored to the user's requirements, if they are to use the data most efficiently. The input must be controlled to maintain the quality and integrity of the data. "Rubbish in, rubbish out", is a clichÃ©, but a useful one that highlights the fact that a data system is only as good as the data it holds. Without input control, a database can rapidly lose its value as it gets filled with data that cannot be searched nor compared easily. For example, it is surprising to see that the problems can be caused by entering the alphabetic character "o" where a zero should be added.
Most databases have administration interfaces that afford a user the ability to retrieve and input data, but by their nature they do so in an uncontrolled manner that is unsuitable for most end-user requirements. Instead a user interface is required.
The control of input and output is likely to be unique to the business requirement, and therefore, this element usually requires the most customization. This raises a problem that on first appearance may not seem to be too important, but on closer inspection has a fundamental effect on the performance and stability of the resulting application. The server part of the system will be located on a small number of easily controlled servers. The distributed client part will be spread around the business' desktop computers.
In many businesses (especially smaller businesses), desktop computers are often varied, with new computers added as they are needed. There is often a wide range of end-user computing hardware in place throughout a business. Servers, on the other hand tend to be small in number and are brought in to address a limited number of requirements.
Therefore, the straightforward server application (the database) is being held on the most easily controlled and defined area of the network; the server. The complicated client user interface is hosted on the most diverse part of the network; users' computers. So there is a problem in that the part of the system that needs most customization, and therefore is most likely to require maintenance, is located on the most diverse part of the network. This is a recipe for failure.
Deploying the client side of the system via a web service overcomes this problem. With a web service, the client application is split between a central web server, and a distributed web interface (the users' web browser). The two are connected over the network via a well-defined standard based protocol (HTTP). The majority of computation and logical operations are carried out at the web server. The user's web browser is used to display information and provide simple forms for user input.
In their simplest form, both the information display and input forms are presented via standard languages (HTML or XHTML). This reliance on simple defined open standards means that the work of the user's web browser is kept to a minimum, with most of the complicated work being carried out at the web server.
The result is that the least controlled part of the network (end user workstations) now hosts the simplest part of the system (receiving and displaying the HTML information). The more complicated parts of the system resides on the most easily controlled parts of the network: the web and database servers.
Therefore, a client/server based web application provides the ideal platform to store, manipulate, and present data throughout a dispersed business environment.
There are a number of alternative programming and scripting frameworks that can provide a web application to present data stored in a central database. So why use Ruby on Rails rather than JSP, ASP.Net, or PHP?
An underlying principle of Ruby on Rails is that of convention over configuration. Basically, this means that the designers of the framework have broken the workings of a web application into its core components. Conventions have allowed the core components to be standardized, and thereby access to them is greatly simplified.
For example, if you want to save data comprising details of a list of bags, the Rails convention is to save the list in a database table called
bags. The convention then prescribes that each line of data can be represented by an object that is the singular of the table name. So if our table is
bags, the object that can hold data from the tables is a
Bag object. Fields in the table are automatically converted to properties of the object. So if there is a
color field, the object will have this property; that is,
bag.color. All you need is to create the database schema, define the database connection in a single configuration file, and your application will be able to create your
bags table and use the data in the table as
Bag objects. Saving a new bag to the database will be as simple as:
next_bag = Bag.new next_bag.color = "Black" next_bag.save
In three lines you've created a
Bag object, defined the color as black, and saved it to the database. Thanks to the Rails conventions, the system knows automatically to save the data into a table called
bags, and to enter the text
Black into the
color field. Programmatically, you do not have to open the connection to the database, define the database command that will input the data for you, and close the database connection; all of that is taken care of, for you.
By keeping to the conventions, the application developer is able to concentrate on the logic of an application and is freed from having to worry about the underlying nuts and bolts. So rather than wasting time repeating the code required for all the web applications, the developer can devote most of his time to work on the logic that makes the new application different from the rest, and address the problem at hand.
With the use of convention, everyday tasks such as page pagination, data validation, and search ahead AJAX tools, that can take tens of lines of code to write in other frameworks, can be added in two or three lines of code.
The best way to demonstrate this is with an example:
this_day = Time.now next_week = 1.week.from_now seconds_between = next_week - this_day seconds_in_day = 24 * 60 * 60 days_between = (seconds_between / seconds_in_day).to_i print "There are " + days_between.to_s + " days between today and the day next week"
The code creates two times a week apart, and returns a short report describing the number of days between the two. It appears very simple, but in fact, there is a lot of work being done by Ruby:
First off, it has created five named objects. It was able to create these objects on the fly without the programmer having to pre-define them.
Ruby has created objects of four different classes:
next_weekare Time objects;
seconds_betweenis a Float [decimal number];
days_betweenare Fixnums [an integer type]; and the final output text is a String.
days_between, Ruby compared two different types of objects, worked out the required class type to store the result (a Float), and then allowed that object to be converted to a Fixnum Integer, thereby discarding the unwanted decimal content (that is what the
When printing, Ruby has converted an Integer to a String (the .to_s tells Ruby to do the conversion) and combined it with two strings to create a new String object. The new object is then output to the console.
This ease of use means that the code is easy to write, but perhaps (more importantly) it is easy to read. It means that you can easily understand code you wrote a year ago, and another developer can read your code, modify it, or fix bugs.
The other aspect of Ruby that plays an important role in defining the coding used in Rails, is that it is an Object Orientated Programming (OOP) language. Without going into details, the consequence is that sections of code are separated into discrete blocks each with well defined inputs and outputs. This helps to prevent spaghetti code with code pathways being difficult to follow. This does not mean that it is impossible to write gobbledygook in Ruby, but rather the structure of Ruby encourages the programmer to write well formed code. Well formed code is easy to read, understand, and modify. The creation of well formed code is the object of every competent developer.
Ruby on Rails applications are built using three types of text files: Ruby code files
(.rb), HTML templates (typically
rhtml files, but can also be
rxml), and YAML configuration files. Being text files, they are easy to edit, move, deploy, and back up. No complicated development environment is required. Code does not require compiling before use. You can create these files in Notepad on a Windows system, edit them in Textmate on a Mac, and then deploy them on a Linux server, should you so desire.
Typically, open source software is considered a low cost option, though there is some argument as to the on-going support costs. Certainly open source solutions are not expensive and tend to be of good value. However, while the cost aspect is attractive, there are other features of open source software that have more compelling benefits to a business application developer.
Open access to source code: This allows you to read the underlying coding to gain better understanding of how the system: works, thereby making it easier to optimize your solution and more easily extend and customize the functionality. With Ruby on Rails, this is even easier as much of the underlying framework code is written in Ruby itself.
No vendor locks in: There are no hidden costs such as extra charges for upgrades and bug fixes. Your choice of software solution is not reliant on the status and expected longevity of the vendor. However, you are reliant on the life of the open source project. If the community moves onto something else, the project development can dry up. However, even in this case, the code is still available and there is nothing to stop you further developing it. If a vendor goes out of business, the code usually disappears too.
Written by and for the people using the software: Open Source applications are written by the people who use the software. OK, not all the people who use it, but a wide group of different users. This means that the resulting applications work the way a lot of people who use them, want them to work. They do not work the way a corporation has decided they should work and more importantly they do not require you to work the way some faceless corporate entity dictates, to get the best out of the application. This is one of the key reasons why open source software is so often user friendly and why so many people find using open source applications such a liberating experience.
As already mentioned, there is a rapid increase in literature base available for both Ruby and Rails. Online resources are plentiful too. For example, the site
http://api.rubyonrails.com lists the frameworks, classes, and methods used by Ruby on Rails, allowing a developer to find the classes and methods they need, and dig into the underlying code to see how they work.
Being open source, the manuals are also written by the people who use the system. Too many manuals for commercial software seem more to be a list of functions, rather than a guide on how to use those functions. Good examples of these are instructions on how to install software. Help systems written by developers tend to skimp on this area, as the developers do not install very often and tend to install in a fairly limited environment. End users on the other hand have a wide range of installation issues. As users tend to write open source documentation, the resulting manuals often have the solutions to a range of installation issues. Such is the case for Ruby on Rails with there being guides and assistance to installing in a range of environments.
The test environment is built into the Rails framework, can be configured to populate a test database, and then run test procedures on that data, reporting back on their success. This means that you can safely test an application without adding live data to it, whether at the creation stage, while modifying, or further developing a production application, and during bug fixing. These tests are stored with the application code and therefore can be used to test the application after moving code to a new environment.
The test system encourages a developer to create test procedures early in the development process, and use the resulting test code throughout the life of the application. To detect system malfunction, test systems are used to help developers identify when the code they have created does not quite work the way they expect it to work.
The integrated test system can be used to ensure that applications are tested effectively and often.
Often when developing applications, the most difficult part is not creating the application, but getting it to work with other systems. This can also be the case with Ruby on Rails, particularly during the early stages of development.
In the early years of Rails, it was a common experience for new developers to be creating useful Rails code within hours of their first introduction to the framework. Then, it would take them days of research, head scratching, and many reconfigurations to get their chosen web server to work well with their new Rails application. Getting the connection to work between the Rails application and the web server was often more difficult than writing the Rails code. Fortunately, the web server connection headaches are a thing of the past, but this example illustrates that a guide, which simply described how to write Rails code would leave a developer with some difficult problems to solve before they could roll out a complete solution. Therefore, some effort is made here not only to describe how to create a Rails application, but also how to get it to work with the operating system that will host it and the services that will interact with it.
There are a number of tools that aid the developer to both generate and maintain a good development environment. For example, an integrated development environment (IDE) can make writing and working with code easier. Version control systems provide many useful tools for a developer; especially if the developer works in a team. This book is not a guide to these tools, but does describe how to configure the tools and the Rails environment so that they work together.
This book is aimed at developers who are new to Ruby on Rails, but have some familiarity with the framework and who want to move on from the basic tutorials. In particular, the book is aimed at those who wish to use the unique attributes of Rails to develop and roll out small applications. These applications will be straightforward to develop, easy to roll out, and simple to maintain. The developer will also be provided with guidance in creating a development environment where code can be created, stored, and shared easily.