Ruby on Rails: aspetti negativi e avvertenze [chiuso]

Questa non è una mossa iniziale per il Rohing Bashing - onesto!

Sto imparando Ruby e il framework Rails. A prima vista sembra essere piuttosto interessante e un'esperienza meravigliosa rispetto a PHP. (In effetti, mi ricorda i giorni più felici con C # e .NET.)

Tuttavia, entrando in questo, non ho esperienza con questo framework o linguaggio e sono curioso: quali sono gli aspetti negativi o le cose che vorresti sapere quando stavi iniziando?

(Forse questo dovrebbe essere un wiki della comunità?)

Ciò deriva dall'esperienza acquisita, dall'apprendimento continuo e dalla scrittura di un'applicazione relativamente semplice in Rails.

1) Curva di apprendimento

Rails è ingannevolmente semplice. I tutorial, i video e i libri dimostrano tutti quanto velocemente riesci a ottenere un'applicazione funzionante (se brutta), ma questi semplicemente graffiano la superficie. Tendono a fare molto affidamento sulla generazione di codice e "impalcature", che è certamente un buon strumento per l'apprendimento ma sopravvive rapidamente alla sua utilità.

Non commettere errori, Rails è difficile da padroneggiare. Una volta superate le basi (ne parleremo più avanti) ti imbatterai in un muro se hai bisogno di fare qualcosa di più della semplicistica funzionalità di "demo app" che vedi propagandare. Puoi imparare con una conoscenza di base di Ruby mentre impari, ma devi rapidamente raccogliere Ruby o rimarrai alto e asciutto (e non il tipo buono DRY) se devi andare oltre i vincoli di Rails.

Rails è, come mi piace chiamarlo in modo amorevole, dipingere programmando numeri . Se ti attieni al 100% alle convenzioni (ad esempio, stai all'interno delle linee e usi i colori che ti viene detto di usare) puoi fare applicazioni decenti in modo rapido e semplice. Se e quando devi deviare, però, Rails può passare dal tuo migliore amico al tuo peggior nemico.

2) Quando tutto ciò che hai è un martello ...

Rails fa molto bene le applicazioni CRUD semplicistiche. Il problema si presenta quando l'app non deve fare altro che leggere / scrivere da un database. Ora, per la cronaca, l'ultima versione di Rails che ho usato era la 2.3.4, quindi le cose potrebbero essere cambiate da allora, ma ho riscontrato grossi problemi quando i requisiti aziendali sono cambiati, quindi l'applicazione doveva avere un piccolo sistema di flusso di lavoro integrato e integrarsi con un'applicazione PHP legacy. La convenzione Rails di "un modulo, un modello" funziona perfettamente per app e applicazioni di immissione dati banali, ma non tanto quando è necessario eseguire la logica di elaborazione o disporre di flussi di lavoro o qualsiasi cosa che non sia il tipico "Utente immette dati in alcuni campi di testo, risultati Invia "tipo di cosa. Esso può essere fatto, ma è in alcun modo "facili", o meglio, wasn'

Inoltre, a Rails non piace giocare bene con altre applicazioni che non usano i suoi metodi preferiti di accesso ai dati; se devi interfacciarti con un'applicazione che non ha un'API di stile "Web 2.0", devi aggirare Rails invece che con esso; di nuovo parlo per esperienza qui perché questo è quello che mi è successo.

3) È nuovo

Infine, Rails è ancora il "nuovo bambino sul blocco" in molte aree. Questo non importa per uso personale o tipo di scenari "Penso che sia bello e voglio impararlo", ma parlando come qualcuno che preferirebbe usare Rails nel mio lavoro quotidiano, se non ti trovi in ​​una posizione dove Rails è molto diffuso, può essere molto difficile trovare lavoro a tempo pieno come sviluppatore di Rails. È ancora in gran parte il dominio di "hip, nuove startup" e non un attore importante nella maggior parte delle aree metropolitane. Il tuo chilometraggio può variare a questo proposito, ma so che la mia area (Tampa) Rails è essenzialmente inesistente.

