Come installare un ambiente WAMP (Windows, Apache, MySQL, PHP) sul proprio PC

Questa guida è datata. La versione aggiornata è presente al seguente link: Come installare un ambiente WAMP (Windows, Apache, MySQL, PHP) sul proprio PC (aggiornamento 2014).

La maggior parte dei siti web oggi in circolazione si basa su una soluzione a stack di software open source nota come LAMP: Linux, Apache, MySQL e PHP (Se al posto di Linux c’è Windows si parlerà di WAMP). Continua la lettura di Come installare un ambiente WAMP (Windows, Apache, MySQL, PHP) sul proprio PC

Spunti per una strategia di Disaster Recovery efficace

Al giorno d’oggi l’importanza delle informazioni e dei dati per le aziende è vitale, infatti citando wikipedia:

For example, of companies that had a major loss of business data, 43% never reopen and 29% close within two years.fonte:wikipedia

Quindi in sostanza quasi la metà delle aziende che subiscono una grave perdita di dati sono destinate a chiudere.

Può non sembrare, ma la probabilità di perdere dati importanti è molto alta, solo per fare un esempio può verificarsi a seguito di:

  • errori umani (es. per sbaglio “facendo pulizia” nel computer si cancella un file di troppo; dopo aver editato un file al posto di scegliere “Salva con nome…” si preme “Salva” ed ecco che la versione originale del file è persa.);
  • guasti (es. si rompe il disco rigido su cui erano memorizzati i dati, si danneggia la chiavetta USB, si riga il CD/DVD ecc.)
  • minacce informatiche (es. virus che cancella i dati del computer, virus che cifra i documenti presenti sul computer e chiede il riscatto ecc.)
  • furti (es. il ladro ruba i computer dell’ufficio e il server su cui erano memorizzate tutte le anagrafiche)
  • disastri (es. incendi, allagamenti ecc.)

Inoltre, anche qualora un’azienda abbia fatto delle copie dei dati importanti molte volte recuperarli (sperando che siano in buono stato) e ripristinarli richiede molto tempo (tipicamente giorni) che influisce sensibilmente sulla produttività aziendale e di conseguenze sulle perdite di denaro.

Fortunatamente con gli appositi strumenti informatici è possibile predisporre le misure tecnologiche e organizzative necessarie a far sì che i dati che perderete vengano ripristinati in scioltezza.

Come probabilmente avrete capito l’unico modo di evitare la perdita irreparabile di dati è quella di fare una copia degli stessi (copia di backup).

Questo però da solo non basta, nel seguito di questo articolo vedremo come predisporre un sistema di disaster recovery con i seguenti punti di forza:

  • backup e ripristino dei dati veloce e il più possibile automatizzato;
  • backup alla scadenza temporale preferita (giornaliero, settimanale, ogni ora, ogni minuto, ecc..).
  • copia remota dei dati (es. copia dei dati dal server in ufficio verso un computer di un’altra sede) in modo da mettersi al riparo da furti o disastri naturali;
  • backup incrementale, ovverto vengono copiate solo le ultime modifiche dei dati rispetto all’ultimo backup, in questo modo la velocità nell’effettuare un backup aumenta sensibilmente.
  • occupazione dei backup estremamente ridotta;
  • possibilità di vedere le varie versioni storiche di un documento potendo andare indietro nel tempo, nel modo più immediato possibile (Macchina del tempo).

Per raggiungere gli obiettivi sopra esposti è necessario predisporre un’infrastruttura come quella in figura.

A disaster recovery scenario

L’esempio mostra la sede di un’azienda più un secondo luogo sicuro che potrebbe essere ad esempio la seconda sede.

Il backup è fatto a due livelli.

  1. I file importanti dei computer della rete della sede 1 (es. file autocad, pdf, documenti word, excel, ecc.) sono copiati e storicizzati sul server 1.
  2. I file importanti del server 1 e i backup della rete della sede 1 sono copiati e storicizzati sul server 2.

