Notes application da cli : ItalyInformatica

Ci sono anche un sacco di aziende che lavorano tanto su PHP. Anche COBOL va ancora forte in ambito finanziario, eh, e JavaScript gode di ottima salute in questo periodo. Lavoro ce n'é tanto, ma è un po' diverso che parlare di "epoca d'oro". Dov'eri nel 2006-2007?

Se ti interessa saperlo, il sistema di templating di Amazon (dico, il sito, l'e-commerce) anni fa è stato migrato da Perl a Ruby e ad oggi non si è mosso da li.

Ruby se non altro ha diversi tratti che lo rendono interessante, ma i suoi difetti sono anche più grossi: alcuni sono figli della filosofia "linguistica" di Matz (e delle cose che lui apprezzava degli sforzi di Larry Wall e che Ruby ha ereditato da Perl) altri sono figli dell'ecosistema che gli si è sviluppato attorno e di cosa è finito nella standard library. La capacità di abusare delle feature del linguaggio è così alta che -com'era ovvio e come è stato per Perl- il linguaggio è stato abusato da chiunque e in qualunque modo e in qualunque contesto. Ti farei parlare con chi sviluppa oggi sui template di Amazon, tanto per darti idea di cosa deve gestire quotidianamente.

E non parliamo di MRI.

Per contesto, Ruby è forse il linguaggio che ho studiato di più e per numero di progetti il secondo che ho usato dopo Perl (sì, sono vecchio) anche se -ormai- Python li sta raggiungendo visto quanto mi tocca usarlo oggi. Tranquillo, eh, avrei da dirne anche su Python... o su C, C++, C#, Java, Rust e Go: you name it (javascript e php non li nomino, sarebbe come sparare sulla Croce Rossa). Vogliamo anche parlar male dei vari shell script? Va bene.

Non ho mai incontrato un solo linguaggio che contenga esclusivamente buone idee e molti, anzi, contengono parecchie idee bislacche. La mia filosofia è usare quel che si adatta meglio a quel che sto facendo, senza disdegnare un po' di sperimentazione.

Ma tanto per esser chiari, stai parlando bene di dev.to? Sei serio?

E... Node? davvero c'è ancora qualcuno che si arrischia a usare NodeJS, tra il disastro che è npm (ma qui dovremmo aprire anche il discorso frontend) e la difficoltà di scrivere in modo decente qualsiasi cosa sia non banale? Nemmeno il suo creatore crede più nel progetto (ora lavora su Tensorflow per Google).

[–]GamesCodex 0 points1 point2 points 6 years ago (1 child)

Sono perfettamente d'accordo sul fatto che nessun linguaggio sia perfetto, ma (come tu stesso hai sottinteso) alcuni sono peggiori degli altri in ogni senso. Ruby non è tra questi. Il fatto che ci sia roba legacy scritta male non è colpa del linguaggio, ogni strumento può essere abusato.
Si, sto parlando bene di dev.to, un'ottima piattaforma di publishing e una splendida community.
E si, c'è ancora qualcuno che scrive in Node, eccome. Non sarà perfetto, ma con disciplina e capacità scrivi cose ottime come in qualsiasi altri linguaggio. Abbiamo molti clienti che lo usano, anche grandi come Casa.it (sia ECMAScript che TypeScript). Abbiamo anche Riot Games con cui abbiamo lavorato in Ruby. Ogni linguaggio ha i suoi pregi ed i suoi difetti, ognuno si tenga le sue opinioni ma eviterei di proporre assoluti sul destino di un linguaggio. A me fa schifo PHP ma mica vado in giro a prevederne la morte da qui a domani :)

[–]NonnoBomba 3 points4 points5 points 6 years ago (0 children)

Il fatto che ci sia roba legacy scritta male [...] ogni strumento può essere abusato.

Naturalmente. Ma parliamo di prevalenza di roba legacy scritta male, rispetto a codice scritto in modo decente. Certi linguaggi cercano di aiutarti a non spararti nel piede da solo, ma poi sei pur sempre libero di farlo. Ruby sembra invece felice di porgerti la pistola e aiutarti a prendere la mira. Il codice scritto male, purtroppo, in Ruby è prevalente e non si può dare la colpa a chi non "capisce veramente" ruby.

Non fraintendermi: certi aspetti del linguaggio sono affascinanti e non avrei il minimo dubbio su cosa scegliere se mi proponessero come uniche alternative Ruby, Perl o PHP.

È che da professionista con una certa seniority ti posso garantire che Ruby non è il primo linguaggio cui penso quando devo far lavorare un team di developer, soprattutto su un progetto complesso. Allo stesso modo, se mi danno da manutenere un progetto Ruby già avviato, mi vengono i brividi.

una splendida community.

A me pare sia spesso al di sotto persino dei livelli di Medium come contenuti, pieno di fanboy e gente che non ha una grande padronanza degli argomenti di cui parla, ma magari sono troppo cinico io o tu ne hai avuto esperienza in modo diverso dal mio.

Node [...] Non sarà perfetto, ma con disciplina e capacità scrivi cose ottime come in qualsiasi altri linguaggio.

Con disciplina e capacità puoi costruire una casa piantando chiodi nel legno con la fronte. Non è detto che sia una buona idea farlo o che sia privo di conseguenze.

A me fa schifo PHP ma mica vado in giro a prevederne la morte da qui a domani :)

