Millewin: estrarre l’elenco degli ultimi pazienti visitati

Logo: millewin - estrarre l'elenco degli ultimi pazienti visitati

Visto il recente aumento di casi di COVID-19 può tornare utile avere un elenco di tutti i pazienti incontrati nello studio in un certo arco di tempo.

Per farlo basta eseguire una query da Millewutilità nel seguente modo:

  1. Aprire Milleutilità
  2. Aprire il menù Statistiche e selezionare Impostazione Estrazioni SQL Personali
  3. Aggiungere il codice SQL
    Premendo il pulsante Nuovo creare una nuova estrazione chiamata Ultimi contatti e incollare nel campo Comando SQL il codice riportato sotto. Una volta fatto salvare il tutto con il bottone Salva
  4. Eseguire l’estrazione
    Premere il tasto Applica per eseguire l’estrazione. Il programma chiederà su quali dati eseguire l’estrazione. In questo passo è importante selezionare l’intervallo di date di interesse su cui eseguire la query. Una volta deciso, proseguire con il comando Avanti.
    Si aprirà una nuova schermata da cui è possibile eseguire l’estrazione mediante il pulsante Esegui posto in alto a destra.
  5. Salvare i dati in formato Excel
    A seconda dell’intervallo di date selezionato e del numero di accessi allo studio medico il programma potrebbe impiegare più o meno tempo a fornire l’elenco di tutti i pazienti incontrati. Una volta che il processo di estrazione è terminato è possibile esportare i dati in formato Excel mediante il pulsante Salva in alto a sinistra.

Di seguito è riportato il codice da inserire nel campo Comando SQL descritto al punto 3:

select
	data_contatto,
	ora_contatto,
	cognome,
	nome,
	codfiscale,
	datanasc,
	tipo
from
	v_contatti
order by
	data_contatto,
	ora_contatto

BONUS: estrarre i pazienti con più contatti in un dato periodo

Facendo delle piccole modifiche alla query riportata poco sopra è possibile ripetere lo stesso procedimento per ottenere il numero di volte che un paziente di è presentato allo studio in un determinato intervallo di tempo. Per farlo la query da eseguire è la seguente:

select
	cognome,
	nome,
	codfiscale,
	tipo,
	count(*) as totale_contatti
from
	v_contatti
group by
	cognome, 
	nome,
	codfiscale,
	tipo
order by
	cognome,
	nome

Se questo post ti è stato utile puoi farmelo sapere lasciando un commento qui sotto oppure scrivendomi direttamente a t.me/lorenzomillucci.
Inoltre ti invito ad iscriverti al mio canale Telegram e a seguirmi su Twitter per non perderti nemmeno un post del mio blog. A presto!

Installare Python 3.9 su Ubuntu 20.04

Visto il successo dell’articolo su come installare Python3.8 su Ubuntu 18.04, ora che è stata da poco rilasciata la versione 3.9 ho pensato di crearne una versione aggiornata per l’ultima LTS disponibile (che di default ha la 3.8).

Le novità introdotte dall’aggiornamento di Python 3.9 le trovi direttamente nell’articolo ufficiale della documentazione.

Ma bando alle ciance e vediamo subito come installarlo su Ubuntu 20.04 sfruttando un PPA aggiuntivo.

Installazione

Per installare subito l’ultimissima versione di Python sul tuo sistema apri il terminale e digita i seguenti comandi:

sudo add-apt-repository ppa:deadsnakes/ppa
sudo apt update
sudo apt install python3.9

NOTA: dallo stesso repository puoi scaricare anche le versioni 3.1, 3.5, 3.6 e 3.7 di Python (la versione 3.8 è quella fornita di default da Ubuntu 20.04)

Non appena l’installazione sarà finita potrai utilizzare la nuovissima versione di Python utilizzando il comando python3.9


Se questo post ti è stato utile puoi farmelo sapere lasciando un commento qui sotto oppure scrivendomi direttamente a t.me/lorenzomillucci.
Inoltre ti invito ad iscriverti al mio canale Telegram e a seguirmi su Twitter per non perderti nemmeno un post del mio blog. A presto!

GitHub: caricare tutti i diff con un solo click

In un mondo ideale tutte le pull requests (PR) dovrebbero essere piccole e concise non arrivando mai a superare le 200-300 righe di diff. Spezzare il lavoro in piccoli task, infatti, permetti di semplificare la vita al collega che dovrà fare la code-review prima del merge del codice.

