Devo dare ascolto agli avvertimenti di Derek Sivers sulla migrazione da PHP a Rails?

Question

Come probabilmente sapete, Derek Sivers è il ragazzo che ha creato CD Baby e alla fine lo ha venduto per qualche soldo. Lo ha scritto in PHP in origine e poi in fondo alla sceneggiatura per riscriverlo in Rails. I suoi guai sono la leggenda:

7 reasons I switched back to PHP after 2 years on Rails

Questo articolo è uscito nel 2007, ma essendo di recente infatuato con Rails, Mi chiedo se qualcosa è cambiato per rendere Rails più di una scommessa saggia nel frattempo, o dovrei restare con la mia buona e vecchia brutta fidanzata PHP?

Qualcuno è d'accordo sul fatto che Rails non offra vantaggi significativi rispetto a PHP?

Answer 1

La riscrittura di un sito esistente è quasi sempre una cattiva idea. È difficile mettere il tuo cuore nella ricostruzione di una vecchia ruota. Ho lavorato a una riscrittura di un sito da CGI a un server di app Java e ho visto diversi programmatori uscire a causa di esso. Per uno, preferivano il loro vecchio modo di fare le cose e non volevano imparare Java. In secondo luogo, credo che non abbiano avuto l'entusiasmo di riscrivere una tonnellata di codice legacy che avevano mantenuto con riluttanza all'inizio. Molto meglio provare Rails su una nuova attività e vedere come funziona. Almeno allora lo stai mettendo in una posizione di parità con PHP nei concorsi di motivazione psicologica.

Answer 2

Austin Ziegler ha scritto una risposta interessante a tale articolo:

On Derek Siver’s Return to PHP…

L'essenza di esso è:

1. Derek ha scelto la tecnologia per le ragioni sbagliate. Lo ha scelto in parte in base alla campagna pubblicitaria di Rails, ma lui ha pensato che fosse come un proiettile d'argento che avrebbe magicamente reso la sua applicazione migliore solo perché è in Rails.

2. Rails non si adattava modello di applicazione di Derek per CD Baby, e modello di applicazione di Derek è più importante rispetto alla tecnologia di essere utilizzato, in quanto rappresenta un business capisce bene.

3. Ha ignorato i suoi esperti esistenti per la nuova tecnologia. Né lui né i suoi dipendenti di conoscevano Ruby da parte, forse, da giocare con esso. Questo non era una tecnologia che è stata considerata per essere appropriata dall'esperienza; questa era una tecnologia ritenuta appropriata dalla gestione (scusa Derek, potresti ancora sporcarti le mani con il codice , ma sei ancora in gestione).

4. Derek si avvicinò al progetto come un terra-up con tutto l'ambiente riscrivere con una distribuzione One Big Day, senza esaminare le modalità per eliminare gradualmente nel corso tempo. È quasi sempre possibile trovare i punti di interfaccia nel punto di interfaccia dove è possibile sostituire un pezzo rotto alla volta, . In fin dei conti, questo è ciò che le persone Rails avrebbero dovuto dirvi comunque: sostituire un'area alla volta, ciascuna con una diversa base di codici. Interfacciali come servizi REST-ful. Non fare in modo che dipenda da un singolo schema di database. di

Answer 3

Luke Crawford recent post about Muxtape offre un altro punto di vista.

Ho trascorso i miei primi 4 anni come sviluppatore web con PHP, ed era divertente all'epoca, ma quando ho iniziato a rendermi conto di quanto fosse gravemente inefficiente ho iniziato a cercare altrove. Avevo abbandonato il mio tradizionale background informatico per il web e le sue maggiori possibilità di design, ma per questo sapevo che c'era un modo migliore. Gli sviluppatori PHP non dovrebbero essere ridicolizzati tanto quanto spesso perché, francamente, consentono alle persone senza uno sfondo più rigoroso di realizzare cose sorprendentemente tecniche. Questo dovrebbe soddisfare i nerd, ma di solito si trasforma in una specie di debole 'machismo' invece. Ad ogni modo, questa insoddisfazione è iniziata alla fine del 2004 e Ruby on Rails era nuovo di zecca, stabile e rispondeva a tutte le limitazioni che avevo affrontato con il mio vecchio framework PHP MVC. Da allora ho fatto esclusivamente il lavoro su Rails.

In ogni caso, sarebbe difficile difendere l'affermazione categorica "Rails non offre vantaggi significativi rispetto a PHP".

PHP è un ottimo strumento per risolvere determinati problemi. Rails è un ottimo strumento per risolvere determinati problemi.

