Newsgroup: it.comp.lang.delphi
Titolo: In merito alla consegna di un sorgente (Risposta unica)

Rispondo con un unico messaggio al polpettone di misto idiozie che
e' stato scritto nel thread:
Zortek wrote:
"Lascia perdere Carlo, discutere con LaForgia e' come discutere di
religione con un kamikaze islamico, ha le sue convinzioni incrollabili e
non solo da li' non esce, ma si permette pure di fare l'arrogante e di
insultare chi non la pensa come lui."
Caro Zortek, io non ho offeso proprio nessuno.
E' troppo facile concludere a questo modo i messaggi ed e' una
moda che ormai ha preso piede in questo ng.  E gia', quando
gli altri non la pensano come te, sono arroganti e offensivi.
Io reputo parimenti arrogante l'atteggiamento di qualcuno che si offende
perche' qualcun altro gli espone un punto di vista diverso.
Tu stai palesemente negando che la programmazione sia una disciplina che
deve seguire certe regole, che tutti conosciamo, ma che voi
evidentemente, per il solo gusto di polemizzare, non volete 
riconoscere.  State negando che il software vada scritto nel modo
migliore e su queste basi c'e' veramente poco di cui discutere.
Che il software debba essere scritto per essere manutenibile,
leggibile, modulare, ecc... ecc... e' scritto su ogni testo
di programmazione, ma voi, evidentemente, non ne avete mai
letto uno o, forse, l'avete letto, ma fate finta di non saperlo.
La programmazione come la intendo io e' la programmazione come
dovrebbe essere.  Ripeto, forse non hai mai partecipato ad un 
progetto di dimensioni modeste (non necessariamente grande) per
renderti conto di quali siano le regole da seguire.
Andrea Gnesutta wrote:
"<snip>"
Abbiamo gia' parlato dell'argomento su un altro ng e ti ho gia'
detto la mia.  Non ho bisogno di leggere i testi che consigli,
anzi ti faccio presente che ne esistono anche altri ;)
C'e' modo e modo di far pubblicita' ai propri colleghi del 
Politecnico :))
Carlo Bertuccini wrote:
"scusa ma a parlare di grandi progetti siam tutti capaci, il discorso è
poi prender parte ai progetti. Io posso dirti di aver sviluppato
progetti che si sono estesi per 2/3 anni e con milioni di righe di
codice! Ci credi?"
 
Stando alle cose che affermi, no, non ci credo.
Tu puoi credermi o meno, per me non fa nessuna differenza.
Io non parto dal presupposto che gli altri sbagliano, io cerco
di discutere di argomenti tecnici, tu e qualcun altro amate spostare
le cose sul piano personale, quando non ce n'e' motivo.  Uno ti dice
che le variabili globali non vanno usate, "e no, sei tu che sei
arrogante e offensivo, io le ho sempre usate senza problemi", uno
ti dice che il software deve essere scritto perche' sia 
manutenibile, "e no, sei arrogante, io l'ho sempre scritto
incasinato e mi sono trovato sempre bene".  Come al solito, non
c'entri mai il punto del discorso.  Che il codice debba essere
scritto nel modo migliore non puo' essere considerata un'opinione,
e' una legge della programmazione, perche' il software sopravviva
per qualche tempo senza enormi stravolgimenti.  Se non sei arrivato
al punto, nella tua esperienza, di rendertene conto, evita del
tutto di intervenire.
E con questo, spero di aver concluso ;)
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 perche' qualcun altro gli espone un punto di vista diverso.
Su questo ho parecchio da ridire. Secondo me, il tuo modo di rispondere ha
parecchio di arrogante e fastidioso. Le tue risposte "No", "Niente vero",
"Balle" ecc senza argomentazioni su molti thread sono note a tutti, cosi'
come la tua "convinzione" di essere il depositario della verita'.
Questo non per offendere, ma semplicemente per esporre il mio punto di vista
e criticare (positivamente). E' un errore tipico di chi sa molto credere di
sapere tutto (come diceva socrate).
Per altro penso che tu sia uno dei piu' esperti del NG, e anche in questo
thread sono piu' d'accordo con te che con l'altro punto di vista (tra
l'altro ho appena passato ingegneria del software :)
Secondo me la programmazione e' un'arte, ma cosi' come lo puo' essere
l'architettura. Un lavoro d'equipe, dove ci sono certe regole.
Detto cio', cosi' come sono entrato nel thread, me ne esco :)

 tutto di intervenire.
