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

A volte sento persone che si lamentano dei loro clienti, dicendo che insistono nell'usare Rails, che hanno ricevuto troppo Kool Aid. Se sono reclutatori, si sentono quasi male allo stomaco di dover trovare un altro sviluppatore "primadona" di Ruby on Rails. Quindi 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 ne abbiano idea. Ci piace esagerare casi come questo. Quando ci pensi un po', non sembra giusto pensare che una persona che mi sta dando soldi per costruire cose sia in qualche modo limitata e "semplicemente non ce la fa". In effetti, credo che la maggior parte dei clienti conosca bene le proprie opzioni e tuttavia decidano comunque di utilizzare Rails.

Cercherò di spiegare cosa, secondo me, rende Rails così vantaggioso da essere preso seriamente in considerazione per una pletora di progetti ed esigenze.

Vantaggi di Rubino

È possibile che nessuno sappia dei vantaggi 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 scintillante chiamato Rails" e che senza Rails, "Ruby sarebbe irrilevante". Non posso dire con certezza se sia vero o meno, ma so che sarebbe un vero peccato se il mondo perdesse una lingua così superba. Il fatto è: l'autore di Rails ha scelto Ruby deliberatamente e la sua scommessa "selvaggia" è stata ripagata con enorme interesse. Quello che 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". Allora, perché usare Ruby on Rails? Ruby rende felici i programmatori, come pubblicizzato.

Mentre la maggior parte degli sviluppatori concorda sul fatto che Ruby sia utile, alcuni lo considerano troppo . Si preoccupano di cosa potrebbe accadere con tutte le libertà che Ruby consente, tutte le possibilità di uso improprio. Lasciami illustrare con alcune patch di scimmie:

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

È così facile: con solo cinque righe di codice, abbiamo preso una classe esistente e ne abbiamo sovrascritto il comportamento. Niente è sacro, nemmeno una corda. 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 end end "2".to_i #=> 0.8700000000000001

Proprio così, abbiamo introdotto un errore nella classe String che potrebbe essere racchiuso e oscurato da uno strato all'altro di complessità.

Quindi, potresti pensare: tutti e la loro madre possono rovinare la mia preziosa domanda? Anche se questo comportamento sembra davvero spaventoso, in realtà non lo è. In cinque anni di utilizzo di Ruby, ho avuto esattamente zero problemi con questo comportamento. Può sembrare controintuitivo, ma lo è anche guidare le auto a 60 MPH in direzioni opposte separate solo da una sottile linea bianca in mezzo alla strada. In pratica, entrambi funzionano molto bene.

Un altro vantaggio è che Ruby è uno strumento versatile. In quanto tale, ha bordi affilati simili a coltelli. Mi piace pensare che gli adulti sappiano maneggiare i coltelli bene: la prova dei bambini è per, beh, i bambini (Tweet). Ed essere trattato come un bambino in 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. Ovviamente oggi ci chiediamo “perché usare Ruby on Rails”; quindi, questo è un dibattito per un'altra volta. Certo, Ruby perde alcune funzionalità che hanno altre lingue (Lisp hmm, hmm). Nel complesso, Ruby è vicino al vertice del "continuum del potere linguistico".

I miei primi anni con Ruby sono stati umili. Ho imparato così tanto solo leggendo il codice degli altri. A volte rimasi sbalordito; a volte ero pazzo; 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 i cerchi solo per il gusto di saltarci dentro, il tutto dicendoti "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 vantaggi di Ruby, questo pragmatismo produce soluzioni eleganti e incoraggia/ispira 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 è stato ricordato della sua veridicità abbastanza recentemente quando un mio amico ha cercato di mostrarmi quanto sia davvero "cool" Hibernate. Stava lottando. Potevo sentire il suo dolore perché non era in grado di impostare una miriade di opzioni e parametri di configurazione che avrebbero dovuto essere predefiniti 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 il 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 quasi zero per complicazioni inutili. E Rails ha un punteggio davvero alto in quel dipartimento. È più di una semplice "convenzione sulla configurazione"; Sto parlando dell'intera mentalità pragmatica che è molto apprezzata all'interno e permea la comunità di Rails.

Espressività

