 Bueno, pues hola a todos, muchas gracias por venir a esta charla, además está siendo contraprogramada por Harry Percival, así que gracias por estar aquí en esta de Django. Os voy a hablar de 10 lecciones que aprendí en un proyecto grande de Django. O primero me presento, soy Yamila, veis aí mi Twitter e mi Github, hace dos años e montamos en España la primera Paiconés e de paso montamos la Asociación de Paito en España y también de paso cofundé PayLadies España y después otras compañeras fundaron PayLadies Barcelona también al hilo de PayLadies aquí. Actualmente trabajo en Caleidos, que es un empresa que cofundé hace 4 años, está dedicada ao software libre y veremos porque luego es interesante tenerlo en cuenta e nos dedicamos a hacer aplicaciones para emprendedores y para startups e hacemos aplicaciones con Django. Entonces esta charla os voy a contar un pouco como hicimos la renovación completa de la guía Repsol que pode que os suene e está dirigida aquellos de vosotros que estáis empezando con el desarrollo web o que vais a enfrentar os a un proyecto grande por primera vez. Entonces máso o menos os voy a contar un poquito algunas lecciones sobre un proyecto grande. El proyecto, como os he dicho, es la guía Repsol. Teníamos que cambiar la imagen de la guía e además mantener toda esa nostalgia que para os que lo conozcais, lo entenderéis bien que tiene la marca, que tiene mucho tiempo. Los nostros padres iban con el libro en el coche que era en el callejero e con la información turística e entonces para este novo enfoque tuvimos como cinco puntos principales que fueron as fichas turísticas e gastronómicas, un mapa bastante potente, un planificador donde organizar tus viajes e bastante contenido editorial. Digo que es un proyecto grande. Teníamos 80.000 fichas turísticas e 500 artículos e sigueron creciendo. Así de primeras vais a decir que no es tanto porque está el Big Data e todo eso pero fue un verde reto mostrar las 80.000 fichas en el mapa a la vez porque no es nada fácil. La primera versión de la aplicación la liberamos a los 18 meses, se puso en producción a los 18 meses e después pasamos otros seis meses con transferencia e añadiendo algunas funcionalidades. El equipo original tenía dos X, un diseñador, seis backends, teníamos front, un product owner e además mucha gente alrededor del proyecto que eran los gestores de contenido, los traductores, la gente de marketing, los de IT de Repsol, el M de Gastronomía, que era también un stake hold de Canadá por allí e como somos una empresa a Jail e hacíamos proyectos a Jail e utilizamos las iteraciones estas cortas que son 42 sprints, 600 user stories e máis de 1.300 puntos. Así que máis o menos ese era el proyecto. Sabiendo eso vamos a empezar con las lecciones. Asi de primeras, quando uno se pone a hacer un proyecto web lo primero que piensa, incluso que no sea web, es un poco en la arquitectura. Incluso cuando estás en el mundo a Jail necesitas hacerte la composición del hogar. Si el proyecto es pequeño puedes quedarte con la estructura que propones Django esta especie de modelo vista controlador donde el back y el front están bastante acoplados. Pero cuando te pasas a un proyecto más grande basado en enfrentarte a ciertos retos que van a necesitar que tu aplicación tenga unos cimientos bastante más fuertes. Entonces, en la guía Repsol el website este que os he descrito pero como a los seis meses cambio el alcance radicalmente. Teníamos que exponer los datos a aplicaciones móviles hubo que hacer la versión móvil del mapa hubo que exponer los datos a través de un API para aplicaciones de terceros, integraciones con terceros. E claro, no estávamos exactamente preparados. Teníamos módulos de API pero no teníamos un gran API e eso que significa que lo pasamos un poco mal porque teníamos módulos de terceros. Entonces, lo que aprendimos por las malas en este caso foi que teníamos que haber separado desde o principio o API e o front. Porque o API suele ser bastante más estable e tiene un ciclo de vida distinto que os fronts que sueles tener varios fronts e que cambian constantemente. Entonces, esta foi nuestra primera lección. Siguendo con a idea de estar preparados para las cosas que puedan venir la idea es preparate para el cambio para integrarnos quando empezamos a desarrollar el proyecto nos teníamos que integrar con un proveedor de mapas. Parecia que iba ser Google Maps pero no estava claro, ni siquiera el cliente lo tenía claro. Así que como teníamos que empezar nós a montar la estructura o que hicimos fue crear un módulo que se habéis estado antes en la charla de Jesús es lo que llama adaptadores para bibliotecas externas nós dos creamos un adaptador de mapas e ese adaptador es el que hablaba con el resto de la aplicación. Quando llegó el momento en Google Maps e de hecho el proveedor no cambió pero a los dos meses Google decidió cambiar el API de los mapas porque pueden e entonces foi bastante fácil adaptar nuestro adaptador al nuevo API e a interfacia se quedaba igual con lo cual pusimos máis esfuerzo al principio pero fue unha buena decisión que pasa que a veces no sabes cuándo estás poniendo demasiado esfuerzo e a veces de equivocarse a veces un pouco de sobreingenería e de coger un poquito do olfato La lección tres es que de cara a coger este olfato a veces son útiles las reglas una de ellas que a mí me parece útiles refactorizar e abstraer que es unha forma de refactorización en la segunda oportunidad entonces cuando estás desarrollando e ves un trozo de código con tebulas loca no hace falta isolar en ese momento pero estáte atento porque la siguiente vez que lo necesites entonces lo abstraes e para los dos puntos de código que lo necesitan llámase a esa función de parsear, strings, fechas, lo que sea de esa manera sólo haces la abstracción este refactor quando hace falta innovantes puede ser útil antes de seguir muy bien, muy listos por supuesto estáis enmicharla In your face, Harry fersival ahora levantar la mano aquellos que conozcais al dedillo, la quinta lei de la termodinámica ya bueno, en realidad me lo estaba esperando porque es bastante habitual olvidarse de esta quinta lei pero que lo que dice es que antes o despues cometerás un error e será antes, lo dice la termodinámica no lo digo yo, tiene que ser verdad que nos dice la termodinámica tenemos unha lección que es como muy sencilla pero que a veces nos olvida que es test, test, test hay que testear as aplicaciones intensivamente en la guía Repsol hicimos test pero no muchos, nos estábamos especialmente orgullosos de esta parte e llegó un momento en el que para tocar ciertas partes del código sentíamos miedo allí había dragones se tiene que encargar la persona que lo ha hecho porque es la que sabe exactamente como lo ha hecho os tiene que sonar esto entonces, lo cierto es que Python y Django ofrecen un montón de herramientas para hacer que los test sean robustos, consistentes, repetibles al final, se yo me toco digo necesito estar segura de que non estoy rompiendo nada en mis compañeros e a unica manera es que mis compañeros hayan hecho test e que yo pueda volver a testear sus cosas e, el mismo modo, yo puedo asegurarme de que haciendo mis tests outra persona va a poder añadir código con cierta fiabilidad así que en Python y Django tenéis librerías específicas de Mox, de Stabs tenéis espías, un montón e hay que conocerlas de los puntos fuertes seguendo con no traslección uno de los puntos fuertes de Django es la comunidad que en eventos como este está clarísimo hay muchísimas bibliotecas que ya están hechas e entras en GitHub tienes decenas de miles de bibliotecas de funcionalidades, de aplicaciones que ya están hechas en Django en Python e que deberías utilizar quando tú estás haciendo un desarrollo grande porque hay otras personas que han hecho un montón de test, un montón de documentación un montón de trabajo e que seguramente tú no necesitas reinventar la rueda pero que pasa, que a veces esa biblioteca que quieres coger no es exactamente o que quieres o es demasiado grande e estás metiendo una dependencia enorme para una parte muy pequeña o por el motivo que sea necesitas tener muchísimo control de lo que está sucediendo es importante aprovecharse de uno de las ventajas que tiene Python, que es el software libre e que además es bastante es muy fácil de hackear o de conocer, bueno, C types e o sujo es que hay que conocer las tripas de la tecnología en la que estamos e atrevernos a desarrollar lo que haga falta en el momento del mismo modo aquí igual que antes cuándo te pones a desarrollar desde cero e cuándo tienes que utilizar otras librerías en la guía Repsol utilizado Django Respringware para nuestra API no hemos hecho un API desde cero teníamos que hacer un gestor editorial pues nos inventamos el CMS utilizamos Django CMS que es muy potente e está genialmente hecho e le hemos extendido para hacer nos propios widgets sin embargo teníamos que hacer una migración desde un esquema dado en SQL Server hasta el nuevo esquema en Postgres e existen ya ETLs para los novos ETL extract, transform e load para hacer migraciones de bases de datos existen ETLs como pentajo por ejemplo pero no hacía exactamente lo que queríamos ni como queríamos e es unha herramienta muy grande así que nos picamos nuestro propio ETL para nuestro caso de uso utilizando pues el foring datarrapper de Postgres utilizando los custom commands de Django así que pues en este caso lo hicimos nosotros mismos, del mismo modo que a técnica de JavaScript que pudo hacer cluster de 80.000 de un diccionario con 80.000 elementos pues nos tuvimos que picar nosotros el clusterizado en back e mandar a front solamente la versión mínima de las fichas en el mapa así que no é sempre es fácil de saber pero bueno además de los grandes titulares sobre arquitectura, sobre test hay algunas lecciones o buenas prácticas que son muy útiles sobre todo programando, si habéis hecho el workshop de Django Girls ya sabéis la utilidad de esto pero si no por si acaso para mí es importante decirlo e usar un sistema de control de versiones distribuido quando hay mucha gente haciendo cambios al código es importante poder revisar el histórico poder ir y volver localizar los bugs fácilmente e de forma determinista en la guía Repsol un nuevo código lo que é master o que hacíamos era usar el pull request significa que para empezar a trabajar en una nova funcionalidad nos hacíamos una rama a partir de master vamos desarrollando aí e quando estamos conformes con el código, los test y la documentación entonces hacemos un pull request este pull request lo va a revisar un compañero el compañero lo pode aceptar lo pode rechazar o puede proponer cambios que es lo más habitual pero de esta forma todo el código que entra en master es un código de xonas lo cual está muy bien porque reduce drásticamente el número de bugs que hay en tu código lo cual está bastante bien usar pull request como procedimiento para añadir código a master hay una parte del desarrollo que a veces se nos pasa sobretudo quando somos programadores que é a idea de documentar porque nuestro código es super clarito se entiende perfecto e no hay que documentarlo pues no, hay que documentarlo e se es un aplicación grande hay que documentarlo más en la guía rebsol teníamos dos documentaciones la documentación interna para desarrolladores la documentación externa para que vaya a consumir el API le dan igual las dependencias le dan igual las versiones lo que le interesa son statuses responses y requests entonces con eso tienes ya una buena primera aproximación en la guía rebsol lo que además hicimos foi lo que llamamos que creo que existe ya antes de nosotros desarrollo dirigido por documentación todos os user stories que estuvieran que ver con el API primero crevamos la documentación e se lo mandabamos al equipo de front en forma de pull request el equipo de front que é o que está trabajando con el html e o javascript é o que decide o que válida e esa propuesta realmente les vale e entonces una vez que aprobaba el equipo de front, el pull request vamos a implementarlo viene a ser un pouco o diseño por contrato pero está enfocado en un nivel un pouco má salto e a última lección quando estás haciendo un proyecto con software libre que haces usar software libre para poder usar software libre existe un ecosistema que deberíamos tratar bien mejorar, alimentar así que cuando desarrollas tienes que contribuir estaría bien contribuir al software libre tanto como se pueda hay muchísimas formas se puede portar un bug, se puede arreglar un bug se puede escribir un tutorial o se puede dar una charla se puede por supuesto liberar unha biblioteca eso está sempre genial, encaleídos todos os clientes firman unha clausa en el contrato por la cual acceden a que vamos a liberar en el curso del proyecto vamos a liberar software libre que no sé vamos a liberar sobre, perdón de partes no críticas de su modelo de negocio con lo cual encapsulamos funcionalidades las liberamos e las consumimos como bibliotecas externas y puede que alguien le resulten útiles para nosotros como en este caso ha sido liberar Tyga que es un producto que hemos hecho nosotros, está hecho con Django está hecho con Angular e estamos encantados de poder liberar, pero para poder liberarlo tienes que cumplir las 9 anteriores y otras 90 más porque lo suyo es que por un lado no te queres morir de la vergüenza por tu código e por outro lado, quieres que que la gente contribuya con un poco de felicidad así que hay que documentar bien, hacer una piponita por supuesto tener a gente aí echando un cable pero que haya test, que haya un repositorio ordenado e para todo eso en el caso de Tyga es libre e ha funcionado muy bien, tenemos un montón de contributos pero es que hay que hacer un esfuerzo de hacer un aplicación un poco bella así que estas son las 10 este es el resumen máso o menos veis que pueden aplicar a cualquier proyecto grande sin embargo cuando estás trabajando con Python y Django cosas máas específicas como que bibliotecas están obsoletas quales son las personas que son buenos mantenedores e te puedes fiar mucho máas de su código de sus productos así que aplica a todo pero con algunas consideraciones sobre el ecosistema de Python y Django e básicamente estas son mis 10 lecciones tenes alguna pregunta no, el ETL era tan tan ad hoc estaba hecho específicamente para leer las tablas del SQL server que nos exponían en ese puerto y en esa IP e... non miento, de hecho nos teníamos que descargar fíjate, el ETL les mandábamos las queries al cliente, las ejecutaban e nos las dejaban en un FTP nos descargábamos entonces los CSVs porque es que era la única manera el único acceso que nos daban a la base data original FTP nos descargábamos los CSVs los levantábamos con el foreign data wrapper e hacíamos los inserts hacíamos unas novas queries con os inserts entonces claro nos montamos unas clases que parseaban todo aquello, vamos, no le serviría de hecho probablemente no nos serviría máis a nosotros tan pouco ahora mismo esa parte estava muy bien testeada e unha documentada porque dependía tan pouco de nosotros que dedicamos mucho esfuerzo en que aí la cobertura fuera muy alta alguna pregunta máis del... digamos el desarrollo por contrato como funcione esa metodología el tener un un equipo de backend máis especializado que desarrolla una documentación e front enda por bueno esa interfaz tenéis mucho toma e DACA lo habéis discutido previamente el tipo de interfaz que se necesita des del frontal, como lo hacéis pues sí, primero como somos equipos pequeños estamos sentados un al lado del outro realmente ahí estamos constantemente permeando el diseño de que queríamos hacer con el API, de como queríamos que fueran as respuestas, de que significa el 404 e de que vamos intentar que el 404 represente lo que tiene que representar eso ya lo habíamos hecho previamente entonces para cuando llegamos para cuando yo hago el pull request digamos que esa estructura básica ya está echa e lo único que hago es temas de contenido que no son los fallos que yo creo que pode dar pero ese el que está maquetando e el que está preparando la interfaz con lo cual me dice no me estás dando este dato que necesito o me está faltando este error necesito que también me reportes este error llegado ao caso, así que digamos que la estructura ya está resuelta aún así es imperfecta porque a veces el equipo de front por supuesto, nós nos equivocamos el equipo de front tiene muchísima prisa e lo acepta e hemos implementado algo que luego hay que volver para atrás de todo, muchas gracias por la charla e bueno, iba también en el tema del desarrollo dirigido por el contrato e habéis probado utilizar também TDD alineado con este tipo de desarrollo eu he probado a padecer el TDD entonces sí, lo que pasa es que quando estás en mi experiencia esto ya es, no puedo hablar de TDD cuando estás montando la aplicación para mí no hay TDD posible no puedo hacer TDD de como voy a definir por exemplo, os modelos de Django pero vamos que en este momento está Harry Pérsival hablando de que se puede de que se puede desde o minuto cero e ele lo hace e supongo que con mucha expertise se puede, en mi caso por ejemplo no, cuando ya lo tienes montado e lo que vas haciendo es añadir funcionalidades mucho máis aisladas aí sí que es mucho máis fácil empezar a implementar el test, dejar que falle con la funcionalidad concreta mi experiencia mi pregunta va en torno para el tema de la API primero para el tema de documentación utilizabais swagger nos ha ido fatal en el proyecto en el que estoy ahora hemos intentado utilizar blueprint que es un markdown con dracof que lo que haces te le este blueprint e te lo monta de hecho lo moquea para que front pueda tenerlo moqueado es decir dedicamos muchísimo esfuerzo a mantener la tecnologia que hay detrás así que le hemos cambiado por hacerlo a mano e dedicamos el esfuerzo en mantener el contenido e isto haces la documentación e perdona? utilizamos sphinx o askydoctor por ejemplo askydoctor vale y la segunda tema de los test utilizais alguna librería específica ola misma que da Django para testar la API en el proyecto de diarrepsol que es un poco el que estoy hablando utilizamos no nos trajimos nada externo de lo que ya venía con Python y Django e e mi opinión fue una ahora, digo, fue una mala decisión teníamos que dedicar más tiempo a aprender muy bien alguna herramienta para moquear bien ciertas cosas porque teníamos un montón de integraciones con terceros tuvimos muchos fallos teníamos que haber hecho má test también teníamos que na parte de test no tengo ninguna cosa que mostrar má que el error que tuvimos en realidad alguna pregunta más? non alguna por dacharlas o primero, he visto en la primera transparencia que teníais tema de traductores tú es alguna lección interesante en internazionización? pues que el software libre y la internazion están rotos no, es verdad no, la comunidad libre nos da igual internazionalizar bien que significa esto? que tenemos puntopos generamos ficheros puntopos e se lo mandamos a un traductor e esperamos que mágicamente lo traduzcan todo bien sin contexto porque el puntopo es un fichero plano e ademas les mandamos unos ficheros con unos símbolos como raros en los que dentro ponen tantos porcientos y cosas e esperamos que si dentro ponen value no traduzcan eso por valor pues no se porque no se es un traductor le das una palabra así que hay algunas herramientas como transifex en taiwan me parece que estamos utilizando transifex sí que hay algunos mecanismos tienen bastante coste de poner en marcha e de mantener entonces merece la pena cuando tienes un proyecto completamente abierto cuando nuestro proyecto es un deliver para el cliente lo que hacíamos era en este caso, la empresa de traducción tuvimos mucha suerte porque era muy competente se pudo hacer con os puntopo montó un adaptador de su herramienta para os puntopo e podia traducir enviarnos los de vuelta non era nada automático le enviábamos os puntopo os traducía nos lo enviaba de vuelta e los compilábamos e os poníamos en producción deja de hacer preguntas difíciles por favor alguna fácil bueno pues gracias e cerramos el track local contigo