Io concordavo con Zortek su alcuni punti. Se non sei d'accordo tanto
piacere.
Visto che non siamo d'accordo su praticamente nulla, perchè non mi eviti?
--
- Carlo -
cbertu81(at)libero(dot)it

 renderti conto di quali siano le regole da seguire.
non ho mai partecipato ad un progetto di programmazione in team, questo e'
vero, ma e' dal 1978 che programmo, da quando si lavorava su macchine in rpn
con codici numerici, e di analisi, programmazione, metodi e modalita' di
lavoro, probabilmente ne so qualcosa piu' di te.

 [snip] [snip] [snip]
peccato non ho seguito il thread originale, ma capisco comunque qualche
cosa....
NON ESISTE codice "come deve essere", c'è una differenza sostanziale dalla
teoria e dalla pratica nel campo della programmazione.
Se tu hai avuto (spero) esperienze di lavoro in team, saprai che le regole
(dettate spesso da un team di gestori del progetto che non sono propriamente
dei tecnici del codice) valgono per quel che riguarda la parte dei
programmatori front-end mentre quelli back-end (le bestie pelose, per
internderci) vanno di "pura" esperienza e creatività.
Insisto: non esiste e NON DEVE esistere il codice "come deve essere"
altrimenti il codice scritto in futuro non sarà altro che la copia evoluta
di roba vecchia.
Scrivere codice è pura poesia.
_____________________________
mente_libera
"where no man has gone before"
mente_li...@yahoo.it

> Scrivere codice è pura poesia.
clap! clap! clap!
bravissimo! :)
Ciao, Sandro

 teoria e dalla pratica nel campo della programmazione.
ma non sono per niente d'accordo...
La teoria crea delle regole che vanno rispettate nel limite del possibile.Un
codice che non ha una lettura pulita perchè non si è seguito certe regole
quel codice sarà semrpe una schifezza.Ricordati che il codice,soprattutto se
si lavora in team,dovrà essere gestito da diverse persone.Ci sono fior di
programmatore che predicano la scrittura di codice ordinata che segua certe
regole e noi siamo ancora qui a discutere su queste cose.
IMHO  ovviamente  :))
ps: ovivo che poi il mondo del lavoro puo modificare tutto,ma se si ha una
base su come scrivere un codice leggibile verrà poi da se rispettare certe
regole.
ciao :)

Scusate ma dopo tanto sentir parlare non sono riuscito a non dire la mia.
A parte le simpatie personali (quì ognuno giudica come vuole), mi sembra che
quì
si stia rinnegando l'ingeneria del software.
Scrivere del software non significa mettersi davanti ad un pc e buttare giù
righe di
codice, questo si può fare per piccole cose, per programmi personali o per
fare
esperimenti.
Il primo insegnamento che ho ricevuto è che un programma va "pensato" prima
di
essere scritto. Attenzione non rinnego che la programmazione sia un atto
creativo,
anzi, spesso dormendo vengono in mente le soluzioni fantasiose a problemi
che
sembravano richiedere molto codice.
Io penso che anche il codice "fantasioso" più e deve essere scritto in modo
chiaro
e ordinato.
Ad esempio io uso spesso la notazione ungherese per le variabili:
  [tipodato][nomesignificativo]
  es: IntLivelloSerbatoio
con un piccolo sforzo aumento la leggibilità e riduco la necessità di
inserire commenti
tipo "\\ s: intero che contiene il livello del serbatoio".
Se uno non rispetta le regole (che sono dettate anche dal buon senso) può
comunque
scrivere dell'ottimo software, ma a parità di qualità degli algoritmi un
codice ordinato
è ovviamente superiore, sia per riutilizzi (alcuni pezzi di codice
disordinato da mè
scritto anni fà mi risulta ora incomprensibile) che per il lavoro in gruppo
(e un gruppo
è formato anche da solo due persone.
Quessta è la mia idea, e anche di molte persone che conosco e programmano
sia
in piccole software house che in aziende più di 10(!) programmatori dedicati
ad ogni
progetto.
A proposito gli analisti o project leader non sono sempre degli ingnoranti
della
programmazione, personalmente ne conosco uno (ovviamente non sono io) che
è considerato uno dei maggiori in italia e visto all'opera fà impressione
per la bravura
ed è attualmente responsabile di tutti i programmatori di un'azienda che
"non dorme mai" :-).

 e ordinato.