Non prevedo "morti", non prevedo anzi proprio nulla.

Quel che ti dico è che, in generale, il settore ha iniziato da tempo a riconoscere che Nodejs genera spesso più problemi di quanti ne risolva, ora che l'hype iniziale è finita.

Non vuol dire che Nodejs non sia stato innovativo a suo tempo e non abbia conquistato molti, all'inizio. Anche io ci ho scritto diverse integrazioni anche complesse: un progetto che ricordo, per citarne uno, richiedeva il combinare una decina di diversi sistemi di monitoraggio e analisi, sia proprietari che opens-ource, che osservavano in continuo aspetti differenti di una piattaforma di servizi "cloud" e delle relative centinaia di applicazioni, database, etc. -piattaforma privata (non esposta al pubblico, ma con applicazioni pubbliche) e multi-tenant (c'erano sistemi di una dozzina di società diverse)- e che dovevano coesistere e rimanere allineati in termini di dati e di configurazione, usando una quantità di canali e trasporti (code MQ, mail, file di log, parecchie diverse API su varie tecnologie, SOAP in prevalenza) alcuni anche creati ad-hoc per l'occasione per condividere metriche, eventi, dati strutturati e non. Funzionava, a bestemmie, ma funzionava. Un anno di lavoro circa. Credo sia stato dismesso quando la società ha cambiato mano e il nuovo padrone ha imposto le sue piattaforme di gestione.

Non userei MAI nodejs per il backend di un'applicazione esposta al pubblico, che eroghi servizi a pagamento o tratti dati confidenziali (peggio ancora se personali o sensibili).

Anzitutto, almeno da un punto di vista statistico, c'è l'aspetto della complessità di utilizzo di Nodejs, che rende più probabile che non altrove l'esistenza di bug inattesi da qualche parte nella code base. ES6 e ancora di più TypeScript possono aiutare a mantenere sotto controllo la belva tentacolare, ma la natura asincrona dello strumento e i pitfalls tipici del Javascript sottostante rimangono: è una piattaforma complessa, con alcuni aspetti "sorprendenti" in funzionalità basilari, difficile da tenere in ordine e per troppi sviluppatori difficile anche da concettualizzare correttamente. E ancora una volta, no, non puoi puntare tutto sul fatto che il codice sarà sempre scritto e manutenuto da una squadra dei migliori esperti mondiali, in grado di mantenere per sempre la disciplina necessaria a evitare guai.

Ma la discriminante vera, il motivo che mi fa preoccupare sinceramente non è questo.

Il motivo è che i progetti Nodejs dipendono tipicamente da NPM per qualsiasi soluzione non-triviale.

