El programa deploy-new-certs
ha alcanzado ya cierta longitud y he calculado que sobre el 80% de él son comprobaciones de parámetros, ausencias, presencias y contenidos. Y está bien, porque lo que pretendo es tener el mayor control posible sobre lo que ha ocurrido y no dejar el grueso de los sucesos sobre largos muros de texto producidos por terceros.
Categoría: 100DaysOfCode
100DaysOfCode: día 12 – volviendo a la vida
Pues sí, porque aunque llevo más de diez días de trabajo en programación se me ha olvidado por completo publicarlo aquí. Y así ni retos ni leches.
100DaysOfCode: día 12 – completado el analizador léxico
Todos estos días he estado programando entre una y tres horas como poco, pero no he escrito aquí las entradas que lo «demuestran». No importa. Tampoco es que vaya a ser evaluado más tarde, y si digo ésto es para que mi yo del futuro no me venga con reproches chorras, que ya nos conocemos.
100DaysOfCode: día 11 – refactorizando
Ayer no pude dar continuidad al reto. Una lástima pero estuve bastante ocupado con la administración de sistemas y terminé cansado, sin ganas de más.
Hoy he estado probando algunas ideas con la máquina de estados léxica de ttt, jugando con varias ideas con las que creo que ha quedado bastante escalable. También he escrito otra escena más de la obra que tengo que representar este año y que estoy empleando como fuente de datos para el programa.
Mañana espero poder alimentar un programa y comprobar si lo que he diseñado es factible o no.
Por cierto que veo que necesito pero ya poner en línea el acceso web al repositorio git y a los paquetes Debian. No es indispensable pero me ayudará en un plan que tengo a medio plazo para mi vida laboral. Iba a decir carrera pero me ha entrado la risa. ¿Carrera hacia dónde? ¿Al abismo? Para eso no hacen falta tantas alforjas. :-)
100DaysOfCode: día 10 – máquinas de estado
Hoy es domingo y he hecho lo que he podido programando. Tenía mucho que hacer en casa y no he tenido oportunidad de dedicarme mucho.
He seguido con la parte del código del analizador léxico de los códigos teatrales tratados y me ha salido una máquina de estado muy cuqui porque algunos elementos se extienden más allá de una línea y he preferido ésto a tener que pegarme con expresiones regulares multilínea.
Las máquinas de estados son mi construcción favorita de siempre en programación. Es algo muy raro pero el cosquilleo que siento con ellas es único. Al principio escribo una barbaridad de código y luego, poco a poco, lo voy optimizando hasta dejarlo en su mínima expresión. Es análogo al huevo y la gallina y me lo paso muy bien. Que sí, que ya hay analizadores léxicos de sobra; he usado lexx para hacerme, años atrás, mi propio lenguaje de programación interpretado y tuvo su encanto para aprender a usar la herramienta y centrarme en lo que hacía el lenguaje en sí: campos calculados en formularios de entrada de datos. Excesivo pero gozoso.
En fin, que tengo aún otra máquina de estados más en la parte sintáctica y estoy deseando ponerme con ello.
100DaysOfCode: día 9 – completando partes
El sábado ha sido un día raro para conseguir tiempo para este reto. Ignoro si el que lo propuso tuvo en cuenta los días laborables pero presumo que no. Tampoco es que me parezca mal. Sólo es más complicado.
Me cundió lo suficiente como para que uno de los componentes de ttt estuviese completo: tests variados, código (por supuesto) y documentación. Que es como quiero hacer las cosas. Sí, es más lento. Pero es más mejor. :-)
100DaysOfCode: día 8 – poco que rascar
Ha sido un día extraño y sólo le he sacado algo de partido a la mañana, cuando he estado retocando cosas de administración. Hoy sólo dejo constancia aquí de que estado creando la máquina de estados para el analizador síntactico de ttt y las reglas para su analizador léxico. En papel han quedado bien pero el código apenas ha avanzado.
Mañana más.
100DaysOfCode: día 7 – nueva idea y continuación de otros
Hoy he tenido un día regular en este reto. Me he pasado parte de la mañana enfrascado en muchos temas y le he dado demasiadas vueltas a la parte de administración. Espero recuperar tiempo mañana.
ttt
Aquí el trabajo ha sido poco. Un test de un módulo Perl escrito y funcional que falla en todos los aspectos que tiene que fallar porque el código que testea no existe en su mayoría. Respecto al módulo he avanzado bastante, especialmente cuando me he dado cuenta de que son tres métodos públicos, sin atributos de clase, y que no merecía la pena emplear bibliotecas de código para automatizar la clase. Vamos, ni ésta ni ninguna de las otras tres en las que está compuesto.
mydevtools
Aquí he estado pensando bastante y me he lanzado a crear una nueva herramienta que las unifique a todas. Así, sin miedo, pero con esperanza brillando en mis ojitos de que esta vez voy a conseguirlo.
No, en serio. El único problema, si puedo llamarlo así, que encuentro con este paquete es que son demasiados los scripts que lo componen y aunque lo tengo bastante documentado me pierdo en el nombre, los parámetros y el orden de uso que tengo que darle en cada momento.
He ideado un programa llamado mybuild que va a reunir toda la funcionalidad que tienen los otros para no tener tanto espacio de nombres ocupado. Si total, las tareas son las mismas de siempre.
Ahora mismo en un archivo make tengo la siguiente disposición con las tareas comunes en un directorio de desarrollo.
all:
build: build-manpages
build-manpages: extract_pod
build_repo_manpages -b -s docs
extract_pod:
extract_pod_manpages -t docs
install: install-docs install-lib
install-docs:
build_repo_manpages -i -s docs -t $(DESTDIR)/usr/share/man
install-lib:
install_repo_files libmyparams-perl $(DESTDIR)
clean: clean-docs clean-tmp
clean-tmp:
find . \( -name "*.bak" -o -name "*.orig" -o -name "*.deb" \) -delete -print
clean-docs:
build_repo_manpages -c -s docs
Más o menos así. Depende de la antigüedad del proyecto utilizaré unos u otros para hacer lo mismo en todas las fases: inicialización, construcción, testeo, instalación y empaquetado. Y siempre tengo que mirar ejemplos de otros proyectos recientes o tirar de página de manual para saber cómo funciona. No está bien.
La herramienta que he comenzado dará un aspecto más sencillo a los archivos make:
all:
build: build-docs build-binary
build-docs:
mybuild build docs
build-binary:
mybuild build bin
clean: clean-repo clean-docs
mybuild clean bin
clean-repo:
mybuild clean repo
clean-docs:
mybuild clean docs
Creo que la idea se pilla. Se llama al programa con la operación y luego el tópico y se encarga, como ya hacen lo otros programas, de mirar valores por defecto, comprobar si se puede o no hacer algo, hacerlo o no, y dar los errores correspondientes; todo con la máxima de que va a ser empleado en otros programas y que debe morirse si hay algo de verdad mal y no decir ni pío si el resto va bien o no ha tenido que hacer nada.
He empezado escribiendo la documentación y luego pasaré a los test. No tengo prisa pero estaría bien que algunos de los tópicos estuviesen cubiertos como la documentación, tema más que trillado por el paquete, lo antes posible.
Ah, lo mismo el nombre es demasiado largo y lo acorto con uno de mis famosos y valorados acrónimos. :-)
100DaysOfCode: día 6 – empaquetando otros programas
Antes de nada voy a hacer un cambio en estas entradas porque no me entero de nada de lo que he escrito. Y mira, así no se puede vivir. Voy a poner un titular pequeño en cada tema y luego lo etiqueto para el futuro.
100DaysOfCode: día 5 – arreglos y nuevos proyectos
El programa gra ya es utilizable. Ángel me indicó el tipo MIME correcto y lo he arreglado, empaquetado e instalado. Se puede ver en http://taquiones.net/cgi-bin/gra. Vale que no es muy impresionante pero es un comienzo importante para mí.
El proyecto ttt (textos teatrales tratados) ya está definido en sus componentes básicos. Podría utilizar bibliotecas ya existentes pero son más las ganas de programar yo que de tener algo útil pronto, así que he llegado a completar una de las escenas de la obra en el formato de texto que he pergeñado.
En el siguiente ejemplo se ve que he tomado elementos de markdown intentando que sea lo más sencillo de transcribir.
# Autos ### neones M=María J=José (Buen coche. Buena familia. Jośe, María y el niño detrás, dormidito. Una de la madrugada) M: Míralo, estaba destrozado. J: Es un ángel. M: Tendríamos que salir más. J: Claro. M: ¡ Qué bien lo pasé ! J: Ya te vi. M: ¿Tú no? J: Te bebiste media botella. M: Tú bebiste más ... J: Sí, pero a mí no me sube igual.
Se indica el título de la obra con un sostenido, el de un acto con dos (opcional), el de una escena con tres (también opcional por si es microteatro o similar) y tiene un par de asignaciones que conforman mínimamente el dramatis personae. Algo más tendré que añadir, como una descripción del personaje, pero la intención es aprovechar y crear atajos para los diálogos que se ven en el texto.
Las acotaciones se indican entre paréntesis y pueden aparecer como elementos sueltos o dentro de los diálogos (o los monólogos) y éstos se marcan con el nombre del personaje, dos puntos y una o más líneas de texto hasta una línea en blanco u otra entrada de personaje.
El programa carga un texto de este tipo, lo organiza en elementos y luego lo convierte a otro formato para imprimirlo, llevarlo en el móvil o colgarlo en la red. La conversión llevará una característica especial para mí: crear el texto sin los diálogos de un personaje para facilitar el aprendizaje. Sé que existe software para estos casos, especialmente aplicaciones móviles pero, de nuevo, vuelvo con la fijación de arrancar a programar.
Se me ocurrió emplear también el formato epub y resulta que Ángel es un experto en sufrir con él. Y mira, me viene al pelo porque me ha descubierto un programa (de un tipo raro llamado Grunk o algo así) para convertir entre formatos. Que voy a emplear claro. No pretendo rehacer todo el trabajo yo solito, que tengo más ideas cociéndose.