il punto e' un altro: mentre Laforgia sostiene che, a prescindere dalla
dimensione e dalla natura del progetto, tutto va documentato e commentato in
modo certosino e accademico, dal mio punto di vista un programmatore che
sviluppa software non in team puo' usare tranquillamente il suo metodo di
codifica personale, lasciando perdere accademie e stili da libri di testo.
Quello che conta e' il risultato: se un software e' funzionale e mantenibile
che ci siano piu' o meno commenti all'interno e' un fatto completamente
trascurabile dal punto di vista di chi lo gestira'. Se poi un programmatore
e' uno fuori di testa che incasina tutto e 6 mesi dopo non si raccapezza
piu' col suo progetto, non sara' certo il libro di testo a fargli cambiare
metodo, perche' molto probabilmente e' una questione di carattere.
Ciao, Sandro

 [...]
La teoria, si sa, è demagogia... lasciamola a chi deve scrivere libri e
relazioni (meno male che tali persone esistono), nella realtà delle cose
trova spazio limitato...
La mia esperienza personale (ho a che fare con un manipolo di back-end
programmers tutti i giorni) è che ci deve essere, questo si, una strategia e
una profonda analisi (non lo è mai abbastanza!) sull'architettura software
da adottare.
Le strategie e l'architettura decisa, pero', si riferiscono allo strato di
interfaccia componenti<->front-end, vale a dire: un back-end programmer mi
costruisce un componente per gestire, per esempio, il carrello di un
generico sito, il front-end programmer DEVE sapere quali sono i metodi e le
proprietà di tale componente e come influsicono sul componente stesso.
Questa è ingegneria del software.
il back-end programmer (quello peloso :) decide come sviluppare il
componente in modo autonomo e utilizzando le tecniche che più gli piacciono.
Questa è creatività.
Per esperienza deve essere cosi', o meglio, facendo cosi' funziona meglio:
il back-end è libero di sviluppare come meglio vuole e si sente appagato dal
risultato (quelle bestie pelose vogliono sempre essere consapevoli di essere
i migliori!!).
Tutto il resto è teoria.


 codifica personale, lasciando perdere accademie e stili da libri di testo.
e dopo questa divenne per tutti "Zortek il poeta"! :-)
Comunque condivido in pieno!


 Tutto il resto č teoria.
non sono per niente d'accordo...
Questo lo chiami lavoro il Team?
Spero ti capiti presto del codice da rivoluzionare proveniente da un
"Artista" come lo intendi tu, capirai
anche il Punto di vista di Laforgia.

Una soluzione particolarmente "estrosa" di un problema è un conto.
Ma se ti trovi davanti codice privo di qualsiasi senso, la cosa cambia:
* 50 tquery su una form senza usare un data module
* nomi di variabile tipo "fattura"
Che non vuol dire "numero della fattura" ma MANIfattura.
*blocchi if..then..else lunghi 500 righe
*procedure che ricevono 14 parametri di ingresso e che cambiano il loro
comportamento in base ad uno di essi
*utilizzo di goto x uscire da un while not eof do....
* Commenti a iosa NON AGGIORNATI
Come definite queste cosette?
Ci sono delle regole basilari dettate dallo strumento di sviluppo.
Ma, alla base di tutto, occorre il buon senso.
Consigli....
1) un bel volume: "La grande Guida alla costruzione del software" di Steve
McConnel
Non è recentissimo, ma trovate molte utili indicazioni.
2) Extreme programming (XP)
Si propone come metologia leggera (a differenza di UML che è titanica...)
per gruppi da 2 a 10 sviluppatori.
Alcune cose possono essere anche applicate dai programmatori singoli.
Bye
A.

 come la tua "convinzione" di essere il depositario della verita'.