Answer 4

Ho esperienza con PHP & Ruby + Ruby on Rails (guadagnato con entrambi, ma non molto).

La libreria Ruby è molto meglio. La libreria di PHP è una raccolta di funzioni in uno spazio dei nomi globale con nomi e ordine di argomenti incoerenti. strpos vs str_repeat. Il primo argomento di strpos è la stringa grande e il secondo argomento è la stringa da trovare. Il primo argomento di explode è la stringa da dividere e il secondo argomento è la stringa grande. Questo è stato un grosso problema per me. Ho dovuto cercare un sacco di cose quando si utilizza PHP, ma non quando si utilizza Ruby. Posso ricordare le cose perché sono coerenti. I nomi dei metodi rendono chiaro l'ordine degli argomenti. Un altro: PHP strlen($str) vs count($arr) mentre in Ruby è solo anything.length.

Ruby il linguaggio è migliore di PHP. Ha delle chiusure, una buona OO, una bella sintassi (questo è soggettivo, ma hai bisogno di molta meno punteggiatura in Ruby, ed è quello che mi sbaglio più spesso).

Questa è la mia esperienza. Prova entrambi e scopri cosa funziona per te.

Answer 5

Essendo sia uno sviluppatore attivo di Rails che di PHP (con esperienza risalente al 2000), non sono assolutamente d'accordo con la dichiarazione.

Sostengo che Ruby offre vantaggi significativi rispetto a PHP e Rails è una struttura migliore di qualsiasi altra cosa nel mondo PHP. Molto di questo ha a che fare con il linguaggio stesso: Ruby può fare cose che semplicemente PHP non può fare. Una volta che si strappa l'eleganza della meta-programmazione, ti si apre un nuovo livello di espressività.

Answer 6

Disclaimer: Non sono affatto un esperto di Ruby o Rails.

Come qualcuno che è stato nel settore per quasi 15 anni vedo diversi segnali di avvertimento che mi rendono particolarmente nervoso su Ruby on Rails. Qui ignorerò la lingua perché una lingua è una lingua. Il rubino è un linguaggio moderno con chiusure, eccezioni, OO, ecc. Alcuni lo criticano in termini di prestazioni. Questi problemi sono in gran parte irrilevanti dal fatto che non influiscono sulle prestazioni del mondo reale (se ci vogliono 300ms per scaricare e visualizzare una pagina Web, a chi importa che i codici server impiegano 10, 20 o anche 30 ms per funzionare?) E transitori in quanto sono corretti nelle versioni successive (come sembra essere il caso di Ruby 1.9).

Ruby on Rails è uno stack pesante e chiuso. Intendo questo come un'osservazione non un'accusa. È strettamente integrato (incluso con Prototype) molto simile a JBoss Seam nel mondo Java (essendo strettamente integrato con JBoss/Hibernate e sì so che le pubblicazioni e gli articoli recenti hanno affrontato il problema di usarlo con, per esempio, Glassfish e un altro provider JPA)

Questa può essere una buona cosa e una cosa negativa. J2EE, ad esempio, essendo uno stack abbastanza aperto è stato la causa di molte innovazioni nell'industria del software nell'ultimo decennio, poiché quasi ogni parte di esso (in particolare EJB) è stata sostituita da diversi progetti che potrebbero essere inseriti insieme. E naturalmente lo era, se non il luogo di nascita di Spring, era certamente l'incubatore.

D'altra parte si hanno più stack chiusi come .Net, dove la loro natura chiusa consente una rapida innovazione, un modello che Microsoft ha (in generale) eccelso. In pochi anni, DirextX è passato dall'essere uno scherzo a battere completamente OpenGL come piattaforma di sviluppo di giochi perché qualsiasi sistema chiuso può evolvere molto più rapidamente di un sistema di standard aperti. È così che funziona.

L'altro punto rilevante che menzionerò è che negli ultimi anni c'è stato un passaggio verso gli ORM ("mappatura oggettuale-relazionale") in Java, .Net e altrove e questo fa parte dell'impeto dietro Rails. Ho già commentato in precedenza, ad esempio "Using an ORM or plain SQL?" e non ripeterò i punti nella loro interezza.

Come molti di voi saprebbero c'è una discrepanza tra l'oggetto e il mondo relazionale che gli ORM hanno cercato di collegare. Nell'ultimo anno o due mi sono occupato principalmente di Java (in particolare JPA).

Ora, quando si ponte tra due cose che non corrispondono si finisce con "leaky abstractions" (come Joel dirla):

