Newsgroup: it.comp.java
Titolo: Qualcuno usa VisualAge for Java?

Sicuramente nel grigio mondo degli sviluppatori professionisti schiavi di
IBM c'è qualcuno che usa VisualAge for Java. Mi chiedevo se ce ne fossero
altri??!?! è mai possibile che io non possa avere un sano scambio di
opinioni con qualcuno
che non sia affetto dal morbo della demo o che prenda soldi da Big Blue? Per
esempio, mi piacerebbe avere un parere spassionato sulla
programmazione visuale: porta veramente dei vantaggi nella produttività? Per
quanto mi riguarda mi permette di secernere interfaccia grafica molto
velocemente, peccato che debba passare le giornate a trovare i bachi nei
suoi metodi del cazzo firePropertyDiQua e firePropertyDiLà. è così o è solo
il disagio del principiante. è così o devo scaricarmi qualche tonnellata di
patches dal merdoso sito di big blue. Per inciso: loro le patches le
chiamano rollup, sa un po' di carta igienica oppure di "facciamoci una
canna"! Mi piacerebbe sapere perchè quando si
programma nel VCE lo spostamento degli oggetti risulta così pesante. perchè
posso cambiare le proprietà a molti oggetti contemporaneamente se poi il
tempo che ci mette è la somma dei tempi delle singole operazioni aumentata
di un tot (e una colossale rottura di palle ad aspettare il che qualcosa si
muova senza
neanche l'ombra di una clessidra)? Ho un Pentium 350 con 128 Mb di RAM e un
HD da 6 Gb semi vuoto.
Forse devo mettere una scheda grafica poderosa di quelle che non fanno una
piega con Tomb Rider, Fifa 99 e 18 mpeg in esecuzione tutto nello stesso
istante!?! Ok,
non vorrei dilungarmi troppo, comunque dovreste aver capito, naufrago
VisualAge cerca compagnia sulla sua zattera sperando che qualcuno legga
questo "message in a bottle". VACiao!

 [..]
La prog. visuale ha un grande vantaggio di produttivita' per quanto
riguarda la costruzione grafica della gui, come e' ovvio :) dato  che
ci si mette decisamente meno a *posizionare* gli elementi che con la
codifica diretta (chiunque abbia mai usato le curses o TurboVision
confermera' :).
Per quanto riguarda quello che io chiamo "codice di reazione", la mia
impressione e' che non ci sia una grande differenza nell'uso di
*ambienti* visuali (tantomeno poi quando - come VA - sono decisamente
macchinosi e ingombranti), anzi - codificare direttamente le risposte
(magari con l'aiuto di alcuni tools che generano codice di delegazione
etc) e' spesso la scelta migliore, dato che quello che si perde in
tempo di scrittura iniziale lo si guadagna in conoscenza diretta del
codice e quindi in efficienza in debug e manutenzione - senza contare i
promblemi dovuti all'uso di librerie proprietarie (ad es. quella
symantec) che replicano componenti standard ma con un comportamento
leggeremente diverso.
Di conseguenza, la programmazione "a frecce" di VA non e' che mi
attragga troppo: in effetti, usandola bene, e posto che l'ambiente di
sviluppo e le librerie non abbiano bug (assunzione decisamente forte!
;-) puo' velocizzare la scrittura di codice semplice... ma se un
programmatore e' in grado di usarla "bene", e' piu' che probabilmente
in grado di scrivere ottimo codice altrettanto in fretta per i fatti
suoi - senza dover passare per le macchinosita' di cui parli.
Questi sono in miei $0.10, naturalmente. :)
-cs
--
God is Real, unless declared Integer
Sent via Deja.com 
http://www.deja.com/
Share what you know. Learn what you don't.

 confermera' :).
In teoria forse si, ma in pratica, almeno personalmente, non riesco a costruire
una gui piu' in fretta con un ambiente visuale, perche' quello che vedi non e'
quasi mai quello che realmente ottieni. Eppoi una volta presa dimestichezza con
GridBagLayout riesco a costruire gui decisamente piu' velocemente a mano.
Secondo me il vantaggio che hanno i tool di sviluppo sono le librerie e i beans
che incorporano, ad es. per l'accesso ai dati o per corba ecc...
----
Luca Giuranna - jagui@_
zz_bigfoot.com
 -
(to reply remove "_zz_")
- JPress 0.1 beta 1 -

 quasi mai quello che realmente ottieni.
