Erase una vez un proyecto de alta disponibilidad sobre una infraestructura viva. No habia medios para montar entorno de pruebas, todo debia realizarse sin posibilidad de downtime en horario comercial. Para mas inri las intervenciones debian realizarse en horario comercial. Trabajo de dos fines de semana se alargo durante un par de meses. Cada dia tenia una ventana de operaciones de dos horas. Arrancar y parar el sistema de pruebas y verificar que todo quedaba en orden llevaba cerca de 90 minutos.

Lo dicho, media hora cada dia.

Para colmo hace poco tuve que desactivar el sistema por obsolescencia de uno de los dos nodos. El pobre estaba recalentando la sala de maquinas y no nos podiamos permitir un verano con las maquinas a cincuenta grados.

La instalacion de puppet en visualtis es pequeña (aunque funcional) y me puedo permitir el lujo de mantener la version de puppet bastante actualizada. En ultima instancia, aunque falle puppet nada critico se rompe; en este caso.

Lo mas notable tras la actualizacion fue el bajo rendimiento de Webrick. Los clientes no podian actualizar sus plugins: <em> err: Could not retrieve plugins: execution expired</em>.

Al final la actualizacion acabo en convertirse en razon para pasar a mongrel y nginx. Todo ventajas, con todo funcionando correctamente el rendimiento de los puppetd mejoro espectacularmente; con mongrel mis clientes se ejecutan mucho mas rapido.

Para estabilizar el cambio a mongrel solo tuve que lidiar con un problema. De repente dejaron de funcionar las limitaciones de acceso por IP; con 0.24.7 mi fileserver.conf solo tiene lineas del tipo allow *. Parece que este problema esta relaccionado con que nginx y mongrel no se estaban comunicando correctamente,  el error estara subsanado en nuevas versiones. ]]> http://www.adriansilva.org/es/2009/07/05/a-puppet-0244-0247-migration/feed/ 0 http://www.adriansilva.org/es/2009/06/21/css-lint-in-gitc/ http://www.adriansilva.org/es/2009/06/21/css-lint-in-gitc/#comments Sun, 21 Jun 2009 11:10:05 +0000 skiold http://www.adriansilva.org/?p=340

Un pequeño git hook (pre-commit) que comprueba la sintaxis de las hojas de estilo css antes de hacer un commit al repositorio Git.

De la validacion css se encarga la herramienta cssparse de css-utils (python).

La manera de obtener una lista de ficheros css que se van a incluir en el proximo commit es util para otros hooks pre-commit.

for css in $(git diff-index --name-only --cached HEAD -- | grep '\.css$'); do
if cssparse $css 2>&1 | grep '^ERROR' ; then
exit 1
else
echo "css files validated"
exit 0
fi
done
]]> http://www.adriansilva.org/es/2009/06/21/css-lint-in-gitc/feed/ 0 http://www.adriansilva.org/es/2009/04/11/sitting-in-the-crossroads-of-life-and-business/ http://www.adriansilva.org/es/2009/04/11/sitting-in-the-crossroads-of-life-and-business/#comments Sat, 11 Apr 2009 18:41:46 +0000 skiold http://www.adriansilva.org/?p=287 La Nasa Tamboril, entre los caminos de los negocios, el Software Libre, y el cambio personal; es un lugar apenas definido por las perspectivas de los que caminan por sendas similares. En este post hablo de esos otros cuyos pasos me sirven de inspiración y guia.

• Dave Pollar por duplicado. Primero su  Desaprender a Jugar. Me encanta el concepto de let-self-change que maneja. Nos recuerda que el cambio siempre es una posibilidad.
• Tambien anda interesado Pollard en construir negocios adaptativos. Negocios y relevancia vital.
• El propio camino es inspirador a vces: social media, online conversations, blogs, … Pero hay que tener presentes algunas reglas.
• Los muchos ejemplos de que es posible construir negocios fructiferos, con sentido y comunidad; crossfit-hq y agilar me vienen a la mente.
• Palabras pequeñas y cargadas de significado: fukuoka, openspaces, kanban.

No soy el unico reflexionando sobre la trayectoria y perspectivas de Visualtis. En este video uno de nuestros rock-star-java da su vision sobre el devenir de las cosas en la empresa. Me quedo con dos de las virtudes defendidas: Simplicidad, y Comunicación.

Pedro Ayala sobre el desarrollo en Visualtis

La charla tuvo lugar dentro de los festejos por el 25 aniversario de la Facultad de Informatica de Murcia. A mi entender la conferencia es larga de más; he de buscar la presentación de acompañamiento como resumen.

Quiero recopilar un buen conjunto de consejos y buenas practicas que puedan ayudar a los que pretendan ofrecer temas con soporte para i18n:

• Escribe el tema en ingles, ampliaras las audiencia del tema y te podras beneficiar de el trabajo de traduccion de otros temas.
• Lee la documentación de WordPress sobre i18n. Imprime sus buenas practicas y asegurate de tenerlas en lugar visible antes de empezar con la i18n.
• Usa printf y sprintf generosamente. Solo estoy repitiendo lo que piden en la documentacion de WordPress (las que acabas de leer . A mi me parecio especialmente importante el uso de descripciones y comentarios (con la función _c()).
• Usa textos comunes y habituales. Para darle difusion al tema y facilitar el trabajo de los traductores, mejor no ser muy original. Por ejemplo “Submit It” es más comun que “Say It Pal!” para el envio de comentarios. Nada impide que seas más original y unico en las copias de tus temas para uso privado o de clientes, pero es en el beneficio de la mayor difusion del tema que la version publica sea lo mas sencilla posible.
• No incluyas solo puntuacion. Ni evites incluir fragmentos pequeños; los parametros alt y title, el ‘value’ de los botones ‘submit’, las funciones next|prev_post_link y otras plantillas wp, todas ellas aceptan i18n.Siguen dos ejemplos que muestran este punto en acción ¿alguna razon para no traducir “Comments”?; ¿necesita ‘|’ ser traducido a algun idioma ?
  

  <?php _e($numComments, ‘XXXXXXX’); ?> Comment(s)

  __(‘ | ‘)

Por ultimo, lo mejor es empezar con las mejores plantillas posibles, tomando como base para nuevos temas uno que tenga buen soporte para i18n; sandbox es uno: moderno, sencillo y con i18n completa.

En este caso teniamos codigo php en Latin-1 siendo servido por un Apache amante del Utf-8. En un alojamiento compartido esto se deberia corregir desde el .htaccess  de la aplicacion php con:

AddCharset ISO-8859-1 .php
AddDefaultCharset ISO-8859-1

En este caso habia que tocar la configuracion central de apache para permitir que .htaccess modifique estos parametros (via ‘AllowOveride FileInfo’ en la configuracion del directorio base /var/www/htm/). O sea que con las mismas se podia haber cambiado el codificado en la configuracion principal.

Lo mismo se puede conseguir desde php:

PHP. Use the header() function before generating any content, e.g.:
header(‘Content-type: text/html; charset=utf-8′);

Lo comentan:

• En w3c dan consejos basicos sobre el uso de las cabeceras http y los codificados.
• En particular sobre el uso de los .htacces de apache
• De interes el listado de nombres de codificados aceptables en las directivas de apache.