Editor on Melabit

Antigravity: un driver scritto dall'IA

Wed, 04 Mar 2026 18:00:00 +0000

Fra tutti i modelli di Raspberry Pi e di Arduino con cui al momento passo la giornata, il mio preferito è senza dubbio il Raspberry Pi Pico, un microcontrollore piccolo ma potente, in grado di essere programmato non solo in C/C++ tramite l’IDE di Arduino, ma anche in MicroPython e CircuitPython, due versioni diverse (e concorrenti) di Python specifiche per i microcontrollori.

A differenza degli altri modelli di Raspberry Pi, il Pico non dispone di una connessione dedicata alla videocamera, ma può utilizzare quelle con interfaccia SPI,¹ come ad esempio la Arducam Mini 5MP Plus.

In teoria non dovrebbe essere un lavoro difficile. Dopo aver dato una occhiata alla documentazione ufficiale, si tratta solo di collegare la videocamera al Pico, scaricare il driver e i programmi di test dal repository GitHub del produttore, copiarli sul Pico dopo aver installato la versione di Python supportata, e infine provare a scattare qualche foto.

Non avrei potuto sbagliarmi di più.

Ci vuole un driver

Gli unici due programmi di di test disponibili, uno per Arduino e l’altro per CircuitPython, prevedevano di utilizzare Windows per visualizzare il video prodotto dalla videocamera, una cosa insolita dato che la stragrande maggioranza di chi lavora con questi dispositivi usa Linux o macOS. CircuitPython, poi, è meno diffuso di MicroPython, e io avrei preferito usare quest’ultimo per compatibilità con gli altri componenti già collegati al Pico.

Con un po’ di pazienza, e avendo a disposizione un programma che insegna ad usare le funzioni principali per gestire il dispositivo, si può provare a tradurre il codice CircuitPython in MicroPython (e viceversa),² ma in questo caso non c’era nulla del genere a disposizione.

Altra guide trovate sul web sembravano promettenti, ma alla prova dei fatti non funzionavano. L’unica opzione rimasta era quella di bypassare i tool ufficiali e di scriversi da solo un driver per la videocamera.

Una parola!

Io so come scrivere il codice per risolvere una equazione differenziale o per analizzare dei dati di misura. Me la cavo anche con la programmazione di microcontrollori ed affini per catturare i dati dei sensori collegati. Ma qui si tratta di ben altro. Si tratta di studiare nei dettagli come funziona a basso livello la comunicazione fra il Pico e la videocamera. Un lavoro da ingegneri specializzati, che scrivono i driver che poi permettono a noi umani di eseguire operazioni complesso come scattare una foto con poche righe di codice Python.

E allora perché non mettere al lavoro uno degli agenti integrati in Antigravity per fargli fare quello che io non sono capace di fare?

Non sarei stato obbligato ad usare Antigravity, anche Claude Code, Google Gemini, Deepseek o uno degli altri mille LLM che abbiamo a disposizione avrebbe potuto tranquillamente lavorarci su. Ma, come ho già scritto, usare uno degli agenti integrati in Antigravity permette di lavorare direttamente nell’editor e di accedere al sistema operativo sottostante, una vantaggio enorme quando si deve provare e riprovare mille volte il codice prodotto.

L’IA al lavoro

Quando si leggono tanti articoli entusiastici sul vibe coding, ovvero sullo sviluppo del software eseguito dall’intelligenza artificiale senza nessun intervento o quasi da parte del programmatore umano, sembra tutto facile (tanto per citarne qualcuno, questo articolo che ha avuto milionate di letture oppure questo senza dimenticare il tweet che ha iniziato tutto).³ In sostanza, scrivi due-tre righe chiedendo all’LLM o all’agente di turno di fare questo o quello, te ne vai a pranzo o a fare una passeggiata e quando torni è tutto pronto.⁴

Proviamo per una volta a fare lo stesso con Gemini, dandogli solo le informazioni essenziali e verificando cosa riesce a fare davvero. In questo caso queste informazioni si riducono al link alla pagina web della videocamera e a una tabella che descrive come sono collegati i pin della videocamera al Pico (sono più di tre righe, lo so, ma io sono prolisso).

Prompt

