Advanced Technology

Ho avuto la malsana idea di comprarmi una telecamera. Cerco, leggo, e scelgo. Dalla scheda tecnica sembra proprio un buon prodotto. Inserisco nel carrello, pago, arriva il corriere.

Prima impressione: oddio cosa ho comprato!!!!!

Dalle foto sembrava essere il doppio di quello che è, invece sta quasi interamente nel palmo di una mano, ma vabbè, ci si può abituare a questa cosa.

Leggo il libretto di istruzioni, tutto regolare. Funzione video, foto e registrazione audio. Il video lo registra su un microdrive che sembra una compactflash, ma che compatflash non è, di 4GB per un totale di 1 ora alla massima qualità (8,5Mbps). Il formato è un MPEG2, che ti sposti direttamente sul tuo HD (l'estenzione è .mod, ma basta rinomianre il file) e lo lavori con un qualsiasi programma di video editing, dal più sofisticato Adobe premiere (o Adobe premiere elements che offre anche un tool per l'importazione dalla telecamera, senza copia e incolla e prima rielaborazione del file), ad un Uluead Video studio o ai prodotti della Cyberlink (Che onestamente butterei dalla finestra assieme alla telecamera, infatti indovinate che prodotto c'è incluso alla telecamera???).

Ok, soffermiamoci sulla nota dolente del prodotto. La batteria. Sul libretto di istruzioni dice, durata massima 1 ora. Poi "Nota: se si utilizza lo zoom o la funzione di riproduzione del video, la durata della batteria si può ridurre". Notate il condizionale, che invece i tecnici e io confermo essere un imperativo assoluto. Non si può ridurre. Si riduce e basta e per me, tra ridurre e morire completamente ci passa una grande differenza.

Ho avuto la sfortuna di provare con mano questa cosa in una gita fuori porta e con una batteria sola, se si usano circa due minuti di zoom (senza riproduzione video) più di 20 minuti di ripresa non si fanno.
Qualsiasi persona che usa la telecamera per uso amatoriale e per un filmino delle vacanze, in 1 ora di registrazione vorrebbe o potrebbe dover fare più di 2 minuti di zoom.

E trovo estremamente assurdo il discorso che fanno all'assistenza tecnica "ma se lei non usa lo zoom vedrà che la batteria le dura 1 ora come riportato sul manuale di istruzioni".

Hanno cercato poi di dirmi che esiste un kit esterno che si può collegare al posto dell'alimentatore, portandosi dietro una batteria esterna (il che per quanto possibile, non lascia molte prospettive di portabilità del prodotto) ma comunque questo fantomatico alimentatore esterno non è stato trovato nemmeno dal tecnico con cui ho speso un 20 minuti di telefono per sentirmi dire cose che avevo già letto sul manuale di istruzioni.

Altra risposta datami è: basta comprare un numero di batterie sufficienti: un rapido calcolo, 20 minuti a batteria, 1 ora di registrazione, 2 microdrive che ho, 6 batterie, 1 ce l'ho … sono altri 400 e passa euro.

Se sommiamo i 700 della telecamera e quelli delle batterie, ci avrei tranquillamente preso un prodotto semi-professionale.

L'assistenza clienti. Gentilissima la signorina. Mi ha consigliato di portare il prodotto all'assistenza tecnica autorizzata che faranno delle prove, ma c'hanno poco da provare. Effettivamente la telecamera se la si usa come dice il libretto di istruzioni, fa quello che deve.

Il problema è che il libretto di istruzioni lo trovi nella scatola, dopo che hai comprato il prodotto, e uno quando sceglie il prodotto, non certo si legge il manuale di istruzioni (che nel caso di JVC era effettivamente anche disponibile sul sito). Ma immaginatevi per 25 telecamere dalle quali sono partito e ai 3 prodotti che alla fine sono arrivato. Se dovevo leggermi i manuali di istruzioni, sarei diventato cretino prima di comprare il prodotto. Assurdo.

La cosa più sconcertante di tutto questo discorso è poi quella che il prodotto è stato anche classificato come miglior prodotto 2005/2006 da non sò quale ente o "marchio" famoso. Mi piacerebbe sapere tanto come questi "premi" vengano assegnati o meglio regalati. Perchè un prodotto la cui usabilità rasenta lo 0 secondo me non è nemmeno definibile prodotto. Figuriamo poi "miglior prodotto della categoria 2005/2006". Forse la categoria alla quale si riferifano era quella delle "telecamere da non compare".

Mi spiace solo che siano già passati i 10 giorni di ritorno del prodotto per insoddisfazione. Ma secondo me, qua, una non conformità ci scappa tutta. Devo verificare.

Per concludere, il giudizio complessivo: tenetevi i soldi in tasca o spendeteli per una Sony o qualche altro prodotto.

Ad essere onesto, per quanto sia stato per gli scorsi anni un utente passivo del .net framework, non significa che non ci ho fatto nulla.

Ci ho giocato, poco, ma l’ho fatto. E una delle cose che ho provato è stata quella dei validator. Beh che dire. La versione 1.1 sicuramente è stata deludente, nel senso che Microsoft non si è smentita, ed è quindi andata sull’onda della sua filosofia "il mondo non mi basta" (The World is not enough) che non c’entra un fico secco con lo 007, ma il concetto è proprio quello, ovvero fare tutto come se gli altri non esistono.
Tant’è che i validator su browser alternativi di tutto rispetto (che sul mio pc regnano sovrani come browser di default) come Firefox e compagni ovviamente avevano dei problemi di comprensione legati ovviamente al fatto che la sintassi JavaScript adottata dai validator era tutta "IEizzata".

Tentativi tipo modificare il browsercap.ini piuttosto che la WebUIValidation.js … vi ometto i risultati, con la logica conseguenza che fare ancora tutto con il vecchio sistema javascript client-side per tutti era sicuramente la via più spicciativa per ottenere qualcosa.

Fortunatamente le cose son cambiate. Quando andai ad una delle preview del 2.0, Daniele (Bochicchio), illustrò le novità e la retrocompatibilità con altri browser sicuramente era un punto a favore del nuovo framework.

All’epoca della preview, ovviamente, era ancora in beta e certo mi sarei aspettato un pò più di impegno da parte del team di Microsoft per implementare qualche custom control in più.

Beh non l’hanno fatto. Forse avevano altre priorità. Come biasimarli.

Insomma, morale della favola, fare una validazione sul checkbox, è praticamente impossibile, non per lo meno senza scrivere del codice. Ed è quello che ho fatto io per ottenere uno stupid CheckBoxValidator.

Certo il controllo non è che sia commercialmente valido, nel senso che fa lo stretto indispensabile, e non può certo essere paragonato a tool belli e pronti all’acquisto tipo quello di Peter Blum, però per quello che occorreva a me.

Da dove iniziamo. Dalla classe BaseValidator innazitutto. Implementando la classe, si ha praticamente una struttura di un validatore pronta all’uso. Chiaramente così come è non farebbe nulla. Dobbiamo quindi implementare la nostra logica di validazione.
Il tutto si riconduce essenzialmente a due override: il primo per il metodo EvaluateIsValid, che permette di determinare quando il valore del controllo oggetto della verifica è valido, il secondo è il metodo ControlPropertiesValid che consente di stabilire se il controllo associato al validatore è del tipo corretto.

Quindi nel mio caso, ecco un pò di codice:

Questa riga qui sopra la mettiamo nel costruttore. Il puntatore base, che si riferisce appunto alla classe implementata BaseValidator, andrà a modificare la proprietà per far scrivere durante il rendering in HTML tutta quella serie di elementi necessari per far funzionare la validazione lato client-side. Un esempio aggiungere il Control-ID all’array Javascript di funzioni da richiamare e via dicendo.

Questo codice qui sotto, semplicemente lo aggiungiamo al resto:

Ovviamente il tutto l’ho messo dentro l’evento OnPreRender che viene scatenato non appena il controllo è stato caricato, ma prima che qualsiasi parte HTML sia stata inviata al nostro client (altrimenti non avremmo modo di moficare lo stream da passare al browser).
Mi sincero ovviamente di chiamare il metodo base OnPreRender, altrimenti tutte le altre cosette nascoste (necessarie) che fa il BaseValidator, verrebbero ovviamente saltate.

E il gioco è praticamente fatto.

Mettete tutto dentro una vostra classe, compilate e refenziate, quindi semplicemente dentro la pagina aspx fate una cosa di questo tipo.

Ok, diciamo che questa soluzione l’ho scritta nel 2001, all’epoca non facevo uso di blogs, quindi me la sono tenuta per me e per qualche – forse – post negli apposti NG, ma nulla di più.
Oggi stavo mettendo le mani su di un mezzo programmino che mi sto scrivendo per uso interno, e cercavo un sistema elegante per sapere se la mia Identity Column con la prossima insert mi sfora il valore massimo consentito. Beh, gira che rigira, o ho cercato male io o effettivamente nulla di più elegante non ci sta.
Pure cercando nel mio account di SQL Magazine non ho trovato nulla, solo un post del 2001 di Moran ma che lascia forti dubbi e tutto dipende da quanto si usa il DB.
Non mi ritengo un DBA … questo no, e forse questa soluzione verrà castrata immediatamente, però la ritengo semplice e funzionale. Quindi a vostra disposizione.

Velocemente commento con il fatto che, ovviamente, la tabella deve avere una colonna di tipo identity e che quello che ritorna è il valore massimo a seconda della scala di precisione adottata.

Con questo valore di ritorno, semplicemente facendo una cosa del tipo

Possiamo sapere se stiamo nei limiti oppure se con qualche altro check dobbiamo fare altro.

Premessa

Nel mio caso io ho lavorato sul web.config, ma dato che non ho fatto nulla di tracendentale e ho utilizzato solo classi del framework e nulla di personalizzato, presumo che se il file di configurazione sia quello di un applicativo, non dovrebbero esserci problemi.

Ricordo che una soluzione per antonomasia non esiste, questo è chiaro. Sulle prima, infatti, non ero nemmeno sicuro che questa fosse quella che faceva al caso mio, e tra l’altro avevo anche dei problemi nel farla funzionare, sicchè mi venne suggerito di usare un semplice schema XML/XSD, che se sulle prime poteva sembrare efficace, immaginando meglio lo scenario finale, risultava poco "sicuro" per via del fatto che chiunque avesse avuto accesso al sorgente del sito avrebbe potuto variare il contenuto del valore da validare. Quindi sono ritornato sui miei passi e ho iniziato a capirci qualcosa dei Validator.

Al lavoro dunque!

La necessità

Poter controllare cosa accidenti scrive l’utente in un file di configurazione.

La soluzione

Sulle prime quando ho cercato di capire come potessi fare a validare, la prima ricerca che ho fatto è stata proprio "Custom Validator" e – benchè mi pare di capire che questo sia il nome di quello di cui sto parlando -, tutti i risultati che venivano fuori (Msdn, google, ecc.) erano riferiti a custom validator che però si associavano esclusivamente a controlli sulle webform. Il che non era esattamente quello che volevo.

Mi sono guardato un attimo intorno, ed in particolare sul fatto di cosa una custom configSections (per crearla bisogna ereditare da ConfigurationSection) e i suoi elementi (creabili da ConfigurationElement) e qui erano saltati fuori StringValidator e compagni.

Erano esattamente quello che mi serviva. Allora, come da ogni buon programmatore (??) guardo da che classe ereditano … e nel caso dello StringValidator, da StringValidatorAttribute che come unica proprietà da implementare richiede la ValidatorInstance, una proprietà di sola lettura che restituisce un oggetto, la vostra classe, di tipo ConfigurationValidatorBase che si occuperà di fare il lavoro "sporco" e di validare il contenuto dell’attributo del file di configurazione, richiamando dapprima il metodo CanValidate per verificare che il tipo di dati datogli in pasto sia validabile secondo la nostra classe e poi il rispettivo Validate per sapere se il valore è o meno valido.

Reperite queste informazioni, il gioco è stato abbastanza (??) semplice. 

Ma vediamo qualche linea di codice:

 

Con questa classe – non ereditabile (non sia mai qualcuno tocchi il mio codice) – qui sopra non faccio altro che definire un oggetto di tipo attributo (perchè eredita da ConfigurationBaseAttribute che a sua volta eredita da Attribute) che chiamo – guarda caso per ricordarmi – con il nome del mio attributo presente nel file di configurazione con l’aggiunta del suffisso Validator tanto per rimanere in stile Microsoft (La parola Attribute che segue Validator sebbene non strettamente indispensabile e caldamente ignorata dall’IDE ce l’ho aggiunta per la stessa identica ragione – rimanere con una classe stile Microsoft).

All’interno dichiaro una variabile globale di tipo Validatore (che ancora non ho mostrato), il costruttore di default, e l’impementazione della proprietà ValidatorInstance.

Non mi soffermo di più sul fatto che all’interno della classe si potevano creare dei NamedParameter con i quali poter accettare dei valori opzionali in ingresso, o ulteriori costruttori firmati. Ma per lasciare le cose semplici, supponiamo che a noi non interessano parametri.

A questo punto, dobbiamo scrivere la nostra classe che si occupa di validare il contenuto dell’attributo. Ecco qua:

 

Ok, forse non sarà il massimo dell’eleganza dichiarare quell’array lassu, secco con due valori e francamente in un caso dove realmente dovrei validare il nome scegliendolo da una lista di possibili valori, sinceramente ho qualche difficoltà anche io a capire come andarli a leggere da un elenco più nutrito che non mi sia scritto prima a mano. Ma questo è pur sempre un esempio.

Questa classe, come dicevo prima, controlla il contenuto dapprima verificando che il tipo in ingresso sia valido e poi validandolo, e in caso negativo si preoccupa di sollevare un’eccezione al compilatore con relativo messaggio che aiuti a capire cosa è successo.

Come uso il tutto? Intanto prendendo le due classi e mettendole nel codice, poi, sempre premesso che stiate lavorando su di un configuration element, non dovrete far altro che andare al di sotto della vostro elemento,

mettere una parentesi quadra per aggiungere un attributo ed ecco che magicamente compare nella nostra lista il nostro validatore.

Et voilà, il gioco è fatto.