Re: [Python] Python vs UML
Il giorno 14/feb/08, alle ore 20:03, [EMAIL PROTECTED] ha scritto: Non c'e` specifica migliore di questa: assert somma(4, 5) == 9 A te il compito arduo di scrivere la funzione che ho usato poco sopra. LO SO... LO SO... def somma(a,b): return b*b - a*a somma(4,5) 9 Ah... che bello! Soddisfa il test :D G ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
On 7 Feb, 02:55 pm, [EMAIL PROTECTED] wrote: Toh... compare un linguagigo di modellazione per specifiche hardware. Per l'hardware va bene e per il software no? Ma e` chiaro... Realizzare l'hardware ha dei costi non indifferenti. Come pensi di simulare il funzionamento dell'hardware senza realizzarlo se non hai un modello? Di contro il software e` estremamente flessibile e non si capisce perche` dovrei cercare di irrigidirlo invece di usare una strada che mi permetta di sfruttarne la flessibilita`. Per inciso, chiunque abbia competenze di Product Lifecycle Management sa benissimo quanto sia cruciale per loro l'accorciamento del tempo di sviluppo di un nuovo prodotto e l'introduzione di strumenti digitali che rendesse possibile lo studio fisico sul modello virtuale ha ridotto i costi in modo assurdo. Un modello di automobile per un crash-test e` capace di costare 2-4 milioni di euro e devono farne parecchi di crash- test. Se riesco a fare CAE sul modello riduco il numero di modelli fisici che dovro` realizzare, potenzialmente portandolo a uno. L'idea e` chiaramente quella di ridurre il costo del prodotto e erroneamente viene applicata anche al software. Nel software non c'e` differenza tra modello e prodotto, sono la stessa cosa. Realizzare il modello del modello e` abbastanza inutile se permetti. Ecco perche` non va bene paragonare le case al software o i prodotti fisici al software. Il software NON e` fisico. E` software ed e` di per se` un modello e un prototipo di se stesso. C'� una grossa azienda che produce software molto grosso e ha sedi di tutto il mondo. Essa vende un programma fantastico che però quasi subito accusa dei malfunzionamenti. Fatti gli accertamenti del caso, si scopre che c'� un pezzo di codice che non si comporta a dovere. Supponiamo poi che il progettista e lo sviluppatore siano persone diverse (che non � una roba cos� poco diffusa come potreste pensare) come fa il progettista a discolparsi? Con dei fogli di stampante su cui ha scritto degli appuntini per lo sviluppatore? O magari affermando che lui gliel'aveva detto al programmatore come si faceva? Il progettista non e` molto bravo perche` invece di scrivere dei fogli di carta doveva scrivere parecchi test di integrazione e di sistema ecc. ecc. Il programmatore invece doveva scrivere dei test unitari su cio` che scriveva. Non c'e` specifica migliore di questa: assert somma(4, 5) == 9 A te il compito arduo di scrivere la funzione che ho usato poco sopra. Poi d'accordo che il progettista non sempre scrive dei test ma nel caso collabora con chi lo fa (gli ingegneri QA, i deployment engineer e via dicendo) ed e` in grado di dire quali siano i test necessari e quali no. Con l'UML _COMUNQUE_ non si sarebbe scoperto che il programmatore briccone aggiungeva 1 a tutte le somme e moltiplicava per 3 tutte le differenze. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
On 6 Feb, 04:21 pm, [EMAIL PROTECTED] wrote: La mia esperienza � quella espressa all'inizio. Non esiste dire che l'UML fa schifo. Come non ha senso dire Java fa schifo, Perl fa schifo, il minestrone fa schifo. Come gi� detto ci sono diversi campi di applicazione. Personalmente l'ho usato solo *una* volta, e con profitto, durante lo svolgimento del tirocinio. Tutte le altre volte (siti web e robe del genere) mi sono fatto due pallini a penne in un foglio e ho risolto egregiamente. Non capisco perche` non si possa dire che qualcosa faccia schifo. Magari non lo faceva quando e` nato ma con l'evoluzione inizia a fare schifo o a essere inadatto un po' per tutto. D'altronde se pure i Javisti stanno cercando un sostituto di Java con Scala un motivo ci sara` credo. Diverso e` il discorso se sia o meno una cosa che fa schifo a te, nel senso che se a te basta Java allora siamo tutti contenti. Ci sono persone a cui Java non piace ma non per partito preso, piuttosto perche` l'hanno usato, poi hanno imparato altri linguaggi e hanno visto che riuscivano ad essere piu` produttivi per fare sostanzialmente qualsiasi cosa e allora la conseguenza e` che ad oggi il linguaggio vecchio non sia piu` adatto. Poi si puo` provocare un po' dicendo che fa schifo. Qualuno ha fatto notare che If the implementation is hard to explain, it's a bad idea;. Ma purtroppo la mondo esistono cose complicate da spiegare a voce e/o con codice vario. Se devo fare un'applicazione che regola il braccio meccanico che esegue un'operazione laser sugli occhi, l'UML serve. Diceva Einstein che hai veramente capito una cosa solo quando riesci a farla capire anche a tua nonna. Devo ancora conoscere un argomento che non si possa imparare facilmente nel suo concetto. Sono riuscito a spiegare come funziona un JIT a una dottoressa di lingue orientali, penso di poter riuscire a spiegare come funziona un'applicazione che esegue l'operazione laser sugli occhi. Resta oscuro il motivo per cui UML porterebbe a software piu` robusto e con meno bachi. Da quando il livello di dettaglio di UML e` tale da impedire i bachi? Prima di tutto potrei non sapere che linguaggio di programmazione usare: Capo: Hey tu? Ci serve un programma che permetta di utilizzare questo fantastico dispositivo embeddato all'interno di un vibratore che regoli la frequanza degli impulsi. Io: Ah, si ok, in cosa lo scrivo? c, c++ o turbo pascal? Capo: Non lo so, non ci � ancora arrivato, per� mi assicurano che � a oggetti E` a oggetti cosa significa? Il vibratore e` un oggetto non e` a oggetti. Io: Hey! Ma se non è ancora arrivato come faccio a sviluppare qualcosa? Ho il codice? Capo: Col cazzo, eccoti gli schemini UML. Tu devi estendere la classe Vibro implementando qualcosa per la regolazione dell'intensit� Non funziona cosi`... Nei dispositivi embedded ci sono una serie di problemi di basso livello che vanno affrontati altro che UML. Se quando ti arriva l'amplificatore scopri che invece di 2MB di EPROM ce n'e` solo la meta` cosa fai col codice che hai scritto? Lo butti via, altro che UML. Se quando arriva scopri che non puoi usare glibc (per dire) ma devi usare tiny-libc-from- vattelapesca-srl il codice lo puoi buttare via. Se quando arriva... (e via dicendo, ci sono un milione di problemi nelle tecnologie embedded, che mica per niente si chiamano embedded visto che software e hardware sono mortalmente accoppiati). Quindi mooolto prima che inizi l'implementazione, tutti i diagrammi vengo analizzati da diverse persone, in diretto rapporto con il commitente e con esperti del settore, ad esempio medici e ingegneri biomedici. Perci� il progetto subir� svariate modifiche. Iniziare a scrivere codice ora, sarebbe una cosa piuttosto noiosa. Dato che molto di esso verr� cancellato e/o profondamente modificato. E` assurdo ragionare di architettura quando non hai la piu` pallida idea di quello che potrai farci sull'hardware che ti danno. Nel campo embedded la sperimentazione e` fondamentale, UML non aiuta. Tanto peggio e` il pensiero di aver realizzato qualcosa avendo scritto un diagramma UML. L'UML e` un disegno, anche quando lo traduci in codice hai solo lo scheletro, nessuna funzionalita` e niente di niente. Mentre scrivi codice sarai COSTRETTO (perche` capita sempre) a cambiare architettura e se ogni volta devo tornare a UML l'iterazione inizia a impiegare settimane invece che minuti. Poi supponiamo che questo software si faccia. E che il braccio meccanico regoli male l'intensità del laser decapitando il paziente e distruggendo l'intera ala ovest dell'ospedale. Di chi � la colpa? Si prendono specifiche, progetto UML e implementazione. E si controlla se il progetto rispetta le specifiche, e se l'implementazione rispetta il progetto. Come fa l'UML a stabilire in che modo viene regolata la potenza del laser? Se nel codice il programmatore ha scritto: laser.power = input_from_user + MegaWatt(2000) UML ci puo` fare
Re: [Python] Python vs UML
2008/2/14 Giovanni Porcari [EMAIL PROTECTED]: LO SO... LO SO... def somma(a,b): return b*b - a*a somma(4,5) 9 Ah... che bello! Soddisfa il test :D Ricordami di non usare software scritto da te :P. for a, b, c in [(1,2,3), (4,5,9), (19, 1, 20), (0, 0, 0)]: assert somma(a, b) == c :P -- Valentino Volonghi aka Dialtone Now running MacOS X 10.5 Home Page: http://www.twisted.it ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
On 3 Feb, 09:00 pm, [EMAIL PROTECTED] wrote: e se devi definire le interfacce prima di scrivere il codice per parallelizare l'implementazione di alcune componenti del software ? Si scrivono dei test e si fanno riunioni in piccoli gruppi di sviluppo che si prendono carico di un sottosistema. Si danno le specifiche e ci si integra in modi diversi a seconda del caso (dipende se esiste una piattaforma comune su cui si integrano tutti oppure se il gruppo crea delle API che documenta e che poi usi per integrare in una base che stai costruendo ecc ecc). Scrivi tutti gli stub dei moduli ? No, mentre scrivo i test faccio i moduli. Riesci ad avere una visione d'insieme di una grande applicazione a mente ? Solitamente si, magari ci si mette un po' per farsela ma se non hai idea di quello che stai costruendo mi chiedo come fai a costruirlo bene. IMHO e' solo questione del modello di sviluppo che si segue... si probabilmente quando si parla di Agile non c'e' proprio bisogno di uml, ma se cominciamo a vedere un approccio Waterfall dove chi fa l'analisi e' una persona diversa da chi fa il progetto che e' diversa dalle persone che implementano l'applicazione... allora formalizzare i flussi di informazioni fra tutte queste persone potrebbe avere un senso... dato che il codice si scrive alla fine L'approcio Waterfall e` fallimentare e superato gia` da decenni, ma neanche dagli approci agili ma addirittura dall'approcio a spirale. Semplicemente non funziona quindi perche` dovrei usarlo per misurare la bonta` di un approcio allo sviluppo? Tutto serve ad uno scopo se lo usi in un'ambito diverso sembra una minchiata e questo e' normale :) UML puo` servire per comunicare col management, FORSE, ma il punto e` che non riesce a convogliare tutte le informazioni che dovrebbe ed e` impossibile farlo tra l'altro con gli strumenti noti fin'ora. L'unico modo per comunicare quelle informazioni e` che il management sia parte del processo di sviluppo e non un semplice supervisore. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
Aggiungo un indispensabile contributo a questa discussione: avete letto la vignetta su stacktrace? http://stacktrace.it/2008/01/silver-bullets/ ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
CUT Non so chi ti ha dato l'idea del 'codice critico - UML', Nessuno, e infatti non volevo dire quello. Ho solo fatto un esempio a caso. Ma mi chiedo che accidenti di esempi fai. Vedi sopra: è solo un esempio. Esempio che ha una GROSSA somiglianza con gli esempi che fanno nei corsi universitari di ingegneria del software ecc. Nel mondo reale è leggermente diverso... Sempre tipicamente, questa roba la modelli in verilog etc Toh... compare un linguagigo di modellazione per specifiche hardware. Per l'hardware va bene e per il software no? Stai scherzando, vero? O sul serio pensi che hardware e software possano essere trattati alla stessa maniera? CUT C'è una grossa azienda che produce software molto grosso e ha sedi di tutto il mondo. Essa vende un programma fantastico che però quasi subito accusa dei malfunzionamenti. Fatti gli accertamenti del caso, si scopre che c'è un pezzo di codice che non si comporta a dovere. Supponiamo poi che il progettista e lo sviluppatore siano persone diverse (che non è una roba così poco diffusa come potreste pensare) come fa il progettista a discolparsi? Con dei fogli di stampante su cui ha scritto degli appuntini per lo sviluppatore? O magari affermando che lui gliel'aveva detto al programmatore come si faceva? Ok, ora è certo: stai scherzando! ;-) 1) La separazione *netta* tra progettista e sviluppatore non è nemmeno così diffusa come puoi pensare. 2) Se un pezzo di codice non si comporta a dovere, che gliene può fregare al progettista? 3) Se pure non fosse un pezzo di codice, ma un errore di progetto, in cosa potrebbe aiutare UML? -- Antonio Valente ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
On Feb 7, 2008, at 3:55 PM, Java wrote: Toh... compare un linguagigo di modellazione per specifiche hardware. Per l'hardware va bene e per il software no? E' chiara la differenza fra hardware e software con annessi e connessi? Chiedo perché se lo fosse, dovresti renderti conto che in primo luogo quello che va bene per il software non va bene per l'hardware (aggiungo che, anche se forse nei corsi universitari di Ing Sw non lo dicono spesso che ci sono *grosse* differenze anche nel modo in cui approcciare diversi tipi di progetti software, costi accettabili, defect rate accettabili, tipi di difetti accettabili, tipi e quantità di ritardo accettabile). In aggiunta il punto è che essere 'contrari' ad un dato linguaggio di modellizzazione voglia essere contrario a *tutti*, al concetto di 'modellizzazione' (ivi inclusa quella per ambiti non informatici etc etc etc). Tipicamente l'hardware ha in se e per se un livello di astrazione bassino; viceversa il software non necessariamente. Tipicamente Python ha un livello di astrazione non certamente più basso di UML (per quanto ovviamente un linguaggio di programmazione come Python è adattissimo per esprimere determinati tipi diagrammi UML, mentre altri no -- al che bisogna chiedersi se questi altri diagrammi sono o meno utili, per cui vedere se usare UML per quelli, se usare un altro formalismo oppure se si possono non fare e basta --). Poi si pongono problemi di *costo* di realizzazione. Un prototipo software è direttamente eseguibile (un diagramma UML no). *Costruire* dell'hardware, disfarlo, cambiarlo è costosissimo: con il software molto meno (specie se in un linguaggio in cui i cambiamenti sono facili). Tipicamente fai prima a scrivere un programma in verilog che a bruciarti un PLA (ammesso che il problema che stai risolvendo sia proprio semplice, se no con un PLA vai poco lontano). Etc etc. Comunque io fossi in te mi chiederei se pensi *davvero* che hw e sw siano la stessa cosa. C'è una grossa azienda che produce software molto grosso e ha sedi di tutto il mondo. Essa vende un programma fantastico che però quasi subito accusa dei malfunzionamenti. Fatti gli accertamenti del caso, si scopre che c'è un pezzo di codice che non si comporta a dovere. Supponiamo poi che il progettista e lo sviluppatore siano persone diverse (che non è una roba così poco diffusa come potreste pensare) come fa il progettista a discolparsi? Con dei fogli di stampante su cui ha scritto degli appuntini per lo sviluppatore? O magari affermando che lui gliel'aveva detto al programmatore come si faceva? Scusa, ma questa è stra-fuffa. E' una situazione ipotetica in primo luogo, sufficientemente generica da voler dire tutto e nulla. Aggiungo che in un caso del genere, i primi a saltare sono quelli del reparto qualità (se esiste), poi quelli del testing (che evidentemente hanno cazzeggiato). Questo sempre nel mondo fantastico dei ruoli distinti e del 15 teste e un senior e 10 neolaureati. Comunque, tornando a noi, dopo averti ringraziato dei tuoi insights sul mondo del software, non posso che ribadire quello che ti fa notare anche Antonio. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
2008/2/5 Crash Override [EMAIL PROTECTED]: Dal tuo grado di nervosismo nello scrivere e dal tuo italiano si capisce chi sei e cosa fai nella vita. 1) ti consiglio di imparare a scrivere in italiano perchè nella vita è sempre utile 1a) forse non sai neanche parlarlo correttamente, ed esprimersi bene nella vita è utile te l'assicuro 2) I ruoli esistono e non puoi eliminarli anche se fondametalmente nutri per loro molta invidia Ciao e divertiti con i tuoi amici di quinta elementare p.s.: rispondo con il tuo stesso tono solo che in un italiano più corretto Non c'è alcun motivo per scrivere una mail con questo tono. Sarebbe molto meglio evitare messaggi di questo genere per non rovinare l'atmosfera di questa mailing list. Francesco ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
On Feb 4, 2008, at 2:23 PM, Marco Mariani wrote: Se ti interessa focalizzare il tuo scetticismo nei confronti di XP: Ci ho dato una lettura rapida. Il primo è ben scritto: ma non mi pare ponga argomenti decisivi. E' molto una cosa tipo: ho incontrato un team di coglionazzi che facevano XP. Non hanno cavato un ragno da un buco. XP è pericoloso. Io nelle stesse condizioni avrei detto: erano un team di coglionazzi. Primo perchè XP lo si può anche fare male (e nel caso aiuta avere almeno la prima volta un consulente capace di dare una mano a riguardo, invece che uno che osteggia il metodo -- il che non può che peggiorare la faccenda --). In secondo luogo se uno ha un team di scimmie ammaestrate è completamente ovvio che non può fare XP. Ma il problema non è XP: il problema sono le scimmie ammaestrate. Le scimmie ammaestrate in un altro metodo riescono a uscirne? Può essere. Ma non essendo io una scimmia ammaestrata non è detto che l'altro metodo faccia un gran bene a me. Fra le altre varie cose ci si dimentica di alcuni fattori: i progetti che falliscono malamente sono *tantissimi*. Spesso proprio per problemi di metodo. Per cui io partirei dal presupposto: l'ingegneria tradizionale ha grossi problemi (sono tutti li da constatare). Possiamo fare di meglio? Si. No. Che ipotesi dobbiamo aggiungere per fare di meglio? Poi magari viene fuori anche che Scrumm è meglio di XP. O che AUP è meglio di entrambi. O che c'è un terzo metodo geniale, o ancora che il vecchio V-model da risultati migliori a patto che A) B) C). Ma questi sono tutti discorsi su cui trarre risultati *concreti* è difficile. C'è troppa variabilità sui membri del progetto, sui clienti, sul management, gestione dei tempi etc etc etc. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
Roberto Bettazzoni ha scritto: Ciao a tutti, butto i miei 2 centesimi In sintesi: concordo sull'inutilità di UML per lo sviluppo, soprattutto se usi un linguaggio come Python. Y3s ha scritto: Il giorno 03/feb/08, alle ore 21:38, Crash Override ha scritto: Enrico Franchi ha scritto: On Feb 3, 2008, at 8:30 PM, giuseppe saviano wrote: ho capito che la progettazione uml in alcuni casi risulta limitante; nella stessa serie di messaggi si parlava poi di list comprehension ... altri esempi? Non è che è limitante, è che tutt'ora devo trovare un caso in cui sia davvero utile. Forse non avete ben chiari i vari ruoli dei membri che contribuiscono al successo di un progetto software. Avete mai sentito parlare di Architect, Designer? O conoscete solo il programmatore? si, si, anche evangelista, analista, tester, coach, QA manager ... di ruoli ce n'è a volontà Qualche volta corrispondono ad un mestiere vero, altre sono solo fuffa IMHO il tutto è piuttosto lineare. Se un gruppo di persone vuole una cosa ed un gruppo di persone sa farla, questi devono comunicare nel linguaggio più efficente allo scopo. UML, Python, Italiano, Inglese, SQL, C++ ... non importa. Qui si parla di comunicazione tra le persone, non di comunicazione con la macchina. L'unico che comunica con la macchina è il programmatore mediante il codice. Nella mia esperienza UML non è il più efficente modo di comunicare con gli umani. Io preferisco l'italiano o l'inglese. A proposito dei ruoli: se sei nell'esercito, e il tuo sergente ti dice che il tenente ti comunica che il capitano ha ricevuto un ordine dal colonnello che il generale vuole che si avanzi di 100 metri ... sei sicuro che siano proprio le parole del generale? I ruoli gerarchici o sequenziali non aiutano certo la comunicazione. Allora quando costruiamo una casa esistono solo i muratori? E se un muratore costruisce bene le mura allora la casa può farla senza progetto? Da un po' di tempo si vocifera che il codice sia il progetto (non la casa) e che il muratore sia l'interprete (non il programmatore). La domanda forse sarebbe: Quali sono i vostri titoli di studio? Che fate nella vita? Ma è meglio tralasciare... Il titolo di studio ... stupendo, come se in questo campo fosse qualificante ... ma daii Scegli: Giro, vedo gente, scrivo codice Mi chiamo Taz, risolvo problemi, si, concordo, è meglio tralasciare :-) Roberto ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python Dal tuo grado di nervosismo nello scrivere e dal tuo italiano si capisce chi sei e cosa fai nella vita. 1) ti consiglio di imparare a scrivere in italiano perchè nella vita è sempre utile 1a) forse non sai neanche parlarlo correttamente, ed esprimersi bene nella vita è utile te l'assicuro 2) I ruoli esistono e non puoi eliminarli anche se fondametalmente nutri per loro molta invidia Ciao e divertiti con i tuoi amici di quinta elementare p.s.: rispondo con il tuo stesso tono solo che in un italiano più corretto ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
On Feb 5, 2008 2:02 PM, Gian Mario Tagliaretti [EMAIL PROTECTED] wrote: 2008/2/5 Crash Override [EMAIL PROTECTED]: Ciao, disclaimer La seguente è solo un' opinione personale e non riflette in alcun modo il pensiero dei gestori della ML. /disclaimer 1) Usa nome e cognome se vuoi un minimo di credibilità, il tuo nick fa molto dodicenne e passi per un troll qualunque. Dai pero' il mio e' carino .. posso tenerlo? :) heheheeh 2) Come ha già detto Francesco Guerrieri questa ML, anche su argomenti caldi, è sempre stata civile, pregasi farla rimanere tale. 3) Non inviare mail in HTML, grazie. g 4) Quotare decentemente i messaggi è sintomo di rispetto verso i lettori di una ML pubblica, hint: non basta scrivere in fondo invece che sopra. beh si si e' giusto.. tanto alla fine ogniuno ha le sue teorie quindi scaldarsi cosi' tanto non e' proprio utile a nessuno :). p.s.: rispondo con il tuo stesso tono solo che in un italiano più corretto p.s. la frase qua sopra *NON* é Italiano corretto, riprova e controlla. vi offendete se posto in inglese cosi' se faccio figuracce posso sempre dire che e' colpa del mio ingelese scolastico :)) Se mi valutate l'italiano mi mettete troppo a disagio :) su su ... alla fine si chiacchiera in ml ... non si prende nessuna decisione fondamentale :) ciao ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
2008/2/5 Crash Override [EMAIL PROTECTED]: Ciao, disclaimer La seguente è solo un' opinione personale e non riflette in alcun modo il pensiero dei gestori della ML. /disclaimer 1) Usa nome e cognome se vuoi un minimo di credibilità, il tuo nick fa molto dodicenne e passi per un troll qualunque. 2) Come ha già detto Francesco Guerrieri questa ML, anche su argomenti caldi, è sempre stata civile, pregasi farla rimanere tale. 3) Non inviare mail in HTML, grazie. g 4) Quotare decentemente i messaggi è sintomo di rispetto verso i lettori di una ML pubblica, hint: non basta scrivere in fondo invece che sopra. p.s.: rispondo con il tuo stesso tono solo che in un italiano più corretto p.s. la frase qua sopra *NON* é Italiano corretto, riprova e controlla. ciao -- Gian Mario Tagliaretti ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
http://www.amazon.com/Applying-UML-Patterns-Craig-Larman/dp/0137488807 Intervengo per dire che di tale libro ne esiste anche una versione italiana. http://addison.it/site/show.php?curr_sec=catalogosub_sec=cat_sk_libroISBN=8871922700 Volevo dare un mio parere, da non esperto, ma studente appena laureato e lavoratore da un po'. C'ho studiato su 'sto libro, e l'impressione che ho di UML non e' di un qualcosa di ingessato, bensi' come qualcosa di opzionale, utile per dare una visualizzazione standardizzata a concezioni astratte e comuni di un progettista software. Mi pare utile avere, ad esempio, esemplificazione grafica dei design pattern. Che poi in Python le cose si semplifichino in maniera drastica (e spesso neanche si vengano a proporre) e' vero, ma la struttura di parti critiche del software, nel mio caso, si semplifica e si comunica abbastanza bene se riesco a tradurla su carta con strumenti standardizzati. Nel libro sopra, si parla di usare UML in sessioni temporali assolutamente limitate nel tempo di sviluppo del progetto, si parla di fotografare diagrammi tracciati collettivamente su una lavagna, si parla insomma di attivita' che sono di supporto, ma non il fulcro della progettazione, si parla di creare e aggiornare gli Use Cases in poche mattinane, Modelli di Dominio e di classe nelle parti arzigogolate, di usare Collaboration Diagram e Sequence Diagram, etc. nelle interazioni tipo, nelle parti piu' critiche (secondo gli assiomi abbracciare il cambiamento e affrontare il rischio subito), nei passi iniziali delle diverse iterazioni della progettazione. Mi trovo d'accordo con queste modalita'. Non riesco a capire quindi perche' tutta quest'attenzione su UML, quasi uno dovesse passare la vita a programmare in UML (e non in Python :-)), e quindi neanche la demonizzazione. Lo trovo un utile strumento di progettazione in team, specie se visto come strumento di applicazione di concetti mentali e non come fine. Un paragone che mi viene in mente e' il Latino al liceo: una lingua morta, una cosa apparentemente inutile. Pero' poi mi sono accorto che certe costruzioni di frase le avevo trasportate da Latino a Italiano senza accorgermente e che la struttura linguistica che il Latino applicava in forma di frase m'era rimasta in mente. -- Marco Bonifazi http://www.bonifazi.eu ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
Marco Bonifazi wrote: Non riesco a capire quindi perche' tutta quest'attenzione su UML, quasi uno dovesse passare la vita a programmare in UML (e non in Python :-)), e quindi neanche la demonizzazione. Cerco di riassumere brevemente. Il fatto che Python e altri linguaggi dinamici siano particolarmente espressivi, fa si' che il design a livello medio sia espresso meglio dal codice stesso (*), che non da un diagramma. Avere una finestra piu' ampia sul problema senza uscire dal codice, permette un refactoring e design emergente a un livello piu' alto di quanto non avresti in linguaggi piu' bondage. Sulle parti delicate (architettura su larga scala, scalabilita', concorrenza, security) non mi sembra che UML sia del tutto inutile, anche in Python. Se proprio fa venire il mal di pancia, almeno i diagrammi di attivita' e sequenza. (*) non vale se il codice e' scritto in fortranese. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
Enrico Franchi wrote: Ci ho dato una lettura rapida. Il primo è ben scritto: ma non mi pare ponga argomenti decisivi. E' molto una cosa tipo: ho incontrato un team di coglionazzi che facevano XP. Non hanno cavato un ragno da un buco. A dir la verita', gli autori sostengono che a non aver cavato un ragno con C3, il progetto pilota della metodologia XP, siano Kent Beck e soci.. salvo poi pubblicizzare il successo clamoroso del software. http://www.c2.com/cgi/wiki?IsEarlierCancellationFailure Io nelle stesse condizioni avrei detto: erano un team di coglionazzi. Primo perchè XP lo si può anche fare male (e nel caso aiuta avere almeno la prima volta un consulente capace di dare una mano a riguardo, invece che uno che osteggia il metodo -- il che non può che peggiorare la faccenda --). Si', se XP non funziona vuol dire che non lo stai facendo bene, l'ho sentito spesso. Se non sei guarito e' perche' non hai abbastanza fede, eccetera :-) Possiamo fare di meglio? Si. No. Che ipotesi dobbiamo aggiungere per fare di meglio? Poi magari viene fuori anche che Scrumm è meglio di XP. O che AUP è meglio di entrambi. O che c'è un terzo metodo geniale, o ancora che il vecchio V-model da risultati migliori a patto che A) B) C). Ma questi sono tutti discorsi su cui trarre risultati *concreti* è difficile. La mia impressione e' che i risultati piu' concreti, dentro e fuori dai libri, vengano indubbiamente dall'applicazione di metodi agili, ma non estremi. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
On Feb 5, 2008, at 3:38 PM, Marco Mariani wrote: Si', se XP non funziona vuol dire che non lo stai facendo bene, l'ho sentito spesso. Il problema è che stai usando la tesi per dimostrare la tesi: io mi limito a dire che i successi della programmazione agile sono troppi per fare finta che non funzioni. Non a caso quelli che dicono che non funziona tipicamente portano ad esempio un caso (o n casi) in cui non ha funzionato. Ora applicando questo discorso in modo più generale ottengo che siccome molti progetti software falliscono/sono scritti male etc etc etc non è possibile fare progetti software decenti. Il che è ovviamente un assurdo. In particolare, quando applichi un nuovo modello di sviluppo (quale che sia) devi avere: 1) un team convinto nell'applicarlo 2) un team con buone skill, che sia formalmente in grado di arrivarci in fondo. nel senso che anche con il miglior spremirape, il sangue dalle rape non ce lo cavi. Questo è al di la di XP, Agile, etc etc etc. Vuoi introdurre gestione della qualità standardizzata in un processo UP? Se il team non ne ha voglia e introduce le procedure solo in modo svogliato e di facciata, non cambi nulla. Fai solo perdere più tempo avendo gente che impiega tempo per fingere di seguire il nuovo processo. Ma non per questo dico che la gestione della qualità 'non funziona'. Il problema è che tutti noi siamo biased, volenti o nolenti. A seconda di questo siamo molto più attivi/vogliosi di trovare controesempi che di trovare success-stories (o viceversa). E siamo pure disposti a generalizzare illecitamente quello che abbiamo trovato. Invece ci vuole oggettività. Cosa difficile, per inciso. Nota che XP (e la maggior parte dei metodi agili) sono pensati *anche* per essere introdotti gradualmente; sono metodi flessibili e più un insieme di tecnica che un 'canone standardizzato' alla RUP. Non tutte le tecniche funzionano in tutti i progetti. Alcune tecniche possono essere adattate, migliorate alla situazione, eliminate. E tutto questo è detto chiaramente. Chi prende XP e lo mette in pratica come seguendo un copione sta facendo di tutto meno che fare XP. BTW, io non sono un fan sfegatato di XP. La mia impressione e' che i risultati piu' concreti, dentro e fuori dai libri, vengano indubbiamente dall'applicazione di metodi agili, ma non estremi. Sono abbastanza d'accordo. 'Estremizzare' un metodo agile è in pratica contro la sua stessa natura. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
Non mi era successo di sentire una discussione di SE, cosi interessante complimenti :). ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
Giorgio Zoppi ha scritto: Non mi era successo di sentire una discussione di SE, cosi interessante complimenti :). e il bello è che io che ho causato il putiferio, osando spezzare un'arancia in difesa del povero modello unificato, me ne resto fuori a leggere le mail che affermano che se non lo so fare (non ho viglia di impararlo, è complicato etc etc) allora fa schifo :-D ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
On Feb 6, 2008, at 12:06 AM, Java wrote: me ne resto fuori a leggere le mail che affermano che se non lo so fare (non ho viglia di impararlo, è complicato etc etc) allora fa schifo :-D Non mi pare di avere letto alcuna di queste mail. Ad ogni modo sono sicuro che portando anche la tua esperienza non puoi che alzare il livello della discussione. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
Marco Bonifazi ha scritto: Mi pare utile avere, ad esempio, esemplificazione grafica dei design pattern. Che poi in Python le cose si semplifichino in maniera drastica (e spesso neanche si vengano a proporre) e' vero, ma la struttura di parti critiche del software, nel mio caso, si semplifica e si comunica abbastanza bene se riesco a tradurla su carta con strumenti standardizzati. Il che contrasta con lo Zen di Python: - If the implementation is hard to explain, it's a bad idea; - If the implementation is easy to explain, it may be a good idea. Da non programmatore quale sono, devo dire che mi sono molto servite più queste due frasi :) Simone Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
Giorgio Zoppi wrote: IMHO e' solo questione del modello di sviluppo che si segue... si probabilmente quando si parla di Agile non c'e' proprio bisogno di uml, ma se cominciamo a vedere un approccio Waterfall dove chi fa l'analisi e' una persona diversa da chi fa il progetto che e' diversa Sta cosa dello sviluppo agile ed Extreme Programming non lo mai capita, ma in Italia ce qualcuno in questa ml. che lo fa realmente? Se si quanto fate durare le iterazioni? Ce qualcuno che fa UP Agile? Secondo me se non è fatto bene puzza di code-and-fix. Se ti interessa focalizzare il tuo scetticismo nei confronti di XP: http://www.stickyminds.com/getfile.asp?ot=XMLid=3248fn=XDD3248filelistfilename1%2Epdf http://www.amazon.co.uk/Extreme-Programming-Refactored-Case-Against/dp/1590590961/ref=sr_1_1?ie=UTF8s=gatewayqid=1202131161sr=8-1 http://www.amazon.co.uk/Questioning-EXtreme-Programming-Pete-McBreen/dp/0201844575/ref=sr_1_1?ie=UTF8s=gatewayqid=1202131150sr=8-1 Non me ne vogliano gli amici dell'XPUG di Bologna :-) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
2008/2/3, giuseppe saviano [EMAIL PROTECTED]: ciao a tutti, è un po' che lurko e vorrei fare i complimenti a questa bella community! soprattutto alcuni fra gli ultimi post, mi hanno letteralmente aperto agli occhi su quanto python sia un vero e proprio modo di pensare, oltre che un linguaggio. ed in particolare mi ha colpito: hem rimasugli di UML e Ingegneria del software. Sigh, non si rendono nemmeno conto di quanto male faccia insegnare UML. :( Questa affermazione non la capisco,sarò che sono ignorante, mi dispiace. UML è ottimo per documentare il codice e l'interazione tra i sottosistemi, e anche per pensare a pattern. Quando lavori da solo è un po una rottura usarlo. ciao, Giorgio. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
Il giorno 03/feb/08, alle ore 20:30, giuseppe saviano ha scritto: CUT ho capito che la progettazione uml in alcuni casi risulta limitante; In alcuni casi?!? Sempre direi...UML è IMHO una roba di cui non ho mai capito il senso. Se devo spiegare un concetto ad altre persone è molto più facile e comprensibile un pezzo di codice ben scritto (soprattutto se è python). Se lo devo spiegare a un non tecnico, avere uno schema pieno di riquadri, linee e freccette non aiuta di certo...mentre per la documentazione, codice ben scritto si documenta al 90% da sè. I commenti servono proprio a spiegare il 10% rimanente. Insomma, non trovo una sola applicazione utile di UML, se non quella di vendere tanti libri e rompere le scatole a chi vorrebbe produrre invece di perdere del tempo ;-) nella stessa serie di messaggi si parlava poi di list comprehension ... altri esempi? Altri esempi di cosa? Di roba pythonica? Prova ad aprire una shell e digitare: import this -- Antonio Valente ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
On Feb 3, 2008, at 8:30 PM, giuseppe saviano wrote: ho capito che la progettazione uml in alcuni casi risulta limitante; nella stessa serie di messaggi si parlava poi di list comprehension ... altri esempi? Non è che è limitante, è che tutt'ora devo trovare un caso in cui sia davvero utile. No, il fatto che il management si ecciti se gli porti dei plichi di documentazione non conta. In pratica UML è una cosa che piace molto ai patiti del big design up front (ci vuole pure un linguaggio in cui esprimerlo sto design, no?). Nei linguaggi inerentemente dinamici, la programmazione agile è parte del DNA di quasi ogni programmatore. Aggiungo: Don't Repeat Yourself; perchè esprimere qualcosa in UML quando ho Python? Faccio prima ed è pure eseguibile. Mica sviluppiamo in Java, qui. Poi c'è tutto il discorso sulla ridondanza dell'informazione, etc etc etc. Nota, non è che sono *contro* UML: sono contro la maggior parte degli usi che se ne fanno; specialmente sono contrario ad usarlo come strumento di design. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
Y3s ha scritto: Il giorno 03/feb/08, alle ore 20:30, giuseppe saviano ha scritto: CUT ho capito che la progettazione uml in alcuni casi risulta limitante; In alcuni casi?!? Sempre direi...UML è IMHO una roba di cui non ho mai capito il senso. Se devo spiegare un concetto ad altre persone è molto più facile e comprensibile un pezzo di codice ben scritto (soprattutto se è python). Se lo devo spiegare a un non tecnico, avere uno schema pieno di riquadri, linee e freccette non aiuta di certo...mentre per la documentazione, codice ben scritto si documenta al 90% da sè. I commenti servono proprio a spiegare il 10% rimanente. Insomma, non trovo una sola applicazione utile di UML, se non quella di vendere tanti libri e rompere le scatole a chi vorrebbe produrre invece di perdere del tempo ;-) Mah... Vai e dillo alla IBM (Microsoft Hp etc etc)che con l'uml ci perdono un sacco di tempo. Ti do una dritta generale: quando un'azienda fa qualcosa, è perché ci guadagna, non perché ci perde del tempo. Poi cerchiamo anche di separare un po le cose. Una cosa è quando fai il tuo programmino o sitini internet. Un'altra è quando devi progettare una grossa applicazione alla quale trovi impegnati diversi team. Come esercizio potresti provare ad analizzare i codice dell'ultimo kernel linux. Vediamo se lo capisci al 90%. L'UML fa da linguaggio universale che chiunque può prendere capire e implementare. Lo si può usare *anche* come documentazione inserito all'interno di processi di sviluppo agili tipo XP programming e simili. Ma magari avrete da ridire anche su di questi... Per maggiori dettagli sull'UML: http://it.wikipedia.org/wiki/Unified_Modeling_Language Per l'elenco di aziende che si divertono a perdere tempo: http://www.omg.org/cgi-bin/apps/membersearch.pl (schiacciare search) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
Enrico Franchi ha scritto: On Feb 3, 2008, at 8:30 PM, giuseppe saviano wrote: ho capito che la progettazione uml in alcuni casi risulta limitante; nella stessa serie di messaggi si parlava poi di list comprehension ... altri esempi? Non è che è limitante, è che tutt'ora devo trovare un caso in cui sia davvero utile. No, il fatto che il management si ecciti se gli porti dei plichi di documentazione non conta. In pratica UML è una cosa che piace molto ai patiti del big design up front (ci vuole pure un linguaggio in cui esprimerlo sto design, no?). Nei linguaggi inerentemente dinamici, la programmazione agile è parte del DNA di quasi ogni programmatore. Aggiungo: Don't Repeat Yourself; perchè esprimere qualcosa in UML quando ho Python? Faccio prima ed è pure eseguibile. Mica sviluppiamo in Java, qui. Poi c'è tutto il discorso sulla ridondanza dell'informazione, etc etc etc. Nota, non è che sono *contro* UML: sono contro la maggior parte degli usi che se ne fanno; specialmente sono contrario ad usarlo come strumento di design. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python Forse non avete ben chiari i vari ruoli dei membri che contribuiscono al successo di un progetto software. Avete mai sentito parlare di Architect, Designer? O conoscete solo il programmatore? Allora quando costruiamo una casa esistono solo i muratori? E se un muratore costruisce bene le mura allora la casa può farla senza progetto? Se vi riferite esclusivamente a Python forse in parte potreste aver ragione... Dico forse perchè la mia conoscenza di Python non è molto approfondita (sicuramente si tratta di un linguaggio non difficilissimo). La domanda forse sarebbe: Quali sono i vostri titoli di studio? Che fate nella vita? Ma è meglio tralasciare... ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
On Feb 3, 2008, at 8:44 PM, Giorgio Zoppi wrote: Questa affermazione non la capisco,sarò La spiego. che sono ignorante, mi dispiace. UML è ottimo per documentare il codice e l'interazione tra i sottosistemi, e anche per pensare a pattern. Documentare il codice con UML? 1. per l'interazione tra i sottosistemi ci potrebbe pure stare. peccato che non sia necessario; oltre tutto ci sono tante di quelle parti lasciate scoperte (volutamente) dallo standard che anche li bisogna praticamente sempre definirsi il proprio dialetto. 2. per documentare il codice, direi proprio di no. In primo luogo perchè UML diventa particolarmente rognoso quando si scende nei dettagli: la documentazione del codice spesso non prescinde dai dettagli, ergo eccoci con UML in difficoltà. In secondo luogo nel tempo in cui ci va a fare un diagramma (anzi, i due o tre diagrammi necessari per una data fase) UML si ripulisce il codice fino a renderlo sostanzialmente auto-esplicativo, tramite l'uso di nomenclatura *chiara*, docstrings, tests ed eventualmente se tutto questo non bastasse commenti mirati. 3. pensare a pattern è diverso da *conoscere* i pattern. pensare a pattern è come dire pensare a mattoncini: se qualcuno mi dicesse che penso a mattoncini io gli tirerei due schiaffoni. Non si *pensa* a pattern; quando si conoscono *bene* i pattern si *vedono* nel problema i pattern. Ma questo è un modo a posteriori di usare i pattern; viceversa pensare a pattern usa unità di ragionamento e struttura troppo rigide. Ora potresti provare a spiegarmi perché UML è ottimo (lasciando stare il fatto che lo usano tutti). Io sinceramente non sono mai riuscito a capire questa cosa. O meglio: posso capirla quando penso al mondo business, ai manager, ai commerciali, all'inventare un problema e vendere i costosi strumenti necessari per risolverlo. Posso capirla quando penso a linguaggi completamente ingessati, team di progettisti, analisti e programmatori virtualmente disgiunti. E ho presente anche il fatto che un numero spropositato di progetti finisce in un bagno di sangue. D'altra parte sono completamente aperto a ricredermi. Quando lavori da solo è un po una rottura usarlo. Anche quando lavoro in gruppo. Certo, se per una serie di ragione i miei compari non sono in grado di leggere il codice e la documentazione e hanno bisogno di rappresentazioni grafiche... ok. Anche UML ha un suo senso. Viceversa preferisco del buon codice, scritto bene, non più complesso del necessario e una buona suite di test che mostri anche come il codice va usato e come non va usato. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
Il giorno 03/feb/08, alle ore 21:41, Enrico Franchi ha scritto: On Feb 3, 2008, at 8:44 PM, Giorgio Zoppi wrote: Questa affermazione non la capisco,sarò La spiego. che sono ignorante, mi dispiace. UML è ottimo per documentare il codice e l'interazione tra i sottosistemi, e anche per pensare a pattern. Documentare il codice con UML? 1. per l'interazione tra i sottosistemi ci potrebbe pure stare. peccato che non sia necessario; oltre tutto ci sono tante di quelle parti lasciate scoperte (volutamente) dallo standard che anche li bisogna praticamente sempre definirsi il proprio dialetto. E in ogni caso è poco espressivo. 2. per documentare il codice, direi proprio di no. In primo luogo perchè UML diventa particolarmente rognoso quando si scende nei dettagli: la documentazione del codice spesso non prescinde dai dettagli, ergo eccoci con UML in difficoltà. In secondo luogo nel tempo in cui ci va a fare un diagramma (anzi, i due o tre diagrammi necessari per una data fase) UML si ripulisce il codice fino a renderlo sostanzialmente auto-esplicativo, tramite l'uso di nomenclatura *chiara*, docstrings, tests ed eventualmente se tutto questo non bastasse commenti mirati. Quoto 3. pensare a pattern è diverso da *conoscere* i pattern. pensare a pattern è come dire pensare a mattoncini: se qualcuno mi dicesse che penso a mattoncini io gli tirerei due schiaffoni. Non si *pensa* a pattern; quando si conoscono *bene* i pattern si *vedono* nel problema i pattern. Ma questo è un modo a posteriori di usare i pattern; viceversa pensare a pattern usa unità di ragionamento e struttura troppo rigide. Quoto. Diverso è parlare a pattern, dove e quando possibile). -- Antonio Valente ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
e se devi definire le interfacce prima di scrivere il codice per parallelizare l'implementazione di alcune componenti del software ? Basta parlarsi. Secondo me le CRC cards (o un semplice pezzo di carta) sono 100 volte più utili dell'ingessato UML Scrivi tutti gli stub dei moduli ? Riesci ad avere una visione d'insieme di una grande applicazione a mente ? Dipende da quanto grande, e poi ci sono gli architetti per questo. E di certo non si preoccupano dei nomi dei metodi. IMHO e' solo questione del modello di sviluppo che si segue... si probabilmente quando si parla di Agile non c'e' proprio bisogno di uml, ma se cominciamo a vedere un approccio Waterfall dove chi fa l'analisi e' una persona diversa da chi fa il progetto che e' diversa dalle persone che implementano l'applicazione... allora formalizzare i flussi di informazioni fra tutte queste persone potrebbe avere un senso... dato che il codice si scrive alla fine Il waterfall è un problema per la maggioranza dei casi, e non sono io a dirlo :-D -- Lawrence, stacktrace.it - oluyede.org - neropercaso.it It is difficult to get a man to understand something when his salary depends on not understanding it - Upton Sinclair ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
2008/2/3, Domenico Chierico [EMAIL PROTECTED]: On Feb 3, 2008 9:41 PM, Enrico Franchi [EMAIL PROTECTED] wrote: Quando lavori da solo è un po una rottura usarlo. Anche quando lavoro in gruppo. Certo, se per una serie di ragione i miei compari non sono in grado di leggere il codice e la documentazione e hanno bisogno di rappresentazioni grafiche... ok. Anche UML ha un suo senso. Viceversa preferisco del buon codice, scritto bene, non più complesso del necessario e una buona suite di test che mostri anche come il codice va usato e come non va usato. e se devi definire le interfacce prima di scrivere il codice per parallelizare l'implementazione di alcune componenti del software ? Scrivi tutti gli stub dei moduli ? Riesci ad avere una visione d'insieme di una grande applicazione a mente ? Il problema è che le applicazioni esplodono soprattutto quelle scritte in linguaggi come C# e Java: lo dico per esperienza. In Python non ho scritto mai piu di 1000 righe di codice. Cio' accade soprattutto quando si è in tanti a lavorare, perche ognuno vuole mettere le sue ganzate: questo o quel design pattern quel modo di procedere invece che un'altro. Cosi uno si trova a passare i pomeriggi a fare debug scritto dagli altri (se riuscite a capire un sistema fatto da tanto solo dall'analisi statica, cambio mestiere...vado a fare l'educatore), mentre se fosse solo un po' piu documentato magari con UML il pomeriggio lo passerebbe a fare shopping o cmq sa come e' fatto il sistema si mette l'anima in pace e quando ci sono problemi di performance sa dove andare a parare per eliminare i colli di bottiglia. Un'altra cosa che accade spesso in progetti opensource, non nel kernel di Linux che è ben commentato o nei sorgenti di Python (per esempio la parte sul garbage collection è una favola..quasi quasi è piu la doc che il codice), è che spesso ti trovi davanti ad grandi parti di codice C o Java, dove non c'e un commento o solo commenti stupidi: esperienza di un paio di mesi fa davanti a JBoss per dare una struttura gerarchica agli EJB, preferivo sparire e cambiare mestire. Infatti si è passati a Python e SCA di IBM. IMHO e' solo questione del modello di sviluppo che si segue... si probabilmente quando si parla di Agile non c'e' proprio bisogno di uml, ma se cominciamo a vedere un approccio Waterfall dove chi fa l'analisi e' una persona diversa da chi fa il progetto che e' diversa Sta cosa dello sviluppo agile ed Extreme Programming non lo mai capita, ma in Italia ce qualcuno in questa ml. che lo fa realmente? Se si quanto fate durare le iterazioni? Ce qualcuno che fa UP Agile? Secondo me se non è fatto bene puzza di code-and-fix. In generale comunque usare linguaggi piu snelli come Python, semplifica di molto il ciclo di sviluppo. Due mesi fa ho scritto un parser soap, che prelevava i pacchetti dalla rete, con libpcap in Python, in una giornata..in C o in Java c'avrei messo mezza settimana. Tutto serve ad uno scopo se lo usi in un'ambito diverso sembra una minchiata e questo e' normale :) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
Y3s ha scritto: Il giorno 03/feb/08, alle ore 22:00, Domenico Chierico ha scritto: On Feb 3, 2008 9:41 PM, Enrico Franchi [EMAIL PROTECTED] wrote: Quando lavori da solo è un po una rottura usarlo. Anche quando lavoro in gruppo. Certo, se per una serie di ragione i miei compari non sono in grado di leggere il codice e la documentazione e hanno bisogno di rappresentazioni grafiche... ok. Anche UML ha un suo senso. Viceversa preferisco del buon codice, scritto bene, non più complesso del necessario e una buona suite di test che mostri anche come il codice va usato e come non va usato. e se devi definire le interfacce prima di scrivere il codice per parallelizare l'implementazione di alcune componenti del software ? Scrivi tutti gli stub dei moduli ? Riesci ad avere una visione d'insieme di una grande applicazione a mente ? Il punto è: che bisogno c'è di usare una cosa inutile e complessa come uml? perchè non utilizzare semplicemente un linguaggio altamente espressivo, che ha anche il vantaggio di fornirti un prototipo eseguibile? IMHO e' solo questione del modello di sviluppo che si segue... si probabilmente quando si parla di Agile non c'e' proprio bisogno di uml, ma se cominciamo a vedere un approccio Waterfall dove chi fa l'analisi e' una persona diversa da chi fa il progetto che e' diversa dalle persone che implementano l'applicazione... allora formalizzare i flussi di informazioni fra tutte queste persone potrebbe avere un senso... dato che il codice si scrive alla fine Waterfall? Gli anni '80 sono passati da un po' eh ;-) Comunque, nessuno nega che la formalizzazione dei flussi di informazioni tra persone diverse dello stesso team o tra team diversi sia necessaria, ma io (e penso altri) non capisco perchè uml. Non capisco i vantaggi di uml rispetto a un altro linguaggio più espressivo. Probabilmente perchè avere un diagramma fa più fico nelle riunioni? Pensa che ho avuto una discussione simile nell'ambito SQL su cosa fosse meglio usare: un diagramma E/R o del semplice codice pseudo SQL. La mia tesi a favore del codice SQL era la facilità di modifica e versionamento (specialmente se condiviso) mentre un diagramma grafico è una rottura da gestire. La sua tesi era che non si deve scrivere codice nella fase di design (ok, ma un diagramma E/R non è codice?). Manlio Perillo ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
On Feb 3, 2008, at 10:38 PM, giuseppe saviano wrote: no, intendevo altri esempi di costrutti python non esprimibili con uml IMHO non hai ben chiaro cosa sia UML e come si usi. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
Il giorno 03/feb/08, alle ore 22:36, Manlio Perillo ha scritto: Waterfall? Gli anni '80 sono passati da un po' eh ;-) Comunque, nessuno nega che la formalizzazione dei flussi di informazioni tra persone diverse dello stesso team o tra team diversi sia necessaria, ma io (e penso altri) non capisco perchè uml. Non capisco i vantaggi di uml rispetto a un altro linguaggio più espressivo. Probabilmente perchè avere un diagramma fa più fico nelle riunioni? Pensa che ho avuto una discussione simile nell'ambito SQL su cosa fosse meglio usare: un diagramma E/R o del semplice codice pseudo SQL. Però già un diagramma E/R è diverso: è più semplice e non c'è bisogno di imparare un nuovo formalismo, bastano 2 o 3 convenzioni, poi tutti riescono a scrivere una tabellina di campi. Mentre UML è un vero formalismo, ingessato, poco flessibile, non si impara certo in 10 minuti. Quello che dico è: se dobbiamo insegnare a uno un linguaggio come UML, non conviene insegnargli un linguaggio reale? Comunque tra diagramma E/R e codice SQL generico penso sia davvero una questione di gusti! La mia tesi a favore del codice SQL era la facilità di modifica e versionamento (specialmente se condiviso) mentre un diagramma grafico è una rottura da gestire. La sua tesi era che non si deve scrivere codice nella fase di design (ok, ma un diagramma E/R non è codice?). Infatti. -- Antonio Valente ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
On Feb 3, 2008, at 10:35 PM, Giorgio Zoppi wrote: Il problema è che le applicazioni esplodono soprattutto quelle scritte in linguaggi come C# e Java: lo dico per esperienza. Quoto, ovviamente. Per Java intendo. C# non me lo filo, per cui non mi esprimo. Mi sono spesso interrogato sulla tendenza a sovraingegnerizzare di progettisti Java. In Python non ho scritto mai piu di 1000 righe di codice. Eh... Cio' accade soprattutto quando si è in tanti a lavorare, perche ognuno vuole mettere le sue ganzate: questo o quel design pattern quel modo di procedere invece che un'altro. Cosi uno si trova a passare i pomeriggi a fare debug scritto dagli altri Questo è vero. Ma va anche detto che ci sono *tanti* metodi che possono essere usati. Il pair programming risolve abbastanza alla svelta (a meno che casualmente non si formi sempre una coppia di due con gli stessi vizi...). In generale anche la peer review risolve. (se riuscite a capire un sistema fatto da tanto solo dall'analisi statica, cambio mestiere...vado a fare l'educatore) Se ti può interessare, a margine, ho anche lavorato a tools di analisi statica automatizzata. :P Ma è meglio che non dica quale sia la mia opinione a riguardo. , mentre se fosse solo un po' piu documentato magari con UML il pomeriggio lo passerebbe a fare shopping o cmq sa come e' fatto il sistema si mette l'anima in pace e quando ci sono problemi di performance sa dove andare a parare per eliminare i colli di bottiglia. Se riesci a capire dove sta il collo di bottiglia di un sistema guardando la descrizione (necessariamente astratta) in UML, tanto di cappello. Io non sono minimamente in grado (esattamente come mi rendo conto che la pura intuizione è fuorviante). Preferisco usare un buon profiler e arrivare al punto. Un'altra cosa che accade spesso in progetti opensource, non nel kernel di Linux che è ben commentato o nei sorgenti di Python (per esempio la parte sul garbage collection è una favola..quasi quasi è piu la doc che il codice), è che spesso ti trovi davanti ad grandi parti di codice C o Java, dove non c'e un commento o solo commenti stupidi: esperienza di un paio di mesi fa davanti a JBoss per dare una struttura gerarchica agli EJB, preferivo sparire e cambiare mestire. Infatti si è passati a Python e SCA di IBM. Bene. Sempre felice quando si passa a Python. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
On Feb 3, 2008, at 10:42 PM, Y3s wrote: Però già un diagramma E/R è diverso: è più semplice e non c'è bisogno di imparare un nuovo formalismo, bastano 2 o 3 convenzioni, poi tutti riescono a scrivere una tabellina di campi. Sono abbastanza d'accordo. Tra l'altro quello dei DB è uno dei pochi campi in cui mi trovo bene con gli schemi. Anche usando sintassi pseudo-relazionali, avere le keys grafiche aiuta a focalizzare le interdipendenze. Mentre UML è un vero formalismo, ingessato, poco flessibile, non si impara certo in 10 minuti. E poi ti possono vendere un bel case da K$ a licenza... ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
Oh, grazie del link. Ma se si vuole consigliare qualcosa di buono, perchè non linkare il libro di Fowler? http://www.amazon.com/UML-Distilled-Standard-Addison-Wesley-Technology/dp/0321193687/ref=pd_bbs_sr_1?ie=UTF8s=booksqid=1202078809sr=1-1 Per quanto in completo e totale disaccordo, non è mae nemmeno questo: http://www.amazon.com/UML-Unified-Process-Object-Oriented-Addison-Wesley/dp/0321321278/ref=pd_bbs_sr_1?ie=UTF8s=booksqid=1202078755sr=8-1 Cosa vuole dire? Che sono abbastanza realisti, non sono degli invasati. E no, non mi hanno convinto che il loro metodo sia buono, ma almeno l'esposizione è lucida e ben fatta. Gia che siete in vena di link, a me è piaciuto molto questo: Applying UML and Patterns. http://www.amazon.com/Applying-UML-Patterns-Craig-Larman/dp/0137488807 ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
On Feb 3, 2008, at 9:31 PM, Java wrote: Vai e dillo alla IBM (Microsoft Hp etc etc)che con l'uml ci perdono un sacco di tempo. Ti do una dritta generale: quando un'azienda fa qualcosa, è perché ci guadagna, non perché ci perde del tempo. Beh, per quanto tempo ci perda IBM ci fanno pure un sacco di soldi. Presente Rational Rose? Insomma, oste, come è il vino? Poi cerchiamo anche di separare un po le cose. Una cosa è quando fai il tuo programmino o sitini internet. Un'altra è quando devi progettare una grossa applicazione alla quale trovi impegnati diversi team. Come esercizio potresti provare ad analizzare i codice dell'ultimo kernel linux. Vediamo se lo capisci al 90%. Ma che discorso! Tra l'altro un kernel è un *pessimo* esempio per un uso sensato di UML. Sono perfettamente convinto che se ti faccio vedere l'ottimizzatore di un compilatore non lo capisci nemmeno al 10%. E se te lo faccio vedere con qualche documentazione in UML continui a non capirlo. Ma non per un limite tuo: perchè (probabilmente) non hai li le tue skills. Tra l'altro avrei molta poca fiducia di un programmatore che non è in grado di comprendere il codice, a prescindere dal fatto che capisca UML. L'UML fa da linguaggio universale che chiunque può prendere capire e implementare. Ma via, non scherziamo. Un 'linguaggio universale'. Se non lo studi non lo capisci; e allora quale è il vantaggio? Che si presta ugualmente male a descrivere i vari linguaggi di programmazione? Lo si può usare *anche* come documentazione inserito all'interno di processi di sviluppo agili tipo XP programming e simili. Ma magari avrete da ridire anche su di questi... Che lo si possa inserire chi dice nulla. Sul fatto che sia davvero necessario ho dei seri dubbi. Sul fatto che sia parzialmente antitetico allo spirito stesso di XP sono invece piuttosto d'accordo. In particolare è *ovvio* che è integrabile in XP; come è ovvio che elementi di XP possono essere presi e innestati in altri processi di sviluppo. XP è *estremamente* flessibile. Questo non vuole dire che UML sia semplicemente un overkill. Per maggiori dettagli sull'UML: http://it.wikipedia.org/wiki/Unified_Modeling_Language Oh, grazie del link. Ma se si vuole consigliare qualcosa di buono, perchè non linkare il libro di Fowler? http://www.amazon.com/UML-Distilled-Standard-Addison-Wesley-Technology/dp/0321193687/ref=pd_bbs_sr_1?ie=UTF8s=booksqid=1202078809sr=1-1 Per quanto in completo e totale disaccordo, non è mae nemmeno questo: http://www.amazon.com/UML-Unified-Process-Object-Oriented-Addison-Wesley/dp/0321321278/ref=pd_bbs_sr_1?ie=UTF8s=booksqid=1202078755sr=8-1 Cosa vuole dire? Che sono abbastanza realisti, non sono degli invasati. E no, non mi hanno convinto che il loro metodo sia buono, ma almeno l'esposizione è lucida e ben fatta. Per l'elenco di aziende che si divertono a perdere tempo: http://www.omg.org/cgi-bin/apps/membersearch.pl (schiacciare search) Quindi aspetta... 1 mosche non possono sbagliare? ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
On Feb 3, 2008, at 10:32 PM, Domenico Chierico wrote: No no ma infatti sono d'accordo che probabilmente il diagramma delle classi e' la parte piu' inutile dell'uml ... secondo me soprattutto nelle universita l'uml e' spiegato e insegnato in modo insensato. Vediamo un po' sto UML... tutta la parte di UseCase (che per inciso è il pezzo più utile dell'ambaradan) è un'inutile formalizzazione di una cosa molto naturale. E' precisamente il pezzo in cui si vede quanto la descrizione testuale sia *molto* più importante del disegnino. A questo punto, seghi i disegnini, rendi il tutto più umano e meno formale invece che 'use- case' hai delle stories: più leggibili, comprensibili e comode. Ma diciamola... anche le macchine a stati mi è capitato di usarle. Ma tipicamente fuori dal formalismo dell'UML, quando e se ce ne è bisogno, senza irrigidirmi alla UP o peggio RUP. La parte di architettura di UML è aperta: ovvero in pratica ti devi reinventare il tutto tu. Il diagramma delle classi concordo: è inutile o quasi (se non a posteriori, come informazione aggiuntiva se ad uno proprio garba vedere le cose grafiche). Ma quindi di utile cosa ci sarebbe? be sicuramente e' poco applicabile oramai pero' per certi tipi di progetto la via vecchia e' sempre attuabile. Per i progetti che vanno fatti fallire, dai. Anche se vuoi stare in modalità ingessata, allora UP è venti volte migliore. Be in conclusione la cosa secondo me da chiarire e' che l'UML non e' un linguaggio pensato per la documentazione del codice, e' semplicemente una formalizzazione per la modellazione , ha senso solo e' soltato se e' generato prima (molto prima) di mettere le mani su una tastiera, e soprattuto non e' compito di un programmatore creare l'uml. Dovrebbe essere, sempre per come l'ho inteso io, un mezzo standard per far comunicare architetti e sviluppatori, analisti e architetti etc etc... Questa è in effetti la funzione classica che assume (e che ha nelle intenzioni dei suoi creatori). Il punto è che buona parte di noi qui sono assolutamente pro XP. Dal che segue che tutto sto rigidume 'eBiz' ci fa un po' onco. Io la vedo cosi' non uso molto UML ma quando e' servito e' stata una gran cosa... certo e' si potrebbe anche creare qualcosa di meglio, non e' che sia cosi' bello ... ma io conosco solo quello.. :) Non credo si possa creare qualcosa di strettamente migliore (ovvero, si può, ma potrebbe essere UML 3.0 o un'altra cosa ma poco importa). Il punto è proprio la presunzione dello strumento. Ci si è inventati un problema e si ha creato lo strumento quasi adatto per risolverlo. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
ba secondo me la questione non sta proprio in questi termini... per me uml e' solo una maniera formalizzata di fare i soliti disegnini al fine che chiunque se vuole studia e li capisce poi decidi tu cosa ti serve disegnare... e' un linguaggio per descrivere i risultati della fase di modellazione .. non e' uno strumento per modellare i problemi. Invece di fare lo use case con il quadrato hanno deciso che si usa il cerchio chiunque lo vede capisce .. tutto qua .. secondo me spesso si cerca di usare l'uml per cose per cui non ha senso. Ora che tu ti trovi meglio a scrivere per esteso o io a fare i pallini o un'altro fara' le crocette e' una questione di personale gusto ... Uml e' solo uno dei linguaggi per fare disegnini e schemini .. io solitamente lo uso sulla carta. that's all .. per me ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
Il giorno 04/feb/08, alle ore 00:02, Enrico Franchi ha scritto: On Feb 3, 2008, at 10:32 PM, Domenico Chierico wrote: No no ma infatti sono d'accordo che probabilmente il diagramma delle classi e' la parte piu' inutile dell'uml ... secondo me soprattutto nelle universita l'uml e' spiegato e insegnato in modo insensato. Vediamo un po' sto UML... tutta la parte di UseCase (che per inciso è il pezzo più utile dell'ambaradan) è un'inutile formalizzazione di una cosa molto naturale. E' precisamente il pezzo in cui si vede quanto la descrizione testuale sia *molto* più importante del disegnino. A questo punto, seghi i disegnini, rendi il tutto più umano e meno formale invece che 'use- case' hai delle stories: più leggibili, comprensibili e comode. E se chi le scrive ha il giusto senso dell'umorismo anche molto più simpatiche e di conseguenza leggere da leggere (doh!) CUT Ma quindi di utile cosa ci sarebbe? Il case da K$ dell'altro post forse? ;-) -- Antonio Valente ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
On Feb 3, 2008, at 9:38 PM, Crash Override wrote: Forse non avete ben chiari i vari ruoli dei membri che contribuiscono al successo di un progetto software. Avete mai sentito parlare di Architect, Designer? O conoscete solo il programmatore? Non ti senti arrogante ad uscirtene con una frase del genere? Se vi riferite esclusivamente a Python forse in parte potreste aver ragione... Dico forse perchè la mia conoscenza di Python non è molto approfondita (sicuramente si tratta di un linguaggio non difficilissimo). Ma quale è il punto? Stiamo in una ML di Python o sbaglio. Per inciso, se uso un linguaggio demenziale, potrebbe cambiare proprio tutto alla radice. Cambia la quantità di informazione semantica portata dal codice stesso, cambia l'utilità di determinati strumenti. Si cambia anche linguaggio, per inciso. Che so... quando lavoro in Prolog mi verrebbe da ridere a usare UML (poi a me Prolog non è che stia molto simpatico). Ma idem per Haskell (che invece mi sta molto simpatico), eh. Guarda caso UML è culo e camicia con Java. Insomma, perchè sbattermi con uno schema UML quando in un tempo comparabile ho un prototipo funzionante con una buona suite di test unitari e funzionali. E magari pure qualche pezzo dei test di integrazione. Quali sono i vostri titoli di studio? Che fate nella vita? Ma è meglio tralasciare... Dottore in Matematica e Informatica. Ma penso che possiamo tralasciare cose tristi come sbandierare curriculum, pubblicazioni, etc etc etc, sono d'accordo. Ed è un giochino in cui non mi faccio trascinare. Tra l'altro spiegami cosa dovrebbe avere a che fare il titolo di studio con la competenza in un discorso di questo tipo. In Università insegnano quasi nulla di quello che è necessario 'qua fuori'. Sulle cose *teoriche* sono *molto* forti. Idem sul formare determinate abilità di ragionamento e tutto. Sugli aspetti tecnologici spesso no: e giustamente, per inciso. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
Uml e' solo uno dei linguaggi per fare disegnini e schemini .. io solitamente lo uso sulla carta. Ma infatti vanno fatti su carta. Trovo che gli strumenti case siano scomodi, costosi e perdi tempo. Molto spesso il reverse engineering non funziona. Io alla fanzoppi lo faccio spesso, sperando di avere qualche lume sul progetto..ma è sempre difficile fare ispection con tali strumenti. Te nel tuo gruppo devi comunicare e questo lo puoi fare parlando, scrivendogli un trattato usare le CRC cards (ce un libro chiamato Object Thinking della MS Press, bellino su questo), oppure facendo dei diagrammi di sequenza. La modellazione del dominio la fai a priori: è il modo in cui pensi ad oggetti importante non lo strumento formale. Lo strumento formale come UML ti serve per scambiare informazioni e ricevere informazioni IMHO ed non necessariamente dovrebbe essere al pc. Personalmente cmq sono un fan dei diagrammi di sequenza. Cheers, Giorgio. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
On Feb 4, 2008, at 12:12 AM, Y3s wrote: E se chi le scrive ha il giusto senso dell'umorismo anche molto più simpatiche e di conseguenza leggere da leggere (doh!) Si, vero. :) Il case da K$ dell'altro post forse? ;-) Solo dopo averlo scritto. :P ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
On Feb 4, 2008 12:19 AM, Giorgio Zoppi [EMAIL PROTECTED] wrote: Personalmente cmq sono un fan dei diagrammi di sequenza. Cheers, Giorgio. si si i diagrammi di sequenza so un po pallosi da fare ma quando devi farti capire e' la via :) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
Ciao a tutti, butto i miei 2 centesimi In sintesi: concordo sull'inutilità di UML per lo sviluppo, soprattutto se usi un linguaggio come Python. Y3s ha scritto: Il giorno 03/feb/08, alle ore 21:38, Crash Override ha scritto: Enrico Franchi ha scritto: On Feb 3, 2008, at 8:30 PM, giuseppe saviano wrote: ho capito che la progettazione uml in alcuni casi risulta limitante; nella stessa serie di messaggi si parlava poi di list comprehension ... altri esempi? Non è che è limitante, è che tutt'ora devo trovare un caso in cui sia davvero utile. Anch'io vengo da una storia di UML imposto dal management in una grossa applicazione J2EE ... lasciamo stare, brutti ricordi Però, ultimamente, ho visto due applicazioni dell'UML - Dove lavoro ora chi scrive embedded lo utilizza con successo per documentare l'unione di Hw e Sw. Sembra che sia piuttosto utile allo scopo. (è una parte che non conosco bene, lo riferisco solo per dovere di notizia). - In una applicazione sviluppata congiuntamente da un team C++ ed uno Python abbiamo visto che 2 o 3 semplici diagrammi in UML, che congelavano le interfacce senza scendere in dettagli, evitavano una marea di discussioni. Non che fosse vitale dal punto di vista del design, o tecnico in generale, ma è stato utile: il team C++ non voleva vedere del codice pitonico e molti serpidi non capivano il C++. L'UML è stato un compromesso accettabile per entrambi. Forse non avete ben chiari i vari ruoli dei membri che contribuiscono al successo di un progetto software. Avete mai sentito parlare di Architect, Designer? O conoscete solo il programmatore? si, si, anche evangelista, analista, tester, coach, QA manager ... di ruoli ce n'è a volontà Qualche volta corrispondono ad un mestiere vero, altre sono solo fuffa IMHO il tutto è piuttosto lineare. Se un gruppo di persone vuole una cosa ed un gruppo di persone sa farla, questi devono comunicare nel linguaggio più efficente allo scopo. UML, Python, Italiano, Inglese, SQL, C++ ... non importa. Qui si parla di comunicazione tra le persone, non di comunicazione con la macchina. L'unico che comunica con la macchina è il programmatore mediante il codice. Nella mia esperienza UML non è il più efficente modo di comunicare con gli umani. Io preferisco l'italiano o l'inglese. A proposito dei ruoli: se sei nell'esercito, e il tuo sergente ti dice che il tenente ti comunica che il capitano ha ricevuto un ordine dal colonnello che il generale vuole che si avanzi di 100 metri ... sei sicuro che siano proprio le parole del generale? I ruoli gerarchici o sequenziali non aiutano certo la comunicazione. Allora quando costruiamo una casa esistono solo i muratori? E se un muratore costruisce bene le mura allora la casa può farla senza progetto? Da un po' di tempo si vocifera che il codice sia il progetto (non la casa) e che il muratore sia l'interprete (non il programmatore). La domanda forse sarebbe: Quali sono i vostri titoli di studio? Che fate nella vita? Ma è meglio tralasciare... Il titolo di studio ... stupendo, come se in questo campo fosse qualificante ... ma daii Scegli: Giro, vedo gente, scrivo codice Mi chiamo Taz, risolvo problemi, si, concordo, è meglio tralasciare :-) Roberto ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
