Efectos colaterales de TDD

El uso de TDD (desarrollo guiado por la pruebas) tiene varios efectos colaterales, a mi criterio, la mayoría de ellos positivos. Algunos de ellos son evidentes y ampliamente conocidos, pero algunos otros suelen pasar desapercibidos.

Uno de estos efectos colaterales las pruebas y el código de prueba pasan a ser ciudadanos de primera categoría. Esto es así porque el desarrollo arranca con las pruebas y eso hace que el código de las pruebas sea una herramienta central para pensar nuestro diseño. Antes de escribir una funcionalidad la vamos a estar describiendo en una prueba, eso concretamente implica que en la prueba escribiremos invocaciones a métodos y objetos que aún no hemos creado. Esto no ocurre cuando escribimos las pruebas a posteriori. El hecho de que las pruebas sean un ciudadano de primera categoría implica que el código de prueba debe ser tratado con el mismo cuidado que el código de producción, esto es: debe ser mantenible, cumplir las convenciones y sobre todo ser claro y evitar duplicaciones. Ojo, no es que al escribir las pruebas a posterior no debamos cumplir con esto, pero al hacer TDD estas propiedades del código de prueba toman mayor relevancia porque el código tiene un protagonismo distinto.

Al mismo tiempo, como no escribiremos código de producto sin tener primero una prueba, es común que la cantidad de pruebas sea mayor que si escribimos pruebas a posteriori (no tengo evidencias formales de esto, es más bien una sensación basada en lo que visto tanto con mis alumnos como con mis clientes). Cuantas más pruebas tenemos, más importante es la claridad y mantenibilidad del código de prueba. Curiosamente y un poco a contramano de esto, suele ocurrir que al agregar nuevos casos de prueba sobre una funcionalidad existente, muchas veces comenzamos “copy&pasteando” el código de prueba del caso anterior. Esto en principio genera código duplicado y ahí la importancia de hacer refactoring sobre el código de prueba. Personalmente me pasa que a partir de cierto punto, siento que hago mucho más refactoring sobre el código de prueba que sobre el código de producción. Más aún, cuando la aplicación alcanza cierto tamaño o grado de complejidad los refactorings sobre código de prueba llevan a generar clases/métodos “de soporte” por ejemplo para generar objetos/datos de prueba. En línea con esto me parece que no es casualidad que el libro de Gerard Meszaros tenga como subtítulo “Refactoring Test Code“. También los libros de Tarlinder y Freeman tienen capítulos dedicados al cuidado del código de prueba.

A propósito de este tema, el próximo jueves 12 de noviembre voy a estar dando una charla en la conferencia dotnetconf 2020 en la que compartiré algunas técnicas para mejorar la legibilidad de tests en C#: Enhancing Test Readability with Extension Methods and Fluent Interfaces.

Sobre mi taller de Git en Nerdearla 2020

Ante todo: ¡Zarpado evento Nerdearla 2020!

En este año de pandemia he participado de varias conferencias online pero ninguna estuvo ni cerca de Nerdearla, ni a nivel contenido, ni a nivel producción, ni a nivel interacción (y eso que Nerdearla aún no terminó). Simplemente mis felicitaciones al equipo organizador.

Ahora sí, el taller. En la sala de zoom había unas 40 personas que era el límite establecido, pero en paralelo la sesión fue transmitida por YouTube y por la página de la conferencia. Según me comentó uno de los organizadores llegó a haber más de 250 personas viendo la transmisión.

Al iniciar el taller hice dos preguntas a la audicencia en parte para validar algunas “creencias mias” y en parte para entender mejor a la audiencia. Para esto utilicé la herramienta mentimeter. En primer lugar les pregunte si habían utilizando alguna otra herramienta de versionado más allá de Git. Resultó que aproximadamente la mitad de los que contestaron solo habían trabajado con Git, en un palabra los podríamos calificar como “nativos git”.

Luego pregunté sobre la forma habitual de utilizar Git en el sentido de que qué tipo de herramienta utilizan. Resultó ser que la gran mayoría (~70%) indicó utilizar la terminal. Esto me sorprendió pues pensé que por la forma en que estaba anunciado el taller, me encontraría con mucha menos gente utilizando la consola y mucha más gente utiliza el IDE.

