¿Debo hacer caso a las advertencias de Derek Sivers sobre migrar de PHP a Rails?

Question

Como probablemente sepa, Derek Sivers es el tipo que creó CD Baby y finalmente lo vendió por mucho dinero. Lo escribió en PHP originalmente y luego en el camino establecido para volver a escribirlo en Rails. Sus problemas son parte de la leyenda:

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

Ese artículo se publicó en 2007, pero recién se enamora de rieles, me pregunto si algo ha cambiado para hacer rieles más de una apuesta inteligente, mientras tanto, o debería quedarme con mi buena y vieja novia fea de PHP?

¿Alguien acepta que Rails no ofrece ninguna ventaja significativa sobre PHP?

Answer 1

Volver a escribir un sitio existente es casi siempre una mala idea. Es difícil poner tu corazón a recauchutar una rueda vieja. Trabajé en una reescritura de un sitio de CGI a un servidor de aplicaciones Java y vi que varios programadores renunciaron debido a eso. Por un lado, preferían su antigua forma de hacer las cosas y no querían aprender Java. En segundo lugar, creo que no tenían el entusiasmo de volver a escribir una tonelada de código heredado que habían estado manteniendo de mala gana para empezar. Es mucho mejor probar Rails en una nueva tarea y ver cómo le va. Al menos entonces lo está poniendo en pie con PHP en el sorteo de motivación psicológica.

Answer 2

Austin Ziegler escribió una interesante respuesta a ese artículo:

On Derek Siver’s Return to PHP…

El quid de la cuestión es:

1. Derek escogió la tecnología por las razones equivocadas. Lo eligió parcialmente según el alboroto de Rails, pero lo imaginó como una bala de plata que mejoraría mágicamente su aplicación simplemente porque está en Rails.

2. Carriles no encajaba modelo de aplicación de Derek como CD Baby, y el modelo de solicitud de Derek es más importante que la tecnología sea utiliza, ya que representa un negocio entiende bien.

3. Hizo caso omiso de sus expertos existentes para la nueva tecnología. Ni él ni sus empleados conocían a Ruby aparte, tal vez, jugando con ella. Este no era una tecnología que se consideró ser apropiado por experiencia; esta fue una tecnología considerada apropiada por administración (lo siento, Derek, es posible que aún se esté ensuciando las manos con el código , pero todavía eres administrador).

4. Derek se acercó al proyecto en su conjunto y el medio ambiente de la planta hasta reescribir con un despliegue Un gran día, sin considerando maneras de fase, en más de tiempo. Casi siempre es posible encontrar puntos de interfaz donde puede reemplazar una pieza rota a la vez. En última instancia, esto es lo que la gente de Rails debería decirle de todos modos: reemplace un área a la vez, cada uno con una base de código diferente. Interfazelos como servicios REST-ful. No haga que dependan de un solo esquema de base de datos. de

Answer 3

Lucas Crawford recent post about Muxtape ofrece otra perspectiva.

pasé mis primeros 4 años como desarrollador web usando PHP, y fue muy divertido en el momento, pero cuando empecé a darse cuenta de lo grave que era ineficaz empecé a buscar en otro lugar. Había abandonado mi experiencia tradicional en informática para la web y sus mayores posibilidades de diseño, pero debido a esto sabía que había una mejor manera. Los desarrolladores de PHP no deberían ser ridiculizados tanto como a menudo porque, francamente, les permite a las personas sin un trasfondo más riguroso lograr cosas increíblemente técnicas. Esto debería satisfacer a los nerds, pero por lo general se convierte en algo así como un "machismo" débil. De todos modos, esta insatisfacción comenzó a finales de 2004 y Ruby on Rails era completamente nueva, estable, y abordaba todas las limitaciones que había confrontado con mi viejo framework PHP MVC de cosecha propia. He hecho el trabajo de Rails exclusivamente desde entonces.

En cualquier caso, sería difícil defender la declaración categórica "Rails no ofrece ninguna ventaja significativa sobre PHP".

PHP es una gran herramienta para resolver ciertos problemas. Rails es una gran herramienta para resolver ciertos problemas.

Answer 4

Tengo experiencia con PHP & Ruby + Ruby on Rails (dinero ganado utilizando ambos, pero no mucho).

