settembre 2006 Blog Posts
E' stato rilasciato dal team di ADO.NET una CTP di ADO.NET vNext Entity Data Model Designer Prototype, scaricabile qui (un nome più corto no eh?). Il designer è ancora a livello di prorotipo...in pratica hanno ancora tutto il tempo per copiare il codice da NHibernate :-)Scherzi a parte, il workshop sarà una buona occasione per discuterne...
...e anche un po storditi...si sono messi a pedinare De Sanctis...e hanno pure sbagliato persona....infatti hanno pedinato il nostro De Sanctis...adesso capisco perchè il report dell'agenzia a Moratti diceva..."zero su tutta la linea". :-)
Invece l'altro De Sanctis (che farebbe sempre meglio a starsene zitto) avrà fatto il pienone.Almeno adesso si sa in che mani erano le intercettazioni. Ma il "Grillo parlante" lo diceva già da un pezzo.
Devo dire che Scott è uno dei miei blogger preferiti, e ci ha regalato una perla (un po lunghetta a dire la verità) ma che vale la pena di essere letta. Qui l'articolo in integrale ("Pathfinder", rather than "Architect") che nasce a sua volta come commento ad un altro post di Sam Gentile (Being an agile architect). Si parla di quale sia il ruolo e le differenze tra gli sviluppatori/architetti in team tradizionali rispetto a team agili. Ma voglio commentare alcune parti per chi non lo volesse leggere tutto. "Everyone is a Designer - and if they're not, they better become one.[...]There is a basic assumption on...
Moto più importante (:-)) della notizia delle stored proc in NHibernate postata dal Crad ;-), è quella della possibilità di operazioni in batch verso il database, in questo caso per adesso solo SQL. Di Ayende come al solito...qui tutti i risultati. Passando ad un discorso più generico...molti si chiedono se usare un ORM fa rallentare le prestazioni, le migliora....giustissime osservazioni per carità. Mi fa un po sorridere però, il fatto che un sacco di gente "spara" supposizioni prestazionali anche senza aver mai usato un ORM...:-)Giusto che un PM di un progetto chieda: "Ci saranno problemi prestazionali usando l'ORM VattelaAPesca ?"Assurdo che un PM di...
Eccola qui... Se qualcuno non sapesse chi sia...Dietro la lavagna!:-)
ate queste 5 gemme (soprattutto per l'ultima)...Il risultato a più alto impatto nel vostro codice sarà: Oggetti di dominio che non avranno più responsabilità specifiche di visualizzazione, binding, persistenza, e varie attività funzionali.Il loro compito sarà maggiormente concentrato nell'esprimere (nel codice) i concetti del modello analitico. Vediamo come si può mantenere poco inquinata una Entity del Dominio, delegando a chi di dovere...le proprie responsabilità.(Ho messo tra parentesi dei framework di esempio, ovviamente che ci possono essere d'aiuto, la cui scelta è puramente tecnlogica, ma dal punto di vista architetturale...l'importante è rispettare la delega) Responsabilità di Persistenza: Delegate nel Layer Infrastrutturale di storage (posso usare NHibernate). Responsabilità di Configurazione, Assemblaggio e Wiring:Delegate...
on essendo presente nella Domain Driven Design un vero e proprio manifesto o dei comandamenti, ho fatto in modo che da un estratto della mia bibbia...se ne potessero tirare fuori alcuni. Sono generici e saranno completati poi da modalità più specifiche di design, ma devo dire che già espressi in questa forma fanno il loro effetto: Partizionare le applicazioni in Layer. Il design dei layer deve garantire la loro coesione. I Layer dovrebbero dipendere solo da layer sottostanti. Usare pattern architetturali per garantire un basso accoppiamento di un layer con un altro. Concentrare tutto il codice che riguarda il...
Quest'articolo su un Branch & Merge (un ramo importantissimo della SCM) è assolutamente introduttivo e piuttosto didascalico, ma è una base per chiunque non sia mai stato abituato a pensare che una freeze di rottura della linea evolutiva sia un bene e non un male.E' Scritto da Chris Birmele. Oggi ho cercato di spiegarlo giusto ad una quindicina di persone, tra sviluppatori e referenti di progetto...:-)Ammetto che i suoi disegnini sono un po più belli dei miei! Leggo prima l'articolo, becco subito dopo il suo blog (che in verità avevo sottoscritto ma si era perso chissàddove) e becco un altro bel post...
Il odel Driven Design, pretenderebbe di poter generare il codice partendo dall'UML. Ed è li che il fallimento ci aspetta dietro l'angolo.Fare una generazione di codice da UML e poi continuare a mantenere il codice allineato al modello è un lavoro pesante e difficilmente automatizzabile. Teniamo a mente anche che: I diagrammi rappresentano una vista del modello analitico. Ma non sono il modello analitico. Per dirla con un detto zen...se qualcuno vi indica la luna con il dito...non confondete il dito con la luna. E' invece il codice di un progetto (e volendo astrarre, anche il design) che riesce a catturare...
ncora qualche premessa. E' proprio vero. Provate a fare una riunione per discutere del vostro dominio attorno ad un tavolo, tra developer, esperti di dominio, architetti e chi volete voi, e vedrete che ognuno andrà per la propria strada. Farà le proprie supposizioni e i propri voli pindarici. Provate a schizzare un grafico alla lavagna con sole 5 classi in UML e fare la stessa riunione con le stesse persone e vi accorgerete della differenza. Quella sola presenza al centro del tavolo riesce a far tenere l'attenzione sul modello analitico (di cui è una mera rappresentazione), e pone le basi per...
Gli sperti di dominio (i clienti) conoscono i termini del loro campo di conoscenza, ma non conoscono i termini propri dello sviluppo software. Concordemente gli sviluppatori che utilizzano termini di propri di sviluppo, possono descrivere bene un sistema in termini funzionali ma privo di significato per un esperto di dominio. Nella Domain Driven Design l'uso di un linguaggio comune tra gli sviluppatori, architetti, analisti ed esperti di dominio è essenziale alla riuscita del progetto. Il mancato uso di un linguaggio comune rischia di confondere il visione del modello analitico, e della sua implementazione. Peggio ancora può indirizzare verso un refactoring sbagliato. E' errato...
li analisti finanziari hanno a che fare numeri.
Gli avvocati hanno a che fare con le leggi.
I Domain Modelers hanno a che fare con la conoscenza. Non fanno altro che acquisire conoscenza dagli Esperti di Dominio (i clienti) e distillare questa conoscenza in modo da selezionare la parte rilevante ai fini dell'effettiva soluzione del problema di business.
n mindset (una forma-mentis), cioè una serie di principi e priorità, atte ad accelerare la progettazione software che ha a che fare con domini di particolare complessità.
Le premesse fondamentali sono:
La maggior parte dei progetti, dovrebbe basarsi su un Dominio, e su una Logica di Dominio.
La progettazione di Domini complessi dovrebbe basarsi su un modello analitico.
Bisogna tener presente che:
Il modello analitico (cioè il risultato del lavoro degli analisti) è uno strumento di sola comprensione.
Un analista poi può usare UML per la visualizzazione del modello stesso.
Il modello non porterà nessun dettaglio implementativo ai fini di non inquinare la comprensione.
L'implementazione di un modello molte...
Ero stanco della pesantezza di RssBandit. Seguo quasi 300 blogs. Mi impestava la macchina.Ho installato FeedDemon. Occupa tremendamente di meno, ed è sensazionalmente più veloce.
Tiene una base di sincronizzazione tramite NewsGator, posso leggere da pc diversi ed avere tutto in sync,
oppure anche solo da browser (sempre via newsgator) o da palmare, leggere in assenza dell'aggregator sul sito e tenere sempre aggiornata la base dati, aggiungere feed o rimuovere.ahh...anche da Media Center...20 dollarini o poco più...