1. Use filters
In order to remove duplicate code within the controller is good practice to use the filters to perform tasks that are common to most if not to all methods.
A classic case in which you use filters is user authentication.
Another example may be a function that makes the log of user activity.
I show here a very simple example for demonstration purposes only

We have defined our function add_log that saves data request in a log on db.
Now in our controller we will do something like this:

The PostController can be optimized using a before_filter in the following way

Then if we want the calls to some methods (eg show and index) can not be traced we can simply define the filter as follows:

Obviously the use of filters should be done in a careful way because excessive use of before_filter or after_filter for operations not so general can make the code less immediate to understand.

2. Organize helpers by functionality
The second technique that I introduce today is a better system (in my opinion) to organize helper files.

Rails typically generates an helper file for each controller. So it’s easy that in a short time you have a large number of helpers and often you use only a few of them.
For example:

And in the ApplicationController:

A system I find very convenient is rather to organize helpers for functionality, removing all unnecessary and empty files.

In the ApplicationController you not need to change anything. As before it loads all the helpers in the helpers folder. The advantage of this solution is to have fewer helper files and know immediately where to enter or search for a method when you have to add or change it.

Share on:

Related Post

• Rails Best Practices: introductionRails Best Practices: introduzione
• Rails Best Practices 5: Optimize MigrationRails Best Practices 5: Ottimizzare le Migration
• Rails Best Practices 4: Put method in the right modelRails Best Practices 4: Scrivere i metodi nel model corretto
• Rails Best Practices 3: Increase Controller’s readabilityRails Best Practices 3: Aumentare la leggibilità dei controller
• Rails Best Practices 2: Move logic to modelRails Best Practices 2: Spostare la logica nel model

For examples, we are working on a Django 1.1 project and and we need to start a new one with the latest version of the framework.

The best solution is to keep the various environments separate, in order to ensure that each project accesses only the libraries which it depends.

Python offers us virtualenv, a tool to create multiple isolated environments. Each environment is completely independent from the others and from the installed packages in system’s site-packages folder.

Let’s then see how to create a virtualenv and install the latest version of Django (today 1.2.1).

1- Install python-setuptools

The first thing to do is to install python-setuptools in order to have access to the command easy_install and to easly download packages. Alternatively, you can get the same results using the package pip.

Let us open a console and type the following commands:

2- Install virtualenv

The second step is to install the package virtualenv using easy_install:

3- Create the virtual environment

Once installed the package virtualenv we will need to create a space to host multiple environments. In my case, I’ve chose to create a directory in my home rather than in another writable folder in the filesystem.

Now we create the real virtualenv, called “Django-1.2-env. Note the argument added to the command virtualenv, —no-site-packages: so our virtual environment will have only a minimal set of libraries in his site-packages folder. We also note that all next commands will not need access as super user via sudo.

4- Download Django in /tmp

Open a new console and download the tarball with the latest version of the framework Django. For simplicity, I’ve downloaded the package to /tmp.

5- Installing Django in virtualenv

At this point, unpack Django and activate the virtualenv (via the command “source virtualenvdir/bin/activate”). Once activated virtualenv, we’ll find his name in the shell: (django-1.2-env)stefano@stefano-laptop

We verify here that Django is installed properly in the virtual site-packages:

6- Create a new project

At this point, we can create a new project using the command django-admin.py as required by the framework.

In conclusion, we can say that virtualenv is an excellent solution to create environments fully independent and designed to accommodate each individual project. In this way, we avoid conflicts of libraries and have the opportunity to try new configurations without creating problems for other applications.

Share on:

Random Posts

• System Information application for Nokia S60v5 phonesApplicazione System Information per telefoni Nokia S60v5
• Rails Best Practices 3: Increase Controller’s readabilityRails Best Practices 3: Aumentare la leggibilità dei controller
• Add current_user to Cucumber step definitionsAccedere a current_user negli step definitions di Cucumber
• New ProjectsNuovi progetti
• Connect a Dataset instantiaded by code to a CrystalReport reporting toolConnettere un Dataset istanziato da codice al tool di reportistica CrystalReport

