Origini dell'Agile Development

Sapevate che le tecniche di sviluppo agile si sono ispirate, almeno all’inizio, al sistema produttivo che Toyota aveva adottato già negli anni '50?

Io no, lo apprendo ora:

-          http://martinfowler.com/bliki/AgileVersusLean.html

-          http://it.wikipedia.org/wiki/Toyotismo

View 2008

Dal 11 al 14 novembre a Torino si terrà la nona edizione di View, la conferenza internazionale di computer grafica.

Hotmail non ama Chrome

Flickr Uploadr e Proxy

L'uploader ufficiale di Flickr è Flickr Uploadr.
Questo tool può smettere di funzionare quando lo si utilizza dietro ad un proxy.
In questo caso è necessario aprire il file <folder di installazione di Flickr>\defaults\preferences\prefs.js ed aggiungere le seguenti linee di codice
:

pref( 'network.proxy.http', 'your.proxy.org' );
pref( 'network.proxy.http_port'port );
pref( 'network.proxy.type', 1 );


Ovviamente il tutto a tool non avviato. Al suo riavvio, l'uploader dovrebbe funzionare correttamente.

Error Reporting in Windows XP/2003

Windows XP/2003 hanno la prerogativa di poter visualizzare una finestra riassuntiva degli errori che si sono verificati durante un determinato periodo. Questo articolo contiene una breve guida su come gestirne la configurazione.

A volte anche i Guru sbarellano (IMHO)

Mi trovo in leggero disaccordo con quanto espresso da Joel Spolsky nel suo post Don't hide or disable menu items.

Secondo me non è corretto lasciare tutti i comandi abilitati, in alcuni casi si rischia davvero di sovraffolare la GUI.
Sì, indicare all'utente il motivo dell'impossibilità di portare a termine un'operazione può essere un modo per rendere il software accattivante ma alla lunga rischia di stufare gli utenti esperti.

Si potrebbe rendere configurabile un simile comportamento, una modalità novice che preveda i messaggi ed una expert che nasconda/disattivi i comandi non permessi.
In generale, se dovessi visualizzare un messaggio di spiegazione non userei una Message Box: significa un click in più. Al massimo opterei per un tooltip o cose di questo tipo.

Shader X2...free

Il sito GameDev.Net mette a disposizione gratuitamente i PDF dei due libri Shader X2:
- Introductions and Tutorials with DirectX 9.0
- Shader Programming Tips and Tricks with DirectX 9.0

trueSpace is free

Dopo l'acquisizione in febbraio di Caligari da parte di Microsoft, è possibile scaricare gratuitamente il suo prodotto di punta trueSpace, compresi manuali e video-corsi.

WF e Workflow Simultanei

Le seguenti osservazioni sono valide per WF 3.0, non ho ancora fatto prove sul 3.5.

Una notizia interessante riportata da MSDN a proposito della proprietà MaxSimultaneousWorkflows della classe DefaultWorkflowSchedulerService è la sequente:
"The default value for this method is 5 for a single-processor machine, and (int)(5 * Environment.ProcessorCount * .8) for a multiple-processor machine...".
Questo significa che, se non diversamente specificato, il WF Runtime è in grado di eseguire 5 workflow concorrenti su una macchina mono-processore, che diventano 8 con un processore Hyper-Threading.

Cosa fare se si vuole scavalcare questo limite e non si può/vuole aumentare il numero di processori?
La proprietà MaxSimultaneousWorkflows è read-only, quindi si deve agire al momento della configurazione dei servizi, in uno dei due seguenti modi:

  • creare esplicitamente l'istanza di DefaultWorkflowSchedulerService utilizzando il costruttore che riceve il numero massimo di workfllow simultanei, ed iniettare successivamente il servizio nel WF Runtime. Qui c'è un esempio di come fare;
  • configurare il servizio attraverso l'app.config del processo che ospita il runtime. Qui c'è l'esempio.

Attenzione però: il servizio DefaultWorkflowSchedulerService richiede i thread al thread pool di .NET. Quest'ultimo, se pesantemente sollecitato, può andare incontro a fenomeni di starvation capaci di compromettere il funzionamento dell'applicazione.
In casi del genere, fornendo un proprio servizio derivato da WorkflowSchedulerService, si può tentare di applicare una strategia di threading fatta su misura per il problema specifico.

WF e Serializzazione

Una classe normalmente contiene uno o più campi i cui valori determinano lo stato delle sue istanze.
Nel caso in cui la classe in esame fosse una WF Activity occorre fare un po' d'attenzione.

Infatti, durante la vita di una WF Instance può capitare che si debba salvarne lo stato per poterlo recuperare in un secondo momento, anche molto avanti nel tempo e magari su una macchina diversa da quella su cui l'istanza era in esecuzione. Questa operazione, che prende il nome di Passivation, prevede che l'intero WF e le Activity che lo compongono siano serializzabili.

Un'Activity è serializzabile se i suoi campi lo sono, pena il verificarsi di comportamenti poco chiari.
Ad esempio, l'inizializzazione di un'ipotetico campo di tipo MyClass così definito:

public sealed class MyClass { }

all'interno di un'Activity del tipo:

public sealed class MyActivity : Activity
{
    MyClass myClass;
    
    
//...
}

è sufficiente a causare la mancata esecuzione dell'Activity stessa. Infatti, basta inizializzare il campo myClass come segue:

protected override void Initialize(IServiceProvider provider)
{
    
base.Initialize(provider);
    
this.myClass = new MyClass();
}

per fare in modo che il metodo Execute non venga chiamato e saltando invece al metodo Uninitialize.

I rimedi sono due:

  1. rendere serializzabile il tipo MyClass;
  2. se il campo myClass può essere ricostruito al termine della de-serializzazione dell'Activity, lo si può rendere non-serializzabile attraverso l'attributo NonSerialized;
  3. si trasforma il campo myClass in una variabile locale del metodo Execute, istanziandola quindi ad ogni esecuzione dell'Activity; tale pratica prevede che le istanze di MyClass siano veloci da creare, altrimenti si deve ripiegare sui rimedi precedenti.