aprile 2007 Entries

Krut Computer Recorder, scritto in Java, permette di generare un filmato in formato mov (QuickTime) catturando il contenuto dello schermo e la voce registrata dal microfono.

Utile per creare filmati di istruzione.

http://sourceforge.net/projects/krut

Non ho ancora avuto il tempo di comprendere a fondo la questione, però quando utilizzavo SaveOrUpdate per aggiornare un oggetto già oggetto dello stesso metodo un paio di volte, ottenevo l'eccezione indicata e il record nel db non veniva aggiornata con il Flush successivo. Usando invece SaveOrUpdateCopy, se l'oggetto è già presente nel contesto di persistenza, non viene generata l'eccezione ma viene aggiornato l'oggetto presente (ciò che io pensavo facesse SaveOrUpdate; a questo punto cosa fa SaveOrUpdate? E Update?)

L'eccezione si verificava durante il flush di una sessione in cui avevo salvato, con SaveOrUpdate, un nuovo oggetto ancora transiente; il problema era dovuto al fatto che avevo generato da codice il guid e quindi il metodo SaveOrUpdate pensava di aver a che fare con un oggetto esistente nel db!

Da classico programmatore Windows, ieri mi sono accorto di fare un errore ecclatante in una pagina ASP.Net:

la visualizzazione di alcuni controlli dipende dallo stato dell'applicazione (è una sorta di Wizard); sia sul page load che sul pulsante per avanzare richiamavo il metodo per visualizzare i controlli opportuni.

Pb: non ho considerato che l'evento page load avviene sempre (ad ogni aggiornamento della pagina) e prima dell'evento generato dal pulsante avanti, per cui l'azione che cambiava effettivamente lo stato, eseguita sul click del pulsante, avveniva dopo che il page load aveva gestito lo stato come se fosse ancora il precedente.

Soluzione: la gestione dello stato sul page load, in un caso come questo, deve essere fatta solo se non si tratta di PostBack; la gestione degli altri passaggi di stato sarà fatta solo sul pulsante, dopo aver modificato lo stato.

 

In questa categoria vorrei appuntarmi ciò che ogni giorno spero di scoprire relativamente al mondo .Net. Non pubblicherò sul muro questi post perchè da perfetto principiante molte scoperte saranno relative "all'acqua calda". L'obiettivo sarebbe di scoprire almeno una cosa al giorno; vedremo ...

Riprendendo uno degli argomenti del post precedente (quello “della ruspa”, per intenderci …), penso che un settore in cui l’approccio agile, inteso in un senso molto lato, possa dare un grosso contributo è quello della formazione.

Secondo quanto ho vissuto come studente prima e docente poi, i contenuti dei corsi sono sempre presentati in modo sequenziale, affrontando separatamente i vari argomenti, ognuno al livello di approfondimento richiesto dal corso.

 

Questo approccio non favorisce i collegamenti tra un argomento e l’altro, perché potrò collegare il primo e l’ultimo argomento solo a fine corso; i collegamenti, a mio avviso, non sono qualcosa di secondario ed è solo attraverso di essi che è possibile capire a fondo anche le entità oggetto del collegamento. Mi sembra uno dei soliti errori in cui la nostra forma mentale ci fa cadere: tendiamo a vedere qualsiasi sistema come indipendente da altri sistemi (nel senso di definito in sé), seppur ad essi relazionato. Secondo la mia esperienza sono invece portato a dire che ogni sistema è quello che è soprattutto per le relazioni che ha (potrei dire: “dimmi che relazioni hai e ti dirò chi sei”); perché allora cercare di capirlo senza curarsi di queste relazioni? E’ un po’ come esplorare una mappa osservandone vari punti al livello di dettaglio massimo senza mai allontanare la visuale; sfido a capirci qualcosa.

 

Un approccio agile invece, che affronti i vari argomenti in modo iterativo, consente di delineare in modo più preciso, iterazione dopo iterazione, le varie entità e le loro relazioni (se volete pensate ai nodi e agli archi di una rete). E’ come esplorare una mappa partendo dalla vista di alto livello e scendendo man mano ad un livello di dettaglio maggiore.

 

Leggendo il libro di Larman (Applying UML and Design Pattern) ho constatato con piacere che i capitoli centrali sono proprio approntati secondo questo approccio, approfondendo in modo iterativo i contenuti.

Io stesso, come docente, ho sperimentato la bontà dell’approccio: dopo aver tenuto corsi di Access che seguivano il percorso classico (struttura db in profondità prima, creazione interfaccia dopo), ho visto che sfruttando tre iterazioni (una prima passata introduttiva molto veloce, una seconda passata in cui vedere solo le relazioni uno-molti e giocare un po’ con l’interfaccia, e poi una terza passata in cui approfondire le temutissime relazioni molti-molti e il loro impatto sulla progettazione dell’interfaccia), i discenti hanno faticato molto meno ad assimilare i contenuti ed il corso è risultato più “divertente”.

 

Ciao a tutti e, per chi ci sarà, a domani (forza janky!).

Durante gli anni di studio all’università di ingegneria, spinto dall’esigenza di capire l’origine della mia difficoltà ad “entrare” velocemente in argomenti per me completamente nuovi (sono diplomato in ragioneria e il salto si è fatto sentire), mi ero accorto che il mio approccio allo studio era simile a quello di una ruspa che deve spostare un montone di terra in un’unica passata: finché il montone è piccolo tutto bene, ma quando è grande la ruspa procede con sempre più fatica e rischia di finire sotterrata dalla terra!

Un approccio molto più efficace è invece quello di una ruspa che suddivide il lavoro in più passate, spostando uno strato sottile per volta; si lascia guidare dal montone stesso seguendone il profilo e scavalcandolo avanti e indietro senza affondare troppo la pala.

Definirei questo approccio “agile” perché si basa sul concetto di iterazione, che ritengo fondamentale, e tende ad affrontare il problema senza “puntarsi” troppo.

Ritengo che l’agilità, finalmente abbastanza compresa da chi si occupa di software, dovrebbe essere applicata anche da chi fa formazione, perché affrontando un argomento in modo iterativo la fatica si riduce ed è molto più facile cogliere i collegamenti tra i diversi aspetti (io solitamente comprendevo “il senso” di un corso gli ultimi giorni prima di sostenere l’esame, quando avevo presente tutti i mattoni e finalmente “l’arco” che stavo costruendo stava in piedi; prima erano solo mattoni separati e dell’arco neanche l’ombra …). Inoltre cogliere il senso delle cose, oltre a rendere l’apprendimento più facile, ti da anche quella soddisfazione che ti da ancora più forza per affrontare le passate successive, instaurando così un circolo virtuoso che si autoalimenta. Cosa volere di più?