Le che le mie risposte siano prive di argomentazioni e' tutto da
dimostrare, caro MSX.  Se le si vuol vedere tali e reputare qualcuno
arrogante e fastidioso perche' non la pensa alla stessa maniera, e' un
altro discorso.  Ribadisco: tu reputi "arrogante" qualcuno che ribatte
ai tuoi punti, io reputo "arrogante" e "ottuso" colui che si offende e
ti reputa arrogante, perche' ribatti ai suoi punti.  Molte delle
persone che si permettono di ribattere in questi thread non ha mai
neanche letto un libro sulla programmazione (in generale), ne' ha mai
studiato su qualche testo di ingegneria del software.  Non arrivo a
capire, a questo punto, quali siano le argomentazioni di chi non ha
mai sviluppato software a livello professionale o non ha mai studiato
argomenti su come il software andrebbe sviluppato, in thread come
questo.
Bada che io non sto discutendo di "punti di vista", io sto discutendo
delle regole che stanno alla base della programmazione, in generale, e
che dovrebbero essere note a tutti (e' questo che intendo con "la
programmazione come dovrebbe essere", a parte le battutine idiote dei
vari elementi).  Queste regole le trovi esposte come suggerimenti,
consigli, "best-practices" ecc... ecc.. in qualsiasi testo che tratti
l'argomento "programmazione" e, piu' in generale, di sviluppo del
software.  La programmazione e' un arte nel senso che per essere
realmente "arte" ha bisogno di essere fondata su regole precise.

 Visto che non siamo d'accordo su praticamente nulla, perchè non mi eviti?
Perche' non eviti di intervenire per apporre soltanto il tuo "sono
d'accordo" in coda ai messaggi ?
Cerca di fare qualcosa di utile per gli altri, astieniti ;)

 lavoro, probabilmente ne so qualcosa piu' di te.
Stando alle cose che hai scritto in questo thread, si direbbe proprio
di no.
Tu puoi crogiolarti nell'idea di saperne piu' di me, la cosa non mi
interessa minimamente, potrebbe essere vero, potrebbe non esserlo
affatto, chi lo sa ?, ma quello che ti consiglio e' di non intervenire
in un thread come questo, se non sei del tutto convinto che quanto
stai dicendo sia vero a livello generale.  La programmazione come la
intendi tu e' la programmazione di chi programma dal 1978, ma non ha
mai lavorato su qualcosa sviluppato da piu' di una persona, ovvero
cio' che normalmente si intende per "progetto serio".
La programmazione come la intendi tu NON e' la programmazione che
riguarda moltissime aziende di sviluppo software, quindi la prossima
volta che ti viene in mente di ribattere con "tutti programmano cosi'
(i.e.: tutti programmano come me)", pensaci almeno tre volte ;)

 di roba vecchia.
Probabilmente ti conveniva seguire il thread dall'inizio.
Esistono delle regole in programmazione che impongono (per quanto
questa imposizione venga ignorata da "programmatori" come Zortek) che
il codice sia leggibile, sia manutenibile, modulare, ecc... ecc...,
ovvero che esso sia facilmente modificabile in vista di una futura
scalabilita'.
Questo e' un dato di fatto.  Questa e' una regola di sopravvivenza
dell'industria del software che viene tenuta in grandissima
considerazione, quando si lavora su cose un tantino piu' complesse che
la calcolatrice di Windows.  A differenza di quanto tu possa pensare,
la teoria alla base dello sviluppo dei sistemi software influenza
*moltissimo* la pratica.  Non esisterebbe la programmazione orientata
agli oggetti se non fosse cosi'.

 codifica personale, lasciando perdere accademie e stili da libri di testo.
Assolutamente no.  Quando si programma in gruppo c'e' sempre bisogno
di arrivare a delle convenzioni.  Ribadisco: se non lo hai mai fatto,
evita di intervenire su questo punto, ci vuole tanto ?

 [...]
