NSA - Non Solo Amiga
SOFTWARE => Linguaggi di programmazione e scripting => Topic aperto da: Allanon - 28 Febbraio 2012, 23:52:56
-
Stavo spippolando su Internet per iniziare a documentarmi sul pitone e mi sono imbattuto in pyDev, un plug-in per Eclipse che sicuramente Cesare conoscerà :)
Io sono rimasto sbalordito guardando il video di esempio, cioè... cose che neanche lontanamente nella mia mente erano contemplate, tipo che mentre scrivo il codice creo le calssi al volo, oppure rinomino un metodo e automaticamente il codice che ho scritto viene adeguato... sono sbigottito, adesso installo TUTTOOOOO!!! :mrgreen:
link: pyDev (http://http://pydev.org/)
-
eh lo so, ma a parte quando sviluppavo con Access e VBA, ultimamente mi sono dovuto "arrangiare" a causa della mia tendenza smodata verso linguaggi & piattaforme esotiche (leggasi Hollywood e sistemi amigoidi) :D
Ritornare ad usare IDE degni di questo nome è una Babilonia per me :lol:
-
...ma almeno gli stupidi errori di battitura li eliminiamo, e poi noooo.... non sono cattive abitudini :D
-
Stavo spippolando su Internet per iniziare a documentarmi sul pitone e mi sono imbattuto in pyDev, un plug-in per Eclipse che sicuramente Cesare conoscerà :)
Io sono rimasto sbalordito guardando il video di esempio, cioè... cose che neanche lontanamente nella mia mente erano contemplate, tipo che mentre scrivo il codice creo le calssi al volo, oppure rinomino un metodo e automaticamente il codice che ho scritto viene adeguato... sono sbigottito, adesso installo TUTTOOOOO!!! :mrgreen:
link: pyDev (http://http://pydev.org/)
Sì, lo conosco bene, anche perché mi sono girato parecchi IDE per Python. :D
L'unico difetto di PyDev è che... è per Eclipse. Non lo sopporto proprio come IDE: mi sembra un patchwork raffazzonato, per alla fine l'ho mollato.
Per tanto tempo ho avuto NetBeans, e mi sono trovato bene, ma purtroppo hanno deciso di interrompere il supporto a Python (il plug-in funziona fino alla versione 6.9).
Di recente sto sperimentando con Eric4, che ha un mare di funzionalità, ma sento la mancanza del tool di refactoring di NetBeans.
Parlano benissimo di WingIDE e PyCharm, ma sono a pagamento e non li ho mai provati.
Insomma, l'IDE migliore forse è quello che si sviluppa lo stesso sviluppatore. :lol:
Comunque quello per cui ti meravigli è ordinaria amministrazione da anni ormai, per chi segue il mondo degli IDE. 8-)
-
...pensa te in che condizioni ho lavorato fino ad oggi :-)
-
Lo credo bene. :D
Anzi, non pensavo proprio che non conoscessi gli IDE (moderni), e in tutta onestà sono rimasto meravigliato... dalla tua meraviglia. Non per farmi i fatti tuoi, ma... dove hai vissuto finora? :?
P.S. Devo provare anche i Python Tools for Visual Studio, di cui ho sentito parlare bene. Visto che di recente sto utilizzando IronPython per sviluppare applicazioni dotate di GUI (tramite le meravigliose WPF), può darsi che si rivelino più comode per questo scopo.
-
Ti faccio un riassuntino :)
In questi ultimi anni (10) ho vissuto in un'azienda dove sviluppavo solo ed esclusivamente con VBA e Access con sporadiche incursioni su Excel, quindi con l'IDE interno di Office molto valido. Sempre a livello lavorativo ho creato qualche automatizazzione anche con AutoIT (http://http://www.autoitscript.com/site/autoit/) (Windows) ed Expect (http://http://expect.sourceforge.net/) su Linux per monitorare in tempo reale gli ordini trasmessi dai venditori, ma comunque, a livello di codice, roba di poche centinaia di righe anche se incasinate per via di alcune sincronizzazioni necessarie fra le mie applicazioni e quelle "ufficiali" della casa madre, in pratica era un hack bello e buono :D.
Poi facevo assistenza remota prima con PCAnywhere, poi con VNC, sulle postazioni di utenti con problemi.
Nel tempo libero facevo poche cose con roba esotica (per quei tempi) come FreeBasic e qualche altro interprete sperimentale che non ricordo, ma la scimmia era in agguato...
Ho acquistato BlitzBasic per Windows e mi sono messo a fare qualcosina (l'IDE integrato era abbastanza scarso), poi ho scoperto Lua ed ho iniziato a sviluppare un database relazionale con Lua prncipalmente per AROS (che prima o poi riprenderò in mano), era un progetto carino e quasi completo e utilizzabile.
Nel frattempo ho acquistato una Sam e poco dopo Hollywood, finora ho programmato con Hollywood usando solo PSPad e WinUAE perciò immagina che strazio, finchè si tratta di programmini può andare bene ma per un mostro meccanico come AMC PSPad cominciava a starmi stretto.
Adesso sono passato alla nuova versione di Hollywood per Windows che quantomeno ha un editor integrato con syntax hilighting e help online delle funzioni, ma rimane il problema delle classi, per questo ho aperto quel thread sugli IDE qualche giorno fa.
Insomma, fino ad oggi non ho mai avuto bisogno di un IDE complesso perchè me la sono cavata con text editor evoluti e con gli strumenti interni di Office ecco perchè non ho tenuto d'occhio la scena degli IDE.
Poi arrivi te e mi attorcigli un pitone al collo...
:P
-
Ho capito. Non hai avuto la possibilità di provare la Nutella.
E adesso, alla prima cucchiaiata, mi sei diventato subito un drogato. :D
Ma... ti capisco, eccome. :)
P.S. E non hai ancora visto cosa ti mette a disposizione Python a livello di costrutti sintattici e librerie. 8-)
-
se Eclipse ti fa questo effetto, con Visual Studio vieni nei pantaloni :lol:
-
E' che non ci sono abituato
:mrgreen:
Comunque se mai dovessi incontrare Visual Studio mi metterò il pannolone per precauzione :lol:
-
@Antonio: Visual Studio lo uso da un bel pezzo, principalmente per il C, e un po' di mesi fa per C# (Windows Phone 7).
Se si comporta allo stesso modo anche con Python, vado in brodo di giuggiole. :D
-
Ancora non digitato un singolo carattere nel prompt dell'interprete di Python, sto dando un'occhiata veloce alla documentazione, e la prima domanda che mi viene in mente è:
Ma come diavolo ho fatto ad ignorare tutta questa bella roba fino ad oggi?
:think:
-
Te l'avevo detto altre volte di provare Python. :oops:
L'unico che non si riuscirà mai a convincere della goduria che si prova a lavorarci sarà sempre rebraist, che continua a sbattere la testa con la MUI in C quando c'è persino PyMUI a disposizione per non impazzirci. :|
-
Che è una delle cose che uso poco o niente. :D
Non amo documentare il codice. Con lo unit testing si documenta da sé. :ugeek:
-
Che è una delle cose che uso poco o niente. :D
Non amo documentare il codice. Con lo unit testing si documenta da sé. :ugeek:
Lo unit testing non è un end user product (nella programmazione), la documentazione invece lo è.
Se tu mi offri certi servizi e mi garantisci che sono rispettati tutti gli invariant, pre e post condition a me non interessa testare il codice o addirittura leggermi i file di unit test!
La documentazione spesso la leggi anche per trovare velocemente un esempio di come impiegare un determinato strumento (per questo adoro la documentazione Microsoft).
Lo unit testing serve a documentare il codice fornendo proprio tutti gli esempi necessari a capire cosa si aspetta uno strumento (API, funzione, classe), in modo che l'utilizzatore ne sia pienamente consapevole in poco tempo.
Inoltre breaka l'encapsulation se i tuoi unit test (e lo fanno, dato che in un linguaggio dynamic typing lo si deve fare) testano anche le funzioni interne del codice e non solo l'interfaccia.
Non ho capito la parte evidenziata. Potresti essere più chiaro, per favore?
Questo è un problema nel caso volessi offrire moduli in formato binario, a meno che non separi testing di implementazione e di interfaccia (ed offri solo i test per le interfacce).
I miei test riguardano l'interfaccia. L'API (perché sviluppo sempre API) viene trattata una blackbox. Fatta eccezione per gli effetti che provoca; quindi se mi aspetto che un'API inserisca un record nel database, dopo la sua invocazione vado a controllare se effettivamente è così, e nel db ci sia quello che mi aspetto.
Capisco che documentare il codice mentre si programma è noiosissimo, in genere lo si fa a prodotto finito e soprattutto dopo che la fase di testing è terminata e non ci sono ulteriori modifiche da fare
E' anche per questo che non lo faccio: è troppo noioso scrivere documentazione, soprattutto sapendo che hai fatto un sacco di lavoro in tal senso mettendo in piedi una buona suite di test (che, nel mio caso, generalmente è circa il doppio del codice di produzione).
Comunque capisco anche il tuo punto di vista. Certamente se dovessi distribuire il mio codice all'esterno sarei sicuramente costretto a scrivere la documentazione (perché è quello che normalmente si aspettano i programmatori; in particolare quelli che non sono avvezzi allo unit testing), e in tal caso opererei come hai scritto qui alla fine.
Scrivere documentazione in corso d'opera è un'emerita stupidaggine: ci si ritroverebbe con due "codici" da gestire, mantenere, aggiornare, e che potrebbero anche trovarsi non aggiornati allo stesso tempo (il codice fa una cosa, e la documentazione ne dice un'altra). Cosa tutt'altro che scontata.
-
Lo unit testing serve a documentare il codice fornendo proprio tutti gli esempi necessari a capire cosa si aspetta uno strumento (API, funzione, classe), in modo che l'utilizzatore ne sia pienamente consapevole in poco tempo.
No, lo unit test non serve a documentare il codice, se tu lo usi per documentare ne fai uso improprio (o secondario), ma non serve a quello.
Scusami, volevo dire che serve anche a quello.
Inoltre breaka l'encapsulation se i tuoi unit test (e lo fanno, dato che in un linguaggio dynamic typing lo si deve fare) testano anche le funzioni interne del codice e non solo l'interfaccia.
Non ho capito la parte evidenziata. Potresti essere più chiaro, per favore?
Intendo l'implementazione. In un linguaggio dynamic typing non hai l'ausilio del compilatore o interprete per testare la bontà di ogni singola riga di codice, quindi devi fare delle unità di testing anche per l'implementazione. In un linguaggio static typing è sufficiente solo testare l'interfaccia, perché alla fine gli effetti del typing si propagano nell'implementazione. In realtà sarebbe più corretto dire che l'implementazione è testata tramite il constraint dell'interfaccia.
In effetti spesso aggiungo anche dei test specifici per controllare che i tipi passati alla funzione sia quelli attesi.
E' anche per questo che non lo faccio: è troppo noioso scrivere documentazione, soprattutto sapendo che hai fatto un sacco di lavoro in tal senso mettendo in piedi una buona suite di test (che, nel mio caso, generalmente è circa il doppio del codice di produzione).
Sono due lavori totalmente diversi. Ti faccio un esempio banalissimo per farti capire che unit testing != documentazione:
Vogliamo testare una funzione per l'EOF nei file, lo facciamo con un file fisso di tot caratteri, dopo quei tot caratteri ci aspettiamo EOF, nel caso di feof() del C è:
while(1) {
/* code */
if ( feof(infile) )
break;
}
Mentre il TestEOF() della mia dsarlib (nomi inventati) è:
while( ! TestEOF(infile) ) {
/* code */
}
La posizione dell'EOF lo testo conteggiando il numero dei caratteri prima, se usassi loop diversi ci sarebbe un numero minore o maggiore rispetto a quello corretto.
Mi sai dire la differenza di come io nella mia libreria ho implementato il testing dell'EOF, a primo colpo d'occhio? Scommetto che senza una buona documentazione non ci riusciresti :-) (ed è normale).
Semplicemente il feof() del C ti dice se tu sei esattamente sulla posizione dell'EOF, mentre TestEOF() ti dice se il prossimo getch() fallirà perché sarà l'EOF.
L'unit testing ti aiuta a verificare se è corretto per come lo hai voluto implementare tu, ma per comunicarlo al programmatore devi documentarlo! Onestamente mi auguro di non trovare programmatori che pretendano che io capisca una certa implementazione leggendo il codice del testing come quello sopra!
Ti faccio un esempio di come controllo situazioni del genere nel mio codice:
function TestLogin() {
AssertException('StringTooSmall', 'Login', '', 'Prova!');
AssertException('StringTooLong', 'Login', str_repeat('N', 31), 'Prova!');
AssertException('StringTooSmall', 'Login', 'Pippo', '');
AssertException('StringTooLong', 'Login', 'Pippo', str_repeat('N', 31));
NewUser();
Login('Pippo', 'Pluto');
}E' in PHP perché è il primo che avevo davanti, ma comunque dovrebbe servire a rendere l'idea: riproduco lo scenario e lo testo.
In Python lavoro ancora meglio perché a ogni API/funzione/classe dedico una suite di test, e per ogni scenario esiste un test specifico con nome abbastanza indicativo (anche molto lungo, se capita) per far capire cosa sta testando. E poi ovviamente c'è il codice che esercita lo specifico scenario, e solo quello, che è abbastanza esplicativo.
Comunque capisco anche il tuo punto di vista. Certamente se dovessi distribuire il mio codice all'esterno sarei sicuramente costretto a scrivere la documentazione (perché è quello che normalmente si aspettano i programmatori; in particolare quelli che non sono avvezzi allo unit testing), e in tal caso opererei come hai scritto qui alla fine.
Posso chiederti, per curiosità, chi legge i file di unit testing a scopo di documentazione? :O
C'era un progetto chiamato Diamonds che abbiamo sviluppato nella sezione Programmazione del sito di hwupgrade. Fino a un po' di mesi fa c'era un sottoforum apposito (http://http://www.hwupgrade.it/forum/showthread.php?t=2298389) in cui erano stati raccolti tutti i thread, ma visto che il progetto è poi stato abbandonato gli amministratori hanno deciso di spostare i thread all'interno della sezione Programmazione. Comunque se vedi nel link si possono ancora recuperare.
Qui (http://http://www.hwupgrade.it/forum/showthread.php?t=1861352) trovi anche un thread in cui se ne parla, ma sono più interessanti i thread del progetto vero e proprio.
A proposito: se riesci a scaricarti i sorgenti non troverai commenti, a parte per i TODO. :D
Scrivere documentazione in corso d'opera è un'emerita stupidaggine: ci si ritroverebbe con due "codici" da gestire, mantenere, aggiornare, e che potrebbero anche trovarsi non aggiornati allo stesso tempo (il codice fa una cosa, e la documentazione ne dice un'altra). Cosa tutt'altro che scontata.
Il problema di syncare codice e documentazione è un problema reale, ma evitare di farlo fidati che è peggio
Sì, ho chiaro cosa intendi. Volevo soltanto dire che se si deve fare, è meglio farlo alla fine e non mentre si sviluppa, per i problemi che esponevo. ;)
-
Logicamente di tutto quello che avete detto non è che abbia una grande esperienza, anche perchè con Python non ho neanche iniziato, posso solo dire che per i miei progetti non posso non documentare durante la stesura del codice (parlo di documentazione rivolta principalmente a me stesso e per le miei librerie) perchè a distanza di mesi non sarei più in grado di capire a colpo d'occhio cosa fa questo o quello, con quali parametri e limitazioni.
Poi man mano che effettuo delle modifiche modifico la documentazione (all'interno del codice stesso) e metto in coda una serie di brevi commenti su ciò che ho modificato/aggiunto.
Faccio questo perchè altrimenti non ne vengo più fuori :D
Se poi devo pubblicare qualcosa è il momento di stendere la user doc, ma questo solo ed esclusivamente quando il progetto è concluso e stabile altrimenti diventa un secondo lavoro.
-
Però non mi hai detto se a colpo d'occhio hai capito come è stato implementato il test dell'EOF.
Così com'era scritto no, non era assolutamente comprensibile. Avrei scelto un identificatore più descrittivo del tipo di controllo effettuato da quel pezzo di codice.
Ci sono situazioni complesse in cui non te ne puoi uscire con un semplice assert.
Francamente non so. L'esperienza con Diamonds mi porta a dire di no. Ma non posso nemmeno escludere a priori che in futuro non potrei trovarmi di fronte a un caso veramente tosto da formalizzare a livello di test.
Inoltre ci sono cose che non puoi documentare con l'unit testing, come degli internal che fanno riferimento a fatti di performance. Per esempio io pretendo di sapere se GC.Collect() mi invoca uno stop the world oppure è continuo o concorrente, perché nel primo caso sceglierei i momenti più adatti per farlo. Oppure ogni quanto i dati vengono automaticamente flushati in uno stream.
Concordo. Su questo genere di informazioni non c'è unit testing che tenga, ma è normale: non sono strettamente attinenti all'implementazione del codice.
L'unit testing serve per verificare la robustezza delle interfacce, e preferisco lasciarlo per quello.
Lo uso principalmente per quello, e ne sono soddisfattissimo, ma ti assicuro che in ambito Extreme Programming viene valorizzato anche a livello di documentazione. C'è una robusta e florida scuola di pensiero in merito.
Per la documentazione non devi mica scrivere un tema di 50 pagine, bisogna essere rigorosi, concisi ed inambigui. L'ultimo è importante e puoi raggiungerlo solo con i primi due
Concordo.
Logicamente di tutto quello che avete detto non è che abbia una grande esperienza, anche perchè con Python non ho neanche iniziato,
Tranquillo: il discorso che abbiamo fatto finora è generale e non riguarda soltanto Python.
posso solo dire che per i miei progetti non posso non documentare durante la stesura del codice (parlo di documentazione rivolta principalmente a me stesso e per le miei librerie) perchè a distanza di mesi non sarei più in grado di capire a colpo d'occhio cosa fa questo o quello, con quali parametri e limitazioni.
Poi man mano che effettuo delle modifiche modifico la documentazione (all'interno del codice stesso) e metto in coda una serie di brevi commenti su ciò che ho modificato/aggiunto.
Faccio questo perchè altrimenti non ne vengo più fuori :D
Abbiamo due approcci completamente diversi. :mrgreen:
Per me è proprio grazie allo unit testing che posso spaziare da un progetto a un altro completamente diverso, effettuando modifiche e aggiungendo funzionalità con la consapevolezza e la sicurezza di realizzarli in tempi abbastanza "lineari" e rapidi, perché in poco tempo guardando i precisi test che m'interessano riesco a rendermi conto del lavoro che c'è da fare.
Comunque è una questione di pratica: più lavori in questo modo, più ne acquisisci la mentalità e ne apprezzi i frutti. 8-)
Se poi devo pubblicare qualcosa è il momento di stendere la user doc, ma questo solo ed esclusivamente quando il progetto è concluso e stabile altrimenti diventa un secondo lavoro.
Infatti. Farei così anch'io al tuo posto.