I have a Rasperry Pi Pico 2W connected to a Arducam 5MP Plus OV5642 Mini Module Camera Shield (https://www.arducam.com/arducam-5mp-plus-spi-cam-arduino-ov5642.html). I have connected the camera to the Pico using the standard layout found in the documentation:

Camera	CS	MOSI	MISO	SCK	GND	VCC	SDA	SCL
Pico	GP5	GP3	GP4	GP2	GND	3V3	GP8	GP9

Please write a basic Micropython code to test that everything is right and that the camera can take photos

Gemini ci lavora su furiosamente, tira fuori codice MicroPython che non funziona, si ingegna a correggerlo in base ai miei suggerimenti e finisce sempre per fare nuovi errori (dico sempre Gemini per semplicità, ma sono passato anche a Gemini 3.1 Pro, Claude Opus 4.6 e Claude Sonnet 4.6 via via che finivano i token).

A un certo punto, non sapendo più che pesci prendere, Gemini ipotizza anche che ci sia un problema hardware, come un collegamento sbagliato o una videocamera difettosa (ma interrogando i singoli pin della videocamera è facile verificare che tutto funziona correttamente).

Dopo ore ed ore di lavoro e dato che con MicroPython non riesce a combinare niente di buono, gli chiedo di passare ad Arduino, che è una piattaforma software più matura. Ci vogliono altre ore di lavoro ma alla fine, testardamente, ce la fa, e quella qui sotto è la prima immagine in assoluto scattata con il codice Arduino generato da Gemini (l’immagine originale era al contrario e io mi sono limitato a ruotarla di 180°).

Va detto che subito dopo faccio un errore gravissimo che mi, anzi ci, costringe a rifare tutto da capo. Ma questo è argomento di un’altra storia.

Epilogo

Una volta generato un programma funzionante in Arduino, chiedo a Gemini di rifare tutto per CircuitPython. Anche questo port richiede parecchie ore di lavoro, inframmezzate da un paio di riavvi forzati del Mac che, dopo qualche bug di troppo, è stato obbligato a disabilitare la comunicazione fra le porte USB e il Pico.

In teoria dovrei ripetere il ciclo per la terza volta con MicroPython. Ma l’idea di perdere chissà quanto altro tempo a guardare Gemini che lavora mi fa venire i brividi e lascio perdere, almeno per ora.

Conclusioni

Non so cosa usano quelli che scrivono gli infiniti articoli che proclamano che chiunque, anche se non sa un tubo di programmazione, può farsi scrivere dall’IA in poco tempo un programma perfettamente funzionante.

Anche se di programmazione ne so qualcosa, a me è successo solo per gli esperimenti più semplici descritti nei due articoli precedenti. E men che meno è successo in questo caso. Va detto, però, che sono in buona compagnia.

– Immagine generata da Google Gemini.

È vero, seguendo alla lettera i dettami del vibe coding, qui non ho scritto nemmeno una riga di codice e ho fatto eseguire a Gemini perfino i comandi di Terminale che potrei scrivere ad occhi chiusi. Ma è altrettanto vero che se non avessi dialogato di continuo con l’agente, se non lo avessi guidato passo passo, se non avessi corretto i suoi tanti tanti errori, a volte davvero banali, Gemini non sarebbe andato da nessuna parte.

E ci sono volute molte ore di lavoro ininterrotto, fin troppe ore secondo me, per ottenere qualcosa di utilizzabile.

Altro che programmazione rapida ed intuitiva. Altro che codice basato sulle buone vibrazioni stile anni ‘60. Altro che programmazione for dummies!⁵

Se non ti rimbocchi le maniche e non ti dai da fare in prima persona con il codice, anche quello prodotto da un agente più o meno intelligente, non vai da nessuna parte. Sarebbe bello essere smentito.

L’interfaccia SPI (Serial Peripheral Interface) è una interfaccia di comunicazione seriale, molto utilizzata per collegare un microcontrollore (master) ad uno o più dispositivi periferici (slave) in modo veloce ed affidabile. ↩︎
Mentre scrivevo l’articolo ho trovato questo video, che spiega come mescolare nello stesso script codice MicroPython e CircuitPython. Se funzionasse anche in casi più complicati di accendere e spegnere un LED sarebbe davvero una svolta. ↩︎
Sarà un caso che sono sempre post lunghissimi ma senza mai uno straccio di prova, un prompt, qualche brano di codice, dei link a supporto delle tante affermazioni non verificate e non verificabili? ↩︎
Mai nessuno, da vero nerd, dice che va a fare un po’ di sesso. ↩︎
Dal titolo di una famosa serie di guide introduttive agli argomenti più svariati, che spaziavano da come usare il DOS a come giocare a scacchi. ↩︎

Antigravity: dalla sorpresa al dubbio

Mon, 16 Feb 2026 18:00:00 +0000

Per quanto Antigravity sia efficace, scavando più in profondità ci si accorge che i sistemi ad agenti che agiscono al suo interno, per quanto servizievoli e capaci di rispondere in modo preciso a tante questioni complesse, non sono esenti dai soliti problemi di tutti i modelli linguistici di grandi dimensioni (LLM, Large Language Model) con cui abbiamo a che fare da tre anni a questa parte.

Vediamo alcuni esempi pratici.

– Immagine generata da Google Gemini.

Esempio #1

Dopo aver provato con successo ad estrarre i dati dalle immagini di un mio articolo, mi sono messo subito al lavoro per provare a applicare il metodo ad altre figure simili a quelle analizzate la prima volta, come ad esempio questa.

Obiettivamente, la figura è più complessa rispetto alle mie precedenti: nella parte superiore compare un istogramma che mostra le misurazioni mensili di precipitazione e altezza della neve per due località dal nome impronunciabile del Québec, dove le diverse misurazioni sono rappresentate con tonalità e colori differenti. Più in basso, ma parzialmente sovrapposto all’istogramma, troviamo un grafico a linee con le temperature medie mensili delle due località, la cui scala verticale è posizionata sul lato destro.

La figura è più complessa, è vero, ma non mi sarei mai aspettato che Gemini 3 Flash faticasse così tanto. Ci prova, ci riprova, ma ogni volta c’è qualcosa che non va. L’istogramma tutto sommato non è un grosso problema, ma non c’è verso di fargli capire cosa deve fare con i dati del grafico a linee. E questo anche dopo avergli spiegato dove deve guardare per determinare i valori di temperatura di ogni mese

Prompt

Hint: To evaluate temperatures for a given month you should take a point on the temperature plot that is between the two precipitation bars

Sono molto sorpreso dalla difficoltà che ha Gemini a ripetere ed estendere i risultati della mia prima prova, anche se continua a rassicurarmi sostenendo di aver capito benissimo quello che voglio e di aver eseguito un lavoro meticoloso.

Risposta

I have completed a meticulous re-evaluation of Figure 4 using the "midpoint" method you suggested (reading the temperature at the horizontal center between the two monthly precipitation bars). Final Corrections Applied: [...]

Nei fatti, sembra che Gemini non abbia la minima idea di cosa sia davvero il metodo “midpoint” e si limiti solo a ripetere ciò che gli dico, modificando solo qualche parola. Se così non fosse, infatti, risolverebbe l’intoppo in pochi secondi, tirando fuori i dati giusti proprio ha fatto la prima volta.

Alla fine mi arrendo. Non ha senso perdere delle ore per far fare ad un agente intelligente un lavoro che fatto a mano richiederebbe solo pochi minuti.

Esempio #2

Devo ammettere di essere deluso, ma forse mi sono aspettato troppo dal mio agente intelligente.

E allora cerco di semplificargli la vita, scegliendo un grafico di un mio vecchio articolo che non dovrebbe costituire un ostacolo particolarmente arduo per Gemini 3 Flash.

Che invece si incarta e fa errori incomprensibili. Con qualche aiutino, riesce a tirare fuori i dati mostrati in questo grafico, che però ha ancora parecchi punti mancanti (messi in evidenza dai riquadri colorati) o punti aggiunti in modo fantasioso (come quello indicato dalla freccia).

Nuova delusione. Perché usare un agente intelligente se si fa prima ad acquisire i punti a mano?

Esempio #3

Ma io non mi arrendo facilmente e provo ancora a fargli fare qualcosa di buono. E allora prendo una figura da quest’altro articolo, che è piuttosto semplice dal punto di vista grafico, ma che allo stesso tempo sarebbe utile poter acquisire in modo automatico, perché la quantità di dati contenuta rende difficile digitalizzarla a mano in modo preciso.

Scottato dalle esperienze precedenti gli chiedo prima di tutto di descrivere cosa vede nella figura.

Prompt

Now could you describe in simple words what you "see" in figure 1?

La risposta è lunga, precisa e quasi senza sbavature,

Risposta

Looking at figure 252505_1_f1.jpeg, I can see:

Two side-by-side graphs showing current-voltage (I-V) characteristics:

(a) Left graph (T = 2.0 K):

Shows a hysteretic behavior - the curve forms a loop
The current jumps abruptly at certain voltage points
There’s a clear gap between the upward and downward voltage sweeps
The vertical jumps occur around ±1 mV

(b) Right graph (T = 5.8 K):

Shows non-hysteretic behavior - smooth, continuous curve

No loop or gap between voltage sweeps
The transition is gradual rather than abrupt
The curve is more rounded at the critical points

Key observation: This demonstrates how the same Josephson junction behaves differently at different temperatures. At the lower temperature (2.0 K), it shows hysteresis (memory effect), while at the higher temperature (5.8 K), the hysteresis disappears and the junction becomes “overdamped.”

Both graphs show current ranging from about -15 to +15 mA on the y-axis, with voltage on the x-axis measured in millivolts (mV).

ma in realtà contiene un errore proprio alla fine della risposta che manderebbe a pallino tutti i tentativi di digitalizzare i dati contenuti nei due grafici.

Quando glielo faccio notare, Gemini 3 Flash si corregge immediatamente e sembra quasi dispiaciuto. Ma come ben sappiamo, tutti gli LLM sono programmati per assecondare sempre l’interlocutore.

Vado avanti e cerco di dargli una mano, spiegandogli per bene cosa dovrebbe fare.

Prompt

No problem. Now could you extract the values of voltage and current from the two images? Please produce a table for each image, and export the table as a csv file and a markdown file, with suffix `_table`.
Since one of the I-V curves is hysteretic, I suggest this strategy for extracting the data: start from V=0, increase V up to the maximum value following one of the paths, decrease V to 0 following the other path, do the same for the negative values of V.

Ma nonostante il suggerimento, non c’è verso di fargli fare un lavoro decente. Il meglio che ottengo sarebbe questo, che a prima vista è un ottimo risultato.

Peccato però che ci sia un errore grave e incomprensibile, che lascio a voi scoprire.

In ogni caso, l’immagine precedente è davvero il meglio del meglio del meglio, ed è stata ottenuta dopo ore di tentativi falliti (come questo tentativo iniziale, o questo, o questo) e di suggerimenti prima vaghi e poi sempre più precisi, un po’ come si fa con uno studente impreparato dal quale si cerca di tirar fuori qualche parola. Nonché di risposte che cercavano di adattarsi al suggerimento del momento, senza fare mai, o quasi mai, tesoro di tutto ciò che si era detto in precedenza.

Tutti questi tentativi infruttuosi sono stati resi ancora più frustanti dal fatto che, diversi anni fa, avevo risolto lo stesso problema in modo preciso e riproducibile con appena duecento righe di codice in Python (ricordavo male, non era C ma Python).

E quando alla fine gli spiego per filo e per segno come si fa, suggerendogli perfino che la chiave di tutto è convertire il file originale JPEG in un formato, il PBM (che è praticamente una griglia di 0 o 1 a seconda che il pixel sia bianco o nero),

Prompt

My suggestion is to change focus completely. If I were you I would:

take note of the extreme values of voltage and current on the X and Y axes;
get rid of the extraneous information outside the plot area and of the text (if any) inside it;
convert the image to the PBM (or PGM) format, that gives you a clean grid of black and white (or gray and white) pixels;
remove the extraneous grid dots using a 3x3 or 5x5 filter (or anything like that);
calculate the X and Y position of each black pixel, converting the [values] to Voltage and Current (it is just a proportion).

Clearly you can change the order of the steps or do something different if you believe your approach is better than mine.

non c’è lo stesso verso lo stesso di fargli fare qualcosa di utile.

Ancora più frustante è il fatto che Gemini non si è nemmeno fatto scrupolo di provare ad imbrogliarmi! Quando ha trovato il file originale dei valori misurati, che usavo per confrontare i risultati delle sue analisi con i dati veri, ha provato ad usare quel file per generare i dati che gli chiedevo. Chiaramente questa volta i risultati erano perfetti, ma ci voleva una intelligenza, artificiale o non, per tirare fuori una cosa del genere?

Altri esempi

Nei giorni in cui ho provato e riprovato quello che ho descritto in questo articolo ho fatto anche molte altre prove, come fargli scrivere del semplice codice in LaTeX, o convertire in CSV o Markdown le tabelle contenute nei file PDF di alcuni articoli.

Con il LaTeX se l’è cavato sempre bene, con le tabelle ha faticato parecchio anche quando il layout era abbastanza semplice. Inutile entrare nei dettagli, perché alla fine non ci sono grosse differenze rispetto agli esempi precedenti.

Conclusioni

Dopo gli ottimi risultati descritti nell’articolo precedente ero sinceramente convinto di poter usare gli agenti intelligenti integrati in Antigravity per estrarre facilmente i dati sepolti in tanti articoli scientifici di qualche anno fa, cosa che mi avrebbe permesso di eseguire delle nuove analisi comparate in modo rapido ed efficiente.

Purtroppo tutte le prove più approfondite descritte in questo articolo si sono rivelate un totale fallimento.

Il modello usato, quasi sempre Gemini 3 Flash (ma ho provato, anche se ho provato in modo più superficiale anche Gemini 3 Pro e Claude Sonnet 4.5),¹ ha mostrato un comportamento poco coerente e ripetibile. Ad esempio utilizzando metodi diversi per risolvere lo stesso problema, senza che fosse mai chiaro se dietro la scelta di un algoritmo o libreria di calcolo ci fosse una precisa motivazione tecnica o se si trattasse solo di una questione di probabilità statistica nella generazione delle risposte.

Un altro problema serio è stato la mancanza di memoria, un po’ come la pesciolina Dory dei cartoni animati. Nonostante pochi giorni prima avesse risolto con successo il problema di estrarre i dati da un istogramma, Gemini non stato in grado di riapplicare la stessa metodologia ad un caso analogo. Altre volte, una volta risolto un problema in modo parziale, gli capitava di ricominciare a lavorarci su ripartendo da zero, invece di limitarsi a rielaborare e a migliorare la risposta precedente.

Ma il problema che forse mi ha disturbato di più è stata l’incapacità di generalizzare il lavoro già fatto. Se gli chiedi di estrarre dei dati da una immagine, Gemini crea un programma adatto a quella immagine, senza mai cercare di sviluppare un metodo generale applicabile ad altre immagini dello stesso tipo. Se gli chiedi di generare il grafico di un file di dati, Gemini crea uno script adatto solo per quel file, che sarà impossibile o quasi adattare ad altri casi analoghi.

Quando un umano affronta un problema, tende ad affezionarsi alla soluzione e cerca di riusarla e di estenderla a problemi simili. Un LLM non se ne cura e riscopre la ruota ad ogni nuova iterazione. Sembra il trionfo dell’usa-e-getta, lo spreco di risorse e di intelligenza (per quanto artificiale) elevato all’ennesima potenza.

E queste cose non le ho notate solo io, che con queste cose ci gioco soltanto. Studi scientifici molto seri – che ad esempio hanno provato ad usare gli LLM per riscoprire la legge di gravitazione di Newton a partire dalle orbite dei pianeti attorno al Sole, oppure per prevedere il comportamento di una molecola in base alle diverse rappresentazioni della sua struttura – hanno raggiunto le stesse, identiche conclusioni.

La nostra analisi rivela che questi modelli si comportano, invece, come se sviluppassero delle euristiche specifiche per il singolo compito, che non riescono a generalizzare.²

Il semplice aumento delle dimensioni del modello non migliora le prestazioni né la capacità di generalizzazione.³

Infine, e anche se a prima vista sembra il contrario, non dobbiamo mai dimenticare che gli LLM non capiscono davvero quello che gli si chiede, sono solo molto bravi a ritrovare un ago in un pagliaio molto, molto, molto grande. Un LLM può spiegare per filo e per segno cos’è una “caratteristica I-V di una giunzione Josephson”, perché ha letto un sacco di libri e di articoli sull’argomento. Ma poi, quando si tratta di collegare il concetto ideale di “caratteristica I-V” con la sua rappresentazione sperimentale riportata in una figura, fallisce miserabilmente, dimostrando di essere solo un pappagallo bene ammaestrato.

C’è chi sostiene che gli LLM di ultima generazione siano in grado di scrivere da soli un intero compilatore C o decine di migliaia di righe di codice perfettamente funzionante.

Da parte mia, e molto più umilmente, mi accontenterei che questi modelli riuscissero a produrre un file di dati o una tabella in maniera ripetibile, senza incorrere in errori inspiegabili o in risultati incoerenti. E magari evitando situazioni incresciose come quelle che ho sperimentato, in cui una volta tutto procede senza problemi e la volta successiva non si riesce a cavare un ragno da un buco.

Ho usato anche la versione a pagamento di Gemini, gentilmente concessami dall’università, senza notare differenze rispetto alla versione gratuita. Chi sostiene che i modelli a pagamento facciano cose che quelli gratuiti si sognano dovrebbe fornire prove più che solide prima di essere creduto. ↩︎
K. Vafa et al., What Has a Foundation Model Found? Using Inductive Bias to Probe for World Models, arXiv 2507.06952v4, 2025. ↩︎
B. Yan et al., Inconsistency of LLMs in molecular representations, Digital Discovery vol. 4, 2025. ↩︎

Sorpresa Antigravity

Wed, 21 Jan 2026 18:00:00 +0000

Lo confesso, quando ho cominciato ad usare Antigravity avevo molte riserve, perché il nuovo editor rivoluzionario prodotto da Google mi sembrava solo uno dei tanti cloni di VS Code di Microsoft.¹

Ma appena ho iniziato ad usare le funzioni agentiche di Google Antigravity ho dovuto ricredermi, perché c’è davvero del buono.

Certo, ci sono anche tanti limiti, ma sono gli stessi di tutti gli altri modelli linguistici di grandi dimensioni (LLM, Large Language Model), che funzionano bene se li guidi passo passo in quello che devono fare, ma che hanno anche poca fantasia e vanno in affanno se gli sottoponi dei problemi nuovi e appena appena complicati.

– Immagine generata da Google Gemini.

Editor e IDE

Google Antigravity è una IDE (Integrated Development Environment), in italiano un ambiente di sviluppo integrato, cioè è un editor con funzionalità aggiuntive che aiutano a scrivere e a correggere il codice.

Essendo un derivato da VS Code ne riprende tutti gli aspetti positivi e negativi, primo fra tutti il fatto di essere basato su Electron, un framework multipiattaforma molto comodo per gli sviluppatori ma anche molto avido di risorse e di spazio su disco.

Infatti, come avevo già notato nell’ultimo articolo, una volta installato Google Antigravity occupa sul mio Mac la bellezza di 700 MB (696.6 MB per la precisione), un pelo di più dello stesso VS Code (683.9 MB) e qualcosa meno del padre Windsurf (718.7 MB). Tanto per fare un confronto, i miei due editor preferiti, TextMate e BBEdit, occupano rispettivamente 40 e 65 MB.²

Sulle funzionalità di editing del codice e di supporto allo sviluppo c’è poco da dire. Sono identiche a quelle di VS Code e possono essere estese a dismisura tramite le più di 8.500 estensioni disponibili sull’Open VSX Registry, un database di estensioni specifico per gli editor derivati da VS Code.

In teoria si potrebbero usare le estensioni di VS Code, ma Microsoft da qualche mese ha bloccato l’uso del marketplace di VS Code a tutti gli altri editor derivati (fra cui Cursor, Windsurf o Antigravity). Alla faccia dei principi dell’open source…

Funzioni agentiche

Ma cos’è l’Intelligenza Artificiale ad agenti (o agentica)? È un sistema di IA in grado di agire in modo autonomo, raggiungendo obiettivi complessi con una minima supervisione umana e senza dover essere istruito in modo dettagliato e ben definito.

È un po’ come il sogno dei cuochi dilettanti: avere a disposizione un robot in grado di guardare cosa c’è in frigorifero e nella dispensa e di preparare da solo un pranzo completo dopo avergli spiegato vagamente cosa vogliamo.

Ma è anche il sogno dei programmatori da bar, i vibe coders, quelli che vorrebbero poter chiedere all’IA di programmare una applicazione “fatta così e cosà”, andare a mangiare una pizza e trovare tutto pronto al ritorno, compreso il porting per le principali piattaforme e un sito di e-commerce dove venderla.

Mettere Antigravity alla prova

Finora tutti questi esperimenti non è che ci abbiano fatto una grande figura ma, come ci insegna Sean Connery, mai dire mai. E allora vediamo come funzionano nella pratica le funzioni agentiche integrate in Google Antigravity.

Per provarle, ho chiesto al programma di eseguire alcuni compiti specifici, spaziando da cose semplici fino ad un compito particolarmente complesso, cercando di lasciarlo libero di decidere cosa fare e intervenendo solo quando era davvero necessario. Ho scelto compiti vicini alle esigenze di ricercatore, ma credo che i risultati siano lo stesso molto significativi.

Ecco come è andata.

Prima di iniziare

Prima di iniziare ho finto di usare Antigravity per la prima volta, cancellando con AppCleaner tutti i file generati dall’applicazione. Ho eseguito di nuovo la procedura di onboarding, decidendo di Start fresh, senza importare la configurazione da VS Code o da Windsurf, e di usare la modalità Review driven development, senza modificare le opzioni di default.

Per quanto riguarda le estensioni, non ne installo nessuna, perché preferisco decidere da solo cosa mi serve.

Dimenticavo: la versione di Antigravity che ho usato per scrivere questo articolo è la 1.11.17 ma, vista la velocità dello sviluppo, è possibile che alcuni aspetti dell’interfaccia e del funzionamento del programma siano già cambiati al momento della pubblicazione dell’articolo.

Compito #1: Estrazione di dati dalle immagini

Cominciamo con una cosa semplice, ma molto importante quando si ha a che fare con dei vecchi articoli scientifici: estrarre i dati dalle immagini. Il mio obiettivo è verificare se è possibile istruire l’IA di Antigravity ad estrarre da solo i dati dalle figure di questo articolo appena pubblicato, di cui non sono per niente orgoglioso (per usare un eufemismo), ma che i referee, sorprendentemente, hanno accettato quasi senza fiatare.

Oggi, in base ai principi della riproducibilità dei risultati ottenuti, è diventato normale condividere tutti i dati di un articolo scientifico tramite dei repository pubblici come Zenodo, OSF, Dataverse o magari GitHub. Ma fino a pochi anni fa i dati originali erano di fatto accessibili solo attraverso le figure negli articoli, ed è proprio per questo che è fondamentale poterli estrarre dalle immagini.

Ci sono parecchi programmi dedicati all’estrazione dei dati dalle figure (come questo, questo o questo), ma richiedono di essere guidati dall’utente, che al minimo deve definire la posizione degli assi X ed Y e i limiti delle coordinate da estrarre. Alcuni programmi riescono a funzionare automaticamente, ma solo se hanno a che fare con tipi ben definiti di immagini.³

Prima di cominciare, creo una nuova directory dove salvo i grafici scaricati dalla pagina web dell’articolo, proprio come farebbe un collega che volesse ripetere il mio esperimento. Già che ci sono, ci metto anche il file PDF dell’articolo, che mi servirà più avanti.

NOTA. Tutte le domande riportate qui sotto sono state copiate senza correggere gli errori di battitura e la sintassi zoppicante, causati (anche) alla voglia di vedere rapidamente cosa veniva fuori. Tutto sommato questi errori sono utili, perché dimostrano che questi sistemi riescono a comprendere le nostre richieste anche quando la forma non è perfetta.

Scelgo di usare Gemini 3 Pro (High), che in questo momento è il modello più potente presente in Antigravity, e per prima cosa gli chiedo di orientarsi nel contenuto della directory.

Prompt

In the current directory you will find a pdf file, a couple of folders and some inages in png or webp format. Is all this right?

Gemini ci pensa un paio di secondi e poi mi conferma che è tutto corretto. Molto bene, allora

Prompt

Now open the file containing "Fig1" in the filename. This is an histogram showing the concentration of several chemical species in two kinds of Shungite, type Z (darker bars) and type B (lighter bars). Could you extract the values of concentration from the images? Please produce a table with the name of each chemical species and the associated concentrations for the Type Z and Type B material. Export the table as a csv file named "gemini-fig1.csv" and as a markdown file "gemini-fig1.md"

Questa è l’immagine con cui ha a che fare Gemini

Nonostante io sia stato volutamente vago sul nome del file, Gemini la trova senza problemi e e dopo una ventina di secondi produce i due file richiesti. La tabella generata da Gemini è questa

Chemical Species	Type Z (Concentration %)	Type B (Concentration %)
SiO2	41	52
C	33	16
Al2O3	11	16
Fe2O3	5	3
FeO	3	2
TiO2	0.2	1
MnO	0.1	0.2
S	1.2	0.5
MgO	0.5	1.5
Na2O	1.5	1.2
CaO	0.5	2
K2O	1	2
H2O	2	1.5
minor elements	0.5	0.5

Confrontandola con la tabella vera, che contiene i valori di concentrazione realmente misurati

Species	Type_Z	Type_B
SiO2	40.8	52
C	33.4	16.3
Al2O3	10.6	15.8
Fe2O3	4.7	3.2
FeO	3.5	1.9
TiO2	0.4	0.9
MnO	0.14	0.12
S	1.1	0.6
MgO	0.3	1.6
Na2O	1.6	1.2
CaO	0.4	2.3
K2O	1	2.2
H2O	1.6	1.4
Other	0.46	0.48

si nota subito che tutti i valori estratti dalla figura sono molto vicini a quelli reali, con approssimazioni minime e sempre minori dello 0,5%.

Sono davvero impressionato dal risultato: Antigravity ha fatto tutto in pochi secondi e senza nessun intervento da parte mia, a parte la preparazione dei file e la scrittura del prompt. È vero che anche i normali chatbot come ChatGPT o Claude possono fare le stesse cose, ma Antigravity ci permette di lavorare direttamente sul nostro computer e con i nostri file, senza dover trasferire niente su e giù per l’interfaccia web del chatbot.

Compito superato a pieni voti.

Compito #2: Riproduzione di grafici

Per motivi non rilevanti qui, ho partecipato poco – e più che altro in modo critico – alla stesura dell’articolo menzionato nel Compito #1. In particolare, non mi sono occupato come al solito di preparare i grafici, che invece sono stati realizzati da una collega in Matlab, un sistema di calcolo molto amato dagli ingegneri. I quali hanno ragione, perché con Matlab si possono fare con poco sforzo dei calcoli molto complicati. Ma produrre dei grafici di qualità non è certo il suo forte.

Vediamo allora se riesco a far ricreare a Gemini 3 Pro l’istogramma del Compito #1, utilizzando la libreria ggplot2 di R.

Prompt

Now generate the R code to recreate the same graph, using ggplot2 and whenever possible the functions available in the tidyverse.

Dopo un po’ lo script è pronto e viene salvato automaticamente nella directory del progetto. Gli do una rapida occhiata e mi sembra a posto. Apro il terminale integrato in Antigravity ed eseguo lo script come mi viene suggerito,

Rscript recreate_fig1.R

e, a parte i colori invertiti, la figura è identica all’originale.

Voglio essere chiaro su questo punto: io non ho toccato nemmeno una virgola del codice generato in Antigravity da Gemini (e non lo farò nemmeno in seguito), il quale quindi riesce da solo a ricreare in R una copia quasi perfetta dell’originale, leggendo i dati presenti nella figura e riconoscendo tutti gli elementi di contorno del grafico, come le etichette degli assi X e Y, le scale numeriche o la legenda.

Conosco abbastanza bene R e avrei potuto ottenere lo stesso risultato in poco tempo, ma non c’è dubbio che anche in casi come questo Antigravity può essere un valido aiuto per chi è a digiuno di programmazione.

Io comunque sono incontentabile e chiedo a Gemini di invertire i colori

Prompt

Sorry, but the colors are inverted. Type Z is light grey and Type B is dark grey. Please switch the colors so that they are identical to the original. Save the new R code as `Rscript recreate_fig1-1.R`

Eseguo il nuovo script e ora i colori sono quelli corretti. Noto con piacere che anche il nome del file png generato è stato aggiornato, cosa che rende più facile confrontare i diversi file prodotti da Gemini.

Di nuovo, sono davvero molto impressionato. Gemini ha fatto tutto perfettamente e io non ho dovuto correggere nemmeno una riga del codice.

Era un lavoro facile, non c’è dubbio, ma rimane comunque un risultato molto interessante. Anche perché stiamo parlando di un linguaggio specialistico come R, che non ha certo la mole di esempi su cui addestrarsi che hanno linguaggi molto più diffusi, come Python o JavaScript.

Anche questo compito mi pare superato a pieni voti.

Compito #3: Generazione di nuovi grafici

Gemini è riuscito a ricreare perfettamente l’istogramma dell’articolo, ma vorrei verificare se ci sono delle rappresentazioni alternative più efficaci.

Lascio di nuovo la palla a Gemini 3 Pro, che tira fuori due idee interessanti, un grafico Lollipop e un Dumbell plot, che però per varie ragioni non mi soddisfano più di tanto. Provo a fargli fare delle modifiche, Gemini esegue sempre tutto a puntino ma il risultato non migliora.

Alla fine, mi convinco che il grafico più equilibrato è il solito istogramma, ma questa volta con gli assi X e Y scambiati e colori molto diversi per i due tipi di materiale.

Dato che, come ho già detto, sono incontentabile, prendo una figura molto più complicata dal solito articolo,

e gli faccio ripetere il lavoro di generazione dei grafici equivalenti usando R e ggplot2. Gemini si mette subito all’opera e capisce da solo che la concentrazione dei vari elementi al giorno 0 vale per entrambi i tipi di materiale, una cosa che non è banale da capire guardando solo il grafico.

Risposta

For Day 0 ("untreated sample"), I assigned the same concentration value to both Type Z and Type B in the dataset. This format suggests that both treatments start from the same baseline, which will make plotting lines easier in R.

Vi risparmio i dettagli, dico solo che Gemini fa tutto quello che gli chiedo, e produce con poco sforzo diversi tipi di visualizzazioni diverse dei dati presenti nell’immagine qui sopra, come questa heatmap o questo Sankey plot. I grafici prodotti non mi soddisfano al 100%, ma comunque dimostrano che Gemini è in grado di eseguire anche i compiti richiesti da utenti incontentabili come il sottoscritto.

Gemini riesce anche a capire da solo che, se gli chiedo di mettere i grafici prodotti in due colonne, una per ciascuno dei due materiali studiati, quello che voglio davvero sono quelle che nel gergo di R si chiamano facet. Sembra una cosa sciocca, ma significa che queste rappresentazioni più complesse diventano alla portata anche di chi sa cosa vuole, ma non sa come esprimerlo in modo preciso.

Va detto, però ,che per quanto sia comodo (e anche divertente) chiedere e osservare Gemini mentre lavora, quando si arriva alle modifiche più fini si perde molto più tempo a scrivere le domande e ad aspettare le risposte che a lavorare direttamente sul codice. E questo è un dettaglio da tenere in conto.

Diciamo che questo compito merita la sufficienza.

Compito #4: Interazione con il codice e il sistema operativo

Vediamo ora se Gemini 3 Pro integrato in Antigravity è in grado di eseguire delle operazioni basilari di gestione dei file e delle cartelle. Tutti gli esempi valgono per macOS, su cui ho fatto tutte le prove, ma anche per le varie incarnazioni di Linux e di BSD Unix.

Per prima cosa gli chiedo di mettere ordine nei file generati finora, spostando gli script in R nella directory code, i file dati in data e i grafici podotti in output. Gemini 3 Pro ci pensa un po’ su e poi crea un semplice script di shell per eseguire quanto richiesto. Fa anche un errore, se ne accorge e mi chiede di autorizzarlo a correggerlo. Molto, molto bene.

Ma quello che mi piace ancora di più è che aggiorna da solo tutto il codice già scritto con i nuovi percorsi dei vari file.

Gli chiedo allora di aggiungere a ciascuno script in R il mio solito preambolo, che crea un ambiente R ben definito. Gli do un esempio tratto da uno dei miei vecchi script. ma per il resto gli lascio mano libera. Gemini fa tutto a puntino e aggiorna di nuovo da solo tutti i percorsi dei file creati finora. Davvero impressionante!

Gemini si comporta in modo ineccepibile anche con la conversione dei tab, da due spazi a quattro spazi, come piace a me. Anzi, si accorge persino che deve farlo evitando errori di formattazione nel codice. Meglio di un linter.

Passo infine al versioning con git che è sempre utile quando un progetto diventa appena complicato.

Prompt

Could you now initialize a local `git` repository for this project? Versioning is very useful as soon as a project starts to become complicated.

Va tutto a meraviglia, Gemini crea il repository richiesto, fa un primo commit e aggiunge anche un file .gitignore sensato. Ovviamente posso interrogarlo per chiedere lo status del repository o per eseguire tutte le altre operazioni con git che sono abituato ad eseguire dal Terminale.

Devo ammettere che ho un po’ paura a far fare tutte queste cose ad un sistema agentico, ma in ogni caso il risultato è perfetto.

Anche in questo caso vale quello che ho scritto alla fine del Compito precedente: chi conosce bene i comandi di git fa molto più in fretta a lavorare nel Terminale che a chiedere a Gemini. Però è altrettanto vero che per il normale ricercatore (ma anche per il normale utente) a digiuno di Terminale e sistemi di versioning, usare un sistema ad agenti come questo può essere un ottimo modo per interagire a basso livello con il codice senza dover studiare pagine e pagine di documentazione.

In ogni caso, un altro compito superato a pieni voti.

Compito #5: Analisi statistica dei dati

Qui non la faccio lunga, anche perché sulla analisi statistica Antigravity/Gemini 3 Pro è un po’ scarso.

Se lo lascio libero di fare quello che preferisce, tira fuori cose senza senso, come creare delle matrici di correlazione fra le concentrazioni dei diversi metalli pesanti o cercare di confrontare le “differenze di efficacia” dei due materiali. Non è un compito facile, lo ammetto, ma dimostra – se ci fosse ancora bisogno di dimostrarlo – che questi sistemi intelligenti sono molto utili quando gli si dice con precisione cosa fare, ma non riescono a lavorare da soli quando l’utente non ha una idea chiara su cosa vuole ottenere.

Infatti, quando gli spiego per benino con che tipo di dati ho a che fare e cosa voglio ottenere,

Prompt

The two types of shungite, type Z and type B, are different materials and they are used independently. In other words, the experiments made using type Z material is completely independent from the experiment with type B, so the two materials cannot be directly compared. This means that the stat_difference_boxplot has little sense, and the same is true for the correlation matrix which photographs a single day (I guess day 0 for only one type of material), while we are interested to time series. Therefore you should try to use some statistical analysis able to deal with time series.

Gemini ci pensa su per un po’, fa degli errori ma riesce a correggerli da solo e alla fine tira fuori un modellino che dimostra come il materiale di tipo Z assorbe i metalli pesanti più rapidamente del materiale di tipo B. Se ci fossero più dati a disposizione, avrebbe senso ragionare un po’ sul modello, ma per ora può bastare.

Difficile dare un voto qui, diciamo non classificato.

Compito #6: Estrazione di tabelle dai file PDF

Qui entrarre in un territorio ostile. Estrarre automaticamente il contenuto delle tabelle contenute nei file PDF sembra una cosa banale, e invece è un argomento su cui si sono arrovellati centinaia e centinaia di ricercatori, e io fra questi. Il problema principale è che il formato PDF è orientato a gestire l’aspetto grafico della pagina, ma non sa nulla del suo contenuto.

Per le mie prove, ho chiesto ad Antigravity di aprire il file PDF di uno degli Annali Idrologici della Regione Puglia e di estrarre i dati di temperatura minima e massima misurati in alcune stazioni meteorologiche pugliesi. I dati giornalieri ora sono disponibili sul web, ma gli Annali in PDF rimangono una risorsa fondamentale, perché contengono i dati di temperatura e precipitazione (e altro) misurati in tutte le circa 150 stazioni della rete meteorologica pugliese a partire dal 1921, permettendo così di analizzare com’è cambiato il clima della regione nell’ultimo secolo.

Il problema di estrarre i dati da questi file PDF l’ho risolto anni fa attraverso una combinazione di script in R e AWK, ma la procedura è lunga e complessa perché bisogna correggere a mano le tante incongruenze contenute nelle tabelle.⁴ Alla fine, per estrarre i dati di un singolo anno ci vogliono un paio di ore di lavoro attento, che non è male vista la complessità dell’analisi, ma che sarebbe molto utile riuscire a delegare all’IA.

E allora provo a farlo fare a Gemini 3 Pro, scrivendo un prompt bello lungo dove gli spiego per filo e per segno cosa fare

Prompt

Open annale2013.pdf and go to page 6, where you will find a pair of data tables with measured precipitations [sic! sarebbe dovuto essere “temperatures”] for two weather stations. The data is arranged in pairs of columns, and each pair corresponds to a month, G for gennaio (january), F for febbraio (february), etc,. until D or dicembre (december).

As for the pairs, the first column is the minimum temperature and the second column is the maximum temperature.

Each row represents a different day.

At the end of each table there are some summary data, Medie, Med.mens. and Med.norm that you can skip.

Missing data can be marked by either one or more > or < signs, or by = or be simply blank. In some tables there are extraneuous signs that you can skip outright.
Read the table and generate two different csv files, one for the maximum temperature and one for the minimum temperature, following this example

Date,Altamura,Andretta
    2007-01-01,13.4, 7.7,
    2007-01-02,15.7, 9.7,
    2007-01-03, 7.1, 2.7,
    2007-01-04, 9.5, 7.0,

The header contains the date in ISO format, YYYY-MM-DD, and the name of the weather station which is written in bold at the top of each table, just under the months. All other information in thsi area, eg., (Te), Bacino etc. is not useful and can be skipped.

Gemini prova e riprova a risolvere il problema con Python, ma i suoi script producono un sacco di errori e saltano parecchi giorni con dati validi. Del resto non è un problema facile, ci ho buttato il sangue io stesso per mesi, per cui gli do un aiutino.

Ma a questo punto Gemini va in errore e non c’è verso di andare avanti.

La cosa migliore sarebbe ricominciare da zero, ma nel frattempo ho raggiunto il quota limit for Gemini 3 Pro (High) e dovrei aspettare diversi giorni prima di poter continuare.

Non se ne parla, preferisco cambiare modello e passo a Gemini 3 Flash di cui tutti parlano in questo momento. Gemini 3 Flash si mette al lavoro e mi propone un piano di lavoro che sembra sensato, ma che alla prova dei fatti produce, come ammette lui stesso, una jumbled mess (un pasticcio confuso) perché ci sono extraneous characters and unclear formatting (caratteri estranei e formattazione poco chiara).

Gli suggerisco di usare la libreria pdftools di R, che ho usato io stesso e che dà risultati infinitamente migliori dei tool analoghi per Python e alla fine, bingo!, Gemini ce la fa e produce un file dati corretto al 100%.

Lo so, per essere davvero utile dovrei fargli ripetere il processo per tutte le stazioni e per parecchi anni diversi, ma per ora mi accontento, anche perché non voglio sprecare tutta la mia quota in questa attività. In ogni caso il risultato raggiunto con Gemini 3 Flash è molto promettente e merita di essere approfondito come si deve.

Va detto, invece, che con Claude Sonnet 4.5 (Thinking) non c’è verso di fargli fare qualcosa di buono. Prova e riprova, raggiungo il limite di quota anche per questo modello e mi devo fermare.

Votazione? Gemini 3 Flash prende il massimo, mentre Gemini 3 Pro andrebbe riprovato nelle stesse condizioni del modello minore. Claude Sonnet 4.5, infine, prende un non classificato

Compito #7: Programmazione di un microcontroller

Un altro campo in cui le funzioni agentiche di Google Antigravity potrebbero dimostrarsi molto interessanti e la programmazione dei microcontroller, come Arduino, Raspberry Pi Pico o ESP32. Ci sono letteralmente una marea di questi oggettini, e non per niente facile orientarsi fra i tanti modelli diversi e, ancora di più, fra le migliaia di sensori e moduli che gli si possono collegare.

In questo caso specifico, un sistema di IA che produca velocemente del codice funzionante potrebbe essere davvero utile.

Per le mie prove decido di usare un Nicla Vision, che di fatto è un Arduino con una videocamera incorporata. Il Nicla Vision è un vero gioiellino, che non costa poco ma che vale tutti i soldi spesi. Ma è anche un oggetto poco diffuso rispetto ai normali microcontroller, per cui se Antigravity riesce a programmarlo correttamente, riuscirà di sicuro a fare altrettanto con i normali Arduino, Pi Pico o ESP32.

Torno quindi ad usare Gemini 3 Flash e gli chiedo se conosce il Nicla Vision. Gli do anche il link alla pagina web del prodotto per aiutarlo ad orientarsi. Gemini mi conferma di sapere bene di cosa sto parlando, per cui possiamo partire può partire.

Per programmare questi oggettini, io ho sempre e solo usato Arduino IDE e Thonny e non so se Gemini può gestire il microcontroller direttamente dall’editor. Quando glielo chiedo, Gemini risponde con un comando molto semplice

% ls /dev/tty.usbmodem* /dev/cu.usbmodem* 2>/dev/null || echo "No usbmodem devices found"

che permette di controllare che il Nicla Vision sia collegato al Mac. Una volta che l’ha trovato, verifica se sono installate le librerie Python necessarie per comunicare con il microcontroller e, dato che non ci sono, mi propone di installarle. Giustamente mi dà anche la possibilità di scegliere se farlo a livello globale o in un virtual environment, e non c’è bisogno di dire che scelgo la seconda opzione.

Gemini prepara anche un piccolo script di test che fa lampeggiare il LED (il classico Hello World dell’IoT) e, quando gli confermo che tutto funziona, proclama soddisfatto

Risposta

I'm ready to start writing more complex code for your project. What would you like to build first?

Fin qui Gemini non fa nulla di più di quello che avrei potuto fare io stesso con Homebrew e Conda. Ma per riuscirci avrei dovuto consultare pagine e pagine di documentazione sparsa per il web. Qui invece riesco a configurare tutto in pochi minuti, e per di più imparo tante cose utili.

Dato che Gemini era così ansioso di rendersi utile, gli ho chiesto di scrivere un piccolo programma che sfrutta il Nicla Vision per scattare delle foto ad intervalli prestabiliti e inviarle al Mac tramite Wi-Fi. Risultato? Ha funzionato tutto al primo colpo.

E Gemini non si è nemmeno offeso quando gli ho detto papale papale che non mi fidavo a dargli in pasto la password del mio Wi-Fi, anzi ha proposto una soluzione alternativa più sicura. Ma io sono malfidato, e alla fine ho usato l’hotspt del mio iPhone con una password usa e getta.

Anche l’ultimo compito è superato a pieni voti.

Lasciare una traccia

Una cosa seccante di Antigravity è che non dispone di una funzione per esportare un log completo di quello che si fa, con le domande fatte e le risposte del modello, e magari anche i suoi pensieri.

Correzione. Mi sbagliavo, l’abbreviazione da tastiera CMD (⌘)-E consente di aprire l’Agent Manager, una finestra separata di Antigravity che, fra le altre cose, consente di vedere l’intera storia di quello che ha fatto Antigravity, compresi i suoi pensieri. Il problema è che non c’è una voce di menu specifica per l’Agent Manager (o almeno, io non l’ho trovata) e l’abbreviazione da tastiera è visibile solo all’avvio del programma.

Correzione #2. Si può aprire l’Agent Manager direttamente dalla barra degli strumenti di Antigravity: la voce corrispondente si trova proprio accanto alle icone che permettono di modificare il layout dell’applicazione e di effettuare delle ricerche. Non so perché non me ne sia accorto prima, ma è anche vero che tutti gli altri comandi della barra degli strumenti sono rappresentati da icone; per questo non è immediato riconoscere quella voce come un comando anziché come una semplice stringa, come avviene per il nome dell’applicazione che occupa il centro della barra degli strumenti.

In ogni caso, dopo ogni operazione volta, Antigravity mi permette di leggere un Walkthrough dettagliato di ciò che ha fatto e, facendo click con il tasto destro sul Tab relativo,

mi accorgo che posso rivelare il file nel Finder. Quando lo faccio, compare una cartella con un gran numero di file Markdown, con nomi standard come implementation_plan, task, o walkthrough seguiti dal suffisso resolved e da un numero progressivo

che dovrebbero rappresentare la storia di tutto quello che faccio con il sistema agentico.

Da quanto vedo, ogni volta che chiedo qualcosa ad uno degli agenti integrati, Antigravity genera tre file contenenti: (1) quello che deve fare, task, (2) il piano di lavoro, implementation_plan e (3) una sintesi di quello che ha fatto, walkthrough. A prima vista, non è facile mettere in relazione fra loro questi file, ma il meccanismo merita di essere approfondito. Per la cronaca, tutti i file in questione si trovano in una directory contenuta all’interno di ~/.gemini/antigravity/brain/, ma la directory principale ~/.gemini/antigravity/ contiene parecchie altre directory con file di configurazione, codice generato e altro.

Conclusioni

Da quello che ho scritto è chiaro che usare Antigravity mi è piaciuto. Ci sono casi in cui chi sa programmare rischia di essere più rallentato che aiutato, ma in generale, e soprattutto per coloro che sanno usare Word, Excel e poco più, le funzioni agentiche di Antigravity possono rivelarsi un aiuto davvero prezioso.

Nel corso della mia vita di programmatore non-professionista sono passato dallo scrivere il codice consultando i volumoni giganteschi di documentazione a cercare le risposte su StackOverflow. Per come la vedo io, le funzioni agentiche di Antigravity sono come uno StackOverflow con il turbo: non si limitano a presentare delle risposte alle nostre domande, ma le interpretano, ragionano su di esse e propongono soluzioni in modo quasi autonomo.

Ma, proprio come su StackOverflow, bisogna sempre fare affidamento sulle proprie conoscenze e sulla propria esperienza per separare il grano dal loglio, le risposte utili e davvero funzionanti da quelle che valgono meno di niente.

Non parliamo però per favore di vibe coding, cioè di poter chiedere genericamente al programma di svolgere un dato compito, per poi andarsene in giro mentre Antigravity fa tutto da solo!⁵ Come si vede dagli esempi, se non si è molto precisi e non gli si spiega per bene cosa vogliamo, controllando poi passo passo ciò che Antigravity propone di fare, si rischia che l’intero processo fallisca o produca dei risultati sbagliati.

Proprio come un tesista, una dottoranda, o un nuovo collega, Antigravity può darti una grossa mano se sai cosa vuoi e come lo vuoi ottenere, e se glielo spieghi per bene. Ma fargli tirare fuori delle idee sue, non dico originali ma almeno sensate, per ora è solo fantascienza. O marketing.

Già il solo fatto che Google utilizzasse, per un suo strumento di sviluppo, del codice prodotto da un concorrente diretto mi sembrava, diciamo così, piuttosto singolare. ↩︎
È vero che TextMate e BBEdit non sono delle IDE vere e proprie (soprattutto TextMate), ma la differenza di dimensioni rimane lo stesso impressionante. ↩︎
Io stesso ho sviluppato parecchi anni fa un programma in C, no era in Python, che faceva tutto da solo, ma funzionava solo con le immagini di un tipo ben determinato di oscilloscopio digitale. ↩︎
La fantasia degli estensori delle tabelle meriterebbe un premio. ↩︎
Anche un guru della programmazione molto indaffarato come Linus Torvalds usa il vibe coding, ma sa perfettamente quello che vuole fargli fare. E comunque lo usa solo per i suoi giochetti, non certo per sviluppare il kernel di Linux. ↩︎

Fotocopiato!

Mon, 15 Dec 2025 18:00:00 +0000

Il video qui sopra è la presentazione ufficiale di Google Antigravity, una IDE (Integrated Development Environment) che non è solo una semplice IDE ma è “un nuovo modo di lavorare per questa prossima era dell’intelligenza agentica”. Che non ho ancora ben capito cosa significa, ma che suona tanto intelligente e al passo con i tempi.

E allora vediamo cos’è questo “nuovo modo di lavorare” nel quale gli agenti “ti aiutano a decollare”. Una espressione che in altri tempi avrebbe significato ben altro.

Scarico l’ultima versione disponibile di Google Antigravity, la 1.11.17 per la cronaca, che una volta installata occupa la bellezza di 700 MB. Una volta superate le solite schermate di onboarding ed essermi autenticato tramite il mio account Gmail, ecco cosa viene fuori

Praticamente VS Code di Microsoft, con in più il tool agentico Antigravity, che non so ancora bene a cosa possa servire e, soprattutto, se serve davvero.

Del resto, me lo avevano praticamente detto durante l’onboarding, quando è comparsa questa schermata dove mi veniva proposto di configurare l’editor da zero oppure di importare la configurazione da VS Code. O da Windsurf.

Windsurf?

Sì, Windsurf, un editor derivato da Cursor,¹ che a sua volta derivava dal solito VS Code.

La somiglianza (per usare un eufemismo) diventa evidente quando li si mette uno accanto all’altro, Antigravity a sinistra e Windsurf a destra.

Identici.

Insomma, l’IDE rivoluzionaria, il “nuovo modo di lavorare per questa prossima era dell’intelligenza agentica” che “ti aiuta a decollare”, non è altro che un clone di un editor che a sua volta era già il clone di un altro editor che a sua volta era il clone…

Basta approfondire un po’ per scoprire che Google ha speso 2.4 miliardi di dollari per acquisire il codice di Windsurf e per assumere i due fondatori, Varun Mohan e Douglas Chen, insieme ad una manciata di sviluppatori dell’azienda.² Ma, per timore di interventi dell’antitrust, Google ha evitato di acquistare il prodotto vero e proprio o il marchio, per cui Windsurf continua ad esistere e ad essere sviluppato indipendentemente, provando a ripetere la storia di Davide contro Golia.

Insomma, è un po’ come se negli anni ‘80 Microsoft avesse assunto Steve Jobs e Steve Wozniak, con magari anche Bill Atkinson, Andy Hertzfeld e Susan Kare, prendendo con loro anche il codice del primo Macintosh. Per poi ripubblicarlo qualche mese dopo come Windows 1.0. E tutto ciò mentre Apple continuava tranquillamente a sviluppare lo stesso codice per il Mac originale.

Ho l’impressione che quelli di Google abbiano usato qualcos’altro per decollare.

Ma a parte le battute, gli agenti presenti in Antigravity funzionano e sono utili nel corso dello sviluppo del codice? Non lo so nemmeno io, ed è quello che vedremo in diretta la prossima volta.

Chi è interessato alle polemiche nate dopo le ultime modifiche ai prezzi di Cursor può leggere qui. ↩︎
L’articolo citato è a pagamento, ma può essere letto liberamente qui. ↩︎

Modifiche a colpo d'occhio con SubEthaEdit

Mon, 27 Nov 2023 06:00:00 +0000

– Fonte: Possessed Photography su Unsplash.

SubEthaEdit (SEE per brevità) è un editor per macOS discreto, che fa più o meno tutto ciò che ci si aspetta da un editor moderno (con alcune mancanze significative), e che in più ha la particolarità di permettere a più utenti collegati di lavorare in modo collaborativo allo stesso documento.

Di queste caratteristiche generali ho già scritto nell’articolo precedente. In questo articolo, invece, voglio soffermarmi sulla funzione di SEE che mi ha colpito di più in assoluto, cioè la possibilità di mettere bene in evidenza tutte le modifiche effettuate su un documento di testo anche quando non si collabora con altri utenti, una funzione molto particolare ma che in certi casi può diventare davvero un toccasana.

Modifiche in evidenza

A che serve evidenziare le modifiche ad un testo? Serve tutte le volte in cui si debba mostrare in modo chiaro e tracciabile all’editore, al committente, al cliente, o semplicemente ai colleghi, cosa è stato cambiato in un dato documento, come succede molto spesso nell’editoria scientifica ma anche in tanti altri settori professionali.

Con un wordprocessor non è un problema, Word e i suoi cloni hanno uno strumento integrato di revisione del testo che, per quanto pesante e implementato in modo farraginoso, fa il suo lavoro. Ma come può fare chi preferisce scrivere in modalità solo testo, usando LaTeX o il sempre più popolare Markdown?

Questi due strumenti permettono di segnalare le modifiche inserendole all’interno di tag dedicati (\hl{testo modificato} per LaTeX e {==testo modificato==} per Markdown), ma è fastidioso dover aggiungere i tag mentre si procede alla revisione del testo, con il rischio di perdere il filo del discorso e di allungare i tempi di lavoro.

Come mi sono accorto da poco, SEE può essere un ottimo strumento per risolvere questo problema.

La funzione di evidenziazione del testo modificato di SubEthaEdit può essere attivata una volta per tutte selezionando l'opzione `Highlight Changes when not collaborating posta in cima al pannello `General` delle Preferenze, e sarà valida per tutti i nuovi documenti aperti nel programma.

Se vogliamo attivarla anche nel documento corrente, dobbiamo andare nel menu View e selezionare la voce Highlight Changes.

Da questo momento in poi, tutte le modifiche o le aggiunte al testo corrente verranno messe in evidenza da un fondo colorato in giallo (il colore si può cambiare nella sezione Collaboration delle solite Preferenze).

Un caso personale

Alcune settimane fa dovevo modificare un articolo scritto in LaTeX che richiedeva la riscrittura o l’aggiunta di grosse porzioni di testo, nonché la correzione di un bel po’ di errori di inglese, il tutto con la necessità di mettere bene in evidenza tutte le modifiche effettuate, anche al livello delle singole parole.

LaTeX ha una funzione specifica per mettere in evidenza il testo modificato (\hl, che sta per highlight), il problema è che, quando le modifiche sono tante, è difficile riuscire a ricordarsi di circondare anche il più piccolo pezzetto di testo modificato con \hl{...} senza perdere il filo del discorso e finire per dimenticare qualcosa di importante.¹

Ho provato i miei soliti editor,² per vedere se potevano offrire qualcosa che faceva al caso mio ma, a parte (ovviamente) Emacs,³ non ho trovato niente più del solito diff, uno strumento da Terminale molto usato dai programmatori che mette a confronto due file diversi e segnala quali righe sono state modificate.

Ma, appunto, con diff possiamo vedere quali righe sono cambiate, non cosa è cambiato in ciascuna riga! Per un programmatore non è un problema, perché le righe di codice sono brevi ed è facile notare le differenze, ma in un documento LaTeX una singola riga può corrispondere ad un lungo paragrafo di testo, ed è quindi molto più difficile notare a prima vista cosa è cambiato rispetto al testo originale.⁴

Ci sono altri strumenti a linea di comando che avrebbero potuto fare al caso mio, come wdiff, che bisogna installare con Homebrew, oppure git diff --word-diff, ma usarli avrebbe complicato ulteriormente un lavoro già di per sé piuttosto complesso.

Un po’ per caso un po’ per fortuna ho lanciato SEE, che avevo installato sul Mac senza usarlo mai più di tanto, e mi sono accorto che faceva perfettamente al caso mio.

Con questo editor il lavoro di revisione è stato semplicissimo: mi bastava prendere un blocco di testo dal file originale in LaTeX, copiarlo nella finestra di SEE e inserire via via le correzioni, vedendole tutte chiaramente e in tempo reale con il loro fondo giallo. Una volta finita la revisione di tutto il blocco, potevo circondare tutte le parti di testo evidenziate con hl{...}, per poi sostituire il testo rivisto a quello del file originale LaTeX.

Vi assicuro, descrivere la procedura è molto più complicato che realizzarla, tanto che sono riuscito a completare tutta la revisione in appena un paio di giorni, perché SEE mi permetteva di concentrarmi esclusivamente sulla riscrittura del testo, rimandando la gestione minuta delle modifiche solo alla fine della correzione dell’intero blocco.⁵

Perché tutta questa trafila di copia e incolla da LaTeX a SEE e viceversa? Non sarebbe stato più semplice lavorare solo in SEE? Certo, ma l’articolo originale era su Overleaf e volevo che i colleghi potessero continuare ad accedere all’ultima versione anche mentre io ci lavoravo. E poi SEE ha un grosso difetto, perché non conserva le evidenziazioni quando si salva un documento e lo si riapre una seconda volta. Sarebbe bastata quindi una distrazione, un blocco imprevisto del Mac o magari un banale calo di tensione per perdere di colpo traccia di tutte le modifiche più recenti. Non potevo permettermelo e non ho voluto rischiare.⁶

A questo proposito, ho chiesto agli sviluppatori di rendere permanenti le evidenziazioni del testo, ma dopo due mesi non ho avuto risposta e temo che la richiesta non sarà soddisfatta, almeno in tempi brevi.

Dal personale al generale

Ma questa funzione particolare di SEE serve solo a chi, come me, si muove nell’ambito dell’editoria scientifica? Non credo, in realtà mettere bene in evidenza le modifiche ad un documento è una funzione molto utile in svariati settori professionali, e spesso sono proprio i committenti o i clienti a richiedere esplicitamente che il documento contenga una visualizzazione chiara di tutti i cambiamenti subiti.

Non a caso la funzione di revisione con evidenziazione delle modifiche effettuate è molto usata da chi scrive in Word, sia quando lavora in collaborazione con altri che quando deve semplicemente correggere un documento altrui.

L’implementazione delle revisioni in Word è molto macchinosa (e come poteva essere diversamente?) e le modifiche possono essere visualizzate in molti modi diversi, una flessibilità che però tante volte genera solo confusione quando si aprono dei documenti altrui. Nella modalità di visualizzazione più dettagliata si arrivano a vedere le singole lettere aggiunte o cancellate, e il tutto diventa presto un guazzabuglio incomprensibile di testo barrato e testo colorato, con configurazioni e colori diversi per ciascun utente. Considerazioni analoghe si possono fare anche per altri sistemi di scrittura come LibreOffice Writer o Google Docs, che forse riescono a fare persino peggio di Word.

In ogni caso, Word sarà anche molto popolare ma tanti, come me, preferiscono usare sistemi di scrittura basati sul testo puro, come LaTeX o il popolarissimo Markdown, che ha parecchi segni speciali per gestire le evidenziazioni di un blocco di testo ({==testo evidenziato==}), così come le aggiunte ({++testo aggiunto++}), le ~~cancellazioni~~ ({--testo cancellato--}), e perfino le ~~modifiche~~ sostituzioni ({testo precedente>testo sostituito~}).

Quando le modifiche da fare sono tante, come ci si può concentrare sul testo da rivedere senza perdere il filo del discorso, quando bisogna inserire di continuo i tag, piuttosto complessi in verità, che indicano tutti i cambiamenti effettuati?

SubEthaEdit può essere un’ottima risposta a questo problema.

Una funzione analoga ce l’ha anche Markdown, che usa i tag {== e ==} per mettere in evidenza il testo compreso fra essi. Purtroppo non tutti gli interpreti Markdown supportano questi tag (fra cui, purtroppo, l’interprete usato da Wordpress.com), una particolarità che crea non poca confusione.
Per aggirare il problema, si può usare la coppia di tag standard HTML5 <mark>testo evidenziato</mark>, che di default produce un testo con uno sfondo giallo (ma si possono usare facilmente altri colori). ↩︎
Per i più curiosi, i miei editor sono, in ordine di preferenza, TextMate, BBEdit e Visual Studio Code, che ho dovuto adottare al posto del defunto Atom. Uso anche la versione per macOS di GNU Emacs, ma ammetto di farlo molto meno spesso di quanto vorrei. ↩︎
Emacs dispone dell’highlight-changes-mode che avrebbe fatto perfettamente al caso mio, ma c’erano dei motivi pratici che mi impedivano di usarlo. ↩︎
E comunque diff lavora su due file diversi, una cosa che nel mio caso particolare avrebbe aggiunto un ulteriore livello di complicazione. ↩︎
L’ho già detto ma è meglio ripetere: a differenza di altri strumenti che confrontano due file separati, uno contenente il testo originale e l’altro quello modificato, SEE opera in tempo reale e direttamente sul testo in lavorazione, semplificando parecchio il lavoro di revisione ↩︎
In effetti ci sarebbe un’altra opzione, usare Meld. Ma fino a poco tempo fa, per motivi che mi sfuggono, Meld si rifiutava di partire sul mio Mac con macOS Monterey, per cui non ho provato nemmeno ad usarlo per questo lavoro. Da un po’ però funziona, per cui potrebbe essere argomento per un prossimo articolo. ↩︎

SubEthaEdit, scrivere insieme in tempo reale

Mon, 30 Oct 2023 06:00:00 +0000

– Fonte: Annie Spratt su Unsplash.

SubEthaEdit è in giro da un bel po’ di tempo, se la memoria non mi inganna più o meno dai tempi di Tiger.¹ Quando uscì fece scalpore, perché per la prima volta dava la possibilità a più utenti di lavorare contemporaneamente allo stesso documento, con il limite che tutti i Mac dovevano essere connessi alla stessa rete locale.

Oggi, fra Office 365, Teams, Google Documents (e naturalmente Overleaf), scrivere un testo in collaborazione fra vari utenti sparsi nel mondo sembra una cosa scontata,² ma 20 anni fa era una funzione mai vista prima su un computer personale.

Infatti, secondo uno degli autori, la scrittura collaborativa di un testo è stata inventata intorno alla metà degli anni ‘90 presso il solito Xerox PARC, ma fino a SubEthaEdit nessuno aveva pensato di applicarla ad un prodotto commerciale.

L’editor

SubEthaEdit (SEE per gli amici) è un editor di testo puro, proprio come TextMate, BBEdit, Sublime Text o il defunto Atom, ormai soppiantato da Visual Studio Code.³

SEE ha tutte le funzioni di base di un editor moderno, riconosce la sintassi dei principali linguaggi di programmazione (tranne R, accidenti!), così come di Markdown e di LaTeX, e può essere configurato in modo abbastanza dettagliato, per adattarsi al meglio ai gusti personali.

A questo proposito, io preferisco visualizzare i caratteri nascosti (Show: Invisible Characters) e sostituire i tab con gli spazi (una abitudine da programmatore). Entrambe le modifiche si fanno nel pannelo Editing delle Preferenze di SEE. Mi piace anche ingrandire leggermente il font di default a 12 punti e aumentare la spaziatura fra le linee al 110% per rendere il testo più leggibile e più consistente con gli altri editor che uso (pannello Styles).

Rispetto ai mostri sacri citati prima, SEE manca di parecchie funzioni, fra cui alcune che ormai fanno parte del normale corredo di un editor moderno, come la possibilità di commentare rapidamente un blocco di codice, di aggiungere delle parentesi aperte e chiuse oppure dei simboli attorno ad un blocco di testo selezionato,⁴ oppure di effettuare una selezione per colonne, utile in particolare quando si lavora con le tabelle.⁵

SEE non ha nemmeno il completamento automatico del codice ma insomma, questa è una funzione supportata solo dagli editor più avanzati, quindi è un peccato veniale. Anche gli stili, i temi, o come volete chiamarli, sono pochi, ma almeno per me, che uso quasi sempre lo stile di default, questo è un non-problema.

Peccato anche che non metta in evidenza automaticamente gli errori ortografici, ma che io sappia questo lo fa nativamente solo BBEdit ed è uno dei motivi per usarlo per scrivere dei testi in Markdowno o LaTeX.

Molto utile, invece, la possibilità di avere visualizzazioni diverse dello stesso documento sia nella stessa finestra che in finestre separate, così come il conteggio in tempo reale del numero di caratteri, parole o linee di cui è composto un documento, una funzione che mi avrebbe aiutato moltissimo qualche mese fa.

Per averlo, bisogna attivare dal menu View la visualizzazione della barra di stato superiore e inferiore (che servirà fra poco), che riportano una serie di informazioni utili sul documento aperto fra cui, a destra della barra di stato superiore, proprio il numero di caratteri, parole o linee del documento. Cliccando sul numero si può cambiare ciclicamente il tipo di conteggio riportato.

Scrittura collaborativa

La caratteristica più interessante di SSE è il supporto nativo per la scrittura collaborativa, che permette a due o più utenti collegati alla stessa rete locale di lavorare contemporaneamente allo stesso documento.

Prima di condividere un documento bisogna aprire il pannello Collaboration delle Preferenze di SEE e assicurarsi di aver attivato l’opzione relativa (Enable Collaboration) e di non essere invisibili agli altri utenti della rete (Invisible to others on the Network).

È sufficiente ora cliccare sull’icona in basso a destra nella barra di stato (quella che assomiglia al simbolo del Wi-Fi ruotato) per rendere il documento disponibile agli altri utenti della rete. Questa circostanza viene indicata in modo evidente nella stessa barra di stato, dove compare una grossa icona colorata con le iniziali dell’utente che ha iniziato la condivisione. Per differenziare meglio i vari utenti è possibile personalizzare l’icona ed il colore associato a ciascun utente nel solito pannello Collaboration delle Preferenze, come si può vedere nelle due immagini qui sotto.

A questo punto, se un altro utente esegue SubEthaEdit su un Mac collegato alla stessa rete locale, potrà accedere non solo alla lista dei suoi documenti locali più recenti, ma anche a quelli condivisi su cui può collaborare.

Per farlo, dovrà cliccare sul nome del documento condiviso e aspettare di essere autorizzato a modificare o eventualmente soltanto a leggere il documento in questione, potendo così iniziare la sua attività di scrittura a quattro (o più) mani.

Anche la barra di stato di SEE cambierà, mostrando le icone dei due (o più) utenti che stanno lavorando in contemporanea, con i colori associati a ciascun utente.

Questi colori sono fondamentali, perché permettono di valutare a colpo d’occhio chi ha effettuato ciascuna modifica. È anche possibile lavorare sulla stessa porzione di testo, correggendo e integrando ciò che ha scritto l’altro.

SEE non ha problemi nemmeno quando si prova a scrivere in contemporanea esattamente nello stesso punto, ma si limita ad inserire entrambi i caratteri, differenziandoli in base all’utente. Per quanto ci abbia provato non sono mai riuscito a mandarlo in crash con giochetti di questo tipo.

In alternativa alla trafila di condivisione descritta prima, è anche possibile invitare esplicitamente a collaborare un altro utente che ha già aperto SEE sul suo Mac.

Inoltre, cliccando con il tasto destro del mouse sull’icona simil-Wi-Fi in basso a destra, è possibile definire a priori se il documento su cui si sta lavorando è modificabile dagli altri utenti, solo leggibile oppure è bloccato. In quest’ultimo caso non viene condiviso in rete e potrà essere modificato solo in locale.

Insomma, le possibilità non mancano, ed anche se ormai dovremmo essere abituati a lavorare in rete sullo stesso file, qui tutto si svolge in modo molto fluido e intuitivo. Peccato solo per il limite della rete locale e per il fatto che SEE giri solo su macOS, due fattori che rendono il programma utile solo ad un numero piuttosto ristretto di utenti.

Conclusioni

SubEthaEdit è un discreto editor di testo per macOS, che diventa insostituibile quando si ha bisogno di utilizzare le sue funzioni di scrittura collaborativa. Devo ammettere, però, che finora ho sempre preferito i suoi fratelli maggiori, in particolare TextMate e BBEdit.

Ma ultimammente ho scoperto una funzione piccola-piccola e molto specialistica di questo programma che, quando serve, si dimostra davvero insostituibile. Però di questo ne parlerò la prossima volta.

Mi sono sbagliato di poco, secondo Wikipedia la prima versione di SubEthaEdit risale ai tempi di Panther (Mac OS X 10.3), il sistema operativo immediatamente precedente a Tiger (10.4). ↩︎
Ma conosco fin troppi utenti rimasti ancorati allo scambio via email di una sequenza interminabile di documento_v1.docx,documento_v2.docx, documento_v2b.docx, documento_v2b_ultima_versione.docx, seguiti inevitabilmente da documento_v2b_straultimissima_versione.docx e da documento_v2b_sara_la_volta_buona.docx ↩︎
Chi rimpiange Atom può provare Pulsar, un fork open source di Atom che aspira ad essere una versione migliorata e più moderna del genitore, ma che su macOS ha sembra avere ancora problemi di prestazioni. ↩︎
Con gli altri editor quando scrivo in Markdown sono abituato a selezionare un blocco di testo e a scrivere _ o ** per circondarlo con i tag che lo fanno visualizzare rispettivamente in italico o in grassetto. Con SEE non funziona e questa mancanza mi ha fatto penare durante la scrittura di questo articolo. ↩︎
Ho proposto di aggiungere queste funzioni sul repository GitHub del programma ma finora non ho ricevuto alcun feedback dagli sviluppatori. Vedo anche che la maggior parte delle richieste rimangono inascoltate ed è probabile che la mia farà la stessa fine. ↩︎

Script per tutti i giorni: lo script è il comando

Fri, 12 Apr 2019 18:00:00 +0000

Nelle puntate precedenti abbiamo visto come scrivere dei semplici script in bash o in awk che risolvono un problema assai specifico, è vero, ma che possono anche costituire una buona base di partenza per affrontare argomenti più complessi (i link alle puntate precedenti si trovano alla fine dell’articolo).

In particolare, nella terza puntata abbiamo imparato come rendere i nostri script quasi indistinguibili dai normali comandi del Terminale: (1) si aggiunge in testa allo script lo shebang, cioè la sequenza di caratteri #!, seguita dal percorso completo al programma da utilizzare per eseguire lo script,¹ (2) si usa il comando chmod per rendere lo script eseguibile (almeno) all’utente attuale del Mac,

$ chmod u+x nomescript

dove nomescript è il nome generico dello script che vogliamo rendere eseguibile (ad esempio lo script convert_title.sh della terza puntata).

Il “quasi” di prima dipende dal fatto che, anche con queste modifiche, ogni volta che eseguiamo lo script dobbiamo indicare esplicitamente la directory dove si trova. Ad esempio, se ci siamo spostati con cd nella directory che contiene nomescript, per eseguirlo script dobbiamo scrivere

$ ./nomescript

premettendo quindi al nome dello script il percorso (./) alla directory corrente.

Invece, quando eseguiamo uno dei comandi del sistema operativo, ci basta scrivere il nome del comando nel Terminale e il sistema operativo (o più precisamente la shell che stiamo usando, che in genere è bash)² va a cercare il programma sul disco rigido e lo esegue senza troppi problemi.

Qual’è il meccanismo che permette alla shell di sapere in quale directory si trovano i comandi che eseguiamo nel Terminale? Esiste un modo per replicare questo comportamento anche per i nostri script, rendendoli praticamente indistinguibili dai comandi intrinseci del sistema operativo?

Variabili di ambiente

In realtà non c’è niente di sofisticato o di particolarmente intelligente in quello che fa la shell. La chiave di tutto sta nelle variabili di ambiente di bash, delle variabili speciali usate fra l’altro per specificare le impostazioni di lavoro della shell. Se lanciamo il Terminale ed eseguiamo il comando

$ env

otterremo un lungo elenco con tutte le variabili di ambiente definite da bash, che per convenzione vengono scritte in maiuscolo. Fra queste spiccano HOME, che definisce il percorso alla cartella Home dell’utente che sta usando il Mac, USER che riporta il nome account (o nome breve) dell’utente, e PWD che contiene il percorso alla directory in cui ci troviamo (percorso che, come già visto, si può ricavare con il comando pwd, ma guarda la combinazione).

Se siamo interessati solo ad una particolare variabile di ambiente, possiamo stamparla con echo seguito dal nome della variabile di ambiente, che però deve essere preceduto dal simbolo $. Ad esempio

$ echo $HOME

stampa nel Terminale il valore della variabile di ambiente HOME.

Fra tutte le variabili di ambiente elencate da env, quella che ci interessa di più in questo momento è PATH, che contiene una serie di percorsi di directory separati dal simbolo :. Nella configurazione di default il valore del PATH è

$ echo $PATH
PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

Shell e PATH

È proprio il PATH che permette alla shell di trovare da sola i comandi di sistema. Ogni volta che eseguiamo un comando nel Terminale, la shell lo cerca nelle directory indicate nel PATH, esaminandole una dopo l’altra nell’ordine in cui sono scritte. Se trova il comando lo esegue immediatamente, senza preoccuparsi di esaminare le directory successive, altrimenti dà un errore di command not found.

Di conseguenza, l’ordine in cui sono elencati i percorsi nel PATH è importante. Questa particolarità può essere sfruttata per sostituire un comando del sistema operativo con una versione più recente, senza però cancellare il comando originale: se il comando originale è situato in /usr/bin o in /bin, basta installare la versione aggiornata in una directory del PATH che precede queste due directory, come ad esempio /usr/local/bin (che nei sistemi Unix serve proprio per installare il software “locale” non gestito direttamente dal sistema operativo).³

La seconda conseguenza è che, se modifichiamo il PATH aggiungendo altre directory in testa o in fondo all’elenco originale, possiamo obbligare la shell a cercare i comandi anche in queste nuove directory non presenti nella configurazione di default. Che è proprio quello che ci serve.

Prima di andare avanti una avvertenza FONDAMENTALE. Possiamo aggiungere senza troppi problemi delle nuove directory al PATH di default, ma non dobbiamo MAI MAI MAI rimuovere le directory presenti nella configurazione originale del PATH, in particolare le quattro directory /usr/bin:/bin:/usr/sbin:/sbin (leggetele ad alta voce e notate l’assonanza). Cancellare per errore una di queste directory dal PATH significa non poter più usare il Mac, o perlomeno dover usare degli strumenti non alla portata di tutti per rimettere a posto le cose.

Siete avvertiti!!!

Modificare il PATH

Per aggiungere (o rimuovere) delle directory al PATH di default del nostro Mac dobbiamo modificare con un editor di testo (non con un wordprocessor!) il file .bashrc situato nella nostra HOME. Questo introduce una piccola complicazione, perché il file ~/.bashrc è un file nascosto, non accessibile direttamente dal Finder.

Se usiamo emacs o vi possiamo aprire .bashrc direttamente dal Terminale. Ci basta spostarci nella HOME

$ cd ~

ed eseguire

$ emacs .bashrc

oppure

$ vi .bashrc

Se questi editor ci sembrano troppo difficili da usare (e lo sono!), possiamo usare nano che, come emacs e vi, si trova installato di default su ogni Mac

$ nano .bashrc

Anche se nano è un editor piuttosto limitato rispetto ai due mostri sacri, è molto comodo per modificare velocemente i file di sistema senza dover affrontare una lunga fase di apprendimento.

Se invece preferiamo usare un editor grafico come BBEdit, TextMate, Atom o simili, la procedura esatta per aprire un file nascosto dipende dall’editor scelto.

Alcuni editor permettono di installare un comando di Terminale con cui lanciare l’editor dalla linea di comando: mate per TextMate, atom e bbedit per… lo sapete già. Anche con questi editor, quindi, possiamo aprire .bashrc dal Terminale con uno dei comandi seguenti

$ mate .bashrc 
$ atom .bashrc
$ bbedit .bashrc

Con BBEdit e TextMate, la finestra di apertura file dispone di un tasto Opzioni con il quale si può decidere di mostrare (e quindi di aprire) anche i file nascosti

Ma il metodo più generale per modificare un file nascosto con un editor grafico è quello di usare il comando open dal Terminale

$ cd ~
$ open -a "TextMate" .bashrc

dove l’opzione -a permette di specificare l’applicazione con cui aprire il file indicato.

Qualunque sia il metodo utilizzato, alla fine ci ritroveremo con il file .bashrc pronto per essere modificato. Tutto quello che dobbiamo fare è aggiungere questa linea alla fine di .bashrc

export PATH=$PATH:~/Development

che istruisce la shell di andare a cercare i comandi da eseguire nel Terminale anche nella directory ~/Development, dove abbiamo deciso di salvare tutti gli script che sviluppiamo.

Una volta fatta questa semplice modifica, salviamo il file .bashrc e usciamo dall’editor. Chiudiamo e riapriamo il Terminale per costringere la shell a rileggere il file .bashrc (oppure eseguiamo il comando $ source ~/.bashrc senza chiudere il Terminale) e proviamo di nuovo ad eseguire nomescript, ma questa volta senza premettere il percorso alla directory dove si trova

$ nomescript

Questa volta lo script funzionerà senza bisogno di aiutini, proprio come se fosse un normale comando di sistema. Per verificare che tutto funzioni come descritto possiamo provare ad eseguire uno degli script della terza o della quinta puntata.

Ma non è ancora finita…

Bisogna ammetterlo, aggiungere al $PATH una directory qualunque come ~/Development può andar bene per fare delle prove veloci, ma non è per niente elegante. Sarebbe molto meglio adeguarsi alle convenzioni di Unix, secondo le quali i programmi eseguibili devono trovarsi in una directory denominata bin.

Niente di più facile, possiamo creare facilmente una directory bin nella nostra HOME

$ cd
$ mkdir bin

e decidere di tenere gli script in fase di sviluppo nella directory ~/Development, per poi spostarli (o meglio copiarli) in ~/bin quando sono pronti per essere usati. Naturalmente dovremo modificare di conseguenza il file .bashrc, aggiungendo alla fine del file

export PATH=$PATH:~/bin

al posto di export PATH=$PATH:~/Development visto sopra.

Non ci piace vedere con il Finder la directory bin nella HOME? Possiamo nasconderla con facilità, basta solo eseguire dal solito Terminale il comando

$ chflags hidden ~/bin

(il comando duale $ chflags nohidden ~/bin rende di nuovo visibile la directory).

Conclusioni

Per i più pigri che non vogliono andare a rileggere le puntate precedenti per provare le novità descritte nell’articolo, ecco un semplice script in bash che mostra la data e l’ora corrente nel formato standard Unix e in una forma molto più dettagliata (e per una volta anche nella nostra lingua)

#!/bin/bash

year=`date +%Y`
month=`date +%B`
day=`date +%d`
hour=`date +%H`
minute=`date +%M`
second=`date +%S`
dayofyear=`date +%j`
weekday=`date +%A`

echo `date`
echo -n "Oggi è $weekday $day $month $year, "
echo -n "il $dayofyear-esimo giorno dell'anno, "
echo "e sono le ore $hour:$minute:$second"

Copiamo lo script nell’editor preferito, salviamolo in ~/bin (o in ~/Development) con il nome data_estesa, rendiamolo eseguibile con chmod e proviamo che funzioni come previsto

$ data_estesa
Fri Apr 12T17:28:00:50 CEST 2019
Oggi è Venerdì 12 Aprile 2019, il 102-esimo giorno dell'anno, e sono le ore 17:28:50

E per oggi è davvero tutto.

Articoli precedenti

Per leggere gli articoli precedenti della serie basta cliccare sui link qui sotto.

Prima puntata, Script per tutti i giorni: semplici modifiche alle stringhe di testo
Seconda puntata, Script per tutti i giorni: dalla linea di comando al programma
Terza puntata, Script per tutti i giorni: shell e parametri
Quarta puntata, Script per tutti i giorni: ricapitoliamo
Quinta puntata, Script per tutti i giorni: entra in scena awk

Sul Mac uno script in bash richiede il percorso /bin/bash, uno in awk puro /usr/bin/awk, mentre uno nella ormai veneranda versione 2.7 di python installata di default in macOS richiede /usr/bin/python (ma ci vuol poco ad installare python3 con Homebrew o Conda). ↩︎
Ma ci sono anche zsh, ksh, tcsh, fish, solo per menzionare le shell più note. ↩︎
È esattamente quello che fa Homebrew, uno strumento utilissimo (di cui ho scritto parecchio su questo blog) che utilizza /usr/local/bin per installare un gran numero di strumenti software provenienti dal mondo Linux e non disponibili su macOS, oppure per aggiornare a versioni più recenti quelli, normalmente piuttosto datati, forniti da Apple insieme al sistema operativo. ↩︎

Script per tutti i giorni: entra in scena awk

Mon, 18 Feb 2019 18:00:00 +0000

– Tastiera A.W.K., Viscount Instruments.

Nelle prime tre puntate di questa serie abbiamo imparato a scrivere uno script in bash per trasformare una stringa di testo in modo che segua delle convenzioni ben determinate a priori (qui i link alla prima, seconda e terza puntata).

In questo caso particolare, la stringa risultante dalla trasformazione deve essere scritta tutta in minuscolo e non deve contenere apostrofi o altri caratteri speciali, a parte il trattino usato come separatore di parole. L’idea è quella di usare questa stringa, insieme alla data di pubblicazione del post, per dare un nome standard e facilmente rintracciabile al file Markdown che contiene il testo del post stesso, utilizzando il formato YYYY-MM-DD-titolo-del-post.md, dove YYYY indica l’anno, MM il mese e DD il giorno di pubblicazione.

L’approccio seguito finora è utile per imparare i fondamenti della programmazione in bash, ma manca decisamente di praticità. Partire dal titolo e dalla data di pubblicazione presenti nell’intestazione del post per arrivare al nome completo del file richiede un certo lavoro di copia e incolla fra l’editor, il Finder e il Terminale, e gli errori sono sempre in agguato.

Quello che ci vuole è uno script che renda il processo completamente automatico, rinominando il file Markdown a partire dal contenuto del documento stesso.¹

Si potrebbe benissimo fare anche con bash, ma perché complicarsi la vita quando c’è uno strumento fatto apposta per analizzare ed estrarre dei dati dai file di testo?

AWK, questo sconosciuto

AWK è un linguaggio di programmazione interpretato sviluppato negli anni ‘70 presso i Bell Labs, il famosissimo centro di ricerca americano che ci ha dato il transistor, il laser, Unix e il C (e moltissimo altro). AWK è stato sviluppato da Alfred Aho, Peter Weinberger e Brian Kernighan, tre grandi studiosi di computer science, fra i quali spicca il terzo, coautore insieme a Dennis Ritchie di The C Programming Language, il volume di riferimento sul linguaggio C, noto anche semplicemente come “K&R” dai cognomi dei due autori.

Alla base di AWK c’è l’idea di elaborare un file di testo una riga alla volta, controllando che la riga in esame soddisfi una o più condizioni prestabilite ed eseguendo le azioni programmate per ciascuna di queste condizioni

    condizione #1: {azione #1}
    condizione #2: {azione #2}
    ...
    condizione #N: {azione #N}

Per AWK un file di testo è costituito da un certo numero di righe (record), ciascuna delle quali è suddivisa in uno o più campi (field), separati fra loro da un separatore di campo, che di default è lo spazio ma che può essere modificato a piacere. Per riferirsi a ciascun campo AWK usa le variabili speciali $1, $2 e così via, dove il numero indica la posizione del campo all’interno della riga. La variabile $0 contiene l’intera riga corrente.

Tutto qui? Più o meno. C’è (quasi) solo da aggiungere che AWK prevede due azioni speciali opzionali, racchiuse fra i blocchi BEGIN {...}, END {...}, che servono per eseguire le operazioni preliminari e conclusive necessarie per il buon funzionamento del programma, ad esempio per definire il separatore di campo. Un programma completo in AWK ha quindi una struttura di questo tipo,

    BEGIN { istruzione
            istruzione
            ....
          }
    
    condizione #1: { istruzione
                     istruzione
                     ....
                   }
    condizione #2: { istruzione
                     istruzione
                     ....
                   }

    ...
    condizione #N: { istruzione
                     istruzione
                     istruzione
                     ....
                   }

     END { istruzione
           istruzione
           ....
         }

