Newsgroup: it.lavoro.informatica
Titolo: -Informatica - SENRIOR DEVELOPER J2EE

Per progetto  o assunzione cerchiamo un Senior Developer con almeno un
paio d'anni di esperienza nello sviluppo di progetti in ambito J2EE,
con conoscenza  ottima di EJB, Struts 1.2. Eclipse, Hibernate.
Sede di lavoro Vicenza.
L'attività riguarda lo sviluppo di un'applicazione web con
architettura J2EE orientata ai servizi e che quindi spazia
dall'implementazione del layer di presentazione a quella del layer di
business logic e data access.
Disponibilita' anche immediata.
Oltre scopo assunzione si possono valutare anche candidati con partita
iva.
Residenza nei pressi di Vicenza, Padova, Verona.
Inviare il curriculum a 
c...@itbrick.it
  indicando come rif. in oggetto
mail:  J2EE/VI  con autorizzazione al trattamento dei dati personali.
Maggiori informazioni nel sito 
www.itbrick.it

Scusate, Senior Developer j2ee
it_b...@libero.it
 ha scritto:


con conoscenza  ottima di EJB, Struts 1.2. Eclipse, Hibernate.
e' proprio il caso che mi metta a studiare EJB.

cicap ha scritto:



Pensa che 9/10 progetti attuali J2EE gli EJB non li mettono perche' li
odiano anche gli architetti :-)
Se devi studiarli a sto punto studia gia' il JEE5, che J2EE e' gia' Old
Comunque piu' che studiare ( che serve sempre ) conta entrare in un
progettone di 1 anno almeno , possibilmente con un buon Architect che ti
spiega le cose in 1 minuto mentre sui libri c'e' un mare e le cose che
contano non sono poi cosi' tante
Certo prima che in Italia arrivi un progetto jEE5 fai pensione :-)
Nicola
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 >con conoscenza ottima di EJB, Struts 1.2. Eclipse, Hibernate.
Tutta sta roba ci metti almeno i 2 anni richiesti a usarli davvero bene
Nicola
 
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 Tutta sta roba ci metti almeno i 2 anni richiesti a usarli davvero bene
io ci ho messo di più e non li uso ancora *davvero* bene. :-D
la mia statistica personale è 10/10 senza ejb, li ho solo sentiti 
nomianre quando avevano dei problemi e cercavano qualcuno che glieli 
risolvessi.
Riflessione mia personale: hai scelto gli ejb ora rema !

 Riflessione mia personale: hai scelto gli ejb ora rema !
GLi EJB hanno veramente una storia contorta e turbolenta.
1.
Nascono per poter fare chiamate di Procedure remote via CORBA. Ma nessuno
di fatto li ha mausati per quello. Comunque CORBA se lo portano dietro
dalle origini piu' o meno nascosto, a seconda dei periodi.
2.
Il session stateless gestisce la transaction logica e di fatto e' il vero
cavallo vincente di tutta la tecnologia.
3. 
Lo sttateful nasce per le session web, spesso va in conflitto/concorrenza
con le session dei webserver.ě e quindi so cazzi.
4.
i MSD sono da wwf razza in via di estinzione.
5. 
Gli entity e' un bagno di sangue.
Entity 1.0 erano carini ma esplodevano i server sotto carico
Entity 2.0 volevano risolvere i problemi degli 1 ma hanno aggiunto per
semplificare un linguaggio nuovo HQL che e' un "dito ar culo"
Entity 3.0 in sviluppo in JEE5 dovrebbero avvicinarsi ad Hibernate e si
spera che le cose vadano meglio, ma vi assicuro ( lo sto stufdiando) che
sono un bordello forse peggio dei precedenti allo stato attuale
6.
Come PAttern gli EJB mantengono un loro fascino.
I session in particolare come oggetti di logica pura non sono male, certo
se metti nel progetto gente senza esperienza bye bye baby il pattern va a
farsi friggere
7.
Load balancing e Tolerance(rarissima) sono la vera forza degli EJB e dove
cade l'asino. Spesso anche grandi Architetti "so tutto io" scivolano sulla
buccia di banana del balancing
8.
Ejb e container dell'application server direi un buon grado fdi
portabilita' reale delle applicazioni
Nel complesso gli EJB sono eterni "rimandati a settembre", si puo' fare
quasi tutto a meno, ma quando attacchi il balancing ( ed e' raro che di
fatto succede davvero) ti penti di non averli.
Considerato che come dici te chi li ha voluti si porta dietro milioni di
problematiche, capisco chi non li usa.
Io personalmente li metto sempre nei miei porgetti , comunque oggi siamo
veramente in attesa di sti EJB 3 per trarre una conclusione finale.
Al limite Struts + hibernate puo' bastare pero' il grado di "ordine" dell
applicazione va a puttane avendo nelle servlet tutto assieme :
Logica / presentazione / DB, un cesso imho


 semplificare un linguaggio nuovo HQL che e' un "dito ar culo"
HQL non c'entra nulla = Hibernate quey language che e' ottimo
JQL ( o una cosa simile ) e' il linguaggio dei 2.0 che fa schifo totalmente



