Heroku

Mi sono divertito a vedere alcune soluzioni "Cloud", e cercare di capire punti di forza e debolezza.
Fra tutte quella che per ora preferisco è Heroku, una soluzione che è focalizzata sullo sviluppatore, cercando il più possibile di nascondere la parte infrastrutturale.
Diciamo che è molto semplice mettere su un'applicazione con un db e una WebApp (Tomcat ad esempio). Tutto gira in containers attraverso una runtime. Tutto (configurazione, load balancing, logging, sicurezza) è gestito dall'infrastruttura e completamente trasparente all'utente.
Tutto quello che il team di sviluppo deve fare è sviluppare l'applicazione: alla messa in produzione ci pensa Heroku.
I linguaggi supportati sono molteplici: Java in primis, Php, Node.js, Ruby, Python per citare i più conosciuti. Al momento non è ufficialmente supportato C# ed il Framework .Net, anche se sembra che sia possibile deploiare applicazioni di questo linguaggio (con .Net Core)
Il modo più semplice per deploiare le app è attraverso Git con un semplice comando, anche se è possibile deploiare direttamente un war.
Questi due approcci sono totalmente antitetici: io personalmente preferisco il secondo, perchè posso creare il war, magari pubblicarlo su un repository Maven, ed essere sicuro di poterlo pubblicare "as is" su un ambiente di produzione alla fine di un ciclo di test e Q.A. approval.

Arduino in the real world: Controllino

E finalmente Arduino va nel mondo reale, con una soluzione già pronta per essere installata!
http://controllino.biz/

.Net [DllExport]

Dovendo lavorare con codice Legacy (o vintage se vogliamo...) cerco, quando posso, di riscrivere alcune funzionalità con linguaggi più moderni, o semplicemente di fare cose che non si potevano fare al tempo.
Finora, per fare un bridge tra C, Delphi, PowerBuilder e qualsiasi altro linguaggio legacy e magari un C#, ho sempre usato le interfacce COM, creando librerie in C# che esponessero l'interfaccia COM al resto del mondo.
Poi mi hanno fatto vedere che qualche santo ha trovato il modo per i linguaggi che girano su framework .Net (quindi C#, VB#, F#) di esporre funzioni come se fossero vere e proprie dll.
Il progetto si chiama DllExport e il suo uso è molto semplice: sulla funzione che si vuole esportare basta apporre l'annotazione [DllExport].
In fase di compilazione viene aggiunto uno step alla catena (per queste cose, tanto di cappello al copilatore ILASM), che fa in modo che la dll che si crea non solo rispetti la mappa degli assembly .Net, ma anche quella delle dll (vedi qui)
La dll risultante portà quindi essere vrappata come una cara, vecchia dl: ovviamente per funzionare necessiterà del Framework .Net, è ovvio.
Un solo accorgimento: la compilazione dell'assembly non può avvenire per AnyCpu, ma è obbligatorio farla per x86 o x64

Grazie al mio omonimo per la dritta, mi ha aperto un mondo.

Markdown to Html and Pdf

Da poco ho scoperto Markdown, un modo comodissimo di creare documenti in stile Meta-Html, ma molto più semplice da editare.
Tra l'altro, Markdown è il formato di default supportato nei sistemi di source control come GitHub (ecco cos'è quel README.md !)
Vi lascio ad uno studio approfondito sulla sintassi, che è molto facile da imparare e permette una buona composizione del testo.
Siccome mi sono appassionato a questo modo di creare la documentazione, mi sono chiesto se, una volta creati documenti in Markdown, non ci fosse un modo per trasformarli in Html e, perché no, Pdf.

Convertire i Markdown in Html e Pdf

Dal sito di Markdown viene espressamente detto che Markdown è sia una sintassi che un tool per convertire le pagine in Html. E quindi la prima conversione è "compresa nel prezzo".
Ma ci sono altri tool di conversione?
Cercando di rispondere alla domanda ho trovato questo articolo, che da una serie di tools, sia on-line che locali, che possono fare al caso.
La soluzione più completa, per convertire Markdown in HTML, Pdf e altri 1.000 formati, sembra essere Pandoc