va beh, ma si parlava di Visual Age che mi sembra che non abbia di
questi problemi (non sono mica tutti uguali)
--
Greetings, Alessandro
http://www.esalab.it
Pesaro, Italy


 che incorporano, ad es. per l'accesso ai dati o per corba ecc...
Si', da questo punto di vista Java e' particolare - i LayoutManager
semplificano la vita *anche* a livello programmativo - non devi
generalmente specificare coordinate.
Tuttavia, per dialog complesse, la mia personale esperienza e' che ci
si mette meno tempo a disegnarle che a descriverle. Chiaramente, ognuno
ha le sue preferenze. ;-)
Per quanto riguarda le librerie - specie per accesso a dati e corba -
non mi trovi d'accordo: dato che esistono componenti standard o
quasistandard (JDBC, com.sun.corba.*) la mia scelta e' al 99% di usare
questi - magari costruendoci qualcosa su - che non componenti
proprietari forniti con l'ambiente di sviluppo: manutenzione e
deployment sono piu' gestibili, e i componenti proprietari, a meno di
casi particolari, non offrono cosi' tante funzionalita' in piu' da
valere la candela.
--
God is Real, unless declared Integer


 
Concordo pienamente con te. 
Ricordiamoci che una buona progettazione è fondamentale per ottenere
codice
robusto e manutenibile. 
Come ho già detto nel post precedente, quello degli ambienti RAD è più
uno
specchietto per le allodole, un espediente per vendere ide.
Io non sono mai riuscito a sviluppare applicazioni coi controfiocchi in
poco
tempo. 
Sarò ben felice di essere smentito.
Buon lavoro.
-- 
+---------------------------+
| Roberto Bagnoli           |
| 
robe...@comune.modena.it
 |
+---------------------------+

Ho usato per un po' Visual Age for Java 2.
Sinceramente mi sembrava bello, ma non fantastico per il semplice fatto che
era troppo povero di bean (e non è vero che un bean sviluppato su un
ambiente funzioni sempre nell 100% dei casi su un altro.... difficile dire
di chi siano i bug dopo...)
Sicuramente ha qualche bug, ma niente di irrisolvibile.
Sicuramente è lentissimo e la gestione del repository è un incubo.
A me piacciono gli IDE, ritengo lo sviluppo con IDE "decisamente" più veloce
di quello manuale e per un progretto serio non userei MAI il codice manuale.
Uso sempre IDE.
Tuttavia, c'è IDE e IDE.
Quando ho provato JBuilder, dopo VA, sono rimasto impressionato: BELLISSIMO,
la versione che ho visto era un po' datata e aveva qualche bug secondario,
ma niente di più grave.
Non mi è piaciuto invece Symatec Visual Café, ma siamo nel campo dei gusti
personali.
Le mie sono tutte opinioni personali e non pretendo di avere la verità in
tasca, comunque in un IDE cerco sempre le librerie migliori per quello che
faccio. Mi occupo prevalentemente di database e cercavo bean che mi
velocizzassero lo sviluppo; credo che JBuilder da questo punto di vista sia
il migliore e che personalizzare le librerie standard di Java sia un lavoro
improbo e non molto utile, anche perché c'è chi lo ha già fatto, creando e
testando librerie da rivendere.
Concludendo: Visual Age non è il migliore ma neanche il peggiore e per un
neofita le freccette sono comode, ma poi ci si accorge che non fanno altro
che richiamare dei metodi....
Se provi JBuilder dovresti avere una impressione migliore.
PS: i miei sono pareri spassionati, non prendo soldi né da IBM, né da
Borland.

 fatto, creando e testando librerie da rivendere.
