vabbè fanculo tutti imparati il prolog :sneer:
Printable View
vabbè fanculo tutti imparati il prolog :sneer:
Cmq volevo segnalarvi che hador mi ha consigliato in pvt la coppia Mono & Osx per sviluppare.
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:
http://imgs.xkcd.com/comics/real_programmers.pngQuote:
Originally Posted by Tunnel
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.
Hador, il tuo voler sempre e per forza avere l'ultima parola su tutto non implica che tu abbia ragione.Quote:
Originally Posted by Hador
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.
madò che stronzata :|Quote:
Originally Posted by San Vegeta
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
momento ioioio, torno a farmi gli affari miei
That's Lame.Quote:
Originally Posted by San Vegeta
hai centrato il problema :sneer:Quote:
Originally Posted by San Vegeta
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.
win incontrastabileQuote:
Originally Posted by San Vegeta
asd robe del primo anno
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.Quote:
Originally Posted by Hador
Poi magari software da cui dipendono vite umane hanno altri processi, ma non ci giurerei :sneer:
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" ...Quote:
Originally Posted by Hador
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:
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.Quote:
Originally Posted by Amiag
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
imho java
Scusa Hador, non vorrei darti contro, ma stai confondendo il test con l'affidabilità. Sono due cose differenti.Quote:
Originally Posted by Hador
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).
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.Quote:
Originally Posted by marlborojack
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.Quote:
Originally Posted by Hador
La cosa piu' importante è il processo di debugging, che puo' essere aiutato coi test.
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.
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.Quote:
Originally Posted by Alkabar
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 :pQuote:
Originally Posted by Alkabar
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.Quote:
Originally Posted by Hador
Uno dei problemi maggiori non è la funzionalità ma trovare dev. capaci di fare software tunati a dovere.
Ti stai impelagando male:Quote:
Originally Posted by Hador
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.
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.Quote:
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
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...Quote:
Originally Posted by Karidi
Perchè poppi e assumi cose che non ho detto?Quote:
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.
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.
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.Quote:
Originally Posted by Karidi
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
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.
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.Quote:
Originally Posted by Eltarion
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...
No, sto parlando delle fasi che vengono dopo i rilasci del software e nelle sue fasi , e delle problematiche.Quote:
Originally Posted by Alkabar
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.
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.
Ma se mi dici "ALKA", la prendo sul personale si, scusa eh :sneer:Quote:
Originally Posted by Karidi
Si ma un conto di dicoQuote:
Originally Posted by Alkabar
Alka, ma che cazzate dici
un altro
Alka, e faccio un discorso generico
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, trovatiQuote:
Originally Posted by Hador
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.Quote:
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.
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.Quote:
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...
Chiaro, chiaro, ho riletto, hai ragione, mi stava montando l'astio per Hador e sei finito nel ciclone.Quote:
Originally Posted by Karidi