NeatCoding

Issue filosofico... era tempo che non ne facevo uno eh? :)

Periodo di lavoro intenso, questo, tanti progetti tutti importanti su tanti clienti... e da tutti i miei clienti faccio parte di quello che io ormai chiamo il "Gruppo Dottor House".

Breve spiegazione: credo che chiunque abbia almeno sentito parlare della famosa serie; Nel caso, per riassumerla, parla del  dotto Gregory House, medico fuori dal normale a capo di una equipe di medici brillanti predisposti alla risoluzione dei casi disperati, a volte anche un pò eccessivi, tipo che si parte da un raffreddore e si arriva ad una sindrome sconosciuta mortale e/o potenzialmente debilitante a vita... ma di solito è mortale :)

Io invece faccio parte di team di disperati, tutti con la stessa particolarità: siamo quelli da cui gli altri vanno quando sono nelle canne :)
Se c'è un progetto impossibile, qualcosa da consegnare lunedi ed è venerdi pomeriggio tardi, (Il gruppo doctor house lavora sabato e domenica da un bel po di tempo :( ), qualcosa che nessuno conosce dal punto di vista tecnologico ma che, non si sa come ne perchè, è già stato stimato, qualcosa che è stato talmente rovinato che sembra impossibile recuperarlo, però bisogna metterlo in piedi per la data di rilascio..... di solito entriamo in gioco noi :)

Da qui la mia idea di chiamarli così.... non perchè mi ritenga simile a lui, magari, ma perchè come efficenza (e come cinicità verso il progetto) i miei team e lui sono abbastanza simili... e devo dire che non siamo così brillanti ma la maggior parte delle volte riusciamo a portare a casa la pellaccia ed a risolvere la magagna...

Nei mesi in cui latito in questi team, cambiando progetti, tipologia, cliente, manager, insomma di tutto, sono arrivato a farmi una specie di statistica interna su quanti progetti si possano gestire in questa maniera prima di collassare....

Per esempio, un progetto urgente/complesso/tecnologia nuova si può affiancare a quanti progetti contemporanei  non urgenti si vuole.... se già ci sono due progetti urgenti ed altri meno urgenti diventa un macello...

In questo periodo con un cliente particolare il gruppo ha raggiunto il limite per cui si rischia il fallimento: 2 progetti  su tecnologia "nuova" (nel senso che nessun'altro ha know-how e quindi può nel caso aiutare) entrambi urgenti e con date di scadenza ben definite (uno la data di scadenza è stata ridefinita a posteriori con un anticipo di praticamente due mesi) piu due progetti non urgenti ma comunque da consegnare e mediamente complessi....

In questo caso il gruppo Doctor House rischia di non farcela... ed il problema è che vedendo per la prima volta un potenziale limite del team, noto anche la conclusione piu catastrofica: che invece di risolvere, fallisca su tutti i fronti cercando di salvare tutto e facendo invece fallire tutto insieme,  completamente, miseramente. In questo caso, la soluzione che adotteremo, che è secondo me inevitabile, è quella classica del telefilm omonimo: bisogna farne morire uno. La scelta non sarà facile, ma se nell'ospedale non c'è nessun altro in grado di guarire il paziente e non si può trasferire in un altro ospedale vuol dire che sforzarsi diventerebbe rischioso per tutti gli altri che possono ancora farcela...

La scelta non spetta a me, ma spero vivamente che si prenda il progetto piu moribondo, che ha meno possibilità di venire consegnato in tempo.... e si faccia slittare la consegna :)

