Post di Federico Quintieri

Sei nuovo nel progetto. Installi le dipendenze. Segui gli step de README. É quasi tutto pronto… Ad un certo punto arriva qualcuno nel team e dice "aspetta che ti mando il dump del database". Allora, zio fringuello, nel 2024 io credo che sia molto piu professionale usare le migration per creare/manipolare lo schema del hashtag #db piuttosto che fare ancora tutto a manella. E sarebbe altrettanto interessante avere strumenti che popolino il #database alla bisogna con dati di esempio. Chi le chiama #fixture. Chi le chiama #seed. Chi testa il codice le distingue in fixture dinamiche (caricate nei test magari) o statiche (caricate prima di lanciare tutti i test). Hai presente quando ti servirebbe il db in un preciso stato? Eh… perché non farsi dei comandi per generare quello stato al volo invece che far sempre tutto a mano? Poi… va bene #versionare il codice ma va altrettanto bene versionare lo schema del #db!! Sono o non sono strettamente legati tra loro? Per testare una precisa versione del codice, dovrai avere una precisa versione del database. No? Quindi versione lo schema!! Quando testi, molte fixture le carichi direttamente dentro al test per avere l’esatta condizione di dati che ti serve in quel preciso momento. Vero?

Dove alloggia Mario? E niente, se sapete rispondere avete capito la logica relazionale. I database relazionali non sono solo uno strumento ma l'applicazione di un modello astratto di gestire i dati che non può invecchiare perchè è un idea. Sarebbe come fare invecchiare l'operazione dell'addizione. Quindi qualunque software vogliate sviluppare dovete partire da una progettazione dei dati fatta in questo modo, anche se voleste usare quelle robe strane NOSQL.

Lo sapete che molto spesso i problemi di performance non sono causati dal codice... ...ma dalle richieste assurde di clienti e da "analisti" che li ascoltano e che sono poco analisti e molto commerciali? Eh sì, perché molte volte non è il codice ad essere "sbagliato" o "poco performante", è proprio la richiesta che non sta né in cielo né in terra, ma piuttosto che approfondire il "commercianalista" vuole vendere e basta. Un po' di tempo fa ho incrociato una query che restituiva centinaia di migliaia di record e li svuotava in una griglia di Windows Forms. Ho chiesto perché non fosse stata fatta (almeno) paginata, e mi è stato risposto "perché il cliente la voleva così ed era abituato così". Insistendo ho chiesto quale fosse il processo che portava il cliente a desiderare di consultare una mole di dati così massiva e la risposta mi ha lasciato senza parole: "il cliente ha un codice, scritto su un foglietto di carta. Lo deve trovare nella lista." Quel giorno l'Informatica è morta. #development #storytelling #performance #analyst #sql #nojoke

ACID: quattro lettere, una garanzia di sicurezza nei database. ⚠️ Ecco perché chiunque lavori con i database dovrebbe conoscere l'ACID: Atomicità, Coerenza, Isolamento e Durabilità. In questo post vediamo come queste proprietà mantengano i dati al sicuro, anche quando qualcosa va storto. 🟢 La spiegazione breve: Atomicità: o tutto o niente. Le transazioni incomplete vengono annullate come se non fossero mai avvenute. Coerenza: ogni transazione rispetta le regole del database, mantenendo i dati sempre corretti. Isolamento: anche con più transazioni simultanee, ciascuna lavora come se fosse da sola. Durabilità: una volta completata, la transazione è permanente, anche in caso di crash del sistema. ☝️ Ora approfondiamo un concetto chiave: l'isolamento. È il guardiano che impedisce alle transazioni di influenzarsi a vicenda. Livelli di isolamento come serializzabile sono i più sicuri, ma rallentano il sistema. Per un equilibrio tra velocità e sicurezza, si possono scegliere livelli inferiori come lettura confermata che, pur limitando l’isolamento, garantiscono prestazioni più rapide. Ma attenzione: potresti avere letture sporche o fantasma! 👍 Se lavori con sistemi distribuiti, durabilità significa anche replicazione: i dati sono copiati su più nodi, così se uno va giù, le transazioni confermate restano al sicuro sugli altri. 😎 E tu? Quando lavori con i database, quale di queste proprietà trovi più cruciale? Hai mai affrontato problemi con le letture sporche o transazioni non isolate? Raccontami la tua esperienza e come hai risolto! #sql #database #cs50

