Documental sobre Ruby on Rails [video]
(youtube.com)- El punto de partida de Rails surgió durante el desarrollo de Basecamp en 37signals, cuando David Heinemeier Hansson creó él mismo en Ruby las herramientas que necesitaba
- La colaboración entre Jason Fried y David empezó en 2001 con una pregunta sobre PHP en el blog de 37signals, y derivó en el desarrollo del backend de Basecamp y la extracción de Rails
- Rails buscó combinar dentro de Ruby la sensación de desarrollo web rápido de PHP con el rigor del diseño orientado a objetos al estilo Java, y su forma esencial se creó entre el verano de 2003 y el lanzamiento de Basecamp en febrero de 2004
- Su difusión inicial se apoyó en un producto real como Basecamp, una demo de 15 minutos, comparaciones con Java y la reputación de 37signals; también se formaron los primeros colaboradores, como Jamis Buck, Jeremy Kemper y Tobias Lütke, y el Rails core team
- Tras publicarse como open source con licencia MIT, Rails mantuvo su rumbo de permitir que equipos pequeños construyan grandes aplicaciones web, impulsado por casos a gran escala como Shopify y GitHub y por una comunidad que lleva 20 años activa
El encuentro entre 37signals y David Heinemeier Hansson
- En 1999 o 2000, Jason Fried dirigía una empresa de diseño web llamada 37signals y estaba creando en PHP un proyecto paralelo llamado Single File, una base de datos online de libros
- Había avanzado bastante aprendiendo PHP con libros, pero se encontró con partes donde se trabó; como en esa época no existían espacios de respuestas como StackOverflow, pidió ayuda online
- David Heinemeier Hansson, que trabajaba en la industria web en Copenhague, Dinamarca, leía con regularidad el blog de 37signals, Signal vs. Noise, y en 2001 respondió una pregunta de programación de Jason
- La respuesta de David fue muy detallada, y Jason sintió que no era un simple comentario, sino una verdadera intención de ayudar
- Luego David revisó todo el código de Jason y dijo algo como “esto no está muy bien, empecemos de nuevo”; la colaboración entre ambos comenzó en ese punto
- Trabajaron de forma remota durante un tiempo hasta que se conocieron en persona por primera vez cerca del Hancock Building, en Chicago, y Jason recuerda que la ropa blanca de David llamaba mucho la atención
Rails nació mientras construían Basecamp
- 37signals gestionaba proyectos de clientes por email y sentía que era difícil seguir las versiones de archivos, las tareas pendientes y el estado de preparación para un lanzamiento, así que en 2003 decidió crear una herramienta de gestión de proyectos para uso interno
- En ese momento David era estudiante de una escuela de negocios en Copenhague, por lo que solo podía trabajar unas 10 horas por semana, y como compensación por desarrollar el backend de Basecamp prefería una laptop Apple y equipos antes que dinero
- David conoció Ruby a través de textos de Martin Fowler y Dave Thomas, y le atrajo que el código de este lenguaje creado en Japón se leyera casi como pseudocódigo
- Antes de Basecamp, 37signals usaba PHP en sus trabajos, pero David decidió construir el backend de Basecamp en Ruby, y Jason confió en esa elección
- La combinación que David buscó en Rails tenía dos elementos
- La inmediatez para poner algo en la web rápidamente, como en PHP
- El rigor intelectual del diseño orientado a objetos y los patrones que veía en Java
- En esa época Ruby no tenía muchas bibliotecas o frameworks que ayudaran con desarrollo web y acceso a bases de datos, así que David creó él mismo las herramientas que necesitaba para construir Basecamp
- Entre el verano de 2003 y el lanzamiento de Basecamp en febrero de 2004 se formó el núcleo de Rails; después del lanzamiento de Basecamp, David refinó el código y la documentación durante unos 6 meses y publicó Rails en 2004
Publicación inicial, marketing polémico y formación del core team
- Mientras preparaba la publicación de Rails, David consideraba importante no solo el código, sino también la calidad de la documentación, y juzgó que la primera versión debía ser lo suficientemente buena
- Cuando Rails empezó a llamar la atención, David intentó defender con fuerza la dirección del framework y dijo “no” a las demandas que no quería aceptar
- En una de las primeras conferencias de Rails, David usó una diapositiva que decía “F()c% You” como respuesta a exigencias injustificadas y amenazas de fracaso, dejando clara su postura de que el open source no es una relación comercial y que los usuarios no pueden dictar la dirección
- Al mismo tiempo, Rails creció incorporando buen trabajo enviado por miles de colaboradores, y no es que David rechazara el feedback o las contribuciones en sí
- En la International Ruby Conference de 2004, David presentó Rails enfocándose menos en una demostración de código y más en las razones por las que lo había creado y en su objetivo de ofrecer una mejor experiencia a los programadores
- Durante aproximadamente el primer año, solo David hacía commits directos al código, y los parches se recibían por email, Wiki y otros medios
- Luego dio acceso al codebase a personas que habían contribuido mucho, formando el Rails core team; Jamis Buck, Jeremy Kemper, Marcel Molina, Scott Barron, Sam Stephenson y Michael Koziarski participaron como committers iniciales
- 37signals contrató a algunas personas del Rails core team y a algunos contribuidores de Rails, y Jamis Buck se convirtió en el primer programador contratado por 37signals en la etapa en que Basecamp estaba creciendo
La difusión creada por un producto real y su ecosistema
- La reputación de 37signals y el producto exitoso real que era Basecamp tuvieron un papel importante en la atención inicial que recibió Rails
- David creía que, para dar a conocer una herramienta basada en un lenguaje menos conocido como Ruby, hacía falta un grito fuerte más que una presentación discreta, y creó materiales polémicos que comparaban una implementación en Java con una implementación en Rails
- En la difusión de Rails actuaron en conjunto la demo de 15 minutos, los clientes pagos y el crecimiento de Basecamp, y el código que realmente funcionaba
- Tobias Lütke usó Rails muy temprano cuando estaba por iniciar una empresa en Canadá y construía una tienda online de snowboard; ese proyecto, Snowdevol, más tarde derivó en Shopify
- Tobias recuerda que gracias a Rails pudo crear el sistema solo, y que en ese momento era más productivo que otros equipos que construían tiendas online
- Shopify es una empresa influenciada por Rails; incluso hoy usa la versión más reciente de Rails, la mayor parte de su codebase está en Ruby y su estructura básica de carpetas es igual a la de una app Rails común
- Las críticas de que Rails “no escala” existieron desde el inicio, pero Basecamp daba soporte a usuarios reales y, aun antes de casos como Shopify y GitHub, se siguió argumentando que Rails había sido escalable desde el principio
- Shopify se presenta como un servicio a gran escala que representa alrededor del 10% del comercio electrónico mundial, y también se mencionan experiencias de quienes dicen no saber qué escala sería imposible de manejar con Rails
Lanzamientos, fusión con Merb y una dirección mantenida durante 20 años
- Desde el principio, que Rails se publicara como open source fue una elección natural, y David consideraba que, como la base que hizo posible su trabajo web eran herramientas open source, también debía compartir su propia caja de herramientas
- También hubo discusiones sobre cobrar por Rails o mantenerlo como una ventaja competitiva exclusiva, pero David decidió que el open source con licencia MIT era importante y que haría de Rails algo muy exitoso
- La herramienta creada por Jamis Buck para desplegar Basecamp más tarde se consolidó con el nombre Capistrano
- El flujo de lanzamientos principales de Rails fue el siguiente
- Rails 1.0 fue un punto de partida importante
- Rails 1.2 se considera una versión inicial estable y el momento en que mostró la apariencia de un framework web maduro
- En diciembre de 2007, Rails 2.0 trajo sesiones basadas en cookies, named scopes y más
- En marzo de 2009, Rails 2.3 se trató como un lanzamiento con las herramientas que un desarrollador web moderno necesitaba, desde apps pequeñas hasta grandes
- En la época de Rails 2.3, jQuery estaba apareciendo, y Rails intentó crear espacio para absorber la energía del mundo JavaScript
- Más tarde, el framework web Ruby Merb apareció como un competidor más rápido, liviano y con menos responsabilidades, y los desarrolladores de Rails vieron cosas que aprender de esa dirección
- Rails 3.0 derivó en la fusión con Merb, lo que requirió un gran trabajo para rediseñar el interior de Rails como una estructura configurable, recombinable y modular
- La comunidad de Rails se enfocó en permitir que incluso personas sin formación formal en ciencias de la computación o programación pudieran crear aplicaciones web y construir una carrera
- Rails buscó bajar la barrera de entrada y ofrecer luego un camino para convertirse en programadores de alto nivel dentro de empresas o industrias
- Como dice actualmente el sitio web de Rails, Rails es un framework que permite que equipos pequeños vayan de “Hello World a una IPO”, y se considera que la comunidad y la calidad del codebase están hoy en su mejor momento
1 comentarios
Opiniones de Hacker News
Disfruté mucho este documental, y la historia personal de Toby de Shopify muestra muy bien la perspectiva de un framework de una sola persona.
“From Hello World to IPO” también estuvo bueno, y me pareció especialmente notable el comentario de que, sin importar si abres la app de Rails más grande o una app nueva, la estructura es casi la misma.
En el entorno actual, donde se mezclan APIs y stacks de frontend, esa consistencia no siempre está garantizada.
Los cambios recientes en Rails están reforzando aún más una base sólida, y además de Kamal también se está trabajando en cosas como Solid Cache y Solid Queue para facilitar la infraestructura.
En el frontend, Turbo Morphing también está activo, y en apps móviles también Turbo Native y Strada.
Ya actualicé a 7.1 y tengo una app móvil hecha con Turbo Native en producción; también me entusiasma cambiar la caché de Redis por Solid Cache para simplificar más y cachear por más tiempo.
Da gusto ver que la comunidad de Rails sigue activa y que miembros actuales y anteriores del equipo core siguen profundamente conectados con el framework.
Nunca he usado Rails, pero algo que de verdad odio del ecosistema de Node.js es la falta de convenciones claras.
Incluso usando el mismo framework, la estructura siempre cambia y termina siendo un desastre; la excepción sería Next.js, aunque eso está más cerca del lado frontend.
También están apareciendo muchas herramientas de desarrollo alrededor de Ruby y Rails, así que espero más cambios positivos en Rails 8.0 y Ruby 3.4.
Me dio risa enterarme de que es el fundador de Shopify y que tiene un patrimonio de 5.500 millones de dólares.
Los desarrolladores tienden a subestimar mucho este aspecto de RoR.
No solo facilita el onboarding, sino que también reduce mucho el bikeshedding.
Puede que MVC no sea lo mejor para todo, pero en la mayoría de los casos es suficientemente bueno.
Tengo que ver esto más tarde hoy.
He probado varios frameworks como Laravel, ExpressJS, MeteorJS, Django, Flask, etc., y cada uno tenía sus pros y contras, pero siempre terminaba abandonando después de seguir tutoriales o intentar hacerlo a mi manera.
Empecé con Rails hace tres días y durante el fin de semana pude armar rápidamente un MVP para mostrárselo a un colega.
Rails me permitió concentrarme en qué debía hacer la app, no en cómo implementarla, y recién ahora entiendo por qué a la gente le gusta tanto.
En Rails soy realmente productivo.
Desde hace mucho, mi mayor queja ha sido que cuando te sales de las convenciones falta documentación o hay mucha información contradictoria.
Encontrar y entender la “forma bendecida” puede ser muy difícil; por suerte, ChatGPT es bastante bueno para darte un punto de partida en estos temas.
Fue un documental realmente excelente.
He usado Rails durante los últimos años, y es muy productivo para que equipos pequeños construyan productos e implementen lógica de negocio siguiendo patrones bien establecidos.
Si te interesa cómo es la estructura real de una app Rails, recomiendo ver el codebase de Jumpstart. Es un buen recurso para aprender cómo estructurarla.
https://jumpstartrails.com/
Como alternativa, Bullet Train también está bastante bien, pero agrega muchas bibliotecas personalizadas que son difíciles de considerar como “la forma Rails”.
https://bullettrain.co/
Creo que este documental sobre Rails y el documental sobre Elixir no alcanzaron a abarcar mucho.
Son tan cortos que apenas alcanzan a plantear la historia de sus orígenes antes de terminar, y cierran antes de llegar a los puntos que podrían emocionar.
Más que mostrarle a la comunidad o a gente de fuera de la comunidad lo increíbles que son estas tecnologías, parecían más orientados a alimentar el ego de quienes aparecen.
Me gustaría que hicieran un documental de 1 hora y 30 minutos para Elixir y otro para Rails, y que fueran más allá de las partes donde se elogian entre sí, mostrando años de dificultades, distintas formas de uso en varias empresas, etc.
Es decir, si tomaran el formato de Indie Game: The Movie, creo que sería mucho más atractivo; ojalá hubiera más buenos documentales sobre software.
Hubo muchos pequeños fragmentos históricos difíciles de encontrar en otro lado: lo particular que era el enfoque de David, cómo se formó el equipo de Rails a través de Toby y otras personas, cómo se fusionó con otros frameworks, etc.
Podría haber sido más largo, pero que lo hayan hecho así ya es excelente.
Lo vi, pero creo que no mostró lo suficiente lo que Rails logró hacer.
Ruby on Rails cambió el paradigma de construir aplicaciones web, alejándose del enfoque centrado en archivos como PHP, JSP y WebForms, hacia rutas y el patrón MVC; hoy casi cualquier framework web serio tiene esta forma de trabajar.
El documental no habló de eso, pero aun así fue entretenido de ver.
Dicho eso, casi da pena poner a Struts y Rails en la misma frase, porque Rails logró muchísimo más.
Las figuras legendarias de los primeros tiempos de Rails allanaron el camino para la forma moderna de desarrollar apps web.
Incluso se puede decir que en el desarrollo web hay un antes y después de Rails.
Al leer los comentarios, suena como si Rails estuviera volviendo a ganar algo de popularidad, dejando atrás la imagen de ser simplemente un framework aburrido pero sólido.
Rails me recuerda a una versión de mí que construía cosas de forma más divertida y desprolija, y a otra época que encajaba con mi camino de entonces.
Lo que realmente valoro de Rails es su visión fuerte, y que no se convirtió en otro framework inflado para crear aplicaciones “enterprise”.
Aunque es un framework de 20 años, no tiene miedo de cambiar con audacia para adaptarse a los tiempos, y todavía se ve punk comparado con otras cosas.
Me dio calidez recordar mi propia historia de cuando empecé a usar Rails hace 20 años.
https://twitter.com/buger/status/1723040883325460818
Entre 2015 y 2019 trabajé en una app Rails muy grande en producción, y como resultado terminé amando Rails pero odiando Ruby.
Si existiera un Rails en TypeScript o Go, no se me ocurriría ninguna razón para usar otra cosa en el backend de una app web.
Rails Console es una de las mejores herramientas de productividad que he usado.
Con TypeScript quizá podría hacerse usando el REPL existente de Node, pero la gran razón por la que la consola de Rails es tan útil, al final, es Ruby en sí.
Los documentales de Honeypot son realmente buenos; los recomiendo mucho.