Photo by Mabel Amber
El paquete flag sólo soporta unos pocos tipos de variables: string, int, bool y duration.
Sin emabargo, podemos definir nuestros propios tipos de forma sencilla; en esta entrada creamos flags de tipo email y que admitan múltiples valores separados por comas (slice).
Ahora que tenemos un concepto que funciona, el siguiente paso es generalizarlo. En esta entrada el foco es “estandarizar” los conceptos de comando usando el paquete flag.
Una de las limitaciones del paquete flag es que no proporciona soporte para comandos o subcomandos. Sin embargo, podemos simularlos de manera sencilla.
El paquete flag es la opción desarrollada y mantenida por el equipo de Go para la gestión de flags.
Como viene incluido en la biblioteca standard de Go, no requiere ninguna dependencia externa.
En esta entrada, vemos a explorar algunos ejemplos usando el paquete flag.
Uno de los motivos por los que el blog ha estado en un estado de semi-abandono durante este tiempo es porque estoy dedicando mucho tiempo a aprender Go.
Voy desarrollando pequeños proyectos que resuelven problemas concretos de mi día a día o relacionados con mi trabajo; así, como tengo un buen conocimiento del problema a resolver, también sé cómo espero que sea “la solución” a desarrollar. De esta forma, aprendo lo que necesito en vez de intentar aprender cosas “porque sí” (como temas de concurrencia).
A medida que voy aprendiendo, revisito los proyectos y así, poco a poco, los voy mejorando.
Tenemos varios procesos que se basan en parsear datos proporcionados por los usuarios en un fichero CSV, validarlos y “hacer algo con ellos”.
Los scripts que se encargan de estos procesos se pueden dividir en dos categorías: sencillos pero “delicados” y robustos pero complicados.
Uno de nuestros scripts de validación ha crecido y crecido para incorporar todo tipo de transformaciones y validaciones… Pero como suele pasar en estos casos, la evolución ha sido orgánica, es decir, sin planificación… Y aunque es perfecto para la tarea que realiza, es difícil aprovechar todo lo que hemos desarrollado para poder reutilizarlo en cualquiera de los otros procesos y así, mejorarlos.
El problema no son las funciones que implementan una u otra función de validación; el problema es que hay que hay una relación invisible entre los datos en el CSV y las funciones que deben aplicarse a cada campo… Al no estar documentada esa relación, mantener los scripts resulta complicado si no se está familiarizado con la tarea para la que fueron diseñados.
En vez de seguir ampliando el problema, he desarrollado una aplicación que espero que pueda aplicarse de forma “universal” en todos los procesos y acabar con el problema de una vez por todas.
Y la solución que se me ocurrió fue la de definir un schema para el CSV.
