Programmazione

Lo dico subito, da App Inventor 2 mi sarei aspettato molto di più. Sarà per la sua origine (Google), sarà per chi lo sviluppa attualmente (il MIT), pensavo fosse molto più rifinito e facile da usare di quanto sia in realtà. Con App Inventor 2 (da ora in poi AI2) lo sviluppo dell’interfaccia grafica e del codice a blocchi di una applicazione viene effettuato interamente nel browser web, ma per eseguirla bisogna compilare ogni volta l’applicazione e trasferirla su un cellulare o un tablet Android.

Il modello di programmazione tradizionale si basa sulla scrittura di codice sorgente secondo una struttura logica e ad una sintassi ben definita e dipendente dal linguaggio di programmazione prescelto. L’idea di sostituire questo modello con uno fondato su una interfaccia grafica sulla quale trascinare dei blocchi funzionali predefiniti, manipolandoli ed assemblandoli l’uno all’altro quasi fossero dei mattoncini del LEGO, data dalla fine degli anni ‘80 a livello commerciale e si basa su ricerche iniziate già negli anni ‘60. Questo cambio di paradigma aveva l’obiettivo di rendere la programmazione accessibile anche ai non iniziati, permettendo di insegnarne i rudimenti già ai bambini della scuola elementare.

Perché mai un utente del Mac dovrebbe voler usare un emulatore di Android sotto OS X? Innanzi tutto perché è divertente. E poi Android è il principale concorrente di iOS sulle piattaforme mobili ed è utile conoscerlo e confrontarne i pregi (pochi, ma ce ne sono) e i difetti (parecchi) con quelli di iOS.

Ogni volta che scrivo un post per questo blog mi sforzo di esporre l’argomento trattato nel modo più chiaro possibile e di presupporre che chi legge non sappia nulla, o quasi, dell’argomento trattato. L’aspetto negativo di questo atteggiamento è che mi obbliga a ripetere continuamente il significato di alcuni termini fondamentali, correndo il rischio di far perdere il filo del discorso a chi conosce già il significato di questi concetti e appesantendo il tono generale del post.

Questo blog spegne oggi la sua prima candelina virtuale con il centesimo post. Una coincidenza non casuale ma niente affatto pianificata.1 Un anno fa non avrei mai potuto pensare di riuscire a scrivere tanto. È stata una bella fatica, ma allo stesso tempo una sfida divertente. Che ha messo a dura, durissima, prova la mia capacità di spiegare qualcosa in modo comprensibile. Spero qualche volta di esserci riuscito.

L’algoritmo del Crivello di Eratostene è stato implementato in almeno 103 linguaggi diversi, alcuni decisamente curiosi o esoterici. Chi ha mai sentito parlare di AutoIt, Bracmat, M4, Nimrod o zkl? Manca una implementazione in Blockly, un linguaggio di generazione di codice visuale a blocchi. Blockly è stato sviluppato da Google e deriva da Scratch, StarLogo TNG e SNAP!, linguaggi di programmazione didattici rivolti soprattutto ai programmatori più giovani, e anche da AppInventor, un linguaggio più avanzato con cui si possono sviluppare applicazioni per Android.

Caught me crawlin’, baby, Crawlin’ ‘round your door, Seein’ everything I want, I’m gonna crawl on your floor. – The Doors, Crawlin’ King Snake. Nel post di qualche mese fa, Setacciare numeri con il serpente, avevo preso lo spunto da un semplice programma che calcolava i numeri primi mediante il famoso Crivello di Eratostene, traducendo il programma dal BASIC originale in Python, che considero il linguaggio di programmazione più interessante, oggi.

Dopo i programmi di derivazione Unix, at e cron, è la volta di parlare di launchd, una soluzione sviluppata dalla Apple per OS X. Launchd Launchd è il programma che, a partire dalla versione 10.4 (Tiger) di OS X, esegue tutti i processi di avvio del sistema operativo e che, come se non bastasse, può anche svolgere i compiti eseguiti da cron.

Nella prima parte di questa serie abbiamo visto come usare il comando at per automatizzare determinate attività sul Mac dal Terminale. At è utile ogni volta che si vuole eseguire un comando automaticamente una sola volta e in un momento ben definito Ma at ha anche parecchi limiti e non è adatto a svolgere una attività periodica in modo trasparente, come richiesto da Lucio Bragagnolo nel post da cui ha preso spunto questa serie.

Qualche giorno fa Lucio “Lux” Bragagnolo ha pubblicato sul suo interessantissimo blog (da seguire assolutamente ogni giorno!), un post in cui poneva una domanda molto stimolante. Lascio a lui la parola per descrivere il problema: Octopress – il motore di questo blog – si basa su una cartella che risiede nel Mac. La cartella contiene sottocartelle varie che ospitano i pezzi del blog. Pubblicare questo articolo significa creare un file e metterlo nella giusta cartella, per poi dare un comando di Terminale che genera una edizione aggiornata del blog e un altro comando di Terminale che deposita una copia dell’edizione dentro il server di pubblicazione. Spesso mi trovo a scrivere pezzi per il blog su iPad, lontano da Mac. Facciamo finta che il Mac rimanga irraggiungibile fisicamente per tutta la giornata. Qual è la strategia che richiede meno lavoro in assoluto per pubblicare il pezzo?