Post di Roberto Zingone

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.

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?

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 dei 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

O_DIRECT mi ha fatto cambiare strada, ecco perchè non abbiamo scelto Unraid. La scelta della piattaforma giusta per gestire lo storage aziendale è una decisione strategica che richiede attenzione ai dettagli. Recentemente, durante la valutazione di Unraid per le nostre esigenze, ci siamo imbattuti in una caratteristica tecnica che ha completamente cambiato il nostro approccio: O_DIRECT. Cos’è O_DIRECT e perché è importante? O_DIRECT è un’opzione che consente al sistema operativo di scrivere i dati direttamente sul disco, bypassando la cache. Questo garantisce: Integrità dei dati: I dati vengono scritti in modo sicuro, riducendo i rischi in caso di interruzioni improvvise. Prestazioni prevedibili: Evita problemi legati alla cache durante carichi intensi come virtualizzazione o gestione di database. Affidabilità in ambienti critici: Ideale per contesti in cui la sicurezza dei dati è una priorità assoluta. La limitazione di Unraid Unraid è molto popolare per la sua flessibilità, soprattutto in ambiti domestici o per piccoli uffici, ma manca del supporto completo a O_DIRECT. Questo rappresenta un limite importante per chi, come noi, ha bisogno di: Coerenza dei dati per gestire archiviazioni critiche, Performance stabili anche sotto carichi impegnativi, e Funzionalità avanzate per VM e storage aziendale. Non volevamo correre rischi su aspetti fondamentali come la protezione e la gestione dei nostri dati. Perché abbiamo scelto TrueNAS e ZFS Dopo aver analizzato attentamente le opzioni, la scelta è ricaduta su TrueNAS con ZFS, un file system che offre: Scritture transazionali: Ogni operazione è sicura e atomica. Auto-riparazione con checksum: Ideale per mantenere l’integrità dei dati. Snapshot avanzati: Perfetti per backup incrementali e ripristini rapidi. Caching intelligente (ARC): Prestazioni elevate senza compromettere l'affidabilità. La lezione appresa Questa esperienza ci ha insegnato che, quando si tratta di gestire dati critici, ogni dettaglio conta. La flessibilità di Unraid è indubbia, ma non è sufficiente per soddisfare i requisiti di integrità e affidabilità che cercavamo. Conclusione Abbiamo imparato che è essenziale approfondire ogni aspetto tecnico prima di scegliere una piattaforma. O_DIRECT ci ha fatto riflettere e ci ha portato verso una soluzione più robusta e adatta alle nostre esigenze. Se anche tu stai valutando alternative per lo storage o hai affrontato decisioni simili, mi piacerebbe conoscere la tua esperienza! Confrontiamoci nei commenti o in privato.

In un articolo hai capito perché parte tutto dai dati e serve conservarli con la soluzione informatica opportuna. In dei video ho mostrato come creare delle basi di dati gratuite, con una difficoltà crescente. Quei servizi potenzialmente non ti servono se il fornitore che ospita il tuo sito aziendale (o dell’organizzazione) ti permette, senza costi … Come creare una base di dati se hai già un sito aziendale Leggi altro » - https://lnkd.in/duA93nz8

Come analizzare l'andamento di un Expert Advisor? Tramite i dati. Dove possiamo salvare questi dati? Nei database SQLite integrati con la Metatrader5. In questo caso ho salvato il risultato giornaliero del sistema. Il magic number, il simbolo e la modalità (se backtest o live). Queste sono le informazioni di base. Tramite la colonna 'Risultato' ne ho create altre 6 che contengono i valori necessari a capire se mettere in pausa il sistema oppure no. Quindi quello che ho fatto è stato leggere i record della colonna 'Risultato' per crearne delle altre. Alla fine c'è un altra colonna che conterrà il risultato di una condizione che esamina tutti questi valori creati. Idoneo | Non Idoneo Tramite questo noi possiamo facilmente mettere in pausa il nostro EA. Questa è una tabella molto basilare tutt'ora in sviluppo. Si potrebbe creare un database per ogni sistema e creare più tabelle per suddividere ogni tipo di valore o aggiungerne altri. Però la mia idea era di rendere il tutto il più semplice possibile. Se hai delle idee su come potrei fare lasciami un commento. Ti aspetto al prossimo post 😉.

🎄 Advent of Code 2024 - Giorno 6 Ieri è stato un giorno duro con l’AoC 2024. Pensavo sarebbe stato il primo giorno in cui non sarei riuscito a risolvere entrambi i problemi, ma dopo 4 tentativi falliti, sono riuscito a trovare la risposta: attraversare la matrice bidimensionale cambiando coordinata per coordinata e poi verificando (con un altro for-loop) se tale matrice fosse valida o meno. (Questa volta non condividerò la mia risposta, è enorme). Tuttavia, mi ha fatto riflettere su due cose importanti: 1. Validazione della Soluzione: • Avere una soluzione corretta con i dati di esempio non basta. È fondamentale identificare casi estremi che potrebbero far fallire il codice. • Inoltre, se l’input è enorme, usare console.log() per analizzare ogni caso non è una buona idea. 2. Ottimizzazione del Codice: • Trovare la soluzione è importante, ma fermarsi a pensare a come ottimizzare le sezioni che abbiamo già risolto può essere molto vantaggioso. La mia soluzione impiega 19 secondi per dare la risposta… al 99% di utilizzo del PC… sapete cosa si dice: “Abbiamo comprato tutto il PC, quindi usiamo tutto il PC!”. D’altra parte, come dato curioso, la soluzione del nostro amico GPT-01 ha impiegato 9 secondi… non sono così male, vero? 😉 :wq

