Newsgroup: it.comp.java
Titolo: Articoli e white paper gratuiti online

Solo un breve messaggio per comunicarvi che sul mio sito
www.bigatti.it
 sono disponibili alcuni PDF che potrebbero essere
utili:
- Metodologie Agili: concetti, prodotti e risorse
- Java manuale di stile
E' poi disponibile una sezione dedicata allo sviluppo Java Enterprise
in cui raccolgo risorse ed articoli originali. I primi due pubblicati
sono relativi all'architettura J2EE di un'applicazione per la grande
azienda, ed a strategie del logging applicativo.
Cordialmente,
Massimiliano Bigatti
http://www.bigatti.it
SUN Certified Enterprise Architect for Java Platform 2 Enterprise
Edition Technology

 ha scritto nel messaggio
news:57101e4d.0306...@posting.google.com...


...


 termini un po' ostici da tradurre?
Nell'ordine: babylon, dizionario, fantasia ;)
Ivan
--------------------------------
Inviato via 
http://usenet.libero.it

 
Mixare italiano ed inglese e' di solito un pessimo stile. Essendo Java 
gia' in inglese, utilizzando librerie molto probabilmente in inglese, 
essendo l'inglese tipicamente molto piu' conciso, e per esempio essendo 
i getter e i setter uno standard per i bean non traducibile, e' IMHO 
(vedi anche C++ manuale di stile, a cui probabilmente ti sei ispirato 
per il titolo, per quello che ne pensa Pescio) molto meglio mantenere 
un'unica lingua per tutto.
A costo di qualche piccolo sforzo in piu' su termini proprio 
intraducibili, che volendo possono anche essere lasciati in Italiano: 
tipicamente sono oggetti entity (nel senso di Jacobson,, ovviamente!) e 
la leggibilita' non peggiora cosi' tanto se c'e' qualche (ma pochi) 
getBancoPostaAccount o cose simili
ciao
uL

 l'italiano per programmare in Italia. ;)
utopia... in un team internazionale l'inglese e' un must.
ciao
uL

 programmazione in quanto utilizza dei termini spesso prolissi,
C'e' anche un problema di sw. eng: l'inglese e' lingua franca, e si puo' 
assumere che la si "debba" conoscere per lavorare a certi livelli nel 
nostro campo. Non cosi' per nessun'altra lingua. 
Di conseguenza, usare altre lingue in un software limita inutilmente il set 
di risorse che potenzialmente si possono usare - che, vista la cronica 
mancanza di sviluppatori sufficientemente buoni, non e' mai bello.
-- 
Fighting for peace is like fucking for virginity
ObjectZone - 
http://space.tin.it/computer/csadun

 getBancoPostaAccount o cose simili
Hai colto nel segno: quei pochi termini in italiano sono utilizzati
per descrivere le entità del sistema. Ad esempio, il metodo
getBancoPostaAccount che tipo ritorna? Io sarei portato a pensare un
BancoPostaAccount, che è eventualmente una sottoclasse di Account.
Il termine dunque si propaga e la mia idea che venga poi a contatto
con classi come ClienteBancoPosta oppure ContoCorrente.
Ecco che vedrei dunque l'italiano utilizzato nelle entità del sistema
Massimiliano

 mancanza di sviluppatori sufficientemente buoni, non e' mai bello.
A mio avviso questo si applica per progetti internazionali, in Italia
gli sviluppatori di lingua inglese non sono molto diffusi (almeno per
i gruppi di lavoro che ho visto io), e l'italiano lo devono comunque
conoscere perchè vivono in Italia.
Se poi parliamo di gruppi di sviluppo distribuiti in varie nazioni,
magari per progetti open source, siamo al di fuori delle intenzioni
della mia white paper. In quel caso il ragionamento della lingua non
si applica in quanto l'argomento era lo sviluppo in Italia.

 Nell'ordine: babylon, dizionario, fantasia ;)
questo mi era abbastanza chiaro. Se hai una metodica da condividere te
ne sarei grato.

 conoscere perchè vivono in Italia.
