Acquisire testo da immagini con Python – Parte 1 – Cominciamo dalle basi

Qualche giorno fa in questo post [1] parlavo dei temi relativi all’AI e le sue differenze con la pura automazione. Come esempio pratico vorrei provare ad acquisire in automatico i dati provenienti da alcune immagini e convogliare queste informazioni in un excel. Dovete sapere che io sono un grande amante dei giochi degli anni ottanta e novanta. E voi direte che centra questo? Uno dei giochi sul quale ho perso letteralmente le notti quando ero poco più che un teenager era Championship Manager (Scudetto nell’edizione italiana). E’ stato il primo gioco a fornire una simulazione di ottimo livello del manager calcistico. Sono passati gli anni, sarà l’età avanzata, sarà del sano romanticismo, ma ancora questo gioco riesce a toccare corde cui i giochi strafighi di oggi difficilmente riescono a sfiorare. Se non lo conoscete vi invito a fare un giro su questo sito [2] dove potete addirittura scaricare il gioco (nella versione 97/98) e con dosbox [3] un simulatore di DOS potete persino giocarci. Ebbene una delle cose che ho sempre desiderato fare è avere uno scarico dei dati di giocatori e partite per poterli incrociare avere delle statistiche da cui possibilmente evincere trends ed informazioni utili a schierare le formazioni migliori.

Una schermata di esempio è quella delle skills di un singolo calciatore in cui ci sono info anagrafiche e capacità tecniche

Scheda calciatore

Nella fattispecie mi piacerebbe quindi avere in un unico excel le skills per colonna e i giocatori per riga magari indicando anche la data in cui questi dati sono stati raccolti con l’idea di poter monitorare un giocatore anche in giorni diversi nel caso le sue skills migliorino o peggiorino. Detto questo non ho la minima idea di come procedere, quindi chiedo a ChatGPT se mi può dare una mano:

Definizione del requisito

Chiedo scusa per l’inglese maccheronico, ma penso si capisca abbastanza bene. Ed ecco la risposta:

Prima parte della risposta

Bene, diciamo che già la lista delle attività pone sul tavolo alcuni strumenti come Python, OpenCV… In più mi porta cnhe un esempio di codice Python da utilizzare:

import os
import cv2
import pytesseract
import csv
from datetime import datetime

# Function to categorize screenshots based on format
def categorize_screenshots(screenshot_folder):
    # Implement your logic to categorize screenshots
    pass

# Function to extract data from screenshots and rename files
def extract_data_and_rename(screenshot_folder):
    for file in os.listdir(screenshot_folder):
        if file.endswith(".png"):
            img_path = os.path.join(screenshot_folder, file)
            img = cv2.imread(img_path)
            # Implement OCR to extract data from the image
            extracted_data = pytesseract.image_to_string(img)
            # Extract relevant information from the data
            # Rename the file using extracted data and current date
            new_filename = f"{extracted_data}_{datetime.now().strftime('%Y-%m-%d')}.png"
            os.rename(img_path, os.path.join(screenshot_folder, new_filename))

# Function to fill CSV files with data from screenshots
def fill_csv_files(screenshot_folder, csv_folder):
    for file in os.listdir(screenshot_folder):
        if file.endswith(".png"):
            img_path = os.path.join(screenshot_folder, file)
            img = cv2.imread(img_path)
            extracted_data = pytesseract.image_to_string(img)
            # Write extracted data to CSV file
            csv_filename = file.replace(".png", ".csv")
            with open(os.path.join(csv_folder, csv_filename), "w", newline="") as csvfile:
                csv_writer = csv.writer(csvfile)
                # Write data to CSV file
                csv_writer.writerow(extracted_data.split("\n"))

# Main function to execute the workflow
def main():
    # Path to the folder containing screenshots
    screenshot_folder = "path/to/screenshots"
    # Path to the folder where CSV files will be stored
    csv_folder = "path/to/csv_files"

    # Categorize screenshots
    categorize_screenshots(screenshot_folder)

    # Extract data from screenshots and rename files
    extract_data_and_rename(screenshot_folder)

    # Fill CSV files with data from screenshots
    fill_csv_files(screenshot_folder, csv_folder)

if __name__ == "__main__":
    main()

Fantastico: non avevo idea da dove cominicare e ChatGPT mi ha dato delle indicazioni preziose per cominiciare ad approfondire i temi.

Python