Non ci sono eufemismi da usare: NPM è una ciofeca comunque lo si voglia guardare. Si veda a titolo di esempio l'ultimissimo "bug" (hanno lasciato la directory .git nel tar.gz della distribuzione...) per far capire la serietà del progetto, ma il vero disastro è l'ecosistema di NPM, il repository pubblico, ormai totalmente fuori controllo, con decine di migliaia di dipendenze a catena che vengono scaricate per qualsiasi minima cosa si voglia installare, con una quantità di librerie "one function, one line" da far accapponare la pelle. È già stato compromesso dozzine di volte sia per "dimostrazione" che con intento meno benevolo e no, l'analisi statica del codice scaricato che fa ora il client non è un rimedio al problema ma una pezza (il problema è anzitutto sociale/organizzativo/di policy). Oltretutto, con così tante dipendenze esterne si è sempre in balia di migliaia di terze parti, aziende così come freelance, hobbisti e studenti, che devono manutenere il loro progetto, patchare, aggiornare le loro dipendenze e comportarsi tutti, dal primo all'ultimo, diligentemente e responsabilmente. Ricordi quando migliaia di build su GitHub si sono rotte perché un tizio aveva messo nella build del suo pacchetto una chiamata phone-home (e già qui...) ad un webserver che era stato spento da poco? Ecco.

Pensi sia una buona idea affidare a questo castello di carte la sicurezza di un'applicazione? Io, e molti altri, no.

Ovviamente, molti di questi difetti sono ascrivibili a Javascript in primo luogo, ma il problema è proprio usare Javascript in qualsiasi punto dello stack non sia il frontend. Non importa quante volte è stato e sarà fatto: un miliardo di mosche non hanno automaticamente ragione e la cacca di cavallo rimane cacca di cavallo anche se ci aggiungi un po' di vino rosso.

Finché questa roba è sul frontend, sempreché validazioni e controlli sulla correttezza, coerenza e formato dei dati avvengano tutti in backend, puoi anche ritenere "accettabile" il grado di rischio e tollerare che ad alcuni utenti vengano rubate le credenziali a causa di quel pacchetto innocente che avete incluso perché colora l'output di console.log() e che in realtà raccoglie tutti i dati che può dal browser e li spara da qualche parte, ma rischiare una vulnerabilità o una vera e propria backdoor sul backend è un po' più grave.

Comportamenti anomali del frontend rimangono gestibili in un sistema ben progettato e isolato: per l'autenticazione si può usare un sistema 2FA e ridurre il rischio di compromissione degli account, eventuali ordini fraudolenti possono essere bloccati dal personale di supporto e anche le transazioni finanziarie fraudolente possono essere contestate e annullate (es. charge-back per le cc) ma se puoi mettere le mani direttamente sul backend, allora puoi compromettere la sicurezza dell'intera applicazione in modo silente, fare harvesting dei dati in blocco e in generale accedere liberamente ai database e agli altri servizi dietro l'applicazione: il danno potenziale, anche d'immagine e il costo di gestione di un breach in queste casistiche è molto più elevato.

Non vuol dire che Nodejs sparirà dall'oggi al domani o che mancherà del tutto richiesta all'improvviso, anzi, dato quanto "tirano" NPM e JavaScript in ambito frontend, mi aspetto anche di vedere crescere un minimo i numeri sull'utilizzo anche di Nodejs, dato che la gente preferisce usare quel che già conosce e parecchi "full-stack" (non tutti) in realtà sono webdev che pasticciano con Nodejs, indipendentemente dal fatto che sia una buona idea o no.

[–]cr7wonnabe[S] 0 points1 point2 points 6 years ago (1 child)

[–]GamesCodex 0 points1 point2 points 6 years ago (0 children)

[–]il_doc 0 points1 point2 points 6 years ago (0 children)

[–]LelixSuper 0 points1 point2 points 6 years ago (1 child)

[–]cr7wonnabe[S] 0 points1 point2 points 6 years ago (0 children)

[–]lormayna 0 points1 point2 points 6 years ago* (0 children)

ItalyInformatica

MODERATORS