Saturday, November 24, 2018

Slides: De .Net a Python

Slides que utilizamos para nuestra presentación en CommitConf 2018. También se pueden ver aquí



Video:


Sunday, November 4, 2018

A brief history about agile transformation

By re-reading a post from a friend of the honey-badger tribe, I realized how much in common it has with a known situation experienced in a recent past.

Imagine you join a team in the following situation:
  • Unclear processes and workflow
  • Lack of knowledge about the product
  • Team executing decisions taken by others
  • Vague software development practices
Also, within this context, imagining you receiving a great market opportunity which requires deliver something with a fixed deadline. Looks like a case to continue doing what's done in the past to avoid taking risk of failure, but off course leaving the same picture as above regarding team processes. There is always the chance to be counterintuitive and use this greenfield project to boost the team processes to another level. The good thing is to have an organization aware of this issues and the willingness to support any change that improves the way they work. So, having this context, the willing to improve it and a deadline to fulfill, how would you do it?

Well, there are no silver bullets for the transition of organizations to become agile organizations. But there some things they had that helps to start trying small steps towards that end:
  • Acknowledge the problem
  • The willing to solve it
  • The opportunity to start solving it
Having all these ingredients in mind you define a new way of working based on Respect, create space for continuously improve Communication, Collaboration and Learning. This new way of working has open doors to constants Feedback, the process will be constantly evolving and adjusting to our needs and conform, applying the Inspect and Adapt cycle ( see the twelfth principle of the Agile Software Development). Basically, you invert the pyramid by rejecting receive only solutions from the stakeholders and instead receive more customer oriented needs which allow the team to respond back with solutions created by themselves.

Is important to emphasize that you don’t call this new way of working Scrum or Kanban nor XP, you just get some techniques of those frameworks and apply them into your context; and this is one of the key things we need to understand about agility: We aren’t more agile just because we do Scrum or eXtreme Programming, we should first understand the context in which we are playing and create our own process improve Adaptability, Risk Management and Innovation within the organization. To achieve it I do agree on choosing the best practices and techniques from others methodologies or cultures like Scrum, Kanban, XP or DevOps just to mention some of them or create your own artifacts that simply leads the team or organization to that end.

Let’s review some of the things that the team has tried:
  • Begin with the end in mind: Having today a clear image of the end of the work is the key reference for the team to measure accuracy on every single step or iteration they do. In reference to the book: The 7 Habits of Highly Effective People
  • Retrospectives: Part of the previously mentioned feedback loop. They do it periodically, rotate the facilitator and set concrete actions to improve.
  • Planning meetings: The conversation should be the focus in having a common understanding of the problem that need be solved using customer/business language. Then the teams should decide how to solve it.
  • Working towards having Continuous Integration, which not only having a build server that runs tests for every commit but also has the team mindset that code should be integrated altogether the sooner the better avoiding long-lived branches and unwanted conflicts, errors and miscommunication.
  • Working towards having Continuous Delivery
  • User Stories: Reduce the risk of failure by having granulated and acknowledging the added value.
  • Reduce Work In Progress (WIP): To Increase focus, collaboration and detect bottlenecks.
  • Demos: Another part of the feedback loop where several roles should meet and talk about the increments of the product. Sharing knowledge and checking if we are all moving in the right direction.
  • Pair Programming: With the objective of sharing knowledge, reduce knowledge silos, increase team cohesion and improve code quality.  
  • Automated Testing: Still not Test Driven Development, maybe in the future.
At the end of the deadline, the results talk by themselves by having a team behaving close to a self-organized and autonomous team, having collective ownership over the code, having better understanding of the product and the impact they have over it, understanding the process they follow to add value to the organization and how/when this process can be improved. All this can be achieved because the organization simply give them trust and freedom to do, fail, success and act in consequences.

At the end of the deadline, the team should have been doing the right thing and after they should focus on doing things right. Meaning that you should first focus on the user needs, lean processes, feedback loop, ... ( the right thing ) and then look for technical excellence, reduce lead times, reduce feedback loops among others by polishing DevOps culture, XP practices, etc. Always keeping the continuous inspect and adapt cycle.

Related resources:

Tuesday, October 9, 2018

PyConES 2018

Last weekend (October 5-7) I attended, together with some colleagues from TrustYou, the PyConES conference in Málaga. Like in PyConES-2017, this was an opportunity to meet again with the python community, meet new people and companies, meet with former colleagues and friends as well as browse the challenges they face. All this around a common denominator that in this case is Python.



Some of the talks look interesting to me:

Keynote by Héctor Socas Navarro
Hector Socas is a physics at The Instituto de Astrofísica de Canarias(IAC) and he shows us some
cutting edge challenges that Astrophysics is facing nowadays and how the technology is playing a
key role in those. It was amazing to learn about the marvellous things about the Universe and see
how Python is helping those things.

Back to Basics: NLP by Claudia Guirao
I especially liked this talk of the Data Science track because the speaker managed to explain the
concepts using a friendly language so the audience can understand. The talk is well summarized in
these notes.

Python Core
Last but not least I would like to mention some python core talks interesting to me:

¡Oh vosotros los que entráis, abandonad toda esperanza! by Pablo Galindo
Where he walks us through the different stages of the python compiler: syntax, grammar, ASTs.


Hora de sacar la basura: garbage collector by Pablo Galindo and Victor Torres
They, in 25 mins, show us how Python Garbage Collector works, pros and cons,
together with some possible improvements that are being evaluated for future. You can check in detail the slides here.

GIL: Todo lo que siempre quisiste saber y nunca te atreviste a preguntar by Jesus Cea
He explained how GIL works, talked about improvements in Python 3 over Python 2. It is always interesting to hear someone that really knows the inners of GIL.


I appreciate the effort of Python España, Ebury, Yes we tech y Málaga Python for organizing this conference. As I always highlight in my conference posts the best part of every conference is the networking and this was not an exception at all together with the beautiful city Málaga.



Looking forward to PyConES2019!!!

Monday, August 27, 2018

Europython 2018 - Part I


Last July I had the opportunity to attend the Europython Conference. It had been 4 years since the last time I attended Europython but the experience was again amazing. I highlight 3 things:  Spending time with TrustYou team, learning more about Python and the Community, and having the experience of improvising a lightning talk being a bad speaker but still a good way to give back to the community.

I'll go through some of the talks I have attended and provide some summary of my learnings. In this post, I summarize half of them ( you can see the others in the Part II blog post about to come )


Technologies to master parallelism in Python by Shailen Sobhee

Even though the title is misleading (I find it difficult to master something by only taking a workshop), I liked it and it helped me to recall and discover some insights in parallel executions in Python. Some topics that we played with:

  • Multithreading
  • Multiprocessing
  • Joblib
  • Dask
This image gives an overview of the interaction of Python and Parallelism:




More info:
Presentation: EuroPython-2018-Shailen-Sobhee
Code: python-parallelism-tutorial

Fast native code with Cython by Stefan Behnel

Cython is a language to write C extensions for Python as easy as Python. Cython compiler translates Python code to C/C++ and supports static type annotations to allow direct use of C/C++ data types and functions. What is Cython good for?
  • Integrate native code in Python
  • Speed up Python code in Python
  • Writing C without having to write C
In this workshop, Stefan shows us how to speed up our code using Cython and compares time against Python and Numpy code. 

The naive programmer by Daniele Procida

Amazing talk that emphasizes software development as a creative craft ( art ) and reinforces inclusivity of naive programmers. We weren't naive at some point of our career? Aren't we naive nowadays after some years as software developers? Do we behave well with naive programmers around us?

Drawing a parallel line between artists and developer we can see how some sophisticated artists like George Braques and naive artists like Henri Rousseau were accepted by their art in the society. Do we accept in the same way "naive" programmers?

My personal opinion on this topic is that naive is not a permanent state that disappears once you acquire some experience, instead of a state that constantly appears and disappears during our lifetime as developer depending on the context, technology, role and/or others.

I highly recommend you to watch this talk if you have the opportunity. I leave this summary with a question for the ready:
Would you rather be a naïve programmer with a vision, or a sophisticated programmer without?
Presentation: the-naive-programmer

Bridging the Gap: from Data Science to Production by Florian Wilhelm 

Nowadays Data Science is trending and needed in a lot of organizations. Is a fairly new role in the industry and organizations are still filling the gaps to have an effective workflow ( Production working software ) when Data Science is involved. In this talk, the speaker gives some insights on how to do this based on his experience.


Some takeaways:

  • Production is not an afterthought 
  • Think early about QA
  • DevOps culture
  • Team responsibility
  • Reduce the number of frameworks and languages up to the minimum 
  • Embrace processes and automation
Presentation: bridging-the-gap-from-data-science-to-production

Bad hotel again? by Elisabetta Bergamini

Last but not least, in this talk, Elisabetta showed how, in Meta-Review team, we are trying to improve travellers experience providing great hotel summaries that could help the customer find the perfect match. She explained how by applying some Machine-Learning, NLP and Data Engineering techniques the platform transforms 3M weekly reviews, 900K hotels and 22 languages into useful and readable feedback describing hotels based on customers reviews.