Come si vede in figura è importante che il server 2 si trovi in una posizione geografica ragionevolmente distante dal server 1. Questo per evitare che un evento disastroso che dovesse coinvolgere il server 1 possa interessare anche il server 2 (esempi di eventi disastrosi possono essere: terremoti, allagamenti, furti, incendi ecc.).

I server e i computer della rete vanno configurati come segue:

Server:

  • Sistema Operativo: Una distribuzione Linux per Server. Ad esempio l’ultima Ubuntu Server Long Term Support.
  • Programmi: un server SVN + rsnapshot

Computer della rete:

  • Sistema Operativo: Windows
  • Programmi: un client SVN (es.  Tortoise SVN)

Il server SVN e i rispettivi client SVN installati sui computer della rete servono a eseguire il primo livello di backup. Ogni client può salvare i propri file sul server, copiare i file salvati da altri client e vedere le versioni storiche di uno stesso file in modo da poter consultare tutti i cambiamenti subiti da un file e poter ripristinare una versione precedente di un file.

Il tool Rsnapshot consente invece di implementare il secondo livello di backup. Ovvero consente di effettuare una copia tra i due server che può essere schedulata con una granularità temporale a scelta (es. ogni giorno, ogni ora ecc.). Inoltre in modo facile è possibile consultare “fotografie” dei file copiati nei vari giorni e poter aprire una versione vecchia direttamente con un doppio click.

Quali sono i dati importanti per avere un preventivo preciso?

La richiesta di un preventivo è la fase più delicata per lo sviluppo di una soluzione su misura:

  • più le richieste sono poco dettagliate e più il preventivo sarà approssimativo, sarà possibile cioè dare solo un’idea a grandi linee di tempi e costi;
  • più le richieste sono poco dettagliate e più tempo sarà necessario per redigere il preventivo.

Questo articolo vuole quindi essere una guida per aiutare i Clienti a formulare richieste il più preciso possibile in modo da avere preventivi altrettanto precisi e in tempi ragionevoli.

A questo proposito è utile seguire questa traccia:

  1. Esiste già una soluzione che fa buona parte di quello che serve al Cliente?
    1. Sì: questa soluzione è modificabile (è ad esempio open-source)?
      1. Sì: quali sono le modifiche richieste per raggiungere l’obbiettivo?
      2. No: bisogna sviluppare una soluzione da zero;
    2. No: bisogna sviluppare una soluzione da zero;

 
Nel caso in cui la soluzione richiesta non sia banale, bisogna sempre tener presente che svilupparla da zero è molto più costoso che modificarne una già esistente.

Nel caso 1.1.1 cioé modifica di una soluzione già esistente è bene chiedere direttamente allo sviluppatore il quale, se disponibile, probabilmente farà il preventivo più conveniente.

Il caso che riserva più sorprese sia allo sviluppatore che al Cliente è indubbiamente l’1.1.2: richiesta di sviluppo da zero di una soluzione copiandone una già esistente.

In questo caso tipicamente il Cliente ha una percezione ridotta del set di funzionalità implementate nella soluzione da copiare e cioè ne vede solo una parte (quella che gli interessa di più) dando per scontato tutto il resto.

Inoltre, sempre in questo caso, il Cliente può venire polarizzato dal prezzo di vendita della soluzione da copiare e aspettarsi pertanto una cifra analoga senza tener presente che il prezzo di vendita di una soluzione venduta a tanti non può essere la stessa di una soluzione sviluppata ad hoc per una sola realtà.

Nel caso per esempio delle estensioni i prezzi di mercato si aggirano sulle poche decine di dollari, questo ovviamente non significa che per svilupparli siano bastate poche decine di dollari: il produttore dell’estensione la può vendere a cifre irrisorie a patto che a comprarla siano migliaia di persone es. 20 dollari per 1000 persone uguale 20000 dollari, tutt’altra questione.

Tipicamente i siti che vendono queste estensioni riportano il numero di download o di acquisti. Per farsi un’idea delle cifre coinvolte è bene quindi fare la moltiplica.

Senza dilungarsi troppo, per altri ragionamenti sul costo di un software e su quanto vale un software si può approfondire con i seguenti articoli:

Tipicamente è in questo caso che il preventivo risulta più alto delle aspettative del Cliente e richiede maggior tempo per essere redatto con il conseguente rischio che venga rifiutato.

