View Full Version : Dubbio sicurezza opensource
Dark_Sephirot86
29-12-2005, 19:22
E' da tempo che mi frulla in testa un dubbio.
Ma i programmi opensource non dovrebbero essere poco sicuri? Eppure perchè schiacciano così nettamente i prodotti a codice chiuso, in primis quelli di M3rdasoft?
In linea teorica un browser come Firefox o un sistema come Linux, avendo gli hacker pieno accesso al sorgente, dovrebbero essere traforabili come il burro, eppure perchè non lo sono?
E' da tempo che mi frulla in testa un dubbio.
Ma i programmi opensource non dovrebbero essere poco sicuri? Eppure perchè schiacciano così nettamente i prodotti a codice chiuso, in primis quelli di M3rdasoft?
In linea teorica un browser come Firefox o un sistema come Linux, avendo gli hacker pieno accesso al sorgente, dovrebbero essere traforabili come il burro, eppure perchè non lo sono?
Perchè il fatto che tutti sappiano dov'è il buco unita alla disponibilità del sorgente,consente a chiunque di chiudere la falla.
Non avendo i sorgenti, alcune falle di M$ si sono protratte per mesi e, fintanto che M$ non provvedeva, non poteva farlo nessuno.
Scoperchiatore
29-12-2005, 19:37
Non è che non lo sono, è che spesso sono testati molto di più proprio per questo motivo.
Difatti esistono tanti sistemi operativi che fanno della loro forza l'uso di SOLI programmi sicuri e testati,
perchè l'opensource permette una sorta di intelligenza collettiva, e l'avere il codice libero significa doversi concentrare sulla creazione di un buon codice
trovare un bug in prodotti tipo firefox è difficile perchè ci sono molti sviluppatori che lavorano per correggerli
in prodotti closed quest'attenzione è ovviamente minore perchè tanto non si può studiare il codice e si genere la falsa credenza che quei bug siano nascosti e difficili da trovare
L'open source nasce con lo scopo di creare una tecnologia migliore e far sì che tutti ne possano partecipare.
Il rencere pubblici i sorgenti da la possibilità di trovare i problemi (di qualsiasi natura) da parte della comunità molto prima che lo faccia un malintenzionato; e da la possibilità di chiudere i problemi anche in poche ore. Cosa impossibile con il modello di sviluppo classico.
E poi diciamolo, per la maggior parte delle volte, il software open è sempre software di ottima qualità.
Dark_Sephirot86
29-12-2005, 21:12
E poi diciamolo, per la maggior parte delle volte, il software open è sempre software di ottima qualità.
Questo è dimostrato dai fatti. Ma era appunto questo che faceva sorgere il mio dubbio. Il fatto che continuino ad uscire nuove versioni di FireFox dimostra che di bugs ce ne sono, anche perchè, avendo esperienza come programmatore (anche se sono pochi mesi che lo studio a scuola) so che fare un programma di quella complessità senza bugs non è difficile, è impossibile. Figuriamoci un OS!
Anche perchè non è detto che il bug che trovi la collettività e il malintenzionato sia lo stesso. Un malintenzionato non potrebbe forse trovare un bug che verrà corretto nella versione, che ne so, 1.7?
Questo è dimostrato dai fatti. Ma era appunto questo che faceva sorgere il mio dubbio. Il fatto che continuino ad uscire nuove versioni di FireFox dimostra che di bugs ce ne sono,
Una nuova versione non significa necessariamente un bug da correggere, anzi, solitamente significa miglioria. I bug sono contemplati nelle sottoversioni e nelle patch
Anche perchè non è detto che il bug che trovi la collettività e il malintenzionato sia lo stesso. Un malintenzionato non potrebbe forse trovare un bug che verrà corretto nella versione, che ne so, 1.7?
Nel caso un malintenzionato trovi un bug e se ne avvalga, ovvio che qualcuno ne subisce le conseguenze in mancanza di una patch.
Ma dall'analisi dell'attacco si capisce dov'è il bug e si corre ai ripari.
Subito! non è che si dice "Ok, correggo poi rilascio assieme alla versione prevista per il prossimo anno" ;)
Questo vuol dire che viene rilasciata una patch (per chi la sa applicare) e/o una sottoversione dell'applicativo per chi deve ancora installare.
Artemisyu
29-12-2005, 21:41
Un malintenzionato non potrebbe forse trovare un bug che verrà corretto nella versione, che ne so, 1.7?
Il procedimento logico è inverso.
E' la scoperta di nuovi bug che genera il rilascio della maggiorparte delle release :)
Non è che il rilascio di una nuova versione pianifica che vengano introdotte delle correzioni di bug noti :)
Quest'ultimo è un metodo di sviluppo tipico dei programmi a codice chiuso :)
E' da tempo che mi frulla in testa un dubbio.
Ma i programmi opensource non dovrebbero essere poco sicuri? Eppure perchè schiacciano così nettamente i prodotti a codice chiuso, in primis quelli di M3rdasoft?
In linea teorica un browser come Firefox o un sistema come Linux, avendo gli hacker pieno accesso al sorgente, dovrebbero essere traforabili come il burro, eppure perchè non lo sono?
che la security throug obscurity si sia dimostrata la tecnica perdente è ormai provato, basta vedere il ciclo di aggiornamenti di firefox e quello di ie.
Un po di tempo fa avevo letto il post di uno che diceva una cosa simile: avere il codice sorgente disponibile in un sistema operativo è come mettere l'allarme in casa e scrivere il codice per spegnerlo sulla porta.
Sbagliato:
avere il codice disponibile è come mettere l'allarme in casa e il suo schema di funzionamento: sai come funziona, ma l'allarme c'è lo stesso.
Poi tu mi dici: si ma se lo schema di funzionamento mi fa capire che il filo rosso stacca l'allarme, siamo daccapo.
E qui la risposta: il problema è che anche chiunque possa leggere quello schema può vedere che li c'è una debolezza e modificare un attimo l'impianto.
Esatto, in più se sai di scrivere software aperto stai attento a cosa scrivi per paura di fare figuracce :D
Di buchi ce ne sono ovunque, è impossibile scrivere programmi senza buchi, per quanto uno ci sta attento qualcosa scappa e se non scappa a lui è scappato a quelli che hanno scritto le librerie che usa. In più molti programmatori non sanno come scrivere in modo da evitare buchi, a loro basta che funzioni, soprattutto quando hai il fiato di qualche scadenza sul collo ti lasci scappare qualche controllo.
Il discorso è proprio quello di dare la possibilità di controllare cosa si ha in mano, che poi la maggior parte degli utenti non guardi il codice è un'altro discorso, l'importante è averne la possibilità.
Correggere un buco senza avere i sorgenti a disposizione è un'impresa ed è pure illegale! E' lo stesso discorso del filo rosso, una cosa è vederlo un'altra è poter fare in modo che non basti quello a staccare l'allarme.
cdimauro
03-01-2006, 15:28
Ma i programmi opensource non dovrebbero essere poco sicuri?
Non esiste una metrica oggettiva relativa alla "sicurezza" di un sistema: dovresti chiarire cosa intendi con ciò.
Eppure perchè schiacciano così nettamente i prodotti a codice chiuso, in primis quelli di M3rdasoft?
In base a cosa "Schiaccerebbero" i prodotti MS?
In linea teorica un browser come Firefox o un sistema come Linux, avendo gli hacker pieno accesso al sorgente, dovrebbero essere traforabili come il burro, eppure perchè non lo sono?
Anche in linea pratica è così. Tant'è che sono stati hackerati un sito della NASA, Debian, GNU e qualcun altro di cui adesso non ricordo il nome.
cdimauro
03-01-2006, 15:35
Perchè il fatto che tutti sappiano dov'è il buco unita alla disponibilità del sorgente,consente a chiunque di chiudere la falla.
Ma se ne possono aprire anche altre. Adesso non ricordo la fonte, ma da un'indagine relativa al bug fix di un prodotto, risultava che statisticamente il 15% dei bug fix aveva generato degli ulteriori bug.
Se questo dato riguarda società di grosso calibro, che adottano metodologie consolidate dell'ingegneria del software, si può intuire che il bug fix condotto da persone che non rispecchiano gli stessi "standard qualitativi" dev'essere sicuramente peggiore.
Il fatto di avere disponibile il fix dopo poche ore dall'individuazione del bug, fa pensare che la fase di testing sia stata ridotta al lumicino, con le conseguenze che ne possono derivare.
E' di gran lunga preferibile un workaround a un bug noto, in attesa di un fix che passi una consistente fase di test, piuttosto che un fix rilasciato troppo fretta e che può portare facilmente ad altri bug sconosciuti (e quindi potenzialmente dannosi).
cdimauro
03-01-2006, 15:38
Non è che non lo sono, è che spesso sono testati molto di più proprio per questo motivo.
Vedi sopra: è tutto da vedere.
Difatti esistono tanti sistemi operativi che fanno della loro forza l'uso di SOLI programmi sicuri e testati,
Non esiste una metrica che definisca oggettivamente la sicurezza di un sistema: in base a cosa puoi definire un'applicazione "sicura"?
Quanto ai test, non bastano mai. Proprio per questo sono nate metodologie di sviluppo "test driven", ma non è che si risolve del tutto il problema: il bug è sempre dietro l'angolo, anche se la percentuale di falle per righe di codice (ad esempio) può risultare più ridotta.
Quanti sistemi / applicazioni open source adottano metodologie come questa?
ilsensine
03-01-2006, 15:41
Tant'è che sono stati hackerati un sito della NASA, Debian, GNU e qualcun altro di cui adesso non ricordo il nome.
www.microsoft.com , www.microsoft.com/uk , www.cdimauro.net .. :p
cdimauro
03-01-2006, 15:49
perchè l'opensource permette una sorta di intelligenza collettiva, e l'avere il codice libero significa doversi concentrare sulla creazione di un buon codice
:rotfl: Non scherziamo con le cose serie: "l'intelligenza collettiva" ce l'ha anche un gruppo che lavora a un'applicazione. Inoltre il codice di buona fattura lo si crea adottando rigorose metodologie di sviluppo, non mettendosi davanti alla tastiera.
L'open source non c'entra proprio nulla.
trovare un bug in prodotti tipo firefox è difficile perchè ci sono molti sviluppatori che lavorano per correggerli
in prodotti closed quest'attenzione è ovviamente minore perchè tanto non si può studiare il codice e
Forse dimentichi che per un team di sviluppo il codice è per forza di cose a disposizione: altrimenti non potrebbe lavorarci nessuno.
Quanto al personale "esterno" che lavora nel campo della sicurezza, può effettuare delle prove sulle API, "giocando" opportunamente sui parametri. Tante falle di sicurezza vengono trovate così dalle agenzie specializzate in questo settore.
Altre falle si trovano effettuando il tracing del codice o il disassemblaggio di porzioni di esso.
si genere la falsa credenza che quei bug siano nascosti e difficili da trovare
I bug, in quanto tali, rimangono nascosti finché non si trovano.
Comunque è indubbiamente più difficile trovare dei bug per del personale esterno, senza avere a disposizione dei sorgenti.
cdimauro
03-01-2006, 15:51
www.microsoft.com , www.microsoft.com/uk , www.cdimauro.net .. :p
:rotfl: Ma vuoi farmi morire? :p
cdimauro
03-01-2006, 15:57
L'open source nasce con lo scopo di creare una tecnologia migliore e far sì che tutti ne possano partecipare.
L'open source non è una "tecnologia": è soltanto una diversa forma di fruizione di un prodotto.
Il rencere pubblici i sorgenti da la possibilità di trovare i problemi (di qualsiasi natura) da parte della comunità molto prima che lo faccia un malintenzionato;
Ampiamente opinabile: i cacciatori di bug "buoni" e quelli "cattivi", a parità di "capacità acquisite", hanno la stessa probabilità di beccare un bug leggendo un sorgente, ma questo non vuol implica assolutamente che i buoni troveranno i bug prima dei cattivi; sono due cose completamente diverse.
e da la possibilità di chiudere i problemi anche in poche ore.
Vedi sopra: bisogna stare attenti, perché non è certo bello fixare un bug per poi ritrovarsene un altro. Anche perché questi sono i bug più "bastardi", in quanto il codice in oggetto viene ingenuamente considerato "sicuro" proprio grazie al bug fix che ha subito.
Cosa impossibile con il modello di sviluppo classico.
Per quanto riguarda la quantità di manodopera, sicuramente.
Per quanto riguarda le metodologie di sviluppo e relativo mantenimento / bug fix, è tutto da vedere.
E poi diciamolo, per la maggior parte delle volte, il software open è sempre software di ottima qualità.
Ti riferisci ai sorgenti prodotti, o al prodotti di per sé? In entrambi i casi, la tua affermazione è ampiamente opinabile.
cdimauro
03-01-2006, 16:03
Questo è dimostrato dai fatti.
Di quali fatti parli?
Ma era appunto questo che faceva sorgere il mio dubbio. Il fatto che continuino ad uscire nuove versioni di FireFox dimostra che di bugs ce ne sono, anche perchè, avendo esperienza come programmatore (anche se sono pochi mesi che lo studio a scuola) so che fare un programma di quella complessità senza bugs non è difficile, è impossibile. Figuriamoci un OS!
Esatto: è impossibile. In generale, dato un qualunque algoritmo, è dimostrabile che non è possibile sapere se sia privo di bug o meno.
Inoltre il fatto che negli ultimi tempi le segnalazioni di bug di FireFox sono aumentate, la dice lunga su quanto pesi il fattore diffusione di un prodotto.
Anche perchè non è detto che il bug che trovi la collettività e il malintenzionato sia lo stesso. Un malintenzionato non potrebbe forse trovare un bug che verrà corretto nella versione, che ne so, 1.7?
Infatti. E potrebbe anche sfruttarlo prima che qualcun altro lo scopra, segnali e arrivi il fix.
Artemisyu
03-01-2006, 16:03
Ti riferisci ai sorgenti prodotti, o al prodotti di per sé? In entrambi i casi, la tua affermazione è ampiamente opinabile.
Egregio dottore, ma quand'è che l'open source ha cominciato a starti tanto sulle palle?
Io non capisco tutto quest'astio per un modello di sviluppo che si è generato quasi da solo, si è reso operativo in pochissimo tempo e che si è dimotrato vincente, permettendo grandissimi progressi in pochissimo tempo?
GNU/Linux è un sistema che più persone lo usano più rapidamente si sviluppa, e ha rosicchiato fette enormi di mercato (nel campo server, ovviamente) in un tempo ridotto, dimostrando spesso e volentieri un prodotto più versatile, scalabile, adattabile ad ogni situazione, e molto più conveniente.
Gran parte dei costi inferiori e della dimostrada qualità del prodotto è proprio da trovarsi nel modello di sviluppo che contesti tanto.
ciao ciao!
cdimauro
03-01-2006, 16:09
Una nuova versione non significa necessariamente un bug da correggere, anzi, solitamente significa miglioria. I bug sono contemplati nelle sottoversioni e nelle patch
I bug sono contemplati SEMPRE, sia che si effettui manutenzione / bugfix di un prodotto, sia (e a maggior ragione) se vengono introdotte altre modifiche / funzionalità.
Nel caso un malintenzionato trovi un bug e se ne avvalga, ovvio che qualcuno ne subisce le conseguenze in mancanza di una patch.
Ma dall'analisi dell'attacco si capisce dov'è il bug e si corre ai ripari.
L'analisi non è affatto facile: dal solo "comportamento anomalo" può essere molto difficile scoprire la causa.
Subito! non è che si dice "Ok, correggo poi rilascio assieme alla versione prevista per il prossimo anno"
Questo vuol dire che viene rilasciata una patch (per chi la sa applicare) e/o una sottoversione dell'applicativo per chi deve ancora installare.
Subito significa anche rilasciare un prodotto che ha un'elevata probabilità di aver generato altri bug.
cdimauro
03-01-2006, 16:17
che la security throug obscurity si sia dimostrata la tecnica perdente è ormai provato, basta vedere il ciclo di aggiornamenti di firefox e quello di ie.
L'analisi, pure superficiale, di un caso specifico, non dimostra la generalità di un concetto.
Inoltre la sicurezza basata sul rilascio dei sorgenti e quella sul non rilascio sono due lati della stessa medaglia, che è appunto la sicurezza. Sono mutualmente esclusive e la prima non fa affatto fuori la seconda (in termini di sicurezza). Tutt'altro.
Hanno entrambi pregi e difetti proprie della scelta effettuata, ma nessuno dei due rappresenta la soluzione al problema della sicurezza di un sistema (in generale. Nello specifico è da vedere, caso per caso, in base agli obiettivi che ci si pone).
Un po di tempo fa avevo letto il post di uno che diceva una cosa simile: avere il codice sorgente disponibile in un sistema operativo è come mettere l'allarme in casa e scrivere il codice per spegnerlo sulla porta.
Sbagliato:
avere il codice disponibile è come mettere l'allarme in casa e il suo schema di funzionamento: sai come funziona, ma l'allarme c'è lo stesso.
Poi tu mi dici: si ma se lo schema di funzionamento mi fa capire che il filo rosso stacca l'allarme, siamo daccapo.
E qui la risposta: il problema è che anche chiunque possa leggere quello schema può vedere che li c'è una debolezza e modificare un attimo l'impianto.
Solo che nel frattempo io sarò già entrato in casa tua e l'avrò svaligiata. :asd:
Poi puoi anche trovare la falla, modificare lo scherma e ripubblicarlo: tornerò a studiarmelo, e appena ne troverò un'altra che ti sarà sfuggita ti fregherò ancora. :D
Proprio questo è un caso in cui la security through obscurity dimostra la sua indubbia validità. ;)
www.cdimauro.net .. :p
Difatti il sito sembra ancora non reperibile.. :O
Ma quanto ci metti a ripararlo?
:D
cdimauro
03-01-2006, 16:28
Esatto, in più se sai di scrivere software aperto stai attento a cosa scrivi per paura di fare figuracce :D
A giudicare da tanto software open source che ho visto, sono in molti a non preoccuparsi delle figuracce... :asd:
In più molti programmatori non sanno come scrivere in modo da evitare buchi,
Se conosci un modo per scrivere programmi senza bug, fammelo sapere: ti assicuro che diventiamo miliardari.
Ti risparmio la fatica: NON ESISTE nessun metodo del genere e MAI esisterà.
a loro basta che funzioni, soprattutto quando hai il fiato di qualche scadenza sul collo ti lasci scappare qualche controllo.
Se lo fai di proposito, sei un folle (e non sei assolutamente un professionista; a meno che non ti sia stata data carta da bianca dal tuo responsabile).
Se lo fai per distrazione, è una cosa normale: può capitare a tutti, anche a chi ha parecchi anni di esperienza alle spalle e adotta solide metodologie di sviluppo.
Il discorso è proprio quello di dare la possibilità di controllare cosa si ha in mano, che poi la maggior parte degli utenti non guardi il codice è un'altro discorso, l'importante è averne la possibilità.
Questa possibilità ce l'hai anche senza avere i sorgenti in mano. ;)
Correggere un buco senza avere i sorgenti a disposizione è un'impresa ed è pure illegale!
Correggere un bug è interesse di chi ha sviluppato il software, non di chi l'ha trovato e non ha a disposizione i sorgenti.
Inoltre non credo che sia illegale: lo è aggirare le protezioni in tanti paesi, e in altri il reverse engineering, ma non la correzione di un bug di per sé (a meno che non si sia violata una delle due).
E' lo stesso discorso del filo rosso, una cosa è vederlo un'altra è poter fare in modo che non basti quello a staccare l'allarme.
Se non basta quello, se ne troverà un altro. Il nocciolo della questione sta tutta qui.
Mettiamo che tu debba collegare il nocciolo di una centrale nucleare all'esterno: renderesti disponibili i sorgenti e gli schemi del sistema oppure no? Nel primo caso faresti la felicità di gente come Bin Laden. :p
cdimauro
03-01-2006, 16:39
Egregio dottore,
Quando qualcuno comincia a tirare in ballo il (mio) titolo, è segno che non è in grado di discutere tranquillamente. Questo è statisticamente dimostrabile. ;)
ma quand'è che l'open source ha cominciato a starti tanto sulle palle?
Mai. Tant'è che lo uso. Mi faresti vedere da cosa l'avresti dedotto, cortesemente?
Io non capisco tutto quest'astio
Lo vedi soltanto tu.
per un modello di sviluppo che si è generato quasi da solo,
Guarda che l'open source esiste da quando il software stesso ha fatto capolino sulla faccia della Terra.
si è reso operativo in pochissimo tempo e che si è dimotrato vincente, permettendo grandissimi progressi in pochissimo tempo?
Questo è tutto da vedere.
GNU/Linux è un sistema che più persone lo usano più rapidamente si sviluppa,
Ma nonostante tutto non riesce a competere nemmeno con Windows (figuriamoci OS X) come soluzione desktop: perché?
e ha rosicchiato fette enormi di mercato (nel campo server, ovviamente) in un tempo ridotto, dimostrando spesso e volentieri un prodotto più versatile, scalabile, adattabile ad ogni situazione, e molto più conveniente.
Anche questo è tutto da vedere. In ambito server, per le sue caratteristiche, ha avuto un grande successo, ma sul versante desktop la situazione non è affatto la stessa.
Gran parte dei costi inferiori e della dimostrada qualità del prodotto
Cosa intendi per "qualità"? Ti riferisci ai sorgenti o all'applicazione "in esecuzione"? In entrambi i casi, ci sarebbe parecchio da dire. Ma questo NON dipende strettamente dal modello di sviluppo, quanto dalle metodologie (di sviluppo) adottate e dallo spreco di risorse (troppa poca organizzazione, forking, ecc.).
Fortunatamente lo sviluppo del kernel (cioé Linux) è in mano a un'oligarchia, e procede piuttosto bene, seppur con qualche intoppo (ma i bug, come già detto, sono una caratteristica intrinseca del software).
è proprio da trovarsi nel modello di sviluppo che contesti tanto.
ciao ciao!
Io non lo contesto affatto. Anzi, ho detto chiaramente che open e closed source sono due facce della stessa medaglia, nell'ambito della sicurezza (ed era questo l'argomento di discussione del thread), e che certi risultati dipendono dalle metodologie adottate e NON dal fatto che un prodotto sia open o closed.
cdimauro
03-01-2006, 16:40
Difatti il sito sembra ancora non reperibile.. :O
Ma quanto ci metti a ripararlo?
:D
Ho avuto per un anno un dominio e relativo spazio web: non ho mai messo neppure una paginetta HTML scritta a mano con scritto "Lavori in corso..." :p
Correggere un bug è interesse di chi ha sviluppato il software, non di chi l'ha trovato e non ha a disposizione i sorgenti.
Sarà, ma se il motore cigola preferisco avere la libertà di aprire il cofano e stringermi la vitina piuttosto che andare in officina e farmi smontare mezza automobile senza capire esattamente cosa gli è successo. La libertà di intervenire, quindi, fa una grande differenza. Ovvio che la faccia anche per chi guadagna dal fatto che il software sia chiuso e veda nell'opensource svanire una discreta somma, ma è il prezzo da pagare quando la gente prende coscienza del proprio diritto alla conoscenza e alla trasparenza.
perchè l'opensource permette una sorta di intelligenza collettiva, e l'avere il codice libero significa doversi concentrare sulla creazione di un buon codice
Immagino tu non abbia mai dato un'occhiata ad esempio al codice sorgente di Firefox oppure ai sorgenti del kernel di Linux? Non sono proprio un fulgido esempio di "buon codice".
Sarà, ma se il motore cigola preferisco avere la libertà di aprire il cofano e stringermi la vitina piuttosto che andare in officina e farmi smontare mezza automobile senza capire esattamente cosa gli è successo. La libertà di intervenire, quindi, fa una grande differenza. Ovvio che la faccia anche per chi guadagna dal fatto che il software sia chiuso e veda nell'opensource svanire una discreta somma, ma è il prezzo da pagare quando la gente prende coscienza del proprio diritto alla conoscenza e alla trasparenza.
Se non fosse che il motore di un'automobile non e' proprio la stessa cosa del software. Sono due "oggetti" profondamente differenti.
Mi sembrano le contestazioni che fa un dipendente di M$ ben istruito da Bill, comunque ....
;)
I bug sono contemplati SEMPRE, sia che si effettui manutenzione / bugfix di un prodotto, sia (e a maggior ragione) se vengono introdotte altre modifiche / funzionalità.
Non ho detto il contrario. Ho detto che non si attende una nuova release per correggere il bug e che non esce una nuova release solo per correggere un bug.
L'analisi non è affatto facile: dal solo "comportamento anomalo" può essere molto difficile scoprire la causa.
Tu chiami comportamento anomalo un modem che si scollega e ricollega, un PC che genera elevato traffico, il disco che ti si riempie ?
L'analisi è comunque più facile se hai il sorgente, piuttosto che no.
Se ci lavori un po' come programmatore, dovresti sapere che dal comportamento anomalo, come lo chiami tu, non risali mai alla causa, ma a cio' che l'ha generato. Da lì parti a circoscrivere il problema, analizzi il codice relativo a quella porzione e vai alla causa.
Subito significa anche rilasciare un prodotto che ha un'elevata probabilità di aver generato altri bug.
Non è che per forza di cose, se cambi una riga tra true a false apri nuovi bugs ;) e comunque preferisco che venga tappato subito un bug noto e rischiare per un bug non noto (che darà un po' da studiare), che non stare con le braghe calate ad aspettare che M$
1) raccolga tot segnalazioni per prenderlo in considerazione
2) indica una riunione per valutare il problema
3) organizzi un piano di intervento
4) istituisca una commissione di sorveglianza
... pausa caffè....
5) distribuisca i pezzi di codice a vari sottogruppi.
La patch che ne uscirà avra meno bugs (dubito), ma nel frattempo mi hanno rigirato per bene il computer oppure ho dovuto staccarlo dalla rete con i danni che ne conseguono.
P.S.:
Non sono sicuro, ma a differenza di quello che dici, credo che in M$ pochi abbiano la visibilità completa del codice; per lo più ricevono incarico di sviluppare su specifica delle porzioni che poi qualcun altro riassemblerà.
Solo che nel frattempo io sarò già entrato in casa tua e l'avrò svaligiata. :asd:
Poi puoi anche trovare la falla, modificare lo scherma e ripubblicarlo: tornerò a studiarmelo, e appena ne troverò un'altra che ti sarà sfuggita ti fregherò ancora. :D
Proprio questo è un caso in cui la security through obscurity dimostra la sua indubbia validità. ;)
Ti contraddici ;)
Nell'attesa che chi produce l'allarme ne rilasci un nuovo modello, il ladro, senza bisogno di impegnarsi in nuovi studi, svaligia l'intera città, non la casa e quando l'antifurto sarà pronto, non ci sarà più niente da proteggere.
Pensaci Bill ;)
Mi sembrano le contestazioni che fa un dipendente di M$ ben istruito da Bill, comunque ....
;)
A me le tue invece sembrano le contestazioni che fa un dipendente di Sun ben istruito ;)
Artemisyu
03-01-2006, 16:53
Mai. Tant'è che lo uso. Mi faresti vedere da cosa l'avresti dedotto, cortesemente?
Dal fatto che è un continuo far notare punti deboli di questo sistema di sviluppo, preferendo addirittura un attività di bugfixing interna all'azienda rispetto alla revisione paritaria del codice.
Guarda che l'open source esiste da quando il software stesso ha fatto capolino sulla faccia della Terra.
Appunto.
E comunque non era l'opensource che conosciamo oggi.
Ma nonostante tutto non riesce a competere nemmeno con Windows (figuriamoci OS X) come soluzione desktop: perché?
Perchè linux non è una soluzione desktop.
Lo si può usare su un desktop ovviamente, al prezzo di qualche compromesso.
Cosa intendi per "qualità"? Ti riferisci ai sorgenti o all'applicazione "in esecuzione"? In entrambi i casi, ci sarebbe parecchio da dire. Ma questo NON dipende strettamente dal modello di sviluppo, quanto dalle metodologie (di sviluppo) adottate e dallo spreco di risorse (troppa poca organizzazione, forking, ecc.).
Mi riferisco al fatto che ho dovuto smettere di propinare GNU/Linux ai miei clienti, perchè dopo l'installazione ed un po' di formazione, il sistema andava talmente bene che si dimenticavano della mia esistenza, ed io non guadagnavo più una lira.
Questo, in un modo o nell'altro, è "qualità".
Artemisyu
03-01-2006, 16:54
Mi sembrano le contestazioni che fa un dipendente di M$ ben istruito da Bill, comunque ....
;)
Concordo.
Io fossi in lui farei una bella donazione alla SCO, che sta portando avanti una crociata molto simile alla sua su questo forum. :D
ciao ciao!
Dal fatto che è un continuo far notare punti deboli di questo sistema di sviluppo, preferendo addirittura un attività di bugfixing interna all'azienda rispetto alla revisione paritaria del codice.
Non ci vuole una chissa' quale preparazione in Ingegneria del Software per capire come un'attivita' di bugfixing e relativo testing ben strutturata e basata su metodologie formali all'interno di un'azienda sia meno costosa e piu' sicura del "trova il bug, fixalo subito e rilascia il fix il prima possibile" tipico di molte produzioni open source (non tutte).
Ma il punto fondamentale e' che state proprio prendendo tutti un'incredibile cantonata perche' state parlando di fischi per fiaschi :)
Open Source NON e' una metodologia di sviluppo, e' un modello di distribuzione del software. NON c'entra nulla con la metodologia di sviluppo e non c'entra nulla con la bonta' o meno del codice che dipende solo dalla metodologia di sviluppo.
A giudicare da tanto software open source che ho visto, sono in molti a non preoccuparsi delle figuracce... :asd:
Prima di fare questa affermazione, dovresti solo sforzarti di ripensare a quella scena in cui un certo Bill Gates, alla presentazione del suo bel closed source (mi pare Win98), attaccò uno scanner per dimostrare la potenzialità del suo prodotto e venne fuori una schermata blu.
A me sarebbe venuta voglia di spararmi per una figuraccia simile in mondovisione :Prrr:
Immagino tu non abbia mai dato un'occhiata ad esempio al codice sorgente di Firefox oppure ai sorgenti del kernel di Linux? Non sono proprio un fulgido esempio di "buon codice".
Sono sicuro che tu potrai avere valutato la bontà del codice M$, per fare un paragone !
Ah, dimenticavo, a meno che non lavori in M$ non hai potuto :D
Peccato, perché altrimenti mi potevi spiegare cosa ci faceva un simulatore di volo nascosto, se non erro, in Word.
Era per dare dimostrazione dell'ottima qualità del codice ;) ??
Sono sicuro che tu potrai avere valutato la bontà del codice M$, per fare un paragone !
Ah, dimenticavo, a meno che non lavori in M$ non hai potuto :D
Peccato, perché altrimenti mi potevi spiegare cosa ci faceva un simulatore di volo nascosto, se non erro, in Word.
Era per dare dimostrazione dell'ottima qualità del codice ;) ??
Aspetta, sto cercando di capire una cosa, la tua e' una guerra personale contro MS (perche' io non ho citato MS) oppure una disamina dei modelli di sviluppo e distribuzione del software?
(Si', ho avuto la possibilita' di guardare molto codice e metodologie di sviluppo MS, no, non lavoro in MS, no, non tutto il codice prodotto da MS e' di ottima qualita', si' molto codice prodotto da MS e' di buona qualita')
Se non fosse che il motore di un'automobile non e' proprio la stessa cosa del software. Sono due "oggetti" profondamente differenti.
Un esempio come un altro, ma non ce n'era un reale bisogno. La libertà dell'opensource è chiara a tutti, anche a chi sviluppa software closed e se mi ero permesso di fare un esempio, era solo perchè sembra che certe posizioni pro-closed eludano sistematicamente la questione libertà. Anche in questo caso, senza offesa, mi sembra che non si sia preso nemmeno in esame il concetto espresso da me e ci si sia limitati a notare che un motore di un'auto non è un software. Puntualizzazione che francamente non comprendo, soprattutto perchè non in merito a ciò che stavo dimostrando. E allora, per evitare che questo circo si protragga in eterno, sarò banalmente chiaro: il software aperto mi da una libertà che il software chiuso mi toglie. E io la libertà non la baratto con niente.
Un esempio come un altro, ma non ce n'era un reale bisogno. La libertà dell'opensource è chiara a tutti, anche a chi sviluppa software closed e se mi ero permesso di fare un esempio, era solo perchè sembra che certe posizioni pro-closed eludano sistematicamente la questione libertà. Anche in questo caso, senza offesa, mi sembra che non si sia preso nemmeno in esame il concetto espresso da me e ci si sia limitati a notare che un motore di un'auto non è un software. Puntualizzazione che francamente non comprendo, soprattutto perchè non in merito a ciò che stavo dimostrando. E allora, per evitare che questo circo si protragga in eterno, sarò banalmente chiaro: il software aperto mi da una libertà che il software chiuso mi toglie. E io la libertà non la baratto con niente.
La puntualizzazione e' semplicissima: un motore non e' un software, si costruiscono e si modificano in maniere differenti, hanno comportamenti differenti, non possono essere assimilati. Fare un esempio su uno non dice nulla sul comportamento dell'altro.
Come in questo caso. Il discorso sulla liberta' lascia il tempo che trova, in realta' mi sembra solo una scusa per difendere una posizione a priori (in mancanza di argomenti piu' convincenti). Soprattutto considerando che anche con il software rilasciato con molte tipologie di licenza open source tu NON hai la liberta' di modificarlo, immagino sia questa la liberta' che ti sta tanto a cuore.
Adesso quindi per coerenza ti dovresti scagliare non contro il modello di distribuzione open o closed, ma contro le licenze.
Infine, la tua liberta' finisce dove inizia quella degl'altri: se chi ha sviluppato del codice non vuole che tu lo modifichi, non hai alcuna liberta' di farlo. Ed e' giusto che sia cosi', io che scrivo codice ho la liberta' di decidere in che forma distribuirlo.
Il discorso sulla liberta' lascia il tempo che trova, in realta' mi sembra solo una scusa per difendere una posizione a priori (in mancanza di argomenti piu' convincenti).
Considerare la libertà una scusa non ha molto senso, essendo essa un bene primario in ogni contesto.
Soprattutto considerando che anche con il software rilasciato con molte tipologie di licenza open source tu NON hai la liberta' di modificarlo, immagino sia questa la liberta' che ti sta tanto a cuore.
Adesso quindi per coerenza ti dovresti scagliare non contro il modello di distribuzione open o closed, ma contro le licenze.
Non capisco come mai, a piacimento, si critichi il "tutto" in certi casi e il "dettaglio" in altri. Parlavamo di software aperto e chiuso? In quello aperto ci guardo dentro, in quello chiuso no. Non mi riesce di dirlo con meno parole, mi spiace.
Infine, la tua liberta' finisce dove inizia quella degl'altri: se chi ha sviluppato del codice non vuole che tu lo modifichi, non hai alcuna liberta' di farlo. Ed e' giusto che sia cosi', io che scrivo codice ho la liberta' di decidere in che forma distribuirlo.
Anche qui non capisco: qualcuno ha chiesto la crocefissione di chi sviluppa codice chiuso? No, per me può anche stamparselo, arrotolarlo e fumarlo in solitudine, io esprimo una preferenza da utente verso il software aperto. Va da se che, col progredire e l'espandersi del modello opensource, tanti "licenziatori" che con gelosa cura certosina hanno blindato il loro codice, si ritroveranno scartati in favore di soluzioni che garantiscono meglio la libertà della gente e il diritto per essa di sviluppare e usare software nato dal lavoro comunitario e collettivo. Mi spiace se questo porterà ad un danno verso i suddetti licenziatori, ma è un effetto collaterale: potevano perdere meno tempo dall'avvocato ed impiegarlo a cooperare nella comunità open, ci avrebbero gudagnato loro e ci avrebbero fatto guadagnare gli altri. ;)
Considerare la libertà una scusa non ha molto senso, essendo essa un bene primario in ogni contesto.
Stai parlando del sesso degl'angeli :)
Non capisco come mai, a piacimento, si critichi il "tutto" in certi casi e il "dettaglio" in altri. Parlavamo di software aperto e chiuso? In quello aperto ci guardo dentro, in quello chiuso no. Non mi riesce di dirlo con meno parole, mi spiace.
Piuttosto che sintetizzare ulteriormente, invece, ti prego di usare piu' parole perche' stai facendo molta confusione. Il poter guardare dentro il codice non e' una liberta' inalienabile dell'uomo. E' come se mi dicessi che vuoi essere libero di guardare nella mia camera da letto... no, puoi guardarci solo se te lo permetto e non te lo permetto ovviamente :)
Se ti permetto di guardare dentro il mio codice, sei libero di farlo, altrimenti non lo sei. Io ho la liberta' di decidere che cosa fare del mio codice. E' la mia unica critica alla filosofia della FSF che piu' che un'inneggiare alla liberta' mi sembra un negare la liberta' altrui a favore dei propri interessi.
Nei confronti dell'Open Source come modello di distribuzione del software, al contrario, non ho nulla in contrario: e' una possibilita', a volte e' un'opzione utile per determinate situazioni, altre volte no.
Se ho bisogno di scrivere una versione pesantemente custom di un software ho bisogno di una versione open source. Se ho bisogno di un software life critical o mission critical per nessun motivo potrei affidarmi al software open source perche' se qualcosa andasse storto in quel software nessuno ne sarebbe responsabile.
Per ogni problema, c'e' lo strumento adatto.
Anche qui non capisco: qualcuno ha chiesto la crocefissione di chi sviluppa codice chiuso?
Si', chiunque critichi il software closed con la scusa che vuole essere libero di guardarlo e modificarlo. No, non sei libero di guardare e modificare quello che produce qualcun altro a meno che questo qualcuno non ti conceda questa liberta'. Spero che il concetto sia chiaro ora.
Ho citato l'FSF, elaboro un attimo il concetto. Quando leggo che tutto il software deve essere open in nome di una non meglio precisata liberta' di informazione mi gira il sangue al contrario. E' come se qualcuno mi dicesse che in ogni bagno deve esserci una telecamera cosi' chiunque puo' guardarmi mentre faccio i bisogni in nome della liberta' di informazione. Follia pura.
Artemisyu
03-01-2006, 19:10
Ho citato l'FSF, elaboro un attimo il concetto. Quando leggo che tutto il software deve essere open in nome di una non meglio precisata liberta' di informazione mi gira il sangue al contrario. E' come se qualcuno mi dicesse che in ogni bagno deve esserci una telecamera cosi' chiunque puo' guardarmi mentre faccio i bisogni in nome della liberta' di informazione. Follia pura.
Mi si gela A ME il angue nele vene a vedere che riesci a pensare una cosa del genere.
il software è un ene di consumo qualsiasi, lo si usa per raggiungere degli scopi, punto e basta.
Come fai a confonderlo con la privacy non lo capisco.
Un software non è un "informazione personale" di chi l'ha programmato.
Mi semra che tu non abbia capito proprio una sega di cosa vuol dire "free software"
Open Source NON e' una metodologia di sviluppo, e' un modello di distribuzione del software. NON c'entra nulla con la metodologia di sviluppo e non c'entra nulla con la bonta' o meno del codice che dipende solo dalla metodologia di sviluppo.
La GPL è un modello di distribuzione del software. L'open source è un modello di sviluppo, che nella sua forma più pura consente a tutti di partecipare allo sviluppo e di un progetto o al suo sfruttamento commericale. E questo, non c'era nulla con la ridistribuzione del codice.
Tornando a cdimauro:
L'open source non è una "tecnologia": è soltanto una diversa forma di fruizione di un prodotto.
E quando mai avrei detto che è una tecnologia? :=)
Ampiamente opinabile: i cacciatori di bug "buoni" e quelli "cattivi", a parità di "capacità acquisite", hanno la stessa probabilità di beccare un bug leggendo un sorgente, ma questo non vuol implica assolutamente che i buoni troveranno i bug prima dei cattivi; sono due cose completamente diverse.
Certo, ma le cose cambiano se sono 100 che lo fanno a fin di bene contro 10 che lo fanno con cattive intenzioni. 100 persone hanno più possibilità di 10 persone.
Vedi sopra: bisogna stare attenti, perché non è certo bello fixare un bug per poi ritrovarsene un altro. Anche perché questi sono i bug più "bastardi", in quanto il codice in oggetto viene ingenuamente considerato "sicuro" proprio grazie al bug fix che ha subito.
Anche con il modello di sviluppo open source, si testano i cambiamenti apportati :-) Esempio. FireFox ha una vulnerabilità documentata. La patch è già pronta, chi vuole può già applicarla, ma la nuova sottoversione verrà rilasciata solo dopo 5 giorni di testing.
Inoltre, è troppo generico. Sfido io la Microsoft a volerci fare del testing di mesi, quando viene scoperta una vulnerabilità di grado critico in un suo prodotto.
Ti riferisci ai sorgenti prodotti, o al prodotti di per sé? In entrambi i casi, la tua affermazione è ampiamente opinabile.
Ovvio che non mi riferisco ai sorgenti, Come si potrebbe mai? Pagagonare Firefox a Opera basandosi sui sorgenti? Quali sorgenti?
Fortunatamente lo sviluppo del kernel (cioé Linux) è in mano a un'oligarchia,
Scusa :°) Ma c'è sempre qualcuno che coordina ogni progetto. Cosa credi? Un responsabile di progetto c'è sempre.
Immagino tu non abbia mai dato un'occhiata ad esempio al codice sorgente di Firefox oppure ai sorgenti del kernel di Linux? Non sono proprio un fulgido esempio di "buon codice".
E uno sguardo a progetti come Apache httpd, gcc e NetBSD, giusto per fare due nomi, no?
Mi si gela A ME il angue nele vene a vedere che riesci a pensare una cosa del genere.
il software è un ene di consumo qualsiasi, lo si usa per raggiungere degli scopi, punto e basta.
Come fai a confonderlo con la privacy non lo capisco.
Un software non è un "informazione personale" di chi l'ha programmato.
Esattamente perche' e' uno strumento per raggiungere degli scopi, farne una questione di liberta' e di religione e' fuori dal mondo.
Mi semra che tu non abbia capito proprio una sega di cosa vuol dire "free software"
Penso che sia il contrario.
La GPL è un modello di distribuzione del software. L'open source è un modello di sviluppo, che nella sua forma più pura consente a tutti di partecipare allo sviluppo e di un progetto o al suo sfruttamento commericale. E questo, non c'era nulla con la ridistribuzione del codice.
No. Open Source e' un modello di distribuzione del software. SCRUM, ad esempio, e' un modello di sviluppo (development process).
No. Open Source e' un modello di distribuzione del software.
Procedimento inverso: che modello di sviluppo è uno che permette a tutti di partecipare allo sviluppo di un progetto?
Sai, perchè a me sembra che si parli di sviluppo e non di distribuzione :)
Procedimento inverso: che modello di sviluppo è uno che permette a tutti di partecipare allo sviluppo di un progetto o al suo sfruttamento per fini commerciali?
Sai, perchè a me sembra che si parli di sviluppo e non di distribuzione :)
Si chiama "Distributed Development Process" e puoi comodamente non rilasciare il codice open quando lo sviluppo e' terminato.
Se si parla di modello di sviluppo e ci si riferisce all'open source, come ho detto, si sta commettendo un errore di fondo fin dal principio del thread.
Una cosa e' la metodologia di sviluppo ("Distributed", "SCRUM", "Agile", "Waterfall").
Un'altra cosa e' la policy di distribuzione ("Open", "Closed").
Esempio di "Sviluppo Distribuito": CollabNET (http://www.collab.net/).
E NON rilasciano tutto quello che sviluppano Open.
Esempio di distribuzione "Open" all'interno di un'azienda: ThoughtWorks (http://www.thoughtworks.com), sviluppano del software all'interno con metodologie agili (XP) e poi lo rilasciano open source.
Come vedi, sono due cose diverse.
Uhm..no, ti evidenzio meglio:
che modello di sviluppo è uno che permette a tutti di partecipare allo sviluppo di un progetto o al suo sfruttamento per fini commerciali?
Chi adotta Distributed Development Process ne limita la partecipazione a determinato gruppo di persone , e quindi che io voglio parteciparci, non potrei, o sbaglio?
Scusa se insisto, ma non capisco :-)
Uhm..no, ti evidenzio meglio:
che modello di sviluppo è uno che permette a tutti di partecipare allo sviluppo di un progetto o al suo sfruttamento per fini commerciali?
Si chiama Distributed Development Process (e due).
Chi adotta Distributed Development Process ne limita la partecipazione a determinato gruppo di persone , e quindi che io voglio parteciparci, non potrei, o sbaglio?
Sbagli. Puo' limitare o meno la partecipazione. Quando poi distribuisce il prodotto puo' decidere di distribuirlo open source oppure chiuso senza fornire la licenza.
La confusione nasce dal fatto che la maggior parte dei progetti open source sono sviluppati con un processo distribuito, ma non e' condizione necessaria; come l'esempio di ThoughtWorks, posso sviluppare del codice con una metodologia inerentemente non distribuita (quale XP) e poi distribuirlo open source (un esempio e' CruiseControl).
E' come se qualcuno mi dicesse che in ogni bagno deve esserci una telecamera cosi' chiunque puo' guardarmi mentre faccio i bisogni in nome della liberta' di informazione. Follia pura.
Ti lamentavi dell'esempio del motore e fai un esempio del menga ;) ??
Ti lamentavi dell'esempio del motore e fai un esempio del menga ;) ??
Se pensassi fosse un esempio del menga non lo farei ;)
Altro che nucleare, questi thread sono la vera soluzione alla crisi energetica! :D
Comunque se posso esprimere la domanda di Dark_Sephirot86 in modo un po' più neutro, ovvero:
Un progetto open source è più insicuro perchè tutti hanno la possibilità di guardare il codice?
La risposta più corretta è no (il che non vuol dire che sia vero il contrario). Un software è più sicuro se e scritto bene e meno se è scritto male. Ci sono esempi da ambo le parti di software scritto bene e male (si lo so che se è closed uno non può vedere il codice, comunque il concetto è quello).
Ora vi lascio perchè è cominciato Inuyasha :)
jappilas
03-01-2006, 20:12
La GPL è un modello di distribuzione del software. L'open source è un modello di sviluppo
open source uguale "sorgente aperto", cioè disponibile al pubblico, e infatti vuol dire nè più nè meno questo... non contiene intrinsecamente direttive o modelli a cui gli sviluppatori debbano attenersi
fatto salvo di fornire a chi ottiene una copia del SW, anche i relativi sorgenti, lo sviluppatore o il team di sviluppatori può regolarsi come meglio crede
che nella sua forma più pura
scusami, ne esiste una meno pura?
consente a tutti di partecipare allo sviluppo e di un progetto o al suo sfruttamento commericale.
"a tutti" non è detto: molti progetti sono parecchio restii ad accettare patch, ed anche solo suggerimenti per nuove features, da "chiunque": spesso si prende in considerazione solo chi appartenga al team di sviluppo ufficiale, ed anche all' interno del team esistono livelli d' importanza... l' unico mezzo per l' individuo "qualunque" di realizzarsi apportando le proprie modifiche a quel progetto è in quei casi, forkarlo...
il che mi fa pensare che degli stessi progetti il cui prodotto è pubblicato in forma "open" adottino per lo sviluppo un modello distribuito (tnx fek :)), nonchè (se vogliamo) meritocratico, e che rendere visibile ogni minor release di ogni file .c e .h in un repository cvs o svn sia leggermente fuorviante...
La risposta più corretta è no (il che non vuol dire che sia vero il contrario). Un software è più sicuro se e scritto bene e meno se è scritto male. Ci sono esempi da ambo le parti di software scritto bene e male (si lo so che se è closed uno non può vedere il codice, comunque il concetto è quello).
La risposta piu' corretta e' non dare alcuna risposta, perche' come dice giustamente Cesare non c'e' alcuna metrica oggettiva per stabilire la sicurezza del software.
Si puo' cercare di fare un'analisi del numero di difetti nel software open source in confronto a quello closed source, ma si entrerebbe nel proverbiale "world of pain": le metodologie di sviluppo anche solo dietro al software open sono diverse, stabilire una metrica univoca nel calcolo della densita' di difetti e' un compito erculeo, i linguaggi sono diversissimi, insomma, non si puo' fare all'atto pratico.
Però, uff, c'è sempre un però.
Prendiamo le QT per esempio, sono sotto doppia licenza (commerciale e GPL) il suo modello di sviluppo è chiuso (:))
Ma posso io forkare le QT, magari dando vita alle GTQ, offrendoci assistenza io?
"o al suo sfruttamento commericale"
Scusatemi, ma mi è rimasto quest'ultimo dubbio :D
Però, uff, c'è sempre un però.
Prendiamo le QT per esempio, sono sotto doppia licenza (commerciale e GPL) il suo modello di sviluppo è chiuso (:))
Ma posso io forkare le QT, magari dando vita alle GTQ, offrendoci assistenza io?
"o al suo sfruttamento commericale"
Scusatemi, ma mi è rimasto quest'ultimo dubbio :D
Questo non lo so, dovrei leggermi la licenza commerciale.
qua si perdono le ore a parlare di licenze, leggi, dettagli semantici (modello di sviluppo o di distribuzione?)... l'unica cosa certa è ke il modello closed source non significa più sicurezza xkè altrimenti MS con le tecnologie e le metodologie acquisite con l'esperienza e i soldi dovrebbe produrre codice quasi perfetto (la realtà è tutt'altra quindi è difficile dire se conviene la struttura leggera-elastica tipo open o lenta-rigida tipo closed)! comunque x il fatto ke praticamente solo il closed source si attieni ai principi di ingegneria del SW io ci andrei piano, xkè nell'ingegneria del SW rientra anke la documentazione! di fatto se scrivo un codice ke deve essere compreso da un qualsiasi pazzo maniaco ke lo vuole comprendere, mi obbligo a documentarlo meglio ed è un dato di fatto ke il codice open è meglio documentato (ci sono molti esempi)!
ma lasciamo un attimo da parte tutto questo... quello su cui secondo me bisogna riflettere è: il programmatore ke contribuisce a un progetto open lo fà xkè gli piace farlo e si diverte (non parlo del kernel o di gcc ovviamente :D non ci si può divertire con quella roba.. o si?), mentre il programmatore closed la maggiorparte delle volte programma xkè deve farlo! secondo me questo è un fattore psicologico da non sottovalutare quando si cerca di stimare la probabilità di sbagliare una riga di codice.. no? io se programmo quello ke mi piace programmare lo faccio meglio.. voi no?
comunque x il fatto ke praticamente solo il closed source si attieni ai principi di ingegneria del SW io ci andrei piano, xkè nell'ingegneria del SW rientra anke la documentazione! di fatto se scrivo un codice ke deve essere compreso da un qualsiasi pazzo maniaco ke lo vuole comprendere, mi obbligo a documentarlo meglio ed è un dato di fatto ke il codice open è meglio documentato (ci sono molti esempi)!
Ma sei proprio certissimo di quello che scrivi? :)
Ma sei proprio certissimo di quello che scrivi? :)
tutte le volte ke ho voluto modificare un codice open source l'ho capito in poco tempo! comunque di sicuro è pieno di commenti a lato.. tu mi puoi dimostrare ke il codice closed è più documentato? benvenga, ma non voglio un esempio come se da quello valesse tutto, ma un ragionamento lineare e logico ke mi faccia cambiare idea! io ti ho detto ke secondo me il fatto ke il codice è sotto gli occhi di tutti è uno stimolo a documentarlo meglio!
tutte le volte ke ho voluto modificare un codice open source l'ho capito in poco tempo! comunque di sicuro è pieno di commenti a lato.. tu mi puoi dimostrare ke il codice closed è più documentato? benvenga, ma non voglio un esempio come se da quello valesse tutto, ma un ragionamento lineare e logico ke mi faccia cambiare idea! io ti ho detto ke secondo me il fatto ke il codice è sotto gli occhi di tutti è uno stimolo a documentarlo meglio!
Guarda, tralasciamo il fatto che stai continuando a confondere il concetto di distribuzione open source con il concetto di metodologia di sviluppo usata per produrre il software in questione, che sono due concetti totalmente differenti.
Tralasciamo anche che di solito non rispondo a chi non ha l'educazione per scrivere in maniera comprensibile evitando di abusare delle k e della sanita' mentale di chi legge.
Io non ti posso dimostrare che il codice closed sia piu' o meno documentato, visto che continuiamo a parlare solo di un modello di distribuzione non di una metodologia di sviluppo. Ma posso dimostrare che che non serve documentare e commentare il codice per renderlo leggibile e di alta qualita', anzi, e' vero l'esatto contrario: codice di alta qualita' raramente ha commenti e raramente ho visto codice open (diciamo sviluppato in maniera distribuita) di alta qualita'. CruiseControl invece e' codice open di altissima qualita', tanto e' vero che non e' sviluppato in maniera distribuita e, incredibile a dirsi, chi lo sviluppa e' pagato per farlo :)
Guarda, tralasciamo il fatto che stai continuando a confondere il concetto di distribuzione open source con il concetto di metodologia di sviluppo usata per produrre il software in questione, che sono due concetti totalmente differenti.
wikipedia dice: "In informatica, open source (termine inglese che significa sorgente aperto) indica un software rilasciato con un tipo di licenza per la quale il codice sorgente è lasciato alla disponibilità di eventuali sviluppatori" (fin qui è modello di distribuzione) "in modo che con la collaborazione (in genere libera e spontanea) il prodotto finale possa raggiungere una complessità maggiore di quanto potrebbe ottenere un singolo gruppo di programmazione." (adesso è modello di sviluppo)
Tralasciamo anche che di solito non rispondo a chi non ha l'educazione per scrivere in maniera comprensibile evitando di abusare delle k e della sanita' mentale di chi legge.
a me invece danno fastidio quelli ke riempiono i forum di definizioni, leggi empiriche e argomenti giuridici superflui... ma io continuerò a non vietartelo come tu non vieterai a me di skrivere con la k suppongo..
Io non ti posso dimostrare che il codice closed sia piu' o meno documentato, visto che continuiamo a parlare solo di un modello di distribuzione non di una metodologia di sviluppo. Ma posso dimostrare che che non serve documentare e commentare il codice per renderlo leggibile e di alta qualita', anzi, e' vero l'esatto contrario: codice di alta qualita' raramente ha commenti e raramente ho visto codice open (diciamo sviluppato in maniera distribuita) di alta qualita'. CruiseControl invece e' codice open di altissima qualita', tanto e' vero che non e' sviluppato in maniera distribuita e, incredibile a dirsi, chi lo sviluppa e' pagato per farlo
allora il mio professore di ingegneria del SW è deficente!! si chiama Carlo Ghezzi comunque se vuoi contattarlo per dirglielo... almeno corregge il grave errore ke ha commesso nel suo libro!
wikipedia dice: "In informatica, open source (termine inglese che significa sorgente aperto) indica un software rilasciato con un tipo di licenza per la quale il codice sorgente è lasciato alla disponibilità di eventuali sviluppatori" (fin qui è modello di distribuzione) "in modo che con la collaborazione (in genere libera e spontanea) il prodotto finale possa raggiungere una complessità maggiore di quanto potrebbe ottenere un singolo gruppo di programmazione." (adesso è modello di sviluppo)
Wikipedia sbaglia. E non e' la prima volta.
a me invece danno fastidio quelli ke riempiono i forum di definizioni, leggi empiriche e argomenti giuridici superflui... ma io continuerò a non vietartelo come tu non vieterai a me di skrivere con la k suppongo..
Mai vietero' a nessuno di rendersi ridicolo, e' una libera scelta.
allora il mio professore di ingegneria del SW è deficente!! si chiama Carlo Ghezzi comunque se vuoi contattarlo per dirglielo... almeno corregge il grave errore ke ha commesso nel suo libro!
Non credo sia deficiente, credo semplicemente che essendo un professore non abbia mai lavorato nel campo e non conosca in dettaglio le metodologie di sviluppo e le tecniche di costruzione del software che si sono imposte negl'ultimi anni. E' tipico, l'ambiente accademico in materia di Ingegneria del Software e' sempre stato diversi anni indietro.
Sarei felicissimo di contattarlo e di discutere con lui di Ingegneria Del Software. In fondo anch'io ho un master in questo ambito e diversi anni di esperienza lavorativa nel campo, e credo che sarebbe piuttosto interessato :)
Fatto sta che codice di alta qualita' non ha commenti.
Wikipedia sbaglia. E non e' la prima volta.
wikipedia sbaglia a definire "open source"? non ti viene mai il dubbio ke tu puoi sbagliare?
Mai vietero' a nessuno di rendersi ridicolo, e' una libera scelta.
esatto! proprio questo!
Non credo sia deficiente, credo semplicemente che essendo un professore non abbia mai lavorato nel campo e non conosca le metodologie di sviluppo e le tecniche di costruzione del software che si sono imposte negl'ultimi anni. E' tipico, l'ambiente accademico in materia di Ingegneria del Software e' sempre stato diversi anni indietro.
Sarei felicissimo di contattarlo e di discutere con lui di Ingegneria Del Software. In fondo anch'io ho un master in questo ambito e diversi anni di esperienza lavorativa nel campo, e credo che sarebbe piuttosto interessato
questo è proprio ridicolo! dovresti documentarti su di lui prima di dire ke il suo approccio è indietro diversi anni! io ti posso dire ke abbiamo utilizzato un linguaggio di supporto a java in laboratorio per ridurre notevolmente i bug nel codice e... non mi dire! a un seminario di IBM non sapevano neanke ke esisteva questo linguaggio! ki è indietro? il livello accademico o quello professionale? forse dove hai studiato te erano indietro, non lo so, dove studio io no!
comunque hai totalmente travisato il mio discorso.. io focalizzavo l'attenzione su: "io se programmo quello ke mi piace programmare lo faccio meglio.. voi no?"
vedi di non andare troppo fuori topic grazie!
Fatto sta che codice di alta qualita' non ha commenti.
Questa è la più bella che ho sentito negli ultimi anni! :sofico: :sofico: :sofico:
Certo, magari neanche un identazione decente deve avere il codice, giusto?
Questa è la più bella che ho sentito negli ultimi anni! :sofico: :sofico: :sofico:
Certo, magari neanche un identazione decente deve avere il codice, giusto?
eheh! veramente non ho parole! x un attimo ho pensato ke non stavamo parlando della stessa cosa! :D
wikipedia sbaglia a definire "open source"? non ti viene mai il dubbio ke tu puoi sbagliare?
Spesso il dubbio mi viene, in questo caso no. Basta il contro esempio che ho gia' fatto: CruiseControl e' un software open source, il suo sviluppo e' all'interno di un'azienda con metodologia agile e non distribuita. Ovvero il contrario di quanto affermato in quella definizione errata.
questo è proprio ridicolo! dovresti documentarti su di lui prima di dire ke il suo approccio è indietro diversi anni! io ti posso dire ke abbiamo utilizzato un linguaggio di supporto a java in laboratorio per ridurre notevolmente i bug nel codice e... non mi dire! a un seminario di IBM non sapevano neanke ke esisteva questo linguaggio! ki è indietro? il livello accademico o quello professionale? forse dove hai studiato te erano indietro, non lo so, dove studio io no!
Forse non mi sono spiegato. Ovviamente adesso mi parlerai diffusamente di metodologie di sviluppo agile, pratiche di refactoring, unit testing, test driven development, design pattern. Immagino che se dove studi tu (non te) sono cosi' avanti, non farai alcuna fatica a capire come ognuna di queste pratiche si basa proprio sul concetto che codice ben fattorizzato di alta qualita' non ha bisogno di commenti.
Sai di che cosa sto parlando vero? Conosci adesempio le pratiche di refactoring vero?
La cosa piu' probabile e' che tu abbia capito poco o nulla a lezione e riporti cio' che ti ha detto il professore in maniera errata.
Fatto sta che codice di alta qualita' non ha bisogno di commenti, e mantenere documentazione scritta del codice e' una pratica di sviluppo inefficiente.
comunque hai totalmente travisato il mio discorso.. io focalizzavo l'attenzione su: "io se programmo quello ke mi piace programmare lo faccio meglio.. voi no?"
E' un'evidente fesseria.
vedi di non andare troppo fuori topic grazie!
Sto parlando di metodologie di sviluppo in un topic che parla di metodologie di sviluppo. Sono perfettamente in topic. Rilassati.
Questa è la più bella che ho sentito negli ultimi anni! :sofico: :sofico: :sofico:
Bella vero? :)
Documentati:
http://c2.com/cgi/wiki?ToNeedComments
One consequence of refactoring is that it introduces a new method name. That name should shoulder a lot of the information burden that might have required a comment. Especially if the original method was long.
Are you saying that having well-factored code and having commented code are mutually exclusive?
In XP, it's a matter of focus. Our rule is that a comment is a sign that the code is not finished. When we see a method that needs a comment, our rule doesn't let us stop with the comment -- it leads us to focus on improving the code. And since we practice CollectiveCodeOwnership, anybody is free to clarify code if it isn't clear enough.
If you write and refactor code with a focus on minimizing comments, less than 1% of your methods will support non-redundant comments. And teams with a strong oral tradition (enforced in XP with PairProgramming) will not suffer in any way from the absence of those redundant comments.
E aggiungo, proprio in questo forum portiamo avanti un progetto che rilasceremo open source, sviluppato con metodologia agile (ma distribuita). Non commentiamo il codice, preferiamo concentrarci sulla qualita' dello stesso invece. Sei libero di leggerlo e farci sapere se questo porta a codice di bassa qualita'.
Certo, magari neanche un identazione decente deve avere il codice, giusto?
No, l'indentazione e' importante.
Sto parlando di metodologie di sviluppo in un topic che parla di metodologie di sviluppo. Sono perfettamente in topic. Rilassati.
ma non era un topic sulle metodologie di distribuzione? ti stai contraddicendo.. rilassati te
ma non era un topic sulle metodologie di distribuzione? ti stai contraddicendo.. rilassati te
Me sono rilassato. No, e' un topic sulla metodologia di sviluppo distribuito che confonde (come fai tu) la distribuzione open source con lo sviluppo distribuito.
Spesso il dubbio mi viene, in questo caso no. Basta il contro esempio che ho gia' fatto: CruiseControl e' un software open source, il suo sviluppo e' all'interno di un'azienda con metodologia agile e non distribuita. Ovvero il contrario di quanto affermato in quella definizione errata.
diciamo ke il termine opensource non l'hai coniato te, quindi non ha il significato ke gli vuoi dare te, ma è ben + ampio!
Forse non mi sono spiegato. Ovviamente adesso mi parlerai diffusamente di metodologie di sviluppo agile, pratiche di refactoring, unit testing, test driven development, design pattern. Immagino che se dove studi tu (non te) sono cosi' avanti, non farai alcuna fatica a capire come ognuna di queste pratiche si basa proprio sul concetto che codice ben fattorizzato di alta qualita' non ha bisogno di commenti.
Sai di che cosa sto parlando vero? Conosci adesempio le pratiche di refactoring vero?
La cosa piu' probabile e' che tu abbia capito poco o nulla a lezione e riporti cio' che ti ha detto il professore in maniera errata.
Fatto sta che codice di alta qualita' non ha bisogno di commenti, e mantenere documentazione scritta del codice e' una pratica di sviluppo inefficiente.
skerzi vero? abbiamo fatto tutte queste cose in ingSW1! ci soffermeremo meglio nel testing in ingSW2! non mi prendere x ignorante ti prego!! il refactoring da solo non basta e i commenti sono vitali a meno ke il mio professore è deficente! ti prego contattalo xkè qui riskiamo ke 2milioni di ingegnieri escono ignoranti dall'università!
E' un'evidente fesseria.
allora se non vuoi affrontare l'argomento me lo dicevi mezzora fa ke andavo a dormire!
Me sono rilassato. No, e' un topic sulla metodologia di sviluppo distribuito che confonde (come fai tu) la distribuzione open source con lo sviluppo distribuito.
spero ke non hai capito neanke te cosa hai detto.. :mc:
diciamo ke il termine opensource non l'hai coniato te, quindi non ha il significato ke gli vuoi dare te, ma è ben + ampio!
Infatti non l'ho coniato, mi limito a riportare la definizione corretta.
skerzi vero? abbiamo fatto tutte queste cose in ingSW1! ci soffermeremo meglio nel testing in ingSW2! non mi prendere x ignorante ti prego!! il refactoring da solo non basta e i commenti sono vitali a meno ke il mio professore è deficente! ti prego contattalo xkè qui riskiamo ke 2milioni di ingegnieri escono ignoranti dall'università!
Ovvero, non sai di che cosa sto parlando.
I commenti sono un segno di "bad coding" ed una pratica da evitare. Un commento non fa altro che ripetere a parole quello che gia' il codice esprime; se lo esprime in maniera offuscata, per renderlo chiaro la soluzione non e' commentarlo, ma riscriverlo. Inoltre i commenti violano il principio DRY (Dont Repeat Yourself), sono una duplicazione inutile di informazione, offuscano ulteriormente il codice, spesso e volentieri vanno fuori sincronia con il codice stesso e spesso sono semplicemente errati, fornendo informazioni errate a chi le legge.
Insomma, commentera il codice invece di riscriverlo e' una pratica deprecabile, tipica di un principiante.
Ma puoi sempre provare a portarmi un buon motivo per il quale dovrei commentare un pezzo di codice invece di scriverlo piu' chiaramente, magari basato sulla tua esperienza. Hai esperienza? Hai mai partecipato ad un progetto di qualche tipo o scribacchi codice solo nel tempo libero su cose che ti piacciono?
allora se non vuoi affrontare l'argomento me lo dicevi mezzora fa ke andavo a dormire!
Vai pure a dormire, non stai comunque dando un grande apporto :)
Anche se OT, chiudo il discorso sui commenti (gia' ampiamente affrontato nel forum di Programmazione) con un esempietto pratico:
mConfig.UseHDR = true;
mAutoExposureEnabled = true;
if (CheckCapabilities())
{
CreateRenderTargets();
CreateFilters();
EnableBloom(mBloomEnabled);
EnableColorCorrection(mAutoExposureEnabled);
}
else
{
mForceDisabled = true;
}
Ha bisogno di commenti? :)
La mancanza di commenti riduce enormemente la leggibilità del codice, tant'è che uno non sa neanche da che parte iniziare per trovare un errore.
Sai,commentare la chisura di un semplice ciclo o di un modulo in generale non occupa più di 2 minuti in generale...
Con quei 2 minuti risparmi 10 minuti a chi lo legge..
Certo, produrre software di qualità è lodevole, ma metterci anche i commenti vuol dire produrre software di qualità... anche maggiore se è per quello.
Per tornare in topic,l'opensource lo ritengo sicuro..
La mancanza di commenti riduce enormemente la leggibilità del codice, tant'è che uno non sa neanche da che parte iniziare per trovare un errore.
Sai,commentare la chisura di un semplice ciclo o di un modulo in generale non occupa più di 2 minuti in generale...
Con quei 2 minuti risparmi 10 minuti a chi lo legge..
Certo, produrre software di qualità è lodevole, ma metterci anche i commenti vuol dire produrre software di qualità... anche maggiore se è per quello.
E' vero l'esatto contrario. La presenza di commenti riduce enormemente la leggibilita' di codice offuscato dai commenti stessi, che spesso sono fuori sincronia e palesemente errati. Come ho scritto prima, se un pezzo di codice e' mal strutturato e illeggibile, la soluzione non e' commentarlo, ma riscriverlo di modo che sia leggibile e ben strutturato, eliminando la necessita' dei commenti e creando una struttura piu' semplice da gestire e mantenere.
Quali commenti aggiungeresti al codice che ho postato?
L'open source non e' piu' o meno sicuro. L'affermazione che hai fatto non ha senso espressa cosi'.
Infatti non l'ho coniato, mi limito a riportare la definizione corretta.
l'hai presa da www.ledefinizionicorrette.com? mi sembra ke sopravvaluti un attimo la tua sapienza! opensource può intendere benissimo anke una metodologia di sviluppo nel senso ke tutti ci capiamo e non c'è una definizione univoca quindi rassegnati xkè sennò kiedo stallman ke lui lo sa di sicuro!
Ovvero, non sai di che cosa sto parlando.
I commenti sono un segno di "bad coding" ed una pratica da evitare. Un commento non fa altro che ripetere a parole quello che gia' il codice esprime; se lo esprime in maniera offuscata, per renderlo chiaro la soluzione non e' commentarlo, ma riscriverlo. Inoltre i commenti violano il principio DRY (Dont Repeat Yourself), sono una duplicazione inutile di informazione, offuscano ulteriormente il codice, spesso e volentieri vanno fuori sincronia con il codice stesso e spesso sono semplicemente errati, fornendo informazioni errate a chi le legge.
Insomma, commentera il codice invece di riscriverlo e' una pratica deprecabile, tipica di un principiante.
Ma puoi sempre provare a portarmi un buon motivo per il quale dovrei commentare un pezzo di codice invece di scriverlo piu' chiaramente, magari basato sulla tua esperienza. Hai esperienza? Hai mai partecipato ad un progetto di qualche tipo o scribacchi codice solo nel tempo libero su cose che ti piacciono?
questa è grossa! le conosco tutte le tecnike ke hai citato! quelle sul testing le dobbiamo approfondire ulteriormente ma parole come design pattern non mi hanno spaventato rassegnati!
comunque se non vuoi contraddirti nessun codice è privo di errori, xciò se scrivi di fianco cosa intendevi fare con quel codice è già qualkosa da cui partire x correggere un possibile errore!
ma forse non hai capito! guarda non volevo arrivare a tanto.. visita http://www.elet.polimi.it/page1.do?dau1.oid=155&UserCtxParam=0&GroupCtxParam=0&ctx1=it&crc=493511044
c'è la sua mail e la sua vita più o meno! fammi sapere cosa ne deriva dalla vostra discussione, sono curioso!
Vai pure a dormire, non stai comunque dando un grande apporto
devo dedurre ke tu programmi meglio controvoglia! ok grazie x il chiarimento!
La presenza di commenti riduce enormemente la leggibilita' di codice offuscato dai commenti stessi, che spesso sono fuori sincronia e palesemente errati.
si parte dal presupposto ke uno sa leggere e soprattutto scrivere ovviamente! anke questo è indice di qualità
l'hai presa da www.ledefinizionicorrette.com? mi sembra ke sopravvaluti un attimo la tua sapienza! opensource può intendere benissimo anke una metodologia di sviluppo nel senso ke tutti ci capiamo e non c'è una definizione univoca quindi rassegnati xkè sennò kiedo stallman ke lui lo sa di sicuro!
No, e' la definizione corrente di software open source che spiega gli esempi che ho citato.
questa è grossa! le conosco tutte le tecnike ke hai citato! quelle sul testing le dobbiamo approfondire ulteriormente ma parole come design pattern non mi hanno spaventato rassegnati!
A giudicare da quello che scrivi, al contrario, non sai di che cosa sto parlando.
comunque se non vuoi contraddirti nessun codice è privo di errori, xciò se scrivi di fianco cosa intendevi fare con quel codice è già qualkosa da cui partire x correggere un possibile errore!
Che cosa devo scrivere di fianco di piu' di quello che gia' e' scritto nel codice?
Te lo riposto, si legge come se l'inglese:
if (CheckCapabilities())
{
CreateRenderTargets();
CreateFilters();
EnableBloom(mBloomEnabled);
EnableColorCorrection(mAutoExposureEnabled);
}
devo dedurre ke tu programmi meglio controvoglia! ok grazie x il chiarimento!
No, programmo in genere perche' mi piace, ma questo non ha alcun effetto sulla qualita' del mio codice, che resta piu' o meno la medesima sia se quello che sto scrivendo mi piace sia se non mi piace. Si chiama professionalita'.
beh io vado a dormire ke è meglio!
ps. adesso capisco xkè ie6 è pieno di errori!! certo loro commenteranno un casino il codice :doh: ! x questo ci impiegano 2 mesi a correggere un bug!
No, e' la definizione corrente di software open source che spiega gli esempi che ho citato.
ma dimmi da dove l'hai pescata sta definizione così ci mettiamo tutti il cuore in pace!
A giudicare da quello che scrivi, al contrario, non sai di che cosa sto parlando.
refactoring significa trasformare il codice in maniera + leggibile, se usi eclipse e clikki col destro sul nome di una funzione ce l'hai nel menù a tendina (ad esempio puoi cambiare nome alla funzione, spostarla in un altro package o altre cose ankora) comunque ti permette di fare tante trasformazioni
unit testing = junit x quanto riguarda il nostro corso (se hai programmato in java non mi dire ke non sai cos'è)
test driven development sarà argomento di ingsoft2 e cmq nn c'entra molto qui
design pattern sono soluzioni note a problemi noti! c'è molta letteratura sull'argomento!
ho superato l'esame? mamma mia ke tensione!!!
approposito! conosci JML (Java Modeling Language)? o qualke linguaggio simile? altrimenti sembra ke tu sai tutto e gli altri sono caproni! comunque parla davvero con il mio professore e te ne sarò grato xkè ci aggiornerai sulle tecnike + recenti.. bla bla
E' come se qualcuno mi dicesse che in ogni bagno deve esserci una telecamera cosi' chiunque puo' guardarmi mentre faccio i bisogni in nome della liberta' di informazione. Follia pura.
Beh... effettivamente e' un esempio poco pertinente (non so cosa voglia dire "menga"). La possibilita' di esaminare i sorgenti la paragonerei piu' al fatto di sapere come e' stata preparata una crostata: ingredienti + procedimento. :)
Beh... effettivamente e' un esempio poco pertinente (non so cosa voglia dire "menga"). La possibilita' di esaminare i sorgenti la paragonerei piu' al fatto di sapere come e' stata preparata una crostata: ingredienti + procedimento. :)
se non altro so ke tra gli ingredienti di un software open source non ci sono 20 tonnellate di spyware! mi sbaglio se definisco windows uno spyware? pensa ke qualke hacker ha dimostrato ke invia un sacco di informazioni violando la privacy!
refactoring significa trasformare il codice in maniera + leggibile, se usi eclipse e clikki col destro sul nome di una funzione ce l'hai nel menù a tendina (ad esempio puoi cambiare nome alla funzione, spostarla in un altro package o altre cose ankora) comunque ti permette di fare tante trasformazioni
No, non significa quello. Refactoring e' una serie di modifiche al codice che ne preserva il comportamento osservabile e ne migliora la struttura interna.
unit testing = junit x quanto riguarda il nostro corso (se hai programmato in java non mi dire ke non sai cos'è)
Unit testing non e' junit, junit e' solo un framework di testing, e non solo di unit testing, ma anche di regression testing, performance testing con i dovuti plugin, functional testing per certi aspetti, o anche acceptance testing. Unit testing si riferisce solo alla verifica delle post condizioni di un'unita' di codice.
test driven development sarà argomento di ingsoft2 e cmq nn c'entra molto qui
Ok :)
design pattern sono soluzioni note a problemi noti! c'è molta letteratura sull'argomento!
No, non sono quello :)
I Design Pattern sono soluzioni testate solo a problemi di design ricorrenti del codice indipendenti dal linguaggio. E non a qualunque problema noto.
ho superato l'esame? mamma mia ke tensione!!!
No, ti consiglio di frequentare meno i forum e di studiare di piu'. Oltre a fare tanta esperienza, per maneggiare questi argomenti non basta aver seguito malamente una lezione di un professore (e non aver capito quello che ti ha detto), ma servono anni di esperienza sul campo.
se non altro so ke tra gli ingredienti di un software open source non ci sono 20 tonnellate di spyware! mi sbaglio se definisco windows uno spyware? pensa ke qualke hacker ha dimostrato ke invia un sacco di informazioni violando la privacy!
links?. Ed in ogni caso anche se fosse vero ci sono sempre i firewall.
ciao ;)
approposito! conosci JML (Java Modeling Language)? o qualke linguaggio simile? altrimenti sembra ke tu sai tutto e gli altri sono caproni! comunque parla davvero con il mio professore e te ne sarò grato xkè ci aggiornerai sulle tecnike + recenti.. bla bla
Non sono un grande amante dei linguaggi di modellazione formale (non mi verrai ora a dire che il design di una soluzione va fatta up front e modellata con uno di questi linguaggi ora, vero? ;)) ma ho una ragionevole familiarita' con JML e UML.
Non ho mai detto di sapere tutto, anzi, ho moltissimo da imparare come tutti, e non ho mai detto che gli altri sono tutti caproni. Anzi. La volonta' di imparare e progredire senza fossilizzarsi come in certi ambienti accademici e' fondamentale nel mio lavoro.
se non altro so ke tra gli ingredienti di un software open source non ci sono 20 tonnellate di spyware! mi sbaglio se definisco windows uno spyware? pensa ke qualke hacker ha dimostrato ke invia un sacco di informazioni violando la privacy!
Non saprei. Personalmente non ho sistemi Microsoft e ne uso di rado, e probabilmente non mi accorgerei di nulla se ci fossero programmi nel mio sistema operativo che inviano le mie informazioni personali verso l'esterno.
In linea di massima, un produttore di sw puo' mettere nel suo prodotto quello che vuole ma, nel caso faccia una cosa del genere con i dati dell'utente, dovrebbe riportarlo a chiare lettere e chiedere esplicita autorizzazione per quello che sta facendo. Se non lo fa, viola la legge. E se e' stato dimostrato che un prodotto viola la legge, il produttore credo possa essere denunciato.
Il problema e' che spesso solo in pochi si soffermano a leggere le licenze dei vari prodotti (probabilmente c'e' una diversa licenza per ciascuna applicazione), e magari in tali licenze c'e' scritto qualcosa che puo' assomigliare grossomodo ad una autorizzazione al trattamento dei dati personali, per cui la denuncia sarebbe inutile. Comunque non mi e' mai capitato di leggere di queste licenze ( :p ), quindi parlo, come sempre :ciapet: , in via del tutto ipotetica.
links?. Ed in ogni caso anche se fosse vero ci sono sempre i firewall.
ciao ;)
Secondo me non dovrebbe essere necessario, per un utente, installare software aggiuntivo per proteggersi dal suo stesso sistema operativo. Al massimo, uno dovra' proteggersi da attacchi esterni :) . O no?
No, non significa quello. Refactoring e' una serie di modifiche al codice che ne preserva il comportamento osservabile e ne migliora la struttura interna.
Unit testing non e' junit, junit e' solo un framework di testing, e non solo di unit testing, ma anche di regression testing, performance testing con i dovuti plugin, functional testing per certi aspetti, o anche acceptance testing. Unit testing si riferisce solo alla verifica delle post condizioni di un'unita' di codice.
Ok :)
No, non sono quello :)
I Design Pattern sono soluzioni testate solo a problemi di design ricorrenti del codice indipendenti dal linguaggio. E non a qualunque problema noto.
No, ti consiglio di frequentare meno i forum e di studiare di piu'. Oltre a fare tanta esperienza, per maneggiare questi argomenti non basta aver seguito malamente una lezione di un professore (e non aver capito quello che ti ha detto), ma servono anni di esperienza sul campo.
skusa se non ho usato le stesse parole ke hai usato te! mi sembra l'asilo! il refactoring migliora la struttura interna nel senso ke la rende + leggibile!
junit è un framework e lo so! il concetto era ke abbiamo usato junit x apprezzare la potenza dello unit testing! (adesso capisco xkè non capisci i commenti!)
x i design pattern.. skusa non avevo il libro davanti! ma non ci si era capiti? un problema noto è un problema ricorrente! non ci attakkiamo alle sottigliezze!
poi tu hai detto ke non conosco nulla di ingSW o ho capito male? quindi mi consideri un caprone! comunque non mi stupisce se hai iniziato a programmare in visual basic, si fanno sempre riconoscere quelli!! adesso io me ne vado a dormire (ronf ronf)! parla con il mio professore e non stressare con i dettagli sulle definizioni! pensa al contenuto + ke alla forma! mamma mia ke pesantezza sto qua! cos'è un cyborg inviato da MicroSold?
http://www.consultingtimes.com/ossdev.html :)
Non sono un grande amante dei linguaggi di modellazione formale (non mi verrai ora a dire che il design di una soluzione va fatta up front e modellata con uno di questi linguaggi ora, vero? ;)) ma ho una ragionevole familiarita' con JML e UML.
Non ho mai detto di sapere tutto, anzi, ho moltissimo da imparare come tutti, e non ho mai detto che gli altri sono tutti caproni. Anzi. La volonta' di imparare e progredire senza fossilizzarsi come in certi ambienti accademici e' fondamentale nel mio lavoro.
JML nn ci azzecca niente con UML! kecc'entra UML? ho mai parlato di diagrammi delle classi o cose simili?
links?. Ed in ogni caso anche se fosse vero ci sono sempre i firewall.
ciao ;)
x lo meno c'è scritto nel codice se c'è uno spyware
skusa se non ho usato le stesse parole ke hai usato te! mi sembra l'asilo! il refactoring migliora la struttura interna nel senso ke la rende + leggibile!
junit è un framework e lo so! il concetto era ke abbiamo usato junit x apprezzare la potenza dello unit testing! (adesso capisco xkè non capisci i commenti!)
x i design pattern.. skusa non avevo il libro davanti! ma non ci si era capiti? un problema noto è un problema ricorrente! non ci attakkiamo alle sottigliezze!
Non hai usato parole diverse, hai proprio scritto cose sbagliate. E' normale quando i concetti non ti sono chiari.
poi tu hai detto ke non conosco nulla di ingSW o ho capito male? quindi mi consideri un caprone!
Ma no, penso solo che tu non sappia di che cosa sto parlando. E sia anche piuttosto arrogante nel cercare di imporre le tue francamente risibili opinioni a chi ne sa giusto un pelino piu' di te.
comunque non mi stupisce se hai iniziato a programmare in visual basic, si fanno sempre riconoscere quelli!! adesso io me ne vado a dormire (ronf ronf)! parla con il mio professore e non stressare con i dettagli sulle definizioni! pensa al contenuto + ke alla forma! mamma mia ke pesantezza sto qua! cos'è un cyborg inviato da MicroSold?
Hmmm... no, ho iniziato circa 20 anni fa in C/Pascal. Anno piu', anno meno. Ho un po' di esperienza nel campo, sai...
[...] comunque non mi stupisce se hai iniziato a programmare in visual basic, si fanno sempre riconoscere quelli!! adesso io me ne vado a dormire (ronf ronf)! parla con il mio professore e non stressare con i dettagli sulle definizioni! pensa al contenuto + ke alla forma! mamma mia ke pesantezza sto qua! cos'è un cyborg inviato da MicroSold?
Cosa hai contro chi ha cominciato con con visual basic? Io ho cominciato con il basic del commodore 64 e me li sono fatti tutti fino a 6.0. :D
ciao ;)
ma non ho capito se tu in black&white hai progettato il codice o hai implementato funzioni... a me convinceva di + ghezzi a lezione ke il tuo limitarti a dire tu sbagli, l'altro sbaglia, voi sbagliate, io faccio giusto! scrivi qualcosa di decente x favore!
jappilas
03-01-2006, 23:19
MS con le tecnologie e le metodologie acquisite con l'esperienza e i soldi dovrebbe produrre codice quasi perfetto
per quale motivo? in MS lavorano persone, le persone non sono infallibili e la perfezione (a prescindere dal campo che si considera) non è di questo mondo
sta di fatto che a detta di molti, la metodologia di sviluppo adottata in MS da qualche anno a questa parte, la ponga tra le migliori SW house esistenti
nell'ingegneria del SW rientra anke la documentazione!
ah sì? quando ho dato quell' esame il prgramma comprendeva design pattern, modello di approccio al problema e al design (all' epoca si insegnava il waterfall) , i teoremi del testing, ma nulla che scendesse nei dettagli del coding (che può essere fatto nel linguaggio che risulta più utile e con le convenzioni che assicurano la maggior consistenza e leggibilità )
il codice open è meglio documentato (ci sono molti esempi)!
ci sono moltissimi esempi anche del contrario, se è per questo ... e codice scritto pedestremente e commentato allo stesso modo, ne ho letto e cercato di tracciare un discreto quantitativo (e non è bello quando ti devi affidare al call stack per cercare di capire un algoritmo perchè il codice da solo non ti dà indicazioni sufficienti...)
tutte le volte ke ho voluto modificare un codice open source l'ho capito in poco tempo! comunque di sicuro è pieno di commenti a lato..
io invece ho tutte le volte dovuto scremare i commenti per vedere che accrocchio si combinava con le chiamate a funzione, e ci ho messo molto più tempo di quanto avrei impiegato se i commenti fossero stati di meno ma i nomi scelti per variabili e funzioni, più indicativi...
se scrivo un codice ke deve essere compreso da un qualsiasi pazzo maniaco ke lo vuole comprendere, mi obbligo a documentarlo meglio ed è un dato di fatto ke il codice open è meglio documentato
io se scrivo codice ex novo sapendo che altri dovranno metterci le mani in secondo tempo, cerco di inventarmi nomi autoesplicativi per variabili, classi e funzioni
i commenti servono quando proprio ciò non è fattibile (magari perchè ci si deve appoggiare a qualche componente esterno, fatto da altri, sul cui contenuto non si ha possibilità di intervenire) e, almeno nel workflow del lab dove lavoro alla tesi, per generare la documentazione tramite doxygen
il programmatore closed la maggiorparte delle volte programma xkè deve farlo!
parlo per me, ma anche il programmatore closed source segue la strada che ha scelto di percorrere... nessuno mi ha puntato la pistola alla tempia quando ho scelto questo indirizzo, l' ho scelto perchè all' epoca mi affascinava il settore e lo trovavo promettente
secondo me questo è un fattore psicologico da non sottovalutare quando si cerca di stimare la probabilità di sbagliare una riga di codice
credo possa capitare, in genere, nelle situazioni in cui la pressione sia più elevata del normale... ma per un professionista, che una maggior probabilità sia correlata al fatto stesso di lavorare a contratto, significa essere scadente come professionista...
Cosa hai contro chi ha cominciato con con visual basic? Io ho cominciato con il basic del commodore 64 e me li sono fatti tutti fino a 6.0. :D
ciao ;)
niente di personale credimi! ma in visual basic sembra sia impossibile applicare una qualke regola di ingSW! magari è ottimo x fare altre cose ma qui parliamo di ingSW!
Cosa hai contro chi ha cominciato con con visual basic? Io ho cominciato con il basic del commodore 64 e me li sono fatti tutti fino a 6.0. :D
ciao ;)
Ma tu vic sei un noto lamma inviato da Sun per diffondere Java a noi poveri programmatori :D
niente di personale credimi! ma in visual basic sembra sia impossibile applicare una qualke regola di ingSW! magari è ottimo x fare altre cose ma qui parliamo di ingSW!
Correggo, io sto parlando di ingegneria del software, tu stai solo bofonchiando senza grande cognizione di causa :)
Per altro, le ultime versioni di Visual Basic.NET sono piu' che decenti ed e' possibile scrivere dell'ottimo codice se si e' capaci a programmare. Ovviamente se pensi che commentare il codice invece che riscriverlo sia fondamentale, non potrai mai scrivere codice decente in un qualunque linguaggio.
(non so cosa voglia dire "menga")
Termine lombardo per dire, diciamo, "del cavolo".
Essendo riferito ai "bisogni" è abbastanza appropriato ;)
[OT]
Per ripetizioni di lumbard ho trovato questo interessante link :D
http://www.gattosilvestro.net/cursdelumbard.html
ohmmadonna! è arrivato l'elfo! comunque pensa ke a me all'esame di ingSW mi hanno valutato x la qualità della javadoc ke ho prodotto! cmq non sono io il professore kiedi al tuo amico fek la mail di ghezzi e non mi tormentate!
ahah commentare non serve! xkè adesso noi parliamo in C! C è una classe di equivalenza del linguaggio naturale! in C si può esprimere qualsiasi cosa! ok adesso devo scappare mi dispiace! comunque è stato divertente!!
ps. ah grazie x avermi detto dei nomi delle variabili autoesplicativi! pensa ke io le kiamavo pippo1, pippo2 e pippo3!
Ma tu vic sei un noto lamma inviato da Sun per diffondere Java a noi poveri programmatori :D
Sistema la build machine invece di perdere tempo qui nel forum a parlare del piu e del meno :Prrr:
ciao ;)
ah fek! dimenticavo! sai ke JML nn ci azzecca niente con UML vero?
ohmmadonna! è arrivato l'elfo! comunque pensa ke a me all'esame di ingSW mi hanno valutato x la qualità della javadoc ke ho prodotto! cmq non sono io il professore kiedi al tuo amico fek la mail di ghezzi e non mi tormentate!
Ma stai ancora paragonando un esamino di ingegneria del software a piu' di 10 anni di esperienza nel settore... su su su ma siamo seri e perdi piu' tempo a studiare che ne hai bisogno :)
Ma stai ancora paragonando un esamino di ingegneria del software a piu' di 10 anni di esperienza nel settore... su su su ma siamo seri e perdi piu' tempo a studiare che ne hai bisogno :)
mi sembri fuori topic! se fossi il moderatore ti bannerei! non devi prenderla sul personale!! rispondi alle domande invece! byez (sul serio)
ah fek! dimenticavo! sai ke JML nn ci azzecca niente con UML vero?
Ti ripeto di si', sono entrambi linguaggi di modellazione del design formali, uno basato su diagrammi (ad esempio i diagrammi di classe di UML), l'altro sulla descrizione mediante una grammatica formale e piu' vicino al linguaggio naturale delle precondizioni, postcodinzioni e invarianze (JML). Una specie di Design By Contract alla Eiffel, ma decisamente meno elegante.
Sono due strumenti diversi che perseguono gli stessi scopi (e che non adoro).
mi sembri fuori topic! se fossi il moderatore ti bannerei! non devi prenderla sul personale!! rispondi alle domande invece! byez (sul serio)
Sono perfettamente in topic invece, visto che stai insultando chiunque non ti dia ragione, mi limito a riportarti in riga :)
Ha bisogno di commenti? :)
Si, perché è comprensibile ma non gestibile; non so se rendo l'idea.
Immaginati di essere uno che si trova con quel pezzo di codice davanti la prima volta, o tu stesso dopo 3 anni; a mio avviso ci vorrebbero dei commenti che rispondessero alle domande che riporto.
mConfig.UseHDR = true; // Variabile che serve a cosa e dove? Nel pezzo di codice subito seguente non è usata...
mAutoExposureEnabled = true; // Impostata a true perchè? Non è dichiarata qua, quindi resetto il valore qualunque fosse stato prima
if (CheckCapabilities()) // OK, faccio un controllo; ma in merito a cosa? Alla memoria, alla banda, ai puffi?
{
CreateRenderTargets();
CreateFilters();
EnableBloom(mBloomEnabled);
EnableColorCorrection(mAutoExposureEnabled);
}
else
{
mForceDisabled = true; // Ok, lo imposto a true, ma perché nell'if non l'ho impostato a false?
}
Per gli if e gli else, puoi anche non commentare la chiusura perché sono poche righe, ma se fossero di più farebbe comodo; lo stesso se ne avvessi più annidati, è comodo sapere l'else a quale if fa riferimento.
Non è che devi commentare proprio tutto, ma dove serve.
E ora mi darai del figlio di Sun di nuovo, ma se scrivi bene dei commenti durante lo sviluppo, poi hai anche la documentazione (leggi javadoc) ;)
Non mi dire che "quando modifichi, poi non li aggiorni", perché allora ti potrei rispondere che "quando modifichi senza commento, prendi cantonate".
Dipende dall'attenzione con cui fai le cose, in un caso e nell'altro.
jappilas
03-01-2006, 23:45
pensa ke a me all'esame di ingSW mi hanno valutato x la qualità della javadoc ke ho prodotto!
pensa ke a me all' esame di Ing SW hanno fatto studiare un frammento di codice di un paio di centinaia di linee, con complessità ciclometrica intorno a 35 (se non ricordo male), determinando domini di correttezza per i casi di percorrenza di: tutte le condizioni, tutte le istruzioni, condizioni AND istruzioni... il secondo esercizio consisteva nell' analisi di un' applicazione che gestisse manipolazione da client esterni su strutture dati gerarchiche e aggregate, e modellazione tramite i DP necessari (se non ricordo male ci andava un Composite, un Observer, il Proxy e una Factory... il diagramma mi prese 3 fogli A4... :D)
cmq non sono io il professore kiedi al tuo amico fek la mail di ghezzi e non mi tormentate!
nessuno ti tormenta... faccio solo un confrontino tra un esame di ingsoft vecchio e nuovo ordinamento :D
ahah commentare non serve! xkè adesso noi parliamo in C! C è una classe di equivalenza del linguaggio naturale! in C si può esprimere qualsiasi cosa!
commentare non è inutile a priori... spesso però potrebbe tranquillamete essere sostituito da una naming convention più "umana"
hai la fortuna che un simbolo in C non ha praticamente vincoli sul naming... perchè non sfruttarlo per far assomigliare un programma a un "discorso" in inglese? ;)
Si, perché è comprensibile ma non gestibile; non so se rendo l'idea.
Immaginati di essere uno che si trova con quel pezzo di codice davanti la prima volta, o tu stesso dopo 3 anni; a mio avviso ci vorrebbero dei commenti che rispondessero alle domande che riporto.
O tipo me stasera dopo un anno e mezzo che l'avevo scritto. Beh, e' scritto in inglese, infatti e' stato perfettamente gestibile.
mConfig.UseHDR = true; // Variabile che serve a cosa e dove? Nel pezzo di codice subito seguente non è usata... // Imposta l'uso dell'HDR, c'e' scritto :)
mAutoExposureEnabled = true; // Impostata a true perchè? Non è dichiarata qua, quindi resetto il valore qualunque fosse stato prima Imposta l'uso dell'autoesposizione, c'e' scritto :)
if (CheckCapabilities()) // OK, faccio un controllo; ma in merito a cosa? Alla memoria, alla banda, ai puffi? // Fa un controllo delle capabilities, c'e' scritto :)
{
CreateRenderTargets(); // Crea i render target, c'e' scritto :)
CreateFilters(); // Crea i filtri, c'e' scritto :)
EnableBloom(mBloomEnabled); // Abilita il bloom a seconda della variabile, c'e' scritto. :)
EnableColorCorrection(mAutoExposureEnabled); // Abilita la correzione del colore in base al valore della variabile impostata prima, c'e' scritto pure questo :)
}
else
{
mForceDisabled = true; // Ok, lo imposto a true, ma perché nell'if non l'ho impostato a false? // Perche' e' impostato dal costruttore, c'e' scritto nella lista di inizializzazione :)
}
Per gli if e gli else, puoi anche non commentare la chiusura perché sono poche righe, ma se fossero di più farebbe comodo; lo stesso se ne avvessi più annidati, è comodo sapere l'else a quale if fa riferimento.
Infatti io non annido gli if, ma creo nuovi metodi, non ho bisogno di commentare if molto annidati, riscrivo il codice per renderlo piu' chiaro. Classico esempio di come commentare invece ti preclude la possibilita' di strutturare meglio il codice.
Non è che devi commentare proprio tutto, ma dove serve.
No, devi commentare solo cio' che non e' esprimibile altresi' in codice, di solito assunzioni sull'algoritmo che non puoi documentare con l'assert delle precondizioni direttamente nel codice, oppure note di complessita' computazionale dell'algoritmo che stai implementando. Questi sono esempi di buoni commenti. Scrivere che CreateRenderTargets crea i render target non e' un buon commento. Oppure commentare al quinto if annidato a quale branch si riferisce non e' un buon commento, e' roba da principianti.
E ora mi darai del figlio di Sun di nuovo, ma se scrivi bene dei commenti durante lo sviluppo, poi hai anche la documentazione (leggi javadoc) ;)
Non mi dire che "quando modifichi, poi non li aggiorni", perché allora ti potrei rispondere che "quando modifichi senza commento, prendi cantonate".
Dipende dall'attenzione con cui fai le cose, in un caso e nell'altro.
Si', ti dico che spesso e volentieri i commenti non vengono aggiornati e oltre a essere inutili diventano anche dannosi. Al danno la beffa. Non e' questione di attenzione del codice, sarebbe come dire che basta fare attenzione e non si introducono bug, magari :)
E' questione che il 99% dei commenti sono una chiara violazione del principio DRY come ho detto, sono nient'altro che una duplicazione delle informazioni. E duplicare le informazioni quando si programma e' un male, diminusce la mantenibilita' del codice.
Prova a scrivere meno commenti, concentrati sul codice stesso, riscrivilo in maniera piu' chiara di modo che sia leggibile come fosse inglese: il tuo codice ti ringraziera'.
I commenti sono come il deodorante per la puzza, meglio lavarsi :)
commentare non è inutile a priori... spesso però potrebbe tranquillamete essere sostituito da una naming convention più "umana"
hai la fortuna che un simbolo in C non ha praticamente vincoli sul naming... perchè non sfruttarlo per far assomigliare un programma a un "discorso" in inglese? ;)
Esatto :)
Come dicevo non e' inutile commentare in tutti i casi, e' inutile commentare laddove una semplice riorganizzazione del codice porta ad una struttura piu' leggibile e comprensibile senza essere appesantito da inutili commenti che non fanno altro che riaffermare cio' che il codice gia' afferma. Inoltre il codice che si autodocumenta e' per definizione sempre in perfetta sincronia con se' stesso.
Poi rimane il restante 1% di commenti utili alla comprensione delle assunzioni. L'esempio che faccio sempre in questo caso e' quello della complessita' computazionale di un algoritmo: e' spesso utile commentare che, ad esempio, una ricerca e' O(N) piuttosto che O(N^2) per informare il cliente sul suo utilizzo. E' perfettamente inutile commentare, invece, il fatto che un metodo chiamato FindRecord sta cercando un record :)
jappilas
04-01-2006, 00:01
Si, perché è comprensibile ma non gestibile; non so se rendo l'idea.
imho l' esplicazione di alcuni dei metodi non chiari in quel frammento, si troverà quasi certamente oltre il frammento o in quelle consuetudini che dopo un po' di tempo finiscono nel DNA degli sviluppatori di una certa azienda o di un certo settore
ad esempio... la CheckCapabilities: a me appare quasi scontato che ad essere verificate saranno delle flag relative a funzionalità delle directx supportate o meno, e probabilmente qualunque sviluppatore del settore grafico si troverà a scrivere una funzione con quello scopo e, per esplicatività, a darle un nome simile a quello scelto da fek
Immaginati di essere uno che si trova con quel pezzo di codice davanti la prima volta, o tu stesso dopo 3 anni; a mio avviso ci vorrebbero dei commenti che rispondessero alle domande che riporto.
imho proprio perchè certe cose, quindi anche certi meccanismi, vengono acquisiti magari per via del settore in cui si opera, fek o un suo collega comprenderà quel codice anche tra 3 anni
in questo caso un commento che vedrei bene riguarda se una flag sia attesa vera o falsa di default, non il significato delle variabili...
e' spesso utile commentare che, ad esempio, una ricerca e' O(N) piuttosto che O(N^2) per informare il cliente sul suo utilizzo.
o anche questo :)
ps: mi scuso per la scarsa chiarezza, sono un tantino stanco... :O
@fek e jappilas
Vi offendete se vi dico che sono punti di vista ;) ??
Non potete partire dal presupposto che un codice è scritto in uno stile che per consuetudine comprendete.
Io che non arrivo dalla computer grafica, devo potere comprendere cosa fa un singolo pezzo di codice senza dovermi studiare i pezzi prima o i pezzi dopo.
Poi semmai vado a vederli.
Può darsi che per voi le Capabilities siano una cosa, ma che arrivi un programmatore che con Capabilities ne intende un altra. Un minimo cenno evita menate.
Nei "controcommenti" mi hai detto cosa fanno certe variabili, ma questo si capiva. Infatti ho detto che il codice era comprensibile.
Ma non mi hai detto il perché lo fanno li, piuttosto che non altrove, o perché in un modo piuttosto che in un altro.
E' questo che giustifica la logica del codice: non deve fare qualcosa, ma arrivare a qualcosa. Ti potrei sbattere lì un loop che non fa niente e dirti: "E' chiaro, sta contando da 1 a 1000". Ok, grazie. Ma perché? Se non c'è un perchè, probabilmente è un refuso.
Per quel che ne so, tra 2 mesi guardano quel pezzo di codice che hai postato, potrebbe avere avuto senso inizializzare la variabile a false. Perchè non l'ho fatto? Vuoi mica che mi vada a risfogliare 2000 pagine di specifiche, sempre che esistano ?
Probabilmente alla Sun sono rimasti indietro perché hanno scritto troppo codice ;)
cdimauro
04-01-2006, 08:26
Sarà, ma se il motore cigola preferisco avere la libertà di aprire il cofano e stringermi la vitina piuttosto che andare in officina e farmi smontare mezza automobile senza capire esattamente cosa gli è successo. La libertà di intervenire, quindi, fa una grande differenza. Ovvio che la faccia anche per chi guadagna dal fatto che il software sia chiuso e veda nell'opensource svanire una discreta somma, ma è il prezzo da pagare quando la gente prende coscienza del proprio diritto alla conoscenza e alla trasparenza.
E' un discorso che non regge. L'utente medio non se ne farà niente né dei sorgenti di un programma né del progetto / schema della macchina, perché non saprà intervenire.
E' una questione di conoscenza ed esperienza: se ho sufficienti capacità acquisite, potrò mettere le mani al sorgente di un programma, al motore di una macchina, ma anche all'eseguibile di un programma di cui non ho il sorgente.
cdimauro
04-01-2006, 08:38
Mi sembrano le contestazioni che fa un dipendente di M$ ben istruito da Bill, comunque ....
;)
Non ti permetto di fare illazioni false e tendenziose sul mio conto: non ho alcun rapporto con MS & co., se non in qualità di semplice utente. Mettitolo bene in testa.
Tu chiami comportamento anomalo un modem che si scollega e ricollega, un PC che genera elevato traffico, il disco che ti si riempie ?
L'analisi è comunque più facile se hai il sorgente, piuttosto che no.
Se ci lavori un po' come programmatore, dovresti sapere che dal comportamento anomalo, come lo chiami tu, non risali mai alla causa, ma a cio' che l'ha generato. Da lì parti a circoscrivere il problema, analizzi il codice relativo a quella porzione e vai alla causa.
Certamente, ed è più facile avendo i sorgenti in mano, non c'è dubbio, ma anche senza è possibile lavorare (vedi crack, ricercatori di falle di sicurezza, reverse engineering, ecc.).
Non è che per forza di cose, se cambi una riga tra true a false apri nuovi bugs ;)
Non è per forza di cose, ma è possibilissimo e dovresti saperlo, se hai esperienza nel campo della programmazione.
e comunque preferisco che venga tappato subito un bug noto e rischiare per un bug non noto (che darà un po' da studiare), che non stare con le braghe calate ad aspettare che M$
1) raccolga tot segnalazioni per prenderlo in considerazione
2) indica una riunione per valutare il problema
3) organizzi un piano di intervento
4) istituisca una commissione di sorveglianza
... pausa caffè....
5) distribuisca i pezzi di codice a vari sottogruppi.
La patch che ne uscirà avra meno bugs (dubito), ma nel frattempo mi hanno rigirato per bene il computer oppure ho dovuto staccarlo dalla rete con i danni che ne conseguono.
Infatti la situazione non è come la descrivi, visto che alla segnalazione di un bug MS risponde almeno con un workaround al problema, in attesa di realizzare la patch secondo il suo modello di sviluppo.
P.S.:
Non sono sicuro, ma a differenza di quello che dici, credo che in M$ pochi abbiano la visibilità completa del codice; per lo più ricevono incarico di sviluppare su specifica delle porzioni che poi qualcun altro riassemblerà.
Mi sembra che la situazione non sia diversa da tante altre realtà simili.
cdimauro
04-01-2006, 08:39
Ti contraddici ;)
Nell'attesa che chi produce l'allarme ne rilasci un nuovo modello, il ladro, senza bisogno di impegnarsi in nuovi studi, svaligia l'intera città, non la casa e quando l'antifurto sarà pronto, non ci sarà più niente da proteggere.
Nessuna contraddizione: la vedi soltanto tu.
Pensaci Bill ;)
Se continui così chiederò l'intervento del moderatore.
cdimauro
04-01-2006, 08:45
Dal fatto che è un continuo far notare punti deboli di questo sistema di sviluppo,
Mi sembra che non manchino pro e contro di entrambi i modelli nei miei messaggi: se tu vuoi continuare a vedere soltanto le cose che t'interessano, non posso farci niente.
preferendo addirittura un attività di bugfixing interna all'azienda rispetto alla revisione paritaria del codice.
Non ho detto questo: rileggi meglio.
Appunto.
E comunque non era l'opensource che conosciamo oggi.
Hai ragione: era nettamente migliore, visto che non aveva vincoli e licenze a cui sottostare.
Perchè linux non è una soluzione desktop.
Lo si può usare su un desktop ovviamente, al prezzo di qualche compromesso.
Perfettamente d'accordo.
Mi riferisco al fatto che ho dovuto smettere di propinare GNU/Linux ai miei clienti, perchè dopo l'installazione ed un po' di formazione, il sistema andava talmente bene che si dimenticavano della mia esistenza, ed io non guadagnavo più una lira.
Questo, in un modo o nell'altro, è "qualità".
Hai ragione: sarà per lo stesso motivo che sono pochi i clienti, parenti e amici che mi chiamano dopo che gli ho sistemato il computer con Windows.
cdimauro
04-01-2006, 08:46
Concordo.
Io fossi in lui farei una bella donazione alla SCO, che sta portando avanti una crociata molto simile alla sua su questo forum. :D
ciao ciao!
Io non sto facendo nessuna crociata: dateci un taglio, o chiederò provvedimenti.
cdimauro
04-01-2006, 08:50
Prima di fare questa affermazione, dovresti solo sforzarti di ripensare a quella scena in cui un certo Bill Gates, alla presentazione del suo bel closed source (mi pare Win98), attaccò uno scanner per dimostrare la potenzialità del suo prodotto e venne fuori una schermata blu.
A me sarebbe venuta voglia di spararmi per una figuraccia simile in mondovisione :Prrr:
Cazzi suoi.
Comunque io mi riferivo alla qualità del codice prodotto (ai sorgenti).
ilsensine
04-01-2006, 08:51
Fatto sta che codice di alta qualita' non ha commenti.
Questa è la più bella che ho sentito negli ultimi anni! :sofico: :sofico: :sofico:
Chiunque abbia la sventura di passare parecchie ore della sua vita davanti al codice, sa che è vero...
cdimauro
04-01-2006, 09:13
E quando mai avrei detto che è una tecnologia? :=)
"L'open source nasce con lo scopo di creare una tecnologia migliore e far sì che tutti ne possano partecipare."
;)
Certo, ma le cose cambiano se sono 100 che lo fanno a fin di bene contro 10 che lo fanno con cattive intenzioni. 100 persone hanno più possibilità di 10 persone.
Indubbiamente, ma stiamo parlando astrattamente di possibilità. Tanto per fare un esempio, un solo "cattivone" potrebbe trovare e sfruttare una falla di sicurezza sfuggita agli occhi di 100 "angioletti".
Anche con il modello di sviluppo open source, si testano i cambiamenti apportati :-) Esempio. FireFox ha una vulnerabilità documentata. La patch è già pronta, chi vuole può già applicarla, ma la nuova sottoversione verrà rilasciata solo dopo 5 giorni di testing.
Inoltre, è troppo generico. Sfido io la Microsoft a volerci fare del testing di mesi, quando viene scoperta una vulnerabilità di grado critico in un suo prodotto.
L'ho già scritto: meglio un workaround in attesa di una patch sviluppata con tutti i crismi.
Non ha proprio senso rilasciare una patch subito: c'è il forte rischio di creare più problemi di quanti ne dovrebbe risolvere.
E' come se per curarti una malattia ti dessi subito un vaccino che potrebbe, però, svilupparti un cancro (perché non è stato testato come si deve).
Ovvio che non mi riferisco ai sorgenti, Come si potrebbe mai? Pagagonare Firefox a Opera basandosi sui sorgenti? Quali sorgenti?
Non parlavo in generale: quando parlavo di "opinabile", mi riferivo al fatto che tante volte mi è capitato di avere fra le mani sorgenti di scarsa qualità.
I confronti si possono fare soltanto se si lavora in un'azienda che produce software closed, oppure a causa della "fuoriscita" degli stessi.
Ad esempio, ho avuto la possibilità di analizzare alcuni sorgenti di Windows, e debbo dire che la qualità del codice prodotto è notevole. Idem per quanto riguarda lo stage / tesi di laurea che ho fatto all'STMicroelectronics.
Scusa :°) Ma c'è sempre qualcuno che coordina ogni progetto. Cosa credi? Un responsabile di progetto c'è sempre.
Non sempre: spesso c'è soltanto qualcuno che tira avanti la baracca.
Organizzazioni gerarchiche ne esistono poche, e quando ci sono la libertà di apportare contributi non c'è. Anche per questo esiste il forking.
E uno sguardo a progetti come Apache httpd, gcc e NetBSD, giusto per fare due nomi, no?
Tu l'hai mai data un'occhiata a GCC (e GNU Pascal, che da esso dipendeva fortemente)? Fallo.
cdimauro
04-01-2006, 09:21
Un progetto open source è più insicuro perchè tutti hanno la possibilità di guardare il codice?
La risposta più corretta è no (il che non vuol dire che sia vero il contrario).
A parte quanto scritto già da fek e col quale mi trovo d'accordo, c'è da considerare anche il contesto. Io non renderei mai pubblico lo schema dell'allarme di casa mia, ad esempio.
Ti ripeto di si', sono entrambi linguaggi di modellazione del design formali, uno basato su diagrammi (ad esempio i diagrammi di classe di UML), l'altro sulla descrizione mediante una grammatica formale e piu' vicino al linguaggio naturale delle precondizioni, postcodinzioni e invarianze (JML). Una specie di Design By Contract alla Eiffel, ma decisamente meno elegante.
Sono due strumenti diversi che perseguono gli stessi scopi (e che non adoro).
ti sbagli! servono a due cose diverse! altrimenti xkè li abbiamo usati tutti e due nello stesso progetto? uno serve in una fase della progettazione e l'altro in un'altra! UML è un livello leggermente + alto di JML! e comunque chiunque li ha usati sa ke servono a cose diverse! JML è un linguaggio per dare le specifiche e non è affatto poco elegante come sostieni!
Sono perfettamente in topic invece, visto che stai insultando chiunque non ti dia ragione, mi limito a riportarti in riga :)
io insultato cosa? rileggi tutto a vedere ki insulta ki! incredibile! hai gia perso la memoria?
cdimauro
04-01-2006, 09:29
l'unica cosa certa è ke il modello closed source non significa più sicurezza
Ma nemmeno il contrario: vedi messaggi precedenti.
pensa ke a me all' esame di Ing SW hanno fatto studiare un frammento di codice di un paio di centinaia di linee, con complessità ciclometrica intorno a 35 (se non ricordo male), determinando domini di correttezza per i casi di percorrenza di: tutte le condizioni, tutte le istruzioni, condizioni AND istruzioni... il secondo esercizio consisteva nell' analisi di un' applicazione che gestisse manipolazione da client esterni su strutture dati gerarchiche e aggregate, e modellazione tramite i DP necessari (se non ricordo male ci andava un Composite, un Observer, il Proxy e una Factory... il diagramma mi prese 3 fogli A4... :D)
nessuno ti tormenta... faccio solo un confrontino tra un esame di ingsoft vecchio e nuovo ordinamento :D
guarda ke io non ho detto ke all'esame dovevo produrre la javadoc! ho detto ke la javadoc ke ho prodotto in laboratorio (non ma solo ma in team) è stata valutata! non entriamo nel merito ma non penso proprio ke ora gli esami sono + facili! questa è bella! allora xkè quasi nessuno si riesce a laureare a luglio? si ho dovuto ankio determinare i domini di correttezza non ti preoccupare! tranquillo ke il testing strutturale l'abbiamo fatto!
commentare non è inutile a priori... spesso però potrebbe tranquillamete essere sostituito da una naming convention più "umana"
hai la fortuna che un simbolo in C non ha praticamente vincoli sul naming... perchè non sfruttarlo per far assomigliare un programma a un "discorso" in inglese? ;)
almeno tu ragioni! sono contento ke ci possa essere dialogo! secondo me l'idea di far assomigliare il codice a linguaggio naturale è irrealizzabile! ci hanno provato con sql.. e se non ci sono riusciti i ricercatori di IBM (i migliori di tutto il mondo) ci sarà un motivo! comunque commentare il codice non basta! bisogna commentarlo bene! un codice commentato male è di scarsa qualità, niente da dire.
Ma nemmeno il contrario: vedi messaggi precedenti.
non ho mai detto il contrario! la mia riflessione si basa sulla seguente cosa:
xkè devo mettere in piedi una struttura complessa, rigida e pesante quando con una struttura semplice, elastica e leggera ottengo software ke con la stessa probabilità contiene un bug?
A proposito di sicurezza nel modello di distribuzione closed-source ( :) ), di patch e di velocita' di rilascio delle stesse, tocchera' attendere almeno altri 5 giorni per quella recente (e gravissima) vulnerabilita' di Windows relativa al formato WMF:
http://attivissimo.blogspot.com/2006/01/falla-wmf-il-rischio-aumenta-come.html
A quanto pare la situazione e' molto molto grave!
comunque sia io con "documentazione" non intendevo solo i commenti! e tu fek hai detto ke l'intera documentazione è inutile! allora mi kiedo quanti di voi sono riusciti a programmare in java senza avere mai aperto la javadoc! se io costruisco una classe ke fa qualcosa come un modulo a se stante, è indice di qualità fornire una documentazione sufficiente per capire come funziona la classe nei minimi dettagli! inoltre spesso e volentieri il nome di un metodo è autoesplicativo, ma non privo di ambiguità!
e poi quanti di voi quando vogliono sapere cosa fa una funzione di java leggono il suo codice?
open source non va confuso con freeware... rilasciare il sorgente non vuol dire non essere pagato! mi sembra ke questo non sia molto kiaro a voi programmatori closed! allo stesso modo closed source non vuol dire a pagamento (sapevate ke c'è una versione di zone alarm gratis? minimale ovvio! ma x uso domenstico + ke sufficiente)! se poi la maggiorparte del software open viene retribuito mediante offerte opzionali è un altro conto! secondo me non è affatto male come sistema!
Piuttosto che sintetizzare ulteriormente, invece, ti prego di usare piu' parole perche' stai facendo molta confusione. [cut] Il poter guardare dentro il codice non e' una liberta' inalienabile dell'uomo.
;)
Francamente non so che dirti, a questo punto temo che qualunque cosa dica verrà rispedita al mittente con i soliti "non capisco", "non è pertinente" o frasi di rito simili (e francamente un po' infantili). In realtà, si capisce tutto e gli esempi sono pertinenti, almeno alle orecchie di chi vuole ascoltare. I sofismi per ingarbugliare il discorso ("puoi vedere il codice solo se te lo permetto"... e grazie al piffero, verrebbe da aggiungere) sono un po' ridicoli, soprattutto quando il tema è alquanto semplice. In questo caso preciso, dubito che sia possibile un punto di vista comune: io ritengo l'opensource una risorsa, altri lo ritengono una delle tante opzioni. Ma è un'interpretazione strumentale per poterne sminuire il valore: in realtà e inconfutabilmente, tra un programma trasparente ed uno che non posso sapere come sia fatto e cosa contenga, c'è una disparità di valore e affidabilità alquanto palese, specie in tempi come quelli attuali in cui il software, anche grazie a Microsoft e ai suoi investimenti sulla "sicurezza", va sempre più perdendo lo spirito originario per trasformarsi invece in una castrante e sofisticatissima scatola nera il cui scopo non ci è del tutto chiaro.
Sistema la build machine invece di perdere tempo qui nel forum a parlare del piu e del meno :Prrr:
ciao ;)
Ma se la sto prendendo a calci da tre giorni quella maledetta. Va e viene :(
;)
Francamente non so che dirti, a questo punto temo che qualunque cosa dica verrà rispedita al mittente con i soliti "non capisco", "non è pertinente" o frasi di rito simili (e francamente un po' infantili).
sono daccordo! mi sembra ke fek critica a priori qualunque cosa venga detta da me e da te! questo non fa altro ke confondere tutte le persone ke leggono questa discussione e inquina il topic con cose non pertinenti :banned: ! cerchiamo di arrivare a un dialogo invece di dire solo "non sono daccordo punto e basta", "non è vero punto e basta" o "io so molte cose più di te punto e basta"! ma chi crede di essere fek? l'inventore dell'informatica? xkè io dovrei accettare la SUA personale definizione di "open source"? se non gli va bene quella di wikipedia può discuterne con ki l'ha scritta ke magari la correggono!
@fek e jappilas
Vi offendete se vi dico che sono punti di vista ;) ??
Non potete partire dal presupposto che un codice è scritto in uno stile che per consuetudine comprendete.
Io che non arrivo dalla computer grafica, devo potere comprendere cosa fa un singolo pezzo di codice senza dovermi studiare i pezzi prima o i pezzi dopo.
Poi semmai vado a vederli.
Può darsi che per voi le Capabilities siano una cosa, ma che arrivi un programmatore che con Capabilities ne intende un altra. Un minimo cenno evita menate.
Non sono punti di vista invece. Qui stai facendo un errore di fondo: stai confondendo il fatto che a te non e' chiaro il dominio del problema con il fatto che pensi che da questo derivi che il codice stesso non sia chiaro.
Sono due concetti separati: se tu non sai che cosa sia l'HDR (e non sei tenuto a saperlo) significa che non conosci il dominio del problema del quale quel codice e' la soluzione. Non significa che la soluzione stessa non sia chiara, perche' lo e': abilita l'HDR, controlla le capabilities, crea i render target, crea i filtri. Chiunque guardando quel codice capisce questo, perche' e' chiaro dal codice stesso. Spesso quando scrivo codice chiamo un non programmatore e gli chiedo di leggere quello che sto scrivendo; ovviamente un non programmatore non ha dimestichezza con il dominio del problema e neppure con il formalismo, ma proprio per questo voglio vedere se il mio codice riesce a comunicare l'idea della soluzione. Se non ci riesce, lo riscrivo.
Il dominio del problema non dev'essere invece spiegato in codice, viene documentato dai requisiti: se non sai che cosa sia l'HDR e ti interessa saperlo, leggi il documento di requisiti dove e' spiegato, sarebbe oltremodo sbagliato ogni volta che cito l'HDR in codice dover spiegare in un commento che cos'e' :)
Nei "controcommenti" mi hai detto cosa fanno certe variabili, ma questo si capiva. Infatti ho detto che il codice era comprensibile.
Infatti non ha bisogno di commenti :)
Ma non mi hai detto il perché lo fanno li, piuttosto che non altrove, o perché in un modo piuttosto che in un altro.
E' questo che giustifica la logica del codice: non deve fare qualcosa, ma arrivare a qualcosa. Ti potrei sbattere lì un loop che non fa niente e dirti: "E' chiaro, sta contando da 1 a 1000". Ok, grazie. Ma perché? Se non c'è un perchè, probabilmente è un refuso.
Il qualcosa a cui deve arrivare (si chiama dominio del problema) e' documentato dai requisiti, NON deve essere documentato dal codice. Per altro anche in questo caso non sono spesso necessari i commenti, perche' esistono i test (acceptance test) scritti in linguaggio formale che documentano i requisiti, e poi testano se il codice li incontra.
Il perche' poi, ad esempio, controllo le caps e' il poter creare i render target: e' scritto li', nel codice, e' inutile ripeterlo in un commento.
Per quel che ne so, tra 2 mesi guardano quel pezzo di codice che hai postato, potrebbe avere avuto senso inizializzare la variabile a false. Perchè non l'ho fatto? Vuoi mica che mi vada a risfogliare 2000 pagine di specifiche, sempre che esistano ?
No, basta che guarda il codice, il codice ti dice esattamente perche' ho inizializzato quella variabile a false: per disabilitare l'HDR. E' scritto li', nel codice.
ti sbagli! servono a due cose diverse! altrimenti xkè li abbiamo usati tutti e due nello stesso progetto?
Perche' sono due formalismi a due livelli di astrazione differenti, te l'ho scritto. Ma ti devo proprio spiegare tutto. Torna a studiare dai :)
se io costruisco una classe ke fa qualcosa come un modulo a se stante, è indice di qualità fornire una documentazione sufficiente per capire come funziona la classe nei minimi dettagli! inoltre spesso e volentieri il nome di un metodo è autoesplicativo, ma non privo di ambiguità!
e poi quanti di voi quando vogliono sapere cosa fa una funzione di java leggono il suo codice?
No, se sei un principiante scrivi la documentazione, se sei un buon programmatore scrivi gli unit test che documentano in codice le post condizioni e l'interfaccia della classe, e allo stesso tempo la testano.
Quando ho un metodo di una classe e voglio sapere come usarlo leggo i test relativi.
cdimauro
04-01-2006, 10:30
No, l'indentazione e' importante.
E a volte indispensabile. :p
sono daccordo! mi sembra ke fek critica a priori qualunque cosa venga detta da me e da te! questo non fa altro ke confondere tutte le persone ke leggono questa discussione e inquina il topic con cose non pertinenti :banned: ! cerchiamo di arrivare a un dialogo invece di dire solo "non sono daccordo punto e basta", "non è vero punto e basta" o "io so molte cose più di te punto e basta"! ma chi crede di essere fek? l'inventore dell'informatica? xkè io dovrei accettare la SUA personale definizione di "open source"? se non gli va bene quella di wikipedia può discuterne con ki l'ha scritta ke magari la correggono!
La stai mettendo sul personale perche' hai finiti i pochi argomenti a disposizione? :)
Non e' la mia personale definizione di open source, e' la definizione corretta di open source, c'e' una differenza sostanziale che ti sfugge.
E mi sembra di averti spiegato per filo e per segno perche' commentare il codice e' da principianti, la differenza fra modello di distribuzione e metodologia di sviluppo, l'inadeguatezza della documentazione classica. Non e' insultando l'interlocutore che ha una marea di esperienza in piu di te che arrivi al dialogo.
cdimauro
04-01-2006, 10:33
skerzi vero? abbiamo fatto tutte queste cose in ingSW1! ci soffermeremo meglio nel testing in ingSW2! non mi prendere x ignorante ti prego!! il refactoring da solo non basta e i commenti sono vitali a meno ke il mio professore è deficente! ti prego contattalo xkè qui riskiamo ke 2milioni di ingegnieri escono ignoranti dall'università!
No, rischi di trovarti con tante nozioni e strumenti (non dico tutti, sia chiaro) che sul campo (leggi: lavoro) non ti servono.
Perche' sono due formalismi a due livelli di astrazione differenti, te l'ho scritto. Ma ti devo proprio spiegare tutto. Torna a studiare dai :)
xkè rispondi alle domande ke non ti faccio?
tu hai scritto: "Sono due strumenti diversi che perseguono gli stessi scopi" e penso ke questo non puoi contestarlo! adesso scrivi ke sono due livelli di astrazione diversi! come sappiamo ogni livello di astrazione ha uno scopo diverso... no? altrimenti ne facciamo uno solo ke tanto gli altri sono ripetitivi xkè mirano a raggiungere lo stesso scopo!
xkè rispondi alle domande ke non ti faccio?
tu hai scritto: "Sono due strumenti diversi che perseguono gli stessi scopi" e penso ke questo non puoi contestarlo! adesso scrivi ke sono due livelli di astrazione diversi! come sappiamo ogni livello di astrazione ha uno scopo diverso... no? altrimenti ne facciamo uno solo ke tanto gli altri sono ripetitivi xkè mirano a raggiungere lo stesso scopo!
No, e' l'esatto contrario: due livelli di astrazione diversi possono avere lo stesso scopo. Esempio classico: il sistema di interrupt e il modello multithreading. Un thread non e' altro che un livello di astrazione superiore sopra al modello di interrupt dell'architettura e risolvono entrambi il problema di gestire l'esecuzione asincrona del codice.
E' spesso utile avere viste a livelli di astrazione diversi sullo stesso concetto (JML e UML); e' invece deleterio se queste viste devono essere mantenute manualmente come pensi tu si debba fare. Dovrebbero essere create automaticamente, ad esempio creare diagrammi di classe automaticamente dalla descrizione in JML e dal codice, per fornire una vista diversa sul dominio della soluzione.
cdimauro
04-01-2006, 10:38
se non altro so ke tra gli ingredienti di un software open source non ci sono 20 tonnellate di spyware!
Falso.
mi sbaglio se definisco windows uno spyware?
Falso (e leggiti l'EULA).
pensa ke qualke hacker ha dimostrato ke invia un sacco di informazioni violando la privacy!
In tal caso MS sarà stata bombordata di procedimenti nei suoi confronti (in Italia si va anche sul penale: la legislazione in materia è fra le più pesanti / rigorose al mondo). Mi dai qualche link su questa "dimostrazione"?
cdimauro
04-01-2006, 10:39
Secondo me non dovrebbe essere necessario, per un utente, installare software aggiuntivo per proteggersi dal suo stesso sistema operativo. Al massimo, uno dovra' proteggersi da attacchi esterni :) . O no?
Sempre che si tratti di azioni illecite del s.o.... ;)
No, se sei un principiante scrivi la documentazione, se sei un buon programmatore scrivi gli unit test che documentano in codice le post condizioni e l'interfaccia della classe, e allo stesso tempo la testano.
Quando ho un metodo di una classe e voglio sapere come usarlo leggo i test relativi.
dire ke bisogna documentare il codice non esclude ke bisogna fare gli unit test! l'ho detto da qualke parte? io scrivo sia la documentazione ke gli unit test! sono x questo un principiante (x fortuna io insulto)? sai.. è dieci anni ke programmo e sono ancora giovane, lo ammetto! xò devo dire ke fornire la documentazione è una buona prassi da seguire! e su questo non c'è alcun dubbio! mi dispiace ke gente + esperta di me non lo sappia! tutto qua!
cdimauro
04-01-2006, 10:42
comunque non mi stupisce se hai iniziato a programmare in visual basic, si fanno sempre riconoscere quelli!!
Cos'hai contro chi lavora in Visual Basic? Oltre al corso di Ingegneria del Software, hai per caso travisato anche le nozioni di quello di Linguaggi di Programmazione? :rolleyes:
cos'è un cyborg inviato da MicroSold?
Siamo a corto di argomenti, eh? Com'è che PUNTUALMENTE escono fuori questi discorsi? :rolleyes: :mc:
La stai mettendo sul personale perche' hai finiti i pochi argomenti a disposizione? :)
Non e' la mia personale definizione di open source, e' la definizione corretta di open source, c'e' una differenza sostanziale che ti sfugge.
E mi sembra di averti spiegato per filo e per segno perche' commentare il codice e' da principianti, la differenza fra modello di distribuzione e metodologia di sviluppo, l'inadeguatezza della documentazione classica. Non e' insultando l'interlocutore che ha una marea di esperienza in piu di te che arrivi al dialogo.
ti ho già kiesto di darmi la fonte della tua definizione così ne possiamo discutere! oppure è corretta solo xkè la pensi te?
dire ke bisogna documentare il codice non esclude ke bisogna fare gli unit test! l'ho detto da qualke parte? io scrivo sia la documentazione ke gli unit test! sono x questo un principiante (x fortuna io insulto)?
Si', sbagli. Stai duplicando informazioni in maniera inutile. E' un tipico errore da principiante. In un team di sviluppo serio saresti improduttivo e quindi eliminato.
Essere un principiante non e' un insulto, anzi, e' un'ottima situazione dalla quale partire per imparare le metodologie di sviluppo corrette; se si ha voglia e capacita' di imparare ovviamente.
No, e' l'esatto contrario: due livelli di astrazione diversi possono avere lo stesso scopo. Esempio classico: il sistema di interrupt e il modello multithreading. Un thread non e' altro che un livello di astrazione superiore sopra al modello di interrupt dell'architettura e risolvono entrambi il problema di gestire l'esecuzione asincrona del codice.
E' spesso utile avere viste a livelli di astrazione diversi sullo stesso concetto (JML e UML); e' invece deleterio se queste viste devono essere mantenute manualmente come pensi tu si debba fare. Dovrebbero essere create automaticamente, ad esempio creare diagrammi di classe automaticamente dalla descrizione in JML e dal codice, per fornire una vista diversa sul dominio della soluzione.
prima di tutto non mi pare ke il livello di interrupt risolve il problema di gestire l'esecuzione asincrona del codice! ma dove l'hai letto? il sistema di interrupt è + generale e stiamo quasi al livello HW (leggi problemi della gestione di un BUS).
cambia esempio se vuoi convincermi!
ti ho già kiesto di darmi la fonte della tua definizione così ne possiamo discutere! oppure è corretta solo xkè la pensi te?
Che noia:
http://www.aardvarkmedia.co.uk/glossary.html
Open Source
Computer software source code that is released under an open-source license or to the public domain. Open source licenses include the GNU General Public License. Popular open-source software includes: Apache, PHP, Mozilla Firebird and the Linux kernel.
http://curry.edschool.virginia.edu/go/www_uses/demos/glossary.html
open source
Software that is distributed in such a way that the original source of the program is accessible to the holder of the product. An effort in the computing community to promote the concept. Unix, Mac OSX, PHP, and other products are now available in open source form.
Ed infine, direttamente dall'Open Source Definition:
http://perens.com/OSD.html
The Open Source Definition is a bill of rights for the computer user. It defines certain rights that a software license must grant you to be certified as Open Source.
Come vedi non fa riferimento alla metodologia di sviluppo ma solo al modello di distribuzione.
Ora, per favore, non ammorbarci ulteriormente con questo problema gia' risolto :)
cdimauro
04-01-2006, 10:48
http://www.consultingtimes.com/ossdev.html :)
Quindi?
prima di tutto non mi pare ke il livello di interrupt risolve il problema di gestire l'esecuzione asincrona del codice! ma dove l'hai letto? il sistema di interrupt è + generale e stiamo quasi al livello HW (leggi problemi della gestione di un BUS).
cambia esempio se vuoi convincermi!
E vedi un po' tu quale problema risolvono gli interrupt. Davvero, e' snervante discutere con uno come te che non ha la piu' pallida idea di che cosa stia parlando. Doverti pure spiegare che cos'e' un interrupt e' avvilente.
cdimauro
04-01-2006, 10:50
x lo meno c'è scritto nel codice se c'è uno spyware
Tu dicevi che un hacker aveva dimostrato che veniva violata la privacy: questo che hai scritto ora che c'entra?
Comunque è da vedere se si tratta veramente di spyware.
Falso.
Falso (e leggiti l'EULA).
In tal caso MS sarà stata bombordata di procedimenti nei suoi confronti (in Italia si va anche sul penale: la legislazione in materia è fra le più pesanti / rigorose al mondo). Mi dai qualche link su questa "dimostrazione"?
la mia considerazione si riferiva al fatto ke se c'è uno spyware in un SW open c'è scritto nel codice, mentre in un SW closed non lo posso sapere! anke se me lo garantisce il produttore stesso io non ci crederei + di tanto! è come kiedere a sun se è meglio java o .NET!
cdimauro
04-01-2006, 10:55
niente di personale credimi! ma in visual basic sembra sia impossibile applicare una qualke regola di ingSW! magari è ottimo x fare altre cose ma qui parliamo di ingSW!
"Sembra"? Ma tu l'hai mai visto il Visual Basic in vita tua? "Sembra" -> stai giudicando un prodotto senza conoscerlo!?! :muro:
cdimauro
04-01-2006, 10:57
mi sembri fuori topic! se fossi il moderatore ti bannerei! non devi prenderla sul personale!! rispondi alle domande invece! byez (sul serio)
Perché non cominci a farlo tu? Manca ancora la tua risposta in merito al codice autoesplicativo che fek ha postato per ben 2 volte, e alla presunta necessità di avere commenti nel codice di qualità. :mc:
Che noia:
http://www.aardvarkmedia.co.uk/glossary.html
Open Source
Computer software source code that is released under an open-source license or to the public domain. Open source licenses include the GNU General Public License. Popular open-source software includes: Apache, PHP, Mozilla Firebird and the Linux kernel.
http://curry.edschool.virginia.edu/go/www_uses/demos/glossary.html
open source
Software that is distributed in such a way that the original source of the program is accessible to the holder of the product. An effort in the computing community to promote the concept. Unix, Mac OSX, PHP, and other products are now available in open source form.
Ed infine, direttamente dall'Open Source Definition:
http://perens.com/OSD.html
The Open Source Definition is a bill of rights for the computer user. It defines certain rights that a software license must grant you to be certified as Open Source.
Come vedi non fa riferimento alla metodologia di sviluppo ma solo al modello di distribuzione.
Ora, per favore, non ammorbarci ulteriormente con questo problema gia' risolto :)
no non è finita! hai provato a cercare "define:open source" su google? solo un risultato su 10 corrisponde alla tua definizione! rassegnati non sei dio!
http://www.google.com/search?hl=en&q=define%3A+open+source&btnG=Google+Search
Sempre che si tratti di azioni illecite del s.o.... ;)
Beh, si parlava di presunti spyware inclusi nel sistema operativo o di azioni non richieste riguardanti i dati privati dell'utente. Comunque lo avevo premesso nel post che precedeva quello da te citato:
In linea di massima, un produttore di sw puo' mettere nel suo prodotto quello che vuole ma, nel caso faccia una cosa del genere con i dati dell'utente, dovrebbe riportarlo a chiare lettere e chiedere esplicita autorizzazione per quello che sta facendo. Se non lo fa, viola la legge. E se e' stato dimostrato che un prodotto viola la legge, il produttore credo possa essere denunciato.
Grossomodo e' quanto tu stesso avevi detto in un altro thread, penso quello relativo a Microsoft e monopolio.
Ciao :)
"Sembra"? Ma tu l'hai mai visto il Visual Basic in vita tua? "Sembra" -> stai giudicando un prodotto senza conoscerlo!?! :muro:
ho usato VB fino alla versione 6 (non xkè mi trovavo bene ma xkè ho dovuto)! spero ke nella versione .NET sia migliorato qualcosa, xkè fino alla 6 un programma scritto in VB risultava illeggibile una volta terminato (non bisogna neanke aspettare gli anni)! comunque niente in contrario con ki programma in VB! in alcuni ambiti è proprio quello ke ci vuole!
Perché non cominci a farlo tu? Manca ancora la tua risposta in merito al codice autoesplicativo che fek ha postato per ben 2 volte, e alla presunta necessità di avere commenti nel codice di qualità. :mc:
ho già risposto ke il codice autoesplicativo è un'utopia! leggi tutto grazie.. poi vuoi ke elenco le domande a cui fek non ha risposto?
no non è finita! hai provato a cercare "define:open source" su google? solo un risultato su 10 corrisponde alla tua definizione! rassegnati non sei dio!
http://www.google.com/search?hl=en&q=define%3A+open+source&btnG=Google+Search
Mi spiace, non faccio guerre di google come fai tu, mi basta che l'Open Software Definition, che e' l'autorita' in materia, riporti la mia stessa definizione e sono contento cosi' :)
Il resto e' il tuo infantile tentativo di tirare un topic per le lunghe per riprenderti dalla sequela di figure da cioccolataio che stai facendo. Ti consiglio di tornare a studiare.
ho già risposto ke il codice autoesplicativo è un'utopia! leggi tutto grazie.. poi vuoi ke elenco le domande a cui fek non ha risposto?
Ho risposto a tutto, non ti ho dato le risposte che volevi, ma questo e' un tuo problema.
Il codice autoesplicativo e' un'utopia se non sai programmare. Per chi sa programmare e' una splendida realta'.
cdimauro
04-01-2006, 11:06
non ho mai detto il contrario! la mia riflessione si basa sulla seguente cosa:
xkè devo mettere in piedi una struttura complessa, rigida e pesante quando con una struttura semplice, elastica e leggera ottengo software ke con la stessa probabilità contiene un bug?
Perché i giudizi che stai dando sulle due cose non sono affatto vere.
cdimauro
04-01-2006, 11:06
A proposito di sicurezza nel modello di distribuzione closed-source ( :) ), di patch e di velocita' di rilascio delle stesse, tocchera' attendere almeno altri 5 giorni per quella recente (e gravissima) vulnerabilita' di Windows relativa al formato WMF:
http://attivissimo.blogspot.com/2006/01/falla-wmf-il-rischio-aumenta-come.html
A quanto pare la situazione e' molto molto grave!
Già detto: MS ha già pubblicato un workaround. ;)
Perché i giudizi che stai dando sulle due cose non sono affatto vere.
Direi che sono proprio campati in aria a partire da una base di preparazione sull'argomento molto approssimativa.
E vedi un po' tu quale problema risolvono gli interrupt. Davvero, e' snervante discutere con uno come te che non ha la piu' pallida idea di che cosa stia parlando. Doverti pure spiegare che cos'e' un interrupt e' avvilente.
gli interrupt risolvono anke il problema del lettore cd ke kiede di scrivere nel bus mentre anke l'hard disk vuole farlo! come vedi questo il multithreading non lo gestisce!
e' invece deleterio se queste viste devono essere mantenute manualmente come pensi tu si debba fare. Dovrebbero essere create automaticamente, ad esempio creare diagrammi di classe automaticamente dalla descrizione in JML e dal codice, per fornire una vista diversa sul dominio della soluzione.
sono daccordo! ci sono strumenti sofisticati x generare codice in automatico e vanno usati! prova poseidon! io mi sono trovato bene! ma attento ke il fatto ke siano generati in automatico non vuol dire ke sono assenti!
Perché i giudizi che stai dando sulle due cose non sono affatto vere.
spiegami xkè! sono contento se qualkuno mi spiega la verità
cdimauro
04-01-2006, 11:11
open source non va confuso con freeware... rilasciare il sorgente non vuol dire non essere pagato! mi sembra ke questo non sia molto kiaro a voi programmatori closed!
E' chiarissimo. Noto, invece, che spesso non è chiaro a chi fa uso di prodotti open source, che li spacciano sempre per gratis... ;)
allo stesso modo closed source non vuol dire a pagamento (sapevate ke c'è una versione di zone alarm gratis? minimale ovvio! ma x uso domenstico + ke sufficiente)!
Esattamente, ma è cosa nota: public domain e freeware esistono da decenni.
se poi la maggiorparte del software open viene retribuito mediante offerte opzionali è un altro conto! secondo me non è affatto male come sistema!
Certamente.
Ho risposto a tutto, non ti ho dato le risposte che volevi, ma questo e' un tuo problema.
Il codice autoesplicativo e' un'utopia se non sai programmare. Per chi sa programmare e' una splendida realta'.
non mi hai detto se in B&W hai progettato o implementato.. c'è differenza
gli interrupt risolvono anke il problema del lettore cd ke kiede di scrivere nel bus mentre anke l'hard disk vuole farlo! come vedi questo il multithreading non lo gestisce!
E' un esecuzione asincrona che viene mappata sui thread ad un livello di astrazione piu' alto piu' alto :)
non mi hai detto se in B&W hai progettato o implementato.. c'è differenza
Progetto (faccio il design) sempre mentre scrivo il codice. Si chiama design evolutivo. Mai su carta prima di scrivere il codice, come ad esempio insegnano all'Universita': e' sbagliato.
E' chiarissimo. Noto, invece, che spesso non è chiaro a chi fa uso di prodotti open source, che li spacciano sempre per gratis... ;)
Esattamente, ma è cosa nota: public domain e freeware esistono da decenni.
Certamente.
siamo daccordo allora! lo dico xkè a qualk1 sembra ke programmare a sorgente aperto sia sinonimo di non guadagnare
cdimauro
04-01-2006, 11:16
;)
Francamente non so che dirti, a questo punto temo che qualunque cosa dica verrà rispedita al mittente con i soliti "non capisco", "non è pertinente" o frasi di rito simili (e francamente un po' infantili). In realtà, si capisce tutto e gli esempi sono pertinenti, almeno alle orecchie di chi vuole ascoltare. I sofismi per ingarbugliare il discorso ("puoi vedere il codice solo se te lo permetto"... e grazie al piffero, verrebbe da aggiungere) sono un po' ridicoli, soprattutto quando il tema è alquanto semplice. In questo caso preciso, dubito che sia possibile un punto di vista comune: io ritengo l'opensource una risorsa, altri lo ritengono una delle tante opzioni. Ma è un'interpretazione strumentale per poterne sminuire il valore: in realtà e inconfutabilmente, tra un programma trasparente ed uno che non posso sapere come sia fatto e cosa contenga, c'è una disparità di valore e affidabilità alquanto palese, specie in tempi come quelli attuali in cui il software, anche grazie a Microsoft e ai suoi investimenti sulla "sicurezza", va sempre più perdendo lo spirito originario per trasformarsi invece in una castrante e sofisticatissima scatola nera il cui scopo non ci è del tutto chiaro.
A me sembra che sia tu a non voler capire e riportare sempre le stesse questioni. Ad esempio qui continui a parlare dei programmi closed come di oggetti di cui NON puoi sapere cosa contengano e cosa fanno: è assolutamente errato, e te l'ho già scritto in tutte le salse.
E' infantile continuare a sostenere le stesse cose anche di fronte alla dimostrazione della loro falsità: altro che "punti di vista" diversi. :rolleyes:
E' un esecuzione asincrona che viene mappata sui thread ad un livello di astrazione piu' alto piu' alto :)
mi stai dicendo ke il lettore cd è un thread? spiegati meglio! è un argomento complesso, non puoi esaurirlo con una riga!
mi stai dicendo ke il lettore cd è un thread? spiegati meglio! è un argomento complesso, non puoi esaurirlo con una riga!
No, ho detto che il sistema di interrupt viene mappato sui thread ad un livello di astrazione piu' alto. E' chiarissimo. Per favore, non allungare il thread inutilmente attaccandoti a tutto quello che scrivo. E' snervante, infantile e inutile.
Progetto (faccio il design) sempre mentre scrivo il codice. Si chiama design evolutivo. Mai su carta prima di scrivere il codice, come ad esempio insegnano all'Universita': e' sbagliato.
pensa ke noi quando abbiamo fatto il progetto il diagramma delle classi l'abbiamo ultimato solo dopo ke era finito il codice! quindi vedi ke poi all'università non insegnano tanto male! comunque credo ke il professore ghezzi ne sappia qualcosa + di te.. forse non ti sei documentato abbastanza o non l'hai ancora contattato!
cdimauro
04-01-2006, 11:22
la mia considerazione si riferiva al fatto ke se c'è uno spyware in un SW open c'è scritto nel codice, mentre in un SW closed non lo posso sapere!
Falso. Hai mai sentito parlare di reverse engineering, di decompilazione / resourceing, tracing, ecc.?
anke se me lo garantisce il produttore stesso io non ci crederei + di tanto! è come kiedere a sun se è meglio java o .NET!
Questi sono fatti tuoi: non c'entrano nulla col discorso di cui sopra.
pensa ke noi quando abbiamo fatto il progetto il diagramma delle classi l'abbiamo ultimato solo dopo ke era finito il codice! quindi vedi ke poi all'università non insegnano tanto male! comunque credo ke il professore ghezzi ne sappia qualcosa + di te.. forse non ti sei documentato abbastanza o non l'hai ancora contattato!
Non e' una gara a chi ne sa di piu' fra me e il tuo professore.
Riguardo all'Ingegneria del Software, essendo il mio campo di lavoro da piu' di dieci anni, credo di essere ben documentato. Stai venendo a noia con quest'arroganza :)
No, ho detto che il sistema di interrupt viene mappato sui thread ad un livello di astrazione piu' alto. E' chiarissimo. Per favore, non allungare il thread inutilmente attaccandoti a tutto quello che scrivo. E' snervante, infantile e inutile.
no solo adesso ho capito quello ke intendevi! prima non era chiaro! comunque dovresti sapere ke il sistema di interrupt dei bus asincroni è implementato via HW con particolari circuiti detti "arbitri"! master, slave.. ti dice niente? non ho ancora capito a quale thread fai riferimento quando si parla di lettori cd e hard disk...
no solo adesso ho capito quello ke intendevi! prima non era chiaro! comunque dovresti sapere ke il sistema di interrupt dei bus asincroni è implementato via HW con particolari circuiti detti "arbitri"! master, slave.. ti dice niente? non ho ancora capito a quale thread fai riferimento quando si parla di lettori cd e hard disk...
Si', so come sono implementati gli interrupt a livello hardware. Smettila. E ti ho gia' detto spiegato il concetto, non ho intenzione di farlo ulteriormente. Non sono il tuo insegnante di sostegno.
Non e' una gara a chi ne sa di piu' fra me e il tuo professore.
Riguardo all'Ingegneria del Software, essendo il mio campo di lavoro da piu' di dieci anni, credo di essere ben documentato. Stai venendo a noia con quest'arroganza :)
l'arroganza l'hai portata te in questa discussione quando hai cominciato a sparare fuori termini tecnici nella speranza ke io non li capissi! comunque mi pareva ke avevi detto ke ti avrebbe fatto piacere discutere con lui di cose serie! ke aspetti?
jappilas
04-01-2006, 11:26
guarda ke io non ho detto ke all'esame dovevo produrre la javadoc! ho detto ke la javadoc ke ho prodotto in laboratorio (non ma solo ma in team) è stata valutata! non entriamo nel merito ma non penso proprio ke ora gli esami sono + facili! questa è bella! allora xkè quasi nessuno si riesce a laureare a luglio? si ho dovuto ankio determinare i domini di correttezza non ti preoccupare! tranquillo ke il testing strutturale l'abbiamo fatto!
non era per stabilire "il mio è stato più difficile del tuo", se confronto c' era era più a livello di "cose insegnate e chieste all' esame", nel senso di ampiezza del programma
inoltre ho ripensato solo in secondo tempo (ma se anche l' avessi fatto in tempo non avrei editato il post precedente) che i corsi nel nuovo ordinamento sono più frammentati, quindi quello che posso aver studiato che tu non abbia avuto l' opportunità di vedere, probabilmente ti toccherà in ing. soft. 2...
su questo ti dò atto ;)
almeno tu ragioni! sono contento ke ci possa essere dialogo! secondo me l'idea di far assomigliare il codice a linguaggio naturale è irrealizzabile! ok, ci hanno provato con sql.. e se non ci sono riusciti i ricercatori di IBM (i migliori di tutto il mondo) ci sarà un motivo
:)
ma perchè irrealizzabile? che in un listato la sintassi del C, come la sintassi dell' SQL nel corpo di una query, siano sempre presenti, visibili al programmatore e da esso gestibili, è certo
ma imho è anche possibile farle rimanere "unobtrusive" ("non invasive", non mi veniva termine migliore), cercando di curare sia l' algoritmo sia il naming
cdimauro
04-01-2006, 11:26
ho usato VB fino alla versione 6 (non xkè mi trovavo bene ma xkè ho dovuto)! spero ke nella versione .NET sia migliorato qualcosa, xkè fino alla 6 un programma scritto in VB risultava illeggibile una volta terminato (non bisogna neanke aspettare gli anni)!
Il codice "cattivo" lo puoi scrivere male con qualunque linguaggio.
Viceversa, il codice buono (e leggibile) lo puoi scrivere con qualunque linguaggio (anche col Visual Basic 6).
Non puoi biasimare il VB6 se qualcuno non sa scrive altro che codice illegibile con esso.
Come dicono dalle mie parti: "il pesce puzza dalla testa". Quella del programmatore, in questo caso...
Falso. Hai mai sentito parlare di reverse engineering, di decompilazione / resourceing, tracing, ecc.?
Questi sono fatti tuoi: non c'entrano nulla col discorso di cui sopra.
ci sono mille modi x nascondere uno spyware nel SO! comunque non sta a me giudicare se win lo fa o no! quindi sostanzialmente facciamo ke windows non è + uno spyware xkè non ce ne è la certezza!
cdimauro
04-01-2006, 11:28
ho già risposto ke il codice autoesplicativo è un'utopia!
Per chi non è in grado di realizzarlo, sicuramente.
leggi tutto grazie..
E' proprio quel che sto facendo.
poi vuoi ke elenco le domande a cui fek non ha risposto?
Fallo pure.
l'arroganza l'hai portata te in questa discussione quando hai cominciato a sparare fuori termini tecnici nella speranza ke io non li capissi! comunque mi pareva ke avevi detto ke ti avrebbe fatto piacere discutere con lui di cose serie! ke aspetti?
No, ho semplicemente dimostrato senza ombra di dubbio che non sapevi di che cosa stavi parlando. Quando incontrero' il tuo professore ad una conferenza saro' felice di farci due chiacchiere.
cdimauro
04-01-2006, 11:29
Direi che sono proprio campati in aria a partire da una base di preparazione sull'argomento molto approssimativa.
D'altra parte l'ha detto anche lui che è ancora giovane: ha tutto il tempo per imparare. SE vuole. ;)
jappilas
04-01-2006, 11:29
io mi sto perdendo un tantino... da cosa è uscito il discorso sugli interrupt? :O
D'altra parte l'ha detto anche lui che è ancora giovane: ha tutto il tempo per imparare. SE vuole. ;)
O certo, se vuole. Fa un po' sorridere come si ostini a ribattere senza ne' capo ne' coda ad argomenti che non coglie posti da gente con un po' di esperienza in piu' del piccolo studentello ancora alle prese con l'esamge di ingegneria del software :)
cdimauro
04-01-2006, 11:31
sono daccordo! ci sono strumenti sofisticati x generare codice in automatico e vanno usati! prova poseidon! io mi sono trovato bene! ma attento ke il fatto ke siano generati in automatico non vuol dire ke sono assenti!
Fra Poseidon e Umbrello non so chi sia il peggiore.
Comunque preferisco scrivere del codice e tirare fuori il diagramma UML SE mi serve, con tool come ModelMaker (per Delphi).
io mi sto perdendo un tantino... da cosa è uscito il discorso sugli interrupt? :O
Era un esempio di come diversi livelli di astrazione risolvano lo stesso problema. Poi ha menato il can per l'aia pur di negare l'evidenza. Sostanzialmente ogni volta che gli dimostro un errore madornale, prende un particolare di quello che ho scritto e lo contesta per sviare il discorso. E' quanto meno infantile e rende il thread illeggibile perche' si salta di palo in frasca.
non era per stabilire "il mio è stato più difficile del tuo", se confronto c' era era più a livello di "cose insegnate e chieste all' esame", nel senso di ampiezza del programma
inoltre ho ripensato solo in secondo tempo (ma se anche l' avessi fatto in tempo non avrei editato il post precedente) che i corsi nel nuovo ordinamento sono più frammentati, quindi quello che posso aver studiato che tu non abbia avuto l' opportunità di vedere, probabilmente ti toccherà in ing. soft. 2...
su questo ti dò atto ;)
:)
ma perchè irrealizzabile? che in un listato la sintassi del C, come la sintassi dell' SQL nel corpo di una query, siano sempre presenti, visibili al programmatore e da esso gestibili, è certo
ma imho è anche possibile farle rimanere "unobtrusive" ("non invasive", non mi veniva termine migliore), cercando di curare sia l' algoritmo sia il naming
in ingSW2 approfondiamo la fase di testing! ti assicuro ke i ritmi del nuovo ordinamento non sono x niente rilassanti :,(...
per tornare al codice-linguaggio naturale... è da quando esiste la programmazione ke uno vorrebbe scrivere "fai due più uno e poi stampalo a schermo" (esempio stupido lo ammetto ma è x dare un'idea), ma il linguaggio naturale è troppo complesso rispetto a un linguaggio di programmazione! dove qualcosa non si riesce a esprimere in C lo si deve kiarire con un commento (se programmi in C raramente ottieni qualkosa ke assomiglia anke solo vagamente al linguaggio naturale)! certo... alcuni linguaggi di altissimo livello hanno raggiunto una notevole semplicità, ma non sempre si può usare un linguaggio di altissimo livello!
No, ho semplicemente dimostrato senza ombra di dubbio che non sapevi di che cosa stavi parlando. Quando incontrero' il tuo professore ad una conferenza saro' felice di farci due chiacchiere.
non me ne sono accorto! :D
io mi sto perdendo un tantino... da cosa è uscito il discorso sugli interrupt? :O
secondo te il sistema a interrupt risolve lo stesso problema del multithreading? a me sembra ke uno tratti di gestire + processi contemporaneamente, mentre l'altro di gestire + periferike contemporaneamente! le problematike sono sostanzialmente diverse... anke in qualke modo non mancano punti in comune (a livello astratto)
cdimauro
04-01-2006, 11:41
spiegami xkè! sono contento se qualkuno mi spiega la verità
Hai appioppato "complessa, rigida e pesante" a chi sviluppa software closed e "semplice, elastica e leggera" a chi sviluppa software open: non è affatto vero! Dove sta scritto?
Per chi non è in grado di realizzarlo, sicuramente.
dillo ai ricercatori di IBM ke si sono persi qualcosa..
Falso. Hai mai sentito parlare di reverse engineering, di decompilazione / resourceing, tracing, ecc.?
Pero' ricordiamo anche che molto spesso (quasi sempre) il reverse engineering, la decompilazione e anche la modifica dei binari di un programma commerciale closed-source rappresenta una violazione della licenza. Quindi, una persona rispettosa della legge non potrebbe mai nemmeno pensare di disassemblare il codice, anche se per cercare la presenza di software maligno e non per crackare o danneggiare un sistema.
Il mio discorso fa sempre riferimento alla eventuale presenza di spyware nel sistema operativo e ai metodi per bloccarli, nulla ha a che vedere con la bonta' del codice closed vs. quello open, o con il diritto di disporre dei sorgenti per la tutela della liberta' dell'utente finale :)
in ingSW2 approfondiamo la fase di testing! ti assicuro ke i ritmi del nuovo ordinamento non sono x niente rilassanti :,(...
per tornare al codice-linguaggio naturale... è da quando esiste la programmazione ke uno vorrebbe scrivere "fai due più uno e poi stampalo a schermo" (esempio stupido lo ammetto ma è x dare un'idea), ma il linguaggio naturale è troppo complesso rispetto a un linguaggio di programmazione! dove qualcosa non si riesce a esprimere in C lo si deve kiarire con un commento (se programmi in C raramente ottieni qualkosa ke assomiglia anke solo vagamente al linguaggio naturale)! certo... alcuni linguaggi di altissimo livello hanno raggiunto una notevole semplicità, ma non sempre si può usare un linguaggio di altissimo livello!
Ancora non ti e' chiaro cio' che abbiamo detto. Lo scopo e' di far assomigliare il codice il piu' possibile al linguaggio naturale, di modo che il codice "sia leggibile come se fosse inglese", non che sia l'inglese. Sono due cose diverse.
Le assunzioni che non sono esprimibili in codice vanno commentate e con i linguaggi moderni molto espressivi questi casi sono pochissimi (se sai programmare, ovviamente). Anche in C sono spesso in grado di ottenere codice che assomiglia molto al linguaggio naturale.
Mentre e' ovviamente sbagliato che un concetto che non e' esprimibile in codice vada commentato, perche' i commenti non vengono eseguiti per ovvi motivi.
in ingSW2 approfondiamo la fase di testing! ti assicuro ke i ritmi del nuovo ordinamento non sono x niente rilassanti :,(...
per tornare al codice-linguaggio naturale... è da quando esiste la programmazione ke uno vorrebbe scrivere "fai due più uno e poi stampalo a schermo" (esempio stupido lo ammetto ma è x dare un'idea), ma il linguaggio naturale è troppo complesso rispetto a un linguaggio di programmazione! dove qualcosa non si riesce a esprimere in C lo si deve kiarire con un commento (se programmi in C raramente ottieni qualkosa ke assomiglia anke solo vagamente al linguaggio naturale)! certo... alcuni linguaggi di altissimo livello hanno raggiunto una notevole semplicità, ma non sempre si può usare un linguaggio di altissimo livello!
La soluzione è se in C non riesci non usarlo. :)
Il mondo dei linguaggi è in continua espansione. Linguaggi come Ruby, C#, Java e anche il Python, tanto caro a cdimauro, ti permettono di scrivere cose chiarissime con un po di esperienza.
ciao ;)
Hai appioppato "complessa, rigida e pesante" a chi sviluppa software closed e "semplice, elastica e leggera" a chi sviluppa software open: non è affatto vero! Dove sta scritto?
non hai capito! forse io ho sbagliato a descriverli in modo così nettamente antipodali! la verità sta un pò + in mezzo... comunque non ti ho kiesto di giudicare la mia affermazione vera o falsa ma di giustificare la tua tesi secondo la quale ad esempio la struttura di sviluppo adottata da MS è semplice, elastica e leggera..
cdimauro
04-01-2006, 11:44
ci sono mille modi x nascondere uno spyware nel SO!
E ce ne sono 10 mila per scovarli.
comunque non sta a me giudicare se win lo fa o no! quindi sostanzialmente facciamo ke windows non è + uno spyware xkè non ce ne è la certezza!
Facciamo che, fino a "prova provata" (termine giuridico), nessun software, né closed né open source, può essere accusato di essere spyware.
La soluzione è se in C non riesci non usarlo. :)
Il mondo dei linguaggi è in continua espansione. Linguaggi come Ruby, C#, Java e anche il Python, tanto caro a cdimauro, ti permettono di scrivere cose chiarissime con un po di esperienza.
ciao ;)
purtroppo il C è ankora indispensabile in alcuni ambiti! l'alto livello è bello ma esiste anke il basso livello! e se nell'alto livello bastano poki commenti essenziali, nel basso livello sono davvero indispensabili!
Fra Poseidon e Umbrello non so chi sia il peggiore.
Comunque preferisco scrivere del codice e tirare fuori il diagramma UML SE mi serve, con tool come ModelMaker (per Delphi).
poseidon non è proprio paragonabile a umbrello in quanto a potenzialità... l'unico problema è ke richiede molte risorse al sistema xkè è fatto in java! comunque genera automaticamente diagrammi ke è una meraviglia! te lo consiglio!
Facciamo che, fino a "prova provata" (termine giuridico), nessun software, né closed né open source, può essere accusato di essere spyware.
hai solo ripetuto quello ke ho detto io!
purtroppo il C è ankora indispensabile in alcuni ambiti! l'alto livello è bello ma esiste anke il basso livello! e se nell'alto livello bastano poki commenti essenziali, nel basso livello sono davvero indispensabili!
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).
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).
ok il c++ è leggermente meglio.. ma ankora non si avvicina minimamente al linguaggio naturale! e poi lo vai dire te ai milioni di programmatori ke usano ankora C ke non serve +? sono daccordo ke GNOME è meglio programmarlo in c++, ma ad esempio un kernel qualsiasi lo farei in C!
io ci avrei impiegato meno tempo a commentare... ke inefficienza!
cdimauro
04-01-2006, 11:54
in ingSW2 approfondiamo la fase di testing! ti assicuro ke i ritmi del nuovo ordinamento non sono x niente rilassanti :,(...
per tornare al codice-linguaggio naturale... è da quando esiste la programmazione ke uno vorrebbe scrivere "fai due più uno e poi stampalo a schermo" (esempio stupido lo ammetto ma è x dare un'idea), ma il linguaggio naturale è troppo complesso rispetto a un linguaggio di programmazione! dove qualcosa non si riesce a esprimere in C lo si deve kiarire con un commento (se programmi in C raramente ottieni qualkosa ke assomiglia anke solo vagamente al linguaggio naturale)! certo... alcuni linguaggi di altissimo livello hanno raggiunto una notevole semplicità, ma non sempre si può usare un linguaggio di altissimo livello!
Stai scherzando, vero? Il linguaggio naturale è quello che più si presta a far commettere errori nell'esprimere qualcosa. Anzi, l'ambiguità è una componente, che spesso viene utilizzata. Ad esempio: quante volte capita di non afferare, o afferrare l'opposto, qualcosa espressa in forma ironica / sarcastica. Se pensiamo a una battuta di una mente fine, poi, non ne parliamo.
I linguaggi di programmazione sono nati con obiettivi diversi, e scrivere codice leggibile e autoesplicativo non vuol dire necessariamente cercare di "mimare" quanto si farebbe con un linguaggio naturale.
cdimauro
04-01-2006, 11:55
dillo ai ricercatori di IBM ke si sono persi qualcosa..
Se sono gli stessi che hanno realizzato SEQUEL prima e Query-By-Example dopo, sanno quello che fanno (obiettivi e come raggiungerli). Tanto per fare un esempio. ;)
ok il c++ è leggermente meglio.. ma ankora non si avvicina minimamente al linguaggio naturale! e poi lo vai dire te ai milioni di programmatori ke usano ankora C ke non serve +? sono daccordo ke GNOME + meglio programmarlo in c++, ma ad esempio un kernel qualsiasi lo farei in C
E per l'ennesima volta, il problema non e' se il linguaggio si avvicina o meno al linguaggio naturale.
Ci pensa Stroustrup a dire a chi programma ancora in C (no, non sono milioni) che il C puo' essere sostituito in tutti gli ambiti dal C++ nel suo libro "Design and Evolution of C++".
Se scrivessi un kernel in C sbaglieresti. Un kernel puo' essere scritto in maniera piu' efficace in C++.
Stai scherzando, vero? Il linguaggio naturale è quello che più si presta a far commettere errori nell'esprimere qualcosa. Anzi, l'ambiguità è una componente, che spesso viene utilizzata. Ad esempio: quante volte capita di non afferare, o afferrare l'opposto, qualcosa espressa in forma ironica / sarcastica. Se pensiamo a una battuta di una mente fine, poi, non ne parliamo.
I linguaggi di programmazione sono nati con obiettivi diversi, e scrivere codice leggibile e autoesplicativo non vuol dire necessariamente cercare di "mimare" quanto si farebbe con un linguaggio naturale.
no non sto skerzando! qualke genio dell'informatica ci ha provato x tutta la vita! diglielo ke ha buttato via il tempo!
ti ricordo ke scrivere in italiano (o in inglese) senza ambiguità lo si impara alle elementari credo... io dò sempre x scontato ke sappiamo tutti commentare il codice decentemente :D!
cdimauro
04-01-2006, 11:59
Pero' ricordiamo anche che molto spesso (quasi sempre) il reverse engineering, la decompilazione e anche la modifica dei binari di un programma commerciale closed-source rappresenta una violazione della licenza. Quindi, una persona rispettosa della legge non potrebbe mai nemmeno pensare di disassemblare il codice, anche se per cercare la presenza di software maligno e non per crackare o danneggiare un sistema.
Certamente sono cose da considerare, ma qui stiamo andando nel caso particolare. Allora dovremmo anche considerare i paesi in cui esistono certe norme e altri in cui non ci sono vincoli come questi.
Il punto è, casi particolari di questo tipo a parte, che dato un eseguibile è possibile sapere come funziona, e anche modificarlo.
Il mio discorso fa sempre riferimento alla eventuale presenza di spyware nel sistema operativo e ai metodi per bloccarli, nulla ha a che vedere con la bonta' del codice closed vs. quello open, o con il diritto di disporre dei sorgenti per la tutela della liberta' dell'utente finale :)
Chiaro. ;)
no non sto skerzando! qualke genio dell'informatica ci ha provato x tutta la vita! diglielo ke ha buttato via il tempo!
ti ricordo ke scrivere in italiano (o in inglese) senza ambiguità lo si impara alle elementari credo... io dò sempre x scontato ke sappiamo tutti commentare il codice decentemente :D!
Ecco un altro motivo per il quale i commenti sono deleteri: sono in linguaggio naturale che per definizione non e' univoco e formale, al contrario di un linguaggio di programmazione.
Se sono gli stessi che hanno realizzato SEQUEL prima e Query-By-Example dopo, sanno quello che fanno (obiettivi e come raggiungerli). Tanto per fare un esempio. ;)
SEQUEL e QBE non hanno gli stessi obbiettivi! tanto ke QBE non ha la stessa potenza espressiva di SQL! significa ke non tutte le query ke fai in SQL puoi tradurle in QBE!
Ecco un altro motivo per il quale i commenti sono deleteri: sono in linguaggio naturale che per definizione non e' univoco e formale, al contrario di un linguaggio di programmazione.
x questo servono i linguaggi di specifica e la documentazione! comunque visto ke il linguaggio naturale per definizione non e' univoco e formale, al contrario di un linguaggio di programmazione.. xkè non ci esprimiamo in C# in questa discussione? mi sa ke il problema è ke non ci capiamo!
cdimauro
04-01-2006, 12:19
non hai capito! forse io ho sbagliato a descriverli in modo così nettamente antipodali! la verità sta un pò + in mezzo...
Se sta in mezzo vuol dire che fra le due cose non c'è alcuna differenza. :p
comunque non ti ho kiesto di giudicare la mia affermazione vera o falsa ma di giustificare la tua tesi secondo la quale ad esempio la struttura di sviluppo adottata da MS è semplice, elastica e leggera..
Non ho mai detto niente del genere. Non conosco la struttura di MS. Da dove hai dedotto queste cose?
x questo servono i linguaggi di specifica e la documentazione! comunque visto ke il linguaggio naturale per definizione non e' univoco e formale, al contrario di un linguaggio di programmazione.. xkè non ci esprimiamo in C# in questa discussione? mi sa ke il problema è ke non ci capiamo!
Perche' C# e i linguaggi di programmazione formali non sono abbastanza espressivi per esprimere tutti i concetti esprimibili dal linguaggio naturale. Lo imparerai nell'esame di linguaggi e traduttori.
Mentre il linguaggio naturale non puo' esprimere univocamente i concetti che servono ad una macchina per l'esecuzione.
I linguaggi di specifica e la documentazione servono fino a un certo punto, in realta' non servono nella maggior parte dei casi. Si possono esprimere la maggior parte dei requisiti in maniera univoca mediante gli acceptance test in un linguaggio formale. Il vantaggio e' oltre all'univocicita' del linguaggio il fatto che gli acceptance test danno anche un chiaro segnale sul quando e se il requisito e' stato incontrato dal codice.
jappilas
04-01-2006, 12:22
secondo te il sistema a interrupt risolve lo stesso problema del multithreading? a me sembra ke uno tratti di gestire + processi contemporaneamente, mentre l'altro di gestire + periferike contemporaneamente! le problematike sono sostanzialmente diverse... anke in qualke modo non mancano punti in comune (a livello astratto)
per come l' ho imparata, pensavo il multithreading risolvesse alcuni tipi di problemi attraverso la parallelizzazione dei flussi di controllo svincolabili (ad es aumentare l' operatività in un' applicazione o sistema, rendendo non modali più finestre possibili, ... ma ce ne sarebbero tanti altri) mentre gli interrupt hardware risolvano quello dell' arbitraggio degli accessi ad un bus ...
e che fossero quindi sostanzialmente due tecniche di carattere diverso su due livelli diversi... :stordita:
cdimauro
04-01-2006, 12:23
purtroppo il C è ankora indispensabile in alcuni ambiti! l'alto livello è bello ma esiste anke il basso livello! e se nell'alto livello bastano poki commenti essenziali, nel basso livello sono davvero indispensabili!
#define begin {
#define end }
#define endif }
if (Condizione)
begin
end
else
begin
endif
;)
Se sta in mezzo vuol dire che fra le due cose non c'è alcuna differenza. :p
non così tanto in mezzo! non far finta di non capire!
Non ho mai detto niente del genere. Non conosco la struttura di MS. Da dove hai dedotto queste cose?
l'ho dedotto dal fatto ke passano mesi prima ke correggono un bug critico! io mi trovo bene con suse linux xkè i bug critici vengono risolti in un tempo relativamente breve.. comunque se su linux ci mettono 2 mesi a correggere un bug non mi lamento (tanto l'ho avuto gratis), ma in win ho pure pagato x avere un servizio!
cdimauro
04-01-2006, 12:24
poseidon non è proprio paragonabile a umbrello in quanto a potenzialità... l'unico problema è ke richiede molte risorse al sistema xkè è fatto in java! comunque genera automaticamente diagrammi ke è una meraviglia! te lo consiglio!
Preferisco continuare a fare come ho già scritto. ;)
per come l' ho imparata, pensavo il multithreading risolvesse alcuni tipi di problemi attraverso la parallelizzazione dei flussi di controllo svincolabili (ad es aumentare l' operatività in un' applicazione o sistema, rendendo non modali più finestre possibili, ... ma ce ne sarebbero tanti altri) mentre gli interrupt hardware risolvano quello dell' arbitraggio degli accessi ad un bus ...
e che fossero quindi sostanzialmente due tecniche di carattere diverso su due livelli diversi... :stordita:
esattamente quello ke cercavo di spiegare a fek! ma lui non fa altro ke rispondere "no ti sbagli" a tutte le cose ke dico! :D
per come l' ho imparata, pensavo il multithreading risolvesse alcuni tipi di problemi attraverso la parallelizzazione dei flussi di controllo svincolabili (ad es aumentare l' operatività in un' applicazione o sistema, rendendo non modali più finestre possibili, ... ma ce ne sarebbero tanti altri) mentre gli interrupt hardware risolvano quello dell' arbitraggio degli accessi ad un bus ...
e che fossero quindi sostanzialmente due tecniche di carattere diverso su due livelli diversi... :stordita:
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.
Perche' C# e i linguaggi di programmazione formali non sono abbastanza espressivi per esprimere tutti i concetti esprimibili dal linguaggio naturale. Lo imparerai nell'esame di linguaggi e traduttori.
Mentre il linguaggio naturale non puo' esprimere univocamente i concetti che servono ad una macchina per l'esecuzione.
I linguaggi di specifica e la documentazione servono fino a un certo punto, in realta' non servono nella maggior parte dei casi. Si possono esprimere la maggior parte dei requisiti in maniera univoca mediante gli acceptance test in un linguaggio formale. Il vantaggio e' oltre all'univocicita' del linguaggio il fatto che gli acceptance test danno anche un chiaro segnale sul quando e se il requisito e' stato incontrato dal codice.
sono stato io a dire ke un linguaggio di programmazione non potrà mai avere lo stesso potere espressivo del linguaggio naturale! non cerkiamo di girarla come conviene!
puoi fare tutti i test ke vuoi... ma a me in ingSW mi hanno spiegato ke il testing esaustivo è pura utopia!
cdimauro
04-01-2006, 12:30
hai solo ripetuto quello ke ho detto io!
Ma non eri tu che non ti fidavi del software closed? Non eri tu che bollavi Windows come spyware?
66 Mentre Pietro era di sotto, nell'atrio, viene una delle serve del capo dei sacerdoti 67 e, veduto Pietro che si scaldava, guardatolo attentamente, dice: "Anche tu eri con il Nazareno, con Gesù". 68 Ma egli negò dicendo: "Non lo conosco, nè capisco ciò che tu dici". E se ne andò fuori, nel vestibolo, e un gallo cantò. 69 Ora la serva, vedutolo, cominciò di nuovo a dire ai presenti: "Costui è di quelli". 70 Ma egli di nuovo lo negava. E poco dopo, di nuovo, i presenti dicevano a Pietro: "Sicuramente sei di quelli: infatti sei galileo". 71 Ma egli cominciò ad imprecare e a giurare: "Non conosco quest'uomo di cui parlate". 72 E subito un gallo cantò per la seconda volta. Allora Pietro si ricordò della parola che Gesù gli aveva detto: "Prima che un gallo canti due volte mi rinnegherai tre volte". E scoppiò in un pianto dirotto.
sono stato io a dire ke un linguaggio di programmazione non potrà mai avere lo stesso potere espressivo del linguaggio naturale! non cerkiamo di girarla come conviene!
puoi fare tutti i test ke vuoi... ma a me in ingSW mi hanno spiegato ke il testing esaustivo è pura utopia!
Mi sorge il dubbio che tu abbia difficolta' di comprensione del testo, oppure stai solo trolleggiando e stiamo perdendo tutti quanti tempo qui. Rileggi dall'inizio con piu' attenzione.
Provo a fare un piccolo riassunto dello stato della discussione che stai frammentando. Questi sono i fatti:
- Open Source e' un modello di distribuzione del software, non una metodologia di sviluppo.
- Non esiste alcuna metrica oggettiva per definire la sicurezza di un sistema o di un software, quindi affermare che i modelli tipici di sviluppo dietro a software distribuito open source sono piu' o meno sicuri e' privo di significato.
- Commentare diffusamente il codice invece di riscriverlo in maniera leggibile e' una pratica scorretta, perche' peggiora la mantenibilita' del codice stesso.
cdimauro
04-01-2006, 12:37
no non sto skerzando! qualke genio dell'informatica ci ha provato x tutta la vita! diglielo ke ha buttato via il tempo!
Non confondere la ricerca nel campo dei linguaggi di programmazione, che esistono e sono sviluppati per dei motivi ben precisi (leggi anche quello che ha scritto fek), da quella nel campo della comprensione dei linguaggi naturali.
ti ricordo ke scrivere in italiano (o in inglese) senza ambiguità lo si impara alle elementari credo...
Dovresti avere imparato che è normale che si verifichi il contrario.
All'ONU quando si tratta di discutere di questioni delicate, si usa il francese e non l'inglese: secondo te per quale motivo?
io dò sempre x scontato ke sappiamo tutti commentare il codice decentemente :D!
Non è affatto scontato. ;)
cdimauro
04-01-2006, 12:39
SEQUEL e QBE non hanno gli stessi obbiettivi! tanto ke QBE non ha la stessa potenza espressiva di SQL! significa ke non tutte le query ke fai in SQL puoi tradurle in QBE!
Dovresti imparare a leggere e capire quel che dicono gli altri, prima di rispondere: ho forse detto che SQL e QBE hanno gli stessi obiettivi?
Eppure mi sembrava di aver scritto qualcosa di non ambiguo, nel linguaggio naturale che ho utilizzato (l'italiano)... :p
Dovresti imparare a leggere e capire quel che dicono gli altri, prima di rispondere: ho forse detto che SQL e QBE hanno gli stessi obiettivi?
Eppure mi sembrava di aver scritto qualcosa di non ambiguo, nel linguaggio naturale che ho utilizzato (l'italiano)... :p
Sto trovando anch'io le stesse difficolta', gli dici le cose e non le capisce, o secondo me non le legge proprio e va dritto per la sua strada :)
Non mi stupisco che non abbia capito un'acca dell'esame di ingegneria del software allora...
cdimauro
04-01-2006, 12:44
non così tanto in mezzo! non far finta di non capire!
Ma io capisco abbastanza bene: l'hai detto tu che sta in mezzo, no? Forse dovevi essere meno ambiguo... :asd:
l'ho dedotto dal fatto ke passano mesi prima ke correggono un bug critico!
Interessante. Mi spieghi tramite quale procedimento logico arrivi a dedurre tutto ciò? Per curiosità: anch'io ho una fervida immaginazione, ma a certe cose proprio non riesco ad arrivarci... :p
io mi trovo bene con suse linux xkè i bug critici vengono risolti in un tempo relativamente breve..
Riprendiamo il discorso già fatto? E la fase di test? Preferisci togliere di mezzo l'influenza con un vaccino che poi ti può provocare il cancro? :rolleyes:
comunque se su linux ci mettono 2 mesi a correggere un bug non mi lamento (tanto l'ho avuto gratis),
Open source non vuol dire gratis... ;)
ma in win ho pure pagato x avere un servizio!
Se hai pagato pensando di avere un software esente da bug, possono essere soltanto due i casi:
- ti hanno preso in giro;
- non hai ancora affrontato il corso di Teoria della Computabilità.
Nel secondo caso, preparati, perché avrai delle (amare per un programmatore) sorprese. :p
Open source non vuol dire gratis... ;)
Se hai pagato pensando di avere un software esente da bug, possono essere soltanto due i casi:
- ti hanno preso in giro;
- non hai ancora affrontato il corso di Teoria della Computabilità.
Nel secondo caso, preparati, perché avrai delle (amare per un programmatore) sorprese. :p
Come sei crudele, dai, lo hanno giudicato per aver scritto due javadocs, ormai e' un esperto mondiale di ingegneria del software... e' gia' nell'aria un libro scritto a quattro mani fra lui e Martin Fowler :asd:
cdimauro
04-01-2006, 12:51
Sto trovando anch'io le stesse difficolta', gli dici le cose e non le capisce, o secondo me non le legge proprio e va dritto per la sua strada :)
Secondo me tutte e due. :p
Non mi stupisco che non abbia capito un'acca dell'esame di ingegneria del software allora...
Questo ormai è assodato... :asd:
Mi sorge il dubbio che tu abbia difficolta' di comprensione del testo, oppure stai solo trolleggiando e stiamo perdendo tutti quanti tempo qui. Rileggi dall'inizio con piu' attenzione.
ho letto 3 volte.. non capisco dove sbaglio! inoltre l'acceptance test non c'entra nulla con la mantenibilità del codice, quindi non sostituisce la documentazione!
Provo a fare un piccolo riassunto dello stato della discussione che stai frammentando. Questi sono i fatti:
- Open Source e' un modello di distribuzione del software, non una metodologia di sviluppo.
tua personale opinione! smettila di imporla come oro colato
- Non esiste alcuna metrica oggettiva per definire la sicurezza di un sistema o di un software, quindi affermare che i modelli tipici di sviluppo dietro a software distribuito open source sono piu' o meno sicuri e' privo di significato.
infatti io sto cercando di spiegare ke non è vero ke il software closed è + sicuro! sono tutti e due non esenti da bug! xò l'open ha una serie di vantaggi innegabili sotto altri punti di vista
- Commentare diffusamente il codice invece di riscriverlo in maniera leggibile e' una pratica scorretta, perche' peggiora la mantenibilita' del codice stesso.
mi pare ke parlavamo di commentare semplicemente... non diffusamente! stai facendo un passo indietro? hai appena detto ke se commenti bene (non diffusamente) non peggiora la mantenibilità del codice!
comunque rimani della tua opinione!
ho letto 3 volte.. non capisco dove sbaglio! inoltre l'acceptance test non c'entra nulla con la mantenibilità del codice, quindi non sostituisce la documentazione!
Pazienza se non lo capisci.
tua personale opinione! smettila di imporla come oro colato
No, definizione presa dall'Open Source Definition. Rassegnati.
mi pare ke parlavamo di commentare semplicemente... non diffusamente! stai facendo un passo indietro? hai appena detto ke se commenti bene (non diffusamente) non peggiora la mantenibilità del codice!
comunque rimani della tua opinione!
No, sei tu che non hai capito di nuovo quello che abbiamo scritto, eppure era chiaro, rileggi con piu' attenzione :)
Per l'ultima volta, si commenta solo ed esclusivamente le assunzioni che non sono esprimibili in codice (ed e' un fatto raro). Non e' una mia opinione, e' l'opinione diffusa fra i professionisti nel settore con una certa esperienza, e per altro e' l'opinione di gente del calibro di Martin Fowler e Kent Beck. Commentare come suggerisci tu e' da principianti invece.
Ma io capisco abbastanza bene: l'hai detto tu che sta in mezzo, no? Forse dovevi essere meno ambiguo... :asd:
infatti! xò non ho detto al centro! intendevo ke la realtà è un pò + smussata, non far finta di non aver capito!
Interessante. Mi spieghi tramite quale procedimento logico arrivi a dedurre tutto ciò? Per curiosità: anch'io ho una fervida immaginazione, ma a certe cose proprio non riesco ad arrivarci... :p
non è immaginazione ma pura realtà! ti ricordi le recenti vicende su ie6?
Riprendiamo il discorso già fatto? E la fase di test? Preferisci togliere di mezzo l'influenza con un vaccino che poi ti può provocare il cancro? :rolleyes:
guarda ke quelli ke lavorano a suse testano prima di rendere disponibili le patch! non capisco dove vuoi arrivare! trovo ke il loro sistema di aggiornamento sia + veloce, affidabile e trasparente rispetto a quello di MS! dovresti provare prima di giudicare!
Open source non vuol dire gratis... ;)
l'ho detto? ho detto solo ke linux non l'ho pagato! ed è vero! nonostante ciò le patch di suse sono puntuali
Se hai pagato pensando di avere un software esente da bug, possono essere soltanto due i casi:
- ti hanno preso in giro;
- non hai ancora affrontato il corso di Teoria della Computabilità.
quando ho detto ke ho un software esente da bug? skusa ma forse ti sei confuso con qualkun'altro!
Nel secondo caso, preparati, perché avrai delle (amare per un programmatore) sorprese. :p
ahah
Secondo me non capisce e sta solo facendo a gara ad avere l'ultima parola. Infantile :)
Secondo me non capisce e sta solo facendo a gara ad avere l'ultima parola. Infantile :)
secondo me è inutile parlare con voi! pensate ke le vostre idee sono inopinabili e ke non sia possibile ke vi sbagliate su qualkosa... ragionavo così all'asilo!
io sarei infantile? ahah buona questa!!
comunque vi annuncio ke ora vi lascio inquinare questo forum quanto volete! vado a fare cose + importanti!
Non ci sto capendo niente personalmente su tutto questa discussione.... :p
interrupt su un thread in cui si parla di sicurezza dell'opensource? :p
Comunque sia, comincio un pò a ricredermi sull'uso dei commenti.
E' innegabile che un codice scritto come si deve è pure autocommentante... :rolleyes: (nel senso che è palese a cosa serve quel codice)
E poi mi state facendo un impressione su tutti gli argomenti che state sviscerando... devo finire ancora le superiori e rimango perplesso di andare avanti all'università leggendo tutti questi argomenti :ciapet:
Non ci sto capendo niente personalmente su tutto questa discussione.... :p
interrupt su un thread in cui si parla di sicurezza dell'opensource? :p
Comunque sia, comincio un pò a ricredermi sull'uso dei commenti.
E' innegabile che un codice scritto come si deve è pure autocommentante... :rolleyes: (nel senso che è palese a cosa serve quel codice)
E poi mi state facendo un impressione su tutti gli argomenti che state sviscerando... devo finire ancora le superiori e rimango perplesso di andare avanti all'università leggendo tutti questi argomenti :ciapet:
il codice si autocommenta fino a un certo livello di complessità.. dopo no! x il fatto ke non capisci niente ringrazia fek e il dottore (guarda ke sei laureato in scienze informatike a catania, non in computer engineering a stanford)!
secondo me è inutile parlare con voi! pensate ke le vostre idee sono inopinabili e ke non sia possibile ke vi sbagliate su qualkosa... ragionavo così all'asilo!
Dimmi dove avrei mai affermato che le mie idee sono inopinabili e non mi posso sbagliare. Ho affermato l'esatto contrario. Quello che ancora non capisci e' che non sto riportando opinioni mie, ma sto riportando best practice affermate nell'industria e definizioni rigorose. Fattene una ragione.
il codice si autocommenta fino a un certo livello di complessità..
Se l'implementazione e' troppo complessa, si semplifica il codice. Si chiama Refactoring (visto che non sapevi che cosa fosse?).
cdimauro
04-01-2006, 13:29
infatti! xò non ho detto al centro!
Hai detto a metà. Se poni le strutture closed e open agli estremi, puoi scrivere metà o centro: è sempre la stessa cosa. :p
intendevo ke la realtà è un pò + smussata, non far finta di non aver capito!
Ripeto: io capisco benissimo. Tu, invece, lo vuoi capire sì o no che NON SONO AFFATTO D'ACCORDO CON QUELLO CHE HAI SCRITTO? E che vorrei capire cosa intendi per metà, centro, estremi, ecc. ecc. Qualunque cosa tu intenda, SCRIVILA! CHIARA. NON AMBIGUA.
non è immaginazione ma pura realtà! ti ricordi le recenti vicende su ie6?
No: spiegati. E poi mi descrivi anche il procedimento logico con cui arrivi a certe conclusioni.
guarda ke quelli ke lavorano a suse testano prima di rendere disponibili le patch! non capisco dove vuoi arrivare! trovo ke il loro sistema di aggiornamento sia + veloce, affidabile e trasparente rispetto a quello di MS! dovresti provare prima di giudicare!
Suse ancora non l'ho provato, ma per il resto ho già subito abbastanza la leggerezza con cui si sviluppa e si rilascia codice in certi ambiti. Ho ancora CUPS che non mi funziona, nonostante 2GB di aggiornamenti. E gli aggiornamenti fatti la scorsa settimana mi hanno portato un nuovo kernel che non parte nemmeno se piangi in aramaico, e quello precedente, che prima funzionava, che adesso richiede qualche reset per "riprendersi" e farmi vedere la finestra di login di X.
l'ho detto? ho detto solo ke linux non l'ho pagato! ed è vero! nonostante ciò le patch di suse sono puntuali
La prossima volta lo scrivo chiaro e tondo è una battuta: non si sa mai, vista l'ambiguità insita nella lingua naturale che uso... :p
Comunque anche con Fedora Core le patch arrivano regolarmente... Fino a quando il supporto non viene brutalmente interrotto del tutto. D'altra parte è aggratis: non posso pretendere niente. ;)
quando ho detto ke ho un software esente da bug? skusa ma forse ti sei confuso con qualkun'altro!
Hai scritto questo:
"comunque se su linux ci mettono 2 mesi a correggere un bug non mi lamento (tanto l'ho avuto gratis), ma in win ho pure pagato x avere un servizio!"
Il servizio che ti offre MS è un software, che per definizione è soggetto a bug. Come qualunque software, visto che è una caratteristica INTRINSECA del software stesso.
Quindi perché ti lamenti? I bug non si possono eliminare del tutto, pur avendo pagato. E la loro correzione, una volta trovati, richiede tempo.
ahah
C'è poco da ridere: è una materia che non è apprezzata dalla maggior parte degli studenti, a causa dei tanti concetti poco digeribili (e alcuni anche controintuitivi). Ma è una materia che ti fa capire tantissimo (se la studi come si deve) le implicazioni teoriche e pratiche dello scrivere il software.
E poi mi state facendo un impressione su tutti gli argomenti che state sviscerando... devo finire ancora le superiori e rimango perplesso di andare avanti all'università leggendo tutti questi argomenti :ciapet:
Mah... finche' si parla di linguaggi formali, li seguo, e mi fa pure bene, visto che all'esame di linguaggi e sistemi formali ho preso solo 18 :D
La faccenda degli interrupt e dei thread... boh! L'architettura degli elaboratori e la multiprogrammazione sono argomenti che, almeno alla mia universita', vengono fatti in maniera un po' superficiale :mad:
Mi dispiace che il tono dei messaggi sia sempre piu' ostile.
Non ci sto capendo niente personalmente su tutto questa discussione.... :p
interrupt su un thread in cui si parla di sicurezza dell'opensource? :p
Comunque sia, comincio un pò a ricredermi sull'uso dei commenti.
E' innegabile che un codice scritto come si deve è pure autocommentante... :rolleyes: (nel senso che è palese a cosa serve quel codice)
E poi mi state facendo un impressione su tutti gli argomenti che state sviscerando... devo finire ancora le superiori e rimango perplesso di andare avanti all'università leggendo tutti questi argomenti :ciapet:
Ti quoto in pieno, se perso il senso del thread :(
cdimauro
04-01-2006, 13:33
secondo me è inutile parlare con voi! pensate ke le vostre idee sono inopinabili e ke non sia possibile ke vi sbagliate su qualkosa... ragionavo così all'asilo!
Infatti all'asilo non c'è bisogno di dimostrare niente. Però se mi dici che le strutture closed e open stanno a metà, al centro, o dove diavolo vuoi, permettimi di chiederti quanto meno il senso delle tue affermazioni, e poi la relativa dimostrazione.
comunque vi annuncio ke ora vi lascio inquinare questo forum quanto volete! vado a fare cose + importanti!
Spero che con ciò ti riferisca allo studio... :p
DanieleC88
04-01-2006, 13:34
Bella vero? :)
Si parla di commenti nel codice? E qui devo correre in difesa di fek perche' ha ragionissima. Guarda il progetto Diamonds. ;)
Cosa hai contro chi ha cominciato con con visual basic?
Ahime', anche io ho cominciato col Visual Basic... meno male che ho scoperto il C e C++. :D
E a volte indispensabile. :p
Python? :p
Se continui così chiederò l'intervento del moderatore.
Impara solo a vedere la presenza degli smiles, non prendertela sempre sul personale.
Non voleva essere un offesa il riferimento a M$, ma se la prendi come tale...
Pensavo, e penso ancora, che nel sentire quello che dici mi sembra di leggere i rapporti che di tanto in tanto commissiona Microsoft su Linux, ovvero paragoni ottimi per chi li legge, opinabili per chi li analizza.
Se poi ritieni offensivo l'opinabile.... :(
josephdrivein
04-01-2006, 13:36
Ma nonostante tutto non riesce a competere nemmeno con Windows (figuriamoci OS X) come soluzione desktop: perché? Ora. si sottointendeva linux nella frase: potresti motivare questa affermazione?
Intendi in termini di quota di mercato?
In tal caso non è vero, secondo w3schools è tutto il 2005 che sia Os X che Linux sono intorno al 3%, per dicembre 2005:
Windows 93.5%, Linux 3.2%, Mac 3.3%
Mentre nel 2004 era di poco sopra Linux.
O forse è un'opinione personale? In tal caso vi aggiungo la mia, probabilmente non è proprio per chiunque, tuttavia anche come desktop è dannatamente piacevole da usare.
cdimauro
04-01-2006, 13:37
il codice si autocommenta fino a un certo livello di complessità.. dopo no!
Così parlò il luminare della programmazione... :rolleyes: Ma se non sei nemmeno in grado di comprendere dei concetti di ingegneria del software, come pretendi di capire come realizzare software, per quanto "complicato" che si autocommenta? :mc:
x il fatto ke non capisci niente ringrazia fek e il dottore (guarda ke sei laureato in scienze informatike a catania, non in computer engineering a stanford)!
Com'era prevedibile, da buon troll, in mancanza di argomenti passi a tirare in ballo il titolo. Torna a pure a studiare dal prof. Ghezzi, e la prossima volta apri bene le orecchie e cerca di capire le cose ti vengono dette... :mc:
Si parla di commenti nel codice? E qui devo correre in difesa di fek perche' ha ragionissima. Guarda il progetto Diamonds. ;)
si parlava di documentazione in generale... sono loro ke si sono attaccati ai commenti! comunque il progetto diamonds lo guardo di certo! sono contento se serve a imparare qlkosa! x il topic... ormai è come se una petroliera si fosse arenata... una grossa macchia di petrolio! 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! poi vi ripeto: closed non vuol dire + sicuro! e fin qui è certo!
Cazzi suoi.
Comunque io mi riferivo alla qualità del codice prodotto (ai sorgenti).
Quindi, quel codice, era di ottima qualità, la figura l'ha fatta solo Bill Gates... :confused:
cdimauro
04-01-2006, 13:43
Impara solo a vedere la presenza degli smiles, non prendertela sempre sul personale.
Non voleva essere un offesa il riferimento a M$, ma se la prendi come tale...
Pensavo, e penso ancora, che nel sentire quello che dici mi sembra di leggere i rapporti che di tanto in tanto commissiona Microsoft su Linux, ovvero paragoni ottimi per chi li legge, opinabili per chi li analizza.
Non è questione di smile o meno: il problema è che quando gente come te legge certe cose, passa subito alla classica associazione "Microsoft" docet. Non è la prima volta che vengono etichettato come "uomo MS", "pagato da MS", ecc.
Evidentemente esprimere delle opinioni, le PROPRIE idee, che possono risultare indigeste ad alcuni, è chiedere troppo, vero?
Se poi ritieni offensivo l'opinabile.... :(
Le cose opinabili si discutono e smontano facilmente: non avrai diffocoltà a farlo con ciò che ho scritto io. ;)
cdimauro
04-01-2006, 13:45
Ora. si sottointendeva linux nella frase: potresti motivare questa affermazione?
Intendi in termini di quota di mercato?
In tal caso non è vero, secondo w3schools è tutto il 2005 che sia Os X che Linux sono intorno al 3%, per dicembre 2005:
Windows 93.5%, Linux 3.2%, Mac 3.3%
Mentre nel 2004 era di poco sopra Linux.
O forse è un'opinione personale? In tal caso vi aggiungo la mia, probabilmente non è proprio per chiunque, tuttavia anche come desktop è dannatamente piacevole da usare.
La seconda che hai detto. ;) Trovo OS X più semplice e intuitivo da usare (pur essendo un s.o. Unix-like).
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.