Newsgroup: it.lavoro.informatica
Titolo: [Mi] - Informatica - Programmatore J2ee Struts

Res Srl, nell'ambito di un progetto in ambito assicurativo, ricerca un
programmatore J2EE struts.
Le caratteristiche richieste sono:
· almeno 4 anni di esperienza
· conoscenza di JBoss/Tomcat come application server
· conoscenza di Struts come framework di sviluppo
· conoscenza di Eclipse come strumento di sviluppo EDI
L'inquadramento lavorativo avverrà tramite P.IVA o contratto
a progetto. per periodi variabili: 6-8-12 mesi (inserimento
all'interno di progetti in corso).
La cifra verrà concordata a seguito del colloquio
L'inserimento della figura all'interno del progetto
potrà avvenire a partire dal mese di maggio.
La sede di lavoro è a Milano
I candidati interessati possono inviare un CV dettagliato in formato
EUROPEO all'indirizzo 
in...@onres.it
 ed in copia a
andrea_...@fastwebnet.it
 citando il riferimento e
specificando l'autorizzazione al trattamento dei dati personali ai
sensi della legge sulla Privacy (L. 196/03).Ai sensi della normativa
vigente
l'offerta di lavoro si intende estesa a entrambi i sessi (L 903/77).
Non verranno tenute in considerazione le candidature di consulenti con
meno di 4 anni di esperienza.

 meno di 4 anni di esperienza.
Quindi solo Senior.
Sono certo li pagherai da senior, spero.
Ma secondo te il senior gira per cocopro ?

 Ma secondo te il senior gira per cocopro ?
Boh, può capitare. A me hanno offerto 46.800 lordi per un anno in 12
rate da 3.900 lordi. Devo valutare, preferirei continuare con P. IVA,
ma la retribuzione mi sembra decorosa.
M.

ma la retribuzione mi sembra decorosa.
all'estero ?

bodhi ha scritto:

Di solito lavoro per 230/240 + IVA al giorno. Dicono che più o meno è
l'equivalente. Mi sembra che sia un calcolo giusto, ma non sono 3.900
al mese da TI. In pratica è molto di meno perchè non ci sono 13°,
14°, TFR, contributi da dipendente e buoni pasto.
Più o meno credo che sia il costo di un dipendente a 2000 netti e
qualcosa + buoni pasto per 14 mensilità. Sbaglio?
M.

l'equivalente.
Ah no, avevo letto male e di corsa
quello è si un compenso equo per un p.iva, cioè => 25e/h +iva e cassa l'ora


ma cambiate framework per carita'. 


Lo chiami framework? al massimo è un pattern ;-)
ha ha, comunque ci sono sempre progetti in Struts che devono essere 
mantenuti... mica si può cambiare tutto solo perché cambiano le mode.
-- 
Marco Ermini
http://www.markoer.org
http://www.marcoermini.com/

 ma cambiate framework per carita'.
Non ti è gradito che usino struts?
Che lavorino in ambito assicurativo ti sta bene? E il nome della
società ti piace?

 mantenuti... mica si può cambiare tutto solo perché cambiano le mode.
Io continuo a mettere struts anche nei nuovi progetti.
un po' perche' lo conosco molto bene e nessuno mi ha convinto dei
concorrenti.
E' molto semplice e snello e non complica molto la gia' forse troppo
complessa architettura j2ee.
ciauz Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

societą ti piace?
ROFTL

societą ti piace?
Uhm..no cambiate anche il resto per carita'   ;)


Pattern proprio no ;)
Si e' vero, ma infatti era una battuta e basta.
Comunque, se si tratta di un progetto nuovo lo stesso inventore di struts lo 
sconsiglia. 

 sconsiglia.
Si ma tu che usi ? Spring, JSF, ruby on rail ?
N



Fino ad ora ho usato solo Sturts e JSF.
E' vero che se dovessi sviluppare un sito completamente accessibile, 
indicizzabile, indirizzabile ecc, dovrei tornare indietro ad framework 
classico come Struts, ma a questo punto ormai opterei per qualcosa di 
meglio, che per sentito dire potrebbero essere Spring o Tapestry (non sono 
sicuro che quest'ultimo sia un fw di tipo classico o qualcosa di molto 
vicino a JSF).

 o qualcosa di molto vicino a JSF).
