¡Vacaciones! Ahora toca ¿descansar?

Por fin, vacaciones. Pero ¿tiempo libre? ¡Más quisiera!

Cuando me volví de Madrid me las pintaba y me las deseaba, un trabajo de 8 a 15 con las tardes libres. Pero ya me he encargado yo de ocuparlas de alguna forma: primero la reforma del piso, dos meses liado con albañiles y demás (y aún queda pintar, poner la tarima, la semana que viene me cambian unas ventanas…); luego cursos, el de SEO y el CCNA; algún proyecto mío que también ocupa tiempo… Total, ¿tardes libres? <nelson>¡Ja, ja!</nelson>

Y estas vacaciones pintan igual. Aparte de alguna escapada de buceo y un viaje a Estambul de cinco días, los planes son:

  • seguir haciendo cosas en el piso.
  • repasar el CCNA, que acabamos las clases en febrero y por distintos motivos el examen se ha ido retrasando y aún no lo hemos hecho. Parece que será a finales de abril.
  • pegarle un empujón a un proyecto que tengo a medias.
  • y lo último: ¡sacarme el carnet de moto! (luego pongo un post sobre esto)

En fin… de todas formas me conozco, si no me busco algo que hacer seguro que hubiera estado en casa aburrido y quejándome de que no tenía nada que hacer. X-D El caso es quejarse.

Imágenes en "negativo" tras escalar con ImageMagick

Un apunte rápido de una cosa que solucioné en el trabajo hace unas semanas y desde entonces he visto en otro par de sitios.

Al escalar imágenes con el convert de ImageMagick (o con alguna de sus API) algunas fotos se quedan como en negativo: tonos negros, verdes oscuro, etc. aunque por supuesto la imagen original se ve bien. Después de darle vueltas el «problema» con estas imágenes es que el color iba codificado en CMYK en lugar de RGB, y por lo visto ImageMagick en el escalado por defecto usa RGB como salida y no realiza la conversión necesaria.

Solución rápida: antes de escalar las imágenes, pasarlas a RGB con:


convert -colorspace rgb original.jpg rgb.jpg

En medios exclusivamente digitales es difícil que esto pase, ya que para imágenes en pantalla se usa RGB. Sin embargo en medios que trabajen también con papel (prensa, editoriales, publicidad) es más fácil porque CMYK es el modelo que se usa para imprimir, y es posible que alguna foto en este formato pase inadvertidamente a la versión digital del medio.

tinydns por dominios

[spanish]Los que han trabajado conmigo saben que me gustan mucho los servidores de DJB. Creo que tanto qmail como djbdns son dos servidores estables como una roca en los que se puede confiar sin problemas. Pero hay mucha gente que simplemente no los entiende y los critica por cualquier motivo.

Por ejemplo, con el djbdns. He oído muchas veces la queja de que tener todos los dominios del tinydns en un único fichero de configuración (data) es un coñazo, cuando tienes muchos dominios (>50) la cosa se vuelve inmanejable. Eso prueba mi argumento de que esta gente no se entera de una de las ventajas de los programas de DJB: si, puedes editar los ficheros de configuración a mano, ¡pero lo bueno que tienen es que usan formatos simples fácilmente automatizables! ¿No quieres tener todos los dominios en un único fichero? Perfecto, sepáralos como te resulte más cómodo administrarlos y luego los vuelves a juntar antes de compilarlos.

El siguiente Makefile sirve precisamente para esto: en vez de trabajar con el «data» de toda la vida se crea un directorio «domains» donde se usa un fichero por dominio (el formato es el mismo), a partir de ese momento se usan estos ficheros y no el «data» para la administración. Al ejecutar make el makefile junta todos los ficheros de los dominios en el data y lo compila. Y si defines la IP o FQDN del servidor de backup en env/BACKUP, lo sincroniza. Fácil, ¿verdad?[/spanish]

[english]It’s no secret that I really like DJB‘s software. I think that qmail and djbdns are rock-solid pieces of software, something you can really rely on. But some people just don’t get them and bash them for whatever reasons.

Case in point, djbdns. Many a time I’ve heard the argument that having all tinydns’ domains in a single data file is a PITA. Well, that proves those people don’t get the point in DJB configuration files: you can edit them by hand, but their real power is that they’re easily scriptable! You don’t want having all the domains in a single file? Ok, split them and join them before compiling!

You can do this with the following makefile: split the domains, one per file on the «domains» directory, and work with those files, don’t ever touch the original «data» file again. And if you have a backup server put it’s IP address or FQDN on an env/BACKUP file. Then when you run «make» it will join all the files, compile them and sync the results with the backup server. Easy as pie, don’t you think?[/english]


all: data.cdb

data: domains/*[^bB][^aA][^kK~]
        cat $+ > data

data.cdb: data
        /usr/bin/tinydns-data
        [ -f ../env/BACKUP ] && rsync -azv * root@`cat ../env/BACKUP`:`pwd`

clean:
        -rm -f *~ domains/*~