domenica 25 marzo 2012
#
Ieri ho pubblicato il mio primo contributo su Visual Studio Gallery si tratta di un controllo per Windows Forms chiamato Doctor Bit Weather Control che permette di visualizzare le condizioni meteo attuali di una località definita.
Il controllo si basa sui servizi pubblici forniti dai Web Service di Yahoo, principalmente dai servizi di localizzazione (WOEID) e Meteo. Il suo funzionamento è semplicissimo, una volta trascinato sul Form basta richiamarne il metodo SetWeather che accetta i parametri Location e Unit che indicano rispettivamente la località di cui si vuole conoscere il meteo e l’unità di misura con cui devono essere visualizzati i dati (Celsius o Farenheit). Il controllo espone inoltre la proprietà Language che permette di impostare la lingua con cui i dati vengono visualizzati (ad oggi Italiano o Inglese). In futuro è prevista l’introduzione anche di Francese Tedesco Spagnolo e Portoghese. Se qualcuno volesse contribuire ad una di queste traduzioni si può tranquillamente fare avanti. Il controllo, ovviamente, è completamente gratuito e non può essere utilizzato in applicazioni commerciali. Ha avuto fin da subito un buon successo, il primo giorno è stato scaricato da oltre 40 persone e, considerato che è stato pubblicato di venerdi sera, mi sembra un ottimo risultato!
Provatelo! Attendo feedback!
Alberto
mercoledì 14 marzo 2012
#
Ce l’abbiamo fatta a conquistare un altro primato!!!!
La domanda non è più “dove andremo a finire?” adesso è diventata “dove andremo per ricominciare!!!!”
Alberto
mercoledì 1 febbraio 2012
#
Come annunciato il 9 Gennaio al CES da Steve Ballmer, Microsoft ha rilasciato la prima versione commerciale del Kinect SDK for Windows utilizzabile con un sensore dedicato chiamato Kinect for Windows, leggermente diverso dal corrispondente per XBox.
Tra le novità spiccano il near mode e il modello a oggetti che ha assunto delle definizioni più comprensibili.
Per maggiori dettagli: http://www.microsoft.com/en-us/kinectforwindows/develop/new.aspx
Alberto.
venerdì 13 gennaio 2012
#
Oggi mi sentivo un po’ stranito da tutto questo clamore che si sta facendo intorno all’evasione fiscale, ai controlli degli ispettori del fisco e della Guardia di Finanza, tant’è che mi sono messo a rimuginare sui perchè in Italia è così difficile rispettare le norme fiscali a costo di essere beccati in flagrante. Infatti le domande che mi sono posto sono state molteplici: “Perchè gli Italiani rischiano così tanto per non pagare le tasse violando la legge?” “Perchè un rischio così alto non se l’assumono anche per altre violazioni?” Pensandoci bene, il rischio che ti assumi violando la normativa fiscale può provocarti conseguenze alla lunga molto più gravi rispetto, ad esempio, alla violazione di un limite di velocità o della disposizione di non fumare in determinati luoghi. Ma perchè, allora, in così poco tempo siamo riusciti ad essere tutti più disciplinati con l’auto e con le sigarette? Pensiamo soltanto a quello che accadeva sulle strade e quali nuvole di fumo c’erano nei ristoranti o in altri luoghi pubblici non più tardi di 7-8 anni fa, rispetto a quello che accade oggi. Cosa è successo?
Non credo sia accaduto niente di particolarmente eclatante da un punto di vista delle istituzioni, a parte qualche divieto di fumo in più e la patente a punti. Sicuramente questi dispositivi hanno innescato un meccanismo virtuoso ma, a mio avviso, il grosso lavoro è stato compiuto dalla collettività, che ha “imparato” a rispettare gli altri in maniera più rigorosa.
E cos’altro non è la costituzione se non un modo in cui tutti noi dobbiamo “imparare” a rispettare gli altri? Il problema è che la costituzione da sola non basta, ci vuole anche una certa dose di rispetto spontaneo, altrimenti la costituzione rimarrà soltanto una carta e niente più.
E’ ovvio che oggi si fa un gran parlare di EDUCAZIONE FISCALE perchè effettivamente il nocciolo della questione è proprio questo: in Italia la normativa fiscale esiste, quello che manca è il secondo ingrediente, ovvero l’EDUCAZIONE FISCALE. In parole povere gli italiani sanno che DEVONO pagare le tasse ma NON SANNO PERCHE’ le stanno pagando. Se vado dal salumiere e acquisto 3 hg. di mortadella, pagando il prezzo richiesto, ho l’opportunità di soddisfare immediatamente un bisogno (la fame), poichè gli effetti del versamento di un corrispettivo (i soldi) mi procurano uno stato di benessere immediato (il profumo della mortella). Per le tasse questo meccanismo è parziale, ovvero si ferma alla prima fase: il versamento del corrispettivo, manca la parte di verifica immediata del bene ricevuto e da qui nasce il primo malcontento da parte di chi deve versare.
Oltre a questo aspetto, che scatena una ritrosìa principalmente involontaria, in genere si aggiunge un altro aspetto relativo alla verifica successiva di quali siano le modalità di impiego dei soldi che versiamo all’erario. Questa seconda fase, molto più ponderata e frutto di informazioni specifiche, fa sì che l’italiano si ponga in uno stato di assoluta diffidenza nei confronti di chi amministra i soldi da lui versati in favore della collettività, indicandogli metodi illegali di autodifesa.
Una volta chiariti questi aspetti, rimane molto difficile trovare un modo efficace per instradare i connazionali sul terreno dell’EDUCAZIONE FISCALE nel rispetto della collettività.
Ma se ci pensiamo bene esiste un modo, oltre a quello coercitivo, per sviluppare negli italiani una sana EDUCAZIONE FISCALE, altro non è quello di creare un INTERESSE da parte del contribuente al DICHIARARE di più. Così come la patente a punti premia ogni due anni gli automobilisti più virtuosi, anche il fisco dovrebbe premiare gli italiani che dichiarano di più, innescando un meccanismo per cui LE ALIQUOTE FISCALI SI ABBASSANO ALL’AUMENTARE DEGLI INTROITI DICHIARATI. Beh, però sembra ovvio che così facendo il fisco ci rimette. Questo è vero ma soltanto apparentemente. Mi sono permesso di calcolare, secondo un’ipotetica tabella di prezzo, quali sono gli introiti (teorici, ovviamente) che il fisco acquisirebbe dall’applicazione del semplice principio dell’abbassamento delle aliquote. Ammettiamo di applicare un’aliquota fiscale del 20% fino ad un dichiarato di € 39,00 e del 19% per chi dichiara più di € 40,00.
Se facciamo una scaletta:
| GUADAGNO LORDO | ALIQUOTA (%) | RIMANENZA | IMPOSTA |
| 35 | 20 | 28 | 7 |
| 36 | 20 | 28,8 | 7,2 |
| 37 | 20 | 29,6 | 7,4 |
| 38 | 20 | 30,4 | 7,6 |
| 39 | 20 | 31,2 | 7,8 |
| 40 | 19 | 32,4 | 7,6 |
| 41 | 19 | 33,21 | 7,79 |
| 42 | 19 | 34,02 | 7,98 |
| 43 | 19 | 34,83 | 8,17 |
Notiamo che i due scaglioni successivi di reddito da applicarsi in concomitanza del subentro dell’aliquota inferiore (€ 40 e € 41) provocano, ovviamente, un abbassamento del gettito fiscale, ma che dal valore successivo in poi, il fisco inizia a incassare di più.
Fin qui potremmo anche accontentarci di questo risultato, invece ho voluto inserire nel calcolo un ulteriore elemento.
Ammettiamo di fare “l’avvocato del diavolo” e mettiamoci dalla parte del fisco che sicuramente non ha piacere che gli si abbassi il gettito, come possiamo migliorare la fase di passaggio di aliquota senza che il fisco ci rimetta e invogliando il contribuente a dichiarare di più? Semplice: blocchiamo ciò che spetta di RIMANENZA al contribuente finchè egli stesso non dichiara un guadagno lordo che permette al fisco di avere un introito maggiore rispetto all’aliquota precedente, ovvero nel caso sopra indicato la tabella dovrebbe essere così riscritta:
| GUADAGNO LORDO | ALIQUOTA (%) | RIMANENZA | IMPOSTA |
| 35 | 20 | 28 | 7 |
| 36 | 20 | 28,8 | 7,2 |
| 37 | 20 | 29,6 | 7,4 |
| 38 | 20 | 30,4 | 7,6 |
| 39 | 20 | 31,2 | 7,8 |
| 40 | 19 | 31,2 | 8,8 |
| 41 | 19 | 31,2 | 9,8 |
| 42 | 19 | 34,02 | 7,98 |
| 43 | 19 | 34,83 | 8,17 |
Così facendo l’interesse del CONTRIBUENTE è quello di DICHIARARE DI PIU’ perchè accedendo ad un aliquota di imposta inferiore la rimanenza di denaro a sua disposizione aumenta.
Ovviamente non credo che questo sistema sia perfetto, lungi da me pensare in questi termini, la perfezione non appartiene all’uomo, ma potrebbe essere una buona base di riflessione per proposte ancora più valide. Dopotutto se il nostro sistema fiscale è basato su la DICHIARAZIONE del proprio reddito, è ovvio che lo stato dovrebbe mettere in moto dei meccanismi affinchè questo venga fatto in maniera SPONTANEA, altrimenti dobbiamo imparare a convivere o con la paura di un controllo fiscale o con l’evasione.
Alberto.
venerdì 21 ottobre 2011
#
La realizzazione di un progetto di rilevazione presenze dei dipendenti (meglio conosciuti come marcatempo) non è che presenti difficoltà particolari poichè la materia è stata abbondantemente sviscerata e acquisita. Quello che noi vogliamo realizzare è un progetto di stretta interazione tra periferiche di rilevazione e software gestionale interamente sviluppato da noi. Ecco il perchè della scelta di NetDuino, una board ottimale per le nostre esigenze. I progetti principali sono due: il progetto NetDuino e l’applicazione client VB.NET di gestione dati e periferiche.
Analizziamo quelle che devono essere, secondo le specifiche, le funzionalità delle periferiche di rilevazione presenze.
- Devono poter lavorare in modalità stand-alone (non collegate direttamente ad un host).
- Devono fornire una semplice interfaccia utente di facile lettura e gestione.
- Devono poter fornire all’utente la possibilità di indicare le causali di ingresso e di uscita al momento della registrazione.
- Devono utilizzare la tecnologia RFID.
- Devono comunicare, su richiesta dell’host, i dati memorizzati.
Ovviamente la scelta della composizione hardware della periferica è strettamente definita dalle specifiche, per cui vediamo di analizzare come sono state implementate le singole richieste.
Lavorare in modalità stand-alone significa che la periferica deve memorizzare i dati localmente per cui deve essere munita di un supporto di memorizzazione. Netduino ha la possibilità di installare a bordo una MicroSD, noi abbiamo scelto il taglio minimo oggi in commercio ovvero 2GB, abbondantemente sufficienti per la nostra applicazione. Oltre all’aspetto di memorizzazione, per un sistema di controllo presenze è importante poter memorizzare la data/ora della transazione. Sfortunatamente Netduino non presenta a bordo un RTC (Real Time Clock) per cui l’abbiamo aggiunto esternamente come spiegato in questo post. Lavorare stand-alone significa anche che la periferica deve essere in grado, una volta configurata, di conoscere in autonomia tutti i dati sufficienti a fare il proprio lavoro, anche in questo caso la MicroSD a bordo ci viene in aiuto permettendo di memorizzare un file di configurazione e di caricarli all’avvio della periferica.
Per avere un’interfaccia utente semplice e di facile lettura la nostra scelta si è orientata su un display a caratteri di 2 righe x 16 colonne dettato principalmente dalle ridotte dimensioni della scatola di contenimento della periferica, ma sufficiente per gestire le informazioni necessarie. Oltre al display sono stati aggiunti 2 Led (uno rosso e uno verde) per la segnalazione immediata di eventuali anomalie di memorizzazione delle transazioni, un buzzer che indica l’avvenuta lettura del badge RFID ed un pulsante per lo scrolling delle causali di ingresso e di uscita.
L’uso della tecnologia RFID è dovuto alla semplicità di utilizzo di questo tipo di tecnologia, questo è stato oltremodo possibile alla presenza sul mercato di uno shield in scatola di montaggio molto completo.
La comunicazione all’host dei dati memorizzati avviene tramite la rete Ethernet utilizzando i l’interfaccia di rete embedded di Netduino Plus, oltre che allo sviluppo di un semplice protocollo di interrogazione da parte dell’host Windows. Questo protocollo definisce delle semplici richieste inviate alla periferica, la quale risponde inviando dati. Le richieste sono le seguenti:
- Are You Alive –-> Verifica se la periferica è in grado di comunicare
- Clear Display Screen –-> Cancella il contenuto del display
- Delete Log File –-> Chiede alla periferica di cancellare il file dei LOG all’interno dell’ SD
- Get Access Log –-> Chiede alla periferica di inviare il file dei LOG
- Reset Device –-> Chiede alla periferica di auto-resettarsi.
- Set RTC Clock –-> Chiede alla periferica di impostare l’orologio interno
- Switch Led On –-> Chiede alla periferica di accendere uno dei 2 LED (rosso o verde)
- Write Configuration File –-> Invia alla periferica i dati di configurazione
- Write Display 1 Row –-> Chiede alla periferica di scrivere un testo sulla prima riga del display
- Write Display 2 Row –-> Chiede alla periferica di scrivere un testo sulla seconda riga del display
Ovviamente, essendo il progetto alla sua prima release, il protocollo per adesso espone le funzionalità base ma che sicuramente saranno in futuro da sviluppare ed implementare ulteriormente.
Nei prossimi post vedremo come queste funzionalità sono state modularizzate in un software.
A presto,
Alberto
giovedì 20 ottobre 2011
#
La programmazione di piccoli device mi ha sempre affascinato ed immaginate la sorpresa quando ho letto che era disponibile la programmazione del Micro Framework per Visual Basic. Dopo essermi “scornato” con la mancanza di esperienza diretta nel settore e aver ricercato on line la soluzione più adatta al mio progetto, sono finalmente riuscito a costruire un device completo per la rilevazione presenze tramite RFID. Questo il primo prototipo:
L’ho costruito utilizzando i seguenti componenti:
Un’enclosure per arduino della Adafruit
Un kit RFID in scatola di montaggio della Futura Elettronica basato sul reader RFID ID-12 della Innovations. Ottimo kit che, oltre che al lettore RFID, ha a bordo un Buzzer, due Led di segnalazione, un relais di potenza (per aprire una porta, un tornello e altro) ed un pulsante di input gestibile che io ho utilizzato per gestire le causali di ingresso e di uscita.
Un Real Time Clock per memorizzare data e ora di ogni singola transazione.
Un Display seriale 2X16 caratteri per gestire un minimo di info lato utente.
ed, ovviamente una scheda Netduino Plus con a bordo una Micro SD da 1 GB per i LOG dei passaggi.
Il tutto pilotato da un’applicazione MF scritta in Visual Basic che si collega tramite socket ad un’applicazione Desktop utilizzata per la configurazione delle singole periferiche e per la gestione del Log delle transazioni.
In un post successivo descriverò più approfonditamente le applicazioni software.
A presto,
Alberto
domenica 21 agosto 2011
#
Aspettavo con ansia l’uscita di “Mango” la nuova versione del S.O. per il mio smartphone Windows Phone 7. Moltissime sono le novità introdotte da questa versione, per adesso sempre in beta, ma disponibile per i developer che intendono avvantaggiarsi nello sviluppo di soluzioni che utilizzano le nuove caratteristiche messe a disposizione dal Team di sviluppo. Per quanto mi riguarda l’interesse maggiore l’ho avuto nei confronti dell’introduzione dei Socket. A dire il vero (e questo secondo me è il punto di forza del .NET Framework) non ho dovuto imparare niente di nuovo ma soltanto implementare anche per WP7 le funzionalità che già utilizzavo in altri tipi di applicazioni (Desktop, WPF, Micro Framework e Silverlight). Ovviamente non sempre tutte le funzionalità esposte dalla versione più completa del framework (attualmente la 4.0) le troviamo nella loro completezza anche in framework ridotti e destinati a piattaforme diverse da quella PC, ma generalmente non ci scostiamo mai molto dalla versione di riferimento.
Quello che ho voluto implementare in versione demo è l’utilizzo dei socket per inviare a un PLC domotico dei comandi Modbus RTU standard, che mi permettano di modificare un registro del PLC, il quale comanda un relais di accensione delle varie luci dell’ufficio. Per approfondire i vari standard si rimanda ai seguenti riferimenti:
PLC –>http://it.wikipedia.org/wiki/Programmable_logic_controller
ModBus –> http://it.wikipedia.org/wiki/Modbus --> http://www.modbus.org/
In parole povere quello che devo fare consiste nel costruire un Array di Byte di dati secondo lo standard ModBus RTU e trasmetterlo al PLC via Socket, indicando qual’è lo status del registro da impostare. Siccome i relais digitali del PLC sono stati impostati come fossero dei semplici pulsanti (premo—> accende—>premo—> spenge—>premo—>accende—>premo—>spenge…) dovrò indicare sempre e comunque al registro del relais digitale di impostare il proprio status su True (equivale a dire premo il pulsante) poichè il PLC è programmato in modo che se un registro digitale alza il proprio bit di accensione, dopo aver eseguito il comando, il PLC automaticamente resetta lo status del relais digitale abbassando il bit, proprio come accade ad un pulsante fisico che ritorna nella posizione di spento. Se il PLC non fosse stato programmato in questo modo, avrei dovuto manualmente inviare un secondo comando ModBus per resettare il bit del relais digitale. Ovviamente il mio impianto domotico prevede alcune periferiche collegate tra di loro come il seguente schema:
L’utilizzo di questo tipo di Hardware prevede l’invio del comando ModBus utilizzando il protocollo UDP per cui l’utilizzo del socket si limita esclusivamente all’invio dell’Array di Byte generato dalla mia classe di gestione del protocollo ModBus (che non indico in questa sede) attraverso un oggetto Socket:
Private Sub SendPacket(PLCIPAddress As String, Port As Integer)
Dim Client As New Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp)
Dim Packet As Byte() = ModBus.GetModBusBuffer(…)
If Client IsNot Nothing Then
Dim socketEventArg As New SocketAsyncEventArgs()
Dim Addr As IPAddress = IPAddress.Parse(PLCIPAddress)
socketEventArg.RemoteEndPoint = New IPEndPoint(Addr, Port)
AddHandler socketEventArg.Completed, AddressOf SendComplete
socketEventArg.SetBuffer(Packet, 0, Packet.Length)
Client.SendToAsync(socketEventArg)
End If
End Sub
Private Sub SendComplete(sender As Object, e As SocketAsyncEventArgs)
If e.SocketError <> SocketError.Success Then
‘Gestione eccezioni di comunicazione
End If
End Sub
Ovviamente il tutto è visto in maniera alquanto semplificata poichè numerose sono le implementazioni che possiamo introdurre, prima tra tutte, ad esempio, la lettura dello status di un registro, ovvero verificare se la luce è accesa o spenta, inserire un dimmer e regolare l’intensità della luce attraverso uno slider, gestire il termoregolatore per alzare o abbassare la temperatura della stanza, ecc.. ecc..
Tutto questo probabilmente sarà oggetto di altri post in merito al building automation per adesso spero di aver reso l’idea di quanto possa essere semplice sviluppare applicazioni apparentemente complesse e quanto elevate sono le opportunità di business create dalle tecnologie Microsoft.
Se volete vedere il programma in azione:
Interagire con le periferiche di Building automation utilizzando il cellulare.
Alberto.
mercoledì 10 agosto 2011
#
Convertendo un progetto da VS 2008 a VS 2010 si è manifestato un errore relativo all’utilizzo della libreria Interop.Excel.dll. In VS 2008 Quando impostavo il valore della formula di una cella ad una particolare funzione utilizzando la sintassi
Range.Formula = “=SOMMA.SE(…”
tutto funzionava perfettamente. In VS2010, invece mi viene sollevata l’eccezione HRESULT 0x800A03EC. Andando per tentativi ho trovato la soluzione impostando non la proprietà FORMULA bensì la proprietà FormulaLocal che tiene conto anche della Culture della sintassi della Formula in relazione alla culture del foglio di Excel caricato.
Range.FormulaLocal=”=SOMMA.SE(…”
Non capisco perchè, però, con VS 2008 funziona ugualmente… 
Alberto.
lunedì 8 agosto 2011
#
Oggi ho finalmente terminato di scrivere la prima versione di “Riff-Raff” un’applicazione scritta con il MicroFramework per l’automazione domotica ed i servizi casalinghi. Basata sulla scheda Fez-Cobra della GHI Electronics in box OEM con pannello touch-screen da 3.5’’. “Riff-Raff” è un’applicazione che permetterà all’utente di gestire le utenze domestiche (accensione e spegnimento delle luci, gestione della temperatura, sistema antiintrusione, ecc…) interfacciandosi con l’Home PLC prodotto dalla Net Building Automation o con qualsiasi PLC che implementi il protocollo ModBus RTU attraverso la rete LAN. Oltre a questo, sono state aggiunte altre funzionalità di gadgeteer come, ad esempio, la visualizzazione delle news, le previsioni del tempo e altro. Il progetto è ancora abbastanza acerbo ed in fase di sviluppo, ma già dalle immagini che allego è possibile capire di cosa si tratta.
Le impostazioni della periferica vengono gestite attraverso un file XML memorizzato a bordo della SD che poi viene inserita nell’apposito slot della scheda, è previsto, in futuro, di gestire le impostazioni anche attraverso socket scrivendo direttamente nella SD della periferica collegata via LAN. Questi alcuni screenshot del programma di configurazione che al momento utilizza Yahoo API per la visualizzazione delle condizioni e delle previsioni del tempo.
Alcuni screenshot dell’applicazione e della scheda:
La pagina principale:
La pagina del meteo:
La pagina di gestione delle luci (accende/spenge):
La pagina delle news:
La pagina dell’orologio e della temperatura:
Se qualcuno ha qualche curiosità in merito sul progetto e sui suoi sviluppi non esiti a conttarmi.
Ciao,
Alberto
mercoledì 3 agosto 2011
#
A questo indirizzo: http://research.microsoft.com/en-us/um/redmond/projects/kinectsdk/download.aspx è disponibile un aggiornamento del Kinect SDK Beta 1 per Windows.
Alberto.