Meetup members counters tag

joelibaceta commented 5 years ago

Este PR propone varios cambios con el fin de permitir añadir mas funcionalidad en el proceso de build de la aplicación, con el fin de disponer de features como el del contador de miembros.

Resumen de cambios:

Se escribió un plugin que consulta a partir de una url el numero de miembros de un grupo de meetup.
Se propone migrar el proceso de deploy de la version automatica de GitHub hacia Travis CI.
Se configuro y uso el nuevo tag para mostrar el numero de miembros del grupo.
Se incluye el CSS resultante en el html en tiempo de generacion de contenido estático.
Se aplico un diseño tentativo abierto a discusión.

Ejemplo de uso del nuevo tag de liquid:

{% meetup_members_counter https://www.meetup.com/Flutter-Peru/ %}

Sobre el diseño queda abierto a discusion, en lo personal me parece algo cargado pero brinda una posibilidad de usar mas labels en un futuro, como "nuevo", "destacado", "sin eventos próximos", etc.

Prueba de concepto: http://joelibaceta.github.io/peruanosdev.github.io/

Captura de Pantalla 2019-07-03 a la(s) 06 16 42

¿Por qué se propone usar un plugins y no JS en el frontend?

Usando un plugin de Jekyll podemos obtener informacion de los meetups en el momento de generacion del contenido estático, haciendo que este se realice una única vez sin penalizar el performance del lado del usuario final.

Para esto consultamos al api de Meetup.com el cual no necesita autenticación.

¿Por qué se propone migrar a travis?

Esto debido a que la version genérica de despliegue automático de paginas Jekyll desde GitHub limita el uso de plugins y lo restringe a un whitelist, por lo que añadir cualquier contenido dinámico seria complicado.

Captura de Pantalla 2019-07-03 a la(s) 06 30 32

Captura de Pantalla 2019-07-03 a la(s) 06 32 43

Ventajas

Se puede inspeccionar el proceso de generacion de contenido estático y validar su correcta ejecución y consistencia en cada PR. (Ejemplo: https://travis-ci.org/joelibaceta/peruanosdev.github.io ).
Se pueden incluir scripts de testing que validen los PRs, por ejemplo validar la estructura del archivo communities.json.
Se pueden automatizar cron jobs para actualizar el contenido estático de forma automática ( Ejemplo: volver a consultar el numero de miembros de los meetups cada 24 horas ).

Desventajas

Se requiere configuración por única vez, pero manual desde el equipo de owners del repo:
- Crear un branch gh-pages
- Configurar el token de usuario para los deploys
- Agregar la variable de entorno GITHUB_TOKEN a Travis
- Setear gh-pages como rama principal para la pagina del proyecto en la configuración del repo
Dependencia externa del proyecto Travis.org

¿Por qué se incluyen los estilos en el html resultante?

Esto se realizo con el fin de facilitar las pruebas en local, ramas alternativas y/o despliegues de prueba ya que cada uno puede requerir de una configuración distinta de base_url y/o ruta de recursos, por lo que se agrego un script para simplificar todo el sitio en un único archivo .html resultante.

One more thing:

Si empezamos a usar plugins para añadir dinamismo, podríamos simplificar el archivo communities.json a una única lista de urls ya que los nombres y/o informacion adicional podría ser obtenida desde el API publico de Meetup, actualizándose automáticamente ante cambios.

07Gond commented 5 years ago

@joelibaceta me encanta este cambio! Entiendo que después del merge se debería hacer los cambios para que funciona correctamente con Travis. Y con los plugins se podrían simplificar muchas cosas, claro!

Agrego a @hpneo que tiene más experiencia aquí para obtener también su visto bueno.

hpneo commented 5 years ago

@07Gond @joelibaceta lo veo bien. Lo único que comentaría sería en base al despliegue, que si es posible hacerlo con cuentas "generales" y no atar ni Travis ni el token de GH a un usuario en específico. ¿Se podrá hacer esto?

joelibaceta commented 5 years ago

@hpneo al momento GitHub no permite la creación de tokens genéricos o de organización, debe ser un usuario de la organización.

Lo que podría sugerir es crear una cuenta de mail alias del dominio peruanos.dev con reenvío a todos los organizadores para las gestión de tokens.

Es el principal pain de esta solución, pero me parece que una vez superado se amplían las posibilidades de futuros features, por ahi sirve el esfuerzo.

joelibaceta commented 5 years ago

Sorry por el push -f. estaba ordenando los commits

hpneo commented 5 years ago

@07Gond @hacksy ¿Hay alguna cuenta de correo general que podamos usar?

07Gond commented 5 years ago

@hpneo tenemos un email de peruanos.dev con su pass. Coordinamos ese tema por interno?

hpneo commented 5 years ago

@07Gond para que no muera el hilo. Me comentas :)

07Gond commented 5 years ago

@hpneo Gracias por el reminder! Te paso los accesos ahora.

hpneo commented 5 years ago

@joelibaceta @07Gond tengo la cuenta de @peruanosdotdev con el token con el permiso repo_deployment, así como una cuenta de TravisCI asociada al correo comunitario.

Lo que me queda de duda es si podemos apuntar el deployment a master y no a gh-pages.

joelibaceta commented 5 years ago

@hpneo no me queda claro, dices generar los estáticos dentro de master?, en realidad me parece que gh-pages es el mas adecuado para alojar los estáticos finales para separar el Source del Build

07Gond commented 5 years ago

@hpneo Cómo va esto?

joelibaceta commented 5 years ago

@07Gond :c murió el hilo ?

darksy12 commented 5 years ago

Que necesitamos para que esto funcione?

07Gond commented 5 years ago

Preguntemos a @hpneo

carlosgub commented 5 years ago

Que falta para que lo aprueben :o

joelibaceta commented 5 years ago

:c ya se olvidaron del repo

carlosgub commented 5 years ago

:( queria hacer una mejora luego de la tuya para hacktoberfest :(

joelibaceta commented 5 years ago

Quien tiene los accesos? Para ir a buscarlo en su oficina el lunes ... ? XD

carlosgub commented 5 years ago

Creo que hansy tiene poder?

peruanosdev / peruanos.github.io