Posts
83
Comments
165
Trackbacks
11
January 2007 Blog Posts
WebCast per tutti...Developer & Aspire Architect

Come già riportato da Roberto (qui) sottolineo nuovamente il fatto che il WebCast della serie "Aspire Architect" tenuto da Janky (complimenti!!!) è veramente fondamentale per tutti...giusto per farvi venire l'acquolina in bocca  e sperando di non violare nessuna legge sul copyright  vi elenco i temi toccati in questa ora e mezza...

  • Class VS Struct
  • Property VS Method
  • Constructor(s)
  • Namespace
  • Design for extensibility
    • Unsealed class
    • Abstract class VS Interface
  • Exception design
  • Design pattern e soluzioni idiomatiche
  • Usage guideline for .NET Framework
    • Collection
    • IClonable
    • Equals

Janky esprime con energia () le guidelines principali e i concetti basilari indispensabili per sfruttare al meglio le potenzialità del framework .Net nei nostri progetti, mettendo in evidenza quelle sfumature (come nel caso del confronto tra le classi astratte e le interfacce...veramente illuminante!!!) che possono fare la differenza, trasformando una buona soluzione in un'ottima soluzione.  
Vi posso assicurare che è un'ora e mezza assolutamente ben spesa...insomma per seguire il pattern () di questo post di Lorenzo...è assolutamente un MUST!!!

"...sovvertiamo le gerarchie..."
powered by IMHO 1.3

posted @ Sunday, January 7, 2007 10:17 AM | Feedback (1)
Five Things You Didn't Know About Me

Taggato da Matteo ecco, anche se un po' a scoppio ritardato , le cinque cose che (forse) non sapete di me...

  1. Io sono di Collebeato, uno splendido e tranquillo paesino della provincia di Brescia, ho sposato Manuela, nata a Giussano in provincia di Milano, nella chiesa di Provaglio d'Iseo...ed ora abito a Castel Mella 
  2. ...mi sono sposato il 12 Settembre 2004...
  3. Il mio primo approccio con il mondo dell'informatica è avvenuto al tempo della scuola media (...che bei tempi...) durante un corso pomeridiano: 8 persone che si alternavano su tre () pc...il programma, di cui non ricordo il nome, permetteva di disegnare a video linee monocromatiche per la composizione di poligoni o forme geometriche più complesse.
  4. Il mio primo vero programma risale al tempo del corso di Informatica 1 all'università, nel quale bisognava gestire uno stabilimento balneare e tutte le attività ad esso collegate...ovviamente il linguaggio era il mitico Pascal.
  5. Tifosissimo della Fortitudo Bologna, ho assistito all'ultima partita della finale scudetto 1996 con Milano, nella curva dell'allora Stefanel ...ma la notizia è che, dopo una sonora sconfitta dello squadrone capitanato da Carlton Myers e il conseguente scudetto assegnato a Milano, mi sono "pippato" il viaggio di ritorno sul pullman dei sostenitori urlanti della Stefanel ...

E adesso scateno la mia "ira" e taggo...Davide Mauri, Luca Minudel, Claudio Maccari, Tiziana Loporchio e Riccardo Golia

...sovvertiamo le gerarchie...
powered by IMHO 1.3
posted @ Friday, January 5, 2007 9:57 AM | Feedback (0)
TDD e lo sviluppo per approssimazioni successive...feedback

In relazione al mio post precedente, ho deciso di rispondere con un nuovo post (per motivi di visibilità e di spazio) ai feedback veramente interessanti di Davide, Antonio, Claudio e Luca.

@Davide
Post molto interessante! Visto che hai notato anche tu un corrispettivo matematico dell'approcio Agile (approcio che si ritrova esattamente indentico -  come principio di base - nella modellazione dei db attraverso la Normalizzazione) ti rimando ad un mio post di qualche tempo fa: http://blogs.ugidotnet.org/nettools/archive/2006/12/20/60861.aspx
sono curioso di sapere che ne pensi.