questo si da per scontato, non siamo a discutere se chiamare una variabile
in un certo modo puttosto che in un altro, è lampante che la cura della
sintassi del codice è alla base di un buon team programming, il discorso
(spero che sia stato cosi' per tutti) era molto più profondo. Si discuteva
la libertà di un programmatore di decidere autonomamente come implementare
un determinato algoritmo. Facciamo un esempio quasi banale: il codice per
tracciare una linea fra 2 punti.... quanti modi conoscete per farlo?
probabilmente tutti hanno presente il metodo bresenham, che poi è quello
riportato da quasi tutti i libri di computer grafica (anche il Foley
VanDamme), oppure il run-slice lenght riportato in alcuni libri "advanced" o
altri...
Il metodo migliore non esiste, anzi (e questo è il punto) non è ancora stato
scovato.
Qualcuno prima o poi abbandonando le vie classiche troverà un nuovo
algoritmo per tracciare una linea 200volte più veloce di tutti gli altri
finora creati, questa è creatività.
Questo è quello che io intendo "programmazione" e non digitare bellissime
righe di codice.


 trova spazio limitato...
Ma per piacere ! la teoria, come gia' detto, alla base dello sviluppo
del software influenza eccome la pratica.  Se oggi programmi in modo
orientato agli oggetti e' proprio grazie alla teoria alla base dello
sviluppo del software, che ha finalmente trovato un modo per
incanalare certi principi (vedi l'information hiding, la modularita',
...) in una strada percorribile dal programmatore, senza troppi
sforzi.  Suppongo che tu non abbia mai sentito parlare di "design
patterns".

Una soluzione particolarmente "estrosa" di un problema [cut]
Bye
AS

 tante cose giuste.
Non avrei mai pensato di dirlo, ma su questo sono d'accordo (considerazioni
personali a parte, come dovrebbe essere) con Andrea.
Programmare in team, anche se non l'ho mai fatto, è indiscutibilmente diverso
dal programmare per noi stessi e basta.
Se io faccio un programma per me, o comunque che so che nessun altro ci metterà
le mani, poco me ne frega di come o se lo commento e di come lo scrivo, di che
algoritmi uso ecc, ecc. Tanto al peggio non capirò più niente, ma dovrò solo
fare mea culpa.
Se dovessi lavorare con altra gente invece... non c'è paragone. E' una forma, se
vogliamo, di rispetto verso gli altri scrivere codice leggibile e manutenibile.
Oltretutto, alcune piccole cose come la denominazione delle variabili o la
generalizzazione delle funzioni, se usate anche per piccoli progetti aiutano
indiscutibilmente; non solo, se si usano sempre, poi non ci si fa più caso;
se mi permettete una metafora, è più o meno come imparare a suonare uno
strumento: all'inizio si fanno tante cose che non si capisce, che si reputano
stupide o troppo semplici. Ma in questo modo le si "assimilano" senza nemmeno
renderci conto che poi si usano ogni volta che si suona qualcosa.
Comunque, per concludere, credo che ancora una volta stiate discutendo per
niente, o meglio, su due cose differenti: la programmazione in generale e la
programmazione in team.
L'unico appiglio è il carattere di Andrea (discutibile, sotto certi aspetti, ma
molto raramente sull'aspetto tecnico...).
Confesso che a volte anche a me da fastidio il tono di alcune risposte di
Andrea, che con le sue conoscenze potrebbe tranquillamente rispondere un po'
meno "secco", ma ormai ci ho quasi fatto l'abitudine, e comunque lui è fatto
così; non sono certo la sua morosa/moglie per volerlo cambiare ;)
--
Jax che ha detto la sua e adesso è contento, fino al prossimo temporale...

 anche il Punto di vista di Laforgia.
Eppure ho provato tutte e due le soluzioni, ho ottenuto maggiori risultati
con il metodo del core-programmer autonomo.
Devo fare una premessa, io ritengo "peloso" un programmatore quando:
 - non ha nessuna paura di confrontarsi con codice scritto da altri
 - ritiene che il codice messo in produzione possa essere ancora ottimizzato
 - non si faccia troppe paranoie sulle "nuove tecnologie di programmazione"
 - obbietti quasi sempre, ma non troppo:), sui miei modi di vedere le cose
 - a cena mangi 3 pizze (è statisticamente provato... :))
sono esplosivi sempre sul punto di brillare...
gli altri non mi servono, è inutile che mi facciano codice pulito e bello
per un'eventuale esposizione nelle gallerie di Parigi....
E poi volgio ragionare su un concetto: perche' si dice sempre di fare codice
pulito e  documentato?
ma certo, per la riutilizzabilità dello stesso.... ok....
Quanto puo' durare un componente sia pur ben fatto e documentato? 4 mesi? 6
mesi? 1 anno?
I clienti vogliono avere sempre il massimo della tecnologia al minimo
costo.... Ogni 2 mesi la c'è una nuova tecnologia hardware da dover
considerare (lettori smart-card, lettori finger-print, wi-fi, gprs, meteo,
webcam, ....).
In una realtà di lavorativa, mi dite come scegliereste? "pelosi" ma
indipendenti nel codice o bravissimi e pulitissimi scribani?


 Cerca di fare qualcosa di utile per gli altri, astieniti ;)