Non conosco questo linguaggio se non per sentito dire: non ho mai scritto mezza riga di codice, ma mi sembra di poter dire, dall’esempio che riporta ChatGPT, non sia poi così complesso. Leggendo su Wikipedia [4] tra l’altro scopro che deve il nome ai Monthy Python, già questa la dice lunga. Installarlo non è complesso basta seguire gli step indicati nelle varie guide online (tipo questa [5]). Anzitutto verifico che non sia già presente con questo comando a terminale:

python --version

Nel mio caso il risultato è quello che vedete (io ho installato la versione 3)

Bash

Nel caso non lo abbiate installato potete seguire la guida utilizzando brew

brew install python

Ora che Python è finalmente installato possiamo aprire Visual Studio code e utilizzando il codice che ChatGPT ci ha fornito creiamo un file .py di test da eseguire.

Nel prossimo post vedremo le librerie da utilizzare in Python così come ce le ha suggerite ChatGPT.

[1] https://www.beren.it/2024/02/08/automazione-o-intelligenza-artificale/

[2] https://www.fmscout.com/a-cm9798-v2-project.html

[3] https://www.dosbox.com

[4] https://it.wikipedia.org/wiki/Python

[5] https://www.jcchouinard.com/install-python-on-macos/

Automazione o Intelligenza artificale?

Breve digressione tra le principali differenze che occorrono tra una un’intelligenza artificiale e ciò che è una semplice automazione

Negli ultimi mesi il termine “Intelligenza artificiale” è entrato un po’ ovunque nelle agende politiche e sociali dopo che con ChatGPT si sono materializzati degli utilizzi reali di questo tipo di tecnologia. Come sempre la prima reazione è stata di disgusto, rifiuto, aberrazione: la più classica delle accezioni è stata “perderemo un sacco di posti di lavoro” ma non sono mancate le estremizzazioni come “tra non molto le macchine prenderanno il sopravvento” aka moriremo tutti. Non sono uno psicologo ma non ci voleva un genio per prevedere una reazione simile che, si può tranquillamente a mio avviso, derubricare come una declinazione della più generale resistenza al cambiamento. Naturalmente c’è anche ha cominciato a sfruttarne le positività: da quelli che si sono fatti scrivere le ricerche a scuola a chi ci ha scritto pure dei libri a “quattro mani”. Un fatto è che dai tempi di Asimov e delle sue leggi della robotica l’AI non è più solo fantascenza ma sta divenendo realtà.

1. Un robot non può recar danno a un essere umano né può permettere che, a causa del suo mancato intervento, un essere umano riceva danno.
2. Un robot deve obbedire agli ordini impartiti dagli esseri umani, purché tali ordini non vadano in contrasto alla Prima Legge.
3. Un robot deve proteggere la propria esistenza, purché la salvaguardia di essa non contrasti con la Prima o con la Seconda Legge.

Isaac Asimov – I Robot

Fatta questa premessa, una cosa che fatico sempre molto a differenziare è ciò che è relamente una AI da ciò che è una semplice automazione. E quindi mi sono detto chiediamolo a ChatGPT.

Chiediamo a Chat GPT

Ecco cosa dice in particolare come spiega le differenze l’AI stessa:

Automazione Classica:

  • L’automazione classica coinvolge la programmazione di regole e procedure fisse per eseguire compiti specifici.
  • Le attività di automazione classica sono basate su algoritmi e logica predeterminata, senza la capacità di apprendimento o adattamento.
  • Le azioni da eseguire e le condizioni per eseguirle sono esplicitamente definite dal programmatore.
  • L’automazione classica è efficace per compiti ripetitivi e ben definiti, ma può mancare di flessibilità per gestire situazioni impreviste o complesse.

Intelligenza Artificiale:

  • L’intelligenza artificiale è in grado di apprendere dai dati e adattarsi all’ambiente senza essere esplicitamente programmati per compiere determinate azioni.
  • Gli algoritmi di intelligenza artificiale possono analizzare grandi quantità di dati per rilevare modelli e tendenze, e utilizzare queste informazioni per prendere decisioni o eseguire azioni.
  • Le IA possono essere addestrate su una varietà di compiti e possono migliorare le loro prestazioni nel tempo attraverso l’apprendimento continuo.
  • Le IA possono affrontare compiti più complessi e ambigui rispetto all’automazione classica, poiché sono in grado di interpretare e comprendere dati non strutturati o situazioni in evoluzione.

