Come aggiungere “Apri in Visual Studio Code” al menu contestuale di Windows 10/11

Se utilizzi spesso Visual Studio Code, può essere utile aggiungere una voce personalizzata al menu contestuale di Windows per aprire rapidamente la cartella corrente direttamente nell’editor.
Questo risultato può essere ottenuto tramite una semplice modifica del Registro di sistema utilizzando un file .reg.

Ecco il mio ad esempio:
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Directory\Background\shell\VSCode]
@=”Apri in Visual Studio Code”
“Icon”=”C:\\Users\\valerio.guaglianone\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe”

[HKEY_CLASSES_ROOT\Directory\Background\shell\VSCode\command]
@=”\”C:\\Users\\valerio.guaglianone\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe\” \”%V\”"

Come funziona
La configurazione crea una nuova voce nel menu che appare quando si fa clic con il tasto destro sullo sfondo di una cartella in Esplora file:
Apri in Visual Studio Code
Quando viene selezionata, Windows esegue il comando che avvia VS Code e apre automaticamente la directory corrente.

Le chiavi principali del file .reg
La chiave:
“`reg
[HKEY_CLASSES_ROOT\Directory\Background\shell\VSCode]
“`
registra una nuova voce nel menu contestuale delle cartelle.

Il valore:
“`reg
@=”Apri in Visual Studio Code”
“`
definisce il testo visualizzato all’utente.

L’attributo:
“`reg
“Icon”=”C:\\Users\\nomeutente\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe”
“`
associa l’icona ufficiale di Visual Studio Code alla voce del menu.
Infine, la chiave:

“`reg
[HKEY_CLASSES_ROOT\Directory\Background\shell\VSCode\command]
“`
specifica il comando da eseguire:

“`reg
@=”\”C:\\Users\\nomeutente\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe\” \”%V\”"
“`
dove `%V` rappresenta il percorso della cartella attualmente aperta.

Un’alternativa più portabile
Se VS Code è stato aggiunto al PATH di sistema, è possibile utilizzare direttamente il comando `Code.exe` senza dover specificare il percorso completo. In questo modo la configurazione diventa indipendente dall’utente e dalla posizione di installazione del programma.

Come rimuovere la personalizzazione
Nel caso in cui non sia più necessaria, è sufficiente eliminare la chiave del registro associata a `VSCode`, rimuovendo così la voce dal menu contestuale di Windows.

Conclusioni
Con poche righe di configurazione è possibile integrare Visual Studio Code direttamente nell’esperienza di navigazione di Windows, riducendo il numero di passaggi necessari per aprire rapidamente un progetto e migliorando la produttività durante lo sviluppo.

Quali sono le differenze chiave tra Bicep e Terraform?

Le differenze principali tra Bicep e Terraform risiedono nel loro ambito di applicazione, nel linguaggio utilizzato e nel modo in cui gestiscono lo stato dell’infrastruttura. Ecco un dettaglio delle distinzioni chiave:

• Ambito e Portabilità: Bicep è uno strumento specifico per Azure (Azure-centric), progettato come un’alternativa più leggibile ai modelli ARM in formato JSON. Al contrario, Terraform è una soluzione multi-cloud e agnostica rispetto al cloud, che permette di gestire infrastrutture su diversi provider (come AWS o Google Cloud, oltre ad Azure) utilizzando un unico workflow coerente.
• Linguaggio di Configurazione: Bicep utilizza un linguaggio specifico del dominio (DSL) che viene compilato in modelli ARM prima di essere eseguito da Azure. Terraform utilizza l’HashiCorp Configuration Language (HCL) per definire le risorse.
• Gestione dello Stato: Una caratteristica distintiva di Terraform è la sua capacità di imporre la gestione dello stato dell’infrastruttura. Attraverso comandi come terraform plan e terraform apply, offre un approccio strutturato per monitorare e aggiornare le risorse esistenti. Bicep, d’altra parte, si affida al meccanismo di distribuzione sottostante di Azure Resource Manager (ARM), poiché i suoi script vengono trasformati in modelli ARM standard.
• Casi d’Uso Ideali:
  • Bicep è la scelta preferita per i professionisti che lavorano esclusivamente o prevalentemente in ambienti Azure-centrici e desiderano una sintassi dichiarativa più semplice rispetto ai modelli JSON.
  • Terraform è preferito per ambienti multi-cloud e strategie di Infrastructure-as-Code (IaC) complesse, grazie alla sua modularità, riutilizzabilità e astrazione tramite estensioni dei provider.

In sintesi, mentre Bicep ottimizza l’esperienza nativa di Azure, Terraform offre la flessibilità necessaria per gestire infrastrutture eterogenee su scala globale.

