IKEA!
Qualche volta penso che la "tecnica Ikea" (il piolo 'a' nel buco 'b') si sia sparsa dalla costruzione di mobili ed altri aggeggi fisici anche al mondo del software. Il guaio e' che quando qualche cosa va male con una libreria dell'Ikea si puo' sempre infilarla nel secchio dell'immondizia ed andare con un bello scaffale di ferro, se qualche cosa va male con una delle tante webapplicascion invece...
E adesso che il prologo e' fatto, andiamo a parlare dell'odierno casino. "Odierno" in questo caso e' un ossimoro dato che ho bestemmiato per 4 o 5 giorni su questo casino. Allora, c'e' una bella (si fa per dire) dittarella che ha sviluppato l'ennesimo CMS che oramai ce ne sono bizzeffe in giro. Caratteristica particolare di questo cms e' che e' prodotto in olanda (dicono loro) e quindi il supporto teNNico e' puramente olandese. Almeno, se fornissero del supporto teNNico, dato che non lo fanno.
Comunque sia, circa un anno fa (maro' come passa il tempo), $ditta ha deciso di subireadottare il suddetto CMS come 'base' per il proprio sito webbe. A parte che io continuo a non capire perche' uno debba avere un CMS se poi ogni volta che si vuole cambiare una virgola l'intero sito deve essere re-installato, ma questo sono io. Tra casini e rilasci l'accrocchio e' andato in produzione e ci e' rimasto per circa un annetto finche'...
Una settimana fa' (circa) il programmatroto incaricato della manutenzione del marasma (che per comodita' chiameremo CL) e' venuto a portarmi la lieta (si fa per dire) novella che c'e' una nuovissima versione del famoso CMS che risolve tutti i problemi della versione vecchia (io manco sapevo che avesse tanti problemi dato che il sito funziona) ed anche di piu'. Ok, dove sta' la fregatura? Semplice: la nuova versione funziona solo ed unicamente con l'ultimissimissima versione di TomCat che, guardacaso, NON E' installato sul server dei tapini. Decisione del programmatroto: si installa la nuovissima versione di TomCat e del CMS immediatamente.
Decisione immediatamente abortita nel momento in cui gli ho detto chiaro e tondo che se qualche cosa non funziona se la risolve lui ed io non voglio sentire assolutamente niente e che il cliente (che paga per il supporto del bacherozzo) deve autorizzare conscio del fatto che il sito del menga puo' andare KO e restarci per svariati giorni (ricordo che installare quell'arnese mi ha preso un bel po' di tempo).
Decisione di ripiego: si installa la merdaviglia sul server di 'test' e si verifica che tutto funzichi prima di portarlo in produzione.
Installare TomCat sul server di test: 10 minuti, installare una nuova istanza dell'applicazione: altri 10 minuti. Vedere che l'accrocchio si rifiuta anche solo di partire: 4 secondi. E poi comincia il vero calvario.
CL - Ma sul server di sviluppo che ho installato in locale funziona tutto perfettamente.
IO - Ottimo. Mettiamo il tuo pc come server di produzione allora?
CL - Hemmm... no, non mi sembra una bella idea...
IO - Ancora meglio. E allora perche' non ti fai venire un'idea di che cosa puo' andare male in questo arnese? Lo hai fatto tu.
CL - Cosa dice nel log?
IO - Ti ho appena fatto notare che il log e' miserandamente vuoto.
Tralascio sul prosieguo della discussione. Comunque dopo un po' mi sono messo a dissezionare questo arnese scoprendo una serie di files .properties che riferivano allegramente ad altri file locati in "C:/..." (sul pc di CL probabilmente). Rimessi a posto i vari files abbiamo anche scoperto un altro piccolo snafu: il server di produzione ha tomcat locato in /usr/local, mentre il server di 'test' lo ha in /var/lib. Ora, io tralascio i commenti che mi sono venuti spontanei quando ho scoperto la locazione della cosa (del tipo "cosa minchia ci fa tomcat qui dentro??!??!") ma tanto e'... il guaio e' che e' difficile avere dei files di configurazione e script che si riferiscono a /usr/local sperare che funzionino quando il tutto e' in /var/lib no? Un symlink dopo le cose gia' sembrano meglio.
Ora, una delle particolarita' di questo coso e' che puo' funzionare in 3 modi diversi: puo' leggere i suoi dati direttamente dal database (normale), puo' costruire il database da una serie di files .xml oppure puo' costruire entrambi (il database ed i files xml) dai dati forniti nell'applicazione. Si potrebbe discutere molto di quale logica vi sia nella cosa ma e' cosi' e quindi io non mi metto nemmeno a discutere. Comunque sia, il problema e' che l'avvio del sistema con database vuoto e senza files .xml richiede circa un quarto d'ora durante la quale l'applicazione lavora come un castoro in overdose da caffeina per produrre tutti i suoi files di appoggio ed il database e poi comincia a funzionare. Quindi un "full restart" non e' esattamente una cosa che voglio fare molto spesso... tuttavia, in molti casi l'unico modo per capire se questo coso e' funzionante oppure no e' proprio un full-restart, il che significa che l'operazione di debugging non e' proprio rapidissima.
CL comincia a lamentare il fatto che sul server di produzione le librerie (.jar) sono tutte concentrate nella tomcat/lib, mentre sul server di test sono nella directory lib dell'istanza. Gli faccio notare un paio di volte che sul server di produzione gira UNA versione di tomcat con UNA istanza ed UNA applicazione, quindi non ha senso avere dozzine di librerie sparse per il sistema, mentre sul server di test vi sono almeno 3 diverse versini di tomcat con una dozzina o giu' di li' di istanze ed altrettante applicazioni per istanza. Poi si lamenta che la porta su cui l'istanza ascolta non e' 8080 come sul server di produzione (vedi sopra) e cosi' via.
Dopo un lavoro di ricerca e modifica certosino per sistemare le millemila cazzate sparse in giro (i server di test hanno la tendenza ad incasinarsi parecchio), riesco finalmente a far partire questa mostruosita' ed avere l'applicazione avviarsi.
Un bel mattino arrivo in ufficio e vedo che CL ha mandato una bella (si fa per dire) mail che annuncia che "oggi facciamo le ultime prove e poi voglio fare un rilascio in produzione". Cioe'... il coso ancora non funziona al 100% e tu vuoi fare il rilascio in produzione? Ma sei scemo o cosa?
Ovviamente dopo 10 minuti e' qui' al mio tavolo che si lamenta. Pare che una delle cose che non funzionano sia il "preview" del sito, che si attiverebbe dal CMS facendo una certa cosa. Sul sito di produzione si vede il sito (e che dovrebbe vedersi senno'?) mentre sul server di test si becca una bella pagina bianca mentre il log si riempie di errori. CL lamenta che manca una qualche libreria. Io gli faccio notare che "NoClassDefFoundError" non e' la stessa cosa di "ClassNotFound". Dopo una ricerca nell'inutile Wiki messo in piedi dai produttori dell'inutile CMS, salta fuori che il problema potrebbe essere nell'assenza di una certa libreria. Che pero' e' presente nella /lib dell'applicazione stessa.
Le madonne scorrono a fiumi e l'applicazione continua a non funzionare. CL continua a lamentarsi sulla configurazione di Apache ('azzo c'entra??) ma quando lo faccio contento e copio/incollo la configurazione suggerita sul sito dei produttori del moccolo, si scopre che quella configurazione funziona ancora meno (la mia non manda il browser in loop infinito di redirect). Alle 4 del pomeriggio dico a CL di scordarsi un rilascio per quel giorno e magari per quella settimana e me ne vado a casa.
Il giorno dopo sono pronto per un altro match, poi mi viene in mente una cosa: una delle tante librerie di quel coso era presente nella /lib dell'istanza e duplicata nella lib dell'applicazione da cui poi fu rimossa perche' nel log apparivano dei messaggi di doppia definizione di certe cose. Tuttavia, gli stessi messaggi appaiono nel log del server di produzione. Percui si rimette la libreria duplicata e verifichiamo. Lo and Behold! il "preview" ricomincia a funzionare.
Risultato: una settimana di passione per installare il merdaviglioso cms e la sua applicazione (che a me pare identica a quella vecchia eh). Il cliente si ritrova un numero impressionante di ore di lavoro per un sito che sembra identico a quello vecchio e se io avessi caricato le ore di lavoro direttamente a CL lui avrebbe potuto semplicemente girarmi la sua paga del mese.
Io rimango della mia opinione: "aggiornare" cose perfettamente funzionanti solo per il gusto di aggiornarle continua ad essere una pessima idea.
Davide
08/10/2012 08:00
Precedente Successivo
