Dove sono finito?

Non lo so, so che al momento sono all’università e sto preparando un altro esame.. e sarà così per tutto luglio…. ho dovuto interrompere la mia mini serie di articoli sulla dependency injection in php e me ne scuso, la riprenderò il prima possibile . In compenso potete forkare una versione preliminare di qoo framework “funzionante” o forse dovrei dire funzionale, ci sono alcune classi di troppo ma i moduli core e controller sono completi.

Nel frattempo vorrei comunicare a tutti voi il mio sdegno per il popolo italiano che sulla questione nucleare si conferma un popolo di pecore che non sanno pensare con la loro testa e si fanno dire dagli altri cosa devono votare.

Se invece di sventolare i 4 si , si sventolassero documentazioni, pro e contro, riguardanti le possibili scelte quella sarebbe una vera situazione democratica e razionale. Quella attuale è un bombardamento mediatico in cui non c’è scelta ma obbedienza. Anche i partiti ambientalisti usano il mediatic bombing sulle povere pecore che siamo noi. Siamo alla frutta.

OFF TOPIC: La mia mail a Mediaset (Italia1)

Scusate per l’off topic, ma non ho saputo resistere.

Avete mai avuto dei “momenti sacri” all’interno della vostra giornata? magari momenti in cui fate qualcosa di tremendamente comune, ma che vi rilassa e vi ammorbidisce la vita? Io ne ho uno, ormai da un paio d’anni: Il caffè dopo pranzo.

