En 2015 el lanzamiento de ListAbierta fue realizado tras un duro trabajo, fue todo un éxito y se emitieron miles de votos.

En 2019, se ha vuelto a retomar el proyecto para las elecciones de Mayo de 2019, ahora ya con la desaparición del firmado de Tractis, se ideo una solución alternativa basada criptográficamente en blockchain con Ethereum, en concreto usando Rinkeby, gracias a la colaboración de
Matyas Karacsonyi.

En esta nueva versión de ListAbierta, únicamente he intervenido en pequeñas modificaciones triviales, pero ha sido muy satisfactorio, puesto que como código realizado hace más de 4 años, ha servido para que otro desarrollador avanzara con el proyecto y volviera a ejecutarse en esta nueva edición con muy poco coste y esfuerzo para la plataforma.

No es que sea la primera vez que me haya pasado esta situación donde un proyecto antiguo se ha podido reutilizar de forma fácil, incluso he tenido proyectos que aun siguen vigentes de hace más de 7 años y tienen simples modificaciones triviales o siguen en ejecución con muy pocos cambios.

Es el valor añadido de realizar una buena planificación inicial de los requerimientos y aplicar los buenos criterios y principios que me fueron instruidos en ingeniería del software durante la carrera de Ingeniero Superior Informática y a posteriori a través de seguimiento autodidacta diario del mucho tecnológico.

Lo que realmente me gustaría destacar, es la decisión de realizar este proyecto como software libre, y las ventajas que ha tenido de cara a integraciones para otros municipios, incluso servir de base o inspiración para otros proyectos aún mas potentes (aunque sean de código cerrado).

Y ya sabes, si en tu municipio aún estáis pensando como poder llevar a cabo listas abiertas para las elecciones municipales de 2019, dale un vistazo a la plataforma, seguro que puede ser muy útil para ti

La entrada ListAbierta: votando en abierto las municipales de 2019 se publicó primero en Shakaran.

A veces se puede dar en servidores GNU/Linux la ocasión de tener una gran cantidad de archivos vacíos o directorios, bajo un mismo directorio y estos pueden tener diversos nombres o ser generados automáticamente (archivos de cache o similares). Con la intención de borrar archivos, liberar inodos y además limpiar tus directorios, pasare a explicar algunos de los siguientes comandos que puedes utilizar.

Para los ejemplos tomare como directorio de trabajo myblog/wp-content/uploads

Borrar archivos vacíos de un directorio

Forma 1: Por tamaño de archivo cero (opción size 0)

find myblog/wp-content/uploads -size 0 -print0 | xargs -0 rm --

Este comando buscará todo aquel archivo de tamaño cero e imprimirá por pantalla la ruta del mismo. Al ser tomado como argumento del programa xargs con rm, borrará cada uno de ellos

Forma 2: Opción empty de find

find myblog/wp-content/uploads -type d -empty -print -delete

Quitando el parámetro -delete, veriamos solo la impresión de los archivos que iríamos a borrar, o al revés sino queremos mostrar la lista de borrados, quitaríamos el parámetro -print

Otra alternativa diferente sería usando xargs:

find myblog/wp-content/uploads -type f -empty -exec rm -f {} \;

Eliminar directorios vacíos

Por otro lado, una vez eliminemos archivos, podemos tener la situación de tener muchos directorios vacíos, para ello podríamos borrarlos con:

find myblog/wp-content/uploads -type d -empty -print -delete

Quitando el parámetro -delete, veriamos solo la impresión de los archivos que iríamos a borrar, o al revés sino queremos mostrar la lista de borrados, quitaríamos el parámetro -print

De esta forma con unos simples comandos podemos organizar mejor nuestra estructura de directorios y archivos en el servidor. Existen varios ataques de denegación de servicio basados en creación de millones de archivos vacíos para saturar la cantidad de inodos de un servidor, luego estos comandos pueden ser muy útiles en esas situaciones de ataque.

La entrada Como borrar todos los archivos o directorios vacíos de un directorio se publicó primero en Shakaran.

Incorpora básicamente unos pocos cambios para fijar la versiones de bower que suelen dar problemas en la actualización de otras dependencias de terceros.

Gracias a contribuciones de otras PR y usuarios como:

[70acdef] Locks all versions down to specific numbers (to the patch level) removing any randomness in installations. Relates to issue #251
[21d793d] Lock fullcalendar bower version to 3.10.0. Issue #251
[f1d21cb] fix bootfox version
[0c4e46f] Merge pull request #249 from izvestia/1.3.x
[ccb1f46] Locks down ionicons to stable 2.0.1 as per issue #240 comments.
[a188716] Merge pull request #245 from xmontero/issue240

Sin embargo, mi desarrollo esta centrado en la rama master y en concreto en la rama experimental para soporte de Symfony 4.x

Este proyecto tiene más de 134.000 descargas, y casi 4.000 mensuales, es una gran responsabilidad realizar cambios y gestionarlos bien.

Asimismo, yo utilizo este proyecto en muchas de las páginas realizadas para mis clientes que me contratan como freelance. Por lo que de forma egoísta y quizás de forma interesada, es un buen combo avanzar el soporte a Symfony 4.x para poder realizar un despliegue en nuevas versiones a mis propios clientes.

Desarrollo futuro de AdminThemeBundle

Como resultado, existen varias complicaciones a comprobar detenidamente, ya que para la transición entre versiones mayores de symfony 3.x a 4.x no es una tarea sencilla. Ademas, si tenemos en cuenta al final la cantidad de usuarios que pueden pasarse a la nueva versión cuando sea liberada con soporte a Symfony 4.x, debo intentar que sea lo más estable posible y evitar una avalancha de issues en github, por lo que intento avanzar despacio, pero seguro. Seguiré informando de futuros progresos sobre AdminThemeBundle. Mientras tanto…

La entrada Avanzu/AdminThemeBundle 1.3.14 se publicó primero en Shakaran.