dove come già detto i blocchi BEGIN {...}, END {...} sono opzionali.

Nonostante la fama dei suoi autori, AWK è poco utilizzato, molto meno di quanto meriterebbe, i programmatori del mondo UNIX preferiscono usare strumenti più semplici ma meno potenti come sed (che abbiamo già incontrato nelle puntate precedenti) o il declinante perl, un linguaggio di manipolazione di file di testo perfetto per i programmatori che mitizzano Tafazzi.

AWK invece ha il giusto equilibrio di potenza e semplicità d’uso ed è uno strumento perfetto se gli si chiede di fare quello per cui è stato ideato, elaborare informazioni strutturate contenute in file di testo.

Per fortuna AWK è installato di default in macOS e in Linux, oltre che in tutti i sistemi operativi basati su UNIX che si trovano in giro, per cui per provarlo basta lanciare il Terminale ed eseguire il comando awk. In realtà ci sono in giro almeno due versioni diverse di AWK. In macOS è installato awk liscio, la versione del linguaggio definita dai tre autori originali nel volume The AWK programming language. Su Linux, invece, si trova in genere gawk, una implementazione del linguaggio della Free Software Foundation pienamente compatibile con awk, a cui sono state aggiunte alcune estensioni piuttosto utili. Installare gawk su macOS è facile per chi usa Homebrew, dal Terminale