Al Cliente conviene quindi sforzarsi di isolare le uniche parti che gli servono davvero.

Questo lavoro può essere fatto solo dal Cliente e prevede che quest’ultimo rifletta attentamente sulle funzionalità che sono per lui di primaria importanza e quali sono invece quelle non necessarie.

Tanto sarà più preciso in questa fase tanto minore sarà l’importo e i tempi di sviluppo del preventivo.

Per fare un esempio ipotizziamo che un cliente, proprietario di un hotel, dopo aver saputo la commissione richiesta da siti come booking.com per inserire le proprie offerte, decida di farsi fare un preventivo per lo sviluppo di una soluzione simile a booking.com da ospitare sul sito del proprio hotel e che gli consenta di gestire in prima persona le prenotazioni per la sua struttura.

A questo punto, se la richiesta di questo ipotetico Cliente si limitasse ad essere “vorrei una soluzione simile a booking.com per il mio hotel” avrebbe come risposta un preventivo da decine di migliaia di euro e diversi mesi di lavoro.

Questo perché le funzionalità di booking.com intanto non sono solo quelle visibili direttamente sul sito, ma c’è anche tutta la parte di amministrazione.

Inoltre non bisogna dimenticare che booking.com avrà un team di sviluppatori che da anni mantengono sviluppato un sistema del genere sul quale l’intera società fa profitto interagendo con centinaia di albergatori in tutto il mondo.

E’ pertanto ingenuo pensare che un sistema del genere possa avere un costo alla portata del singolo utente.

E’ anche vero che in realtà al Cliente non servono tutte le funzionalità implementate da booking.com, magari gliene servono solo un decimo.

Isolare le sole funzionalità necessarie è la chiave per raggiungere l’obbiettivo senza spendere un capitale.

Un modo per capire quali sono queste funzionalità è quello di immedesimarsi negli utenti del sistema e chiedersi di volta in volta come avviene l’interazione con esso.

Es.: l’utente effettua una prenotazione.

  1. l’utente si collega al sito;
  2. l’utente inserisce i dati della propria prenotazione: data di arrivo, data di partenza, numero di persone;
  3. il sistema propone le soluzioni disponibili nel periodo di tempo specificato mostrando per ogni soluzione l’importo complessivo;
  4. l’utente sceglie la soluzione che preferisce;
  5. l’utente conclude la prenotazione inserendo i propri dati anagrafici e i dati della carta di credito;
  6. il sistema effettua la transazione;
  7. il sistema notifica al cliente il buon esito dell’operazione inviandogli una mail riassuntiva della prenotazione effettuata;

 
Alternativa 4: nel caso in cui il sistema non abbia trovato soluzioni che soddisfino i parametri specificati mostra un messaggio all’utente e lo invita a telefonare per mettersi d’accordo con i gestori dell’hotel.

Alternativa 5: il sistema dopo aver verificato che i dati immessi non sono corretti notifica all’utente l’errore e richiede nuovamente l’inserimento dei dati corretti.

Il modo sbagliato per descrivere il caso d’uso dell’esempio precedente sarebbe stato:

  1. l’utente si collega al sito;
  2. l’utente effettua la prenotazione;

 
Il punto 2 è troppo vago e sottintende un mondo di possibilità: può risultare ovvio per il Cliente, ma non certo per lo sviluppatore il quale può non conoscere il dominio applicativo.

Quando si specificano le funzionalità richieste bisogna cioè mettersi nei panni anche di chi le dovrà implementare.

Un altro modo utile per definire i dettagli delle funzionalità richieste è quello di disegnare le schermate del sistema nelle varie fasi di interazione, magari anche semplicemente su un pezzo di carta, giusto per avere un’idea ancora più chiara di che cosa dovrà fare il sistema.

Nel caso in cui il problema da risolvere fosse estremamente complicato o estremamente ampio potrebbe essere più conveniente saltare tutta questa fase e optare per uno sviluppo iterativo come descritto nel seguente articolo: Perché un processo di sviluppo iterativo è meglio per il Cliente?.