Presentation: bad-hotel-again-find-your-perfect-match

Sunday, January 14, 2018

Gracias Tejones

Hace un mes ya que no trabajo en TheMotion. Es un buen momento entonces para hacer retrospectiva y dejar por escrito lo que ha significado este período para mi. Aclaro que en este post solo haré referencia al equipo de tecnología con lo cual cualquier halago, crítica o feedback presente hagásele corresponder a dicho equipo. Aclaro tambien que todo lo escrito está basado en mi visión y opinión personal.



En el equipo de tecnología de TheMotion ( tech o tech-honey-badgers team ) hemos pasado por varias etapas, buenas y no tan buenas, donde siempre ha prevalecido la transparencia, la calidad, la diversión y el trabajo en equipo. Son valores que destacan en este grupo incluso cuando hay un intento de desviar su atención hacia otros haceres que puedan derivar a otros valores ( positivos o negativos ), los valores mencionados emergen solos y de alguna manera indican el camino de hacer las cosas correctamente, muchas veces en formas totalmente opuestas a lo que otros sugieren.

Tech no es un grupo de profesionales haciendo software o brindando servicios para satisfacer clientes. Tech intenta, primero que todo, que prevalezca el hecho de que somos personas y sentimos como tal cada una de las cosas que hacemos, no somos un recurso que sabe de esto o aquello, somos personas que constatemente nos equivocamos, aprendemos, desaprendemos y cada uno tiene una visión distinta o siente de manera diferente cada uno de los hechos que nos impactan. Se podría decir que tech es que equipo donde al principio y al final del día se espera que cada desición y/o acción tomada sea pensanda como y para las personas,  people-first team como algunos dirían.

Los Honey Badgers nos basamos en prácticas de agile software development y valores de XP para la creación mediante el software. Sin entrar mucho en detalle en este punto, destacaría algunas prácticas como el TDD, Pair-programming, retrospectivas periódicas ( todavía mejorables ), Continuous Integration, Continuous Delivery, Infrastructure as Code, entre otras, como vía para facilitar la solidez y simplicidad del código, el aporte continuo de valor, la comunicación y el feedback, aunque aún haya mucho espacio de mejora en varios de estos puntos. Podíamos trabajar en remoto ( 2 días a la semana),  lo cual hace necesario el uso de ciertas herramientas y técnicas de comunicación para garantizar el mejor flujo de información posible. Me enseñó a aplicar muchas prácticas de desarrollo ágil que desconocía o no había podido validar además de introducirme en la comunidad de software craftmanship, todo esto de la mano de haber recuperado el hábito de lectura e impulsarme a escribir en este blog.

El equipo de tech de TheMotion ha significado un antes y un después en mi carrera profesional y personal. Me ha enseñado a ser mejor persona y valorar ciertos aspectos humanos aún cuando estamos inmersos en temas laborales. Me abrió las puertas a Extreme Programming y me dió una visión totalmente distinta sobre  el agile software development, adaptándome a la realidad del contexto, sin ser dogmático ni seguir ciegamente manifiestos, etc. Me ha aportado mucho sobre como hacer productos tecnológicos, sobre como obtener feedback, la importancia tomar decisiones basado en datos, entender las preguntas antes que buscar las respuestas ( entender primero el problema ), que es muy importante el como hacemos las cosas en vez cuan rápido o lento, que es más importante cuál es el outcome que cuanto output hemos tenido.

Se que me dejo muchas enseñanzas aprendidas en esta etapa pero el agradecimiento a cada tejón es inmenso porque de cada uno aprendí algo en mayor o menor medida. Sin importar que camino tome mi carrera a partir de ahora mi deseo es seguir formando parte de los tech-honey-bagers y contribuir junto a ellos a empujar por una mejor realización de software, expandir la idea correcta del agile software development y otras tareas que consideremos necesario para mejora la comunidad de software y la forma en que se afronta la transformacion digital hoy en día.

Gracias por todo tejones!!!


Otro post relacionados con los tech-honey-bagders:



Tuesday, September 26, 2017

PyConES 2017

El pasado fin de semana ( 22-24 de septiembre ) asistí, junto con algunos colegas de TheMotion, a la 5 edición de la PyConES en Cáceres. Es siempre una oportunidad para re-encontrarse con la comunidad, conocer nuevas personas y empresas, reencontraste con ex-colegas y conocidos además de curiosear y conocer retos a los que se enfrentan, todo esto en torno a un denominador común que en este caso es Python.


