Microsoft Visual Studio Code, addio…

In questi giorni sto scrivendo un po’ di codice per Sketchin per fare parlare tra loro diversi sistemi che fanno parte del nostro ecosistema di servizi. Lo scopo è quello di rendere la vita delle persone più facile mettendo a disposizione degli strumenti che permettano loro di ottenere informazioni chiave senza dovere saltare continuamente da un sistema all’altro senza soluzione di continuità.

Abbiamo sempre cercato di selezionare soluzioni SAAS che ci permettessero di avere accesso a delle API. Questo è stato il nostro mantra negli ultimi anni.

La lista dei sistemi è abbastanza lunga ma tra questi abbiamo Salesforce, Harvest, Expensify, Slack, Google Sheets e Gmail. Rimane, purtroppo fuori dal giro, Navision che è una porcheria di prima qualità ma che ci viene imposto dal gruppo. Navision ha delle API ma lo strumento è stato talmente personalizzato che le API di default non servono ad un tubazzo di niente. Questa, però, è un’altra storia.

Ho deciso di usare Python per scrivere l’insieme di questi strumenti e sino ad ora ho molto apprezzato la velocità con la quale posso scrivere codice senza dovermi occupare troppo dei dettagli del contorno. La vastità di librerie che ho a disposizione mi permette di concentrarmi su quello che le applicazioni devono fare piuttosto che sui dettagli.

Io, da sempre, sono stato un grande utilizzatore di vi. Credo che molti sottovalutino la potenza di questo strumento. E’ sufficiente farsi un giro su YouTube per realizzare come vi possa davvero diventare qualcosa di molto simile ad un IDE fatto e finito. In fondo io adoro la linea di comando di una shell. Lì mi sento davvero a mio agio.

Ad ogni modo per questa cosa ho deciso di utilizzare Microsoft Visual Studio Code come IDE di riferimento. Da poco è stata ufficialmente rilasciata la versione per la nuova architettura ARM di Apple e quindi può vivere a pieno titolo sul mio Macbook Air. Ne sono abbastanza soddisfatto nonostante qualche glitch qui e là. Ad esempio: per gestire il mio ambiente di sviluppo Python uso Conda e dopo la prima scrittura di getto di un pò di codice ho cominciato ad organizzare il progetto in moduli e package secondo necessità. Ecco, in questo caso la pletora di plugin che devono vivere in armonia comincia a scricchiolare. Per quanto abbia provato a risolvere il problema i moduli ed i package che vengono importati non vengono riconosciuti da PyLint. Questo mi infastidisce parecchio. Eppure il codice gira senza problemi e quindi i vari moduli vengono trovati senza problemi.

Nella giornata di ieri ho dato una occhiata al footprint di memoria di Microsoft Visual Studio Code e ho scoperto, con una certa sorpresa, che si prende più di un gigabyte di RAM per funzionare. Diciamo che mi sembra un pochino eccessivo. Vero è che sul mio Mac gira senza problemi e, di fatto, non vedo mai una hit sulla swap della macchina. Ad ogni modo un gigabyte di ram mi sembra una vera follia

Tanto per dare una idea, vi occupa meno di 5 megabyte per una sessione. Una leggerissima differenza.

Vero è che l’ambiente visuale velocizza un pochino le cose in termini di accesso e passaggio ad un file all’altro ma rimane il fatto che 1 gigabyte di RAM per un editor di testo mi sembra tanto.

Per questa ragione ho fatto un esperimento per una giornata intera.

Usare solo il terminale del mio Mac in congiunzione con tmux e vi. Se non avete mai usato tmux vi siete persi una perla rara. Io lo uso da sempre e oramai sono arrivato ad una sua configurazione che è un vero spettacolo.

Ho sviluppato quindi per un giorno intero usando questo paradigma e devo dire che non ho notato delle grandissime differenze in termini di produttività. Forse l’unica cosa che fa una qualche differenza è il debugger visuale di VS Code contro il classico pdb da linea di comando. Il problema in questo caso credo di essere io perché non conosco abbastanza bene pdb per essere veloce quanto vorrei. Ho usato per anni gdb quando sviluppavo in C ed era un fulmine di guerra. Devo quindi studiare un pochino.

Alla fine ho deciso che nei prossimi giorni userò questa combinazione per proseguire questo lavoro.

Avrei altre due ipotesi da verificare. Una è un mix tra terminale, tmux e TextMate che è un editor che ho sempre apprezzato molto in passato. Anche questa potrebbe essere una combinazione meno esosa in termini di memoria.

L’altra alternativa è PyCharm ma credo che si avvicini molto a VS Code in termini di requisiti di memoria. Il vantaggio qui è che ci sarebbero molto probabilmente meno menate di conflitti tra i vari plugin essendo una soluzione dedicata allo sviluppo in Python.

Magari nei prossimi giorni faccio una prova.

Per il momento credo che archivierò Microsoft Visual Studio Code. Una cosa bellissima di VS Code però è la possibilità di sincronizzare impostazioni e plugin in maniera automatica su tutte le macchine. Cosa che non mi dispiace affatto visto che durante il corso della giornata salto di continuo tra il mio Mac personale e quello dell’ufficio.