[ topics . it ]

Outlook to the max

Mauro Servienti — Fri, 06 Nov 2009 14:00:00 GMT

Fino ad un paio di anni fa avevo l’abitudine di categorizzare le mail utilizzando una pletora di subfolder della Inbox, il problema è che spesso questo le rende introvabili :-) perchè a distanza di tempo quando vi chiedete “dove ho messo quella roba” giustamente non vi ricordate più l’associazione mentale fatta al tempo e tipicamente passate un buon quarto d’ora a scartabellare tra le folder… oppure semplicemente avrebbe senso mettere la stessa mail in più subfolder.

Ho regalato troppi “quarto d’ora” :-)

Due anni fa circa, in una mattina a Barcellona, ero seduto di fianco a Davide Vernole e facendo il curioso noto che non ha subfolder ma ha semplicemente tutto spiattellato nella Inbox e mi spiega che usa le categorie per taggare la mail… figo :-)

…l’inghippo purtroppo è che chi ha pensato le categorie evidentemente non le ha mai usate perchè per taggare una singola mail perdete ben più di un quarto d’ora… :-/

Rules rulez

Ma anche qui piegare lo strumento è abbastanza facile:

Mi sono fatto una pletora di regole che fanno il 90% del lavoro, se non di più, lasciando a me l’onere di rifinirlo ove necessario. Queste regole fanno si che all’arrivo ogni mail venga automaticamente taggata:

Il fatto che le regole siano client only è un non problema perchè Outlook le applica anche ai messaggi già letti, quindi se segno come già letto un messaggio da OWA o dal Device quando arriva in Outlook viene comunque processato e categorizzato.

Cerca che ti passa…

Ma poi come sfruttiamo questo tagging? Semplicemente si può cercare per categoria, ma la cosa che adoro sono le Search Folder che con un piccolo trick diventano veramente fantastiche:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\QueryBuilder]

(Funziona su tutte le versioni di Outlook, basta sostituire a 14.0 il vostro numero di versione)

Se provate a creare quella chiave di registro, senza metterci nulla basta che esista, e poi provate ad editare/creare una Search Folder… tada!:

Avete un potente sistema di filtro a vostra disposizione per fare query anche molto articolate.

Dimenticavo: prestazionalmente non cambia nulla avere tutto nella Inbox:

Questa è la dimenisione della mia Inbox attuale con i messaggi dall’inzio dell’anno, la ListView dei messaggi è virtualizzata quindi…

[OT] Pensieri sparsi… “reloaded”

Mauro Servienti — Thu, 05 Nov 2009 20:21:08 GMT

Sono a Torino e tipicamente quando sono in albergo mi capita di guardare la televisione, a casa non c’è.

Qui c’è già stato lo switch-over: il digitale terrestre fa pietà, non tanto per i contenuti che facevano pietà prima e adesso sono solo aumentati, quindi peggio su peggio :-) ma piuttosto fa tecnologicamente pietà, mi metto nei panni di un utente, non tecnico, che prima aveva un televisore e adesso ha un televisore + un “coso” con a bordo del software che è fatto tipicamente con i piedi, il decoder che ho qui in albergo è pressochè inutilizzabile… crasha: cribbio ma come è possibile che un televisore (perchè quello è il percepito) crashi… è come se crashasse il frigorifero;
Per ora ho cumulato circa 1h di “visione” e:

L’abitudine che in molti hanno di parlare addosso agli altri per zittirli è veramente odiosa;
non ho trovato nulla che richiedesse un QI superiore a –1;
Guardando un telegiornale capisci molte cose, ma proprio tante;
La trasmissione di Papi, su Italia 1, è decisamente inutile, se la levassero e facessero mezz’ora di fermo immagine saremmo tutti molti più felici ;-);

La fretta è sempre una cattiva consigliera, vedi punto 1, e, prima o poi, ti si ritorcerà contro;
Il sarcasmo gratuito e mal celato è un’altra cosa che mi da molto fastidio;
La formazione è alla base del successo tanto quanto l’ignoranza della controparte (vedi sempre punto 1);

Componente != Servizio

Mauro Servienti — Thu, 05 Nov 2009 10:00:00 GMT