La organización del evento hasta antes de llegar al día de las conferencias me pareció genial brindando bastante información sobre el evento desde el momento de compra de entradas hasta agenda al detalle, pasando por detalles ( que tiene importancia ) como la localización del venue, como llegar a Cáceres, brindar opciones de hospedaje, de traslados, jobs board e incluso de hacer turismo en Extremadura. Agradecido por las cervezas de bienvenida dando paso desde el primer momento al networking e involucración con la conferencia.

Dicho esto creo que aun existe margen de mejora, ejemplo de ello son los siguientes puntos.

  • El formato del evento es muy tradicional en el sentido en que el flujo de conocimiento es mayoritariamente de un ponente a una sala, no creando más espacios para tener mesas redondas, talleres, charlas cortas, open space, mob programming, hackatons u otros formatos que hace el conocimiento fluir de otra manera.
  • Una charla cada 30 minutos hace que el ponente tenga unos 20 minutos si queremos dar tiempo a preguntas y a cambiar de sala, lo cual hace muy difícil tener una presentación en profundidad de un problema y/o solución cuando se trata de temas complejos.
  • Deberíamos aprovechar la versatilidad del lenguaje python incluyendo/invitando a los proyectos científicos a acercarse más a este evento y aportar a la comunidad así como aprender de ellos.
  • El catering resulto ser muy pobre y en un sitio pequeño para tantas personas. Mis colegas y yo terminados comiendo fuera.

Destaco alguna de las charlas que vi y me parecieron interesantes:

High-impact refactors while keeping the lights on

Kartones nos explica como están llevando a cabo la evolución de un Multilito ( pero que funciona ) en Ticketea. Resaltando algunas estrategías y patrones para ir aportando valor poco a poco y manteniendo estable el codigo:
  • Retrasar decisiones
  • Extend, not modify
    • Parallel changes
    • Strangler
    • Event bus, Event sourcing
  • Feature toggles
Como dato adicional, mencionar a pynesis, un cliente open source de kinesis desarrollado por el equipo .

¿Dónde está mi ñ?

Muy interesante repaso histórico de como surge la codificación, empezando por Morse y pasando por ASCII, WINDOWS-1252, y UNICODE entre otros. Como dato curioso para mi el conocer un poco sobre Emoji y Fototipos. 



Un guiño rápido al concepto de encode y decode:


Una forma muy divertida y original de contarnos que son las meta-clases en Python y explicar un poco su uso. Personalmente ha despertado mi curiosidad al respecto así que leeré mas al respecto. Esta es la imagen quizá mas importante al respecto :D


Herramienta para lograr ser un experto en Python

Tengo sentimientos encontrados con esta charla porque a pesar que creo que la buena utilización de idioms puede ayudar a la legibilidad y mantenimiento del código no creo que sea una unidad de medida para la calidad del código o del programador. Dicho esto, creo que es un paso en la dirección correcta para el aprendizaje de Python como lenguaje. 

Conclusiones

De estos días me quedo el networking como mayor aporte, creo que el equipo de TheMotion regresó más reformado y cercanos entre nosotros después de haber debatido y convivido varias cosas que el día a día nos impide por razones varias. Creo que hemos aprendido algunas cosas y al menos yo me vengo con un par para investigar más a fondo. La próxima edición será en Málaga, solo por eso merece la pena ir, ( al menos no tendremos problemas con el transporte a Cáceres  ☺).


Saturday, May 20, 2017

Understanding before

The feeling of pride of belonging to the university you studied at sounds like a common thing worldwide. But what if your university was in a 3rd world country, with poor/none internet access and lack of resources? Would we feel the same? Well ... YES.

The University of Havana taught me to code without internet, something that I'll always appreciate because it forces me to really understand what's behind each line of code I write. I hope to keep this custom as long as possible.

In our first years in "La Colina" my classmates and I wrote most of the software in paper sheets or in a lab at midnight, without internet but having us as the community to throw questions and catch answers. We were our own StackOverflow. This situation forced us somehow to consult books instead of surfing the internet, to figure out solutions instead searching them; taught us (or at least taught me) do not provide solutions or code that we don't understand, as an effect of being unable to copy/paste source code from the web. Combining the possibility of searching for existing solutions to the problem and believing in the religion of understanding the chosen solution before deploying is a strong weapon in a software crafter hands.

I hope to never forget about this weapon, is the least I can do to thank back to my university for consciously or unconsciously providing it to me.

I dedicate this post to Rene Raul ( founder of skyplanner ) and Dustin ( software engineer at Linkedin  ) for sharing their related experiences.

Slides: De .Net a Python

Slides que utilizamos para nuestra presentación en CommitConf 2018. También se pueden ver  aquí Video: