Devo far vedere questo video al mio tech leader, che mi rimproverò perchè internalizzai una libreria di poco meno di 100 linee di codice per fare la decodifica del jwt, perchè così se fosse cambiato qualcosa nel modo di fare la decodifica del jwt, a noi sarebbe bastato aggiornare la dipendenza... Grazie per queste perle, il settore tech italiano ne ha bisogno
Non è un problema solo italiano, in tutto il mondo c'è questa idiozia che bisogna sempre usare una libreria di 100MB per evitare di scrivere 100 linee di codice che "poi devi manutenere". Il problema è che chi prende le decisioni non si fida delle capacità di chi sta in prima linea (e spesso a ragione purtroppo). L'unica soluzione è non lavorare per le aziende che assumono puntando alla quantità piuttosto che alla qualità
Molto stimolante come argomento. Mentalmente provo ancora un po' di resistenza al riguardo, ma senza dubbio sono incuriosito e disposto ad uscire dalla mia zona di comfort. Nel mio futuro lavoro e hobbyistica proverò ad avere un po' più di confidenza in me stesso e a dedicare più tempo e amore alle funzionalità che tendevo a rilegare a dipendenze standard implementandole di mio se la situazione permette. Time will tell qual'è la strada giusta da percorrere 🙂
Verissimo! spesso reinvento la ruota proprio per non aggiungere alle 754 librerie che mi scarica NPM nonostante abbia tutto ottimizzato. È pericoloso, me ne cambiano 5-10 al giorno.. che ne sappiamo non siano compromesse?
E questo è anche la causa delle dimensioni esagerate delle app odierne, dove una banale applicazione con delle funzionalità limitate arriva a pesare anche interi GByte. Grazie Salvatore!
Questo mi fa pensare al caso del linguaggio Odin dove il creatore ha volutamenre scelto di non implementare un package manager proprio per "forzare" ad implementarsi le cose.
Sagezza pura, mi piace un sacco sentire i ragionamenti e i consigli che dai, io sono un junior software dev e tra l'altro lavoro con python, e niente quello che dici è assolutamente vero. Le cose si fanno bene, non veloci
ricordi da Dinosauro,... 20 anni fa mi scrissi un CMS multitenant e multi purpose in ClassicASP e VBScript lato backend e HTML/CSS/JS plain lato Frontend invece di JSON si utilizzava XML come formato di scambio client / server (si utilizzavo AJAX e quindi già avevo separato Frontend e backend) . A distanza di 20 anni quando tutti passaro a WP come CMS con tutti i problemi frequenti e noti Io continua a implemtare il mio CMS. 2014 lo abbandonai definitivamente all'oblio ma ci sta un cliente che ancora lo utilizza in azienda e non accusa la necessità di abbandonarlo, tutto questo senza nel tempo aver avuto necessità di aggiornamenti legati a cambi di tecnologia, liberie o sicurezza. Torna strano anche a me come non abbia mai subito danni dovuti alla sicurezza, mai un defacement o perdita di dati le libreie sono comode ma riscrivere la ruota mi fa sentire "uno Sviluppatore" piu completo e comptente
Grazie Salvatore per questo video. Sto lavorando come contributor in un framework di agenti AI e ho riscritto il file browser interno da zero con grande soddisfazione e sinceramente anche divertendomi.
Il tuo video capita a fagiolo perché tra l'altro ora sto affrontando il problema del computer use tramite LLM, e avevo intenzione di usare PyAutoGUI, scoprendo poi che in Ubuntu 24.04 non usano più XOrg ma Wayland, e che quindi potrei facilmente trovarmi a riscrivere tutto tranne le chiamate a Windows che funzionano già molto bene.
Condivido tutto. Come non menzionare l’autore di left pad che nel 2016 ha pensato bene di buttare giù mezzo mondo. In quel caso è stato npm ad essere inaffidabile, però la libreria in questione era una semplice function che avrebbe potuto essere integrata direttamente in un progetto. Grazie per il video
bestemmio forte se conto le volte che dovevo installare un dep in js, sono andato a vedere su github la sua implementazione e mi sono accorto che erano 50 righe di codice sensato
Molto belli questi video introspettivi! Chi non ha mai affrontato questo dilemma nella propria vita da sviluppatore, inglobare una nuova dipendenza o re-implementare?
Parlo da PenTester: la (non)gestione delle dipendenze è uno dei fattori che spesso consentono di trovare falle sfruttabili in una sessione di test o attacco simulato. C'è da dire che spesso ho notato una certa disattenzione, soprattutto nei contesti web, da parte degli sviluppatori che, credo per comodità, chiamano decide di dipendenze e librerie in diverse parti dell'applicazione, anche quando queste non sembrano necessarie. Trovo molto interessante l'approccio che hai descritto, sono d'accordo su fatto che porterebbe ad una maggiore razionalizzazione del programma con una relativa riduzione della "superficie" attaccabile.
La complessità si gestisce con i layer e con la compartimentazione che si traduce nell'usare parti di codice esterni (librerie). Il problema del proliferare delle dipendenze è che ogni libreria tende a "migliorarsi" nel tempo aggiungendo caratteristiche e quindi altre dipendenze invece di restare focalizzata e stabile. Questo una volta era centrale nella filosofia dei programmi unix ("single purpose only"). Bisognerebbe promuovere di nuovo il beneficio di questo concetto.
Nel caso dello sviluppo web ci si può confrontare molto facilmente con questo problema, quando imparai a lavorare con Vue per imparare a usare il framework a volte scaricavo vecchi repository altrui e semplicemente non partivano. 😅 E con vecchi parlo di repo di due anni, tutta la catena delle dipendenze era saltata. All'epoca stavo sperimentando per la tesi di laurea e scrissi come la riduzione delle dipendenze secondo me sarà parte del futuro portando alcuni esempi per cui non potrei che essere d'accordo. Per altro lo stesso progetto della tesi che è un sito ancora visitato negli anni è sceso da 16 a 2 dipendenze.
Yes. I want to isolate the AI coding from the traditional one in this early times, especially to always know what is in the context window of the model.
Concordo. Secondo me ci sono anche altri punti da considerare: * scriversi le proprie librerie permette di avere sempre codice super specializzato per il task. Si evita quindi che nel codice siano presenti mille branch con l’intento di generalizzarne il comportamento * una libreria comunque necessita di essere integrata, quindi alla fine comunque ti troverai a scrivere glue code grande a piacere * le bestemmie e l’odio per il mondo per quando devi fixare una riga di codice, ma una dipendenza di una dipendenza ti si aggiorna e ti ritrovi 6 ore dopo a cercare di reincastrare tutti i pezzi che fino ad un ‘npm install’ prima funzionavano
Questo video lo devono vedere un pò di gente, sopratutto quelli che per anni ho bacchettato per non infilare nulla. E pensarci settimane! prima di mettere dipendenze, fatte solitamente da un tizio con gli occhiali colorati che prese 4 stelle su github evapora e diventa polvere di stelle.
Peró spesso io ho rinunciato a giocare/contribuire a progettini c/cpp perché riuscire a far la build tra makefile vari era piu complicato del progettino in se. Sono d'accordo del minimizzare le dipendenze e costruite la giusta astrazione al problema. Ma un standard lean ed efficace per compilare il binario ed eseguirlo, con pochi preamboli, é una delle cose che amo di più di cargo...
Si, é più un discorso di default sani, esperienza utente e consistenza tra progetti, che di un tool specifico... la semplicitá fatta bene é sempre cosa buona ma non é banale arrivarci
Ottimo articolo e interessantissimo, nella community js si fa sempre la battuta del "is_odd", che dipende da "is_even". P.S. Abbiamo le prove video che il raffreddore lo avevi anche prima della conferenza :P
@@Abyx12 un po’ di raffreddore, sì, ma mi ha abbracciato e baciato una persona che poi mi ha detto di essere stata con la febbre fino al giorno prima... infatti oggi sto male non da semplice raffreddore.
Alcuni linguaggi usa-e-getta sono peggio di altri da questo punto di vista. JS non ne parliamo proprio, ma pure Python non scherza. Come commentava jwz io ho ancora codice scritto in Perl che dopo 20 anni gira pari pari con l'interprete corrente. Solo che oggi se dici una cosa del genere ti guardano come un animale raro. Il problema non sono le dipendenze ma la mancanza di voglia di mantenere la coerenza della API nel tempo. In certi ambiti le cambiano orgni 3 mesi, come puro esercizio di stile. Dev che flexano e si lanciano nel vuoto.
@antirez vero, ma occorre sempre trovare un tradeoff tra velocità di sviluppo e minimalismo per le dipendenze, da quel punto di vista usate cum grano salis le AI possono effettivamente essere di molto aiuto.
Ho avuto la fortuna di crescere professionalmente sotto l'ala di un vero senior, per lui installare una nuova libreria doveva essere l'ultima delle possibilità da considerare, oltre che una sconfitta per via della manutenzione che avrebbe comportato un aggiornamento a distanza di tempo; da junior che ero facevo davvero difficoltà a capire la sua ostilità ed avversione verso questo modo di fare, crescendo ho capito il perchè e non posso che essere d'accordo con questo articolo e anche con lui.
Conosci persone come Casey Muratori, Jonathan Blow o Ginger Bill? Apprezzo molto il loro atteggiamento nel crearsi i propri strumenti e penso che Casey sia anche un ottimo insegnante
Dovrebbe esistere un equivalente dell'ELO per gli sviluppatori. Tu Salvatore, saresti un super grandmaster. Moltissimi sviluppatori invece, anche se sanno le regole, non hanno lungimiranza e la visione complessiva. Guardando solo alla mossa successiva.
@@antirez complimenti veramente, riuscire a mantenere la retrocompatibilità è una delle sfide ingegneristiche più difficili, ma anche una delle più importanti. Su un progetto grosso come Redis poi... kudos 🙇
Una cosa che mi viene in mente su due piedi, è che se hai diversi for innestati, puoi usare il goto per uscire da tutti i for in una sola botta, come se fosse un return di una funzione. Se non usi il goto e vuoi una funzionalità simile devi wrappare i for innestati in una funzione e usare return
@@davideconsalvo3563 caso interessante, ad oggi ogni qual volta mi sia capitata una situazione simile ho sempre usato il return compartimentalizzando questa cosa alla sola funzione (anche perché sfrutto molto la programmazione funzionale e quindi spezzetto quasi tutto in building blocks) però nel caso del C effettivamente ho fatto qualche ricerca ed è applicato a parti di codice “etichettate”
Hai commentato il codice? ma come non si fa 😂😂 faccelo un video sul tema ❤... Sul discorso delle lib c'è un video illuminante di Greg Yang dive lui dice che si copia il codice e poi lo fa suo, condivido appieno
ho abbondonato la programmazione perchè per me era totlamente insensata , ora porgrammo robot con software matematici dove le cose non cambiano ogni 5 minuti , la fisica per fortuna resta quella per molto tempo , l'informatica porta alla follia
ci sono parti dell’informatica moderna che sono del tutto insensate. Per difendersi bisogna avere la possibilità pratica di rinunciare a far parte di quelle che sono le pratiche comuni.
La catena di dipendenze è una piaga e si può spezzare solamente con la buona volontà. Riscrivere dei piccoli pezzi ove possibile, usare meno framework o, dove non sia possibile, usare il framework meno invasivo ed obeso. Scegliere librerie che abbiano come filosofia il "dipendenze zero". Tendere al principio KISS come regola base. E' difficile. Ma qualcuno deve pur iniziare a farlo o, almeno, a capirlo.
Premesso che ad utilizzare una libreria terza non sai mai che cazzo ti porti dietro, banalmente una scarsa architettura o una vulnerabilità (ed è successo recentemente che l'intero web è controllato NB log4j) Sono uno di quelli che evita di usare una dipendenza terza quando può scriversela da sé come meglio crede, e i vantaggi sono anche nella crescita personale nell'affrontare e imparare nuove dinamiche inveve di diventare un automa che ripete a manetta le solite cose. Noto che questa catena di dipendenza si noti soprattutto nel mondo JS (che guarda caso usa un package manager come npm), guarda React, giusto per dirne uno, e cresce ulteriormente quando installi una libreria di componenti, una libreria per il routing e una libreria pure per farti un seghino in pausa. Diventa veramente complesso trovare un'alternativa, perchè l'unica soluzione è quella di scrivere una nuova libreria / framework dependency-free. Credo che il compromesso in questi casi può avere senso?! Tu hai altre soluzioni in mente per ridurre drasticamente questo problema?
E le collisioni nelle dipendenze transitive che vengono gestite dal package manager per poi capire a runtime che c'è una specifica funzionalità che si rompe, vogliamo parlarne...
In linea di massima concordo con te ma spesso sento la mia voce interiore che inizia a dire.... e se il pezzo di codice che hai "copiato" o riscritto non cambia mai semplicemente perchè è solo tuo e quindi non è sottoposto ai 1000 occhi della libreria in cui è presente? Immagina il tuo codice per avere le informazioni sul terminale. Tu lo usi e sei contento di non doverlo cambiare mai ma potrebbe avere falle che tu non conosci. Quindi sono molto combattuto e non ho una soluzione univoca. Sicuramente non farei MAI uno sviluppo che riguarda algoritmi di crittografia su un software che, per quanto open source, potrebbe avere troppo poco seguito lasciando aperti potenziali falle di sicurezza.
Io ho la netta convinzione che codice scritto con amore, per bene, da una sola persona, sia qualitativamente migliore *in media* di quello scritto per approssimazioni successive di patch. Se una cosa non è security-critical, non mi farei problemi. Se lo è, c'è larga evidenza che anche il resto del software ha bug, e in tal caso farei un bell'audit, come magari gli altri raramente fanno.
Se copi dentro il progetto, non è diverso da fare "require". Se lo scrivi tu, non stai copiando. Se usi un LLM, prima capisci cosa c'è scritto, lo usi come prima versione.
metà del lavoro di uno sviluppatore è aggiornare le dipendenze e quando queste magicamente diventano a pagamento trovare dei sostituti. Impensabile creare una web app senza mantenerla per 1 anno. Questa cosa non ha senso, una volta creata dovrebbe durare 20 anni senza più toccarla e invece..
...daltronde si è andati verso l'idea di "semplificare"...così cala l'attenzione, così si delega tutto al gestore di pacchetti...così...così così...la gene resta scema...e pensa di essere intelligente. Ho recentemente visto un video entratomi per caso in youtube....una persona in un'aula che segue un corso di informatica...e fa vedere che usa un ai per fare un applicazione in un minuto...prende e esce dall'aula e conclude fiera dicendo "ecco il mio corso di informatica"....Signori, avremo davanti anni molto bui davanti...🧐
Non mi trovo molto d'accordo. Lo sviluppo software industriale degli ultimi anni ha avuto un'impennata di qualità anche grazie all'uso delle dipendenze. Il problema, a mio parere, è più nella pratica che non si è ancora consolidata. Non esiste una misurazione oggettiva della qualità di un pacchetto, sappiamo bene che la Big Tech spesso si appoggia su librerie OSS sviluppate da padri di famiglia che dedicano il tempo che possono. Un repository con dipendenze classificate in base alla qualità del processo di sviluppo e manutenzione sarebbe un enorme passo avanti, e lo sviluppatore potrebbe avere un ritorno economico che gli permetterebbe di concentrarsi adeguatamente sul progetto.
@@PietroBonannosemmai di quantità. Basta aprire un browser, utilizzare una delle miriadi delle “single page application” e vedere quanto sono lente. Se comunque funzionano. Tutto questo mentre l’hardware ha fatto e continua a fare passi importantissimi nell’ottimizzazione, che oramai capire bene cosa fa una CPU è diventato praticamente impossibile.
@@esadecimale credo si sia persa la mia risposta, la riscrivo. E' chiaro che, se confronti il meglio di ieri con il peggio di oggi, hai questa impressione. Ricordiamoci certe porcherie in VBScript o Flash e la prospettiva cambia. Considera poi che ormai gli standard delle UI web si sono praticamente allineati a quelli delle applicazioni desktop. La quantità e la complessità del traffico generati è diventata ingestibile per qualsiasi libreria del passato. Inoltre il numero di utenti è almeno due ordini di grandezza in più. Per fare un esempio di app web di qualità, prova Miro e dimmi se quella gestione la trovi in qualsiasi app di 15 anni fa. Mi limito al web solo perché è quello che va per la maggiore. In parte è anche merito delle dipendenze, che hanno liberato i dev dal dover verificare aggiornamenti e update, scaricare, bestemmiare e cercare subdipendenze e così via. Che poi ci sia da affinare il processo e gestire alcuni casi, non ci sono dubbi.
In linea di principio, pienamente condivisibile. Io stesso sottolineo nei miei pacchetti, crates o moduli che una cosa è “dependency-less” quando ci riesco. Ma è tutto legato a contesto, capacità dell’individuo e, soprattutto, interessi. Tu stesso hai detto “mica mi re-implemento SSL?”. Tu! Ma ci sono quelli che lo sanno e vogliono fare. In Rust, per esempio, il progetto RustTls o il progetto per re-implementare DNS Bind. Sono cose che portano dentro dipendenze (non poche) ma sono riscritture necessarie per modernizzare e anche portare i vantaggi di Rust nelle low level libraries. La verità è che bisogna saper scegliere le dipendenze. Scegliere significa guardarsi la history del codice, capire se lo sviluppatore che ci sta dietro è una persona coscienziosa, metodica, che sa gestire bene la responsabilità che si prende, o se è il tipico personaggio minchione che fa una libreria con mezza cosa utile dentro, e 600 dipendenze inutili o superflue/evitabili. Ci sono anni e anni di lavoro da fare per sviluppare questo enorme senso critico. Richiede che hai fatto l’errore prima tu, e pagatene le conseguenze, per capire il tuo discorso ed internalizzarlo. Dobbiamo permettere ai minchioni di minchioneggiare. O spendere tempo a fare mentorship. Ma non ho sempre tempo di fermare le minchiate 😂
non sono convinto che questo approccio così relativista sia equilibrato. È chiaro che ognuno in base alle proprie inclinazioni e capacità può decidere di re implementare quello che vuole, però qui si parla in questo video specifico di ingegneria del software di qualità, senza fare le cose stravaganti. in questo contesto delle linee guida sensate si possono certamente dare, e come dice il post originale il punto è evitare di inserire dipendenze per cose che sono, da riscrivere, quasi meno lavoro davvero meno lavoro di capire il codice altrui, integrarlo, e poi combattere con gli aggiornamenti. Poi ognuno, nel chiuso della propria camera di sviluppo, fa ciò che vuole. Ad esempio, io nella maggior parte dei software ho una politica di dipendenze zero. Capisco che ciò è estremo per troppi programmatori che operano in un contesto aziendale.
@ no ma sono in linea di principio d’accordo. Ma nel contesto delle aziende, uno degli aspetti è dover gestire il consenso. E non tutti sono Antirez :) Non tutti possiamo permetterci di imporre certe politiche, senza creare problemi “umani”. Per questo uno può persuadere, fare talk interni, blogpost etc. Ma poi si fanno i conti con la realtà dove bisogna trovare il giusto medio. Se uno ha il tempo e il peso politico, può decisamente spingere la politica che proponi. E a lungo termine i benefici escono fuori sicuro. Ti parlo dall’interno di un contesto dove ci sono progetti di 8/10 anni scritti per NodeJS. Ti lascio immaginare!!!
@ ne sono consapevole, purtroppo. Però sai qual è la differenza che si può fare? Quantomeno far passare che anche se poi all'atto pratico non sempre è possibile fare le cose così, non è neppure corretto normalizzare la follia delle dipendenze. Almeno va avanti il discorso culturale interno.
...come non citare tra l'altro idiozie come LESS SASS o CSS in JS....ma chi ha partorito sta roba aveva mai imparato a usare i css normalmente?...è follia...ma pensi a quello che fai?...ecco "dipendenza" è la parola giusta! ma nel senso di dipendenza come nel caso delle tossico dipendenze! 🧐
a velocità normale il video è inguardabile .... cioè proprio ti mette a dura prova e santa pazienza... solo a x1,75 diventa normale ... insomma, con questo flegmatismo io caricherei i video già editati con velocita doppia del normale.
Certi video sono molto più veloci, e in altri si parla di cose complicate in cui la lentezza aiuta un po' a digerire i concetti. Credo sia meglio lasciare all'utente la regolazione della velocità tutto sommato.
Devo far vedere questo video al mio tech leader, che mi rimproverò perchè internalizzai una libreria di poco meno di 100 linee di codice per fare la decodifica del jwt, perchè così se fosse cambiato qualcosa nel modo di fare la decodifica del jwt, a noi sarebbe bastato aggiornare la dipendenza...
Grazie per queste perle, il settore tech italiano ne ha bisogno
Non è un problema solo italiano, in tutto il mondo c'è questa idiozia che bisogna sempre usare una libreria di 100MB per evitare di scrivere 100 linee di codice che "poi devi manutenere". Il problema è che chi prende le decisioni non si fida delle capacità di chi sta in prima linea (e spesso a ragione purtroppo). L'unica soluzione è non lavorare per le aziende che assumono puntando alla quantità piuttosto che alla qualità
Thank you for recording this and sharing it to a new audience! ❤
@@ArminRonacher thanks for your post! So many sharp ideas.
Molto stimolante come argomento. Mentalmente provo ancora un po' di resistenza al riguardo, ma senza dubbio sono incuriosito e disposto ad uscire dalla mia zona di comfort. Nel mio futuro lavoro e hobbyistica proverò ad avere un po' più di confidenza in me stesso e a dedicare più tempo e amore alle funzionalità che tendevo a rilegare a dipendenze standard implementandole di mio se la situazione permette. Time will tell qual'è la strada giusta da percorrere 🙂
Verissimo! spesso reinvento la ruota proprio per non aggiungere alle 754 librerie che mi scarica NPM nonostante abbia tutto ottimizzato. È pericoloso, me ne cambiano 5-10 al giorno.. che ne sappiamo non siano compromesse?
E questo è anche la causa delle dimensioni esagerate delle app odierne, dove una banale applicazione con delle funzionalità limitate arriva a pesare anche interi GByte. Grazie Salvatore!
Questo mi fa pensare al caso del linguaggio Odin dove il creatore ha volutamenre scelto di non implementare un package manager proprio per "forzare" ad implementarsi le cose.
Sagezza pura, mi piace un sacco sentire i ragionamenti e i consigli che dai, io sono un junior software dev e tra l'altro lavoro con python, e niente quello che dici è assolutamente vero. Le cose si fanno bene, non veloci
ricordi da Dinosauro,... 20 anni fa mi scrissi un CMS multitenant e multi purpose in ClassicASP e VBScript lato backend e HTML/CSS/JS plain lato Frontend invece di JSON si utilizzava XML come formato di scambio client / server (si utilizzavo AJAX e quindi già avevo separato Frontend e backend) . A distanza di 20 anni quando tutti passaro a WP come CMS con tutti i problemi frequenti e noti Io continua a implemtare il mio CMS.
2014 lo abbandonai definitivamente all'oblio ma ci sta un cliente che ancora lo utilizza in azienda e non accusa la necessità di abbandonarlo, tutto questo senza nel tempo aver avuto necessità di aggiornamenti legati a cambi di tecnologia, liberie o sicurezza. Torna strano anche a me come non abbia mai subito danni dovuti alla sicurezza, mai un defacement o perdita di dati
le libreie sono comode ma riscrivere la ruota mi fa sentire "uno Sviluppatore" piu completo e comptente
Grazie Salvatore per questo video. Sto lavorando come contributor in un framework di agenti AI e ho riscritto il file browser interno da zero con grande soddisfazione e sinceramente anche divertendomi.
Il tuo video capita a fagiolo perché tra l'altro ora sto affrontando il problema del computer use tramite LLM, e avevo intenzione di usare PyAutoGUI, scoprendo poi che in Ubuntu 24.04 non usano più XOrg ma Wayland, e che quindi potrei facilmente trovarmi a riscrivere tutto tranne le chiamate a Windows che funzionano già molto bene.
Condivido tutto. Come non menzionare l’autore di left pad che nel 2016 ha pensato bene di buttare giù mezzo mondo. In quel caso è stato npm ad essere inaffidabile, però la libreria in questione era una semplice function che avrebbe potuto essere integrata direttamente in un progetto. Grazie per il video
Ci pensavo a leftpad... mentre registravo il video.
Questo ragionamento vale ancora di più sull'ecosistema JS. Come è pensabile mantenere in piedi una ecosistema del genere sul lungo termine?
Sorry, I don't understand Italian but I am watching the video with auto generated subtitles. Thank you for sharing the article.
bestemmio forte se conto le volte che dovevo installare un dep in js, sono andato a vedere su github la sua implementazione e mi sono accorto che erano 50 righe di codice sensato
Molto belli questi video introspettivi! Chi non ha mai affrontato questo dilemma nella propria vita da sviluppatore, inglobare una nuova dipendenza o re-implementare?
Parlo da PenTester: la (non)gestione delle dipendenze è uno dei fattori che spesso consentono di trovare falle sfruttabili in una sessione di test o attacco simulato. C'è da dire che spesso ho notato una certa disattenzione, soprattutto nei contesti web, da parte degli sviluppatori che, credo per comodità, chiamano decide di dipendenze e librerie in diverse parti dell'applicazione, anche quando queste non sembrano necessarie.
Trovo molto interessante l'approccio che hai descritto, sono d'accordo su fatto che porterebbe ad una maggiore razionalizzazione del programma con una relativa riduzione della "superficie" attaccabile.
Internalizzare.. non è più una dipendenza! Grande!
La complessità si gestisce con i layer e con la compartimentazione che si traduce nell'usare parti di codice esterni (librerie). Il problema del proliferare delle dipendenze è che ogni libreria tende a "migliorarsi" nel tempo aggiungendo caratteristiche e quindi altre dipendenze invece di restare focalizzata e stabile. Questo una volta era centrale nella filosofia dei programmi unix ("single purpose only"). Bisognerebbe promuovere di nuovo il beneficio di questo concetto.
Nel caso dello sviluppo web ci si può confrontare molto facilmente con questo problema, quando imparai a lavorare con Vue per imparare a usare il framework a volte scaricavo vecchi repository altrui e semplicemente non partivano. 😅 E con vecchi parlo di repo di due anni, tutta la catena delle dipendenze era saltata. All'epoca stavo sperimentando per la tesi di laurea e scrissi come la riduzione delle dipendenze secondo me sarà parte del futuro portando alcuni esempi per cui non potrei che essere d'accordo. Per altro lo stesso progetto della tesi che è un sito ancora visitato negli anni è sceso da 16 a 2 dipendenze.
Mr. Sanfilippo is there a reason you don't use FIM AI tools in your editor and still use the Claude web interface?
Yes. I want to isolate the AI coding from the traditional one in this early times, especially to always know what is in the context window of the model.
@@antirez Thank you
Concordo. Secondo me ci sono anche altri punti da considerare:
* scriversi le proprie librerie permette di avere sempre codice super specializzato per il task. Si evita quindi che nel codice siano presenti mille branch con l’intento di generalizzarne il comportamento
* una libreria comunque necessita di essere integrata, quindi alla fine comunque ti troverai a scrivere glue code grande a piacere
* le bestemmie e l’odio per il mondo per quando devi fixare una riga di codice, ma una dipendenza di una dipendenza ti si aggiorna e ti ritrovi 6 ore dopo a cercare di reincastrare tutti i pezzi che fino ad un ‘npm install’ prima funzionavano
Chi le testa queste librerie?
Questo video lo devono vedere un pò di gente, sopratutto quelli che per anni ho bacchettato per non infilare nulla. E pensarci settimane! prima di mettere dipendenze, fatte solitamente da un tizio con gli occhiali colorati che prese 4 stelle su github evapora e diventa polvere di stelle.
grazie
Peró spesso io ho rinunciato a giocare/contribuire a progettini c/cpp perché riuscire a far la build tra makefile vari era piu complicato del progettino in se.
Sono d'accordo del minimizzare le dipendenze e costruite la giusta astrazione al problema. Ma un standard lean ed efficace per compilare il binario ed eseguirlo, con pochi preamboli, é una delle cose che amo di più di cargo...
Be', dai. Un semplice Makefile è piuttosto semplice.
Si, é più un discorso di default sani, esperienza utente e consistenza tra progetti, che di un tool specifico...
la semplicitá fatta bene é sempre cosa buona ma non é banale arrivarci
Parole Sante.
Ottimo articolo e interessantissimo, nella community js si fa sempre la battuta del "is_odd", che dipende da "is_even".
P.S. Abbiamo le prove video che il raffreddore lo avevi anche prima della conferenza :P
@@Abyx12 un po’ di raffreddore, sì, ma mi ha abbracciato e baciato una persona che poi mi ha detto di essere stata con la febbre fino al giorno prima... infatti oggi sto male non da semplice raffreddore.
Alcuni linguaggi usa-e-getta sono peggio di altri da questo punto di vista. JS non ne parliamo proprio, ma pure Python non scherza. Come commentava jwz io ho ancora codice scritto in Perl che dopo 20 anni gira pari pari con l'interprete corrente. Solo che oggi se dici una cosa del genere ti guardano come un animale raro. Il problema non sono le dipendenze ma la mancanza di voglia di mantenere la coerenza della API nel tempo. In certi ambiti le cambiano orgni 3 mesi, come puro esercizio di stile. Dev che flexano e si lanciano nel vuoto.
@@fplove già, però sta di fatto che evitando ogni dipendenza ci si isola completamente da quel contesto folle.
@antirez vero, ma occorre sempre trovare un tradeoff tra velocità di sviluppo e minimalismo per le dipendenze, da quel punto di vista usate cum grano salis le AI possono effettivamente essere di molto aiuto.
Ho avuto la fortuna di crescere professionalmente sotto l'ala di un vero senior, per lui installare una nuova libreria doveva essere l'ultima delle possibilità da considerare, oltre che una sconfitta per via della manutenzione che avrebbe comportato un aggiornamento a distanza di tempo; da junior che ero facevo davvero difficoltà a capire la sua ostilità ed avversione verso questo modo di fare, crescendo ho capito il perchè e non posso che essere d'accordo con questo articolo e anche con lui.
Conosci persone come Casey Muratori, Jonathan Blow o Ginger Bill? Apprezzo molto il loro atteggiamento nel crearsi i propri strumenti e penso che Casey sia anche un ottimo insegnante
Non li seguo. I miei contatti sono perlopiù con sviluppatori underground che fanno parte di progetti open source.
Dovrebbe esistere un equivalente dell'ELO per gli sviluppatori. Tu Salvatore, saresti un super grandmaster.
Moltissimi sviluppatori invece, anche se sanno le regole, non hanno lungimiranza e la visione complessiva. Guardando solo alla mossa successiva.
Come gestisci il versionamento su Redis? In quali situazioni hai cambiato qualcosa dell'api e per quale motivo?
@@Alessandro__ è compatibile all'indietro da tipo 15 anni. Fine della storia :)
@@antirez complimenti veramente, riuscire a mantenere la retrocompatibilità è una delle sfide ingegneristiche più difficili, ma anche una delle più importanti. Su un progetto grosso come Redis poi... kudos 🙇
Parole sante
Domanda off topic, in uni così come sui vari libri di programmazione sconsigliano salti (goto o simili) che ne pensi del loro utilizzo?
Il goto c'è perché serve. Se è usato bene, in C è estremamente utile... Ci farò un video magari, me lo segno.
Una cosa che mi viene in mente su due piedi, è che se hai diversi for innestati, puoi usare il goto per uscire da tutti i for in una sola botta, come se fosse un return di una funzione. Se non usi il goto e vuoi una funzionalità simile devi wrappare i for innestati in una funzione e usare return
caso classico, ma ci sono altre situazioni dove è ancora più utile, nel caso specifico del C.
@@davideconsalvo3563 caso interessante, ad oggi ogni qual volta mi sia capitata una situazione simile ho sempre usato il return compartimentalizzando questa cosa alla sola funzione (anche perché sfrutto molto la programmazione funzionale e quindi spezzetto quasi tutto in building blocks) però nel caso del C effettivamente ho fatto qualche ricerca ed è applicato a parti di codice “etichettate”
Hai commentato il codice? ma come non si fa 😂😂 faccelo un video sul tema ❤... Sul discorso delle lib c'è un video illuminante di Greg Yang dive lui dice che si copia il codice e poi lo fa suo, condivido appieno
ho abbondonato la programmazione perchè per me era totlamente insensata , ora porgrammo robot con software matematici dove le cose non cambiano ogni 5 minuti , la fisica per fortuna resta quella per molto tempo , l'informatica porta alla follia
ci sono parti dell’informatica moderna che sono del tutto insensate. Per difendersi bisogna avere la possibilità pratica di rinunciare a far parte di quelle che sono le pratiche comuni.
La catena di dipendenze è una piaga e si può spezzare solamente con la buona volontà. Riscrivere dei piccoli pezzi ove possibile, usare meno framework o, dove non sia possibile, usare il framework meno invasivo ed obeso. Scegliere librerie che abbiano come filosofia il "dipendenze zero". Tendere al principio KISS come regola base. E' difficile. Ma qualcuno deve pur iniziare a farlo o, almeno, a capirlo.
Ciao Enkk, grazie, ti ho seguito su IG e ti ho scritto un DM.
Premesso che ad utilizzare una libreria terza non sai mai che cazzo ti porti dietro, banalmente una scarsa architettura o una vulnerabilità (ed è successo recentemente che l'intero web è controllato NB log4j)
Sono uno di quelli che evita di usare una dipendenza terza quando può scriversela da sé come meglio crede, e i vantaggi sono anche nella crescita personale nell'affrontare e imparare nuove dinamiche inveve di diventare un automa che ripete a manetta le solite cose.
Noto che questa catena di dipendenza si noti soprattutto nel mondo JS (che guarda caso usa un package manager come npm), guarda React, giusto per dirne uno, e cresce ulteriormente quando installi una libreria di componenti, una libreria per il routing e una libreria pure per farti un seghino in pausa.
Diventa veramente complesso trovare un'alternativa, perchè l'unica soluzione è quella di scrivere una nuova libreria / framework dependency-free.
Credo che il compromesso in questi casi può avere senso?! Tu hai altre soluzioni in mente per ridurre drasticamente questo problema?
Non ho soluzioni purtroppo perché è un problema culturale prima che tecnologico.
Tutto vero
È un problema molto sentito... Difficile da risolvere. Lato javascript (lato frontend) in azienda cerchiamo di utilizzare solo librerie self contained
E le collisioni nelle dipendenze transitive che vengono gestite dal package manager per poi capire a runtime che c'è una specifica funzionalità che si rompe, vogliamo parlarne...
bello il mare ... cazzo :-) da Sardo che vive in Svizzera tedesca ne sento la nostalgia :-)
In linea di massima concordo con te ma spesso sento la mia voce interiore che inizia a dire.... e se il pezzo di codice che hai "copiato" o riscritto non cambia mai semplicemente perchè è solo tuo e quindi non è sottoposto ai 1000 occhi della libreria in cui è presente? Immagina il tuo codice per avere le informazioni sul terminale. Tu lo usi e sei contento di non doverlo cambiare mai ma potrebbe avere falle che tu non conosci. Quindi sono molto combattuto e non ho una soluzione univoca. Sicuramente non farei MAI uno sviluppo che riguarda algoritmi di crittografia su un software che, per quanto open source, potrebbe avere troppo poco seguito lasciando aperti potenziali falle di sicurezza.
Io ho la netta convinzione che codice scritto con amore, per bene, da una sola persona, sia qualitativamente migliore *in media* di quello scritto per approssimazioni successive di patch. Se una cosa non è security-critical, non mi farei problemi. Se lo è, c'è larga evidenza che anche il resto del software ha bug, e in tal caso farei un bell'audit, come magari gli altri raramente fanno.
Però sei limitato alla grandezza del progetto e alla sua complessità. Ad un certo punto dovrai chiamare dei colleghi (reali o artificiali)
grazie... aspetto molto interessante. Però c'è da capire bene cosa si sta copiando dentro il progetto...
Se copi dentro il progetto, non è diverso da fare "require". Se lo scrivi tu, non stai copiando. Se usi un LLM, prima capisci cosa c'è scritto, lo usi come prima versione.
metà del lavoro di uno sviluppatore è aggiornare le dipendenze e quando queste magicamente diventano a pagamento trovare dei sostituti. Impensabile creare una web app senza mantenerla per 1 anno. Questa cosa non ha senso, una volta creata dovrebbe durare 20 anni senza più toccarla e invece..
...daltronde si è andati verso l'idea di "semplificare"...così cala l'attenzione, così si delega tutto al gestore di pacchetti...così...così così...la gene resta scema...e pensa di essere intelligente. Ho recentemente visto un video entratomi per caso in youtube....una persona in un'aula che segue un corso di informatica...e fa vedere che usa un ai per fare un applicazione in un minuto...prende e esce dall'aula e conclude fiera dicendo "ecco il mio corso di informatica"....Signori, avremo davanti anni molto bui davanti...🧐
Non mi trovo molto d'accordo. Lo sviluppo software industriale degli ultimi anni ha avuto un'impennata di qualità anche grazie all'uso delle dipendenze. Il problema, a mio parere, è più nella pratica che non si è ancora consolidata. Non esiste una misurazione oggettiva della qualità di un pacchetto, sappiamo bene che la Big Tech spesso si appoggia su librerie OSS sviluppate da padri di famiglia che dedicano il tempo che possono. Un repository con dipendenze classificate in base alla qualità del processo di sviluppo e manutenzione sarebbe un enorme passo avanti, e lo sviluppatore potrebbe avere un ritorno economico che gli permetterebbe di concentrarsi adeguatamente sul progetto.
Difficile sostenere che il software moderno sia di qualità.
@antirez Ha avuto un'impennata di qualità. Ma su questo capisco che è difficile avere una misura oggettiva.
@@PietroBonannosemmai di quantità.
Basta aprire un browser, utilizzare una delle miriadi delle “single page application” e vedere quanto sono lente. Se comunque funzionano.
Tutto questo mentre l’hardware ha fatto e continua a fare passi importantissimi nell’ottimizzazione, che oramai capire bene cosa fa una CPU è diventato praticamente impossibile.
@@esadecimale credo si sia persa la mia risposta, la riscrivo. E' chiaro che, se confronti il meglio di ieri con il peggio di oggi, hai questa impressione. Ricordiamoci certe porcherie in VBScript o Flash e la prospettiva cambia. Considera poi che ormai gli standard delle UI web si sono praticamente allineati a quelli delle applicazioni desktop. La quantità e la complessità del traffico generati è diventata ingestibile per qualsiasi libreria del passato. Inoltre il numero di utenti è almeno due ordini di grandezza in più. Per fare un esempio di app web di qualità, prova Miro e dimmi se quella gestione la trovi in qualsiasi app di 15 anni fa. Mi limito al web solo perché è quello che va per la maggiore.
In parte è anche merito delle dipendenze, che hanno liberato i dev dal dover verificare aggiornamenti e update, scaricare, bestemmiare e cercare subdipendenze e così via. Che poi ci sia da affinare il processo e gestire alcuni casi, non ci sono dubbi.
In futuro la professione di OSS maintainer potrebbe essere più valorizzata visto che molte aziende dipendono da questo
In linea di principio, pienamente condivisibile. Io stesso sottolineo nei miei pacchetti, crates o moduli che una cosa è “dependency-less” quando ci riesco.
Ma è tutto legato a contesto, capacità dell’individuo e, soprattutto, interessi. Tu stesso hai detto “mica mi re-implemento SSL?”. Tu! Ma ci sono quelli che lo sanno e vogliono fare. In Rust, per esempio, il progetto RustTls o il progetto per re-implementare DNS Bind. Sono cose che portano dentro dipendenze (non poche) ma sono riscritture necessarie per modernizzare e anche portare i vantaggi di Rust nelle low level libraries.
La verità è che bisogna saper scegliere le dipendenze. Scegliere significa guardarsi la history del codice, capire se lo sviluppatore che ci sta dietro è una persona coscienziosa, metodica, che sa gestire bene la responsabilità che si prende, o se è il tipico personaggio minchione che fa una libreria con mezza cosa utile dentro, e 600 dipendenze inutili o superflue/evitabili.
Ci sono anni e anni di lavoro da fare per sviluppare questo enorme senso critico. Richiede che hai fatto l’errore prima tu, e pagatene le conseguenze, per capire il tuo discorso ed internalizzarlo.
Dobbiamo permettere ai minchioni di minchioneggiare. O spendere tempo a fare mentorship. Ma non ho sempre tempo di fermare le minchiate 😂
non sono convinto che questo approccio così relativista sia equilibrato. È chiaro che ognuno in base alle proprie inclinazioni e capacità può decidere di re implementare quello che vuole, però qui si parla in questo video specifico di ingegneria del software di qualità, senza fare le cose stravaganti. in questo contesto delle linee guida sensate si possono certamente dare, e come dice il post originale il punto è evitare di inserire dipendenze per cose che sono, da riscrivere, quasi meno lavoro davvero meno lavoro di capire il codice altrui, integrarlo, e poi combattere con gli aggiornamenti. Poi ognuno, nel chiuso della propria camera di sviluppo, fa ciò che vuole. Ad esempio, io nella maggior parte dei software ho una politica di dipendenze zero. Capisco che ciò è estremo per troppi programmatori che operano in un contesto aziendale.
@ no ma sono in linea di principio d’accordo. Ma nel contesto delle aziende, uno degli aspetti è dover gestire il consenso. E non tutti sono Antirez :)
Non tutti possiamo permetterci di imporre certe politiche, senza creare problemi “umani”. Per questo uno può persuadere, fare talk interni, blogpost etc. Ma poi si fanno i conti con la realtà dove bisogna trovare il giusto medio.
Se uno ha il tempo e il peso politico, può decisamente spingere la politica che proponi. E a lungo termine i benefici escono fuori sicuro.
Ti parlo dall’interno di un contesto dove ci sono progetti di 8/10 anni scritti per NodeJS. Ti lascio immaginare!!!
@ ne sono consapevole, purtroppo. Però sai qual è la differenza che si può fare? Quantomeno far passare che anche se poi all'atto pratico non sempre è possibile fare le cose così, non è neppure corretto normalizzare la follia delle dipendenze. Almeno va avanti il discorso culturale interno.
@ assolutamente!
...come non citare tra l'altro idiozie come LESS SASS o CSS in JS....ma chi ha partorito sta roba aveva mai imparato a usare i css normalmente?...è follia...ma pensi a quello che fai?...ecco "dipendenza" è la parola giusta! ma nel senso di dipendenza come nel caso delle tossico dipendenze! 🧐
a velocità normale il video è inguardabile .... cioè proprio ti mette a dura prova e santa pazienza...
solo a x1,75 diventa normale ... insomma, con questo flegmatismo io caricherei i video già editati con velocita doppia del normale.
Certi video sono molto più veloci, e in altri si parla di cose complicate in cui la lentezza aiuta un po' a digerire i concetti. Credo sia meglio lasciare all'utente la regolazione della velocità tutto sommato.
Tutto questo in realtà è positivo: più lavoro per gli sviluppatori 🦸🏼♂️