$ brew install gawk

Da ora in poi per semplicità farò cadere la distinzione fatta finora fra AWK, il linguaggio di programmazione, e awk, l’interprete del linguaggio, usando sempre e solo il termine awk per riferirmi ad entrambi.

Un programma banale in awk

Per avere una idea di cosa può fare awk, ecco un piccolissimo (e rozzo) programma di esempio,

BEGIN { FS = ","
        OFS = ", "
      }

$1 ~ /Violanda/ { $1 = "Jolanda" }
                { print $2, $1, $3, $6, $4, $5 }

che applicato ad un elenco di indirizzi come questo,

NOME,COGNOME,INDIRIZZO,LOCALITA,PROVINCIA,CAP
Massino,Nardini,Via Roma 8,Grana,AT,14031
Primo,Sabbatini,Via C. Cattaneo 50,Cala di Volpe,SS,07020
Giuseppe,Marino,Via C. Alberto 75,Barni,CO,22030
Ivano,Costa,Via Guantai Nuovi 29,Ischia,NA,80077
Margherita,Davide,Via Nuova Agnano 83,Rufina,FI,50068
Daphne,Lettiere,Via R. Conforti 67,Castel Di Ieri,AQ,67020
Violanda,Lori,Via A. Manzoni 101,Parona,PV,27020
Luigia,Cremonesi,Via Castelfidardo 145,Cittadella Del Capo,CS,87020
Fiore,Mucciano,Via Valpantena 120,Buccino Stazione,SA,84020
Sandra,Greco,Via Pisanelli 140,Castiglione D'Adda,LO,26823

