Eduardo Ferro Aldama (eferro) personal blog... Expanding my comfort zone. Agile mindset. Software Developer #Python #Go #FLOSS #agile #extremeprogramming https://github.com/eferro https://linktr.ee/eferro Development, Agile, Software Crafter, and random tech and nontech stuff. Opinions are my own.
Thursday, November 28, 2013
Conferencia PyConES 2013
Este fin de semana (23-24 Noviembre) pasado se ha celebrado PyConES, la primera edición de la versión en España de la PyCon
Una conferencia dedica en exclusiva al lenguaje Python, con tres tracks en paralelo (básico, avanzado, ciencia). Sin lugar a dudas ha tenido un éxito brutal, las entradas se agotaron según salieron y la organización ha sido impecable.
Ya esperando la PyConES 2014 :-)
Este año, nos hemos liado la manta a la cabeza y el equipo en el que trabajo preparamos/presentamos dos charlas para la conferencia. Por el "retorno" que hemos tenido de la gente, parece que han aportado valor y que han suscitado algo de debate :-D
Aquí tenéis los enlaces de las presentaciones que usamos:
Las presentaciones las creamos entre todo el equipo de desarrollo @apa42 @pasku1 @nestorsalceda y yo mismo @eferro
Por otro lado, Alea Soluciones, la empresa en la que trabajamos, se porto de lujo y patrocino la conferencia. :-D
Actualización:
Con unos cuantos meses de retraso (superándome a mi mismo), dejo aquí los enlaces a los vídeos:
Posts Relacionados:
Monday, August 26, 2013
Album Fotos / Pineta - Llanos de Lalarri 22/8/2013
Aprovechando las vacaciones he andado pateando un poco el valle del Chistau y cercanías, en los Pirineos Oscenses
Aquí tenéis la primera entrega de fotos...
Pineta - Llanos de Lalarri 22/8/2013
Monday, July 15, 2013
Anfitriones desk-surfing (esta vez con Iván)
La semana pasada, hemos tenido visita de Iván Stepaniuk que ha venido a Alea de desksurfing durante dos días. La experiencia, como en anteriores ha sido muy positiva.... Al igual que Yamila Moreno, en el anterior desksurfing, Iván ha tenido la amabilidad de escribir sus impresiones en un post en su blog....
http://blog.istepaniuk.com/desksurfing-at-alea/
Gracias por el feedback Iván
Tuesday, July 09, 2013
Retrospectiva AOS2013
El año pasado en el AOS de Zaragoza, cuando anunciaron que el siguiente iba a ser en Tenerife, lo primero que me vino a la mente es que iba a ser complicado ir tan lejos y con la familia...
Finalmente no sólo he ido, además he liado a mi familia para tomarnos una semana de vacaciones y a varios compañeros para proponer una charla... vamos un AOS completo.
La verdad es que me lo he pasado fenómeno en este AOS, pero no puedo separar qué parte ha sido debido a las vacaciones en familia, que han sido espectaculares y al propio AOS.
Entre otras cosas he aprovechado para hacer una inmersión :-)
En cuanto al contenido del AOS echo en falta más peso en lo técnico, pero supongo que eso tiene que ver con el estado de madurez de la nuestra comunidad.
Siempre me sorprende que dedicándonos la mayor parte de nosotros a desarrollar software, suele haber más peso en temas de coaching, gestión, metodología, etc, que en temas de desarrollo ágil (prácticas XP, testing, calidad, etc). Me sorprende no porque no sean importantes los primeros temas, sino porque por volumen se necesitan varios desarrolladores ágiles para requerir un scrum master o un coach.
Es más, a mi me interesan mucho las dos partes, pero siempre me cuesta mucho más encontrar gente y experiencias en la parte de desarrollo ágil, XP, clean code, craftmanship, testing y me encantaría que no fuese así y tuviésemos una comunidad algo más balanceada en ese aspecto.
Este año, parte del equipo en el que trabajo, nos lanzamos a compartir nuestras experiencias postponiendo decisiones técnicas y tenemos que decir que creo que la sesión salio muy bien, feedback positivo, hubo bastante debate, y creo que supimos compartir nuestra experiencia.
Para concluir, mi Retrospectiva / Juego de la perfección de este AOS2013
Mi nota para el AOS de este año es 9
Mis motivos son que lo que pasa en un AOS es lo que debe pasar, la gente que está es la que debe estar, por lo que no evalúo para nada el contenido, puesto que es el generado por la comunidad para la comunidad, y lo único que evalúo es la organización, que me pareció impresionante.
Puntos a destacar:
Para darle el 10, yo hubiese deseado:
Para el AOS considero que el idioma debería ser el español, puesto que creo que el nivel de participación baja cuando no se hace así.. y el AOS me gusta como encuentro de gran cantidad de "emisores de información" y creo que la cantidad y calidad de las emisiones baja cuando no se hacen en la lengua materna...
La comunicación es más difícil (cantidad, relación señal/ruido, transmisión de detalles, etc...). Para mi es un problema equivalente a cuando se quiere desarrollar software con un equipo distribuido, no es imposible, pero claramente la comunicación "efectiva" y "afectiva" es más difícil y hay que tenerlo en cuenta.
También tengo que decir, que el tema del idioma lo veo así para el AOS, pero no para otro tipo de conferencias de comunicación más unidireccional en las que existe menos dialogo y se centra más en las transmisión de una idea por parte del que está presentando.
Por tanto, conferencias como la CAS, XP Conference, etc. entiendo que tiene mucho más sentido que sean más internacionales, pero para el AOS, no lo veo, por muchas vueltas que le de.
Finalmente no sólo he ido, además he liado a mi familia para tomarnos una semana de vacaciones y a varios compañeros para proponer una charla... vamos un AOS completo.
La verdad es que me lo he pasado fenómeno en este AOS, pero no puedo separar qué parte ha sido debido a las vacaciones en familia, que han sido espectaculares y al propio AOS.
Entre otras cosas he aprovechado para hacer una inmersión :-)
En cuanto al contenido del AOS echo en falta más peso en lo técnico, pero supongo que eso tiene que ver con el estado de madurez de la nuestra comunidad.
Es más, a mi me interesan mucho las dos partes, pero siempre me cuesta mucho más encontrar gente y experiencias en la parte de desarrollo ágil, XP, clean code, craftmanship, testing y me encantaría que no fuese así y tuviésemos una comunidad algo más balanceada en ese aspecto.
Este año, parte del equipo en el que trabajo, nos lanzamos a compartir nuestras experiencias postponiendo decisiones técnicas y tenemos que decir que creo que la sesión salio muy bien, feedback positivo, hubo bastante debate, y creo que supimos compartir nuestra experiencia.
Para concluir, mi Retrospectiva / Juego de la perfección de este AOS2013
Mi nota para el AOS de este año es 9
Mis motivos son que lo que pasa en un AOS es lo que debe pasar, la gente que está es la que debe estar, por lo que no evalúo para nada el contenido, puesto que es el generado por la comunidad para la comunidad, y lo único que evalúo es la organización, que me pareció impresionante.
Puntos a destacar:
- Se ha conseguido atraer a la gente para tomarse el AOS como unas vacaciones.
- Gran cantidad de actividades paralelas (para potenciar el networking, la diversión...)
- El sitio me pareció muy cómodo.
- El Almogrote estaba riquísimo :)
Para darle el 10, yo hubiese deseado:
- Que fuese íntegramente en español, puesto que considero un AOS un evento de la comunidad que debe fomentar la participación y aportación de la comunidad, y creo que hoy por hoy eso se facilita en español (en algunas sesiones me pareció que se perdieron aportaciones y el ritmo por intentar hacerlas en inglés).
Para el AOS considero que el idioma debería ser el español, puesto que creo que el nivel de participación baja cuando no se hace así.. y el AOS me gusta como encuentro de gran cantidad de "emisores de información" y creo que la cantidad y calidad de las emisiones baja cuando no se hacen en la lengua materna...
La comunicación es más difícil (cantidad, relación señal/ruido, transmisión de detalles, etc...). Para mi es un problema equivalente a cuando se quiere desarrollar software con un equipo distribuido, no es imposible, pero claramente la comunicación "efectiva" y "afectiva" es más difícil y hay que tenerlo en cuenta.
También tengo que decir, que el tema del idioma lo veo así para el AOS, pero no para otro tipo de conferencias de comunicación más unidireccional en las que existe menos dialogo y se centra más en las transmisión de una idea por parte del que está presentando.
Por tanto, conferencias como la CAS, XP Conference, etc. entiendo que tiene mucho más sentido que sean más internacionales, pero para el AOS, no lo veo, por muchas vueltas que le de.
Muchisimas gracias a toda la organización:
Espero que no me deje a nadie (y si me lo dejo, espero que me perdone...)Wednesday, July 03, 2013
El problema de explicar el object relacional impedance mistmatch
Si realmente no has entendido la orientación a objetos y casi todos los objetos que creas son contenedores de datos planos, es imposible que sufras el impedance mismatch entre el mundo de objetos y las bases de datos relacionales, simplemente no estás haciendo objetos... no pasa nada, esta bien, pero no me calientes la cabeza diciendo que usas objetos... :-)
En ese escenario no tiene sentido hablar del object relational impedance mismatch... en realidad casi no tiene sentido hablar de nada relacionado con orientación a objetos (diseño, patrones, polimorfismo, composición, herencia, etc)
Saturday, June 22, 2013
El arte del patadon pa'lante / Postponer decisiones técnicas
24/6/2013 Actualización de formato y añadidas referencias
Este post contiene la esencia de lo que estamos haciendo en Alea Soluciones para postponer en todo lo posible las decisiones técnicas. Vamos a usar este post como base para compartir nuestras experiencias al respecto en el AOS2013
Comenzamos:
Código no es un snapshot, es algo en movimiento
Siempre puedes iterar... iterar/refactorizar es fácil sin miedo y con red... TDD, BDD...
Este post contiene la esencia de lo que estamos haciendo en Alea Soluciones para postponer en todo lo posible las decisiones técnicas. Vamos a usar este post como base para compartir nuestras experiencias al respecto en el AOS2013
Nuestro contexto
- Hacemos productos en entorno de telecomunicaciones
- Equipo Extreme Programming
- Deploy continuo / Entrega continua
A qué nos referimos
Postponer todas las decisiones técnicas hasta el último momento responsableQue no postponemos
- La forma en qué hemos decidido trabajar (de forma ágil, deploy continuo, extreme programming)
- El lenguaje base de desarrollo de cada componente... python...
- Buenas prácticas de OO
Por qué queremos postponer / Beneficios conseguidos
- Cuanto más tarde tomemos una decisión más conocimiento tendremos del negocio y del entorno técnico
- Soluciones más simples/sencillas
- Soluciones más pequeñas
- Trabajar menos :-)
- Más probabilidades de no hacer nada que no aporte valor real ahora
- Más probabilidades de no hacer sobre ingeniería
- Menos esfuerzo en rehacer trabajo si es necesario
- Nuestro objetivo es tener mucho juego de cintura... reaccionar bien y rápido a cualquier cosa... y sin echarnos las manos a la cabeza
- Cuanto más postponemos, menos llenamos la mochila.... es más dificil coger lastre y tendemos a viajar ligeros.... añadimos menos cosas innecesarias.
- Todos sabemos que una mudanza se hace fácil si tenemos pocas cosas
- Una buena arquitectura nos permite postergar decisiones importantes, esto no significa que estemos obligados a hacerlo. Sin embargo, al poder postergarlas tenemos muchísima flexibilidad.
Cómo lo hacemos
- Postergamos las decisiones de forma consciente y meditada
- Consideramos una decisión como buena cuando:
- nos compromete lo mínimo posible
- nos permite postponer otras decisiones
- Es fácilmente cambiable
- Ataca un problema actual (no futuro)
- Suficientemente bueno (sin sobreingenieria, ni nuestra ni de otra gente)
- Prohibido Megaconstrucciones
- Reusamos librerías pero no Frameworks (vamos no dejamos que nos usen a nosotros)
- Consideramos qué todo se puede cambiar (código / diseño / proceso)
- Cuanto vamos a afrontar un sprint o un grupo de funcionalidades nos centramos en identificar qué tenemos que cambiar en nuestra arquitectura y nuestro entendimiento del dominio / lenguaje ubicuo.
- y lo que se decidió era lo correcto en ese momento y en ese contexto y si hay que cambiarlo, no pasa nada, manos a la obra...
- Método Hamburguesa descomposición de PBIs grandes.
- Clean Code
- DDD (u otra variante que permita que la arquitectura no se centre en las herramientas BD, GUI, etc)
Qué necesitamos para hacer fácil postponer.
- seguridad/confidence
- Feedback temprano
- TDD
- Refactor continuo
- Todo se pueda cambiar
Código no es un snapshot, es algo en movimiento
Problemas/Sensaciones que genera postponer decisiones...
- Incertidumbre
- Ansiedad
- Conflicto (como ingenieros)
Postponer... hasta el infinito y más allá...
Hasta el último momento responsable!!!!
Referencias:
- Método Hamburguesa para descomposición de historias de usuario http://gojko.net/2012/01/23/splitting-user-stories-the-hamburger-method/
- Articulo relacionado recomendado Real options enhance agility http://www.infoq.com/articles/real-options-enhance-agility Gracias Marcin
- Domain Driven Design http://www.domaindrivendesign.org/
- Clean Architecture http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html
- Hexagonal Architecture http://alistair.cockburn.us/Hexagonal+architecture
Anfitriones desk-surfing (una vez más)
Hace unos días, Yamila Moreno, de Kaleidos ha tenido la gentileza de visitarnos y trabajar con nosotros un día... y no sólo eso, además ha tenido la paciencia de escribir un post al respecto... :-)
http://kaleidos.net/blog/desk-surfing-en-alea-soluciones/
http://kaleidos.net/blog/desk-surfing-en-alea-soluciones/
Saturday, March 23, 2013
Anfitriones desk surfing en Alea Soluciones
Hace unos días, el equipo de desarrollo "Bifer", en Alea Soluciones, tuvimos nuestra primera experiencia como equipo con un desk-surfing.
Fuimos anfitriones de la visita de Enrique Amodeo que vino a compartir con nosotros dos días de trabajo, ver cómo trabajamos y a compartir su forma de hacer las cosas...
El primer día después de contarle un poco a que nos dedicábamos, intentamos tener una día de trabajo lo más normal posible. Como era un viernes, teníamos demo, y a algunas reuniones, por lo que realmente no pudimos compartir mucho tiempo de programación. Pero entiendo que también es muy importante ver otras partes del proceso de desarrollo.
El lunes sin embargo teníamos funcionalidades preparadas para desarrollar por lo que porque pudimos programar la mayor parte del día. Nos organizamos por parejas como solemos hacer normalmente y Enrique fue rotando de compañero a compañero para que tuviese la oportunidad trabajar con todos.
Desde el punto de vista de equipo creo que fue una gran experiencia. Pudimos compartir enfoques muy diferentes sobre cómo solucionar ciertos problemas lo que siempre enriquece y aparecieron nuevos puntos de vista para algunos diseños... Por otro lado también surgieron buenas aportaciones sobre las prácticas de desarrollo que usamos (TDD, programmación en parejas, etc...)
Por otro lado fue muy interesante ver como el hecho de estar una persona externa equipo, no sólo no nos retrasó, sino que incluso creo que nos organizamos mejor.
En la siguiente retrospectiva de equipo, estuvimos todos de acuerdo en que había sido una experiencia muy enriquecedora y que teníamos que instaurarlo como algo a realizar de forma periódica. Vamos una experiencia fantástica...
Por otro lado, Enrique nos comento lo siguiente:
¿Sugerencias? No se me ocurre ninguna, hacer pair programming fue genial, y ciertamente vuestro dominio me sacó fuera de mi zona de comfort (y he de reconocer que python un poquito también). Quizás hacer un par de fotos de la ocasión podría haber estado bien, pero a mi ni se me ocurrió. Al menos pude aportar un buen par de refactors interesantes.
Para la siguiente, no se nos olvida hacer unas cuantas fotos...
Repetiremos como anfitriones.
Intentaremos salir a otras empresas a conocerlas y aprender.
Gracias Enrique por venir y por compartir con nosotros estos dos días, y gracias Guillermo por ponernos en contacto con Enrique.
Fantástico, otro paso como equipo ágil y equipo de Extreme Programming
Subscribe to:
Posts (Atom)