Personalmente me quedé muy conformé con el taller y hubo varios de los participantes que me manifestaron los mismo. Agradezco a todos los que participaron y también a Aixa por haberme asistido en la logística del taller.

Comparto algunos recursos:

Colaboración Universidad Pública y Estado: un potencial círculo virtuoso

El estado invierte en la universidad pública. Por su parte la universidad educa a los ciudadanos, hace investigación y genera conocimiento que ayuda a mejorar la sociedad. Esta mejora se traduce (indirectamente) en una mejora del estado y así se cierra un circulo virtuoso.

En el área de informática/computación/sistemas creo que se da una situación en la que este circulo virtuoso no resulta tan virtuoso, o al menos no todo lo virtuoso que podría resultar.

Más allá de mi trabajo en la universidad, llevo casi 20 años trabajando en la industria del software, he sido empleado de distintas empresas privadas y en los últimos años he trabajado de manera independiente. Nunca fui empleado de un organismo estatal (más allá de mi trabajo en la universidad) pero como empleado de una empresa privada he trabajado en proyectos de consultoría y capacitación para organismos estatales. Proyectos que perfectamente podría haber realizado una universidad. Al mismo tiempo tengo muchos colegas en situaciones análogas. Esto me ha disparado una pregunta recurrente: ¿porque está una empresa privada haciendo este proyecto y no una universidad pública?

Es aquí donde veo que el círculo virtuoso Estado-Universidad no es todo lo virtuoso que podría ser. Si los organismos estatales contrataran a universidades públicas, estas podrían tener más presupuesto, una cuestión siempre escasa en las universidades Argentinas. Al tener más presupuesto podrían hacer más investigación, o mejorar diversos aspectos de su operatoria y en un última instancia aportar más valor a la sociedad.

Intentando dar respuesta a la pregunta planteada comparto aquí algunas posibles respuestas que se cruzaron por mi cabeza:

  • La universidad no tiene el conocimiento para dar servicios a terceros. No lo creo. Si efectivamente fuera así, entonces tendríamos un problema muy grave. Pero sinceramente no lo creo. Muchos docentes universitarios del área de informática trabajan en la industria y enseñan en la universidad justamente lo que ponen en práctica en la industria (es mi propio caso y el de todo mi equipo docente).
  • La función de la universidad no es dar servicios a terceros. Falso, la universidad (al menos en Argentina) tiene 3 funciones: docencia, investigación y extensión. El prestar servicios a terceros es una actividad de transferencia que puede enmarcarse perfectamente dentro de actividades de investigación y/o extensión.
  • Las personas de la universidad que podrían brindar servicios a terceros prefieren hacerlo en forma privada que por medio de la universidad. Este sí puede ser un tema. Las diferencias salariales en el área de informática entre la universidad y lo que paga el sector privado pueden ser muy relevantes. Sin embargo, según he estado averiguando, hay alternativas que podrían habilitar que los docentes que trabajen en brindar servicios a terceros puedan recibir una remuneración equiparable a lo que podrían ganar desde el sector privado.

Ojo, con esto no estoy diciendo que la universidad tenga que convertirse en una software factory o en un proveedor de servicios de manpower vendiendo “programador por kilo”. Sino que los tipos de trabajos en los que imagino a la universidad, son trabajos de capacitación, consultoría o proyectos de desarrollo con un alto componente investigación/innovación.

Me consta que en algunos casos de algunas universidades y algunos organismos, esta colaboración fluye exitosamente, pero no es el caso común.

Creo que revertir esta situación requiere de un acuerdo de las 3 partes: las universidades, los organismo estatales y los docentes/profesionales.

Estoy bastante convencido de esta idea del círculo virtuoso de colaboración Estado-Universidad y es por ello que ya estoy gestionando para participar de un proyecto de colaboración entre la universidad y un organismo estatal durante el año próximo. Continuará…

#HistoriaDeTrinchera: Planning de una User Story

Recurrentemente hablo con gente que me comenta de sus dificultades para completar el trabajo planificado en la iteración. En muchos de esos casos mi sensación es que el equipo incluye funcionalidades en su iteración sin tener suficientemente en claro su implicancia. Creo que muchos se han ido del extremo de especificar cada detalle de la funcionalidad en un documento tipo especificación de casos de uso, a directamente pasar al otro extremo y escribir un título y nada más. Es por esto que quiero compartir en este artículo el ejercicio que intentamos hacer en mi proyecto actual a la hora de armar nuestro backlog de iteración determinando las funcionalidades que trabajaremos.