Adoro i diff piccoli

Sfortunatamente nel mondo reale non sempre è possibile mantenere le PR di dimensioni accettabili. Soprattutto quando è necessario rilasciare in produzione nuove funzionalità può capitare che non si riesca a spezzarle in rilasci più piccoli.

La pull request che non vorrei mai incontrare

Quando capitano mostri del genere GitHub, per ovvie ragioni di performance, non mostra il diff completo ma richiede di caricare in maniera asincrona i file da rivedere.

Il famigerato bottone “Load Diff”

Quando è necessario fare le review di Pull Request del genere cliccare il pulsante “Load Diff” per ogni file modificato può diventare il peggior nemico del tunnel carpale.

Ma prima di vedere come risolvere questo problema mi presento, sono Lorenzo Millucci e sono un ingegnere del software che ama lavorare con PHP e Symfony. Nel tempo libero mi piace condividere in questo blog le cose che imparo. Iscriviti al mio canale Telegram per non perderti nessuna notizia!

Aprire tutti i diff insieme

Per salvare il tunnel carpale da una montagna di click sul pulsante “Load diff” fortunatamente ci vengono incontro due righe di JavaScript:

document.querySelectorAll('.load-diff-button').forEach(node => node.click())

Ti basterà incollarle nella console degli strumenti per sviluppatori per far si che vengano automaticamente clickati tramite JavaScript tutti i pulsanti “Load Diff”.

Et voilà, il gioco è fatto!

Tip: memorizzare lo script in Chrome/Edge

Si, lo so, è una sola riga di codice. Potrei anche memorizzarla…. Ma se non fossi pigro non avrei mai fatto lo sviluppatore. Ecco perché ho trovato un modo che permetta di utilizzare questo script sfruttando una funzione poco nota di Chrome e Edge: i Frammenti (o Snippets in inglese).

Se ti capita di dover digitare continuamente le stesse righe di codice all’interno della console del browser puoi pensare di salvarle all’interno di un frammento. Infatti memorizzandole in un frammento potrai eseguirle all’interno di qualunque pagina utilizzando direttamente gli strumenti del browser.

La prima cosa da fare per creare un nuovo Frammento è aprire gli strumenti per sviluppatori, spostarti nella sezione Origini (Sources in inglese) e da li selezionare Frammenti (Snippets) e premere su Nuovo frammento (New snippet).

Il browser a questo punto ti chiederà di assegnare un nome al nuovo script e di definirne il contenuto.

Ritornando all’obiettivo dell’articolo, per automatizzare l’apertura dei diff ho creato un nuovo frammento chiamato GitHub PR in cui ho incollato lo script riportato sopra.

Aggiunta di un nuovo frammento

Una volta salvato il frammento, per richiamarlo all’interno di una pagina basterà aprire nuovamente gli strumenti per sviluppatori e premere Ctrl+O per aprire l’elenco dei comandi e digitare le iniziali dello Snippet appena salvato precedute dal simbolo ! (ad esempio nel mio caso il comando sarebbe !GitHub PR)

Esecuzione di un frammento memorizzato

Facendo click sul nome del frammento questo verrà eseguito dal browser e, nel caso in questione, tutti i diff verranno caricati in una sola volta.


Se questo post ti è stato utile puoi farmelo sapere lasciando un commento qui sotto oppure scrivendomi direttamente a t.me/lorenzomillucci.
Inoltre ti invito ad iscriverti al mio canale Telegram e a seguirmi su Twitter per non perderti nemmeno un post del mio blog. A presto!

Fonte

Ubuntu: Installare i driver stampa Samsung (HP)

Samsung Xpress 2070FW

E’ una normale mattina di un giorno infrasettimanale. Come sempre alle 7.00 suona la sveglia ed inizia la routine dei preparativi per andare al lavoro.

Oggi sono stato bravo, ho ben 5 minuti di anticipo sul solito orario di partenza in modo da stampare con calma quel foglio che devo da consegnare al lavoro.

Avvio velocemente il mio notebook con Ubuntu 20.04, apro il documento che mi serve e premo il pulsante di stampa.

Cosa potrebbe mai andare storto?

Si dice che non si debba mai far capire ad una stampante che si ha fretta altrimenti questa si incepperà inesorabilmente.

Legge di Murphy

Questo è quello che tira fuori la stampante:

Eh si, era proprio questo il documento che volevo stampare….

