Por fecha 2009-02 - Userlinux.net

Desde que he comprado la ER-6n (10.2008) apenas había tenido tiempo a disfrutarla por culpa -mayormente- del tiempo. Este fin de semana todo ha acompañado y me he marcado mis primeros kilómetros de lobo solitario. Menudo vicio, a ver si empieza a mejorar el tiempo y alargo las rutas, que hay mucho por conocer -deseando acabar el rodaje-.

La verdad, nunca me había hecho falta tocar esta parte del sistema, pero aquí dejo el tip por si pudiera ayudar a alguien -me incluyo, mi memoria no está para alardes-. El tema es que tenía que hacer un rsync en el hook post-commit de SVN de forma automática y sin prompt de contraseñas (va a ser cierto eso de que hablamos raro).

Al hacer un commit en SVN aprovecho para exportar el mismo repositorio en un directorio local, pero además de eso quiero pasarlo a otra máquina vía rsync con lo que creo una relación de confianza entre los roots de ambas máquinas y pruebo.

Era algo que hasta ahora se hacía bastante molesto pero no me había parado a buscarle solución. Para hacer un commit al SVN desde Eclipse tenía que dejar de usar una mano en el teclado para coger el ratón, posicionarme, botón derecho - Team - Commit.

Ahora todo ha cambiado, ya semos felices porque en Window - Preferences - General - Keys tenemos algo tal que así: Así que con asignar Ctrl+Shift+s al Commit, Ctrl+Shift+U para el Update y poco más todo listo, 5 segundos ahorrados entre commit y commit. Ahora a ver si podemos saltarnos el diálogo de comentar los cambios, ya que nadie lo usa.

¿Alguien sigue notificando algún tipo de error con los feeds?. Pregunto porque creo haber resuelto tanto el tema de la codificación como los enlaces a cada una de las entradas, que no funcionaban de forma correcta. ¿Hay algo más que deba saber?. Grasias de antebrazo por el feedback.

Después de leer un poco y siguiendo -muy de refilón- la última entrada me gustaría recomendar algunas lecturas que pueden ayudar tanto a la organización de un equipo de desarrollo como a convertir tu aplicación web en un servicio masivo:

• Método Scrum.
• Tillate.com implementa scrum.
• Serie "Scaling Up" de Brandom Savage.

Espero que sea de ayuda y, como dije antes, toda experiencia previa, comentario, duda o mejora es bienvenida.

Hubo un tiempo en el que empecé con un patrón que parecía el adecuado. El mini-fw que estaba empezando era como un billar: directorios estáticos por un lado, app por otro y el core como tercera banda -la más importante sin duda- donde trato de coleccionar -y reutilizar- funciones.

En la segunda entrega creamos el despachador de forma que todas las url's tenían que pasar por un index.php que controlaba todo el tráfico.

Y ahí se quedó el invento, al menos en lo que a publicaciones se refiere. En cuanto al código he avanzado bastante y pensaba que había seguido el camino correcto hasta que el maldito Apache Benchmark Tool se cruzó en todo esto.

Screen es una de esas herramientas de uso diario que -por lo menos a mi- me resulta imprescindible, extensible a cualquier sysadmin, linuxero y/o amante del la consola (terminal).

Y cada vez encuentro tips que la hacen más imprescindible si cabe. Lo penúltimo -nunca pierdo la esperanza- ha sido el fichero .screenrc, donde además de definir las preferencias de la aplicación, puedes organizar las ventanas y lo que se va a abrir en ellas:

Desde que Feedburner se ha cambiado a Google, este sitio empezó a tener problemas de encoding con los feeds. He intentado cambiar la configuración del mismo pero no ha sido posible.

El problema es que mis feeds se escriben en ISO-8859-1 y así se lo hago saber a todo el mundo en las cabeceras:

<?xml version="1.0" encoding="iso-8859-1"?>

Pero el bueno de Feedburner parece que solo entiende de utf-8 y reescribe la cabecera de una forma muy peculiar:

<?xml version="1.0" encoding="UTF-8"?>

Así que no me ha quedado más remedio que hacerle caso y tirar de utf8_encode() en la generación del feed.

Gracias a todos los que habeis informado del problema y mis disculpas por haber tardado en solucionarlo.

No me apetece demasiado comentar los números de éste mes, de hecho estoy en temporada apática, así que ahí queda el resumen. A ver si con los cambios que se avecinan varía un poco rumbo del viento y volvemos a la normalidad.

Para almacenar una cadena en MySQL podemos utilizar varios tipos de campo, como nunca recuerdo la diferencia entre los normales, los medium y los long, ahí queda la nota mental:

• Char: 0-255 caracteres.
• Varchar: 0-255 caracteres.
• Tinytext: 0-255 caracteres.
• Text: 65.535 caracteres.
• Mediumtext: 16.777.215 caracteres.
• Longtext: 4.294.967.295 caracteres.

Si, nos ha extrañado, pero los campos de tipo mediumtext albergan más cantidad de datos que los text. Fin de la nota mental.

Update: A raíz del comentario de Wu me gustaría aclarar que la diferencia entre CHAR y VARCHAR es la forma en la que se almacenan los datos en MySQL. Por ejemplo entre un CHAR(4) y un VARCHAR(4) guardando el dato "ab" tendríamos que:

CHAR(4)	"ab  "
VARCHAR(4)	"ab"

Como vemos en los campos de tipo CHAR siempre se reserva el espacio que hemos designado para su uso, mientras que en los VARCHAR la asignación es dinámica siempre y cuando no se sobrepase el límite impuesto.

El TINYTEXT, junto a sus hermanos TEXT, MEDIUMTEXT y LONGTEXT son de tipo BLOB (binary large object) y su almacenamiento es distinto a CHAR ó VARCHAR.