Gli "Ospiti" della Sala Macchine


Home Page | Commenti | Articoli | Faq | Documenti | Ricerca | Archivio | Storie dalla Sala Macchine | Contribuire | Imposta lingua:en it | 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

Precedente elenco Successivo

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

I commenti sono aggiunti quando e soprattutto se ho il tempo di guardarli (io o l'autore della storia) e dopo aver eliminato le cagate, spam, tentativi di phishing et similia. Quindi non trattenete il respiro.

In aggiunta: se il vostro commento non viene pubblicato non scrivetemi al riguardo, evidentemente non era degno di pubblicazione.

9 messaggi this document does not accept new posts

Eugenio Dorigati

orrore.... Di Eugenio Dorigati postato il 14/05/2009 14:38

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"

Tommaso

format Di Tommaso postato il 15/05/2009 16:54

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 Di GattoNero postato il 15/05/2009 19:27

> 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 Di Andrea postato il 15/05/2009 23:53

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

Chi più spende meno spende!

Ma fagliela capire...

-- Andrea


Daniele C.

-AT- Andrea Di Daniele C. postato il 18/05/2009 15:10

> 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.


anonymous

Database e Java Di anonymous postato il 15/05/2009 20:31

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 Di Daniele C. postato il 18/05/2009 15:14

> 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.


anonymous

LOL Di anonymous postato il 01/06/2009 14:59

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 Di Massimo M. postato il 19/01/2010 19:03

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 messaggi this document does not accept new posts

Precedente elenco Successivo


Il presente sito e' frutto del sudore della mia fronte (e delle mie dita), se siete interessati a ripubblicare uno degli articoli, documenti o qualunque altra cosa presente in questo sito per cortesia datemene comunicazione (o all'autore dell'articolo se non sono io), cosi' il giorno che faccio delle aggiunte potro' avvisarvi e magari mandarvi il testo aggiornato.


Questo sito era composto con VIM, ora e' composto con VIM ed il famosissimo CMS FdT.

Questo sito non e' ottimizzato per la visione con nessun browser particolare, ne' richiede l'uso di font particolari o risoluzioni speciali. Siete liberi di vederlo come vi pare e piace, o come disse qualcuno: "Finalmente uno dei POCHI siti che ancora funzionano con IE5 dentro Windows 3.1".

Web Interoperability Pleadge Support This Project
Powered By Gojira