Tutto abbastanza condivisibile e chiaro almeno nella teoria. Mi sorge comunque il dubbio che non è raro che si spacci l’una per l’altra ammesso che poi sia effettivamente sbagliato provare a separarle. Di certo si tende a volte, nelle discussioni da bar ma non solo a dare dell’intelligenza anche a qualcosa che d’intelligenza effettivamente non ne ha. Una macchina può essere bravissa ad eseguire un’automazione: sempre le stesse azioni per cui è programmata e sempre nello stesso modo (probabilmente molot preciso), senza però fare mai un salto che la porti a mettere in discussione quanto fatto finora e migliorarlo. Un buon esercizio potrebbe essere quello di provare a trovare un applicazione pratica in cui scendere nei dettagli e provarne le differenze.

Creare un Component in React.js

Per component (componente) normalmente si fa riferimento a qualcosa che può essere utilizzato/riutilizzato in diversi contesti normalmente in associazionne con altri componenti. Nel contesto di React.js i component sono oggetti che ritornano sostanzialmente del HTML e sono codificati in files .js. Sono normalmente messi in una cartella “components” nel folder src. Nel caso che vedete sotto andiamo a creare un component Employee e lo posizionamo in quel folder. Se vi interessa approfondire la modalità con cui si linkano le funzionalità tra diversi file js vi rimando a questo post [1].

Cartella components

A questo punto “disegnamo” html direttamente nel componente. Si, in soldoni l’idea è che il componente ritorni il frammento dell’HTML che poi verrà renderizzato da chi il componente lo richiama.

function Employee(){
    return <h3>Here is an employe</h3>;
}

export default Employee;

Nell’esempio disegneremo un titolo h3 e lo incorporeremo nella App.js

import './App.css';
import Employee from './components/Employee'

function App() {
  return (
    <div className="App">
      <header className="App-header">
        <Employee/>
        ...
      </header>
    </div>
  );
}

export default App;

Con questo esito:

application display component

Come potete notare è fondamentale che la function nel return ritorni un frammento di HTML che sia totalmente contenuto in un unico tag. Questo deve succedere sempre a partire da App.js. All’interno della function e prima del return si possono utilizzare tutti i comandi classici javascript ed implementare logiche, anche complesse. Immaginiamo che per qualche ragione si debbano visualizzare dei tag o delle info piuttosto che altre, in base a delle logiche definite. Una possibilità potrebbe essere quella di creare una variabile ed in base al suo valore decidere cosa renderizzare a schermo.

E’ possibile infatti utilizzare delle variabili all’interno del jsx che viene ritornato dal componente stesso e per farlo basta utilizzare le parentesi graffe {}.

      <header className="App-header">
        { returnEmployees ?
          <>
            <Employee/>
            <Employee/>
            <Employee/>
          </>
          :
          <></>
        }
      </header>

Nell’esempio riportato sopra si usa un’operatore ternario per verificare la variabile e ritornare il frammento che serve in base all’esito di quella verifica. Importante è che l’output sia sempre contentuto in un tag (anche quello vuoto) come nell’esempio. Si possono aggiungere più frammenti {} anche uno di seguito all’altro ma non vanno innestati. Importante: all’interno di questi frammenti si utilizza la sintassi javascript.

E’ bene infine ribadire che un component non è necessario che sappia nulla del contesto in cui è utilizzato perchè deve potenzialmente essere in grado di esistere così com’è. E’ solo chi utilizza che deve conoscere come funziona e come utilizzarlo correttamente.

[1] https://www.beren.it/2024/02/02/import-export-and-export-default-in-javascript/

Import, Export and Export Default in Javascript

Lavorando con diversi javascripts files nell’intenzione di separare quanto più possibile il codice e comunque riuscire a sfruttare funzionalità contenute in alcuni files in altri files è molto utile capire come funzionano Import ed Export.

La keyword export serve proprio a rendere disponibile all’esterno di un file una parte di codice definita nel file stesso. Ci sono due modalità con cui farlo: l’export e l’export default.

Export Default: è normalmente utilizzato quando si vuole condivider una specifica parte di codice all’esternoe le keywords da apporre sono export default

// 📂 math.js
const add = (a, b) => a + b;
export default add;

// 📂 main.js
import myAddFunction from './math.js';
const result = myAddFunction(5, 10); // This will call the add function from math.js and store the result in the 'result' variable.