Cosě poi vaghi per il NG a diffondere le tue teorie errate senza nessuno che
ti porta sulla retta via? No, grazie!


 patterns".
Gamma? Helm? (gli altri 2 mi sfuggono)... i 4 dell'ave maria?
chiariamo che io mi riferisco sempre ad un contesto in cui ci sia una
società con al suo interno vari team di sviluppo i quali sono divisi in
back-end e font-end programmers, questa è la mia realtà.
La realtà di una società che deve monetizzare il proprio lavoro. I 4
patterns guru succitati agivano in un contesto completamente differente
ossia quello della ricerca e sviluppo.
Ora, hai idea di quanto costi ad una società la ricerca e lo sviluppo? ne
hai la più pallida idea? sai cosa vuol dire avere un team di almeno 3
core-programmers, ossia i più pagati, impegnati nello sviluppo di un nuovo
pattern per la risoluzione di un problema tecnico che probabilemente entro
un anno è già stato stravolto da nuove tecnologie hardware?
Ecco perche' io dico la teoria va bene conoscerla... ma la realtà è un'altra
cosa.


 indipendenti nel codice o bravissimi e pulitissimi scribani?
Vuoi proprio saperlo? Sceglierei i secondi, non foss'altro che i primi non si
comandano facilmente e se uno di questi se ne va, sono organi genitali senza
zucchero (mai vista la pubblicitŕ dei sistemi di backup, CA mi pare?).
I secondi invece si possono scambiare, comandare e cambiare senza problemi... un
po' come usare un "layer" indipendente fra l'analisi e il programma :)
--
Jax

Rispondo a Carlo Bertuccini che, tra le altre cose, ha scritto:
Andrea >
Come al solito, non c'entri mai il punto del discorso.
Carlo >
BTW: si dice far centro e non far c'entro! ;)
Andrea >
Si dice "che cosa c'entra ?", non "che cosa centra ?".
Ha ragione Carlo. La frase "non c'entri mai il punto del discorso" è sbagliata.
Carlo >
Imbecille, non è questo il caso.
Ed ecco che con questo Carlo è passato dalla ragione al torto.
Ma smettetela, ca**o! Anche sulla grammatica vi pigliate????
--
Jax che ne ha un po' le palle piene, e a cui puntualmente verrà detto "ma perché
allora non te ne vai?" da qualche gentiluomo

 [cut]
il bello è che non è tanto diverso :)
la realtà (quello che io reputo realtà ovviamente...) è che è molto raro (se
non impossibile) che in una società ci sia più di 1 programmatore sullo
stesso codice, CVS quanto vuoi ma su uno stesso componente 1 e 1 sola
persona... altrimenti è un coding-jam da paura.
Non parlo di progetti open-source (source-forge, ecc...) dove un progetto
può occuparmi anni e anni di sviluppo e dove ogni tanto faccio uscire una
nuova release, io parlo di un progetto che ha un'inizio preciso e una fine
precisa (anche se, non so perche', si tende sempre ad andare in penale :)) )
e dove ogni progetto è una cosa a se, nettamente distinta da altri
progetti...
sono con voi con il concetto di scrivere codice elegante e pulito, ma questo
si da per scontato.


 Ed ecco che con questo Carlo è passato dalla ragione al torto.
No, mi spiace Jax, ma non è così! Ti sfido a trovare tra tutti i miei
messaggi qualcuno che sia stato apostrofato offensivamente  da parte mia.
Aldilà di Laforgia non ne troverai mai. Poi ti invito a cercare quante
persone siano state offese da Laforgia. Questa dell'italiano è solo una
delle tante volte in cui ha torto e pretende ragione con frasi tipo "Hai
bisogno di lezioni di italiano?". Sorry, ma non mi pento di come gli ho
risposto ... in passato magari lo ho fatto e di tutta risposta ho ricevuto
altre "frecciatine". Non facciamo finta di non sapere con chi abbiamo a che
fare, non facciamo finta di non sapere che Laforgia è un cafone maleducato.
Lui si permette questo atteggiamento solo perchè alle volte per evitare di
dirgli "Sei un maleducato e non meriti considerazione" qualcuno gli risponde
con frasi "Sei un buon programmatore che dovrebbe moderare i termini". E in
passato questo errore lo ho commesso anche io.


 po' come usare un "layer" indipendente fra l'analisi e il programma :)
