Magma Conf 2014, Lucha Libre on Stage, different opinions about Rails and Software Craftsmanship

2. Los Técnicos
No Photoshop was !
needed in this pictures

3. Los Rudos

4. Primera Caída

5. Client Side
vs
HTML Render, Server Side

6. HTML Render, server side (Rudos
Manuel) vs client side (Techs Edwin)
• Es lento en el servidor pero ligero para los clientes.
• Hay mas problemas de compatibilidad.
• Exploradores viejos y compus lentas les cuesta mucho mas trabajo hacer el rendering del DOM.
• EL DOM ES LEEEEEENTOOOOO porque los años de falta de estandares y lo complejo de las
implementaciones de CSS.
• Server side es mas para layouts sencillos sin mucha interactividad.
• Implementar cuestiones altamente interactivas con server-side rendering es incomodo, raro,
monstruoso etc.
• En "client side rendering" (por lo general) se duplica logica de negocios, validaciones etc.
• La logica de negocios en un server side render acopla la vista con el modelo (por lo general).
• Realct JS rulea! (http://jlongster.com/Removing-User-Interface-Complexity,-or-Why-React-is-
Awesome)

7. API + JS Thick client
vs
Full Rails MVC

8. Arquitecture: API + JS Thick client (Techs
Paco) vs Full Rails MVC (Rudos Javier)
• Arquitecture: API + JS Thick client (Techs Paco) vs Full Rails MVC (Rudos Javier)
• Los servicios en una API se pueden separar y escalar mas rapido y con menos costo a largo plazo.
• A corto plazo una app full Rails stack es mucho mas rapido llegar a un MVC.
• A largo plazo una app full Rails se vuelve monolitica, dificil de mantener y escalar.
• Reemplazae secciones de un API/Frontend es mas facil.
• La organizacion del trabajo puede ser mas facil en una app monolitica, no hay tanto problemas de versiones
pero tambien tiene sus desventajas.
• El deployment puede ser mas fácil en una app monolítica.
• Con una app Rails clasica tienes muchas cosas resueltas que no tienes que pensar: Cookies, Seguridad etc.
• Hay mas gemas y plugins para apps vanilla Rails pero una app basada en API's tiene mucha mas
flexibilidad.
• Una app monolitica tiende a hacerce lenta y hacerla mas rapida complica la arquitectura mas y mas y mas.
• El desarrollo de apps con "Thick clients" requiere de un equipo mas experimentado y tiene una curva de
aprendizaje mas alta.

9. Segunda Caída

10. Integration with Capybara Fixtures
vs
BDD/TDD and Fabricates

11. BDD/TDD and Fabricates (Rudos Manuel)
vs Integration with Capybara Fixtures
(Techs Paco)
• TDD esta muerto! Lo dijo DHH
• Las pruebas de integracion te dan pas por tu dinero (esfuerzo)
• Las pruebas de integracion son lentas?
• Las pruebas unitarias prueban de mas y se llenan de polvo facilmente?
• Las pruebas de integracion son "brittle"?
• "Prueba lo que tiene sentido de probar" VS "Prueba todo por si las moscas"
• Prueba pimero == "Me pongo esposas y limito mis implementaciones"
• Prueba despues == "Mejor hagamos que esto funcione y no hay pedo
porque soy un chingon"

12. Pure Models and
DataMapper Patterns
vs
ActiveRecord

13. Tercera Caída

14. Convensions/Defaults (Rudos Manuel)
vs Tailord made (Techs Paco)
• Las convensiones ayudan a la coaboracion.
• Es mas sencillo introducir gente nueva a un proyecto (Onboarding)
• Es mas facil innovar (salirse del molde) cuando la app es a la medida
• No todas las conveciones aplican para todos los proyectos
• El "boilerplate" es pura basura que alenta una aplicacion
• Una aplicacion tailor made requiere de mas atencion a cosas ya resueltas.
• Es muy facil querer reinventar la rueda todo el tiempo y por tanto perder
tiempo y dinero del cliente o desarrollo de producto.
• Actualizar una app basada en convensiones es muy dificil si las API's y
convensiones cambian.

15. Own Infrastructure
vs
PaaS

16. Tailor Made
vs
Conventions & Defaults

17. Final Score!!!!

18. ¡Muchas Gracias!