This is a tipically migration that will be generated by rails after execution of commands like generate Model or generate Scaffold.
Now, let’s add indexes for the foreign keys and the sort fields.

Indexes definition is important for performance.
A table indexed increase the performance of SQL queries.
My advice therefore is: write indexes!
There are also some plugins that help to identify the fields to index.
By doing a quick search on github you can find different, I will point out just a few:

• http://github.com/eladmeidar/rails_indexes
• http://github.com/mlomnicki/automatic_foreign_key
• http://github.com/samdanavia/ambitious_query_indexer

2. Write data seed
Since version 2.3.4 Rails introduced the concept of seed.
In fact the idea was also present in earlier versions, but starting from release 2.3.4 was created a separate file and also an appropriate command to run the seed (ie the population) of data.
When you start to develop web applications with Ruby on Rails, happen often to write migrations that contains both instructions for creating tables and those for populate the database with default values.
A migration of this type is shown in the following example:

A migration written in this way will run without error but it is always advisable to keep separate the structure of the db from data. This in order to repopulate the database with test data rather than real data as needed without having to recreate it each time.
We see below how to write the file migration and seed file to separate the data from the schema.
Migration

seeds.rb

Now after you create the database you will simply run the command rake db:seed to populate it.

Use the seed file is also useful to populate the database with large amounts of data generated at random or with specific data to simulate specific conditions.
For this purpose there are many plugins for generating pseudo-random data.
We list the ones I use most:

• Faker: http://faker.rubyforge.org/
• Populator: http://github.com/ryanb/populator
• Random Data: http://random-data.rubyforge.org/

I close this post about migrations with a sample seed file that fill the database with 5 company pseudo-random generated by using the three plugins listed above:

Share on:

Related Post

• Rails Best Practices 6: Filters and helpers fileRails Best Practices 6: Filtri e file helper
• Rails Best Practices: introductionRails Best Practices: introduzione
• Partial Validation in RailsValidazione Parziale in Rails
• How to model a custom search form in RailsCome modellare una form di ricerca usando Rails
• Rails Best Practices 4: Put method in the right modelRails Best Practices 4: Scrivere i metodi nel model corretto

1. Put method in the right model

In our example, suppose we want to represent the animal world by creating a model Kind that represents types of animal and an Animal models representing animals.
For each type (quadrupedal, bipedal, bird) there are different animals that justify the has_many: animals relation defined in the following code.

Next, we define a method “herbivores” within the AnimalsController that, given a type of animal return all the herbivorous contained in that type.

The flaw in this code is to have defined the method find_herbivores inside the Kind model when in fact refers to a property of the Animal class.

Let’s see how to rewrite it in proper way, using a named_scope in the Animal model.

2. Delegate

In this second example, suppose we have a Location class associated with an owner and want to show owner’s data in the Location’s view.
A first simple implementation is the following:

And in the view:

This type of implementation is very common in Rails applications, but you can make it more elegant by using the construct “delegate” as follows:

Now we can rewrite the view as follows:

The result does not change, but the code is certainly more elegant.

Share on:

Related Post

• Rails Best Practices 6: Filters and helpers fileRails Best Practices 6: Filtri e file helper
• Rails Best Practices 3: Increase Controller’s readabilityRails Best Practices 3: Aumentare la leggibilità dei controller
• Rails Best Practices 2: Move logic to modelRails Best Practices 2: Spostare la logica nel model
• Rails Best Practices 1: Fat Model – Skinny ControllerRails Best Practices 1: Fat Model – Skinny Controller
• Rails Best Practices: introductionRails Best Practices: introduzione

This pattern expects a series of commands to be executed and a set of objects capable to handle them.
Each of these “handler” objects can send the command to the next handler in the chain if it is not able to carry it out.
A mechanism also exists for adding new handler objects to the end of this chain.

To show this pattern, we take as example a real situation very familiar to web developers.

Suppose that the manager must deliver a new web project.

