Archive for August 2009

Bringing web applications to your Desktop with Prism

I have almost finished working on a web app that will be used inside intranets by students willing to do their English language exams interactively. I have reached the point where I want the app to have as much as possible the look of a desktop one. So I started thinking that may be with the help of Javascript I might be able to remove the browser toolbar; not a bad idea so far. Also I wanted to disable both back and refresh buttons because the exam is timed and the student will have a time counter for each section. However after I ran through this thread and found a strong resistance towards such ideas, I decided to go with other solution. Simply I chose to remove the toolbar and use keystroke events to determine which ones are related to navigation, just like ‘f5’ and ‘backspace’. So far so good, but after few minutes of work on this approach, I had few thoughts at mind: “Why am I doing so? Do I really need a browser to do this? shouldn’t be there any software that can render HTML markup and can have a customized interface?”
I start searching for such a software and found Prism, which is a cool product by Mozilla that helps you turning a web app into a desktop like one. Taken from the product why page:

Instead of running all your web apps in the browser, Prism lets you run them in their own window just like normal applications. A single faulty app or web page can no longer take down everything you are working on.

Prism is so easy to be used, it takes 1 minute approximately to turn your web app into a desktop one and you will gain many Desktop integration things like:

  • Access web apps from system taskbar or dock
  • Tray icon and dock menus
  • Associate applications with browser links
  • Minimize to tray
  • System tray icon and dock badges

Prism can be used as a stand alone soft, or just another Firefox addon(this one didn’t play well with me). Give it a shoot, you won’t regret it!

Observer and Singleton design patterns in Ruby

This is my first article in http://railsmagazine.com, it was published in issue 3, so basically I’m just republishing it here again.

Observer and singleton are two common design patterns that a programmer should be familiar with, however what made me write about them, is that both are there out of the box for you to use in ruby.
So let’s have a look at both and see how ruby help you use them directly:

Observer Design Pattern

According to Wikipedia:

The observer pattern (sometimes known as publish/subscribe) is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems.

So how does ruby help you implementing this design pattern? Well, the answer is by mixing the observable module into your subject (observed object).
Let’s take an example, let’s suppose we have a banking mechanism that notifies the user by several ways upon withdrawal operations that leaves the account with balance less or equal to $0.5.
If we look deeply at this problem, we can qualify it as a good candidate for observer design pattern, where the bank account is our subject and the notification system as the observer.
Here is a code snippet for this problem and it’s solution:

So to user ruby observer lib we have to implement four things:
1- Require the ‘observer’ lib and include it inside the subject (observed) class.
2- Declare the object to be ‘changed’ and then notify the observers when needed – just like we did in ‘withdraw’ method.
3- Declare all needed observers objects that will observe the subject.
4- Each observer must implement an ‘update’ method that will be called by the subject.

Observers in Rails

You can find observers in rails when using ActiveRecord, it’s a way to take out all ActiveRecord callbacks out of the model, for example a one would do this:

A neater solution is to use Observers:

You can generate the previous observer using the following command:

You still can have observers that map to models that don’t match with the observer name using the ‘observe’ class method, you also can observe multiple models using the same method:

Finally don’t forget to add the following line inside config/environment.rb to define observers:

Singleton Design Pattern

According to Wikipedia:

In software engineering, the singleton pattern is a design pattern that is used to restrict instantiation of a class to one object. (This concept is also sometimes generalized to restrict the instance to a specific number of objects – for example, we can restrict the number of instances to five objects.) This is useful when exactly one object is needed to coordinate actions across the system.

The singleton design pattern is used to have one instance of some class, typically there are many places where you might want to do so, just like having one database connection, one LDAP connection, one logger instance or even one configuration object for your application.
In ruby you can use the singleton module to have the job done for you, let’s take ‘application configuration’ as an example and check how we can use ruby to do the job:

So what does ruby do when you include the singleton method inside your class?
1- It makes the ‘new’ method private and so you can’t use it.
2- It adds a class method called instance that instantiates only one instance of the class.
So to use ruby singleton module you need two things:
1- Require the lib ‘singleton’ then include it inside the desired
class.
2- Use the ‘instance’ method to get the instance you need.