Mellen
26th October 2010, 22:10
post originale: http://www.wayne2k1.com/showthread.php?t=99016
View Full Version : Litigio sui test
marlborojack
26th October 2010, 22:49
Allora: una dispensa gratis
# Bruce Eckel
Thinking in C++, 2nd Edition, Volume 1 http://www.mindview.net/Books/TICPP/ThinkingInCPP2e.html
Sito per il download gratuito: http://www.mindview.net/Books/DownloadSites
Il mio libro più chiaro e conciso, riferimento per il corso di Fondamenti di Informatica 1
# Andrea Domenici, Graziano Frosini
Introduzione alla programmazione ed elementi di strutture dati con il Linguaggio C++
Franco Angeli
ISBN 88-464-3173-1
L'inventore del C++ ne sapeva a pacchi. Niente di meglio per imparare la programmazione ad oggetti che leggere uno che praticamente li ha inventati, gli oggetti
# Bjarne Stroustrup
C++. Linguaggio, libreria standard, principi di programmazione
Pearson Education Italia
ISBN: 88-464-6202-5
# Bruce Eckel
Thinking in C++, 2nd Edition, Volume 1 http://www.mindview.net/Books/TICPP/ThinkingInCPP2e.html
Sito per il download gratuito: http://www.mindview.net/Books/DownloadSites
Il mio libro più chiaro e conciso, riferimento per il corso di Fondamenti di Informatica 1
# Andrea Domenici, Graziano Frosini
Introduzione alla programmazione ed elementi di strutture dati con il Linguaggio C++
Franco Angeli
ISBN 88-464-3173-1
L'inventore del C++ ne sapeva a pacchi. Niente di meglio per imparare la programmazione ad oggetti che leggere uno che praticamente li ha inventati, gli oggetti
# Bjarne Stroustrup
C++. Linguaggio, libreria standard, principi di programmazione
Pearson Education Italia
ISBN: 88-464-6202-5
Brcondor
26th October 2010, 23:20
Attualmente io ho fatto c, dopo c++ e infine ora sto lavorando abbastanza su MatLab.
Secondo me iniziare con c ti da il vantaggio che devi "violentare" la tua mente e la tua logica per far tua la logica di c. Capito c secondo me sei già 1 bel passo avanti...
Secondo me iniziare con c ti da il vantaggio che devi "violentare" la tua mente e la tua logica per far tua la logica di c. Capito c secondo me sei già 1 bel passo avanti...
Vynnstorm
26th October 2010, 23:23
iniziato col c, entrato tutto in testa subito:)
marlborojack
26th October 2010, 23:27
Io ho iniziato con l'assembler ed è la cosa migliore per capire TUTTO, ma ora come ora, se uno vuole divertirsi con la programmazione, meglio partire con il paradigma ad oggetti e poi se c'è interesse andare al livello più basso. Almeno se non hai voglia vai subito verso java, python, ruby
Vynnstorm
26th October 2010, 23:32
Ah già, in realtà il corso di programmazione è partito con assembler, poi grammatica e definizione di linguaggio, poi c. Penso sia la cosa migliore.
Kat
26th October 2010, 23:49
Vabe partire con l'assembler mi sembra un po esagerato, ok che ti fa capire come funzionano le cose a basso livello, pero non deve mica fare un percorso universitario di informatica.
Dipende anche un po dal target cmq, se interessa fare roba in ambito web col C non si va molto lontano, se importa capire i rudimenti allora il C va benissimo (non per object oriented pero).
Dipende anche un po dal target cmq, se interessa fare roba in ambito web col C non si va molto lontano, se importa capire i rudimenti allora il C va benissimo (non per object oriented pero).
Vynnstorm
26th October 2010, 23:53
concordo con kat, l'assembler evitalo pure.
Hador
27th October 2010, 00:07
seeee assembler, anche il c mica serve se uno non vuole specializzarsi in quello.
modo più veloce secondo me è partire da java o c#, sono potenti, facili e hanno quintali di tutorial per imparare, liberi dalle menate potenti ma poco intuitive del c/c++ che mi paiono piuttosto inutili per imparare, meglio capire come strutturare le cose bene piuttosto che riciclare i nomi delle variabili o fare i giochi coi puntatori. I libri però non mi sono mai andati giù, ne ho diversi ma non li ho mai usati veramente. Il savitch è piuttosto famoso per java, idem il liskov. Entrambi hanno un approccio anche progettistico (da noi il corso di programmazione è poco incentrato su algoritmica e molto su progettazione, uml, test, ecc.).
modo più veloce secondo me è partire da java o c#, sono potenti, facili e hanno quintali di tutorial per imparare, liberi dalle menate potenti ma poco intuitive del c/c++ che mi paiono piuttosto inutili per imparare, meglio capire come strutturare le cose bene piuttosto che riciclare i nomi delle variabili o fare i giochi coi puntatori. I libri però non mi sono mai andati giù, ne ho diversi ma non li ho mai usati veramente. Il savitch è piuttosto famoso per java, idem il liskov. Entrambi hanno un approccio anche progettistico (da noi il corso di programmazione è poco incentrato su algoritmica e molto su progettazione, uml, test, ecc.).
Mosaik
27th October 2010, 00:18
seeee assembler, anche il c mica serve se uno non vuole specializzarsi in quello.
modo più veloce secondo me è partire da java o c#, sono potenti, facili e hanno quintali di tutorial per imparare, liberi dalle menate potenti ma poco intuitive del c/c++ che mi paiono piuttosto inutili per imparare, meglio capire come strutturare le cose bene piuttosto che riciclare i nomi delle variabili o fare i giochi coi puntatori. I libri però non mi sono mai andati giù, ne ho diversi ma non li ho mai usati veramente. Il savitch è piuttosto famoso per java, idem il liskov. Entrambi hanno un approccio anche progettistico (da noi il corso di programmazione è poco incentrato su algoritmica e molto su progettazione, uml, test, ecc.).
*
C# o VB.Net e passa la pura ...
Java è il male :confused:
modo più veloce secondo me è partire da java o c#, sono potenti, facili e hanno quintali di tutorial per imparare, liberi dalle menate potenti ma poco intuitive del c/c++ che mi paiono piuttosto inutili per imparare, meglio capire come strutturare le cose bene piuttosto che riciclare i nomi delle variabili o fare i giochi coi puntatori. I libri però non mi sono mai andati giù, ne ho diversi ma non li ho mai usati veramente. Il savitch è piuttosto famoso per java, idem il liskov. Entrambi hanno un approccio anche progettistico (da noi il corso di programmazione è poco incentrato su algoritmica e molto su progettazione, uml, test, ecc.).
*
C# o VB.Net e passa la pura ...
Java è il male :confused:
Tunnel
27th October 2010, 00:19
Uhm, mi sa che riciclo per me questi consigli. Ormai le richieste di sviluppi interni si fanno pressanti e mi tocca imparare il C# senza aver mai toccato un linguaggio di programmazione. QQ
Consigli in merito ? Ribadisco che sono a totale digiuno di programmazione. In compenso sono un maestro dei trigger ricorsivi in loop infinito :metal:
Consigli in merito ? Ribadisco che sono a totale digiuno di programmazione. In compenso sono un maestro dei trigger ricorsivi in loop infinito :metal:
marlborojack
27th October 2010, 01:10
seeee assembler, anche il c mica serve se uno non vuole specializzarsi in quello.
modo più veloce secondo me è partire da java o c#, sono potenti, facili e hanno quintali di tutorial per imparare, liberi dalle menate potenti ma poco intuitive del c/c++ che mi paiono piuttosto inutili per imparare, meglio capire come strutturare le cose bene piuttosto che riciclare i nomi delle variabili o fare i giochi coi puntatori. I libri però non mi sono mai andati giù, ne ho diversi ma non li ho mai usati veramente. Il savitch è piuttosto famoso per java, idem il liskov. Entrambi hanno un approccio anche progettistico (da noi il corso di programmazione è poco incentrato su algoritmica e molto su progettazione, uml, test, ecc.).
Sì, ma se uno deve imparare l'informatica sarà meglio che si faccia un'idea di cosa sia la memoria, di cosa sia la pila, dei puntatori e SOPRATTUTTO che un'inizializzazione NON E' un assegnamento. Prima di partire con l'architettura del software. Per quello il c++ è il più completo, oltre all'OO e all'ereditarietà multipla, ecc... c'è anche la gestione della memoria, delle strutture dati base (differenze tra array e liste) ecc...
E non c'entra nulla il riciclare i nomi delle variabili (ma chi lo fa poi, LOL) o giochi coi puntatori (sebbene immagino che anche tu inconsapevolmente li usi per i callbacks ;), c'entra farsi un'idea più completa della struttura di un calcolatore e della sua programmazione, Anche perchè, se uno non sa cos'è una classe, che cazzo si mette a leggere di patterns?
Ma immagino che su questo saremo sempre come cane e gatto, lol. Detto questo converrai però con me che se le basi sono solide, a imparare un linguaggio è come bersi un bicchier d'acqua, per cui io preferisco i libri che schematizzano bene i concetti. E poi TANTA pratica
modo più veloce secondo me è partire da java o c#, sono potenti, facili e hanno quintali di tutorial per imparare, liberi dalle menate potenti ma poco intuitive del c/c++ che mi paiono piuttosto inutili per imparare, meglio capire come strutturare le cose bene piuttosto che riciclare i nomi delle variabili o fare i giochi coi puntatori. I libri però non mi sono mai andati giù, ne ho diversi ma non li ho mai usati veramente. Il savitch è piuttosto famoso per java, idem il liskov. Entrambi hanno un approccio anche progettistico (da noi il corso di programmazione è poco incentrato su algoritmica e molto su progettazione, uml, test, ecc.).
Sì, ma se uno deve imparare l'informatica sarà meglio che si faccia un'idea di cosa sia la memoria, di cosa sia la pila, dei puntatori e SOPRATTUTTO che un'inizializzazione NON E' un assegnamento. Prima di partire con l'architettura del software. Per quello il c++ è il più completo, oltre all'OO e all'ereditarietà multipla, ecc... c'è anche la gestione della memoria, delle strutture dati base (differenze tra array e liste) ecc...
E non c'entra nulla il riciclare i nomi delle variabili (ma chi lo fa poi, LOL) o giochi coi puntatori (sebbene immagino che anche tu inconsapevolmente li usi per i callbacks ;), c'entra farsi un'idea più completa della struttura di un calcolatore e della sua programmazione, Anche perchè, se uno non sa cos'è una classe, che cazzo si mette a leggere di patterns?
Ma immagino che su questo saremo sempre come cane e gatto, lol. Detto questo converrai però con me che se le basi sono solide, a imparare un linguaggio è come bersi un bicchier d'acqua, per cui io preferisco i libri che schematizzano bene i concetti. E poi TANTA pratica
Hardcore
27th October 2010, 01:18
Parti col C, ti tornerà utile in una valanga di altri linguaggi. Io personalmente farei C, poi Java
marlborojack
27th October 2010, 01:20
Ah già, in realtà il corso di programmazione è partito con assembler, poi grammatica e definizione di linguaggio, poi c. Penso sia la cosa migliore.
Parti col C, ti tornerà utile in una valanga di altri linguaggi. Io personalmente farei C, poi Java
Io spero intendiate C++, considerando che il C non ha la programmazione OO e che ormai persino per le missioni spaziali usano il paradigma della programmazione ad oggetti. Senza contare che il C++ è compatibile ANSI C, per cui c'è tutto quel che serve
Parti col C, ti tornerà utile in una valanga di altri linguaggi. Io personalmente farei C, poi Java
Io spero intendiate C++, considerando che il C non ha la programmazione OO e che ormai persino per le missioni spaziali usano il paradigma della programmazione ad oggetti. Senza contare che il C++ è compatibile ANSI C, per cui c'è tutto quel che serve
Hardcore
27th October 2010, 01:24
No io intendo il C. Non so a me è piaciuto molto avere imparato C e mi è servito per molti altri linguaggi. Personalmente farei prima uno studio di cosa è stato un linguaggio molto usato, importante. Poi passerei direttamente a Java.
Ovviamente imho.
Ovviamente imho.
Mosaik
27th October 2010, 01:38
Sì, ma se uno deve imparare l'informatica sarà meglio che si faccia un'idea di cosa sia la memoria, di cosa sia la pila, dei puntatori e SOPRATTUTTO che un'inizializzazione NON E' un assegnamento. Prima di partire con l'architettura del software. Per quello il c++ è il più completo, oltre all'OO e all'ereditarietà multipla, ecc... c'è anche la gestione della memoria, delle strutture dati base (differenze tra array e liste) ecc...
E non c'entra nulla il riciclare i nomi delle variabili (ma chi lo fa poi, LOL) o giochi coi puntatori (sebbene immagino che anche tu inconsapevolmente li usi per i callbacks ;), c'entra farsi un'idea più completa della struttura di un calcolatore e della sua programmazione, Anche perchè, se uno non sa cos'è una classe, che cazzo si mette a leggere di patterns?
Ma immagino che su questo saremo sempre come cane e gatto, lol. Detto questo converrai però con me che se le basi sono solide, a imparare un linguaggio è come bersi un bicchier d'acqua, per cui io preferisco i libri che schematizzano bene i concetti. E poi TANTA pratica
Sicuramente è piu' completo ma molte cose te le danno gratis qualsiasi framework quindi lasciano un po' il tempo ceh trovano...
Come dire che per imparare a guidare una macchina non c'e' bisogno di sapere cosa accade dentro al motore l'importate è sapere cosa sono accelleratore , freno , cambio ecc :D
E non c'entra nulla il riciclare i nomi delle variabili (ma chi lo fa poi, LOL) o giochi coi puntatori (sebbene immagino che anche tu inconsapevolmente li usi per i callbacks ;), c'entra farsi un'idea più completa della struttura di un calcolatore e della sua programmazione, Anche perchè, se uno non sa cos'è una classe, che cazzo si mette a leggere di patterns?
Ma immagino che su questo saremo sempre come cane e gatto, lol. Detto questo converrai però con me che se le basi sono solide, a imparare un linguaggio è come bersi un bicchier d'acqua, per cui io preferisco i libri che schematizzano bene i concetti. E poi TANTA pratica
Sicuramente è piu' completo ma molte cose te le danno gratis qualsiasi framework quindi lasciano un po' il tempo ceh trovano...
Come dire che per imparare a guidare una macchina non c'e' bisogno di sapere cosa accade dentro al motore l'importate è sapere cosa sono accelleratore , freno , cambio ecc :D
Hardcore
27th October 2010, 02:09
Sicuramente è piu' completo ma molte cose te le danno gratis qualsiasi framework quindi lasciano un po' il tempo ceh trovano...
Come dire che per imparare a guidare una macchina non c'e' bisogno di sapere cosa accade dentro al motore l'importate è sapere cosa sono accelleratore , freno , cambio ecc :D
Personalmente credo che programmare equivalga piu a costruire una macchina, piuttosto che a usarla.
Come dire che per imparare a guidare una macchina non c'e' bisogno di sapere cosa accade dentro al motore l'importate è sapere cosa sono accelleratore , freno , cambio ecc :D
Personalmente credo che programmare equivalga piu a costruire una macchina, piuttosto che a usarla.
Axet
27th October 2010, 02:52
Sì, ma se uno deve imparare l'informatica sarà meglio che si faccia un'idea di cosa sia la memoria, di cosa sia la pila, dei puntatori e SOPRATTUTTO che un'inizializzazione NON E' un assegnamento. Prima di partire con l'architettura del software. Per quello il c++ è il più completo, oltre all'OO e all'ereditarietà multipla, ecc... c'è anche la gestione della memoria, delle strutture dati base (differenze tra array e liste) ecc...
E non c'entra nulla il riciclare i nomi delle variabili (ma chi lo fa poi, LOL) o giochi coi puntatori (sebbene immagino che anche tu inconsapevolmente li usi per i callbacks ;), c'entra farsi un'idea più completa della struttura di un calcolatore e della sua programmazione, Anche perchè, se uno non sa cos'è una classe, che cazzo si mette a leggere di patterns?
Penso che con riciclare il nome delle variabili si riferisse allo scope eh.
Cmq hai ragione, ma considera che è tutto relativo. Dipende dal livello a cui uno punta di arrivare.. se vuole fare due programmini in croce tanto per divertirsi è inutile andare a sbattere la testa con quello che ci sta sotto. Allora tanto vale fare un ulteriore passo indietro e iniziare dalla macchina di turing e l'architettura di von neumann, voglio dire.
Chiaro invece che se uno vuol fare "sul serio", allora sicuramente conviene iniziare dal basso.
Ma immagino che su questo saremo sempre come cane e gatto, lol. Detto questo converrai però con me che se le basi sono solide, a imparare un linguaggio è come bersi un bicchier d'acqua, per cui io preferisco i libri che schematizzano bene i concetti. E poi TANTA pratica
Vero, ma non è un discorso di basi imo. Sicuramente aiutano, ma lo scoglio per uno che non ha mai programmato è entrare nell'ordine di pensiero di come si programma. Orientare la mente al problem solving. E' questo quello che ti permette di smazzarti poi qualsiasi linguaggio senza problema, le basi da questo punto di vista sono un plus.
edit:
per spiegarmi meglio, saper programmare equivale a saper scrivere un algoritmo in grado di risolvere il problema dato, a livello di flow chart. Se uno è in grado di fare ciò sa programmare. Il resto sono praticamente solo dettagli implementativi.
E non c'entra nulla il riciclare i nomi delle variabili (ma chi lo fa poi, LOL) o giochi coi puntatori (sebbene immagino che anche tu inconsapevolmente li usi per i callbacks ;), c'entra farsi un'idea più completa della struttura di un calcolatore e della sua programmazione, Anche perchè, se uno non sa cos'è una classe, che cazzo si mette a leggere di patterns?
Penso che con riciclare il nome delle variabili si riferisse allo scope eh.
Cmq hai ragione, ma considera che è tutto relativo. Dipende dal livello a cui uno punta di arrivare.. se vuole fare due programmini in croce tanto per divertirsi è inutile andare a sbattere la testa con quello che ci sta sotto. Allora tanto vale fare un ulteriore passo indietro e iniziare dalla macchina di turing e l'architettura di von neumann, voglio dire.
Chiaro invece che se uno vuol fare "sul serio", allora sicuramente conviene iniziare dal basso.
Ma immagino che su questo saremo sempre come cane e gatto, lol. Detto questo converrai però con me che se le basi sono solide, a imparare un linguaggio è come bersi un bicchier d'acqua, per cui io preferisco i libri che schematizzano bene i concetti. E poi TANTA pratica
Vero, ma non è un discorso di basi imo. Sicuramente aiutano, ma lo scoglio per uno che non ha mai programmato è entrare nell'ordine di pensiero di come si programma. Orientare la mente al problem solving. E' questo quello che ti permette di smazzarti poi qualsiasi linguaggio senza problema, le basi da questo punto di vista sono un plus.
edit:
per spiegarmi meglio, saper programmare equivale a saper scrivere un algoritmo in grado di risolvere il problema dato, a livello di flow chart. Se uno è in grado di fare ciò sa programmare. Il resto sono praticamente solo dettagli implementativi.
San Vegeta
27th October 2010, 08:36
I dettagli implementativi sono quelli che distinguono un'applicazione solida da una debole che richiederà sempre assistenza e darà problemi in momenti critici.
Vai sul C#, ha dalla sua il paradigma di programmazione ad oggetti, è fatto abbastanza bene, è simile a java nel caso un giorno volessi impararlo, è documentato molto e bene e ha integrata nel framework anche la parte grafica, così ti puoi fare le interfacce grafiche in pochi minuti.
Vai sul C#, ha dalla sua il paradigma di programmazione ad oggetti, è fatto abbastanza bene, è simile a java nel caso un giorno volessi impararlo, è documentato molto e bene e ha integrata nel framework anche la parte grafica, così ti puoi fare le interfacce grafiche in pochi minuti.
Hador
27th October 2010, 08:46
non sono un fan della conoscenza basso livello dei linguaggi di programmazione, non penso sia importante conoscere la differenza a livello di memoria tra un array e una lista, basta sapere le differenze in termini pratici e quando usare uno e quando usare l'altro. I discorsi sulle performance delle strutture dati hanno un sapore antico e java è comodo per imparare "alla mia maniera" proprio per le sue "restrizioni", penso sia meglio concentrarsi sul paradigma e sulle funzionalità piuttosto che sulla gestione della memoria. Infatti io non ho fatto ingegneria :sneer:
I dettagli implementativi sono quelli che distinguono un'applicazione solida da una debole che richiederà sempre assistenza e darà problemi in momenti critici.
Vai sul C#, ha dalla sua il paradigma di programmazione ad oggetti, è fatto abbastanza bene, è simile a java nel caso un giorno volessi impararlo, è documentato molto e bene e ha integrata nel framework anche la parte grafica, così ti puoi fare le interfacce grafiche in pochi minuti.non i dettagli implementativi, i TEST distinguono una applicazione solida da una debola -_-
btw visual studio mica è gratis, per il resto java o c# è uguale, c# sicuramente da più soddisfazione in quando è facile partire usando interfacce grafiche (mentre in java le gui non sono così immediate da usare, anche se le swt non sono male), java in compenso è gratuito e lo è il suo IDE (qua è lunga, a me piace eclipse netbeans mi fa merda, ma non è verità assoluta :|) :nod:
I dettagli implementativi sono quelli che distinguono un'applicazione solida da una debole che richiederà sempre assistenza e darà problemi in momenti critici.
Vai sul C#, ha dalla sua il paradigma di programmazione ad oggetti, è fatto abbastanza bene, è simile a java nel caso un giorno volessi impararlo, è documentato molto e bene e ha integrata nel framework anche la parte grafica, così ti puoi fare le interfacce grafiche in pochi minuti.non i dettagli implementativi, i TEST distinguono una applicazione solida da una debola -_-
btw visual studio mica è gratis, per il resto java o c# è uguale, c# sicuramente da più soddisfazione in quando è facile partire usando interfacce grafiche (mentre in java le gui non sono così immediate da usare, anche se le swt non sono male), java in compenso è gratuito e lo è il suo IDE (qua è lunga, a me piace eclipse netbeans mi fa merda, ma non è verità assoluta :|) :nod:
Cifra
27th October 2010, 09:18
10 anni di cobol :metal: na passeggiata de salute.
Mellen
27th October 2010, 10:04
eheh..
come immaginavo ho scatenato più un dibattito e le varie scuole di pensiero si sono mostrate.
Io ho fatto diciamo... 3 mesi di Matlab, quindi potete capire il livello base, ma ho notato come pur avendo avuto pochissime dispense, 0 libri e tanti esempi, sono riuscito a districarmi molto bene (avevamo una quantità spaventosa di esempi pratici di vari programmini, tantissimi sbagliati ma messi lì più che altro per fare numero nella dispensa e darti un'idea... beh, li correggevo man mano mentre i compagni non capivano nemmeno cosa ci fosse da fare).
Ora non punto a diventare un hacker (magari!) però imparare un minimo di base, per poi magari se mi appassiona imparare a fare 2 programmini del cavolo (dimostrare a me stesso più che altro) per poi passare a capire bene un linguaggio html (avevo fatto col FrontPage ancora alle superiori ma lo considero meno di zero).
come immaginavo ho scatenato più un dibattito e le varie scuole di pensiero si sono mostrate.
Io ho fatto diciamo... 3 mesi di Matlab, quindi potete capire il livello base, ma ho notato come pur avendo avuto pochissime dispense, 0 libri e tanti esempi, sono riuscito a districarmi molto bene (avevamo una quantità spaventosa di esempi pratici di vari programmini, tantissimi sbagliati ma messi lì più che altro per fare numero nella dispensa e darti un'idea... beh, li correggevo man mano mentre i compagni non capivano nemmeno cosa ci fosse da fare).
Ora non punto a diventare un hacker (magari!) però imparare un minimo di base, per poi magari se mi appassiona imparare a fare 2 programmini del cavolo (dimostrare a me stesso più che altro) per poi passare a capire bene un linguaggio html (avevo fatto col FrontPage ancora alle superiori ma lo considero meno di zero).
Hador
27th October 2010, 10:13
guarda se vuoi imparare facendo programmini la scelta giusta è ad esempi con linguaggio alto livello, c# o java come già detto, il primo ti devi procurare l'ide e lavori solo su win (mono in realtà non lo conosco ma funziona, ma nn so quanto sia uguale a vs) però crei in maniera più guidata e semplice interfacce grafiche, java fai un po' più di fatica con interfacce anche se l'IDE per le altre cose è più immediato da usare imo. Io procederei così, poi mentre capisci come funziona ti informi sui dettagli, ma se nel programmino per fare una agenda di numeri di telefono usi vector al posto di arraylist, benchè i primi siano meno performanti di n volte rispetto ai secondi, ne te ne accorgi ne ti cambia un cazzo.
altrimenti afferra un librone a due mani e buttati sull'architettura dei linguaggi, e li vada per il c++. Approccio sicuramente più ingegneristico ma un po' meno divertente imo.
altrimenti afferra un librone a due mani e buttati sull'architettura dei linguaggi, e li vada per il c++. Approccio sicuramente più ingegneristico ma un po' meno divertente imo.
Tanek
27th October 2010, 10:44
Imho Mellen thinking in java letto con calma + netbeans (IDE gratuito) + java, una cosa molto tranquilla per soddisfare la tua voglia di fare un po' di prove.
Poi se vedi che ti piace allora approfondisci per bene (sempre con thinking in java) e magari cominci a pensare a qualcosa web-oriented :)
(ma perchè dovrebbe imparare C? Piuttosto C++, ma C zero proprio imho. E a sto punto visto che vuole provare un po', meglio iniziare direttamente con C# o Java)
ps x Mosaik: .net è il male :nod:
Poi se vedi che ti piace allora approfondisci per bene (sempre con thinking in java) e magari cominci a pensare a qualcosa web-oriented :)
(ma perchè dovrebbe imparare C? Piuttosto C++, ma C zero proprio imho. E a sto punto visto che vuole provare un po', meglio iniziare direttamente con C# o Java)
ps x Mosaik: .net è il male :nod:
Mellen
27th October 2010, 10:51
mmmm... libri...
l'assenza al momento di € mi porta a cercare roba gratis online..
:(
l'assenza al momento di € mi porta a cercare roba gratis online..
:(
Hador
27th October 2010, 11:29
i libri cmq si trovano anche online... mo se arriviamo a java iniziamo a litigare se eclipse o netbeans :sneer:
Tanek
27th October 2010, 11:36
mmmm... libri...
l'assenza al momento di € mi porta a cercare roba gratis online..
:(
La versione online di Thinking in Java è completamente free!! (è a pagamento solo la versione cartacea)
ps: ahahah vero, la prossima diatriba sarà "è meglio eclipse o netbeans" :sneer: (imho per iniziare netbeans, per cose serie eclipse :nod: )
l'assenza al momento di € mi porta a cercare roba gratis online..
:(
La versione online di Thinking in Java è completamente free!! (è a pagamento solo la versione cartacea)
ps: ahahah vero, la prossima diatriba sarà "è meglio eclipse o netbeans" :sneer: (imho per iniziare netbeans, per cose serie eclipse :nod: )
Mellen
27th October 2010, 11:40
ok.. cercherò di pescare nel torrente..
esiste anche la versione in italiano per caso?
immagino l'ultima sia la 4°
esiste anche la versione in italiano per caso?
immagino l'ultima sia la 4°
Amiag
27th October 2010, 13:13
Va benissimo partire col C ma consideralo solo a scopo didattico e non perderci troppo tempo. Appena pensi di averci giocato abbastanza, passa a Java (o C++/C# a seconda di quello che vuoi farci)
C e' utile per imparare alcune cose base che in linguaggi di alto livello come Java non vedrai mai (es. gestione della memoria, input/output di basso livello, etc) inoltre per fare i primi tentativi da molta piu' soddisfazione avere il tuo bell'eseguibile imo.
ps imparare un linguaggio sono 2 settimane max, ma scrivere codice di qualita' in quel linguaggio son 2+ anni e non ce' scorciatoia che tenga.
C e' utile per imparare alcune cose base che in linguaggi di alto livello come Java non vedrai mai (es. gestione della memoria, input/output di basso livello, etc) inoltre per fare i primi tentativi da molta piu' soddisfazione avere il tuo bell'eseguibile imo.
ps imparare un linguaggio sono 2 settimane max, ma scrivere codice di qualita' in quel linguaggio son 2+ anni e non ce' scorciatoia che tenga.
Axet
27th October 2010, 13:23
I dettagli implementativi sono quelli che distinguono un'applicazione solida da una debole che richiederà sempre assistenza e darà problemi in momenti critici.
A parte che come dice giustamente hador sono i test che discriminano un'applicazione solida da una che non lo è, se vuoi metterla su questa falsa riga allora senza uno studio architetturale le applicazioni che produci sono merda sciolta con flessibilità 0 che dopo 2 anni sono da prendere, buttare nel cesso, e gogo scrivine una nuova.
La base della programmazione è l'essere in grado di arrivare a un algoritmo che risolve un problema. Il resto è roba di contorno (per quanto concerne la programmazione).
Fortunatamente poi l'informatica non si esaurisce alla mera programmazione. Del resto per fare il programmatore non ci vuole una laurea, basta essere perito.
A parte che come dice giustamente hador sono i test che discriminano un'applicazione solida da una che non lo è, se vuoi metterla su questa falsa riga allora senza uno studio architetturale le applicazioni che produci sono merda sciolta con flessibilità 0 che dopo 2 anni sono da prendere, buttare nel cesso, e gogo scrivine una nuova.
La base della programmazione è l'essere in grado di arrivare a un algoritmo che risolve un problema. Il resto è roba di contorno (per quanto concerne la programmazione).
Fortunatamente poi l'informatica non si esaurisce alla mera programmazione. Del resto per fare il programmatore non ci vuole una laurea, basta essere perito.
Mellen
27th October 2010, 14:14
Va benissimo partire col C ma consideralo solo a scopo didattico e non perderci troppo tempo. Appena pensi di averci giocato abbastanza, passa a Java (o C++/C# a seconda di quello che vuoi farci)
C e' utile per imparare alcune cose base che in linguaggi di alto livello come Java non vedrai mai (es. gestione della memoria, input/output di basso livello, etc) inoltre per fare i primi tentativi da molta piu' soddisfazione avere il tuo bell'eseguibile imo.
ps imparare un linguaggio sono 2 settimane max, ma scrivere codice di qualita' in quel linguaggio son 2+ anni e non ce' scorciatoia che tenga.
2 anni per scrivere programmini anche del cazzo???
O_O
C e' utile per imparare alcune cose base che in linguaggi di alto livello come Java non vedrai mai (es. gestione della memoria, input/output di basso livello, etc) inoltre per fare i primi tentativi da molta piu' soddisfazione avere il tuo bell'eseguibile imo.
ps imparare un linguaggio sono 2 settimane max, ma scrivere codice di qualita' in quel linguaggio son 2+ anni e non ce' scorciatoia che tenga.
2 anni per scrivere programmini anche del cazzo???
O_O
Hardcore
27th October 2010, 14:17
Beh se il tuo intento è fare un po di programmini ecc, java o c# vanno benissimo. Io ritengo cmq il C una base necessaria in quanto non a oggetti e quindi permette di avere una visione della programmazione differente.
Hador
27th October 2010, 14:27
differente si, ma il paradigma ad oggetti è meglio di quello procedurale, ergo è differente in peggio.
I limiti sono le performance in ambiente embedded, ma più si andrà avanti più verranno superati.
-nessuno ha visto niente
I limiti sono le performance in ambiente embedded, ma più si andrà avanti più verranno superati.
-nessuno ha visto niente
Amiag
27th October 2010, 14:28
2 anni per scrivere programmini anche del cazzo???
O_O
No i programmini li impari a scrivere in 2 sett.
Mi riferivo al discorso "basta l'algoritmo e il resto son dettagli"
O_O
No i programmini li impari a scrivere in 2 sett.
Mi riferivo al discorso "basta l'algoritmo e il resto son dettagli"
Mellen
27th October 2010, 14:43
Beh se il tuo intento è fare un po di programmini ecc, java o c# vanno benissimo. Io ritengo cmq il C una base necessaria in quanto non a oggetti e quindi permette di avere una visione della programmazione differente.
avendo fatto matlab per qualche mese, quindi aver almeno capito cosa significano certe basi (anche se ammetto che ora come ora ricordo quasi nulla ma con una rinfrescata veloce ritengo di ricordare) credi possa bastare?
intanto ho reperito il testo su Java (anche se in inglese... ho trovato tradotto in altre lingue tranne l'italiano :gha:) e credo mi metterò a leggerlo
avendo fatto matlab per qualche mese, quindi aver almeno capito cosa significano certe basi (anche se ammetto che ora come ora ricordo quasi nulla ma con una rinfrescata veloce ritengo di ricordare) credi possa bastare?
intanto ho reperito il testo su Java (anche se in inglese... ho trovato tradotto in altre lingue tranne l'italiano :gha:) e credo mi metterò a leggerlo
Alkabar
27th October 2010, 14:43
differente si, ma il paradigma ad oggetti è meglio di quello procedurale, ergo è differente in peggio.
I limiti sono le performance in ambiente embedded, ma più si andrà avanti più verranno superati.
Intendi dire Procedurale. Java è imperativo e a oggetti.
I limiti sono le performance in ambiente embedded, ma più si andrà avanti più verranno superati.
Intendi dire Procedurale. Java è imperativo e a oggetti.
Mez
27th October 2010, 14:46
io conosco solo php, da un paio di settimane leggo python e lo trovo mui easy
Hador
27th October 2010, 14:48
Intendi dire Procedurale. Java è imperativo e a oggetti.
e io che ho scritto? :sneer:
e io che ho scritto? :sneer:
Rise-the-Sky
27th October 2010, 15:02
e io che ho scritto? :sneer:
In realtà C è definito come strutturato, non procedurale. :confused:
(poi vabbè strutturato deriva da procedurale)
Python è un bel linguaggio per iniziare perchè FORZA la bella scrittura del codice, però è meno diffuso del Java (quindi meno 'utile' a livello di CV e con meno materiale trovabile online).
In realtà C è definito come strutturato, non procedurale. :confused:
(poi vabbè strutturato deriva da procedurale)
Python è un bel linguaggio per iniziare perchè FORZA la bella scrittura del codice, però è meno diffuso del Java (quindi meno 'utile' a livello di CV e con meno materiale trovabile online).
Alkabar
27th October 2010, 15:21
e io che ho scritto? :sneer:
Si editami anche i peli del culo eh.....:sneer:
Si editami anche i peli del culo eh.....:sneer:
Hador
27th October 2010, 15:32
vabbè fanculo tutti imparati il prolog :sneer:
Tunnel
27th October 2010, 15:40
Cmq volevo segnalarvi che hador mi ha consigliato in pvt la coppia Mono & Osx per sviluppare.
Axet
27th October 2010, 15:40
I linguaggi imperativi son tutti uguali alla fin della fiera, non c'è manco da discuterci troppo.
Io mi darei subito dall'inizio a linguaggi logici o funzionali :sneer:
Io mi darei subito dall'inizio a linguaggi logici o funzionali :sneer:
Hador
27th October 2010, 15:43
Cmq volevo segnalarvi che hador mi ha consigliato in pvt la coppia Mono & Osx per sviluppare.http://imgs.xkcd.com/comics/real_programmers.png
Kat
27th October 2010, 19:14
Pure io consiglierei python, e' semplice ma potente, per cominciare puo' essere una buona scelta.
Di Visual Studio cmq esiste la versione express che e' free, e per quello che vuole fare lui va benissimo.
Di Visual Studio cmq esiste la versione express che e' free, e per quello che vuole fare lui va benissimo.
San Vegeta
27th October 2010, 20:17
non sono un fan della conoscenza basso livello dei linguaggi di programmazione, non penso sia importante conoscere la differenza a livello di memoria tra un array e una lista, basta sapere le differenze in termini pratici e quando usare uno e quando usare l'altro. I discorsi sulle performance delle strutture dati hanno un sapore antico e java è comodo per imparare "alla mia maniera" proprio per le sue "restrizioni", penso sia meglio concentrarsi sul paradigma e sulle funzionalità piuttosto che sulla gestione della memoria. Infatti io non ho fatto ingegneria :sneer:non i dettagli implementativi, i TEST distinguono una applicazione solida da una debola -_-
btw visual studio mica è gratis, per il resto java o c# è uguale, c# sicuramente da più soddisfazione in quando è facile partire usando interfacce grafiche (mentre in java le gui non sono così immediate da usare, anche se le swt non sono male), java in compenso è gratuito e lo è il suo IDE (qua è lunga, a me piace eclipse netbeans mi fa merda, ma non è verità assoluta :|) :nod:
Hador, il tuo voler sempre e per forza avere l'ultima parola su tutto non implica che tu abbia ragione.
I test sono test, non la rappresentazione di ogni momento di vita dell'applicazione, soprattutto se si parla di 30 applicazioni che interagiscono insieme e non usa sola.
Per quanto riguarda il Visual Studio che non è gratis, mi dici a cosa serve questa dichiarazione?
Ha chiesto da cosa dovrebbe iniziare per avvicinarsi alla programmazione, non cosa dovrebbe usare per programmare e non spendere soldi. Il C# è un linguaggio di programmazione per il quale esistono anche compilatori e IDE gratuiti, per non parlare del Visual Studio Express che è appunto gratuito.
btw visual studio mica è gratis, per il resto java o c# è uguale, c# sicuramente da più soddisfazione in quando è facile partire usando interfacce grafiche (mentre in java le gui non sono così immediate da usare, anche se le swt non sono male), java in compenso è gratuito e lo è il suo IDE (qua è lunga, a me piace eclipse netbeans mi fa merda, ma non è verità assoluta :|) :nod:
Hador, il tuo voler sempre e per forza avere l'ultima parola su tutto non implica che tu abbia ragione.
I test sono test, non la rappresentazione di ogni momento di vita dell'applicazione, soprattutto se si parla di 30 applicazioni che interagiscono insieme e non usa sola.
Per quanto riguarda il Visual Studio che non è gratis, mi dici a cosa serve questa dichiarazione?
Ha chiesto da cosa dovrebbe iniziare per avvicinarsi alla programmazione, non cosa dovrebbe usare per programmare e non spendere soldi. Il C# è un linguaggio di programmazione per il quale esistono anche compilatori e IDE gratuiti, per non parlare del Visual Studio Express che è appunto gratuito.
Hador
27th October 2010, 20:26
I test sono test, non la rappresentazione di ogni momento di vita dell'applicazione, soprattutto se si parla di 30 applicazioni che interagiscono insieme e non usa sola.madò che stronzata :|
non è per buttarla in flame, ma vuol dire non aver capito un ostia di cosa vuol dire testare un'applicazione, di conseguenza vuol dire che le tue applicazioni non hanno una garanzia di funzionamento. Il giustismo, cioè il "il programma è giusto perchè sono bravissimo", è piuttosto condannato qua. Perchè è na boiata :p
non è per buttarla in flame, ma vuol dire non aver capito un ostia di cosa vuol dire testare un'applicazione, di conseguenza vuol dire che le tue applicazioni non hanno una garanzia di funzionamento. Il giustismo, cioè il "il programma è giusto perchè sono bravissimo", è piuttosto condannato qua. Perchè è na boiata :p
San Vegeta
27th October 2010, 20:47
momento ioioio, torno a farmi gli affari miei
Vynnstorm
27th October 2010, 20:52
hai ragione tu.
intanto io son pagato 6k euro per non capire un cazzo, e tu?
That's Lame.
intanto io son pagato 6k euro per non capire un cazzo, e tu?
That's Lame.
Hador
27th October 2010, 20:52
hai ragione tu.
intanto io son pagato 6k euro per non capire un cazzo, e tu?hai centrato il problema :sneer:
E' una discussione da tech, se hai tempo ti passo materiale te lo leggiucchi e poi mi dici, ma come si dice "hope is not a strategy". Un ingegnere non progetta un ponte sperando che regga perchè lui è bravo, allo stesso modo il software critico (arei ad esempio) è dimostrato matematicamente. La via di mezzo sono le strategie di testing, che non è solo test unitario, che servono a garantire che quel che hai fatto funzioni se non al 100% che è impossibile almeno nella stragrande maggioranza dei casi, e a scoprire facilmente i bug più comuni.
Il programmatore genio che fa tutto lui è roba da 20 anni fa, che ha portato a diversi disastri su diversa scala, tanto per citarne uno ecclatante c'era un modello di respiratore controllato da un software che qualcosa come il 0.00001% dei casi crashava. Risultato? morti. Poi vabbè se uno fa programmazione web su piccola scala ok, altrimenti è tutto un altro cazzo di discorso.
intanto io son pagato 6k euro per non capire un cazzo, e tu?hai centrato il problema :sneer:
E' una discussione da tech, se hai tempo ti passo materiale te lo leggiucchi e poi mi dici, ma come si dice "hope is not a strategy". Un ingegnere non progetta un ponte sperando che regga perchè lui è bravo, allo stesso modo il software critico (arei ad esempio) è dimostrato matematicamente. La via di mezzo sono le strategie di testing, che non è solo test unitario, che servono a garantire che quel che hai fatto funzioni se non al 100% che è impossibile almeno nella stragrande maggioranza dei casi, e a scoprire facilmente i bug più comuni.
Il programmatore genio che fa tutto lui è roba da 20 anni fa, che ha portato a diversi disastri su diversa scala, tanto per citarne uno ecclatante c'era un modello di respiratore controllato da un software che qualcosa come il 0.00001% dei casi crashava. Risultato? morti. Poi vabbè se uno fa programmazione web su piccola scala ok, altrimenti è tutto un altro cazzo di discorso.
Gramas
27th October 2010, 20:56
hai ragione tu.
intanto io son pagato 6k euro per non capire un cazzo, e tu?
win incontrastabile
intanto io son pagato 6k euro per non capire un cazzo, e tu?
win incontrastabile
Rayvaughan
27th October 2010, 21:27
asd robe del primo anno
Amiag
27th October 2010, 23:45
Il programmatore genio che fa tutto lui è roba da 20 anni fa, che ha portato a diversi disastri su diversa scala, tanto per citarne uno ecclatante c'era un modello di respiratore controllato da un software che qualcosa come il 0.00001% dei casi crashava. Risultato? morti. Poi vabbè se uno fa programmazione web su piccola scala ok, altrimenti è tutto un altro cazzo di discorso.
Non contarci troppo ... son stato in progetti anche molto grandi in cui la baracca la tenevano su una manciata di persone (per lo piu tecniche) e tutti gli altri a traino.
Poi magari software da cui dipendono vite umane hanno altri processi, ma non ci giurerei :sneer:
Non contarci troppo ... son stato in progetti anche molto grandi in cui la baracca la tenevano su una manciata di persone (per lo piu tecniche) e tutti gli altri a traino.
Poi magari software da cui dipendono vite umane hanno altri processi, ma non ci giurerei :sneer:
Hador
28th October 2010, 00:21
no spe so che le cose vengono fatte a cazzo di cane, ma non venirmi a dire che non servono :|
Amiag
28th October 2010, 00:30
no spe so che le cose vengono fatte a cazzo di cane, ma non venirmi a dire che non servono :|
Nono servono , il problema e' che poi mettere in pratica certi processi e' quasi impossibile... vedi la tendenza degli ultimi dieci anni (?) verso i vari approcci "agili" che alla fine non sono altro che un modo per dare piu liberta ai "tecnici" mantenendo allo stesso tempo un minimo di processo "definito" ...
Nono servono , il problema e' che poi mettere in pratica certi processi e' quasi impossibile... vedi la tendenza degli ultimi dieci anni (?) verso i vari approcci "agili" che alla fine non sono altro che un modo per dare piu liberta ai "tecnici" mantenendo allo stesso tempo un minimo di processo "definito" ...
Tunnel
28th October 2010, 09:03
Noi buttiamo fuori dll con 1 giro di test sulla piattaforma di sviluppo e 1 giro di test dal cliente.
Poi segnalano loro se qualcosa non va :nod:
Poi segnalano loro se qualcosa non va :nod:
Hador
28th October 2010, 09:08
Nono servono , il problema e' che poi mettere in pratica certi processi e' quasi impossibile... vedi la tendenza degli ultimi dieci anni (?) verso i vari approcci "agili" che alla fine non sono altro che un modo per dare piu liberta ai "tecnici" mantenendo allo stesso tempo un minimo di processo "definito" ...non far casino, i processi agili sono fondati sui test, cioè tipo il primo punto del manifesto agile è tests first, "utilizza i test come specifica". E anche in italia in medie piccole realtà è ormai comune trovare lo sviluppo organizzato con xp, scrum o derivati.
marlborojack
28th October 2010, 09:44
beh spezzo una lancia a favore di Hador. Bisognerebbe sempre farsi il cartone animato, ovvero simulare l'esecuzione, ma oltre un certo numero di righe di codice rischi di non poterlo fare per cui sostituisci la perfetta conoscenza dei processi dell'applicazione con una serie di test che ne assicurino almeno la correttezza in probabilità, serve ormai molto meno tempo a creare un set di ingressi di test e controllare le uscite che farsi tutto lo schema del codice.
Meglio avere il culo parato insomma, perchè sulla carta i programmi son tutti giusti ma quando vengono eseguiti sbarellano tutti, e questa è la prima direttiva della creazione di software
Meglio avere il culo parato insomma, perchè sulla carta i programmi son tutti giusti ma quando vengono eseguiti sbarellano tutti, e questa è la prima direttiva della creazione di software
Pic STK
28th October 2010, 09:56
imho java
Alkabar
28th October 2010, 10:08
madò che stronzata :|
non è per buttarla in flame, ma vuol dire non aver capito un ostia di cosa vuol dire testare un'applicazione, di conseguenza vuol dire che le tue applicazioni non hanno una garanzia di funzionamento. Il giustismo, cioè il "il programma è giusto perchè sono bravissimo", è piuttosto condannato qua. Perchè è na boiata :p
Scusa Hador, non vorrei darti contro, ma stai confondendo il test con l'affidabilità. Sono due cose differenti.
Il test ti fa sapere che la data funzionalità si comporta correttamente, ma non ti dice niente sulla stabilità del software.
La stabilità del software dipende da quanti bug ci sono che non sei riuscito a trovare.
Siccome i bug si distribuiscono in maniera esponenziale (si chiama reliability growth model) tu non puoi sapere niente sull'affidabilità del software che hai scritto,
visto che se volessi fare realmente tutto il test e il debugging necessario per togliere ogni bug, il costo del software ti esploderebbe nelle mani (perchè i bug si distribuiscuno secondo legge esponenziale nel tempo, piu' ne trovi, piu' è difficile trovarne altri).
non è per buttarla in flame, ma vuol dire non aver capito un ostia di cosa vuol dire testare un'applicazione, di conseguenza vuol dire che le tue applicazioni non hanno una garanzia di funzionamento. Il giustismo, cioè il "il programma è giusto perchè sono bravissimo", è piuttosto condannato qua. Perchè è na boiata :p
Scusa Hador, non vorrei darti contro, ma stai confondendo il test con l'affidabilità. Sono due cose differenti.
Il test ti fa sapere che la data funzionalità si comporta correttamente, ma non ti dice niente sulla stabilità del software.
La stabilità del software dipende da quanti bug ci sono che non sei riuscito a trovare.
Siccome i bug si distribuiscono in maniera esponenziale (si chiama reliability growth model) tu non puoi sapere niente sull'affidabilità del software che hai scritto,
visto che se volessi fare realmente tutto il test e il debugging necessario per togliere ogni bug, il costo del software ti esploderebbe nelle mani (perchè i bug si distribuiscuno secondo legge esponenziale nel tempo, piu' ne trovi, piu' è difficile trovarne altri).
Alkabar
28th October 2010, 10:11
beh spezzo una lancia a favore di Hador. Bisognerebbe sempre farsi il cartone animato, ovvero simulare l'esecuzione, ma oltre un certo numero di righe di codice rischi di non poterlo fare per cui sostituisci la perfetta conoscenza dei processi dell'applicazione con una serie di test che ne assicurino almeno la correttezza in probabilità, serve ormai molto meno tempo a creare un set di ingressi di test e controllare le uscite che farsi tutto lo schema del codice.
Meglio avere il culo parato insomma, perchè sulla carta i programmi son tutti giusti ma quando vengono eseguiti sbarellano tutti, e questa è la prima direttiva della creazione di software
La correttezza in probabilità ? Cioè intendi dire che statisticamente va almeno per il 95% di quello che l'utente normale vorrebbe andasse. Si questo è corretto.
Meglio avere il culo parato insomma, perchè sulla carta i programmi son tutti giusti ma quando vengono eseguiti sbarellano tutti, e questa è la prima direttiva della creazione di software
La correttezza in probabilità ? Cioè intendi dire che statisticamente va almeno per il 95% di quello che l'utente normale vorrebbe andasse. Si questo è corretto.
Alkabar
28th October 2010, 10:16
hai centrato il problema :sneer:
E' una discussione da tech, se hai tempo ti passo materiale te lo leggiucchi e poi mi dici, ma come si dice "hope is not a strategy". Un ingegnere non progetta un ponte sperando che regga perchè lui è bravo, allo stesso modo il software critico (arei ad esempio) è dimostrato matematicamente. La via di mezzo sono le strategie di testing, che non è solo test unitario, che servono a garantire che quel che hai fatto funzioni se non al 100% che è impossibile almeno nella stragrande maggioranza dei casi, e a scoprire facilmente i bug più comuni.
Il programmatore genio che fa tutto lui è roba da 20 anni fa, che ha portato a diversi disastri su diversa scala, tanto per citarne uno ecclatante c'era un modello di respiratore controllato da un software che qualcosa come il 0.00001% dei casi crashava. Risultato? morti. Poi vabbè se uno fa programmazione web su piccola scala ok, altrimenti è tutto un altro cazzo di discorso.
Sei un po' troppo spocchioso Hador, Vegeta non ha detto niente di scorretto. I test ovviamente servono, ma ti dicono solo che qualcosa funziona o non funziona, spesso non ti dice molto sull'interazione nel tempo dei vari componenti.
La cosa piu' importante è il processo di debugging, che puo' essere aiutato coi test.
E' una discussione da tech, se hai tempo ti passo materiale te lo leggiucchi e poi mi dici, ma come si dice "hope is not a strategy". Un ingegnere non progetta un ponte sperando che regga perchè lui è bravo, allo stesso modo il software critico (arei ad esempio) è dimostrato matematicamente. La via di mezzo sono le strategie di testing, che non è solo test unitario, che servono a garantire che quel che hai fatto funzioni se non al 100% che è impossibile almeno nella stragrande maggioranza dei casi, e a scoprire facilmente i bug più comuni.
Il programmatore genio che fa tutto lui è roba da 20 anni fa, che ha portato a diversi disastri su diversa scala, tanto per citarne uno ecclatante c'era un modello di respiratore controllato da un software che qualcosa come il 0.00001% dei casi crashava. Risultato? morti. Poi vabbè se uno fa programmazione web su piccola scala ok, altrimenti è tutto un altro cazzo di discorso.
Sei un po' troppo spocchioso Hador, Vegeta non ha detto niente di scorretto. I test ovviamente servono, ma ti dicono solo che qualcosa funziona o non funziona, spesso non ti dice molto sull'interazione nel tempo dei vari componenti.
La cosa piu' importante è il processo di debugging, che puo' essere aiutato coi test.
Karidi
28th October 2010, 11:36
Beh per questo che ci sono più fasi di test
- Sviluppo, ma molte volte non si usano gli ambienti predisposti ma si usano i propri portatili o Mac per fare figo poi quando rilasciano sui sistemi di Release Management ti trovi di tutto e fioccano le madonne.
- IAT/UAT ambienti di integrazione accettazione che nella maggior parte delle volte sono mononodi
- PreProduzione, enviroment scalati dalla produzione ma con architetture di Cluster e Multistanze integrate tra loro nei vari mondi (Web/PRV etc.etc.) i DB sono le copie fisiche o restore effettuati tramite Storage.
(in questo ambiente vengono fatti gli stresstest e le prove di deploy in cluster mode, che sono i maggiori bagni di sangue/caporetto che hanno i software rilasciati.
TEST: Dipende dalla bravura dei gruppi di QA dalle specifiche che seguono la CR o il progetto e qui vengono redatti i TESTCase che sono gli scenari, che vengono studiati sui documenti che arrivano dall'analisti, dalla fattibilità dagli Architetti e i PM etc.etc.
Per questo che ci sono strumenti molto diffusi come la suite Mercury etc.etc.
La maggior parte dei problemi che si hanno nelle architetture enterprise è che chi si fregia di titolo di Architetto non sa una ceppa di nulla di Sistemi/Network e architetture, quindi fa il suo Software superfunzionante sul suo MAC, poi quando vai a fare integrazione/deploy scopri che non va una bega per poi sdraiarlo in pochi secondi quando lo bombardi con LoadRunner.
Alka: 10 anni fa si chiedeva che un Software Funzionasse ora si chiede che un Software sia PErformante ed Efficace c'è una differenza abissale tra i due concetti.
- Sviluppo, ma molte volte non si usano gli ambienti predisposti ma si usano i propri portatili o Mac per fare figo poi quando rilasciano sui sistemi di Release Management ti trovi di tutto e fioccano le madonne.
- IAT/UAT ambienti di integrazione accettazione che nella maggior parte delle volte sono mononodi
- PreProduzione, enviroment scalati dalla produzione ma con architetture di Cluster e Multistanze integrate tra loro nei vari mondi (Web/PRV etc.etc.) i DB sono le copie fisiche o restore effettuati tramite Storage.
(in questo ambiente vengono fatti gli stresstest e le prove di deploy in cluster mode, che sono i maggiori bagni di sangue/caporetto che hanno i software rilasciati.
TEST: Dipende dalla bravura dei gruppi di QA dalle specifiche che seguono la CR o il progetto e qui vengono redatti i TESTCase che sono gli scenari, che vengono studiati sui documenti che arrivano dall'analisti, dalla fattibilità dagli Architetti e i PM etc.etc.
Per questo che ci sono strumenti molto diffusi come la suite Mercury etc.etc.
La maggior parte dei problemi che si hanno nelle architetture enterprise è che chi si fregia di titolo di Architetto non sa una ceppa di nulla di Sistemi/Network e architetture, quindi fa il suo Software superfunzionante sul suo MAC, poi quando vai a fare integrazione/deploy scopri che non va una bega per poi sdraiarlo in pochi secondi quando lo bombardi con LoadRunner.
Alka: 10 anni fa si chiedeva che un Software Funzionasse ora si chiede che un Software sia PErformante ed Efficace c'è una differenza abissale tra i due concetti.
Hador
28th October 2010, 11:50
Scusa Hador, non vorrei darti contro, ma stai confondendo il test con l'affidabilità. Sono due cose differenti.
Il test ti fa sapere che la data funzionalità si comporta correttamente, ma non ti dice niente sulla stabilità del software.
La stabilità del software dipende da quanti bug ci sono che non sei riuscito a trovare.
Siccome i bug si distribuiscono in maniera esponenziale (si chiama reliability growth model) tu non puoi sapere niente sull'affidabilità del software che hai scritto,
visto che se volessi fare realmente tutto il test e il debugging necessario per togliere ogni bug, il costo del software ti esploderebbe nelle mani (perchè i bug si distribuiscuno secondo legge esponenziale nel tempo, piu' ne trovi, piu' è difficile trovarne altri).
sei tu che fai casino, i test mica servono a provare il software, servono a garantire l'assenza di bug (a seconda della strategia in maniera matematica o probabilistica). La ricerca infatti sta nel trovare le strategie di test migliori per minimizzare lo sforzo e ottimizzare la probabilità di identificare i bug, l'esempio del coglione è il partition testing, se ho un metodo che processa una numero intero quali sono i test migliori che posso fare? Gli input sono infiniti, scriverò un test però per i casi significativi, -1, 0, 01, 1.1, numero random. Ho coperto tutti gli stati? no. Ho coperto gli stati sensibili? Si.
Posso infatti utilizzare diversi criteri per valutare la mia test suite, dai diversi criteri di copertura (codice, controllo, data flow) a metodi attivi quali il fault injiection.
vammi pure contro, ci sto a fare la tesi su questa cosa :sneer:
Sei un po' troppo spocchioso Hador, Vegeta non ha detto niente di scorretto. I test ovviamente servono, ma ti dicono solo che qualcosa funziona o non funziona, spesso non ti dice molto sull'interazione nel tempo dei vari componenti.
La cosa piu' importante è il processo di debugging, che puo' essere aiutato coi test.non è questione di esser spocchiosi, è questione che sbagli :p
Il test ti fa sapere che la data funzionalità si comporta correttamente, ma non ti dice niente sulla stabilità del software.
La stabilità del software dipende da quanti bug ci sono che non sei riuscito a trovare.
Siccome i bug si distribuiscono in maniera esponenziale (si chiama reliability growth model) tu non puoi sapere niente sull'affidabilità del software che hai scritto,
visto che se volessi fare realmente tutto il test e il debugging necessario per togliere ogni bug, il costo del software ti esploderebbe nelle mani (perchè i bug si distribuiscuno secondo legge esponenziale nel tempo, piu' ne trovi, piu' è difficile trovarne altri).
sei tu che fai casino, i test mica servono a provare il software, servono a garantire l'assenza di bug (a seconda della strategia in maniera matematica o probabilistica). La ricerca infatti sta nel trovare le strategie di test migliori per minimizzare lo sforzo e ottimizzare la probabilità di identificare i bug, l'esempio del coglione è il partition testing, se ho un metodo che processa una numero intero quali sono i test migliori che posso fare? Gli input sono infiniti, scriverò un test però per i casi significativi, -1, 0, 01, 1.1, numero random. Ho coperto tutti gli stati? no. Ho coperto gli stati sensibili? Si.
Posso infatti utilizzare diversi criteri per valutare la mia test suite, dai diversi criteri di copertura (codice, controllo, data flow) a metodi attivi quali il fault injiection.
vammi pure contro, ci sto a fare la tesi su questa cosa :sneer:
Sei un po' troppo spocchioso Hador, Vegeta non ha detto niente di scorretto. I test ovviamente servono, ma ti dicono solo che qualcosa funziona o non funziona, spesso non ti dice molto sull'interazione nel tempo dei vari componenti.
La cosa piu' importante è il processo di debugging, che puo' essere aiutato coi test.non è questione di esser spocchiosi, è questione che sbagli :p
Amiag
28th October 2010, 11:54
non far casino, i processi agili sono fondati sui test, cioè tipo il primo punto del manifesto agile è tests first, "utilizza i test come specifica". E anche in italia in medie piccole realtà è ormai comune trovare lo sviluppo organizzato con xp, scrum o derivati.
Beh non direi che sono il primo punto, ma di certo sono importanti. Pero' sono test usati in fase di sviluppo ed eseguiti dagli stessi sviluppatori, tante' vero che una delle critiche mosse a questi processi e' cosi' si rischia di ridurre l'importanza dei test di integrazione e quality assurance.
Beh non direi che sono il primo punto, ma di certo sono importanti. Pero' sono test usati in fase di sviluppo ed eseguiti dagli stessi sviluppatori, tante' vero che una delle critiche mosse a questi processi e' cosi' si rischia di ridurre l'importanza dei test di integrazione e quality assurance.
Karidi
28th October 2010, 11:58
Uno dei problemi maggiori non è la funzionalità ma trovare dev. capaci di fare software tunati a dovere.
Alkabar
28th October 2010, 12:35
sei tu che fai casino, i test mica servono a provare il software, servono a garantire l'assenza di bug (a seconda della strategia in maniera matematica o probabilistica). La ricerca infatti sta nel trovare le strategie di test migliori per minimizzare lo sforzo e ottimizzare la probabilità di identificare i bug, l'esempio del coglione è il partition testing, se ho un metodo che processa una numero intero quali sono i test migliori che posso fare? Gli input sono infiniti, scriverò un test però per i casi significativi, -1, 0, 01, 1.1, numero random. Ho coperto tutti gli stati? no. Ho coperto gli stati sensibili? Si.
Ti stai impelagando male:
Il test di per se ti dice solo che lo stato del sistema è corretto o no dati certi input, non ti garantisce l'assenza di bug anche dentro ai componenti stessi che ti hanno computato il risultato corretto. Se vai avanti a dir di ste cose mi fai pensare male.
Posso infatti utilizzare diversi criteri per valutare la mia test suite, dai diversi criteri di copertura (codice, controllo, data flow) a metodi attivi quali il fault injiection.
vammi pure contro, ci sto a fare la tesi su questa cosa :sneer:non è questione di esser spocchiosi, è questione che sbagli :p
O magari sei tu che hai studiato male il corso di ingegneria del software. Tutto sommato molto probabile considerando che arrivi a confondere imperativo con procedurale.
Ti stai impelagando male:
Il test di per se ti dice solo che lo stato del sistema è corretto o no dati certi input, non ti garantisce l'assenza di bug anche dentro ai componenti stessi che ti hanno computato il risultato corretto. Se vai avanti a dir di ste cose mi fai pensare male.
Posso infatti utilizzare diversi criteri per valutare la mia test suite, dai diversi criteri di copertura (codice, controllo, data flow) a metodi attivi quali il fault injiection.
vammi pure contro, ci sto a fare la tesi su questa cosa :sneer:non è questione di esser spocchiosi, è questione che sbagli :p
O magari sei tu che hai studiato male il corso di ingegneria del software. Tutto sommato molto probabile considerando che arrivi a confondere imperativo con procedurale.
Alkabar
28th October 2010, 12:39
Beh per questo che ci sono più fasi di test
- Sviluppo, ma molte volte non si usano gli ambienti predisposti ma si usano i propri portatili o Mac per fare figo poi quando rilasciano sui sistemi di Release Management ti trovi di tutto e fioccano le madonne.
- IAT/UAT ambienti di integrazione accettazione che nella maggior parte delle volte sono mononodi
- PreProduzione, enviroment scalati dalla produzione ma con architetture di Cluster e Multistanze integrate tra loro nei vari mondi (Web/PRV etc.etc.) i DB sono le copie fisiche o restore effettuati tramite Storage.
(in questo ambiente vengono fatti gli stresstest e le prove di deploy in cluster mode, che sono i maggiori bagni di sangue/caporetto che hanno i software rilasciati.
TEST: Dipende dalla bravura dei gruppi di QA dalle specifiche che seguono la CR o il progetto e qui vengono redatti i TESTCase che sono gli scenari, che vengono studiati sui documenti che arrivano dall'analisti, dalla fattibilità dagli Architetti e i PM etc.etc.
Per questo che ci sono strumenti molto diffusi come la suite Mercury etc.etc.
La maggior parte dei problemi che si hanno nelle architetture enterprise è che chi si fregia di titolo di Architetto non sa una ceppa di nulla di Sistemi/Network e architetture, quindi fa il suo Software superfunzionante sul suo MAC, poi quando vai a fare integrazione/deploy scopri che non va una bega per poi sdraiarlo in pochi secondi quando lo bombardi con LoadRunner.
Che non clasha per niente col fatto che i test sono un aiuto al debugging, non sono il debugging. Altrimenti perchè mai faresti dei test...
Alka: 10 anni fa si chiedeva che un Software Funzionasse ora si chiede che un Software sia PErformante ed Efficace c'è una differenza abissale tra i due concetti.
Perchè poppi e assumi cose che non ho detto?
Certo non l'ho detto e rileggendo: non l'ho detto. E rileggendolo di nuovo: non l'ho detto quello che scrivi.
Ho detto che il test ti dice solo se un componente funziona o no, dove per funziona o no intendo che finisce nello stato corretto dato un certo input.
- Sviluppo, ma molte volte non si usano gli ambienti predisposti ma si usano i propri portatili o Mac per fare figo poi quando rilasciano sui sistemi di Release Management ti trovi di tutto e fioccano le madonne.
- IAT/UAT ambienti di integrazione accettazione che nella maggior parte delle volte sono mononodi
- PreProduzione, enviroment scalati dalla produzione ma con architetture di Cluster e Multistanze integrate tra loro nei vari mondi (Web/PRV etc.etc.) i DB sono le copie fisiche o restore effettuati tramite Storage.
(in questo ambiente vengono fatti gli stresstest e le prove di deploy in cluster mode, che sono i maggiori bagni di sangue/caporetto che hanno i software rilasciati.
TEST: Dipende dalla bravura dei gruppi di QA dalle specifiche che seguono la CR o il progetto e qui vengono redatti i TESTCase che sono gli scenari, che vengono studiati sui documenti che arrivano dall'analisti, dalla fattibilità dagli Architetti e i PM etc.etc.
Per questo che ci sono strumenti molto diffusi come la suite Mercury etc.etc.
La maggior parte dei problemi che si hanno nelle architetture enterprise è che chi si fregia di titolo di Architetto non sa una ceppa di nulla di Sistemi/Network e architetture, quindi fa il suo Software superfunzionante sul suo MAC, poi quando vai a fare integrazione/deploy scopri che non va una bega per poi sdraiarlo in pochi secondi quando lo bombardi con LoadRunner.
Che non clasha per niente col fatto che i test sono un aiuto al debugging, non sono il debugging. Altrimenti perchè mai faresti dei test...
Alka: 10 anni fa si chiedeva che un Software Funzionasse ora si chiede che un Software sia PErformante ed Efficace c'è una differenza abissale tra i due concetti.
Perchè poppi e assumi cose che non ho detto?
Certo non l'ho detto e rileggendo: non l'ho detto. E rileggendolo di nuovo: non l'ho detto quello che scrivi.
Ho detto che il test ti dice solo se un componente funziona o no, dove per funziona o no intendo che finisce nello stato corretto dato un certo input.
Karidi
28th October 2010, 12:45
I test ovviamente servono, ma ti dicono solo che qualcosa funziona o non funziona, spesso non ti dice molto sull'interazione nel tempo dei vari componenti.
Alkabar
28th October 2010, 12:52
I test ovviamente servono, ma ti dicono solo che qualcosa funziona o non funziona, spesso non ti dice molto sull'interazione nel tempo dei vari componenti.
E quindi stai capendo cazzi per mazzi.
E quindi stai capendo cazzi per mazzi.
Eltarion
28th October 2010, 12:58
ma che cazzo di seghe mentali vi state facendo? Ha chiesto se c'era qualche linguaggio veloce da imparare da usare non in ambito profesisonale. Non ci sono altre risposte se non C# o VB.NET. L'ottimizzazione della gestione della memoria, il multithreading in ambito distribuito e la gestione delle concorrenze non credo siano una sua priorità. State solamente facendo una gara a chi ce l'ha più lungo e duro. LOL
Alkabar
28th October 2010, 13:00
Aggiungo, tanto per concludere, citando dal sommerville:
il software ha caratteristiche funzionali e non funzionali.
Le caratteristiche funzionali, riguardano la funzione del software. Quello che fa.
Le caratteristiche non funzionali, riguardano:
-performance
-Speed
-Resource Usage
-altro
E sono caratteristiche emergenti del software. Cioè sono cose che si possono valutare solo a posteriori, dopo che il software è in piedi e gira, perchè hanno senso solo alla fine del processo.
I test, si fanno per la parte funzionale. Perchè non esiste un test, nel mentre che si programma, per vedere se il software è perfomante è semplicemente stupido.
Senza rancore eh, ma seriamente ora vi state impelagando davvero davvero male.
il software ha caratteristiche funzionali e non funzionali.
Le caratteristiche funzionali, riguardano la funzione del software. Quello che fa.
Le caratteristiche non funzionali, riguardano:
-performance
-Speed
-Resource Usage
-altro
E sono caratteristiche emergenti del software. Cioè sono cose che si possono valutare solo a posteriori, dopo che il software è in piedi e gira, perchè hanno senso solo alla fine del processo.
I test, si fanno per la parte funzionale. Perchè non esiste un test, nel mentre che si programma, per vedere se il software è perfomante è semplicemente stupido.
Senza rancore eh, ma seriamente ora vi state impelagando davvero davvero male.
Alkabar
28th October 2010, 13:07
ma che cazzo di seghe mentali vi state facendo? Ha chiesto se c'era qualche linguaggio veloce da imparare da usare non in ambito profesisonale. Non ci sono altre risposte se non C# o VB.NET. L'ottimizzazione della gestione della memoria, il multithreading in ambito distribuito e la gestione delle concorrenze non credo siano una sua priorità. State solamente facendo una gara a chi ce l'ha più lungo e duro. LOL
Beh, in tutta onestà non mi sono piaciute le uscite di Hador a gamba tesa su Vegeta sulla questione dei test e ho risposto, del 3D mi interessava davvero poco. Magari foste un po' piu' civili in generale invece che fare i galletti del quartiere, dico forse, la gente non risponderebbe.
Beh, in tutta onestà non mi sono piaciute le uscite di Hador a gamba tesa su Vegeta sulla questione dei test e ho risposto, del 3D mi interessava davvero poco. Magari foste un po' piu' civili in generale invece che fare i galletti del quartiere, dico forse, la gente non risponderebbe.
Hador
28th October 2010, 13:07
quel che a me pare probabile è che tu non abbia idea di che cosa si stia parlando invece :sneer:
devo andare a pappa, ma tu non insegnavi sta roba? Se tu potessi provare tutti i valori di input avresti la garanzia dell'assenza di bug, in quanto hai verificato tutte le transizioni possibili a partire da quello stato. Dato che non puoi utilizzi delle strategie, o ottimistiche (es partition testing), o pessimistiche (es analisi statica), o di astrazione (model checking). Il debug non centra una sega, il software critico secondo te è controllato a mano facendo debug? Ma che stai dicendo alka.
E giga lol sul fatto che il testing si fa solo su caratteristiche funzionali, la validazione che fa scusa? Va bene fare il tuttologo ma fino ad un certo punto.
Non esiste un modo per testare le performance o usabilità mentre fai le cose? ma tutta la sega sui processi iterativi a che minchia serve allora, per sport? Mha...
devo andare a pappa, ma tu non insegnavi sta roba? Se tu potessi provare tutti i valori di input avresti la garanzia dell'assenza di bug, in quanto hai verificato tutte le transizioni possibili a partire da quello stato. Dato che non puoi utilizzi delle strategie, o ottimistiche (es partition testing), o pessimistiche (es analisi statica), o di astrazione (model checking). Il debug non centra una sega, il software critico secondo te è controllato a mano facendo debug? Ma che stai dicendo alka.
E giga lol sul fatto che il testing si fa solo su caratteristiche funzionali, la validazione che fa scusa? Va bene fare il tuttologo ma fino ad un certo punto.
Non esiste un modo per testare le performance o usabilità mentre fai le cose? ma tutta la sega sui processi iterativi a che minchia serve allora, per sport? Mha...
Karidi
28th October 2010, 13:21
E quindi stai capendo cazzi per mazzi.
No, sto parlando delle fasi che vengono dopo i rilasci del software e nelle sue fasi , e delle problematiche.
Grazie, che non puoi provare il carico (che fa parte del mondo dei TEST, visto che si chiamano STRESSTEST) perchè non hai l'architettura per poterlo fare, non hai un architettura scalata della produzione con apparati di rete e integrata etc.etc.
Non sto rispondendo a te, sto rispondendo in generale su una discussione che è ormai andata OT, parlando da NON programmatore, ma da chi deve subirsi gli ABORTI che tanti pseudo Architetti/ingegneri del software producono.
L'ultima frase era una conclusione quando ti dicevo la differenza con 10anni fà, ma come al solito la prendi sul personale.
No, sto parlando delle fasi che vengono dopo i rilasci del software e nelle sue fasi , e delle problematiche.
Grazie, che non puoi provare il carico (che fa parte del mondo dei TEST, visto che si chiamano STRESSTEST) perchè non hai l'architettura per poterlo fare, non hai un architettura scalata della produzione con apparati di rete e integrata etc.etc.
Non sto rispondendo a te, sto rispondendo in generale su una discussione che è ormai andata OT, parlando da NON programmatore, ma da chi deve subirsi gli ABORTI che tanti pseudo Architetti/ingegneri del software producono.
L'ultima frase era una conclusione quando ti dicevo la differenza con 10anni fà, ma come al solito la prendi sul personale.
Karidi
28th October 2010, 13:22
Il discorso uno deve imparare quello che più gli piace o si trova portato, come per i Sistemi Operativi come per altre cose ci saranno sempre divergenze chi preferisce Java o MS, per l'autore del post sarebbe giusto illustrare anche finalizzato a cosa l'imparare a programmare.
Alkabar
28th October 2010, 14:21
No, sto parlando delle fasi che vengono dopo i rilasci del software e nelle sue fasi , e delle problematiche.
Grazie, che non puoi provare il carico (che fa parte del mondo dei TEST, visto che si chiamano STRESSTEST) perchè non hai l'architettura per poterlo fare, non hai un architettura scalata della produzione con apparati di rete e integrata etc.etc.
Non sto rispondendo a te, sto rispondendo in generale su una discussione che è ormai andata OT, parlando da NON programmatore, ma da chi deve subirsi gli ABORTI che tanti pseudo Architetti/ingegneri del software producono.
L'ultima frase era una conclusione quando ti dicevo la differenza con 10anni fà, ma come al solito la prendi sul personale.
Ma se mi dici "ALKA", la prendo sul personale si, scusa eh :sneer:
Grazie, che non puoi provare il carico (che fa parte del mondo dei TEST, visto che si chiamano STRESSTEST) perchè non hai l'architettura per poterlo fare, non hai un architettura scalata della produzione con apparati di rete e integrata etc.etc.
Non sto rispondendo a te, sto rispondendo in generale su una discussione che è ormai andata OT, parlando da NON programmatore, ma da chi deve subirsi gli ABORTI che tanti pseudo Architetti/ingegneri del software producono.
L'ultima frase era una conclusione quando ti dicevo la differenza con 10anni fà, ma come al solito la prendi sul personale.
Ma se mi dici "ALKA", la prendo sul personale si, scusa eh :sneer:
Karidi
28th October 2010, 14:24
Ma se mi dici "ALKA", la prendo sul personale si, scusa eh :sneer:
Si ma un conto di dico
Alka, ma che cazzate dici
un altro
Alka, e faccio un discorso generico
Si ma un conto di dico
Alka, ma che cazzate dici
un altro
Alka, e faccio un discorso generico
Alkabar
28th October 2010, 14:32
quel che a me pare probabile è che tu non abbia idea di che cosa si stia parlando invece :sneer:
Ah beh, la insegno, ci lavoro, la scrivo in progetti per cui mi danno soldi per assumere della gente a lavorarci sopra... mah... questa discussione sta diventando sterile, se hai bisogno di pomparti l'ego, trovati
una gnocca svedese e vacci in giro per la città, non venire a discutere sul forum.
devo andare a pappa, ma tu non insegnavi sta roba? Se tu potessi provare tutti i valori di input avresti la garanzia dell'assenza di bug, in quanto hai verificato tutte le transizioni possibili a partire da quello stato. Dato che non puoi utilizzi delle strategie, o ottimistiche (es partition testing), o pessimistiche (es analisi statica), o di astrazione (model checking). Il debug non centra una sega, il software critico secondo te è controllato a mano facendo debug? Ma che stai dicendo alka.
E giga lol sul fatto che il testing si fa solo su caratteristiche funzionali, la validazione che fa scusa? Va bene fare il tuttologo ma fino ad un certo punto.
Guarda che sei tu che fai lo studente spocchioso, io sto solamente parlando della materia su cui lavoro.
In piu':
Il model checking è tool formale per verificare che il modello astratto funziona, di nuovo non ti garantisce l'assenza di bug nel prodotto finito.
E soprattutto costa, perchè va quasi sempre a forza bruta in tutti gli stati per assicurare che delle proprietà siano soddisfatte.
Una tra tutte la liveness, cioè che non ci siano deadlock. Oppure che si possa raggiungere uno stato del sistema.
Da qua a dimostrare che il sistema è veloce e fa il caffe' ne passa. Quella si chiama evaluation e col testing c'entra si e no.
Alla evaluation si che controlli le caratteristiche non funzionali del software perchè se un software ha complessità fattoriale non sei proprio contento.
Non esiste un modo per testare le performance o usabilità mentre fai le cose? ma tutta la sega sui processi iterativi a che minchia serve allora, per sport? Mha...
Non si chiama test. E' qualcosa di ben piu' complesso di un test. Per l'appunto in ricerca la chiamiamo evaluation. Test è abuso di linguaggio. Nel senso che lo stai stuprando.
Ah beh, la insegno, ci lavoro, la scrivo in progetti per cui mi danno soldi per assumere della gente a lavorarci sopra... mah... questa discussione sta diventando sterile, se hai bisogno di pomparti l'ego, trovati
una gnocca svedese e vacci in giro per la città, non venire a discutere sul forum.
devo andare a pappa, ma tu non insegnavi sta roba? Se tu potessi provare tutti i valori di input avresti la garanzia dell'assenza di bug, in quanto hai verificato tutte le transizioni possibili a partire da quello stato. Dato che non puoi utilizzi delle strategie, o ottimistiche (es partition testing), o pessimistiche (es analisi statica), o di astrazione (model checking). Il debug non centra una sega, il software critico secondo te è controllato a mano facendo debug? Ma che stai dicendo alka.
E giga lol sul fatto che il testing si fa solo su caratteristiche funzionali, la validazione che fa scusa? Va bene fare il tuttologo ma fino ad un certo punto.
Guarda che sei tu che fai lo studente spocchioso, io sto solamente parlando della materia su cui lavoro.
In piu':
Il model checking è tool formale per verificare che il modello astratto funziona, di nuovo non ti garantisce l'assenza di bug nel prodotto finito.
E soprattutto costa, perchè va quasi sempre a forza bruta in tutti gli stati per assicurare che delle proprietà siano soddisfatte.
Una tra tutte la liveness, cioè che non ci siano deadlock. Oppure che si possa raggiungere uno stato del sistema.
Da qua a dimostrare che il sistema è veloce e fa il caffe' ne passa. Quella si chiama evaluation e col testing c'entra si e no.
Alla evaluation si che controlli le caratteristiche non funzionali del software perchè se un software ha complessità fattoriale non sei proprio contento.
Non esiste un modo per testare le performance o usabilità mentre fai le cose? ma tutta la sega sui processi iterativi a che minchia serve allora, per sport? Mha...
Non si chiama test. E' qualcosa di ben piu' complesso di un test. Per l'appunto in ricerca la chiamiamo evaluation. Test è abuso di linguaggio. Nel senso che lo stai stuprando.
Alkabar
28th October 2010, 14:33
Si ma un conto di dico
Alka, ma che cazzate dici
un altro
Alka, e faccio un discorso generico
Chiaro, chiaro, ho riletto, hai ragione, mi stava montando l'astio per Hador e sei finito nel ciclone.
Alka, ma che cazzate dici
un altro
Alka, e faccio un discorso generico
Chiaro, chiaro, ho riletto, hai ragione, mi stava montando l'astio per Hador e sei finito nel ciclone.
Hador
28th October 2010, 14:46
Ah beh, la insegno, ci lavoro, la scrivo in progetti per cui mi danno soldi per assumere della gente a lavorarci sopra... mah... questa discussione sta diventando sterile, se hai bisogno di pomparti l'ego, trovati
una gnocca svedese e vacci in giro per la città, non venire a discutere sul forum.
Guarda che sei tu che fai lo studente spocchioso, io sto solamente parlando della materia su cui lavoro.
In piu':
Il model checking è tool formale per verificare che il modello astratto funziona, di nuovo non ti garantisce l'assenza di bug nel prodotto finito.
E soprattutto costa, perchè va quasi sempre a forza bruta in tutti gli stati per assicurare che delle proprietà siano soddisfatte.
Una tra tutte la liveness, cioè che non ci siano deadlock. Oppure che si possa raggiungere uno stato del sistema.
Da qua a dimostrare che il sistema è veloce e fa il caffe' ne passa. Quella si chiama evaluation e col testing c'entra si e no.
Alla evaluation si che controlli le caratteristiche non funzionali del software perchè se un software ha complessità fattoriale non sei proprio contento.
Non si chiama test. E' qualcosa di ben piu' complesso di un test. Per l'appunto in ricerca la chiamiamo evaluation. Test è abuso di linguaggio. Nel senso che lo stai stuprando.evaluation che cazzo centra è il confronto tra il prodotto e il piano a livello di processo. Ti rimando ad una lettura, poi ripassa quando ci hai capito qualcosa, i primi due capitoli sono di sample ti dovrebbero bastare per inquadrare il discorso: http://ix.cs.uoregon.edu/~michal/book/
tu stai parlando di una materia che evidentemente non conosci, se hai un collega che si occupa di test seriamente bussagli alla porta e fagli leggere quel che hai scritto in ste pagine, ti riderà in faccia.
e nota che sono un signore che non sto rispondendo con i tuoi toni, ma da quando fai parlare il culo invece che la testa? è un discorso su argomenti scientifici, perchè non ti documenti prima di sparar perle di saggezza?
una gnocca svedese e vacci in giro per la città, non venire a discutere sul forum.
Guarda che sei tu che fai lo studente spocchioso, io sto solamente parlando della materia su cui lavoro.
In piu':
Il model checking è tool formale per verificare che il modello astratto funziona, di nuovo non ti garantisce l'assenza di bug nel prodotto finito.
E soprattutto costa, perchè va quasi sempre a forza bruta in tutti gli stati per assicurare che delle proprietà siano soddisfatte.
Una tra tutte la liveness, cioè che non ci siano deadlock. Oppure che si possa raggiungere uno stato del sistema.
Da qua a dimostrare che il sistema è veloce e fa il caffe' ne passa. Quella si chiama evaluation e col testing c'entra si e no.
Alla evaluation si che controlli le caratteristiche non funzionali del software perchè se un software ha complessità fattoriale non sei proprio contento.
Non si chiama test. E' qualcosa di ben piu' complesso di un test. Per l'appunto in ricerca la chiamiamo evaluation. Test è abuso di linguaggio. Nel senso che lo stai stuprando.evaluation che cazzo centra è il confronto tra il prodotto e il piano a livello di processo. Ti rimando ad una lettura, poi ripassa quando ci hai capito qualcosa, i primi due capitoli sono di sample ti dovrebbero bastare per inquadrare il discorso: http://ix.cs.uoregon.edu/~michal/book/
tu stai parlando di una materia che evidentemente non conosci, se hai un collega che si occupa di test seriamente bussagli alla porta e fagli leggere quel che hai scritto in ste pagine, ti riderà in faccia.
e nota che sono un signore che non sto rispondendo con i tuoi toni, ma da quando fai parlare il culo invece che la testa? è un discorso su argomenti scientifici, perchè non ti documenti prima di sparar perle di saggezza?
Tanek
28th October 2010, 14:53
Separate il thread plz, all'OP non interessano queste cose, il povero Miave vuole provare a fare qualche programmino per diletto e state sminchiando il thread :)
ps: non ho letto nei dettagli la diatriba, quindi non entro nel merito del discorso (e appunto oltretutto è OT).
ps: non ho letto nei dettagli la diatriba, quindi non entro nel merito del discorso (e appunto oltretutto è OT).
Karidi
28th October 2010, 14:55
A mio avviso state parlando di due cose differenti:
alka tu ti stai limitando a parlare di test durante la fare di implementazione del software quelli che fai in fase di sviluppo a livello codice e in ambiente di dev.
Hador: invece sta parlando più con una lunga visione,partendo dallo sviluppo del software fino a ricadere nel discorso che ti facevo io di Ciclo di Vita del Software quindi da quando viene implementato dal team di sviluppo fino ad arrivare al Deploy in produzione e al supporto in esercizio, impattando quindi gruppi di QA gruppi di Stress&performance Test, Validation del software fino alla messa in esercizio con concetti di Sanity Check
Separate il thread plz, all'OP non interessano queste cose, il povero Miave vuole provare a fare qualche programmino per diletto e state sminchiando il thread :)
ps: non ho letto nei dettagli la diatriba, quindi non entro nel merito del discorso (e appunto oltretutto è OT).
Logico sei solo un pigiatasti :kiss: :kiss:
alka tu ti stai limitando a parlare di test durante la fare di implementazione del software quelli che fai in fase di sviluppo a livello codice e in ambiente di dev.
Hador: invece sta parlando più con una lunga visione,partendo dallo sviluppo del software fino a ricadere nel discorso che ti facevo io di Ciclo di Vita del Software quindi da quando viene implementato dal team di sviluppo fino ad arrivare al Deploy in produzione e al supporto in esercizio, impattando quindi gruppi di QA gruppi di Stress&performance Test, Validation del software fino alla messa in esercizio con concetti di Sanity Check
Separate il thread plz, all'OP non interessano queste cose, il povero Miave vuole provare a fare qualche programmino per diletto e state sminchiando il thread :)
ps: non ho letto nei dettagli la diatriba, quindi non entro nel merito del discorso (e appunto oltretutto è OT).
Logico sei solo un pigiatasti :kiss: :kiss:
Hador
28th October 2010, 15:01
sono io mod e decido io, la discussione si è evoluta, poi vi separo il thread se proprio vogliamo :nod:
io ovviamente sto parlando di tutte le fasi di testing, altrimenti avrei parlato di test unitario, ma lo ho scritto diverse volte. Non è neanche un problema di nomi dato che tutte sono fasi di test (test unitario, test di sistema, test strutturale, test di integrazione, stress test, ecc...), con le macro categorie verification e validation.
Tutto il discorso è nato dal fatto che è stato detto che non è possibile garantire, a qualsiasi livello, che un software funzioni bene e faccia quel che deve fare, e che i test servono solo per provare la funzionalità. Con alka che ha continuato dicendo che per garantire l'assenza di bug non si fa test ma debug (lol).
Cosa che accomuna le due persone che hanno sostenuto tale posizione è stato il fornire il loro stipendio/posizione lavorativa come motivazione del fatto che han ragione.
io ovviamente sto parlando di tutte le fasi di testing, altrimenti avrei parlato di test unitario, ma lo ho scritto diverse volte. Non è neanche un problema di nomi dato che tutte sono fasi di test (test unitario, test di sistema, test strutturale, test di integrazione, stress test, ecc...), con le macro categorie verification e validation.
Tutto il discorso è nato dal fatto che è stato detto che non è possibile garantire, a qualsiasi livello, che un software funzioni bene e faccia quel che deve fare, e che i test servono solo per provare la funzionalità. Con alka che ha continuato dicendo che per garantire l'assenza di bug non si fa test ma debug (lol).
Cosa che accomuna le due persone che hanno sostenuto tale posizione è stato il fornire il loro stipendio/posizione lavorativa come motivazione del fatto che han ragione.
Alkabar
28th October 2010, 15:16
Tutto il discorso è nato dal fatto che è stato detto che non è possibile garantire, a qualsiasi livello, che un software funzioni bene e faccia quel che deve fare, e che i test servono solo per provare la funzionalità. Con alka che ha continuato dicendo che per garantire l'assenza di bug non si fa test ma debug (lol).
E di nuovo, io non ho detto niente di sbagliato, ma ahimè l'ignoranza è davvero una brutta bestia. Va beh continua da solo.
E di nuovo, io non ho detto niente di sbagliato, ma ahimè l'ignoranza è davvero una brutta bestia. Va beh continua da solo.
Hador
28th October 2010, 15:18
io il materiale te l'ho fornito, tu?
Alkabar
28th October 2010, 15:21
Concludo qua:
evaluation che cazzo centra è il confronto tra il prodotto e il piano a livello di processo. Ti rimando ad una lettura, poi ripassa quando ci hai capito qualcosa, i primi due capitoli sono di sample ti dovrebbero bastare per inquadrare il discorso: http://ix.cs.uoregon.edu/~michal/book/
Non c'è scritto niente di sbagliato qua. Sei tu che non capisci dove e come si applica, non avendo alcuna esperienza, appunto, assumi e parli a vanvera.
tu stai parlando di una materia che evidentemente non conosci, se hai un collega che si occupa di test seriamente bussagli alla porta e fagli leggere quel che hai scritto in ste pagine, ti riderà in faccia.
Ma anche no.
e nota che sono un signore che non sto rispondendo con i tuoi toni, ma da quando fai parlare il culo invece che la testa? è un discorso su argomenti scientifici, perchè non ti documenti prima di sparar perle di saggezza?
[/QUOTE]
Sei un signore ? Due persone che ci lavorano ti hanno detto che toppi, se magari ti fermassi due secondi invece che continuare con sto ioioioioioio.
Oh vabbeh, ti smusi anche quando ti danno davanti da integrare già solo 4 sistemi complessi assieme, vedrai che tutti i test andranno benissimo, ma il sistema sarà lento, capiteranno bug a muzzo e per quanti test metterai su, ci sarà sempre qualcosa
che ti sfugge di mano.
evaluation che cazzo centra è il confronto tra il prodotto e il piano a livello di processo. Ti rimando ad una lettura, poi ripassa quando ci hai capito qualcosa, i primi due capitoli sono di sample ti dovrebbero bastare per inquadrare il discorso: http://ix.cs.uoregon.edu/~michal/book/
Non c'è scritto niente di sbagliato qua. Sei tu che non capisci dove e come si applica, non avendo alcuna esperienza, appunto, assumi e parli a vanvera.
tu stai parlando di una materia che evidentemente non conosci, se hai un collega che si occupa di test seriamente bussagli alla porta e fagli leggere quel che hai scritto in ste pagine, ti riderà in faccia.
Ma anche no.
e nota che sono un signore che non sto rispondendo con i tuoi toni, ma da quando fai parlare il culo invece che la testa? è un discorso su argomenti scientifici, perchè non ti documenti prima di sparar perle di saggezza?
[/QUOTE]
Sei un signore ? Due persone che ci lavorano ti hanno detto che toppi, se magari ti fermassi due secondi invece che continuare con sto ioioioioioio.
Oh vabbeh, ti smusi anche quando ti danno davanti da integrare già solo 4 sistemi complessi assieme, vedrai che tutti i test andranno benissimo, ma il sistema sarà lento, capiteranno bug a muzzo e per quanti test metterai su, ci sarà sempre qualcosa
che ti sfugge di mano.
Hador
28th October 2010, 15:33
Due persone che ci lavorano ti hanno detto che toppi, se magari ti fermassi due secondi invece che continuare con sto ioioioioioio.
Oh vabbeh, ti smusi anche quando ti danno davanti da integrare già solo 4 sistemi complessi assieme, vedrai che tutti i test andranno benissimo, ma il sistema sarà lento, capiteranno bug a muzzo e per quanti test metterai su, ci sarà sempre qualcosa
che ti sfugge di mano.la conclusione quale sarebbe? Procedere a tentoni dato che è difficile? Qua di ioioioio vedo solo un cercare di imporre la propria opinione senza nient'altro che il "ascolta me che sono uno che ne sà, mi pagano".
-ps sto in un lab con 3 post doc che fa capo 3 professori che dicono quel che sto ripetendo, loro non lavorano? :sneer:
Oh vabbeh, ti smusi anche quando ti danno davanti da integrare già solo 4 sistemi complessi assieme, vedrai che tutti i test andranno benissimo, ma il sistema sarà lento, capiteranno bug a muzzo e per quanti test metterai su, ci sarà sempre qualcosa
che ti sfugge di mano.la conclusione quale sarebbe? Procedere a tentoni dato che è difficile? Qua di ioioioio vedo solo un cercare di imporre la propria opinione senza nient'altro che il "ascolta me che sono uno che ne sà, mi pagano".
-ps sto in un lab con 3 post doc che fa capo 3 professori che dicono quel che sto ripetendo, loro non lavorano? :sneer:
marlborojack
28th October 2010, 17:25
Ragazzi piano perchè non vi si sta dietro
Se tu potessi provare tutti i valori di input avresti la garanzia dell'assenza di bug, in quanto hai verificato tutte le transizioni possibili a partire da quello stato.
Falso. Il pc è un sistema con memoria, e questo basta a contraddire la tesi. Hint: Stati non controllabili ma osservabili. It happens.
Il test di per se ti dice solo che lo stato del sistema è corretto o no dati certi input, non ti garantisce l'assenza di bug anche dentro ai componenti stessi che ti hanno computato il risultato corretto.
Vero
E sono caratteristiche emergenti del software.
Vero, cazzo, stavi andando bene
Cioè sono cose che si possono valutare solo a posteriori, dopo che il software è in piedi e gira, perchè hanno senso solo alla fine del processo.
I test, si fanno per la parte funzionale. Perchè non esiste un test, nel mentre che si programma, per vedere se il software è perfomante è semplicemente stupido.
FALSO, FALSISSIMO, quasi la morte. Se tu non avessi modo di conoscere il tempo di esecuzione A PRIORI non esisterebbero i sistemi operativi real-time, con tutto quello che ne deriverebbe, visto che sono dappertutto. Ma proprio ovunque. Ci sono campi nei quali conoscere le performances E' UN REQUISITO CRITICO, e in tali campi si conosce perfettamente il tempo di esecuzione. Se ne può discutere ma neanche tanto, o le macchine non avrebbero le centraline. Sommerville deve decisamente fare più attenzione a quello che dice, o qualcuno gli tira in testa un WCET :asd:
Se tu potessi provare tutti i valori di input avresti la garanzia dell'assenza di bug, in quanto hai verificato tutte le transizioni possibili a partire da quello stato.
Falso. Il pc è un sistema con memoria, e questo basta a contraddire la tesi. Hint: Stati non controllabili ma osservabili. It happens.
Il test di per se ti dice solo che lo stato del sistema è corretto o no dati certi input, non ti garantisce l'assenza di bug anche dentro ai componenti stessi che ti hanno computato il risultato corretto.
Vero
E sono caratteristiche emergenti del software.
Vero, cazzo, stavi andando bene
Cioè sono cose che si possono valutare solo a posteriori, dopo che il software è in piedi e gira, perchè hanno senso solo alla fine del processo.
I test, si fanno per la parte funzionale. Perchè non esiste un test, nel mentre che si programma, per vedere se il software è perfomante è semplicemente stupido.
FALSO, FALSISSIMO, quasi la morte. Se tu non avessi modo di conoscere il tempo di esecuzione A PRIORI non esisterebbero i sistemi operativi real-time, con tutto quello che ne deriverebbe, visto che sono dappertutto. Ma proprio ovunque. Ci sono campi nei quali conoscere le performances E' UN REQUISITO CRITICO, e in tali campi si conosce perfettamente il tempo di esecuzione. Se ne può discutere ma neanche tanto, o le macchine non avrebbero le centraline. Sommerville deve decisamente fare più attenzione a quello che dice, o qualcuno gli tira in testa un WCET :asd:
Alkabar
28th October 2010, 18:50
FALSO, FALSISSIMO, quasi la morte. Se tu non avessi modo di conoscere il tempo di esecuzione A PRIORI non esisterebbero i sistemi operativi real-time, con tutto quello che ne deriverebbe, visto che sono dappertutto. Ma proprio ovunque. Ci sono campi nei quali conoscere le performances E' UN REQUISITO CRITICO, e in tali campi si conosce perfettamente il tempo di esecuzione. Se ne può discutere ma neanche tanto, o le macchine non avrebbero le centraline. Sommerville deve decisamente fare più attenzione a quello che dice, o qualcuno gli tira in testa un WCET :asd:
E anche no, tu capitomboli proprio male, pure qua il buon Sommerville ha ragione per un banale fatto: se il sistema non è montato, software o meno, a meno di chiamarti Otelma, tu come si comporta dal punto di vista delle performance non lo sai DI CERTO. Test sui componenti non ti aiutano, test incrociati ti aiutano un po'... lo vedi quando hai una larga base di utenti che lo usano se va o no, perchè solo loro saranno in grado di ispezionare una gran parte dei sotto rami del codice.
E' lo stesso motivo per cui metti su degli omarini a giocare tutto il giorno con il giochino 3D e ripetere un miliardo di volte le stesse azioni nel gioco...
E' anche l'esatto motivo per cui i costi di mantenimento del software o di un sistema sono 3 volte piu' grandi di qualunque altro costo di sviluppo...
E anche no, tu capitomboli proprio male, pure qua il buon Sommerville ha ragione per un banale fatto: se il sistema non è montato, software o meno, a meno di chiamarti Otelma, tu come si comporta dal punto di vista delle performance non lo sai DI CERTO. Test sui componenti non ti aiutano, test incrociati ti aiutano un po'... lo vedi quando hai una larga base di utenti che lo usano se va o no, perchè solo loro saranno in grado di ispezionare una gran parte dei sotto rami del codice.
E' lo stesso motivo per cui metti su degli omarini a giocare tutto il giorno con il giochino 3D e ripetere un miliardo di volte le stesse azioni nel gioco...
E' anche l'esatto motivo per cui i costi di mantenimento del software o di un sistema sono 3 volte piu' grandi di qualunque altro costo di sviluppo...
San Vegeta
28th October 2010, 19:35
Cosa che accomuna le due persone che hanno sostenuto tale posizione è stato il fornire il loro stipendio/posizione lavorativa come motivazione del fatto che han ragione.
Posto che non mi interessa piu' la discussione perchè TU sei il depositario unico della verità assoluta e chiunque non la pensi come te ha torto, e quindi io ho torto perchè non la penso come te.
Posto che sto postando (giochi di parole ftw) solo per staccare un attimo dal lavoro.
quello che volevo dire è che io mi sono limitato a dire che i test non possono mostrare tutto il ciclo di vita del software e che i dettagli implementativi di un software distinguono un'applicazione solida da una debole.
Ho persino giustificato brevemente la mia affermazione e non ho nessuna intenzione di scrivere un libro per renderla piu' prolissa nella speranza che faccia colpo su di te.
Se io sostengo che i dettagli implementativi mi caratterizzano positivamente o negativamente un'applicazione non lo faccio perchè me lo son sognato la notte, lo faccio perchè, AD ESEMPIO, sapere che un'applicazione java gira su una JVM e puo' avere un range di memoria perfettamente definito a priori mi garantisce che sia che l'applicazione in questione sia single thread sia che l'applicazione sia multi thread, il totale della memoria occupata sarà quello che è stato deciso all'avvio. E' un dettaglio implementativo. E' un dettaglio importante perchè SO che a runtime non potrà capitare che su una macchina da 4gb di memoria un'applicazione java configurata per occupare 1 gb mi finisca per esaurire la memoria totale del sistema.
Un altro dettaglio implementativo è in che modo trasferire file tra un'applicazione e un'altra: coda jms o file transfer? se non sai quanto saran grossi i file, puoi scegliere qualunque metodo: se un singolo file è piu' grande della memoria totale dell'applicazione che espone la coda jms, non funziona piu' un cazzo; col file transfer l'unico modo per non far funzionare il sistema è riempire completamente il filesystem.
Queste sono cose che puo' prevedere un bravo architetto con TUTTI i dati alla mano, oppure eviti certi problemi implementando il software rispettando le caratteristiche del linguaggio o del sistema.
basta sono stato prolisso e probabilmente neanche chiaro, ciao
Posto che non mi interessa piu' la discussione perchè TU sei il depositario unico della verità assoluta e chiunque non la pensi come te ha torto, e quindi io ho torto perchè non la penso come te.
Posto che sto postando (giochi di parole ftw) solo per staccare un attimo dal lavoro.
quello che volevo dire è che io mi sono limitato a dire che i test non possono mostrare tutto il ciclo di vita del software e che i dettagli implementativi di un software distinguono un'applicazione solida da una debole.
Ho persino giustificato brevemente la mia affermazione e non ho nessuna intenzione di scrivere un libro per renderla piu' prolissa nella speranza che faccia colpo su di te.
Se io sostengo che i dettagli implementativi mi caratterizzano positivamente o negativamente un'applicazione non lo faccio perchè me lo son sognato la notte, lo faccio perchè, AD ESEMPIO, sapere che un'applicazione java gira su una JVM e puo' avere un range di memoria perfettamente definito a priori mi garantisce che sia che l'applicazione in questione sia single thread sia che l'applicazione sia multi thread, il totale della memoria occupata sarà quello che è stato deciso all'avvio. E' un dettaglio implementativo. E' un dettaglio importante perchè SO che a runtime non potrà capitare che su una macchina da 4gb di memoria un'applicazione java configurata per occupare 1 gb mi finisca per esaurire la memoria totale del sistema.
Un altro dettaglio implementativo è in che modo trasferire file tra un'applicazione e un'altra: coda jms o file transfer? se non sai quanto saran grossi i file, puoi scegliere qualunque metodo: se un singolo file è piu' grande della memoria totale dell'applicazione che espone la coda jms, non funziona piu' un cazzo; col file transfer l'unico modo per non far funzionare il sistema è riempire completamente il filesystem.
Queste sono cose che puo' prevedere un bravo architetto con TUTTI i dati alla mano, oppure eviti certi problemi implementando il software rispettando le caratteristiche del linguaggio o del sistema.
basta sono stato prolisso e probabilmente neanche chiaro, ciao
marlborojack
28th October 2010, 20:18
E anche no, tu capitomboli proprio male, pure qua il buon Sommerville ha ragione per un banale fatto: se il sistema non è montato, software o meno, a meno di chiamarti Otelma, tu come si comporta dal punto di vista delle performance non lo sai DI CERTO. Test sui componenti non ti aiutano, test incrociati ti aiutano un po'... lo vedi quando hai una larga base di utenti che lo usano se va o no, perchè solo loro saranno in grado di ispezionare una gran parte dei sotto rami del codice.
E' lo stesso motivo per cui metti su degli omarini a giocare tutto il giorno con il giochino 3D e ripetere un miliardo di volte le stesse azioni nel gioco...
E' anche l'esatto motivo per cui i costi di mantenimento del software o di un sistema sono 3 volte piu' grandi di qualunque altro costo di sviluppo...
LOL. Scadiamo nel surreale, se non nel ridicolo. Se io devo ogni 12 millisecondi leggere un dato su un registro e scriverne uno su di un altro per controllare un motore elettrico, devo fare un'analisi WCET del mio software per garantire che questo avvenga e che quindi sia schedulabile ogni 12 millisecondi, altrimenti non posso fare un emerito cazzo con nessun sistema reale. Allora prendo il codice generato, prendo il tempo di esecuzione di ogni singola istruzione e conto. A quel punto posso dire che, se l'apparato sul quale eseguo l'algoritmo funziona secondo i parametri standard sui quali mi sono basato, allora il mio programma viene eseguito ogni tot e ci impiega tot1 e fine della discussione, non ci sono FATTI o cazzate altrimenti National Instruments sarebbe fallita decenni fa, Matlab non servirebbe ad un cazzo e soprattutto non avremmo l'80% della tecnologia attuale, dai PLC ai sistemi operativi in tempo reale. I test sui componenti li fa chi li produce, e io mi attengo a quel che mi dicono, altrimenti cazzi loro.
E' lo stesso motivo per cui metti su degli omarini a giocare tutto il giorno con il giochino 3D e ripetere un miliardo di volte le stesse azioni nel gioco...
E' anche l'esatto motivo per cui i costi di mantenimento del software o di un sistema sono 3 volte piu' grandi di qualunque altro costo di sviluppo...
LOL. Scadiamo nel surreale, se non nel ridicolo. Se io devo ogni 12 millisecondi leggere un dato su un registro e scriverne uno su di un altro per controllare un motore elettrico, devo fare un'analisi WCET del mio software per garantire che questo avvenga e che quindi sia schedulabile ogni 12 millisecondi, altrimenti non posso fare un emerito cazzo con nessun sistema reale. Allora prendo il codice generato, prendo il tempo di esecuzione di ogni singola istruzione e conto. A quel punto posso dire che, se l'apparato sul quale eseguo l'algoritmo funziona secondo i parametri standard sui quali mi sono basato, allora il mio programma viene eseguito ogni tot e ci impiega tot1 e fine della discussione, non ci sono FATTI o cazzate altrimenti National Instruments sarebbe fallita decenni fa, Matlab non servirebbe ad un cazzo e soprattutto non avremmo l'80% della tecnologia attuale, dai PLC ai sistemi operativi in tempo reale. I test sui componenti li fa chi li produce, e io mi attengo a quel che mi dicono, altrimenti cazzi loro.
Amiag
28th October 2010, 20:31
Se io devo ogni 12 millisecondi leggere un dato su un registro e scriverne uno su di un altro per controllare un motore elettrico,
va beh ma si parlava di programmazione a medio alto livello .... state andando OT sull OT
va beh ma si parlava di programmazione a medio alto livello .... state andando OT sull OT
marlborojack
28th October 2010, 20:46
va beh ma si parlava di programmazione a medio alto livello .... state andando OT sull OT
Il computo del worst-case-execution-time è pur sempre un test per sapere se il programma rispetta il requisito minimo sul tempo di esecuzione. il thread è litigio sui test. Di cosa si sta parlando? I programmi in realtime si scrivono anche in c++ con paradigma ad oggetti e vi sono svariati esempi di middleware soft-realtime
Il computo del worst-case-execution-time è pur sempre un test per sapere se il programma rispetta il requisito minimo sul tempo di esecuzione. il thread è litigio sui test. Di cosa si sta parlando? I programmi in realtime si scrivono anche in c++ con paradigma ad oggetti e vi sono svariati esempi di middleware soft-realtime
Karidi
28th October 2010, 20:52
Posto che non mi interessa piu' la discussione perchè TU sei il depositario unico della verità assoluta e chiunque non la pensi come te ha torto, e quindi io ho torto perchè non la penso come te.
Posto che sto postando (giochi di parole ftw) solo per staccare un attimo dal lavoro.
quello che volevo dire è che io mi sono limitato a dire che i test non possono mostrare tutto il ciclo di vita del software e che i dettagli implementativi di un software distinguono un'applicazione solida da una debole.
Ho persino giustificato brevemente la mia affermazione e non ho nessuna intenzione di scrivere un libro per renderla piu' prolissa nella speranza che faccia colpo su di te.
Se io sostengo che i dettagli implementativi mi caratterizzano positivamente o negativamente un'applicazione non lo faccio perchè me lo son sognato la notte, lo faccio perchè, AD ESEMPIO, sapere che un'applicazione java gira su una JVM e puo' avere un range di memoria perfettamente definito a priori mi garantisce che sia che l'applicazione in questione sia single thread sia che l'applicazione sia multi thread, il totale della memoria occupata sarà quello che è stato deciso all'avvio. E' un dettaglio implementativo. E' un dettaglio importante perchè SO che a runtime non potrà capitare che su una macchina da 4gb di memoria un'applicazione java configurata per occupare 1 gb mi finisca per esaurire la memoria totale del sistema.
Un altro dettaglio implementativo è in che modo trasferire file tra un'applicazione e un'altra: coda jms o file transfer? se non sai quanto saran grossi i file, puoi scegliere qualunque metodo: se un singolo file è piu' grande della memoria totale dell'applicazione che espone la coda jms, non funziona piu' un cazzo; col file transfer l'unico modo per non far funzionare il sistema è riempire completamente il filesystem.
Queste sono cose che puo' prevedere un bravo architetto con TUTTI i dati alla mano, oppure eviti certi problemi implementando il software rispettando le caratteristiche del linguaggio o del sistema.
basta sono stato prolisso e probabilmente neanche chiaro, ciao
Un bravo architetto sà che HEAP di memoria configurabile con i parametri JAVA_OPTIONS=" -xms -xmx" (su WLS WAS) o JAVA_OPTS (Tomcat e JBOSS) su non è quanto occupa il processo dell'application server, ma bensi la memoria allocata e dedicata per gli oggetti dinamici (vivi morti dell'applicazioni),
Hai un pelino di confusione ma mica tanta.....
Il processo è l'insieme della Memoria usata nello start del processo, delle librerie del classpath, startupclass, driver etc.etc.etc. e Deployato, quindi se dentro il tuo EAR per ogni componente che te hai dentro (war e ejb, gli hai ridefinito le stelle librerie) è logico che ti carica su una cosa mastodontica o metti le immagini dentro senza appoggiarti a un CMS o un Apache o usi strutture dedicate come le folder APP-INF e APP-LIB che servono per sharare le librerie a tutti i componenti del EAR, struttura propretaria di WLS
Visto che HEAP SIZE si definisce nello script di start dei Managed Server e come dicevo prima precisamente nella definizione delle JAVA_OPTIONS e non a livello di Singola applicazione quindi è comune a tutte le applicazioni deployate sul APPL.SERVER.
http://download.oracle.com/docs/cd/E13222_01/wls/docs81b/perform/JVMTuning.html
http://www.caucho.com/resin-3.0/performance/jvm-tuning.xtp
Se fai un heap troppo piccola e invece carici diversi oggetti come sessioni, etc.etc. nell'heap questa entrarà in full garbage collection e implode il server.
Per il transfer file, beh se sei un pazzo e vuoi trasferire nella JMS quintali di dati fai pure, poi ti trovi qualcuno che inizia a definirti Threshold and Quota.
Posto che sto postando (giochi di parole ftw) solo per staccare un attimo dal lavoro.
quello che volevo dire è che io mi sono limitato a dire che i test non possono mostrare tutto il ciclo di vita del software e che i dettagli implementativi di un software distinguono un'applicazione solida da una debole.
Ho persino giustificato brevemente la mia affermazione e non ho nessuna intenzione di scrivere un libro per renderla piu' prolissa nella speranza che faccia colpo su di te.
Se io sostengo che i dettagli implementativi mi caratterizzano positivamente o negativamente un'applicazione non lo faccio perchè me lo son sognato la notte, lo faccio perchè, AD ESEMPIO, sapere che un'applicazione java gira su una JVM e puo' avere un range di memoria perfettamente definito a priori mi garantisce che sia che l'applicazione in questione sia single thread sia che l'applicazione sia multi thread, il totale della memoria occupata sarà quello che è stato deciso all'avvio. E' un dettaglio implementativo. E' un dettaglio importante perchè SO che a runtime non potrà capitare che su una macchina da 4gb di memoria un'applicazione java configurata per occupare 1 gb mi finisca per esaurire la memoria totale del sistema.
Un altro dettaglio implementativo è in che modo trasferire file tra un'applicazione e un'altra: coda jms o file transfer? se non sai quanto saran grossi i file, puoi scegliere qualunque metodo: se un singolo file è piu' grande della memoria totale dell'applicazione che espone la coda jms, non funziona piu' un cazzo; col file transfer l'unico modo per non far funzionare il sistema è riempire completamente il filesystem.
Queste sono cose che puo' prevedere un bravo architetto con TUTTI i dati alla mano, oppure eviti certi problemi implementando il software rispettando le caratteristiche del linguaggio o del sistema.
basta sono stato prolisso e probabilmente neanche chiaro, ciao
Un bravo architetto sà che HEAP di memoria configurabile con i parametri JAVA_OPTIONS=" -xms -xmx" (su WLS WAS) o JAVA_OPTS (Tomcat e JBOSS) su non è quanto occupa il processo dell'application server, ma bensi la memoria allocata e dedicata per gli oggetti dinamici (vivi morti dell'applicazioni),
Hai un pelino di confusione ma mica tanta.....
Il processo è l'insieme della Memoria usata nello start del processo, delle librerie del classpath, startupclass, driver etc.etc.etc. e Deployato, quindi se dentro il tuo EAR per ogni componente che te hai dentro (war e ejb, gli hai ridefinito le stelle librerie) è logico che ti carica su una cosa mastodontica o metti le immagini dentro senza appoggiarti a un CMS o un Apache o usi strutture dedicate come le folder APP-INF e APP-LIB che servono per sharare le librerie a tutti i componenti del EAR, struttura propretaria di WLS
Visto che HEAP SIZE si definisce nello script di start dei Managed Server e come dicevo prima precisamente nella definizione delle JAVA_OPTIONS e non a livello di Singola applicazione quindi è comune a tutte le applicazioni deployate sul APPL.SERVER.
http://download.oracle.com/docs/cd/E13222_01/wls/docs81b/perform/JVMTuning.html
http://www.caucho.com/resin-3.0/performance/jvm-tuning.xtp
Se fai un heap troppo piccola e invece carici diversi oggetti come sessioni, etc.etc. nell'heap questa entrarà in full garbage collection e implode il server.
Per il transfer file, beh se sei un pazzo e vuoi trasferire nella JMS quintali di dati fai pure, poi ti trovi qualcuno che inizia a definirti Threshold and Quota.
Alkabar
28th October 2010, 20:59
LOL. Scadiamo nel surreale, se non nel ridicolo. Se io devo ogni 12 millisecondi leggere un dato su un registro e scriverne uno su di un altro per controllare un motore elettrico, devo fare un'analisi WCET del mio software per garantire che questo avvenga e che quindi sia schedulabile ogni 12 millisecondi, altrimenti non posso fare un emerito cazzo con nessun sistema reale. Allora prendo il codice generato, prendo il tempo di esecuzione di ogni singola istruzione e conto. A quel punto posso dire che, se l'apparato sul quale eseguo l'algoritmo funziona secondo i parametri standard sui quali mi sono basato, allora il mio programma viene eseguito ogni tot e ci impiega tot1 e fine della discussione, non ci sono FATTI o cazzate altrimenti National Instruments sarebbe fallita decenni fa, Matlab non servirebbe ad un cazzo e soprattutto non avremmo l'80% della tecnologia attuale, dai PLC ai sistemi operativi in tempo reale. I test sui componenti li fa chi li produce, e io mi attengo a quel che mi dicono, altrimenti cazzi loro.
Quale è il punto di cio' che dici, dove da contro a quanto dico io, piu' che altro, che dico che il test è solo una parte del debugging e che non hai certezza assoluta del comportamento del codice ?
Stai cercando di sostenere che si ha il controllo totale del codice col testing? Su qualche componente del tuo immenso progetto avrai qualche certezza, questo è quanto.
Cosa vi siete fumati oggi, da quando in qua l'informatica è diventata una scienza esatta. Lo so io perchè, perchè c'è di mezzo Alka, pur di dar contro ad Alka si stravolgono anche le leggi della probabilità,
mauauauauahahah.
Quale è il punto di cio' che dici, dove da contro a quanto dico io, piu' che altro, che dico che il test è solo una parte del debugging e che non hai certezza assoluta del comportamento del codice ?
Stai cercando di sostenere che si ha il controllo totale del codice col testing? Su qualche componente del tuo immenso progetto avrai qualche certezza, questo è quanto.
Cosa vi siete fumati oggi, da quando in qua l'informatica è diventata una scienza esatta. Lo so io perchè, perchè c'è di mezzo Alka, pur di dar contro ad Alka si stravolgono anche le leggi della probabilità,
mauauauauahahah.
marlborojack
28th October 2010, 21:06
Quale è il punto di cio' che dici, dove da contro a quanto dico io, piu' che altro, che dico che il test è solo una parte del debugging e che non hai certezza assoluta del comportamento del codice ?
Stai cercando di sostenere che si ha il controllo totale del codice col testing? Su qualche componente del tuo immenso progetto avrai qualche certezza, questo è quanto.
Cosa vi siete fumati oggi, da quando in qua l'informatica è diventata una scienza esatta. Lo so io perchè, perchè c'è di mezzo Alka, pur di dar contro ad Alka si stravolgono anche le leggi della probabilità,
mauauauauahahah.
Il punto è che il tempo di esecuzione può non essere solo un elemento di prestazione, ma anche un requisito funzionale. E sì, su certi tipi di codice, tipo sui plc, devi avere il controllo totale. Ma se intendevi sui software di determinate estensioni e che non hanno requisiti sul tempo di esecuzione, allora la tua precedente affermazione è vera.
E non capita spesso di poter partecipare ad una rissa sui test per la validità del software, non potevo mancare :D
http://lh5.ggpht.com/_MqYsHWQ7fo4/SorAF4LzuyI/AAAAAAAAAJM/WkoGaqv1gkM/Bring_on_the_Bad_Guys.jpg
Stai cercando di sostenere che si ha il controllo totale del codice col testing? Su qualche componente del tuo immenso progetto avrai qualche certezza, questo è quanto.
Cosa vi siete fumati oggi, da quando in qua l'informatica è diventata una scienza esatta. Lo so io perchè, perchè c'è di mezzo Alka, pur di dar contro ad Alka si stravolgono anche le leggi della probabilità,
mauauauauahahah.
Il punto è che il tempo di esecuzione può non essere solo un elemento di prestazione, ma anche un requisito funzionale. E sì, su certi tipi di codice, tipo sui plc, devi avere il controllo totale. Ma se intendevi sui software di determinate estensioni e che non hanno requisiti sul tempo di esecuzione, allora la tua precedente affermazione è vera.
E non capita spesso di poter partecipare ad una rissa sui test per la validità del software, non potevo mancare :D
http://lh5.ggpht.com/_MqYsHWQ7fo4/SorAF4LzuyI/AAAAAAAAAJM/WkoGaqv1gkM/Bring_on_the_Bad_Guys.jpg
San Vegeta
28th October 2010, 21:07
Un bravo architetto sà che HEAP di memoria configurabile con i parametri JAVA_OPTIONS=" -xms xxxx -xmx" (su WLS WAS) o JAVA_OPTS (Tomcat e JBOSS) su non è quanto occupa il processo dell'application server, ma bensi la memoria allocata e dedicata per gli oggetti dinamici (vivi morti dell'applicazioni),
Hai un pelino di confusione ma mica tanta.....
Il processo è l'insieme della Memoria usata nello start del processo, delle librerie del classpath, startupclass, driver etc.etc.etc. e Deployato, quindi se dentro il tuo EAR per ogni componente che te hai dentro (war e ejb, gli hai ridefinito le stelle librerie) è logico che ti carica su una cosa mastodontica o metti le immagini dentro senza appoggiarti a un CMS o un Apache o usi strutture dedicate come le folder APP-INF e APP-LIB che servono per sharare le librerie a tutti i componenti del EAR, struttura propretaria di WLS
Visto che HEAP SIZE si definisce nello script di start dei Managed Server e come dicevo prima precisamente nella definizione delle JAVA_OPTIONS e non a livello di Singola applicazione quindi è comune a tutte le applicazioni deployate sul APPL.SERVER.
http://download.oracle.com/docs/cd/E13222_01/wls/docs81b/perform/JVMTuning.html
http://www.caucho.com/resin-3.0/performance/jvm-tuning.xtp
Se fai un heap troppo piccola e invece carici diversi oggetti come sessioni, etc.etc. nell'heap questa entrarà in full garbage collection e implode il server.
Per il transfer file, beh se sei un pazzo e vuoi trasferire nella JMS quintali di dati fai pure, poi ti trovi qualcuno che inizia a definirti Threshold and Quota.
-Xms1000m -Xmx1000m -XX:PermSize=128m -XX:MaxPermSize=128m
l'applicazione occupa un totale di 1128mb, non uno di più non uno di meno. le librerie sono caricate all'interno di questa memoria allocata
JAVA_OPTIONS e JAVA_OPTS sono variabili di comodo, potevano chiamarsi anche pippo e parepino e funziona tutto uguale. I parametri della JVM sono passati tramite -D e -X. -XX è specifico per alcune JVM.
non parlare di cose a vanvera per favore
Hai un pelino di confusione ma mica tanta.....
Il processo è l'insieme della Memoria usata nello start del processo, delle librerie del classpath, startupclass, driver etc.etc.etc. e Deployato, quindi se dentro il tuo EAR per ogni componente che te hai dentro (war e ejb, gli hai ridefinito le stelle librerie) è logico che ti carica su una cosa mastodontica o metti le immagini dentro senza appoggiarti a un CMS o un Apache o usi strutture dedicate come le folder APP-INF e APP-LIB che servono per sharare le librerie a tutti i componenti del EAR, struttura propretaria di WLS
Visto che HEAP SIZE si definisce nello script di start dei Managed Server e come dicevo prima precisamente nella definizione delle JAVA_OPTIONS e non a livello di Singola applicazione quindi è comune a tutte le applicazioni deployate sul APPL.SERVER.
http://download.oracle.com/docs/cd/E13222_01/wls/docs81b/perform/JVMTuning.html
http://www.caucho.com/resin-3.0/performance/jvm-tuning.xtp
Se fai un heap troppo piccola e invece carici diversi oggetti come sessioni, etc.etc. nell'heap questa entrarà in full garbage collection e implode il server.
Per il transfer file, beh se sei un pazzo e vuoi trasferire nella JMS quintali di dati fai pure, poi ti trovi qualcuno che inizia a definirti Threshold and Quota.
-Xms1000m -Xmx1000m -XX:PermSize=128m -XX:MaxPermSize=128m
l'applicazione occupa un totale di 1128mb, non uno di più non uno di meno. le librerie sono caricate all'interno di questa memoria allocata
JAVA_OPTIONS e JAVA_OPTS sono variabili di comodo, potevano chiamarsi anche pippo e parepino e funziona tutto uguale. I parametri della JVM sono passati tramite -D e -X. -XX è specifico per alcune JVM.
non parlare di cose a vanvera per favore
Karidi
28th October 2010, 21:14
Quale è il punto di cio' che dici, dove da contro a quanto dico io, piu' che altro, che dico che il test è solo una parte del debugging e che non hai certezza assoluta del comportamento del codice ?
Stai cercando di sostenere che si ha il controllo totale del codice col testing? Su qualche componente del tuo immenso progetto avrai qualche certezza, questo è quanto.
Cosa vi siete fumati oggi, da quando in qua l'informatica è diventata una scienza esatta. Lo so io perchè, perchè c'è di mezzo Alka, pur di dar contro ad Alka si stravolgono anche le leggi della probabilità,
mauauauauahahah.
Alka, la fase di test non è parte del Debugging ma una parte del ciclo di vita del software, che deve essere testato e integrato prima e poi collaudato per le performance.
Il debug indica che c'è un defect e quindi fai il troubleshooting per scoprirlo.
Il Test server per verificare che le nuove funzionalità richieste dalle CR che di solito arrivano dal Marketing ---> Analisti ---> Fattibilità ---> Sviluppo ---> Test Accettazione Validazione ----> Test Integrazione e ambienti complessi ---> Messa in esercizio/Produzione ---> Maintenance
Ma per fare i TEST si devono redigere prima i TESTCase partendo dai documenti di Specifiche che arrivano dagli Analisti ancor prima del software, e si fanno i test per verificare che le CR implementate sono correttamente fatte.... Ma è una fase del ciclo del software.
Il Debug, serve a trovare il problema generato a fronte da un DEFECT/Anomalia riscontrata.
Stai cercando di sostenere che si ha il controllo totale del codice col testing? Su qualche componente del tuo immenso progetto avrai qualche certezza, questo è quanto.
Cosa vi siete fumati oggi, da quando in qua l'informatica è diventata una scienza esatta. Lo so io perchè, perchè c'è di mezzo Alka, pur di dar contro ad Alka si stravolgono anche le leggi della probabilità,
mauauauauahahah.
Alka, la fase di test non è parte del Debugging ma una parte del ciclo di vita del software, che deve essere testato e integrato prima e poi collaudato per le performance.
Il debug indica che c'è un defect e quindi fai il troubleshooting per scoprirlo.
Il Test server per verificare che le nuove funzionalità richieste dalle CR che di solito arrivano dal Marketing ---> Analisti ---> Fattibilità ---> Sviluppo ---> Test Accettazione Validazione ----> Test Integrazione e ambienti complessi ---> Messa in esercizio/Produzione ---> Maintenance
Ma per fare i TEST si devono redigere prima i TESTCase partendo dai documenti di Specifiche che arrivano dagli Analisti ancor prima del software, e si fanno i test per verificare che le CR implementate sono correttamente fatte.... Ma è una fase del ciclo del software.
Il Debug, serve a trovare il problema generato a fronte da un DEFECT/Anomalia riscontrata.
Karidi
28th October 2010, 21:14
-Xms1000m -Xmx1000m -XX:PermSize=128m -XX:MaxPermSize=128m
l'applicazione occupa un totale di 1128mb, non uno di più non uno di meno. le librerie sono caricate all'interno di questa memoria allocata
JAVA_OPTIONS e JAVA_OPTS sono variabili di comodo, potevano chiamarsi anche pippo e parepino e funziona tutto uguale. I parametri della JVM sono passati tramite -D e -X. -XX è specifico per alcune JVM.
non parlare di cose a vanvera per favore
Heap size does not determine the amount of memory your process uses
Permanent generation (MaxPermSize setting) is separate heap space that
is not garbage collected (ergo the permanent). Whatever is allocated to
perm is in addition to the heap set with -Xmx.
Essendo definite a livello Server, quindi non è la definizione della tua applicazione ma un impostazione di sistema.
l'applicazione occupa un totale di 1128mb, non uno di più non uno di meno. le librerie sono caricate all'interno di questa memoria allocata
JAVA_OPTIONS e JAVA_OPTS sono variabili di comodo, potevano chiamarsi anche pippo e parepino e funziona tutto uguale. I parametri della JVM sono passati tramite -D e -X. -XX è specifico per alcune JVM.
non parlare di cose a vanvera per favore
Heap size does not determine the amount of memory your process uses
Permanent generation (MaxPermSize setting) is separate heap space that
is not garbage collected (ergo the permanent). Whatever is allocated to
perm is in addition to the heap set with -Xmx.
Essendo definite a livello Server, quindi non è la definizione della tua applicazione ma un impostazione di sistema.
San Vegeta
28th October 2010, 21:17
infatti è la memoria disponibile al processo.
e non hai dimostrato niente
e non hai dimostrato niente
Amiag
28th October 2010, 21:21
Il computo del worst-case-execution-time è pur sempre un test per sapere se il programma rispetta il requisito minimo sul tempo di esecuzione. il thread è litigio sui test. Di cosa si sta parlando? I programmi in realtime si scrivono anche in c++ con paradigma ad oggetti e vi sono svariati esempi di middleware soft-realtime
sto parlando del fatto che stai usando un esempio ultra-specifico per generalizzare su tutt'altro...
ti voglio vedere a calcolare il tempo di esecuzione di ogni singola istruzione di un programma c++ :point: non hai neanche accesso a intervalli di tempo di 12 ms in linguaggi di alto livello (beh su pc "normali" almeno)
sto parlando del fatto che stai usando un esempio ultra-specifico per generalizzare su tutt'altro...
ti voglio vedere a calcolare il tempo di esecuzione di ogni singola istruzione di un programma c++ :point: non hai neanche accesso a intervalli di tempo di 12 ms in linguaggi di alto livello (beh su pc "normali" almeno)
San Vegeta
28th October 2010, 21:23
Essendo definite a livello Server, quindi non è la definizione della tua applicazione ma un impostazione di sistema.
oddiosanto ma che cazzo stai a dì?
oddiosanto ma che cazzo stai a dì?
Alkabar
28th October 2010, 21:26
Alka, la fase di test non è parte del Debugging ma una parte del ciclo di vita del software, che deve essere testato e integrato prima e poi collaudato per le performance.
Il debug indica che c'è un defect e quindi fai il troubleshooting per scoprirlo.
Il Test server per verificare che le nuove funzionalità richieste dalle CR che di solito arrivano dal Marketing ---> Analisti ---> Fattibilità ---> Sviluppo ---> Test Accettazione Validazione ----> Test Integrazione e ambienti complessi ---> Messa in esercizio/Produzione ---> Maintenance
Ma per fare i TEST si devono redigere prima i TESTCase partendo dai documenti di Specifiche che arrivano dagli Analisti ancor prima del software, e si fanno i test per verificare che le CR implementate sono correttamente fatte.... Ma è una fase del ciclo del software.
Il Debug, serve a trovare il problema generato a fronte da un DEFECT/Anomalia riscontrata.
Asp, non concordo:
una problema/anomalia non è qualcosaa che è sempre facile riprodurre. Quando la riscontri, la cosa piu' importante è definire un test che la riproduca spesso cosi' da poterla debuggare.
Il debug indica che c'è un defect e quindi fai il troubleshooting per scoprirlo.
Il Test server per verificare che le nuove funzionalità richieste dalle CR che di solito arrivano dal Marketing ---> Analisti ---> Fattibilità ---> Sviluppo ---> Test Accettazione Validazione ----> Test Integrazione e ambienti complessi ---> Messa in esercizio/Produzione ---> Maintenance
Ma per fare i TEST si devono redigere prima i TESTCase partendo dai documenti di Specifiche che arrivano dagli Analisti ancor prima del software, e si fanno i test per verificare che le CR implementate sono correttamente fatte.... Ma è una fase del ciclo del software.
Il Debug, serve a trovare il problema generato a fronte da un DEFECT/Anomalia riscontrata.
Asp, non concordo:
una problema/anomalia non è qualcosaa che è sempre facile riprodurre. Quando la riscontri, la cosa piu' importante è definire un test che la riproduca spesso cosi' da poterla debuggare.
Alkabar
28th October 2010, 21:28
Il punto è che il tempo di esecuzione può non essere solo un elemento di prestazione, ma anche un requisito funzionale. E sì, su certi tipi di codice, tipo sui plc, devi avere il controllo totale. Ma se intendevi sui software di determinate estensioni e che non hanno requisiti sul tempo di esecuzione, allora la tua precedente affermazione è vera.
E non capita spesso di poter partecipare ad una rissa sui test per la validità del software, non potevo mancare :D
http://lh5.ggpht.com/_MqYsHWQ7fo4/SorAF4LzuyI/AAAAAAAAAJM/WkoGaqv1gkM/Bring_on_the_Bad_Guys.jpg
Ma Marlbro, non ce l'hai mai il controllo totale. Nemmeno sul PLC, nemmeno su realtime. E' una triste verità. Poi ovviamente avrai un controllo tale che il 99.99999999999% delle volte ci prendi, ma devi fare i conti col fatto, soprattuto in sistemi realtime, che stai avendo a che fare con un ambiente non deterministico che puoi prevedere fino a un certo punto.
Se poi sono sistemi realtime distribuiti, beh li c'è da piangere.
E non capita spesso di poter partecipare ad una rissa sui test per la validità del software, non potevo mancare :D
http://lh5.ggpht.com/_MqYsHWQ7fo4/SorAF4LzuyI/AAAAAAAAAJM/WkoGaqv1gkM/Bring_on_the_Bad_Guys.jpg
Ma Marlbro, non ce l'hai mai il controllo totale. Nemmeno sul PLC, nemmeno su realtime. E' una triste verità. Poi ovviamente avrai un controllo tale che il 99.99999999999% delle volte ci prendi, ma devi fare i conti col fatto, soprattuto in sistemi realtime, che stai avendo a che fare con un ambiente non deterministico che puoi prevedere fino a un certo punto.
Se poi sono sistemi realtime distribuiti, beh li c'è da piangere.
Karidi
28th October 2010, 21:37
oddiosanto ma che cazzo stai a dì?
Server = Application Server sto intendendo non a livello di HOST.
Server = Application Server sto intendendo non a livello di HOST.
San Vegeta
28th October 2010, 21:47
e anche se fosse, tu lo sai che un application server come tomcat, jboss, weblogic server o websphere è un'applicazione java?
se non lo sai vatti a vedere come è stato lanciato il processo, vedrai un "java ecc ecc ecc"
e ora basta, smettila di darti la zappa sui piedi ti prego
se non lo sai vatti a vedere come è stato lanciato il processo, vedrai un "java ecc ecc ecc"
e ora basta, smettila di darti la zappa sui piedi ti prego
Kat
28th October 2010, 21:51
State male.
Glasny
28th October 2010, 21:52
Mi son perso sto thread :(
Suvvia usate le triple di hoare :D (affermazione random perchè non ho letto tutto il thread)
Suvvia usate le triple di hoare :D (affermazione random perchè non ho letto tutto il thread)
Karidi
28th October 2010, 22:23
parliamone in PM
San Vegeta
28th October 2010, 22:51
falso, punto
Hador
29th October 2010, 09:23
sostanzialmente abbiamo un informatico che programma con la credenza che quel che fa non può sapere esattamente come si comporterà e uno che tira supercazzole sulla gestione della memoria di java (senza rendrsi conto che uno stress test e/o un test di sistema fanno emergere eventuali problemi di memoria, ergo tramite i test verifichi i dettagli implementativi)... vado a lucca a lunedì :nod:
Alkabar
29th October 2010, 11:34
sostanzialmente abbiamo un informatico che programma con la credenza che quel che fa non può sapere esattamente come si comporterà
Ma quel che faccio io, so con estremamente ottima approssimazione come si comporta, quello che ti sto dicendo in realtà è che quello che fai tu sono sicuro che non sai come si comporta realmente perchè confidi solo nei test come un perfetto niubbo.
Sai che comunque non sei poi differente da Hudlok ? Tendi a far finta di non capire una sega e a ripetere a disco rotto delle boiate nella speranza che facciano presa.
e uno che tira supercazzole sulla gestione della memoria di java (senza rendrsi conto che uno stress test e/o un test di sistema fanno emergere eventuali problemi di memoria, ergo tramite i test verifichi i dettagli implementativi)... vado a lucca a lunedì :nod:
Hai veramente scritto che tramite gli stress-test verifichi i dettagli implementativi.....
Quindi non hai una idea di cosa sia la differenza tra white box testing e black box testing.
Toh, lo sanno anche a Microsoft:
http://msdn.microsoft.com/en-us/library/ff649503.aspx
Uno stress test è tipicamente black box.
O anche qua:
http://www.google.co.uk/url?sa=t&source=web&cd=5&ved=0CCoQFjAE&url=http%3A%2F%2Fwww.cs.nott.ac.uk%2F~cah%2FG53QAT %2FG53QAT09pdf6up.pdf&rct=j&q=black%20box%20testing%20stress%20test&ei=sJPKTP7gIIWTswbaorSnAQ&usg=AFQjCNHPzufAZbDId0uhywA60oRzIxA9DA&sig2=cDZYMjWgU6DsEin1O940XA&cad=rja
Tra parentesti, è una analisi ai morsetti del sistema.... in cui prendi il sistema da un punto di vista olistico, per definizione hai questi problemi:
Disadvantages of Black Box Testing
• Possibility that coincidental aggregation of
several errors will produce the correct response
for a test case, and prevent error detection.
• Absence of control of line coverage. There is no
easy way to specify the parameters of the test
cases required to improve coverage.
• Impossibility of testing the quality of coding and
its strict adherence to the coding standards.
Il black box testing è anche quello che usi per valutare le performance del sistema. Ma e' sempre in base a un comportamento che statisticamente pensi sia quello giusto. "W i deliri di onnipotenza..."
Il white box testing d'altro canto, prende il sistema da un punto di vista interno, riduzionista, e va a testare i blocchi e i dettagli implementativi... ma ha un banale svantaggio:
Non puoi testare ogni singola linea di codice e la sua interazione con il resto del sistema, è semplicemente troppo costoso.
Quindi, prestami un gomito Hador.
Ma quel che faccio io, so con estremamente ottima approssimazione come si comporta, quello che ti sto dicendo in realtà è che quello che fai tu sono sicuro che non sai come si comporta realmente perchè confidi solo nei test come un perfetto niubbo.
Sai che comunque non sei poi differente da Hudlok ? Tendi a far finta di non capire una sega e a ripetere a disco rotto delle boiate nella speranza che facciano presa.
e uno che tira supercazzole sulla gestione della memoria di java (senza rendrsi conto che uno stress test e/o un test di sistema fanno emergere eventuali problemi di memoria, ergo tramite i test verifichi i dettagli implementativi)... vado a lucca a lunedì :nod:
Hai veramente scritto che tramite gli stress-test verifichi i dettagli implementativi.....
Quindi non hai una idea di cosa sia la differenza tra white box testing e black box testing.
Toh, lo sanno anche a Microsoft:
http://msdn.microsoft.com/en-us/library/ff649503.aspx
Uno stress test è tipicamente black box.
O anche qua:
http://www.google.co.uk/url?sa=t&source=web&cd=5&ved=0CCoQFjAE&url=http%3A%2F%2Fwww.cs.nott.ac.uk%2F~cah%2FG53QAT %2FG53QAT09pdf6up.pdf&rct=j&q=black%20box%20testing%20stress%20test&ei=sJPKTP7gIIWTswbaorSnAQ&usg=AFQjCNHPzufAZbDId0uhywA60oRzIxA9DA&sig2=cDZYMjWgU6DsEin1O940XA&cad=rja
Tra parentesti, è una analisi ai morsetti del sistema.... in cui prendi il sistema da un punto di vista olistico, per definizione hai questi problemi:
Disadvantages of Black Box Testing
• Possibility that coincidental aggregation of
several errors will produce the correct response
for a test case, and prevent error detection.
• Absence of control of line coverage. There is no
easy way to specify the parameters of the test
cases required to improve coverage.
• Impossibility of testing the quality of coding and
its strict adherence to the coding standards.
Il black box testing è anche quello che usi per valutare le performance del sistema. Ma e' sempre in base a un comportamento che statisticamente pensi sia quello giusto. "W i deliri di onnipotenza..."
Il white box testing d'altro canto, prende il sistema da un punto di vista interno, riduzionista, e va a testare i blocchi e i dettagli implementativi... ma ha un banale svantaggio:
Non puoi testare ogni singola linea di codice e la sua interazione con il resto del sistema, è semplicemente troppo costoso.
Quindi, prestami un gomito Hador.
Palur
29th October 2010, 11:50
a regà ma un po di bunga bunga?
marlborojack
29th October 2010, 15:53
a regà ma un po di bunga bunga?
Perchè? Quello che ti fanno in sport non ti bastava e sei venuto a provare qua?
Torna da dove sei venuto, hai superato i confini della mappa. Qui ci sono gli informatici
Perchè? Quello che ti fanno in sport non ti bastava e sei venuto a provare qua?
Torna da dove sei venuto, hai superato i confini della mappa. Qui ci sono gli informatici
Kolp
29th October 2010, 18:09
hanno confermato la squalifica a krasic :(
sapete quanto costa un biglietto per los angeles?
sapete quanto costa un biglietto per los angeles?
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.