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.

Thursday, April 27, 2017

Pleasure on deletion

Have you ever wonder how difficult is to delete some code in your service? Recently I watched The art of destroying software by Greg Young which is a good starting point to think about something that have been ringing around my current work place: "delete code is good".

Nowadays micro-services and distributed systems are trending topic in software development. It seem like if you are doing the micro-services way then you are in the right path or at least in the modern path. In my opinion is more about:
  • Know well enough the responsibilities  of each part of you system
  • Keep good balance of coupling and cohesion
  • As consequence be able to Delete Code 
Because when you have those then you can go and delete part ( or complete) of a service because: is not need anymore, want to kill some technical debt or even for the fun of recreate it from scratch with different approaches. At the end you are going to have the same system from business perspective but with less code to read, less code to test and less code to cause error. If something is not need or not used just delete it! Keep in mind that is even better if you delete code and you not need to change your tests.



I finish with some phrases of Greg Young:

Unit tests only show that the tests passed, they don’t show lack of bugs.
The definition of a refactor is: I either change my tests or my code and I only change one out of the two.
 Technical debt is not a concept business people understand.
 If you can rewrite a piece of code in a week, you can understand it in a week. 
The one big secret to great consulting: Never build big programs. 
The difference between great code and sucky code is the size of the programs. 
Don’t try to plan for future changes. Focus on the ability to completely rewrite everything from scratch when that change actually occurs
Make the decision at the last responsible moment. 



Tuesday, April 18, 2017

Socrates Canaries 2017

The past week ( April, 6-9th ) I had the honor to be a participant in the SoCraTes Canaries 2017, the Software Craftsmanship and Testing conference. Almost three days full of experiences that helped us to become better people and better crafts(wo)men. It was my first time in a Socrates Conference and also first time in an Open Space conference format.

This are the strong points I would like to remark:
  • Open Space or Unconference
  • People willing to share and open to learn
  • Software side talks ( like: liquid modernity, mental health, time management, ... )
  • English as default language
  • The Venue
  • Networking
It's amazing how the unconference flows leading by our own goods, filling the talk slots by the spontaneous willing to learn something new and/or to share knowledge, experiences and/or learned lessons. Something that shocked me, in a good way, that talks did not need to be prepared, if needed we just improvised so we all learn/share.  All the talks, workshops, mob sessions, round table and so on were hosted in English. The venue, NH Imperial Playa, is a great place to host this kind of events with sufficient rooms (including the beach and the bar opened 24hrs for us),  great breakfast and dinner ( the lunch was improveable), good internet connection, good material to draw and present and  near to the beach so you can swim between talks if you want to.



One of the strong points of this unconference is the amount of software side talks, speeches or discussions about topics with no straight relation with code, programming or similar which affect us directly or indirectly in our daily professional life. There were many of them for example: learning styles, mental health, liquid modernity, divorce, time management, reading speech and others. I'm not going deeply on any of them but the essence is that each of them reflects how our society is becoming more open to treat these topics in a proactive and positive way focusing ( in this specific conference ) on how to affect and/or benefit  us in our profession. I was impacted by the fact that I have never taken the time to learn how to learn, how to read and/or how to filter information thanks to talks like Learning styles and Personal time management, so I'm going to be focus on this topics in this first weeks after the event.  Another lesson learned is to avoid the Impostor Syndrome, giving value to our knowledge and sharing it even if we think is too simple because it can have value for someone, this post is one way to start applying it. We all have valuable things to share to the audience via blogs, videos, talks, code and any other way we can imagine.



After this general thoughts, let's go deeper into some talks:

Lessons learned & Tools: Remote
Round table to share experiences and tools related to remote work. Some common opinion about difficulties of doing pairing, set rules at home and that  companies should facilitate laptops, headphones, internet connection and others to make it happen smoothly.
The remote culture need to be extended and understood company wide and here the trust in each other is the key to success. If we are working remotely people in the office should feel not difference and vice-versa, this include lot of possible situations, that I'm not covering here, for example: the side talks by the coffee machine that sometimes become real solutions and remote people don't know about it or when the remote colleague has internet issues at home affecting the all team. Some tools and tips can be tried in order to find the right balance for the company for example using Bluetooth common micro instead laptop microphone for meetings, use discord or similar tool, having one or more remote days if you are not fully remote in order to practice and so on. Some tools mentioned:

  • team presence tools for example: PukkaTeam, SqWiggle
  • screenhero
  • jitsi
  • tmate 
  • trello
  • github projectst 
  • discord 
  • mumble
  • google hangout
  • google docs


Craft thinking @mashooq
Thoughts about the book "The craftsman" by Richard Sennett and how affects in our own definition of craftsmanship. Some notes:

  • Craftsmanship.  Human impulse: the desire to do a job well for it's own sake.
  • Motivation matters more than talent. Motivation to solve the problem.
  • Conflicting Objectives. Impaired by competitive pressure, frustration and obsession.
  • Perfection vs Practicability. Minimum Lovable Product vs Minimum Lovable Feature. It is difficult to find the right balance but it can be refined with pair programming, peer review, iterations, etc
  • Minimal force.
     