JEE 5 non dovrebbe unificare Hibernate e EJB, tra l'altro?
Comunque con Hibernate ci ho fatto qualcosa, ma dopo aver visto che era piu' 
il tempo che perdevo con le sue eccezioni che altro, ho deciso di cambaire 
fw di persistenza (tanto finche' il progetto non e' immenso non occorre 
tutta la sua potenza).
Per quanto riguarda Struts 1.2 spero di non doverlo mai piu' utilizzare :). 
Poi se si parla di JEE 5 perche' non usare JSF, che ne fa parte.
Per quanto riguarda EJB, immagino che lo imparero' sul campo se mai lo 
usero', come ho fatto con le altre tecnologie. 


Perche' parli di servlet e non di action?
Poi le action richiamano lo strato sotto (gestione della logica applictiva, 
che a sua volta richiama lo strato di persistenza), spesso grazie a Spring, 
ma si puo' fare anche senza.
La presentazione risiede nelle JSP.

 La presentazione risiede nelle JSP.
Le Jsp sono di nuovo compilate come servlet Quindi stanno allo stesso
livello.
L'architettura canonica completa J2EE e' :
Servlet = Presentation
EJB Session = logica
EJB Entity e/o framwork persistenza = Dati
Poi la parte servlet ci metti il framwork che vuoi : Struts / JSF eccetera
La persistenza di nuovo ci metti il framwork che vuoi
Spring e' un giganrte che sta sulla parte servlet di front-end ma volendo e'
si estende anche nel back-end
Ma si se ora ci mettiamo a dicutere di architettura j2ee finiamo nel 2010
:-)
Comunque concordo che la cosa migliore e' imparare sul campo, integrando con
studi di testi architetturali


 usero', come ho fatto con le altre tecnologie.
Buona fortuna, sul campo si, ma voglio vedere se trovi ancora uno che ti
paga per imparare



Pero' non capisco l'affermazione "applicazione va a puttane avendo nelle 
servlet tutto assieme ".
Le servlet sono una tecnologia, mica puo' essere un problema che venga 
utilizzata la tecnologia servlet.
Semmai e' come viene utilizzata il problema.
Il fatto che le JSP siano servlet (dal punto di vista tecnico), che le 
action siano richiamate dalle servlet, non conta molto. Daltronde quando 
scrivi una JSP non hai certamente molto a che fare con la classe 
HttpServlet, o meglio non ne hai a che fare per forza. 

 HttpServlet, o meglio non ne hai a che fare per forza.
Si la Jsp e' una servlet a tutti gli effetti, anche se non te ne accorgi.
Normalmente nei progetti oggi e' vietato usare <% e cosi' il codice sta
tutto nell'action o nelle tag lib cosi' e' piu' evidente che sei a livello
servlet



Be dai non essere pessimista, basta cercare;)
 io è almeno un anno che lavoro su Java 5 e figurati che l'anno scorso
ho deployato in prod su jboss la prima applicazione con ejb3(da allora
sono anche cambiate le specifiche...).Però preferisco usere ancora
Hibernate e Spring, soprattutto ora che il 2.0 è integrato benissimo
con AspectJ e si possono fare cose davvero carine...
Per la parte web stiamo provando il GoogleWeb Toolkit, ma ne abbiamo
provate di tutte dall'ormai obsolteto Struts, a tapestry a jsf ...
Davide

 Davide


 in panne :-)
Ok, non c'è problema.


 Seam;) ... era un cliente che non voleva Spring (!!!)
E tu perchè lo volevi invece? Ma davvero l'IoC fa guadagnare tutta
'sta performance?

 'sta performance?
Se parli di performance in termini di velocità di esecuzione,
assolutamente no.
Il grande guadagno dell'IoC sta  nella produtivittà, manutenibilià e
passami il temine "testabilità".
Inoltre sei poratato a scrivere codice molto meglio e elimini molto
"codice-glue" rindondante e ripetitivo. Visto che ogni riga di codice
costa da mantenere meno righe si scrivono meglio è.
Dopo un paio di app con spring non si riesce più a farne a meno...
almeno io...
Davide

 almeno io...
Ultimo progetto :
requisiti:
-velocità di esecuzione
Con spring lo stesso codice andava 20% più lento.
tolto spring al mio pezzo (con rissa di 2 settimane con l'architetto).


 in che modo lo rallentava?
Non mi è mai capitato, di avere rallentamenti dovuti al container di
spring.

 Davide

 spring.
lo faceva andare + lento , i lcodice parsava al di fuori del container
spring 20 righe al secondo chiamandolo da spring (o almeno
l'architettura messa in piedi utilizzando spring) faceva 16 righe al
secondo.
Con questo , lascio aperta la possibilità che spring non rallentasse ,
ma come era stato usato su quel progetto , lo rallentava di sicuro.

 ma come era stato usato su quel progetto , lo rallentava di sicuro.
In generale non rallenta a  meno di non usere AOP che nella serie 1.x
di spring è reallizata con il dynamic proxying e quidni non
perfromantissimo. In generale non mi era mai capitato e quindi ero
curioso di capire, perchè non si sa mai...;)