Aggiunta: esatto, in questo periodo non gestisco piu team di scimmie!! Per ora... si vedrà tra poco... :(

Ho avuto dei bei problemi a creare un applicativo WPF che fosse bello a vedersi ma che incorporasse anche alcune funzionalità del tipo contabile/amministrativo.

Putroppo, per questo tipo di lavori, una griglia è sempre quello che fa al caso nostro, perchè non c'è un modo piu comodo dal punto di vista dell'utente per avere una visione d'insieme e riuscire ad avere un'operatività discreta su quello che sta facendo... questo almeno finchè l'utente vorrà vedere i dati piu o meno come li vede stampati.... necessità che non capisco molto se non stai facendo report, ma fa nulla :)

Comunque, sono dovuto scendere a patti con questa necessità e mi sono  dovuto procurare una griglia. Come (spero) sappiate, la Grid presente in WPF non è visuale ma un mero contenitore di oggetti, che può fungere da griglia ma operazioni come il caro vecchio databind di dati complessi pùò risultare nella scrittura di un DataTemplate particolarmente ostico (se non conoscete i DataTemplate e i ControlTemplate, Corrado ha fatto a suo tempo due semplici esempi sia per il primo che per il secondo... magari poi io parlerò meglio dei casini che sono successi a me con detti oggetti :P) e soprattutto una gestione eventi da incubo. Alla fine, abbiamo deciso di basarci su un prodotto di terze parti, che non pubblicizzo perchè non è nel mio stile ma tanto lo sapete tutti che i componenti che girano sono sempre di quelle 4/5 aziende.

Comunque, in questo caso ho avuto la necessità di "skinnare" la griglia con le esigenze del cliente e mi sono scontrato con.... la totale e disarmante mancanza di documentazione coerente per quanto riguarda il theming. Vedere un'applicazione di esempio, e il tema di esempio fornito con la griglia, che fa determinate cose e non vedere scritto _da nessuna parte_ come poterlo replicare credo che sia la cosa piu frustrante che possa capitare ad uno sviluppatore.....

Ovviamente, a questo punto lo  sviluppatore si inca**a, entra in hard core mode (non nel senso che apre i vari cloni pornografici di youtube, ma che si mette d'impegno :P) e cerca di trovare un metodo. Nello specifico, io ho preso la DLL contenente il theme pack che mi interessava e l'ho scardinata usando Reflector.

Per farlo, basta sapere come funziona il meccanismo delle risorse: come vi ha detto anche il solito Corrado, ogni risorsa può essere messa in un dictionary esterno, che altro non è che un .XAML, sia nello stesso assembly che in un assembly esterno. Questi XAML in fase di compilazione viene compilato nella DLL come risorsa embedded, quasi come i file .JS o .CSS in ASP.NET. Quasi,  però, perchè in realtà non vengono messi dentro gli assembly così come sono, ma vengono sottoposti alla semi-compilazione propria di tutti gli XAML, diventando così BAML (cioè XAML Binario). Il grosso problema è che il nostro amico Reflector "impazzisce" quando cerca di visualizzare dei BAML comportandosi in maniera strana (appaiono faccine e 2 di picche...).

Fortunatamente, ci viene in aiuto la lista degli addin per reflector, in cui troviamo l'impagabile BAML Viewer, che mi ha permesso di salvarmi in solo testo i miei assembly per controllare cosa fa la sporca griglia dietro le quinte.

E per la griglia si, confermo che le funzionalità non sono proprio accennate: facendo una ricerca all'interno della documentazione non si trova neanche la  keyword relativa... sigh, peccato rovinare dei così bei lavori prendendo sottogamba la documentazione per il dev che dovrà usarla....

Ho in cantiere due issue su ControlTemplate e DataTemplate: noto spesso dai clienti che la differenza tra i due non è così conosciuta come dovrebbe essere, e soprattutto i meccanismi di utilizzo dell'uno e dell'altro non li si conosce....

Purtroppo, sono slittati come priorità visto che oggi ho passato una giornata lavorativa a venire a patti con un progetto VS2005 + Cider e un VS2008.

Dovevo fare delle prove con una GridView per WPF di cui magari un giorno vi parlerò, e per farlo ho aperto  un progetto WPF _nuovo_ con VS2008 e tenendo di fianco il vecchio VS2005 come referenza e controllo. Il progetto vs2008 è complicatissimo, ovviamente: contiene una window vuota che ha solo la griglia bindata a una singola tabella di tre campi :P

E' successo il finimondo.....

Mi sono sempre lamentato di Visual Studio 2005 perchè effettivamente non da alcun tipo di supporto, è lento e goffo e non sai mai se i warning sono warning o errori oppure è semplicemente la luce che entra e si riflette ed a Visual Studio non piace e quindi da i Warning. 2008 per contro è infinitamente piu preciso, ma non è stato pensato per lavorare con le risorse. La griglia in questione fa un massiccio uso di ResourceDictionary (tipo 4 o 5 quelli custom che sto facendo ex-novo io, piu altri che sono embedded negli assembly) e lavorare esclusivamente con i resource dictionary pur su un progetto nuovo comporta:

1: 300 Mega di ram _sempre_ istanziata. Per fare cosa, non si sa
2: Lentezza esasperante a fare qualsiasi cosa: cambiare un attributo comporta il controllo in tempo reale di _tutto_ il resourcedictionary. E quindi vedo che se apro un tag ovviamente lui pronto mi dice che non è chiuso.. e grazie.. e per dirmelo mi inchioda la macchina. Sicuramente è modificabile (spero) da configurazione, ma il fatto che parta così di default mi fa un pò paura.... mi ricorda con orrore i vecchi tempi di VB6...:P
3: Lentezza esasperante nell'apertura di un qualsiasi dictionary. Se lo passa tutto per cercare di visualizzare qualcosa. Ma dico, non è meglio che se incontra ResourceDictionary chiude automaticamente l'anteprima e basta??
4: Eludendo il discorso Dictionary, devo dire che il supporto del designer è piu scarso di come me lo ricordavo.... qualsiasi usercontrol che utilizzare dei Content Template con della grafica, non viene renderizzato (rimane il placeholder ma si perde la grafica nel Resource Dictionary)

Che dire... non fate come me, se volete fare queste cose, fatele in blend :)

Ultimamente ho parlato spesso di risorse e WPF: sia io che Corrado vi abbiamo fatto vedere come utilizzare al meglio le risorse per gli elementi testuali.

In qualche post futuro farò una breve digressione sulle varie tipologie di risorse e su come possono essere utilizzate con differenti tipi di oggetti.

Può succedere, in ogni caso, di avere la necessità di trovare una particolare risorsa da codice, cioè non interrogando i Dictionary in maniera programmatica. Mi sono scontrato con questo problema "stupido" agli inizi del mio percorso in WPF perchè credevo nella mia innocenza che il FindName funzionasse alla grande visto che restituisce un Object.

Giustamente, invece, le risorse possono essere si figlie di un FrameworkElement (FindName infatti cerca gli oggetti figli di un particolare FrameworkElement, che può essere una finestra, uno UsesrControl o altro)  ma anche essere esterne e inglobate come dictionary...

Quindi, il metodo corretto da usare e quello ad-hoc, FindResource ricordandosi come con FindName di eseguire il cast corretto!

Agli "inizi" della mia avventura con WPF mi capitava spesso di avere un errore abbastanza scomodo che era "Mapping URI is not valid" quando dovevo tipo importare un mio namespace per referenziare per esempio uno usercontrol (quindi qualcosa del tipo xmlns:uc="clr-namespace.." etc etc).

Per mia esperienza personale, con Visual Studio 2005 e prima che gli errori avessero un pò di senso da quel punto di vista, le sviste piu comuni erano:

1: ":" al posto di "=". Non so perchè ma mi è sempre venuto automatico scrivere per esempio xmlns:uc="clr-namespace=myNamespace" invece della sintassi corretta xmlns:uc="clr-namespace:myNamespace"

2: Nel caso di una referenza ad un controllo presente in un altro Assembly, bisogna definire per forza il nome dell'assembly a cui appartiene. In questo caso, invece, è corretto non mettere i ":" ma mettere "=" (io invece, ovviamente, facevo il contrario....). Quindi diventa
xmlns:uc="clr-namespace.myNamespace;assembly=myAssembly"

3: In questo ultimo caso, è necessario NON lasciare uno spazio dopo il ; altrimenti non funziona.

Se siete dei poveretti che (come me) hanno ancora dei progetti WPF che usano 2005 con le WPF Extension, magari possono esservi utili :)

