Warning: array_key_exists() [function.array-key-exists]: The second argument should be either an array or an object in /web/htdocs/www.request.to.it/home/frank/scripts/sb_display.php on line 60
"Abbiamo il DB!" 
venerdì, ottobre 20, 2006, 10:20 - Agile, Dev
Prologo
Ormai è un mese e mezzo che sono su questo nuovo progetto, nuovamente nel centro di ricerca, che ormai di ricerca ne fa ben poca, della <grande compagnia telefonica>. L'applicazione è sviluppata completamente da zero, ripeto da zero!

Ok, cominciamo con il post.

Il primo giorno, riunione del team, dopo le presentazioni di rito, il capo progetto prende la parola ed esclama: "Abbiamo il DB!".
Ok, ma l'applicazione che deve fare? "Abbiamo il DB!". Certo i dati sono importanti, ma forse sarebbe meglio partire dagli aspetti funzionali e modellare il db su questi. Insomma test, green, refactor ad ogni livello :). "Abbiamo il DB!".

Ok, ci adeguiamo, siamo in 4 sviluppatori, siamo agili. Ogni tanto abbiamo bisogno delle modifiche al db, per assolvere a qualche requisito funzionale (ma dai, "Abbiamo il DB!"). Il db prodotto fa schifo, ed è un complimento. Dopo i primi confronti è scontro aperto, ci viene rinfacciato di non sapere fare il nostro lavoro, che quelli sono i dati e su quelli dobbiamo lavorare. Ci viene detto di rileggerci i sacri testi di basi di dati. Visto il prodotto, mi chiedo se qualcuno abbia sentito anche solo parlare di forme normali. Qualche cosa la otteniamo, ma l'ultima battaglia ci vede vincitori per la modifica, perdenti perchè probabilmente sarà l'ultima.

L'individuo che ha progettato il DB non accetta il confronto, impone la sua idea ed ha spostato la questione sul piano personale. E' indisponente, supponente, altezzoso, geloso del suo operato.
Nella sua visione delle cose, ed anche in quella di altre persone come il capo progetto, una volta fatto il db, il resto sono dettagli implementativi.....
Ah, ovviamente il db viene modificato a piacimento da loro... fortunatamente abbiamo scelto hibernate e con gli h8-tools per eclipse rigeneriamo almeno un paio di volte alla settimana gli oggetti di mapping...

Non siamo una banda di imbecilli. Varie volte ho progettato db prima dell'applicazione, ma questo accadeva nella preistoria (vabbè, 475 anni fa :) )! Visto che si parte da zero, e non si sviluppa su un db legacy, il vantaggio sarebbe quello di partire dai requisiti funzionali, che tanto cambieranno 50 volte, ed adeguare la struttura di db ogni volta.

Il software è molle! E lo si può modellare come argilla, se si ha una buona suite di test automatici.

Ci troviamo così nell'assurda situazione di applicazione nuova e db legacy! Con un db che ha meno di 30 giorni di vita, ma sembra essere stato scolpito nella pietra!

E poi, anche nel caso di db legacy, in questi anni sono state sviluppate tecniche di refactoring anche per quelli, vedi il post di Enri sull'argomento.

Stiamo pensando all'ammutinamento. Ci creiamo una nuova istanza e la modelliamo a nostro uso e consumo.

Mi sembra incredibile, nel 2006, vivere queste situazioni. Sarà che sono orientato verso altri modelli di sviluppo, alla comunicazione, al confronto, ma poi mi guardo intorno e vedo che spesso e volentieri è così.

In definitiva, non penso molleremo facilmente.

[ 173 commenti ] ( 3864 visite )   |  [ 0 trackbacks ]   |  permalink  |   ( 3 / 2101 )
Non tutti gli IDE sono uguali 
mercoledì, ottobre 4, 2006, 13:56 - Dev, Eclipse, Software
Un po' di tempo fa mi sono ritrovato faccia a faccia dopo molto tempo con JDeveloper , l'IDE di Oracle. L'ultima volta che ci avevo lavorato era il 2003 su piattaforma Windoze e me lo ricordavo come un incubo. Beh, le cose non sono cambiate molto. Sarà che Eclipse mi ha abituato bene, ma su linux il fanciullo è veramente pessimo.