Sarà perchè da piccolo ero abituato a gardare Dragon Ball appena finito di mangiare ma ormai nessuno può rovinarmelo, Italia 1 c’è riuscita per la prima volta: Inserendo Human Take control tra una puntata dei Simpson la successiva :(

Dependency Injection in PHP parte 2: Container

La settimana scorsa avevo pubblicato un articolo introduttivo alla dependency injection; questa volta faremo un passo avanti  definendo un Container, ovvero una classe il cui scopo è quello di contenere i nostri oggetti e di permettere di recuperarli in modo pratico.

Un primo container primitivo è un oggetto dotato di due metodi set() e get() i quali permettano l’accesso alle istanze rilevanti per la nostra applicazione:

class Container
{
   protected $_Data = array();
   public function get($item_name)
   {
      if (isset($this->_Data[$item_name]) )
         return $this->_Data[$item_name];
      return null;
   }
   public function set($item_name,$item)
   {
      $this->_Data[$item_name] = $item;
   }

}

Questo può sembrare triviale ma in realtà è tutto ciò di cui abbiamo bisogno! : Grazie al container possiamo dedicare una parte dell’applicazione, che chiameremo bootstrapping, alla creazione delle istanze di oggetti che utilizzeremo in altri punti dell’esecuzione.

$connection = new MysqlConnection($host,$user,$password,$db);
$db = new Database($connection);

$logger = new TxtLogger('myfile.txt');

$view = new View('master');

$container = new Container();
$container->set('database',$db);
$container->set('logger',$logger);
$container->set('master_view',$view);

A questo punto non ci resta che passare l’istanza di container ai business objects che necessitano delle istanze di database, logger e view per poi poterle riutilizzare:

//...
public function businessMethod()
{
   $this->doAction();
   $this->container->get('logger')->log(' Action done :) ');

   $userDao = new UserDao( $this->container->get('database') );
}

Per rendere il codice più leggibile potremmo sovrascrivere il magic method __get() in modo da cercare l’attributo richiesto direttamente nel container:

public function __get($name)
{
   if (null !== $this->container->get($name) )
   return $this->container->get($name);

   throw new BusinessObjectException('Unkown property '.$name);
}
public function anAction()
{
   $this->database->query('INSER INTO table VALUES (bla bla bla)');
}

Per approfondire il design di un container, vi consiglio di leggere queste slides scritte da Fabien Potencier, il creatore di Symfony.

Dependency Injection in php: Introduzione

Quando ti trovi di fronte ad un progetto che utilizza di un buon numero di classi e istanze, serve un piano d’attacco. Non puoi semplicemente cominciare a scrivere,  altrimenti è molto probabile che, al momento della verità (Il testing), arrivino i problemi. Lo dico con certezza perchè io stesso, fino a qualche tempo fa, ero uno di quelli che iniziava subito a scrivere codice e che poi si ritrovava con mille tab aperte in eclipse per cercare di fixare il problema.

La dependency injection è l’arte di semplificare la creazione e la configurazione delgi oggetti e recentemente, dopo aver spopolato in ambiente Java, ha cominciato a prendere piede in ambiente php; in questi articoli cercherò di riportare ciò che ho imparato a riguardo.

Pensate di avere un oggetto che dovere utilizzare in diversi punti dell’applicazione e che per essere utilizzato ha bisogno di un minimo di configurazione, ad esempio:

/**
*   Nota : pensiamo che il Device non
*   l'abbiamo scritto noi, ma che stiamo utilizzando
*   classi di terze parti altrimenti avremmo potuto
*   modificare il costruttore del device e
*   scrivere new Device($logger,$request)
*/

$device = new Device();
$logger = new XmlLogger();
$logger->prepare('path/to/file.xml');
$device->setLogger($logger);
$device->setRequest(HttpRequest::create()  );
$response = $device->doYourWork();

Prima di riuscire a fare il suo lavoro, il device ha bisogno di alcune righe di preparazione e questo ogni volta che in un punto diverso dell’esecuzione avete bisogno di usare una istanza di device! Diciamo che Device, in questo caso, ha due dipendenze: XmlLogger e HttpRequest.

Premesso che eviterò di usare stati globali come la peste (per maggiori informazioni leggete qui) e quindi qualsiasi forma di Singleton, scrivere quel codice di configurazione ogni volta che si vuole chiamare doYourWork() potrebbe essere una grossa seccatura, specialmente se Device fosse più complesso.

Una prima soluzione ci è data dalla Dependency injection: scriviamo un Container:

class DeviceContainer
{
public function getDevice()
{
   $this->device = new Device();
   $logger = new XmlLogger();
   $logger->prepare('path/to/file.xml');
   $this->device->setLogger($logger);
   $this->device->setRequest(HttpRequest::create()  );
   return $this->device;

}
}

Ora, ogni volta che avremo bisogno di utilizzare il Device, dobbiamo solamente chiamare il metodo getDevice() della classe container ed otterremo una istanza correttamente configurata :

class DeviceUserA
{
   function work()
   {
       $container = new DeviceContainer();
       $device = $container->getDevice();
       $device->doYourWork();
    }

}

Questa soluzione è ancora poco flessibile perchè potreste necessitare all’interno della vostra applicazione di diversi tipi di device ognuno con una configurazione diversa. Dobbiamo modificare il nostro DeviceContainer:

class DeviceContainer
{
public function getDeviceA()
{
   if (null !== $this->device_a)
      return $this->device_a
   $this->device_a = new DeviceA();
   $logger = new XmlLogger();
   $logger->prepare('path/to/file.xml');
   $this->device_a->setLogger($logger);
   $this->device_a->setRequest(HttpRequest::create()  );
   return $this->device_a;

}
public function getDeviceB()
{
   if (null !== $this->device_b)
      return $this->device_b

   $this->device_b = new DeviceB();

   $dsn = 'mysql:dbname=testdb;host=127.0.0.1';
   $user = 'dbuser';
   $password = 'dbpass';
   $connection = new PDO($dns,$user,$password);
   $logger = new MysqlLogger($connection);

   $this->device_b->setLogger($logger);
   $this->device_b->setRequest(HttpRequest::create()  );
   return $this->device_b;

}

}

Potete notare che ogni metodo getDeviceX() ha due righe di codice che consentono di non reistanziare l’oggetto ogni volta
ma di riutilizzare istanze già create dal container.

Per questo articolo è tutto, nel prossimo vedremo come scrivere un container che funzioni in ogni situazione (o quasi) senza bisogno di modificare la classe container.

Ora torno a lavorare a qoo framework, non vedo l’ora di pubblicarlo ed essere criticato ;) .

Nuovo progetto: qoo framework

Ebbene si, lo ammetto ho sempre avuto un debole per la programmazione ad oggetti e per il design delle architetture software. Nondimeno ho sempre avuto un debole per i framework php e da circa 4 anni ho sempre scritto collezioni di classi a mano per capire quali idee ci fossero dietro alcuni tra i framework php più famosi.

Recentemente ho deciso che la prossima collezione di classi avrebbe dovuto essere più versatile delle altre e che avrei dovuto utilizzarla per realizzare più applicazioni. Questa decisione, unita al fatto di voler provare a gestire un progetto medio-grande ed Open source mi hanno portato alla ‘creazione’ di questo progetto, un framework php5 molto leggero, orientato alla leggibilità del codice ed alla flessibilità di utilizzo. L’ ho chiamato qoo framework.

La prima domanda che potrebbe venirvi in mente è “Abbiamo bisogno di un nuovo framework?” dopotutto ce ne sono tantissimi, alcuni dei quali (Zend e Symfony ad esempio) validissimi ed usatissimi, altri (Lithium, interessantissimo) sono emergenti e molto promettenti. Ognuno ha i suoi pro ed i suoi contro, zend e symfony sono incredibilmente potenti ma necessitano di un certo sforzo iniziale per poter rendere produttivo lo sviluppatore. Lithium adotta una architettura particolare che fa l’occhiolino alla programmazione orientata agli aspetti e Code igniter a volte soffre di eccessiva semplificazione (dal mio punto di vista) che porta a mancanza di eleganza. Eleganza che per me è una caratteristica molto importante quando si tratta di codice php.