Innanzitutto ti ringrazio per i complimenti...ricambio, per l'ottimo lavoro che stai portando avanti con Ugiss, veramente molto utile!!!
Ho letto il tuo post, ma sinceramente non credo sia così semplice  e forse nemmeno possibile  definire univocamente un metodo matematico che possa dimostrare la maggiore funzionalità di uno sviluppo agile rispetto ad un approccio, diciamo così, classico.
Nel campo agile ho ancora poca esperienza e quindi sono poco attendibile, ma per quel poco che ho potuto vedere e toccare con mano, in relazione al tuo post, posso solamente dire, per rimanere in ambito pseudo-matematico , che la buona riuscita di un progetto che si basa sulle metodologie agili, necessita, ancor più (IMHO) di un progetto che si basa sulla metodologia "tradizionale", di condizioni al contorno (leggi competenza, esperienza...) molto forti. La variabilità di queste condizioni al contorno e la loro non facile definizione sono quei parametri aleatori che, secondo me, non permettono di identificare quel formalismo che "stai" cercando...
Purtroppo , almeno per ora, credo che per dimostrare i benefici di un approccio agile, il modo migliore sia quello di portare ad esempio casi reali di progetti "ben riusciti"...cosa che per altro gran parte di noi sta già facendo!!!

@Antonio
Mi piace l'idea delle approssimazioni successive, anche se, mentre in matematica c'è un unica soluzione nel design sono numerose e non è così immediato capire quale sia la migliore.
L'esperienza di diversi anni di programmazione senza TDD può essere sia uno svantaggio che un vantaggio, lo svantaggio è nella fatica di entrare nell'ottica di essere guidato dai test nel design dell'applicazione, in quanto pensi di conoscere già qual'è la soluzione migliore; il vantaggio è quello di possedere un bagaglio di conoscenze che ti permettono di non commettere le ingenuità di un principiante.
Io ormai non riuscirei più a farne a meno del TDD e vedere un'applicazione senza test mi dà la stessa impressione di girare in macchina senza cinture e cioè di correre un rischio inutile, ma è un discorso personale e non è detto che se vale per me valga per tutti.
Concludo incoraggiandoti nell'apprendimento del TDD vedrai che ti porterà molti frutti.

Condivido buona parte del tuo feedback...il fatto che nel design ci siano più soluzioni "ottime", è uno dei presupposti per i quali ritengo che una forte dose di esperienza porti ad una più celere e corretta individuazione/definizione della soluzione cercata. Prendendo come assodato il concetto che, anche definendo come punto di partenza un design lontano da quello ottimale si converge comunque verso la soluzione ottima (attenzione!!! ho scritto si converge e non si ottiene), la possibilità di individuare, già a priori, un buon punto di partenza, abbatte il numero di "sessioni" di refactoring e quindi incrementa la produttività.
Ti ringrazio per l'incoraggiamento e lo estendo a tutti...TDD ti cambia la vita, provatela!!!

@Claudio
"per rendere veramente agile lo sviluppo di un'applicazione tramite TDD deve esserci una considerevole dose di esperienza"
IMHO il TDD è un ottimo modo per conoscere/capire/digerire il paradigma OO

Assolutamente sì...l'iteratività dell'approccio agile, o meglio del TDD, permette di stabilire a che livello di granularità la nostra applicazione si spinge nell'utilizzo del paradigma OO, dell'utilizzo dei pattern e così via. Spostare sempre un po' più in là il livello di granularità (non oltre un certo limite, ovviamente) permette di approfondire e sviscerare il paradigma OO in tutti i suoi aspetti.