Entrambe le cose, nel senso che supporta l'indicizzazione con url 
classiche e allo stesso
tempo la gestione delle pagine tramite componenti utilizzando i 
template anche per questi ultimi.
E' piu' vicino concettualmente ad Apple WebObjects/GNUstepWeb/SOPE ma con
importanti differenze, vedi ad esempio l'integrazione con Hivemind.
Ciao
Mirko

 ha scritto nel messaggio 
news:e2d08f$s4g$1...@area.cu.mi.it...

Bisogna vedere come pero', perche' anche con JSF volendo e facendo uso dei 
PhaseListener si possono ottenere pagine indicizzate, ma al costo di perdere 
molto della potenza del framework.

 di perdere molto della potenza del framework.
Cambia solo il modo di gestione delle url:
http://wiki.apache.org/jakarta-tapestry/FriendlyUrls
 - per la 4.0
Ciao
Mirko

 vicino a JSF).
VEdo che non sono allora dei marz<iani quelli che hanno postato :)
JSF ha trovato alcuni "fun" ma poi non e' mai decollato
Spring ha avuto un successo gia' maggiore, ma soffre di "eccesso di
potenza", cioe' e' potentissimo, ma va imparato bene, a differenza di
struts, che di fatto una persona in gamba che sa "come" si studia un
pattern, lo impara in pochissimi giorni.
Tapestry, nono ha mai avuto una diffusione enterprise.
In Italia struts la fa da padrona, i progetti sono sempre quelli, e noi che
ci lavoriamo conosciamo meglio quello.
Chi apre un progetto nuovo oggi sa che gente brava su struts ce ne e' tanta,
mentre gente con esperienza reale in spring molto meno.
Quindi la scelta di struts, pur essendo piu' conservativa e probabilmente
non ottima, rimane una scelta legittima per gli architetti italiani.
Ciao Nicola.



Io non ci giurerei, problemi di accessibilita' a parte sta decollando, o 
decollera' presto.
IMHO perche:
1) Alcuni grossi problemi della versione 1.1 e 1.0 sono gia' stati abbattuti 
dalla nuova versione 1.2 (che ora si trova in beta). Questa nuova versione 
offre sopprattutto l'allineamente tra la tecnologia JSF e quella JSP che 
prima mancava.
2) Ho visto che gli sviluppatori stanno facendo grossi sforzi verso AJAX, e 
secondo me e' l'unico framework a poter offrire tali funzionalita' con una 
certa trasparenza. Fornire AJAX con facilita' significa attirare un sacco di 
nuovi adepti. ;)
3) Stanno gia' proliferando un sacco di librerie di componenti per JSF, tool 
di sviluppo, framework che si appoggiano su di esso.
4) Personalmente credo che la versione 2.0 (cioe' la prossima) sara' un 
ulteriore grosso salto di qualita'. 


Io insegno AJAX all'Universita' di MIlano :-)
Struts ho provato ad adattarlo ad AJAX e puo' essere utile per piccole cose
come la validation.
Ora stiamo valutando le taglibraries della JAkarta per AJAX se ti interessa
ti faccio sapere nei prossimi giorni
Il front'end principe per ajax e' ruby on rail ma ancora non lo ho provato.
J2EE e AJax in generale vanno d'accordissimo, io chiamo struts de dentro
ajax e tengo la pagina in HTML per esempio in una semplice applicazione che
sto provando a fare.
ciao Nicola



