Mercurial for first time

This is simply version control system.

Basic usage:

1). How to clone from repo?


hg clone http://www.selenic.com/repo/hello my-hello


If everything went gladly, You will see new folder in your current directory called `my-hello` . This is the directory that you have checkout from the repository.

2). How to see  revision information?

Go to your checkout folder. (my-hello). And type


hg parents

Libraries installation for symfony development using yum

yum install php-pdo.i686
yum install php-xml
yum install php-mbstring.i686
yum list php-pear
yum install php-pecl-apc
yum install php-process

WILD CARDS WITH WGET

You can download all the pdf files under docs folder:


wget -r -l1 --no-parent -A.pdf http://somehost.com/docs/


Step 1
-------------


Go to linux shell


Step 2
-------------


Have the following command and hit enter


wget -r -l1 --no-parent -A.pdf http://somehost.com/docs/




It will download all the pdf files in the specified host.


Enjoy... :)

Design Principles

What are Software Design Principles?

Software design principles represent a set of guidelines that helps us to avoid having a bad design. The design principles are associated to Robert Martin who gathered them in "Agile Software Development: Principles, Patterns, and Practices". According to Robert Martin there are 3 important characteristics of a bad design that should be avoided:

• Rigidity - It is hard to change because every change affects too many other parts of the system.
• Fragility - When you make a change, unexpected parts of the system break.
• Immobility - It is hard to reuse in another application because it cannot be disentangled from the current application.

Open Close Principle

• Software entities like classes, modules and functions should be open for extension but closed for modifications.

OPC is a generic principle. You can consider it when writing your classes to make sure that when you need to extend their behavior you don’t have to change the class but to extend it. The same principle can be applied for modules, packages, libraries. If you have a library containing a set of classes there are many reasons for which you’ll prefer to extend it without changing the code that was already written (backward compatibility, regression testing, …). This is why we have to make sure our modules follow Open Closed Principle.

When referring to the classes Open Close Principle can be ensured by use of Abstract Classes and concrete classes for implementing their behavior. This will enforce having Concrete Classes extending Abstract Classes instead of changing them. Some particular cases of this are Template Pattern and Strategy Pattern.

Dependency Inversion Principle

• High-level modules should not depend on low-level modules. Both should depend on abstractions.
• Abstractions should not depend on details. Details should depend on abstractions.

Dependency Inversion Principle states that we should decouple high level modules from low level modules, introducing an abstraction layer between the high level classes and low level classes. Further more it inverts the dependency: instead of writing our abstractions based on details, the we should write the details based on abstractions.

Dependency Inversion or Inversion of Control are better know terms referring to the way in which the dependencies are realized. In the classical way when a software module(class, framework, …) need some other module, it initializes and holds a direct reference to it. This will make the 2 modules tight coupled. In order to decouple them the first module will provide a hook(a property, parameter, …) and an external module controlling the dependencies will inject the reference to the second one.

By applying the Dependency Inversion the modules can be easily changed by other modules just changing the dependency module. Factories and Abstract Factories can be used as dependency frameworks, but there are specialized frameworks for that, known as Inversion of Control Container.

Interface Segregation Principle

• Clients should not be forced to depend upon interfaces that they don't use.

This principle teaches us to take care how we write our interfaces. When we write our interfaces we should take care to add only methods that should be there. If we add methods that should not be there the classes implementing the interface will have to implement those methods as well. For example if we create an interface called Worker and add a method lunch break, all the workers will have to implement it. What if the worker is a robot?


As a conclusion Interfaces containing methods that are not specific to it are called polluted or fat interfaces. We should avoid them.

Single Responsibility Principle

• A class should have only one reason to change.

In this context a responsibility is considered to be one reason to change. This principle states that if we have 2 reasons to change for a class, we have to split the functionality in two classes. Each class will handle only one responsibility and on future if we need to make one change we are going to make it in the class which handle it. When we need to make a change in a class having more responsibilities the change might affect the other functionality of the classes.

Single Responsibility Principle was introduced Tom DeMarco in his book Structured Analysis and Systems Specification, 1979. Robert Martin reinterpreted the concept and defined the responsibility as a reason to change.

Liskov's Substitution Principle

• Derived types must be completely substitutable for their base types.

This principle is just an extension of the Open Close Principle in terms of behavior meaning that we must make sure that new derived classes are extending the base classes without changing their behavior. The new derived classes should be able to replace the base classes without any change in the code.


Liskov's Substitution Principle was introduced by Barbara Liskov in a 1987 Conference on Object Oriented Programming Systems Languages and Applications, in Data abstraction and hierarchy

How to create sample vaadin application with maven 2.2.1

Step one
--------

Create maven project with typing the following command on your command line.


mvn archetype:create -DgroupId=com.sample.vaadin -DartifactId=SampleVaadin -DarchetypeArtifactId=maven-archetype-webapp

Here is the sample pom.xml

 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">  
  <modelVersion>4.0.0</modelVersion>  
  <groupId>com.sample.vaadin</groupId>  
  <artifactId>SampleVaadin</artifactId>  
  <packaging>war</packaging>  
  <version>1.0-SNAPSHOT</version>  
  <name>SampleVaadin Maven Webapp</name>  
  <url>http://maven.apache.org</url>  
  <dependencies>  
   <dependency>  
    <groupId>junit</groupId>  
    <artifactId>junit</artifactId>  
    <version>3.8.1</version>  
    <scope>test</scope>  
   </dependency>  
  </dependencies>  
  <build>  
   <finalName>SampleVaadin</finalName>  
  </build>  
 </project>  

Step two
--------

Integrate jetty servlet container to vaadin project