Rails è il più vicino possibile all'inglese (a meno che tu non stia usando COBOL). Utilizza ciò che è noto come DSL interno, estendendo Ruby con la propria semantica. Costruire una DSL è sempre pericoloso poiché stai effettivamente sviluppando una nuova lingua. Poiché è interno, non è necessario utilizzare un parser esterno, ma in un certo senso sembra una nuova lingua. Il team di Rails ha trovato un buon equilibrio con il suo DSL, usandolo dove ha senso e solo di rado esagerando, dimostrando un eccellente autocontrollo. Penso che qualsiasi programmatore, indipendentemente dall'esperienza di Rails, (e anche alcuni non programmatori) potrebbe capire questo:

 class User < ActiveRecord::Base devise :database_authenticatable, :registerable validates_numericality_of :years_of_experience, :allow_blank => true acts_as_taggable acts_as_taggable_on :certificates, :expertise_kinds validates_presence_of :first_name, :last_name, :email has_many :translations has_attached_file :avatar, :styles => {:small => "240x240>"} has_attached_file :cv ...

In effetti, se non hai familiarità con Ruby, potrebbe sembrare strano: è quasi come se non fosse un linguaggio di programmazione. Una volta che ti rendi conto che si tratta solo di chiamate di metodo senza parentesi, sei a posto. Tuttavia, Rails DSL sembra essere questo 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 committenti che si assicurano che rimanga in ottime condizioni. Molti progetti diminuiscono con l'età, ma con Rails le scintille volano ancora quando è necessario prendere decisioni. Sembra che i manutentori (ancora) si interessino davvero e vogliano che le persone utilizzino Ruby on Rails e ne comprendano i vantaggi.

Sotto lo stesso Rails, 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 è (per usare un eufemismo) molto impressionante. Rails ha avuto un breve deragliamento quando ha provato a creare i propri "plugin Rails". Fortunatamente, questo non si è bloccato, quindi RubyGems rimane la superba fonte unificata per il codice programmato da individui molto brillanti.

La sinergia tra un linguaggio interessante, un framework web pragmatico e una community superba offre a Rails un risultato molto migliore della somma delle sue parti.

Scadenza

Rails ha fatto il giro dell'isolato. In un modo un po' hipster, non è nemmeno più così cool. Questa è una buona cosa quando si tratta di scegliere uno stack tecnologico: vuoi qualcosa di provato. E Rails è proprio questo. Di recente abbiamo scritto un pezzo parlando dell'ampia varietà di interpreti e runtime di Ruby ora disponibili.

Marketing

Lo so, lo so. Come professionista IT, dovrei davvero dare valore alle cose "serie" e ignorare il "brillante" . Può sembrare superficiale, ma ammettiamolo:

1. Rispetto alla concorrenza, il sito Rails sembra buono .
2. Il primo cast di Rails, ai tempi, era semplicemente mozzafiato. Potrebbe non sembrare così impressionante oggi, ma ricorda che l'unico motivo per cui tutti sappiamo di Java è che tutti erano così entusiasti della possibilità di eseguire un'applet Java nel browser. Dopotutto, questo si è rivelato non essere così importante, ma comunque ha messo Java sul radar. Allo stesso modo, questo screencast del motore di blog di 15 minuti è stato un enorme successo che ha entusiasmato molte persone.

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

(Non) reinventare la ruota

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

Il dilemma qui: quante volte vuoi scrivere le stesse cose ancora e ancora? Alcuni di essi possono essere riscritti meglio, ne sono certo, ma ci vuole tempo, molto tempo. Più consenti a Rails di fare per te, meno devi preoccuparti di riscrivere o re-implementare le tue funzionalità.

Rails è (come si suol dire) "batterie incluse". Questa non è una buona cosa se sei appassionato di sparsità o se senti il ​​bisogno di avere una conoscenza approfondita di come funziona tutto. In pratica, se lasci andare le tue paure, sembra funzionare. Rails ha impostazioni predefinite ragionevoli per quasi tutto ciò di cui hai bisogno ed è abbastanza modulare da evitare di metterti in curva in un punto stretto.

Conclusione

Chiediti 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 applicazioni di sistemi core aziendali complesse che di solito sembrano un po' più "brutte" (con un'interfaccia utente più generica e con fedeltà inferiore), ma compensano questo macchia con un sacco di regole e logiche di business complicate. 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 tua disposizione quasi pronto all'uso con documentazione costantemente al di sopra della media (in qualche modo, il core team di Rails ha convinto i contributori che scrivere documentazione è interessante (anche se sappiamo tutti che è non), 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 una struttura potente che puoi utilizzare sia per il tuo futuro punto di svolta che per il tuo prossimo sito di affari nel mezzo della strada. E con il tuo pool di gemme top di gamma, hai a portata di mano un arsenale che implementa alcune delle idee più brillanti nella programmazione di computer. Senza problemi.