Nei sistemi ONTAP 8.x e ONTAP 9.x esistono più file di log. Se si intende esaminare i log di ONTAP il miglior posto in cui cercare è il registro EMS. L’Event Management System(o EMS) raccoglie, in pratica, tutti gli eventi notificati dal sistema operativo ONTAP (https://en.wikipedia.org/wiki/ONTAP).

L’EMS fornisce, inoltre, anche un meccanismo di filtraggio per una facile revisione. Gli eventi EMS possono essere visualizzati direttamente dalla clustershell; di seguito qualche comando utile:

• event log show

Il comando presentato sopra mostra l’elenco degli ultimi eventi, possiamo anche scegliere di visualizzare gli eventi indicando un range temporale espresso in minuti, come ad esempio tutti gli eventi degli ultimi 15 minuti:

• event log show -time >15m

Oppure, per essere ancora più precisi nella ricerca, possiamo indicare un periodo temporale ben preciso con:

• event log show -time “2/1/2018 13:00:00″..”2/1/2018 14:00:00″

da notare che l’output parte dal valore indicato nella parte destra, cioè mostra gli eventi a partire dalle 14:00:00 in ordine decrescente.

Se, ad esempio, desiderassimo vedere solo tutti gli errori basterà invece indicare esplicitamente la severity corrispondente come segue:

• event log show -severity ERROR

Le voci di severity utilizzabili, per questo livello di filtraggio, sono le seguenti:

1.       emergency
2.       alter
3.       critical
4.       error
5.       warning
6.       notice
7.       informational
8.       debug

In questo breve post espongo le otto migliori pratiche di gestione di un progetto, apprese strada facendo. Qualora riteneste valide queste indicazioni potreste attuarle presso la vostra azienda, credo vi potrebbero aiutare a mantenere un flusso di lavoro snello, adeguato ed a motivare i vostri dipendenti.

Sono semplici riflessioni, nulla di accademico; ho infatti rivolto semplicemente, ai miei colleghi, una domanda: cosa odiano i programmatori? In pratica cosa li manda fuori di testa?

(1) I requisiti del software non chiari

Spesso il primo problema riscontrato è il gap dei requisiti. Un progetto non ben chiaro oppure una comunicazione non chiara tra il cliente, i responsabili di progetto e gli sviluppatori, conducono alla creazione di software difettosi oppure incompleti.

Se cliente ed il responsabile del progetto non sono abbastanza specifici sul prodotto richiesto, non dovrebbero aspettarsi che gli altri leggano le loro menti e facciano il lavoro che loro non hanno svolto correttamente. I programmatori non sono legilimens.

È il compito di un manager raccogliere le specifiche del progetto e renderlo più completo possibile, per cui gli sviluppatori non hanno bisogno di indovinare oppure chiedere più volte le specifiche.

(2) Le attività ripetitive

Il problema qui può essere, ad esempio, far lavorare un programmatore molto su un progetto per un lungo periodo. Può anche essere il caso di un cliente che cambi spesso la propria idea su una o più funzioni dello stesso software. In entrambi i casi, se uno sviluppatore si sente bruciato dalle attività ripetitive che sta facendo, forse è giunto il momento di parlarne.

Se possibile, spostare il dipendente in un altro progetto. A volte un semplice cambiamento dei task su cui uno sta lavorando può essere defaticante e serve a mantenere il dipendente motivato.

(3) L’entropia del software da debito di progettazione

Il debito di progettazione è l’effetto causato dall’adozione di una semplice soluzione senza però tener conto della futura scalabilità del progetto. In sintesi, riflette il lavoro di sviluppo aggiuntivo che si presenta quando viene utilizzato codice facile da implementare nel breve periodo anziché applicare la migliore soluzione a lungo termine. La ragione per cui gli sviluppatori odiano questo tipo di debito è semplice: proprio come il caso di un debito finanziario, ci sarà un momento per “restituirlo”, che in termini di sviluppo significa affrontare nuovamente lo stesso problema.

Per risolvere il problema, gli sviluppatori spesso devono riscrivere il codice per terminare “il lavoro non completato”. Inoltre, causa scadenze mancate, in quanto è chiaramente difficile stimare quanti lavori sono necessari per pagare il debito stesso maturato.

La soluzione da applicare è semplice: non cadere nella scelta più semplicistica solo perché più facile quando si pianifica. Pensate alla soluzione valida una volta per tutte. Questo debito non è necessariamente una cosa negativa, talvolta il debito di progettazione (o debito tecnico se preferite) è positivo e necessario per far evolvere i progetti.

Questo breve articolo vi fornirà utili informazioni su come controllare la versione di Bash presente sul vostro sistema operativo. Potrà sembrarvi banale ma al sottoscritto è capitato un paio di volte di dover risalire alla versione in uso della shell per adattare degli script.

1 – Controllo della versione utilizzando il comando bash

Il modo più semplice ed immediato per controllare la versione di Bash è eseguire il comando shell bash con l’opzione di comando –version:

dal comando appena usato si evince che la versione della Bash presente nel sistema è la 4.4.20, direi un metodo veloce ma con un output prolisso se vogliamo.

A volte capita di dover eseguire uno script PHP da command line; ed è ancora più frequente il dover ritoccare alcuni parametri del file di configurazione del PHP prima di eseguire il comando stesso. Per stabilire dove e quale sia il file da modificare basterà inserire in un terminale il comando:
php -r ‘phpinfo ();’| grep “Configuration File”
come output vedremo qualcosa di simile:
Configuration File (php.ini) Path => /etc/php5/cli
Loaded Configuration File => /etc/php5/cli/php.ini.

Buon PHP a tutti!

Redirigete il crontab attuale su un file:
$ crontab -l > filecron.txt

Modificate il file appena creato con un editor (VI, nano, ecc.):
$ vi filecron.txt

Infine, aggiornate il crontab con il nuovo file:
$ crontab filecron.txt

Tutto qui.

Quando si usa il comando su per diventare utente root oppure per assumere l’identità di un altro utente, si può usare il comando suspend per tornare momentaneamente alla sessione di shell precedente.

Per tornare alla sessione di root lasciata poco prima, si può invece usare il comando fg.

Nel caso si sia avviata una shell di login (per esempio con il comando su -), allora si può forzare il ritorno alla shell precedente, con il comando suspend -f.

Un messaggio per avvisare tutti gli utenti collegati di disconnettersi dal sistema:
# wall prego disconnettersi urgentemente dal sistema!!

Se gli utenti non si disconnettono da soli si può fare così:

1. si vedono i pid degli utenti ancora collegati alla macchina con:
# who -a | grep pts

2. quindi si procede con il comando:
# kill <pid utente>

Fuori tutti!