(Premessa: non ho letto le tue 48 pagine, visto che ho provato ad accederci
e mi ha detto picche...)
Ecco i miei 2 cent (modo di dire che ora va benissimo anche in
eurolandia)...
Sebbene sia d'accordo con Ugo e con gli altri, la mia piccola esperienza sia
in Italia che nei 5 anni che ho trascorso negli Usa, mi hanno insegnato a
non essere fondamentalista.
Da una parte c'è la bella, sana, interessante teoria, dall'altra la cruda,
triste, ma anche intrigante realtà. Io ho sempre programmato (con tanto di
commenti) in inglese. Forse mi veniva spontaneo perchè era più naturale
visto che il 97% della documentazione e risorse da cui partivo era in
inglese e forse ero facilitato dal fatto che all'inizio scrivevo "da solo",
non in team e che, come qualcuno ha comunque fatto già notare, chi inizia a
programmare, bene o male l'inglese lo conosce.
Mi rendo conto però che essendo, appunto, il fondamentalismo una brutta
malattia scendere a compromessi è molto più semplice ed efficace. Così come
spesso accade quando si disegnano sistemi che devono funzionare, sono
convinto (anche per esperienze) che quando si lavora in team italiani, non
vi siano problemi mischiare terminologie inglesi ed italiane. E' ovvio che,
alla base di tutto, ci deve essere una convenzione concordata (e penso che
il tuo pdf presenti una cosa simile), che permetta al gruppo di lavorare
senza doversi preoccupare troppo di queste cose.
Se il team è un team italiano l'uso della nostra lingua nel codice non lo
vedo affatto come un problema. E non parlo solo di entità: per me il
problema non è solo il "ContoBancoPosta", ma anche gli attributi dello
stesso oggetto... Non vedo perchè impazzire a spiegare ad un webmaster che
la proprietà "zip" della mia custom tag, all'interno della jsp, corrisponde
al "cap".
Alla fine se le proprietà e le entità le metto in italiano, il mioi
webmaster che non sa una riga di codice Java e che vive di jsp tags, sa che
"property" è la proprietà e che li' dentro basta che metta quello che a lui
serve...
Il rischio è che se mi invento un termine o ne uso uno semitraducibile in
modo sbagliato, lui (il webmaster) dice "non funziona un cazzo, il codice
non va... [seguono improperi contro il mondo]".
Oltretutto credo che per scrivere codice solo ed esclusivamente in inglese,
bisognerebbe "vivere" in Inghilterra o negli Stati Uniti, per sapere quali
siano i termini giusti da utilizzare... altrimenti si rischia di cadere nel
"ridicolo" agli occhi dello straniero. (e se lo straniero non deve leggere
il codice, perchè abbiamo usato termini inglesi?)
Almeno se si usa l'italiano, si ha una buona scusa (la "scelta aziendale").
Per non parlare poi del tipo di inglese: inglese-inglese o
inglese-americano?
Mi piacerebbe sapere cosa usano i "puristi del codice in inglese" (senza
offesa, visto che mi ci metto anche io), per una semplice "agenda":
Nome & Cognome... First & Last name (americano) oppure Family name & Surname
(inglese)?
La "Middle initial", in Italia è usata mooolto raramente, non so in
Inghilterra, ma negli Usa se non ce l'hai ti guardano male.
Provincia... come lo traduco? Mi verrebbe da dire "County", anche se
"Contea" ha un significato molto diverso da provincia e "State" è molto
differente persino da Regione... ah, anche Regione come lo traduco?
Codice Fiscale... TaxpayerID può andare bene, anche se non è la stessa
cosa... e poi come lo distinguo da Partita IVA (no, niente IVA Game).
Poi ci sarebbe da analizzare anche il dicorso dei plurali...
    public List getNews() ... mi ritorna tutte le notizie...
se volessi usare l'inglese sul serio dovrei poi fare
    public String getPieceOfNews(int index)... per avere la singola notizia.
(Stesso discorso vale per un software per i Mobili, dove il singlolare del
termine plurale "furniture" è "pieceOfFurniture"...)
Il purista della lingua potrebbe anche obiettare se scrivo il codice di un
orologio... "clock", "watch" e "timepiece" hanno significati differenti, ma
molto simili... è giusto usare "clock"?
Scherzi a parte... è vero, un codice totalmente in inglese è molto più
"bello" anche perchè noi siamo oramai abituati a collegare la programmazione
all'inglese.
Ma mischiare termini non lo vedo affatto come un problema, all'interno di un
team italiano. Probabilmente mi sbaglio, ma secondo me può anche migliorare
il lavoro del team stesso.
Mi piacerebbe leggere, comunque, il documento...
    Regards,
        Kazuma
PS: se volete divertirvi, Beppe Severgnini ha scritto un paio di libri sulla
differenza tra inglese e americano...
Non ricordo, però, che abbia citato "knock me up": lo dici in albergo per
farti svegliare ad una certa ora... (deriva da quando non esistevano le
sveglie telefoniche e, quindi, quello dell'albergo bussava all porta per
svegliarti). Ma fallo solo in inghilterra e non negli Usa, soprattutto se
sei donna, visto che è uno dei tanti modi di dire "mettimi incinta".
--
I've got nothing against God. It's his fan club I can't stand.
Alex "Kazuma" Garbagnati, 
http://www.kazuma.net
EJB & Tomcat jGuru FAQ Manager, 
http://www.jGuru.com
Tutor "Progetto Scuole", 
http://www.JIA.it
Java Italian Association - SUN - MIUR

         Kazuma
Sono completamente d'accordo con te, anche perchè nella w/p troverai
motivazioni e premesse simili alle tue. Riprova il download, ho
verificato oggi e funziona correttamente.
Ciao
Massimiliano

