Ambienti di sviluppo web

La maggior parte degli ambienti di sviluppo orientati al web necessitano di almeno tre tipologie di strumenti di lavoro

• Un editor o un IDE per generare, editare e gestire il codice. Alcuni esempi sono Eclipse e NetBeans (IDE), oppure Notepad++, Scintilla e VI (Editors)
• Uno o più server che realizzano l'architettura, ovvero creano l'ambiente dove andrà a girare il nostro software. Questi possono comprendere web server, application server, database server, proxy server, fronted ecc. (per chiarimenti sul ruolo dei vari server vedi Architettura client-server)
• Uno o più framework (o set di librerie). Questo elemento non è strettamente necessario, ma è quasi sempre presente in tutti gli ambienti di lavoro. Vedasi ad esempio Spring, Struts, Zend, jQuery, Prototpye ecc.

Con questo articolo vogliamo discutere e confrontare alcuni configurazioni possibili dei server, in particolare del web server e dell'application server, facendo riferimento rispettivamente ad Apache ed Tomcat. Lo scopo è quello di creare un ambiente di sviluppo semplice e leggero, senza la necessità di installare alcun IDE. Vedremo come configurare i server in modo da poter lavorare con un editor qualsiasi, facendo coincidere l'ambiente di sviluppo (dove teniamo i sorgenti) con quello di deploy (dove verifichiamo il risultato).

Configurazione di Apache

Abbiamo già discusso l'installazione di Apache Installare Apache su Windows (su sistemi Windows). A seconda del tipo di installazione, le applicazioni web vanno deployate (ovvero “installate”) all'interno di un percorso del tipo

<path di installazione>\EasyPHP-<versione>\www

<path di installazione>\xampp\htdocs

La scelta di deployare le applicazioni web all'interno di questi percorsi è quasi obbligatoria negli ambienti di produzione. Nel caso degli IDE il problema non si pone, perché in tal caso la configurazione del server è integrata all'interno dello strumento di lavoro, e lo sviluppatore si concentra unicamente sul codice, senza preoccuparsi di dove effettivamente vanno a finire le risorse compilate o deployate. Lo svantaggio dell'IDE, nel caso di un progetto di modeste dimensioni, è che si rischia di spendere più tempo a litigare con la configurazione dell'IDE che a sviluppare il codice.

Una soluzione alternativa potrebbe essere la seguente:

1. Editiamo il file httpd.conf (o il suo analogo apache2.conf) e cerchiamo al suo interno la stringa DocumentRoot
2. Commentiamo il valore corrente della direttiva DocumentRoot, digitando il simbolo # all'inizio della riga
3. Scriviamo sulla riga sottostante la nuova direttiva DocumentRoot, specificando il percorso della directory dove vogliamo tenere i nostri sorgenti (o le pagine web)

Il risultato dovrebbe essere qualcosa del genere

#DocumentRoot "${path}/www"

DocumentRoot "c:\home\develop\my_sites"

la configurazione ci permette di tenere tutti i nostri progetti web all'interno della directory c:\home\develop\my_sites, lasciandoli ben separati dalla cartella di installazione di Apache.

Alcuni vantaggi sono:

• Semplicità del backup: facendo il backup della directory my_sites eseguiamo il backup solo dei nostri sorgenti, e non del server. E' buona norma fare sempre un backup della configurazione del server, ma questo solitamente va fatto una volta sola, mentre i nostri progetti andrebbero “backuppati” almeno ogni giorno
• Editing diretto: se non utilizziamo un IDE, solitamente è più facile gestire i nostri files all'interno di una directory facilmente accessibile, che non cambia posizione o nome quando aggiorniamo Apache o cambiamo application server. Questo ci permette di navigare in modo semplice e intuitivo tra le risorse del file system, in modo da editarle, copiarle e spostarle come facciamo con qualsiasi altra risorsa
• Controllo di configurazione: se usiamo SVN, CVS o un qualsiasi altro sistema di controllo della configurazione (o versionamento dei progetti), potremo lavorare direttamente sulle copie versionate del nostro progetto, senza rischiare un qualche disallineamento tra risorse di lavoro e risorse effettivamente deployate

Un possibile svantaggio di questo ambiente di sviluppo è di essere poco adatto a lavorare in team, ma si tratta di un problema facilmente rimediabile. Se dovessimo condividere i nostri progetti possiamo importarli in un IDE, senza fare alcuno sforzo in più di quello normalmente necessari a configurare un IDE. In altre parole la configurazione descritta sopra permette di rimandare ad un secondo tempo la scelta e la configurazione dell'IDE, mettendoci in grado di sviluppare sin da subito.

Configurazione di Tomcat

A titolo d'esempio mostriamo la modifica da inserire nel file server.xml di Tomcat per realizzare una configurazione simile a quella appena vista per Apache

<Host name="localhost" appBase="webapps" ecc...>

<Context path="/foo" docBase="c:\home\develop\my_sites\foo"

debug="0" reloadable="true"/>

in questo caso dobbiamo inserire un elemento XML del tipo <Context> per ogni webapp che vogliamo esporre su Tomcat, ma a parte questa differenza vale quando già discusso per Apache.