Dannazione!

Ero così felice che Ubuntu avesse riconosciuto subito la stampante senza bisogno di dover intervenire manualmente. E invece anche questa volta è stato necessario installare manualmente i driver.

Ma prima di mostrarti come installare i driver per la stampante mi presento, sono Lorenzo Millucci e sono un ingegnere del software che ama lavorare con PHP e Symfony. Nel tempo libero mi piace condividere in questo blog le cose che imparo. Iscriviti al mio canale Telegram per non perderti nessuna notizia!

Installazione driver

In questo articolo io faccio riferimento all’installazione dei driver per la stampante Samsung Xpress M2070FW su Ubuntu 20.04. Se utilizzi un modello di stampante diverso o se hai una versione differente del sistema operativo la procedura potrebbe cambiare leggermente ma dovrebbe essere comunque valida.

  • Andiamo con ordine, la prima cosa da fare è verificare che la stampante sia accesa e collegata al computer,
  • Dopodiché collegati al sito Samsung/Hp, seleziona il modello della stampante e scarica il pacchetto Unified Linux Driver contenente i driver,
  • Estrai il pacchetto appena scaricato utilizzando il click destro del mouse e selezionando la voce estrai dal menù a tendina. Oppure se preferisci il terminale puoi utilizzare il comando:
tar -zxvf uld_V1.00.39_01.17.tar.gz
  • Spostati all’interno della cartella appena estratta e dai i permessi di esecuzione allo script di installazione utilizzando il comando:
chmod +x ./install.sh
  • Avvia l’installazione con il comando
./install.sh

ATTENZIONE: sarai obbligato a scorrere tutti i termini di servizio di Samsung/Hp prima di poter procedere all’installazione effettiva dei driver. Alla fine delle lunghe paginate di condizioni da accettare ti verrà chiesto di accettarle rispondendo alla domanda **** Do you agree ? [y/n]. Se anche tu stavi tenendo pigiato il tasto invio per scorrere velocemente i termini di servizio ti capiterà di sicuro di saltare questa domanda rifiutando quindi i termini di contratto. Purtroppo in questa situazione l’unica soluzione è riavviare l’installazione da capo.

Accetti i termini di servizio?
Attenzione a non rifiutare l’accettazione dei termini di servizio tenendo premuto invio

Una volta che la procedura sarà terminata potrai andare nelle impostazioni di Ubuntu e aggiungere la stampante seguendo la procedura guidata del sistema operativo.

NOTA: se avevi provato ad aggiungere la stampante prima di installare i driver potresti doverla rimuovere e ri-aggiungere affinché vengano utilizzati i driver appena installati al posto di quelli generici.


Se questo post ti è stato utile puoi farmelo sapere lasciando un commento qui sotto oppure scrivendomi direttamente a t.me/lorenzomillucci.
Inoltre ti invito ad iscriverti al mio canale Telegram e a seguirmi su Twitter per non perderti nemmeno un post del mio blog. A presto!

La leggibilità del codice

Codice illeggibile?

The rationale for the code being the primary source of documentation is that it is the only one that is sufficiently detailed and precise to act in that role [….].

This principle comes with a important consequence – that it’s important that programmers put in the effort to make sure that this code is clear and readable.

Martin Fowler – CodeAsDocumentation

Di solito gli sviluppatori non dedicano particolare attenzione alla scrittura della documentazione. Nel caso migliore è vista come un male necessario, nel caso peggiore invece è trattata come un task da fare il più tardi possibile (e tendenzialmente mai).

Recentemente, grazie alla diffusione di metodologie agili, la scrittura della documentazione sta diventando parte integrante del processo di sviluppo di un software. Infatti il processo di scrittura e di mantenimento della documentazione può essere semplificato inserendola all’interno del codice stesso. In questo modo il codice assume il ruolo di sorgente principale di documentazione di un progetto.

In questo articolo ti voglio parlare dell’importanza di mantenere una documentazione a scopo interno che sia ben fatta, con un codice che sia “parlante” e con il giusto numero di commenti. Per farlo cercherò di rispondere alle seguenti 3 domande:

  • Perché il codice deve essere leggibile?
  • Quando è che un codice è leggibile?
  • Come scrivo codice che sia leggibile?

Ma prima di rispondere a queste domande mi presento, sono Lorenzo Millucci e sono un ingegnere del software che ama lavorare con Symfony e a cui piace condividere in questo blog le cose che impara. Iscriviti al mio canale Telegram per non perderti nessuna notizia!