scambia la posizione del nome e del cognome e sposta il CAP prima della Località in tutte le righe del file. Già che c’è, corregge anche il nome sbagliato “Violanda” e lo trasforma in “Jolanda”. Nella riga #5, $1 ~ /Violanda/ è la condizione, e {$1 = "Jolanda"} l’azione relativa, mentre nella riga #6 la condizione è vuota e quindi l’azione conseguente {print $2, $1, $3, $6, $4, $5} si applica a tutte le righe del file. Il blocco BEGIN {...} serve per definire il carattere (o i caratteri) che separa i campi contenuti in ciascuna riga letta o scritta dal programma: la variabile predefinita FS è il separatore dei campi del file di input (quello letto dal programma), OFS è il separatore dei campi delle righe stampate dallo script.

Per provarlo, copiate il programma in un editor e salvatelo come swap.awk, poi copiate la lista di indirizzi e salvatela come address.csv (meglio se salvate i due file nella cartella ~/Development, ricordate?). Infine lanciate il Terminale, eseguite il comando

$ awk -f swap.awk address.csv

e vedete cosa viene fuori. Provate a cambiare OFS e a vedere che succede.

Domanda 1: Come si fa a lanciare lo script senza dover premettere il comando awk?

Domanda 2: Se si rimuove la variabile FS dal blocco BEGIN{...} lo script continua a funzionare correttamente?