To realize the entire project should be conducted several heterogeneous activities such as design the user interface, develop the application, write the user manual, deploy the application.

The manager doesn’t have all required skills but he can rely on a pool of developers.

When the activity reaches a developer, this can solve it or, if he is unable to, send it to a colleague.
In this way a chain of responsibility is formed, where each actor specializes in solving only certain types of requests.

Let’s see how to carry out this scenario in Ruby.

Is therefore necessary that every element in the chain has the ability to “forward” the request to the next if he is not able to manage it.

So we create a module that defines this common logic and removes code duplication.

As you can see, the next_in_chain method provides the next element in the chain.
To meet demands that can not be managed, I’ve used the method_missing “pattern” : when the request can not be managed by the actor (e.g. the invoked method is not defined in the class), it will be forwarded to the next.

Now define the players of our example:

At this point we simulate our chain by running the following code:

and the output will be:

WebDesigner: I’m designing the interface
WebDeveloper: I’m building the application
TechnicalWriter: I’m writing documentation
WebDeveloper: I’m deploying the application
WebManager: Application delivered
This request cannot be handled!

In conclusion, the use of this pattern is useful when we deal with heterogeneous requests and we want to make sure that these are best handled by a specific handler.
It can also be used when we run commands in sequence, where each element forwards the coming command to the next handler.

An alternative to this pattern could be a decorator, able to add capacity to a specific handler. In this case a single handler will completely manage all requests.

In these first three articles of the series we have analyzed the first pattern shown by the GoF for each category.

In the coming articles I will no more follow the order set by the GoF but I’ll analyze the most useful patterns to address the most common needs.

Source code here

Previous posts from this series:
Design Patterns in Ruby: Introduction
Design Patterns in Ruby: Abstract Factory
Design Patterns in Ruby: Adapter

Share on:

Related Post

• Design Patterns in Ruby: AdapterDesign Patterns in Ruby: Adapter
• Design Patterns in Ruby: Abstract FactoryDesign Patterns in Ruby: Abstract Factory
• Design Patterns in Ruby: Introduction Design Patterns in Ruby: Introduzione
• How to model a custom search form in RailsCome modellare una form di ricerca usando Rails
• Create zip files on the fly with rubyCreare un file zip al volo con ruby

1. Methods within model

Suppose we have the classic user registry defined in such a way that an admin user can enable or disable other users.

The deactivate method inside user Controller may be defined as follows:

What is clear is that this method has a lot of business logic inside. We see then how to define a method in the User Model to implement business logic so we can streamline this method.

This rewrite makes the deactivate method within Controller more readable and more easily testable.

2. Factory Method
In a similar way to what has been done for the deactivate method, sometimes can be handy while writing a create method, to define a Factory Method in the model that contains the logic of creation / initialization of the object and then call it from the controller.
As usual, let’s see an example.
Imagine you are developing a new management system where a news must be associated with the user who created it and it must also be visible only for a week.
A solution, without the Factory Method is the following:

Let us now see how to define a proper method (the Factory Method) of creating the news in the model so, once again, we simplify the controller

Once again we managed to write a better code in the Controller by moving the logic in the Model.

This post concludes the first part of this series when I tried to illustrate some best practices that allow to simplify the controller and move the business logic in the Model.

From the next post I will start to illustrate some Best Practices applicable to the Models.

Share on:

Related Post

• Rails Best Practices 6: Filters and helpers fileRails Best Practices 6: Filtri e file helper
• Rails Best Practices 4: Put method in the right modelRails Best Practices 4: Scrivere i metodi nel model corretto
• Rails Best Practices 2: Move logic to modelRails Best Practices 2: Spostare la logica nel model
• Rails Best Practices 1: Fat Model – Skinny ControllerRails Best Practices 1: Fat Model – Skinny Controller
• Rails Best Practices: introductionRails Best Practices: introduzione

The purpose of an adapter is “to convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.”

Suppose therefore to have two classes, PalGame and NtscGame, that extend a superclass Game. These subclasses respectively expose two methods: play and run.