Perché il codice deve essere leggibile?

Affrontiamo subito l’elefante nella stanza: perché devo prendermi la bega di scrivere del codice che sia leggibile?

Lo sviluppo di software è un task che viene affrontato in team nella quasi totalità dei casi. Ormai quasi nessun progetto viene sviluppato da una singola persona. Questo vuol dire che il codice che oggi io scrivo da solo davanti al mio PC prima o poi dovrà essere letto e capito da altri sviluppatori in modo che possano modificarlo per correggere bug o per aggiungere nuova funzionalità.

Quando il codice non è facilmente leggibile, lo sviluppatore che dovrà modificare dopo di me quelle righe dovrà perdere una notevole quantità di tempo solo per capire cosa ho fatto e come l’ho fatto per quello che magari poteva essere un fix facile e veloce.

Nel caso peggiore il codice scritto potrebbe essere così astruso che uno sviluppatore, piuttosto che perdere tempo nel cercare di decifrarlo, potrebbe decidere di riscriverlo da capo. Ma il processo di riscrittura non è esente da rischi. Infatti non è raro che qualche edge-case particolare non venga coperto dal nuovo codice o che venga introdotto qualche bug che il codice originale non aveva. Tutto ciò rende quindi necessario iterare più e più volte il processo di scrittura aumentando notevolmente i tempi e i costi di sviluppo.

Un altro fenomeno che spesso si verifica quando il codice non è facilmente interpretabile dagli sviluppatori è quello chiamato “Shanghai programming”.
Hai presente il gioco Shanghai? Quello in cui c’è un mucchio di bastoncini e i giocatori si sfidano a chi ne sfila il numero maggiore senza muovere gli altri.
Bene, può accadere la stessa cosa nello sviluppo di un software. Uno sviluppatore, non riuscendo a capire cosa faccia il mio codice, potrebbe essere portato a cambiare solamente le parti strettamente necessarie ad implementare la funzionalità richiesta senza toccare il resto. Questo comportamento non può che portare ad un’ulteriore riduzione della leggibilità del codice.

Arrivati a questo punto non devi stupirti del fatto che il codice non leggibile sia uno dei più grandi contribuenti all’aumento incontrollato del debito tecnico.

Ora che hai capito il perché il codice deve essere facilmente leggibile da chiunque procediamo a chiarire quando è che un codice è leggibile (e di conseguenza quando non lo è).

Malore: La tipica reazione di uno sviluppatore di fronte ad un codice illeggibile
La tipica reazione di uno sviluppatore di fronte ad un codice illeggibile

Quando è che un codice è leggibile?

Sfortunatamente non esiste una risposta universale a questa domanda. A seconda del linguaggio utilizzato, del team o della singola persona presa in considerazione la risposta a questa domanda varia.

Quello che sicuramente possiamo dire è che un codice è illeggibile se non è formattato in modo coerente.
Ti è mai capitato di aprire un libro e vedere una pagina fitta-fitta di testo senza alcuna suddivisione in paragrafi? Quando succede a me la prima reazione è quella di chiudere il libro e lasciare perdere la lettura. Questa è la stessa reazione di uno sviluppatore che vede un codice mal-formattato.

Quindi una prima costatazione da fare è che per aumentare la leggibilità del codice è necessario stabilire delle convenzioni da seguire per l’impaginazione/formattazione del codice. Ad esempio definire che tutti i metodi devono essere scritti in camelCase. Oppure che l’indentazione del codice deve essere fatta utilizzando gli spazi piuttosto che tabulazioni, ecc…
Tipicamente per queste regole stilistiche ci vengono incontro vari tool automatici di analisi statica che, una volta definite le regole, evidenziano (e a volte correggono automaticamente) tutti gli errori che incontrano.

Ma è sufficiente definire delle regole stilistiche per scrivere del codice leggibile? Ovviamente la risposta è no.

Una volta che il codice è ben formattato bisogna iniziare a vedere che ciò che abbiamo scritto sia comprensibile anche agli altri membri del team di sviluppo.

La prima cosa da fare in questo caso è farsi una serie di domande:

  • Si riesce a seguire il flusso del codice?
  • Il nome di un metodo/variabile aiuta a capire a cosa serve?
  • E’ necessario aggiungere un commento ulteriore per chiarire cosa sto facendo?
  • ecc…