Nominare i file è una scienza* Raramente le organizzazioni stabiliscono le regole a cui attenersi per dare i nomi dei file eccetto quando sono gli applicativi a farlo ( fatturazione, deliberazioni, ricettari ecc.) Da un intelligente modo di nominare i file tutti possono ricavare molti vantaggi: - archivi più ordinati - facilità di recupero informazioni - agevole ricostruzione dei flussi - report immediati grazie all’ordinamento cronologico dato dalla regola base che riguarda la prima parte del nome file che deve essere “rigorosamente” la data di creazione ( o quella del documento rappresentato) in formato ISO 8601 ovvero: anno mese giorno separati o meno da un carattere speciale - . _ ( questo per noi europei facilita la lettura rispetto alla rappresentazione AAMMYY). Negli anni ho suggerito a molti amici, ai colleghi insegnanti, ai miei allievi, ai vari partner nei RTI di adottare questo metodo, illustrato nell’immagine qui sotto e, a distanza di anni, ho solo ricevuto positivi riscontri. L’utilità di sapere già dal nome il contenuto di un file - senza doverlo aprire -non ha prezzo. Per chi programma, poi, salvare ogni giorno con nome diverso le varie relaise del codice, fornisce la cronologia immediata dello sviluppo. All’inizio appare poco naturale ma dopo poco tempo si coglie il vantaggio e non si abbandona più. Quando si apre il dialog box “Salva come …” si butta l’occhio all’orologio del PC e si legge la data al rovescio oggi 2024-07-23 e dopo tutto il resto. Provate e … * si evidenzia che mettendo la data a inizio nome file , ma solo nel formato ISO8601, ordinando i file per nome vengono mostrati in sequenza cronologica. Prassi utilissima per ricostruzioni storiche, report si attività professionali, fascicoli procedimentali ecc. e utile nella ricerca rapida. Esiste uno script per pre-impostare la data in ISO8601 all’inizio del nome file quando si apre la finesta salva con nome.

Circa 402,74 milioni di terabyte creati ogni giorno e 147 zettabyte previsti per la fine dell’anno, stiamo parlando della mole spaventosa di informazioni prodotta nell’ultimo periodo, numeri da capogiro, che pongono profonde riflessioni sull’importanza reale di tutti questi dati e sul metodo più rapido ed efficace per analizzarli. 📈 In azienda le fonti interne principali di informazione includono applicativi come ERP, CRM, sistemi di gestione delle risorse umane (HRMS), sistemi di produzione (MES), approvvigionamento (SRM) e gestione del magazzino (WMS). 📊 Restano ancora di fondamentale importanza fonti come i fogli Excel, pur non avendo le caratteristiche di un database; tuttavia, ad oggi le informazioni non provengono più solo da fonti strutturate, ma anche da fonti non strutturate come pdf, immagini, video e tante altre, che i sistemi di intelligenza artificiale e deep learning hanno imparato ad analizzare con successo. 🔍 Una considerazione a parte va fatta per le API (Application Programming Interface), che sono un insieme di istruzioni e protocolli che permettono di inviare richieste ad altri prodotti e servizi come social media, servizi finanziari ed altre risorse web ottenendo in risposta informazioni che possono risultare strategiche, basti pensare all’ambito del marketing ed alle informazioni messe a disposizione in automatico dalle API di Facebook e Google. 🌐📊 #PillolediBI #DataIntegration #BusinessIntelligence #Analytics Fonti: https://lnkd.in/eWinhqAT https://lnkd.in/d8GAEF2b

C’è chi odia i fusi orari e chi mente ⌛️ La gestione dei timestamp è un aspetto fondamentale dell’informatica, ma spesso crea grossi problemi agli sviluppatori. 🤯 Ma cos'è un timestamp? Si tratta di una sequenza che identifica univocamente un singolo momento nel tempo, e può essere memorizzato in diversi formati.  I più famosi sono: 📍 Unix Timestamp: il numero di secondi trascorsi dal 1° gennaio 1970 (epoch Unix). È il formato più diffuso per la sua semplicità, ma non considera direttamente i fusi orari. 📍 ISO 8601: una rappresentazione più leggibile, come `YYYY-MM-DDTHH:MM:SSZ` che può includere informazioni sul fuso orario. Problemi legati ai fusi orari 👇 Un timestamp dovrebbe idealmente essere immutabile e universale, ma spesso le applicazioni necessitano di adattarsi ai fusi orari locali.  Questo porta a problemi come: 📍 Variazioni stagionali: in Europa, per esempio, i fusi orari cambiano a seconda del periodo dell'anno: d'estate si utilizza il CEST (UTC+2), mentre d'inverno il CET (UTC+1). 📍 Ambiguità: la conversione tra fusi orari può portare a errori, specialmente quando si tratta di periodi di transizione come l'entrata o l'uscita dall'ora legale. Ecco alcuni suggerimenti per minimizzare i problemi legati ai timestamp e ai fusi orari: 📍 Utilizza UTC: Memorizza sempre i timestamp in UTC (il fuso orario di riferimento globale), convertendo in fusi orari locali solo quando necessario per l'interfaccia utente. 📍 Test approfonditi: Assicurati di testare le tue applicazioni in scenari che includano cambi di ora legale e fusi orari non standard. 📍 Documentazione: Mantieni una documentazione chiara su come la tua applicazione gestisce i timestamp e i fusi orari, per evitare malintesi e bug. #timestamp #datascience #ai