A esempio fare refactoring è un'operazione lenta, con un sacco di passi di wizard per completare la singola operazione. Ed è già un passo avanti, perchè una volta non c'era nessun supporto al refactoring... ed infatti usavo Eclipse e reimportavo in JDev.

L'interfaccia, in swing, è lenta e farraginosa. E non vuole essere la solita guerra swing vs. swt. Ci sono un sacco di esempi di applicazioni swing veloci. Jdev non è una di queste.

Jdev è grosso, ca 200MB, eppure di default non ha Junit integrato. E' necessario scaricare l'extension apposita. Certo, ha un sacco di roba per lavorare Ejb, Toplink, ADF/BC4J, ma rimane lento e pesante.

Sinceramente, ma perchè Oracle continua a mantenere un prodotto simile? Perchè non migrare ad Eclipse come infrastuttura? Se lo hanno fatto BEA e Borland un motivo ci sarà... Tra l'altro è membro della fondazione e collabora allo sviluppo della parte dedicata ad EJB3.

L'unico che resiste impavido è IDEA di JetBrains. E' molto che non lo uso, ma ne conservo un bellissimo ricordo. Tra l'altro era, e spero sia ancora, molto veloce benchè utilizzare le tanto vituperate swing.

L'IDE è lo strumento che ci deve consentire di essere più produttivi.
JDev non è sicuramente la mia prima scelta :)

[ 59 commenti ] ( 4945 visite )   |  [ 0 trackbacks ]   |  permalink  |   ( 3 / 2442 )
Nessuno ti regala niente, ed i framework non sono da meno 
venerdì, settembre 22, 2006, 15:12 - Dev, Java, Spring, DataBase
Chi mi conosce lo sa. Adoro i framework, non mi piace reinventare la ruota se qualcuno l'ha già fatta, rotola bene ed ha tante persone che la migliorano. Molti progetti open source di successo sono framework che assolvono alle più disparate esigenze: MVC, IOC, O/R mapping, JMX...... Ehi, quante buzzword in una sola riga! Mi manca ESB, SOA, WS :)

Un framework che mi ha dato molte soddisfazioni è Spring, che io definisco un meta-framework, vista la sua capacità di collegare tra loro lo cose più disparate.

Ma veniamo al titolo del post...

Un po' di tempo fa sono stato mandato da un cliente per ingegnerizzare un prototipo da applicazione a servizi. L'applicazione in se non sembra nulla di complesso: axis sul front-end, dei controller/manager/servizi (chiamateli come volete) esposti e dei dao per fare persistenza. Ero a corto, molto a corto, di tempo e know-how, dopo più di 2 anni a fare VOIP.

Ho preso Spring ed usato i suoi DAO. Ho cominciato con dei dao basati su JDBC. Poi mi sono detto: "che palle rimappare i result-sets sugli oggetti di dominio, prendiamo un O/R mapper a caso: hibernate".

E' stato a dir poco un bagno di sangue. A causa della mancanza di tempo, e presa la strada, non sono tornato indietro. Grazie a Spring molte cose mi venivano gratuitamente, ma allo stesso tempo non capivo cosa stava succedendo. Mi dicevo che se tutti lo usano non sarà cosi difficile, ma non faceva le cose che volevo. Ovvero, non faceva le cose come pensavo!
Avendo tempo probabilmente sarei partito utilizzando H8 direttamente per comprendere bene i suoi meccanismi interni, poi avrei spostato le cose in spring utilizzando i dao, facendo poi gestire le transazioni i AOP. Tutto piano piano. Un passo alla volta.
Così invece ho fatto un salto nel vuoto sperando che il paracadute si aprisse.

Ho pagato pegno! Alla fine, seppur di fretta, e grazie alle FS, ho letto parte del manuale, ho fatto prove, tests etc...
Più o meno ne sono venuto fuori, però la prossima volta non lo faccio più.