Please update your pom.xml as follows:

 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">  
  <modelVersion>4.0.0</modelVersion>  
  <groupId>com.sample.vaadin</groupId>  
  <artifactId>SampleVaadin</artifactId>  
  <packaging>war</packaging>  
  <version>1.0-SNAPSHOT</version>  
  <name>SampleVaadin Maven Webapp</name>  
  <url>http://maven.apache.org</url>  
  <dependencies>  
   <dependency>  
    <groupId>junit</groupId>  
    <artifactId>junit</artifactId>  
    <version>3.8.1</version>  
    <scope>test</scope>  
   </dependency>  
      <dependency>  
           <groupId>com.vaadin</groupId>  
           <artifactId>vaadin</artifactId>  
           <version>6.6.2</version>  
           <type>jar</type>  
           <scope>compile</scope>  
      </dependency>  
  </dependencies>  
  <build>  
   <finalName>SampleVaadin</finalName>  
      <plugins>  
        <plugin>  
          <groupId>org.mortbay.jetty</groupId>  
          <artifactId>maven-jetty-plugin</artifactId>  
     </plugin>  
           <plugin>  
                     <groupId>org.apache.maven.plugins</groupId>  
                     <artifactId>maven-compiler-plugin</artifactId>  
                     <version>2.3.2</version>  
                     <configuration>  
                          <source>1.6</source>  
                          <target>1.6</target>  
                     </configuration>  
           </plugin>  
   </plugins>  
  </build>       
 </project>  


*** You can test whether jetty is running by typing "mvn jetty:run"


Step tree
--------

Writing code under src/main/java/com/sample/vaadin/HelloVaadin.java

 /**  
 * This is the main class of the vaadin page  
 * @author gayan  
 *  
 * src/main/java/com/sample/vaadin/HelloVaadin.java  
 */  
 package com.sample.vaadin;  
 import com.vaadin.Application;  
 import com.vaadin.ui.*;  
 public class HelloVaadin extends Application {  
   @Override  
   public void init() {  
     Window mainWindow = new Window("HelloVaadin");  
     Label label = new Label("Hello Vaadin user");  
     mainWindow.addComponent(label);  
     setMainWindow(mainWindow);  
   }  
 }  

Step four
--------

Edit you web.xml file under webapp/web.xml as following

 <!DOCTYPE web-app PUBLIC  
  "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"  
  "http://java.sun.com/dtd/web-app_2_3.dtd" >  
 <web-app version="2.5" xmlns:xsi="[http://www.w3.org/2001/XMLSchema-instance\" xmlns="[http://java.sun.com/xml/ns/javaee]" xsi:schemalocation="[http://java.sun.com/xml/ns/javaee] [http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd]">  
   <display-name>HelloVaadin</display-name>  
   <context-param>  
     <param-name>productionMode</param-name><param-value>false</param-value><description>Vaadin production mode</description>  
   </context-param>  
   <servlet>  
     <servlet-name>HelloVaadin</servlet-name>  
     <servlet-class>com.vaadin.terminal.gwt.server.ApplicationServlet</servlet-class>  
     <init-param>  
       <param-name>application</param-name>  
                <param-value>com.sample.vaadin.HelloVaadin</param-value>  
                <description>Vaadin application class to start</description>  
     </init-param>  
   </servlet>  
   <servlet-mapping>  
     <servlet-name>HelloVaadin</servlet-name>  
     <url-pattern>/*</url-pattern>  
   </servlet-mapping>  
 </web-app>  

Final step
--------

Have commond "mvn compile jetty:run" and please have a look on http://localhost:8080 on your browser.

Linux chmod by the numbers

Up to this point, we’ve been setting the mode with letters. It turns out that you can also set the mode numerically. Here’s how it works:

1. Write the permissions you want the file to have. To make your life easier, write the permissions grouped into sets of three letters. For example, let’s say you want file info.sh to have these permissions
   

   - rwx r-x r-- info.sh
   

2. Under each letter, write a digit 1; under each dash write a digit zero. Ignore the dash at the very beginning that tells you whether it’s a file or directory. This gives you three binary numbers.
   

   - rwx r-x r-- info.sh
     111 101 100
   

3. Now convert each set of three digits to a single digit using this table:
   

   Binary Becomes 000 0 001 1 010 2 011 3

   Binary Becomes 100 4 101 5 110 6 111 7

   From our example, the 111 101 100 translates to the number 754.
4. Now use that number in a chmod command to set your desired permissions on the file:
   

   chmod 754 info.sh

Minimize ripple effects in OOP programing

What is the meaning of minimize ripple effect?
Minimizing the ripple effects means limit the force of  changes to a program. Simply saying by keeping details secret in your code (information hiding or encapsulation).


Basically there are three ways of doing it: 


By indirection 
  That means named constants replacing "magic numbers" in your piece of code.
  e.g: 
  A magic number is a direct usage of a number in the code. see the following piece of code as example     which is not best practice to use:


public class Foo {
     public void setPassword(String password) {
          // don't do this
          if (password.length() > 7) {
               throw new InvalidArgumentException("password");
          }
     }
}


 Best practice is in the following code: 





public class Foo {

     public static final MAX_PASSWORD_SIZE = 7;

     public void setPassword(String password) {

          if (password.length() > MAX_PASSWORD_SIZE) {

               throw new InvalidArgumentException("password");

          } 

}

***  It will improve the readability of the code and of course maintainability. 

***  Imagine the case where I set the size of the password field in the GUI. If I use a magic number, whenever the max size changes, I have to change in two code locations. If I forget one, this will lead to inconsistencies.


By minimizing visibility


 Use private fields, package-private classes to hide information from public access.


By generic references


Use  (polymorphism) - using high level references (interfaces or abstract classes) instead of low level references (concrete classes).