4) Fuoco e movimento

Rails è in continua evoluzione. Questa è sia una cosa buona che una cattiva; è buono perché la comunità si evolve e abbraccia nuovi concetti. È un male perché la comunità si evolve e abbraccia nuovi concetti. Può essere molto travolgente per un principiante di Rails perché in genere quando ti imbatti in un problema e ti guardi intorno, vedrai entrambe le persone che raccomandano tale gemma per risolverlo o che dicono che il modo in cui va male comunque e non dovresti t usalo, ecco un modo migliore ... e finisci per avere una lista di strumenti aggiuntivi da imparare insieme a Rails per stare al passo con i cognoscenti di Rails. Cose come Git, BDD/RSpec, Cucumber,Haml/Sasse una cornucopia di altre cose galleggiano tutte e vengono spinte come "il modo giusto di fare le cose" nella Terra di Rails, e parlando per esperienza potresti finire per essere sommerso cercando di imparare una dozzina o più di tecnologie oltre a Rails, perché l'utilizzo del toolkit standard di Rails sembra "sbagliato".

Questo è ora aggravato ancora di più da Rails 3.1 che rende Sass e CoffeeScript di tutte le cose predefinite, quindi un principiante totale di Rails non solo deve imparare Ruby e Rails ma Sass (probabilmente semplice se conosci CSS) e CoffeeScript (non pazzo difficile ma sicuramente abbastanza diverso da JavaScript non elaborato) al minimo indispensabile per iniziare, inoltre si può presumere Git. Anche senza factoring in RSpec e amici, e la dozzina o più gemme con cui in genere finirai, sono 4 cose diverse che devi imparare prima di poter iniziare seriamente a scrivere applicazioni Rails. Confronta questo con un linguaggio come C #, o Java, o anche con PHP in cui le tue conoscenze HTML / CSS / JavaScript / SQL non cambieranno e devi solo imparare il linguaggio stesso e forse le sfumature del framework.

Documentazione.