bella la visione a layer... :) altro che risorse umane. :)
in pratica tu vorresti tutti bambini di 4+ anni che uniscono, seguendo le
istruzioni, i mattoncini del duplo (i lego sarebbero già troppo...)
Puo' essere che funzioni... ma sei un'assemblatore di codice... niente di
più...


 realmente "arte" ha bisogno di essere fondata su regole precise.
Ripeto che sono d'accordo con te su questo, ma io non critico le tue
risposte, ma il modo in cui le dai (alcune, of course).
Detto cio', mi chiedo come ha fatto Carlo Bertuccini: ma secondo te perche'
sei cosi' spesso al centro di flames? Ci sara' pure un motivo, o sono sempre
gli altri ?
--
{MSX}  -  
http://msx.rules.it
Mantenitore delle FAQ di it.comp.lang.delphi,
reperibili qui: 
http://gpi.infomedia.it/abc/delphi/FaqDelphi.txt

 codice... niente di più...
Embé? Cosa sono alla fine tutti gli sviluppatori Delphi e VB? Assembliamo ciò
che qualcun altro (peloso o no) ha fatto.
Ripeto: IMHO dovrebbero esserlo gli analisti, pelosi, e non gli sviluppatori.
--
Jax che ha come sfondo un bel gattone peloso :)

Carlo, lascialo perdere. Come gia' scrissi a suo tempo, Andrea deve avere
forti problemi a livello caratteriale. Onestamente, non so se, quando e come
lui abbia lavorato in team, oppure se i suoi discorsi campati in aria li
faccia solo per aver letto un testo all'universita', certo e' che non riesco
a immaginare un team di persone che si coordinino con lui, fatto salvo non
abbia un cane rabbioso di project leader che lo metta a stecchetto e lo
tratti per come si merita facendolo lavorare come un mulo, e in silenzio.
Questo potrebbe spiegare, pur se limitatamente, i suoi atteggiamenti
arroganti e il voler costantemente negare l'evidenza (prima lui ti offende,
poi quando glielo fai notare, la colpa e' tua che sei troppo bambino per
esserti offeso e devi ancora crescere e imparare dal Dio Laforgia :D ..ma ti
rendi conto?), ma do piu' credito ad un serio problema caratteriale. Tanto
appurato (ed e' da un bel po' che lo abbiamo appurato) che vogliamo fare?
continuare a sopportarlo? o killarlo? A me piace discutere con gente
educata, nel rispetto delle opinioni altrui, mentre Laforgia e' l'esatto
opposto del mio interlocutore tipo, e, dato che lui non vuole cambiare
atteggiamento, ma non solo, continua a negare di avere questo atteggiamento
irritante e arrogante, io lo ho killato. E invito voi a fare altrettanto.
Ciao, Sandro

D'accordissimo con te Carlo, su tutto. Comunque direi che sia il caso di
tornare a parlare di Delphi. Parlare di Laforgia non e' un argomento
granche' interessante, penso sarai d'accordo :)
Ciao, Sandro

 irritante e arrogante, io lo ho killato. E invito voi a fare altrettanto.
Mi chiedo come sia possibile che questa persona abbia un carattere talmente
pietoso da litigare con il mondo intero. Sono riuscito a trovare dei suoi
flame persino su it.discussioni.animali.cani !!
Comunque credo proprio che seguirò il tuo consiglio onde evitare di spendere
altro tempo dietro ad una persona che non merita un decimo dell'attenzione
che gli è stata data.


 granche' interessante, penso sarai d'accordo :)
FreeAndNil(Laforgia);// ;P
Davide DG.
-- 
All resistance is futile! Prepare to be disassembled !

> FreeAndNil(Laforgia);// ;P
ahahahah bella! :D
procedure TMainForm.FormCreate(Sender: TObject);
begin
 Application.OnMessage:=Self.LaforgiaMsgHandler;
end;
procedure TMainForm.LaforgiaMsgHandler(var Msg: TMsg; var Handled: Boolean);
begin
 if (Msg.message = WM_KEYDOWN) and
Screen.ActiveControl.InheritsFrom(TLaforgia) then Msg.wParam:=0;
end;
con questa semplice procedura, invece, qualunque cosa scriva Laforgia viene
completamente ignorata :D :D :D
Ciao, Sandro

 flame persino su it.discussioni.animali.cani !!
