En Every Bug Has a Sad, Sad Song un comentario interesante sobre la relación entre bugs (fallos de programación) y fallos de seguridad.

Suele decirse que cuando un programa tiene bugs es posible que estos den lugar a vulnerabilidades, y a problemas de seguridad.

Pero el autor se queja del abuso que se hace de este ‘deslizamiento’ y que los que señalan esos fallos deberían ayudar a los desarrolladores a aprender sobre seguridad y no criticarlos sin más.

Ya hemos hablado algunas veces de aleatoriedad desde el punto de vista de la seguridad. En algunos casos, la aleatoriedad necesaria tiene que ver con producir resultados suficientemente diversos, pero en otros casos hay que pensar en más cosas. En “Not So Random Randomness” in Game Design and Programming discuten sobre el tema y cómo puede ser interesante influir en la ‘aleatoriedad’ para tener un juego más interesante.

Desarrollar apps para móviles es hacer programas. Desarrollar pensando en la seguridad para móviles es algo que cualquier desarrollador respetable debería pensar desde el primer momento. Los teléfonos, claro, tienen sus particularidades y no está de más recordarlas.

En Recomendaciones para el desarrollo de aplicaciones móviles seguras hay una lista de consejos que pueden servir de recordatorio sobre estos temas.

Uno de los problemas que encontré con este alojamiento es que no tiene etiquetas (tags). De hecho, no sólo no las tiene sino que no está previsto que se incluyan fácilmente con la configuración actual porque no hay plugins disponibles Using Jekyll Plugins with GitHub Pages (Wow, un plugin de emojis, y otro de menciones!).

Pongo estas ideas aquí por si alguien me da pistas sobre cómo hacerlo mejor y/o por si alguien más puede aprovecharlas en su sitios.

Puesto que no puedo añadir plugins para las etiquetas y tampoco quiero generar todo el sitio estáticamente (quiero imaginar que es mejor utilizar jekyll en las github pages) pensé utilizar alguno de los plugins que hay para generar sólo las etiquetas. De los que encontré estoy probando jekyll-tagging que ha sido bastante fácil de instalar y configurar, como se explica más abajo. Hay más formas, como jekyll-tags-plugin, y en Tags In Jekyll hay otra explicación. Incluso llegué a pensar en hacerme un programita para generarlo pero me parecía demasiado trabajo tener que ver cómo va el sistema de plantillas y todo eso…

Primero, hago una nueva copia del sitio en local (con git clone): me servirá para generar el sitio con sus etiquetas y todo.

En este sitio sigo las instrucciones de los desarrolladores del plugin README para instalarlo. En particular, instalar la gema, generar el fichero Gemfile, poner el código en el directorio _plugins y modificar el _config.yml.

• Genero el sitio con jekyll build --watch y en _site lo tengo en estático.
• Copio al sitio donde mantengo el repositorio local (donde edito, genero y publico los posts) el directorio _site/tags a la raíz (parte estática pages) , lo añado con git add y publico.
• Ahora tengo el sitio servido por jekyll con las etiquetas en modo estático.

Los problemas de esta forma de trabajar parecen evidentes: necesito dos copias en local del sitio, el flujo de trabajo complicado (aunque se puede automatizar). ¿Las ventajas? Tratar de mantener en la medida de lo posible el funcionamiento en github.io obteniendo la funcionalidad que nos ofrezcan. Veremos si es acertado o será mejor cambiar más adelante pero … ¡Tachán! Tenemos etiquetas.

Próximamente: Entiendo que podremos generar las categorías de una forma parecida (espero que no haga falta una tercera copia). Nunca he recibido muchos comentarios, pero espero poder incluirlos de alguna forma: la gente utiliza sitios como disqus pero fantaseo con algo más cercano a GitHub (¿tal vez a través de las issues? Veo que no soy el primero que lo piensa en GitHub hosted comments for GitHub hosted blogs. La limitación será entonces que para usarlo será necesario estar registrado en GitHub pero … ¿Saben por qué me apunté yo aquí? ¡Justo! Porque alguien me sugirió que lo hiciera (vimblog.vim: publicar en wordpress.com fácilmente).

Seguiremos informando.

Esta entrada casi es una promesa a mi futuro yo porque no he leído el código de Doom ni es algo que prevea que vaya a poder hacer próximamente.

En The Exceptional Beauty of Doom 3’s Source Code hablan justamente de eso, el código de este juego y muestran ejemplos de codificación e ideas que tal vez podrían resultarnos útiles.

Siempre me ha interesado leer guías de estilo de codificación y ese tipo de cosas de diversas empresas y proyectos porque es útil para saber lo que queremos (o no querríamos) hacer con nuestro propio estilo. Sí que leo con cierta frecuencia código de otros en GitHub y en los proyectos de programación de nuestros estudiantes, que de todo el mundo se aprende.

El código de los proyectos de software libre (y las normas/consejos) de los propios proyectos nos pueden servir para leer un buen montón de código que es algo que, me temo, no hacemos con la suficiente frecuencia.