Tutte le astrazioni non banali, in una certa misura , sono che perde.

Ora, ciò che aggiungerò è questo: esiste una relazione inversa tra la complessità dell'astrazione e quanto l'astrazione perde. Caso in questione: ibatis. Ibatis è un framework di persistenza estremamente leggero ma potente per Java e di cui sono un grande fan. Esso racchiude SQL in file esterni e in più mette molti moderni comportamenti ORM, come ad esempio:

• Pigro-carico di relazioni;
• Mappatura dei risultati;
• Raggruppamento di risultati su più livelli (qualcosa JPA non può fare); e
• Tipi discriminati (ovvero il tipo è determinato i dati).

vorrei stima che ibatis ha il 90-95% delle funzionalità di Hibernate con la sola complessità testa essendo runtime valorizzazione bytecode per il lazy loading via cglib (JPA lo fa allo stesso modo), con l'unico aspetto negativo che si devi scrivere le tue domande (e non considero un serio svantaggio, ma le opzioni possono variare).

Confrontalo con un fornitore JPA che fa affidamento sulla strumentazione, la tessitura a tempo di caricamento e i caricatori di classe non standard per implementare quella funzionalità aggiuntiva del 5-10% (e l'astrazione continua a perdere).

cui v'è una legge dei rendimenti decrescenti, quando si tratta di fare le cose meno che perde. A un certo punto, è meglio investire in una pompa di sentina di quanto non sia nel fissare ogni perdita nella barca.

Portare questo ritorno a Rails: l'argomento di astrazione che perde è il mio più grande problema con la filosofia Rails.

Che suona anche un campanello d'allarme per me è i commenti che si ottiene in messaggi come On Derek Siver’s Return to PHP… è: "Derek ha scelto la tecnologia per le ragioni sbagliate"

• : Attendere ... Non è RoR o un framework per applicazioni Web generiche o un facsimile piuttosto vicino? Stando così le cose, perché non puoi fare un sito come CDbaby in esso?
• "Rails non in forma modello di applicazione di Derek per CD Baby": In che modo?
• "ha ignorato i suoi esperti esistenti per la nuova tecnologia.": Aspetta ... non ha fatto assumere un esperto?
• "scusa Derek, si potrebbe ancora essere sporcarsi le mani con il codice, ma sei ancora di gestione": Sono d'accordo con il commento che questa citazione è "stupido" e aggiungerà che la sua fuorviante, irrilevanti e senza dubbio un uomo di paglia ;
• "Derek si avvicinò al progetto nel suo complesso-ambiente di terra-up riscrivere con una distribuzione One Big Day": probabilmente non è consigliabile, ma se siete disposti a spendere tempo e denaro su di esso, non vedo come un motivo per cui non puoi fare il sito in RoR.

Ora 5-7 anni fa, quando è stato EJB hyped You got critiche è basata su un sacco di cose e si otterrebbe difensori risoluti sostenendo:

• "Applicazione X non funziona con la Modello EJB ";
• "Non hanno capito come funziona EJB";
• "EJB non è per tutte le applicazioni" (preferiscono ammettere la sconfitta su questo piuttosto che affrontare il problema più clamoroso che non è proprio appropriato per non parlare di una buona idea per, beh, quasi nulla);
• ecc

Così i messaggi anti-Ruby (e soprattutto le loro confutazioni) tutti i suoni molto familiare per me.

Vale la pena ricordare l'anno vecchio rant "Rails is a Ghetto" di Zed Shaw, che è una parola strana di 6000 parole ("conflagrazione" è probabilmente una parola migliore) contro Rails. Alcune citazioni notevoli:

Questo è esattamente ciò che rende Rails un ghetto .Un gruppo di idioti un po 'addestrati phon che non si prendono mai la briga di sedersi sul e imparano davvero il computer scienza, erano troppo bravi per studiare nel college .

e

Notate come mi ci sono voluti pochi secondi per risposta. Questa singola affermazione in pratica significa che siamo stati tutti ingannati. L'applicazione principale di Rails che DHH ha creato necessario riavviare _400 volte al giorno. Questa è un'applicazione di produzione che non può rimanere in piedi per più di 4 minuti in media.

e (a perdite di memoria):

Questo è un motivo in più Rails è ghetto come l'inferno. Patch importanti come lo sono ignorate in gran parte dagli sviluppatori giapponesi , e mentre loro sono ragazzi molto carini, quanto sopra solo sa di ora amatoriale.

e

La parte migliore di tutta la faccenda è c'è potenzialmente 10 nuove web quadri che possono prendere on Rails. Inferno, Mongrel generato o aiutato 5 di quelli. Il mio preferito di questi framework è Merb che è letteralmente "Mongrel plus Erb", ma ora utilizza principalmente Erubis . Quello che mi piace di Merb è che ha dimostrato che è possibile creare un framework web sicuro Ruby con tutte le stesse idee di Rails e utilizzare la maggior parte di l'ingranaggio di Rails allo stesso tempo. Tuttavia, lo scherzo è che prima di Merb i deficienti Rails Core urlavano e in basso non è possibile rendere sicuro il thread Rails . Tuttavia, Ezra ha dimostrato che erano tutti sbagliati semplicemente scrivendo un Rails migliore rispetto a Rails e tutto grazie a Mongrel essere così facile da hackerare e lavorare con.

e:

Ruby on Rails è diventato pieno di gente come Koz, con Koz il più anziano dei smarties wannabe. Koz è stato fortunato e ha iniettato la sua codifica shitty in un buon progetto, lo ha incasinato, e poi lo ha bloccato alla sicurezza come modo per ottenere più controllo . Ovviamente, in realtà, non è lo a conoscere il codice di sicurezza ed è per questo che il suo codice sembra avere molti bug (vai a controllare la merda della data . Indizio: mesi non hanno sempre 30 giorni).

E, bene, continua.

Quindi immagino di poter riassumere in questo modo: Rails smells bad.

Answer 7

Rails è un buon framework, ma a volte le migrazioni sono idee sbagliate. Preferisco iniziare da zero, non puoi "tradurre" il codice PHP nel contesto di Rails. Non può essere fatto, principalmente a causa del linguaggio Ruby stesso e del pattern MVC.

Answer 8

Lo avrei riscritto in Rails, ma se ami PHP, vai con PHP. Non preoccuparti di quello che dicono gli altri, fai quello che ti si addice.

Answer 9

Nel mondo degli affari, il tempo è denaro - ea volte bisogna percorrere la strada della minor resistenza. Nessun ambiente, lingua, struttura, ecc. È perfetto. Impara e usa quello che vuoi e mantienilo in movimento!

Answer 10

Ho letto quel post di Derek Silvers. C'è qualcosa di strano in questo. Racconta la storia di un progetto che è sfuggito al controllo, trascinato per mesi e che alla fine è stato abbandonato. Incolpa questo sul framework Rails. Eppure non ha mai detto di cosa si trattava di Rails che ha causato il fallimento del progetto. L'articolo sarebbe molto più credibile se offrisse alcune informazioni solide, ma non menziona nemmeno un luogo specifico in cui Rails lo delude. Il più vicino che viene è quello di dire che i loro "bisogni" (?) Si sono scontrati con le preferenze di Rails (quali? Come?)

Nel frattempo, persone di tutto il mondo (incluso me stesso) stanno implementando applicazioni Web complesse in quantità ragionevole di tempo usando Ruby on Rails.

Data la mancanza di dettagli o di qualsiasi informazione tecnica specifica, nel pezzo di Derek, , è possibile che il progetto non sia riuscito per un numero qualsiasi di motivi che non hanno nulla a che fare con Rails.

La domanda iniziale era "dovrei prestare attenzione agli avvertimenti di Derek Silvers sulla migrazione da PHP a Rails?" La mia risposta sarebbe no, i suoi "avvertimenti" equivalgono a un vago aneddoto con zero prove a sostegno. È perfettamente sicuro ignorarli.

Dovresti reimplementare un'applicazione PHP in Rails? Questa è un'altra domanda. Non c'è una risposta generale a quello. Dipende interamente dalle circostanze.

Answer 11

La migliore risposta sarà lo stesso dell'autore. Sembra di fare un altro ritorno a RoR !:

Premessa

mia ex società (CD Baby) è stato uno dei prima di passare a gran voce per Ruby on Rails , e quindi ancora più forte interruttore torna a PHP (Google me per leggere sul dramma). Questo libro di Michael Hartl venuto così altamente raccomandato che ho dovuto provare, e Ruby on Rails tutorial è quello che ho usato per interruttore di nuovo a Rails nuovo.

http://railstutorial.org/book

E scrematura proprio sito, infatti, dimostra il suo ritorno a RoR:

Invece di cercare di insegnare a tutti il ​​mio framework PHP unico, tutti progetti standardizzare su Rails 3 .

http://thoughts.pro/

I ragazzi che sono passati da Rails a PHP solo seguendo il famoso articolo di lui, ora è il momento di tornare su Rails, ancora!