Tuesday, June 12, 2012

Can't start portgresql in F15, F16

First please login as follows in your terminal :


# su - postgres

Then type

$ pg_ctl init

---------------------------------

After execute above command try to start the server as normal way :

systemctl start postgresql.service or /etc/init.d/postgresql start

If you want to start the server from start-up please type as following in your terminal:

chkconfig postgresql on

Friday, May 11, 2012

Adapter pattern using php

Programming would be simple, but boring. Programmers would continue to build applications on top of the same technologies that they did years ago. They would never need to introduce different databases, implement new best practices, or consume different APIs. But these things do change. Luckily, programmers have the Adapter Design Pattern to help update legacy systems with new code and functionality.

The solution is to build another object, using the Adapter Design Pattern. This Adapter object works as an intermediary between the original application and the new functionality. The Adapter Design Pattern defines a new interface for an existing object to match what the new object requires.

Code Example

In the original code base of the project, an object exists that handles all of the error messages and codes called errorObject. The original programmers didn’t think their code would ever generate any errors, so they designed the system to output the errorObject’s error information directly to the console.

In this example, a 404:Not Found error is being generated. You are going to assume that the error message content and code may change, but the text will always stay in the same format.

 class ErrorObject  
 {  
   private $error;  
   public function __construct($error){  
     $this->error = $error;  
   }  
   public function getError(){  
     return $this->error;  
   }  
 }  


 class LogToConsole  
 {  
   private $errorObject;  
   public function __construct($errorObject){  
     $this->errorObject = $errorObject;  
   }  
   public function write() {  
     fwrite(STDERR, $this->errorObject->getError() . "\n");  
   }  
 }  

Here is the testing...

 include "ErrorObject.php";  
 include "LogToConsole.php";  
 /** create the new 404 error object **/  
 $error = new ErrorObject("404:Not Found");  
 /** write the error to the console **/  
 $log = new LogToConsole($error);  
 $log->write();  
How about new requirement comes that error need to output to csv format, with the code and description.
Lets look at how we going to do that with Adapter pattern.
 class LogToCsvAdapter extends ErrorObject  
 {  
   private $errorNumber, $errorText;  
   public function __construct($error)  
   {  
     parent::__construct($error);  
     $parts = explode(':', $this->getError());  
     $this->errorNumber = $parts[0];  
     $this->errorText = $parts[1];  
   }  
   public function getErrorNumber()  
   {  
     return $this->errorNumber;  
   }  
   public function getErrorText()  
   {  
     return $this->errorText;  
   }  
 }  






Here is the testing...
 include "ErrorObject.php";  
 include "LogToCsv.php";  
 include "LogToCsvAdapter.php";  
 /** create the new 404 error object adapted for csv **/  
 $error = new LogToCsvAdapter("404:Not Found");  
 /** write the error to the csv file **/  
 $log = new logToCSV($error);  
 $log->write();  




Good luck...

Wednesday, May 9, 2012

How to delete .svn files for linux

Recursively delete .svn directories


This is a simple example of a unix command, which recursively deletes subversion .svn folders. Subversion is a well-spread open-source revision control application. Every copy of source code received from subversion repository has .svn folders, which store metadata. However, if you want to use or distribute source code, these .svn folder are often not necessary.     

We use find command to find all .svn folders beginning from current directory.


eg: type : find . -type d -name .svn

It is possible to pass these directories directly to rm command, using grave accent quotes (key to left of '1')

eg: type : rm -rf `find . -type d -name .svn`

above command will remove every .svn folder beginning from current directory.

You may do not like to type each and every time so you can create shell script for that.


1) Create a file called  /usr/bin/csvn 
2) Input following codes:

#!/bin/sh
echo "recursively removing .svn folders from"
pwd
rm -rf `find . -type d -name .svn`

You may save this script to /usr/bin/csvn (or other binary folder included in path) and use later to get 'clean' project source without typing lengthy commands.

For example

$ svn checkout svn://server.com/svn/project
A    project/index.php
A    project/sourceA/a.php
A    project/sourceA/a1.php
A    project/sourceA/a2.php
A    project/sourceB/b.php
A    project/sourceB/module/lib.php
A    project/sourceC/c.php
Checked out revision 15.
$ cd project
$ csvn
recursively removing .svn folders from
/Users/anyexample/Source/project

~Good luck~

Thursday, March 29, 2012

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



Wednesday, March 14, 2012

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

Thursday, September 29, 2011

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... :)

Thursday, February 3, 2011

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