ma LOLLLLLLLLLLL!!!!!!!!!! :DDDDDDDDDDDD
Ciao, Sandro

 (i.e.: tutti programmano come me)", pensaci almeno tre volte ;)
Vero, ma lui programma in singolo, e allora può essere diverso il metodo.
Vero che anche lui ne trarrebbe vantaggio, ma se programma dal 1978,
probabilmente dovrebbe sforzarsi parecchio.

 evita di intervenire su questo punto, ci vuole tanto ?
Attento, leggi bene: lui ha detto "quando si scrive software NON in team".
(Non) ribadisco(non l'avevo ancora scritto): prima di rispondere, cerca di
leggere bene(se in occasioni come queste ti scusi, non ti fa male; comunque
già sei molto meno categorico di altre volte).
Per il contenuto concordo con te: personalmente se un software non è
modulare ecc. diventa più complicato programmarlo. Però voglio fare un caso
concreto Delphi(tanto per tornare all'argomento del ng): Il componente
TUpDown(le freccine su e giù su un campo numerico) supporta solo numeri
interi, quindi mi è servito scrivere delle procedure che aggirino il
problema(a chi interessa spiego come); quando ho scritto delle procedure per
farlo una volta per tutte, ho risolto problemi che avevo con due TUpDown che
si comportavano diversamente. Se avessi scritto un componente Delphi, avrei
potuto semplicemente trascinarlo sul form e impostare il TEdit(box di testo)
associato, come col TUpDown normale, MA avrei dovuto imparare a scrivere
componenti. Finché il programma è corto(forse 100 righe) non mi conviene, ma
se diventa + serio(es. 5000 righe, poi non so quale sia il punto esatto) e
lo uso tante volte anche in progetti diversi, mi conviene scrivere il
componente(che significa, all'incirca, incapsulare tutto). Questa soluzione
è più elegante dal punto di vista ingegneristico, ma non usarla, come ho
spiegato, non significa non saper programmare, significa essere + pratici.
Ciao
--
Paolo Giarrusso
Per rispondere togliere solo "TOGLIMI" dall'indirizzo, non _spam.

 sintassi del codice è alla base di un buon team programming
Spiacente, ma il discorso verte proprio su questo. Il post originale diceva:
un mio cliente vuole il sorgente del programma. La risposta: il sorgente
senza il programmatore originale non serve, perché nessun altro riuscirà a
metterci mani. Spunti vari:
* preferisco riscrivere del codice piuttosto che decifrarlo;
* anche commentandolo non si capisce;
sono stati postati pezzi di codice incomprensibile, come questo(è un pezzo
del codice originale, nell'altro thread, iniziato da Pinco Pallino)
// per ogni modello cerca tutte le combinazioni con tutti i colori
    s2:=CoordinateCelle;
    repeat
     n:=FastPos2(';'+s1+'+',s2); if n=0 then break;
     s4:=copy(s2,n+1,30);
     s4:=copy(s4,1,FastPos2(';',s4)); // a questo punto s4 contiene
<rifmod>+<rifcol>=<rifgriglia>;
     delete(s2,1,n+length(s4)-1);
     // determina il rifcol
     s3:=copy(s4,FastPos2('+',s4)+1,30); s3:=copy(s3,1,FastPos2('=',s3)-1);
Zortek aggiungeva: io ho una mia logica con cui so cosa sono s1,s2,s3,s4.
Inoltre, dal punto di vista della produttività, si è spesso assemblatori di
codice; tutti i programmi che informatizzano strutture dati di vario genere
venivano un tempo scritti da zero, ora si scriverebbero come database
Access+macro, o con ADO/SQL e un DBMS professionale. Nei siti Web si va
scopiazzando a man bassa, molti siti non sono altro che grafica+implementare
che a un utente vanno associati dei dati, una password, qualche controllo su
di essi e ciao ciao... Oddio, non c'è solo questo, ma il riuso di componenti
è una realtà immensa.


 si da per scontato.
A) come ti ho già scritto, il problema è che Andrea La Forgia si arrabbia in
modo discutibile contro la folla che non lo dà per scontato;
B) i progetti devono poter essere corretti, si devono correggere bug, si
devono aggiornare per l'euro, per l'anno 2000... per l'anno 2039, su Unix(il
contatore dei secondi a partire dal 1970 andrà in overflow), ecc.