Trovo sempre utile per applicazione di un certo calibro ricorrere alle risorse per tutto ciò che riguarda il testo. E' facile, veloce e non costa praticamente niente.
Se vi siete persi il mio primo Issue generale sulle risorse, andatevelo a rivedere per sicurezza :)

Per chi usa Blend (e per chi non lo usa scaricate la December Preview di Blend2 che è uno spettacolo) basta selezionare l'oggetto (pulsante/label/whatever) e controllare il piccolo quadratino di fianco alla casella di testo: schiacciandolo, si avrà accesso ad una serie di voci tra cui quattro segnalate in verdino che sono

Local Resource
System Resource
Edit Resource
Convert to new resource

Se non avete creato nessuna risorsa, l'unica disponibile sarà l'ultima, che vi consente di creare una risorsa per quella stringa in tre posti diversi: Application, This Document e Resource Dictionary.

La differenza è che il primo mette la risorsa nello XAML dell'app.xaml, integrato nei ResourceDictionary del documento; il secondo lo mette invece nello xaml del documento corrente, il terzo permette di selezionare un file esterno di tipo ResourceDictionary da cui prendere la risorsa. Se non ci sono risorse esterne nel progetto, ti permette di creare un file nuovo.

Di solito, quest'ultima è l'opzione che preferisco. Dopodichè posso sempre modificare il valore della risorsa usando edit o andando nello spazio dedicato alle risorse di Blend.