We then subclass a Console class with PalConsole and NtscConsole. These two classes are expected to talk with, respectively, games of kind PalGame and NtscGame.

How can see, the method play_game of a PalConsole will call the play method of the game, the NtscConsole instead will invoke the run method.

Our goal is to let a PalConsole to run games of kind NtscGame.

Below we’ll follow the line traced by the GoF and we’ll build an Adapter class that provides the play method needed by the PalConsole’s interface:

As you can see, the adapter exposes a simple play method that calls the run method of the NTSCGame.

The following code:

will produce this output:
I am the NTSC version of Final Fantasy and I am running!

We see at this point some alternatives to further exploit the potential of Ruby.

One possibility is to take advantage of the Ruby’s “open classes”. The language makes possible to add methods to an already loaded class in this way:

As we can see, we’ve added at runtime the method play for a NtscGame game.

The above code produces the following output:
I am the NTSC version of Final Fantasy and I am running!
I am the NTSC version of Double Dragon and I am running!

Note however that with this solution we added the play method to the entire class NtscGame. All instances that are created will be equipped with the play method.
This type of action is very risky because it could not guarantee compatibility with other libraries, for example because of name clash.

Another alternative would be to use the “singleton classes”.
Ruby makes it possible to change a single instance of a class, by creating an anonymous class as its superclass that implements the new defined method.

There are several possibilities to implement these singleton classes. Let’s see in the following snippet some implementations.

All implementations will provide the same type of output:
I am the NTSC version of Final Fantasy and I am running!
I am the NTSC version of Winning Eleven and I am running!
I am the NTSC version of Thunderforce and I am running!
I am the NTSC version of Dragons Lair and I am running!

In this post we have therefore seen the usefulness of this design patterns and how Ruby allows the developer to “leave” the classic implementation suggested in order to better take advantage of the potentiality of the language.

Source code here

Previous posts from this series:
Design Patterns in Ruby: Introduction
Design Patterns in Ruby: Abstract Factory

Share on:

Related Post

• Design Patterns in Ruby: Chain of ResponsibilityDesign Patterns in Ruby: Chain of Responsibility
• Design Patterns in Ruby: Abstract FactoryDesign Patterns in Ruby: Abstract Factory
• Design Patterns in Ruby: Introduction Design Patterns in Ruby: Introduzione
• How to model a custom search form in RailsCome modellare una form di ricerca usando Rails
• Create zip files on the fly with rubyCreare un file zip al volo con ruby

1. Virtual Attribute

Suppose we have a customers list table defined as follows

Suppose we have a customers list table defined as follows but we want to define an input mask where street and city are grouped into one field called “address”.
The form with the “address” field will be defined as follows:

Now in the create method we’ll have something like:

We can now improve this method by defining the address field as a virtual attribute of the Client model.

In the form we can now define the address field as f.field_tag instead of as text_field_tag :

Finally, the controller will become simpler:

2. Model Callback
Now we see a method, called Model Callback that allows us, as with the virtual attribute just seen, to simplify the form and to move the controller’s logic inside the model.

Suppose we have to implement a feature that automatically associates a set of tags to a post.
This feature, called calculate_tags return a list of tags based on the most frequent words contained in the post.
We don’t see the code of this function and instead see how and when to invoke the automatic generation of tags.

A first implementation can be as follows. Given the following form:

the corresponding create method will be:

Editing the Post model, let’s see how to improve the code we’ve just wrote.
First we introduce in our model an attribute, “calculate_tags”, and a filter “generate_tags”, of type before_save

Returning to the form we can now redefine the field calculate_tags as f.check_box

Finally, our create method in the controller will return to its simplest form.

Share on:

Related Post

• Rails Best Practices 6: Filters and helpers fileRails Best Practices 6: Filtri e file helper
• Rails Best Practices 4: Put method in the right modelRails Best Practices 4: Scrivere i metodi nel model corretto
• Rails Best Practices 3: Increase Controller’s readabilityRails Best Practices 3: Aumentare la leggibilità dei controller
• Rails Best Practices 1: Fat Model – Skinny ControllerRails Best Practices 1: Fat Model – Skinny Controller
• Rails Best Practices: introductionRails Best Practices: introduzione