@Luca
"E' l'esperienza che ci permette di partire da un punto già "prossimo" alla soluzione ottimale"
Su questo non concordo: il punto è l'esperienza che accumuli durante il primo tentativo e le nuove info che nel frattempo diventano disponibili.
Quindi direi piuttosto "sbagliando si impara". Se poi aggiungi che il bersaglio è per sua natura mobile (l'80% di vita di un software consiste in evoluzioni e mutamenti) la "soluzione ottimale" cessa di esistere.

Per evitare equivoci, forse è meglio fare una distinzione tra esperienza generale ed esperienza specifica. Cosa voglio dire?
E' molto semplice...con esperienza generale (che è quella a cui faccio riferimento nel mio post precedente) intendo proprio la conoscenza e l'assimilazione che ognuno di noi ha del paradigma OO. Una buona conoscenza/esperienza dei design pattern, per esempio, ci permette di individuare a priori i casi in cui è necassario utilizzare uno State piuttosto che un Abstract Factory o piuttosto che nello specifico non è necessario nessun pattern, evitandoci inutili complicazioni.
L'esperienza specifica invece è quella relativa al caso in esame e comprende la conoscenza dell'ambito applicativo nel quale ci si sta muovendo. E' questo genere di esperienza che, nelle approssimazioni successive dovute al refactoring, cresce e si definisce insieme all'architettura dell'applicazione.
Condivido per altro, che il bersaglio è per sua natura mobile, ma non che la soluzione ottimale cessa di esistere...al massimo si sposta!!!

Un ringraziamento a tutti, comunque, per avermi dato la possibilità di riflettere ulteriormente su questo argomento!!!
Ciao a tutti

...sovvertiamo le gerarchie...
powered by IMHO 1.3
posted @ Thursday, January 4, 2007 10:10 AM | Feedback (0)
TDD e lo sviluppo per approssimazioni successive

Non molto tempo fa, discutendo con Emanuele di alcune problematiche relative ad un progetto che stavo (e che sto tutt'ora) seguendo e alle possibili soluzioni da adottare, a fronte di alcune mie "pippe mentali" (come da lui stesso definite ), mi sospinse/indirizzò verso TDD...
Un rapido giro per la rete alla ricerca di alcune superficiali informazioni, giusto per inquadrare l'argomento e capire come e quando poterlo utilizzare nello sviluppo delle mie applicazioni e...boom!!! Ormai la mia mente si era/è messa in moto in modo da assimilare il più in fretta possibile queste nuove nozioni per comprenderne l'essenza e rendere tanta buona teoria molto produttiva. Devo essere sincero, all'inizio mi sembrava di avere a che fare con una di quelle "solite teorie"...molto teoriche  e poco pratiche, ma vi posso assicurare che con il passare dei giorni nella mia testa andava radicandosi la forte convinzione di aver "trovato" uno strumento/metodologia che poteva rendere più produttiva la mia fase di sviluppo.
Parallelamente a queste convinzioni mi sembrava di scorgere un'analogia lontana con qualcosa di conosciuto, ma non mi era ancora chiaro cos'era...solamente in questi giorni di ferie , nei quali ho potuto soffermarmi più approfonditamente su alcuni aspetti, mi sono accorto che TDD altro non è (non solo a dir la verità...) che la trasposizione nel mondo dello sviluppo software del metodo delle approssimazioni successive (utilizzato/adattato in vari ambiti tra cui la matematica, l'elettronica...).
Se non ricordo male , la soluzione di molti sistemi non lineari fonda le sue "fondamenta" su questo metodo interattivo per la ricerca della "soluzione ottima": partendo da un punto, a seguito (appunto) di approssimazioni successive, ci si avvicina sempre più alla soluzione che, nel contesto in esame, può essere ritenuta ottima.
TDD non "fa altro" che a fronte di una serie più o meno lunga di "sessioni di refactoring" far convergere la nostra applicazione verso una soluzione che si può ritenere ottimale. Starò sicuramente scoprendo l'acqua calda , ma vi posso assicurare che questa illuminazione è stata veramente...illuminante  e ha dato origine ad una serie di mie personali considerazioni inerenti ad un argomento a me/noi tanto caro: lo sviluppo di buone applicazioni... !!! Molte volte, ricercando questa soluzione ottima a priori, mi dilungavo su aspetti/tematiche che ritenevo indispensabili per rendere l'applicazione più flessibile, più robusta...abbassando a monte la mia produttività e allungando i tempi di sviluppo!
TDD, come più volte ho sentito dire nell'ambito delle metodologie agili, fa invece "emergere l'architettura" dell'applicazione a poco a poco...ma qui sta il punto focale: per rendere veramente agile lo sviluppo di un'applicazione tramite TDD deve esserci una considerevole dose di esperienza, è proprio questo, secondo me (e aggiungerei...come al solito ) l'ago della bilancia. E' l'esperienza che ci permette di partire da un punto già "prossimo" alla soluzione ottimale, riducendo il numero di "approssimazioni" (leggi sessioni di refactoring) da eseguire ed è sempre l'esperienza che ci deve far capire dove fermare la ricerca della soluzione ottima...

E con questo? direte voi ...
Bhe non ci deve essere un perchè per tutto, no?...

...sovvertiamo le gerarchie...
powered by IMHO 1.3
posted @ Tuesday, January 2, 2007 3:22 PM | Feedback (5)