Ma basta con awk. Questo articolo non vuole essere una introduzione al linguaggio ma vuole solo mostrare come si può risolvere con AWK il problema che ci sta a cuore. Chi volesse è approfondire la conoscenza del linguaggio può consultare i volumi e le guide online riportate in bibliografia.

Rinominare automaticamente un post

E finalmente eccoci al programma awk che rinomina da solo il file Markdown di un post in base al titolo e alla data contenuti nei metadati del documento, che contengono, fra l’altro, il titolo, la data di pubblicazione, la categoria e i tag associati al post stesso.

BEGIN { FS = " "
        OFS = "-"
        EXT = ".md"
      }

$1 ~ /[Dd]ate:/   { date = $2 }
$1 ~ /[Tt]itle:/  { title = ""
                    for (i = 2; i <= NF; i++) {
                        title = title FS tolower($i)
                    }
                  }

END { newfilename = date OFS title
      gsub("[[:cntrl:]]", "", newfilename)
      gsub("[\"]+", "", newfilename)
      gsub("[\.,;:!\?&\$]+", "", newfilename)
      gsub("[-| ]+", "-", newfilename)
      newfilename = newfilename EXT
      system("mv " FILENAME " " newfilename)
    }

Riassumo brevemente cosa fa il programma, chi non fosse interessato può saltare direttamente al prossimo paragrafo. La prima condizione $1 ~ /[Dd]ate/ cerca la stringa date: (indifferentemente in minuscolo o maiuscolo) nel primo campo di tutte le righe del post e quando la trova assegna il secondo campo, corrispondente alla data, alla variabile date. La seconda condizione fa lo stesso per il titolo e lo assegna alla variabile title. Poiché il titolo è distribuito su un numero imprecisato di campi (ricordo che il separatore di campo FS è lo spazio), viene utilizzato un ciclo for per leggere ed aggiungere in successione a title tutti i campi della riga successivi al primo. Il numero di campi presenti nella riga del titolo è contenuto nella variabile di sistema NF, aggiornata automaticamente dall’interprete ogni volta che viene letta una nuova riga. La parte finale del programma, racchiusa nel blocco END {...}, si occupa di definire la variabile newfilename, contenente il nuovo nome da assegnare al file, e di trasformarla secondo le regole desiderate. La variabile newfilename contiene inizialmente (riga #12) la data e il titolo letti nel post, separati da un trattino (il valore di OFS). Nelle quattro righe successive viene utilizzata la funzione gsub per rimuovere da questa variabile tutti i caratteri indesiderati (caratteri di controllo, virgolette, punteggiatura) e per sostituire spazi e trattini (anche multipli) con un trattino singolo. Alla riga #17 viene aggiunta l’estensione definita in EXT, mentre l’ultima riga del blocco effettua una chiamata al sistema operativo per rinominare effettivamente il file, utilizzando un’altra variabile di sistema, FILENAME, che contiene il nome originale del file Markdown su cui sta operando lo script.

Salviamo il programma nella solita cartella Development con il nome setpostname.awk. Per provarlo dobbiamo avere anche un file Markdown contenente nell’intestazione (header) almeno i metadati relativi al titolo e alla data. Possiamo prendere la prima parte di questo post,

---
layout: post  
title: "Script per tutti i giorni: entra in scena awk"  
author:	Sabino Maggi  
date: 2019-02-18T18:00:00  
categories:  
  - programmazione  
tags:  
  - awk  
  - bash  
  - editor  
  - gawk  
  - perl  
  - script  
  - terminale  
comments: true  
sidebar: true  
toc: true  
published: 2019-02-18T18:00:00  
slug:  

---

Nelle prime tre puntate di questa serie abbiamo imparato a scrivere uno script in `bash` per trasformare una stringa di testo in modo che segua delle  convenzioni ben determinate a priori (qui i link alla [prima](https://melabit.wordpress.com/2018/11/23/script-per-tutti-i-giorni-semplici-modifiche-alle-stringhe-di-testo/), [seconda](https://melabit.wordpress.com/2018/12/05/script-per-tutti-i-giorni-dalla-linea-di-comando-al-programma/) e [terza](https://melabit.wordpress.com/2018/12/30/script-per-tutti-i-giorni-shell-e-parametri/) puntata).

In questo caso particolare,...

e salvarlo con un nome qualsiasi nella stessa cartella Development. Poiché la fantasia fa difetto, chiamiamolo articolo.md. A questo punto lanciamo il Terminale, spostiamoci nella cartella Development

$ cd ~/Development

e lanciamo lo script in awk con il comando

$  /usr/bin/awk -f setpostname.awk articolo.md

e voilà, il file articolo.md viene rinominato automaticamente in 2019-02-18-script-per-tutti-i-giorni-entra-in-scena-awk, che è esattamente quello che volevamo. Nota per i più curiosi: dato che awk ha bisogno di sapere sia il nome dello script contenente i comandi che quello del file da elaborare, si usa l’opzione -f per indicare esplicitamente lo script con i comandi.

Perché uso l’intero percorso /usr/bin/awk per richiamare awk? Semplicemente perché voglio essere sicuro di utilizzare l’interprete awk presente di default in macOS e non la versione estesa installata tramite Homebrew, che funziona in modo leggermente diverso e darebbe degli avvertimenti poco incomprensibili, pur riuscendo lo stesso a rinominare correttamente il file.

Conclusioni

Ormai siamo quasi a posto con la rinominazione automatica di un post in Markdown (che poi in effetti è solo una scusa per gettare le basi e per poter affrontare script complessi e più utili). Manca solo un piccolissimo dettaglio, che può far diventare questo script del tutto indistinguibile dai comandi standard del sistema operativo e che sarà l’argomento della prossima puntata.

Bibliografia

Alfred Aho, Brian Kernighan, Peter Weinberger, The AWK programming language, Addison-Wesley, 1988.
Arnold Robbins, Gawk: Effective AWK Programming, Edition 4.2, 2018.
Sculpting text with regex, grep, sed, awk, emacs and vim.
Wikibooks, An Awk Primer.
Bruce Barnett, Awk a Tutorial and Introduction.
Tutorials Point, Awk Tutorial.

Una cosa che io trovo bellissima anche dal punto di vista diciamo così, filosofico, e che mi ricorda i bellissimi articoli di Douglas Hofstadter su Le Scienze sui testi autoreferenziali. ↩︎

Script per tutti i giorni: shell e parametri

Sun, 30 Dec 2018 18:00:00 +0000

– Foto: Trammell Hudson su Flickr.

Lo script di conversione del titolo di un post mostrato alla fine della puntata precedente è diventato ormai quasi “utilizzabile”. Mancano solo un paio di tocchi finali, che vedremo nel corso di questa terza parte.

Una casa per i programmi

Prima di proseguire è bene decidere una volta per tutte dove salvare gli script che stiamo sviluppando. Non so voi, ma io preferisco usare una cartella dedicata allo scopo invece di buttare tutto dove capita. In tutti gli articoli di questa serie gli script in fase di sviluppo saranno salvati nella cartella Development, situata all’interno della cartella Home (o Inizio) dell’utente che ha effettuato il login (la cartella Home è quella rappresentata dall’icona di una casetta). Ovviamente siete liberi di usare un altro nome e un’altra posizione sul disco rigido, ma dovrete ricordarvi di modificare di conseguenza i percorsi dei comandi.

Già che ci siamo, creiamo subito la cartella Development. Se usate il Finder non ho bisogno di dirvi come si fa, se invece usate il Terminale basta eseguire i comandi

$ cd ~
$ mkdir Development

dove il primo comando, cd ~ (ma su macOS e varie versioni di Linux è sufficiente il semplice cd) ci fa spostare nella nostra Home, mentre il secondo comando crea la nuova directory Development. Nelle shell Unix come bash, il simbolo tilde ~ (che si scrive premendo ALT-5) indica la Home dell’utente.

Volendo potremmo anche eseguire semplicemente

$ mkdir ~/Development

che crea la directory desiderata con un unico comando.

Qualche breve nota generale. In questo contesto i termini script o programma sono equivalenti e li userò indifferentemente. Lo stesso vale per directory e cartella. Io preferisco il primo, ma so benissimo che, da quando esistono le interfacce grafiche, il termine “cartella” è diventato di uso molto più comune. Nel seguito cercherò di usare “cartella” nel testo discorsivo degli articoli e “directory” quando si tratterà di riferirsi ai comandi di bash e al Terminale. Infine, il simbolo $ prima di ogni comando è il cosiddetto prompt e serve ad indicare che stiamo interagendo con il Terminale; non fa parte dei comandi e quindi non deve mai essere inserito quando scriviamo un comando nel Terminale.

Andare con le proprie gambe

Nella puntata precedente siamo arrivati ad usare uno dei tanti editor di testo disponibili su macOS per inserire queste righe di codice

string="La privacy al tempo dell'Internet of Things: gran finale"
 
fix_string=$(echo $string | tr "[:upper:]" "[:lower:]")
fix_string=$(echo $fix_string | sed "s/'/ /g")
fix_string=$(echo $fix_string | sed "s/[[:punct:]]//g")
fix_string=$(echo $fix_string | sed "s/ /-/g")
 
converted_string=$fix_string
echo $converted_string

Ora possiamo salvare lo script nella cartella ~/Development/, dandogli un nome significativo che ci aiuti a ricordare anche in un secondo momento cosa fa il programma. Molto meglio quindi usare un nome come convert_title.sh piuttosto che un criptico SCCUSIFJ.sh, anche se profuma tanto di DOS e di anni ‘80.

Nei sistemi Unix come macOS l’estensione .sh non è indispensabile ma ci aiuta a capire al volo che il file è uno script della shell (da cui .sh). È possibile usare altre estensioni come .shell, .script, .cmd o perfino .bat, per il sistema operativo non cambia nulla.

A questo punto possiamo finalmente di eseguire lo script. Lanciamo il Terminale, spostiamoci nella cartella dove abbiamo salvato lo script

$ cd ~/Development

ed eseguiamo lo script con il comando

$ sh convert_title.sh
la-privacy-al-tempo-dell-internet-of-things-gran-finale

ottenendo, come previsto, la trasformazione della stringa definita nella string nel formato adatto a Jekyll o a Wordpress.

Per eseguire lo script dobbiamo premettere al nome del file il comando sh che indica al sistema operativo che il file in questione contiene una serie di comandi di shell, cioè di comandi che permettono di interagire con il sistema operativo stesso (attenzione, il comando sh è una cosa ben diversa dall’estensione .sh vista prima!). Con questa informazione, il sistema operativo trasferisce l’esecuzione dello script alla shell di default, che in macOS e nella maggior parte dei sistemi Linux attuali è bash. Niente però impedisce di forzare l’utilizzo di bash, scrivendo esplicitamente

$ bash convert_title.sh

al posto di sh convert_title.sh, oppure di utilizzare altre shell eventualmente disponibili nel sistema, come tcsh, ksh, zsh o fish (argomento che non verrà trattato in questa serie).

Purtroppo affidarsi alla configurazione di default del sistema può creare problemi, ad esempio perché qualcuno ha cambiato la shell di default, magari solo per fare una prova, dimenticando di ripristinare la configurazione iniziale. Per fortuna in genere queste cose non succedono per cui possiamo stare relativamente tranquilli. Però il meccanismo appena descritto non è né semplice, né tanto meno a prova di bomba.

Proviamo a semplificarci la vita con due piccole modifiche. Prima di tutto utilizziamo il comando chmod per rendere eseguibile lo script all’utente attuale del Mac

$ chmod u+x convert_title.sh

dove la u indica l’utente che sta usando il Mac e il simbolo +x significa che il file viene reso eseguibile (la x sta per eXecute). Se volessimo rimuovere questa autorizzazione, non dovremmo far altro che eseguire il comando duale

$ chmod u-x convert_title.sh`

Se invece volessimo autorizzare tutti gli utenti del Mac ad eseguire questo script, dovremmo scrivere

$ chmod a+x convert_title.sh

mentre per autorizzare solo gli utenti che fanno parte del nostro stesso gruppo di lavoro oppure tutti gli altri utenti fuori dal nostro gruppo di lavoro, dobbiamo usare rispettivamente chmod g+x convert_title.sh oppure chmod o+x convert_title.sh.

Ma queste sono finezze utili per i server a cui accedono decine e decine di utenti contemporaneamente, i Mac sono sostanzialmente macchine monoutente (o che gestiscono un numero molto ridotto di utenti), per cui chmod u+x (o al massimo chmod a+x) a noi basta e avanza.

L’altra modifica utile è quella di indicare esplicitamente al sistema operativo quale shell vogliamo utilizzare per interpretare i comandi contenuti nel nostro script. Per farlo è sufficiente aggiungere all’inizio dello dello script la sequenza di caratteri #!, il cosiddetto shebang,¹ seguita dal percorso completo al programma di shell che vogliamo usare.

Dato che qui usiamo bash, il nostro script diventa

#!/bin/bash

string="La privacy al tempo dell'Internet of Things: gran finale"
 
fix_string=$(echo $string | tr "[:upper:]" "[:lower:]")
fix_string=$(echo $fix_string | sed "s/'/ /g")
fix_string=$(echo $fix_string | sed "s/[[:punct:]]//g")
fix_string=$(echo $fix_string | sed "s/ /-/g")
 
converted_string=$fix_string
echo $converted_string

Ma come lo troviamo il percorso di bash? C’è un comando anche per questo: which seguito dal nome di un qualunque comando Unix restituisce proprio il percorso completo del comando all’interno del filesystem. Di conseguenza which bash restituisce

$ which bash
/bin/bash

che è proprio ciò che dobbiamo inserire in testa allo script subito dopo lo shebang.

Per verificarlo, basta provare a salvare lo script modificato con un nome diverso, diciamo convert_title_v2.sh e rendiamolo esegubile con il comando chmod a+x convert_title_v2.sh descritto prima.² A differenza di convert_title.sh, questo secondo script potrà essere eseguito senza dover premettere sh

$ ./convert_title_v2.sh 
la-privacy-al-tempo-dell-internet-of-things-gran-finale

Per una serie di ragioni che vedremo in una prossima puntata, dobbiamo però aiutare il sistema operativo a trovare lo script aggiungendo esplicitamente il percorso allo script da eseguire. Poiché nei sistemi Unix (e non solo), il punto . indica la cartella corrente (mentre il doppio punto .. si riferisce alla cartella che contiene la cartella corrente), scrivere ./ immediatamente prima del nome dello script equivale a dire al sistema operativo che lo script si trova nella cartella corrente, che in questo caso è la cartella dove siamo entrati all’inizio di questa puntata con il comando cd ~/Development.

Parametri sulla linea di comando

C’è ancora una cosa che non va bene. Ogni volta che vogliamo cambiare la stringa da convertire dobbiamo intervenire direttamente sullo script, modificando la variabile string. Facendo così è facile sbagliare, e in ogni caso sarebbe molto più comodo rendere lo script indipendente dai dati sui quali deve operare (in questo caso la stringa da convertire).

Non voglio entrare nei dettagli (ma ci sarà tempo per approfondire la questione), per ora basterà dire che per rendere lo script indipendente dalla stringa da trasformare è sufficiente assegnare a string il valore della variabile convenzionale $1

#!/bin/bash

string=$1

fix_string=$(echo $string | tr "[:upper:]" "[:lower:]")
fix_string=$(echo $fix_string | sed "s/'/ /g")
fix_string=$(echo $fix_string | sed "s/[[:punct:]]//g")
fix_string=$(echo $fix_string | sed "s/ /-/g")
 
converted_string=$fix_string
echo $converted_string

L’interprete bash assegna automaticamente alle variabili $1, $2, … $9, dette parametri posizionali, i valori degli argomenti dello script, cioè i valori dei parametri presenti sulla linea di comando subito dopo il nome dello script da eseguire.³ I diversi parametri sono separati da uno o più spazi, e se un parametro contiene degli spazi bisogna racchiuderlo fra virgolette, non importa se semplici ' o doppie " (però è preferibile ~~essere consistenti ed~~ evitare di mescolare i due simboli).

Salviamo lo script così modificato con il solito nome convert_title.sh e torniamo al Terminale. Ora per usare lo script dobbiamo scrivere la stringa da convertire direttamente sulla linea di comando, subito dopo il nome del file, racchiudendola fra virgolette dato che la stringa contiene degli spazi (io preferisco usare le virgolette doppie)

$ ./convert_title.sh "La privacy al tempo dell'Internet of Things: gran finale"
la-privacy-al-tempo-dell-internet-of-things-gran-finale

Naturalmente niente impedisce di trasformare stringhe molto più lunghe, come ad esempio un paragrafo di questo stesso articolo, l’unica limitazione è che la stringa non deve contenere dei caratteri di ritorno a capo

$ convert_title.sh "Purtroppo affidarsi alla configurazione di default del sistema può creare problemi, ad esempio perché qualcuno ha cambiato la shell di default, magari solo per fare una prova, dimenticando di ripristinare la configurazione iniziale. Per fortuna in genere queste cose non succedono per cui possiamo stare relativamente tranquilli. Però il meccanismo appena descritto non è né semplice, né tanto meno a prova di bomba."
purtroppo-affidarsi-alla-configurazione-di-default-del-sistema-può-creare-problemi-ad-esempio-perché-qualcuno-ha-cambiato-la-shell-di-default-magari-solo-per-fare-una-prova-dimenticando-di-ripristinare-la-configurazione-iniziale-per-fortuna-in-genere-queste-cose-non-succedono-per-cui-possiamo-stare-relativamente-tranquilli-però-il-meccanismo-appena-descritto-non-è-né-semplice-né-tanto-meno-a-prova-di-bomba

Se guardiamo attentamente il risultato della conversione notiamo come lo script non riesce a trattare correttamente i caratteri accentati, come era stato già notato esplicitamente nella prima puntata di questa serie di articoli. Per ora sarà sufficiente evitare di usare i caratteri accentati o almeno scriverli con una vocale seguita da un apostrofo, come se stessimo usando una tastiera americana.

Conclusioni (per ora)

Se togliessimo l’estensione al nome del file, lo script convert_title diventerebbe quasi indistinguibile dai comandi veri e propri del sistema operativo. Dico “quasi” perché per poterlo eseguire dobbiamo ancora premettere il percorso alla cartella corrente al nome del file. Ci sarà modo per risolvere questo (piccolo) problema, i più impazienti possono leggere qui per capire in anteprima come si fa.

La prossima volta faremo un veloce ripasso dei comandi presentati in queste prime tre puntate, utile per consolidare quanto visto finora prima di passare ad usare uno degli strumenti più potenti ma anche meno conosciuti dell’arsenale Unix.

Revisioni

30-12-2018: Corretta una imprecisione relativa al cambiamento dei permessi dei file quando la prima riga di uno script contiene lo shebang e il percorso all’interprete bash (si veda la nota 2).

Detto anche sha-bang o hashbang. ↩︎
Se la stringa #!/bin/bash è esattamente la prima riga dello script, quando salviamo lo script l’editor TextMate lo rende eseguibile da tutti gli utenti del sistema, proprio come se avessimo usato esplicitamente il comando chmod a+x .... È una particolarità del solo TextMate, tutti gli altri editor che ho provato (Atom, BBEdit, Visual Studio Code e CotEditor fra quelli grafici, nano, emacs e vim per quanto riguarda gli editor testuali) non modificano mai i permessi del file. ↩︎
Se abbiamo bisogno di più di nove parametri, dobbiamo racchiudere quelli dal decimo in poi fra parentesi graffe, scrivendo ${10}, ${11} e così via. ↩︎

Script per tutti i giorni: dalla linea di comando al programma

Wed, 05 Dec 2018 18:00:00 +0000

– Foto: Matthew Ratzloff su Flickr.

Il comando per generare automaticamente il nome del file nel formato previsto da Jekyll (o da Wordpress) dal titolo del post presentato alla fine della prima puntata potrà anche essere interessante dal punto di vista didattico ma, diciamolo, è poco pratico per essere utilizzato veramente. Bisogna lanciare il Terminale, andare a cercare il comando da qualche parte, copiarlo e incollarlo nel Terminale, cancellare il titolo preesistente e incollare il titolo del nuovo post su cui stiamo lavorando… Si fa prima a fare tutto a mano nel Finder!

Ma se lo trasformiamo in uno script, cioè in un piccolo programma eseguibile direttamente dal Terminale come un qualunque comando del sistema operativo, le cose diventano improvvisamente molto più interessanti.

Dove vai se l’editor non ce l’hai?

Per lavorare sugli script è fondamentale avere a disposizione un buon editor di testo. In macOS sono già integrati due pesi massimi, emacs e vi, eseguibili direttamente dal Terminale tramite i comandi omonimi. Fatevi un favore e non usateli.

Questi due editor, che hanno dato origine ad una vera e propria guerra di religione fra i fan dell’uno e dell’altro programma, sono perfetti per i professionisti, per chi è già esperto di programmazione ed è disposto ad affrontare una fase di apprendimento lunga e piuttosto impervia. Ma per chi è all’inizio e deve concentrarsi sull’imparare le basi e la logica della programmazione, un editor troppo complicato è più che altro un ostacolo ed una distrazione.

Molto meglio installare uno dei tanti editor grafici disponibili per macOS. Fra Atom, BBEdit, TextMate, Visual Studio Code, c’è solo l’imbarazzo della scelta. Sono tutti gratuiti (si, ora anche BBEdit è gratuito, la licenza serve per sbloccare le funzioni avanzate utili per i professionisti), sono tutti di ottima qualità (si, anche un prodotto Microsoft come Visual Studio Code può essere ottimo). Io preferisco usare TextMate e Atom – di quest’ultimo mi piace moltissimo la possibilità di sincronizzare automaticamente le impostazioni, i plugin e i temi fra tutti i computer su cui l’ho installato, che siano Mac o generici PC con Linux o Windows – però BBEdit è perfetto per i file di grosse (o meglio dire enormi) dimensioni come quelli che mi stanno capitando per le mani ultimamente. Mentre Visual Studio Code… beh, Visual Studio Code è stato una vera sorpresa sin dalla prima volta che l’ho usato.

Dalla linea di comando allo script

Lanciamo quindi l’editor che preferiamo e incolliamo l’ultima versione del comando di Terminale visto nella puntata precedente

echo "La privacy al tempo dell'Internet of Things: gran finale" | tr "[:upper:]" "[:lower:]" | sed "s/'/ /g" | sed "s/[[:punct:]]//g" | sed "s/ /-/g"

In questo comando c’è una parte variabile, la stringa “La privacy al tempo dell’Internet of Things: gran finale”, che dobbiamo cambiare ogni volta che vogliamo generare un nuovo titolo, mentre tutto il resto rimane sempre inalterato (a meno di non modificare di proposito il codice).

È sempre consigliabile separare le parti variabili del codice da quelle che rimangono sempre uguali, per evitare di alterare il programma per errore e renderlo inusabile. In questo caso, basta definire una variabile a cui viene assegnata la stringa da elaborare, usata come una specie di segnaposto nel resto del programma, e separare anche visivamente con una o più righe vuote le variabili dal resto del programma. Lo script diventa così

string="La privacy al tempo dell'Internet of Things: gran finale"

echo $string | tr "[:upper:]" "[:lower:]" | sed "s/'/ /g" | sed "s/[[:punct:]]//g" | sed "s/ /-/g"

dove la prima riga definisce la variabile string, che viene poi usata nel comando vero e proprio.

Da notare che quando si assegna una variabile in bash non si possono mettere degli spazi prima e dopo l’operatore di assegnazione =. In altre parole il nome della variabile, l’operatore e il valore della variabile devono essere scritti tutti attaccati. Inoltre, quando si usa la variabile nello script bisogna sempre anteporre il prefisso $ e scriverla come $string. Sono due particolarità di bash di cui è facile dimenticarsi quando si è abituati ad usare altri linguaggi di programmazione, a me succede anche troppo spesso.

Guardiamo ora la seconda riga. Nel comando originale da Terminale l’abbiamo scritta tutta di seguito, usando l’operatore | per trasferire il risultato di un comando al comando immediatamente successivo, che lo usa come dato di ingresso da elaborare. È una pratica che evita la creazione di troppe variabili, magari usate solo una volta, che è diventata popolare di recente in R, un linguaggio di programmazione specializzato nell’analisi statistica dei dati.

Personalmente la trovo una pratica poco lungimirante. Sarà anche comoda nel momento in cui sviluppiamo un programma, ma rende molto più difficile capire in un secondo momento quello che fa lo script. Ormai la memoria dei computer è gigantesca, possiamo benissimo sprecarne un po’ per definire qualche variabile in più.¹

Una versione riveduta del programma precedente, nella quale i risultati di ciascuna fase di elaborazione vengono salvati in una variabile diversa, può quindi essere

string="La privacy al tempo dell'Internet of Things: gran finale"

lowercase=$(echo $string | tr "[:upper:]" "[:lower:]")
del_apostr=$(echo $lowercase | sed "s/'/ /g")
del_punct=$(echo $del_apostr | sed "s/[[:punct:]]//g")
fix_spaces=$(echo $del_punct | sed "s/ /-/g")

converted_string=$fix_spaces
echo $converted_string

Qui devo ammettere di avere esagerato. Se la prima versione scritta tutta d’un fiato era difficile da leggere e da capire, usare una variabile diversa per ogni passo del programma è altrettanto estremo. Un buon compromesso potrebbe essere

string="La privacy al tempo dell'Internet of Things: gran finale"

fix_string=$(echo $string | tr "[:upper:]" "[:lower:]")
fix_string=$(echo $fix_string | sed "s/'/ /g")
fix_string=$(echo $fix_string | sed "s/[[:punct:]]//g")
fix_string=$(echo $fix_string | sed "s/ /-/g")

converted_string=$fix_string
echo $converted_string

in cui si usa una variabile (string) per la stringa da elaborare, un’altra (fix_string) per conservare i risultati intermedi ed infine un’ultima variabile (converted_string) per il risultato finale del programma.

Se si guardano attentamente le due ultime versioni dello script, si nota che ho continuato ad usare l’operatore | per inviare a sed o a tr la stringa da elaborare. Non è una contraddizione rispetto a quanto dicevo prima. Una cosa è scrivere una sequenza di quattro, cinque o più comandi collegati uno all’altro a formare una catena di montaggio inestricabile, un’altra è utilizzare ripetutamente una struttura ben definita e riconoscibile come echo $... | tr "..." oppure echo $... | sed "...".

Del resto non ci sono alternative: sia sed che tr sono fatti per operare su un file oppure in modo interattivo nel Terminale (si scrive una stringa nel Terminale, si preme Invio e sed o tr la elaborano, stampano il risultato e si mettono in attesa di una nuova stringa finché non li interrompiamo premendo CTRL-D) e l’unico modo per obbligarli a lavorare da programma e usare echo per fornirgli il dato in ingresso già bello e pronto.

Al nostro script mancano ancora due cosette per essere quasi comodo da usare, ma questo sarà l’argomento della prossima puntata.

A meno naturalmente di non avere dei grossi limiti di memoria, come succede quando si scrivono programmi per dispositivi embedded o dell’IoT, oppure di dover scrivere del codice molto efficiente per applicazioni ultrasofisticate. Ma chi è alle prese con questi problemi non ha bisogno di leggere questi articoli. ↩︎

First Draft: la prova

Wed, 23 Dec 2015 06:00:00 +0000

Non soffro particolarmente della sindrome della pagina bianca, ma sono anche consapevole che le cose migliori mi vengono fuori quando ho l’ispirazione e scrivo di getto.

Non a caso scrivo ancora spesso a mano. Mi piace la sensazione della penna che scorre veloce sul foglio, seguendo al meglio il filo del pensiero. Anche se vengono fuori geroglifici quasi incomprensibili, riesco (quasi sempre) a decifrarli e a tradurli in un testo decente.

Scrivendo al computer si dovrebbe cercare di fare lo stesso: buttare giù una prima stesura senza preoccuparsi troppo della forma, degli errori o della formattazione, tutte cose che distraggono dalla scrittura e di cui ci si può preoccupare in un secondo momento.

Purtroppo i programmi di scrittura non aiutano, perché invitano a concentrarsi fin dall’inizio sui dettagli, distraendo dall’obiettivo principale che è quello di riuscire a fissare le idee sulla pagina.

First Draft

First Draft è un programma di scrittura anomalo, che si propone di riprodurre sullo schemo del computer quello che facciamo quando scriviamo su un foglio di carta. Tutto quello che si cancella non viene rimosso definitivamente dallo schermo ma viene solo sbarrato, restando comunque visibile e magari riutilizzabile in un secondo momento.

First Draft può essere scaricato liberamente dal Mac App Store.¹ La versione gratuita non ha limitazioni e salva automaticamente tutto quello che scriviamo sul Mac, compresi gli errori e le cancellazioni.

Ma se vogliamo rimuovere le modifiche e utilizzare il documento pulito è indispensabile sbloccare la funzione di esportazione, con un acquisto in-App di 14.99 euro. Vedremo fra poco se ne vale la pena.

Usiamo il programma

Quando avviamo First Draft ci viene chiesto se vogliamo assistere ad una breve lezione interattiva che insegna ad usare il programma. La lezione è fatta bene, peccato che la richiesta venga ripetuta ad ogni avvio, diventando rapidamente noiosa. È vero che si può decidere di saltare la lezione, ma sarebbe più logico memorizzare la scelta dell’utente ed evitare di ripetere ogni volta la stessa domanda.

Considerazioni analoghe valgono per la schemata di presentazione di First Draft. Perché si deve essere obbligati ogni volta a leggere le caratteristiche introdotte nella nuova versione, senza poter scegliere di passare direttamente all’uso del programma? La prima volta va anche bene, ma dopo un po’ è una vera seccatura.

[caption id=“attachment_2294” align=“aligncenter” width=“605”] Schermata di presentazione di First Draft.[/caption]

La finestra dell’editor di First Draft è divisa in tre parti distinte, un’area centrale che contiene il testo e due colonne bianche ai lati. La larghezza dell’area di testo è fissa e non può essere modificata. Allargando la finestra dell’editor si aumenta solo la larghezza delle colonne laterali, che diventano preponderanti rispetto all’area centrale. A qualcuno potrà anche piacere, a me da solo l’impressione di un sacco di spazio sprecato inutilmente. Una scelta del genere può andare bene per un iPad o un MacBook con lo schermo piccolo, ma non ha molto senso con un monitor di dimensioni normali.

[caption id=“attachment_2295” align=“aligncenter” width=“605”] La finestra dell’editor.[/caption]

Anche la dimensione del testo non può essere modificata, nonostante la presenza dell’opzione relativa nella barra laterale di configurazione del programma. Lo stesso vale per lo stile del font: cliccando su uno dei quattro stili disponibili non succede assolutamente niente.

[caption id=“attachment_2296” align=“aligncenter” width=“605”] Barra laterale di configurazione.[/caption]

Troppi bachi

Ma i problemi non si limitano a questo. Purtroppo First Draft è infestato da parecchi altri bachi evidenti. Ad esempio, dopo averlo usato alcune volte, le cartelle che contengono i documenti di First Draft e che sono visibili sul lato sinistro della finestra di avvio appaiono ripetute più volte. La ripetizione non ha nessun effetto negativo sull’uso del programma, ma è comunque piuttosto fastidiosa.

[caption id=“attachment_2297” align=“aligncenter” width=“605”] Cartelle multiple nella finestra di avvio.[/caption]

Se nella barra laterale di configurazione si seleziona la modalità scura, l’unico modo per ripristinare quella chiara di default è tornare alla finestra di avvio del programma e riaprire il documento su cui si sta lavorando. Ma anche così la finestra di avvio rimane parzialmente scura e la finestra dell’editor è imbruttita da una barretta laterale scura. La visualizzazione corretta viene ripristinata solo chiudendo e riaprendo il programma.

[caption id=“attachment_2299” align=“aligncenter” width=“605”] Problemi di visualizzazione passando dalla modalità chiara a quella scura.[/caption]

In certi casi, in particolare quando si sposta la finestra di First Draft mentre si sta editando un documento (ma non solo), i bottoni rosso, arancione e verde tipici delle finestre di OS X vengono cancellati più o meno completamente. La cosa è ben visibile in alcune delle immagini di questo articolo ed è dovuta alla comparsa di una finestra vuota leggermente più piccola, che si sovrappone quasi completamente alla finestra principale. È la prima volta che vedo qualcosa del genere, dopo aver usato alcune centinaia di programmi per OS X.

Come se non bastasse, First Draft va molto spesso in crash, per fortuna senza cancellare quello che si è scritto fino a quel momento (ma in questo caso probabilmente tutti i meriti vanno a OS X e alle sue funzioni di salvataggio automatico dei documenti).

[caption id=“attachment_2300” align=“aligncenter” width=“557”] Uno dei tanti crash di First Draft.[/caption]

Ma a un certo punto…

Dopo aver aperto e chiuso molte volte First Draft sono costretto a correggere, almeno in parte, quello che ho scritto. Infatti improvvisamente le opzioni di scelta dello stile e della dimensione del font e il passaggio dalla modalità chiara a quella scura hanno iniziato a funzionare in modo corretto (ma tutti gli altri bachi rimangono).

Per cercare di riprodurre questo comportamento strano, ho provato a resettare First Draft, cancellando tutti i file di supporto di First Draft con l’ottimo AppCleaner (un programma che consiglio senza remore) e conservando solo l’applicazione vera e propria.

[caption id=“attachment_2301” align=“aligncenter” width=“605”] Reset del programma.[/caption]

In questo modo il programma torna allo stato iniziale, come se fosse stato appena installato dall’App Store. Purtroppo anche tutti i bachi si ripresentano esattamente come prima.

Lanciando di nuovo First Draft un numero imprecisato di volte compaiono all’improvviso, e senza un motivo apparente, dei riquadri di suggerimento (balloon help) sovrapposti alla finestra principale di First Draft. È proprio questo che, chissà perché, riattiva il funzionamento corretto delle preferenze del programma.

Non è chiaro però cosa determini la comparsa degli aiuti. L’ipotesi più probabile è che questi appaiano solo dopo un certo numero di riavvii del programma. Se è così, è un’altra scelta incomprensibile: gli aiuti servono immediatamente, per guidare il nuovo utente all’uso del programma, non dopo decine di riavvii, quando è presumibile che l’utente abbia imparato ad usarlo.

Conclusioni

First Draft è un programma potenzialmente interessante, ma purtroppo la realizzazione pratica è del tutto insoddisfacente. Alcune scelte di progetto poco comprensibili e i tanti bachi fastidiosi lo rendono, allo stato attuale, poco utilizzabile in modo serio e produttivo.

Distribuire un programma in queste condizioni da solo l’impressione di sciatteria e di scarsa attenzione nei confronti degli utenti.

I 15 euro richiesti per sbloccare le funzioni di esportazione sarebbero eccessivi anche se il programma funzionasse perfettamente ma, allo stato attuale, rappresentano praticamente una truffa.

In questo momento First Draft è ancora disponibile sul Mac App Store italiano. Ma dovrebbe essere stato rimosso dal Mac App Store americano per violazione del marchio commerciale, perché una azienda concorrente ha registrato dal 2014 un programma per Windows con lo stesso nome. Un programma piuttosto furbetto, un generatore automatico di contenuti per blog, pagine web e simili (probabilmente alcune persone che conosco lo usano già a fondo). ↩︎

Script di shell in OS X

Thu, 06 Nov 2014 06:00:00 +0000

Nei sistemi operativi basati su Unix la shell è una applicazione che permette di eseguire i comandi del sistema tramite una interfaccia testuale a linea di comando.

La shell più popolare oggi è bash, acronimo di “Bourne-Again Shell”, un gioco di parole fra Stephen Bourne, l’autore della shell sh da cui deriva bash, e il termine “born” (nato). Bash significa quindi sia “la nuova shell di Bourne” che “la shell rinata”.

Bash è la shell ufficiale del progetto GNU, ed è da tempo la shell di default in praticamente tutte le distribuzioni di Linux oltre che in OS X. Per accedere a bash in OS X si utilizza il Terminale, una applicazione di cui si è già parlato più volte in questo blog. Il Terminale si trova in Applicazioni > Utility.

Bash permette di eseguire i comandi del sistema operativa sia in modo interattivo, scrivendoli uno alla volta sulla linea di comando, che tramite uno script di shell (shell script), un vero e proprio programma all’interno del quale è possibile usare variabili, strutture di controllo e funzioni, esattamente come in tutti i linguaggi di programmazione.

Uno script di shell ben fatto può diventare quindi un vero e proprio comando specializzato, eseguibile dalla linea di comando e praticamente indistinguibile dai comandi intrinseci del sistema.

Ma come si crea uno script di shell? Basta seguire alcune semplici regole.

Innanzi tutto lo script va scritto usando un editor, mai un wordprocessor come Word o Pages. Lo script deve infatti essere un semplice file di testo e non deve contenere i codici di formattazione o i caratteri speciali inseriti normalmente dai programmi di videoscrittura.
Come editor si può usare TextEdit, preinstallato in tutte le versioni di OS X, ma vanno ancora meglio programmi gratuiti, come TextWrangler, TextMate 2.0, Brackets, Atom, o commerciali, come il mostro sacro BBEdit e Sublime Text. Tutti questi editor hanno il grande vantaggio rispetto al semplice TextEdit di evidenziare i comandi di bash e di supportare l’autocompletamento delle parole chiave riconosciute dall’editor.
Volendo si possono usare anche macvim o emacs, ma chi è in grado di usarli non ha bisogno di sicuro di leggere queste note.
Per permettere al sistema operativo di identificare il file come uno script per la shell bash, gli script devono iniziare con la riga

#!/bin/bash

È buona regola salvare tutti i propri script in una cartella (directory) comune, in modo che siano facilmente rintracciabili dal sistema operativo (ma dopo un po’ di tempo anche da noi stessi!)
Per uniformarci alle convenzioni di Unix, creiamo una directory bin nella nostra cartella Inizio (o directory home), dove salveremo tutti gli script.¹ Lanciamo il Terminale ed eseguiamo i comandi

$ cd ~
$ mkdir bin

dove il simbolo ~ indica per convenzione la cartella home dell’utente.

Lo script deve essere reso eseguibile direttamente con il comando

$ chmod u+x scriptname

Aiutiamo il sistema operativo a trovare facilmente i nostri script aggiungendo la directory bin appena creata alla variabile di ambiente PATH, che definisce le directory dove il sistema operativo va a cercare i comandi del sistema. Torniamo al Terminale ed eseguiamo in sequenza i comandi

cp -p .bashrc .bashrc.ORIGINAL
echo “export PATH=~/bin:$PATH” » .bashrc

Il primo comando duplica il file .bashrc originale, mentre il secondo aggiunge la riga contenuta fra virgolette alla fine del file .bashrc. Bisogna stare molto attenti ad usare due simboli di maggiore nel secondo comando altrimenti si rischia di sovrascrivere .bashrc con effetti potenzialmente disastrosi (questo è il motivo per cui è bene prima duplicare il file .bashrc originale).

Una volta chiuso e rilanciato il Terminale, la cartella ~/bin sarà aggiunta alla lista delle directory contenenti i comandi eseguiti da bash.

Bisogna notare che la creazione della directory ~/bin e la sua aggiunta al PATH del sistema vanno eseguiti una sola volta per ogni utente del Mac.

Vorrei infine sfatare una credenza ormai obsoleta: non è assolutamente necessario che il nome dello script termini con l’estensione .sh. È una vecchia abitudine che ha l’unico vantaggio di rendere immediatamente riconoscibile uno script salvato in una directory qualunque del sistema. Ma è una pratica inutile se si segue il consiglio di tenere tutti gli script di shell in una directory predefinita come ~/bin.

La cartella Inizio in OS X è quella identificata dall’icona di una casetta. ↩︎