Consumer-Driven Contracts (CDC ) 
@pclavijo
Interesting talk showcasing the Contract Driven Test with real example. Lessons learned:

  • Is about TDD and unit testing, not integration testing nor execution time checks. Using the contract stored in a broker.
  • CDC and Continuous Integration. Once the contract is changed ( in the consumer )  and the provider change then CDC validates all the consumers contracts if at least one is broken you cannot merge
  • Check if incoming Pact versions will support messaging. Anyway the tool used ( if any) is not the key thing in CDC.
Learning Styles @indykidd

Useful round table about difference learning styles. .Some ideas were shared on approach to follow in specific occasions for example using a book when you clearly know what you need to learn or start with videos, audios, small lectures when you are deciding about something, but each person will have his own way of going it. One key-point was the fact that we need to learn how to learn, how to read ( not necessarily in order not necessarily everything) , what to read and filter out everything that disturb us from the may objective.

Some resources:

  •  Information diet ( Book )
  •  Pragmatic Thinking and Learning ( Book )
  • Dan Sha Ri ( Book )
  • The speed reading bible ( Book )
  • Learning how to learn ( Course )
  • Spines ( app )


Personal Time Management @gardenunez
Round table about how to better organize yourself in order to fulfill your objective and not get stressed because of the rush we live nowadays. Some notes:

  • Keep focus on what we are doing.
  • Measure time on some activities and analyze later to see if it follows our priorities.
  • Use the pomodoro technique, use alarms and silent notifications
  • Eat the frog. Do the most unwanted thing first 
  • Focus (or Stop Starting, Start Finishing) ( recommended by @eferro )

It isn't that we don't have time to do some things, is that we need to prioritize those things.

Taming the monolith @mashooq
Great talk about architecture. Some insides:

  • Coupling and Cohesion is always present. Having microservices does not mean to remove coupling but to tame the coupling achieving a balance with cohesion.
  • Use the User Journey as reference to define your architecture. Do not use the data to create the boundaries between services.
  • Be aware when you have a distributed monolith.
  • "Everyone need to be architect and developer at the same time" - @mashooq


Liquid modernity @jordianguela
A talk about how society has changed during the years to become more dynamic based on the thoughts of Zygmunt Bauman. Couples not necessary stay together for all life, jobs are not necessary for all life, people change city of living constantly, travel more often, etc. Jordi exposed the facts and together we analyzed the pros and cons about it, I let you (the reader) research about it and come to your conclusions.


UX & design @adelatorrefoss
Talk about how to integrate development and ux into our way of working.  Two approaches were analyzed:
  • Agency: where the UX-er is not part of the company and work part-time in order to accomplish some functionality(ies). The approach has the problems that the designer doesn’t have enough focus because he/she is normally working in several part-time project/companies at the same time and once he/she leaves the company he take with him a lot of knowledge not spread in the development team.
  • In House: The UX is part of the team and thus removing the previous problems if we achieve that UX-ers and developers work together in order to increase no only the business knowledge inside the company but also to improve performance and team cohesion. Of course this approach is normally more expensive economically ( at first ).
Postgresql. The one tool to bring to a desert island @juanignaciosl
Presentation about some features of Postgresql used in Carto. Better to refer you to the presentation itself. Key points:
  • Json vs Jsonb: Introduced by postgresql since version 9.2 ( for JSON) , 9.4 ( for JSONB). Is making a big difference for postgres as a database solution without need to move to other NoSQL solutions. Recommend to use JSONB for better performance and  operations.
  • Generate series for data generation, good for testing purposes. 
  • Good documentation references in the presentation. 

Other sessions 
  • Carbon offset
  • Gendered language
  • How to build your personal brand
  • Different Organizations

Resources
Summarizing these talks plus some side talks in the corridors I listed some resources that may be useful:

Books:
Non violent communication
Reinventing Organizations
Spin Selling
Start with why
Thinking fast and slow
The back of the napkin
Bikablo
The laudest duck
The devops 2.0 toolkit
The craftsman - Richard Sennett
Information diet
Pragmatic Thinking and Learning
Dan Sha Ri
The speed reading bible

Talks:
The art of destroying software
How to get better at the things you care about

Courses
Learning how to learn #coursera
DDD fundamentals #pluralsight

Others
lazy manifesto
Neuland markers
Is postgresql good enough
Safe and unsafe operations postgresql


Final thoughts and Thanks
I specially thanks to @eferro for arousing my curiosity about this conference and guide me in the process as a rookie craftsman. You can read his notes about the conference.
Thanks to codesaiDaniel , Miguel for making it happen so well. Please keep it like that for the upcoming ones.
Thanks to this amazing craftsmanship community for always being ready to share and learn.

See you in the next one.



 

Slides: De .Net a Python

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