lunedì 10 novembre 2008
Facebook, blogs, web 2.0…
divertenti certo, magari per ruzzarci un po’, ma alla fine la mia vera unica grande passione per rimanere in contatto con le persone su internet è il vetusto NNTP, la mia agorà virtuale impossibile da abbandonare.
tutto il resto è noia.
Saluti.
mercoledì 3 settembre 2008
In LINQ esiste la possibilità di rendere piatta una gerarchia mediante l'utilizzo del costrutto Select Many, questo costrutto è particolarmente utile quando si vogliono selezionare Customers (entità padre) attuando un filtro sugli orders (entità figlio, ovvero un Customer è legato ad una collection di Orders e viceversa un Order è legato ad un solo Customer).
Ad esempio volendo filtrare tutti i Customer che hanno eseguito almeno un Order il cui totale è maggiore di 100 si può scrivere:
Select Many
1 IList<Customer> filteredCustomers =
2 from c in customers
3 from o in c.Orders
4 where o.Amount > 100
5 select c;
Ho scoperto che questo costrutto in Entity Framework tira dei brutti scherzi con il fetch eager dei riferimenti di una entità.
Per eseguire un fetche eager in EF si utilizza il metodo Include, quindi se vogliamo caricare un Customer e con un solo round trip sul DB anche tutti i suoi Orders possiamo scrivere come segue:
1 IList<Customer> allCustomers =
2 from c in context.Customers
3 .Include("Orders")
4 select c;
In questo caso ci ritroveremo ogni entità Customer con la lista degli Orders già caricata, e correttamente se si osserva la query SQL generata si potrà apprezzare una LEFT OUTER JOIN fra la tabella [CUSTOMERS] e la tabella [ORDERS] che serve per recuperare tutte le proprietà di ogni Order coinvolto.
Il problema nasce quando la Include viene utilizzata in un costrutto Select Many come quello proposto:
1 IList<Customer> filteredCustomers =
2 from c in context.Customers
3 .Include("Orders")
4 from o in c.Orders
5 where o.Amount > 100
6 select c;
7
Il risultato è ovviamente corretto, nel senso che vengono selezionati i Customer che hanno almeno un Order che soddisfa il filtro, ma il problema è che la Include non ha alcun effetto, ovvero i Customer non vedono inizializzata la propria lista di Orders. Osservando la query SQL effettivamente viene eseguita solo una INNER JOIN solo ed esclusivamente per legare i Customer agli Order su cui in effetti viene eseguito il filtro, ma non c'è traccia del caricamento dei dettagli degli ordini una volta individuati i Customer filtrati.
Per la cronaca osservando il Profiler di SQL Server nel primo caso EF lancia una semplice query T-SQL (un EventClass di tipo SQL), mentre nel secondo lancia una store procedure ExecuteSql (un EventClass di tipo RPC).
domenica 31 agosto 2008
Julie Lerman, che sta scrivendo un libro per O'Reilly circa Entity Frameowrk, piano piano si sta rendendo conto delle "stranezze" (chiamiamole così) in cui ci si imbatte utilizzando EF. Chiariamo una cosa, EF è un framework con cui si può lavorare, tanto che lo sto utilizzando per un progetto reale, ma è suscettibile di critica, soprattutto quando ci si rende conto che chi lo ha progettato è chiaro che non avesse in mente che cosa sia esattamente un ORM.
Per farla breve si è resa conto che probabilmente non sarebbe stata la cosa più furba del mondo esporre alla UI il concetto di EntityKey e EntityReference, di conseguenza è stata "costretta" (da EF ovviamente) a scrivere una tonnellata di codice ripetitivo per incapsulare nelle enitity stesse la gestione degli stessi (ed utilizzare il termine "sick" la dice lunga...).
Beata ignoranza! Nel senso di Persistence Ignorance, che ella scopre essere "tanto cara e tanto onesta" (cit.).
Mi lascia abbastanza scioccato il fatto che tratti l'argomento come una "issue" saltata fuori durante la stesura di codice d'esempio per il libro, come se avesse trovato un fungo velenoso durante una passeggiata nel bosco, quando un minimo di conoscenza della teoria di base degli ORM e appunto della Persistence Ignorance, gli avrebbe suggerito a priori che lo scenario che stava cercando di risolvere si sarebbe tramutato in un incubo (tanto che io ho deciso di non risolverlo, perchè context is king).
Due considerazioni a latere.
Pensiamoci tutti due volte quando siamo tentati di dire che i patterns e compagnia cantante sono solo teoremi dei massimi sistemi, che prima o poi ci troveremo a combattere contro codice di produzione "reale" in cui uno dei tanti vituperati pattern ci avrebbe salvato la vita se correttamente implementato (e quindi speriamo che il team di EF abbia capito la lezione, e che V2 sia in realtà la V1 di un prodotto che di uguale avrà solo il nome).
Rimango basito e dubbioso quando scopro che ci sono persone che di ORM e architetture che ne fanno uso (nella fattispecie basate su Domain Model) non ne sanno quasi nulla e che vengono scelte per scrivere libri inerenti: Julie lerman e David Sceppa, con due libri su EF in uscita (O'Reilly e Microsoft Press), ne sono un esempio lampante.
sabato 30 agosto 2008
Il fondatore di Castle Project e le amare riflessioni circa il nostro lavoro. Tutto il mondo è paese, non solo geograficamente, ma anche tecnologicamente.
Purtroppo.
venerdì 29 agosto 2008
Voglio solo segnalare che nella nuova preview di ASP.NET MVC gli extension methods generici di HtmlHelper sono stati spostati da System.Web.Mvc a Microsoft.Web.Mvc, nota che non compare nella release note.
Per chi può, eviti di andare di reflector come me...
venerdì 15 agosto 2008
Stamattina mi sono trovato di fronte ad una situazione che ultimamente affronto un po' troppo spesso, impiegando circa un'ora di letture fra blog e articoli. In particolare ho voluto affrontare (per l'ennesima volta) una questione "teorica" riguardo lo unit testing: l'utilizzo di un framework di mock.
Non voglio in questa sede dilungarmi sul fatto che esistano diversi tipi di oggetti simulati secondo la tradizionale definizione di Fowler (dummy, fake, stub, mock), bensì esprimere tutto il mio personale rammarico circa alcuni mie atteggiamenti da ingegnere riguardo lo sviluppo software.
In pratica mi sto rendendo conto che la mia produttività sta scemando nel tempo perchè a rischio perfezionismo. La mia forma mentis è quella dell'ingegneria, e fino a qualche mese fa non mi rendevo conto di quanto questa sia pervasiva nella mia vita professionale. Non che sia un male intendiamoci, però credo che ci debba essere anche un limite.
Il problema che comincio a intravedere è che tendo troppo spesso a ritrovarmi insoddisfatto di fronte ad alcune soluzioni implementative che realizzo, eccedendo nel refactoring o addirittura nella sovraingegnerizzazione progettuale.
L'esempio lampante di quanto sto dicendo lo sto vivendo proprio in questo ultimo periodo, lavorando su un progetto che fa uso dell'Entity Framework. Quest'ultimo soffre di errori di progettazione abbastanza evidenti a livello architetturale per essere un ORM, il suo lavoro lo fa per carità, ma a costo di alcune magagne fra cui l'ormai famigerata Persistence Ignorance per quanto riguarda le classi che fanno parte del Domain Model.
Ebbene, ho provato per diversi giorni ad analizzare da ogni punto di vista la questione cercando in tutti i modi di trovare una soluzione elegante che facesse il paio con alcune pratiche di buona implementazione architetturale che sto cercando di raggiungere, con risultati del tutto deludenti (insomma la cosa per come è fatto l'EF è impossibile, punto).
Ma quello che a prima vista poteva essere scambiato come il cercare di combattere contro un framework nato e pensato male, battaglia se vogliamo del tutto legittima, stamattina ho capito essere altro.
Nel mondo reale le soluzioni software devono essere rilasciate nei tempi e nei costi progettati, devono aderire a precisi requisiti (funzionali e non), fine del discorso.
Impiegare per l'ennesima volta un'ora del mio tempo per derimere un dubbio stucchevole circa la differenza di utilizzo fra mock e stub in uno unit test, non va in alcun modo in questa direzione.
Non voglio essere frainteso: non sto dicendo che non sia importante capire la differenza fra testare lo stato (con uno stub) o testare il comportamento/interazione (con un mock). Sto affermando che esiste una netta differenza fra me e Martin Fowler (maddai...), esattamente come esiste la differenza fra un premio nobel per la fisica ed un ingegnere che deve progettare e costruire un ponte strallato.
Detto in termini meno metaforici, non devo perdere di vista che l'obiettivo è quello di dotare la mia soluzione software di una suite di test robusta, ma che in nessun caso debba essere causa, di una inutile ricerca della perfezione semantico-semiotica circa l'arte teoretica dello unit testing.
Questo al momento è il maggiore limite che sto notando nella mia formazione unievrsitaria, che se da una parte mi ha dato la capacità di affrontare le questioni professionali con metodo, dall'altra, non mi ha affatto insegnato la differenza che c'è fra la teoria e la pratica, e questo per colpa della natura stessa dell'università italiana, che anche ad ingegneria difetta pesantemente di pragmatismo.
In definitiva sto facedo training autogeno, per combattere l'"ansia da prestazione" circa il confronto fra ciò che sto producendo e l'empireo degli archetipi dello sviluppo software.
martedì 12 agosto 2008
A quanto sembra (non si sa mai vista l'imperante ignoranza dei giornalisti nel campo della tecnologia...) Steve Jobs ha ammesso che negli iPhone esiste un meccanismo software che sarebbe in grado di disabilitare da remoto taluni programmi installati dagli utenti, se questi venissero in qualche modo considerati "malevoli" dalla Apple.
Nello stesso articolo che ho linkato, ed io mi associo alla considerazione, ci si domanda quale sarebbe stata la reazione dell'opinione pubblica se una cosa di questo tipo l'avesse fatta Microsoft con Windows Mobile...
Dopo aver rimosso quello che c'ere da rimuovere (principalmente la SP1 Beta) con l'apposito tool, l'installazione della SP1 definitiva ha impiegato circa un'ora, ma è andata liscia come l'olio.
Aperto il progetto su cui sto lavorando (che comprende ASP.NET MVC, Entity Framework e Silverlight 2) non ho avuto alcuna spiacevole sorpresa: build senza alcun problema.
Devo dire che questa SP1 è stata pensata, dal punto di vista del deploy, molto ma molto meglio rispetto a quella per Visual Studio 2005.
lunedì 11 agosto 2008
Per gli abbonati MSDN è disponibile la SP1 definitva di Visual Studio 2008, sono ben 893 MB...
Spero vivamente che l'installazione non sia la tragedia che fu quella della SP1 di Visual Studio 2005.
mercoledì 16 luglio 2008
Siccome mi hanno taggato in due devo propio rispondere...
A quale età hai cominciato a programmare?
Nel 1986, avevo 13 anni
Come hai cominciato a programmare?
Tutto è cominiciato con "Press play on tape" sul Commodore 64, mi sono domandato a che cosa servisse quella schermata blu con la riga di comando, poi ho comprato in edicola una rivista che aveva dei listati per il Commodore: li copiavo :-D
Qual’è stato il tuo primo linguaggio di programmazione?
Il Basic del Commodore, non so se avesse un nome specifico
Qual’è stato il primo programma vero che hai scritto?
Il primissimo non l'ho proprio "scritto", ho modoficato uno che avevo copiato, era un gioco di carte per il Commodore. Il primo da solo soletto è stato in prima superiore e stampava la serie di Fibonacci dato un numero, in Pascal 3 (nemmeno Turbo...)
Quali linguaggi hai usato da quando hai cominciato a programmare?
Il Basic del Commodore, Pascal (dalla 3 al Turbo 6), Algol, Ada, Fortran, Modula 2, Assembler, C, C++, C#, VBA, VB.NET (no Java non l'ho mai usato...)
Quando è stato il tuo primo vero lavoro da programmatore?
Ricercatore scientifico presso il Dipartimento di Idraulica del Politecnico di Milano, 2001
Con il senno di poi, rifaresti lo stesso il programmatore? Ricominceresti a programmare?
Le domande del tipo "lo rifaresti di nuovo" non mi sono mai piaciute. Al massimo posso dire che col senno di poi avrei cercato di commettere molti meno errori attitudinali nel fare il programmatore.
Se ci fosse una cosa che hai imparato nella tua carriera e che vorresti dire ai giovani programmatori, cosa diresti?
Fare il programmatore professionista è qualcosa che non ha nulla a che fare con qualsiasi cosa abbiate fatto prima con un editor di testo e un compilatore in maniera non remunerata.
Qual’è la cosa più divertente che hai programmato?
Sinceramente parlando non ho mai programmato nulla di "divertente", nel senso che ho sempre lasciato ad altri l'esplorazione del lato ludico del programmare, usufruendone ovviamente. In generale se si parla di divertimento personale, io spesso mi sono divertito, anche quando implemento un servizio WCF.
Siccome sono un toscano polemico e bastian contrario, e siccome non sopporto le catene di sant'antonio, non taggo proprio nessuno...
Saluti