verificato oggi e funziona correttamente.
Si, il tuo download funziona... 
ma funziona solo il link sulla destra dotto Risorse. Quello a fine
pagina ancora non funziona (colpa degli underscore)...
Ora che ho letto il tuo documento, confermo che mi trodi d'accordo.
Nonvoglio essere ripetitivo, ma il fondamentalismo dell'inglese nel
codice di un team italiano può essere controproducente e,
probabilmente poco utile.
E' ovvio che questo discorso salta se si tratta di un lavoro con un
team internazionale. Nelle poche (purtroppo) mie collaborazioni che ho
mantenuto con gli Usa, è ovvio che la lingua è l'inglese.
Ora ti pongo io una domanda... che ne pensi delle slides all'interno
dei seminari? Dovrebbero essere in Italiano o tradotte?
Io, francamente, preferisco tradurle. Sia quando facevo gli interventi
per Borland, sia per le mie presentazioni al Webb.It o alla Java
Conference, ho sempre voluto creare le slides in Italiano (o tradurre
nel caso di Borland). Parlo, ovviamente, di interventi fatti in
Italia...
Io credo fortemente nel ruolo divulgativo di un seminario e, quindi,
mi sembra giusto che sia fatto il massimo per poter semplificare
maggiormente la comprensione delle slides. Non dico traduzioni al
100%, anche perchè alcuni termini, alcuni concetti e "idiomi" devono
rimanere in injglese per avere senso, ma le parti discorsive sono
convinto che dovrebbero essere tradotte, anche per rispetto
all'audience che ti viene ad ascoltare...
	Regards,
		Kazuma
---


 si applica in quanto l'argomento era lo sviluppo in Italia.
Non parlavo specificatamente del tuo white paper (che non ho letto ma
per carita': se e' per definizione una risorsa per italiani, ovvio che
si usi l'italiano; come la FAQ o questo ng.. risorse in inglese ce ne
sono gia' migliaia, quel che servono sono risorse localizzate); ma di
costruzione di software in generale e documentazione interna (nomi di
metodi, commenti, eccetera). 
E non mi riferisco nemmeno all'open source - che appunto ha regole e
mercato piuttosto diverse. Ovviamente, sul discorso Italia, dipende da
cosa fai, e dove lo fai. Ma in generale, l'Italia e' integrata con l'EU
- il che ha annullato molte barriere burocratiche alla mobilita': il
trend sara' lento, ma c'e'. Inoltre per un'azienda puo' risultare piu'
efficiente voler usare risorse straniere (caso tipico, gli indiani).
Poi, una delle idee cardine del disegno di un componente software e' che
non puoi prevederne oggi l'uso domani: a patto che il costo rimanga
basso, piu' strade ti prepari, meglio e'. Dal punto di vista di
business, usare l'inglese apre semplicemente mercati potenziali a costo
quasi zero. 
E venendo al costo: usare l'inglese - a livello tecnico - e' quasi
gratis. E' impensabile che un professionista serio dell'IT non lo
conosca, specie se e' programmatore (cio' ovviamente non vuol dire che
non esista gente che lavora che non lo conosce.. ma qui il discorso si
allargherebbe ;). Non e' che uno debba essere Disraeli, ma il minimo
necessario per documentare e disegnare con nomi anglo costa proprio
poco. 
Chiaro che in certi casi particolari il rapporto costi/benefici
(potenziali e no) sara' troppo alto: bon. Ma in moltissimi casi non lo
e' - ma e' solo una questione di adottare una mentalita' che massimizzi
i benefici mantenendo costanti (e piu' bassi possibili ;-) i costi. Che,
a mia piccola esperienza, in ambito software e' un pattern che si ripete
spesso in ambiti del tutto diversi - dalla scelta della lingua alle
scelte di composizione. 
Infine, una mia personalissima opinione e' che, in Italia, non siamo
potenzialmente secondi a nessuno per quanto riguarda creativita' e
capacita', nel nostro settore: ma quello che spessissimo ci blocca e' la
mancanza di vision (ok, un eufemismo per "provincialismo" :) e di
ambizione che ci porta ad interessarci esclusivamente del nostro
praticello locale. Che per carita', e' bellissimo e invidiato da mezzo
mondo, ma *e'* locale - e piccolo. Uno dei motivi per cui non lavoro in 
Italia e' che, appunto, talvolta bisogna spendere energie per sfondare 
barriare che, altrove, non esistono neppure.
Anche considerando i costi del lavoro (che in Italia non sono certo bassi), 
se da un lato osservi i mercati dove l'Italia ha avuto e ha successo -
moda, piccole ditte ad alta tecnologia, eccetera, vedrai che in tutte o
abbiamo linguisticamnte colonizzato ("zucchine" lo capiscono pure in 
inglese ;-) oppure abbiamo adottato un respiro internazionale - che e' a 
dire usato l'inglese. 
E anche dall'altro - posto che gli US sono ancora la fonte principale di 
innovazione tecnologica nell'IT/software - se guardi ai primi posti 
troverai nazioni (dalla repubblica Ceca ad Israele fino a qualche tempo fa 
alla stessa Norvegia) che - pur possedendo una definitissima identita' 
nazionale - adottano l'inglese come interfaccia verso il mondo senza 
nemmeno farci caso.