Update: in blend, ogni risorsa viene richiamata utilizzando DynamicResource. Credo che il motivo sia dovuto al fatto che blend essendo un enorme wizardone preferisce "pararsi le spalle" nel caso la vostra risorsa diventi da semplice testo che non cambia mai a qualcos'altro che ha bisogno di essere valutata a runtime....
La cosa migliore da fare è andare a cambiare i valori nello XAML da DynamicResource a StaticResource, perchè tanto il testo sempre testo sarà.... come appunto faccio qui sotto quando spiego l'utilizzo senza blend.
Grazie a Corrado per avermelo ricordato :)

Per chi non usa blend, per ricreare questo metodo basta creare un file di risorse (Resource Dictionary (WPF) come tipo di file in Visual Studio) e incorporarlo nella propria applicazione utilizzando <ResourceDictionary.MergedDictionaries> per importare la nostra risorsa. Dopodichè, il nostro pulsante/label/bottone  potrà chiamare il testo direttamente dallo XAML con (x esempio nel caso di un bottone)

Content="{StaticResource Bottombar.MenuButton}"

Dove ovviamente Bottomnbar.MenuButton sarà il nome della chiave del nostro ResourceDictionary che avrà una struttura tipo

<ResourceDictionary (piu altra "fuffa dichiarativa xml")>
  <System:String x:Key="Bottombar.MenuButton">Menu</System:String>
</ResourceDictionary>

Ho visto che Corrado non ne ha mai parlato, quindi mi lascio andare ad una piccola digressione sulle Resouce e i ResouceDictionary in WPF.

Le risorse in WPF sono un discorso molto ampio. Sarebbe meglio trattarlo tutto intero, ma questo esulerebbe un pò dallo spirito nudo e crudo del Daily Issue (che è tornato in sordina dopo un luuuungo tempo di silenzio... mi scuso ma viaggi e impegni mi  hanno stretto alla gola :D) quindi lo tratterlò un pò a pezzi.

Come prima parte, una breve infarinatura sulle risorse: sono un "tantino" diverse dalle nostre resx, ma il concetto è lo stesso: sono coppie chiave valore che contengono una serie di informazioni. Il valore può essere del testo o un oggetto diverso da una stringa a seconda del tipo di risorsa che vogliamo utilizzare....  possiamo avere risorse per il testo, per i colori, per le animazioni, e per praticamente qualsiasi cosa esista in XAML.

Le risorse, diversamente da ASP.NET, possono essere integrate nei documenti stessi oltre che in un file di risorse separato.

Ogni oggetto può avere delle risorse specificate, quindi posso definire delle risorse per una window (<Window.Resources>) o anche per un rettangolo o un button (<Rectangle.Resources> o <Button.Resources>) oppure possono essere raggruppate in un ResourceDictionary, cioè uno XAML contenente coppie chiave/valore.

Ogni risorsa può essere statica o dinamica, questo generalmente cambia il modo con cui viene caricata la risorsa: tutte le risorse statiche vengono caricate all'avvio mentre quelle dinamiche vengono valutate al momento dell'effettivo utilizzo.

Per una descrizione dettagliata dell'utilizzo delle risorse guardate la relativa pagina di MSDN.... sono cosciente del fatto che non è un proprio Issue ma è necessario parlare un pò delle risorse visto che 42432342 dei miei Issue hanno avuto loro come protagoniste :D

Tra poco dovrò ricominciare con il solito tran tran quotidiano... solito neanche tanto visto che "solitamente" salto da un cliente all'altro correndo come un matto... diciamo solo che tra poco dovrò smetterla di pagare le cose in dollari e cercare di pensare in inglese :)

Dovrò probabilmente tornare, stavolta per un periodo piu lungo ed un tantino piu organizzato (cioè da solo, macchina mia ed appartamento... la vita da hotel non fa per me....) ma per un pò me ne starò tranquillo in italia....

L'unica delusione che ho avuto è stato non poter assistere dal vivo alla keynote di BillG Al CES ... cioè, c'ero, ma sono riuscito a vedere poco perchè la ressa era tale che mi ha costretto ad uscire.....
anche il CES in se non ho potuto vederlo come meritava, sono arrivato in ritardo ed ero di fretta... va beh magari l'anno prossimo mi andrà meglio!

Alcune considerazioni sparse sulla "vacanza lavorativa" appena trascorsa:

