Bene e benvenuti su Geekbar, nuova settimana e nuovo episodio dovremmo essere attorno al 110, 111 episodio quindi di strada ne abbiamo fatta con me ho Luca, ciao Luca! Ciao Mauro, ciao pretepo, ciao a tutti come va Luca? Bene, benissimo ti vedo bello carico Sì sì sono carichissimo, sono al quinto caffè penso nell'ultima mezz'ora, però appunto sarà per quello Oggi parliamo di una cosa molto particolare Diciamo che è una roba che mi confonde ancora, nel senso che non so se essere un estimatore di quelli più spinti o Andarci contro.Parliamo di no code.Tu Che feel hai con questo concetto Luca? Ma io sono qui proprio per questo, per capire cosa devo capire, per capire cosa devo pensare del del lock code, ho sentimenti contrastanti a secondo dall'angolazione in cui guardo quindi sono qui per questo, sono carico anche per questo e non vedo l'ora di parlarne o per lo più ascoltare quello che c'è da dire Benvenuti su GITBAR, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.Allora noi per chiarirci le idee abbiamo un super ospite oggi.è già stato nostro ospite in qualche puntata fa, nella puntata 75 è una persona che utilizza il no code nella sua impresa praticamente tutti i giorni ed è felice di farlo, ne abbiamo parlato a suo tempo e oggi ritorna con noi Luca Marchesotti ciao Luca, com'è? Ciao a tutti, benissimo, grazie per avermi invitato Mauro, è sempre un piacere No, ebbè, ce lo siamo lasciati detto l'ultimo episodio che abbiamo registrato insieme.È un argomento troppo interessante, dobbiamo riberci una birra insieme per riparlarne.Anche se credo che oggi mi verrà difficile, visto che vi chiamate entrambi Luca, devo trovare una soluzione per non confondermi.Scherzo.Ci siamo...chi è Luca per chi se lo fosse perso? intanto vi suggerisco di andare a recuperare la puntata 75 dove abbiamo parlato di machine learning.Luca è un ex ricercatore all'Oxerox Research Center Europe, oggi ha una società che si occupa di machine learning, MLOps, ma è anche un appassionato di no code, giusto Luca? Assolutamente sì, ho iniziato quasi un decennio fa e quindi è una passione che ho maturato col tempo e adesso è pervasiva, nel senso che una volta che inizi poi non smetti più E allora, guarda, mi hai subito stimolato la prima domanda Tornando indietro di dieci anni com'era il mondo no code? Qual era il feeling? Quali erano gli strumenti? In realtà c'erano un paio di società, io ne ho conosciuta una dall'inizio, il nome è Zapier, con la pronuncia italiana, e diciamo che ce n'erano veramente pochi di strumenti molto grezzi.Detto questo, il concetto era già affascinante all'epoca, avere la possibilità di prendere informazione, girarla, farla girare in diversi tool.Io sono sempre stato dell'idea che è molto meglio un approccio di tipo marketplace, un approccio di tipo distribuito, nel senso non mi piace utilizzare un solo tool per fare tutto, ancorché è semplice.Infatti, non nella mia società sono responsabile della parte tecnica, ma i miei ingegneri mi chiamano anche "chief complication officer", nel senso che dicono "tu sei la persona che si occupa di creare complessità nella nostra società".Però, appunto, nel senso il discorso è multifaceted, voglio dire, se tu hai un approccio monolitico e dici "io sono una società Salesforce e e quindi uso Salesforce per tutto, per il marketing, per il sales, per il machine learning, per l'analytics eccetera, e ho delle limitazioni e delle complicazioni, questo è sicuro.Se invece vai con l'approccio totalmente redistribuito, cioè per il breast of breed di ogni settore, quindi hai HubSpot da una parte, poi hai Salesforce dall'altra, poi hai Google Data Studio eccetera, non hai alternative, devi avere un approccio no code.ok questi sono i due estremi io ricordo un po' di anni fa si parlava di API, di mercato dell'API di mashup applications possiamo immaginare la Procional Code come l'industrializzazione di questo mercato o la consumerizzazione di questo tipo di mercato Assolutamente sì, perché nel momento in cui tu hai un approccio totalmente distribuito dove il dato viene provveduto con degli API ovviamente questi API in ingresso e in uscita devono essere collegati in un qualche modo.Tutte queste piattaforme no code, e ne citerò tre, quindi Zapier, Tray.io, Automate.io ma poi ce ne sono anche altre e non fanno altro che collegare come se fosse un acquedotto tutti questi diversi, di questi sorgenti di dati e li colleghiamo in ingresso o in uscita.Quindi possiamo immaginare come un sostituto per quello che dovrebbe essere il nostro glue code che credo che sia una delle cose più pallose da scrivere immagino? Assolutamente, perché tutte queste società, quindi Zepier 3 e Automate, hanno fatto il lavoro sporco per noi, nel senso che hanno tutte queste interfacce, questo tipo di plugin che vanno a prendere dati da Google Sheet, Google Data Studio, Salesforce eccetera, e non solo connettono tra di loro le diverse applicazioni e gestiscono i formati dei dati, ma ti gestiscono anche il discorso dell'autorizzazione, quindi tu non hai altro da fare che giocare con i moduletti e non hai bisogno ovviamente di scrivere neanche una riga di codice, che è un po' la promessa del no code.Fin dall'inizio, fin dal 2013, 2012 quando ho incominciato, era la promessa iniziale.Per me in realtà il driver era diverso, però come dire, al pubblico veniva rivenduti in questo modo? Sì, devo dire che secondo me è anche una fiammella di marketing, quella "non scriverai più nessun tipo di codice" perché poi alla fine rischi di trovarti in delle situazioni un po' edgy dove comunque un po' di codice lo devi scrivere.Però senza dubbio automatizzare quel tipo di operazioni e connessioni a strumenti facciamo ripetutamente può essere utile.Dall'altra parte però ne abbiamo una sorta di dipendenza dai tool che utilizziamo e adesso la butto dura in modo da da da da perché è un problema che va affrontato.io tornando indietro col un paio d'anni fa mi viene in mente il caso non so se ve lo ricordate pars si parlava di back end as a service e pars da un giorno all'altro ha chiuso i suoi servizi vero è che ha rilasciato open source la la la la la sua struttura tutta la sua infrastruttura e tool però comunque ha chiuso questo vuol dire che alcune aziende che hanno basato tutto il loro business su quello strumento si sono ritrovate passatemi il termine col culo per terra e Pars dal canto suo ha avuto l'accortezza di rilasciare tutto open source è un po' attamponato il problema però alla fine tutti i vantaggi che quelle applicazioni, quelle società ne hanno avuto sono stati a tempo e poi li hanno pagati tutti insieme dopo.Quello che ti chiedo è nel momento in cui tu utilizzi questi strumenti ti senti anche di utilizzarli in parti business critical e se sì esistono dal tuo canto degli accorgimenti per diciamo un po passami il termine per quanto grezzo possa essere pararti il culo nella situazione peggiore nel worst case scenario no? Allora per rispondere alle tue domande noi le utilizziamo già in diciamo ambiti core della nostra società, poi facciamo machine learning, quindi voglio dire, giochiamo e lavoriamo con dati tutto il giorno, è il nostro mestiere, quindi già quel discorso lì è gestito da una piattaforma no code.Ci sono tre cose che puoi fare per, come dire, pararti il di dietro per determinate situazioni e queste tre cose sono documentazione, documentazione, Spiego meglio.Supponiamo che io, noi attualmente utilizziamo due piattaforme no code, che sono Automate.io e Zapier, e abbiamo penso 70-80 automazioni in totale, ok? Quindi se per esempio se Zapier dall'oggi al domani smette di fare business, noi in teoria, a noi non funziona più niente perché abbiamo il CRM, abbiamo la piattaforma di marketing, abbiamo le nostre Machine Learning API, abbiamo le Lambda, sono tutte connesse tramite Zapier a Notion che è il nostro Knowledge Base e il nostro sistema operativo.Non lo state vedendo ma sto facendo tanti cuori per Notion.Esatto, allora il problema qual è? Il problema è che nei momenti in cui questi due sistemi operativi, perché per noi ormai in Zepier è un sistema operativo.Se dovessero smettere di funzionare dovremmo cercare un altro, dall'oggio al domani.Il problema è replicare tutta quell'architettura di Zepier altrove.Per quello che io vi dico che da metà dell'anno scorso noi abbiamo investito tempo e denaro in una documentazione veramente capillare.Cioè noi abbiamo adesso delle dashboard che sostanzialmente ci dicono quali sono le automazioni che funzionano, quelle che non funzionano.Ho una persona che si occupa di gestire solo questo, quindi gli arrivano le allerte, che gestisce anche il tipo di documentazione associata ad ogni automazione e che se dovesse andare giù uno di questi servizi comunque non è che partiamo a zero.Noi sappiamo già l'ingresso e l'uscita, sappiamo cosa fa ogni automazione e soprattutto ho una persona che se ne occupa.Quando hai parlato di scrivere la documentazione, per questa parte, come si scrive la documentazione? Cioè hai un template, una struttura ben definita che ti aiuta, ti guida in questa direzione? Sì, ci sono due cose che noi utilizziamo.è un Lucy chart, quindi facciamo uno schema come se fosse un'architettura alla AWS e poi ogni modulo e ogni connessione è codificata e mappata dentro una dashboard che potrebbe anche essere un Google Sheet dove sostanzialmente tu dici cosa è l'ingresso, cosa è l'uscita e che cosa fa questa automazione.e poi ovviamente hai il link all'automazione Zepier o all'automazione Trade.io nel senso che nel momento in cui qualcosa non funziona la persona che fa la manutenzione deve avere la capacità di cliccare sull'automazione e capire di che cosa si tratta per fare il debug o per, come dire, metterla a posto Tu hai citato già diversi servizi, possiamo fare un walkthrough? Zeppier si occupa, come ci dicevi prima, di mettere in connessione servizi differenti, giusto? Sì, allora non fa solo questo, nel senso che puoi manipolare anche i dati, nel senso che c'è la possibilità di connettere ma c'è anche la possibilità di elaborare.Loro hanno dei servizi che ti permettono addirittura di fare del code embedding, quindi puoi mettere dentro del Python o delle lambda tue, puoi ovviamente creare dei webhook e inserire i tuoi webhook.Secondo me è più di un discorso di ingresso e uscita, c'è anche dell'elaborazione vera e propria, che è stato un po' il mio driver iniziale nel 2013, tra l'altro.Poi hai citato un altro servizio che io con la mia memoria da pesce rosso ho già dimenticato.Hai parlato di...Ho parlato di Trade.io e Automation, Automated.io.Esatto.Il primo di cosa si occupa? Allora, il Trade.io diciamo che è un...fanno più o meno tutti la stessa cosa, ma la fanno in maniera un po' diversa e con delle interfacce diverse.Alcuni sono più user friendly, come Zapier, altri sono un po' meno user friendly, come Automate.io, che tra l'altro l'hanno acquisito, quella di Notion, l'anno scorso.E la grande visione di Notion adesso è quella di inglobare Automate.io io e fare questo tipo di connessione direttamente da dentro il loro sistema.Però diciamo che sono un po' tutte equivalenti.Ci sono alcune piattaforme che fanno cose un po' più basiche, adesso ve le ritrovo, un secondo, però diciamo che queste tre fanno più o meno tutte la stessa cosa.ok questo nell'ottica di appunto creare dei processi, possiamo chiamarli dei processi, automatizzare dei processi che coinvolgono diverse sorgenti di dati, ma ti è mai capitato di trovarti nella condizione dove il processo era talmente complicato che, vabbè mi hai parlato di lambda prima quindi sicuramente ci sono stati degli edge case che lo strumento di per sé che sia SONOTION con ZAPPYR con AUTOMATE DOTAIO non era sufficiente e in quel caso l'ergonomia della estendibilità come nel senso avete fatto a cazzotti con lo strumento ci sono stati delle situazioni dove avete dovuto fare a cazzotti con lo strumento oppure è venuto tutto abbastanza fluido? Ma allora ottima domanda innanzitutto e diciamo che col no code ti scontri sempre con dei limiti e diciamo l'abilità sta nel capire quali sono quei limiti o conoscerli in anticipo e poi andare ad avere una diciamo una strategia di fallback ok? Quali sono i limiti? Per esempio, memoria, tempo.Se tu vuoi fare delle operazioni sui dati che vanno al di là di una regular expression parsing o se vuoi fare del machine learning, ovviamente tu non lo puoi fare con il codice nativo di Zapier, per nominarne uno.Ti devi scrivere una lambda, ok? E questo è un po' quello che facciamo noi sempre.nei momenti in cui non riusciamo a fare qualcosa o nei momenti in cui il tool diventa troppo lento e andiamo a farci una lambda e con i webbook connettiamo la lambda a Zapier o a Automate.io.Per un attimo voglio provare a fare questa riflessione, magari sto per dire una cavolata, insomma siete in tre perché si è aggiunto anche Carmine, ciao Carmine, ne approfitto per salutarti.Ciao a tutti, mi sono eclissato per qualche minuto per non togliere la parola ovviamente.Ciao a tutti.Voglio fare però un paio di passi indietro storicamente e voglio provare a vedere la questione da un'altra ottica.No Code non è solo, però come mi insegni Luca, Automation Ma c'è tutto un altro mondo di no code, per esempio mi viene in mente Good Barber, penso si chiami così, che permette la creazione di applicazioni, tra l'altro dovrebbe essere un team interessante che c'è da diversi anni, un team corso Ma come Good Barber sono spuntati come funghi gli strumenti per costruire dei siti web.Mi viene in mente...Koda per esempio.Koda non lo conosco però c'è...adesso non mi vengono in mente, che vergogna.Wix forse.Wix è un esempio, sì.Squarespace.Squarespace.ce n'è uno ancora più avanzato molto figo che permette anche di fare animazioni e interazione avanzata con con delle librerie ma comunque stanno emergendo e vanno a posizionare poi elementi diversi posizioni diverse nel landscape delle applicazioni che solitamente venivano sviluppati col codice mi viene in mente che ne sono un substack che adesso tra l'altro sta in qualche modo facendo il replace di quelli che erano i blog personali e i siti personali cambiando anche il paradigma però se io voglio tornare indietro a quando ho iniziato a programmare mi ricordo che c'era Dreamweaver che faceva la generazione del codice per fare i tweet crude Poi è venuto wordpress che a modo suo era un modo per fare dei siti no code perché fondamentalmente con l'installazione dei plugin Insomma risolvevi tutti i problemi però nell'evoluzione personale poi si è son passato a rails e quindi ho transato dal no code verso il code.Oggi un un dev che ritorna al no code.Come può approcciare verso il no code senza percepire una sorta di involuzione? È un ottimo spunto questo.In effetti io non ho la risposta perché in realtà io adesso non mi sono mai definito un developer perché da ex ricercatore il mio codice fa veramente pietà e poi il nostro codice di machine learning non è codice, è un'altra cosa.Per me è difficile esprimere un'opinione netta, però non lo so, io non penso che nel momento in cui fai no code stai facendo codice, forse no.È proprio un'altra attività, secondo me.la persona che da noi fa no code non è un developer, è un'altra persona.Poi ho invece i developer che mi fanno le lambda.Quindi è difficile per me pensare che un developer si metta anche, proprio come ruolo professionale secondo me ci deve essere qualcuno altro che si occupa di questa architettura no code.Difficile da definire, però adesso per esempio non so se avete visto stanno uscendo i notion experts o i notion certified, ecco ci sono anche i CODA certified experts cioè delle figure professionali che si diventano super specifiche su un prodotto su una piattaforma e ti sviluppano la soluzione.bellissimo, per un attimo ho immaginato il notion architect, no? solution architect, notion solution architect.Luca e Carmine invece da sviluppatori che prospettiva avete verso ma io infatti volevo fare anche una domanda volevo chiedere come fa a tenere a bada quegli sviluppatori che non dovrebbero intervenire nel disegno ma io sono sicuro che scalpitano nel "no questa cosa facciamola con una lambda, almeno questa per favore fammela fare" e invece dall'altra parte c'è l'architetto che dice "no usiamo questi altri due servizi che fanno la stessa cosa" oppure "no come li tieni a bada?" In realtà siamo tutti dei nerdacci quindi ci capiamo a vicenda nel senso che io comunque poi ci sono in mezzo io che non sono molto democratico, quindi si fa come dico io, quindi è molto semplice.Però alla fine delle fini, da me, sono tutti veramente molto presi, quindi queste cose di DevOps, come dire, alla fine della fiera non interessano più di tanto, cioè sono percepite come delle menate e se lo vogliono sbrigare il prima possibile, se riescono a fare via Zapier, io gli dico fallo, fallo nel modo più veloce possibile.Poi sono berati di roba da fare per i clienti, quindi non hanno alternativa, però sì, è un ottimo punto, è un dilemma quello che stai introducendo tu, Luca.No, infatti è nata dall'esperienza.Allora, Mauro aveva citato Wordpress tanti anni fa, lo utilizzo ancora ad oggi, penso anche tantissime persone, ma io quando ho approcciato Wordpress con l'illusione di dire "ah che bello, fa tutto lui, mi evito tante cose", in realtà mi serviva, non riuscivo a tenere le mani ferme perché mi serviva una cosa e piuttosto che installare o cercare un plugin già fatto me lo facevo da solo.Andavo a vedere nel core del codice perché c'era un giro che non mi tornava oppure non riuscivo a inserire quello byte che volevo nel punto giusto, allora andavo a vedere nel codice e quindi ho detto "ok, Wordpress non fa per me, non posso metterci mano".Secondo me dipende tanto da quello che devi fare, probabilmente questa è la risposta più centrista possibile che posso dare, però dipende da quello che devi fare e dipende secondo me anche dal budget che hai.Nel senso, ci sono tante soluzioni no code che sono veramente belle da utilizzare, che però anche poi hanno un costo.Con le persone con cui ho parlato e mi hanno sbanderato il no code come il futuro, eccetera, mi dicevano tutte "noi abbiamo scelto questa piattaforma qui perché nel lungo termine ci costa meno".Secondo me questa qui è una valutazione un po' sentecistica.Nel senso, se io dovessi scegliere una piattaforma no code, non la sceglierei sicuramente perché mi costa meno o almeno solo perché mi costa meno.Perché poi alla fine è una scelta abbastanza, secondo me, mio, perché dici "io voglio risparmiare sulla manodopera e vado su qualcosa di gestito".Probabilmente ti ritroverai a pagare della manodopera ancora più specializzata su quella cosa lì, insomma.Quindi secondo me è una cosa che va scelta, ma non per il prezzo.Come sviluppatore onestamente apprezzo le cose no code, quando mi fanno fare meno roba.Poi, se estendiamo il concetto di no code e ci mettiamo anche dentro quello che è low code, ci sono tanti strumenti che noi già utilizziamo oggi che fanno questa cosa qui.Nel senso, basti pensare anche a qualunque code generator di qualunque framework.Non lo chiamiamo no code, ma low code, ma sono comunque strumenti con cui siamo familiari.Ovviamente ce ne passa un abisso tra il generatore di un framework web e, non lo so, Elementor tipo.Ovviamente lì ci passa un abisso.Però secondo me effettivamente sono anche quello strumento che in certi tipi di business può fare la differenza.Se io ho la Web Agency e devo effettivamente fare dei siti vetrina, perché complicarmi la vita andare a fare con Next o con Gatsby, vi prego, con Gatsby no, insomma, o comunque con delle soluzioni diciamo più complesse quando in realtà posso farlo con WordPress o con Elementor o con qualunque altra cosa.Insomma, che tra l'altro io ho letto su qualche gruppo che qualcuno usa ancora Cold Fusion, una cosa che non sentivo da quando ero bambino e che sembrava di nuovo.Hai risvegliato un mostro.Piccola parentesi che chiudo subito.Ho visto l'altro giorno un'offerta di lavoro del New York Times e tra i requirements c'era Cold Fusion.Comunque Torniamo al nostro discorso no code.Provocazione.È assurdo.C'era un detto, no? "È meglio imparare a pescare che ricevere un pesce tutti i giorni".L'elemento di gratificazione immediata che hai col no code può essere anche un tranello.cioè il fatto che tu puoi tirare su una roba funzionante in pochi secondi può in qualche modo ingannarti e poi mostrarti il lato negativo che sono che ne so l'esplosione dei costi quando scali o ne butto sul tavolo un'altra la difficoltà di utilizzo quando hai 10-15 persone che utilizzano lo stesso tool Questo è, metti proprio il dito sulla piaga, perché è un po' la mia paura.La mia paura è che nel momento in cui abbiamo 100 developers, la maggior parte delle automazioni che abbiamo per esempio per la gestione dei timesheet non funzionano più, o comunque possono funzionare, però richiedono una manutenzione tale che non ha più senso farlo in quel modo, il timesheet.Avrebbe avuto molto più senso andare a comprare un tool che gestisce i timesheet, un toggle o qualcosa di quel tipo.Io sono molto d'accordo che dipende molto dallo use case in cui ti trovi.Quel discorso della gratificazione mi ha un po' spaventato perché io conosco molti developers e alcuni di questi developers piacciono talmente tanto fare codice che lo fanno anche quando non lo dovrebbero fare.Questo da imprenditore è una cosa che c'è una tendenza che io vedo e cerco di mitigare perché ovviamente Nel momento in cui un developer spende il suo tempo su delle attività che non sono core o su delle attività che potrebbero essere fatte in molto meno tempo, vedo proprio delle opportunità mancate, delle risorse sprecate.Quindi qui tocchiamo col no code, vedi degli aspetti legati all'individualità, legati appunto alla gratificazione del developer, legato allo use case.cioè è proprio complessa come decisione.Assolutamente sì, la cosa interessante è che comunque fondandoci l'azienda tutto diventa più complesso perché te ne assumi anche le responsabilità.Ho un'altra domanda, sempre legata a questo tipo di responsabilità.La domanda è ci sono dei momenti in cui tu tocchi il limite del tool e hai bisogno di parlare con l'assistenza utenti? Nel mondo del codice per risolvere questo problema abbiamo la documentazione, abbiamo comunque tutta una serie di storie.Abbiamo sta Cover Flow che è tanti cuori.Nel mondo invece del no code come ci si muove? Come funziona? Non ti è mai capitato di dover interagire con l'assistenza utente? Quali sono i feedback? Ci sono stati dei problemi? Allora, sì, recentemente abbiamo un'integrazione per gestire tutti i calendari o sincronizzare tutti i calendari Google, quindi Google Calendar su Notion e c'è un'applicazione fantastica che si chiama Google to Notion o Notion to Calendar si chiama, e non sincronizzava, anzi Si, sincronizzava benissimo, però sincronizzava da oggi in avanti.Se tu dovevi andare indietro più di due settimane, non lo sincronizzava.Quindi ho chiamato il developer, ho contattato il developer e questo developer veramente molto diligentemente mi ha aperto una Zoom call e dopo due giorni mi ha fatto la feature.E quindi ha deployato una feature che permette adesso di andare indietro di tre mesi.Allora questo è stato un colpo di fortuna, però io ti dico, due settimane fa ero già con un mal di testa, perché ovviamente i nostri contractor vengono pagati sulla base del time sheet che noi sincronizziamo da Google Calendar.Se queste sincronizzazioni non funzionano, questi non vengono pagati nella maniera giusta ed è un grosso problema.Quando si parla di soldi è sempre un problema.Esatto, quindi nel momento in cui io avrei solo una consiglia da dare a quelli che si approcciano al no code per automatizzare dei processi importanti.Utilizzate meno piattaforme possibili e quindi software consolidation, software consolidation, software consolidation.Qui da noi a Spark abbiamo un po' l'approccio Ryanair.mi sembra che utilizzino lo stesso modello di aerei, un Airbus 737, non vorrei sbagliarmi, e lo fanno per un motivo molto preciso.Uno, addestrare i piloti è molto più economico perché addestrano tutti sullo stesso tipo di aereo.Due, la manutenzione viene fatta con lo stesso tipo di meccanici e poi tre, anche il stoccaggio di parti eccetera, ancora una volta sono tutti uguali questi aerei, quindi in teoria viene minimizzata.Noi abbiamo un po' lo stesso approccio, utilizziamo Notion per tutto, utilizziamo Zapier e utilizziamo Automated.io, adesso lo vogliamo togliere.Quindi con tre tool ti fai più o meno tutto quello che gestisce Sales, Marketing e Product Development per noi.Quindi minimizzare il numero di tool che utilizzate dal punto di vista proprio del no code è fondamentale.E quando tu devi scegliere un servizio, quali sono le domande che ti fai? L'esamino che fai al servizio prima dell'adozione? Beh, quanto sono...diciamo, c'è o non c'è un API innanzitutto.Nel senso, se c'è un API o non c'è un API.Questo non è solo per il no code, nel senso che io comunque voglio avere accesso ai dati.Numero due, Product Hunt, come posizionato su Product Hunt, Customer Base e soprattutto lo vedi subito l'approccio, secondo me, che hanno, come si posizionano sul mercato.Se c'è un'attitudine verso dei delivery o comunque del, lo vedi dal change log, no? Quante feature deploiano, quanto ci mettono a fare nuove releases, eccetera.Ovviamente ci sono dei tool con delle release ogni 15 giorni.Quali sono i nostri preferiti? Che comunque che strano.Io mi ricordo qualche anno fa un Obama che si scriveva Code Academy perché diceva "imparare a scrivere il codice è come imparare a parlare in questa nuova era" e oggi siamo arrivati a questo.Luca potrete percepire una mia quasi repulsione verso il no code questo non è vero è solo un gioco delle parti per questo podcast e per un attimo voglio portare un'esperienza personale che non è tanto no code quanto low code perché secondo me quando si parla di business che scalano il no code arriva a un certo punto dove dimostra tutti i suoi limiti e allora a quel punto comunque mano ce la devi mettere da qualche parte e io voglio condividere con voi questa esperienza è un progetto non posso dire molto di questo progetto però vi posso dire che è un e-commerce che fattura decine di milioni di dollari l'anno.Quindi non stiamo parlando del commerce di conserve di nonna Pina, cioè è un'azienda enorme che ha basato tutto il suo business su Shopify, che è uno dei fari del no code per il mondo dell'e-commerce e che ha trovato dei limiti arrivati ad un certo punto per cui tutto il front end è stato fatto ex novo quindi è stata costruita tutto un processo di user interaction un'analisi di user interaction su questo sono state costruite delle interfacce e è stato costruito un front end e molto intelligentemente i team di Shopify hanno capito che la direzione era quella poi ci torneremo sul mondo dell'headless.Nel contempo però questo business ha avuto bisogno di altri tool che semplificassero alcuni processi specifici.Abbiamo avuto qua nel nostro podcast ospite Francesco Malatesta che ci ha parlato della sua applicazione per la gestione dei cambi prezzi dentro Shopify quindi un servizio terzo che lui ha realizzato nel marketplace di Shopify e che permette l'automazione di quel tool e noi ne usavamo un altro mi sa che si chiamasse resubscribe che si occupava delle sottoscrizioni quindi degli abbonamenti con acquisto ricorrente di prodotto e devo dire che nonostante la scala gigante tutto ha funzionato alla perfezione salvo poi però renderci conto che alcuni tool erano mantenuti da un singolo developer o da un piccolo team che quando si vedono crescere una cosa fuori da loro controllo perché entra la nuova startup che utilizza la feature Questa startup esplode e al posto di un milione di chiamate gli arrivano 100 milioni.Sto sto dicendo numeri del tutto a caso ma giusto per per capirci dove davvero c'è un moltiplicatore assurdo.E questi sono single developer piccoli team crollano sotto il peso del nuovo cliente e fuori dal loro controllo perché poi alla fine mica lo acquisiscono loro il controllo si viene tra virgolette dal marketplace della piattaforma di turno.Quindi come secondo te si può mitigare questa cosa che secondo me è uno dei veri problemi del low code? Guardate io magari Carmine e Luca possono darmi una mano a rispondere perché mi trovo veramente imbarazzo a rispondere a questa domanda.Non ho la più pallidità nel senso perché la logica rigordiologica sarebbe andare a fare un audit o un assessment tecnico di tutti i tool che vengono utilizzati dentro il processo e fare questa due diligence, tenere d'occhio gli anelli deboli della catena.Questa è la mia perspettiva, però sono interessato magari Carmine o Luca hanno una risposta un po' più intelligente.Io vedo gli stessi problemi che ce li abbiamo anche nell'icode, nelle librerie, nei programmi, nei framework, nei tool, nei sistemi operativi, insomma in tutto quello che usiamo anche noi come sviluppatori quotidianamente, in un modo o nell'altro abbiamo sempre questo problema.Certo, non ce l'abbiamo come carico, come risorse, come servizio che deve sopportare passare da mille richieste a dieci milioni, però abbiamo quel tool che è mantenuto da un ragazzo nell'Ebraska da qualche parte che è probabilmente in fin di vita, sa metterci le mani solo lui, aggiornamento del sistema operativo, questa cosa si spacca e nessuno più sa come risolvere e come fixare questo problema.Ci vedo un'analogia, non è la stessa cosa, però sono problemi che noi per quanto ci possiamo sforzare in un modo o nell'altro li buttiamo dalla porta e ci rientrano sempre dalla finestra, in diverse forme, ma sono sempre quelli.Sì, alla fine sì.Lo stesso discorso concevi tu con libri e con altri strumenti accessori.Sta nel saper scegliere lo strumento giusto per la parte del tuo business, della serie.Se scegli questo strumento per la parte del tuo prodotto più a critica, la parte fondamentale, non è un prodotto che ha una certa community, la cui azienda non è un'azienda stabile o che comunque non ha feedback che sono sufficientemente positivi, poi lì non è colpa dello strumento, nel senso alla fine lo hai scelto tu.Diciamo spesso come sviluppatori, magari questa cosa non ci diamo molto conto, perché magari, non lo so, mi sto importando questa libreria JavaScript che non ha tanta...di cui non mi fido tantissimo, però magari sono una sviluppatore JavaScript e se succede qualcosa ci so comunque mettere mano.Con il tool non ho la minima idea di come fare, però probabilmente starei molto più attento e sarei molto più diligente nella scelta rispetto magari ad una libreria che posso sempre cambiare, no? non lo so, alla fine se uno scrive il codice in una certa maniera ci sono alcune cose che diventano un dettaglio, insomma.Se scegli uno strumento no code probabilmente questa cosa non succede, insomma.E probabilmente, diciamo, è quella cosa che non fa rifare ad uno sviluppatore.Può sembrare brutto da dire, ma lo fa rifare al produttone comunque lo fare fare ad una figura che non è necessariamente tecnica, ad una figura che accore il prodotto.Sono d'accordo sul fatto di non far fare le cose agli sviluppatori.Gli sviluppatori devono solo programmare, non devono fare altre cose al di fuori di quello.Eppure a salvaguardia di questo ragionamento mi ferrebbe da pensare una cosa che è un po' antitetica a quello che Luca diceva prima.Luca correggimi se sbaglio.Prima dicevi il modo migliore per non cadere nel tranello e per rendere uso questa parola che odio ma secondo me la migliore resiliente tutta la mia infrastruttura ai servizi di terze parti è quella di trovare quei pochi servizi affidabili e su questo basare tutta la mia infrastruttura.Beh, ma a me viene da pensare e cosa succede se invece utilizzo l'approccio opposto? Quindi se mi doto di tutta una serie di servizi, per quanto tanti siano, un po' l'approccio alla NPM, la cui superficie è molto limitata alla single responsibility, fanno una sola cosa proprio per questo possono essere facilmente rimpiazzabili.Intanto è un approccio fattibile nel mondo del no code a livello pratico visto che tu ne hai avuto esperienza? Allora ottima domanda, devo fare una premessa, a me piace venire al Gitbar perché mi, come dire, vado un po' fuori dalla mia comfort zone, sapete che io non sono un developer vengo dal mondo, anzi, sono nel mondo machine learning e sono un machine learning, considerami come un machine learning engineer quindi per noi la cosa importante è che i dati non vengano persi, che i dati vengano conservati nella maniera giusta, finché c'è il dato da qualche parte poi chi se ne frega del codice, chi se ne frega del moduletto no code, l'importante è che il dato io non lo perde, che il dato sia strutturato e che sia salvato nella maniera giusta.Questa premessa, che è importante, ti dò una chiave di lettura per tutto quello che ti dico, perché io ti dico "guarda, dal mio punto di vista, nel mio use case di machine learning, il no code ci va alla perfezione".Tu mi dici "invece di avere due o tre architetture monolitiche, prendi dei micro tool che ti fanno cose e sono facilmente rimpiazzabili".Assolutamente sì.Mi piace questo tipo di approccio perché ti crei dei fallback ovvi, nel senso che magari la stessa cosa la puoi dare da fare a tre microservizi e anche se uno o due falliscono c'è il terzo.Quindi da questo punto di vista, dal punto di vista della resilienza è un approccio assolutamente positivo.Dal punto di vista della manutenzione forse un po' meno, dal punto di vista dei costi un po' meno, però come diceva prima Carmine, il driver del no code non deve essere risparmiare del denaro o non necessariamente quello, deve esserci un altro perché se no nel lungo termine non ha senso.Sì, sì, capisco assolutamente.E' comunque interessante, tutte le volte che vieni qua a Gitbar mi piace perché porti una visione da un'altra angolazione.Noi spesso, e questo Luca lo dobbiamo ammettere, siamo concentrati molto sul codice perché comunque il frutto dei nostri sforzi.Ecco, mi lasci fra una precisazione che forse per i tuoi ascoltatori è importante ascoltare e scusami se ti interrompo.Lo devi.Il codice per un developer è come dire "blood life", è vita, ok? E il codice di cui voi vi occupate è codice che deve essere di altissimo livello perché nella maggior parte dei casi è codice di produzione, quindi deve essere distillato di pura intelligenza.Il nostro codice, il codice di un machine learning engineer è roba accia, sono dei notebook Jupiter, sono degli esperimenti che noi prendiamo e una volta che ha destratto il modello buttiamo via, ed è per questo che è importante capire la differenza o l'impatto che può avere il no code sulla vita di un machine learning engineer o di un data scientist, mettiamoci anche dentro l'eta scientist versus un developer vero come siete voi.Noi facciamo codice, però non è neanche comparabile al vostro codice.Certe volte nemmeno noi commettiamo, perché sono codici intermedi, sono comunque degli scenari di sviluppo completamente diversi.Quindi quello che dico deve essere un po' preso con le pinze.Scusate, parlo troppo.Hai ragione Luca, per un attimo mi viene in mente il codice Python oscala di alcuni amici che da developer puro mi viene voglia di tirargli i capelli e loro mi dicono "sì ma sta roba deve girare una volta al mese" e ci sono io che calco run, cioè just works come disse quello.Sì, hai ragione, è bello avere questa prospettiva differente.Allora ho un'altra domanda.Visto che comunque hai anche un ruolo di gestire figure diverse, mi viene in mente la situazione dove figure diverse devono lavorare sullo stesso blocco di...sulla stessa funzionalità.pensi che gli strumenti di oggi siano all'altezza per permettere quello? io da sviluppatore penso alle code review e mi immagino una code review di un tool no code sto provando a fare uno sforzo di immaginazione, immagino non esista questo tipo però come si fa la review di una certa impostazione, configurazione no code e come si gestisce la qualità da quel punto di vista? Altra domanda molto interessante, provo a rispondere anche se noi abbiamo fatto No Code da diversi anni però non siamo ancora nella nostra comfort zone.Allora, noi abbiamo un vantaggio, siamo un team completamente distribuito, che in realtà è uno svantaggio in alcune situazioni, ma è anche un vantaggio perché ti obbliga a documentare qualunque cosa tu faccia.Attualmente noi siamo dei power user di Loom, che voi tutti immagino conosciate.è uno unicorn che fa sostanzialmente, che ti da la possibilità di registrare dei video, come dire, uno screen share e ti mette anche la webcam sovrapposta al video.Allora, noi lo utilizziamo da almeno 3-4 anni.Nell'ultimo anno questo tipo di tool si sono sviluppati tantissimo, a tal punto che adesso hanno anche sviluppato delle feature speech to text.Quindi che cosa vuol dire? Per la documentazione questo tipo di interfaccia è il tool emana dal cielo, perché supponiamo che noi vogliamo, abbiamo questa architettura no code, l'architettura no code sta girando e deve essere ampliata con un'architettura essere ampliata con delle Lambda.Le Lambda sono gestite dai Machine Learning Engineers e dai developer.Poi abbiamo questa nuova figura professionale che è il manutentore dell'architettura no code.Tutti questi si parlano con dei Loom, si parlano con dei video.Quindi c'è il no code developer o il manutentore che fa il video di manutenzione che spiega qual è il problema con la Lambda e l'altra, diciamo, il machine learning engineer che magari è a Milano, prende il loom e lo guarda, gli risponde con un altro loom e si crea una conversazione assincrona.Questo è, secondo me, il futuro di interazioni complesse, che secondo me possono risolverti il problema nel momento in cui questo no code non è documentabile su GitHub o su dove tieni il tuo codice, perché di codice proprio non ce n'è.Ho risposto? Sì, tra l'altro sono curiosissimo di vederlo lungo.Guardavo mentre parlavi una preview del tool e sembra sembra figo lo devo assolutamente provare.Quali sono i vantaggi rispetto a una comunicazione su slack che così a cent'ore ma non ho esperienza con loom quindi non ti posso dire la vedo più immediata più botta e risposta.Il vantaggio è che col video hai hai molta più informazione.Se io mi metto davanti a uno screen share e tu vedi esattamente quello che faccio, questi sono nati, questo approccio è nato per i graphic designer che operano su delle interfacce complesse come per esempio Premiere, eccetera.Cioè Premiere tu una guida non la puoi scrivere, una guida Premiere, Adobe Premiere, la puoi fare però per spiegare delle animazioni complesse, eccetera.Cioè tu devi proprio vedere uno screen share, ok? Quindi è nato da di lì.Quindi il beneficio è che, voglio dire, riesci a documentare processi complessi molto velocemente.Quindi in tre o quattro minuti, se una cosa la fai in tre o quattro minuti, fai un loom di tre minuti ed è finito.Quindi se con la tua piattaforma no code devi configurare uno Zapier lo zepi era 10 passi e devi cliccare su tutti i 10 passi con il video, lo riesci a documentare velocissimamente.Un altro vantaggio è il discorso che è assincrono, una comunicazione assincrona, nel senso che se la persona è a Vancouver e l'altro developer è a Milano, quello di Vancouver glielo fa il giorno tal dei tali e poi risponde il giorno dopo, non ci sono problemi.Oppure parli al tuo futuro, parli nel futuro, anche a te stesso.A me capita di rivedere i loom che faccio per i miei developer, però me li faccio anche per me.Lo svantaggio è che l'informazione è incapsulata e è per questo che stanno cercando di introdurre delle feature speech to text, nel senso che dentro un loom magari io documento 5 diversi zeppier, 5 diversi processi, ok? E quindi se io non ho la capacità e la voglia di scrivere esattamente quello che ci sta dentro il loom, hai voglia poi, tutta questa informazione è incapsulata, è siload dentro il video.È difficilmente cercabile, come dice Gio.È difficilmente cercabile.E' un po' il problema che abbiamo noi col podcasting, non so se vi ricordate, qualche tempo fa avevo lo speech to text attivo negli episodi, solo che AWS si zappava ai due terzi delle parole visto che il nostro podcast è un podcast tecnico mischia italiano e inglese e i tool di text to speech non sono abbastanza evoluti o perlomeno non sono trainati per il mio inglese macchironico e quindi si perdono metà delle parole però questo avrebbe dovuto rendere gli episodi ricercabili e quindi un vantaggio assolutamente importante.Luca tu ti occupi di machine learning ma quali sono le potenzialità di un'azienda che si occupa di ML e ML Ops come la tua in un'ottica di no code generale? Diciamo che noi siamo un pezzettino che può diventare molto interessante dentro un'architettura no code, nel senso che nel 2013 quando io mi sono messo dietro al no code mi ci sono messo esattamente per questo motivo, perché io volevo avere accesso privilegiato a dati sparsi ovunque e consolidarli con le mie lambda e con i miei tool di machine learning.Ovviamente se tu invece hai una struttura monolitica o se hai un accesso, come dire, non privilegiato ai dati è molto più difficile agganciarci quel pezzettino di machine learning.Il secondo motivo, e concludo, è che nel momento in cui tu hai la capacità di accedere a questi dati li puoi trasformare, ok? Li puoi trasformare col machine learning e li puoi arricchire.chiaro chiarissimo e sempre parlando in termini di dati tu adesso ti trovi a Londra giusto? io sono a Dublino in Irlanda ancora meglio vicino ancora meglio ancora meglio per la domanda che ti voglio fare hai trovato utilizzando tool diversi spesso da fornitori esteri o di altri continenti hai trovato delle difficoltà per la compliance GDPR? Allora ottima ottima domanda adesso col post brexit tutto è diventato più complicato più semplice dipende da che parte sei dell'isola e allora diciamo che dipende da che tipo di dati parliamo.Vi faccio un esempio Xero, voi sapete che cos'è? L'avete già utilizzato? No.Allora è una piattaforma, è un tool di accountancy ed è una delle piattaforme di accountancy, accountancy tool, quindi contabilità più famose al mondo, a tipo 50-60 mila aziende che fanno parte di questo, diciamo ormai è un un ecosistema.Cosa fa Xero? Prende i dati transazionali delle tue banche, dalla banca della tua società e ti crea automaticamente profit and loss, balance sheet eccetera, cioè quegli strumenti che un imprenditore deve avere sott'occhio praticamente ogni giorno.e poi con quegli strumenti vai a pagare le tasse, fai delle bolle, fai delle fatture, eccetera.Quindi è un tool fondamentale.Cosa è successo post Brexit? È successo che tutti i clienti che stavano in Europa hanno perso l'accesso all'automatic reconciliation del feed delle banche.Siamo passati da uno scenario in cui noi ogni giorno ricevavamo gli update, avevamo un P&L, quindi Profit and Loss, aggiornata, a una situazione in cui se non facevamo il download del CSV dalla banca e poi a mano andavamo a uploadarlo su zero non funzionava più niente.Come me, come la nostra società, migliaia di società all'interno dell'Europa.Le implicazioni del GDPR, le implicazioni di eventi cataclismici come il Brexit sono drammatici.Sul discorso no code io non ci voglio neanche pensare a cosa succederebbe se fossi per esempio in Russia attualmente e Zepier mi dice "guarda, adesso con tutti i server, con tutti i servizi che hanno un IP russo non ci lavoriamo più.Tranquillo anche per i coder hanno lo stesso problema visto che AWS ha sospeso i servizi nel territorio russo.E infatti come dicevo i problemi sono sempre gli stessi cambia solo il punto in cui guardi.Quindi comunque fondamentalmente abbiamo avuto conferma che le paure sono le sono le stesse.C'è anche da dire che spesso la paura ti paralizza e non vai da nessuna parte quindi è importante comunque fare degli esperimenti, misurare.E' solo a misura.Esiste un modo, sai, l'utilizzo dei software si misura facilmente.Abbiamo tutto il nostro mondo magico delle metriche belline sia in fase di realizzazione con i nostri bay barn vaun che in fase di utilizzo con le nostre dashboard graziosine e graziosette.E invece nel mondo no code visto che comunque c'è una moltiplicità di tool come si tengono sotto occhio.Ne è un po' accennato all'inizio, però come si tengono sotto occhio tutti gli strumenti? Ottima domanda.Allora, ancora una volta ci sono delle piattaforme come per esempio Zapier.Io ovviamente porto l'esempio delle piattaforme che conosco, poi altre magari sono meglio o peggio, però Zapier per esempio dà comunque già dei log che si fa pagare i cari, però che puoi esaminare e utilizzare per tirare fuori delle KPI, dei warnings, per fare un alerting system che automaticamente ti dà un quadro della situazione e ti dà anche un'idea delle performance.Io qualche tempo fa, Carmine e Luca lo sanno bene, qualche tempo fa, questa la devo dire, perché è una cosa che mi ha fatto arrabbiare tantissimo, stavamo realizzando, ci siamo impegnati anche un po' per realizzare un sistema di newsletter che partisse vedo Carmine e Luca che ridono, che partisse dal gruppo Telegram l'idea era quella poi non abbiamo avuto granché tempo per terminarlo ammetto la nostra colpa però l'idea era partire dal gruppo Telegram, raccogliere i messaggi che contenevano un link e mensilme storarli da qualche parte e mensilmente o settimanalmente attivare un sistema di newsletter che share a questi link che altrimenti sarebbero persi nei meandri dei messaggi telegram e sarebbero diventati introvabili.L'idea era fantastica però dovendola realizzare in realtà e non avendo molto tempo per farlo ci siamo un po' bloccati "eh ma il template engine si usiamo react ma lo renderizziamo server side facciamo" da sviluppatori spesso cadiamo in questa trappola fatto sta che abbiamo scritto un bel po di codice che non è stato poi alla fine finalizzato un giorno così per provare ho provato a utilizzare integro mat non so se lo conosce uno zepier della La situazione però la cosa carina di Integromat rispetto a Zapier è che aveva un'integrazione per Telegram Su Zapier non l'ho trovato E la cosa che mi ha fatto incazzare tantissimo è che in 15 minuti Utilizzando Integromat, Telegram e un servizio di newsletter che non era Substack ma qualcosa del genere no forse era substack quello che usa carola frediani vabbè alla fine in 15 minuti ho tirato su quello che ci serviva poi in realtà non l'ho testato non ho finito di testarlo quindi è ancora un mezzo aborto però funzionava o almeno faceva finta di funzionare e questa cosa mi ha fatto impazzire perché in realtà il codice che stavamo scrivendo era anche bello era anche figa l'architettura dell'applicazione che stavamo realizzando.Mi fai fare una domanda Mauro e qui adesso divento veramente come il mio terapista.Ma perché tu scrivi quel codice? Perché volevi scrivere quel codice? Condividi il tuo vero desiderio.Perché io e penso Luca e Carmine amiamo scrivere i codici.Esatto e lì andiamo veramente a mettere il dito sul problema.Perché scrivere il codice? Era quello che pensavo, sì va beh in 15 minuti l'hai fatto e funziona, ma non hai scritto codice.Che divertimento c'è.Però vedi, la cosa è particolare perché da qualche tempo io mi incazzo, e credo che sia uno dei motivi per cui comunque anche quel progetto si è bloccato, perché arrivi a un certo punto dove sei costretto a scrivere del boilerplate code.Quindi quel codice ripetuto, noioso, quello che Carmine chiama il crudino della chiesa, ne un esempio.Assolutamente, sì.Chi sviluppa Go sa bene cosa fa, però lì abbiamo un code in generate, quindi un'altra cosa.Però sì, effettivamente è la parte più noiosa, cioè ora sto cominciando un nuovo progetto mentre stiamo parlando, insomma, una roba personale e sono quattro ore che faccio boilerplate.Nel senso, è una cosa che potevo fare in no code, fortunatamente no, altrimenti l'avrei fatto con un airtable out zero tipo.Alla fine è quella cosa lì.Io credo che noi abbiamo cominciato a scrivere codice perché in quel momento lì avevamo comunque troppe idee, nel senso si volevano fare tante cose.La newsletter era la punta dell'iceberg, avevamo tutte queste idee, tutte queste cose che erano molto custom e quindi ci siamo messi a scrivere codice.Probabilmente se avessimo riflettuto di più su qual era il vero output, insomma, probabilmente saremmo andati su una soluzione del genere dall'inizio, insomma.Ecco, e secondo me è anche questa cosa qui, non puoi scegliere una soluzione no code se non hai bene in mente quello che vuoi fare, perché non hai la stessa flessibilità che hai chi ha i spin-off logic, quindi devi sforzare a capire quello che vuoi fare effettivamente per poi vedere se quella è la soluzione fitta.Insomma, ecco perché quello che dicevo prima probabilmente lo dovrebbe scegliere chi non fa codice, perché chi fa codice dice "no, questo non lo usiamo, ora ci metto 100 impronuti e lo faccio in un fail".Infatti Carmine, tu veramente descrivi il sottoscritto, nel senso che io sono quello che dice "ho bisogno di mandare 100 newsletter perché non abbiamo abbastanza leads, fammi sta newsletter immediatamente".capito? Io non mi pongo neanche il problema di farlo col codice, io ho proprio il bisogno di farlo e quindi nei momenti in cui tu hai il bisogno chiaro, hai un vantaggio e il vantaggio è che non c'è nessun beneficio ludico nel prendere una direzione nell'altra, cioè il task deve essere fatto, comunque tu lo faccia, a me non importa.Questo è chiaro, una domanda però, capita a volte invece che le esigenze si plasmano attorno agli strumenti che hai a disposizione? Perché per me la discriminante è quello, io magari sono un tipo, o comunque anche il mio capo per esempio, l'azienda dove lavoro è proprio così, noi vogliamo le cose esattamente come le abbiamo pensate, disegnate e progettate, però non c'è un tool che fa esattamente quello che abbiamo pensato, disegnato o progettato e quindi ce lo facciamo noi.Però ovviamente questo atteggiamento ha un sacco di limiti perché alla fine quello che tu hai in mente, anche se non è proprio proprio proprio così, non muore nessuno, anzi forse addirittura meglio.Però quindi immagino che invece se guardi prima i tool e poi pensi alle esigenze puoi dire "beh vabbè mi va bene, facciamo così, e va bene così" ed ovviamente è un risparmio mega galattico e sei subito sul mercato, fai subito quello che volevi o comunque parzialmente volevi e tutto funziona.Allora, chi si accontenta gode in generale.Fatta questa doverosa premessa, la cosa più semplice è quella ovviamente di usare tool third parties perché quei tool lì, le persone che hanno fatto quei tool lì si sono già risolti un sacco di problemi che tu conosci e anche un sacco di problemi che tu non conosci.Quindi voglio dire, cercare sempre di andare verso dei tool che magari non soddisfano pienamente, però soddisfano più del 50% dal mio punto di vista è un win.Anche perché poi nel momento in cui tu te lo fai in casa, non solo devi mantenere, ma lo devi anche migliorare nel tempo ed è questo uno degli elementi principali che io vedo nel no code.Perché tu con il no code sostanzialmente poi ti vai a creare un prodottino, un mini prodotto, super bespoke, super su misura.Però cosa succede? Succede che poi magari hai bisogno di nuove features o comunque tra due o tre anni ti vengono fuori dei nuovi bisogni.Questi bisogni tipicamente se tu usi un prodotto come per esempio un prodotto tipo Toggle che fa il timesheet, questi bisogni vengono soddisfatti con le nuove features perché questi qua hanno centinaia di migliaia di clienti, li stanno a sentire e poi orientano la loro prodotte veramente in quella direzione che viene chiara dal cliente.Se te lo fai in casa, come fai poi a stare dietro a questi evolving needs che ovviamente ti esploderanno? Io questo non lo so.No, io lo so bene però… Non ve lo dico perché potrebbe essere contornato di bestemmie.Esattamente.Esattamente, no vabbè quello dipende sempre dallo spirito perché poi dipende dalle soddisfazioni, dipende dall'angolazione in cui vuoi guardare il tuo prodotto, la tua azienda o il tuo output in generale.Ragazzi guardavo l'orologio siamo già un'ora e venti e devo dire che la chiacchierata è interessantissima ma dobbiamo accingerci alla chiusura.Come ogni settimana è arrivato il momento di ringraziare chi ci sostiene in questo progetto [Musica] Come ogni settimana è arrivato il momento di ringraziare chi ci sostiene in questo progetto, chi con un piccolo contributo fa sì che i costi mensili di Gitbar possano essere coperti e insomma in qualche modo possiamo non metterci di tasca perché Gitbar è un podcast gratuito ma questo non vuol dire che sia senza costi abbiamo una serie di sottoscrizioni da pagare, Spreaker Streamyard, insomma ne abbiamo diverse e le vostre donazioni ci aiutano in qualche modo a sostenere queste spese detto questo però è fatta questa premessa doverosa devo ringraziare i tre donatori di oggi ben tre e siamo super felici il primo è Angelo Fruttaldo che ci dona tre birre grazie Angelo il secondo è Riccardo Fasin che ci dona tre birre scrivendo un messaggio grazie per il vostro lavoro date spunti continui che ci permettono di diventare sviluppatori migliori oltre che aumentare la sindrome dell'impostore tranquillo la sindrome dell'impostore questo lo dico io ce l'abbiamo tutti ed è un qualcosa di fisiologico e naturale quindi alla fine bisogna semplicemente imparare a conviverci anche noi che stiamo dietro il microfono e ci suggerisce un balocco.Ve lo metto nel paese dei balocchi.È un'estensione per il browser che ha fatto Riccardo, molto carina, che si occupa di, in qualche modo, fare una sorta di enrichment di quelle che sono le feature di Stack Overflow.vi faccio un esempio il highlight the correct answer, la funzionalità che permette di evidenziare la risposta corretta con il background verde in modo da far andare direttamente l'occhio là dove serve, il copy answer link ci sono tutta una serie di funzionalità molto comode per sta cover flow e che trovate nelle note dell'episodio.Tra i donatori quindi abbiamo anche Stefano Brivio che ringraziamo per cui a questo punto alziamo i calici e brindiamo alla salute di Angelo, di Riccardo e di Stefano grazie! per cui prima di chiudere abbiamo il nostro momento il paese dei balocchi il momento in cui i nostri guest i nostri host condividono con noi un libro, un articolo, un tool in questo caso che ha catturato la loro attenzione e che in qualche modo può generare valore nella nostra community.Quindi Luca ti chiedo tu hai qualcosa da condividere con noi? E con tu con il paese dei balocchi! Ah il paese dei balocchi! Sì allora per quanto riguarda tool sicuramente loom che l'abbiamo già citato questo è un tool che assolutamente ha dei vantaggi ha dei vantaggi incredibili ha un potenziale incredibile e poi ho un articolo che è un articolo sul task management che ho letto su wired un paio di mesi fa e che è diciamo è è diventato attualissimo e che magari ti condivido e poi linki nella descrizione.Assolutamente sì.Ed è un articolo molto interessante appunto su come gestire il lavoro e su come partire dal cosiddetto "why", dal perché.Perché facciamo le cose.Perché ci piace scrivere codice.grazie luca e luca tu hai qualcosa da condividere con noi? ma sì di recente ho fatto l'abbonamento audible.com così perché avevo dei libri in inglese siccome come sapete l'ho detto anche di recente su Telegram, io l'inglese non andiamo molto d'accordo perché quando ho dovuto scegliere la seconda lingua ho scelto il francese nella mia grande lungimiranza, così adesso a 40 anni non conosco né l'inglese né il francese.L'inglese lo conosco però mi è venuta questa idea di prendermi i libri che ho in inglese, ascoltarli con Audible contemporaneamente leggendoli così evito di fare brutti errori di pronuncia tipo on premise on premise e amenità di questo tipo.Quindi niente mi sentivo di condividere questa mia intuizione.Bello bello bello tra l'altro c'è design data intensiva application dentro c'è definix project non so se hai avuto modo di vederli sono tanti cuori per Audible è uno degli abbonamenti di default ormai che non posso cancellare.Purtroppo non ci stanno pagando per questo ma se vogliono magari.Sì signora Amazon quanto meno non farci pagare le bollette di AWS.Il sogno.Carmine tu hai qualcosa per noi? Allora io vi suggerisco di provare iTable.Il table è una delle cose che fa tutto il contrario di tutto, se mi chiedi cosa fa Artitable, probabilmente qualunque cosa.È uno strumento no code per fare sostanzialmente tutto, insomma.Credo che nasca in realtà come strumento di collaborazione per team, ma in realtà non vuol dire che è una cosa tipo notion, perché non è vero, però potete farci tante cose, nel senso se avete magari da fare un prototipo o una cosa semplice o magari vi serve quella dashboard interna che non avete voglia di sviluppare probabilmente con Airtable e con l'integrazione di Airtable ce la fate insomma.Ecco diciamo sì può essere l'alternativa al file excel su Google Sheets dove ci iscrivete tutti e non capita più quello che sta succedendo.Bello bello bello Airtable tra l'altro dobbiamo dirlo che nel nostro prototipo di newsletter system il nostro storage era proprio Airtable quindi un po' di di no code c'era.In realtà siccome Notion l'hai già citato e non voglio ripetermi io ho due balocchi.Il primo è un prodotto fighissimo, il secondo è una marchettata.Non mi pagano ma è una marchettata.Allora il prodotto fighissimo è un tool che serve per fare pannelli d'amministrazione.voi lo sapete io odio scrivere codice boilerplate odio fare i pannelli d'amministrazione che usa una sola persona per la quale mi devo sbattere a fare disegnare bottoncini cose e ho risolto provando retool non so se lo conoscete è molto molto figo tra l'altro permette di iniettare del codice che ti scrivi tu in javascript è tanta roba quindi buttateci un occhio La seconda cosa sempre perché io sono pigro e non mi va di Di ripetermi quest'ultimo periodo ho dedicato parecchio tempo a studiare Super Base che è un back end as a service open source quindi se non l'avete ancora fatto Provatelo e questa è la parte non Marchetta la parte marchetta è che tra qualche giorno il codemotion terrò un talk proprio su super base quindi se vi va venitemi a trovare alla code motion conf che è online quindi diciamo non dovete fare molta strada detto questo è il momento di passare lo straccio nel nostro bancone e ringraziare Luca per esserci venuto a trovare grazie grazie davvero, grazie di cuore no grazie a voi, grazie a voi, è sempre un piacere confrontarsi e parlare con voi è sempre interessantissima la conversazione mi sono divertito tantissimo e soprattutto apprezzo come ogni volta vedere appunto il tuo punto di vista che è completamente diverso diverso dal nostro o no luca e carmine, condividete con me Sì, beh, non tanto diverso dal nostro alla fine.Appunto, cambia l'angolazione però a me è venuta voglia adesso di provare qualcosa.Infatti mi sono segnato via via tutte le cose.Cosa è successo Luca? Tu sei quello che fa tutto handmade.Eh sì, sarà che mi sono anche scocciato di farlo.Sono la persona degli eccessi.scrivere codice va bene, non scrivere codice va bene uguale, scrivere codice metà metà no, allora adesso vado al noto.L'importante è lo scopo alla fine, diciamo così.E con questa frase profonda e tipica di Carmine, quelle frasi filosofiche profonde che ti caratterizzano, ringraziamo di nuovo Luca e ci diamo appuntamento alla prossima settimana, ciao! Ciao! il gruppo telegramma ciao ciao 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 [Musica]