Jenkins, primi approcci

Cos'è?

Jenkins è un automation server.
Serve quindi per automatizzare task ripetitivi. In particolare è usato per fare il build e il deploy di qualsiasi progetto.

Perché usarlo?

Diciamo che, al primo approccio, me lo sono chiesto anch'io. Cosa può fare Jenkins più di me nel compilare, testare, impacchettare e deploiare un progetto?
In realtà nulla, ma lo fa continuamente e sempre allo stesso modo.
Mi spiego meglio. Le fasi di costruzione di un software di solito sono, dopo la scrittura del codice, la compilazione, (forse) il testing automatico, l'impacchettamento e il deploy (almeno in ambiente di test).
Supponiamo di avere un repository dei sorgenti (Git) e che tutte queste fasi, sulla nostra macchina, funzionino.
Facciamo il commit dei sorgenti e scateniamo il nostro server Jenkins, che sta su una macchina diversa da quella di sviluppo.
Il Job inizia quindi a scaricare i sorgenti e a compilarli, e già qui il processo si blocca perché sembra che manchi un sorgente: ci siamo infatti dimenticati di committarlo, la cosa più normale e che capita con più frequenza (il telefono ha squillato, il collega ci ha chiesto qualcosa, è arrivata una mail urgente, sappiamo tutti come funziona...)
Ecco quindi che Jenkins ha individuato il primo problema, e via via così per tutte le fasi di gestione del nostro software.
Il testing automatico poi è quella fase in cui magari dobbiamo anche avviare una V.M. o un Docker con un db pronto: Jenkins può fare anche questo, sia con plugin dedicati (ce ne sono un fantastiliardo per tutte le esigenze), che lanciando batch o powershell da noi scritti ad hoc.

E ovviamente, può inviarci mail sullo stato del job, se è finito bene, male, con quali errori e in quanto tempo.

Tutto questo aumenta la qualità del nostro codice.
Ovviamente, per il testing, sta a noi implementare un set esaustivo di test: Jenkins non è intelligente, è solo instancabile.

Limiti

Ovviamente non è tutto oro quello che luccica: ho sperimentato Jenkins con .Net, una strana coppia direi, e proprio qui ho visto qualche limite.
In particolare esiste un plugin per compilare via MsBuild, e funziona bene finché si creano build di tipo generico, ma non sono riuscito ad usarlo nelle pipeline (flussi di build), che invece sarebbero stati perfetti per le mie esigenze.

C++ con Visual Studio Code

Cercando un'alternativa per un IDE di sviluppo in C++, mi sono imbattuto nell'articolo di Microsoft su come programmare in C++ con Visual Studio Code

Per questo IDE è stato creato un plugin alla stessa Microsoft che consente l'intellisense del codice.
Il plugin però, come ben specificato, non contiene built-in alcun compiler o debugger, che devono essere installati separatamente.
Non è necessario che il compilatore sia quello Microsoft, anche se il plugin è già pronto a lavorare con questo (ovviamente solo su Windows, non su Linux o Mac), ma possono essere usati anche altri compilatori come ad esempio MINGW, e proprio con quello ho fatto una prova per vedere se tutto funzionava correttamente.

Diciamo subito che non è tutto automatico, tanto che ho dovuto, seguendo le istruzioni, creare sia il file c_cpp_properties.json che il tasks.json per poter compilare. Però, una volta fatto, tutto si risolve con un semplice CTRL+SHIFT+B e la compilazione è fatta!

Certo, una volta compilato, sarebbe bello poter debuggare. Niente di più semplice! Il file launch.json, nel folder .vscode, contiene appunto tutte le configurazioni necessarie per poter debuggare.
Anche in questo caso, seguendo l'articolo, che rimanda alla documentazione del plugin, sono riuscito a creare una configurazione perfettamente funzionante. Anch qui, non è automatico per i nabbi, ma una volta capito il meccanismo il pattern è replicabile all'infinito.

A questo punto sono diventato curioso: e se volessi fare il build tramite makefile?
Il gioco è concettualmente lo stesso: il file tasks,json contiene le configurazioni di progetto: basta modificarlo o aggiungere nuovi task per ottenere il risultato voluto.
Nel mio caso ho modificato il task di build nel seguente modo:

{
  "taskName": "build",
  "type": "shell",
  // "command": "g++",
  "command": "mingw32-make",
  "args": [
    //"-g", "-o", "helloworld", "helloworld.cpp"
  ],
  "group": {
    "kind": "build",
    "isDefault": true
  }
}

In questo modo il task build chiama, invece di g++ con i parametri, il maker: chiamandolo senza parametri il processo cerca ovviamente il file di default, cioè makefile.

E quindi direi che Visual Studio Code potrà essermi molto utile per i miei piccoli esperimenti in C++.

La fine di Windows 10 Mobile

Microsoft ha deciso che il mobile non è più nei suoi piani, ed infatti dismette anche l'idea Windows 10 Mobile.
Ce ne faremo una ragione.

http://www.lastampa.it/2017/10/09/tecnologia/news/microsoft-chiude-lera-di-windows-mobile-negli-smartphone-la-lotta-tra-android-e-ios-fgITmf6MuEsPn0vEbg908O/pagina.html

Powershell

Dalla Home Page di PowerShell:

PowerShell è una piattaforma di automazione e un linguaggio di scripting per Windows e Windows Server che permette di semplificare il management dei sistemi. Diversamente da altre shell, PowerShell sfrutta la potenza del Framework .NET, mettendo a disposizione oggetti e un set di funzionalità per poter controllare i sistemi Windows.

In pratica, se avete bisogno di automatizzare i vostri server (incluse automatizzazioni di build) PowerShell è ciò che fa per voi.

Recentemente MicroSoft lo ha reso open source, assieme a .Net Core

PowerShell si usa in maniera molto simile ad un bash, permettendo l'esecuzione di comandi non solo da linea comandi, ma anche da file.
Sempre come bash, i comandi posso essere concatenati tramite una pipeline, per cui l'output di un comando diventa l'input del successivo.

Proprio per la sua natura di linguaggio di scripting è possibile creare intere librerie di funzioni, permettendo una grande riusabilità.
Ad esempio ci sono intere librerie di comandi sia per Azure che per AWS, permettendo di automatizzare la maggior parte dei task.

Nelle funzioni è possibile accedere a tutto il framework .Net, permettendo così una buona estensibilità.

Se scrivere una funzione non fosse poi sufficiente, è possibile creare estensioni in C#, dette CmdLet, che possono assolvere a compiti più complessi o interfacciarsi direttamente con dll o quant'altro.

Arduino: splittare il programma in più sorgenti

Prima di dire come splittare un programma Arduino in più sorgenti è necessario capire come funziona il processo di build dei sorgenti.
In particolare, il preprocessing concatena tutti i files .ino nella directory, e crea un singolo file con estensione .cpp.
A questo file viene aggiunta la direttiva #include che contiene tutte le librerie necessarie ad Arduino.
Quindi, volendo aggiungere un altro sorgente al principale, basta aggiungere un file .ino nella directory, e il compilatore farà il resto.
In alternativa, se si sta usando l'IDE Arduino, per aggiungere un nuovo sorgente basta fare click nell'angolo in alto a destra e selezionare "New Tab" (come descritto qui)
Se invece si usa un IDE tipo AtmelStudio tutto questo processo viene a cadere, perché i sorgenti non hanno più l'estensione .ino, ma sono puri e semplici files .cpp, e ci sarà un makefile esplicito che farà la compilazione.

Arduino: comunicare via seriale

Tutte le schede Arduino hanno a bordo almeno una porta seriale.
Questo è uno tra i sistemi più usati per colloquiare con l'esterno.
Proprio per questo motivo la libreria che gestisce la scheda seriale è integrata nella libreria di base (Arduino.h)
Il principio della seriale è semplice: nella funzione setup() va inizializzata ed aperta tramite la funzione Serial.begin(): a quel punto è possibile leggere e scrivere sulla seriale. Per un semplice e veloce debug è possibile usare il monitor seriale presente sull'Arduino IDE.
Quindi, oltre la funzione begin(), le 2 funzioni più usate sono print() e read()

