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
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 ] ( 4961 visite )   |  [ 0 trackbacks ]   |  permalink  |   ( 3 / 2455 )
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 ] ( 8598 visite )   |  [ 0 trackbacks ]   |  permalink  |   ( 3 / 2453 )
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 ] ( 1511 visite )   |  [ 0 trackbacks ]   |  permalink  |   ( 3 / 2032 )
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 ] ( 5359 visite )   |  [ 0 trackbacks ]   |  permalink  |   ( 3 / 579 )
Evitare la complessità 
martedì, maggio 16, 2006, 10:53 - Dev, Design
Io non so per quale ragione, ma ai programmatori piace la complessità. Ne sono attratti, se riescono a fare una cosa complessa, pensano che sia bellissima.

Personalmente, e lo ribadisco ogni volta, sono stupido: nella complessità mi perdo. Se una classe implementa più di due interfacce... sono fottuto :)

Nella <grande compagnia telefonica> dove sono in consulenza il software su cui opero è frutto della stratificazione di anni di lavoro: è pieno legacy!. In questi due anni ne ho prese parti, le ho smontate, revisionate, semplificate. Di molte classi ne ho fatto uno spezzatino!

Una cose che mi piace è delegare. Come tutti, all'inizio della mia esperienza in OOP sono stato affascinato dalla ereditarietà, fortunatamente il mio tasso di stupidità mi ha frenato molto presto.

Io preferisco la composizione. Classi piccole che composte fanno il "tutto". Ogni componente fa poco e poi delega a qualcuno che, nel mio caso, è "sopra". Io sono su di una "pila" protocollare, quindi c'è quasi sempre un livello superiore.

Il cuore dell'applicativo, nella sua precedente versione, era una gerarchia di tre classi da 5000 righe ciascuna. E' facile comprendere che spesso nelle riunioni tecniche mi debba scontrare con una "cultura" lievemente diversa. Ogni volta devo combattere strenuamente per adottare la soluzione più semplice.

Ma poi, come è successo l'ultima volta, tutto ciò che abbiamo disegnato al mattino sulla lavagna è stato stravolto e complicato nel pomeriggio durante la redazione di un documento riassuntivo.

Ma ce la farò anche questa volta, ne sono certo. La complessità non vincerà!





[ 11 commenti ] ( 1527 visite )   |  [ 0 trackbacks ]   |  permalink  |   ( 3 / 520 )

Indietro Altre notizie