Stavo leggendo una interessante serie di post sull’integrazione tra Castle e WCF, illuminante e istruttiva per molti versi ma sinceramente faccio molta fatica a digerire questo mascheramento.

Credo che in generale ci sia un problema di fondo nella teminologia usata: quando si parla di IoC si usa indifferentemente componente o servizio. L’errore secondo me sta nell’utilizzare poi indifferentemente servizio quando questo viene inteso come componente e quando questo invece viene inteso come servizio nel senso SOA del temine, portando alla convinzione che siano concettualmente utilizzabili allo stesso modo.

Secondo me non c’è nulla di più sbagliato, ho la ferma convinzione che il codice debba esplicitare, e non nascondere, che si sta utilizzando un servizio nel senso SOA del temine perchè l’approccio da utilizzare e le problematiche da gestire e prendere in considerazione sono abissalmente diverse.

Secondo me è un grave errore pensare che la differenza tra n-layer e n-tier stia solo nel fatto che il boundary è diverso. Non è possibile pensare di scrivere uin’applicazione n-layer e migrarla a n-tier piazzando un po’ qua e un po’ la Wcf e una facility per Castle.

Pensate a questo scenario:

using( var dc = this.dataContextFactory.Create() )
{
    using( var tx = dc.BegingTransaction( IsolationLevel.Serializable ) )
    {
        dc.Insert( entity );
        dc.FlushChanges();

        tx.Commit();
    }
}

IDataContextFactory è un wrapper per la session factory di NHibernate, nulla di trascendentale, il codice esplicita molto bene quello che succede. La IDataContextFactory viene iniettata con Castle Windsor. Adesso immaginamo che:

Qualcuno scrive una nuova implementazione di IDataContextFactory e IDataContext che utilizzano Wcf;
Qualcuno modifica il file di configurazione di Castle per utilizzare la nuova implementazione e la WcfFacility;
Qualcuno configura Wcf per utilizzare Message Queue;

Il codice la sopra scala immediatamente verso una transazione distribuita senza che nessuno abbia chiesto nulla ma peggio del peggio quella transazione distribuita passa da una Message Queue Transazionale…

Cosa succede se il servizio Wcf è giù?

Code Snippets

Mauro Servienti — Wed, 04 Nov 2009 08:30:00 GMT

Parliamo un po’ di produttività… ma non tanto in termini di linee di codice scritte in una unità di tempo quanto piuttosto di come e quanto cali la nostra, la mia sicuramente, resa a causa della noia che scrivere codice sempre uguale produce…

Se usate Wpf (o in generale sviluppo di applicazione rich client) questo è un esempio di noia mortale:

private String _myValue = null;
public String MyValue
{
    get { return this._myValue; }
    set
    {
        if( value != this.MyValue )
        {
            this._myValue = value;
            this.OnPropertyChanged( () => this.MyValue );
        }
    }
}

il supporto per INotifyPropertyChanged è veramente tedioso da scrivere e ad esempio in un’applicazione Wpf basata su M-V-VM lo scrivere decinaia e decinaia di volte :-)

Code Snippets

Perchè quindi non farsi un Code Snippet? che scritta una cosa del genere:

esploda in questo?:

permettendoci di ridurre all’osso quello che dobbiamo scrivere.

How to…

Un Code Snippet è semplicemente un file xml con estensione “.snippet” che opportunamente piazzato viene egregiamente digerito da Visual Studio e dall’intellisense:

Il Code Snippet che produce quella proprietà è questo:

<?xml version="1.0" encoding="UTF-8"?>
<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
  <CodeSnippet Format="1.0.0">
    <Header>
      <Title>Creates a Property with PropertyChanged Support using lambda expressions.</Title>
      <Author>topics.it</Author>
      <Description></Description>
      <Shortcut>ppcl</Shortcut>
      <SnippetTypes>
        <SnippetType>Expansion</SnippetType>
      </SnippetTypes>
    </Header>
    <Snippet>
      <Declarations>
        <Literal Editable="true">
          <ID>PropertyName</ID>
          <Default>PropertyName</Default>
        </Literal>
        <Literal Editable="true">
          <ID>PropertyField</ID>
          <Default>propertyField</Default>
        </Literal>
        <Literal Editable="true">
          <ID>PropertySystemType</ID>
          <Default>System.Object</Default>
        </Literal>
        <Literal Editable="true">
          <ID>PropertyDefaultValue</ID>
          <Default>null</Default>
        </Literal>
      </Declarations>
      <Code Language="csharp">
        <![CDATA[private $PropertySystemType$ _$PropertyField$ = $PropertyDefaultValue$;
public $PropertySystemType$ $PropertyName$
{
    get { return this._$PropertyField$; }
    set 
    {
        if( value != this.$PropertyName$ )
        {
            this._$PropertyField$ = value;
            this.OnPropertyChanged( () => this.$PropertyName$ );
        }
    }
}$end$]]>
      </Code>
    </Snippet>
  </CodeSnippet>