Arduino: linguaggi e tool alternativi

Oltre che con Arduino IDE, è possibile scrivere programmi per Arduino con vari IDE.
Alla fine, è sempre C++ !

Dal sito, si ha una bella lista di Dev Tools, gratuiti e non, open o meno, con cui sbizzarrirsi.

Personalmente ne ho provati vari, ma quello che preferisco è Atmel Studio.
Atmel è il produttore dei chip che vengono montati su Arduino: questo già mi da la garanzia che il compilatore farà il suo dovere.
L'IDE è basato su Visual Studio 2015, e questo già da un'interfaccia conosciuta agli sviluppatori C++, e un buon debugger.

Ovviamente, per semplici progetti Arduino IDE è perfetto, facile, light, con un sacco di librerie pronte da usare, ma quando si passa a far cose più complicate per sfruttare a pieno la potenza della nostra board, penso che Atmel Studio sia quello che fa al caso.
E ci fa anche capire quello che Arduino IDE maschera, cioè il main loop!

Spring configuration e Spring Boot

Giocando con Spring Boot mi sono accorto che le configurazioni vengono fatte attraverso Spring Configuration.
Finora io, vecchio informatico, ho sempre configurato Spring tramite file Xml: questo approccio è sempre meno usato, proprio perché ormai, con l'avvento dei micro services, non si tende più a creare una singola applicazione monolitica dentro un web container (un file .war, tanto per capirsi).

Spring Configuration permette di esplicitare la configurazione via software: basta annotare le classi che costituiscono la nostra configurazione, ed automaticamente verranno caricati i beans corrispondenti. Qui il Javadoc

Una buona serie di esempi su come scrivere le varie configurazioni è disponibile qui. In particolare è interessante verificare come fare per iniettare le dipendenze.

Ora, quando si creano delle Controller, come si può fare a iniettare la dipendenza?
Le Controller in Spring Boot vengono automaticamente istanziate (qualsiasi classe che abbia l'annotation @Controller). In questo caso, come risolvere la dipendenza?
Si può usare l'annotation @Autowired in abbinamento con @Qualifier.
La annotazione @Autowired indica che la variabile verrà automaticamente valorizzata, e con @Qualifier si può esplicitare il nome del bean a cui associarla.
Se si omette il qualifier Spring cerca un bean con nome uguale a quello della variabile: qualora non lo trovi, o non sia del tipo corretto, lancia un'eccezione.
Per una panoramica su @Autowired e @Qaulifier si veda qui.

Arduino: prime impressioni

Ebbene si, mi sono fatto un Arduino.
Perché?, mi son chiesto. Perché volevo capire con mano come funzionava.
Ed eccolo qua, il mio bell' Arduino nuovo con il kit di Sunfounder!

E quindi, all'opera!
A parte il fatto che non so nulla o quasi di elettronica, ho usato i circuiti proposti negli esempi per capire come si potessero scrivere i programmi, e mi sono concentrato sulla scrittura dei programmi.
Ed ho installato Arduino IDE, come suggerito.
Fatto questo, tutto risulta molto semplice, lo scheletro di ogni programma risulta essere fatto di 2 funzioni

• void setup() che serve per inizializzare il programma
• void loop() che contiene il loop principale del programma

Ma.... e qui cominciano i ma...
supponiamo di voler controllare contemporaneamente 2 led, e di volerli far accendere e spengere con tempi diversi, come si può fare?
Facile, mi sono detto, si scrivono 2 thread ed ognuno controllerà un led in maniera indipendente!
Peccato che il processore di Arduino sia sfacciatamente monothread, e che quindi non sia assolutamente possibile scrivere programmi multithread in Arduino....

E allora che si fa?
La risposta si chiama protothreading: in pratica si simula il multithread attraverso un timer e usando funzioni che impegnino per poco tempo il processore.
Fortunatamente la documentazione di Arduino spiega molto bene come fare, vedi qui

Armato di questa conoscenza studierò un qualcosa di complesso da mettere su, e vedrò quali difficoltà si possono incontrare strada facendo