Sono d'accordo in generale di riusare tutto il riusabile.
Il punto e' *come* sono progettate le "librerie da rivendere" dei vari
produttori. Per ovvi motivi, anche storici ed economici oltre che
tecnici, quando un produttore costruisce una libreria, il risultato e'
spesso una collezione di classi fortemente associate, che rendono il
rischio di legare la logica applicativa alla libreria molto pesante, e
garantiscono di doversi portare dietro un sacco di codice giusto
perche' si e' deciso di cambiare il colore di background di una label.
Casi leggendari sono MFC e varie altre librerie Microsoft - molto
spesso c'e' chi non ha neppure chiaro cosa e' C++, cosa e' Windows, e
cosa e' libreria - e anche se e' questo e' chiarissimo, mantere la
logica applicativa sganciata dalla libreria (o dalla GUI) e' un lavoro
certosino - la libreria semplicemente *non favorisce* questo uso.
Per non parlare dei vari megabytes di dll che ti porti dietro con la
tua applicazione.
Facciamo il caso pratico di java, proprio sui beans di database. Che
fanno questi beans? Ci sono quelli che mantengono la connessione
(definici le caratteristiche del db piazzando il bean su una form).
Quelli che permettono lo scorrimento rapido dei record. Quelli che
visualizzano una "finestra" su una tabella SQL, eccetera.
Ora, ciascuna di queste funzionalita' ha una complessita' diversa - e
impatti diversi sulla qualita' del risultato; per esempio, usare un
bean per una connessione e' "male" :) dato che l'equivalente codifica
JDBC insieme ad un pattern di ownership ammonta a quattro linee di
codice e salva il programmatore da un design catastrofico (alla visual
basic) in cui la connessione e' un membro di un entita' GUI (la quale
poi probabilmente lo deve condividere con altre).
L'uso di un bean per visualizzare una tabella con stile excel-like, al
contrario, e' decisamente utile - non c'e' nulla di standard
lontanamente simile, e riscriversi da capo un componente del genere -
anche se possbile - e' quasi in ogni caso un costo notevole e
soprattutto inutile.
Questo e' cio' che intendo: se c'e' un modo/design standard, o
efficiente a livello di codice, per fare qualcosa, io tendo a
preferirlo. Per funzionalita' realmente diverse, o superiori, ben
vengano i componenti o framework proprietari...
A questo proposito, e' interessante notare la sottile (ma poi mica
tanto ;-) differenza tra "libreria" e "gruppo di componenti".
Paradossalmente, per il riuso, e' piu' facile (anche se piu'
ingombrante) avvalersi di componenti venduti singolarmente - in quanto
non fanno assunzioni su un ambiente circostante (la libreria)
"friendly".
Una libreria un minimo complessa, in altri termini, ha quasi sempre con
se' un'idea di "framework", magari neppure ben chiara o specificata:
cioe' combina un'implementazione con delle scelte di design e delle
guidelines di estensione - le quali (nella mia esprienza, che e'
ovviamente limitata) sono di solito pensate con un occhio piu' al
prodotto che alla generalita' di riuso.
Il che e' accettabilissimo, ripeto, se in cambio si hanno funzionalita'
notevoli; ma per usare una finestrella GUI con due bottoni di
scorrimento avanti e indietro su una view... be', di solito con Java io
prefersico disegnare una volta per tutte un componente *generale* come
intendo io, magari affinando l'implementazione con l'uso: almeno, se
faccio qualche assunzione di troppo, il mio team puo' chiedermi lumi
(leggi: insultarmi :) direttamente. Il che da' almeno piu' gusto. :)
BTW, il fatto che Java fornisca per standard un "ambiente" (libreria)
gia' estremamente sofisticato e "chiaro" e' uno dei suoi maggiori punti
di forza per quanto riguarda la produttivita' e rende lo sviluppo di
componenti generali decisamente piu' semplice.


 componenti generali decisamente piu' semplice.
Vero, ma ti confesso che molte librerie standard di Sun, come Swing la
libreria JavaMail, dopo averle provate mi hanno lasciato l'amaro in bocca.
Per carità non pretendo di avere la verità in tasca, ma ti invito a
considerare che non tutti i framework sono poi così pesanti.
Alcune librerie ti consentono di creare un'unità unica contente il codice
di collegamento, di estrazione ecc. poi non devi fare altro che
richiamarlo, magari sempre sfruttando le proprietà visuali.
Personalmente credo che la gestione degli eventi sia piuttosto complicata
da gestire *a mano*.
Insomma, Visual Basic è brutto, ma alcune intuizioni di VB unite alla
potenza di Java possono dare origini a soluzioni veloci da produrre e
piuttosto leggere.
Sulla manutenibilità, speriamo bene, te lo saprò dire quando i clienti mi
chiederanno modifiche ;-)
Altra domanda: per fare dei report con Java tu come fai?
CIAO
Paolo

 Altra domanda: per fare dei report con Java tu come fai?
Dipende. Se i report sono semplici oppure devono essere
visibili/stampabili da network - ho un set di classi che usano set di
template HTML e sostituzioni di variabili. Se non sono semplici... non
uso Java :), ma strumenti legati al database di turno.
Ciao (e grazie per l'interessante discussione),
   Cris


Nella terminologia informatica cosa significano i termini:
background
foreground
dead-lock
plug & play
Vi ringrazio anticipatamente del vostro aiuto.
Rocco