Non ho capito cosa intendi con "tengo la pagina HTML".
Comunque il risultato che si puo' avere con JSF e' ben oltre a quello che si 
puo' ottere con Sturts.
A parte la possibilita' di avere widget/componenti abilitati a AJAX, che 
possono fare le cose piu' complesse, JSF offre anche la possibilita' di 
sviluppare la propria applicazione senza AJAX e di ajaxizzarla 
successivamente senza quasi nessuno sforzo.
In sostanza il modello a componenti su cui e' basato JSF consente di 
ottenere dal server direttamente il codice HTML. A questo punto sul client 
basta solo fare un replace del nodo DOM che si vuole aggiornare.
Ad esempio se io decido di aggiornare una tabella basta che nel server 
chiamo qualcosa come
dataTable.encodeAll(...);
ed ecco che ottengo l'html della tabella pronto per essere sostituito nella 
pagina.
I framework non component-based non offrono questa possibilita'.
Inoltre tutto puo' essere strettamente integrato, senza neanche la 
necessita' di configurare ulteriori servlet o chissa' che.
Non c'e' neanche il bisogno di creare nuovi componenti (cosa che cmq si puo' 
sempre fare per far fronte ad esigenze piu' complesse), si possono in teoria 
ajaxizzare i componenti standard...
Ora JSF 1.2 offre ulteriori possibilita' in questo ambito: il rendering 
parziale di componenti "iterativi" (ad esempio fare il refresh di una riga 
soltanto di una tabella, e non di tutto il componente), e ancora una volta 
senza che questi componenti sappiano nulla di AJAX.
Siamo OT da un bel pezzo mi sa..andiamo su it.comp.java ? 

 Siamo OT da un bel pezzo mi sa..andiamo su it.comp.java ?
Be si, ma ormai siamo qua, e poi AJAX non v'enta nulla con Java :-)



Si e' vero, ma non vorrei che si esagerasse con sto AJAX. Non e' lecito 
usare AJAX  ovunque ;).
Quello che volevo dire e' che l'approccio piu' potente con JSF non richiede 
la configurazione e l'implementazione di un controller specifico per AJAX, 
cosa che invece devi fare con Struts.
Se non e' una servlet, sara' una Action, poco cambia. Con JSF invece no, 
perche' puo' essere strettamente integrato con AJAX.
AJAX...stiamo abusando con sta parola, io personalmente la odio, ma bisogna 
pur farsi capire  ;) 


AJAX va di moda :-)
Comunque non e' alternativo a nulla, forse alle defunte applet epoco altro,
e quindi per noi e' solo una arma in piu', che possiamo usare o ,meno,
quindi benvenuto.
Il fatto che sia molto complesso. e quindi costoso, lo rende inusabile per
molti dei nostri procetti con budget stile spesa alla COOP, pero' le cose
complesse sono anche le migliori per difenderci un po' da chi si offre per
"qualsiasi cosa" a basse cifre.



Si ma speriamo che non venga usata indiscriminatamente anche.
E' chiaro che pone problematiche di accessibilita', indicizzazione e 
navigazine anche. 

 navigazine anche.
COme ogni tecnologia andra' usata nei campi di applicazione specifici.
Pe r la navigabilita' si perde il tasto back, se peo' pensi che il sogno di
chi fa applicazioni web e' eliminarlo :))
 
ciao Nicola



Non intendevo dire che XMLHttpRequest  fa solo chiamate sincrone. So bene 
che se si usa "true" fa chiamata asincrona, ovvero l'utente non resta in 
attesa di nulla.
Intendevo dire che, prima dell'avvento di quell'oggetto, con buon vecchi 
"script", "img", "iframe" si potevano fare solo chiamate asincrone no?
Non c'era modo di forzare il fatto che la prossima richieste fosse fatta 
conseguentemente alla prima.
La novita' di XmlHttpRequest invece e' di permettere cio', quindi visto che 
volevano spacciare AJAX come una cosa nuova al massimo avrebbero dovuto 
parlare di SJAX (eheh non suona bene). 

 parlare di SJAX (eheh non suona bene).
BE prima del connector non era cosi' semplice modificare il dom con dati del
server in modo cosi' diretto.
Se lo vuoi vedere in un modo diverso oggi col connector la differenza logica
fra serve e client e' molto assottigliata.


 Asynchrounous JAvavascript XML
Io javavo, tu javavi, egli javava :-)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


Uhm, io non la vedo cosi'. Non voglio affidare a Javascript il compito di 
programmare la logica applicativa o una sua parte, se ne avrebbero solo 
svantaggi.
Ma forse intedevi logica di presentazione? 


Ma si poi stara' agli architetti decidere dove e cosa mettere.
Volendo javascript e' un linguaggio potentissimo, anche troppo, e oggi con
il connector ha accesso diretto alle risorse del server, quindi teoricamente
si potrebbe fare una applicazione tutta in javascript.
Se poi uno vuole seguire altre architetture bene, e' solo una opzione in
piu'.
ciao Nicola
