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 qui)
  • 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 qui (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.

Ti potrebbero interessare

Youtube Advertising, la pubblicità su YouTube

Youtube ha ormai raggiunto più di un 1 miliardo di ore al giorno di video suddivise fra circa 30 milioni di visitatori. Una popolarità straordinaria che apre le porte anche alla possibilità di fare pubblicità attraverso la [...]

Google Analytics, le nuove funzionalità per migliorare il ROI

Negli ultimi giorni Google ha annunciato cambiamenti radicali per Analytics con l’inserimento di quattro funzionalità che rivoluzioneranno l’approccio che gli utenti hanno nei confronti di questo utilissimo strumento. Le 4 [...]

Cos'è un funnel di vendita

Cos'è un funnel di vendita

In una strategia di digital marketing è fondamentale comprendere cosa sia un funnel di vendita e come portare un utente ad acquistare un prodotto del proprio ecommerce

Quando le persone visitano il [...]

Cisco
DELL
Intel
NetApp
OnApp
Ripe