Nell’esempio vediamo come la funziona add esportata nel primo file possa essere utilizza semplicemente importando il file stesso nel file che la vuole utilizzare.

Export: questa modalità è utile quando si vogliono esportare più pezzi di codice dallo stesso file ed in questo caso la keyword da utilizzare sarà solo export

// 📂 math.js
export function add(a, b) {
  return a + b;
}

export function subtract(a, b) {
  return a - b;
}

// 📂 main.js
import { add, subtract } from './math.js';

const result1 = add(5, 3); // result1 will be 8
const result2 = subtract(10, 4); // result2 will be 6

Import: è invece la keyword che serve ad importare le funzionalità esposte dai files esterni tramite le export e renderle fruibili al contesto del file corrente.

Riassiumiamo qui sotto le prinicpali caratteristiche di entrambi:

  • Con l’export semplice quando usiamo l’import dobbiamo esplicitamente definire thra parentesi graffe {} quali sono le funzionalità che vogliamo utilizzare e dobbiamo anche fare uso del nome esatto esposto. Con l’export default questo non serve.
  • All’interno di un file ci possono essere molteplici export ma solo un export default
  • export e export default possono essere utilizzati all’interno dello stesso file

Per chi volesse approfondire vi lascio un link [1] da cui ho tratto questi spunti.

[1] https://www.freecodecamp.org/news/difference-between-default-and-named-exports-in-javascript/#:~:text=In%20JavaScript%2C%20a%20default%20export,using%20the%20export%20default%20syntax.

Configurare GitHub in una React App con Visual Studio Code

Per chi lavora al codice è importante poter aver repository di codice che consenta principalmente due cose:

  • La gestione del codice in maniera concorrente: tipicamente più sviluppatori possono aver necessità di lavorare sugli stessi files, senza ostacolarsi e senza che l’uno “distrugga” quanto fa l’altro
  • La gestione delle versioni: avere la possibilità di tenere più versioni dello stesso file basate sul quando il file stesso è stato “salvato” nel repository consentendo rapidamente di individuare possibile problemi introdotti ad esempio con un cambiamento sull’ultima versione e poter riprisitnare una versione qualsiasi precedentemente salvata.

In questo post utilizzeremo come repository GitHub, che è del tutto free e consente agli utenti registrati di avere un repository on cloud sempre disponibile ed anche condivisibile. Assumendo di avere già un account creiamo online un nuovo repository (il nome lo potete scegliere a piacere) evitando di inizializzarlo dato che partiamo da una app react creata localmente (date un’occhiata a questo post [1] se non sapete come farne una).

GitHub – Create Repository

Una volta cliccato su Create Repository viene mostrata una pagina di configurazione in cui sono indicati i comandi da lanciare in console per creare e pushare il codice sul repostory appena creato. Basta copiare, incollare nel terminale e cliccare su invio.

GitHub – Repository Commands

A questo punto nella schermata di Visual Studio Code nel tab del versioning appaiono tutti i files della soluzioni che devono essere aggiunti.

Repository files list

I files hanno ora tutti una U sulla destra ma che significa esattamente?

  • U (Untracked): sono files aggiunti al progetto ma non ancora commitatti e nemmeno aggiunti all astaging area
  • M (Modified): un file presente nel repository e modificato
  • A (Added): un file aggiunto alla staging area
  • D (deleted): un file tracciato nel repository e cancellato localmente
  • C (Conflict): un file che ha un conflitto di versione

Quando parliamo di staging area definiamo quei files che vanno a formare un commit e che non sono ancora presenti nel repository.

Ora non resta che scrivere un commento nel box e cliccare commit. Quindi premere push per sincronizzare il tutto. Il risultato è che ora in GitHub nel repository indicato ho tutti i files del mio progetto locale.

Respository load in GitHub

Un occhio attento però noterà che non tutti i files che sono presenti nella cartella locale del progetto sono stati importati. Ad esempio build o node_modules non sono presenti. In realtà ciò è corretto ed il perchè è definito all’interno del file .gitignore posso definire quali file ignorare perchè superflui. Nella fattispecie build contiene la pubblicazione del sito mentre node_module ritorna i pacchetti utilizzati per la build.

[1] https://www.beren.it/2024/01/19/la-mia-prima-react-app/

La mia prima React App