Mentre le guide di Rails sono un'ottima risorsa di apprendimento, i riferimenti alla libreria di Rails (e Ruby, in genere) non sono facili da navigare. Di ', vuoi saperne di più sul belongs_tometodo. Sebbene sia usato su ActiveRecord::Basesottoclassi (i propri modelli), non è documentato nei ActiveRecord::Basedocumenti, ma in un mixin importato dalla classe. In sostanza, non è possibile visualizzare un elenco completo di tutti i metodi che è possibile utilizzare su un oggetto in un unico posto (tranne quando si accende irbe si verifica l'oggetto stesso).

Con un linguaggio altamente dinamico come Ruby, non è semplice dire da dove provenga un metodo che stai usando. Può essere un problema, in particolare per i programmatori dell'apprendimento che cercano di afferrare un nuovo stack tecnologico.

Ruby on Rails ha una curva di apprendimento significativa. Per prima cosa devi imparare le stranezze della lingua, quindi apprendere il quadro, quindi imparare il modo di fare le rotaie, quindi conoscere le molte gemme comunemente usate.

Tuttavia, quando hai imparato quelle cose, arriva incredibilmente naturalmente. In effetti, altri quadri iniziano a sembrare un peso.

Rails è molto orientato al TDD / BDD, quindi se non lo sei allora ci sono altre due cose che dovrai imparare prima di diventare un programmatore Rails competente. Non hai un compilatore e IDE per il backup, quindi la copertura del test è molto il tuo fallback.

Molti sostenitori del TDD, me compreso, considererebbero questo uno dei punti di forza del RoR, oltre che la sua maledizione. Una volta che inizi a scrivere TDD, scopri che la sicurezza offerta dalla copertura del test è migliore della sicurezza offerta da un compilatore. Quindi dover scrivere il codice SOLO per compiacere un compilatore diventa gravoso.

TDD non sembra un compito aggiuntivo in RoR, sembra l'unico modo di lavorare.

Rails ha un grave problema di prestazioni: ogni richiesta è messa in coda dietro a quella attualmente attiva, al contrario del threading come fanno la maggior parte dei framework o permettendo agli eventi di blocco di liberare altre richieste come fanno Node.js e Twister. Ciò significa che devi programmare per velocizzare i tempi di risposta, ma nella maggior parte dei casi è abbastanza facile da eseguire.

Rails è anche progettato per gestire molto bene i sistemi di contenuti, che in tutta onestà è molto Internet. Fare qualcosa di un po 'più complicato, come un gioco Web o un sistema di e-commerce, significa imparare nuove gemme. Imparerai rapidamente che tutte le gemme sono là fuori, ma più oscura è la cosa che vuoi fare, più difficile sarà trovare una buona documentazione.

Nella mia esperienza personale, il principale mal di testa riguarda la compatibilità .

Quando:

• ci sono xprogetti di binari distribuiti,
• ogni progetto utilizza ygemme.
• mentre ci sono nversioni di binari,
• oltre alle mversioni di gemme installate,
• con severalversioni di rubino,
• su una singola scatola Linux come macchina di produzione.
• il programmatore lavora su un altro notebook di sviluppo OS X.

Come libero professionista, che non ha il lusso di aggiornamento / upgrade maggior parte delle cose, si troveranno ad affrontare un sacco di problemi di compatibilità da variabili di cui sopra ... mentre rails, gemse rubycontinuare a cambiare / evoluzione.

La velocità è sicuramente un problema. L'estrema flessibilità di Ruby ha un notevole successo in termini di prestazioni.

Il ridimensionamento orizzontale è un'attività non ovvia, ad eccezione delle tecnologie specificamente progettate per tale compito, che di solito compromettono la semplicità per ridimensionare bene.
Se riesci a gestire 100 volte il numero di richieste per macchina con la tecnologia A rispetto alla tecnologia B, l'utilizzo della tecnologia A è utile se hai motivo di credere che puoi servire i tuoi dati da un singolo server per un periodo di tempo che ti consente di aggiungere parallelizzazione in seguito.
Nel 2009 StackOverflow era ancora servito da un web server . Ovviamente questa non è più un'opzione. Ma suppongo sia positivo che abbiano iniziato con una tecnologia, che potrebbe essere estesa a molti utenti in una sola istanza, prima che si dovessero preoccupare di ridimensionare.

Rispetto a questo, il RoR è molto lento. Il tempo per gestire le richieste semplici è significativo ed è quindi un problema gestire molti clienti (tutto ciò è da vedere in relazione a alternative più veloci).

Per motivi di vago orientamento, ecco alcuni numeri, che confrontano varie altre lingue adatte allo sviluppo web con Ruby:

• Partire
• Clojure
• JavaScript V8 ( node.js )
• JRuby (un'alternativa da non dimenticare - a seconda della zona problematica JRuby potrebbe essere una scelta migliore o peggiore per ottenere un po 'di velocità da un'app di binari)
• Scala
• Giava
• C #

Nota che questo non significa che se usi framework X per Java sarà esattamente 200 volte più veloce di RoR. Ma la differenza di velocità misurata in questi benchmark ha un impatto importante sulle prestazioni complessive della tua app.

Rails ha un grave problema di prestazioni: ogni richiesta è messa in coda dietro a quella attualmente attiva, al contrario del threading come fanno la maggior parte dei framework o permettendo agli eventi di blocco di liberare altre richieste come fanno Node.js e Twister. Ciò significa che devi programmare per velocizzare i tempi di risposta, ma nella maggior parte dei casi è abbastanza facile da eseguire.

Penso che questo sia molto fuorviato. È possibile eseguire Rails in modalità multithread. Quando si esegue in modalità multithread, è necessario utilizzare solo librerie IO che rilasciano il GIL (ad esempio, "mysql2" gem), altrimenti diventa inutile.

Se stai usando jRuby, puoi semplicemente eseguire un singolo processo di rotaie in modalità multithread e utilizzare completamente tutta la potenza della CPU disponibile. Tuttavia, se si utilizza la risonanza magnetica (Ruby 1.8.xo 1.9.x), è necessario eseguire più processi per utilizzare pienamente le CPU, come nel caso di node.js.

• Rails ha molte bellezze che ti nascondono complessità. (Associazioni ActiveRecord, l'intero ciclo di vita di validazione / salvataggio, interpretazione dei dati di richiesta in base alle intestazioni fornite) All'inizio è fantastico. Man mano che cresci, scoprirai che inizi ad adattare la tua app al "modo di Rails" di gestire le cose - a volte questo è buono, a volte questo è innocuo, a volte è in realtà controintuitivo alla cosa che stai cercando di fare. Non tutte le tabelle del database devono essere modellate come oggetti, potrebbe essere necessario un passaggio di convalida altrove, ecc. Molti programmatori di Rails evitano di combattere il framework (che di solito è saggio), ma l'effetto a lungo termine di questo è ... tu porterà con te le abitudini di Rails in luoghi in cui non sono necessariamente richieste.

• La comunità ha l'abitudine di scrivere un software che viene definito "magico" - che memorizza nella cache librerie che funzionano magicamente! I / O evented che ti rende magicamente più veloce! Magia Magia! Quello che di solito è il caso qui è che viene fornita un'API molto interessante per una soluzione tecnica che è carente e sei stupito dagli esempi molto carini che la cosa fa ciò che intendi e solo successivamente scopri che copre una soluzione incompleta. Il ciclo di questo è piuttosto costante e impari a seguirlo, ma dovresti sicuramente familiarizzare con l'idea di leggere un sacco di codice da cui dipendi (una cosa buona!). Le soluzioni magiche della community di Rails non sono così magiche come potrebbe suggerire il README.

• Corollario sopra: più usi Rails, più dovresti leggere la sua fonte. Migliore sarà la comprensione degli interni della struttura, più felice sarà il lungo termine. Non proprio Rails specifico in questo, ma ti sto solo raccontando per esperienza qui. I nomi dei metodi a volte promettono qualcosa che in realtà non stai ricevendo.

• Il cultismo del carico è un problema con Rails, ma questo è probabilmente vero con tutte le comunità framework / lang. Sembra più pronunciato (per me) in Rails, e come tale tende a dare uno strano sguardo generazionale al codice Rails - mentre lavori su diversi progetti Rails, noterai alcune tendenze che tendono a tradire il periodo di tempo in cui sono stati creati . Come puoi immaginare da questa affermazione, la comunità tende a muoversi piuttosto velocemente adottando nuove soluzioni e deprecando quelle vecchie. Dovresti davvero essere in cima alle tue notizie su Ruby, solo per capire alcuni dei codici che sperimenterai quotidianamente.

• In generale, penso che il problema della concorrenza dei dati di solito non sia ben affrontato dalla comunità: man mano che si sviluppa un'app, quando si raggiunge il punto in cui è necessario condividere i dati, ripristinare fisicamente le modifiche remote e bloccare l'accesso ai dati, le soluzioni diventano un po 'più sintonizzato a mano, il che rende alcune delle cose belle di Rails che fai diventare confuse con le necessità tecniche di precisione. Rails non risolve tutti i problemi che potresti avere con un'app Web, immagino lo stia dicendo, e mentre i creatori certamente non predicano quel messaggio è facile farsi ingannare nel pensare che sia implicito.

A seconda di come la vedi, la velocità con cui Rails cambia può essere o meno un avvertimento per te. Le cose cambiano in qualche modo radicalmente di anno in anno man mano che più viene sottratto a ciò che fa schifo e ha bisogno di soluzioni.

Se sei in uno sviluppo attivo, avrai comunque il dito sul polso di questo.