Below is showed one possible implementation of an abstract Factory and its concrete Factories that implement it.

Suppose we have two categories of games as a model classes:

How we can see, both models derive from a common superclass Game.

Let’s define the Factories delegate to build these objects:

Note that we have defined the abstract factory (MyAbstractGameFactory) as a module: it defines the abstract method that must be implemented by the class that includes it.
RpgFactory and ArcadeFactory represent the two concrete factories responsible to build, respectively, Arcade and RPG games.

The code of a GameStore, that can provide games basing on the needs of the customer, will be defined as follows:

At this point, launching the following file main.rb

we’ll get the following output in console:

I am a RPG named Final Fantasy 1
I am a RPG named Final Fantasy 2
I am an Arcade named Double Dragon 1
I am an Arcade named Double Dragon 2
I am an Arcade named Double Dragon 3
I am an Arcade named Double Dragon 4
I am an Arcade named Double Dragon 5

At this point we can optimize our Factories in order to take advantage of the potential offered by Ruby:

As we can see, now a single concrete factory GameFactory continues to build Arcade and RPG basing on the need of the moment.
This will allow a system to be independent from the implementation of concrete objects and that the client, through the interface, to use the different product families.
Note that in both examples the definition of MyAbstractGameFactory was made only for educational purposes and was used to “simulate” in Ruby an abstract method of an abstract class.

The output generated by invoking this new GameStore is the same as seen in the previous example.

All code available in this repository on GitHub: design_patterns_in_ruby

Source code here

Previous posts from this serie:
Design Patterns in Ruby: Introduction

Share on:

Related Post

• Design Patterns in Ruby: Chain of ResponsibilityDesign Patterns in Ruby: Chain of Responsibility
• Design Patterns in Ruby: AdapterDesign Patterns in Ruby: Adapter
• Design Patterns in Ruby: Introduction Design Patterns in Ruby: Introduzione
• How to model a custom search form in RailsCome modellare una form di ricerca usando Rails
• Create zip files on the fly with rubyCreare un file zip al volo con ruby

With this post I would like to start a serie of articles concerning the description of the most common design patterns and how these can be applied with the Ruby language.

In the world of software engineering you don’t need to reinvent the wheel to face daily problems: these problems are often very common and in most cases they require a similar resolution.

Christopher Alexander says that “each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such way that you can use this solution a million times over, without ever doing it the same way twice“.

In 1995, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, starting from the work of Christopher Alexander and Kent Beck, have published “Design Patterns: Elements of Reusable Object-Oriented Software.” With this book, the four authors (from then knowned as GoF, Gang of Four) have proposed solutions to the 23 most common and recurring problems in software engineering.

The GoF have analyzed and divided the 23 patterns into 3 categories:

Creational patterns

• Abstract Factory
• Builder
• Factory Method
• Prototype
• Singleton

Structural patterns

• Adapter
• Bridge
• Composite
• Decorator
• Facade
• Flyweight
• Proxy

Behavioral patterns

• Chain
• Command
• Interpreter
• Iterator
• Mediator
• Memento
• Observer
• State
• Strategy
• Template
• Visitor

We will see during this series all the most common patterns: we’ll analyze the problem and define a solution if possible using the potential provided by the Ruby language.

All showed code will be freely accessible in an out repository on GitHub at this address: design_patterns_in_ruby.

Share on:

Related Post

• Design Patterns in Ruby: Chain of ResponsibilityDesign Patterns in Ruby: Chain of Responsibility
• Design Patterns in Ruby: AdapterDesign Patterns in Ruby: Adapter
• Design Patterns in Ruby: Abstract FactoryDesign Patterns in Ruby: Abstract Factory
• How to model a custom search form in RailsCome modellare una form di ricerca usando Rails
• Create zip files on the fly with rubyCreare un file zip al volo con ruby