</CodeSnippets>

Le 2 cose degne di nota sono la sezione “Declarations”:

<Declarations>
  <Literal Editable="true">
    <ID>PropertyName</ID>
    <Default>PropertyName</Default>
  </Literal>
</Declarations>

che serve per aggiungere elementi editabili durante la fase di editing, appunto :-), dello snippet, usando il tabulatore sarà possibile “navigare” tra i vari elementi all’interno dell’editor, e la sezione “Code”:

<Code Language="csharp">
  <![CDATA[private $PropertySystemType$ _$PropertyField$ = $PropertyDefaultValue$;
public $PropertySystemType$ $PropertyName$
{
    get { return this._$PropertyField$; }
    set 
    {
        if( value != this.$PropertyName$ )
        {
            this._$PropertyField$ = value;
            this.OnPropertyChanged( () => this.$PropertyName$ );
        }
    }
}$end$]]>
</Code>

In cui inserire il blocco di codice che vogliamo snippettare :-)

Ci sono svariati tool per la gestione degli snippet ma secondo me l’unico che merita, oltre naturalmente ad un decente editor per file xml (ad esempio Visual Studio :-) ) è questo add-in del “compare” Alessandro… che è un bravo ragazzo nonstante il set di che ha sul blog sembri dire tutto il contrario :-P

Happy snippetting… ok, ok, scusate :-)

Lo sapevo io…

Mauro Servienti — Tue, 03 Nov 2009 19:06:12 GMT

…che se stamattina la stazione di Treviglio era crashata e continuava a fare boot a nastro la giornata ferroviaria sarebbe stata un delirio…

Esco dal cliente e punto a prendere il Milano-Brescia delle 18.00… magari… il mondo si è fermato ed entro in casa adesso… ben più di 2h per fare 31km.

Visual Studio Template

Mauro Servienti — Tue, 03 Nov 2009 10:30:00 GMT

Nell’ottica di addomesticare lo strumento e non di piegare noi stessi ai limiti, o presunti tali, dello strumento stesso, ci sono una quantità notevole di piccole cose che possiamo fare per semplificarci la vita.

Faccio Unit Test e TDD, credo nella giusta misura, e uso con soddisfazione MSTest per tutta una serie di buone ragioni, ma se c’è una cosa che mi da veramente fastidio è questa:

Che cosa notate? mi sono limitato ad aggiungere ad un progetto di test un nuovo test, nulla di più, eppure:

Il codice del template è commentato… non serve, e per molti, me compreso, è pessima pratica commentare i test;
la scroll bar è lunga come la fame…;
C’è già scritto un sacco di codice;

Insomma non ho ancora fatto nulla e c’è un sacco di rumore di fondo, non va bene; questo è quello che vorrei:

sintetico ed essenziale, senza fronzoli e rumore di fondo.

Facciamolo!!

Credo non ci sia nulla di più facile, basta provare… con un progetto aperto provate a fare: File => Export Template e seguite il semplice wizard :-) poi andate a dare una sbirciatina nella cartella dei settings di Visual Studio, tipicamente: “User Profilo\Documents\Visual Studio 2008\My Exported Templates”… it’s a kind of magic, magic <cit.>

Un paio di settimane di “pomodori”

Mauro Servienti — Mon, 02 Nov 2009 15:00:00 GMT

Sono un paio di settimane che sto seguendo la “ricetta” e ho notato che il fatto di averne parlato ha stuzzicato l’interesse.

Quoto Andrea Dottor:

…Per quanto mi riguarda, non la conoscevo e ne sono rimasto da un lato affascinato, nel senso che, porsi degli obiettivi da 25 minuti non è affatto complesso, e rimanere concentrati per 25 minuti è una cosa fattibile…

L’esperienza di queste 2 settimane mi fa dire che:

25 minuti sono lunghissimi :-)
Stare concentrati per 25 minuti su un obiettivo è impegnativo, devi imparare a gestirti: è fondamentale che l’ecosistema in cui sei calato ti sia amico:

Sistema i tuoi strumenti in quell’ottica;
Rendi partecipe chi ti circonda del perchè e del percome;
Fatti rispettare da chi ti circonda;

Punto 2.1: ho fatto un’altro piccolo esperimento, riuscito alla perfezione, modificando nuovamente il comportamento del mio fido Outlook, da così:

a così:

Ho semplicemente tolto dai “Favorites” la Search Folder dei messagi marcati con un “Follow Up”, tendo ad essere un filino maniacale nell’organizzazione delle mie cose e sapere che ho qualcosa da fare che non ho ancora fatto mi infastidisce abbastanza.

Giusto per capirci, per me sarebbe impossibile avere una Inbox con dei messaggi non letti, quindi nella pause una rapida occhiata ed eventuale marcatura con “Follow Up”, e pianificazione se necessaria (Get Things Done), su quelli che mi interessano. Vi garantisco che con circa 300/350 messaggi/giorno è un lavoraccio :-)

In quest’ottica vedere i “Follow Up” che crescono non mi aiuta a rispettare il ritmo del pomodoro.

I file, le cartelle e… questi sconosciuti

Mauro Servienti — Mon, 02 Nov 2009 12:30:00 GMT

Iniziamo con una piccola nota polemica, concedetemelo :-)

un dev è un professionista come tanti altri, medici o idraulici ad esempio, e quello che mi aspetto da un medico o da un idraulico è che abbia una buona conoscenza, ma soprattutto confidenza, dei suoi strumenti… quindi come è normale che un idraulico sappia cosa è un sifone mi aspetto che un dev sappia cosa è metticiunpoquellochevuoi di Visual Studio; non mi aspetto che lo sappia usare ma mi aspetto che la curiosità l’abbia spinto almeno a dargli un’occhiata.

Purtroppo sempre più spesso consto che questo è molto lontano dalla realtà di tutti i giorni. Che opinione si farebbe un paziente di un dentista che litiga con uno specillo?… e non ditemi che non sapete cosa sia uno specillo… no non è uno specchietto :-)

Detto questo vediamo di affrontare un altro nodo molto importante nell’organizzazione di un qualsiasi progetto software. Nel mio piccolo tendo ad essere un po’ allergico al Class View, non chiedetemi perchè semplicemente faccio fatica ad usarlo e preferisco di gran lunga interfacciarmi con il Solution Explorer.

Se confrontate le due immagini non è che ci sia molta differenza quindi direi che la scelta è puramente soggettiva, ma tutto depende… da che depende…

Si ma il Class View cerca…

vero, questo è interessante, dal Class View è possibile cercare un membro per nome ma la domanda a questo punto è: se un progetto è ben organizzato a cosa mi serve cercare?

Notate il solution explorer qui a sinistra? che differenze ha con il class view sopra? pressochè nessuna… perchè l’orgnizzazione dei progetti è parallela e sincrona, ad esempio, all’organizzazione dei namespace.

Che senso ha in un’organizzazione di questo tipo cercare? potrebbe avere senso pensare che un qualcosa del tipo: Topics.Radical.Model.NHibernate.NHibernateDataContext stia in un posto diverso dal progetto Radical.Model.NHibernate?

Espandendo uno dei progetti ci rendiamo immediatamente conto della cosa:

Ad ognuno il suo spazio

Supponiamo adesso di dover distribuire nella solution i seguenti elementi:

interface IEngine
{
    Boolean IsActive { get; }
}

interface IEngine<T> : IEngine
{
    EngineOperationResult OperateOn( T data );
}

enum EngineOperationResult
{
    Success,
    Aborted,
    Denied
}

tralasciate il design che è tutto tranne che importante adesso e nello specifico probabilmente è pure errato ;-) ma non ci interessa quello… come distribuireste gli elementi di cui sopra nella solution? così:

Con dentro il file Engine.cs tutto il necessario? o così:

lascio a voi la scelta, ma io preferisco la seconda soluzione, ci metto 12 secondi, netti, in più ma ho un colpo d’occhio molto più efficace, molto, ma molto :-)

Il vostro obiettivo è la produttività e la produttività non si misura di certo con il tempo che il compilatore impiega ad analizzare 100.000 files piuttosto che 1 con 10.000.000 di righe, chi se ne frega, intanto che lui compila io bevo il caffè :-)

La produttività secondo me si misura in dimistichezza, facilità di manutenzione, facilità di passaggio di consegne e condivisione del lavoro, facilità di capire al volo dove devo mettere mano per fare una certa cosa, nel primo esempio (Engine.cs) se devo mettere mano all’enumerazione devo per forza usare il Class View, nel secondo no… e se poriettate questo su una solution media:

con qualcosa come 5000 file, di soli sorgenti, è evidente che se le cose non sono maniacalmente organizzate come si deve è più il tempo che passate a cercare che quello che passate a lavorare :-) non parliamo poi del fatto che magari dovete riprendere in mano lavori di qualche mese fa… se l’organizzazione è fallace: panico.

ma… le Partial Class?

Diciamocelo subito, secondo me puzzano :-)

Se non ricordo male le partial class sono state introdotte per poter tenere separato il codice generato dal designer di Windows Forms dal nostro codice, da li le possibilità sono cresciute e lo stesso meccanismo viene sfruttato da Wpf per la separazione tra il codebehind e lo xaml:

Le possiamo usare per organizzare meglio le nostre classi? certo che si, secondo me però prima di farlo val la pena di fare qualche considerazione:

non è che stiamo utilizzando le Partial Class come utilizzeremmo le #region?
non è che le stiamo facendo diventare il tappeto sotto cui nascondere la fuffa?

Secondo me il rischio c’è e io tendo a sfruttare queste sensazioni per far emergere potenziali problemi di design: ho una semplice regola se il codice della roba che sto scrivendo non ci sta tutto sullo schermo, e la scroll bar te lo fa capire molto bene, allora forse è il caso di fare un po’ di refactoring e non di fuffizzare il tutto in una Partial Class.

Ovviamente, come per tutte le regole, non è un dogma e va valutato di caso in caso: ad esempio i controller di MVC e i ViewModel di M-V-VM tipicamente, in quanto accentratori, sono anche un collo di bottiglia per l’organizzazione del codice perchè da li ci passa un intero UseCase, o addirittura più di uno…

Sviluppo Web e qualità, ma in generare sviluppo e qualità

Mauro Servienti — Sat, 31 Oct 2009 06:29:59 GMT

Avete mai provato a tenere abilitato lo script debugger di Internet Explorer?

e poi a navigare un po’ e un po’ la…? che esperienza teribbile :-), tre quarti delle pagine contengone quintalate di errori JavaScript:

producendo una experience che definire pessima è un complimento :-)

L’unica fortuna, per chi produce ste cose, è che quelle opzioni devono essere esplicitamente configurate e quindi in pressochè tutti i browser le cose vanno bene, ma la domanda a questo punto è:

ma il dev che ha scritto quello roba l’ha provata?
ma il tester, di UAT, che l’ha testata ha il debug degli script abilitato?

[OT] Certe cose mi fanno pensare… molto…

Mauro Servienti — Sat, 31 Oct 2009 06:18:43 GMT

Quoto (e condivido):

…snobbata dai più: ma spuntano le foto ed ecco che i grandi quotidiani si avventano allarmati su una notizia che già c’era: «Morto dopo l’arresto, diffuse le foto shock» ha titolato il Corriere, purché sia chiaro che la notizia ritenuta più interessante non era «Morto dopo l’arresto», ma «diffuse le foto shock», dunque le foto.

E il video napoletano stile Gomorra? Avete notato che qualcuno aveva le maniche corte? L’esecuzione, già nota, è dell’11 maggio scorso, e tuttavia Repubblica: «Adesso la città ci aiuti». E perché solo «adesso»? Ah già, perché c’è il video, già, che stupidi.

Fonte: Macchianera.