React è una libreria Javascript tra le più utilizzate nell’implementazione di interfacce web [1]. E’ molto utilizzata per chi lavora con le Sigle Page Application in cui buona sostanza a differenza delle standard web application il DOM viene riscritto per intero ad ogni interazione lasciando al browser l’onere di ridisegnarla in base alla navigazione utente. E’ una modalità che ben si sposa con il concetto di Headless e di architettura composable.

Per prima cosa bisogna installare node.js sulla macchina dove si prevede di sviluppare l’applicazione. A questo punto possiamo utilizzare un comando specifico da terminale per creare l’app: create-react-app. Questo comando lancia la creazione dell’applicazione nella folder corrente del terminale quindi fate attenzione a quando lanciate il comando.

npx create-react-app hello
Crazione della React App

Al termine di un processo che può durare alcuni minuti questo comando genererà la struttura di files che vanno a comporre l’applicazione e che è ben descritta qui [2].

Abbiamo creato il template di app, ora ci serve aprire il tutto in editor di testo dove ci venga facile fare modifiche e lavorare sui files. Ci sono decine di editor ma quello che vi consiglio è Visual Studio Code (lo trovate qui [3]), è free, è leggero ed ha un sacco di estensioni utili. Vale la pena porre attenzione sui due files principali:

Entry Point

Questi files devono essere sempre presenti perchè sono sorgente da cui parte tutto. Index.html in particolare ha in div con id=”root” dal quale parte tutto: è all’interno di questo div che verranno generati di volta in volta i componenti da visualizzare nella pagina.

Index.html

Questo compito verrà svolto da index.js che come vedete sotto ricercherà quel did e lo sostituirà con qualcosaltro che la soluzione definisce, in questo caso <App /> che non è nientaltro che tutto ciò che si trova nel file App.js prsente sempre nella cartella src.

index.js

A questo punto per vedere l’app in azione non ci resta che aprire un nuovo Terminal dal menu di Visual Studio Code ed eseguire il comando:

npm start

Ed eccoci quà l’applicazione demo funziona:

Quando invece dovete pubblicare l’applicazione il comando da utilizzare è leggermente differente: npm run build.

npm run build

Questo genererà una cartella build nella root del progetto.

Build folder

Nella lista dei files se ne trovano due che hanno come nome package.json e package-lock.json. Il nome è molto simile e potrebbe trarre in inganno sul loro significato. Package.json definisce i package e le relative versioni da utilizzare nel progetto. Questo significa che lanciando il comando npm install il sistema in base alle versioni installate sulla macchina definirà quale combinazione di package utilizzare e creerà il file package-lock che a quel punto contiene esattamente tutti i package utilizzati sulla macchina.

[1] https://react.dev/

[2] https://create-react-app.dev/docs/folder-structure

[3] https://code.visualstudio.com/download

J. G. Ballard – Il mondo sommerso

Non avevo mai letto nulla di Ballard, così quando questa estate prima delle vacanze mi ero imbattuto in libreria in questo romanzo mi sono ricordato di avere in passato sentito qualche recensione in merito. L’idea in sè è abbastanza semplice e, di questi tempi pure molto gettonata: un futuro in cui le temperature sulla terra cominciano ad alzarsi creando lo scioglimento dei ghiacci e il conseguente innalzamento delle acque con l’inevitabile innondazione delle città e di granparte delle aree normalmente abitate. In questo caso il colpevole è un’attività solare estrema e non l’attività umana ne l’effetto serra dovuto ad altri eventi endogeni come eruzioni vulcaniche o cataclismi di qualche genere. E’ curioso sapere che in passato il nostro pianeta ha già sperimentato temperature simili nel corso della sua storia e, anzi, in alcuni casi ha raggiunto temperature ben peggiori (date un occhio qui per maggiori info [1]).

Protagonista è Robert Kerans, uno scienziato parte di un’unità militare che effettua ricerche nelle aree con temperature estreme (se ho capito bene siamo intorno a Londra) in un paesaggio in cui l’acqua la fa da padrona e le poche persone rimaste a quelle latitudini vivono agli ultimi piani dei palazzi spostandosi dagli uni agli altri attraverso imbarcazioni o aerovelivoli. In questo scenario apocalittico il protagonista si sente visceralmente attirato a sud da qualcosa che non sa spiegarsi e che lo porterà allo scontro con gli altri supersisti. Un qualcosa a metà tra una sorta di richiamo ancestrale parte di un’eredità dei nostri antenati più vecchi ed una sorta di suicidio sull’altare di quel sole senza il quale non possiamo vivere ma che in taluni casi può essere anche letale.

