Implementar lógica para anunciar eventos en Telegram

[astrojuanlu]

Interesante el caso de Python Coruña: tienen sus PyBirras programadas de aquí hasta el infinito (imagino que con un evento recurrente).

Esto desafía la lógica que habíamos pensado de anunciar en Telegram todos los eventos futuros, no tiene sentido. Se me ocurren varias ideas:

• Anunciar cada día los eventos nuevos, pero solo si faltan menos de 4 semanas (¿pero luego cómo los anunciamos cuando se acerca la fecha?)
• Anunciar cada semana (eventos de la semana) ∪ (siguiente evento programado de cada comunidad)
• Anunciar cuando hay eventos nuevos pero solo el más próximo de cada comunidad, o los que entren dentro de una cierta franja de tiempo (2 a 4 semanas), con algo de lógica para saber los que se han anunciado ya
• ❓

Hay que pensarlo y desarrollarlo un poco más.

Originally posted by @astrojuanlu in https://github.com/PyCampES/telegram-python-es/issues/14#issuecomment-1531329988

[astrojuanlu]

¿Qué opináis @ifranco14 @sergio-reque @EllaQuimica ?

[alexgmin]

Una posible alternativa sería averiguar si es un evento recurrente y gestionarlo de forma especial.

Ahora mismo no recuerdo ya exactamente como era el flujo, pero entiendo que la primera opción sería la mejor si no se puede gestionar casos recurrentes de forma especial. En el caso de eventos recurrentes, tiene cada recurrencia un identificador diferente?

Entiendo que quizá un flujo mejor sería en lugar de anunciarlos al pillarlo de la API, tener como 2 procesos, uno que los pilla y otro que itera sobre lo que haya en la rama y publica lo que toquen. ¿O era ya este el flujo que había ahora?

[astrojuanlu]

Lo malo de la primera idea es que nos obliga a persistir qué eventos se han anunciado ya.

Y lo de los eventos recurrentes, no impide que alguien agende un evento para dentro de un año y medio, lo anunciemos, y se olvide.

Tal vez lo más simple sea anunciar los eventos de la semana cada lunes, hasta que alguien sugiera algo mejor.

[astrojuanlu]

Tal vez lo más simple sea anunciar los eventos de la semana cada lunes, hasta que alguien sugiera algo mejor.

@pablorodpiper está de acuerdo

[soulcodex]

¿Cual es el problema con persistir los eventos y las comunidades? Si es por infraestructura existen varias capas freemium por alli que nos pueden solventar este tema y asi podemos gestionar logicas mas completas al poder tener estado persistente, tampoco hace falta de momento una base de datos SQL una implementación en Redis creo que sirve perfectamente como punto de partida.

Luego creo que deberiamos modelar las comunidades (agregados / entidad) asi como los eventos y que cada una tenga su configuración en cuanto a publicación de eventos y periodicidad ó podemos tratar a todas por igual con un unico flujo y con una unica periodicidad.

Creo que tambien deberia existir un flujo no ahora pero si a futuro que considere eventos de comunidades que ocurren o se publican fuera de meetup por el motivo que sea.

[astrojuanlu]

tampoco hace falta de momento una base de datos SQL una implementación en Redis creo que sirve perfectamente como punto de partida.

Las dos tienen el problema de que requieren infraestructura. Incluso aunque usemos el plan gratuito de cualquier cloud, está sujeto a una cuenta personal de alguien, normalmente una tarjeta de crédito etc. Además nos convierte en custodios de unos datos que a lo mejor no queremos mantener. Todo esto va en contra del objetivo de mantener las cosas simples.

Se me ha acabado el fuelle para trabajar en esto.