Quali sono i vantaggi di Ruby on Rails? Dopo due decenni di programmazione, uso Rails

A volte sento persone che si lamentano dei loro clienti, dicendo che insistono nell’usare Rails, che hanno bevuto troppo Kool Aid. Se sono reclutatori, si sentono quasi male allo stomaco per il fatto di dover trovare un altro sviluppatore ‘primadonna’ di Ruby on Rails. Poi tirano fuori qualcosa di simile a questo confronto incredibilmente ignorante tra Git e PHP per dimostrare il loro punto. “Non sanno nemmeno cosa stanno chiedendo”, dicono.

Per noi programmatori, a volte sembra davvero che i nostri clienti non abbiano un’idea. Ci piace esagerare casi come questo. Quando ci si pensa un po’, non sembra giusto pensare che una persona che mi sta dando dei soldi per costruire delle cose sia in qualche modo limitata e “semplicemente non capisce”. In effetti, credo che la maggior parte dei clienti conosca bene le proprie opzioni e tuttavia decida di scegliere Rails.

Cercherò di spiegare cosa, secondo me, rende Rails abbastanza vantaggioso da essere seriamente considerato per una pletora di progetti e bisogni.

Benefici di Ruby

È possibile che nessuno saprebbe nemmeno dei benefici di Ruby se non fosse per Rails stesso. Ad alcune persone piace sminuire Ruby dicendo che è “così facile per Ruby” con il suo “cavaliere dall’armatura splendente chiamato Rails” e che senza Rails, “Ruby sarebbe irrilevante”. Non posso dire con certezza se questo sia vero o meno, ma so che sarebbe un peccato enorme se il mondo si perdesse un linguaggio così superbo. Il fatto è che l’autore di Rails ha scelto Ruby deliberatamente, e la sua scommessa “selvaggia” ha pagato con enormi interessi. Quello che lui ha visto allora, molti altri possono vederlo oggi. Ruby in qualche modo abilita i programmatori in un modo speciale che è così difficile da spiegare alle “masse non lavate”. Quindi, perché usare Ruby on Rails? Ruby rende felici i programmatori, come pubblicizzato.

Mentre la maggior parte degli sviluppatori concorda sul fatto che Ruby sia comodo, alcuni lo vedono come troppo. Si preoccupano di cosa potrebbe succedere con tutte le libertà che Ruby permette, tutto il potenziale per un uso improprio. Permettetemi di illustrare con un po’ di patch scimmiesco:

"1".to_i #=> 1class String def to_i raise 'foobar' endend"1".to_i #=> RuntimeError: foobar

È così facile: con solo cinque righe di codice, abbiamo preso una classe esistente e ne abbiamo sovrascritto il comportamento. Nulla è sacro, nemmeno una stringa. Questo particolare errore sarebbe facile da individuare, ma le cose possono diventare molto più sinistre:

class String def to_i self.to_f - 1.13 endend"2".to_i #=> 0.8700000000000001

Proprio così, abbiamo introdotto un errore nella classe String che potrebbe essere avvolto e oscurato da strati su strati di complessità.

Si potrebbe pensare: Possono tutti e la loro madre rovinare la mia preziosa applicazione? Mentre questo comportamento sembra davvero spaventoso, non lo è affatto. In cinque anni di utilizzo di Ruby, ho avuto esattamente zero problemi con questo comportamento. Può sembrare controintuitivo, ma lo è anche guidare auto a 60 MPH in direzioni opposte separate solo da una sottile linea bianca in mezzo alla strada. In pratica, entrambi funzionano notevolmente bene.

Un altro vantaggio è che Ruby è uno strumento versatile. Come tale, ha bordi affilati, come un coltello. Mi piace pensare che gli adulti possano maneggiare bene i coltelli, mentre la sicurezza dei bambini è per, beh, i bambini (Tweet). Ed essere trattato come un bambino nell’IT ti lascia vittima del paradosso Blub di Paul Graham: pensi di stare meglio senza certe caratteristiche che non capisci o che qualcuno ti ha detto che sono troppo pericolose. Naturalmente, oggi ci stiamo chiedendo “perché usare Ruby on Rails”; quindi, questo è un dibattito per un’altra volta. Bisogna ammettere che a Ruby mancano alcune caratteristiche che altri linguaggi hanno (Lisp hmm, hmm). Tutto sommato, Ruby è vicino alla cima del ‘continuum di potenza del linguaggio’.