La biblioteca de Ruby es mucho mejor. La biblioteca de PHP es una colección de funciones en un espacio de nombres global con nombres incoherentes y orden de argumento. strpos contra str_repeat. El primer argumento de strpos es la cadena grande y el segundo argumento es la cadena que se debe buscar. El primer argumento de explode es la cadena para dividir y el segundo argumento es la cadena grande. Este fue un gran problema para mí. Tuve que buscar muchas cosas cuando uso PHP, pero no cuando uso Ruby. Puedo recordar cosas porque son consistentes. Los nombres de los métodos hacen que el orden de los argumentos sea claro. Otro: PHP strlen($str) vs count($arr) mientras que en Ruby es solo anything.length.

Ruby el lenguaje es mejor que PHP. Tiene cierres, buen OO, buena sintaxis (esto es subjetivo, pero necesitas mucha menos puntuación en Ruby, y eso es lo que más me equivoco).

Esa es mi experiencia. Pruebe ambos y vea lo que funciona para usted.

Answer 5

Como un desarrollador activo de Rails y PHP (con experiencia que se remonta a 2000), estoy totalmente en desacuerdo con la afirmación.

Sostengo que Ruby ofrece ventajas significativas sobre PHP, y Rails es un mejor marco que cualquier cosa en el mundo de PHP. Mucho de esto tiene que ver con el lenguaje en sí: Ruby puede hacer cosas que PHP simplemente no puede hacer. Una vez que asimilas la elegancia de la metaprogramación, se te abre un nuevo nivel de expresividad.

Answer 6

Descargo de responsabilidad: De ninguna manera soy un experto en Ruby and Rails.

Como alguien que ha estado en la industria por casi 15 años, veo varias señales de advertencia que me ponen nervioso sobre Ruby on Rails específicamente. Voy a ignorar el idioma aquí porque un idioma es un idioma. Ruby es un lenguaje moderno con cierres, excepciones, OO, etc. Algunos lo critican con respecto al rendimiento. Estos problemas son en gran medida irrelevantes ya que no afectan el rendimiento en el mundo real (si se tardan 300ms en descargar y mostrar una página web, ¿a quién le importa que los códigos del servidor tarden 10, 20 o incluso 30ms en ejecutarse?) Y transitorios. se arreglan en versiones posteriores (como parece ser el caso con Ruby 1.9).

Ruby on Rails es una pila cerrada y pesada. Quiero decir esto como una observación, no como una acusación. Está estrechamente integrado (incluso con Prototype) al igual que JBoss Seam en el mundo de Java (se integra estrechamente con JBoss/Hibernate y sí sé que las últimas publicaciones y artículos han abordado el tema de usarlo con, digamos, Glassfish y otro proveedor de JPA)

Esto puede ser algo bueno y algo malo. J2EE, por ejemplo, al ser una pila bastante abierta fue la causa de mucha innovación en la industria del software en la última década, ya que casi todas las piezas (notablemente EJB) fueron reemplazadas por diferentes proyectos que podían ser ranurados juntos. Y, por supuesto, si no fue el lugar de nacimiento de Spring, sin duda fue la incubadora.

Por otro lado, tiene más pilas cerradas como .Net, donde su naturaleza cerrada permite una rápida innovación, un modelo que Microsoft (en general) ha destacado. En unos pocos años, DirextX pasó de ser una broma a derrotar por completo a OpenGL como una plataforma de desarrollo de juegos porque cualquier sistema cerrado puede evolucionar mucho más rápido que un sistema de estándares abiertos. Así es como funciona.

El otro punto relevante que mencionaré es que en los últimos años ha habido un movimiento hacia los ORM ("mapeo relacional de objetos") en Java, .Net y en otros lugares, y esto es parte del ímpetu detrás de Rails. He comentado esto anteriormente, por ejemplo, "Using an ORM or plain SQL?" y no voy a reiterar esos puntos en su totalidad.

Como la mayoría de ustedes sabría que hay un desajuste entre el objeto y los mundos relacionales que los ORM han tratado de salvar. En el último año o dos he tratado esto principalmente a través de Java (JPA específicamente).

Ahora cuando puente entre dos cosas que no coinciden se termina con "leaky abstractions" (como Joel lo puso):

Todas las abstracciones no triviales, hasta cierto grado , son fugas.

