Panel Magmaconf
Upcoming SlideShare
Loading in...5
×
 

Panel Magmaconf

on

  • 171 views

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

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

Statistics

Views

Total Views
171
Views on SlideShare
165
Embed Views
6

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 6

https://twitter.com 6

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Panel Magmaconf Presentation Transcript

  • 1. Los Técnicos No Photoshop was ! needed in this pictures
  • 2. Los Rudos
  • 3. Primera Caída
  • 4. Client Side vs HTML Render, Server Side
  • 5. 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)
  • 6. API + JS Thick client vs Full Rails MVC
  • 7. 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.
  • 8. Segunda Caída
  • 9. Integration with Capybara Fixtures vs BDD/TDD and Fabricates
  • 10. 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"
  • 11. Pure Models and DataMapper Patterns vs ActiveRecord
  • 12. Tercera Caída
  • 13. 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.
  • 14. Own Infrastructure vs PaaS
  • 15. Tailor Made vs Conventions & Defaults
  • 16. Final Score!!!!
  • 17. ¡Muchas Gracias!