La siguiente charla tiene como objetivo presentar las últimas conclusiones y recomendaciones dadas para aplicaciones en el navegador ( SPA ) por el draft de OAUTH2. Hablaremos de porque implicit Flow ya no es un flujo recomendado y las alternativas que tenemos ahora mismo. Desde Code + Pixie hasta Backend for FrontEnd de una forma práctica.
La charla será en castellano. The talk will be in Spanish
20:30 Networking y snacks/cervezas
Unai Zorrilla Castro: Desarrollador y miembro activo de la comunidad desde hace mas de 14 años. Actualmente trabaja en como Lead Dev en Plain Concepts.
Luis Ruiz Pavon: Desarrollador y miembro activo de la comunidad y MVP de Microsoft. Actualmente trabaja como Lead Dev en Plain Concepts.
We'll be doing a different kind of session: we'll be doing a prepared kata. See how a pair would work on the Roman Numeral Kata.
This kata has been practiced at the Software Crafters meetup (e.g., https://www.meetup.com/es-ES/Software-Crafters-Barcelona/events/258492809/), but you don't need to have attended the previous session to enjoy this one.
No prerequisite needed, just show up willing to see a kata developed and energy to learn and share!
See you there!
About the prepared kata:
In a prepared Kata demonstration [... someone is] showing the group their best solution. Not just the finished code, but the entire process from empty editor via Test Driven Development to a full working solution. As they code, they should explain their reasoning and choices, so everyone can follow what is happening and why the code turns out like it does.
[...] You will usually choose a pairing partner from the audience to support you. This person has a particular responsibility to point out omissions, typos etc, but actually everyone in the room should try to be supportive and kind. Comments and suggestions for improvements can be experienced as distracting though, so you’re free to ask people to save them for the retrospective.
If you’re in the audience watching a Prepared Kata performance, your first priority is to make sure you understand what’s happening. The idea is that you follow in enough detail that you’ll be able to go home and reproduce the whole Kata for yourself afterwards, or in the next dojo meeting. The pair at the front should always be willing to stop and explain their thinking. Your other job is to try to think of better ways to do the Kata. Did the pair produce a good design in the end? Are they taking small steps, especially when refactoring? Would a different order of tests lead to better design insights?
From "The Coding Dojo Handbook" by Emily Bache, chapter "Prepared Kata"