Ballard come tutti i più grandi maestri del genere fantascentifico è bravo nel portarci nella vita delle persone e farci vivere le emozioni ed i drammi che vivono, i dilemmi che le angosciano e le speranze che le tengono in vita senza troppe licenze a technologie futuristiche e creature esotiche. In fondo nella nostra vita di tutti i giorni come in quella di un futuro prossimo, non è tanto importante come viviamo quanto perchè lo facciamo.

[1] https://www.nationalgeographic.it/ambiente/2020/09/la-terra-sta-registrando-temperature-da-record-ma-in-futuro-sara-molto-piu-calda

Gestire le versioni di una asp.net Core WebAPI

Una delle più importanti ragioni percui le WebAPI hanno preso largamente piede negli ultimi anni è la possibilità di disaccoppiare fortemente la parte di rappresentazione da quella del layer dati/applicativo. Questo forte disaccoppiamento necessita però che cambi radicali alle WebAPI non vadano a discapito di chi le consuma: se cambio un API dovrei essere sicuro che una volta cambiata tutto ciò che prima funzionava continui a funzionare nella stessa maniera altrimenti potrei potenzialmente “rompere” delle funzionalità di applicazioni che consumano queste API. La maniera migliore per farla è quella di procedere ad un versionamento delle API, ma prima di farlo occorre capirsi sul quando è necessario creare una nuova versione delle API e quando no. Vi lascio questo link [1] che è ricco di spunti ed è ciò su cui ho basato questo post. Riassumendo le casistiche sarebbero più o meno le seguenti:

  • Rimuovere o rinominare API o i suoi parametri
  • Cambiamenti significativi nel comportamento dell’API
  • Cambiamenti al response contract
  • Cambiamenti ai codici di errore

Per prima cosa dobbiamo definire le versioni all’interno del Program.cs. In questo caso definiamo anche la version 1 come quella di default.

builder.Services.AddApiVersioning(options =>
{
    options.DefaultApiVersion = new ApiVersion(1);
    options.ReportApiVersions = true;
    options.AssumeDefaultVersionWhenUnspecified = true;
    options.ApiVersionReader = ApiVersionReader.Combine(
        new UrlSegmentApiVersionReader(),
        new HeaderApiVersionReader("X-Api-Version"));
}).AddApiExplorer(options =>
{
    options.GroupNameFormat = "'v'V";
    options.SubstituteApiVersionInUrl = true;
});

Successivamente occorre decorare il controller con le Versioni supportate e con il conseguente path dinamico basato sulla versione