L'Obsolescenza del Software gestionale: Un Rischio Sottovalutato. In un mondo in continua evoluzione, molte aziende si trovano a fare i conti con un problema critico: l'obsolescenza del software. Quando un sistema non è più aggiornato, non solo limita le sue possibilità di evoluzione, ma aumenta anche il rischio di vulnerabilità informatiche. "Il tempo corre, il tuo software gestionale no. Perchè rischiare l'obsolescenza?" #SoftwareObsoleto #DigitalizzazioneAziendale #GestionaliZucchetti #AssistenzaIT #SoluzioniGestionali #AziendaModerna #SirioSoftware #zucchetti

Quando si lavora ad un #aggiornamento #software, l’approccio è sempre lo stesso: “come fare a proporre qualcosa di nuovo senza però stravolgere le abitudini di chi ci lavora da tempo?”. La cosa più difficile, ancor più dello sviluppo della #procedura, è proprio trovare l’equilibrio tra queste due #necessità.   Immaginate infatti di approcciare una procedura magari migliore, ma completamente stravolta. Si dovrebbe imparare nuovamente da zero quali #pushbutton premere, quale #logica seguire, quali richieste effettuare per ottenere gli #output desiderati. Sarebbe un programma migliore? No, sarebbe un programma diverso.   La cosa giusta da fare quindi, non è stravolgere il software, ma offrirvi #supporto. Perché secondo noi la procedura migliore, è quella di cui l’#operatore senta aver completa padronanza.   Ecco spiegate allora le caratteristiche della nuova gestione #tabelle di Sim-X: la novità c’è, ed è la tabella aggiuntiva della schermata principale, ma c’è anche il supporto, in quanto la nuova tabella, spiegherà voce per voce il significato dei campi e come compilarli. In questo modo, chi si approccia, saprà come fare, chi è già navigato, avrà un reminder.   In breve, non preoccupatevi: non abbiamo stravolto niente, lo abbiamo solo migliorato. News in link: https://lnkd.in/ddHUehbX

💾 Il #database #relazionale è tra noi dagli anni 70 e quindi da 50+ anni sopravvive egregiamente (e con molta probabilità ci sopravvivrà, insieme al #COBOL e al #PL1) e ad oggi rimane un componente centrale e fondamentale delle infrastrutture digitali di ogni compagnia tech (dopo #Excel ovviamente 😅). Perchè? Principalmente per la gestione della #transazionalità, cioè la capacità di un #rdbms di gestire unità logiche di lavoro (le transazioni) che coinvolgono uno o più modifiche ai #dati: una transazione deve eseguire tutte le operazioni richieste o, in caso di errore, annullarle tutte per garantire la #coerenza e l'#integrità dei dati (le note proprietà #ACID). 💰 Questo è fondamentale ad esempio per flussi di lavoro #OLTP come l'accredito del vostro stipendio a fine mese, l'addebito del mutuo o della rata della macchina, l'acquisto (previa verifica della disponibilità nello stock di magazzino) di qualsiasi cosa negli store online. PostgreSQL 👶 O semplicemente #postgres per gli amici è, dopo 35 anni, uno dei #database #opensource più apprezzati (ranking nei link), robusti, affidabili e ricchi di estensioni (una su tutte: #postgis per il supporto ai dati #spaziali e a strumenti #gis open come #qgis). E tutto il mondo #NoSQL e le nuove tecnologie di AI basate su #RAG? Se non c'è da fare #caching seriamente (si legge #Redis) nel 99% dei casi probabilmente saranno sufficienti i tipi #json (testuale) e #jsonb (binario e compresso), per partire con i RAG invece si può tranquillamente iniziare con #pgvector e poi esplorare soluzioni ad-hoc. Ok, poi? Poi bisogna sporcarsi le mani per capire le basi e soprattutto i problemi (permessi, memoria, spazio disco, max numero di connessioni, scaling, repliche, ecc..), quindi come ☑️ opzione #1 si può installare tutto a mano in locale o su macchina virtuale (#vm) ospitata sul nostro #cloudprovider preferito per prendere dimestichezza con le configurazioni… oppure ☑️ opzione #2 si può andare direttamente su una #soluzione #gestita fornita sempre dal nostro #cloudprovider preferito, facilmente scalabile in produzione, dotata di backup automatici, manutenzione semplificata delle versioni, ecc… tutti i benefici che si possono immaginare dal non dover fare tutto a mano. Prossimamente proviamo a dare qualche numero, cioè: tutto bello bellissimo ma quanto mi costa? 🤫