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:
- Editiamo il file
httpd.conf(o il suo analogoapache2.conf) e cerchiamo al suo interno la stringaDocumentRoot - Commentiamo il valore corrente della direttiva
DocumentRoot, digitando il simbolo#all'inizio della riga - 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_siteseseguiamo 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.