I miei primi anni con Ruby sono stati umilianti. Ho imparato così tanto solo leggendo il codice degli altri. A volte ero stupito; a volte ero arrabbiato; ma alla fine, questa conoscenza mi ha permesso di comunicare con il mio computer in modo molto più efficace di prima. Mi dispiace quasi per alcuni altri linguaggi ‘burocratici’ che ti fanno saltare attraverso i cerchi solo per il gusto di saltarli, mentre ti dicono “Sto solo facendo ciò che è meglio per te, è per il tuo bene!”

Pragmatismo

C’è un profondo rispetto per il pragmatismo, inserito nel DNA di Rails al livello più basso possibile. In combinazione con i benefici di Ruby, questo pragmatismo produce soluzioni eleganti e incoraggia la comunità di sviluppo di Ruby on Rails a fare lo stesso. Il pragmatismo è spesso pubblicizzato come una tenda di Rails, quindi questa affermazione non è nuova, ma mi è stata ricordata la sua veridicità abbastanza recentemente quando un mio amico ha cercato di mostrarmi quanto “cool” sia Hibernate. Stava lottando. Potevo sentire il suo dolore mentre non era in grado di impostare una miriade di opzioni e parametri di configurazione che avrebbero dovuto essere i default del framework in primo luogo.

Con l’età, i miei standard per la complessità artificiale sono diventati sempre più alti. Considerando che ho iniziato a scrivere codice di produzione nel 1989 all’età di 11 anni (iniziando con un progetto per il mio vicino di casa in Clipper Summer ’87), ho una tolleranza prossima allo zero per le complicazioni inutili. E Rails ha un punteggio molto alto in questo settore. È più di una semplice “convenzione sulla configurazione”; sto parlando dell’intera mentalità pragmatica che è molto apprezzata all’interno della comunità Rails e che permea tutta la comunità Rails.

Espressività

Rails è quanto di più vicino all’inglese ci sia (a meno che non stiate usando COBOL). Usa ciò che è noto come un DSL interno, estendendo Ruby con la propria semantica. Costruire un DSL è sempre pericoloso, poiché state effettivamente sviluppando un nuovo linguaggio. Poiché è interno, non c’è bisogno di usare un parser esterno, ma in un certo senso sembra un nuovo linguaggio. Il team di Rails ha trovato un buon equilibrio con il suo DSL, usandolo dove ha senso e solo raramente esagerando, dimostrando un eccellente autocontrollo. Penso che qualsiasi programmatore, indipendentemente dall’esperienza di Rails, (e anche alcuni non programmatori) potrebbe capire questo:

In effetti, se non avete familiarità con Ruby, questo potrebbe sembrare strano – è quasi come se non fosse un linguaggio di programmazione. Una volta che vi rendete conto che si tratta solo di chiamate di metodi senza parentesi, siete a posto. Ancora, il DSL di Rails sembra essere un linguaggio speciale per descrivere i requisiti, quando in realtà è solo una denominazione intelligente e un uso intrinseco dell’eccellente sintassi di Ruby.

Comunità

Rails ha un esercito di committers che si assicurano che sia sempre in condizioni ottimali. Molti progetti si ammorbidiscono con l’età, ma con Rails, le scintille volano ancora quando è necessario prendere decisioni. Sembra che i manutentori (ancora) si preoccupino veramente e vogliano che la gente usi Ruby on Rails e ne capisca i benefici.

Sotto Rails stesso, come ciliegina sulla torta, c’è Ruby con il suo formidabile gestore di pacchetti, RubyGems, paragonabile a CPAN in termini di numero di pacchetti – e considerando l’età di CPAN, questa affermazione è (a dir poco) molto impressionante. Rails ha avuto un breve deragliamento quando ha cercato di fare i propri “plugin Rails”. Fortunatamente, questo non è rimasto, così RubyGems rimane la fonte unificata e superba per il codice programmato da individui molto brillanti.

