Ruby on Rails Enterprise Application Development: Plan, Program, Extend

5 (1 reviews total)
By Elliot Smith , Rob Nichols
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Introduction

About this book


All businesses have processes that can be automated via computer applications, thereby reducing costs and simplifying everyday operations. This book demonstrates that a modern web application framework makes an ideal platform for such applications. It shows how the attributes that make the Rails framework so successful for Internet applications also provide great benefit within a business intranet. These attributes include easy roll-out and update of applications, centralized processing and data handling, simple maintenance, straightforward code development, and scalability.

Ruby on Rails is an open-source web application framework ideally suited to building business applications, accelerating and simplifying the creation of database-driven websites. Often shortened to Rails or RoR, it provides a stack of tools to rapidly build web applications based on the Model-View-Controller design pattern.

This book covers topics such as installing Ruby, Rubygems, and Rails on Windows, Linux, and Mac OS X; choosing and installing a database; installing an IDE for Rails development; setting up a Subversion repository to manage your code; creating a new Rails application; understanding Rails models; understanding controllers and views; improving user interfaces with Ajax; using Rails plugins to manage file uploads; using Capistrano to manage application deployment; techniques for scaling Rails applications, such as caching and using Apache to proxy through to the Mongrel server. The example application is straightforward to develop, easy to roll out, and simple to maintain.

Publication date:
October 2007
Publisher
Packt
Pages
528
ISBN
9781847190857

 

Chapter 1. Introduction

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.

 

Why this Book?


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.

Note

Rails is the ideal framework to develop small business applications.

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.

 

Why Develop?


Traditionally, there are two ways to implement an IT solution in a business process.

  1. Buy an off-the-shelf solution.

  2. 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.

 

Why a Client/Server based Web Application?


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.

Extra functionality can be added to the web pages presented to the user, by the use of JavaScript (which allows logical operations to be carried out at the browser), XML (as either an alternative to HTML or as part of custom data transfer operations), and CSS (Cascading Style Sheets provide a way of improving the appearance of web pages without significantly increasing the complexity of the HTML code. In essence, the best way to convert drab web pages into attractive media experiences). These three systems are combined into a framework called AJAX, which is used to greatly enhance the user experience. There is a tradeoff between the addition of this extra functionality, and the additional complication that results, but with care the tradeoff is manageable, and resulting systems are still simpler than alternative solutions.

Therefore, a client/server based web application provides the ideal platform to store, manipulate, and present data throughout a dispersed business environment.

 

But why Ruby on Rails?


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?

Rails Handles Menial Tasks

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.

Clear Code

Underlying everything is Ruby. Ruby is an elegant language with syntax that is easy to understand and use.

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: this_day and next_week are Time objects; seconds_between is a Float [decimal number]; seconds_in_day and days_between are Fixnums [an integer type]; and the final output text is a String.

  • In creating 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 .to_i is doing).

  • 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.

Text Based File

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.

Open Source

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.

Plentiful Documentation

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.

Built-in Safe Test Environment

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.

 

Ruby on Rails in Detail


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.

 

Summary


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.

About the Authors

  • Elliot Smith

    Elliot Smith has worked in IT since 1996, and currently works at Talis, as a software developer working on library systems. Prior to that, he worked at OpenAdvantage (an open-source solutions center) as a business analyst; as a learning technologist and web developer at the University of Birmingham, England; and as a technical writer for Armada Computer Publications. He has an M.Sc. in Artificial Intelligence and a Ph.D. in Computer Science from the University of Birmingham. His personal website is http://townx.org/.

    He thanks Nicola, his wife, for giving him the time and space to write a book; Madeleine, his daughter, for keeping him sane while doing it; and Rob Nichols for giving him the opportunity in the first place.

    Browse publications by this author
  • Rob Nichols

    Rob Nichols first started using computers during his apprenticeship at Rolls-Royce in the early 1980s. At 23 he decided to change direction and started a degree in Geology and Geography at Cardiff University. By 1995 he had gained a Ph.D. from Bristol University, studying the behavior of quicksand. During his time in Bristol and in a subsequent lectureship at Leeds University, he started using the fledgling Internet to communicate with co-workers, gather information, and present Geological information in the form of his first web pages. Following his return to Britain from a lectureship in U.S.P. Fiji, Rob found himself without another lectureship position to go on to. So, changing direction again, he started working for a U.K. computer manufacturer, where he rose to the position of Engineering Manager, managing a team of seventy maintenance and networking engineers, and support staff. Following the collapse of the U.K. computer market in 2002 he moved on to the role of IT manager for a small business providing products and services to the water industry. In this role, Rob has had great success developing intranet-based business applications that streamline business processes, save time, and increase efficiency. In so doing he has transformed the IT department from a business cost to a profit generator by reducing costs and thereby increasing margins. When not working with computers, Rob and his wife reside happily in a small Midlands town in England, where he writes scripts for the local movie-makers club, and photographs the local wildlife.

    For Diane, for putting up with my disappearances into the study to “work on the book”.

    Browse publications by this author

Latest Reviews

(1 reviews total)
Excellent