Ahora lo que añadiré es esto: existe una relación inversa entre la complejidad de la abstracción y cuán permeable es la abstracción. Caso en cuestión: ibatis. Ibatis es un framework de persistencia extremadamente ligero pero potente para Java y del que soy un gran admirador. Se envuelve SQL en archivos externos y por encima de eso pone muchos comportamientos ORM moderna, tales como:

• Lazy-carga de las relaciones;
• Correlación de resultados;
• Agrupación de resultados en varios niveles (algo JPA no puede hacer); y
• Tipos discriminados (es decir, el tipo se determina con los datos).

yo estimaría que ibatis tiene 90-95% de la funcionalidad de hibernación con la única complejidad estar por encima de tiempo de ejecución de mejora de código de bytes para la carga lenta a través de cglib (APP hace de la misma manera) con el único inconveniente que se tiene que escribir sus propias consultas (y no lo considero una desventaja seria pero las opiniones variarán).

Compárelo con un proveedor de JPA que confíe en la instrumentación, el entrelazado en tiempo de carga y los cargadores de clase no estándar para implementar esa funcionalidad extra del 5-10% (y la abstracción sigue teniendo fugas).

Así que no es una ley de los rendimientos decrecientes cuando se trata de hacer las cosas menos permeable. En algún momento es mejor que invierta en una bomba de achique que en la reparación de cada fuga en el barco.

Llevando esto a rieles: el argumento de la abstracción con fugas es mi mayor problema con la filosofía de los carriles.

Lo que también hace sonar alarmas para mí es los comentarios que recibe en los mensajes como On Derek Siver’s Return to PHP… es: "Derek escogió la tecnología por las razones equivocadas"

• : espera ... no es RoR o bien una marco de aplicación web de propósito general o un facsímil bastante cercano? Siendo ese el caso, ¿por qué no puedes hacer un sitio como CDbaby en él?
• "Los rieles no se ajustaban al modelo de aplicación de Derek para CD Baby": ¿Cómo es eso?
• "Él ignoró sus expertos existentes para la nueva tecnología.": Espere ... ¿no contratar a un experto?
• "lo siento Derek, se le podría ensuciarse las manos con el código, pero todavía estás gestión": Estoy de acuerdo con el comentario de que esta cita es "estúpida" y añade que su engañosa, irrelevante y podría decirse que un hombre de paja ;
• "Derek se acercó al proyecto en su conjunto y el medio ambiente de la planta hasta volver a escribir con un despliegue Un gran día": podría decirse que no es recomendable, pero si usted está dispuesto a gastar tiempo y dinero en él, no lo veo como una razón por la cual no puedes hacer el sitio en RoR.

Ahora hace 5-7 años, cuando EJB fue exagerada que tiene críticas de la misma sobre la base de un montón de cosas y se obtendría defensores incondicionales argumentando:

• "Aplicación X no encajaba en el Modelo EJB ";
• "No entendieron cómo funciona EJB";
• "EJB no es para todas las aplicaciones" (que prefieren aceptar la derrota en este caso de enfrentar el problema más evidente de que en realidad no es apropiada ni mucho menos una buena idea para, así, casi cualquier cosa);
• etc.

Así los mensajes anti-Ruby (y especialmente sus réplicas) todas suena muy familiar para mí.

Vale la pena mencionar el viejo rant "Rails is a Ghetto" de Zed Shaw, que es una palabra extraña de 6000 ("conflagración" es probablemente una mejor palabra) en contra de Rails. Algunas citas notables:

Esto es exactamente lo que hace que Rails sea un ghetto.Un grupo de medio entrenados ex idiotas PHP que nunca se molestan en sentarse y realmente aprenden la ciencia de la computadora que eran demasiado buenos para estudiar en la universidad .

y

Observe cómo me tomó unos segundos para respuesta. Esta única declaración significa básicamente que todos nos engañamos. La aplicación principal de Rails que DHH creó requirió reiniciar _400 veces/día. Esa es una aplicación de producción que no puede permanecer activa durante más de 4 minutos en promedio.

y (en pérdidas de memoria):

Esa es una razón más Carriles es gueto como el demonio. Parches importantes como el de arriba son ignorados por los desarrolladores japoneses , y aunque son muy buenos chicos, el anterior solo huele a hora amateur.

y