La sinergia tra un linguaggio fresco, un framework web pragmatico e una comunità superba dà a Rails un risultato molto migliore della somma delle sue parti.

Maturità

Rails è stato intorno al blocco. In un modo un po’ hipster, non è nemmeno più così cool. Questa è una buona cosa quando si tratta di scegliere uno stack tecnologico: si vuole qualcosa di provato. E Rails è proprio questo. Abbiamo recentemente scritto un pezzo che parla della grande varietà di interpreti e runtime Ruby che sono ora disponibili.

Marketing

Lo so, lo so. Come professionista dell’IT, dovrei davvero dare valore alle cose ‘serie’ e ignorare i ‘lustrini’. Può sembrare superficiale, ma ammettiamolo:

1. Paragonato alla concorrenza, il sito di Rails sembra buono.
2. Il primo screen cast di Rails, ai tempi, era semplicemente mozzafiato. Potrebbe non sembrare così impressionante oggi, ma ricordate che l’unica ragione per cui tutti conosciamo Java è che tutti erano così entusiasti della possibilità di eseguire un’applet Java nel browser. Questo si è rivelato non essere così importante dopo tutto, ma comunque, questo ha messo Java sul radar. Allo stesso modo, questo screencast di 15 minuti sul motore del blog è stato un grande successo che ha eccitato un sacco di gente.

Non si tratta nemmeno di vanità; si tratta di coinvolgere quante più persone intelligenti possibile per mettere acqua al mulino. Quando si considerano i framework, il posto migliore per essere tra la folla. Scegliere un framework su cui queste persone intelligenti si stanno concentrando significa semplicemente che molto più terreno è già coperto per voi. E questo mi porta al mio prossimo punto.

(Non) reinventare la ruota

Ho un debole per i framework piccoli. Mi piace quando posso capire cosa sta facendo un particolare framework e perché. In questo senso, Rails è un po’ gonfio, e persino opprimente a volte.

Il dilemma qui: quante volte vuoi scrivere le stesse cose più e più volte? Alcune di esse possono essere riscritte meglio, ne sono sicuro, ma ci vuole tempo, molto tempo. Più permettete a Rails di fare per voi, meno dovrete preoccuparvi di riscrivere o reimplementare le vostre funzionalità.

Rails è (come si dice) ‘batterie incluse’. Questa non è una buona cosa se siete appassionati di sparsità o se sentite il bisogno di avere una vasta conoscenza di come tutto funziona. In pratica, se lasciate andare le vostre paure, sembra funzionare. Rails ha dei valori predefiniti ragionevoli per quasi tutto ciò di cui avete bisogno ed è abbastanza modulare da evitare di mettervi alle strette.

Conclusione

Chiedetevi ancora, perché usare Ruby on Rails? Rails è adatto sia per siti web pubblici all’avanguardia che competono con applicazioni JavaScript a pagina singola, sia per complesse applicazioni aziendali di sistema che di solito hanno un aspetto un po’ più ‘brutto’ (con un’interfaccia utente più generica e a bassa fedeltà), ma compensano questo difetto con una tonnellata di complicate regole di business e logica. Il suo vantaggio è che è versatile e in grado di competere sia con l’elegante che con il potente.

Per la maggior parte dei problemi comuni, Rails ha un componente a vostra disposizione quasi subito, con una documentazione che è costantemente sopra la media (in qualche modo, il core team di Rails ha convinto i collaboratori che scrivere documentazione è figo (anche se tutti sappiamo che non lo è), portando a documenti ben scritti, concisi e che fanno risparmiare tempo).

Quando metti da parte gli unicorni e gli abbracci del venerdì, ti ritrovi con un framework potente che può essere usato sia per il tuo futuro game changer che per il tuo prossimo sito commerciale di medio livello. E con il vostro pool di gemme top-of-the-line, avete a portata di mano un arsenale che implementa alcune delle idee più brillanti della programmazione informatica. Senza problemi.