1: Quando noleggiate un SUV, e siete sul sedile posteriore, e non conoscete il SUV in questione, NON toccate le levette :P
2: Come ogni volta che ci vado, vedere negli stati uniti mini market aperti 24 ore in un paese di poco piu di 9000 abitanti mi tocca il cuore.... Io a Milano, unica metropoli italiana (non lo dico io, c'era scritto in tutte le librerie di Las Vegas.... :P), ho speranze di trovare qualcosa di aperto soltanto andando in stazione centrale...
3: Se avete in programma una vacanza negli stati uniti nell'immediato, portatevi una seconda borsa, vuota.... il cambio in questo periodo è talmente conveniente che è un delitto non fare un giro da Macy's o Bloomingdale ed uscirne fuori carichi.... io ho fatto l'errore di entrare da BestBuy a Las Vegas e da Macy's a Chicago e ne sono uscito piegato... non contento, ho visto un Nike Store di 5 piani (per chi segue i Simpson, pensatelo detto come Home e Mindy dicono "un hot dog lungo mezzo metro".... ecco, ci siete :P) e sono uscito in carrozzina :)
4: Le colazioni a Buffet ti fanno capire perchè gli americani sono tutti obesi... .per la prima volta ho fatto 5 giorni su 10 di buffet a colazione, e quasi non entro nei jeans con cui sono partito :(
5: Per le cene a Buffet, vedere il punto 4. Se andate a Las Vegas vi consiglio il Luxor. Il bellagio è il migliore ma decisamente troppo caro (se 30 dollari che sono piu o meno 20 euro si possono definire cari per mangiare di tutto, tra cui sushi, pesce fresco e carne, tutto di buona qualità).
6: Chicago è bellissima, ma se ci andate d'inverno non fate i fighi come me e portatevi una giacca imbottita! Io ero li col cappotto col termometro a 10 gradi (farenheit... in celsius fa piu o meno -12), neve ed un vento terribile... ho rischiato di svenire uscito dal ristorante l'ultima sera per lo sbalzo di temperatura....
7: La US Airwais non è affatto male... anche se ero scettico... ho fatto 7 voli su 8 con loro e ses si esclude ovviamente il cibo si sta molto bene... i sedili sono decisamente imgliori della American e le hostess non dico fighe, ma almeno umane. La british per ora rimane meglio ma chissà....
8: Di tutti gli aereoporti che ho visto nella mia vita, è la prima volta che faccio scalo a Francoforte e devo dire che è uno dei piu cari... ho appena pagato 3 euro una bottiglia d'acqua e 6 euro un succo d'arancia.... ok che sono uscito dal dollaro col cambio favorevole e mi sentivo ricco, ma questo è un brusco ritorno alla realtà :P
9: Ho vinto 50 dollari a Las Vegas! Ma non per questo offrirò da bere la prox volta che mi farò vedere :P
10: L'organizzazione degli eventi negli USA è spettacolare. Non eravamo riusciti a preregistrarci per il CES ma è bastata una copia del fax ed un biglietto da visita e siamo entrati in tempo 10 minuti. Una cosa simile a SMAU, che non regge come paragone ma è quanto di piu simile abbiamo in italia, avrebbe mobilitato la guardia nazionale e alla fine non saremmo riusciti ad entrare comunque :(
11: Idem per gli alberghi: una prenotazione per due persone è diventata una prenotazione per tre, senza costi aggiuntivi. La tizia della reception ha semplicemente sorriso ed ha detto "la camera è pagata, ma ci sono due letti. Se non vi fa schifo dormire nello stesso letto, vi do tre chiavi, altrimenti pagate una singola".... In italia, la stessa cosa sarebbe risultata in "ah, ma non si può. La camera costa così se è per due, per tre c'è l'aggiunta, e la tassa, e l'incentivo rottamazione, ed il superbollo, ed anche la sovvenzione per chi pulisce la moquette... " .... ri :(

Si si lo so che ci sono piu OT che post veri e propri :)

Dopo un natale ed un capodanno che non posso che definire "lavorativi", sono incredibilmente riuscito a chiudere tutti i miei progetti ed a lasciare le relative mansioni a chi di dovere.

Sono incredibilmente di fretta, visto che tra 14 ore parto e devo ancora fare le valigie e preparare mille cose... ma sono sicuro di farcela :D

Passo Las Vegas e Chicago (lavoro, non iniziate ad insultarmi :P), ed in entrambi i posti dovrei avere la connessione, e quindi spero di avere il tempo in hotel di sparare fuori i miei Daily Issue visto che tra WPF, Live Maps e Live Gadget ne ho una cifra...

Nel frattempo, buon lavoro a tutti e ci si rivede tra una ventina di giorni!