Una de las particularidades de nuestro proyecto es que como parte del equipo tenemos una especialista en diseño de experiencia usuario (digo particularidad pero me parece que esto es cada vez más común). A su vez esa especialista es en simultáneo parte de otro equipo que trabaja en forma transversal en el diseño de la experiencia de varios productos de la organización. Es así que las funcionalidades (que usualmente llamamos user stories) se piensan desde un momento muy temprano teniendo presente la experiencia que se quiere ofrecer al usuario. De esta forma, cuando hablamos sobre una funcionalidad en una reunión de planificación generalmente ya contamos con un diseño de pantalla (o tal vez varias) que acompañan la conversación.

De la conversación sobre la user story buscamos esclarecer los siguientes puntos para poder agregarla al backlog de la iteración:

  • El escenario principal de uso y alguno de los escenarios alternativos más importantes. De ser posible, y si la complejidad lo amerita, ahi mismo expresamos estos escenarios en sintaxis Gherkin.
  • Las tareas necesarias para completar la story como ser: codear la pantalla, codear un nuevo servicio, codear componente para conectar con otro sistema, generar los datos de prueba, automatizar la prueba end-2-end, etc, etc
  • La dependencias de otras aplicaciones/apis y estados de las mismas (esa API que debemos consumir ¿ya está disponible en producción? ¿la está consumiendo algún otro equipo?)
  • La necesidad (o no) de hacer que la funcionalidad sea “apagable” o “segmentable”. Hay funcionalidades que son simples y de baja criticidad que apenas las terminamos pueden ser liberadas al público en general, pero hay otras que, ya sea por su complejidad o criticidad, se prefiere liberarlas gradualmente a distintos grupos de usuarios. En términos técnicos pretendemos identificar si la funcionalidad debe ser “toogleable”.

A medida que vamos viendo cada una estas cuestiones vamos tomando conciencia del tamaño y la complejidad de la funcionalidad y puede que en base a ello decidamos partir la funcionalidad en varios cortes (lo que comúnmente se conoce como slicing).

En algunos casos parte de estas cuestiones se hablan en una reunión de refinamiento que ocure previamente a la planning. A su vez dicha reunión nos permite identificar potenciales blockers para el desarrollo de alguna funcionalidad pedida. En algunos casos también ocurre que la funcionalidad pedida depende de funcionalidades provistas por alguna API desarrollada por otro equipo y que no se encuentra disponible aún o tal vez no provee todo lo que necesitamos. En estos casos en lugar agregar la funcionalidad en cuestión a nuestra iteración, agregamos una tarea de gestión para darle seguimiento a al desarrollo de esa API e incluso hacer algún prueba de concepto como para ir familiarizándonos.

Dos datos adicionales de contexto:

  • En las reuniones de refinamiento no participa necesariamente todo el equipo. Seguro están los especialistas de negocio, la especialista en UX, el facilitador y algunos devs. En general esta reunión dura 1 hora.
  • Las reuniones de planificación tiene 2 partes: una estratégica donde participa todo el equipo y una táctica donde solo participan los técnicos (devs & testers). Entre ambas se van entre 2 y 3 horas.

A partir de lo anterior resulta que para planificar una iteración de 2 semanas este el equipo requiere en total de unas 4 horas de trabajo conjunto.

Algunas de estas cuestiones puede que no coincidan exactamente con lo que recomiendan algunos libros y posiblemente a algunos lectores puede que le resulten impracticables en su propio contexto y lo entiendo. No es mi intención convencer a nadie de trabajar de esta de esta forma, simplemente pretendo compartir lo que a nosotros nos viene funcionando y nos permite entregar software todas las semanas.

Sobre nuestra dinámica de aula invertida

En las dos materias que dicto (UBA y UNTreF) utilizamos la misma dinámica de clases. la cual está basada en una estrategia de aula invertida con técnicas de educación centrada en el alumno y evaluación constante. Más allá de las definiciones formales, y en términos concretos, esto implica que cada tema que estudiamos en la materia consta de tres instancias: estudio, aplicación y evaluación.

Aclaración: en las siguiente secciones cuando digo aula me refiero al tiempo/espacio compartido sincrónicamente entre alumno y docente en forma semanal

