Bene e benvenuti su Geekbar, nuova settimana e nuovi episodi qua nel nostro bar degli sviluppatori l'estate ormai è in stato avanzato devo dire così come ormai il mio livello di decomposizione visto il caldo, nel senso che fa un caldissimo fa veramente veramente caldo però noi continuiamo con i nostri episodi e questa settimana parliamo di un argomento che è un po' di tempo che mi interessa.Pensate me ne parlò mia moglie il primo periodo che ci conoscemmo che bell'incontro romantico parlare di questo argomento fa ridere ma è vero è uno degli argomenti di cui parliamo e quindi mi fa piacere portarlo qua.Prima di svelarvi l'argomento e quindi l'ospite di oggi il mio ruolo palloso dovrete sopportarmi e quello di ricordarvi i nostri contati info@gitbar.it via email o @brenraeppelendel su twitter ma soprattutto il nostro gruppo telegram 870 membri 870 membri tondi tondi che si incontrano tutti i giorni che ci incontriamo tutti i giorni a parlare del più e del meno oggi si parlava di code review nel gruppo che cosa credo sia una delle cose più difficili però bando alle ciance ho già anche parlato troppo sono già passati più di due minuti quindi vi svelo il nostro ospite Benvenuti su github il podcast dedicato al mondo dei full stack developer I mezzo artigiani mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo Abbiamo con noi Alberto De Lazzari o Lazzari, non lo so, sarai tu a correggermi Alberto perché io ormai è da un po' di anni che metto accenti a caso, no? Di solito gli ascoltatori lo sanno, quindi lo spelling è "Lazzari" quindi, non "Lazzari".Quante volte lo sbagliano il tuo nome? La prima volta.No, le lettere più che altro a volte, le vocali.La è al posto della...ah, da lazzare.Lo so, ti chiedo scusa, ma diciamo che tu sei qua oggi per parlarci di una tecnologia che mi ha sempre affascinato, lo dicevo prima, è stato uno degli argomenti che mia moglie ha tirato fuori il giorno che l'ho conosciuta.Però prima di parlare dell'argomento Neo4j voglio un po' parlare del tuo ruolo.Tu attualmente sei Chief Scientist a Larus giusto? Sì esatto.Di cosa vi occupate a Larus? Larus è un'azienda di consulenza, siamo specializzati nel realizzare piattaforme data-driven.L'avventura è cominciata tanti anni fa con Lorenzo Speranzoni che è il fondatore e nasce essenzialmente da persone che avevano competenze nello sviluppo di software custom e poi nel tempo ci siamo sempre più evoluti nel cercare di valorizzare il dato a tutti i livelli, dalla gestione del dato, all'analisi del dato e anche alla visualizzazione, che è una cosa che molto spesso si tralascia ma che è molto importante.Il nostro focus è stato quello di ricreare piattaforme data-driven utilizzando diverse tecnologie, principalmente tecnologie no SQL, tra cui appunto database al grafo.Lorenzo è stato proprio la prima persona a credere nella tecnologia quando effettivamente Neo4j era il primo database al grafo, era nato da poco, era una versione alla versione 1.0, quindi sì, da molto tempo fa diciamo, non troppo, non voglio farlo sembrare.Troppo, anche perché ci ascolta e lo troverai col muso lungo poi come torni in ufficio.No, è super interessante questa cosa dei database a grafo perché in realtà sono, la percezione che ne ho io poi dimmi se sbaglio sono molto potenti ma li vedo ancora non dico in un angolo ma non hanno avuto quella dozione secondo me che un po' avrebbero meditato almeno per quei casi d'uso in cui brillano no? Cosa ne pensi? Che è una dura lotta quotidiana non potete immaginare quanto sia faticoso poi cercare di parlarne, cercare di convincere le persone della loro forza.Sicuramente non è un tema semplice.Una cosa sicuramente importante è che tipicamente il graph è una struttura più complessa rispetto a quella che siamo abituati a utilizzare quindi già quello a volte è un po' uno scoglio sicuramente è meno vicino a qualcosa che può essere ad esempio un documentale come per esempio MongoDB in cui insomma il formato diciamo JSON è qualcosa che tipicamente è molto vicino agli sviluppatori, insomma la maggior parte di essi, è molto facile la struttura grafo, insomma, è un po' più...se sembra almeno all'inizio un po' più complessa, poi in realtà diciamo il mettere in relazione le cose tra di loro è una cosa che il cervello fa ogni giorno, noi uniamo i puntini ogni giorno perché quello fa effettivamente il nostro cervello, quindi la rappresentazione del grafo è molto vicina effettivamente a quella a quella umana.e anche la visualizzazione grafo è una di quelle cose che poi quando le vedi rappresentate questi pallini colorati con le gattità di loro insomma rendono molto bene però c'è diciamo uno scoglio iniziale un po' da superare sicuramente.Una certa complessità che poi tra l'altro è una se dobbiamo proiettare il concetto del database a grafo in un contesto dove c'è l'eterna lotta tra SQL, no SQL, diciamo che in realtà spogliando tutta la lotta di buzzword senza una profondità concettuale.Alla fine rimane poco spazio di marketing nel termine più alto cioè nel valore più alto del termine, per parlare di cose serie e provare ad affrontare e analizzare delle soluzioni alternative.Cosa ne dici? Quanto Neo paga la lotta tra i database SQL e NoSQL? Beh diciamo la mia opinione è che ogni database fa bene il suo lavoro e i database a grafo si focalizzano molto su una cosa ben specifica e quindi nella valutazione generale quando si va a creare una piattaforma per gestire i dati non è detto che io non possa combinare più database perché c'è una cosa che sicuramente fa bene un database a grafo è una cosa che magari fa bene un'altra tecnologia quindi la cosa migliore è combinare insieme queste tecnologie per ottenere il massimo ognuno fa il suo mestiere e insieme riescono a raggiungere lo scopo finale in maniera ottimale ovvio che questo complica la situazione quindi molto spesso uno cerca sempre di non aggiungere ulteriori tecnologie e cerca di risolvere tutto con una ce ne sono alcune che per semplicità di utilizzo o anche di modellazione dell'informazione all'interno di queste tecnologie preferisce e quindi utilizza quella e cerca sempre di dire "potrei farlo con quello che ho già" che poi alla fine è quello che si tenta di fare molto spesso ci sono però comunque alle volte delle evidenze dei limiti proprio tecnologici per il caso d'uso che devo risolvere che effettivamente diventano difficilmente risolvibili se non con una tecnologia specifica quindi il database relazionale in alcuni casi proprio non ce la fa perché non è pensato per fare quello non è stato mai pensato per far quello e magari anche un qualsiasi altra tecnologia non è pensata per fare certi tipi di operazioni sui dati quindi molto spesso quello che poi spinge le persone a utilizzare la tecnologia è "alzo bandiera bianca" ci ho provato in tutti i modi non riesco a risolvere il problema e vado sul database a grafo quindi all'inizio sono costretti poi si rendono conto che effettivamente la scelta sarebbe stata se avessero fatto prima quella giusta dall'inizio.Sai, ne parliamo sempre.Per quanto riguarda lo stack, il concetto di dire "ok, posso al primo problema che trovo adottare la soluzione specifica per quel problema", però poi i problemi diventano tanti, per cui inizia ad avere un'architettura veramente complessa che spesso è più grande della soluzione realizzata, non so se mi spiego, no? e quindi vai con One Size Fits All è un fino a a quel punto però quello che dici tu è interessante, cioè quando ti rendi conto che ci sono alcune parti della tua applicazione, del tuo sistema che ormai non ci stanno più dentro all'One Size Fits All fit all hai bisogno di adottare soluzioni specifiche solo per quelle parti di problema di elezione però no? Ti faccio l'esempio, l'esempio più semplice viene con la gestione delle code no? Se il tuo sistema è piccolo che senso ha tenere nello stesso stack redis per gestire una cache e e RabbitMQ per gestire le code.Se non hai grosse pretese fai tutto con Redis, in quel caso ottimizzi anche tutto il carico, però quando Redis non ce la fai più opti per un RabbitMQ, un po' la stessa cosa possiamo dirla per i database a grafo, cioè utilizzi il tuo data storage preferito che sia SQL o non SQL, però poi arriva un certo punto dove insomma questo grafo lo devi visitare e per farlo se le performance sono una discriminante beh a quel punto devi optare per una soluzione più specifica.Allora la mia domanda è quali sono secondo te i casi d'uso per il quale ha veramente senso utilizzare Neo4j quindi non è solo un'opzione di moda e quali invece sono i casi d'uso che hai visto dove Neo4j era utilizzato quando in realtà non serviva? Se ne hai mai visto? Allora per dare la risposta semplice, la chiamerei la regola dello stupido, tutti i casi nei quali io devo necessariamente mettere in relazione i miei dati, quindi devo cercare di capire come sono collegati o attraversare le relazioni quello è un caso d'uso in cui dovrei utilizzare un database a grafo potete trovare milioni di riferimenti nel web in cui la prima cosa che vi dicono è che un database relazionale non è effettivamente relazionale nel senso che le relazioni non sono il cittadino di prima classe come si direbbe in inglese, non sono qualcosa che è memorizzato come fanno i graph database, quindi quando io devo andare a calcolare queste relazioni, quindi far join essenzialmente, questo lo devo fare tutto in memoria e quando comincio a fare, diciamo, join di join, quindi io sto facendo salto, come se dovessi calcolare l'amico dell'amico dell'amico dell'amico, quello per me nel relazionale è mettere in join tante tante tabelle e comincia ad essere veramente pesante.Il database a grafo questo lo fa con uno schiocco di dita, quindi tutti quei casi in cui devo cominciare a utilizzare molto le relazioni tra i dati sono ovviamente casi d'uso nei quali il database a grafo sicuramente ha un vantaggio tecnologico competitivo insomma molto rilevante.non è solo quello, in realtà una forza che ha il database a grafo rispetto a tutte le altre tecnologie in osql è la base matematica, nel senso la teoria di grafi è una cosa che nasce nel 1700 e dal 1700 ad oggi di algoritmi sui grafi ne sono stati ideati e validati tantissimi, la letteratura e l'applicazione di algoritmi sui grafi ha una applicabilità veramente vasta noi li usiamo tutti i giorni, probabilmente non ce ne accorgiamo, lo sappiamo banalmente la ricerca su google è una ricerca fatta su un always graph e la ricerca è un page rank, tendenzialmente quindi è un algoritmo che calcola quanto importante è una pagina in base ai riferimenti che la pagina dà a altre pagine quello è un semplicissimo utilizzo, l'algoritmo di PageRank è stato inventato dai due fondatori di Google, lo utilizziamo ogni giorno e non sappiamo quando calcoliamo su Google Maps un percorso per andare, quello è un banalissimo cammino minimo, pesato, ma è il percorso che ci da ABI, essenzialmente da casa nostra all'ufficio, anche quello è un algoritmo, è sempre un utilizzo su un grafo, quindi c'è tutta questa parte diciamo di teoria che è molto potente, molto utile, veramente in tantissimi casi, può essere nell'analisi delle frodi, potrebbe essere anche nel qualsiasi tipo di frodi, quindi nell'ambito bancario, sicurativo può essere applicato per questo motivo.Io lo faccio spesso come esempio nelle reti, le reti possono essere autostradali piuttosto che anche banalmente quelle ferroviarie, devo determinare quali sono i punti critici, io faccio sempre l'esempio di Bologna, tutti sappiamo che insomma Bologna è un po' lo snodo tra il nord Italia e il centro sud, se noi facessimo sparire Bologna saremmo praticamente tagliati e non potremmo raggiungere o dal centro verso il nord o dal nord verso il centro perché bene o male quasi tutto passa di là.Ci sono degli algoritmi che mi dicono che effettivamente Bologna è un nodo critico, noi lo sappiamo perché è abbastanza intuitivo, insomma, è una cosa che conosciamo, però effettivamente, insomma, poi quando la rete di comunicazione, ad esempio, è molto grande, non posso andare a danneggiare io a mano, nodo per nodo, un algoritmo mi aiuta a capire quali sono questi nodi critici.Questo è utilissimo per capire effettivamente se devo fare delle analisi a priori, quindi una, diciamo, "what if" analysis, fare un'analisi degli impatti devo capire che cosa succede se c'è un fallimento in un nodo critico in una rete di comunicazioni e posso farlo con gli algoritmi quindi questi casi sono sicuramente i casi dove il database a grafo è veramente insomma il suo pane insomma ecco così.Verissimo c'è c'è uno use case che poi era quello che portò mia moglie quando ci ci conoscemmo, di cui parlo mia moglie, parlava di reti tecnologiche e faceva l'esempio dell'analisi per capire quanto una certa rete tecnologica, ma possiamo anche generalizzarla, fosse dipendente da un fornitore piuttosto che da un altro, cioè posto che i fornitori diversi per diversi segmenti di rette, tu puoi capire quanto i percorsi sono in qualche modo dipendenti da un fornitore.Questa era una cosa interessante di cui mi parlava, adesso io l'ho detta malissimo con la zappa come mio solito, ma tu mi confermi che è uno dei casi d'uso forse più nascosti? Sì sì ma sicuramente diciamo ci sono tanti algoritmi che ti permettono di capire quanto è importante un nodo.Il concetto di importanza varia da caso d'uso e da tipo di algoritmo che utilizzo però essenzialmente mi permette di capire quanto gli altri nodi sono connessi a un certo nodo.Potrebbe essere, ad esempio, che io voglio valutare se c'è qualche soggetto che collega due cellule criminali, tipo le cellule terroristiche.Magari una sta in Iran, una sta in Italia e magari c'è qualcuno che fa da tramite il collegamento tra queste due.Posso capire chi è effettivamente il nodo che collega questi due gruppi tra di loro e quindi diciamo fa da ponte, termine tipicamente ci si da.Allo stesso modo...dimmi dimmi.No, io volevo fare un passo avanti e chiederti su questa cosa.Prima hai citato la teoria dei grafi, vari algoritmi, ma quanto di questi algoritmi si deve conoscere per usare Neo? ti posso dire che l'utilizzo degli algoritmi è già un passo avanti, a volte a me lascia sempre un po' stupito l'effetto wow, quando qualcuno mette i dati connessi e già riesce ad esplorare le connessioni è un grande raggiungimento.Quindi è già quello, a volte poter esplorare i dati e vedere come tra di loro sono collegati.Ti faccio l'esempio, nel mio Graph all un cliente, il cliente è collegato ai prodotti che acquista, potrebbe essere collegato ad altre informazioni, ha una serie di entità collegate a lui, queste entità di per sé creano un contesto, è come se noi ci immaginassimo il nostro profilo Facebook, un conto è prendere il profilo per quello che è, semplicemente c'è il mio nome, il mio cognome, forse dove abito, ora non mi ricordo che informazioni pubbliche ci sono, quattro cose, se però comincio ad andare a vedere i miei amici, i like che metto sui post, le pagine che seguo e così via, quello che creo è un contesto, diciamo io lo chiamo rich contest, un contesto ricco, quindi più informazione attorno.Se voi ci pensate, se non ricordo male, Facebook soltanto andando a due o tre salti, quindi quindi seguendo le relazioni in profondità di due o tre salti, riesce a costruire attorno a voi una quantità di informazione tale che è quella che poi o vende o utilizza per targettizzare la pubblicità, contenuti e cose di questo tipo.Quindi non è che deve fare un'esplorazione enorme, crea questo contesto intorno a voi, prendendo tutto ciò che è collegato, capisce che tipo di persona siete e su quello targetizza.Quindi già questo, molte volte, è già un passo veramente importante per chi effettivamente non ha mai utilizzato la tecnologia e non ha mai messo insieme i dati connessi.Perché quello che succede molto spesso è che io sì conosco il mio patrimonio informativo, poi ovviamente con l'esperienza so come possono essere i miei dati, cosa ci può essere dentro, però non ho mai un'effettiva rappresentazione di tutti i dati connessi perché è un esercizio che non ho mai fatto e quando comincio a metterli tra di loro collegati quello che capisco è che magari certe cose che non mi aspettavo ci fossero ci sono quindi abilita anche a diciamo a porci nuove domande e quindi già questo è importante il secondo passaggio è quello che anche ti permette un po' il linguaggio di programmazione di fare quindi di creare anche magari delle regole io posso cominciare a cercare determinati pattern quindi i pattern sono nient'altro che dei percorsi più o meno lunghi che coinvolgono diversi tipi di nodi possono essere un che ne so un uno schema di riciclaggio di denaro una transazione fraudolenta, può essere un percorso alternativo di qualche tipo, se rappresentassi anche il mio patrimonio informativo potrebbe essere anche qualche regola che definisce delle dipendenze tra le componenti software che non vorrei avere, può essere un po' di tutto un pattern, insomma dipende dal caso d'uso, dal dominio che sto analizzando.Questo è un altro passo successivo molto importante e poi fatto questo passaggio posso pensare anche di cominciare a utilizzare gli algoritmi quindi la cosa importante da capire innanzitutto è che cosa voglio ottenere che tipo di analisi voglio fare questo è il principio la seconda è che tipo di algoritmo utilizzare perché poi non tutti gli algoritmi sono uguali, danno delle informazioni diverse, cercano delle cose diverse, diciamo, tra virgolette, e possono essere applicati anche su grafi con determinate caratteristiche.Alcuni funzionano bene, alcuni per certi tipi di grafo funzionano meno bene, quindi bisogna non solo conoscere il dominio sul quale sto lavorando e le domande che voglio porre o cosa voglio scoprire ma devo anche conoscere come funzionano gli algoritmi e che cosa fanno e quali sono gli eventuali limiti.Voglio farti questa domanda, io qualche test l'ho fatto ma non sono più andato molto più lontano di un Hello World o di un qualcosa similabile a quello e ho visto che il linguaggio di Quiri, che è Cypher, corregimi se sbaglio, è un linguaggio abbastanza intuitivo, semplicemente hai abbastanza indicare insomma con le specie di placeholder i nodi e tu indichi gli edge e alla fine ti tira fuori i dati.Però su Cypher ci torniamo tra un attimo, però voglio collegare a quello che mi hai appena detto cioè ci sono dei casi d'uso dove fare una classica e semplice query non basta dove hai bisogno di conoscere gli algoritmi quindi come dai in pasto gli algoritmi a Neo? Beh quello che si può fare diciamo ci sono diversi approcci il più semplice è quello di utilizzare la graph data science library che è un plugin essenzialmente che si può installare in Neo4j e quello non fa altro che mettere a disposizione delle procedure immaginatele un po' come le care vecchie store procedure in qualche modo in realtà sono delle funzioni java richiamabili dal linguaggio cypher per banalizzare quindi hai queste procedure e queste funzioni che puoi chiamare nel linguaggio e queste funzioni implementano diversi algoritmi cammino minimo, algoritmo di centralità, community detection e così via quindi quello che essenzialmente puoi fare è definire su che parte del grafo vuoi operare perché magari non necessariamente vuoi operare sull'intero grafo ma solo su una porzione e poi applica l'algoritmo e l'algoritmo ti da il risultato questo è il primo modo tipicamente consigliato l'altra possibilità è di usare anche librerie che non sono native come ad esempio Networks, una libreria python non so, sa mai, credo 10-15 anni, quindi è stra consolidata, ha sicuramente molti più algoritmi di quanti ce ne siano in Neo4j, ovviamente devi pagare lo scotto di portarti fuori l'informazione, metterla sul NetOrix, quindi creare il grafo diciamo su NetOrix e poi applicare...Sì, però comunque sei fuori dal contesto di Neo, no? Sì, lì esci, sì lì esci.Però devo dire e tu mi puoi confermare che per tantissimi casi d'uso cipher è più che sufficiente no? Sì sì sì assolutamente quello più diciamo le librerie che estendono il linguaggio con delle procedure con delle funzioni ci riesce veramente a coprire tanto.Domanda come è strutturato il linguaggio cipher? noi veniamo da un mondo dove le query si scrivono in SQL.Cosa cambia tra approccio SQL e Cypher? Non è lontanissimo dalla SQL, nel senso che molti dei costrutti del linguaggio sono simili se non uguali, banalmente le condizioni per filtrare, quindi la tipica wear è molto molto simile, deriva un po' è una combinazione di quello che è l'SQL con la ASCII art, perché rappresentare i nodi con le parentesi, il trattino per rappresentare la relazione con il maggiore o minore per dare la direzione, insomma, si sono inventati questo linguaggio.La forza del linguaggio, oltre ad essere diciamo conciso ed espressivo, perché tipicamente insomma se io dovessi fare il paragone tra la query che devo scrivere in SQL e la query che devo scrivere in Cypher, probabilmente in SQL magari la scrivo con 10 righe e in Cypher la scrivo con una riga.Il vantaggio è che tipicamente quando io esprimo la query, che essenzialmente è un pattern da cercare, io non dico al database cosa deve fare, io gli dico cosa voglio cercare.Mi spiego.Se io voglio...supponiamo di avere una rete sociale e io voglio trovare se c'è un collegamento tra meta, io potrei soltanto dire "ok parti da alberto, devi arrivare a gitbar" e quello che c'è in mezzo non mi interessa, non te lo specifico necessariamente, ti posso dire ci possono essere 5 salti, 10 salti, 20 salti, posso specificare o non specificare il tipo di relazione, quindi posso essere molto o preciso o veramente ampio nel definire che cosa mi interessa nel pattern.Dopodiché il come lo cerca su un affari del database io non me ne preoccupo, io mi preoccupo tanto del fatto che io voglio capire se siamo collegati, di come siamo poi collegati verrà fuori dal risultato e lo e non suggerisco al database di passare di qua, di mettere in "join" questo piuttosto che l'altro quello è una cosa che fa il database automaticamente questo è sicuramente un grosso vantaggio perché in una struttura complicata molto spesso, se effettivamente una cosa che insomma capita voler trovare se c'è una connessione tra due nodi è una cosa abbastanza comune e magari io non so a priori come sono collegati e quindi questo lo posso fare agevolmente senza dover impazzire.Vero, prima hai detto, no? Faccio un passo indietro.Intanto, la cosa bella di Cypher in realtà è un approccio totalmente dichiarativo, come dicevi tu, no? L'approccio a placeholder, devo dire che è veramente una figata perché tu gli dai il pattern come hai appena detto e lui ti tira fuori i risultati ma ti faccio una domanda magari sono scemo prima hai detto che in realtà in alcuni contesti può essere utilizzato per trovare dei pattern quindi finora abbiamo detto io gli do il pattern e lui mi trova le relazioni i dati cosa intendevi quando dicevi riesco a a utilizzarlo in caso di fraud detection proprio perché riesci a trovarmi questo tipo di pattern? Ho capito male io? No, quello che intendevo è, diciamo, hai due possibilità.La prima è io ho delle regole, diciamo delle regole anche definite dagli esperti, gli esperti di riciclaggio o piuttosto di dominio hanno delle regole queste regole di business le posso tradurre in soggetto trasferisce denaro dal suo conto corrente ad un altro conto corrente che poi passa ad un altro conto corrente e ritorna al conto corrente iniziale giusto per fare un esempio stupido questo lo posso definire tramite una query cipher quindi posso in questo caso il pattern lo conosco specifico e quindi dico al database "cercami tutti i pattern di questo tipo, quindi definisco una regola, un pattern, e voglio cercare tutti questi pattern, perché per me questa è una regola che definisce una possibile frode, e questo è un caso.L'altro caso è, magari voglio cercare di capire se all'interno del biografo ci sono dei soggetti, dei conti correnti, piuttosto che altre carte di credito, connesse in un modo più o meno definito.Un altro esempio potrebbe essere il classico carosello IVA, quando si vendono dei beni di servizi tra aziende di stati diversi, ma all'interno della comunità europea, dove tipicamente non si paga l'IVA e quello che fanno è io vendo qualcosa a una azienda in Francia, poi l'azienda in Francia vende a un'altra azienda in Francia, la prima azienda francese a cui ho venduto i servizi non paga l'iva e a un certo punto sparisce, quindi l'iva che era dovuta all'agenzia delle entrate francese non arriva mai e quello che cercano di fare è allungare la catena di passaggio di questi beni che potrebbero anche poi ritornare a me di nuovo.In modo da diluire l'informazione.Esatto, cercano di allontanare sempre di più, diciamo esatto, diluire un po' l'informazione in modo tale che non sia ben raggiungibile.La lunghezza della catena può essere più o meno corta, io magari non lo so a priori, quindi potrei dire "ok, devo partire da un certo nodo, so che venderà qualcosa a un nodo che sta in un altro stato, poi quello che segue può può essere lungo due salti, tre salti, non lo so, o in generale anche quando voglio trovare un collegamento in un social network tra delle persone, potrebbe essere collegato da una persona, ci potrebbero essere due passaggi, tre passaggi.Quindi mi immagino il pattern, non è preciso come quello che ho definito prima, so che potrebbe essere più o meno così e quindi quello che faccio è dire "ok, so che devo partire da qui, devo arrivare qui, nel mezzo so che più o meno c'è questo, magari non so proprio cosa c'è, dimmi tu cosa c'è, poi guardo il risultato, vedo come sono collegati e capisco se magari c'è un pattern oppure no.Chiaro.Forse non l'ho detto prima, tu vieni dal mondo della data science esistente, nel tuo caso trattate grandi moli di dati, enormi moli di dati.A livello di performance come funziona? Nel senso noi siamo prevalentemente web dev comunque molto legati al web e per noi la performance real time, nel senso che faccio la richiesta, il mio cliente fa la richiesta al backend che fa la richiesta a NEO io devo rispondere il prima possibile per avere una buona performance.In questo caso come si comporta NEO e soprattutto come scala? Allora la risposta è un po' articolata.Diciamo la prima distinzione che mi sento di fare è che non ci si può aspettare di avere le stesse performance di che ne so MongoDB piuttosto ma per il semplice fatto che il tipo di struttura che io vado a salvare dal punto di vista della consistenza è molto più complicata in MongoDB il livello di consistenza è sul documento quindi una volta che ho salvato il documento io sono a posto in un Graph Database nativo poi vi spiego perché ho detto nativo quello che io devo valutare è che sia sempre valido nodo-relazione-nodo non esiste a livello anche matematico qualcosa che sia nodo e relazione una relazione deve avere un nodo di partenza e un nodo di arrivo quindi tipicamente quando io vado a fare le operazioni di scrittura in particolare devo sempre verificare di non creare qualcosa di inconsistente che effettivamente non esiste quindi ci deve essere sempre una relazione con due nodi e questo complica un po' di più le scritture perché sto toccando più cose rispetto a quelle che tocco in altri sistemi questo lo fanno i database nativi sono quei graph database che sono stati pensati da zero per gestire questo tipo di struttura non so quanto avete sentito di tecnologia a grafo, ma se avete fatto caso, ce l'hanno tutti Microsoft ha Cosmos DB Oracle ha il suo Graph Database Data Stacks ad esempio ha il suo database creato sopra Cassandra e ce ne sono tanti ma anche Postgres se non mi sbaglio ha un'estensione a Geosocom, non mi ricordo come si chiama.Non sono tutti nati, c'è Janus Graph ad esempio ma non sono nativi e quindi sono essenzialmente database che sono nati con uno scopo e sono stati adattati a essere database a grafo quindi quello che succede è che tipicamente a livello di rappresentazione, quindi di come i dati sono salvati generalmente la struttura non è a grafo, c'è un livello di conversione che trasforma quello che tipicamente non è a grafo in quello che è a grafo in alcuni casi le soluzioni implementative sono fatte con un triple store una tabella che definisce nodi, attributi e come i nodi sono collegati dalle relazioni quindi è possibile che in alcuni graph database succeda, non attivi tipicamente, succeda che la velocità di scrittura sia molto più performante rispetto a quella di Neo4j la fregatura avviene nella lettura, nella lettura e nell'applicazione degli algoritmi perché grafi come Neo4j hanno la capacità di recuperare i nodi adiacenti in tempo costante in particolare Neo4j si basa sulla index free adjacency essenzialmente vuol dire che una volta che ho individuato un nodo andare a recuperare i vicini il costo è costante indipendentemente anche da quanti op faccio tipicamente rimane costante quindi andare a vedere i vicini, vicini, vicini è una cosa molto veloce quindi un po' pago lo scotto magari in scrittura ma poi in lettura riesco a fare cose molto più performanti il database inizialmente nasceva come un database che scalava in verticale quindi l'unica alternativa era più RAM metti più RAM più CPU e vai tranquillo è stato introdotto nell'ultima versione anche la possibilità di fare lo sharding dei dati quindi avere un ambiente distribuito dove ho una parte del grafo da una parte e una parte del grafo in un altro shard e così via lo sharding del grafo non è un tema proprio diciamo semplice da risolvere ahimè e non c'è mai la combinazione giusta nel senso che il problema poi è quando io devo andare a prendere le relazioni e i nodi si trovano su due shard diversi, lì purtroppo...esatto pensavo proprio a quello...lì si introduce una e c'è una latenza che degrada le performance quindi non è che c'è una soluzione fantastica a questo problema tipicamente quello che si può fare è cercare di capire un po' come è il nostro dominio come viene utilizzato il grafo e cercare di suddividere il grafo in modo tale che tipicamente la maggior parte delle query, delle analisi che faccio ricadono dentro uno shard e non vanno a pescare negli altri shard.Ecco secondo quali parametri posso partizionare i miei dati? Ad oggi su Neo4j la scelta è abbastanza libera nel senso che quello che tipicamente si fa è la prima è proprio creare dei database in maniera separata non c'è un concetto di partizione in maniera automatica la chiave come ci può essere magari, che ne so, in un database o chiave valore come può essere Redis o piuttosto che altro in cui magari ci sono delle oristiche predefinite che bilanciano il dato e lo distribuiscono in modo che sia poi efficiente recuperarlo nei vari shard quindi è demandato più alla tua conoscenza del dominio quindi capisci com'è il dominio, come gli utenti lo usano e poi decidi tu un po' come suddividere gli shard poi io quello che ti metto a disposizione è uno strato che ti permette poi di interrogare eventualmente gli shard insieme e riaggregarli insieme e considerarli come un unico grafo e il lavoro di separazione lo lascio a te perché la regola semplice che han deciso di intraprendere è quella di dire tu conosci il dominio quindi la suddivisione meglio che la definisci tu senza avere qualcosa di predefinito in modo tale che non si riesca a far entrare poi le query magari in un specifico shard senza dover andare a pescare le cose dagli altri.Anche perché si cambia la struttura in realtà la struttura definendola tu ed essendo duttile, malleabile perché definisci i vertici e gli archi, non so se sto usando i termini corretti, no? E quindi alla fine essendo così dinamica, così mutevole, è difficile avere una struttura di sharding o comunque degli strumenti di partizionamento efficaci se automatici questo immagino che sia uno dei motivi qualche tempo fa nell'episodio 110 e 108 abbiamo avuto due ospiti il primo era davide mauri di microsoft che ci parlava appunto di SQL server e delle versioni cloud e nel 110 era mateo sassi di mongo db una cosa che è tra l'altro divertentissima, una cosa che anche in quegli episodi si è contrapposta è il concetto di schema constraint.Come si pone Neo col concetto di definizione dello schema a priori? È un po' più vicino al relazionale, nel senso che tu puoi definire delle constraint, quindi puoi definire ad esempio se necessariamente un attributo ci deve essere dentro un nodo, banalmente, se deve essere univoco anche, quindi se tu devi modellare il tuo dominio e hai delle persone con il codice fiscale puoi mettere una constraint che verifica che il codice fiscale sia univoco per il tipo di nodo persona quindi il database in questo ti da una mano o un attributo debba sempre essere valorizzato io mi aspetto che il sesso della persona ci sia sempre quindi se non lo valorizzo mi da un errore rimane comunque la flessibilità posso farlo anche in parte sulle relazioni quindi definire delle costrezze sulle relazioni rimane comunque la flessibilità che hanno i database NoSQL quindi un nodo persona potrebbe avere 10 attributi e l'altro potrebbe avere 20 questo tipo di differenze le posso solo gestire a livello applicativo insomma se c'è necessità però diciamo almeno in generale da delle possibilità più vicine a quelle che siamo abituati a utilizzare nell'sql, nel database nazionale e quindi insomma.Ti faccio una domanda immaginiamo che io voglia fare un graph database dove ho tutti gli episodi il nodo di tipo episodio e il nodo di tipo concetto e poi andarmi a tirare tutti gli archi che collegano nodi e episodi e concetti.Nel tempo numero due io voglio creare un tipo diverso di archi per esempio ospiti con un nodo che è il nodo persona.In quel caso cosa devo fare cioè devo fare una modifica nello schema un po' come succede nei db relazionali o a me basta pushare nuovi nodi con nuovi archi e il gioco è fatto? La seconda non c'è una predefinizione dello schema ci sono graph database nativi come Tiger Graph ad esempio in cui tu definisci a priori lo schema se non ricordo male questo per una questione proprio di anche di performance per come Tiger Graph gestisce poi i dati.In Neo4j non lo devi fare, semplicemente tu pushi, quindi hai deciso che ci sarà un nodo persone, una relazione che collegherà le persone all'episodio al quale hanno partecipato, lo definisci, lo definisci da quella di scrittura e verrà aggiunto, quindi lo schema poi si aggiornerà, non c'è un qualcosa di fisso che tu definisci a priori che devi modificare.Ok, quindi in questo caso lo schema è implicito, cioè è delegato al mio livello applicativo, se sto capendo bene.Si è legato alle tue processi di importazione del dato.Chiaro.Vedo che il tempo vola, l'argomento è super interessante, però voglio farti questa domanda.Qualche volta mi è capitato di utilizzare degli strumenti per la visualizzazione, spesso utilizzati nel mondo della business intelligence, mi viene in mente Tablo, Qlik, così di questo tipo.Buona parte di questi tool hanno direttamente dei connettori verso le data source più famose.Ti è mai capitato di vedere questi tool utilizzati con Neo4j? Sì, succede.Ad oggi sono stati realizzati anche dei connettori più avanzati da Neo4j, c'è proprio un BI connector che è stato proprio pensato per collegarlo a questi strumenti.diciamo che questi strumenti tipicamente non hanno una visualizzazione a grafo, quindi non è che vedi nodi relazioni, però quello che può essere comodo è che molto spesso non necessariamente il neoforge diventa un rimpiazzo di qualcosa, ma è un affiancamento, io magari ho già qualcosa nel mio sistema che funziona in certo modo, ma ci voglio mettere vicino anche e anche un'analisi basata su dati connessi e magari quello che poi faccio dentro il grafo è tirare fuori, potrebbero essere dei cluster di utenti a cui voglio mandare delle campagne di marketing potrebbero essere degli score per definire chi è più a rischio o meno a rischio di frode tutte queste cose in questo caso magari mi basta una estrapolazione di dati e lo facciamo tabellare dal grafo perché se io voglio semplicemente vedere quali sono i top 100 soggetti più rischio e magari il rischio l'ho calcolato in un algoritmo e il valore del rischio l'ho salvato direttamente nel nodo posso estrarre tranquillamente nome della persona, identificativo, score e vederlo nel mio strumento di business intelligence che tipicamente poi magari l'utente di business quindi è inutile integrare uno strumento che nessuno magari sa utilizzare quando l'informazione che effettivamente ho non deve essere necessariamente a grafo, non deve essere un grafo dinamico che posso esplorare, ma deve essere solo magari un'informazione tabellare che comunque deriva da analisi basate sul grafo.In questo caso secondo me è più che opportuno insomma questo tipo di integrazione senza sconvolgere la vita degli utenti che sono sempre un po' arresti al cambio guarda tutte le volte che Wim mi parlava di Neo4j però citava dei casi d'uso dove praticamente Neo4j era utilizzato per l'elaborazione quindi si caricavano i dati su Neo4j o comunque si aveva un mirror, si lanciavano a query, si prendevano i risultati, si caricavano su un classico data store che poi andava a servire la parte front end o back end della situazione, il sito della situazione, l'esempio era quello degli amici che acquistano prodotti piuttosto che degli articoli più simili a quello che di solito leggi o quello che i tuoi amici o le persone che che flaghi come interessante leggono.In questo caso, dalla tua esperienza, se io dovessi sviluppare un'applicazione che scala, mi conviene davvero utilizzare questo approccio alla...mi verrebbe da chiamarlo in stile data science, con un'elaborazione batch, preparo i dati e poi servo e questa elaborazione avviene ogni x tempo oppure mi posso ancora permettere di utilizzare NEO con un connettore al mio back end per andare a servire informazioni in realtà? dipende dal tipo di elaborazione nel senso che ad esempio se tu devi fare una raccomandazione e la raccomandazione di un prodotto e la raccomandazione è semplicemente prendo tutti i prodotti che io ho acquistato, vado a vedere altre persone che hanno acquistato gli stessi prodotti e magari ti suggerisco un prodotto che tu non hai acquistato ma ha acquistato qualcun altro, probabilmente questa cosa riesci a farla in maniera abbastanza scalabile senza senza necessariamente farla a batch quindi puoi fare un servizio diretto è proprio una raccomandazione in tempo reale fatta semplicemente andando a vedere le relazioni dei tuoi prodotti e chi ha acquistato gli stessi prodotti e vedere un po' gli altri come sono diversi se devi applicare una serie di algoritmi dipende dal tipo di algoritmo soprattutto se il grafo è molto grande quindi se tu devi fare delle analisi che partono dall'insieme di nodi, esplorano le relazioni e derivi il risultato da queste puoi farlo tranquillamente in tempo reale se devi applicare degli algoritmi che sono un calcolo globale del grafo e il grafo è molto grande, è difficile farlo in tempo reale soprattutto per alcuni algoritmi, potrebbe essere in tempo, diciamo, near real time e quindi va un po' valutato caso per caso però le querie semplici le puoi servire direttamente, ci mancherebbe per farti un esempio abbiamo fatto un progetto dove nel graph rappresentiamo tutti, diciamo, le access rules, quindi le regole di accesso che un soggetto ha per determinati servizi una serie di applicazioni, ogni applicazione ha un tote di funzioni e ogni soggetto può avere una o più autorizzazioni un'abilitazione essenzialmente a una di queste funzioni anzi può addirittura avere delle abilitazioni che sono date da qualcun altro quindi io delego o incarico qualcuno a lavorare per me quando ti autentichi, vado a vedere tutte le autorizzazioni e so che tu sei abilitato alle funzioni 1 e 2 per l'applicazione A e alle funzioni 4 e 5 per l'applicazione B e lo facciamo in tempo reale, andando direttamente sul grafo facciamo un passaggio, ci calcoliamo tutte le autorizzazioni per ogni utente le parcheggiamo da qualche parte e poi me le vado a leggere.Vado direttamente sul grafo, se no non ha senso utilizzare il grafo quel punto.Diverso è se voglio valutare se una transazione fraudolenta e magari questa valutazione è determinata dal fatto che debba applicare magari un algoritmo su una porzione più o meno grande del grafo e lì devo capire quanto grande il grafo, quanto ci mette l'algoritmo.Non lo posso fare probabilmente in tempo reale quindi quando batto la carta sul POS quello probabilmente non riesco a farlo, dipende ovviamente da quello che voglio fare, però potrebbe essere qualcosa che scatta dopo dopo cinque minuti.Quindi qualcuno magari ha pagato, mi ha rubato la carta e me l'ha clonata, però magari dopo cinque minuti mi viene automaticamente bloccata perché in quei cinque minuti, quindi in real time, riesco comunque a fare l'analisi direttamente sul grafo e notificarla.Quando però i dati scalano e diventano veramente grandi, no? Guardavo oggi alcuni job Spark di Wimison, un data lake di giga e giga di roba, quindi mi immagino un grafo enorme.In quel caso ha ancora senso usare Neo? Cioè nel senso qual è l'upper bound della tua esperienza se l'hai mai vissuto di Neo? questa è una bella domanda nel senso che varia molto anche dalla potrebbe anche capitare con un grafo più piccolo ma magari la complessità di quello che cerco è molto molto importante se cerco dei pattern molto complessi potrebbero comunque metterci un po di tempo Ok, allora giriamo la domanda, proviamo a vederla così.Ti sei mai trovato nella situazione di dire "Ok, Neo4j non ce la fa più, ho bisogno di qualcos'altro" e se sì, qual è quel qualcos'altro? Allora, non mi sono trovato tipicamente in questa situazione perché, cosa succede, uno dei lavori che facciamo è quello di cercare anche di capire, una volta che io modello i dati quindi definisco qual è la struttura che rappresenta poi il mio dominio, non è detto che questa sia effettivamente poi ottimale per le domande che pongo al grafo stesso, quindi quello che facciamo facciamo creare delle relazioni che non sono definite al dominio ma che servono per velocizzare le query per semplificare le cose quindi facciamo delle operazioni di post processing che spostano il carico nella scrittura ma ci semplificano molto di più la lettura ci permettono anche di scalare molto più velocemente sicuramente una cosa che in Neo4j non c'è come può essere in TigerGraph per fare un esempio è il parallelismo TigerGraph è stato proprio pensato per essere altamente parallelizzabile quindi tutto ciò che io chiedo al grafo viene paralizzato nel più possibile essenzialmente.Neo4j per alcune cose non ha una capacità di paralizzare determinate cose che potrebbero in realtà essere paralizzate ma ad oggi non si riesce a fare se non ovviamente facendo qualcosa per chi ha la possibilità di creare delle estensioni, dei plug-in è una cosa che dovresti farti tu.Infatti quando ti facevo questa domanda avevo in mente Spark, Spark ha proprio il concetto di parallelizzare i job quando runni le map eventuali e poi unire i dati in una seconda fase.Però è interessante anche quello che dici cioè io mi creo quelli che in gergo tecnico, corregimi se sbaglio perché è un po' più il tuo ambito di business del mio, mi creo degli specchi di data mart, quindi dei dati pre processati pronti per essere elaborati in quel caso riduco anche la dimensione di quello che sto andando ad elaborare immagino.Vai vai scusami.No no, il vantaggio di utilizzare il grafo è proprio quello tale per cui io posso mantenere diciamo normalizzato quanto voglio il mio...a differenza del database relazionale ma io mi faccio il mio bel modello normalizzato fighissimo poi arrivano quelli del marketing della finanza che mi dicono a me serve questo report lanci la query 40 righe due giorni per creare il report perfetto facciamo il data mart quindi denormalizziamo e siamo a posto questo non fai questo tipo di lavoro, però quello che puoi fare è aggiungere relazioni o nodi per magari semplificare delle cose mantenendo sempre comunque la parte normale, tutto insieme quindi poi se tu vuoi vedere la parte normalizzata vai sulla parte normalizzata, se vuoi utilizzare delle relazioni o nodi di appoggio, se vuoi combinarle le cose le puoi combinare, sta tutto dentro un unico grafo e poi sta a te a decidere da che parte partire, dove andare, che cosa seguire e così via.Questa è un po' l'approccio che si può utilizzare.Molto spesso alcune cose le crei successivamente all'applicazione di algoritmi, crea una relazione nuova, una relazione di similarità tra due soggetti e quella deriva da un algoritmo che è applicato non è una cosa che è del dominio ma è una cosa che viene in fase di post processing tramite un'analisi.Quindi tu potresti lanciare un'acquiri, prendere i risultati e andare a creare degli archi che ti collegano dei nodi figli appunto di un elaborazione expensive che hai runnato.Sì sì sì.Questo è super super interessante.Sì sì, questo si fa.Però questo caso d'uso mi apre una domanda.Uno degli strumenti che trovo veramente interessanti di Postgre, magari non c'entra niente, mi dici "ma lo stai dicendo una cazzata", però una delle cose che trovo interessanti di Postgre è che esistono, io lo dirò con la zappa, abbiate pazienza, una specie di trigger che scatenano certi comportamenti o potrebbero scatenare certi comportamenti all'avvenire di qualcosa, per esempio all'inserimento di un record.Si può fare utilizzando Neo, cioè Neo ha una funzionalità out of the box o con un'estensione che ti permette per esempio nel momento in cui io creo una nuova relazione, creo il nuovo nodo Mauro, creo la relazione friendship con Alberto, a quel punto si triggera qualcosa che in background va a fare una certa query più complessa e va a creare dei nuovi archi a connessione? sì sì si può fare.Il trigger FAP è una funzionalità di Neo o devo in qualche modo pensarci io? non è una cosa che nasce direttamente nel prodotto ma sta dentro sicuramente le APOC che è un diciamo uno dei progetti collaterali di Neo4j e che diciamo quella serie di procedure che ho citato che estendono le funzionalità del grafo tra le varie funzionalità c'è quella che ti permette di definire dei trigger essenzialmente a fronte di un determinato comportamento fa qualcosa, una query tipicamente quindi ci sono questi ci sono anche quelli che possono essere dei processi che verificano a fronte di una determinata condizione fanno una query oppure se conosci abbastanza l'interno del database li puoi sviluppare per conto tuo, non è un problema, puoi creare un'estensione e fare un po' quello che vuoi, anche distruggere le cose Ascolta una domanda, Neo4j è fatto in Java vero? Sì, un po' croce un po' delizia, forse più croce che delizia però insomma...Dici? Perché? no diciamo magari rispetto a altre altre tecnologie che magari sono scritte in linguaggi tipo come C o C# o C++ insomma quello che magari quelli sono ovviamente fanno un uso di risorse più più oculato magari rispetto a quello che può essere la la java virtual machine ecco tutto lì.Eppure sai che è una domanda che mi sono fatto spesso cioè ci sono degli strumenti molti dei quali utilizzano i grafi che sono fatti in java e mi dico se una cosa deve essere particolarmente performante il passaggio java virtual machine non dico che era ma comunque un overhead, mi viene in mente gtfs triplaner che è un tool, ne parleremo probabilmente prima o poi con Carmine, è un tool che serve per calcolare fondamentalmente le strade, i percorsi e anche quelle fatte in java e quindi mi chiedo se è perché java era il linguaggio degli ultimi 15 anni diciamoci la verità almeno per le applicazioni business oriented di una certa dimensione.Sai di altri progetti simili scritti in altri linguaggi? Tiger Graph sicuramente non è scritto in java ad esempio è stato credo scritto volutamente in...adesso mi ricordo in quale C sinceramente.Tiger Graph è open source? non è open source però credo tu possa scaricarti una specie di versione community che puoi provare ok non troverai il codice da nessuna parte e infatti perché cercavo ma non ho trovato sarei curioso di vedere se esiste qualcosa di assimilabile non dico simile ma magari fatto in ching, rusting, sono curioso La più vicina a Neo4j è Memgraph che è fatto in C, credo, se non ricordo male.Quello è, credo, interamente in memoria tipicamente, lavora.Sai cosa mi stupì la prima volta che vidi Neo4j? Era l'approccio completamente diverso della dashboard d'amministrazione.Il fatto di vedere un graffo e quindi di visualizzare i dati fu scioccante per me, abituato alle tabelloze dei classici database SQL o alle esplorazioni di oggetti del MongoDB della situazione.Mi scioccò per quanto fosse eloquente quella dashboard.per quanto semplice perché poi diciamo l'info forza il browser è abbastanza minimale sicuramente in fase di prototipazione risulta comunque comunque utile validare i dati anche per fare un po dei semplici showcase.Per quanto riguarda la data visualization esistono una serie di tool che si sposano bene con Neo4j? Sì, sicuramente.Credo che il tool più famoso sia l'Incurious.Non so se avete mai sentito parlare di Paradise Papers, Panama Papers, eccetera eccetera.Lo lo strumento di visualizzazione che hanno utilizzato i giornalisti delle ICIJ è l'Incurious se voi andate sul sito di ICIJ o cercate Paradise Papers, Pano Papers credo ci sia un'istanza utilizzabile proprio di Incurious che vi permette di esplorare il dato quello è una applicazione con tutto, la collegate a Neo4j e cominciate a cercare e esplorare i dati ha una full text search bar e poi partite da uno o più nodi e esplorate, vedete, poi potete mettere colori anche quello non è open source però in questo caso non è open source, no ci sono diverse librerie di open source di visualizzazione ovviamente poi se volete realizzare un'applicazione dovete metterci un po' del vostro insomma lì avete le primitive per disegnare il grafo, per cambiare il colore dei nodi, mettere l'icona eccetera eccetera però ovviamente c'è un po' di lavoro da fare ecco e ce ne sono diverse di librerie di visualizzazione grafo Insomma se volete fare una cosa figa e non volete pagare le licenze, mettetevi a studiare D3 e altre librerie.No però è un interessante spazio, al di là del fatto che non so se voi abbiate delle partnership con questi strumenti, però al di là del fatto credo ci sia uno spazio interessante per il mondo open source.sì sì sicuramente, diciamo Cytoscape è sicuramente una di quelle librerie abbastanza sviluppata insomma funziona abbastanza bene se non esageriamo col numero di nodi e quindi quindi sì funziona funziona molto bene.Cytoscape.Ok giusto mi sto salvando i link giusto per metterli nelle notte dell'episodio.- Sì, quella insomma può essere un punto di partenza, ad esempio, oppure un'altra open abbastanza carina è...aspetta un secondo...Sigma JS.- Sigma JS.anche quella è molto carina tipicamente questa sigma.js ha già un'estensione per neo4j quindi il lavoro di collegarsi a neo4j e reperire il dato se volete fare delle prove dovrebbe essere abbastanza veloce quindi quella funziona bene mi sembrava abbastanza carino veramente veramente interessante io da nerdone schifoso stavo andando a controllare se sigma.js utilizzasse una famosa libreria per la generazione di questo tipo di chart che è D3 ma non la sto vedendo vabbè pazienza no, non credo che sia un utilizzo di 3 no? no no di solito tutti usano quella però è interessante no, ne Skype, ne Skype ne questa usano di 3 sono fatte da zero se non ricordo male è molto importante comunque la parte di visualizzazione che magari è una cosa che non non emerge non si prende in considerazione ma è veramente fondamentale soprattutto quando si vanno ad esplorare determinati casi, voglio capire che cosa succede attorno, quali possono essere le eventuali interazioni tra soggetti piuttosto che altre entità.Il come le rappresento sicuramente fa molto la differenza, quindi sì, quel tema è molto molto importante perché potrei aver fatto un mega lavoro sotto anche in fase di analisi, ma se poi rappresento il dato in una maniera terribile e poco comprensibile all'ottento finale, è praticamente come se non avessi fatto nulla, insomma, il risultato è zero.Quindi sì, è un tema veramente molto molto importante.Sul quale poi ci faremo anche un episodio, perché mi sta molto a cuore la data literacy.è un argomento spesso sottovalutato ma in realtà come dici tu molto molto importante.Ultima domanda prima di avvicinarci alla chiusura perché guardavo adesso l'orloggio io pensavo di rimanere di stare dentro un'ora e siamo già fuori.Se io volessi iniziare a usare Neo4j cosa devo fare? esistono delle stanze già hostate per il quale posso fare un abbonamento come server oppure non so come posso approcciare? ci sono delle stanze, delle sandbox essenzialmente sono praticamente delle stanze in cloud a uso gratuito hanno poche risorse però se uno vuole cominciare può anche già precaricare dei dataset se uno non ha un esempio di un caso d'uso può prenderne uno e cominciare a giocare se non ricordo male, se non lo utilizzate se vi rilogate, vi risentite altra cosa che potete fare è scaricarvi il Neo4j Desktop che è un'applicazione desktop esistono ancora con quella potete creare una vostra istanza locale per quanto riguarda il caricamento di dati, ne trovate tante anche nel sito di Neo4j nella community ci sono tante risorse su come si importano i dati ci sono vari corsi online che potete trovare sempre nel sito di Neo4j che vi dà l'introduzione all'utilizzo di cipher, alla modellazione, all'uso degli algoritmi quindi insomma vi danno una base per cominciare potete fare anche il test tanto quello è gratuito se volete certificarvi, ci sono diverse certificazioni, quello è il punto di partenza se volete capirne di più, o altrimenti mi chiedete.Sicuramente metterò i vostri contatti nelle note dell'episodio.Ho visto che ormai siamo lunghissimi quindi è il momento di chiudere, ma non ti lascio andare prima di un momento tipico e topico per i nostri episodi e qua ti colgo in fallo perché mi son dimenticato di dirtelo.Noi abbiamo un momento che si chiama il Paese dei Balocchi, che è un momento nel quale i nostri ospiti condividono con noi un tool, un libro, una conferenza, un video, un disco, non lo so, un qualunque cosa pensino sia importante e interessante per la nostra community e quindi la mia domanda è hai qualcosa da scelare con noi? Beh allora vi posso consigliare un libro che si chiama "The Formula" di Albert Barabasi, Albert Barabasi è essenzialmente un po' il padre della scienza delle reti, ha scritto un libro che si chiama "Nature Science" in cui ha messo a fattore comune tutte le varie teorie sui grafi.Il libro essenzialmente vi dice qual è la formula del successo, però con una base matematica e vi fa capire comunque quanto sono importanti le connessioni in tantissimi ambiti.Fa una panoramica anche parlando di diversi personaggi famosi, sportivi piuttosto che altro, e ne spiega perché hanno avuto successo nel determinato sport o nel determinato ambito in cui loro lavoravano, insomma si applicavano e li hanno studiati e hanno determinato che poi la teoria dei grafi aiutavano a comprendere la via del successo.Figo, figo.Diciamo che...Ha successo.Io devo arrivare anche al libro quindi adesso penso che lo metterò nelle note dell'episodio.Io in realtà non ho un balocco anche perché abbiamo appena finito di registrare un episodio poco fa e ho già usato il mio balocco in quell'episodio.L'unica cosa che posso dirvi insomma dotatevi di mojito e sotto l'ombrellone a questo punto prendete e leggete il libro di Alberto che sicuramente è super super interessante.Detto questo ormai è il momento dei saluti, io ringrazio Alberto a nome mio e tutta la community, grazie di cuore per esserci voluto ci ha voluto trovare grazie a voi per l'invito ringraziamo anche Larus che è stata gentilissima a concederti metteremo comunque i vostri link nelle note dell'episodio grazie di cuore grazie mille ciao a tutti ciao ciao alla prossima GitBar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei fullstack dev.