Eccomi quindi alla ricerca di un framework elegante.

Qoo framework è ancora in fase di sviluppo, mancano il Data abstraction layer e la parte dedicata alla creazione di API, ma per il momento posso elencarvi le caratteristiche principali che ho voluto e che voglio dare a qoo:

  • Semplicità
  • Leggerezza
  • Leggibilità
  • Flessibilità
  • Scalabilità
  • Modularità

Le prime tre caratteristiche sono dovute al fatto che sono stanco di vedere e soprattutto di scrivere codice che se non commentato in ogni minimo dettaglio perde di comprensibilità; inoltre, non voglio dover scrivere 2000 righe di codice per fare qualcosa che in php non oo richiederebbe un decimo del codice. Non voglio costringere chi usa il framework ad avere mille file di configurazione e dover sottostare a strettissime regole di interazione tra le componenti. Questo ci porta al quarto punto: flessibilità. Si perchè essendo una webapp un sistema complesso, voglio dare la possibilità di fare la stessa cosa in modi diversi, lasciando libero chi scrive il codice. Per questo in qoo ci sono diversi modi di inizializzare le componenti del sistema e di riutilizzarle in seguito in altri punti dell’applicazione: non ti piace singleton? Benissimo usa il registry! Non ti piace registry? benissimo usa la dependency injection e la parameter propagation!. Il quinto punto si chiama scalabilità e questo riguarda strettamente l’architettura mvc stessa di qoo, disegnata per poter essere frammentata in più layer gestiti sotto una struttura gerarchica (spesso ci si riferisce a questa soluzione con l’acronimo HMVC). Infine “Modularità” si riferisce al fatto che l’implementazione di ogni classe fa si che esse siano debolmente dipendenti le une dalle altre e che le le dipendenze sono gestite tramite metodi get/set.

Seguiranno in futuro altre news, ma per il momento vi lascio alcuni link utili:

Nuova pagina facebook: PHP Programming

Nel poco tempo libero di cui dispongo a causa dell’università e dello sviluppo di un social site (con relativo framework php) che mi tengono occupatissimo, non riesco a postare articoli interessanti ne inerenti la sicurezza delle web app ne alla programmazione php in generale.

Per questo ho deciso di aprire una pagina facebook in cui pubblicherò i link interessanti che mi propone il mio feed reader durante la colazione,  con l’aggiunta di qualche pensiero personale riguardo il php.

Ecco il link alla pagina, iscrivetevi numerosi :D

Windows Vista + Eclipse + Git + Github

Di recente mi sono stati proposti due progetti davvero interessanti riguardanti il web2.0 per prepararmi al meglio ho deciso di riorganizzare le mie carissime e fidatissime classi php che utilizzo da tempo in un piccolo framework che mi permetta di prototipizzare alcune operazioni comuni.

Come servizio di project hosting mi sono affidato a Github, che come suggerisce il nome utilizza repository Git, ecco quindi i passi da compiere per avere un sistema funzionante:

  • Create un account su Github.com
  • Create un repository su github.com con il nome del vostro progetto
  • Seguite questa guida per installare Git su sistemi Windows
  • Aprite Eclipse e nel tab Help cliccate su “install new software”, selezionate il repository “all available site” e nel filtro di ricerca scrivete Git, dovreste trovare un pacchetto chiamato EGit ed uno chiamato JGit, io ho installato EGit quindi faccio riferimento a quello
  • Al posto di creare un nuovo progetto su eclipse, andate su File->Import->Git->Projects from Git ed inserite i dati relativi al vostro repository git locale
  • Importate con il wizard per semplicità

A questo punto avete il vostro progetto collegato al repository Git hostato da Github.com, manca solo un piccolo dettaglio che mi ha creato 5 minuti di panico :

Per qualche motivo, Eclipse cerca di default le vostre chiavi RSA per SSH nella cartella {USER}/ssh invece di {USER}/.ssh . In rete ho trovato due modi per risolvere il problema in windows. Il primo consiglia di creare un link alla directory .ssh e chiamarlo ssh in modo che eclipse la trovi (il comando in questione dovrebbe essere mklink \D .ssh ssh). Il secondo metodo che ha funzionato per me, consiste nel modificare una opzione di eclipse, ovvero andate su Window->Preferences->General->Network Connection->SSH2 e mettete il punto davanti alla benedetta directory ssh.

Buon teamwork a tutti :)