The talking list

Buscando katas para un curso, encontré esta web de la Samman Technical Coaching Society. Es un recurso muy valioso para cualquier persona que se dedique de una forma u otra a la formación técnica, ya sea dentro de equipos de empresas, en coding-dojos, etc.

Technical coaches work with software development teams to help them adopt better coding practices. The Samman method is a concrete approach that many technical coaches use. This website is designed to help people who do technical coaching and is maintained by the Samman Technical Coaching Society. This site shares materials you can use for Code Katas and Learning Hours, as well as many supporting materials. We also have official Training courses.

Samman Coaching

Allen Holub presenta en este breve vídeo una introducción a la técnica de Design by Coding. En pocas palabras, explica como dirigir el desarrollo de un software a partir de historias de usuario, que se codifican en forma de tests (de aceptación y TDD) en los que vamos inventando, sobre la marcha, las interfaces con las que deseamos interactuar.

Es un proceso de prueba y error que se aprovecha de la ductibilidad del software. Si algo no encaja bien con la historia, siempre podremos cambiarlo. Se prioriza definir la forma de comunicarse con el software (interface) sobre su implementación.

Está disponible una charla más extensa sobre el mismo tema.

This 10 minutes video introduces DbC, an agile technique for designing incrementally while you code that that results in a coherent and minimal architecture that’s built on T/BDD techniques.

Design by Coding

Derek Comartin tiene este blog y canal de Youtube en el que trata numerosos temas relacionados con el diseño y arquitectura de software con una aproximación crítica, dedicando muchos posts y vídeos al tema de las arquitecturas Event-Driven, pero también a cuestiones más básicas de diseño. Creo que no hay ni un solo vídeo que no quiera ver en algún momento.

Realmente me parece un canal que merece la pena seguir, aunque hay que tener cuidado de no engancharse porque son decenas de tamas interesantísimos y más allá de que puedas estar de acuerdo en todos sus argumentos, la presentación es muy buena y te hace reflexionar.

A great example of this is Domain-Driven Design. When people first get into it, they immediately latch on to the tactical patterns in code such as Entities, Value Objects, Aggregates, etc. You can find all kinds of tutorials that show you how to use these patterns, but rarely do they ever explain the reasons why you might use them and where they might not be useful. The moral of the story is that you’ll be better served focusing on the problem at hand and the use cases. Then determine what technical solution fits.

Code Opinion

En relación con el artículo anterior, Joan López tiene esta buena explicación en castellano sobre el uso de opciones funcionales en Go.

Otros aspectos ligados a (o fruto de) esa sencillez son la no existencia de parámetros opcionales o la no existencia de sobrecarga de métodos. Y es precisamente en ese aspecto en el que nos queremos centrar hoy. Pues, como veremos a continuación, la falta de dichos recursos a veces nos puede llevar más de un dolor de cabeza y/o dirigirnos a recurrir a prácticas poco atractivas. Sin embargo, si analizamos la situación con un poco de temple, veremos que de la no existencia de dichas características lo que vamos a hacer será encontrar soluciones incluso más atractivas de las que podríamos recurrir en el caso de poseer dichas características. Entremos en materia.

Functional options en Go