[ApiVersion(1)]
[ApiVersion(2)]
[Route("api/v{v:apiVersion}/[controller]")]
public class InfoAPIController : ControllerBase
{

A questo punto devono essere decorati appositamente tutti i metodi che hanno più versioni con lo stesso Http Get name ma differente nome C#

[MapToApiVersion(1)]
[HttpGet(Name = "GetInfo")] //, Authorize]
public string GetV1(string name)
{
    ...

[MapToApiVersion(2)]
[HttpGet(Name = "GetInfo")] //, Authorize]
public string GetV2(string name)
{

Fatto ciò dovremmo quindi essere in grado di usufruire versioni diverse in base al path utilizzato. In realtà, come spiegato per bene nel post sotto, le modalità potrebbero essere differenti ma io opto per un verisoning basato sull’url.

Tutto molto bello ma tutto ciò non basta a visualizzare due differenti versini in Swagger. Per farlo occorrono un altro paio di accortezze che ho scoperto in un altro post [2]. La prima è che vanno configurate le versioni visibili all’interno della configurazione di swagger (nel mio caso sono due):

builder.Services.AddSwaggerGen(options =>
{
    options.AddSecurityDefinition("oauth2", new OpenApiSecurityScheme
    {
        In = ParameterLocation.Header,
        Name = "authorization",
        Type = SecuritySchemeType.ApiKey
    });

    options.OperationFilter<SecurityRequirementsOperationFilter>();

    options.SwaggerDoc("v1", new OpenApiInfo { Title = "Xin Web API", Version = "v1"});
    options.SwaggerDoc("v2", new OpenApiInfo { Title = "Xin Web API", Version = "v2" });
});

Infine nel SwaggerUI vanno registrati i path delle versioni, ma invece di farlo uno ad uno consiglio di utilizzare l’approccio descritto qui [3]

    app.UseSwaggerUI(options =>
    {
        var descriptions = app.DescribeApiVersions();

        // Build a swagger endpoint for each discovered API version
        foreach (var description in descriptions)
        {
            var url = $"/swagger/{description.GroupName}/swagger.json";
            var name = description.GroupName.ToUpperInvariant();
            options.SwaggerEndpoint(url, name);
        }
    });

Attenzione che i due passi sopra sono fondamentali se volete visualizzare correttamente nella drop down di swagger netrambe le versioni e switchare tra di esse i due punti sopra sono fondamentali.

Swagger con le due versioni selezionabili.

[1] https://www.milanjovanovic.tech/blog/api-versioning-in-aspnetcore

[2] https://dev.to/sardarmudassaralikhan/swagger-implementation-in-aspnet-core-web-api-5a5a

[3] https://mohsen.es/api-versioning-and-swagger-in-asp-net-core-7-0-fe45f67d8419

Gestire differenti Appsettings in base all’ambiente di rilascio

Quando si lavora su una soluzione è vitale che si abbia la possibilità di differenziare delle configurazioni in base all’ambiente di destinazione “target” della soluzione. L’esempio più semplice è quello delle stringhe di connessione a DB: se si hanno ambienti diversi normalmente serviranno delle stringhe differenti in base al DB. In generale per i progetti asp.net core (e non solo) è possibile gestire tanti settings quanti sono gli ambienti di rilascio, però non è così banale trovare un modo per rendere dinamica questa modalità. Ho travato infatti molta documentazione sul come giocare con le variabili di ambiente [1] che però, nell’ambiente target (una soluzione cloud), non mi è possibile toccare. Dopo varie ore a cercare in rete qualcosa di sensato sono approdato a questa soluzione che vi spiego che in parte trovate anche in questo video.

Definizione di ambienti di rilascio: per prima cosa definiamo quali ambienti deve contemplare la mia soluzione per capire quanti varianti di file di configurazione servono. Nel mio caso sono 4:

  • Development: la configurazione che utilizzo in Visual Studio quando sviluppo e debuggo
  • Stage: la configurazione che utilizzo per testare l’applicazione sul’ISS locale della macchina di sviluppo
  • Sandbox: l’ambiente di preproduzione in cloud
  • Live: l’ambiente di produzione reale

Per ognuno di questi ambienti mi servirà un file di appsettings dedicato formattato nella seguente maniera: appsettings.{env}.json. Per farlo basta copiare il file appsettings già presente nella soluzione e rinominarlo utilizzando i quattro nomi sopra. Tenete sempre in conto che il primo file ad essere letto è appsettings (quello generico) che poi verrà sovrascritto da quello con il nome dell’ambiente. Questo significa che tutto ciò che chiede di essere specifico per ambiente deve finire in nel file con il nome dell’ambiente stesso.

Caricamento dei settings corretti: in Program.cs carichiamo anzitutto il file appsettings generico all’interno del quale andiamo a creare una configurazione che identifichiamo con Configuration dove scriveremo il target del deploy (uno dei 4 valori sopra). Ed in base a quel valore andiamo a caricare il file dedicato.

var _conf = builder.Configuration.AddJsonFile("appsettings.json", optional: true, false).Build();
string _env = _conf.GetSection("Configuration").Value;
builder.Configuration.AddJsonFile($"appsettings.{_env}.json", optional: true, false);

var app = builder.Build();

In questa maniera basterà identificare nel appsettings generico il target del deploy (volendo anche al volo) all’interno della variabile di configurazione Configuration.

Rilasciare solo i files dell’ambiente: per come fatto sopra e sostanzialmente mostrato anche nel video tutti i files appsettings verranno sempre deliverati in tutti gli ambienti e la cosa non mi mpiace molto perchè si presta ad avere errori se non modifico correttamente il Configuration all’interno dell’appsettings generico. Per ovviare a questo problema genero 3 nuove versioni dal configuration manager: Live, Sandbox e Stage. A questo punto apro il file di progetto in edit ed aggiungo la seguente configurazione che rilascia solo il file corretto in base al target che ho scelto.

	<Choose>
		<When Condition="'$(Configuration)' == 'Live'">
			<ItemGroup>
				<None Include="appsettings.Live.json" CopyToOutputDirectory="Always" CopyToPublishDirectory="Always" />
				<None Include="appsettings.json" CopyToOutputDirectory="Never" CopyToPublishDirectory="Never" />
				<Content Remove="appsettings.*.json;appsettings.json" />
			</ItemGroup>
		</When>
		<When Condition="'$(Configuration)' == 'Sandbox'">
			<ItemGroup>
				<None Include="appsettings.Sandbox.json" CopyToOutputDirectory="Always" CopyToPublishDirectory="Always" />
				<None Include="appsettings.json" CopyToOutputDirectory="Never" CopyToPublishDirectory="Never" />
				<Content Remove="appsettings.*.json;appsettings.json" />
			</ItemGroup>
		</When>
		<When Condition="'$(Configuration)' == 'Stage'">
			<ItemGroup>
				<None Include="appsettings.Stage.json" CopyToOutputDirectory="Always" CopyToPublishDirectory="Always" />
				<None Include="appsettings.json" CopyToOutputDirectory="Never" CopyToPublishDirectory="Never" />
				<Content Remove="appsettings.*.json;appsettings.json" />
			</ItemGroup>
		</When>
		<Otherwise>
			<ItemGroup>
				<None Include="appsettings.Development.json" CopyToOutputDirectory="Always" CopyToPublishDirectory="Always" />
				<None Include="appsettings.json" CopyToOutputDirectory="Never" CopyToPublishDirectory="Never" />
				<Content Remove="appsettings.*.json;appsettings.json" />
			</ItemGroup>
		</Otherwise>
	</Choose>

In questo modo basterà prima di rilasciare in uno degli ambienti selezionare la tipologia di deploy e verranno solo rilasciati i files di configurazione relativi.

[1] https://learn.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?view=aspnetcore-8.0#evcp

Easy log per asp.net core: Serilog

E’ inutile spiegare perchè loggare sia un punto chiave nello sviluppo di un’applicazione. E’ altrettanto inutile dire quanto oggi sia inutile sviluppare un framework custom che lo faccia: ci sono mille plugin che lo fanno (e spesso anche molto bene) per cui c’è davvero l’imbarazzo della scelta. Non tutti però sono semplici da configurare (alcuni sono un vero incubo). La mia scelta dopo vari tentativi è ricaduta su SeriLog. Sul web trovate parecchia documentazione in merito ve ne suggerisco un paio sotto.

Nello specifico queste sono le azioni che ho condotto per installarlo e configurarlo:

  • Scaricare con NuGet Packages Manager il pacchetto Serilog.AspNetCore
  • Ho inizializzato il Logger all’interno del Program.cs
var logger = new LoggerConfiguration()
    .ReadFrom.Configuration(builder.Configuration)
    .Enrich.FromLogContext()
    .CreateLogger();

builder.Logging.ClearProviders();
builder.Logging.AddSerilog(logger);
  • Ho aggiunto nel file appsettings.js le configurazioni di scrittura, tra cui il nome del file dov’è posizionato etc…
"Serilog": {
  "Using": [ "Serilog.Sinks.File" ],
  "MinimumLevel": {
    "Default": "Information"
  },
  "WriteTo": [
    {
      "Name": "File",
      "Args": {
        "path": "../APIlogs/webapi-WebAPICoreAuthBearer.log",
        "rollingInterval": "Day",
        "outputTemplate": "[{Timestamp:yyyy-MM-dd HH:mm:ss.fff zzz} {CorrelationId} {Level:u3}] {Username} {Message:lj}{NewLine}{Exception}"
      }
    }
  ]
}

Con queste semplici azioni il vostro sistema già loggerà in automatico. Qualora vi servisse esplicitamente loggare all’interno dei vostri controller nel caso di un API naturalmente basta utilizzare la solita modalità “iniettiva”.

 private readonly ILogger<InfoAPIController> _logger;
 private readonly IConfiguration _configuration;

 public InfoAPIController(ILogger<InfoAPIController> logger, IConfiguration iConfig)
 {
     _logger = logger;
     _configuration = iConfig;
 }

 [HttpGet(Name = "GetInfo")] ]
 public InfoAPI Get()
 {
     _logger.Log(LogLevel.Information, "GetInfo");
....

[1] https://www.claudiobernasconi.ch/2022/01/28/how-to-use-serilog-in-asp-net-core-web-api/

[2] https://www.youtube.com/watch?v=QjO2Jac1uQw

[3] https://www.milanjovanovic.tech/blog/5-serilog-best-practices-for-better-structured-logging