Tales from the Machine Room

Code [re|ab]use

Solo che il cliente si gestisce lui la manutenzione del sito, scrivendosi il codice per cavoli suoi, quindi il debug e' affare suo.

Dopo di che non ne sentii piu' parlare per un bel po', fino a Lunedi', quando UL (il mio nuovo capo) arrivo' con questa bella notizia...

UL - Quindi lui viene qui' questo giovedi' con il computer di sviluppo e noi dobbiamo dargli una mano a trovare il casino.
IO - Guarda che il problema non glielo risolviamo giovedi'. E neanche venerdi'.
UL - Perche' no?
IO - Perche' non e' un problema di configurazione, e' un problema di programmazione e per risolverlo l'unica e' fare del debug del sistema, ed io non so una mazza di come funziona quel sistema.
UL - Ma funziona perfettamente sul server di sviluppo! Si tratta solo di prendere i parametri di configurazione del server di sviluppo e riportarli in produzione!
IO - Se fosse cosi' lo avremmo fatto da tempo, ma non e' cosi'.

Cosi' giovedi' mi arriva questo tizio, attacco il suo computer e, con l'ausilio di CB che ne sa' molto piu' di me di programmazione di questo cacchio di $applicationserver, ci mettiamo a guardare la cosa. Ovviamente UL ha voluto rendere chiaro che era molto interessato alla cosa, passando ogni 5 minuti a chiedere come andavano le cose...

IO - Senti, qui' possiamo fare due cose: possiamo DIRTI che non stiamo facendo niente o possiamo FARE qualche cosa. Scegli.

Dopo di che' UL ha deciso che poteva resistere senza un aggiornamento ogni 5 minuti. Abbiamo cominciato percio' con un bel controllo di quale e' il "problema".

Questo cacchio di sito ha una parte relativa alla "vendita" di roba, ogni prodotto ha una descrizione ed altre cose. Apparentemente la descrizione viene memorizzata nel database o letta dal database in modo errato perche' i caratteri giapponesi risultano completamente sballati, mentre un altro campo sulla stessa maschera risulta perfetto. Se un campo funziona e l'altro no mi sembra ovvio che non e' un problema di configurazione. Ci mettiamo percio' a guardare il codice. E qui' incomincio a vedere delle cose abbastanza oscene. Per prima cosa la tabella del database contiene 127 campi...

Ok, vediamo cosa cavolo mette in quel campo
SELECT nomecampo FROM tabella WHERE prodotto=idprodotto
NULL
?? NULL ??? come sarebbe a dire NULL ??

Controllo meglio e scopro che quasi tutti i campi della tabella sono nulli... e da dove cavolo li piglia i dati allora?? Cosi' scopro che le informazioni che sono visualizzate a video vengono imballate in una unica hashtable che viene poi serializzata in un unico campo BLOB... lo stesso campo BLOB viene poi letto e deserializzato per ottenere le informazioni... per fare cio' l'accrocchio utilizza un Bean. Il campo che risulta corretto si trova in tale Blob, mentre quello scorretto e' letto dal corrispondente campo VARCHAR del database. Ok, mettiamo TUTTE le informazioni nel blob allora, modificando il Bean.

Dopo un po' di hacking sembra che le informazioni vengano visualizzate e memorizzate correttamente. A questo punto facciamo qualche prova e... non funziona... cioe', nella parte di sito riservata al "back office" funziona tutto correttamente, mentre nella parte "utenti" continua a visualizzare le cose sbagliate... WTF???

E cosi' scopro che, per ogni singola pagina, c'e' un diverso Bean per recuperare le informazioni dal database, mentre qualche pagina addirittura non usa nessun Bean ma legge i dati direttamente...

Inoltre non e' solo quel campo che viene gestito in modo diverso, ma sono molteplici...

Ma chi cacchio ha scritto questa chiavica di codice???

/* Code By Mammalucco Yugoslavo mammalucco@yugoslavia.yu */

...ci avrei giurato...

A questo punto torna alla carica UL.

UL - Allora, trovato niente?
IO - Si', ho trovato che questo e' RFUC.
UL - ?? he?
IO - Really Fooled Up Code
UL - E che possiamo fare?
IO - Io vedo solo 3 possibilita'. Assumendo che sulla macchina di sviluppo funziona correttamente. 1) Si piglia la macchina di sviluppo e la si mette al posto di quella di produzione, 2) si perde il tempo a modificare ogni singola pagina mettendo a posto i vari bean o meglio ancora riscrivendo i vari pezzi in modo da avere UN bean e non diecimila, 3) si rimanda il tutto agli Yugoslavi che se lo sistemino loro dato che le cazzate le hanno fatte loro.
UL - Hemmm... c'e' un problema...
IO - Solo un o?
UL - La versione giapponese deve essere in produzione lunedi'...
IO - ...adesso lo dici? In tal caso le soluzioni sono solo due, la 1) di prima e la 2) si lascia tutto come sta, il sito in giapponese lo si fa funzionare in inglese e si riesaminano le possibilita'.

Davide
15 Marzo 2004

previous next