Dubbio sicurezza opensource

[k0nt3]

Originariamente inviato da fek

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)

Originariamente inviato da fek

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

Originariamente inviato da fek

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!

[fek]

Originariamente inviato da k0nt3

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.

[k0nt3]

Originariamente inviato da fek

Wikipedia sbaglia. E non e' la prima volta.

wikipedia sbaglia a definire "open source"? non ti viene mai il dubbio ke tu puoi sbagliare?

Originariamente inviato da fek

Mai vietero' a nessuno di rendersi ridicolo, e' una libera scelta.

esatto! proprio questo!

Originariamente inviato da fek

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!

[ReNeSiS]

Originariamente inviato da fek

Fatto sta che codice di alta qualita' non ha commenti.

Questa è la più bella che ho sentito negli ultimi anni!
Certo, magari neanche un identazione decente deve avere il codice, giusto?

[k0nt3]

Originariamente inviato da ReNeSiS

Questa è la più bella che ho sentito negli ultimi anni!
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!

[fek]

Originariamente inviato da k0nt3

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.

[fek]

Originariamente inviato da ReNeSiS

Questa è la più bella che ho sentito negli ultimi anni!

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.

[k0nt3]

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

[fek]

Originariamente inviato da k0nt3

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.

[k0nt3]

Originariamente inviato da fek

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!

Originariamente inviato da fek

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à!

Originariamente inviato da fek

E' un'evidente fesseria.

allora se non vuoi affrontare l'argomento me lo dicevi mezzora fa ke andavo a dormire!

[k0nt3]

Originariamente inviato da fek

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

[fek]

Originariamente inviato da k0nt3

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

[fek]

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?

[ReNeSiS]

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

[fek]

Originariamente inviato da ReNeSiS

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

[k0nt3]

Originariamente inviato da fek

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!

Originariamente inviato da fek

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?d...&crc=493511044
c'è la sua mail e la sua vita più o meno! fammi sapere cosa ne deriva dalla vostra discussione, sono curioso!

Originariamente inviato da fek

Vai pure a dormire, non stai comunque dando un grande apporto

devo dedurre ke tu programmi meglio controvoglia! ok grazie x il chiarimento!

[k0nt3]

Originariamente inviato da fek

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à

[fek]

Originariamente inviato da k0nt3

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

[k0nt3]

beh io vado a dormire ke è meglio!
ps. adesso capisco xkè ie6 è pieno di errori!! certo loro commenteranno un casino il codice ! x questo ci impiegano 2 mesi a correggere un bug!

[k0nt3]

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