Gli "Ospiti" della Sala Macchine


Home Page | Comments | Articles | Faq | Documents | Search | Archive | Tales from the Machine Room | Contribute | Login/Register
Nota: i miei commenti (quando ci sono) sono in italico

La storia (infinita?) del $4WC (parte 2)

E dopo un break di 3 giorni (week end piu' un giorno che siam rimasti in sede a lavorare sul vecchio progetto), un aereo preso alle 7 di mattina (con sveglia alle 5, sigh!) ed un'ora in macchina con il buon Manager che ci ha portati di nuovo verso la sede della ditta sommersa dalla neve (ci sono ancora i segni delle unghie sul pavimento di casa mia quando mi hanno trascinato a forza fuori), ricomincia la nostra odissea nel mitologico accrocchio noto come $4WC.

Breve riepilogo per chi si fosse perso la prima parte:

se volessi applicare la logica del $4WC alla vita normale, per farmi un piatto di spaghetti dovrei:

  1. aprire il mobile della cucina e prendere la pentola
  2. uscire sul balcone, scalare il palazzo, calarmi dall'altra parte con una corda per entrare dalla finestra nella stanza di fianco alla cucina a prendere la pasta
  3. saltare dalla finestra e risalire le scale per tornare in cucina
  4. mettere la pentola sul balcone aspettando che piova abbastanza da riempirla
  5. ho tutto, posso cucinare e finalmente ho la pasta!

Dite che esagero? Considerando che i passaggi sopra rappresentano le chiamate, spesso inutili, tramite reflection che il $4WC fa per fare qualsiasi cosa e che il client e' "stupido" quindi ogni cosa che fa si riflette immediatamente sul database (e quindi legge e scrive di continuo)... forse no.

Tirerei in mezzo Davide per un parere, ma poi va a finire che risponde col solito "che c'entro io?" quindi evitero' e continuero' la narrazione.

Dopo aver brevemente ripassato gli orrori della settimana prima con L1, per paura che potessimo dimenticarli?, incontriamo L2, noto anche come Lurch per somiglianza fisica e capacita' oratoria.

Avete presente il classico prof liceal-universitario il cui monotono tono di voce costringe immancabilmente al distacco delle sinapsi e/o all'entrata del cervello in modalita' "gli occhi ti seguono, la testa annuisce, ma in realta' NON stai sentendo quello che viene detto"? Stessa cosa.

Soprattutto, durante i giorni che siamo stati a contatto con questo individuo, spesso e volentieri NON sapeva di che stava parlando, fermandosi quindi a ravanare nel codice alla ricerca di una configurazione una volta, un file un'altra, una spiegazione non imputabile agli influssi degli anelli di Saturno sul perche' la cosa che diceva non era coerente a quanto si trovava scritto nel codice un'altra ancora.

Insomma, il non gia' altissimo morale e' finito sotto i tacchi ed il neurone distaccato allo scopo ha fatto harakiri. Purtroppo pero', prima di tirare le cuoia ha fatto in tempo a far passare alcune informazioni:

Quelli che questi loschi figuri di $Altra_azienda_supermercati si azzardano a definire "batch" sono degli obbrobri scritti in java (i famosi EJB accennati nella prima storia), che con la velocita' degna di un bradipo spalmato sull'autostrada da un tir effettuano operazioni sequenziali sul db tramite CICLI FOR sulle righe risultato delle query. Aprendo e chiudendo connessioni a manetta!

Scopro inoltre che, a parte passare un riferimento al bean a qualche sottometodo infilato in jar per far si che si potesse chiamare un altro metodo del bean stesso (e posso anche starci.. ma allora perche' non fare tutto nel bean, visto che sempre qua si torna?), l'EJB richiama SE STESSO attraverso la sua interfaccia locale!

Abbiamo scoperto poi che fa questi loop allucinanti per agganciarsi alle transazioni dell'application server visto che loro non riescono a gestirle. Tuttavia.. immaginate la botta che abbiamo avuto appena abbiamo visto sta roba!

Il risultato in termini di performance dell'accrocchio qui sopra si puo' tranquillamente misurare in ere geologiche, con un allucinante tempo variabile (a seconda dei casi) dalle 6 alle 8 ore. Ed in questa jungla avremmo dovuto aggiungere (e stiamo, al momento in cui scrivo) la nostra parte per la nuova gestione. Aggiungendo quindi un delta temporale alle elaborazioni gia' lente! Fortunatamente, hanno avuto la saggezza (?) di rendere i batch interrompibili. Come? Facendo loggare un utente "STOP". Prima di ogni operazione, se si trova questo utente loggato, allora si esce dal batch.

Quando l'ho visto, son rimasto senza parole... PL/SQL, questo sconosciuto!! (E no, non possiamo usarlo nemmeno solo per la nostra nuova parte perche' non vogliono. Temo perche' non hanno nessuno che sa usarlo, ma d'altronde non hanno nessuno nemmeno che sa usare Java a quanto posso vedere).

In uno degli attimi di terrore (torpore?), in cui L2 era immerso a ravanare nel codice, CA si e' espresso in una performance da tramandare ai posteri:

ha preso il suo blocco, ha scritto "Lavorate sulla $nome_progetto_vecchio_cliente", ha fatto due passi alle spalle di L2, e ce l'ha mostrato senza farsi vedere. Al che $Io e C1, annuendo impercettibilmente e parimenti impercettibilmente girando i portatili in modo che Lurch non avesse visibilita' di quel che facevamo (d'altronde, pure che l'avesse avuta, era troppo impegnato a produrre il suo ronzio e clickare freneticamente) ed in Desktop Remoto sulle macchine di $Citta'_Pizza_e_Mandolino ci siamo messi a lavorare!

Non avrei mai pensato di poterlo dire, ma... per la prima volta in vita mia sono stato felice di lavorare!!!

Finita questa seconda settimana, fortunatamente piu' corta di un giorno, siamo tornati alla messa in produzione di $nome_progetto_vecchio_cliente e non abbiamo iniziato a mettere le mani nella merdaccia nel $4WC per altri 2 mesi e passa.

Finche' venne marzo e cominciarono gli sviluppi.

-- continua (o forse no e sono morto nel vano tentativo di spurgare il $4WC) --

GattoNero

14/05/2009 16:32

Previous elenco Next

le storie degli ospiti sono in ordine sparso, quindi 'precedente' e 'successiva' possono portare su storie di altri autori

Comments are added when and if I (or the story's author) has the time to check them and after removing junk, phishing and so on. So don't hold your breath. Besides, if your comment doesn't get posted, don't write me about it. Evidently it wasn't worth it.

9 messages post new
Eugenio Dorigatiorrore.... By Eugenio Dorigati - posted 14/05/2009 14:38 - reply
Storia degna di un film dell'orrore. Non oso immaginare il traumatico ritorno a quel progetto senza prenderlo, bruciare ogni copia esistente e riscrivere il tutto come Dio comanda.

--
"Unix IS user friendly. It's just selective about who its friend are"

Tommasoformat By Tommaso - posted 15/05/2009 16:54 - reply

Secondo me fate prima, e meglio a rifare tutta l'applicazione da capo.
Ci guadagnate in tempo, denaro e in salute!!! (Anche perchè eliminate la voce "pillole per la gastrite" dal totale!)

--
Il saggio coltiva Linux...
Tanto Windows si pianta da solo.


GattoNero-AT- Tommaso By GattoNero - posted 15/05/2009 19:27 - reply

> Secondo me fate prima, e meglio a rifare tutta l'applicazione da capo.

Alla fine al cliente importa una sola cosa: costa troppo.
Magari potessimo rifarlo da zero, magari in una tecnologia un pò meno vecchiotta di 5 anni fa..

--
il gattaccio nero


Andrea-AT- GattoNero By Andrea - posted 15/05/2009 23:53 - reply

> Alla fine al cliente importa una sola cosa: costa troppo.

Chi più spende meno spende!

Ma fagliela capire...

--
Andrea


Daniele C.-AT- Andrea By Daniele C. - posted 18/05/2009 15:10 - reply

> Chi più spende meno spende!
>
> Ma fagliela capire...

Scusa, ma mi vuoi dire che tu PUOI fare una cosa simile?!!?

Hai presente Don Chisciotte contro i Mulini a Vento? Ecco, di solito tu sei Sancho Panza, per dire quanto conta il tuo parere.
Quando invece sei Don Chisciotte, stai tranquillo che scoprirai che non sono mulini, ma roccaforti impenetrabili agli arieti della logica o della pianificazione.
Ergo, le possibilità che accettino di ripartire da zero sono, paradossalmente, zero!

--
Don't Make me get my Hambone!!!
http://www.dilbert.com/strips/comic/2009-02-19
---
D.


anonymousDatabase e Java By anonymous - posted 15/05/2009 20:31 - reply

Solita storia, spendono $cifrone per un database (Oracle, DB2, SQL Server, quello che volete) e poi passano il tempo a reinventarsi la ruota (join, integrità, ecc. ecc.) sull'application server per non diventare "dipendenti dal database" - hai speso $cifrone per il database, no? Sfruttalo almeno! Tanto da qualcosa la tua applicazione dipende: linguaggio, librerie, application server, ecc. ecc. Se dipende anche dal database che cosa cambia? Pensi di cambiare database una volta l'anno, dopo che l'ha riempito di dati e addestrato il personale alla gestione?

--
anonymous


Daniele C.-AT- anonymous By Daniele C. - posted 18/05/2009 15:14 - reply

> Pensi di cambiare database una volta l'anno, dopo che l'ha riempito di dati e addestrato il personale alla gestione?

No, ma fa sempre bello poter dire: "Io posso farlo!!" e, sebbene sembri incredibile, a molti manager basta questo per attivare un progetto di proporzioni bibliche.

Poi ci sono i manager taccagni, che ti chiedono la Ferrari e poi si lamentano se la fai pagare più di una 500...

--
Don't Make me get my Hambone!!!
http://www.dilbert.com/strips/comic/2009-02-19
---
D.


anonymousLOL By anonymous - posted 01/06/2009 14:59 - reply

So (diciamo che.. ci sono passato) quello che state passando (e pensando)
Immagino Lurch sia Sa, L1 non so se e' Lo o Ma (penso piu' Ma)..
Se avete cominciato a sviluppare a Marzo ora probabilmente starete cominciando a vedere qualche "funzionalita'" non standard...
.. e, davvero, in bocca al lupo.

P.S.
devo guardare piu' spesso da queste parti.. una volta mi pare di aver anche trovato una storia di un DBA...

--
anonymous


Massimo M.dipendenza da db By Massimo M. - posted 19/01/2010 19:03 - reply

Gia', mai capita sta cosa: un conto e' fare un programma da rivendere a N clienti e che hanno ognuno un db diverso, e allora l'indipendenza dal db e' fondamentale.
ma se hai un db tuo, se sai gia' prima qual'e', se e' un db ben fondato, affidabile e con dietro una ditta solida (leggi ibm od oracle), perche' rendersi indipendenti?
poi tanto anche un programma cosidetto "indipendente" dal db, vai tranquillo che quando cambierai db NON funzionera'.
un po' come la questione dell'indipendenza dalla piattaforma hardware di java. in teoria funziona, in pratica qualche smanettamento lo devi fare.

--
Massimo M.


9 messages post new

Previous tales' list Next


This site is made by me with blood, sweat and gunpowder, if you want to republish or redistribute any part of it, please drop me (or the author of the article if is not me) a mail.


This site was composed with VIM, now is composed with VIM and the (in)famous CMS FdT.

This site isn't optimized for vision with any specific browser, nor it requires special fonts or resolution.
You're free to see it as you wish.

Web Interoperability Pleadge Support This Project
Powered By Gort