Prima di usare un framework che non si conosce, per quanto pubblicizzato, fico e trendy, ci vuole del tempo per capirlo ed assimilarlo. Se non si ha a disposizione questo tempo, per fare uno spike, leggere bene la documentazione, confrontare altre soluzioni, è meglio affidarsi alle soluzioni conosciute, magari tediose e/o tecnologicamente arretrate, ma su cui si hanno le idee chiare!



[ 133 commenti ] ( 8532 visite )   |  [ 0 trackbacks ]   |  permalink  |   ( 3 / 2433 )
Callisto è arrivato! 
lunedì, luglio 3, 2006, 09:04 - Dev, Eclipse
Venerdì è arrivato, puntuale come un orologio svizzero.
Potete trovare tutte le info qui.

Essenzialmente vi scaricate il Platform Runtime e poi potete personalizzarvi l'installazione come meglio credete accedendo atraverso l'update manager al Callisto Discovery Site.



[ 1 commento ] ( 1507 visite )   |  [ 0 trackbacks ]   |  permalink  |   ( 3 / 2026 )
La chimera dell'ottimizzazione 
martedì, maggio 23, 2006, 10:19 - Dev, Design
Partiamo dalla legge dell'ottimizzazione:
- non ottimizzare
- (solo per esperti) non ottimizzare ancora

Sono stato coinvolto nel processo di ottimizzazione alla disperata ricerca delle performance. Mettendo insieme tutti i pezzi non si andava oltre le 100cps (Call Per Second), mentre il concorrente dichiara 350cps, stesso profilo di test, hardware inferiore. E' ovvio a tutti che mai raggiungeremo quelle prestazioni, soprattutto perchè il pradigma e completamente diverso. L'application server del concorrente implementa le SIPServlet che sono sincrone, l'AS che usa StarSIP come stack SIP (quindi noi siamo solo di supporto) è completamente asincrone ed event-driven.

Non so come, ma sono diventato l'esperto di ottimizzazione del codice. Visto che sono un po' bastardo, i primi due tool che ho presentato sono stati
pmd e metrics che sembrano non centrare nulla con l'obiettivo. La mia idea è che non puoi pensare ad ottimizzare se non hai del codice quantomeno decente. Non nomino nemmeno test e design che sono concetti un po' lontani dalla cultura del "il più è che funzioni e vada forte"....

Con l'ausilio dei due tool ho scovato tre classine niente male dove c'erano le peggio cose:
- oggetti instanziati in cicli for
- String pippo = new String ("pippo");
- try/catch dentro a cicli
- classi enormi, metodi da 300 righe
Le tre classi offrivano tre metodi che erano i più chiamati su tutto il globo terraqueo:)

Solo dopo si può cominciare a profilare. Dopo aver provato
tptp, un sotto progetto di eclipse, siamo tornati a OptimizeIt. Devo dire ottimo prodotto. TPTP "ammazza" un po' la macchiano sotto profilatura, OptimizeIt la lascia un pochino più viva. Abbiamo scovato sullo stack 4/5 punti dove potevamo ottenere dei miglioramenti prestazionali. Pochi cambiamenti al codice, ma visto che è codice eseguito ad ogni messaggio, ovvero almeno 100 volte al secondo, capite come anche 1ms di guadagno possa essere importante.

Molte delle ottimizzazioni fatte potevano essere evitate con un po' di buon senso e migliore conoscenza della tecnologia. Molto del design non fatto poteva essere fatto anche senza conoscere Java :)

Il terzo aspetto di questo processo è il tuning della JVM: heap, garbage collector....
Alla fine le impostazioni sono solo relative alla dimensione dell'heap (-Xms), mentre per il gc meglio lasciar fare alla jvm 5.0 che si autoregola da sola meglio che con impostazioni fissate :)

Adesso un po' di link:
- JVM tuning per incremento performance
- scrivere codice ottimizzato

[ 41 commenti ] ( 5348 visite )   |  [ 0 trackbacks ]   |  permalink  |   ( 3 / 570 )

Altre notizie