perche' non faccio piu' il programmatore (motivazione tecnica)
Marcoxxx
di fare il programmatore (mansione che pure ho svolto dal 1998 al 2006 in
maniera quasi ininterrotta), ovvero per la scarsa considerazione che hanno
le aziende della figura del tecnico programmatore con tutto cio' che ne
consegue.
Pero' effettivamente, anche dal punto di vista strettamente tecnico non mi
esalta piu' un gran che fare il programmatore. Cerco di illustrare il
motivo con un esempio:
ho avuto a che fare in questi giorni con un software j2ee scritto da un
altro (per un progetto in cui avevo svolto il ruolo di analista
funzionale, quindi il progetto lo conoscevo abbastanza bene).
Questo software contiene un erroretto (in pratica doveva scrivere
un valore nella riga iniziale di un file e lo stesso valore, aumentato di
due nella riga finale di un file. Invece scrive lo stesso valore sia
nella riga iniziale che finale)
Cerco un po' nel codice (non ricordo quanto tempo: diciamo tra 2 e tre
ore) e finalmente trovo dove e' il problema: bisogna cambiare una riga di
codice da
write(...,numeRec,...)
a
write(...,numRec+2,...)
ok lo faccio e penso: pèro' era divertente programmare....
poi arriva il rompimento:
Il Software e' scritto in j2ee (che fa uso di hybernate), compilato con
maven.
Io ho due portatili uno con linux ubuntu+macchina virtuale W7 (virtualbox)
e un'altro con Windows Vista con macchina virtuale linux ubuntu (sempre
virtual box).
Provo a compilare il software con il notebook linux => non mi funziona una
mazza (apt-get non funziona nella rete aziendale e non capisco perche',
mentre a casa funziona; se anche a casa funziona e mi installo maven, poi
nella rete aziendale quando lancio maven questo non riesce a collegarsi al
suo repository, ecc.)
Provo con la macchina virtuale linux su host Vista e, miracolosamente,
apt-get funziona. Installo maven. Pero' ho altre cose da fare non posso
lanciare maven. Va beh lo faccio domani...
Domani ho da fare (il bug fixing del codice e' a bassissima priorita')..
va beh lo faccio tra qualche giorno.
Tra qualche giorno, vado gongolante a provare a lanciare maven.
Non funge un'emerita cippalippa (pare che vada in timeout il tentativo di
connettersi al suo repository).
Provo apt-get: quello che funzionava qualche giorno prima ora non funziona
piu' ? Perche' ?
Si e' scassato qualcosa ?
Provo a casa e funziona...
Ci devessere qualcosa legato alla rete aziendale
Chiamo il tizio che si occupa delle configurazioni necessarie per andare
in rete. Questo mi fa notare che sono state cambiate delle regole sul
proxy (ovviamente senza dire un'emerito ca**o a nessuno) per cui bisogna
configurare alcune "esclusioni" dall'utilizzo del proxy. Fatto: ora
apt-get funge! Ma sono passati giorni!!
Provo maven: non funge!! Eccheccazz...
a gia'... il proxy... non e' che ora devo configurare il proxy anche su
maven ? Ci provo... dove e' il file di configurazione di maven ?
cerco su internet. Di solito e' in <$YOUR_HOME>/m2/...
ma in <$YOUR_HOME>/m2/... io non trovo una cippa....
a gia'... ma io l'ho installato con apt-get. Chissa' dove l'ha messo.
Cerco su internet. Dicono che a volte sta in /usr/<qualcosa>
io in usr/<qualcosa> non trovo una mazza
Allora vai di find ./ -iname "<file di configurazione di maven, che non mi
ricordo nemmeno piu' come si chiama tanto mi sta sulle balle>"
lo trovo: e' in /etc/<qualcosa>
inserisco il proxy: cazzarola funge....
compilo! Devo testarlo. Ma questo e' a bassa priorita', devo prima
sbrigare queste altre faccende... sbrigo altre faccende e poi testo
funge!! da non credere!
In altre parole:
2 ore per trovare il problema,
3 secondo per modificare il codice per risolvere il problema,
N-mila giorni per riuscire a compilare!!
Ecchecazz**!!
Ma sono un programmatore o un configuratore di rete aziendale e di maven ?
Conclusione:
Meglio non fare il programmatore (anche perche' per 3 secondi divertenti
di scrittura codice, ci sono "secoli" di pallosissime configurazioni da
fare)!
Ciao,
Marco
PS: il portatile con linux ubuntu+macchina virtuale W7 devo ancora
configurarlo per renderlo "compliant" con le nuove regole aziendali
(ammesso che non le abbiano ri-cambiate nel frattempo)
--
questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news segnala gli abusi ad ab...@newsland.it
Equinozio
> di scrittura codice, ci sono "secoli" di pallosissime configurazioni da
> fare)!
Già, anche io avrei smesso di occuparmi della parte tecnica se
lavorassi in j2ee + hybernate .... .... mah va beh, una faccina ce
la metto :-)
ispas
> Già, anche io avrei smesso di occuparmi della parte tecnica se
> lavorassi in j2ee + hybernate .... .... mah va beh, una faccina ce
> la metto :-)
Sono d'accordissimo. La soddisfazione dipende anche dall'ambiente di
programmazione, per fortuna non sono tutti complicati (sono buono :-)
come [J2EE + i suoi 1000 altri prodotti ausiliari].
Indec
vale981
configurare il sistema e minuti a scrivere il mio programmino....la
tristezza dell'essere programmatori!!!
ps il bello è farti pagare N giorni quando tu il lavoro lo hai fatto
in N secondi ihihi
ispas
Si paga l'esperienza e la certezza di ottenere il risultato, o di
risolvere il problema, nel tempo massimo prefissato.
Tutti sono capaci di ottenere il risultato in un tempo lunghissimo,
basta studiare e fare esperienza, appunto! :-)
Pertanto l'arrivare alla soluzione in se e per se vale zero.
JOKER Ltd.
> > Già, anche io avrei smesso di occuparmi della parte tecnica se
> > lavorassi in j2ee + hybernate .... .... mah va beh, una faccina ce
> > la metto :-)
>
> Sai che non l'ho capita?
Voleva dire una cosa tipo: passa a [python/C#/quant'altro] e la voglia
ti torna.
Greetings
JOKER Ltd.
rootkit
> Provo a compilare il software con il notebook linux => non mi funziona una
> mazza (apt-get non funziona nella rete aziendale e non capisco perche',
> mentre a casa funziona; se anche a casa funziona e mi installo maven, poi
> nella rete aziendale quando lancio maven questo non riesce a collegarsi al
> suo repository, ecc.)
credimi se ti dico che quello in cui sei affogato non è neanche un
bicchiere, ma una tazzina d'acqua.
TheStylist
> Ho gia' scritto varie volte il motivo principale per cui non mi va molto
> di fare il programmatore (mansione che pure ho svolto dal 1998 al 2006 in
> maniera quasi ininterrotta), ovvero per la scarsa considerazione che hanno
> le aziende della figura del tecnico programmatore con tutto cio' che ne
> consegue.
allora fai il sistemista!
rootkit
> > Sai che non l'ho capita?
>
> Voleva dire una cosa tipo: passa a [python/C#/quant'altro] e la voglia
> ti torna.
sul "quant'altro" non mi pronuncio, ma se il problema è non riuscire a
scaricare/aggiornare librerie perché sei dietro ad un proxy affoghi
anche con easy_install, eh...
Bartman
> Ho gia' scritto varie volte il motivo principale per cui non mi va molto
> di fare il programmatore (mansione che pure ho svolto dal 1998 al 2006 in
he non le abbiano ri-cambiate nel frattempo)
>
[CUT]
Vabeh, dai, la configurazione dell'ambiente e dei tool è sicuramente
(almeno per me) la parte più pallosa del lavoro di programmatore.
Non ti dico quanto sia divertente mettersi a modificare la configurazione
di JBoss (che l'xml sia maledetto):-)
Argaar
> Ecchecazz**!!
> Ma sono un programmatore o un configuratore di rete aziendale e di maven ?
>
> Conclusione:
> Meglio non fare il programmatore (anche perche' per 3 secondi divertenti
> di scrittura codice, ci sono "secoli" di pallosissime configurazioni da
> fare)!
>
> Ciao,
> Marco
scusa ma mica ho capito questo tuo sfogo "contro"
mi occupo sia dei sistemi che della rete e ogni tanto mi concedo a
momenti di programmazione.
Ora voglio dire, io sono in grado di installarmi una macchina e farla
funzionare tranquillamente (è il mio compito principale), poi
l'esperienza (limitata) da programmatore fa si che da sistemista io mi
installo la macchina e ci configuro sopra i tool, da programmatore uso
quei tool.
se a te manca un pezzo e sei "solo" programmatore, non vedo perchè
adirarsi per qualcosa che non ti compete, semmai la colpa è della tua
azienda che non ti ha dato il supporto di un sistemista...o almeno...qui
da me funziona così, se ad un nuovo programmatore serve una macchina per
lavorare, prendo un pc, lo installo, ci installo i tool, li configuro
"standard" e lui li usa.
è triste che un programmatore non sappia fare tutto da se, però questa è
la mia opinione, qui ci sono tanti programmatori che non sanno una fava
di networking o di linux e windows, si limitano a scrivere codice e a
premere il pulsantino per compilare
Bartman
Ma la piattaforma Microsoft è così più semplice di JEE? Non ho molta
esperienza con C#, ma a me è sempre sembrato un Java un po' più snello (e
quindi non un granché - per quanto apprezzi la piattaforma, Java - il
linguaggio - non è certo tra i miei preferiti).
Il confronto tra Python e Java (dal punto di vista del linguaggio) è
abbastanza impietoso: insomma, il pitone vince a mani basse su tutta la linea :-)
Per quanto riguarda tool e librerie, invece, credo che Java vinca
tranquillamente: c'è tutto e il contrario di tutto...
rootkit
ad oggi questa è oggettivamente una leggenda.
Bartman
> è triste che un programmatore non sappia fare tutto da se, però questa è
> la mia opinione, qui ci sono tanti programmatori che non sanno una fava
> di networking o di linux e windows, si limitano a scrivere codice e a
> premere il pulsantino per compilare
>
Vabeh, "scrivere codice" non è un'attività così banale :-)
Argaar
obiettivamente no....ma <<soggettivamente>> se vieni qui vedrai...;)
Equinozio
> > lavorassi in j2ee + hybernate .... .... mah va beh, una faccina ce
> > la metto :-)
>
> ad oggi questa è oggettivamente una leggenda.
Che leggenda ? Imho j2ee + hybernate o altro è uno degli ambienti
meno divertenti dove lavorare (aka più noiosi), è una mia opinione,
forse "leggendaria" ma è una mia opinione.
Credo che preferirei il php o javascript, per non dire il cobol !
ispas
> Ma la piattaforma Microsoft è così più semplice di JEE? Non ho molta
> esperienza con C#, ma a me è sempre sembrato un Java un po' più snello (e
> quindi non un granché - per quanto apprezzi la piattaforma, Java - il
> linguaggio - non è certo tra i miei preferiti).
Penso proprio che Net non è molto meno pesante e complesso. D'altronde
è nato come clone di Java in buona sostanza :-)
La caratteristica (problema?) di Java è che per fare un'applicazione
EE standard non ti basta JavaEE, ma vengono comunemente usati numerosi
altri pacchetti, tools, infrastrutture esterne, come Hybernate e Maven
che citava Marco, poi Ant ed altri. Ognuno ovviamente con le sue
tonnellate di parametri da settare.
Net appare un pò più compatto, nel senso che in Visual Studio trovi
già quasi tutto di quel che ti serve.
> Per quanto riguarda tool e librerie, invece, credo che Java vinca
> tranquillamente: c'è tutto e il contrario di tutto...
Bisogna vedere se le caratteristiche più usate in un determinato
ambiente (come quelli dei gestionali JavaEE) sono inglobate nelle
librerie di default del linguaggio. Come dire, se al 90% gestisco db
relazionali e produco liste, mi frega poco che ci sia la libreria
grafica 3D e musicale... :-) In passato mi sembrava che Java avesse
questo limite, tant'è che Hybernate non fa parte delle librerie
standard, ma è un progetto esterno. Cosa alquanto cueiosa per la
versione EE, che si rivolge proprio alle imprese.
Bartman
>
> obiettivamente no....ma <<soggettivamente>> se vieni qui vedrai...;)
Ok, ovviamente tutto dipende dal contesto :-D
JOKER Ltd.
> sul "quant'altro" non mi pronuncio, ma se il problema è non riuscire a
> scaricare/aggiornare librerie perché sei dietro ad un proxy affoghi
> anche con easy_install, eh...
Verdad! Pero' almeno devi settare solo da una parte il proxy malefico.
Non ci si mette pure Maven e chissa che.
Greetings
JOKER Ltd.
JOKER Ltd.
> Ma la piattaforma Microsoft è così più semplice di JEE? Non ho molta
> esperienza con C#, ma a me è sempre sembrato un Java un po' più snello (e
> quindi non un granché - per quanto apprezzi la piattaforma, Java - il
> linguaggio - non è certo tra i miei preferiti).
Di certo e' piu' coerente e meno impasticcato. Certo tra usare Java e
C# preferisco il secondo, ma tra C# e che so Python, il primo vola
giu' dalla torre subito.
> Il confronto tra Python e Java (dal punto di vista del linguaggio) è
> abbastanza impietoso: insomma, il pitone vince a mani basse su tutta la linea :-)
Embe' se solo lo capissero nel monto Enterprise
> Per quanto riguarda tool e librerie, invece, credo che Java vinca
> tranquillamente: c'è tutto e il contrario di tutto...
Perche' cosa manca al biforcuto?
Greetings
JOKER Ltd.
JOKER Ltd.
> di JBoss (che l'xml sia maledetto):-)
Sempre e comunque. Con formati intelligenti (JSON in example, oppure
se proprio vuoi la sintesi estrema Yaml) e compatti usare ancora XML
mi sembra una delle tipiche pesantezze Enterprise. Come usare J2EE o
WebSphere, perche' e' cosi' che si lavora e basta. Io sono uno che ama
lo sviluppo agile. Sorry, non fanno per me quei mostri li.
Greetings
JOKER Ltd.
Bartman
>
> Penso proprio che Net non è molto meno pesante e complesso. D'altronde
> è nato come clone di Java in buona sostanza :-)
> La caratteristica (problema?) di Java è che per fare un'applicazione
> EE standard non ti basta JavaEE, ma vengono comunemente usati numerosi
> altri pacchetti, tools, infrastrutture esterne, come Hybernate e Maven
> che citava Marco, poi Ant ed altri. Ognuno ovviamente con le sue
> tonnellate di parametri da settare.
Discorso Hibernate: da quando c'è JPA (che è uno standard JEE) la persistenza è
gestita in maniera decisamente semplice. Non si è più nemmeno obbligati ad usare
l'xml (siano benedette le annotation). Poi uno può usare Hibernate, TopLink o
quello che vuole, ma se rimani nello standard le cose funzionano quasi senza
dover configurare nulla.
Per quanto riguarda i build tool non saprei che dirti: li odio con tutto il mio
cuore, ma in molti contesti sono necessari. Noi di solito usiamo ant ed è un
pacco incredibile (altro xml da modificare!); per i fatti miei ho usato un paio
di volte maven, e seppur rigido, mi è sembrato parecchio semplice da utilizzare
(ok, anche lui ha i file di configurazione in xml...).
Di solito, comunque, a meno di non dover fare cose molto particolari, mettere in
piedi una applicazione JEE non è molto complicato.
> Net appare un pò più compatto, nel senso che in Visual Studio trovi
> già quasi tutto di quel che ti serve.
>
Eclipse e Netbeans non credo siano da meno.
> > Per quanto riguarda tool e librerie, invece, credo che Java vinca
> > tranquillamente: c'è tutto e il contrario di tutto...
>
> Bisogna vedere se le caratteristiche più usate in un determinato
> ambiente (come quelli dei gestionali JavaEE) sono inglobate nelle
> librerie di default del linguaggio. Come dire, se al 90% gestisco db
> relazionali e produco liste, mi frega poco che ci sia la libreria
> grafica 3D e musicale... :-) In passato mi sembrava che Java avesse
> questo limite, tant'è che Hybernate non fa parte delle librerie
> standard, ma è un progetto esterno. Cosa alquanto cueiosa per la
> versione EE, che si rivolge proprio alle imprese.
In passato era così (non ho mai lavorato con gli EJB 2 - ringrazio gli dei della
programmazione), ma potrei sbagliarmi. Ora la persistenza è uno standard (JPA) e
ognuno è libero di implementarla come meglio crede nei limiti delle specifiche
(Hibernate è una implementazione). Del resto, anche ActiveRecord non è uno
'standard' di Ruby, né SQLAlchemy fa parte della 'libreria standard' di Python.
Non voglio difendere Java (un po' forse l'ho fatto :-D), però ora molta
complessità viene nascosta da configurazioni base accettabili per la maggior
parte dei casi. Poi, all'occorrenza, uno può tuffarsi nei file di configurazioni
e prenotare qualche visita da un bravo psichiatra :-)
rootkit
> > ad oggi questa è oggettivamente una leggenda.
>
> Che leggenda ? Imho j2ee + hybernate o altro è uno degli ambienti
> meno divertenti dove lavorare (aka più noiosi), è una mia opinione,
> forse "leggendaria" ma è una mia opinione.
ad oggi con ejb3 e jpa tu hibernate manco lo vedi. che tu trovi noioso
lavorarci non lo metto in dubbio, ma sviluppare il layer di accesso ai
dati è noioso a prescindere e checchè se ne dica senza un orm è
proprio da picconate nei ginocchi, altro che noioso.
per il resto il jee è proprio tutto fuori che noioso.
rootkit
> > sul "quant'altro" non mi pronuncio, ma se il problema è non riuscire a
> > scaricare/aggiornare librerie perché sei dietro ad un proxy affoghi
> > anche con easy_install, eh...
>
> Verdad! Pero' almeno devi settare solo da una parte il proxy malefico.
> Non ci si mette pure Maven e chissa che.
boia dé, son 30 secondi di google scoprirlo...
Bartman
> > Per quanto riguarda tool e librerie, invece, credo che Java vinca
> > tranquillamente: c'è tutto e il contrario di tutto...
>
> Perche' cosa manca al biforcuto?
>
Non credo manchi nulla (ma la mia opinione, purtroppo, conta molto poco - e
quindi continuo a lavorare con Java :-)). Ma per Java ci sono n-mila framework
per fare qualsiasi cosa: di conseguenza, se un tool non mi vabene, ne posso
cercare - e proabilmente lo troverò - un altro simile che mi risolva il
problema. Io lo vedo come un punto di forza (altri la considerano una debolezza).
Forse a Python e Ruby, oggi, manca un'azienda alle spalle che li spinga un po'
di più...
Bartman
> On 1 Ott, 11:13, "Bartman" <22031inva...@mynewsgate.net> wrote:
>
> > di JBoss (che l'xml sia maledetto):-)
>
> Sempre e comunque. Con formati intelligenti (JSON in example, oppure
> se proprio vuoi la sintesi estrema Yaml) e compatti usare ancora XML
> mi sembra una delle tipiche pesantezze Enterprise.
A me Yaml piace, ma mi sa che ormai ha vinto JSON :-)
In ogni caso, JSON mi pare si sempre più utilizzato, forse tra qualche anno
vedremo il cadavere dell'xml passare nel fiume :-)
> Come usare J2EE o
> WebSphere, perche' e' cosi' che si lavora e basta. Io sono uno che ama
> lo sviluppo agile. Sorry, non fanno per me quei mostri li.
>
Usare un application server non è sempre necessario: spesso basta un Tomcat
o un Jetty (che va come una palla di fuoco :-)), ma purtroppo in alcuni casi
si usa JBoss anche per mettere in piedi due pagine web...
rootkit
> La caratteristica (problema?) di Java è che per fare un'applicazione
> EE standard non ti basta JavaEE, ma vengono comunemente usati numerosi
> altri pacchetti, tools, infrastrutture esterne, come Hybernate e Maven
> che citava Marco, poi Ant ed altri. Ognuno ovviamente con le sue
> tonnellate di parametri da settare.
si scrive hibernate.
ispas
> Per quanto riguarda i build tool non saprei che dirti: li odio con tutto il mio
> cuore, ma in molti contesti sono necessari. Noi di solito usiamo ant ed è un
> pacco incredibile (altro xml da modificare!); per i fatti miei ho usato un paio
> di volte maven, e seppur rigido, mi è sembrato parecchio semplice da utilizzare
> (ok, anche lui ha i file di configurazione in xml...).
Non capisco perchè questi build tool non son inglobati nelle IDE di
Java, Eclipse, Netbeans.
Oppure lo sono, ma allora perchè avere la configurazione separata per
ogni tool? Boh.
> In passato era così (non ho mai lavorato con gli EJB 2 - ringrazio gli dei della
> programmazione), ma potrei sbagliarmi. Ora la persistenza è uno standard (JPA) e
> ognuno è libero di implementarla come meglio crede nei limiti delle specifiche
> (Hibernate è una implementazione). Del resto, anche ActiveRecord non è uno
> 'standard' di Ruby, né SQLAlchemy fa parte della 'libreria standard' di Python.
> Non voglio difendere Java (un po' forse l'ho fatto :-D), però ora molta
> complessità viene nascosta da configurazioni base accettabili per la maggior
> parte dei casi. Poi, all'occorrenza, uno può tuffarsi nei file di configurazioni
> e prenotare qualche visita da un bravo psichiatra :-)
Ecco, non capisco perchè allora si debba ricorrere a pacchetti
esterni come Hybernate. Parliamo di EE, che non ce lo sanno che serve
un qualche cosa di concreto per interfacciare i db? Con gli standard
non si magna :-)
Diverso per Ruby o Python, non credo che vantino una edizione EE.
E poi, purtroppo capita spesso che devi manipolare applicazioni
scritte nei vecchi standard, indubbiamente più embrionali e
sgangherati.
A quel punto ti attacchi.... alla tastiera rassegnato ad usare Java
come i "nonni" lo usavano :-)
Senza le tante innovazioni via via aggiunte negli anni.
Equinozio
Secondo me è una palla mostruosa. In parte per i file di
configurazione che si sprecano, in parte per la configurazione
dell'ambiente con l'app server, il web server, in parte perché
difficilmente riesci a produrre qualcosa di visibile in un tempo che
per me rientra nel divertente e sopratutto perché l'architettura che
ci sta dietro non mi piace.
Non parlo di serietà del linguaggio o tutto quel che riguarda la
professionalità. Parlo proprio di divertimento e credo proprio siano
in pochi a divertirsi in j2ee.
Poi nel mio caso, ripeto, avrei smesso di programmare da tempo, o
sarei passato a scrivere stored procedure.
La risposta che puoi dare TE è che TE ti diverti e molti altri si
divertono, e meno male, vuol dire che siamo diversi ed ognuno di noi
fa quel che gli piace.
ispas
> Usare un application server non è sempre necessario: spesso basta un Tomcat
> o un Jetty (che va come una palla di fuoco :-)), ma purtroppo in alcuni casi
> si usa JBoss anche per mettere in piedi due pagine web...
Jetty! Simpatico :-) Una decina di anni fa ci feci qualche cosetta.
Ecco, quello era (è?) un ambiente equilibrato, complicato il giusto.
PS: altra carenza di JavaEE, mancanza di un server web standard,
quando il 99% delle applicazioni JavaEE è web. Misteri buffi. Almeno
con Net hai IIS, inglobato in Windows.
JOKER Ltd.
> Non credo manchi nulla (ma la mia opinione, purtroppo, conta molto poco - e
> quindi continuo a lavorare con Java :-)).
Io mi sono sbattuto un po' ma lavoro con python ora
Ma per Java ci sono n-mila framework
> per fare qualsiasi cosa: di conseguenza, se un tool non mi vabene, ne posso
> cercare - e proabilmente lo troverò - un altro simile che mi risolva il
> problema.
Ma anche per brad pyt(hon) vale lo stesso discorso. Con in piu' che se
non trovi quel che cvuoi ci metti poco a fartelo homemade.
> Forse a Python e Ruby, oggi, manca un'azienda alle spalle che li spinga un po'
> di più...
Ecco questo di certo. Nel bene e nel male.
Greetings
JOKER Ltd.
Bartman
> Non capisco perchè questi build tool non son inglobati nelle IDE di
> Java, Eclipse, Netbeans.
> Oppure lo sono, ma allora perchè avere la configurazione separata per
> ogni tool? Boh.
Credo che ant sia quasi considerato uno standard, ed è integrato sia con
Netbeans sia con Eclipse (per maven credo servano dei plugin, ma non sono molto
aggiornato). Ant non ha bisogno di configurazioni particolari: certo, bisogna
dirgli cosa deve fare :-)
> Ecco, non capisco perchè allora si debba ricorrere a pacchetti
> esterni come Hybernate. Parliamo di EE, che non ce lo sanno che serve
> un qualche cosa di concreto per interfacciare i db? Con gli standard
> non si magna :-)
Non hai bisogno di pacchetti esterni. Hai bisogno di un application server:
scegli quello che preferisci e gestisce tutto lui (più o meno :-)). Ogni
application server rispetta (facciamo finta che sia sempre così) lo standard JEE
e quindi tu puoi usare gli EJB, la persistenza, i messaggi e così via. Come ORM
di default, JBoss usa Hibernate, mentre GlassFish (che, in teoria, dovrebbe
essere l'application server 'ufficiale') usa Toplink (che è di Oracle, quindi
anch'esso dovrebbe essere l'implmentazione 'ufficiale' di JPA). Ma tu usi le
interfacce e le annotation dello standard: che poi sotto ci sia l'uno o l'altro,
dovrebbe fare poca differenza.
Insomma, la versione enterprise di Java è più una serie di specifiche:
l'implementazione è lasciata ad altri (RedHat, Apache, IBM e la ex Sun stessa).
Se stai nello standard, sai che (sempre più o meno) la tua applicazione potrà
funzionare su JBoss o su Glassfish senza che tu debba fare nulla.
> Diverso per Ruby o Python, non credo che vantino una edizione EE.
Ovviamente no, errore mio :-)
> E poi, purtroppo capita spesso che devi manipolare applicazioni
> scritte nei vecchi standard, indubbiamente più embrionali e
> sgangherati.
Argh, per ora non mi è capitato.
> A quel punto ti attacchi.... alla tastiera rassegnato ad usare Java
> come i "nonni" lo usavano :-)
> Senza le tante innovazioni via via aggiunte negli anni.
>
Che ci sono state: in alcuni casi non perfette, ma il mondo Java è meno
ingessato di quanto si possa pensare. Poi, nelle aziende, trovi ancora
application server vecchissimi ("funziona, perché cambiarlo?") e quindi ti spari
nelle gambe...
JOKER Ltd.
> A me Yaml piace, ma mi sa che ormai ha vinto JSON :-)
Anche a me non spiaceva Yaml, ma json ha il grosso vantaggio (per me)
di essere praticamente molto pythonico e molto javascriptico
( costrutti come [] per le liste e {} per i dizionari (in js oggetti,
ma alla fine sono come i dict di python). E esistono encoder/decoder
su qalsiasi linguaggio ormai.
> In ogni caso, JSON mi pare si sempre più utilizzato, forse tra qualche anno
> vedremo il cadavere dell'xml passare nel fiume :-)
Lo attendo con ansia
> Usare un application server non è sempre necessario: spesso basta un Tomcat
> o un Jetty (che va come una palla di fuoco :-)), ma purtroppo in alcuni casi
> si usa JBoss anche per mettere in piedi due pagine web...
Esattamente quello che consideravo.
Greetings
JOKER Ltd.
JOKER Ltd.
> Almeno con Net hai IIS, inglobato in Windows.
Bleargh! Io personalmente non reggo IIS e le sue paturnie. Magari
addesso e' meglio, ma io continuo ad essere allergico (come a quasi
trutto il mondo micro & soffice).
Greetings
JOKER Ltd.
Marcoxxx
> Il 01/10/2010 0.44, Marcoxxx ha scritto:
> > Ho gia' scritto varie volte il motivo principale per cui non mi va molto
> > di fare il programmatore (mansione che pure ho svolto dal 1998 al 2006 in
> > maniera quasi ininterrotta), ovvero per la scarsa considerazione che hanno
> > le aziende della figura del tecnico programmatore con tutto cio' che ne
> > consegue.
> allora fai il sistemista!
Per il sistemista valgono le stesse considerazioni del programmatore.
Ciao,
Marco.
--
questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news segnala gli abusi ad ab...@newsland.it
ispas
> Non hai bisogno di pacchetti esterni. Hai bisogno di un application server:
> scegli quello che preferisci e gestisce tutto lui (più o meno :-)). Ogni
> application server rispetta (facciamo finta che sia sempre così) lo standard JEE
> e quindi tu puoi usare gli EJB, la persistenza, i messaggi e così via. Come ORM
> di default, JBoss usa Hibernate, mentre GlassFish (che, in teoria, dovrebbe
> essere l'application server 'ufficiale') usa Toplink (che è di Oracle, quindi
> anch'esso dovrebbe essere l'implmentazione 'ufficiale' di JPA). Ma tu usi le
> interfacce e le annotation dello standard: che poi sotto ci sia l'uno o l'altro,
> dovrebbe fare poca differenza.
> Insomma, la versione enterprise di Java è più una serie di specifiche:
> l'implementazione è lasciata ad altri (RedHat, Apache, IBM e la ex Sun stessa).
> Se stai nello standard, sai che (sempre più o meno) la tua applicazione potrà
> funzionare su JBoss o su Glassfish senza che tu debba fare nulla.
Non mi convince questa filosofia delle specifiche senza
implementazione. Ne deriva un ambiente potenzialmente mezzo standard e
mezzo no. Ok, GlassFish e Toplink sono più o meno gli standard
ufficiali, ma non li avevo mai sentiti nominare, sempre Tomcat, JBoss,
Websphere. Mi sa che non sono tanto standard, hanno qualche
magagnetta?
> Che ci sono state: in alcuni casi non perfette, ma il mondo Java è meno
> ingessato di quanto si possa pensare. Poi, nelle aziende, trovi ancora
> application server vecchissimi ("funziona, perché cambiarlo?") e quindi ti spari
> nelle gambe...
Ma questa è la prassi in tutta l'informatica. E' assurdo che
un'azienda cambi tutto solo per seguire al versione del momento. Ecco
perchè usare prodotti immaturi ed incompleti (come poteva essere
JavaEE nel 2002) è molto pericoloso. Purtroppo è la situazione che
vivo quotidianamente, sia pure indirettamente :-(
ispas
Sarà brutto, ma è "nella scatola" con Visual Studio. Se vado sul sito
Sun e scarico JavaEE nella scatola c'è un web server decente, a
livello EE? Non mi risulta. Questa frammentazione è perlomeno
fastidiosa.
Bartman
> On 1 Ott, 12:21, "Bartman" <22031inva...@mynewsgate.net> wrote:
>
> > A me Yaml piace, ma mi sa che ormai ha vinto JSON :-)
>
> Anche a me non spiaceva Yaml, ma json ha il grosso vantaggio (per me)
> di essere praticamente molto pythonico e molto javascriptico
> ( costrutti come [] per le liste e {} per i dizionari (in js oggetti,
> ma alla fine sono come i dict di python). E esistono encoder/decoder
> su qalsiasi linguaggio ormai.
Sì, soprattutto perché nel futuro Javascript diventerà ancora più importante.
Comunque, qualsiasi cosa è meglio dell'XML (che sia yaml o json, non fa molta
differenza :-))
Bartman
> On 1 Ott, 12:14, "Bartman" <22031inva...@mynewsgate.net> wrote:
>
> > Non credo manchi nulla (ma la mia opinione, purtroppo, conta molto poco - e
> > quindi continuo a lavorare con Java :-)).
>
> Io mi sono sbattuto un po' ma lavoro con python ora
>
Non so se sei un freelance o lavori in qualche ditta (in quest'ultimo caso,
complimenti alla tua ditta e te :-)). Passerei anche io a qualcosa di più
'divertente', ma per come vanno le cose qui in Italia adesso preferisco
specializzarmi un po' di più su Java.
>
> Ma anche per brad pyt(hon) vale lo stesso discorso. Con in piu' che se
> non trovi quel che cvuoi ci metti poco a fartelo homemade.
Beh, dai, in Java ci sono duemila web framework (poi, magari, mi dirai che fanno
schifo rispetto a un Django o ad un Rails - ma questo è un altro discorso): è
difficile non trovare qualcosa che sia adatti alle proprie esigenze. La quantità
di librerie/tool per python credo sia oggettivamente minore, ma anche per una
questione temporale.
Bartman
> Non mi convince questa filosofia delle specifiche senza
> implementazione. Ne deriva un ambiente potenzialmente mezzo standard e
> mezzo no. Ok, GlassFish e Toplink sono più o meno gli standard
> ufficiali, ma non li avevo mai sentiti nominare, sempre Tomcat, JBoss,
> Websphere.
E' la filosofia 'program to an interface, not an implementation' :-)
Di solito, con le specifiche, ci sono anche le reference implementation: quindi
non è che la Sun - ehm, la Oracle - fa gli standard e poi lascia tutto al caso.
Ci sono poi certificazioni: quindi se tu usi un application server è certificato
per JEE 5 e non rispetta gli standard, tu ti puoi giustamente incavolare e farti
sentire con che te l'ha venduto.
> Mi sa che non sono tanto standard, hanno qualche
> magagnetta?
L'unico problema di Glassfish è che è ventuo dopo JBoss e compagnia. Chi lo usa,
di solito, ne parla molto bene (io, purtroppo, sono inchiodato a JBoss e,
sinceramente, preferisco guardarmi Erlang o Rails per i fatti miei piuttosto che
spulciarmi la documentazione di un altro application server :-))
TopLink non l'ho mai usato, ma penso che anche qui sia una questione di
marketing/fortuna/quant'altro: Hibernate è sempre stato il più famoso, quindi
ORM per Java = Hibernate nel 90% dei casi.
> Ma questa è la prassi in tutta l'informatica. E' assurdo che
> un'azienda cambi tutto solo per seguire al versione del momento. Ecco
> perchè usare prodotti immaturi ed incompleti (come poteva essere
> JavaEE nel 2002) è molto pericoloso. Purtroppo è la situazione che
> vivo quotidianamente, sia pure indirettamente :-(
>
Non è tanto questione di cambiare, quanto di restare aggiornati (forse non mi
sono spiegato bene). Ad esempio, per un'applicazione nuova, noi continuamo ad
usare una versione di un application server che avrà tre anni :-/
Marcoxxx
> On Oct 1, 12:44 am, aritopogig...@web.de (Marcoxxx) wrote:
> > Provo a compilare il software con il notebook linux => non mi funziona una
> > mazza (apt-get non funziona nella rete aziendale e non capisco perche',
> > mentre a casa funziona; se anche a casa funziona e mi installo maven, poi
> > nella rete aziendale quando lancio maven questo non riesce a collegarsi al
> > suo repository, ecc.)
> credimi se ti dico che quello in cui sei affogato non è neanche un
> bicchiere, ma una tazzina d'acqua.
Non lo metto in dubbio (anche se la maggior parte del tempo in realta'
l'ho persa sulla configurazione del proxy aziendale (*) ) ma il problema
e' un altro:
a me fare queste cose non piace!
A differenza di "scrivere codice".
Questo e' il punto. Se volessi tornare a fare il programmatore dovrei
prepararmi a stare la maggior parte del tempo a fare cose che non mi piace
fare!
Ciao,
Marco
(*)
anche perche' il proxy va configurato impostando delle regole (non solo
sul browser, ma bisogna impostare un "proxy di sistema") che potrebbero
somigliare alle seguenti:
usa il proxy
ma non usare il proxy se ti connetti a
*.poste.rete, *.postecom.it, *poste.local, 192.168.qualcosa/qualcosaltro,
62.qualcosa/qualcosaltro
Se te ne dimentichi ad esempio uno, accade che alcune cose funzionano,
altre no. E non capisci ad esempio perche' magari riesci a navigare su
internet ma non riesci a far funzionare apt-get
Il problema e' anche stato che fino a qualche giorno prima le regole erano
tali per cui per navigare su internet dovevi usare il proxy ma non c'era
bisogno di alcun proxy di sistema (per cui maven fungeva anche senza
proxy) e le "esclusioni" fino a qualche giorno prima erano diverse. Senza
contare che poi pare che le esclusioni da fare sul proxy di sistema quando
si usa linux siano diverse da quelle da fare quando si usa windows (non
chiedetemi perche')...
E siccome le "regole da impostare" sono cambiate mentre io facevo le
prove, capitava che un giorno una roba funzionava, il giorno dopo non
piu', oppure su una macchina funzionava tutto, sull'altra una mazza, ecc.
Quindi finche' non ho chiesto al tizio che si occupa della rete, nada...
(non e' che mi posso inventare gli address da escludere dal proxy)
Per altro, sulla configurazione di maven: ma perche' non standardizzano
*dove* questo file deve stare (qualcuno dice "prova /usr/<qualcosa>, altri
dicono che dovrebbe stare in $USER_HOME/.m2, ecc. Io l'ho trovato (con
find) in /etc/<qualcosa>).
Insomma sono cose che a me non piace fare, anche se le risolvessi in 1
millisecondo.
Ciao,
Marco
TheStylist
> On 1 Ott, 13:00, "JOKER Ltd."<joker_...@libero.it> wrote:
> Sarà brutto, ma è "nella scatola" con Visual Studio.
infatti, è parte integrante del "pacco" che ti rifila
la microzozz
;-)
ispas
> E' la filosofia 'program to an interface, not an implementation' :-)
> Di solito, con le specifiche, ci sono anche le reference implementation: quindi
> non è che la Sun - ehm, la Oracle - fa gli standard e poi lascia tutto al caso.
Ma Hibernate o JBoss, cioè quelli che sono così diffusi ed
apprezzati, li ha fatti la Sun? Non mi risulta. Qualcosa di oscuro
c'è
> Non è tanto questione di cambiare, quanto di restare aggiornati (forse non mi
> sono spiegato bene). Ad esempio, per un'applicazione nuova, noi continuamo ad
> usare una versione di un application server che avrà tre anni :-/
Non so in che ambiente operi. Ma ti assicuro che in installazioni
medio-grandi il fatto di aggiornare un componente importante di
sistema, come l'.A.S., è un'operazione delicatissima, che richiede
studi approfonditi, in relazione a quanto dicevo prima, cioè che nel
sistema continua certamente a girare grossa quantità di codice vecchio
di anni.
E tutti questi studi di analisi, oltre al cambio vero e proprio,
costano bei soldoni (decine di migliaia di euro).
Certo, hai ragione nel lungo termine. Se per risparmiare, o per
semplice timore di problemi, l'aggiornamento non si fa mai, alla fine
ti trovi a dover saltare di N versioni in una volta, con lavoro di
adattamento decuplicato (e costi idem).
Va trovata la giusta via di mezzo, forse 3 anni sono pochi, 5 no.
Oppure una "major release" con funzionalità nuove molto utili.
Chiaro che se usi un prodotto giovane, come era Java EE nel 2001-2002
(*), rischi di dover fare aggiornamenti più frequenti.
(*) date del progetto che conosco
rootkit
>> credimi se ti dico che quello in cui sei affogato non è neanche un
>> bicchiere, ma una tazzina d'acqua.
>
> Non lo metto in dubbio (anche se la maggior parte del tempo in realta'
> l'ho persa sulla configurazione del proxy aziendale (*) ) ma il problema
> e' un altro:
>
> a me fare queste cose non piace!
> A differenza di "scrivere codice".
ho capito, e allora? fermate il mondo che voglio scendere? che ogni
tanto ti capiti di dover "fare queste cose" non mi pare un fatto che
alla tua età ti debba cogliere di sorpresa.
> Se te ne dimentichi ad esempio uno, accade che alcune cose funzionano,
> altre no. E non capisci ad esempio perche' magari riesci a navigare su
> internet ma non riesci a far funzionare apt-get
le esclusioni? mmm... no, secondo me sei del tutto fuori strada.
sudo bash
export http_proxy=http://username:password@indirizzo_proxy:porta
export ftp_proxy=http://username:password@indirizzo_proxy:porta
apt-get install quellochetipare
e vedrai che funziona.
> Per altro, sulla configurazione di maven: ma perche' non standardizzano
> *dove* questo file deve stare (qualcuno dice "prova /usr/<qualcosa>, altri
> dicono che dovrebbe stare in $USER_HOME/.m2, ecc. Io l'ho trovato (con
> find) in /etc/<qualcosa>).
il settings.xml? deve stare sotto ~/.m2, ma fintanto non ce lo crei hai
voglia di cercarlo :P
rootkit
> Sarà brutto, ma è "nella scatola" con Visual Studio. Se vado sul sito
> Sun e scarico JavaEE nella scatola c'è un web server decente, a
> livello EE? Non mi risulta. Questa frammentazione è perlomeno
> fastidiosa.
perché glassfish non ti piace?
rootkit
> Non capisco perchč questi build tool non son inglobati nelle IDE di
> Java, Eclipse, Netbeans.
perché lo sono, ecco perché non capisci.
ma ti dirň di piů, durante la fase di sviluppo e debug non sono neanche
necessari piů di tanto. specialmente maven:
http://maven.apache.org/what-is-maven.html
se ci pensi un attimo l'integrazione con l'ide ti serve giusto per avere
le dipendenze risolte.
> Ecco, non capisco perchč allora si debba ricorrere a pacchetti
> esterni come Hybernate.
perché non č necessario, ecco perché non capisci.
l'implementazione di riferimento č toplink che, per tua sommo gaudio, č
distribuita nel download jee del sito della sun. hibernate č solo una
delle tante, forse la piů evoluta e performante:
http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
nota come anche in .net i progetti alternativi siano tutt'altro che
disdegnati.
ps: si scrive hibernate.
rootkit
> La risposta che puoi dare TE è che TE ti diverti e molti altri si
> divertono, e meno male, vuol dire che siamo diversi ed ognuno di noi
> fa quel che gli piace.
ah mettendola su questo piano stai sicuro poni una pietra tombale su
qualsiasi discussione. però le argomentazioni traballanti restano
traballanti.
http://www.oracle.com/technetwork/java/javaee/tech/index.html
giusto per sottolineare che le specifiche per le web application (da te
citate) rappresentano una frazione delle tecnologie abbracciate dal jee
e probabilmente anche la problematica meno interessante.
ngw
Sono entrambe tecnologie da startup, adatte ad ambienti altamente
innovativi e dove si rischia un po' di più, certamente non ad una
enterprise (anche se io li ho usati anche li).
Le aziende ci sono sia per Ruby che per Python, ma appunto sono aziende
che hanno a che fare con le startup (37Signals, EngineYard, Joyent) e
che quindi si rivolgono ad un mercato ben preciso.
Sono comunque tutte ottime tecnologie, dovessi lavorare in una
enterprise il mio problema sarebbe l'ambiente e il lavoro in se, mi
facessero usare Java semplicemente tenterei di introdurre Clojure, che
è uno dei linguaggi IMHO più interessanti, più di Scala (bello, ma la
cui sintassi mi sta ampiamente sulle palle, ne carne ne pesce), degli
ultimi tempi.
ngw
--
Nicholas Wieland (ngw)
Zooppa CTO
911 Western Avenue, Suite 420
Seattle, WA 98104 US
ngw
>> Ma anche per brad pyt(hon) vale lo stesso discorso. Con in piu' che se
>> non trovi quel che cvuoi ci metti poco a fartelo homemade.
>
> Beh, dai, in Java ci sono duemila web framework (poi, magari, mi dirai
> che fanno
> schifo rispetto a un Django o ad un Rails - ma questo è un altro discorso): è
> difficile non trovare qualcosa che sia adatti alle proprie esigenze. La
> quantità
> di librerie/tool per python credo sia oggettivamente minore, ma anche per una
> questione temporale.
Ho forti dubbi eh. Probabilmente c'è meno scelta, questo si, ma il
range dovrebbe essere più o meno equivalente. Python è dell'89/90
comunque, precedente a Java.
Comunque sono 2 tecnologie che si sposano meravigliosamente insieme, io
ad esempio sto usando Hadoop da Ruby, che è in Java.
rootkit
> Per quanto riguarda i build tool non saprei che dirti: li odio con tutto il mio
> cuore, ma in molti contesti sono necessari. Noi di solito usiamo ant ed è un
> pacco incredibile (altro xml da modificare!); per i fatti miei ho usato un paio
> di volte maven, e seppur rigido, mi è sembrato parecchio semplice da utilizzare
> (ok, anche lui ha i file di configurazione in xml...).
i build tool sono *essenziali* per standardizzare il processo. giusto ai
peggio microsoftisti può venire in mente di fare i rilasci manualmente
da dentro l'ide.
Equinozio
> citate) rappresentano una frazione delle tecnologie abbracciate dal jee
> e probabilmente anche la problematica meno interessante.
Ma si ruzza... che poi a fare in jee un sistema ad alte prestazioni
magari su socket tcp/ip con più app server mi divertirei anche io. E'
che alla fine per il tipo di lavoro che piace fare a me j2ee non è lo
strumento adatto.
rootkit
> Ma Hibernate o JBoss, cioč quelli che sono cosě diffusi ed
> apprezzati, li ha fatti la Sun? Non mi risulta. Qualcosa di oscuro
> c'č
eh, sapessi...
http://www.youtube.com/watch?v=uRvRZNCYXk4
JOKER Ltd.
> complimenti alla tua ditta e te :-)).
Sono un autonomo (per scaricare qualcosa, visto che lavoro lontano da
casa) ma alla fin fine lavoro quasi come un interno. Qui si usa python
(e C) da sempre (10 anni quasi) twisted (dalla 2.0), ora TurboGears2.x
per la parte di interfaccia utente web. Pero' il mio ultimo lavoro da
freelance una applicazione client/server scritta in WxPython, e
colloqui (quando poi ho avuto l'offerta qui) con una ditta di Fiernze
(che pero' non ho sostenuto visto che la mia base logistica di Modena
era incompatibile con gli orari di Trenitalia per Firenze) ed uno con
una ditta di ferrara. Entrambe lavorano con Python. In aria avevo, ma
poi ho annullato un paio di offerte su Roma. parlo sempre di Pythno
(varie salse da Zope/Plone a TG2.0, a Twisted, WxPython, PyQT etc.).
Ah subito dopo che avevo iniziato qui (Giugno) ho visto una offerta
interessante su Ancona, sempre per Python.
Python sta crescendo. Sempre piu' aziende medio/piccole lo usano. Non
arriva all'enterprise, ma non mi ineterssa,. Nel mondo $Banca/
$GrandeAzienda/$simili, preferisco non lavorare. Piuttosto mi arrangio
a fare cose da freelance. Ho rifiutato un secondo colloquio (per
deinire accordi) diretti con CRIF (senza contare i 5 o 6 BR che in
periodi successivi hanno cercato di mandamici; facevo gentilmente
notare loro che avendo rifiutato un contatto diretto non ero certo
interessato ad uno indiretto). Idem per Banca mediolanum (ma li anche
altri motivi alla base, ascoltare le voci stupite dei proponenti
quando mi dicevano: ma sa di chi e' si? E io: appunto, per quelli li
non lavoro.). Voglio dire non sono un geniaccio (vedo che sul Ng ci
sono parecchi che mi danno la paga tranquillamente su certe cose) ma
ho 21 anni di mestiere addosso. Qualcos, nonostante i miei limiti la
ho imparata per abitudine (esempio fare una raccolta di specifiche e
relativa analisi funzionale con tempi&costi che di rado il cliente
finale puo' pi dire: ma io avevo capito che ...).
E se ho deciso di lavorare in Python e' perche' trovo che sia il modo
migliore e piu' divertente di fare programmazione, Se dovessi nadare a
lavorare con J2EE ad esempio (ma avevo rifiutato anche offrte in
C#)cambio e mi metto vendere piadine.
> Passerei anche io a qualcosa di più
> 'divertente', ma per come vanno le cose qui in Italia adesso preferisco
> specializzarmi un po' di più su Java.
Beh nel mondo python cresce. Qui siamo un poco indietro ma si vede che
si muove qualcosa.
Java vivra' fino a che sara' interesse di Oracle. Se domani trova una
cosa che gli costa meno mantenere, java si estingue in due anni.
Java e' per il mondo enteprise. In quei posti si e' pati di un
ingranaggio. E sostituibili a caldo. Tolgono uno e ci mettono
uin'altro. Tempo 1 settimana non si nota neppure la differenza.
Io lavoro adesso in un progetto (parte di frontend cliente) di
riscrittura (v. 2.0) di un applicativo di monitoraggio e sicurezza
networking (clienti grandicelli, non posso fare nomi ma roba diciamo
per omini vestiti di grigioverde, oppure altissime cariche (non
esplosive) dell stato etc.).
Dopo 3 mesi che sto' nella cosa conosco benino il 10% del prodotto (e
di questo 10% una meta' e' la nostra riscrittura). Se va via uno non
lo sostituiscono cosi'. Quando ho fatto il collquio il boss mi ha
detto:
"Non ci serve un consulente che sta qui 6 mesi e poi va via. Noi
investiam sulle persone, chi lavora con noi deve garantirci almeno 3 o
4 anni di disponiblita' continua".
QUindi dipende sempre tutto da che target di cliente/datore di lavoro
hai.
> Beh, dai, in Java ci sono duemila web framework (poi, magari, mi dirai che fanno
> schifo rispetto a un Django o ad un Rails - ma questo è un altro discorso):
Django e ROR hanno un punto in comune: entrmbi sono favolosi per fare
quello che vogliono loro.
Se pero' vuoi fare Tu qualcosa ti picchiano (uno ti tiene per le
braccia a l'altro ti lavora ai fianchi). Mi fanno venire in mente
Delphi e C++ Builder. Nel senso che sono differenti piu' che altro a
livello di linguaggio sotto e di sintassi.
Io ho scelto TG2.0 perche' e' un MiddleWare che permette di usare (o
sostituire) qualsiasi componente. Anche se parte con una dotazione
favolosa: Genshi+Pylons+SqlAlchemy+èun framework js a scelta,
consigliati Dojo o JQuery].
> è difficile non trovare qualcosa che sia adatti alle proprie esigenze. La quantità
> di librerie/tool per python credo sia oggettivamente minore, ma anche per una
> questione temporale.
E' piu' o meno coetaneo di java 1.2. Sai quanti WebServer Python
esistono? Troppi. Perche' parecchi si scrivono il loro (uno minimale
che risponde alle HTTPRequest necessita' di non piu' di 4 righe,
inclusa la def).
Se non hai una lib pronta la fai in pochi giorni. In java se non ci
fosse faresti prima a cambiare specifiche. :)
Greetings
JOKER Ltd.
JOKER Ltd.
> ad esempio sto usando Hadoop da Ruby, che è in Java.
Beh ci sarebbe anche (ma IMHO una gran porcata al pari di IronPython
*) Jthon, che usa le librerie java (oltre ad avere l'interprete
scritto in java),
* A che serve scrivere codice python se poi diventa metacodice .NET?
In pratica il dinamismo del linguaggio va a farsi benedire.
P.S: A me Ruby non convince. Questione di gusti, sia chiaro, ma come
chiarezza di sintassi, Python fino ad ora non ha rivali. Certo se vuoi
scrivi roba di merda (context di Obfuscated Python ce ne sono), ma
devi odiarti parecchio per farlo.
Greetings
JOKER Ltd.
JOKER Ltd.
insulti a vicenda?
Ciascuno esprime i suoi pareri senza magiarsi chi la pensa in maniera
diversa.
Si vede che si avvicina il 2012 e l'ebento che cambiera' il mondo
previsto dal calendario Maja. :)
Greetings
JOKER Ltd.
ngw
>>
>> Comunque sono 2 tecnologie che si sposano meravigliosamente insieme, io
>> ad esempio sto usando Hadoop da Ruby, che č in Java.
>
> Beh ci sarebbe anche (ma IMHO una gran porcata al pari di IronPython
> *) Jthon, che usa le librerie java (oltre ad avere l'interprete
> scritto in java),
>
> * A che serve scrivere codice python se poi diventa metacodice .NET?
> In pratica il dinamismo del linguaggio va a farsi benedire.
Forse prima di parlare potrebbe essere interessante provarli o
informarsi un minimo, visto che no, non perdi niente, cambia soltanto
il backend. Il CLR non era in grado di reggere Python credo nel 2002,
oggi puo' far girare anche un linguaggio come F#, che di "dinamismo" ne
ha assai di piů di Python.
> P.S: A me Ruby non convince. Questione di gusti, sia chiaro, ma come
> chiarezza di sintassi, Python fino ad ora non ha rivali. Certo se vuoi
> scrivi roba di merda (context di Obfuscated Python ce ne sono), ma
> devi odiarti parecchio per farlo.
A chi usa Python tipicamente piace Python, a chi usa Ruby tipicamente
piace Ruby. Sono piccole grandi scoperte.
Manuel T
> orse tra qualche anno
> vedremo il cadavere dell'xml passare nel fiume :-)
O forse no, visto che di XML grazie al suo DTD, si può verificare la
correttezza formale.
Manuel T
> i build tool sono essenziali per standardizzare il processo. giusto ai
> peggio microsoftisti può venire in mente di fare i rilasci manualmente
> da dentro l'ide.
Quoto, che cavolo!
Poter essere indipendenti da un ambiente di sviluppo è un punto di forza di
tutto il processo, non uno svantaggio!
Per questo mi piacciono tantissimo sia Ant che Maven.
Manuel T
> Credo che ant sia quasi considerato uno standard, ed è integrato sia con
> Netbeans sia con Eclipse (per maven credo servano dei plugin, ma non sono
> molto aggiornato). Ant non ha bisogno di configurazioni particolari:
> certo, bisogna dirgli cosa deve fare :-)
Netbeans produce il "makefile" ant per ogni progetto che inizi. Questo
script puoi usarlo benissimo fuori dall'ambiente di sviluppo. Inoltre
supporta nativamente i progetti maven. Puoi aprirli direttamente dentro
netbeans.
Eclipse ha una buona integrazione con ant, ma nulla so dire di maven.
Ricordo che lo supporti ugualmente bene.
Marcoxxx
> Il 01/10/10 16.28, Marcoxxx ha scritto:
> >> credimi se ti dico che quello in cui sei affogato non è neanche un
> >> bicchiere, ma una tazzina d'acqua.
> >
> > Non lo metto in dubbio (anche se la maggior parte del tempo in realta'
> > l'ho persa sulla configurazione del proxy aziendale (*) ) ma il problema
> > e' un altro:
> >
> > a me fare queste cose non piace!
> > A differenza di "scrivere codice".
> ho capito, e allora? fermate il mondo che voglio scendere?
Scusa ma il titolo del thread era: "perche' non voglio piu' fare il
programmatore". E la risposta e': perche' devo passare tempo (direi molto:
pensa se dovevo anche mettere la mani sul pom del progetto!) a fare cose
che non mi piacciono!!
> che ogni
> tanto ti capiti di dover "fare queste cose" non mi pare un fatto che
> alla tua età ti debba cogliere di sorpresa.
Infatti e' per questo che non mi piacerebbe l' idea di rimettermi a fare
il programmatore. Una volta capitava molto di meno di doversi mettere a
fare queste cose
> > Se te ne dimentichi ad esempio uno, accade che alcune cose funzionano,
> > altre no. E non capisci ad esempio perche' magari riesci a navigare su
> > internet ma non riesci a far funzionare apt-get
> le esclusioni? mmm... no, secondo me sei del tutto fuori strada.
Mi sa che non ci capiamo. Io questa cosa che hai scritto sotto non
l'ho mai fatta. E nemmeno il tizio che e' venuto quando l'ho chiamato
dicendogli che apt-get qualche giorno prima funzionava e ora non piu'.
Quello ha semplicemente cambiato gli address da escludere dal proxy di
sistema e tutto ha funzionato. Questo che tu ci creda o meno.
Poi puo' anche essere che quello che scrivi qui sotto risolvesse
analogamente il problema, sinceramente non lo so [tranne l'ftp: quello e'
proprio bloccato per policy aziendale dalle postazioni di lavoro e non lo
si puo' usare in nessun caso e verso nessun server, proxy o non proxy.
Quindi se fosse impostato per default qualche repository ftp da cui
apt-get deve scaricarsi i file, questo andrebbe cambiato. Ma avevo
verificato in precedenza che i repository erano http].
Ed evidentemente non lo sapeva nemmeno il tizio che e' venuto che si puo'
fare qualcosa del tipo sotto.
> sudo bash
> export http_proxy=http://username:password@indirizzo_proxy:porta
> export ftp_proxy=http://username:password@indirizzo_proxy:porta
> apt-get install quellochetipare
> e vedrai che funziona.
Tra l'altro il proxy aziendale non richiede alcuna autenticazione (e
ricordo benessimo che quando [ormai circa 2 anni fa] vennero a dirci: "da
oggi per navigare su internet dovrete usare un proxy", aggiunsero anche
che l'unico scopo del proxy era quello di evitare che si potesse andare su
"siti pedopornografici" e che tutto il resto avrebbe continuato a
funzionare come prima)
> > Per altro, sulla configurazione di maven: ma perche' non standardizzano
> > *dove* questo file deve stare (qualcuno dice "prova /usr/<qualcosa>, altri
> > dicono che dovrebbe stare in $USER_HOME/.m2, ecc. Io l'ho trovato (con
> > find) in /etc/<qualcosa>).
> il settings.xml? deve stare sotto ~/.m2, ma fintanto non ce lo crei hai
> voglia di cercarlo :P
Se fai
sudo apt-get install maven2
dopo che quello ha installato maven, settings.xml lo trovi in
/etc/<qualcosacheoranonmiricordo>.
Non l'ho certo creato io (per fortuna, perche' se dovevo anche mettermi a
scrivere tutto l'xml di tale file potevo anche darmi una martellata sugli
zebedei...)
E quello sotto /etc/... e' proprio quello che il maven installato da
apt-get usa, visto che il proxy per maven l'ho configurato li' dentro e
tutto ha funzionato! (mentre prima che lo configurassi li' dentro
funzionava tutto, tranne maven. E questo parrebbe dimostrare che maven
effettivamente quel file se lo va a leggere).
Proprio questa cosa che mi dici sopra (che settings.xml deve stare in
~/.m2, come avevo anche letto in giro su internet), unita a quello che ho
visto con i miei occhi (ovvero che apt-get install maven2 si scarica un
file settings.xml che non e' dove dovrebbe essere e pero' lo usa
tranquillamente) e' un altro dei motivi per cui non mi va molto di fare
il programmatore (specialmente poi se tale file xml dovessi crearlo io da
zero).
E' anche vero che tra le numerose prove che ho fatto per capire perche'
apt-get non fungesse c'e' anche stata quella di cambiare il repository da
cui si va a scaricare i software, per cui magari ne ho lasciato qualcuno
"strano" configurato, ma se rispettassero lo standard, tutti i repository
dovrebbero essere tali da far finire quel file in ~/.m2/
E, da quel poco che posso vedere io, questi casi diciamo un po'
"approssimativi" in j2ee [cioe' ad esempio tu sai che un file deve stare
in un punto e lo trovi invece da un' altra parte] capitano circa il 100%
delle volte che ci si mette le mani (oppure puo' sempre valere la tesi che
sono sfigato io. Magari se un altro esegue
sudo apt-get install maven2
il file glielo mette esattamente dove deve stare...)
Marcoxxx
> Scusa ma il titolo del thread era: "perche' non voglio piu' fare il
> programmatore". E la risposta e': perche' devo passare tempo (direi molto:
> pensa se dovevo anche mettere la mani sul pom del progetto!) a fare cose
> che non mi piacciono!!
> > che ogni
> > tanto ti capiti di dover "fare queste cose" non mi pare un fatto che
> > alla tua età ti debba cogliere di sorpresa.
> Infatti e' per questo che non mi piacerebbe l' idea di rimettermi a fare
> il programmatore. Una volta capitava molto di meno di doversi mettere a
> fare queste cose
Preciso meglio:
quanto scritto sopra e' relativo alla "motivazione tecnica" per cui non mi
andrebbe molto di rimettermi a fare il programmatore.
Ma il motivo principale e' comunque quello che dicevo nell'altro thread:
la scarsa considerazione delle aziende per la figura del tecnico
programmatore (e anche del sistemista, se e' per questo)
ispas
> necessari più di tanto. specialmente maven:http://maven.apache.org/what-is-maven.html
> se ci pensi un attimo l'integrazione con l'ide ti serve giusto per avere
> le dipendenze risolte.
Bella notizia. Allora, perchè parlare di Maven, Hibernate, ecc. come
prodotto a sè, se stanno tutti dentro all'IDE?
> perché non è necessario, ecco perché non capisci.
> l'implementazione di riferimento è toplink che, per tua sommo gaudio, è
> distribuita nel download jee del sito della sun. hibernate è solo una
> delle tante, forse la più evoluta e performante:http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
Non è necessario, ma tanti ci ricorrono. Si vede che questo Toplink
non è un granchè, o forse è venuto dopo.
> nota come anche in .net i progetti alternativi siano tutt'altro che
> disdegnati.
Questo è vero. Anche Net non è che sia tanto più semplice di JavaEE.
ispas
> Poter essere indipendenti da un ambiente di sviluppo è un punto di forza di
> tutto il processo, non uno svantaggio!
Perchè, cambi facilmente ambiente di sviluppo ma non cambi mai tools
di building? Improbabile.
Semmai mi puoi dire che avere tanti pezzi differenti e ben separati ti
dà il vantaggio di una grande flessibilità, ma lo svantaggio di
ammattire, talvolta, per rimettere assieme le cose. Come è capitato a
Marco, e capita a tutti.
rootkit
>> perché lo sono, ecco perché non capisci.
>> ma ti dirò di più, durante la fase di sviluppo e debug non sono neanche
>> necessari più di tanto. specialmente maven:http://maven.apache.org/what-is-maven.html
>> se ci pensi un attimo l'integrazione con l'ide ti serve giusto per avere
>> le dipendenze risolte.
>
> Bella notizia. Allora, perchè parlare di Maven, Hibernate, ecc. come
> prodotto a sè, se stanno tutti dentro all'IDE?
per quanto riguarda hibernate (che non ho capito perché l'avete preso di
punta) è una libreria come un'altra che includi o meno nelle dipendenze
del tuo progetto.
maven e ant invece sono due tool di cui i principali ide (eclipse e
netbeans) integrano i progetti, come ti dicevo prima. niente di che, è
lo stesso discorso che faceva visual studio quando ti faceva importare
il makefile.
>> perché non è necessario, ecco perché non capisci.
>> l'implementazione di riferimento è toplink che, per tua sommo gaudio, è
>> distribuita nel download jee del sito della sun. hibernate è solo una
>> delle tante, forse la più evoluta e performante:http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
>
> Non è necessario, ma tanti ci ricorrono.
ammesso che sia vero (non sto a discuterne), il problema di preciso sarebbe?
rootkit
>> Poter essere indipendenti da un ambiente di sviluppo è un punto di forza di
>> tutto il processo, non uno svantaggio!
>
> Perchè, cambi facilmente ambiente di sviluppo ma non cambi mai tools
> di building? Improbabile.
non hai capito. e credo sia tempo perso spiegare.
rootkit
>> il settings.xml? deve stare sotto ~/.m2, ma fintanto non ce lo crei hai
>> voglia di cercarlo :P
>
> Se fai
> sudo apt-get install maven2
>
>
> dopo che quello ha installato maven, settings.xml lo trovi in
> /etc/<qualcosacheoranonmiricordo>.
>
> Non l'ho certo creato io (per fortuna, perche' se dovevo anche mettermi a
> scrivere tutto l'xml di tale file potevo anche darmi una martellata sugli
> zebedei...)
le impostazioni locali sono corrette sotto ~/.m2, credimi se te lo dico
e se non mi vuoi credere guarda la documentazione.
e in ogni caso prima di darti la martellata negli zebedei sappi che lě
dentro tipicamente ci sono solo le impostazioni proxy (toh?) quindi
cinque righe scopiazzate e basta.
> E' anche vero che tra le numerose prove che ho fatto per capire perche'
> apt-get non fungesse c'e' anche stata quella di cambiare il repository da
> cui si va a scaricare i software, per cui magari ne ho lasciato qualcuno
> "strano" configurato, ma se rispettassero lo standard, tutti i repository
> dovrebbero essere tali da far finire quel file in ~/.m2/
guarda che sotto ~/.m2/ c'č la configurazione di *maven2*, non di apt.
scusa se mi permetto ma che bordello c'hai nella testa? se sei confuso a
questi livelli sfido che non vuoi fare piů il programmatore, solo che
non saprei che altro lavoro di concetto consigliarti eh...
Quincy Magoo
> On 2 Ott, 14:51, Manuel T <man...@t.gov> wrote:
>> Poter essere indipendenti da un ambiente di sviluppo è un punto di
> > forza di
>> tutto il processo, non uno svantaggio!
>
> Perchè, cambi facilmente ambiente di sviluppo ma non cambi mai tools
> di building? Improbabile.
E che cappero c'entra?
L'ambiente IDE puoi averlo diverso a seconda delle preferenze dello
sviluppatore.
> Semmai mi puoi dire che avere tanti pezzi differenti e ben separati ti
> dà il vantaggio di una grande flessibilità, ma lo svantaggio di
> ammattire, talvolta, per rimettere assieme le cose. Come è capitato a
> Marco, e capita a tutti.
No non capita a tutti. Marco è rimasto piantato su un non-problema che
con Maven c'entra come il cavolo a merenda. Maven si lancia da linea di
comando e "magicamente" fa tutto, da risolvere e scaricare le dipendenze
fino a installare la versione passando per compilazione, test,
generazione doc e altro ancora. Marco non doveva fare NIENT'ALTRO che
questo che tu ci creda o no.
--
from iPad
Cicap
> Provo a compilare il software con il notebook linux => non mi funziona una
> mazza (apt-get non funziona nella rete aziendale e non capisco perche',
> mentre a casa funziona; se anche a casa funziona e mi installo maven, poi
> nella rete aziendale quando lancio maven questo non riesce a collegarsi al
> suo repository, ecc.)
Se funge a casa, basta che lo lanci da casa e poi usi lo switch "-o",
che significa appunto offline. Cioè non va sui repository remoti, ma
interroga unicamente quello locale, che secondo quanto dici dovrebbe già
aver tutte le librerie al posto giusto (hai detto che hai provato da casa).
> a gia'... il proxy...
Solitamente se si vedono errori del tipo che hai descritto, la prima
cosa che fanno è aprire il browser e provare a collegarsi a Google. Tu
ci sei arrivato dopo parecchie ore.
Direi che il problema è tuo, non di maven e neppure di chissà chi altro.
non e' che ora devo configurare il proxy anche su
> maven ? Ci provo... dove e' il file di configurazione di maven ?
> cerco su internet. Di solito e' in<$YOUR_HOME>/m2/...
>
> ma in<$YOUR_HOME>/m2/... io non trovo una cippa....
>
> a gia'... ma io l'ho installato con apt-get. Chissa' dove l'ha messo.
> Cerco su internet. Dicono che a volte sta in /usr/<qualcosa>
>
> io in usr/<qualcosa> non trovo una mazza
>
> Allora vai di find ./ -iname "<file di configurazione di maven, che non mi
> ricordo nemmeno piu' come si chiama tanto mi sta sulle balle>"
bastava fare
locate settings.xml
Fine.
> Conclusione:
La tua ignoranza su Maven e non solo ti hanno fatto perdere un sacco di
giorni.
Cicap
> On Oct 1, 12:44 am, aritopogig...@web.de (Marcoxxx) wrote:
>
>> Provo a compilare il software con il notebook linux => non mi funziona una
>> mazza (apt-get non funziona nella rete aziendale e non capisco perche',
>> mentre a casa funziona; se anche a casa funziona e mi installo maven, poi
>> nella rete aziendale quando lancio maven questo non riesce a collegarsi al
>> suo repository, ecc.)
>
> bicchiere, ma una tazzina d'acqua.
A partire dall'errore. Questo si è messo a cercare l'errore di
programmazione senza neanche eseguire e provare a debuggare il sistema.
Probabilmente con un approccio più sensato ci avrebbe messo....cinque
minuti (al netto della sua incapacità con maven).
TheStylist
[CUT]
> Infatti e' per questo che non mi piacerebbe l' idea di rimettermi a fare
> il programmatore. Una volta capitava molto di meno di doversi mettere a
> fare queste cose
è la crisi
Marcoxxx
[SNIP]
> le impostazioni locali sono corrette sotto ~/.m2, credimi se te lo dico
> e se non mi vuoi credere guarda la documentazione.
Non lo metto in dubbio; infatti mi aspettavo di trovarlo li'. Pero'
"l'installatore automatico" lo ha messo da un'altra parte (in/etc/maven2/).
> e in ogni caso prima di darti la martellata negli zebedei sappi che lě
> dentro tipicamente ci sono solo le impostazioni proxy (toh?) quindi
> cinque righe scopiazzate e basta.
Riporto piu' avanti il file settings.xml che lui ha messo in /etc/maven2.
Effettivamente e' quasi tutto commentato e lo era anche la parte del
proxy. Quella l'ho decommentata io. E' vero che e' quasi tutto commentato
(ma non e' "decommentata" solo la parte del proxy) e se mi dici che serve
solo quella ci credo, ma io quando vedo un file del genere e devo fare il
programmatore, cerco di capire a che serve ognuna di quelle parti (che non
sono 5 righe)
guarda che sotto ~/.m2/ c'č la configurazione di *maven2*, non di apt.
> scusa se mi permetto ma che bordello c'hai nella testa?
Si parlava tra tecnici, o almeno pensavo.
Mi pareva ovvio che stavo dicendo una cosa del tipo: "magari se usavo un
altro repository di apt-get, su quest'altro repository avrebbero potuto
esserci delle "regole" che consentivano ad apt-get install di mettere il
file settings.xml in ~/.m2". E magari il file che verrebbe eventualmente
messo in ~/.m2 potrebbe anche essere diverso da quello che nel mio caso e'
stato messo in /etc/maven2. Se a te pare scontato che qualsiasi sia il
repository, quello faccia sempre e comunque la stessa cosa... A me, senza
conoscere i dettagli di funzionamento, parrebbe scontato l'esatto opposto
se sei confuso a
> questi livelli sfido che non vuoi fare piů il programmatore, solo che
> non saprei che altro lavoro di concetto consigliarti eh...
Vedi sopra.... Pensavo che queste cose per un tecnico dovessero essere
scontate...
Sotto il file settings.xml che apt-get install ha scaricato in /etc/maven2/
Sebbene la maggior parte delle cose sia commentata, non mi sembrano 5
righe.
Ciao,
Marco.
-------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
<!--
| This is the configuration file for Maven. It can be specified at two
levels:
|
| 1. User Level. This settings.xml file provides configuration for a
single user,
| and is normally provided in
${user.home}/.m2/settings.xml.
|
| NOTE: This location can be overridden with the CLI
option:
|
| -s /path/to/user/settings.xml
|
| 2. Global Level. This settings.xml file provides configuration for all
Maven
| users on a machine (assuming they're all using the same
Maven
| installation). It's normally provided in
| ${maven.home}/conf/settings.xml.
|
| NOTE: This location can be overridden with the CLI
option:
|
| -gs /path/to/global/settings.xml
|
| The sections in this sample file are intended to give you a running
start at
| getting the most out of your Maven installation. Where appropriate, the
default
| values (values used when the setting is not specified) are provided.
|
|-->
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
<!-- localRepository
| The path to the local repository maven will use to store artifacts.
|
| Default: ~/.m2/repository
<localRepository>/path/to/local/repo</localRepository>
-->
<!-- interactiveMode
| This will determine whether maven prompts you when it needs input. If
set to false,
| maven will use a sensible default value, perhaps based on some other
setting, for
| the parameter in question.
|
| Default: true
<interactiveMode>true</interactiveMode>
-->
<!-- offline
| Determines whether maven should attempt to connect to the network
when executing a build.
| This will have an effect on artifact downloads, artifact deployment,
and others.
|
| Default: false
<offline>false</offline>
-->
<!-- pluginGroups
| This is a list of additional group identifiers that will be searched
when resolving plugins by their prefix, i.e.
| when invoking a command line like "mvn prefix:goal". Maven will
automatically add the group identifiers
| "org.apache.maven.plugins" and "org.codehaus.mojo" if these are not
already contained in the list.
|-->
<pluginGroups>
<!-- pluginGroup
| Specifies a further group identifier to use for plugin lookup.
<pluginGroup>com.your.plugins</pluginGroup>
-->
</pluginGroups>
<!-- proxies
| This is a list of proxies which can be used on this machine to
connect to the network.
| Unless otherwise specified (by system property or command-line
switch), the first proxy
| specification in this list marked as active will be used.
|-->
<proxies>
<!-- proxy
| Specification for one proxy, to be used in connecting to the
network.
|
-->
<proxy>
<id>proxolo</id>
<active>true</active>
<protocol>http</protocol>
<!--username>proxyuser</username>
<password>proxypass</password-->
<host>proxolo.cs.poste.it</host>
<port>8080</port>
<!--nonProxyHosts>local.net|some.host.com</nonProxyHosts-->
</proxy>
</proxies>
<!-- servers
| This is a list of authentication profiles, keyed by the server-id
used within the system.
| Authentication profiles can be used whenever maven must make a
connection to a remote server.
|-->
<servers>
<!-- server
| Specifies the authentication information to use when connecting to
a particular server, identified by
| a unique name within the system (referred to by the 'id' attribute
below).
|
| NOTE: You should either specify username/password OR
privateKey/passphrase, since these pairings are
| used together.
|
<server>
<id>deploymentRepo</id>
<username>repouser</username>
<password>repopwd</password>
</server>
-->
<!-- Another sample, using keys to authenticate.
<server>
<id>siteServer</id>
<privateKey>/path/to/private/key</privateKey>
<passphrase>optional; leave empty if not used.</passphrase>
</server>
-->
</servers>
<!-- mirrors
| This is a list of mirrors to be used in downloading artifacts from
remote repositories.
|
| It works like this: a POM may declare a repository to use in
resolving certain artifacts.
| However, this repository may have problems with heavy traffic at
times, so people have mirrored
| it to several places.
|
| That repository definition will have a unique id, so we can create a
mirror reference for that
| repository, to be used as an alternate download site. The mirror site
will be the preferred
| server for that repository.
|-->
<mirrors>
<!-- mirror
| Specifies a repository mirror site to use instead of a given
repository. The repository that
| this mirror serves has an ID that matches the mirrorOf element of
this mirror. IDs are used
| for inheritance and direct lookup purposes, and must be unique
across the set of mirrors.
|
<mirror>
<id>mirrorId</id>
<mirrorOf>repositoryId</mirrorOf>
<name>Human Readable Name for this Mirror.</name>
<url>http://my.repository.com/repo/path</url>
</mirror>
-->
</mirrors>
<!-- profiles
| This is a list of profiles which can be activated in a variety of
ways, and which can modify
| the build process. Profiles provided in the settings.xml are intended
to provide local machine-
| specific paths and repository locations which allow the build to work
in the local environment.
|
| For example, if you have an integration testing plugin - like cactus
- that needs to know where
| your Tomcat instance is installed, you can provide a variable here
such that the variable is
| dereferenced during the build process to configure the cactus plugin.
|
| As noted above, profiles can be activated in a variety of ways. One
way - the activeProfiles
| section of this document (settings.xml) - will be discussed later.
Another way essentially
| relies on the detection of a system property, either matching a
particular value for the property,
| or merely testing its existence. Profiles can also be activated by
JDK version prefix, where a
| value of '1.4' might activate a profile when the build is executed on
a JDK version of '1.4.2_07'.
| Finally, the list of active profiles can be specified directly from
the command line.
|
| NOTE: For profiles defined in the settings.xml, you are restricted to
specifying only artifact
| repositories, plugin repositories, and free-form properties to
be used as configuration
| variables for plugins in the POM.
|
|-->
<profiles>
<!-- profile
| Specifies a set of introductions to the build process, to be
activated using one or more of the
| mechanisms described above. For inheritance purposes, and to
activate profiles via <activatedProfiles/>
| or the command line, profiles have to have an ID that is unique.
|
| An encouraged best practice for profile identification is to use a
consistent naming convention
| for profiles, such as 'env-dev', 'env-test', 'env-production',
'user-jdcasey', 'user-brett', etc.
| This will make it more intuitive to understand what the set of
introduced profiles is attempting
| to accomplish, particularly when you only have a list of profile
id's for debug.
|
| This profile example uses the JDK version to trigger activation,
and provides a JDK-specific repo.
<profile>
<id>jdk-1.4</id>
<activation>
<jdk>1.4</jdk>
</activation>
<repositories>
<repository>
<id>jdk14</id>
<name>Repository for JDK 1.4 builds</name>
<url>http://www.myhost.com/maven/jdk14</url>
<layout>default</layout>
<snapshotPolicy>always</snapshotPolicy>
</repository>
</repositories>
</profile>
-->
<!--
| Here is another profile, activated by the system property
'target-env' with a value of 'dev',
| which provides a specific path to the Tomcat instance. To use this,
your plugin configuration
| might hypothetically look like:
|
| ...
| <plugin>
| <groupId>org.myco.myplugins</groupId>
| <artifactId>myplugin</artifactId>
|
| <configuration>
| <tomcatLocation>${tomcatPath}</tomcatLocation>
| </configuration>
| </plugin>
| ...
|
| NOTE: If you just wanted to inject this configuration whenever
someone set 'target-env' to
| anything, you could just leave off the <value/> inside the
activation-property.
|
<profile>
<id>env-dev</id>
<activation>
<property>
<name>target-env</name>
<value>dev</value>
</property>
</activation>
<properties>
<tomcatPath>/path/to/tomcat/instance</tomcatPath>
</properties>
</profile>
-->
</profiles>
<!-- activeProfiles
| List of profiles that are active for all builds.
|
<activeProfiles>
<activeProfile>alwaysActiveProfile</activeProfile>
<activeProfile>anotherAlwaysActiveProfile</activeProfile>
</activeProfiles>
-->
</settings>
-----------------------------------
Cicap
> se sei confuso a
>> questi livelli sfido che non vuoi fare più il programmatore, solo che
>> non saprei che altro lavoro di concetto consigliarti eh...
>
> Vedi sopra.... Pensavo che queste cose per un tecnico dovessero essere
> scontate...
>
> Sotto il file settings.xml che apt-get install ha scaricato in /etc/maven2/
Maven legge i file di congfigurazione a cascata. Puoi avere un
settings.xml globale o uno per utente. Quello in /etc/maven2/ è globale,
mentre quello nella home per utente.
Su Windows c'è MAVE_HOME/conf/settings.xml.
> Sebbene la maggior parte delle cose sia commentata, non mi sembrano 5
> righe.
> <proxy>
> <id>proxolo</id>
> <active>true</active>
> <protocol>http</protocol>
> <!--username>proxyuser</username>
> <password>proxypass</password-->
> <host>proxolo.cs.poste.it</host>
> <port>8080</port>
> <!--nonProxyHosts>local.net|some.host.com</nonProxyHosts-->
> </proxy>
Hai ragione, sono otto.
Bartman
> Il 01/10/10 12.05, Bartman ha scritto:
>
> i build tool sono *essenziali* per standardizzare il processo. giusto ai
> peggio microsoftisti può venire in mente di fare i rilasci manualmente
> da dentro l'ide.
>
Non lo metto in dubbio, figurati. Anzi, li apprezzo molto... ma solamente quando
qualcun altro li configura e li fa andare a dovere. Quando devo modificare un
build file di Ant, mi addormento solamente guardando la pagina di documentazione :-)
Bartman
>
> Ho forti dubbi eh. Probabilmente c'è meno scelta, questo si, ma il
> range dovrebbe essere più o meno equivalente.
Boh, ho sempre creduto ci fossero più "cose" per Java, ma forse è la
sovraesposizione al mondo Java che mi fa vedere le cose in questo modo.
>Python è dell'89/90
> comunque, precedente a Java.
Sì, in effetti hai ragione. Sono andato a memoria e ho toppato :-)
> Comunque sono 2 tecnologie che si sposano meravigliosamente insieme, io
> ad esempio sto usando Hadoop da Ruby, che è in Java.
>
Forte! Beato te :-)
ispas
> E che cappero c'entra?
> L'ambiente IDE puoi averlo diverso a seconda delle preferenze dello
> sviluppatore.
E perchè lo sviluppatore non deve avere preferenze diverse per i
programmi di building?
> No non capita a tutti. Marco è rimasto piantato su un non-problema che
> con Maven c'entra come il cavolo a merenda. Maven si lancia da linea di
> comando e "magicamente" fa tutto, da risolvere e scaricare le dipendenze
> fino a installare la versione passando per compilazione, test,
> generazione doc e altro ancora. Marco non doveva fare NIENT'ALTRO che
> questo che tu ci creda o no.
Bè, questa girala a Marco. Se è semplice come dici, tanto meglio,
ottima notizia.
Equinozio
> peggio microsoftisti può venire in mente di fare i rilasci manualmente
> da dentro l'ide.
Per fortuna anche noi ci siamo "evoluti", oggi se vuoi parlare di
continuous integration, possiamo configurare la team system per
bildare ad ogni checkin, puoi usare più macchine, dedicando una
macchina a certe compilazioni e le altre ad altre, rispuntando la
change al programmatore, configurando uno o più ambienti virtuali
(tipo una simulazione su una piccola rete) che vengono tirati su e
provato il deploy. Poi partono i test in automatico ed alla fine il
risultato dei test va a finire sulla build.
Il tutto graficamente, senza nessun file di configurazione. Dice ma se
non basta l'out of the box ? Allora ci metti le manine ma sempre in
maniera umana visto che tutto si basa su Windows Workflow Foundation e
quindi grafico + programmabile in .net .
Si, ci siamo arrivati che funziona nel 2010... ma almeno ci siamo
arrivati in style ;-)
Cicap
> Bč, questa girala a Marco. Se č semplice come dici, tanto meglio,
> ottima notizia.
forse non hai letto il post originale, ma si trattava semplicemente di
problemi di proxy: con Maven centra davvero poco.
JOKER Ltd.
Non conosco quindi non posso dire nulla.
> A chi usa Python tipicamente piace Python, a chi usa Ruby tipicamente
> piace Ruby. Sono piccole grandi scoperte.
Dici? Possibile. I pero mi sono avvicinato ad entrambi da agnostico.
Greetings
JOKER Ltd.
rootkit
>> le impostazioni locali sono corrette sotto ~/.m2, credimi se te lo dico
>> e se non mi vuoi credere guarda la documentazione.
>
> Non lo metto in dubbio; infatti mi aspettavo di trovarlo li'. Pero'
> "l'installatore automatico" lo ha messo da un'altra parte (in/etc/maven2/).
e io prima ti ho detto che va creato. ok non lo sapevi, ora perņ lo sai.
> Riporto piu' avanti il file settings.xml che lui ha messo in /etc/maven2.
> Effettivamente e' quasi tutto commentato e lo era anche la parte del
> proxy. Quella l'ho decommentata io. E' vero che e' quasi tutto commentato
> (ma non e' "decommentata" solo la parte del proxy) e se mi dici che serve
> solo quella ci credo, ma io quando vedo un file del genere e devo fare il
> programmatore, cerco di capire a che serve ognuna di quelle parti (che non
> sono 5 righe)
indubbiamente puoi scegliere questa strada, oppure digitare su google
"maven proxy" e premere "mi sento fortunato".
dai su smettiamola, continuare a sostenere che fosse una situazione
difficile scade nel ridicolo.
> guarda che sotto ~/.m2/ c'č la configurazione di *maven2*, non di apt.
>> scusa se mi permetto ma che bordello c'hai nella testa?
>
> Si parlava tra tecnici, o almeno pensavo.
e meno male che me l'hai ricordato... fra tutti questi "ma io credevo",
"ma io pensavo", "mi pareva ovvio" sembra di essere alla fiera
dell'improvvisazione...
Marcoxxx
> Il 03/10/10 12.42, Marcoxxx ha scritto:
> >> le impostazioni locali sono corrette sotto ~/.m2, credimi se te lo dico
> >> e se non mi vuoi credere guarda la documentazione.
> >
> > Non lo metto in dubbio; infatti mi aspettavo di trovarlo li'. Pero'
> > "l'installatore automatico" lo ha messo da un'altra parte (in/etc/maven2/).
> e io prima ti ho detto che va creato. ok non lo sapevi, ora però lo sai.
E io ti ho risposto che evidentemente non lo sa nemmeno apt-get.
> indubbiamente puoi scegliere questa strada, oppure digitare su google
> "maven proxy" e premere "mi sento fortunato".
> dai su smettiamola, continuare a sostenere che fosse una situazione
> difficile scade nel ridicolo.
Guarda mi sa che non ti e' chiaro che io tutto sostengo, tranne che la
situazione sia stata difficile.
La situazione non e' stata difficile, e' stata decisamente *pallosa*!!!
> e meno male che me l'hai ricordato... fra tutti questi "ma io credevo",
> "ma io pensavo", "mi pareva ovvio" sembra di essere alla fiera
> dell'improvvisazione...
Spiegalo a chi ha scritto apt-get.
Marcoxxx
> Spiegalo a chi ha scritto apt-get.
> Ciao,
> Marco
Anzi no... a chi ha scritto il pacchetto di installazione di maven per
rootkit
>>> Non lo metto in dubbio; infatti mi aspettavo di trovarlo li'. Pero'
>>> "l'installatore automatico" lo ha messo da un'altra parte (in/etc/maven2/).
>
>> e io prima ti ho detto che va creato. ok non lo sapevi, ora però lo sai.
>
> E io ti ho risposto che evidentemente non lo sa nemmeno apt-get.
evidentemente apt non mette le mani nella home degli utenti.
> Guarda mi sa che non ti e' chiaro che io tutto sostengo, tranne che la
> situazione sia stata difficile.
> La situazione non e' stata difficile, e' stata decisamente *pallosa*!!!
si, ovvio. l'uva non è alta, è che non ti piace.
rootkit
>> L'ambiente IDE puoi averlo diverso a seconda delle preferenze dello
>> sviluppatore.
>
> E perchè lo sviluppatore non deve avere preferenze diverse per i
> programmi di building?
certo che sei forte :)
da una parte tessi le lodi di un sistema blindato su cui non devi
decidere nulla, dall'altra parli come se il programmatore debba decidere
tutto.
ebbene si, in java c'è scelta pure su quello. puoi usare maven, ant,
entrambi o nessuno dei due. però quella è, ovviamente, una tipica
decisione che viene presa a livello di progetto. anche l'ide talvolta
viene imposto dall'alto, ma la tendenza è evitarlo perché condividere
nel gestore sorgenti le impostazioni dell'ide quella sì che è una sonora
porcheria (anche con visual studio per inciso, almeno fino al 2005).
mentre invece con il pom.xml qualsiasi sviluppatore tira giù il
progetto, lancia maven e al primo colpo fa tutto quello che deve fare
come lo deve fare. qualsiasi tranne marcoxxx, ovvio :-)
ispas
> Il 03/10/10 17.57, ispas ha scritto:
>
> >> L'ambiente IDE puoi averlo diverso a seconda delle preferenze dello
> >> sviluppatore.
>
> > E perchè lo sviluppatore non deve avere preferenze diverse per i
> > programmi di building?
>
> certo che sei forte :)
> da una parte tessi le lodi di un sistema blindato su cui non devi
> decidere nulla, dall'altra parli come se il programmatore debba decidere
> tutto.
Non tesso le lodi di niente. Rispondo a chi fa considerazioni
incomplete, dimenticando che lo sviluppatore possa scegliere oltre
all'IDE anche il prodotto di building tra svariate decine di proposte
(come minimo il classico make, basta guardare su Wikipedia). O forse
costui non lo sa... :-))
> ebbene si, in java c'è scelta pure su quello. puoi usare maven, ant,
> entrambi o nessuno dei due. però quella è, ovviamente, una tipica
> decisione che viene presa a livello di progetto. anche l'ide talvolta
> viene imposto dall'alto, ma la tendenza è evitarlo perché condividere
> nel gestore sorgenti le impostazioni dell'ide quella sì che è una sonora
> porcheria (anche con visual studio per inciso, almeno fino al 2005).
> mentre invece con il pom.xml qualsiasi sviluppatore tira giù il
> progetto, lancia maven e al primo colpo fa tutto quello che deve fare
> come lo deve fare. qualsiasi tranne marcoxxx, ovvio :-)
Certamente sono d'accordo sul fatto che spesso la serie dei prodotti
di sviluppo non è decisa dal singolo ma a livello di progetto.
Poi naturalmente ti contraddici al 100pc, e ti permetti di dare
giudizi sgangherati su ciò che non conosci, sicuramente l'ambiente in
cui opera Marco *è* imposto, visto che non è un progettino con 4 cani
sciolti che possono usare quel che gli pare.
rootkit
> Eclipse ha una buona integrazione con ant, ma nulla so dire di maven.
> Ricordo che lo supporti ugualmente bene.
c'è un plugin che consente di creare un maven project e fornisce il
supporto necessario allo sviluppo (risoluzione dipendenze, classpath,
indicizzazione repository, interfaccia di lancio, etc...).
imho però l'integrazione di netbeans è decisamente migliore.
rootkit
> > certo che sei forte :)
> > da una parte tessi le lodi di un sistema blindato su cui non devi
> > decidere nulla, dall'altra parli come se il programmatore debba decidere
> > tutto.
>
> Non tesso le lodi di niente. Rispondo a chi fa considerazioni
> incomplete, dimenticando che lo sviluppatore possa scegliere oltre
> all'IDE anche il prodotto di building tra svariate decine di proposte
> (come minimo il classico make, basta guardare su Wikipedia). O forse
> costui non lo sa... :-))
in java ne esistono due e tipicamente la scelta di quale adottare
determina come è organizzato il progetto. quindi è normale che lo
sviluppatore se lo trovi in qualche modo calato dall'alto. diverso
discorso è l'editor, dato che uno sviluppatore può essere più o meno
produttivo con uno piuttosto che con un altro.
> > ebbene si, in java c'è scelta pure su quello. puoi usare maven, ant,
> > entrambi o nessuno dei due. però quella è, ovviamente, una tipica
> > decisione che viene presa a livello di progetto. anche l'ide talvolta
> > viene imposto dall'alto, ma la tendenza è evitarlo perché condividere
> > nel gestore sorgenti le impostazioni dell'ide quella sì che è una sonora
> > porcheria (anche con visual studio per inciso, almeno fino al 2005).
> > mentre invece con il pom.xml qualsiasi sviluppatore tira giù il
> > progetto, lancia maven e al primo colpo fa tutto quello che deve fare
> > come lo deve fare. qualsiasi tranne marcoxxx, ovvio :-)
>
> Certamente sono d'accordo sul fatto che spesso la serie dei prodotti
> di sviluppo non è decisa dal singolo ma a livello di progetto.
> Poi naturalmente ti contraddici al 100pc, e ti permetti di dare
> giudizi sgangherati su ciò che non conosci, sicuramente l'ambiente in
> cui opera Marco *è* imposto, visto che non è un progettino con 4 cani
> sciolti che possono usare quel che gli pare.
e quando mai ho dubitato che non lo fosse? il mio giudizio
"sgangherato" riguarda l'uso di uno strumento che conosco molto bene e
su cui posso anche dare risposte, sempre che si abbia un minimo di
interesse ad ascoltarle. se dico (e non solo io) che il problema è di
banale e molteplice soluzione lo dico con cognizione di causa, certo
che se poi insiste a sostenere che se non riesce a piantare un chiodo
è colpa del martello (anzi nemmeno, della cassetta degli attrezzi da
cui ha preso il martello) non vedo perché insistere io a mia volta.
Bartman
> Beh ci sarebbe anche (ma IMHO una gran porcata al pari di IronPython
> *) Jthon, che usa le librerie java (oltre ad avere l'interprete
> scritto in java),
In verità credo che siano buoni strumenti che consentono di introdurre in
maniera soft un nuovo linguaggio. Poi JRuby - a meno che le cose non sia
cambiate ultimamente - è ancora più 'veloce' della implmentazione standard
(tenendo sempre presente il valore di test del genere) e ha una gestione dei
thread più performante.
>
> * A che serve scrivere codice python se poi diventa metacodice .NET?
> In pratica il dinamismo del linguaggio va a farsi benedire.
>
Che io sappia il dinamismo rimane inalterato.
>
> P.S: A me Ruby non convince. Questione di gusti, sia chiaro, ma come
> chiarezza di sintassi, Python fino ad ora non ha rivali. Certo se vuoi
> scrivi roba di merda (context di Obfuscated Python ce ne sono), ma
> devi odiarti parecchio per farlo.
>
A me piacciono tutti e due (ma a me piacciono i linguaggi in generale, anche se
non ho molto tempo per studiarmeli come vorrei). La caratteristica di Ruby che
adoro sono i blocchi; mentre di Python apprezzo molto il fatto che ti spinga a
pensare in maniera semplice e lineare (e mi piace anche il codice indentato, lo
porterei in ruby e eliminerei gli end :-)) .
ngw
> JOKER Ltd. <joke...@libero.it> ha scritto:
>
>> P.S: A me Ruby non convince. Questione di gusti, sia chiaro, ma come
>> chiarezza di sintassi, Python fino ad ora non ha rivali. Certo se vuoi
>> scrivi roba di merda (context di Obfuscated Python ce ne sono), ma
>> devi odiarti parecchio per farlo.
>>
>
> A me piacciono tutti e due (ma a me piacciono i linguaggi in generale, anche se
> non ho molto tempo per studiarmeli come vorrei). La caratteristica di Ruby che
> adoro sono i blocchi; mentre di Python apprezzo molto il fatto che ti spinga a
> pensare in maniera semplice e lineare (e mi piace anche il codice indentato, lo
> porterei in ruby e eliminerei gli end :-)) .
Son due linguaggi estramamente simili in verità.
Le differenze sono giusto l'indentazione, quanto l'uno prende da
Smalltalk (Ruby enormemente, Python abbastanza) e dai funzionali (Ruby
parecchio, Python abbastanza).
Francamente, anche se non programmo in Python dal 2006, sono entrambi
linguaggi meravigliosi.
Sarebbe il caso di sceglierne uno solo (io li so entrambi perchè son
poco furbo) e buttarsi su cose che permettono di aprirsi a dominii
diversi, come il perennermente da me citato Erlang, o node.js (che ho
addirittura visto gente gongolare all'affermazione di qualcuno che js
sarebbe stato decisivo nei prossimi tempi - non bastasse il fatto che
metà dei DB noSQL hanno un interprete JS embedded).
Per me, limitare l'informatica a Microsoft VS Sun è appunto limitante,
c'è veramente tanto altro. A quel punto pero' da lavoro si va alla
passione, e in molti casi di passione non ce n'è.
[incollare qui n battute sul mantenimento di una famiglia]
ngw
--
Nicholas Wieland (ngw)
Zooppa CTO
911 Western Avenue, Suite 420
Seattle, WA 98104 US
Bartman
> Sono un autonomo (per scaricare qualcosa, visto che lavoro lontano da
> casa) ma alla fin fine lavoro quasi come un interno. Qui si usa python
> (e C) da sempre (10 anni quasi) twisted (dalla 2.0), ora TurboGears2.x
> per la parte di interfaccia utente web.
Bello, Twisted mi ha sempre affascinato, ma non sono andato più in là delle
prime pagine di documentazione:-)
> Pero' il mio ultimo lavoro da
> freelance una applicazione client/server scritta in WxPython, e
> colloqui (quando poi ho avuto l'offerta qui) con una ditta di Fiernze
> (che pero' non ho sostenuto visto che la mia base logistica di Modena
> era incompatibile con gli orari di Trenitalia per Firenze) ed uno con
> una ditta di ferrara. Entrambe lavorano con Python. In aria avevo, ma
> poi ho annullato un paio di offerte su Roma. parlo sempre di Pythno
> (varie salse da Zope/Plone a TG2.0, a Twisted, WxPython, PyQT etc.).
> Ah subito dopo che avevo iniziato qui (Giugno) ho visto una offerta
> interessante su Ancona, sempre per Python.
Sì, le offerte le vedo anche io. Purtroppo non mi posso spostare, altrimenti me
ne sarei già andato da qualche parte e avrei tentato la strada di Ruby.
>
> Python sta crescendo. Sempre piu' aziende medio/piccole lo usano. Non
> arriva all'enterprise, ma non mi ineterssa,.
Meno male, speriamo che anche qui da me qualcuno capisca. Il problema è, come
sempre, la paura di cambiare e pensare che se si passa ad un altro linguaggio si
perda professionalità (a livello aziendale) o le proprie piccole nicchie di
potere (a livello individuale: se sono bravo con Java, perché passare a
Python?). Anche se, in verità, di solito quelli veramente bravi sono i primi a
spingere per il cambiamento...
> Idem per Banca mediolanum (ma li anche
> altri motivi alla base, ascoltare le voci stupite dei proponenti
> quando mi dicevano: ma sa di chi e' si? E io: appunto, per quelli li
> non lavoro.).
Ma mitico :-) Complmenti!
> Voglio dire non sono un geniaccio (vedo che sul Ng ci
> sono parecchi che mi danno la paga tranquillamente su certe cose) ma
> ho 21 anni di mestiere addosso. Qualcos, nonostante i miei limiti la
> ho imparata per abitudine (esempio fare una raccolta di specifiche e
> relativa analisi funzionale con tempi&costi che di rado il cliente
> finale puo' pi dire: ma io avevo capito che ...).
Piacerebbe anche a me fare il freelance, ma per ora il fatto di avere zero
potenziali clienti mi fa desistere :-)
>
> Beh nel mondo python cresce. Qui siamo un poco indietro ma si vede che
> si muove qualcosa.
> Java vivra' fino a che sara' interesse di Oracle. Se domani trova una
> cosa che gli costa meno mantenere, java si estingue in due anni.
> Java e' per il mondo enteprise. In quei posti si e' pati di un
> ingranaggio. E sostituibili a caldo. Tolgono uno e ci mettono
> uin'altro. Tempo 1 settimana non si nota neppure la differenza.
Vabeh, dai, non credo che Oracle abbia comprato la Sun per poi abbandonare Java
(poi, oh, le cose possono sempre accadere :-))
Ho solo una frazione della tua esperienza, ma mi pare di capire che siamo tutti
più o meno sostituibili, in quasi tutti i contesti (gli unici che si fa fatica a
sostituire sono quelli che ci mettono i soldi :-D)
>
> Io ho scelto TG2.0 perche' e' un MiddleWare che permette di usare (o
> sostituire) qualsiasi componente. Anche se parte con una dotazione
> favolosa: Genshi+Pylons+SqlAlchemy+èun framework js a scelta,
> consigliati Dojo o JQuery].
Anche Rails 3 pare sia difentato più flessibile, e in effetti anche nel mondo
Ruby ci sono alternative più malleabili (mi viene in mente Sinatra).
> E' piu' o meno coetaneo di java 1.2. Sai quanti WebServer Python
> esistono? Troppi. Perche' parecchi si scrivono il loro (uno minimale
> che risponde alle HTTPRequest necessita' di non piu' di 4 righe,
> inclusa la def).
>
> Se non hai una lib pronta la fai in pochi giorni. In java se non ci
> fosse faresti prima a cambiare specifiche. :)
>
Vabeh, anche io se dovessi realizzare qualcosa in C++ ci metterei una vita e
farei prima a cambiare. La piattaforma Java è ottima secondo me (intendo le
classi della 'libreria standard',il garbage collector, ecc), il linguaggio
potrebbe essere più espressivo (ma anche qui esistono alternative come Scala,
Clojure e Groovy) e realizzare qualcosa non è certo proibitivo.
Bartman
> O forse no, visto che di XML grazie al suo DTD, si può verificare la
> correttezza formale.
>
Non sto dicendo che l'XML debba sparire dalla faccia della terra (ok,
l'espressione era un po' colorita :-)). Però è innegabile che fino a oggi se ne
è abusato: non credo sia un formato adatto alla lettura o modifica da parte di
un essere umano (in questo caso il sottoscritto). Per un file di configurazione,
posso anche fare a meno della correttezza formale e avere qualcosa di più leggibile.
ispas
> Per me, limitare l'informatica a Microsoft VS Sun è appunto limitante,
> c'è veramente tanto altro. A quel punto pero' da lavoro si va alla
> passione, e in molti casi di passione non ce n'è.
Assolutamente vero. C'è, per esempio, IBM con: Cobol, Fortran, PL/1,
Rexx, RPG... :-))
O Embarcadero ex-Borland con Delphi. Tralasciando tanti "autonomi"
opensource, e tanti altri professionali relativamente di nicchia (come
Ada).
Bartman
> Son due linguaggi estramamente simili in verità.
> Le differenze sono giusto l'indentazione, quanto l'uno prende da
> Smalltalk (Ruby enormemente, Python abbastanza) e dai funzionali (Ruby
> parecchio, Python abbastanza).
> Francamente, anche se non programmo in Python dal 2006, sono entrambi
> linguaggi meravigliosi.
Già: Python e Ruby sono 'belli': oltre alle considerazioni tecniche, il codice
di questi due linguaggi è proprio 'bello'. Pare una considerazione stupida, ma
leggere qualcosa di bello è molto meno stressante rispetto a qualcosa di brutto.
Anche Lisp è una figata, ma trovo tutte quelle parentesi stancanti e confusionarie.
> Sarebbe il caso di sceglierne uno solo (io li so entrambi perchè son
> poco furbo) e buttarsi su cose che permettono di aprirsi a dominii
> diversi, come il perennermente da me citato Erlang,
Programming Erlang è nella mia libreria da un anno ma non ho ancora trovato il
coraggio di leggerlo :-)
> o node.js (che ho
> addirittura visto gente gongolare all'affermazione di qualcuno che js
> sarebbe stato decisivo nei prossimi tempi - non bastasse il fatto che
> metà dei DB noSQL hanno un interprete JS embedded).
Javascript è nell'applicazione che usiamo di più tutti i giorni (il browser): è
difficile non accorgersi della sua importanza oggi e di quella che potrà avere
in futuro (lo so, è possibile auto convincersi di qualsiasi cosa :-D) con
progetti tipo Node.
> Per me, limitare l'informatica a Microsoft VS Sun è appunto limitante,
> c'è veramente tanto altro.
Certo, ma anche all'interno delle tecnologie Sun e Microsoft ci sono progetti
interessanti (mi viene in mente Scala, ad esempio - per Microsoft dico F#, ma so
solo che è un linguaggio funzionale, magari è una porcheria, non so praticamente
nulla).
>A quel punto pero' da lavoro si va alla
> passione, e in molti casi di passione non ce n'è.
> [incollare qui n battute sul mantenimento di una famiglia]
>
O forse ci sono altre passioni :-)
O forse quando uno torna a casa preferisce rilassarsi con
moglie/fidanzata/amante/cane/etc.
Comunque, comprendo il tuo discorso: ma credo che il 'tengo famiglia' sia più
una scusa dietro la quale nascondere una immensa pigrizia mentale.
Nel mio caso, invece, devo tentare di limitare i miei interessi informatici,
visto che ogni giorno escono cose nuove e, se cercassi di stare dietro a tutto,
alla fine non combinerei un bel niente.
ispas
> Non sto dicendo che l'XML debba sparire dalla faccia della terra (ok,
> l'espressione era un po' colorita :-)). Però è innegabile che fino a oggi se ne
> è abusato: non credo sia un formato adatto alla lettura o modifica da parte di
> un essere umano (in questo caso il sottoscritto). Per un file di configurazione,
> posso anche fare a meno della correttezza formale e avere qualcosa di più leggibile.
Ecco perchè gli esseri umani dovranno cedere il passo ad esseri più
evoluti, capaci tra l'altro di leggere facilmente l'XML :-))
Bartman
> Ecco perchè gli esseri umani dovranno cedere il passo ad esseri più
> evoluti, capaci tra l'altro di leggere facilmente l'XML :-))
>
Speriamo manchi poco... copia del cervello, trasferimento in una macchina, e via
a leggere XML! :-)
rootkit
> > i build tool sono *essenziali* per standardizzare il processo. giusto ai
> > peggio microsoftisti può venire in mente di fare i rilasci manualmente
> > da dentro l'ide.
>
> Non lo metto in dubbio, figurati. Anzi, li apprezzo molto... ma solamente quando
> qualcun altro li configura e li fa andare a dovere.
beh maven funziona anche con un pom.xml pressoché vuoto, se è per
questo. ma il punto è un altro. definire il pom.xml/build.xml è una
attività che fa parte del kick-off del progetto, lo fa una persona e
tipicamente una volta per tutte. e anche in questa fase si parte
tipicamente da un archetipo esistente.
Bartman
> beh maven funziona anche con un pom.xml pressoché vuoto, se è per
> questo.
Sì, è vero. Maven l'ho usato qualche anno fa e non lo avevo apprezzato appieno
(anche perché era il mio esordio in un'azienda e, ovviamente, dovevo occuparmi
di altre cose). Ieri l'ho reinstallato sul computer di casa, vedrò di giocarci
nel tempo libero.
> ma il punto è un altro. definire il pom.xml/build.xml è una
> attività che fa parte del kick-off del progetto, lo fa una persona e
> tipicamente una volta per tutte. e anche in questa fase si parte
> tipicamente da un archetipo esistente.
>
Certo, di solito è così. Poi però c'è da aggiungere qualcosa e io, con la
memoria schifosa che mi ritrovo, non ricordo più quale tag modificare e inizio a
piangere come una femminuccia :-D
Cammello
> Bartman wrote:
>
>> orse tra qualche anno
>> vedremo il cadavere dell'xml passare nel fiume :-)
>
> O forse no, visto che di XML grazie al suo DTD, si puň verificare la
> correttezza formale.
O forse sě, visto che anche JSON e YAML possono verificare la
correttezza formale:
http://www.kuwata-lab.com/kwalify/
http://rx.codesimply.com/
http://tools.ietf.org/html/draft-zyp-json-schema-02
Volendo elaborare un po' meglio, XML ha ancora dei vantaggi come
linguaggio di marcatura per /documenti/.
Ma come linguaggio di serializzazione di dati č nettamente piů scomodo
di JSON e YAML.
Difatti le API di molti dei web service piů popolari (da Google in giů)
stanno progressivamente sostituendo XML con JSON (senza peraltro alcuna
specifica formale).
JOKER Ltd.
> Bello, Twisted mi ha sempre affascinato, ma non sono andato più in là delle
> prime pagine di documentazione:-)
E' un prodotto interessante davvero, ma richiede, IMHO, un poco di
impegno iniziale [per capirne la filosofia.
> Sì, le offerte le vedo anche io. Purtroppo non mi posso spostare, altrimenti me
> ne sarei già andato da qualche parte e avrei tentato la strada di Ruby.
Beh questo e' uno ddei punti che io, nell'altro thread (quello
dell'associazione di informatici) metterei assieme al No BR: Si al
telelavoro.
> Python?). Anche se, in verità, di solito quelli veramente bravi sono i primi a
> spingere per il cambiamento...
In effetti hai ragione. A restare ancorati al vecchio sono di solito
le cariatidi prive di voglia di confrontarsi.
> > quando mi dicevano: ma sa di chi e' si? E io: appunto, per quelli li
> > non lavoro.).
> Ma mitico :-) Complmenti!
Beh non e' difficile. Gia' il mondo bancario non mi piace, poi se devo
anche lavorare per quelli li. Anche in Mondadori (a Verona) ho fatto
in modo da non far andare in porto il colloquio (gia' la scelta della
piattaforma in PHP inevec che usare Django, anche se chi mi ha fatto
il colloquio mi ha fatto intendere che loro condividevano la mia idea
ma gli ordini erano dall'alto) sssarebbe bastata da se a farmi dire
no. Ancora una volta pero' il sapere chi sia a pagare mi ha fatto
scappare.
> Piacerebbe anche a me fare il freelance, ma per ora il fatto di avere zero
> potenziali clienti mi fa desistere :-)
Beh vedremo in futuro se cosa accade, magari ci sara' la possibilita'
di creare anche un qualcosa ad hoc er questo.
> Vabeh, dai, non credo che Oracle abbia comprato la Sun per poi abbandonare Java
> (poi, oh, le cose possono sempre accadere :-))
Ho solo detto che java potra' vivere solo fino a che Oracle ne avra'
interesse. Difficile cambi strada senza motivi piu' che validi.
> Ho solo una frazione della tua esperienza, ma mi pare di capire che siamo tutti
> più o meno sostituibili, in quasi tutti i contesti (gli unici che si fa fatica a
> sostituire sono quelli che ci mettono i soldi :-D)
Manco quelli. Se arriva un'altro a metetrci i soldi il vecchio puo'
essere sostituito.
> Anche Rails 3 pare sia difentato più flessibile, e in effetti anche nel mondo
> Ruby ci sono alternative più malleabili (mi viene in mente Sinatra).
Rail non e' Ruby. Come Django non e' Python. Sono strumenti sviluppati
in quel linguaggio, che si configurano/modificano, in quel linguaggio.
Fine. Se poi Ruby cresce posso solo essere contento (anche se io
prediligo Python). Anche Lua e' della stesa famigliola (diciamo che
sono tre cugini) e se cresce mi fa piacere (anche se insito ad usare
Python ma solo perche' rispecchia meglio i miei gusti).
> Vabeh, anche io se dovessi realizzare qualcosa in C++ ci metterei una vita e
> farei prima a cambiare. La piattaforma Java è ottima secondo me
Io dicevo solo che scrivere codice java richiede molto piu' tempo,
analisi, righe di codice. In python pensi a cosa devi fare, in java
(ed altri) pensi anche a come devi farlo.
Greetings
JOKER Ltd.
JOKER Ltd.
> O forse no, visto che di XML grazie al suo DTD, si può verificare la
> correttezza formale.
Sinceramente io lo ho sempre trovato piu' una rottura che una feature.
Porobailmente perche' non mi serviva piu' di tanto oppure perche'
riuscivo a fare le stesse cose in altra maniera.
Greetings
JOKER Ltd.