Una volta terminata questa fase di “auto-analisi” del codice posso finalmente affermare che il codice è chiaramente leggibile da me stesso.

Ma come dicevamo all’inizio orma si lavora sempre in team e quindi non è sufficiente che il codice che ho scritto sia leggibile da me ma deve essere leggibile da qualunque altro collega.

Ecco quindi la prova finale per garantire la leggibilità di un software: superare la code-review.

Solo nel caso in cui un altro sviluppatore sia effettivamente in grado di capire cosa fa il mio codice senza porre domande sul suo funzionamento e senza fraintenderne in alcun modo il flusso logico posso dire di aver prodotto un codice veramente leggibile.

Reazione di festeggiamento quando finalmente la code review passa
Finalmente il codice è leggibile

Come scrivo codice che sia leggibile?

Anche a questa domanda non esiste una risposta universalmente riconosciuta. Tuttavia alcuni principi da avere bene a mente durante lo sviluppo del software sono:

  • Single-responsibility principle (SRP): ogni elemento di un programma deve avere una e una sola responsabilità. In modo tale che per uno sviluppatore sia facile capire cosa andare a modificare in caso di necessità.
  • Don’t repeat yourself (DRY): ogni elemento di un programma deve essere scritto una e una sola volta all’interno della code-base. Deve esistere una sola fonte di verità in modo da garantire che la modifica di un blocco di codice non debba mai essere ripetuta in più volte in più punti dell’applicazione.
  • Naming significativo: i nomi degli attributi, delle funzioni e delle classi deve essere significativo ed essere pensato in modo tale da aiutare la comprensione del codice.
  • Commenti solo se necessari: con un buon naming si può fare a meno di molti blocchi di commenti. Tuttavia esistono porzioni di codice che richiedono ulteriori spiegazioni e che quindi devono essere necessariamente commentate. I buoni commenti spiegano il “perché” di una determinata scelta. Il “come” è spiegato dal codice.
  • Testing: sebbene i test automatici non migliorino direttamente la leggibilità di un blocco di codice, questi permettono di capire il contesto in cui il codice è utilizzato. Inoltre, anche con il codice più leggibile del mondo è facile incappare in errori. Solo con una suite di test automatici in grado di coprire tutto il software è possibile modificare un software senza il terrore di aver rotto qualcosa nel tentativo di aggiustare qualcos’altro.

Conclusioni

Spero che questo articolo ti abbia aiutato a capire “perché”, “quando” e “come” scrivere un codice leggibile. Sicuramente ha aiutato me a mettere in ordine varie idee e nozioni che avevo acquisito ma che non avevo mai avuto modo di organizzare in modo strutturato.

Come hai potuto leggere nel corso dell’articolo alla base di un codice leggibile non c’è nessun concetto astratto o complesso da capire. Si tratta di nozioni che chiunque abbia provato a programmare con un qualunque linguaggio conosce ma che di solito si tende a dimenticare in quanto concetti considerati banali.

Un ulteriore punto che ci tengo a precisare è che la perfezione non esiste. Esisterà sempre un modo più ricercato o più elegante per rendere maggiormente leggibile una porzione di codice.
Il problema è che poiché la leggibilità non è un concetto universalmente definito dagli sviluppatori si possono creare delle situazioni di stallo in cui opinioni differenti rischiano di bloccare completamente lo sviluppo. Proprio per evitare di cercare la perfezione a tutti i costi è fondamentale tenere a mente che molte volte è sufficiente che il codice sia leggibile da chi effettivamente dovrà lavorare sul codice. Ed è per questo che le code-review sono lo strumento principale per garantire la leggibilità del codice.

Infine c’è da dire che il codice non è scritto nella pietra. La ricerca della miglior leggibilità del codice è un processo continuo. Ogni volta che puoi migliorare la leggibilità è bene non indugiare e farlo subito in modo da ridurre il debito tecnico. Grazie alla suite di test automatici (che non a caso ho inserito tra i requisiti per un buon codice leggibile) potrai rifattorizzare il codice avendo la certezza di non aver rotto nulla.


Se questo post ti è stato utile puoi farmelo sapere lasciando un commento qui sotto oppure scrivendomi direttamente a t.me/lorenzomillucci.
Inoltre ti invito ad iscriverti al mio canale Telegram e a seguirmi su Twitter per non perderti nemmeno un post del mio blog. A presto!

Fonte
Fonte