Oggi le 3Domande sono per Gianni Valdambrini, relatore al prossimo Better Embedded di Firenze. Sviluppatore su sistemi embedded, esperto in Python, C++ e Qt. Attualmente Team Leader/Project Manager in Develer.
Gianni: Sono laureato in Informatica a Firenze nel 2004 e da allora ho iniziato a lavorare come sviluppatore software prima e come team leader/project manager dopo, principalmente utilizzando Linux e tecnologie open source.
Lavoro per Develer dal 2007, periodo nel quale ho lavorato con varie tecnologie per desktop e disposivi embedded, realizzando applicazioni in Python, C++ e Qt (di cui sono anche sviluppatore con la più alta certificazione). In questo periodo mi sono occupato anche di formazione a vari livelli, sia come tutor nell'ambito di stage che come docente per corsi di formazione a ditte/professionisti.
Gianni: Il talk, chiamato Qt Everywhere, presenterà Qt, framework per la realizzazione di applicazioni grafiche e non basato su C++ ed esporrà i motivi per cui tale framework si rivela particolarmente adatto per lo sviluppo di applicazioni embedded. Inoltre verrà discussa brevemente l'evoluzione che Qt ha subito negli ultimi anni, delle potenzialità offerte da Qt Quick e di come cambierà nel futuro a breve/medio termine ciò che Qt ha da offrire agli sviluppatori.
Il traning, intitolato Qt Quick: GUI di nuova generazione per desktop e Raspberry Pi, avrà invece un taglio più tecnico, e si propone l'obbiettivo di realizzare da zero un'applicazione utilizzando Qt Quick, la nuova tecnologia offerta da Qt per realizzare applicazioni fluide.
La stessa applicazione verrà eseguita quindi su desktop e su Raspberry Pi, il mini-computer basato su ARM e Linux divenuto famoso per essere una soluzione embedded di medio-alto livello al prezzo di 25$.
Quanto pensi sia reale questa problematica e cosa suggeriresti in merito ad uno sviluppatore Junior?
Gianni: Non credo che la diffusione di prodotti come Raspberry Pi o Arduino impoveriscano il settore, tutt'altro. Nella mia esperienza infatti queste schede pre-confezionate sono ottime per avvicinarsi al mondo embedded, permettendo agli sviluppatori di imparare alcune delle tecnologie e affrontare alcune delle problematiche che si incontrano tipicamente in questo ambiente.
Ma tutto questo non rappresenta un impoverimento per la vera e propria soluzione industriale perché in quel caso diventa forte l'esigenza di personalizzare l'hardware e di conseguenza il software, andando a gestire sensori e periferiche sempre nuovi e diversi.
Per fare un esempio conosciuto a tutti, l'iPhone dalla versione 3 aveva a bordo un ricevitore GPS e un accelerometro, ai quali è stato aggiunto un giroscopio con l'iPhone 4.
Per chi volesse approcciarsi al mondo embedded per la prima volta consiglio quindi assolutamente di acquistare uno di questi prodotti low-cost e iniziare a "giocarci": senza accorgersene si saranno fatti un po' di esperienza che si rivelerà utile nella progettazione/programmazione di applicazioni embedded vere e proprie.
Gianni, ti ringrazio anche pubblicamente dell’intervista, credo molto utile a molti.
Vorrei quindi approfondire il discorso generato dalla terza domanda, cercando di far comprendere meglio i miei timori.
Partendo da un problema noto come “il paradosso dell’automazione” ed applicandolo agli sviluppatori, le mie preoccupazioni sono relative al fatto che la figura del programmatore stia diventando sempre più automatizzata con i “blocchetti” pronti solo da assemblare piuttosto che di conoscitori delle problematiche a basso livello. Certo non stò dicendo che ogni volta si debba riscrivere un driver già funzionante, ma che, aiutato anche dalla diffusione di schede semplicistiche anche nelle scuole, si pensi sempre meno a “cosa c’è dietro” il famoso blocchettino che lo copi/incolli e funziona.
Cercherò di essere più chiaro facendo un esempio con Arduino:
Arduino è grandioso, ideale per tutti quelli che vogliono dotare qualsiasi cosa di automatismi elettronici senza essere appunto degli elettronici.
Ma Arduino di programma attraverso una IDE apposita che si basa su Processing, diciamo un simil C++ e questo per un micro Atmel ad 8bit non è certo il massimo.
Significa che non ho per niente il controllo di quello che accada in memoria, ad esempio.
Allora se nelle scuole Arduino viene spiegato come una scheda con micro Atmel e con IDE AVRstudio che tramite Jtag mi permette di programmare e debuggare in Assembler ed in C allora è un conto. Poi gli studenti possono anche trovare le scorciatotie del C++ e dei blocchetti (vabbè sketch) già preconfezionati. MA se li abituiamo invece solo a quest’ultima soluzione, poi arriverà il bel giorno che lo sketch o la somma degli sketch vada in conflitto ed allora CHI sarà in grado di mettere mano al sorgente assembler?
Non c’è il rischio di un contagio, anche in questo settore, del paradosso dell’automazione?