There are these two young fish swimming along and they happen to meet an older fish swimming the other way, who nods at them and says “Morning, boys. How’s the water?” And the two young fish swim on for a bit, and then eventually one of them looks over at the other and goes “What the hell is water?”
David Foster Wallace, from This is Water
A fish is swimming along, having some breakfast, when suddenly he’s snatched out of his world by his food, into a bright world where it’s hard to breathe, landing on the bottom of a boat, where strange alien creatures make odd sounds. Overhead, he sees an airplane flying at 500 mph (without knowing what “airplane”, “flying” or “500 mph” means). Suddenly, one of the creatures picks him up, removes the pain, and, just as suddenly, he’s back home. Yet, when he regales his friends with this tale, no one can believe such a strange world could exist.
This keynote describes the water you swim in but cannot see anymore, like relational databases and application servers. Additionally, it jerks you out of safe, warm water (briefly) to describe a strange, fantastical world with things like immutable database server, phoenix machines, and lambdas.
You may have trouble getting your friends who didn’t attend to understand.
¿Ya conoces algo de DevOps y automatización de despliegues de aplicaciones?
Hablemos entonces de estrategias y herramientas que nos permitirán llevar cambios a producción de forma inmediata.
Como llevar software a producción sin pasar por largos, ineficientes y burocraticos procesos de TI?. En esta charla quiero hablar concretamente de practicas tecnologicas para llevar cambios a producción de forma automatica y algunas arquitecturas de referencia que pueden ayudar construir productos mas livianos, eficientes y que puedan ser llevados a producción rapidamente
Desde que el mundo del desarrollo de software conoció las bondades del Agilismo para el manejo de proyectos han salido a la luz nuevos impedimentos que transforman a las entregas iterativas e incrementales en un foco de consumo de tiempo y energía, por suerte estos procesos mecánicos y redundantes han podido ser aplacados por nuevas técnicas.
En este workshop se abordara una de las técnicas de mayor crecimiento en los últimos años conocida como ATDD, esta permite involucrar tempranamente a los miembros del equipo en el comportamiento final del sistema, reducir tiempos muertos y encajar los criterios de aceptación dentro del set de pruebas automáticas.
Cuán difícil y costoso se nos ha hecho cambiar las implementaciones después de que el diseño sale del horno, cuán difícil ha sido adapatarnos a nuevos requerimientos, que eran imposible preveerlos.
Simplemente hay ocasiones en las que no se puede, que es imposible, entonces tratamos de martillar con un destornillador o atornillar con un martillo.
Hemos llegado a un punto en el que nos hemos dado cuenta en base a la experiencia, que el enfoque no es el adecuado, y que en lugar de contemplar lo incontemplable, sería mejor que el cambio sea menos costoso, y en lugar de predecir nos concentremos en evolucionar.
El diseño y análisis al inicio han sido la piedra en el zapato de todos los proyectos, cambiamos esto para ser ágiles en el desarrollo, ahora cambiemos para ser ágiles al nivel de arquitectura
Las mejores prácticas de ayer, son antipatrones ahora; así como el código cambia, se refactoriza, la arquitectura puede evolucionar. Hablaremos de prácticas que nos ayuden a desenredar los problemas y hacer que la evolución de la arquitectura no sea un sueño.
Mob programming es un enfoque ágil, extensión y evolución del pair programming, planteado por Woody Sully en su [experience][1] report del Agile Alliance 2014 , tiene como premisa aprovechar todo el potencial, experiencia y conocimiento de un equipo trabajando en el mismo lugar, al mismo tiempo y sobre el mismo código usando una sola computadora. Esta charla pretende dar a conocer la filosofía del mob programing y sus diferencias con el pair programming, además de compartir las experiencias de aplicación vivida por el autor como Scrum Master.
De la mejora continua hasta la calidad total. Su aplicación técnica, empresarial, colectiva e individual.
Partiendo de las prácticas de refactoring y retrospectiva de las metodologías ágiles de desarrollo de software, basadas en la filosofía empresarial japonesa kaizen, hacia los procesos de negocio y la organización empresarial, abordando finalmente su aplicación individual.
Hoy mejor que ayer, mañana mejor que hoy.
Escalar Agile es un "hot topic". Ha aparecido nueva jerga y producto de esta tendencia han surgido herramientas, frameworks que permiten llevar los beneficios de Agile a todos los niveles de una gran organización. Cuando hablamos de grande, nos referimos a equipos de más de 600 personas, distribuidos en varios países, trabajando en múltiples sistemas o componentes.
Se desarrollorá un ejemplo de código sobre el cual se aplicarán los patrones de refactoring como:
Finalmente se demostrará como se puede mejorar un diseño usando refactoring continuo,
BDD (Behavior-Driven Development) es una manera de desarrollar software por medio de especificar el comportamiento de la aplicación, así como de sus componentes de software con sus correspondientes objetos.
El principal artefacto de BDD no son ni las pruebas automatizadas, ni la documentación, ni otra cosa más que las conversaciones que se dan entre diferentes roles que intervienen en un proyecto de desarrollo de software, para vencer la incertidumbre e ignorancia en el proyecto.
El resultado de aplicar BDD son las especificaciones ejecutables, el detalle del entendimiento que se va acelerando con esta forma de desarrollar software, al mismo tiempo que constituye una documentación dinámica y sincronizada con el código de producción además de las tan útiles pruebas de regresión.
CHE, acrónimo de Calm, Happy, Energized es una propuesta para atención plena en Scrum. Según estudios de Harvard Business Review, un alto porcentaje de líderes experimentan calma, felicidad y energía como los grandes propulsores de efectividad y productividad.
¿Cómo conseguir estos estados mentales? Mediante el ejercicio de prácticas de "Atención Plena - Mindfulness"
Mi charla tratará sobre todos los temas prácticos para hacer un desarrollo ágil y obtener resultados de calidad, obteniendo desarrolladores felices y motivados. Los temas sobre los cuales se hablarán de forma práctica:
Continuous Delivery (CD) is a design practice used in software development to automate and improve the process of software delivery. Techniques such as automated testing, continuous integration and continuous deployment allow software to be developed to a high standard and easily packaged and deployed to test environments, resulting in the ability to rapidly, reliably and repeatedly push out enhancements and bug fixes to customers at low risk and with minimal manual overhead.
Microservices is a software architecture design pattern, in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs.[1] These services are small, highly decoupled and focus on doing a small task.
In this talk, we will share our learnings about using these two concepts together in Agile projects.
"Connascence" es una medida de calidad para componentes de software diseñados bajo un paradigma de orientación a objetos equivalente al concepto de acoplamiento que existe en la programación estructurada.
Este conocimiento viene dado en varios niveles, y mientras más fuerte es el nivel de conocimiento de un componente acerca de otro causa que los cambios en el segundo siempre vayan acompañados de cambios en el primero para que el sistema en conjunto continúe funcionando de forma correcta.
Este manera de entender la dependencia entre clases y objetos puede ser extendido hacia componentes de software más complejos como módulos y sistemas.
A persar de que el paradigma Orientado a Objetos tiene más de 47 años, aún se sabe muy poco sobre cómo usarlo correctamente, la mayoría de los lenguajes "so called Object Oriented" realmente no lo son y una gran cantidad de sistemas escritos con este paradigma en realidad cumplen más con la definición del paradigma estructurado que el de objetos. En esta charla veremos qué significa realmente programar y diseñar con Objetos y deshaciendonos de las limitaciones que algunos lenguajes nos imponen
Durante la charla se verá: - Definición Fundacional del Paradigma de Objetos - Diferencias conceptuales con otras interpretaciones del paradigma inducidas por la implementación del lenguaje C++ - Ejemplos concretos de malas implementaciones del paradigma en los lenguajes Java, C# y otros - Ejemplos concretos de malos diseños que no cumplen con la definición del paradigma - Conclusiones finales de qué significa trabajar con objetos