1. Estudio

Ocurre fuera del aula, el alumno debe sentarse a estudiar, típicamente viendo uno o varios videos o leyendo un texto. Esto reemplaza la típica clase magistral donde el docente expone pasando diapositivas. Es justamente este tipo de clases las que convertimos en videos y que los alumnos consumen fuera del aula.

2. Aplicación

Esto ocurre dentro del aula y puede tomar distintas formas dependiendo del tema en particular, pero siempre intentamos que sea una actividad interactiva. Puede que sea una sesión de mob-progamming o alguna actividad de simulación (como el Pizza Game) utilizando alguna herramienta de soporte como Miro, Mentimeter, Kahoot o similares.

3. Evaluación

La evaluación ocurre también fuera del aula y dependiendo del tema puede ser un ejercicio de programación y/o un cuestionario.

De esta forma cada tema es estudiado y evaluado individualmente. Luego complementariamente tenemos dos trabajos integradores donde los alumnos trabajan en equipos y ponen en práctica todos los temas ya estudiados de forma integrada.

Git se ha convertido, hace ya un par de años, en el estándar de facto en lo que refiere a versionado de código. De hecho hay muchos “nativos Git”, gente que desde un comienzo ha trabajado solo con Git sin tener ningún acercamiento a otra herramienta de versionado. Al mismo tiempo, si bien hay gente que hoy en día trabajada con otros sistemas de versionado anteriores a Git como Subversion o CVS, muchos ya tienen en vista la migración a Git.

Sin embargo, más allá de su popularidad, yo tengo la sensación que muchos usuarios de Git desconocen su potencialidad. He visto muchos programadores utilizando Git desde sus IDEs o con alguna herramienta visual (tipo SourceTree), lo cual hace que en cierto modo uno “no se entere” si está usando Git, Subversion o cualquier otros sistema de versionado.

A partir de esto es que se me ocurrió armar este taller, con un enfoque muy práctico para explorar algunas funcionalidades de Git que pueden resultar no tan conocidas. Entre las cuestiones que tengo en mente cubrir están: stash, squash, blame, submodules, cherry-pick, clean y reset entre otras.

Para participar de este taller es necesario que los participantes estén familiarizados con el uso básico de Git (commit, pull y push) y cuenten con una cuenta de GitHub. Adicionalmente les recomiendo ver esta serie de videos que armé hace ya varios años para explicar el uso básico de Git.

La primera edición de este taller será en el contexto de Nerdearla, en cuanto tenga confirmado día y horario lo estaré compartiendo en redes.

Radiografía de un equipo trabajando a lo Extreme Programming

Hay muchas descripciones teóricas en libros, artículos y conferencias sobre cómo trabajar con la metodología Extreme Programming, pero muy pocos dando detalles. En este sentido un recurso excelente es el libro de Henrik Kniberg, Scrum and XP from Trenches. Al margen de ello, quiero compartir aquí algunos detalles de implementación de la forma en la que trabaja el equipo del cual soy parte actualmente.

Equipo (la gente está en todas las dailies):

  • 5 Devs (skills de front, back, ci/cd, infra)
  • 1 Tester
  • 1 UX
  • 1 facilitador
  • 2 personas de negocio

Proceso:

  • Duración de iteración: 2 semanas calendario, time-boxed
  • Daily Stand-up: todos los días 9.15
  • Revisión de iteración & Demo: Jueves de 10:00 a 10:30 (cada 2 semanas)
  • Retrospectiva: Jueves de 10:30 a 11:30 (cada 2 semanas)
  • Planificación estratégica: Jueves de 11:45 a 13:00 (cada 2 semanas)
  • Planificación táctica: Jueves de 14:00 a 16:00 (cada 2 semanas)
  • Refinamiento: por el no tiene un horario ni cadencia fija, viene variando de iteración en iteración
  • Invision (el nombre aún no me cierra): martes de 11:00 a 12:00 tenemos esta reunión semanal donde coordinamos con otro equipo que desarrolla una API con la cual tenemos un importante dependencia