La mejor parte de todo el asunto es que hay potencialmente 10 nuevas web marcos que pueden tener sobre rieles. Infierno, Mongrel generó o ayudó a 5 de esos. Mi favorito de esos frameworks es Merb que es literalmente "Mongrel plus Erb" pero ahora usa principalmente Erubis . Lo que me encanta de Merb es que demostró que se podía hacer un veloz hilo web marco de trabajo de Ruby seguro con todas las mismas ideas que Rails y usar la mayor parte de el equipo de Rails al mismo tiempo. Sin embargo, la broma es que antes de Merb los idiotas de Rails Core gritarían y no se puede hacer que Rails thread sea seguro. Ezra sin embargo los probó a todos mal escribiendo simplemente un mejor Rails que Rails y todo gracias a Mongrel por ser tan fácil de hackear y trabajar.

y:

Ruby on Rails se ha llenado de gente como Koz, con Koz el más antiguo de los sabelotodos aspirantes. Koz tuvo suerte en el mejor de los casos e inyectó su código de mierda en un buen proyecto, lo jodió, y luego se adhirió a la seguridad como la forma de obtener más control . Por supuesto que en realidad no sabe acerca de la codificación segura por lo que su código parece tener muchos de los errores (ver el fecha analizando mierda. Pista: los meses no siempre tienen 30 días).

Y, bueno, continúa.

Así que supongo que puedo resumirlo así: Rails smells bad.

Answer 7

Rails es un buen marco, pero a veces las migraciones son malas ideas. Prefiero comenzar desde cero, no se puede "traducir" el código PHP en el contexto de Rails. Simplemente no se puede hacer, sobre todo por el propio lenguaje Ruby y el patrón MVC.

Answer 8

Lo volvería a escribir en Rails, pero si te encanta PHP, ve con PHP. No te importa lo que otras personas digan, haz lo que te plazca.

Answer 9

En los negocios, el tiempo es dinero, ya veces hay que seguir el camino de la menor resistencia. Ningún entorno, lenguaje, marco, etc. es perfecto. ¡Aprenda y use lo que quiera y manténgalo movin homeboys!

Answer 10

Leí esa publicación de Derek Silvers. Hay algo extraño en esto. Él cuenta la historia de un proyecto que se salió de control, se prolongó durante meses y finalmente tuvo que ser abandonado. Él culpa a esto en el marco de Rails. Sin embargo, nunca dice qué fue lo que causó que el proyecto fallara. El artículo sería mucho más creíble si ofrece alguna información sólida, pero no menciona ni siquiera un lugar específico donde Rails lo defraude. Lo más cerca que llega es decir que sus "necesidades" (?) Chocaron con las preferencias de Rails (¿cuáles? ¿Cómo?)

Mientras tanto, personas de todo el mundo (incluyéndome a mí) están implementando aplicaciones web complejas en cantidades razonables de tiempo usando Ruby on Rails.

Dada la falta de detalles, o realmente cualquier información técnica específica, en el artículo de Derek, , podría ser que el proyecto fallara por cualquier cantidad de razones que no tengan nada que ver con Rails.

La pregunta original era "¿Debería prestar atención a las advertencias de Derek Silvers sobre migrar de PHP a Rails?" Mi respuesta sería no, sus "advertencias" equivalen a una vaga anécdota sin evidencia de respaldo. Es perfectamente seguro ignorarlos.

¿Debería volver a implementar una aplicación PHP en Rails? Esa es otra pregunta. No hay una respuesta general a eso. Depende completamente de las circunstancias.

Answer 11

La mejor respuesta será la del autor. Él parece tener otro regreso a RoR !:

Prólogo

Mi empresa anterior (CD Baby) fue uno de los primeros en cambiar en voz alta para Ruby on Rails , y luego con más fuerza conmutador volver a PHP (Google me para leer sobre el drama). Este libro de Michael Hartl llegó tan altamente recomendado que que tenía que probarlo, y Ruby on Rails tutorial es lo que solía interruptor de nuevo a Rails nuevo.

http://railstutorial.org/book

y rozando su propio sitio, de hecho, demuestra su regreso a RoR:

En lugar de tratar de enseñar a todos mi PHP marco único, todos proyectos contribuirán a la normalización en los carriles 3 .

http://thoughts.pro/

Los chicos que cambiaron de Rails a PHP simplemente siguiendo el famoso artículo suyo, ¡ahora es el momento de volver a Rails, otra vez!