View Full Version : Dubbio sicurezza opensource
jappilas
04-01-2006, 13:47
In realta' no, uno e' l'astrazione ad alto livello dell'altra :)
L'idea e' che a livello hardware l'esecuzione di "azioni" asincrone e' mediata attraverso il sistema degli interrupt. I primi sistemi operativi multitasking *nix astraevano questa visione a basso livello presentando una struttura basata sui concetti di eventi e thread. Che cos'e' un interrupt a piu' alto livello se non un evento in risposta al quale eseguire il codice di un thread? Che cos'e' il context switching se non un interrupt in risposta al quale il sistema operativo cambia contesto e continua l'esecuzione di un altro task?
Via via il concetto di thread si e' spostato dal sistema operativo alla CPU che "nasconde" al sistema operativo il meccanismo di interrupt dietro al concetto di task hardware. Poi si sono aggiunti i processi e i meccanismi di protezione della memoria bla bla bla...
Ma l'idea di base e' che sono due astrazioni a livelli differenti per risolvere lo stesso problema.
in quest' ottica hai ragione :)
il bello è che sono tutte cose che ho visto almeno una volta nella vita (in realtà molte di più, specie nell' ultimo periodo) e dovrei aver acquisito (come minimo sono da qualche parte nel mio cervello, per quanto questo sia una FIFO...)
però mi viene da ragionare a "compartimenti stagni" e non correlare... :fagiano:
cdimauro
04-01-2006, 13:49
io ho provato a argomentare sul fatto ke il programmatore open lo fa xkè gli piace mentre il closed xkè ci lavora! secondo me non è da sottovalutare! io rendo molto di + quando programmo quello ke mi piace!
Ho realizzato tanti programmi per uso personale che NON ho mai rilasciato: l'ho fatto perché mi piace. Nonostante ciò, la qualità e l'impegno che metto nel mio lavoro non ha NULLA da invidiare: come diceva fek, si tratta di professionalità.
poi vi ripeto: closed non vuol dire + sicuro! e fin qui è certo!
Chi l'ha mai negato questo? Continui ancora con questa storia? Mah. :rolleyes:
Artemisyu
04-01-2006, 13:50
Ora capisco perchè i miei colleghi ed amici (anche più grandi, ingegneri informatici e sviluppatori a loro volta) raccontano così tante storie sugli ingegneri del software. :D
Allora non erano leggende metropolitane.
cdimauro
04-01-2006, 13:50
Quindi, quel codice, era di ottima qualità, la figura l'ha fatta solo Bill Gates... :confused:
Cosa intendi per qualità?
cdimauro
04-01-2006, 13:52
Ora capisco perchè i miei colleghi ed amici (anche più grandi, ingegneri informatici e sviluppatori a loro volta) raccontano così tante storie sugli ingegneri del software. :D
Allora non erano leggende metropolitane.
Tipo? Così ci facciamo tutti 4 risate. :p
Chi l'ha mai negato questo? Continui ancora con questa storia? Mah. :rolleyes:
allora basta! questo thread è chiuso! all'unanimità abbiamo deciso ke non c'è da avere dubbi sulla sicurezza del software open source! è sicuramente valido quanto il software closed source!
fine
cdimauro
04-01-2006, 13:54
allora basta! questo thread è chiuso! all'unanimità abbiamo deciso ke non c'è da avere dubbi sulla sicurezza del software open source! è sicuramente valido quanto il software closed source!
fine
:cincin:
jappilas
04-01-2006, 13:55
doppio sorry :O
jappilas
04-01-2006, 13:56
Non ci sto capendo niente personalmente su tutto questa discussione.... :p
interrupt su un thread in cui si parla di sicurezza dell'opensource? :p
hai ragione, ultimamente l' argomento del thread è un tantino virato e le problematiche lo renderebbero più idoneo a un' altra sezione ...
Già detto: MS ha già pubblicato un workaround. ;)
Chiariscimi: ha pubblicato un workaround o una patch ?
Perché a volte, e qua ti offenderai di nuovo, i puristi dell'informatica si nascondono dietro terminologie degne del miglior burocrate o commerciale.
Senza offesa.
jappilas
04-01-2006, 13:59
Quindi, quel codice, era di ottima qualità, la figura l'ha fatta solo Bill Gates... :confused:
riguardo all' episodio in cui win98 andò in BSOD in diretta (di cui a qualche pagina addietro).... sai che era una bufala vero? :D
imho, dal momento che il blue screen si è visto chiaramente "subentrare" da destra con effetto "tendina", non poteva essere altro che una cosa preparata ad arte, quindi prima di convincermi che non fosse uno scherzo ce ne vuole... :asd:
a meno che non si tratti di un caso diverso da quello a cui ti riferivi...
scusatemi.. ho scaricato diamonds e penso ke ci impiegherei una vita a capire tutte le interazioni tra le varie classi... non c'è un diagramma UML (intendo astratto-generale non completo-totale) o qualkosa di simile? oltretutto non ho capito xkè in gameloop c'è una kiamata a sleepOneMillisecond... kiaro a cosa serve... ma xkè?
poi mi sembra ke javadoc sia uno strumento insostituibile... usate qualkosa di simile x generare la documentazione automaticamente?
Cosa intendi per qualità?
Un codice in cui uno, per parole tue, non deve preoccuparsi delle figuracce.
O la frase
A giudicare da tanto software open source che ho visto, sono in molti a non preoccuparsi delle figuracce...
Prescindeva dalla qualità ?
Comunque, per me, un codice è di qualità quando funziona ed è gestibile.
Potete scriverlo usando i criteri che meglio volete, ma se è porcheria tale resta a prescindere dall'ottima leggibilità del codice o dal modello implementato.
Per cui può esistere ottimo codice open source e pessimo closed source e viceversa.
La discussione era sul fatto che il codice sorgente aumentasse le falle di sicurezza o meno, ma la domanda, a questo punto è mal posta.
cdimauro
04-01-2006, 14:05
Chiariscimi: ha pubblicato un workaround o una patch ?
Perché a volte, e qua ti offenderai di nuovo, i puristi dell'informatica si nascondono dietro terminologie degne del miglior burocrate o commerciale.
Senza offesa.
Nessuna offesa, e poi sono un tipo piuttosto preciso (si sarà capito ;)): ho usato il termine corretto, che è appunto workaround. La patch è attesa entro la prossima settimana.
cdimauro
04-01-2006, 14:12
Un codice in cui uno, per parole tue, non deve preoccuparsi delle figuracce.
O la frase
Prescindeva dalla qualità ?
Bisognava distinguere, perché tu hai citato un bug (che a qualcuno risulta essere una bufula), che ci può essere tanto nel codice scritto bene / di qualità, quanto in quello scritto male. I bug, e lo ripeto per la milionesima volta, sono una componente intrinseca del software stesso.
Comunque, per me, un codice è di qualità quando funziona ed è gestibile.
L'obiettivo di QUALUNQUE codice, scritto bene oppure male, è pur sempre quello: risolvere il problema.
Potete scriverlo usando i criteri che meglio volete, ma se è porcheria tale resta a prescindere dall'ottima leggibilità del codice o dal modello implementato.
Secondo la tua definizione, potrebbe anche essere una porcheria e illeggibile: sempre di codice di qualità si tratterebbe, perché il risultato è quello desiderato. Anche le porchierie e i software illegibili sono comunque "gestibili".
Per cui può esistere ottimo codice open source e pessimo closed source e viceversa.
Certamente.
La discussione era sul fatto che il codice sorgente aumentasse le falle di sicurezza o meno, ma la domanda, a questo punto è mal posta.
Sicuramente, visto che così com'è posta ha poco senso.
Artemisyu
04-01-2006, 14:13
Tipo? Così ci facciamo tutti 4 risate. :p
Niente di particolare... semplicemente che sono il ramo più rompipalle di tutta l'informatica.
Fanno di ogni cosa un formalismo astratto.
Pianificano tantissimo sviluppo e non sviluppano nulla... cose del genere :D :D
Mi sembra di vedere questo thread in quelle parole.
Le N pagine sono state spese a discutere sullo stile del codice, volendo dare un valore qualitativo al software in base a come è scritto.
Nel lug in cui partecipo c'è della gente con una preparazione non indifferente... abbiamo un esperto di crittografia via rete, un proprietario di una azienda partner redhat che fa amministrazione di rete e sviluppa anche in java (la bytecode, non so se qualcuno l'ha mai sentita) ed un altro paio di personaggi non trascurabili.
Una cosa che gli ho sentito direi è che gli ingegneri del software riescono a moltiplicarti il costo di sviluppo del software senza che l'applicativo rispecchi gli effettivi costi.
Hanno aggiunto anche che trovare un ingegnere del software che dica che un applicativo è ben programmato è un impresa, specialmente se questo applicativo fa effettivamente qualcosa di utile :D
:p :sofico:
Secondo la tua definizione, potrebbe anche essere una porcheria e illeggibile: sempre di codice di qualità si tratterebbe, perché il risultato è quello desiderato.
questa frase è tutto un programma.. e secondo te se il codice è illeggibile quanto ci impiego a scrivere una patch? e se arriva un nuovo programmatore? come gli spiego tutto il codice? non è inefficiente?
ps. si decisamente non hai studiato a stanford!
Ora capisco perchè i miei colleghi ed amici (anche più grandi, ingegneri informatici e sviluppatori a loro volta) raccontano così tante storie sugli ingegneri del software. :D
Allora non erano leggende metropolitane.
Tieni distinti gli ingegneri informatici dagli ingegneri e ancor più dai dottori in informatica thanks, ;)
Se non tieni presente la distinzione, non potrai capire il 50% delle barzellette !
Artemisyu
04-01-2006, 14:21
Tieni distinti gli ingegneri informatici dagli ingegneri e ancor più dai dottori in informatica thanks, ;)
Se non tieni presente la distinzione, non potrai capire il 50% delle barzellette !
Vivo a contatto con tutte queste categorie di persone :)
Tranquillo che le distinguo benissimo :)
Io comunque citavo le vicissitudini degli ingegneri del software (ing informatici con adeguata formazione e specializzazione).
Sono in grado di raccattare su illazioni del tipo: "non assumerò mai un informatico che abbia passato l'esame di ingegneria del software con più di 19. non voglio fallire" :D :D
Niente di particolare... semplicemente che sono il ramo più rompipalle di tutta l'informatica.
Fanno di ogni cosa un formalismo astratto.
Allora stai parlando, nell'ordine, di:
1) Dottori in Informatica
2) Ingegneri in Informatica (che degli ingegneri hanno preso poco ;))
Gli altri ingegneri (solitamente gli elettronici propensi all'informatica), vanno più al cuore del problema e sono quelli che lasciano teorizzare i primi e risolvono nel concreto i punti lasciati in sospeso ndei secondi
:p
Allora stai parlando, nell'ordine, di:
1) Dottori in Informatica
2) Ingegneri in Informatica (che degli ingegneri hanno preso poco ;))
Gli altri ingegneri (solitamente gli elettronici propensi all'informatica), vanno più al cuore del problema e sono quelli che lasciano teorizzare i primi e risolvono nel concreto i punti lasciati in sospeso ndei secondi
:p
non generalizziamo! io sto facendo ingegneria informatica ma odio i formalismi e prediligo risolvere i problemi (come tutti gli ingegneri)! ke gli ingegneri del SW riescono a complicarti la vita anke quando è semplice è vero xò!
ps. nessuno mi risponde su diamonds?
Artemisyu
04-01-2006, 14:26
Allora stai parlando, nell'ordine, di:
1) Dottori in Informatica
2) Ingegneri in Informatica (che degli ingegneri hanno preso poco ;))
Gli altri ingegneri (solitamente gli elettronici propensi all'informatica), vanno più al cuore del problema e sono quelli che lasciano teorizzare i primi e risolvono nel concreto i punti lasciati in sospeso ndei secondi
:p
Si è vero.
Comunque io ho conosciuto diversi dottori in informatica che sono sviluppatori decisamente pratici e che finalizzano molto i loro progetti.
D'altro canto ho visto anche ingegneri informatici che erano assolutamente fuori di melone.
Ne ho conosciuto anche uno di recente che sviluppa Hurd nel tempo libero.
Per carità, è un gran cranio, però è troppo formalista... se su Hurd sono tutti così ci credo che ancora non funziona :D
Nessuna offesa, e poi sono un tipo piuttosto preciso (si sarà capito ;)): ho usato il termine corretto, che è appunto workaround. La patch è attesa entro la prossima settimana.
Il che è più o meno in linea con i punti che avevo detto prima, pausa caffè compresa.
E dire che sono (o dovrebbero essere) in tanti a lavorarci ;)
Per carità, una settimana è un buon tempo. Bisognerebbe vedere nella realtà quante righe di codice devono essere modificate. Se era una e ma la dicevano, patchavo il sorgente e ricompilavo. Se dava problemi, li avvisavo, se no, in attesa della patch ufficiale, mi ero già ritirato un po' su i calzoni :D
Se fosse stato linux....
non generalizziamo! io sto facendo ingegneria informatica ma odio i formalismi e prediligo risolvere i problemi (come tutti gli ingegneri)!
Che ci vuoi fare, le eccezioni che si iscrivono al corso sbagliato ci sono ;). In quanto eccezioni, confermano la regola !
Sarà compito tuo risollevare le credenziali del settore ;)
jappilas
04-01-2006, 14:31
Che ci vuoi fare, le eccezioni che si iscrivono al corso sbagliato ci sono ;)
mi fai ripensare che avevo un 45% di possibilità di andare a Biologia... :D
Che ci vuoi fare, le eccezioni che si iscrivono al corso sbagliato ci sono ;). In quanto eccezioni, confermano la regola !
Sarà compito tuo risollevare le credenziali del settore ;)
non credo ke farò l'ingegnere del SW! altrimenti adoravo i formalismi (mi dispiace non c'è speranza x il settore)! xò ingegneria del SW è una materia importante (una volta ripulita dai formalismi) ke tutti i programmatori devono conoscere! fare quello di lavoro è un altro paio di maniche.. no non è la mia aspirazione!
Artemisyu
04-01-2006, 14:39
non credo ke farò l'ingegnere del SW! altrimenti adoravo i formalismi (mi dispiace non c'è speranza x il settore)! xò ingegneria del SW è una materia importante (una volta ripulita dai formalismi) ke tutti i programmatori devono conoscere! fare quello di lavoro è un altro paio di maniche.. no non è la mia aspirazione!
Sicuramente, è ovvio.
Ma ho anche sentito gente molto più saggia di me sostenere che l'ing. del sw è si importantissima, ma che una volta spogliata dell'aria fritta rimane ben poco.
Solo un po' di capacità di pianificazione e un po' di linee guida per scrivere il codice in modo che i sistemi preposti a testare il codice sviluppato lavorino meglio. :)
scusatemi.. ho scaricato diamonds e penso ke ci impiegherei una vita a capire tutte le interazioni tra le varie classi... non c'è un diagramma UML (intendo astratto-generale non completo-totale) o qualkosa di simile? oltretutto non ho capito xkè in gameloop c'è una kiamata a sleepOneMillisecond... kiaro a cosa serve... ma xkè?
poi mi sembra ke javadoc sia uno strumento insostituibile... usate qualkosa di simile x generare la documentazione automaticamente?
Il class diagram è troppo lungo da mantenere a mano, come la documentazione javadoc. Stiamo cercando qualcosa che lo faccia in automatico ad ogni commit.
sleepOneMillisecond è una semplice try/catch con dentro una Thread.Sleep(1). Serve a mettere a riposo il gioco per 1 millisecondo cedendo il controllo anche agli altri processi nel sistema.
ciao ;)
Sicuramente, è ovvio.
Ma ho anche sentito gente molto più saggia di me sostenere che l'ing. del sw è si importantissima, ma che una volta spogliata dell'aria fritta rimane ben poco.
Solo un po' di capacità di pianificazione e un po' di linee guida per scrivere il codice in modo che i sistemi preposti a testare il codice sviluppato lavorino meglio. :)
in realtà si tratta migliorare la qualità del SW (udite udite esiste un metro di paragone) rispettando i seguenti punti:
- affidabilità
- efficienza
- facilità di comprensione e modifica
l'ho tratto dalla prima pagina dei miei appunti di ingSW! se qualkuno vuole contestare può farlo dicendo ke sia Barbara Liskov ke Carlo Ghezzi non sanno quello ke dicono :D
x il terzo punto è fondamentale la leggibilità del codice!
Nessuna offesa, e poi sono un tipo piuttosto preciso (si sarà capito ;)): ho usato il termine corretto, che è appunto workaround. La patch è attesa entro la prossima settimana.
Riferendomi alla falla in oggetto, ho l'impressione che quanto dice Attivissimo nell'ultimo articolo che ho linkato sia abbastanza allarmante:
La cosa ironica... [cut]
Continua su http://attivissimo.blogspot.com/2006/01/falla-wmf-il-rischio-aumenta-come.html
Dando un'occhiata ai bollettini di sicurezza di Microsoft degli ultimi 16 mesi, ho visto che vulnerabilita' simili (esecuzione di codice arbitrario) relative a WMF sono piuttosto frequenti, quindi sono portato a pensare che questa componente non sia stata progettata adeguatamente e che nessuna patch, seppur preceduta dal necessario workaround, potra' porvi rimedio. :stordita:
Edit: ho rimosso la citazione dell'articolo di Paolo Attivissimo per non violare le modalita' di distribuzione del suo materiale :O Andate sul suo blog... :)
Il class diagram è troppo lungo da mantenere a mano, come la documentazione javadoc. Stiamo cercando qualcosa che lo faccia in automatico ad ogni commit.
sleepOneMillisecond è una semplice try/catch con dentro una Thread.Sleep(1). Serve a mettere a riposo il gioco per 1 millisecondo cedendo il controllo anche agli altri processi nel sistema.
ciao ;)
aspetta... mi stai dicendo ke senza quella chiamata sul pc può girare solo diamonds? il multithreading non è gestito a livello di SO? scusa voglio solo capire, non sto contestando!
x class diagram intendevo qualkosa di alto livello ke desse un idea generale e basta delle interazioni basilari tra le classi! un class diagram completo è suicidio!
per vostra informazione se utilizzate eclipse potete scrivere la javadoc con sforzo pari a 0,1 visto ke eclipse la scrive da solo quasi!
aspetta... mi stai dicendo ke senza quella chiamata sul pc può girare solo diamonds? il multithreading non è gestito a livello di SO? scusa voglio solo capire, non sto contestando!
No qui stiamo parlando di java. Per il sistema operativo il nostro giochino non è altro che un'altra istanza della jvm. Sara poi la vm a gestire i vari thread del programma java.
x class diagram intendevo qualkosa di alto livello ke desse un idea generale e basta delle interazioni basilari tra le classi! un class diagram completo è suicidio!
per vostra informazione se utilizzate eclipse potete scrivere la javadoc con sforzo pari a 0,1 visto ke eclipse la scrive da solo quasi!
Il problema è che il codice cambia troppo rapidamente. Se ad ogni commit dobbiamo aggiornare Javadoc e il class diagram i tempi di allungano di molto.
Abbiamo gia i test che spiegano che controllano e spiegano le varie relazioni tra le classi e le funzioni delle singole funzioni.
ciao ;)
Comunque, per me, un codice è di qualità quando funziona ed è gestibile.
Potete scriverlo usando i criteri che meglio volete, ma se è porcheria tale resta a prescindere dall'ottima leggibilità del codice o dal modello implementato.
Per cui può esistere ottimo codice open source e pessimo closed source e viceversa.
Per altro la definizione che hai dato sul codice di qualita' (funziona ed e' gestibile) e' la definizione corretta. Ho visto tantissimo codice closed source assolutamente pessimo, ci ho anche dovuto lavorare ed ho visto altrettanto codice open davvero pessimo. Rafforza il concetto che la differenza fra open e closed sta solo nel metodo di distribuzione.
Poi possiamo discutere sul fatto che un modello di sviluppo distribuito tipico di molti progetti open sia buono o no, io non ne sono convinto per svariati motivi.
Una cosa che gli ho sentito direi è che gli ingegneri del software riescono a moltiplicarti il costo di sviluppo del software senza che l'applicativo rispecchi gli effettivi costi.
In questo caso non sono ingegneri del software :)
Il buon ingegnere e' quello che minimizza i costi di sviluppo a parita' di funzionalita'.
Hanno aggiunto anche che trovare un ingegnere del software che dica che un applicativo è ben programmato è un impresa, specialmente se questo applicativo fa effettivamente qualcosa di utile :D
Io sono solito portare CruiseControl come un esempio di ottimo codice, di alta qualita', ben programmato e che fa esattamente quello che serve ed e' molto utile. E guardate quanti commenti ci sono dentro :)
No qui stiamo parlando di java. Per il sistema operativo il nostro giochino non è altro che un'altra istanza della jvm. Sara poi la vm a gestire i vari thread del programma java.
ok.. ho provato a togliere quella riga di codice... cambia qualkosa? sono riuscito ad avviare altri programmi java senza problemi! infatti ci sono vari processi ke come nome hanno java e il SO li tratta come gli altri processi, cioè in multithreading.. sei sicuro ke sia questa la ragione di quella riga di codice?
x il resto noto una grande pulizia nel codice (complimenti). non vuol dire ke è di alta qualità, ma sicuramente è buon codice!
x class diagram intendevo qualkosa di alto livello ke desse un idea generale e basta delle interazioni basilari tra le classi! un class diagram completo è suicidio!
per vostra informazione se utilizzate eclipse potete scrivere la javadoc con sforzo pari a 0,1 visto ke eclipse la scrive da solo quasi!
C'e' una batteria di test che documenta in maniera precisa l'interfaccia di ogni classe e le interazioni fra varie classi. Nessuno ha mai avuto grossi problemi ad entrare nel progetto, di solito in un paio d'ore ed una lettura ai test, sono tutti perfettamente in grado di iniziare ad essere produttivi, da qualunque livello di preparazione siano arrivati.
sleepOneMillisecond() che cosa' fa'? Beh, mette a dormire il gioco per un millisecondo :)
I dettagli di una chiamata a sleep() della JVM sono disponibili sulla documentazione della JVM stessa.
ok.. ho provato a togliere quella riga di codice... cambia qualkosa? sono riuscito ad avviare altri programmi java senza problemi! infatti ci sono vari processi ke come nome hanno java e il SO li tratta come gli altri processi, cioè in multithreading.. sei sicuro ke sia questa la ragione di quella riga di codice?
Come l'SDK delle Win32 spiega, Sleep non fa altro che rilasciare il resto del timeslice al sistema operativo che e' libero di schedulare altri task e processi, ma prima di un millisecondo non puo' rischedulare il task corrente. Senza quella chiamata, eventuali thread nel sistema a priorita' piu' bassa non avranno mai la possibilita' di essere eseguiti e Diamonds tenderebbe a occupare tutta la CPU di cui ha bisogno (non molta al momento).
x il resto noto una grande pulizia nel codice (complimenti). non vuol dire ke è di alta qualità, ma sicuramente è buon codice!
E' codice di alta qualita'. Risultato sorprendente considerando che i ragazzi che lo hanno scritto sono spesso all'inizio della loro carriera, ma li contraddistingue una grande voglia di imparare e una grande apertura mentale, decisamente non comune come abbiamo notato anche da te in questo topic :)
C'e' una batteria di test che documenta in maniera precisa l'interfaccia di ogni classe e le interazioni fra varie classi. Nessuno ha mai avuto grossi problemi ad entrare nel progetto, di solito in un paio d'ore ed una lettura ai test, sono tutti perfettamente in grado di iniziare ad essere produttivi, da qualunque livello di preparazione siano arrivati.
sleepOneMillisecond() che cosa' fa'? Beh, mette a dormire il gioco per un millisecondo :)
I dettagli di una chiamata a sleep() della JVM sono disponibili sulla documentazione della JVM stessa.
a parte ke oggettivamente è + immediato e intuitivo un diagramma (questione di scelte, voi avete fatto la vostra e può essere benissimo accettata) ma... io non ho kiesto cosa fa sleepOneMillisecond()! ho kiesto xkè c'è!
UPDATE: ok l'hai detto sopra
Come l'SDK delle Win32 spiega, Sleep non fa altro che rilasciare il resto del timeslice al sistema operativo che e' libero di schedulare altri task e processi, ma prima di un millisecondo non puo' rischedulare il task corrente. Senza quella chiamata, eventuali thread nel sistema a priorita' piu' bassa non avranno mai la possibilita' di essere eseguiti e Diamonds tenderebbe a occupare tutta la CPU di cui ha bisogno (non molta al momento).
non ho capito cosa c'entra l'SDK delle win32.. in ogni modo... ma se era quello lo scopo xkè non avete usato Thread.yeld()? quello si ke è autoesplicativo! inoltre la storia del millisecondo mi sembra un pò approssimativa.. può essere ke in particolari condizioni di sovraccarico un millisecondo non basta?
E' codice di alta qualita'. Risultato sorprendente considerando che i ragazzi che lo hanno scritto sono spesso all'inizio della loro carriera, ma li contraddistingue una grande voglia di imparare e una grande apertura mentale, decisamente non comune come abbiamo notato anche da te in questo topic :)
dubito ke molte persone hanno una visione d'insieme làddentro! forse te e i pochi ke hanno ideato il progetto... gli unit case non danno molto la visione di insieme! altrimenti si chiamavano ensemble case :D !
Il problema è che il codice cambia troppo rapidamente. Se ad ogni commit dobbiamo aggiornare Javadoc e il class diagram i tempi di allungano di molto.
sapete della compilazione incrementale vero? poi non serve a ogni commit...
Per altro la definizione che hai dato sul codice di qualita' (funziona ed e' gestibile) e' la definizione corretta. Ho visto tantissimo codice closed source assolutamente pessimo, ci ho anche dovuto lavorare ed ho visto altrettanto codice open davvero pessimo. Rafforza il concetto che la differenza fra open e closed sta solo nel metodo di distribuzione.
Poi possiamo discutere sul fatto che un modello di sviluppo distribuito tipico di molti progetti open sia buono o no, io non ne sono convinto per svariati motivi.
Abbiamo quasi trovato la convergenza ;)
Per quanto riguarda le metodologie di sviluppo, credo che i discorsi precedenti siano entrambi validi se si fa una precisazione, che a me, fino a questo momento, è sfuggita: dipende dal target del software.
Se si deve fare un software che ha un target di utenza, di sviluppo, di riusabilità, di persone coinvolte ed anche di budget consistente, adottare certe metodologie (specifiche dettagliate, UML, codice stra-strutturato per la leggibilità, ecc.) ha senso. Ma sono cose che comunque hanno un costo in tempo e denaro (non parlo dello stile di scrittura, una volta appreso non dipende molto dal target)
Se il software è su commissione per un piccolo applicativo a limitato uso (per lo meno nell'idea iniziale), non si può sforare dal budget o dai tempi con discussioni sulla modellizzazione, sulle specifiche fino all'ultimo bit, sul codice leggibile senza commenti, ecc.
Perché o rifiuti il lavoro, o se lo fai devi accontentarti delle specifiche che hai e usare il commento nel codice per dettagliarle meglio nel corso di sviluppo.
E' il classico caso del cliente che sa cosa vuole, ma non come ;)
IMHO
non ho capito cosa c'entra l'SDK delle win32.. in ogni modo... ma se era quello lo scopo xkè non avete usato Thread.yeld()? quello si ke è autoesplicativo! inoltre la storia del millisecondo mi sembra un pò approssimativa.. può essere ke in particolari condizioni di sovraccarico un millisecondo non basta?
Perche' yield rischedula solo processi allo stesso livello di priorita' e non garantisce l'esecuzione di processi a livello di priorita' inferiore.
dubito ke molte persone hanno una visione d'insieme làddentro! forse te e i pochi ke hanno ideato il progetto... gli unit case non danno molto la visione di insieme! altrimenti si chiamavano ensemble case :D !
Praticamente tutti quelli che partecipano attivamente (io non scrivo codice) hanno visione di insieme e sono in grado di scrivere in qualunque parte del codice, grazie ai test.
sapete della compilazione incrementale vero? poi non serve a ogni commit...
Vicius sta parlando di tenere eventualmente aggiornato un class diagram manualmente ad ogni commit: operazione troppo dispendiosa in termini di tempo e perfettamente inutile perche' i test coprono gia' la documentazione in maniera ottima.
jappilas
04-01-2006, 17:14
Io sono solito portare CruiseControl come un esempio di ottimo codice, di alta qualita', ben programmato e che fa esattamente quello che serve ed e' molto utile. E guardate quanti commenti ci sono dentro :)
pochi, molto pochi :)
E' codice di alta qualita'. (rif: Diamonds)
lo definirei anche molto nitido :)
ho scaricato ora l' SVN, il tempo di orientarmi nel trunk e forse forse ... :D
pochi, molto pochi :)
lo definirei anche molto nitido :)
ho scaricato ora l' SVN, il tempo di orientarmi nel trunk e forse forse ... :D
Mi sono sempre domandato perche' uno come te non abbia mai partecipato ;)
Se tutta questa noiosa discussione fosse servita a farti innamorare di Diamonds, ne sarebbe valsa ampiamente la pena... partecipa che e' divertente. E si impara a non commentare il codice :D
Perche' yield rischedula solo processi allo stesso livello di priorita' e non garantisce l'esecuzione di processi a livello di priorita' inferiore.
grazie! si impara sempre qualcosa!
Praticamente tutti quelli che partecipano attivamente (io non scrivo codice) hanno visione di insieme e sono in grado di scrivere in qualunque parte del codice, grazie ai test.
se ne sei sicuro...
Vicius sta parlando di tenere eventualmente aggiornato un class diagram manualmente ad ogni commit: operazione troppo dispendiosa in termini di tempo e perfettamente inutile perche' i test coprono gia' la documentazione in maniera ottima.
io invece parlavo di javadoc guardacaso!
Io sono solito portare CruiseControl come un esempio di ottimo codice, di alta qualita', ben programmato e che fa esattamente quello che serve ed e' molto utile. E guardate quanti commenti ci sono dentro
è finita la pubblicità?
secondo me pinok ha ragione! il fatto di non documentare il codice (attenzione non ho detto commentare) non è la tecnica migliore sempre! dipende dalle dimensioni del progetto e dal livello di manutenibilità ke si vuole avere! può essere conveniente nei progetti relativamente piccoli anke per risparmiare un sacco di tempo, ma alla lunga sui progetti grossi costituisce una perdita di tempo!
jappilas
04-01-2006, 17:43
Mi sono sempre domandato perche' uno come te non abbia mai partecipato ;)
alcune (dis)avventure negli ultimi tempi mi hanno impedito di uscire dal recinto del c++... :mc:
tra l' altro ammetto di aver dovuto ultimamente, scrivere codice inferiore alla qualità che avrei voluto ottenere... :cry: un po' perchè non ne avevo controllo totale, ma soprattutto perchè ci si deve appoggiare a una libreria con convenzioni e comportamento praticamente sui generis (l' alternativa era riscrivere ex novo la pletora di codec di cui avevano bisogno )... :stordita:
se vuoi avere un' idea di quanto penoso sia il risultato (tra l' altro, ancora workinprogress) ...
Se tutta questa noiosa discussione fosse servita a farti innamorare di Diamonds, ne sarebbe valsa ampiamente la pena... partecipa che e' divertente.
se è per quello, lo scopo è stato raggiunto
E si impara a non commentare il codice :D
visto che di solito ho più difficoltà a pensare come scrivere un commento che "fitti" che non a inventare un nome (a meno che i termini simili non comincino a proliferare come mi è successo), su questo ci andrei a nozze :D
tra l' altro ammetto di aver dovuto ultimamente, scrivere codice inferiore alla qualità che avrei voluto ottenere... :cry: un po' perchè non ne avevo controllo totale, ma soprattutto perchè ci si deve appoggiare a una libreria con convenzioni e comportamento praticamente sui generis (l' alternativa era riscrivere ex novo la pletora di codec di cui avevano bisogno )... :stordita:
se vuoi avere un' idea di quanto penoso sia il risultato (tra l' altro, ancora workinprogress) ..
ffmpeg? :D
ciao ;)
jappilas
04-01-2006, 18:01
ffmpeg? :D
ciao ;)
sì... :cry:
inizialmente sembrava simpatica e promettente... nonchè l'unica strada percorribile per dotare la Piattaforma (http://www.infomus.dist.unige.it/eywindex.html) di un modulo di lettura di file mutimediali sufficientemente generale...
poi ci siamo scontrati (io e l' amico a cui è stato assegnato il lavoro , lui per finalizzare un esame, io per iniziare la tesi) con l' impossibilità apparente di ottenere una build senza mingw, poi con le allocazioni / disallocazioni di memoria che la libreria effettua internamente, e ultimamente, con la sequenziazione dei presentation timestamp degli av_frame audio in uscita...
anche tu, se vuoi ricevere una mail che ti dia un' idea di quanto penoso sia il livello attualmente raggiunto e quanto scarse le mie capacità...
secondo me pinok ha ragione! il fatto di non documentare il codice (attenzione non ho detto commentare) non è la tecnica migliore sempre! dipende dalle dimensioni del progetto e dal livello di manutenibilità ke si vuole avere! può essere conveniente nei progetti relativamente piccoli anke per risparmiare un sacco di tempo, ma alla lunga sui progetti grossi costituisce una perdita di tempo!
No, non ha ragione, e' vero l'esatto contrario. Per raggiungere alti livelli di affidabilita' del codice e produttivita' nella costruzione del codice e' molto meglio non documentare in linguaggio naturale, ma affidarsi ai test. E' proprio su progetti di grosse dimensioni che si nota il vantaggio, perche' appiattisce la curva dei costi. Non avendo tu mai partecipato ad un progetto commerciale di grosse dimensioni (diciamo milioni di linee di codice per due o tre anni di sviluppo), non puoi ovviamente apprezzare questo discorso, ti limiti a ripetere a pappagallo quello che hai letto (e non hai capito) sul libro di ingegneria del software. La realta' produttiva e' molto diversa.
posso kiedere una cosa xò? cosa c'è nel vostro metodo degli unit case ke in JML non si può fare? alla fine per come utilizzate junit (cioè come linguaggio x definire asserzioni) mi pare ke non ci siano problemi a utilizzare JML al posto di junit!
ad esempio al posto di fare dei test come i seguenti:
public void testBackgroundPosition()
{
assertEquals("X origin must be 0", 0F, background.getX());
assertEquals("Y origin must be 0", 0F, background.getY());
}
public void testBackgroundWidthAndHeight()
{
assertEquals("Width must be equal to the width of the window", 1024,
background.getWidth());
// Game.getWindowWidth(), background.getWidth());
assertEquals("Height must be equal to the height of the window", 1024,
background.getHeight());
// Game.getWindowHeight(), background.getHeight());
}
public void testBackgroundSpriteNotNull()
{
assertNotNull(background.getSprite());
}
public void testDraw()
{
MockEngine engine = new MockEngine();
background.draw(engine);
assertEquals(1, engine.getNumberOfQuadsDrawn());
}
si poteva pensare di scrivere sopra il costruttore di Background qualcosa tipo:
//@ requires (se c'è qualke condizione da mettere x i parametri in ingresso..)
//@ ensures background.getX()==0 && background.getY()==0 && background.getSprite()!=null && background.getWidth()==1024 && background.getHeight() == 1024
//@ signals (le eccezioni da lanciare nei vari casi es. (NullPointerException npe) background.getSprite()==null)
mentre il controllo su draw sarebbe da vedere in MockEngine...
vi dirò.. JML è anke + potente (oltre a essere + compatto)!
posso kiedere una cosa xò? cosa c'è nel vostro metodo degli unit case ke in JML non si può fare? alla fine per come utilizzate junit (cioè come linguaggio x definire asserzioni) mi pare ke non ci siano problemi a utilizzare JML al posto di junit!
Il 99% dei test non sono esprimibili in JML. Ad esempio le interazioni fra oggetti mediante mock.
Il 99% dei test non sono esprimibili in JML. Ad esempio le interazioni fra oggetti mediante mock.
prima di tutto non si tratta del 99% dei test (ho dato un'occhiata ai test) e poi se MockEngine ha come rep invariant getNumberOfQuadsDrawn()==1 è giusto ke questo sia espresso in MockEngine.java ad esempio se sopra drawQuad(Point position, float width, float height,Texture texture, Rectangle textureRect) di scrive:
//@ ensures getNumberOfQuadsDrawn()==1
l'effetto è identico
comunque JML mi sembra proprio il caso vostro...
prima di tutto non si tratta del 99% dei test (ho dato un'occhiata ai test) e poi se MockEngine ha come rep invariant getNumberOfQuadsDrawn()==1 è giusto ke questo sia espresso in MockEngine.java ad esempio se sopra drawQuad(Point position, float width, float height,Texture texture, Rectangle textureRect) di scrive:
//@ ensures getNumberOfQuadsDrawn()==1
l'effetto è identico
MockEngine e' solo un Mock di un'interfaccia, non ha alcuna invarianza.
Riguardo alle postcondizioni, e' giusto che siano espresse separatamente dal codice di produzione, nei test, per non appesantire. Le invarianze invece possono essere espresse mediante assert all'interno del codice in maniera piu' compatta.
comunque JML mi sembra proprio il caso vostro...
Decisamente no, per cortesia, tieni questi commenti da principiante per te, sappiamo quello che stiamo facendo molto meglio di uno studentello alle prime armi con gli esami :)
MockEngine e' solo un Mock di un'interfaccia, non ha alcuna invarianza.
Riguardo alle postcondizioni, e' giusto che siano espresse separatamente dal codice di produzione, nei test, per non appesantire. Le invarianze invece possono essere espresse mediante assert all'interno del codice in maniera piu' compatta.
Decisamente no, per cortesia, tieni questi commenti da principiante per te, sappiamo quello che stiamo facendo molto meglio di uno studentello alle prime armi con gli esami :)
finiscila con gli insulti! si trattava di una discussione pacifica! comunque tu kiami maniera compatta quella? e poi per quale motivo mettere le post condizioni separate da codice? per farti cambiare schermata ogni 25 secondi? comunque per tua informazione tutte le classi hanno qualke invarianza e questo mi porta a pensare ke anke mockengine ne ha! poi JML supporta anke l'ereditarietà e quindi anke le condizioni vengono ereditate con un notevole risparmio di scritture! bastava mettere le condizioni comuni nell'interfaccia e poi quelle diverse aggiungerle alle varie classi! tutto molto + lineare e leggibile... comunque non sta a me quindi... arrangiatevi
Il 99% dei test non sono esprimibili in JML. Ad esempio le interazioni fra oggetti mediante mock.
questo te lo rimangi?
ps. sai quante cose sono esprimibili meglio con JML...
finiscila con gli insulti! si trattava di una discussione pacifica! comunque tu kiami maniera compatta quella? e poi per quale motivo mettere le post condizioni separate da codice? per farti cambiare schermata ogni 25 secondi? comunque per tua informazione tutte le classi hanno qualke invarianza e questo mi porta a pensare ke anke mockengine ne ha! poi JML supporta anke l'ereditarietà e quindi anke le condizioni vengono ereditate con un notevole risparmio di scritture! bastava mettere le condizioni comuni nell'interfaccia e poi quelle diverse aggiungerle alle varie classi! tutto molto + lineare e leggibile... comunque non sta a me quindi... arrangiatevi
Rilassati, non ti sta insultando nessuno; se pensi di sostituire lo unit testing con qualche dichiarazione in JML e' evidente che non sai di che cosa stai parlando, perche' sono due strumenti totalmente differenti. Fai il classico errore del principiante che legge qualcosa su un libro di testo, non ne ha alcuna esperienza e pensa di poterlo applicare a tutti gli ambiti anche quelli per i quali lo strumento non e' stato pensato.
Il 99% di quei test non e' esprimibile in JML come ho detto.
No, non ha ragione, e' vero l'esatto contrario. Per raggiungere alti livelli di affidabilita' del codice e produttivita' nella costruzione del codice e' molto meglio non documentare in linguaggio naturale, ma affidarsi ai test. E' proprio su progetti di grosse dimensioni che si nota il vantaggio, perche' appiattisce la curva dei costi. Non avendo tu mai partecipato ad un progetto commerciale di grosse dimensioni (diciamo milioni di linee di codice per due o tre anni di sviluppo), non puoi ovviamente apprezzare questo discorso
Se noti, avevo introdotto una distinzione tra software di grosse dimensioni e di dimensioni più modeste.
Su quelli di dimensioni "grosse" non voglio interferire, perché non è il mio campo, mi sembra che tu sia molto più competente.
Su quelli di dimensioni più modeste, a sviluppo veloce e senza specifiche, ormai ci navigo da anni, con clienti che non sanno cosa vogliono e dei quali devo interpretare le richieste.
E' un settore diverso, dove si può produrre, come dappertutto, buono o cattivo codice.
Lì posso dire la mia, e sarei quasi pronto a scommettere che mentre tu stai ancora a discutere sulle metodologie di sviluppo, di specifiche, test, ecc., loro apprezzerebbero il fatto che io il codice l'ho già consegnato, magari pieno di commenti (tanto non pesano, il compilatore li toglie ;)) ma pronto a funzionare.
Non è niente di personale, ma solo un esempio per dirti che i discorsi che stai facendo sono validi ma vanno rapportati alla realtà in cui sono inseriti.
Lì posso dire la mia, e sarei quasi pronto a scommettere che mentre tu stai ancora a discutere sulle metodologie di sviluppo, di specifiche, test, ecc., loro apprezzerebbero il fatto che io il codice l'ho già consegnato, magari pieno di commenti (tanto non pesano, il compilatore li toglie ;)) ma pronto a funzionare.
Credo che sarebbe vero l'esatto contrario :)
Io tendo ad essere molto pragmatico. Porto ancora Diamonds come esempio: niente documenti di specifiche, discussioni sulle metodologie o cose troppo complicate: al termine della prima iterazione di due settimane abbiamo gia' consegnato "la prima versione" al Customer. Il feedback del Cliente e' di primaria importanza per me, la prima cosa che faccio quando devo risolvere un problema e' scrivere la soluzione piu' semplice e veloce possibile, e poi la raffino con il feedback del cliente. Si chiama modello di sviluppo evolutivo e viene in contro esattamente al tuo problema, consegnare il piu' velocemente possibile il prodotto.
I commenti non pesano al compilatore, pesano a chi poi deve mantenere il tuo codice magari scritto male e poi pieno di commenti che lo offuscano ulteriormente. E' proprio questa mentalita' dello "scrivo codice di bassa qualita' velocemente e lo riempio di commenti pensando di risparmiare tempo e denaro" che relega lo sviluppo italiano nella mediocrita' e nella bassa produttivita'. Ci sono modi piu' veloci di produrre software, basta conoscerli e saperli usare.
E' proprio questa mentalita' dello "scrivo codice di bassa qualita' velocemente e lo riempio di commenti pensando di risparmiare tempo e denaro" che relega lo sviluppo italiano nella mediocrita' e nella bassa produttivita'. Ci sono modi piu' veloci di produrre software, basta conoscerli e saperli usare.
Secondo me il lavorare all'estero ti crea preconcetti.
Non è che l'inserimento di commenti equivale a codice di bassa qualità.
Inoltre, se ti adegui a quello che vuole il cliente (e non scrive) dove lo annoti?
Ti scrivi delle specifiche separate? Se già è difficile allineare i commenti all'evoluzione del codice, figurati le specifiche separate.
Siamo punto a capo, ma non voglio convincerti, ognuno proseguirà come meglio crede. Ma un codice scritto in modo leggibilissimo, come dici tu, sarà lampante sul suo modo di funzionare, non sul perché, a meno che tu non scrivi metodi del tipo:
controlloRilassatoSuRichiestaDelClienteCheNonVuoleBlocchiPerNatiPrima1980()
Puoi mettere un controlloNatiPrima1980(), ma tra due anni ti ricordi il perchè e chi ti ha chiesto di fare una simile modifica?
Parliamo sempre di progetti piccoli, non di progetti in cui le modifiche sono richieste in modo formale...
giuseppeS
05-01-2006, 00:54
No :)
Il C puo' essere interamente sostituito dal C++ in tutti gli ambiti e il C++ e' molto piu' espressivo. Quando il codice e' illeggibile lo si riscrive, sia a basso sia a alto livello, non c'e' differenza. La differenza puo' essere quando un pezzo di codice ha dei constraint prestazionali precisi e necessita una codifica magari poco leggibile per incontrare i requisiti: e' un caso piu' unico che raro che va preso singolarmente. In quel caso la soluzione che preferisco non e' un commento, ma avere due versioni del codice, una piu' leggibile e una meno. E' una duplicazione, ma quando un profile mi dice che e' necessaria, non possono farne a meno. Per fortuna e' un caso rarissimo (mi e' successo una volta sola in BW2 su centinaia di migliaia di righe di codice).
Hai mai provato ad utilizzare il C++ a livello kernel e allocare un oggetto (intendo quando funzioni come malloc ancora non esistono perchè non sono state definite da nessuno)?
Ho finito di leggere tutto (ce ne ho messo di tempo :| ), interessante ^^
k0nt3 (o qualcun altro tramite mail) potresti invitare il tuo prof a unirsi direttamente sul forum alla discussione, non sarebbe male :)
Io (che mi ritengo veramente n00b in programmazione) cerco di seguire quanto si fa in diamonds(ho provato anche a fare un task da solo e uno in pair programming, e in futuro penso di continuare la cosa) e anche se a volte per vari motivi non riesco a starci dietro tutti i giorni, quando faccio l'update del codice e mi studio un pò le modifiche fatte non è per niente difficile tornare a capire tutto e lo stato attuale del progetto. Potresti aggregarti pure tu, ci hai mai pensato? E' sempre un'esperienza in piu' sul campo che non fa' mai male e permette solo di imparare qualcosa che magari non si conosceva. E poi imho un'esperienza diretta vale molto di piu' che solo qualcosa semplicemente letto sui libri, ovviamente pero' serve anche qualcosa di teoria
p.s. non badate all'italiano, sono un pò addormentato a quest'ora ^^°°
p.p.s. io con il mio prof riguardo ai commenti e ai nomi esplicativi mi sono messo in guerra, lui li vuole in un modo, io glie li faccio in un altro (i commenti che faccio di solito sono solo i TODO)
cdimauro
05-01-2006, 09:10
questa frase è tutto un programma.. e secondo te se il codice è illeggibile quanto ci impiego a scrivere una patch? e se arriva un nuovo programmatore? come gli spiego tutto il codice? non è inefficiente?
Certo. E allora?
ps. si decisamente non hai studiato a stanford!
Ma a differenza di te ho studiato. :asd: E per di più non ho difficoltà di lettura (rileggiti il mio messaggio)... ;)
cdimauro
05-01-2006, 09:15
Il che è più o meno in linea con i punti che avevo detto prima, pausa caffè compresa.
E dire che sono (o dovrebbero essere) in tanti a lavorarci ;)
Non lavorano mica tutti alla stessa cosa. ;)
Per carità, una settimana è un buon tempo. Bisognerebbe vedere nella realtà quante righe di codice devono essere modificate. Se era una e ma la dicevano, patchavo il sorgente e ricompilavo. Se dava problemi, li avvisavo, se no, in attesa della patch ufficiale, mi ero già ritirato un po' su i calzoni :D
Se fosse stato linux....
Mi sembra un po' presto per dedurre qualcosa: non conosciamo quali modifiche comporta il fix per quel problema.
Hai mai provato ad utilizzare il C++ a livello kernel e allocare un oggetto (intendo quando funzioni come malloc ancora non esistono perchè non sono state definite da nessuno)?
esattamente! bisogna distinguere! a basso livello te lo puoi scordare di non documentare il codice! magari c'è anke bisogno un pezzo di asm... tu lo capisci con un'occhiata :D? invece ad alto livello la documentazione è pura questione di stile
Ho finito di leggere tutto (ce ne ho messo di tempo :| ), interessante ^^
k0nt3 (o qualcun altro tramite mail) potresti invitare il tuo prof a unirsi direttamente sul forum alla discussione, non sarebbe male
magari si inizierebbe a parlare di ingegneria del SW..
Io (che mi ritengo veramente n00b in programmazione) cerco di seguire quanto si fa in diamonds(ho provato anche a fare un task da solo e uno in pair programming, e in futuro penso di continuare la cosa) e anche se a volte per vari motivi non riesco a starci dietro tutti i giorni, quando faccio l'update del codice e mi studio un pò le modifiche fatte non è per niente difficile tornare a capire tutto e lo stato attuale del progetto. Potresti aggregarti pure tu, ci hai mai pensato? E' sempre un'esperienza in piu' sul campo che non fa' mai male e permette solo di imparare qualcosa che magari non si conosceva. E poi imho un'esperienza diretta vale molto di piu' che solo qualcosa semplicemente letto sui libri, ovviamente pero' serve anche qualcosa di teoria
tranquillo.. io con "grosso progetto" non intendevo diamonds! non credere ke non ho mai sviluppato niente in pratica! ho sviluppato 2 applicazioni x una azienda di medie dimensioni (ammetto ke ne ho avuto la possibilità x pura fortuna) e sono stati entusiasti del risultato (mi è bastata una javadoc minimale x non perdere il senso dell'orientamento e qualke caso di test x scovare qualke errore)!
ci ho pensato di aggregarmi a diamonds! nel senso ke mi prendevo l'incarico di gestire tutta la javadoc xkè mi fate pena!
forse se il progetto lo vedi crescere gradualmente non è difficile tornare allo stato attuale.. ma io ke mi sono trovato davanti 31 classi di test in una sola volta... mi è passata la voglia! comunque io sono sicuro ke fek da qualke parte sui suoi fogli di carta ha disegnato qualke diagramma! solo ke vuole far credere ke non servono!
infine sono straconvinto ke senza i capi questo progetto non va da nessuna parte! solo loro hanno la visione globale (anke delle cose ke devono ankora essere implementate)! questo non è proprio nell'ottica open..
Certo. E allora?
praticamente si era persa la cognizione del tempo a causa della confusione... capita di capire male.. si può perdonare? :(
cdimauro
05-01-2006, 09:56
in realtà si tratta migliorare la qualità del SW (udite udite esiste un metro di paragone) rispettando i seguenti punti:
- affidabilità
- efficienza
- facilità di comprensione e modifica
l'ho tratto dalla prima pagina dei miei appunti di ingSW! se qualkuno vuole contestare può farlo dicendo ke sia Barbara Liskov ke Carlo Ghezzi non sanno quello ke dicono :D
x il terzo punto è fondamentale la leggibilità del codice!
Posta un link al PDF o alle slide del corso in oggetto.
Hai mai provato ad utilizzare il C++ a livello kernel e allocare un oggetto (intendo quando funzioni come malloc ancora non esistono perchè non sono state definite da nessuno)?
Si', ho ridefinito l'operatore new di allocazione. Sapevi che si puo' fare vero? :)
cdimauro
05-01-2006, 10:05
Riferendomi alla falla in oggetto, ho l'impressione che quanto dice Attivissimo nell'ultimo articolo che ho linkato sia abbastanza allarmante:
Dando un'occhiata ai bollettini di sicurezza di Microsoft degli ultimi 16 mesi, ho visto che vulnerabilita' simili (esecuzione di codice arbitrario) relative a WMF sono piuttosto frequenti, quindi sono portato a pensare che questa componente non sia stata progettata adeguatamente e che nessuna patch, seppur preceduta dal necessario workaround, potra' porvi rimedio. :stordita:
Credo che Attivissimo dovrebbe imparare a leggere meglio i bollettini di sicurezza rilasciati da F-Secure, riportando le cose per come stanno: non esiste codice arbitrariamente eseguibile dentro i WMF, lascia intendere:
What exactly is going wrong with the WMF vulnerability?
Turns out this is not really a bug, it's just bad design. Design from another era.
When Windows Metafiles were designed in late 1980s, a feature was included that allowed the image files to contain actual code. This code would be executed via a callback in special situations. This was not a bug; this was something which was needed at the time.
The feature now in the limelight is known as the Escape() function and especially the SetAbortProc subfunction.
This function was designed to be called by Windows if a print job needed to be canceled during spooling.
This really means two things:
1) There are probably other vulnerable functions in WMF files in addition to SetAbortProc
2) This bug seems to affect all versions of Windows, starting from Windows 3.0 - shipped in 1990!
"The WMF vulnerability" probably affects more computers than any other security vulnerability, ever.
La parte in grassetto è mia: in particolare guarda la seconda frase che ho evidenziato. Riporto anche i link alle due funzioni:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/prntspol_0d6b.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/prntspol_0883.asp
Secondo me il lavorare all'estero ti crea preconcetti.
Non è che l'inserimento di commenti equivale a codice di bassa qualità.
Inoltre, se ti adegui a quello che vuole il cliente (e non scrive) dove lo annoti?
Ti scrivi delle specifiche separate? Se già è difficile allineare i commenti all'evoluzione del codice, figurati le specifiche separate.
Assolutamente no, e' l'aver lavorato sia in Italia sia all'estero mi fa capire come in Italia si sia letteralmente al terzo mondo. Molti commenti sono sintomo di codice di bassa qualita' , perche' se il codice fosse di alta qualita', leggibile e ben strutturato quei commenti non servirebbero. Ripeto: un commento e' un deodorante su una puzza nel codice che e' meglio semplicemente eliminare, invece di coprire.
Il cliente non deve neppure scrivere i requisiti, si siede in una stanza, prova l'applicazione che gli viene consegnata ogni due/tre settimane, dice che cosa cambiare e il Coach crea da li' la definizione dei requisiti nel dominio del problema. Da qui i test di accettazione che sono per definizione allineati al codice: se il codice si disallinea un test non passa, la build fallisce, c'e' feedback immediato sul problema e il codice viene sistemato.
Siamo punto a capo, ma non voglio convincerti, ognuno proseguirà come meglio crede. Ma un codice scritto in modo leggibilissimo, come dici tu, sarà lampante sul suo modo di funzionare, non sul perché, a meno che tu non scrivi metodi del tipo:
Il problema e' che non devi convincermi, sono ormai anni che i team di sviluppo migliori al mondo lavorano cosi', ed e' provata essere una famiglia di metodologie piu' produttiva delle vecchie metodologie insegnate ancora oggi all'Universita'.
Ti rimando al sito www.thoughtworks.com, e' una di queste aziende che pratica metodologie agili, c'e' molta documentazione, rilasciano anche parecchio software open source.
controlloRilassatoSuRichiestaDelClienteCheNonVuoleBlocchiPerNatiPrima1980()
Puoi mettere un controlloNatiPrima1980(), ma tra due anni ti ricordi il perchè e chi ti ha chiesto di fare una simile modifica?
Parliamo sempre di progetti piccoli, non di progetti in cui le modifiche sono richieste in modo formale...
Il nome di quel metodo e' troppo lungo perche' ha troppe responsabilita' (tutti i vari controlli). La soluzione non e' commentarlo, la soluzione e' rifattorizzarlo, ad esempio, a memoria ti posso consigliare il refactoring chiamato "Move conditionals to explicit language". Inoltre contiene il requisito e quel requisito va documentato in un acceptance test, non nel nome del metodo, che inoltre verifica che il requisito sia costantemente soddisfatto dal codice (un commento non puo' verificarlo). Infine, il perche' di un requisito fa parte delle decisioni economiche non delle decisioni ingegneristiche, quindi va documentato da cliente non nel codice.
forse se il progetto lo vedi crescere gradualmente non è difficile tornare allo stato attuale.. ma io ke mi sono trovato davanti 31 classi di test in una sola volta... mi è passata la voglia! comunque io sono sicuro ke fek da qualke parte sui suoi fogli di carta ha disegnato qualke diagramma! solo ke vuole far credere ke non servono!
Il problema e' tuo che non sei capace, non dei test. Nessun altro ha avuto questo problema :)
Non ho disegnato da nessuna parte nessun diagramma. Non ne abbiamo mai avuto bisogno perche' il design e' evolutivo, emerge dal refactoring. Come ti ha consigliato Cesare, prima studia, fai esperienza, e poi torna a parlare di Ingegneria del Software, cosi' sei solo una barzelletta, parli di cose che non sai.
Posta un link al PDF o alle slide del corso in oggetto.
purtroppo l'accesso alle slide è limitato agli studenti del corso e bisogna disporre di una matricola valida e codice di accesso... comunque non ho nessun problema a darvi la pagina in cui lo dice il server non è sempre attivo.. e vi kiedo gentilmente di non cominciare a netcattare tutte le porte! c'è già abbastanza gente ke rompe ogni giorno! grazie :D
purtroppo l'accesso alle slide è limitato agli studenti del corso e bisogna disporre di una matricola valida e codice di accesso... comunque non ho nessun problema a darvi la pagina in cui lo dice http://konte.dyndns.org:8001 il server non è sempre attivo.. e vi kiedo gentilmente di non cominciare a netcattare tutte le porte! c'è già abbastanza gente ke rompe ogni giorno! grazie :D
Si' si' certo, peccato che le lezioni universitarie siano pubbliche e l'accesso al materiale didattico non possa essere limitato per legge... che bla bla bla :)
giuseppeS
05-01-2006, 10:24
Si', ho ridefinito l'operatore new di allocazione. Sapevi che si puo' fare vero? :)
Prima ancora di scrivere la gestione della memoria usi new/malloc?
Si' si' certo, peccato che le lezioni universitarie siano pubbliche e l'accesso al materiale didattico non possa essere limitato per legge... che bla bla bla :)
allora vai su http://corsi.metid.polimi.it/ e registrati x ottenere l'accesso libero! comunque non ti assicuro ke riuscirai a vedere le slide.. ogni prof fa le sue scelte sui permessi! semmai ci riesci il corso è "Ingegneria del Software (Carlo Ghezzi)" poi vai in "materiale" e il pdf l'ho tratto dalla seconda slide!
Prima ancora di scrivere la gestione della memoria usi new/malloc?
Scrivi il gestore di memoria e poi fai l'overriding dell'operatore new degli oggetti che vuoi usino quell'allocatore di memoria.
Se vuoi modellare l'allocatore di memoria come una classe (non e' necessario), e vuoi crearlo dinamicamente con un new puoi usare la forma "in place" dell'operatore new per creare l'oggetto in una zona di memoria che fornisci esplicitamente. Gli strumenti per il system programming in C++ ci sono tutti, basta conoscerli :)
Puoi trovare degli esempi e una discussione qui:
http://www.gotw.ca/publications/mill15.htm
/ Example 1: Using in-place new, an "explicit constructor call"
//
void* p = ::operator new( sizeof(T) );
// grab a sufficient amount of raw memory
new (p) T; // construct the T at address p, probably calls
// ::operator new(std::size_t, void*) throw()
Nel tuo caso il puntatore p puo' essere fornito esplicitamente o arrivare dal tuo allocatore di memoria che puoi mappare su ::operator new (quello globale) o su una tua funzione.
allora vai su http://corsi.metid.polimi.it/ e registrati x ottenere l'accesso libero! comunque non ti assicuro ke riuscirai a vedere le slide.. ogni prof fa le sue scelte sui permessi! semmai ci riesci il corso è "Ingegneria del Software (Carlo Ghezzi)" poi vai in "materiale" e il pdf l'ho tratto dalla seconda slide!
Si' si'... bla bla bla
cdimauro
05-01-2006, 10:30
esattamente! bisogna distinguere! a basso livello te lo puoi scordare di non documentare il codice!
E perché mai? Tu hai mai lavorato a basso livello?
magari c'è anke bisogno un pezzo di asm... tu lo capisci con un'occhiata :D?
Dipende da chi l'ha scritto e da chi lo legge. ;)
Inoltre tu hai una concezione particolare del codice assembly, come qualcosa di oscuro e difficile. Il fatto che esistano degli assemblatori con una sintassi "poco comprensibile", non vuol dire che l'assembly sia relegato ad essere un linguaggio astruso.
Ad esempio, per quanto riguarda il 65C02, ho sviluppato un assemblatore con una sintassi più ad alto livello rispetto a quella "classica".
Fra questo, che è il "classico"
lda #$10
phx
tax
stz Pippo
beq Zero
e questo
type
ZeroFlag = z
begin
a := #$10
push x
x := a
Pippo := #0
if ZeroFlag goto Zero
end
noti qualche differenza? Hai difficoltà nel comprendere cosa faccia quel codice, pur non avendo mai visto l'ISA del 65C02?
invece ad alto livello la documentazione è pura questione di stile
Perfettamente d'accordo: è lo stile che fa la differenza per il codice di qualità. ;)
comunque io sono sicuro ke fek da qualke parte sui suoi fogli di carta ha disegnato qualke diagramma! solo ke vuole far credere ke non servono!
Che fek abbia o meno dei diagrammi ha poca importanza (ma sono ragionevolmente sicuro di no ;)): a me e a tutti gli altri non sono serviti. Non pensi che servirebbero più a noi, che CI LAVORIAMO?
praticamente si era persa la cognizione del tempo a causa della confusione... capita di capire male.. si può perdonare? :(
Certamente: riconoscere i propri errori è sempre una buona cosa. ;)
cdimauro
05-01-2006, 10:40
allora vai su http://corsi.metid.polimi.it/ e registrati x ottenere l'accesso libero! comunque non ti assicuro ke riuscirai a vedere le slide.. ogni prof fa le sue scelte sui permessi! semmai ci riesci il corso è "Ingegneria del Software (Carlo Ghezzi)" poi vai in "materiale" e il pdf l'ho tratto dalla seconda slide!
Il link che hai fornito è "morto", e non si trova altra documentazione.
Si' si'... bla bla bla
bla bla cosa? registrati se vuoi le slide! nessuno te lo vieta!
bla bla cosa? registrati se vuoi le slide! nessuno te lo vieta!
A casa mia chi fa un'affermazione deve portare le prove di cio' che dice, non devo essere io ad andarmele a cercare. Dubito fortemente che su quelle slide ci sia scritto che il codice vada commentato abbondantemente per aumentarne la leggibilita'. Chi lo scrivesse sarebbe un principiante e non credo che Ghezzi lo sia, anzi. Probabilmente ci sara' scritto il bisogno di fare design up front, scrivere la documentazione, una descrizione del modello Waterfall che ormai e' riconosciuto come non ottimale dal punto di vista produttivo, ma questo e' un altro discorso.
Ecco un ottimo libro che parla di Costruzione del Software, con accenni di Ingegneria del Software:
Code Complete 2 (http://www.cc2e.com/)
Il link che hai fornito è "morto", e non si trova altra documentazione.
ora funziona
SilverXXX
05-01-2006, 11:03
Non per rompere, ma anche alcuni dei miei prof mettono le slide su zone del sito NON PUBBLICHE
cdimauro
05-01-2006, 11:03
in realtà si tratta migliorare la qualità del SW (udite udite esiste un metro di paragone) rispettando i seguenti punti:
- affidabilità
- efficienza
- facilità di comprensione e modifica
l'ho tratto dalla prima pagina dei miei appunti di ingSW! se qualkuno vuole contestare può farlo dicendo ke sia Barbara Liskov ke Carlo Ghezzi non sanno quello ke dicono :D
x il terzo punto è fondamentale la leggibilità del codice!
Bene, ho scaricato la slide di cui parlavi. Ne riporto il contenuto:
Qualità: un elenco informale e intuitivo
Affidabilità
Efficienza
Facilità di comprensione e modifica
Direi che si commenta da sé...
Bene, ho scaricato la slide di cui parlavi. Ne riporto il contenuto:
Direi che si commenta da sé...
informale e intuitivo non vuol dire sbagliato e scorretto! non capisco cosa si commenta da sè!
L'ho detto io che ha fatica a comprendere il testo scritto :)
Nessuno ha mai detto che non si debba ricercare affidabilita', correttezza e leggibilita' nel codice, anzi, si contesta i metodi da principiante con i quali pensi di arrivare a questi obiettivi.
Artemisyu
05-01-2006, 11:11
Nessuno ha mai detto che non si debba ricercare affidabilita', correttezza e leggibilita' nel codice, anzi, si contesta i metodi da principiante con i quali pensi di arrivare a questi obiettivi.
Lui potrebbe contenstare i metodi eccessivamente da ingegnere del software che usi invece tu. :D
giuseppeS
05-01-2006, 11:12
esattamente! bisogna distinguere! a basso livello te lo puoi scordare di non documentare il codice! magari c'è anke bisogno un pezzo di asm... tu lo capisci con un'occhiata :D? invece ad alto livello la documentazione è pura questione di stile
Io non sono contrario ai commenti.
cdimauro
05-01-2006, 11:12
informale e intuitivo non vuol dire sbagliato e scorretto! non capisco cosa si commenta da sè!
fek ha perfettamente ragione: non riesci a capire proprio. :rolleyes:
NON ESISTONO METRI DI PARAGONE "INFORMALI" e "INTUIVI"!!! Diamine, ma non stiamo parlando di ingegneria del software? A questo punto perché non parliamo di Beautyful: tanto è la stessa cosa... :muro:
Credo che Attivissimo dovrebbe imparare a leggere meglio i bollettini di sicurezza rilasciati da F-Secure, riportando le cose per come stanno: non esiste codice arbitrariamente eseguibile dentro i WMF, lascia intendere:
La parte in grassetto è mia: in particolare guarda la seconda frase che ho evidenziato. Riporto anche i link alle due funzioni:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/prntspol_0d6b.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/prntspol_0883.asp
Attivissimo riporta esattamente cio' che dice F-Secure, ovvero che si tratta di scelte di progettazione, che risalgono a molti anni fa, fatte proprio per interrompere la stampa dell'immagine durante lo spooling.
Io ho solo notato che falle in tale formato sono ricorrenti e che consentono di eseguire codice remoto, come dice la stessa Microsoft in un bollettino nel quale rendeva disponibile anche il relativo aggiornamento:
A remote code execution vulnerability exists in the rendering of Windows Metafile (WMF) image format that could allow remote code execution on an affected system. Any program that renders WMF images on the affected systems could be vulnerable to this attack. An attacker who successfully exploited this vulnerability could take complete control of an affected system.
Da: http://www.microsoft.com/technet/security/Bulletin/MS05-053.mspx
Ciao
cdimauro
05-01-2006, 11:13
Io non sono contrario ai commenti.
Nemmeno io, SE e QUANDO è il caso di usarli. ;)
Lui potrebbe contenstare i metodi eccessivamente da ingegnere del software che usi invece tu. :D
Difficile, visto che tendo ad essere molto pragmatico :)
Ogni pratica che uso mira sempre e solo a risparmiare tempo e aumentare la produttivita' nel breve e nel lungo periodo, e lo faccio solo se e' provato che raggiunge questi obiettivi.
Contestarle significa voler scrivere codice volutamente in maniera meno produttiva.
Artemisyu
05-01-2006, 11:16
Nemmeno io, SE e QUANDO è il caso di usarli. ;)
Quello che non capisco è perchè non usare i commenti anche quando sarebbero ridondanti?
Tanto il compilatore gli ignora, chissenefrega se ci sono un paio di commenti in più no? che male fanno?
forse non avete capito...
NON HO MAI DETTO DOCUMENTAZIONE=COMMENTI
non si sà mai... magari se lo scrivo grande e grosso lo capite! i commenti solo dove servono! cioè molti nel codice di basso livello xkè lì si tende a privilegiare l'efficienza a danno della leggibilità del codice!
la documentazione è indice di qualità punto.
giuseppeS
05-01-2006, 11:20
Scrivi il gestore di memoria e poi fai l'overriding dell'operatore new degli oggetti che vuoi usino quell'allocatore di memoria.
Se vuoi modellare l'allocatore di memoria come una classe (non e' necessario), e vuoi crearlo dinamicamente con un new puoi usare la forma "in place" dell'operatore new per creare l'oggetto in una zona di memoria che fornisci esplicitamente. Gli strumenti per il system programming in C++ ci sono tutti, basta conoscerli :)
Non ho detto che non puoi ridefinire new, ma fino a quando non hai una gestione della memoria decente è molto più semplice usare il C del C++, a meno di non trovare soluzioni poco eleganti, come una malloc da usare prima di avere la gestione della memoria.
Nemmeno io, SE e QUANDO è il caso di usarli. ;)
Esatto, ovvero molto raramente e solo quando il codice non puo' in alcun modo esprimere quel concetto (ovvero raramente) ;)
Difficile, visto che tendo ad essere molto pragmatico :)
Ogni pratica che uso mira sempre e solo a risparmiare tempo e aumentare la produttivita' nel breve e nel lungo periodo, e lo faccio solo se e' provato che raggiunge questi obiettivi.
Contestarle significa voler scrivere codice volutamente in maniera meno produttiva.
ahah! non so se tutti si sono accorti qui... ma abbiamo davanti dio! cosa aspettiamo a prendere nota delle sue parole x scrivere un vangelo?
i suoi metodi è dimostrato ke sono i migliori in qualsiasi campo! e probabilmente è dimostrato anke ke lui è più intelligente di tutti gli altri! wow
Artemisyu
05-01-2006, 11:22
Difficile, visto che tendo ad essere molto pragmatico :)
Ogni pratica che uso mira sempre e solo a risparmiare tempo e aumentare la produttivita' nel breve e nel lungo periodo, e lo faccio solo se e' provato che raggiunge questi obiettivi.
Contestarle significa voler scrivere codice volutamente in maniera meno produttiva.
Secondo me sei troppo estremo.
Essere produttivi quando si scrive codice significa non scrivere tre volte la stessa funzione o non usare 10 variabili quando se ne possono usare due.
Ma se si tratta di buttare dentro qualche commento, che immane differenza produttiva fa?
A questo punto immagino di non poter nemmeno sgranchirmi il collo. Probabilmente eviterei di scrivere in quel frangente, evitanto di essere sufficientemente produttivo.
Siamo uomini, non macchine. Il pragmatismo ha un limite.
Credo che la norma che regolamenta i commenti debba essere "mettere sempre i commenti quando servono, e mettere dei commenti riassuntivi all'inizio di ogni ciclo"
Semplicistico? forse, anzi, sicuramente.
Ma dannatamente pratico.
E soprattutto evita di perdere tempo a pensare quando mettere i commenti e quando no, permettendo quindi di programmare.
ci ho pensato di aggregarmi a diamonds! nel senso ke mi prendevo l'incarico di gestire tutta la javadoc xkè mi fate pena!
Sei benvenuto. Mi farebbe piacere averti nel team.
comunque io sono sicuro ke fek da qualke parte sui suoi fogli di carta ha disegnato qualke diagramma! solo ke vuole far credere ke non servono!
Io personalmente non ho neanche uno schizzo che riguarda Diamond e conoscendo fek l'unica cosa che ha accanto al PC sono postit della sua ragazza che gli dice di dare l'aspirapolvere nella sua stanza :D
infine sono straconvinto ke senza i capi questo progetto non va da nessuna parte! solo loro hanno la visione globale (anke delle cose ke devono ankora essere implementate)! questo non è proprio nell'ottica open
Io aiuto fek a gestire il team ma avendo esperienza zero in fatto di giochi e gestione di un team non ho la più pallida idea di dove andremmo. Per quanto riguarda le parti ancora da implementare ti assicuro che non le conosciamo neanche noi perché ancora non lo sa neanche il customer.
In ogni caso vorrei sapere perché il nostro modello non è nell'otica open?
ciao ;)
giuseppeS
05-01-2006, 11:24
Nemmeno io, SE e QUANDO è il caso di usarli. ;)
Pure io sono del parere che commenti come:
a = b + c; //Sommo B e C in A
sono da evitare, anche perchè il codice è più chiaro da leggere del commento lì :)
Artemisyu
05-01-2006, 11:26
ahah! non so se tutti si sono accorti qui... ma abbiamo davanti dio! cosa aspettiamo a prendere nota delle sue parole x scrivere un vangelo?
i suoi metodi è dimostrato ke sono i migliori in qualsiasi campo! e probabilmente è dimostrato anke ke lui è più intelligente di tutti gli altri! wow
Capisco il sarcasmo.
In effetti leggendo la discussione e leggendo gli interventi di cdmauro e di fek viene da chiedersi se effettivamente programmino qualcosa, nella loro vita.
Probabilmente pianificano e gestiscono i commenti e la documentazione al codice, oppure riscrivono 650 volte lo stesso ciclo in modo che sia il più elegente possibile.
Dammi retta k0nt3: visto che tu ancora mi sembri una di quelle persone interessare a sviluppare e non a pianificare l'aria fritta, pensa a programmare, che fai sempre bene :)
Non ho detto che non puoi ridefinire new, ma fino a quando non hai una gestione della memoria decente è molto più semplice usare il C del C++, a meno di non trovare soluzioni poco eleganti, come una malloc da usare prima di avere la gestione della memoria.
Scrivi il gestore di memoria in C++, dov'e' il problema?
Il C++ non ti chiama mai la malloc se tu non vuoi, scrivi il gestore di memoria, poi ridefinisci gli operatori, l'ho fatto decine di volte, e' banale :)
cdimauro
05-01-2006, 11:28
Attivissimo riporta esattamente cio' che dice F-Secure, ovvero che si tratta di scelte di progettazione, che risalgono a molti anni fa, fatte proprio per interrompere la stampa dell'immagine durante lo spooling.
Certo, ma è diverso dal dire che i WMF contengono del codice eseguibile.
Il problema è sempre lo stesso. Rispondo sotto.
Io ho solo notato che falle in tale formato sono ricorrenti e che consentono di eseguire codice remoto, come dice la stessa Microsoft in un bollettino nel quale rendeva disponibile anche il relativo aggiornamento:
Da: http://www.microsoft.com/technet/security/Bulletin/MS05-053.mspx
Ciao
Ecco cosa c'è scritto nell'intestazione del link che hai riportato:
"Vulnerabilities in Graphics Rendering Engine Could Allow Code Execution (896424)"
E' la solita storia, insomma: un exploit che può essere sfruttato per eseguire codice arbitrario.
Capisco il sarcasmo.
In effetti leggendo la discussione e leggendo gli interventi di cdmauro e di fek viene da chiedersi se effettivamente programmino qualcosa, nella loro vita.
Probabilmente pianificano e gestiscono i commenti e la documentazione al codice, oppure riscrivono 650 volte lo stesso ciclo in modo che sia il più elegente possibile.
Ma allora anche tu non leggi quello che la gente scrive :)
Io non scrivo documentazione ridondante, solo codice. Scrivo il codice piu' semplice per una soluzione. Non pianifico MAI il codice prima di scriverlo (si chiama design up front).
E se ti domandi se programmo qualcosa o no, ho pubblicato tre titoli in carriera, ho dieci anni di esperienza professionale alle spalle, diciamo che qualcosa ho fatto e non e' certo documentazione :)
ahah! non so se tutti si sono accorti qui... ma abbiamo davanti dio! cosa aspettiamo a prendere nota delle sue parole x scrivere un vangelo?
i suoi metodi è dimostrato ke sono i migliori in qualsiasi campo! e probabilmente è dimostrato anke ke lui è più intelligente di tutti gli altri! wow
Non buttarla di nuovo sul personale perche' non sai cosa dire :)
Purtroppo non ho inventato io le metodologie agili, mi sarebbe piaciuto ma non ne avevo certamente l'esperienza. Mi limito a descrivere metodologie sviluppate da altri (che tu non conosci per altro).
Capisco il sarcasmo.
In effetti leggendo la discussione e leggendo gli interventi di cdmauro e di fek viene da chiedersi se effettivamente programmino qualcosa, nella loro vita.
Probabilmente pianificano e gestiscono i commenti e la documentazione al codice, oppure riscrivono 650 volte lo stesso ciclo in modo che sia il più elegente possibile.
Dammi retta k0nt3: visto che tu ancora mi sembri una di quelle persone interessare a sviluppare e non a pianificare l'aria fritta, pensa a programmare, che fai sempre bene :)
tranquillo io ho la passione da quando avevo 9 anni! ho addirittura programmato un motore3d da solo (e da zero leggendo kilometri di documentazione) in openGL e c++ mettendoci quasi 2 anni al tempo delle superiori! di sicuro il codice non era di alto livello ma mi ha permesso di capire un sacco di cose (ke non si insegnano all'università)! dopo ke ho fatto questi errori posso dire ke la documentazione è qualkosa di vitale e determinante ai fini della comprensione e manutenzione del SW! e soprattutto ho capito ke pensare allo skeletro della nostra applicazione prima di iniziare a implementarla ci fa risparmiare tempo, xkè riskio di meno di arrivare a ostacoli progettuali a cui non avevo pensato! mi sa ke voi perdete un sacco di tempo con il refactoring quando avreste potuto usarlo x progettare!
Artemisyu
05-01-2006, 11:36
Ma allora anche tu non leggi quello che la gente scrive :)
Io non scrivo documentazione ridondante, solo codice. Scrivo il codice piu' semplice per una soluzione. Non pianifico MAI il codice prima di scriverlo (si chiama design up front).
E se ti domandi se programmo qualcosa o no, ho pubblicato tre titoli in carriera, ho dieci anni di esperienza professionale alle spalle, diciamo che qualcosa ho fatto e non e' certo documentazione :)
Stavo sfogliacchiando... dai ti concedo che un po' di C lo sai ;)
Volevo solo far notare comprendo le uscite di k0nt3, perchè a leggervi in queste discussioni, forse non ve ne siete accorti nemmeno voi, ma effettivamente è tutto un cercare un pelo nell'uovo inutile, e, nella maggiorparte dei casi, anche dannoso.
sinceramente sta discussione tira un fucilata nelle palle non indifferente.
Secondo me sei troppo estremo.
Essere produttivi quando si scrive codice significa non scrivere tre volte la stessa funzione o non usare 10 variabili quando se ne possono usare due.
No, essere produttivi significa scrivere il codice piu' semplice possibile che risolve un problema, nel minor tempo possibile.
Ma se si tratta di buttare dentro qualche commento, che immane differenza produttiva fa?
La differenza che fa e' che nel 99% dei casi butti quel commento perche' il codice no ne' abbastanza chiaro nell'esprimere un concetto. La soluzione non e' mettere un commento per chiarirlo, la soluzione e' riscrivere il codice per renderlo piu' chiaro (l'ho scritto cento volte, incredibile che ancora non lo si sia capito :)).
Nel momento in cui il codice e' chiaro e ben strutturato il commento non farebbe altro che ripetere le stesse cose in linguaggio naturale e quindi ambiguo. Ovvero non solo perdi tempo a scrivere qualcosa che e' gia' stato detto dal codice, ma chiunque legge il tuo codice deve prima leggere il commento, poi la stessa informazione nel codice stesso, perdendo del tempo. Chiunque poi debba cambiare il tuo codice sara' costretto a cambiare il codice stesso e poi ad aggiornare il commento per riflettere cio' che il codice gia' dice. Doppia perdita di tempo. Ma se chi cambia il tuo codice sa programmare toglie il commento ridondante.
Credo che la norma che regolamenta i commenti debba essere "mettere sempre i commenti quando servono, e mettere dei commenti riassuntivi all'inizio di ogni ciclo"
La norma dev'essere: "Quando senti il bisogno di scrivere un commento, scrivi un metodo al suo posto".
Semplicistico? forse, anzi, sicuramente.
No. Errato. Non penso mai a quando mettere i commenti, non li metto e scrivo codice pulito e chiaro. Ancora piu' pratico.
Certo, ma è diverso dal dire che i WMF contengono del codice eseguibile.
Il problema è sempre lo stesso. Rispondo sotto.
Ecco cosa c'è scritto nell'intestazione del link che hai riportato:
"Vulnerabilities in Graphics Rendering Engine Could Allow Code Execution (896424)"
E' la solita storia, insomma: un exploit che può essere sfruttato per eseguire codice arbitrario.
non mi pare ke qualk1 ha detto ke i wmf contengono eseguibili! era sottointeso ke il codice eseguibile veniva iniettato sfruttando l'ennesimo bug!
Stavo sfogliacchiando... dai ti concedo che un po' di C lo sai ;)
Umano :)
Volevo solo far notare comprendo le uscite di k0nt3, perchè a leggervi in queste discussioni, forse non ve ne siete accorti nemmeno voi, ma effettivamente è tutto un cercare un pelo nell'uovo inutile, e, nella maggiorparte dei casi, anche dannoso.
Si', e' fastidioso quando spara una fesseria, gliela si fa notare e poi inizia a cercare il pelo nell'uovo (senza trovarlo) per riprendersi. Quando poi e' con le spalle al muro la butta sul personale....
sinceramente sta discussione tira un fucilata nelle palle non indifferente.
... diventa una fucilata nelle palle. Pero' va detto che fra il tremendo OT qualche concetto interessante e' uscito.
Si', e' fastidioso quando spara una fesseria, gliela si fa notare e poi inizia a cercare il pelo nell'uovo (senza trovarlo) per riprendersi. Quando poi e' con le spalle al muro la butta sul personale....
mi fa piacere leggere la tua descrizione riferita a me! adesso mi sento dio come te!
e soprattutto ho capito ke pensare allo skeletro della nostra applicazione prima di iniziare a implementarla ci fa risparmiare tempo, xkè riskio di meno di arrivare a ostacoli progettuali a cui non avevo pensato! mi sa ke voi perdete un sacco di tempo con il refactoring quando avreste potuto usarlo x progettare!
Ed hai capito molto male, e' vero l'esatto contrario :)
http://www.martinfowler.com/articles/designDead.html
Now the planned design approach has been around since the 70s, and lots of people have used it. It is better in many ways than code and fix evolutionary design. But it has some faults. The first fault is that it's impossible to think through all the issues that you need to deal with when you are programming. So it's inevitable that when programming you will find things that question the design. However if the designers are done, moved onto another project, what happens? The programmers start coding around the design and entropy sets in. Even if the designer isn't gone, it takes time to sort out the design issues, change the drawings, and then alter the code. There's usually a quicker fix and time pressure. Hence entropy (again).
...
The fundamental assumption underlying XP is that it is possible to flatten the change curve enough to make evolutionary design work. This flattening is both enabled by XP and exploited by XP. This is part of the coupling of the XP practices: specifically you can't do those parts of XP that exploit the flattened curve without doing those things that enable the flattening. This is a common source of the controversy over XP. Many people criticize the exploitation without understanding the enabling. Often the criticisms stem from critics' own experience where they didn't do the enabling practices that allow the exploiting practices to work. As a result they got burned and when they see XP they remember the fire.
Hai ancora tanto da imparare :)
Il cliente non deve neppure scrivere i requisiti, si siede in una stanza, prova l'applicazione che gli viene consegnata ogni due/tre settimane, dice che cosa cambiare e il Coach crea da li' la definizione dei requisiti nel dominio del problema. Da qui i test di accettazione che sono per definizione allineati al codice: se il codice si disallinea un test non passa, la build fallisce, c'e' feedback immediato sul problema e il codice viene sistemato.
...
....
Infine, il perche' di un requisito fa parte delle decisioni economiche non delle decisioni ingegneristiche, quindi va documentato da cliente non nel codice.
Con queste risposte hai dimostrato di non comprendere cosa significa lavorare con piccoli clienti che ti commissionano programmi ad uso interno per ottimizzare qualche processo, ma senza avere impatto diretto nella loro organizzazione. Sono contento per te, hai un target più elevato che può permetterti di fare dell'informatica pura.
L'avevo specificato che facevo considerazioni sulle piccole realtà, ma sembra che per te non esistano, dato che hai dipinto uno scenario utopistico; nelle piccole realtà quello che dici non sta in piedi.
Visto che tu stai parlando di informatica strutturata a livello aziendale (open o closed source poco conta), mi tiro fuori ;)
a fek: è difficile ke uno ke lavora alla ThoughtWorks dica il contrario! x piacere non postare + link palesemente di parte, ne ho la nausea!
Artemisyu
05-01-2006, 11:45
No. Errato. Non penso mai a quando mettere i commenti, non li metto e scrivo codice pulito e chiaro. Ancora piu' pratico.
Non è errato.
Tu pressuponi che sono fenomeni e semi fenomeni della programmazione possano avere in mano il codice e capirlo.
Esiste anche chi ha bisogno dei commenti.
Prima o poi l'azienda per cui lavori assumerà un softwarista che dovrà mettere mano anche al tuo codice.
Se non è bravo come te e non ha la comprensione immediata del codice che hai tu il codice non gli dirà proprio nulla.
Sarebbero i commenti a doverglielo dire.
Sarà che sono particolamente sensibile ai commenti perchè sono tanto scemo che devo commentare il codice che scrivo perchè se poi lo rileggo non capisco nemmeno io quello che c'è scritto.
E l'ho scritto io. :(
giuseppeS
05-01-2006, 11:46
Scrivi il gestore di memoria in C++, dov'e' il problema?
Il C++ non ti chiama mai la malloc se tu non vuoi, scrivi il gestore di memoria, poi ridefinisci gli operatori, l'ho fatto decine di volte, e' banale :)
Il problema sta nello scrivere il gestore della memoria in C++ (intendo utilizzando qualche classe e non metodi statici):)
Non è errato.
Tu pressuponi che sono fenomeni e semi fenomeni della programmazione possano avere in mano il codice e capirlo.
Esiste anche chi ha bisogno dei commenti.
Prima o poi l'azienda per cui lavori assumerà un softwarista che dovrà mettere mano anche al tuo codice.
Se non è bravo come te e non ha la comprensione immediata del codice che hai tu il codice non gli dirà proprio nulla.
Sarebbero i commenti a doverglielo dire.
Sarà che sono particolamente sensibile ai commenti perchè sono tanto scemo che devo commentare il codice che scrivo perchè se poi lo rileggo non capisco nemmeno io quello che c'è scritto.
E l'ho scritto io. :(
più ke altro lo stile di programmazione è personale! quello ke tu capisci subito io non lo capisco e viceversa! documentare significa permettera a tutti di capire subito! spero ke non ti sostituiscono nel progetto xkè sarebbe un disastro secondo me!
Con queste risposte hai dimostrato di non comprendere cosa significa lavorare con piccoli clienti che ti commissionano programmi ad uso interno per ottimizzare qualche processo, ma senza avere impatto diretto nella loro organizzazione. Sono contento per te, hai un target più elevato che può permetterti di fare dell'informatica pura.
L'avevo specificato che facevo considerazioni sulle piccole realtà, ma sembra che per te non esistano, dato che hai dipinto uno scenario utopistico; nelle piccole realtà quello che dici non sta in piedi.
Curioso visto che l'ho fatto per anni e lo faccio tutt'ora :)
Visto che tu stai parlando di informatica strutturata a livello aziendale (open o closed source poco conta), mi tiro fuori ;)
No, sto parlando di costruzione del software a qualunque livello. Anche per scrivere un'applicazione da due giorni e' molto piu' produttivo usare determinate pratiche.
SilverXXX
05-01-2006, 11:51
Non è errato.
Tu pressuponi che sono fenomeni e semi fenomeni della programmazione possano avere in mano il codice e capirlo.
Esiste anche chi ha bisogno dei commenti.
Prima o poi l'azienda per cui lavori assumerà un softwarista che dovrà mettere mano anche al tuo codice.
Se non è bravo come te e non ha la comprensione immediata del codice che hai tu il codice non gli dirà proprio nulla.
Sarebbero i commenti a doverglielo dire.
Sarà che sono particolamente sensibile ai commenti perchè sono tanto scemo che devo commentare il codice che scrivo perchè se poi lo rileggo non capisco nemmeno io quello che c'è scritto.
E l'ho scritto io. :(
è vero, c'è un sacco di gente che programma e non dovrebbe, e PEGGIO c'è un sacoc di gente che usa il computer e non dovrebbe :(
Il problema sta nello scrivere il gestore della memoria in C++ (intendo utilizzando qualche classe e non metodi statici):)
Usa metodi statici, dov'e' il problema, fanno parte della definizione del C++ :)
Non è errato.
Tu pressuponi che sono fenomeni e semi fenomeni della programmazione possano avere in mano il codice e capirlo.
Assolutamente no, ho anche raccontato di come spesso do' in mano il mio codice a non programmatori per vedere se riescono a comprendere quello che ho scritto e se non lo comprendono lo riscrivo.
Proprio Diamonds e' una dimostrazione di come con le giuste pratiche e metodologie un gruppo di ragazzi alle prime armi possa scrivere codice di qualita' estremamente alta e con livelli di produttivita' altissimi. Conservo un po' di metriche su Diamonds e questi ragazzi scrivono codice a ritmi di un team di sviluppo chiuso nello stesso ufficio, pur essendo sparsi per l'Europa e lavorando solo nel tempo libero.
A me piacciono le dimostrazioni pratiche e Diamonds lo e' :)
Esiste anche chi ha bisogno dei commenti.
Prima o poi l'azienda per cui lavori assumerà un softwarista che dovrà mettere mano anche al tuo codice.
Tutti quelli che mettono mano al mio codice di solito non fanno fatica a leggerlo e a modificarlo, proprio perche' invece di commentare mi concentro sulla qualita' del codice stesso.
Se non è bravo come te e non ha la comprensione immediata del codice che hai tu il codice non gli dirà proprio nulla.
Sarebbero i commenti a doverglielo dire.
Io non sono affatto bravo, anzi. Sono il primo a dover scrivere codice leggibile altrimenti non lo capisco io :)
Apri Diamonds, scaricati il codice e leggilo. Dicci pure quale metodo non e' chiaro e lo riscriveremo.
Sarà che sono particolamente sensibile ai commenti perchè sono tanto scemo che devo commentare il codice che scrivo perchè se poi lo rileggo non capisco nemmeno io quello che c'è scritto.
E' un segnale che devi riscrivere quel codice per renderlo piu' chiaro, non commentarlo. Quando puzzi che cosa fai, ti lavi o ti copri di deodorante? ;)
Con queste risposte hai dimostrato di non comprendere cosa significa lavorare con piccoli clienti che ti commissionano programmi ad uso interno per ottimizzare qualche processo, ma senza avere impatto diretto nella loro organizzazione. Sono contento per te, hai un target più elevato che può permetterti di fare dell'informatica pura.
L'avevo specificato che facevo considerazioni sulle piccole realtà, ma sembra che per te non esistano, dato che hai dipinto uno scenario utopistico; nelle piccole realtà quello che dici non sta in piedi.
Visto che tu stai parlando di informatica strutturata a livello aziendale (open o closed source poco conta), mi tiro fuori ;)
Al contrario uno sviluppo evolutivo è l'ideale per le piccole realtà. Ho fatto due o tre programmini stupidi per alcune persone qui della zona e se avessi usato questo metodo avrei fatto senza dubbio prima. Se il committente non è del settore non sa di preciso quello che vuole ma sopratutto non sa come spiegartelo.
Se dopo una o due settimane gli fai vedere il progettino abbozzato ti saprà di sicuro dire con più precisione in che direzione ti devi muovere. Poi ritorni ad intervalli regolari. Se usi Waterfall dopo 6 mesi di progetto e sviluppo ti presenti con il progetto finito cosa succede se non avevi capito bene quello che voleva? Probabilmente ti becchi altri 6 mesi di progetto e sviluppo per rifare tutto a spese _tue_. Il primo errore da non commettere in questo lavoro è sparire e ripresentarsi dopo mesi con il prodotto finito.
ciao ;)
a fek: è difficile ke uno ke lavora alla ThoughtWorks dica il contrario! x piacere non postare + link palesemente di parte, ne ho la nausea!
Ne hai la nausea perche' non li comprendi. Puoi anche leggere quello che dice Kent Beck se vuoi (non lavora in ThoughtWorks). Oppure quello che dice Ward Cunningham (lavora su Eclipse, e' quello che ha inventato i wiki).
Much as in the role of design itself, I don't think it's the case that XP does not value experience or good design skills. Indeed many of the proponents of XP - Kent Beck, Bob Martin, and of course Ward Cunningham - are those from whom I have learned much about what design is about. However it does mean that their role changes from what a lot of people see as a role of technical leadership.
In realta' devi solo leggere e studiare, perche' hai tanto da imparare :)
cdimauro
05-01-2006, 12:01
magari se lo scrivo grande e grosso lo capite! i commenti solo dove servono! cioè molti nel codice di basso livello xkè lì si tende a privilegiare l'efficienza a danno della leggibilità del codice!
Il mio messaggio l'hai letto o hai fatto finta di non vederlo? Mi sai dire di quale commento avrebbe bisogno quel pezzo di codice assembly che ho scritto?
Tu non nemmeno sai cosa voglia dire programmare; tanto meno farlo a basso livello.
Sarà che sono particolamente sensibile ai commenti perchè sono tanto scemo che devo commentare il codice che scrivo perchè se poi lo rileggo non capisco nemmeno io quello che c'è scritto.
E l'ho scritto io. :(
Guarda che non sei l'unico.
Le poche volte che non commento, pur utilizzando le regole di scrittura classiche alla Fek (nomi chiari, struttura ordinata, ecc.), mi ritrovo a dover metterci delle mezz'ore, se non di più, a riavvolgere l'ordine di esecuzione per capire il significato, nel contesto, di un certo metodo. E non ti parlo della riga di codice, ma proprio del metodo.
Quando ci metto 2 righe (non tante) di riassuntino, vedo subito se è il caso di passare oltre.
Mettiamola così: invidiamo fek per l'alto livello del codice da lui prodotto, al quale noi programmatori di provincia dovremmo conformarci.
Guarda che non sei l'unico.
Le poche volte che non commento, pur utilizzando le regole di scrittura classiche alla Fek (nomi chiari, struttura ordinata, ecc.), mi ritrovo a dover metterci delle mezz'ore, se non di più, a riavvolgere l'ordine di esecuzione per capire il significato, nel contesto, di un certo metodo. E non ti parlo della riga di codice, ma proprio del metodo.
Quando ci metto 2 righe (non tante) di riassuntino, vedo subito se è il caso di passare oltre.
Mettiamola così: invidiamo fek per l'alto livello del codice da lui prodotto, al quale noi programmatori di provincia dovremmo conformarci.
Non invidiare me, invidia le pratiche che uso. Come ho detto gia' molte volte, i ragazzi che lavorano in Diamonds sono tutti alle prime armi, qualcuno sta imparando a programmare proprio su Diamonds stesso. Guarda il codice, non ha bisogno di commenti, saranno tutti dei fenomeni? Probabilmente si', ma probabilmente usano anche pratiche e metodologie corrette di sviluppo.
Le chiacchiere stanno davvero a zero, scarica il codice di Diamonds, e' open source ( :) ), e guardarlo. E' la dimostrazione pratica di quello che ho scritto qui.
Visto che alla fine parliamo di metodologie agili (cosi' siamo anche tornati IT), ecco il link all'Agile Movment Italiano, faccio un favore a Marco Abis:
http://www.agilemovement.it/
Stiamo portando alla luce modi migliori di sviluppare software facendolo in prima persona ed aiutando altri a farlo. Con questo lavoro siamo giunti a questi valori:
Persone ed interazione più che processi e tools;
Software che funziona più che documentazione esaustiva;
Collaborazione con il cliente più che negoziazione contrattuale;
Rispondere al cambiamento più che il seguire un piano prestabilito;
Artemisyu
05-01-2006, 12:10
è vero, c'è un sacco di gente che programma e non dovrebbe, e PEGGIO c'è un sacoc di gente che usa il computer e non dovrebbe :(
Sia chiaro.
Io non infetto il mondo con il mio pessimo codice.
Diciamo che mi esercito... i miei programmi non escono dal mio hd :D
Quando ci metto 2 righe (non tante) di riassuntino, vedo subito se è il caso di passare oltre.
Mettiamola così: invidiamo fek per l'alto livello del codice da lui prodotto, al quale noi programmatori di provincia dovremmo conformarci.
Supponi di dover debuggare quel codice. Cosa succede se il commento è errato? Se leggendo quel commento, errato, decidi di saltare quel pezzo di codice perché tanto l'errore non può sicuramente essere li se il commento mi dice questo.
ciao ;)
Al contrario uno sviluppo evolutivo è l'ideale per le piccole realtà. Ho fatto due o tre programmini stupidi per alcune persone qui della zona e se avessi usato questo metodo avrei fatto senza dubbio prima. Se il committente non è del settore non sa di preciso quello che vuole ma sopratutto non sa come spiegartelo.
Non vi sto contestando il modello evolutivo, ma l'approccio.
Che devi sentire costantemente il cliente sono d'accordo, ma non so cosa vi facciate pagare voi e quanto tempo ci mettiate.
Fatta l'analisi del problema, le specifiche sono solitamente sommarie, e non c'è nessuno che te le scrive "a parte". Devi scrivertele da solo, e il posto migliore è il commento nel codice.
Perché al cliente, non gliene frega niente che alla fine gli consegni le specifiche (ma semmai un manuale d'uso). E allora, visto che dovete fare da soli (o vi potete permettere uno che gestisca solo le specifiche) mi venite a dire che scrivete ottimamente le specifiche esterne in parallelo (di cui al cliente non frega niente), quando asserite che il commento interno sarebbe non allineato ?
Fek sta dicendo questo: se il cliente varia la richiesta, la documento a parte.
Teoricamente giusto, praticamente sbagliato. Ti telefona per dirti che una certa cosa sarebbe meglio farla in un altro modo, cosa gli rispondi:
1) me lo dica quando ci vediamo tra 2 settimane?
2) mo' me lo marco, sospendo la scrittura del codice, lo aggiungo nelle specifiche, gliele mando per vedere se l'interpretazione della richiesta è corretta, aspetto il via libera e ritorno sul codice
3) Fai una nota nel codice e vai avanti ?
Sia chiaro.
Io non infetto il mondo con il mio pessimo codice.
Diciamo che mi esercito... i miei programmi non escono dal mio hd :D
Partecipa a Diamonds :)
cdimauro
05-01-2006, 12:18
In effetti leggendo la discussione e leggendo gli interventi di cdmauro e di fek viene da chiedersi se effettivamente programmino qualcosa, nella loro vita.
Probabilmente pianificano e gestiscono i commenti e la documentazione al codice, oppure riscrivono 650 volte lo stesso ciclo in modo che sia il più elegente possibile.
Esprimere dei giudizi avventati su gente che non conosci non ti fa onore.
Sul mio conto troverai poca roba "pubblica" in giro: giusto un riferimento al decoder JPEG 2000 che ho sviluppato nel mio stage / tesi di laurea presso la STMicroelectronics, e se cerchi "the best fighter game for the Amiga" anche qualcosa sul gioco al quale ho lavorato una decina d'anni fa.
Per il resto, non posso certo farti vedere il codice che ho scritto nei miei vari lavori. Anche perché preferisco confrontarmi basandomi su fatti e argomentazioni, non sui titoli nobiliari...
Non voglio entrare nel merito, né dire che non sia vero, ma queste frasi
Persone ed interazione più che processi e tools;
Software che funziona più che documentazione esaustiva;
Collaborazione con il cliente più che negoziazione contrattuale;
Rispondere al cambiamento più che il seguire un piano prestabilito;[/i]
le ho sempre sentite decantare da chiunque si occupi di informatica, da 15 anni a questa parte, a partire dal piccol e sprovveduto collaboratore (lavoro da solo, garantisco una presenza più umana, un contatto con il cliente, ecc.) fino alla grande azienda (un mondo intorno a te ;))
Fek sta dicendo questo: se il cliente varia la richiesta, la documento a parte.
Non sto dicendo questo.
Teoricamente giusto, praticamente sbagliato. Ti telefona per dirti che una certa cosa sarebbe meglio farla in un altro modo, cosa gli rispondi:
1) me lo dica quando ci vediamo tra 2 settimane?
2) mo' me lo marco, sospendo la scrittura del codice, lo aggiungo nelle specifiche, gliele mando per vedere se l'interpretazione della richiesta è corretta, aspetto il via libera e ritorno sul codice
3) Fai una nota nel codice e vai avanti ?
4) Scrivi un acceptance test con la nuova specifica che te la documenta. Quando l'acceptance test passa il tuo lavoro e' finito e puoi consegnarlo al cliente, se non e' quello che vuole te lo dira' subito. L'acceptance test ti documenta anche la specifica in un linguaggio privo di ambiguita', e nel frattempo ti dice quando hai finito. Non c'e' bisogno di alcun commento, e di alcuna documentazione scritta permanente.
Esempio di nuovo in Diamonds. Quando il nostro Customer (che poi e' il Designer del gioco) decide di cambiare una specifica, la prima cosa che facciamo e' scrivere un test che codifica la sua nuova specifica e lo inseriamo nella batteria dei test e assegnamo il task a qualcuno. Il task e' concluso quando quel test passa. Il test documenta anche la specifica. Nel tempo che tu scrivi il commento, io ho scritto il test.
Artemisyu
05-01-2006, 12:19
Partecipa a Diamonds :)
Devo affrontare un po' di cambiamenti della mia mediocre esistenza, nel corso dei prossimi mesi.
Se tutto va per il verso giusto tranquillo che tra qualche mese torno a romperti le palle :)
Anche perché preferisco confrontarmi basandomi su fatti e argomentazioni, non sui titoli nobiliari...
Buona questa, sei uno dei pochi che mette il proprio titolo di studio nella firma, e dire che qua siamo in tanti ad averlo, almeno credo.
Io mica ci metto D.R. Ing. ..... (D.R.=Ph.D) ??
cdimauro
05-01-2006, 12:22
non mi pare ke qualk1 ha detto ke i wmf contengono eseguibili! era sottointeso ke il codice eseguibile veniva iniettato sfruttando l'ennesimo bug!
http://attivissimo.blogspot.com/2006/01/falla-wmf-il-rischio-aumenta-come.html][/url]
La cosa ironica è che la falla non è dovuta a un errore di programmazione di Microsoft, ma a una scelta tecnica ben precisa e intenzionale dell'azienda di zio Bill: quando introdusse il formato WMF, negli anni Ottanta, Microsoft ritenne necessario consentire a un'immagine di includere codice eseguibile, in modo da poterne interrompere la stampa durante lo spooling (l'invio alla coda di stampa). A nessuno, in casa Microsoft, venne in mente che un aggressore avrebbe potuto sfruttare questa "funzione" per causare danni.
La parte in grassetto e sottolineata è mia.
L'ho detto e lo ripeto: tu hai problemi di comprensione. SERII problemi, a questo punto.
Il mio messaggio l'hai letto o hai fatto finta di non vederlo? Mi sai dire di quale commento avrebbe bisogno quel pezzo di codice assembly che ho scritto?
Tu non nemmeno sai cosa voglia dire programmare; tanto meno farlo a basso livello.
il fatto ke 2 righe di assembler non hanno bisogno di commento non significa ke una qualsiasi funzione scritta in asm non ha bisogno di commento! hai studiato logica all'università vero?
e poi voi vi continuate ad appigliare ai commenti quando io ho detto documentare! se uno vuole capire tutta la struttura di diamonds deve leggere 31 (immagino ke il numero è destinato a crescere) classi di test! non mi dire ke è immediato! scrivere sopra ogni funzione cosa fa non è certo un male! ad esempio getWindowHeight() l'avrei interpretato come dammi l'altezza ke la finestra ha adesso, mentre invece restituisce l'altezza ke di default viene impostata (esempio stupido solo x far capire cosa intendo)!
ps. so cosa vuol dire programmare a basso livello... anke per esperienza di altri!
Artemisyu
05-01-2006, 12:23
Esprimere dei giudizi avventati su gente che non conosci non ti fa onore.
"viene da chiedersi se" e "probabilmente" non sono proposizione che esprimono giudizi.
Mi sa che la butti un po' troppo sul personale.
Devo affrontare un po' di cambiamenti della mia mediocre esistenza, nel corso dei prossimi mesi.
Se tutto va per il verso giusto tranquillo che tra qualche mese torno a romperti le palle :)
Guarda, nel tempo che hai passato a scrivere qui, scrivi un task di Diamonds :)
La cosa comoda della metodologia di sviluppo che usiamo e' che nessuno e' costretto a dedicare al progetto un tempo fisso ogni settimana. Quando hai mezz'ora libera puoi aprire l'elenco dei task, sceglierne uno, scrivere la test list, il codice relativo, fare il commit e sparire per settimane. Nessuno e' responsabile di nessuna parte precisa del codice, tutti sono responsabili di tutto il codice. Se spacchi col tuo codice qualcosa c'e' la batteria di test a dirlo subito, non puoi fare il commit e nessuno perde tempo. Se il tuo codice non raggiunge un livello minimo di qualita' (ad esempio scrivi un metodo troppo complesso), ho gli strumenti automatici che lo segnalano e ti viene vietato il commit. Tutti i controlli sul codice e la batteria di test sono automatici, c'e' una build machine che controlla il codice costantemente e se accade qualcosa me lo segnala via mail, RSS, fra poco mi faccio mandare anche gli SMS sul cellulare :D
Mi piace citare 71104, e' partito due mesi fa spergiurando che scrivere test e' un'inutile perdita di tempo e il codice va commentato tutto. Ora non va neppure al bagno se non scrive un test e piuttosto che scrivere un metodo piu' lungo di 10 righe vende sua mamma.
cdimauro
05-01-2006, 12:25
Buona questa, sei uno dei pochi che mette il proprio titolo di studio nella firma, e dire che qua siamo in tanti ad averlo, almeno credo.
Non ho mai tirato in ballo il mio titolo e ciò che ho fatto nella vita nelle discussioni (se non quando pertinente). Ripeto: mi sono sempre confrontato su fatti e argomentazioni.
La mia firma con tutto ciò non c'entra niente.
Io mica ci metto D.R. Ing. ..... (D.R.=Ph.D) ??
Fatti tuoi. ;)
La parte in grassetto e sottolineata è mia.
L'ho detto e lo ripeto: tu hai problemi di comprensione. SERII problemi, a questo punto.
non mi stupirei se fosse vera sta storia dell'eseguibile.. non sono mai stati dei geni in quanto a sicurezza! era forte quando outlook eseguiva i programmi da solo! bei tempi!
Artemisyu
05-01-2006, 12:27
Guarda, nel tempo che hai passato a scrivere qui, scrivi un task di Diamonds :)
La cosa comoda della metodologia di sviluppo che usiamo e' che nessuno e' costretto a dedicare al progetto un tempo fisso ogni settimana. Quando hai mezz'ora libera puoi aprire l'elenco dei task, sceglierne uno, scrivere la test list, il codice relativo, fare il commit e sparire per settimane. Nessuno e' responsabile di nessuna parte precisa del codice, tutti sono responsabili di tutto il codice. Se spacchi col tuo codice qualcosa c'e' la batteria di test a dirlo subito, non puoi fare il commit e nessuno perde tempo. Se il tuo codice non raggiunge un livello minimo di qualita' (ad esempio scrivi un metodo troppo complesso), ho gli strumenti automatici che lo segnalano e ti viene vietato il commit. Tutti i controlli sul codice e la batteria di test sono automatici, c'e' una build machine che controlla il codice costantemente e se accade qualcosa me lo segnala via mail, RSS, fra poco mi faccio mandare anche gli SMS sul cellulare :D
Apprezzabilissimo tutto il lavoro, tranne un piccolo particolare...
Non so una riga di java :D
Esempio di nuovo in Diamonds. Quando il nostro Customer (che poi e' il Designer del gioco) decide di cambiare una specifica, la prima cosa che facciamo e' scrivere un test che codifica la sua nuova specifica e lo inseriamo nella batteria dei test e assegnamo il task a qualcuno. Il task e' concluso quando quel test passa. Il test documenta anche la specifica. Nel tempo che tu scrivi il commento, io ho scritto il test.
L'erroro o il fraintendimento, è proprio qua.
Con i piccoli clienti (e probabilmente ognuno di noi ha un proprio concetto di piccolo :p ), chi scrive il test e il task e la stessa persona.
Se ora mi dici che esiste un ambiente di sviluppo che ti affianca dove scrivi il codice con quello dove scrivi i test, in modo che fai la cosa contemporanea, ok, ti posso dire che è buona cosa e dovrò procurarmelo.
Ma in questo caso non vedrei cosa cambierebbe nell'usare da solo due ambienti separati per fare quello che il già citato javadoc mi consente di fare in linea.
P.S.: ma javadoc lo hai mai usato ? Hai presente le pagine di documentazione delle librerie Java? Quando termini di scrivere il codice, lanci javadoc e hai la documentazione.
cdimauro
05-01-2006, 12:32
il fatto ke 2 righe di assembler non hanno bisogno di commento non significa ke una qualsiasi funzione scritta in asm non ha bisogno di commento! hai studiato logica all'università vero?
Certo, ma sei stato tu ad affermare questo:
"a basso livello te lo puoi scordare di non documentare il codice!"
e questo:
"i commenti solo dove servono! cioè molti nel codice di basso livello xkè lì si tende a privilegiare l'efficienza a danno della leggibilità del codice!"
Non c'è bisogno di tirare in ballo la logica per capire che non sai cosa dici: d'altra parte non hai esperienza di programmazione a basso livello. E' stato scritto chiaramente, più volte, QUANDO serve mettere commenti nel codice.
ps. so cosa vuol dire programmare a basso livello... anke per esperienza di altri!
Allora vuol dire che non lo sai: l'esperienza appartiene, appunto, ad altri e non a te.
Apprezzabilissimo tutto il lavoro, tranne un piccolo particolare...
Non so una riga di java :D
Neppure io. E allora? :D
L'erroro o il fraintendimento, è proprio qua.
Con i piccoli clienti (e probabilmente ognuno di noi ha un proprio concetto di piccolo :p ), chi scrive il test e il task e la stessa persona.
Se ora mi dici che esiste un ambiente di sviluppo che ti affianca dove scrivi il codice con quello dove scrivi i test, in modo che fai la cosa contemporanea, ok, ti posso dire che è buona cosa e dovrò procurarmelo.
Ma in questo caso non vedrei cosa cambierebbe nell'usare da solo due ambienti separati per fare quello che il già citato javadoc mi consente di fare in linea.
Puoi usare Eclipse. JUnit e' integrato (e lo e' anche molto bene).
Ma tu sai che mentre programmiamo scriviamo sempre prima i test e poi il codice che li fa passare? E tutto ovviamente all'interno di Eclipse.
P.S.: ma javadoc lo hai mai usato ? Hai presente le pagine di documentazione delle librerie Java? Quando termini di scrivere il codice, lanci javadoc e hai la documentazione.
Certo, lo evito come la peste. Preferisco scrivere un test che oltre a documentarmi in maniera precisa l'interfaccia di una o piu' classi e le post condizioni di una classe, mi fornisce un esempio d'uso e, infine, e' sempre li' a dirmi quando il codice non e' in sincronia con i test che falliscono.
Immagina di cambiare una riga di codice da qualche parte ed in una parte totalmente differente del codice rompi qualcosa. Non credo che i commenti ti rivelino questa situazione, giusto? I test si' (spesso, non sempre ovviamente).
"i commenti solo dove servono! cioè molti nel codice di basso livello xkè lì si tende a privilegiare l'efficienza a danno della leggibilità del codice!"
Per altro in questa affermazione sta sottointendendo che quando si programma a basso livello bisogna ottimizzare sempre il codice, e non c'e' affermazione piu' errata :)
"Premature optimisation is the root of all evil" (Knuth).
ilsensine
05-01-2006, 12:36
Buona questa, sei uno dei pochi che mette il proprio titolo di studio nella firma, e dire che qua siamo in tanti ad averlo, almeno credo.
Io mica ci metto D.R. Ing. ..... (D.R.=Ph.D) ??
Certo se andiamo avanti così il thread ha vita breve. Peccato, perché dovrebbe essere interessante per tutti.
cdimauro
05-01-2006, 12:36
"viene da chiedersi se" e "probabilmente" non sono proposizione che esprimono giudizi.
Mi sa che la butti un po' troppo sul personale.
Mi sa che certe battute te le potresti evitare, visto che servono soltanto a infiammare la discussione.
giuseppeS
05-01-2006, 12:37
Usa metodi statici, dov'e' il problema, fanno parte della definizione del C++ :)
Tanto vale usare direttamente il C e magari usare il C++ ad un livello superiore, no?
Artemisyu
05-01-2006, 12:38
Neppure io. E allora? :D
E come sviluppi diamonds allora? :mbe: :eek:
ps. so cosa vuol dire programmare a basso livello... anke per esperienza di altri!
Ti posso confermare che nel '94 (o '95) avevo scritto delle routines di accesso a basso livello alla modalità VESA della scheda grafica, e senza commenti col cavolo che si capivano ;) con tutto l'impegno che ci mettevi.
Capivi benissimo la chiamata:
attivoModalitaVesa ();
Ma il cosa c'era dentro..... non ti dico ;)
Tanto vale usare direttamente il C e magari usare il C++ ad un livello superiore, no?
No, visto che il C++ e' un superset esatto (nomi di alcuni identificatori a parte) del C.
Non vedo perche' usare il C quando in C++ puoi fare la stessa cosa, meglio, con meno codice e con una tipizzazione piu' forte. C++ non vuol dire usare sempre le classi, ma usarle solo quando e dove serve.
cdimauro
05-01-2006, 12:39
non mi stupirei se fosse vera sta storia dell'eseguibile.. non sono mai stati dei geni in quanto a sicurezza! era forte quando outlook eseguiva i programmi da solo! bei tempi!
Hai presente quando è stato ideato il formato WMF? A quanto pare il bug coinvolge anche Windows 3.0: fatti il conto di quanto tempo è passato, e di come si lavorava all'epoca.
Io lavoravo in assembly anche per quasi tutto all'epoca: dai programmi a linea di comando, a quelli con GUI, ai giochi per AmigaOS.
Artemisyu
05-01-2006, 12:40
Mi sa che certe battute te le potresti evitare, visto che servono soltanto a infiammare la discussione.
So bene che infiammano la discussione.
Ma è anche vero che quello che si è affrettatto a dire di non sparare giudizi quando sapevi benissimo che ciò cheho scritto non ne esprimeva sei tu, non io.
E anche quello che hai scritto tu e a cui ho risposto ha il solo scopo di infiammare le discussioni.
sono io quello ke non capisce? comprati un libro di logica xkè hai le idee confuse!
Certo, ma sei stato tu ad affermare questo:
"a basso livello te lo puoi scordare di non documentare il codice!"
e questo:
"i commenti solo dove servono! cioè molti nel codice di basso livello xkè lì si tende a privilegiare l'efficienza a danno della leggibilità del codice!"
lo penso ankora ke nel codice di basso livello ci vanno molti commenti! molti non vuol dire x ogni riga di codice!
Non c'è bisogno di tirare in ballo la logica per capire che non sai cosa dici: d'altra parte non hai esperienza di programmazione a basso livello. E' stato scritto chiaramente, più volte, QUANDO serve mettere commenti nel codice.
Allora vuol dire che non lo sai: l'esperienza appartiene, appunto, ad altri e non a te.
se leggi ho scritto anke x esperienza di altri ke non vuol dire solo x esperienza di altri ! infatti x un periodo ho masticato abbastanza codice di basso livello (anke asm) e so cosa vuol dire scrivere un algoritmo e non capirlo neanke un secondo dopo averlo scritto! in java non si fa così xkè non si guarda all'efficienza (controsenso se usi java) e quindi il migliore algoritmo è il + chiaro e comprensibile! mi dispiace ke in C o in C++ il vostro metodo non sia il migliore! dovete ammettere ke dove si parla di efficienza si deve scendere a compromessi! soprattutto chiunque ha un pò di buon senso capisce ke una frase come "il nostro metodo è migliore sempre" non merita di essere presa in considerazione.
E come sviluppi diamonds allora? :mbe: :eek:
Io non programmo, faccio solo refactoring ogni tanto e faccio molto coaching. La sintassi di Java e' C-like quindi il codice di un metodo e' facile da comprendere (soprattutto se e' scritto bene ;)). Per il resto Eclipse scrive molto codice da se' e quando non so come esprimere qualcosa correttamente in Java domando.
Alla fine quello che conta e' saper programmare, i dettagli sintattici del linguaggio sono il meno.
cdimauro
05-01-2006, 12:42
Per altro in questa affermazione sta sottointendendo che quando si programma a basso livello bisogna ottimizzare sempre il codice, e non c'e' affermazione piu' errata :)
"Premature optimisation is the root of all evil" (Knuth).
Perfettamente d'accordo. Per ottimizzare il codice c'è sempre tempo: DOPO averlo fatto funzionare. :D
cdimauro
05-01-2006, 12:43
So bene che infiammano la discussione.
Ma è anche vero che quello che si è affrettatto a dire di non sparare giudizi quando sapevi benissimo che ciò cheho scritto non ne esprimeva sei tu, non io.
E anche quello che hai scritto tu e a cui ho risposto ha il solo scopo di infiammare le discussioni.
Sei tu che hai tirato in ballo me e fek, facendo delle pesanti allusioni su quello che abbiamo fatto e come lavoriamo: non cercare di rigirare la frittata, perché non attacca.
lo penso ankora ke nel codice di basso livello ci vanno molti commenti! molti non vuol dire x ogni riga di codice!
Pensi anche che pensare la struttura del codice prima di scriverlo sia una buona idea se e' per questo, ma non fa molto testo visto che non hai esperienza nel campo e hai le idee molto confuse :)
soprattutto chiunque ha un pò di buon senso capisce ke una frase come "il nostro metodo è migliore sempre" non merita di essere presa in considerazione.
... se non fosse che nessuno ha mai detto una cosa simile a parte te.
SilverXXX
05-01-2006, 12:43
Sia chiaro.
Io non infetto il mondo con il mio pessimo codice.
Diciamo che mi esercito... i miei programmi non escono dal mio hd :D
Non intendevo proprio quello, ma tant'è.... qui vi capite poco tutti :D
Artemisyu
05-01-2006, 12:45
Sei tu che hai tirato in ballo me e fek, facendo delle pesanti allusioni su quello che abbiamo fatto e come lavoriamo: non cercare di rigirare la frittata, perché non attacca.
Visto non attacca non rispondermi no?
Perfettamente d'accordo. Per ottimizzare il codice c'è sempre tempo: DOPO averlo fatto funzionare. :D
A qualunque livello :)
Pensare che nel codice a basso livello si debba sempre scendere a compromessi e' l'ennesima affermazione da principiante. In BW2 sono sceso a compromessi sulla leggibilita' del codice per le prestazioni una volta sola su centinaia di migliaia di righe di codice e non posso dire che non sia un'applicazione molto sensibile alle performance. E stavo scrivendo una routine molto a basso livello. Ho semplicemente mantenuto una versione del codice piu' leggibile come reference.
Le ottimizzazioni del codice devono sempre essere prima algoritmiche e sempre dopo una precisa analisi con un profiler. E infine, solo dove e' necessario, si puo' andare a spaccare il ciclo di clock, magari riscrivendo una routine in asm (ormai e' raro).
L'altra cosa divertente: i cellulari si programmano principalmente in Java e non sono proprio dei mostri di potenza computazionale :)
cdimauro
05-01-2006, 12:50
sono io quello ke non capisce? comprati un libro di logica xkè hai le idee confuse!
Le mie idee sono chiarissime: le tue, come hai dimostrato finora, lasciano molto a desiderare.
lo penso ankora ke nel codice di basso livello ci vanno molti commenti! molti non vuol dire x ogni riga di codice!
E perché non pochi o nessuno? Non è ancora meglio?
se leggi ho scritto anke x esperienza di altri ke non vuol dire solo x esperienza di altri !infatti x un periodo ho masticato abbastanza codice di basso livello (anke asm) e so cosa vuol dire scrivere un algoritmo e non capirlo neanke un secondo dopo averlo scritto!
Non hai masticato abbastanza codice a basso livello allora. Che tra l'altro NON vuol dire necessariamente asm.
in java non si fa così xkè non si guarda all'efficienza (controsenso se usi java)
Scrivere a basso livello non implica necessariamente tirare fuori codice efficiente.
e quindi il migliore algoritmo è il + chiaro e comprensibile!
Appunto: quello che si riesce a capire anche senza una riga di commento. Con qualunque linguaggio sia stato scritto.
mi dispiace ke in C o in C++ il vostro metodo non sia il migliore! dovete ammettere ke dove si parla di efficienza si deve scendere a compromessi!
Ti ho dimostrato con quel pezzo di codice per 65C02, che anche lavorando a basso livello è possibile scrivere codice comprensibilissimo senza aver bisogno di una sola riga di commento. Se si hanno le capacità e la voglia per farlo, ovviamente.
soprattutto chiunque ha un pò di buon senso capisce ke una frase come "il nostro metodo è migliore sempre" non merita di essere presa in considerazione.
Chi, dove e quando l'avrebbe scritta?
cdimauro
05-01-2006, 12:51
Visto non attacca non rispondermi no?
:mc:
giuseppeS
05-01-2006, 13:06
No, visto che il C++ e' un superset esatto (nomi di alcuni identificatori a parte) del C.
Non vedo perche' usare il C quando in C++ puoi fare la stessa cosa, meglio, con meno codice e con una tipizzazione piu' forte. C++ non vuol dire usare sempre le classi, ma usarle solo quando e dove serve.
A parte che stiamo uscendo un pò fuori topic con questa discussione:), utilizzando solo il subset C del C++ si usa C e non C++.
A parte che stiamo uscendo un pò fuori topic con questa discussione:), utilizzando solo il subset C del C++ si usa C e non C++.
No, si usa il C++, funzioni inline dove servono ad esempio, un migliore controllo sui tipi, parametri const, etc etc. Tutta roba perfetta per un allocatore magari. Che puo' comunque essere espresso ancora meglio usando la tecnica della costruzione in-place che ti ho mostrato.
Non c'e' alcun caso in cui sia preferibile usare il C piuttosto che il C++.
giuseppeS
05-01-2006, 13:16
No, si usa il C++, funzioni inline dove servono ad esempio, un migliore controllo sui tipi, parametri const, etc etc. Tutta roba perfetta per un allocatore magari. Che puo' comunque essere espresso ancora meglio usando la tecnica della costruzione in-place che ti ho mostrato.
Non c'e' alcun caso in cui sia preferibile usare il C piuttosto che il C++.
Un gestore della memoria richiede parecchio codice, e da solo può essere considerato un progetto completo. Se gli oggetti non si possono usare tanto vale farlo in un linguaggio dove non esistono ed ideato per gestire questo genere di cose.
parlare con voi è pressokè impossibile! a mio avviso non è il caso di andare avanti! quello ke importa è ke siamo tutti daccordo ke i programmi open source non hanno qualità inferiore a quelli closed source in generale, ne tantomeno presentano più bugs x il fatto ke il codice è visibile... detto ciò ognuno continuerà a programmare come meglio crede! come al solito nel mondo dell'informatica ci sono diverse filosofie e vari gruppi ke sostengono l'una o l'altra! nessuno può dire quale sia la migliore (efficienza, affidabilità e manutenibilità la dicono lunga sui compromessi da fare...)! comunque sia se fate parte di questi gruppi dovevate iscrivervi a filosofia! non a informatica!
Un gestore della memoria richiede parecchio codice, e da solo può essere considerato un progetto completo. Se gli oggetti non si possono usare tanto vale farlo in un linguaggio dove non esistono ed ideato per gestire questo genere di cose.
Lo so, ne ho scritti un paio. E tutti ad oggetti, usando la costruzione in-place. Se non vuoi usare quel costrutto puoi usare funzioni libere e continuare a sfruttare i vantaggi del C++ rispetto al C. Il C++ non e' stato ideato per gestire solo la programmazione ad oggetti, ma per gestire svariati paradigmi fra cui quello ad oggetti (ma anche programmazione generica, funzionale, etc). Ed e' stato progettato per la programmazione di sistema. Ti consiglio la lettura del libro di Stroustrup sul design e sull'evoluzione del C++. E' illuminante.
cdimauro
05-01-2006, 13:23
Perfettamente d'accordo. ;)
parlare con voi è pressokè impossibile!
Ovvio, perche' non ti diamo ragione a priori sulle fesserie che scrivi :)
nessuno può dire quale sia la migliore (efficienza, affidabilità e manutenibilità la dicono lunga sui compromessi da fare...)! comunque sia se fate parte di questi gruppi dovevate iscrivervi a filosofia! non a informatica!
Si', si puo' dire quale sia la famiglia di metodologie migliori per un determinato compito, esistono studi e metriche precise che calcolano la produttivita' individuale e del team. Molti studi a riguardo sono gia' stati condotti, famoso quello di Crysler-Dimler (progetto CCC) che ha dato il via alla codifica dell'Extreme Programming. Non si sta parlando di filosofia, ma di pratiche ben precise che usiamo tutti i giorni nella costruzione del nostro software. Ed avendo usato diverse pratiche nella mia carriera ho un'idea abbastanza precisa di quali siano piu' o meno produttive. Si', anch'io in passato commentavo tutto, poi ho imparato a programmare...
Non c'e' alcun caso in cui sia preferibile usare il C piuttosto che il C++.
se non usi gli oggetti è uno spreco usare un compilatore pensato x gestire gli oggetti! è come usare l'aereo x andare da linate a malpensa (visto ke apprezzi gli esempi del menga)! poi C viene ankora usato da un sacco di persone e non mi pare ke siano tutti stupidi!
se non usi gli oggetti è uno spreco usare un compilatore pensato x gestire gli oggetti! è come usare l'aereo x andare da linate a malpensa (visto ke apprezzi gli esempi del menga)! poi C viene ankora usato da un sacco di persone e non mi pare ke siano tutti stupidi!
E due. C++ non e' pensato solo per gestire gli oggetti, ma anche per gestire gli oggetti. E' pensato per permettere diversi paradigmi di programmazione. C++ e' molto migliore del C per la programmazione funzionale. Un altro errore da principiante e' pensare che programmare in C++ significhi usarne ogni singola caratteristica, cosa non vera. Bisogna usare solo le caratteristiche necessarie a risolvere il proprio problema. Se non si ha bisogno di modellare per mezzo degli oggetti, non si usano e si usano altre caratteristiche (template, funzioni inline magari).
Chi usa il C al posto del C++ non e' necessariamente stupido, semplicemente non conosce l'alternativa migliore.
Si', si puo' dire quale sia la famiglia di metodologie migliori per un determinato compito, esistono studi e metriche precise che calcolano la produttivita' individuale e del team. Molti studi a riguardo sono gia' stati condotti, famoso quello di Crysler-Dimler (progetto CCC) che ha dato il via alla codifica dell'Extreme Programming. Non si sta parlando di filosofia, ma di pratiche ben precise che usiamo tutti i giorni nella costruzione del nostro software. Ed avendo usato diverse pratiche nella mia carriera ho un'idea abbastanza precisa di quali siano piu' o meno produttive. Si', anch'io in passato commentavo tutto, poi ho imparato a programmare...
so meglio di te ke gli studi sono fatti solo x giustificare l'ipotesi! un pò come gli studi ke MS ha fatto nel paragonare il costo di linux a quello di windows! deve ankora nascere uno studio completo e oggettivo! in assenza di quello rimango della mia idea xkè personalmente ankio ho un'idea abbastanza precisa di come produco meglio! questione molto relativa...
so meglio di te ke gli studi sono fatti solo x giustificare l'ipotesi! un pò come gli studi ke MS ha fatto nel paragonare il costo di linux a quello di windows! deve ankora nascere uno studio completo e oggettivo! in assenza di quello rimango della mia idea xkè personalmente ankio ho un'idea abbastanza precisa di come produco meglio! questione molto relativa...
Ma non dire fesserie :)
ilsensine
05-01-2006, 14:00
in java non si fa così xkè non si guarda all'efficienza (controsenso se usi java)
k0nt3, abbi pazienza...dove sta scritto che non si può usare il java in maniera efficiente?
Ma mi spiegate cosa centra tutto questo con la domanda iniziale? Secondo me siamo in stallo.
Propongo di lasciare perdere tutto cio che è stato detto fin'ora e ricominciare da una domanda semplice semplice:
Pigliamo due porgetti di pari complessità, entrambi scritti da persone esperte, ben progettati, documentati (ovviamente questi documenti sono più o meno pubblici) ed ottimizzati, lasciamo perdere il linguaggi di programmazione usati e tutto il resto.
Ora, uno di questi progetti segue l'opensource mentre l'altro no, facciamo un confronto serio sulle opportunità e sui difetti che entrambi i casi offrono in ambito sicurezza e lasciamo perdere caccie alle streghe per sparlare di prodotti esistenti.
Secondo me è l'unica soluzione per ridare un senso al topic.
Ora, uno di questi progetti segue l'opensource mentre l'altro no, facciamo un confronto serio sulle opportunità e sui difetti che entrambi i casi offrono in ambito sicurezza e lasciamo perdere caccie alle streghe per sparlare di prodotti esistenti.
Abbiamo gia' risposto a questa domanda:
- Non esiste una metrica precisa per giudicare la sicurezza di un sistema.
- Open-source e' solo una tipologia di distribuzione del software, le sue caratteristiche di sicurezza (nei limiti di quanto detto sopra) dipendono dalla metodologia di sviluppo che puo' essere eterogena.
giuseppeS
05-01-2006, 14:23
Chi usa il C al posto del C++ non e' necessariamente stupido, semplicemente non conosce l'alternativa migliore.
O semplicemente ha bisogno soltanto del subset C.
Bhe, la possibilità di controllare personalmente il codice va al di la della metodologia di sviluppo, data per identica in entrambi i casi.
L'open source è anche un modo di distribuire il software, ma c'è dietro molto di più.
Purtroppo non mi è facile riprendere tutto quanto è stato detto sopra vista la mole di cose (a parer mio) inutili riportare.
O semplicemente ha bisogno soltanto del subset C.
Se e' per questo hai solo bisogno di programmare in assembly per fare quello che ti serve, perche' non usare quello? Perche' non avresti a disposizione tutti i vantaggi di un linguaggio a livello piu' alto come il C.
In questo caso rinunciando ai vantaggi sintattici del C++, ti metti volontariamente nelle condizioni di scrivere codice peggiore e meno resistente ai difetti. Puoi farlo, ovviamente, ma visto che non c'e' nulla che in C puoi scrivere in maniera piu' efficiente che in C++ non c'e' alcuna ragione logica per fare quella scelta, solo ignoranza riguardo alle migliori alternative a disposizione.
giuseppeS
05-01-2006, 14:31
Lo so, ne ho scritti un paio. E tutti ad oggetti, usando la costruzione in-place. Se non vuoi usare quel costrutto puoi usare funzioni libere e continuare a sfruttare i vantaggi del C++ rispetto al C. Il C++ non e' stato ideato per gestire solo la programmazione ad oggetti, ma per gestire svariati paradigmi fra cui quello ad oggetti (ma anche programmazione generica, funzionale, etc). Ed e' stato progettato per la programmazione di sistema. Ti consiglio la lettura del libro di Stroustrup sul design e sull'evoluzione del C++. E' illuminante.
Hai usato la costruzione in-place per scrivere il gestore della memoria? E come facevi a sapere dove scrivere senza interpellare il gestore di memoria, dove capitava?
Non credo che Stroustrup vanterà mai l'uso di C rispetto al C++.
k0nt3, abbi pazienza...dove sta scritto che non si può usare il java in maniera efficiente?
ovviamente se usi un linguaggio interpretato e di alto livello (come è java) non stai ottimizzando l'efficienza (in termini computazionali)... quindi tantovale non perdere tempo a ottimizzare (in generale si rende solo il codice meno leggibile)... non è da confondere con java fa skifo xkè a me piace! java permette di progettare applicazioni velocemente e bene (è considerato infatti l'ideale x affrontare argomenti di ingegneria del SW), inoltre la portabilità è un grosso punto di forza!
volete contestarmi anke questo :D?
Bhe, la possibilità di controllare personalmente il codice va al di la della metodologia di sviluppo, data per identica in entrambi i casi.
L'open source è anche un modo di distribuire il software, ma c'è dietro molto di più.
Non necessariamente, dipende dal contesto e dall'uso che se ne fa dello strumento. In molte situazioni l'avere il codice open source puo' essere uno svantaggio (ipotizziamo anche una metodologia di sviluppo distribuita).
Penso a software mission o life critical: se qualcosa va storto chi ritengo responsabile? Il programmatore in Australia? Mai affiderei un tale software ne' ad un modello di sviluppo distribuito ne' al rilascio dei sorgenti open source, mi affiderei ad una ditta specializzata che posso ritenere legalmente responsabile in caso di difetti critici.
Oppure un'altra situazione e' quella in cui mi appoggio per un software commerciale ad una libreria per la quale ho bisogno di aggiornamenti costanti con tempistiche prevedibili (posso fare l'esempio di DirectX magari). Che succede se i maintainer smettono di mantenere il codice? Non hanno alcun contratto con me, non li posso obbligare. Posso invece firmare un contratto di supporto con lo sviluppatore della librerira tale da impegnarlo ad aggiornare con precise tempistiche la libreria ed e' legalmente obbligato a farlo. In questo caso lascio un po' lasca la distinzione fra modalita' di sviluppo e distribuzione, perche' nulla vieterebbe di avere un software open source con relativo contratto di supporto (penso al supporto delle distribuzioni linux).
Altro esempio, se ho bisogno di un ambiente di sviluppo che giri sotto Linux e Win32, che sia gratuito e non mi interessa il supporto (il caso di Diamonds), a chi mi affido? A software open source.
Dipende dalle situazioni quindi.
ilsensine
05-01-2006, 14:40
ovviamente se usi un linguaggio interpretato e di alto livello (come è java)
Ti do una notiziona: anche l'assembler è interpretato, da un linguaggio ancora a più basso livello ;)
(Lo studierai forse tra qualche esame)
Che facciamo ora? Smettiamo di ottimizzare in c/c++? Ci compriamo tutti la nostra FPGA con il sintetizzatore in Verilog? :)
ovviamente se usi un linguaggio interpretato e di alto livello (come è java) non stai ottimizzando l'efficienza (in termini computazionali)...
Ma per dio, Java non e' interpretato.
(precisazione, nell'accezione comune del termine, perche' come dice ilsensine tutti i linguaggi sono interpretati :))
Bhe, la possibilità di controllare personalmente il codice va al di la della metodologia di sviluppo, data per identica in entrambi i casi.
L'open source è anche un modo di distribuire il software, ma c'è dietro molto di più.
Purtroppo non mi è facile riprendere tutto quanto è stato detto sopra vista la mole di cose (a parer mio) inutili riportare.
non posso ke concordare.. probabilmente volevano confondere le idee riguardo all'open source e ci sono riusciti! se guardi... a pagina 3 mi ero già accordo ke la discussione aveva preso la piega sbagliata... profetico!
Certo se andiamo avanti così il thread ha vita breve. Peccato, perché dovrebbe essere interessante per tutti.
Ah, ma allora stai leggendo... ;)
Perchè mi pareva che il thread avesse avuto vita fin troppo lunga dato l'OT.
Del problema sicurezza dell'opensource si è parlato si e no fino alla seconda pagina, il resto mi sembra più degno del forum "Programmazione"
Ti do una notiziona: anche l'assembler è interpretato, da un linguaggio ancora a più basso livello ;)
(Lo studierai forse tra qualche esame)
Che facciamo ora? Smettiamo di ottimizzare in c/c++? Ci compriamo tutti la nostra FPGA con il sintetizzatore in Verilog? :)
intendi il microcodice? già fatto grazie..
penso ci sia differenza tra una virtual machine e un circuito HW... tutto qua! ho capito ormai niente è + certo! tutto è contestabile! forse io non esisto neppure! avete provato a cercare di dimostrare ke non esisto?
e poi se java è efficientissimo e interpretato esattamente come l'assembler.. perchè non si fanno i sistemi operativi in java? non verrebbero meglio?
ilsensine
05-01-2006, 14:48
Ah, ma allora stai leggendo... ;)
Perchè mi pareva che il thread avesse avuto vita fin troppo lunga dato l'OT.
Del problema sicurezza dell'opensource si è parlato si e no fino alla seconda pagina, il resto mi sembra più degno del forum "Programmazione"
Sì il thread è andato OT, ma visto che la questione originale mi sembra chiusa, non c'è niente di male.
Se vuoi aprire un nuovo thread in Programmazione per continuare lì va benissimo :)
ilsensine
05-01-2006, 14:54
intendi il microcodice? già fatto grazie..
penso ci sia differenza tra una virtual machine e un circuito HW... tutto qua!
I moderni processori hanno il microcode parzialmente programmabile...
e poi se java è efficientissimo e interpretato esattamente come l'assembler.. perchè non si fanno i sistemi operativi in java? non verrebbero meglio?
Sai che ci sono processori con accelerazione HW per il bytecode java?
Hai visto cosa ha combinato la Sun, con il looking glass (http://www.sun.com/software/looking_glass/)?
(e poi ci sono anche s/o in java, che io sappia)
cdimauro
05-01-2006, 14:57
java permette di progettare applicazioni velocemente e bene (è considerato infatti l'ideale x affrontare argomenti di ingegneria del SW), inoltre la portabilità è un grosso punto di forza!
volete contestarmi anke questo :D?
Certo. :D Con Python sviluppo applicazioni bene e più velocemente, ed è anche più portabile di Java (esistono porting anche per piattaforme recondite; basta che ci sia un compilatore C).
Sai che ci sono processori con accelerazione HW per il bytecode java?
Hai visto cosa ha combinato la Sun, con il looking glass (http://www.sun.com/software/looking_glass/)?
(e poi ci sono anche s/o in java, che io sappia)
Alcuni moderni processori per cellulare eseguono parti del bytecode infatti.
cdimauro
05-01-2006, 14:58
non posso ke concordare.. probabilmente volevano confondere le idee riguardo all'open source e ci sono riusciti! se guardi... a pagina 3 mi ero già accordo ke la discussione aveva preso la piega sbagliata... profetico!
L'unico ad avere le idee confuse qui sei tu: mi sembra più che evidente, ormai.
I moderni processori hanno il microcode parzialmente programmabile...
Sai che ci sono processori con accelerazione HW per il bytecode java?
Hai visto cosa ha combinato la Sun, con il looking glass (http://www.sun.com/software/looking_glass/)?
(e poi ci sono anche s/o in java, che io sappia)
tra quello ke hai detto e dire ke java è efficiente come qualsiasi linguaggio compilato in asm ne passa di strada... looking glass lo conosco e non mi pare ke sia così efficiente! metti ke passa il garbage collector (figura mitologica dell'antica grecia :D) mentre ho in esecuzione un'importantissima applicazione real-time! se parli di efficienza non parli di java (mi dispiace se sun non la pensa così)! forse parli di affidabilità, facilità, eleganza e immediatezza!
Alcuni moderni processori per cellulare eseguono parti del bytecode infatti.
come abbiamo fatto ad arrivare ai processori x cellulari in questo thread?!!!?!??!
cdimauro
05-01-2006, 15:05
tra quello ke hai detto e dire ke java è efficiente come qualsiasi linguaggio compilato in asm ne passa di strada...
Cosa intendi con ciò?
looking glass lo conosco e non mi pare ke sia così efficiente! metti ke passa il garbage collector (figura mitologica dell'antica grecia :D) mentre ho in esecuzione un'importantissima applicazione real-time! se parli di efficienza non parli di java (mi dispiace se sun non la pensa così)! forse parli di affidabilità, facilità, eleganza e immediatezza!
Può benissimo succedere anche con Windows se hai scritto un'applicazione in assembly che deve eseguire un'operazione importantissima: può benissimo essere interrotta dallo scheduler o da un interrupt. Non puoi mica uccidere il kernel. :D
cdimauro
05-01-2006, 15:06
come abbiamo fatto ad arrivare ai processori x cellulari in questo thread?!!!?!??!
Io, e penso tanti altri, una mezza idea, per non dire tutta, ce l'ho. E tu? :p
tra quello ke hai detto e dire ke java è efficiente come qualsiasi linguaggio compilato in asm ne passa di strada... looking glass lo conosco e non mi pare ke sia così efficiente! metti ke passa il garbage collector (figura mitologica dell'antica grecia :D) mentre ho in esecuzione un'importantissima applicazione real-time! se parli di efficienza non parli di java (mi dispiace se sun non la pensa così)! forse parli di affidabilità, facilità, eleganza e immediatezza!
Quanta confusione. Un'applicazione real-time non ha vincoli di efficienza, ha vincoli di tempistiche: dev'essere garantito che un task finisca in qualunque situazione prima di una determinata deadline, non dev'essere garantito che quel metodo sia il piu' efficiente possibile :)
Ma tu pensa che una VM come quella di Java per alcune cose puo' essere anche piu' efficiente di codice compilato staticamente, perche' e' in grado di ricompilare i metodi in base ai pattern d'uso e tenere i metodi piu' usati in pagine vicine e localizzarli nella cache. Cosa che un compilatore statico non puo' fare.
ilsensine
05-01-2006, 15:07
looking glass lo conosco e non mi pare ke sia così efficiente! metti ke passa il garbage collector (figura mitologica dell'antica grecia :D) mentre ho in esecuzione un'importantissima applicazione real-time!
Ok mi arrendo
Volevo correggere un tuo grossolano errore, visto che ho qualche inverno più di te dovresti concedermelo (e ascoltarmi).
importantissima applicazione realtime + java...mah...se vuoi potrei addirittura dirti come conciliare in linea teorica le due cose, ma passo (dovresti essere tu a insegnarmelo, visto che sei fresco di studi e all'università di Torino hanno brillanti soluzioni che puoi prendere come spunto)
cdimauro
05-01-2006, 15:13
importantissima applicazione realtime + java...mah...se vuoi potrei addirittura dirti come conciliare in linea teorica le due cose, ma passo (dovresti essere tu a insegnarmelo, visto che sei fresco di studi e all'università di Torino hanno brillanti soluzioni che puoi prendere come spunto)
Una curiosità: ma il kernel, anche su Linux (scusa il gioco di parole :D), non si può mica "congelare", no?
Su AmigaOS potevo fare qualcosa come:
Forbid()
[...Codice...]
Permit()
Per congelare lo schedule dei task, e
Enable()
[...Codice...]
Disable()
per congelare tutti gli interrupt (e quindi anche lo scheduler).
Ok mi arrendo
Volevo correggere un tuo grossolano errore, visto che ho qualche inverno più di te dovresti concedermelo (e ascoltarmi).
Guarda, ci sto provando da pagine ma mica e' facile farglielo capire.
importantissima applicazione realtime + java...mah...se vuoi potrei addirittura dirti come conciliare in linea teorica le due cose, ma passo (dovresti essere tu a insegnarmelo, visto che sei fresco di studi e all'università di Torino hanno brillanti soluzioni che puoi prendere come spunto)
Non conosco la JVM particolarmente bene, ma e' possibile spegnere il garbage collector per un periodo indeterminato e lanciaro su richiesta? Con il CLR 2.0 di .NET si puo' immagino che esista qualcosa di analogo nella JVM.
ilsensine
05-01-2006, 15:17
Una curiosità: ma il kernel, anche su Linux (scusa il gioco di parole :D), non si può mica "congelare", no?
Bè puoi disabilitare gli irq su un unico processore. Alcune volte è necessario (per brevi istanti, mai brevi abbastanza), meglio ancora se puoi disabilitare solo l'irq che ti interessa.
Ingo Molnar sta lavorando per spostare gli irq handler in contesto di processo, in modo da poter utilizzare le normali tecniche di lock. Ho provato qualche mese fa un suo kernel, sta facendo un ottimo lavoro.
Non conosco la JVM particolarmente bene, ma e' possibile spegnere il garbage collector per un periodo indeterminato e lanciaro su richiesta? Con il CLR 2.0 di .NET si puo' immagino che esista qualcosa di analogo nella JVM.
se vuoi rispondo io! certo! si può chiedere al garbage collector di non eseguirsi ma.. non è sicuro al 100% ke non lo faccia!
se vuoi rispondo io! certo! si può chiedere al garbage collector di non eseguirsi ma.. non è sicuro al 100% ke non lo faccia!
Quindi non si puo'. Ma in realta' sono sicuro che sia possibile.
ilsensine
05-01-2006, 15:24
se vuoi rispondo io! certo! si può chiedere al garbage collector di non eseguirsi ma.. non è sicuro al 100% ke non lo faccia!
Tutti i s/o "general purpose" (linux, windows, e tanti altri "spacciati" per hard-real time) non sono 100% deterministici nelle latenze, quini inadatti per molti contesti realtime-critical.
Vi accanite come k0nt3 ma lo fate perché siete abili a spostare il discorso ogni volta su un settore su cui avete maturato esperienza ed avete pronta una soluzione che anni fa non avreste avuto.
Ma anche se espresse male, tante cose dette da k0nt3 non sono campate in aria, ma insegnate nelle Università Italiane e condivise da tanti.
Che poi nelle pratica si tenda a fare diversamente, è ovvio, ma su certi argomenti non ci si può arrivare come prima battuta.
Sul fatto che Java possa essere usato per il real time non ci piove, sul fatto che sia la prima soluzione che viene in mente e uno non credo, a meno che non abbia programmato sempre e solo con Java per applicazioni real time.
Idem per gli altri discorsi, ma credo che il thread non ammetta impostazioni differenti da quelle tracciate.
Per quel che ne so, in M$ commentano il codice (presumo, ma lo consigliano sul sito;)), in SUN commentano il codice, il kernel di linux è commentato. E non mi pare che siano ermetisti del commento.
Probabilmente stanno sbagliando tutti, ma se MS, SUN e gli sviluppatori del Kernel di Linux sbagliano, tutti noi possiamo darci all'ippica.
E qua chiudo, perché devo andare a scrivere del codice con commenti annessi ;)
Vi accanite come k0nt3 ma lo fate perché siete abili a spostare il discorso ogni volta su un settore su cui avete maturato esperienza ed avete pronta una soluzione che anni fa non avreste avuto.
Ma anche se espresse male, tante cose dette da k0nt3 non sono campate in aria, ma insegnate nelle Università Italiane e condivise da tanti.
Che poi nelle pratica si tenda a fare diversamente, è ovvio, ma su certi argomenti non ci si può arrivare come prima battuta.
Beh, ovvio, lavoriamo tutti da anni in questo settore, ci credo che abbiamo maturato esperienza. Anni fa, quando non avevo le soluzioni, io non andavo da chi ne sapeva molto piu' di me a pretendere di aver ragione su cose che non conoscevo. Il contrario, imparavo. Il mio approccio e' sempre di imparare da chi ne sa molto piu' di me e trasmettere quello che so a chi ne sa meno e vuole imparare. E discutere con entrambi per imparare comunque cose nuove.
E poi verificare tutto sul campo.
Grazie a questo approccio credo di aver imparato un certo numero di nozioni sull'informatica.
Ti immagini se quando sono entrato in Lionhead fossi andato da Alex Evans e gli avessi detto: "Hei Alex ma sei dio sceso in terra ke dici cioe' ke ne sai tu io ho skritto un motore treddi' ed ho imparato tante cose te non sai niente di treddi'" :)
No, mi sono seduto ed ho ascoltato ogni cosa che aveva da dirmi.
Per quel che ne so, in M$ commentano il codice (presumo, ma lo consigliano sul sito;)),
Sai male :)
Code Complete 2 e' edito da Microsoft. Leggilo con attenzione, e' il libro piu' importante sulla costruzione del software e quando parla dei commenti nel codice esprime esattamente i concetti che abbiamo espresso noi qui.
ilsensine
05-01-2006, 15:42
Vi accanite come k0nt3
Non ci accaniamo contro di lui...
il kernel di linux è commentato. E non mi pare che siano ermetisti del commento
:read:
Chapter 7: Commenting
Comments are good, but there is also a danger of over-commenting. NEVER
try to explain HOW your code works in a comment: it's much better to
write the code so that the _working_ is obvious, and it's a waste of
time to explain badly written code.
Sembra di sentire Fek, ma si tratta di Linus Torvalds (v. Documentation/CondingStyle tra i sorgenti del kernel)
Perfettamente d'accordo. Per ottimizzare il codice c'è sempre tempo: DOPO averlo fatto funzionare. :D
"write a test, make it run, make it right" ^^
Tornando ancora una volta ai commenti...il 16 dicembre sono stato a un convegno di agile movement (citato prima da fek) ( www.agileday.it ) ed è stato detto più di una volta una cosa: commenti = codice non leggibile, questo è stato detto nella prima sessione (un manager e un programmatori in Ferrari, penso che a loro importi parecchio la produttività e il corretto funzionamento)
Chapter 7: Commenting
Comments are good, but there is also a danger of over-commenting. NEVER
try to explain HOW your code works in a comment: it's much better to
write the code so that the _working_ is obvious, and it's a waste of
time to explain badly written code.
Sembra di sentire Fek, ma si tratta di Linus Torvalds (v. Documentation/CondingStyle tra i sorgenti del kernel)
Non hai posto l'accento sulla parte che ho evidenziato e peccato che ti siano sfuggite le righe subito dopo:
Generally, you want your comments to tell WHAT your code does, not HOW.
Also, try to avoid putting comments inside a function body: if the
function is so complex that you need to separately comment parts of it,
you should probably go back to chapter 5 for a while. You can make
small comments to note or warn about something particularly clever (or
ugly), but try to avoid excess. Instead, put the comments at the head
of the function, telling people what it does, and possibly WHY it does
it.
Che è quanto sto dicendo da pagine: i commenti nel codice per sapere cosa fa un metodo e soprattutto perché sono importanti anche per Torvald, ma qua si sta sostenendo il contrario: quelle informazioni devono essere separate dal codice.
E in base al "GNU Coding Standard"
http://www.gnu.org/prep/standards/html_node/Comments.html#Comments
Also, please write a brief comment at the start of each source file, with the file name and a line or two about the overall purpose of the file.
...
Please put a comment on each function saying what the function does, what sorts of arguments it gets, and what the possible values of arguments mean and are used for.
...
Also explain the significance of the return value, if there is one.
...
Every ‘#endif’ should have a comment, except in the case of short conditionals (just a few lines) that are not nested. The comment should state the condition of the conditional that is ending, including its sense. ‘#else’ should have a comment describing the condition and sense of the code that follows.
Che è quanto sto dicendo da pagine: i commenti nel codice per sapere cosa fa un metodo e soprattutto perché sono importanti anche per Torvald, ma qua si sta sostenendo il contrario: quelle informazioni devono essere separate dal codice.
Esatto, devono essere separate dal codice. Su questo Torvalds sbaglia (o meglio, non ha alternative), perche' il kernel di Linux non adotta una politica di unit testing e non e' test driven, quindi e' costretto a ridursi a commentare i "why" all'inizio di ogni funzione. Non puo' essere altrimenti, il kernel e' vecchio di anni e non avrebbe senso riscriverlo adesso.
Iniziando un progetto da zero, invece, e' possibile affidarsi al testing ed eliminare anche questi commenti per aumentare ulteriormente l'affidabilita' del codice.
Lo stesso dicasi per i GNU Coding Standard: non sono un esempio di buona pratica. L'uso estensivo degli unit testing rende perfettamente inutile commentare i parametri di input di un metodo: sono gia' documentati nei test.
pinok.. non hai capito ke stai perdendo tempo e basta? io l'unika cosa ke ho imparato da questa discussione è ke esiste una setta di programmatori denominata "eXtreme Programmers"! come hai avuto modo di vedere è gente ke vuole vivere dentro una cupola di codice ad alto livello ke li protegge dai puntatori cattivi! praticamente ora fek sta dicendo ke è stato un grave errore scrivere il kernel in C! non voglio entrare nel merito... ma se Torvalds e Tanenbaum (e molti molti altri) fanno sistemi operativi e usano C ci sarà pure un motivo! quindi fek... lascia a loro il compito di fare sistemi operativi in C e tu pensa a fare i giochi in Java...
pinok.. non hai capito ke stai perdendo tempo e basta? io l'unika cosa ke ho imparato da questa discussione è ke esiste una setta di programmatori denominata "eXtreme Programmers"! come hai avuto modo di vedere è gente ke vuole vivere dentro una cupola di codice ad alto livello ke li protegge dai puntatori cattivi! praticamente ora fek sta dicendo ke è stato un grave errore scrivere il kernel in C! non voglio entrare nel merito... ma se Torvalds e Tanenbaum (e molti molti altri) fanno sistemi operativi e usano C ci sarà pure un motivo! quindi fek... lascia a loro il compito di fare sistemi operativi in C e tu pensa a fare i giochi in Java...
Ma non dire fesserie :)
Quota dove ho detto che scrivere il kernel di Linux in C e' stato un grave errore. Tu non comprendi il testo scritto o ti inventi proprio le cose. Torna a studiare che ne hai tanto bisogno, perche' non avevo dubbi che da questa discussione tu non sia riuscito ad imparare nulla.
jappilas
05-01-2006, 18:38
se Torvalds e Tanenbaum (e molti molti altri) fanno sistemi operativi e usano C ci sarà pure un motivo!
ti potrei dire, se all' università di Dresda, i creatori della L4KA hanno scritto la nuova versione del microkernel in C++, quando la prima era ottimizzata in assembly x86 e la seconda in C avranno avuto i loro motivi...
e che, per come l' ho capita io, Torvalds e Tanenbaum (e molti molti altri) hanno usato C perchè è quello che all' epoca (stiamo parlando di più di una dozzina di anni fa) era disponibile, standard, nonchè il linguaggio in cui era scritto Unix - di cui sia minix che Linux sono reimplementazioni - e che conoscevano, essendosi probabilmente formati in ambiente Unix ...
Chi usa il C al posto del C++ non e' necessariamente stupido, semplicemente non conosce l'alternativa migliore.
Prima che inizino nuove guerre sul miglior linguaggio da utilizzare (o sono gia' iniziate :confused: ), vorrei dire quello che ho imparato leggendo quanto spesso scritto dal buon cdimauro in tanti altri thread (solitamente nella sezione programmazione), ovvero:
il miglior linguaggio di programmazione e' quello che ti permette di risolvere il tuo problema nel modo piu' semplice e veloce possibile.
Quindi non credo che chi usa il C al posto del C++, sapendo quel che deve fare, sia necessariamente ignorante(*); semplicemente sceglie il linguaggio che ritiene piu' appropriato a perseguire il proprio scopo.
A meno che non vi sia un principio incontestabile (perche' dimostrato) che il C++ e' sempre migliore del C. Nel caso esistesse, ditemelo cosi' butto via il K&R :D
(*) Ignorante perche' semplicemente non conosce l'alternativa migliore, cioe' ignora.
Ciao
A meno che non vi sia un principio incontestabile (perche' dimostrato) che il C++ e' sempre migliore del C. Nel caso esistesse, ditemelo cosi' butto via il K&R :D
Butta via il K&R :)
C++ e' un superset del C. Non c'e' nulla in C che non possa essere espresso in C++ con la stessa efficienza, spesso e volenteri maggiore.
Butta via il K&R :)
:( Me lo potevate dire prima che lo comprassi... Eppure ho chiesto parecchi consigli prima di farlo. Vabbe', sono comunque soddisfatto dell'acquisto...
C++ e' un superset del C. Non c'e' nulla in C che non possa essere espresso in C++ con la stessa efficienza,
Chiaro
spesso e volenteri maggiore.
Mi piacerebbe sentire anche il parere di Cesare :)
C o non C, intanto a fine gennaio mi arriva questo! (http://vig.prenhall.com/catalog/academic/product/0,1144,0131429388,00.html) :sbav:
e se cerchi "the best fighter game for the Amiga" anche qualcosa sul gioco al quale ho lavorato una decina d'anni fa.
oh cavolo... non avrai mica lavorato a shadow fighter?????????? (lavoravi nei naps???)
o parli di fighting spirit???
cdimauro
06-01-2006, 07:08
Mi piacerebbe sentire anche il parere di Cesare :)
E' lo stesso. :) Considera che, appunto, puoi usare il C++ esattamente come il C.
Questo vuol dire che un buon compilatore, in assenza di costrutti e funzionalità tipiche del C++ (che richiedano "risorse"; per fare un esempio, non mi aspetto certo che l'uso dell'overloading degli operatori per scrivere "a = b + c;" anziché "a = AddComplexNumbers(b, c);" possa produrre codice peggiore ;)), dovrebbe generare per lo STESSO codice.
cdimauro
06-01-2006, 07:14
oh cavolo... non avrai mica lavorato a shadow fighter?????????? (lavoravi nei naps???)
o parli di fighting spirit???
La seconda che hai detto. :p
Comunque ho lasciato il team (Dynamic Style; poi assorbito dalla LightShock, in seguito divenuta Neo) un anno prima che fosse pubblicato, lasciandogli il codice che avevo già sviluppato, ma portandomi dietro quello dell'altro progetto a cui lavoravo soltanto io (USA Racing, che è rimasto nel cassetto).
P.S. I Na.P.S. erano un team di Messina, se non ricordo male, e prima che fosse pubblicato Shadow Fighter alcuni amici comuni ci mostrarono una demo funzionante.
P.P.S. Sai cosa vuol dire Na.P.S.? :D
P.P.S. Sai cosa vuol dire Na.P.S.? :D
Napoli Programming Squad :O
Ho vinto il panettone avanzato a Natale? :D
DanieleC88
07-01-2006, 10:57
Butta via il K&R :)
C++ e' un superset del C. Non c'e' nulla in C che non possa essere espresso in C++ con la stessa efficienza, spesso e volenteri maggiore.
Be', in alcuni casi (in un kernel, ad esempio) il C++ addirittura non serve. Io ho preferito il C99, piu' flessibile del C89, ma con meno problemi del C++ (ad esempio: non so con altri compilatori, ma gcc quando compila in C++ "decora" i nomi delle funzioni con vari caratteri strani... se devo chiamare una routine "ciao" in C++ da codice assembly devo usare qualcosa tipo "call _Z5ciaov", a meno che non la dichiaro con extern "C").
Iniziando un progetto da zero, invece, e' possibile affidarsi al testing ed eliminare anche questi commenti per aumentare ulteriormente l'affidabilita' del codice.
:eekk:
Anche in un kernel? Certo ci sono delle parti che possono essere testate intensivamente, ma altre come le testi? (Un bootloader, una routine per caricare GDT/LDT o IDT, ...)
La cosa mi interessa in prima persona, quindi se c'e' la possibilita' di fare test ti prego di dirmelo subito. :D
Anche in un kernel? Certo ci sono delle parti che possono essere testate intensivamente, ma altre come le testi? (Un bootloader, una routine per caricare GDT/LDT o IDT, ...)
La cosa mi interessa in prima persona, quindi se c'e' la possibilita' di fare test ti prego di dirmelo subito. :D
Mock, mock e ancora mock :D
ciao ;)
DanieleC88
07-01-2006, 12:13
Mock, mock e ancora mock :D
ciao ;)
In assembly? :mbe:
Be', in alcuni casi (in un kernel, ad esempio) il C++ addirittura non serve. Io ho preferito il C99, piu' flessibile del C89, ma con meno problemi del C++ (ad esempio: non so con altri compilatori, ma gcc quando compila in C++ "decora" i nomi delle funzioni con vari caratteri strani... se devo chiamare una routine "ciao" in C++ da codice assembly devo usare qualcosa tipo "call _Z5ciaov", a meno che non la dichiaro con extern "C").
Dichiarala extern "C", e' standard C++ e spegne il name mangling delle funzioni.
:eekk:
Anche in un kernel? Certo ci sono delle parti che possono essere testate intensivamente, ma altre come le testi? (Un bootloader, una routine per caricare GDT/LDT o IDT, ...)
La cosa mi interessa in prima persona, quindi se c'e' la possibilita' di fare test ti prego di dirmelo subito. :D
Ha risposto Vicius. Guarda come testiamo servizi a basso livello forniti da OpenGL, ad esempio, oppure un Timer, creando dei Mock che "fanno finta" di essere i servizi a basso livello.
Da un punto di vista piu' teorico, tu non devi testare, ad esempio, un servizio a basso livello fornito dall'hardware sul quale programmi il kernel, quel servizio e' "garantito" funzionare se tu segui il protocollo e rispetti il suo contratto. Allora quello che testi e' il fatto che rispetti il contratto stesso, segui tutte le specifiche e, al momento di fare la chiamata in un test la sostituisci con un oggetto vuoto (non proprio, semplifico un po').
In assembly? :mbe:
Andiamo sul complesso qui :D
L'assembly non si presta molto ad essere testato. A quel punto puoi scrivere il minimo indispensabile in assembly, essere ragionevolmente sicuro che funzioni, creare un contratto univoco con cui chiami le routine in assembly e poi creare dei Mock attorno. Non riuscirai a testare ogni singola riga di codice del kernel magari, pero' riesci ad isolare le parti non testabili automaticamente: le testerai manualmente, ben sapendo che ogni volta che sei costretto a testare qualcosa manualmente perdi del tempo. E' sempre meglio testare qualcosa piuttosto che non testare nulla.
DanieleC88
07-01-2006, 15:25
Dichiarala extern "C", e' standard C++ e spegne il name mangling delle funzioni.
Lo so, lo so, ma mettere #ifdef __cplusplus... extern "C" {... #endif... #ifdef __cplusplus... }... #endif e' una rottura praticamente inutile (che ci guadagno dall'usare il C++ per il kernel invece che il C99? Ben poco, in effetti, non mi serve e quindi non lo uso. YAGNI. :D).
Da un punto di vista piu' teorico, tu non devi testare, ad esempio, un servizio a basso livello fornito dall'hardware sul quale programmi il kernel, quel servizio e' "garantito" funzionare se tu segui il protocollo e rispetti il suo contratto. Allora quello che testi e' il fatto che rispetti il contratto stesso, segui tutte le specifiche e, al momento di fare la chiamata in un test la sostituisci con un oggetto vuoto (non proprio, semplifico un po').
Andiamo sul complesso qui :D
L'assembly non si presta molto ad essere testato. A quel punto puoi scrivere il minimo indispensabile in assembly, essere ragionevolmente sicuro che funzioni, creare un contratto univoco con cui chiami le routine in assembly e poi creare dei Mock attorno. Non riuscirai a testare ogni singola riga di codice del kernel magari, pero' riesci ad isolare le parti non testabili automaticamente: le testerai manualmente, ben sapendo che ogni volta che sei costretto a testare qualcosa manualmente perdi del tempo. E' sempre meglio testare qualcosa piuttosto che non testare nulla.
Effettivamente credo sia possibile, benche' complesso. Mi ci devo applicare un po' e magari metto su una piccola build machine per il kernellino. :D
Lo so, lo so, ma mettere #ifdef __cplusplus... extern "C" {... #endif... #ifdef __cplusplus... }... #endif e' una rottura praticamente inutile (che ci guadagno dall'usare il C++ per il kernel invece che il C99? Ben poco, in effetti, non mi serve e quindi non lo uso. YAGNI. :D).
Tutta la parte di type safety che ti controlla i tipi in maniera piu' precisa del C, le funzioni inline che sostituiscono la maggior parte degl'usi delle macro. Sostanzialmente un'ambiente piu' sicuro in cui programmare. Non e' certo uno YAGNI.
#ifdef __cplusplus
#define EXTERN_C extern "C"
#else
#define EXTERN_C
#endif
...
int EXTERN_C ItWillBeCalledFromAssembly();
... e passa la paura :)
jappilas
08-01-2006, 10:56
cercare tutti i messaggi di Fek, copiaincollarli in un file di testo, salvarlo come "Developer's Vademecum"...un giorno lo faccio....
ps: what's YAGNI ? :fagiano:
ps: what's YAGNI ? :fagiano:
You Aren't Going to Need It
o anche:
You Ain't Gonna Need It
Fai tu! :p
cercare tutti i messaggi di Fek, copiaincollarli in un file di testo, salvarlo come "Developer's Vademecum"...un giorno lo faccio....
Si potrebbe anche pubblicarli, ma poi toccherebbe pagargli i diritti d'autore... :Prrr:
EDIT: guarda guarda... http://xp.c2.com/YouArentGonnaNeedIt.html
jappilas
08-01-2006, 11:41
You Aren't Going to Need It o anche: You Ain't Gonna Need It
guarda guarda... http://xp.c2.com/YouArentGonnaNeedIt.html
ah ok ;)
ero tanto assorbito a rovistare tra package e "giare" (:D) in Eclipse da non rendermi conto che potevo evocare s. google con un click senza scomodarvi... :stordita:
Si potrebbe anche pubblicarli, ma poi toccherebbe pagargli i diritti d'autore... :Prrr:
non sarebbe a scopo di lucro, magari li concede in licenza a titolo gratuito.... ;)
DanieleC88
08-01-2006, 11:59
Tutta la parte di type safety che ti controlla i tipi in maniera piu' precisa del C, le funzioni inline che sostituiscono la maggior parte degl'usi delle macro. Sostanzialmente un'ambiente piu' sicuro in cui programmare. Non e' certo uno YAGNI.
Uhm... le funzioni inline non esistono anche in C? Ero sicuro di si.
#ifdef __cplusplus
#define EXTERN_C extern "C"
#else
#define EXTERN_C
#endif
...
int EXTERN_C ItWillBeCalledFromAssembly();
... e passa la paura :)
Ottima soluzione. ;)
cdimauro
08-01-2006, 18:54
Napoli Programming Squad :O
Ho vinto il panettone avanzato a Natale? :D
Qualcosa di più volgare. :(
Na.P.S. = Na Putiti Sucari (in siciliano).
Tradotto: "ce la potete xxx".
:(
cdimauro
08-01-2006, 18:55
Uhm... le funzioni inline non esistono anche in C? Ero sicuro di si.
Dipende dal compilatore decidere se espandere una funzione o no.
ilsensine
09-01-2006, 09:13
Dipende dal compilatore decidere se espandere una funzione o no.
inline è in effetti solo un hint, ma ci sono varianti per il "must/must not" (sono state usate a causa di alcune versioni del gcc, troppo o troppo poco aggressive per l'ottimizzazione inline).
Anche per il c++ l'uso di codice inline è lasciato all'ottimizzatore (non vorrai che il tuo template da 1000+ righe sia replicato pari pari ad ogni utilizzo, spero!) se non specificato altrimenti.
vBulletin® v3.6.4, Copyright ©2000-2026, Jelsoft Enterprises Ltd.