Prácticas de desarrollo:

  • Trunk-based Development, todo el equipo, todo el tiempo trabajando en la misma rama
  • Pair-Programming, todo el tiempo
  • TDD todo el tiempo en el código server-side (C#)
  • Test-Last en el código de client-side (angular)
  • Despliegue automatizado a todos los ambiente
  • Feature Toggling

Stack tecnológico:

  • Net Core 3.1
  • Angular 9
  • Gitlab (versionado de fuentes & pipeline)
  • Artifactory (versionado de binarios)
  • RunDeck (deploy automation)
  • Specflow, NUnit, Postman/Newman y Jess (test automation)
  • Sonar (quality check)
  • Docker, Docker Compose & Kubernetes (packaging & runtime)
  • Visual Studio Code, Visual Studio, WebStorm & Rider (IDEs para todos los gustos pues tenemos gustos muy distintos)

Herramientas de gestión / colaboración

  • Microsoft Teams (chat & calls)
  • Miro & Zeplin (diseño & mockups)
  • Jira (backlog)
  • Confluence (wiki)

Algunas de estas cuestiones de esta forma de trabajo no me terminan de convencer (por ejemplo yo preferiría hacer iteraciones de 1 semana) pero por el momento nos viene funcionando bien, el negocio está contento y ningún miembro del equipo ha planteado desconformidades relevantes.

Charla: Trunk-based Development, principios y recomendaciones desde la trinchera

Me invitaron a dar una charla en un conferencia y elegí este tema principalmente por dos cuestiones. Por un lado tengo la sensación que es una práctica muy sana pero al mismo tiempo bastante rechazada, por otro lado es la charla que a mi me hubiera gustado escuchar hace 10 años .

Título: Trunk-based Development: principios y recomendaciones desde la trinchera

Resumen: Trunk-Based Development es una práctica central para implementar CI/CD, pero curiosamente muchos la perciben como una práctica muy difícil o poco aplicable. En esta sesión repasaremos los fundamentos de esta práctica, los prerrequisitos para poder aplicarla efectivamente sin morir en el intento y una serie de recomendaciones para sacarle el mayor provecho. Hablaremos también de las prácticas relacionadas como Pair-Programming, Feature Toggling y Branch by Abstraction. Durante la sesión alternaremos espacios para consultas, debate y “el testimonio algunos creyentes”

Audiencia: es una charla para gente que ya tiene experiencia en desarrollo de software profesional independientemente del modelo de branching y la herramienta de versionado que utilicen. Definitivamente no es una charla para principiantes en desarrollo de software.
Formato: exposición dialogada
Duración: 60 minutos
Palabras clave: ci/cd, control-de-versiones, (no) branching,

En cuanto esté definido día y hora de la charla, lo anunciaré por este medio y en las redes.

Reflexiones de un cuatrimestre online

La cuarentena obligó a las instituciones educativas que operaban en una modalidad presencial a pasar a una modalidad no presencial. Esto tuvo impacto obviamente en las clases pero también en otras cuestiones operativas de las instituciones. Pero dado mi rol docente solo voy a referirme a cómo afecto este cambio a la materia que yo dicto.

El cambio nos impacto, pero a diferencia de otros casos, nosotros consideramos que el impacto fue positivo. En primer lugar dado que ya veníamos dictando la materia con un enfoque de aula invertida, ya teníamos mucho material de estudio generado (lecturas y videos). Por otro ya veníamos trabajando en un esquema de evaluación continua basada en tareas semanales y evitando así la necesidad de tomar examen (los exámenes fueron un todo una complicación para muchas docentes). Al mismo tiempo parte de nuestra materia tiene una fuerte carga de programación y es justamente ahí donde la situación nos generó un impacto positivo: todos los alumnos estaban en su casa, con su computadora, pudiendo así programar en clase. Sin embargo, este cuatrimestre no hicimos mucho uso de esta posibilidad, pero es algo que definitivamente aprovecharemos mucho más de aquí en más.

Un tema central que no logramos resolver es el uso de la cámara: nuestro deseo como docentes es que los alumnos enciendan la cámara durante la clase, sobre todo cuando hacemos actividades interactivas. Creemos que esto ayuda a “achicar la distancia” y a generar otro tipo de vínculo. Pero lamentablemente, no lo logramos. O sea, algunos alumnos (menos de un tercio), usaban la cámara, pero el resto no. En algunos casos esto se debe a conexiones poco estables en las que el uso de la cámara genera aún más inestabilidad. En otros casos, hay gente utilizando computadoras de escritorio que directamente no tiene cámara. Y obviamente también hay cuestiones de gusto, en fin. El tema es sensible, porque por un lado están las cuestiones técnicas pero por otro están las cuestiones de privacidad, de alguna forma cuando uno enciende la cámara está “dejando entrar a la audiencia a su casa”. Hemos sabido de algunas materias que imponen el uso de la cámara como una precondición para cursar la materia. A nosotros por el momento no nos parece un opción válida, pero sin duda es algo que revisaremos en caso de continuar con esta modalidad.

No tenemos ni idea de cuánto tiempo persistirá la pandemia y las condiciones de aislamiento/distanciamiento, pero hay una cuestión que tenemos muy clara: cuando vuelvan las clases presenciales, nosotros no volveremos completamente a la presencialidad. Creemos que para muchas de nuestras clases resulta más beneficioso que los alumnos puedan estar conectados trabajando con sus computadoras. Por esto es que, aún cuando vuelva la presencialidad, nosotros mantendremos un porcentaje de clases online.

Comparto a continuación algunas sugerencias que nos funcionaron bien:

  • Si la clase es con dinámica de clase magistral (docente hablando sin pasando diapositivas y poca intervención de los alumnos), considerar hacer un video y que los alumnos lo vean fuera del horario de clase.
  • Hacer un intervalo si la clase dura más de 90 minutos
  • Para las clases en las que se hagan ejercicios de programación, usar Visual Studio Code con Live Share.
  • Utilizar herramientas como Miro, Mentimeter y Kahoot para hacer más interactivas las clases
  • Considerar grabar las clases pero disponibilizarlas solo a pedido en caso que algún alumno tenga dificultades de conexión

Cierre de un cuatrimestre atípico en MeMo2@fiuba

Cerramos el cuatrimestre de MeMo2@fiuba en una modalidad 100% online y en términos resumidos creemos que estuvo muy bien.

Como herramientas de soporte utilizamos Jitsi para las clases online, Canvas LMS como aula virtual y GitLab como plataforma de desarrollo. En términos descriptivos este cuatrimestre tuvimos:

  • 22 inscriptos, 1 abandono, 21 aprobados
  • 46 tareas individuales que incluyeron 7 ejercicios de programación y 12 cuestionarios con sus correspondientes lecturas y videos
  • 2 trabajos grupales, uno de alcance variable y esfuerzo fijo y otro de alcance fijo y esfuerzo variable
  • 2 visitas de profesionales: Pablo Najt y Matias Gorostegui, gracias a ambos

Más allá de los números hay dos cuestiones interesantes que los alumnos destacaron. Por un lado la predisposición de los docentes para mejorar clase a clase lo cual quedó evidenciado en el hecho de que al final de cada clase les pedimos a los alumnos completar una breve encuesta para tener feedback específico de la clase. Por otro lado la buena adaptación de la materia a la modalidad online, de hecho algunos alumnos nos destacaron como la materia que mejor se adaptó. Siendo sinceros, creemos que no hicimos demasiados cambios para la modalidad online básicamente porque ya teníamos la materia planteada en un modalidad híbrida e invertida, basada fuertemente en el uso del aula virtual y mucho material en video.

De acuerdo a nuestra encuesta interna del curso tuvimos casi los mismos números que el cuatrimestre anterior:

  • Evaluación general del curso: 8.5 / 10
  • Claridad de los docentes: 4.3 / 5
  • Conocimiento de los docentes: 4.8 / 5
  • Dinámica de clases: 4.3 / 5
  • Materiales de estudio: 4.2 / 5
  • Dedicación promedio extra clase: 8.5 hs. semanales
  • Conformidad con la nota de aprobación: 4.4 / 5
  • Nota promedio de aprobación de la materia: 7.8

Por otro, en términos de feedback más general surgido de las encuestas y de la actividad de cierre, nos encontramos con algunos temas recurrentes (como usar python en lugar ruby y tener más cuidado al dar feedback de los ejercicios) y algunos otros temas nuevos (como agregar material sobre object-relation mapping y ver las cuestiones de configuration management antes del TP1).

Finalmente, puertas adentro del equipo docente creo que el trabajo fluyó que en cuatrimestre anteriores y en parte me parece que se debe a implementamos una reunión de de sincronización semanal (la weekly).