Dipendenza informatica aziendale, è necessario rifletterci. Qualche giorno fa ho fatto un post su come sia alto il rischio che le aziende di tutto il mondo possano essere ricattate anche solo dall'OS (Operative System, Sistema Operativo) Microsoft, cosa resa più evidente dagli ultimi che stanno obbligando a cambiare addirittura i calcolatori informatici usati perché Microsoft ha deciso che possono essere installati solo su quelli che hanno specifici requisiti spesso pure non utilizzati dagli utenti. In realtà quella di rendere dipendenti alle proprie applicazioni e ai propri servizi è una comune e sistematica pratica effettuata anche dalle software house che creano EDP gestionali (Electronic Data Processing) e che tendono a non dare la possibilità di esportare facilmente i dati per poterli altrettanto facilmente reimportare da un altro applicativo, ma in questi casi in realtà il problema è più raggirabile di quanto lo sia con il sistema operativo, anche se molto costoso in quanto ci si deve comunque appoggiare a informatici esperti. Questo vale per le piccole e medie aziende che utilizzano programmi relativamente complessi che comunque operano all'interno dell'attività aziendale o al massimo si collegano in rete con qualche piccola filiale ma sempre per uso operativo interno. Il livello di dipendenza dai sistemi informatici delle grandi aziende che si interfacciano anche a livello mediatico con app alle utenze è invece molto più problematico perché, oltre ad avere numerosissime vulnerabilità in più, sono sistemi intrinsechi che vengono fatti su misura da software house che, a loro volta, diventano conseguentemente strettamente vitali per il funzionamento del sistema e pertanto ne approfittano per farsi pagare molto bene. Si arriva così al paradosso che se salta il sistema informatico le aziende vincolatevi possono arrivare addirittura ad essere obbligate alla chiusura per il tempo necessario a risolvere il problema a livello locale o di ampie zone territoriali, nel caso McDonald's è avvento addirittura a livello multi-nazionale.

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

Ce l'abbiamo fatta! Ripristino di Nuvolaris dot dev effettuato con successo. Ed ecco a voi il post-mortem. Ieri sera ci vengono notificati problemi su Nuvolaris dev, ma siccome quello è un ambiente dev non è presidiato 24h (e lo abbiamo detto sempre a tutti) ci siamo accorti del problema solo stamattina. Io e il CTO di Nuvolaris, Francesco Timperi Tiberi, ci siamo messi a investigare sul problema, perché è importante capire cosa è successo per prevenirlo in futuro. Notiamo problemi non ben identificati su Couchdb che ha il log pieno di errori strani. Restartiamo il couchdb, e abbiamo problemi al reattach del volume, che risolviamo rimuovendo la volumeassociation. Ma purtroppo anche se riparte il database, tutto rimane surgelato, e sembra anche che gli ultimi backup non siano andato a buon fine. Allora tentiamo di salvare i dati del db a mano, e nel farlo ci accorgiamo che non si riescono proprio a leggere i file... A quel punto andiamo a controllare lo stato di Ceph e lo troviamo in errore! Ma sopratutto notiamo che... 298 su 300G sono occupati. La cosa ci sembra stranissima perchè invece il volume di couchdb (che monitoriamo) riporta il 34% libero. Allora ho l'intuizione e vado a controllare il totale del volumi e scropro che tutti i volumi allocati sono 480GB ma su Ceph sono disponibili solo 300GB!!! Ecco il nostro grande errore, abbiamo sovradimensionato i volumi, con Ceph che non ne aveva abbastanza. La soluzione era quindi di aggiungere spazio a Ceph, che per fortuna si può fare. Solo che finora non lo avevamo mai fatto... il dramma di avere un sistema stabile è che gli errori capitano raramente, e quando capitano... E per fortuna era stato lasciato il 30% di spazio sui server fisici, anche questo per evenienze si dovesse ampliare.... Seguiamo tutte le best practices (facciamo sistemi da 25 anni, ragazzi...) Mi impegno a trovare la soluzione visto che di Ceph mi sono occupato io. La maggior parte del tempo la ho spesa cercando di capire come aggiungere volumi. La grana più grossa era che rook sembrava non vederli i volumi aggiuntivi. Ci ho sbattuto la testa per un po'. Grazie all'aiuto di Mirko Danzi che si occupa del supporto capiamo che i dischi aggiunti devono essere raw e non qcow2 (ma strano perchè quelli iniziali SONO qcow2) e sistemato questo dettaglio finalmente Rook li vede e li aggancia al resto e ripartiziona il disco e lo spazio disponibile raddoppia. Verificata la procedura in ambiente di test (non vado ad operare, a cuore aperto, in produzione, una cosa mai fatta) passiamo alla fix in produzione. Faccio l'operazione di ripristino con Franz e Mirko che guardano che faccio (non si va mai ad operare in produzione senza un triplo check!!!), prima scrivo i comandi, loro controllano e poi li eseguo... Creiamo e aggiungiamo i dischi, e in 5 minuti e... il sistema riprende a funzionare! Nessuna perdita di dati anche stavolta e sistema di nuovo operativo. E anche se faccio il gradasso, mi è preso un mezzo infarto.