Newsgroup: it.lavoro.informatica
Titolo: perche' non faccio piu' il programmatore (motivazione tecnica)

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.
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

 fare)!
Già, anche io avrei smesso di occuparmi della parte tecnica se
lavorassi in j2ee + hybernate ....   .... mah va beh, una faccina ce
la metto :-)

 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].

 wrote:

Sai che non l'ho capita?

che dire, semplicemente ti capisco perché io pure passo giorni a
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


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.

 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.

 suo repository, ecc.)
credimi se ti dico che quello in cui sei affogato non è neanche un
bicchiere, ma una tazzina d'acqua.

 consegue.
allora fai il sistemista!

 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...


[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):-) 

 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

 ha scritto:

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...



ad oggi questa è oggettivamente una leggenda.

 
Vabeh, "scrivere codice" non è un'attività così banale :-)


obiettivamente no....ma <<soggettivamente>> se vieni qui vedrai...;)

 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 !

 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.

 obiettivamente no....ma <<soggettivamente>> se vieni qui vedrai...;)
Ok, ovviamente tutto dipende dal contesto :-D

 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.

 tranquillamente: c'è tutto e il contrario di tutto...
Perche' cosa manca al biforcuto?
Greetings
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.

 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 :-)

 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.

 Non ci si mette pure Maven e chissa che.
boia dé, son 30 secondi di google scoprirlo...

 
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ù...

 
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...

 tonnellate di parametri da settare.
si scrive hibernate.

 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.

> per il resto il jee è proprio tutto fuori che noioso.
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.

 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.

 di più...
Ecco questo di certo. Nel bene e nel male.
Greetings
JOKER Ltd.

 
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...

 si usa JBoss anche per mettere in piedi due pagine web...
Esattamente quello che consideravo.
Greetings
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.

 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

 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 :-(

 wrote:
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.

 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 :-))

 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.

 
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 :-/

 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 
pincoloproxolino.poste.it
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


 Sarà brutto, ma è "nella scatola" con Visual Studio.
infatti, è parte integrante del "pacco" che ti rifila
la microzozz
;-)

 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

 find) in /etc/<qualcosa>).
il settings.xml? deve stare sotto ~/.m2, ma fintanto non ce lo crei hai 
voglia di cercarlo :P

 fastidiosa.
perché glassfish non ti piace?

 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.

 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.



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

 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.


 (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.

 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.

 c'č
eh, sapessi...
http://www.youtube.com/watch?v=uRvRZNCYXk4

 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.

 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.

Ehi, avete notato che per una volta stiamo parlando civilmente senza
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.

 devi odiarti parecchio per farlo.
A chi usa Python tipicamente piace Python, a chi usa Ruby tipicamente 
piace Ruby. Sono piccole grandi scoperte.


 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.

 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.

 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.

 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...)


 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)


 disdegnati.
Questo è vero. Anche Net non è che sia tanto più semplice di JavaEE.

 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.

 Non è necessario, ma tanti ci ricorrono.
ammesso che sia vero (non sto a discuterne), il problema di preciso sarebbe?

 di building? Improbabile.
non hai capito. e credo sia tempo perso spiegare.

 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...

 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

 Conclusione:
La tua ignoranza su Maven e non solo ti hanno fatto perdere un sacco di 
giorni.

 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).

 fare queste cose
è la crisi

 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>
-----------------------------------


      </proxy>
Hai ragione, sono otto.

 
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 :-)

 
Forte! Beato te :-)

 questo che tu ci creda o no.
Bè, questa girala a Marco. Se è semplice come dici, tanto meglio,
ottima notizia.

 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 ;-)

 ottima notizia.
forse non hai letto il post originale, ma si trattava semplicemente di 
problemi di proxy: con Maven centra davvero poco.

 piace Ruby. Sono piccole grandi scoperte.
Dici? Possibile. I pero mi sono avvicinato ad entrambi da agnostico.
Greetings
JOKER Ltd.

 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...

 dell'improvvisazione...
Spiegalo a chi ha scritto apt-get.


 Marco
Anzi no...  a chi ha scritto il pacchetto di installazione di maven per


 La situazione non e' stata difficile, e' stata decisamente *pallosa*!!!
si, ovvio. l'uva non è alta, è che non ti piace.

 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 :-)

 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.

 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.

 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.


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 :-)) .

 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

 
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. 

 
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.

 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).

 
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. 

 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 :-))

 
Speriamo manchi poco... copia del cervello, trasferimento in una macchina, e via
a leggere XML! :-)

 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.

 
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

 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).

 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.

 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.

 specifica formale).
Ma se questi nuovi formati sono così vantaggiosi in tanti casi, come
mai per un decennio ci hanno imposto sto piffero di XML?? Boh.
Ho dato un'occhiata a JSON, ed è semplicissimo. Impossibile che non ci
si potesse pensare prima.

 specifica formale).
in generale, nei web service prima c'è stato una forte tendenza a
formalizzare sempre e comunque (wsdl, xsd) poi ragionevolmente ci si è
resi conto che non è sempre necessario.
va da se che json nasce nel contesto del javascript, nei linguaggi
tipati staticamente durante il binding il problema del formalismo in
qualche modo te lo devi porre.

 si potesse pensare prima.
Hai prsente SOAP? Un casino, XML, ed altro.
REST, 4 comandi in creoce, nativi di HTTP. Eppure SOAP non solo ha
dominato per anni ma ancora ora c'e chi lo chiede come requisito per
sviluppare.
Greetings
JOKER Ltd.

 sviluppare.
Ma SOAP spesso e volentieri è pappa e ciccia con JavaEE ;-)
Ed anche con Net, in verità.

 ammattire, talvolta, per rimettere assieme le cose
Nel mio gruppo di lavoro sono l'unico fluente con ant e maven. Sono uno dei 
pochi che non ammattisce.

 Ed anche con Net, in verità.
Guarda caso hai appena citato due cose assai poco AGILI e che io,
strana la vita eh?, evito come la peste, solo posso.
Greetings
JOKER Ltd.

 qualche modo te lo devi porre.
Certo, ma non necessariamente attraverso un dtd o altro documento /
esterno/ (rispetto al codice).
Questo è proprio ad esempio l'approccio proposto da Gson (libreria
Java di de/serializzazione JSON), che solleva eccezioni in fase di
deserializzazione se la stringa JSON non matcha con l'oggetto che si
sta popolando: in pratica la definizione della struttura dati è data
dalla classe target stessa, automaticamente (con supporto per le
annotations)
http://code.google.com/p/google-gson/
Non voglio dire che non ci siano casi in cui un documento di
definizione esterno risulti comodo (che in ogni caso possiamo avere
anche per JSON e YAML, come abbiamo visto), ma certamente in
moltissimi casi un approccio più agile (come quello mostrato) è
ugualmente soddisfacente, anche per un linguaggio strong-typed, ed è
molto più semplice da gestire.

 si potesse pensare prima.
E YAML è ancora più semplice :-)

 molto più semplice da gestire.
Il maggior formalismo dell'XML è anche una sua forza che lo rendono
più adatto nello scambio di informazioni tra soggetti diversi,
ovviamente quando i dati non sono molti. La cosa incomprensibile è che
l'abbiano usato perfino per scambiarsi dati tra i layer all'interno
della stessa applicazione, ma quello è un altro discorso.

 E YAML è ancora più semplice :-)
E lo guarderò con ancora più entusiasmo :-)