Pau Sanchez

Resulta que en la versión 8.04 de Ubuntu han metido la beta de Firefox 3. Y yo me pregunto, ¿como pueden sacar un producto “estable” con un programa que está aún en beta?

Me pregunto esto, porque cual fué mi sorpresa cuando más de la mitad de las extensiones que utilizaba para firefox dejaron de funcionar. La que más me dolió fue la extensión de “Firebug”, que es un plugin magnífico para los que nos dedicamos al desarrollo web (aunque en mi caso sea en los ratos libres).

Cosas que probé y NO funcionaron:

• Bajarme la versión 1.1beta de Firebug en Firefox3: el problema es que no acababa de funcionar bien, da problemas, no salia la consola, etc…
• Bajarme la versión 1.2 alfa de Firebug para Firefox3: funcionaba incluso mejor que la versión 1.1beta, sin embargo en algunas páginas medianamente complejas se cuelga
• Instalar firefox-2 en Ubuntu, y tener así instaladas las dos versiones: el problema aquí es que daba error al instalar Firebug 1.0 para Firefox2, con lo que esta solución tampoco vale

La solución para hacer funcionar Firebug en Ubuntu 8.04, consiste básicamente en eliminar Firefox3, instalar Firefox-2 y eliminar ~/.mozilla. La única cosa a tener en cuenta es que es mejor guardarse todo lo de ~/.mozilla para restablecer luego los favoritos, etc…

En el shell:

$ sudo apt-get remove firefox-3.0
$ sudo apt-get install firefox-2
$ mv ~/.mozilla temporal/mozilla-old
$ rm -rf ~/.mozilla


Borrar el directorio de .mozilla sólo hace falta si se ha ejecutado Firefox-3 alguna vez. Finalmente, si es así y se ha borrado el directorio de ~/.mozilla habrá que perder otros 5-10 minutos en reinstalar extensiones y dejar FF2 tal y como estaba.

[Bonus Track]

Ya que viene por defecto FF3 beta, quiza sea excesivo eliminarlo. A todos nos gusta trastear y ver que las cosas van como deben en la siguiente versión de firefox.

Así que aquí va un hack para tener instalados y poder ejecutar Firefox 2 y Firefox 3 al mismo tiempo en Ubuntu 8.04:

$ sudo apt-get install firefox-3.0
$ sudo rm /usr/bin/firefox


La idea es instalar la siguiente versión de firefox pero nunca utilizarlo con el mismo usuario. Así que, de normal se puede usar firefox-2, asegurándose de cambiar todos los enlaces del escritorio, etc… y tener otro usuario (adduser menganito) con el que utilizar firefox3, así ya no hay conflictos y se pueden utilizar ambas versiones de firefox en el mismo sistema.

Ah! y aquí el truco para poder ejecutar aplicaciones gráficas con otro usuario (en este caso menganito):

$ sux menganito
$ firefox-3.0


Llevo un par de días leyendo el libro Building Scalable Web Sites de Cal Henderson (el creador de Flikr). Estoy gratamente sorprendido.

A parte del primer capítulo, que es una mera introducción, los demás capítulos que he leido por el momento son bastante interesantes.

Por ejemplo, el segundo capítulo trata el tema de la arquitectura de un sitio web en terminos generales (para los detalles ya está el resto del libro). Analiza tanto la arquitectura a nivel de software como a nivel de hardware. Está muy bien.

En el tercer capítulo habla del proceso de desarrollo y las herramientas que hacen falta. Aunque no me ha contado nada nuevo, debo decir que sintetiza muy bien los contenidos de las dos asignaturas de Ingenieria del Software que tuve. Si quieres desarrollar software y no tienes muy claro qué herramientas utilizar y por qué motivos usarlas, leete este capítulo, los conceptos son fundamentales.

El cuarto capítulo es también genial. Trata el problema de la internacionalización y la localización, analizando que son, por qué existen, de qué formas se pueden soportar, cual es la mejor forma según las necesidades y cuales son los problemas que existen con los caracteres unicode. Este capítulo es fundamental para todos aquellos que piensen en desarrollar una aplicación (sea web o no) y quieran incluir soporte multiidioma en su web.

El quinto capítulo lo he ojeado por encima, pero creo que es básico. Trata sobre seguridad web. El problema de la inyección de código malicioso en formularios, etc… Parece muy completo y creo que es muy recomendable, sobretodo si tu aplicación web va a ser usada por un gran número de usuarios.

He saltado al capítulo ocho, que trata sobre los cuellos de botella, y de momento cumple bien las expectativas.

Mi valoración por el momento es que es un libro de lectura obligada para todo informático que se precie. Lo recomiendo encarecidamente, y, aunque hay capítulos que únicamente interesen a los desarrolladores web, hay otros que son fundamentales y explican conceptos generales que todo ingeniero informático debe conocer y aplicar.

Si teneis ocasión, ya sabeis.

Habrá quien no le importe lo que voy a decir, a otros les parecerá curioso, a unos pocos les sorprenderá y sólo unos cuantos probablemente lleguen a escandalizarse.Recientemente, tres años después de terminar una Ingeniería Superior en Informática, he aprendido lo que significa el Modelo-Vista-Controlador y como aplicarlo. Cuanto menos curioso, ¿no? Uno de los patrones por excelencia y no sabía como utilizarlo en la práctica.

Bueno, de hecho, lo conocía, sabía lo que era, pero no lo estaba aplicando bien.

¿Qué tiene que ver esto con reescribir código? Bueno, básicamente todo.

Con este conocimiento en mi poder, ahora sé como hacer las cosas mejor de lo que lo hacía, de una forma más organizada, así que puedo continuar añadiendo código a la web de mecanografía tal y como venía haciendo, o puedo aplicar el MVC, haciendo así el código más mantenible para el futuro y más fácil de desarrollar para el presente.

Como siempre, cuando hay que hacer un gran cambio, uno se pregunta: ¿Vale la pena invertir todo este tiempo en ese cambio? ¿compensa el esfuerzo?

La respuesta correcta a esta pregunta sólo se conoce unos meses más tarde de haber tomado una elección. Si después de unos meses la reimplementación y/o reestructuración de código no ha sido beneficiosa de alguna manera, entonces no merecía la pena el esuerzo.

Hasta el momento, he tenido que tomar esa decisión 3 veces en mi carrera profesional. Considero que todas ellas han sido acertadas.

Para el que no se haya parado a pensarlo nunca, a continuación pongo una lista con los pros y las contras para reescribir o reestructurar código.

Las contras de reescribir/reestructurar código:

• Se invierte tiempo
• Surgen nuevos bugs (y luego tienes que invertir más tiempo extra en arreglarlos)
• Dejas de implementar nuevas funcionalidades (y la competencia te come)

Las ventajas de reescribir/reestructurar código:

• entiendes mejor tu programa
• tu código se hace más mantenible
• es más fácil escribir nuevas funcionalidades
• y en definitiva, te encuentras más agusto con tu código y con ello más feliz :)

Todos los días se aprenden cosas nuevas, uno no puede pasarse la vida reimplementando cosas sólo porque sabe hacerlo un poco mejor. Normalmente suele ser más importante implementar nuevas funcionalidades que aporten algo más al producto, que reescribir o reestructurar código.

¿Cuando pesa más pararse a reescribir código? Cuando sepas que a medio o largo plazo te va a aportar una ventaja competitiva o te haga tan conocedor de tu producto que seas capaz de implementar nuevas funcionalidades en la mitad de tiempo.

Un artículo muy interesante, relacionado parcialmente con el tema y que recomiendo sin lugar a dudas, son las 7 razones por las que Derek Sivers volvió a PHP después de pasar 2 años desarrollando en Ruby On Rails (en inglés – y desde aquí gracias a Héctor por el enlace).

Conclusión: al final voy a readaptar y reestructurar artypist usando MVC porque considero que voy a acabar con un código más estructurado, más mantenible y donde voy a poder añadir nueva funcionalidad más fácilmente (por no hablar que voy a meter todo el código de nuevo en mi cabeza).

Esta tarde he estado trabajando en la página de mecanografía.

El caso es que he perdido muchísimo tiempo para realizar una tarea que en principio parece una chorrada.

Quería hacer una barra de progreso normal y corriente, con un color de fondo, el borde en negro (de un pixel de grosor) y el texto que yo eligiera en el centro.

El problema, como siempre ha venido con la incompatibilidad de los navegadores. Lo que funcionaba en Firefox no funcionaba en Internet Explorer y viceversa. Además también funciona de categoría para Opera.

Finalmente, tras muchos intentos de prueba y error, he conseguido lo que quería. A continuación se puede ver el resultado:

Para los interesados, pinchad aquí para ver el ejemplo de la barra de progresos. Si mirais el código fuente vereis lo sencillito que se ha quedado al final.

Nota: Al final he perdido casi más tiempo tratando de poner la barra de progresos en este artículo (WordPress no me deja poner HTML en plano) que programando la barra de progresos. Finalmente he optado por pasar olímpicamente de poner el ejemplo HTML embedido en este artículo y he puesto la imagen.

Actualización: acabo de leer un artículo bastante completo sobre otras soluciones para dibujar barras de progreso y gráficos. Muy interesante :)

Tras la primera entrada sobre de copias de seguridad aquí va otra entrada sobre cómo hacerlo para el caso de servidores web.

Para realizar backups, primero se necesita una cuenta de usuario en la máquina. Si no tienes cuenta de usuario, poco puedes hacer.

En mi caso básicamente tengo dos webs de las que quiero hacer backup: artypist.com y este blog.

Este blog utiliza wordpress, por lo que realmente, hacer un backup de los archivos tampoco aporta mucho valor, ya que en caso de perder los ficheros, se podrian volver a bajar de internet.

Lo más importante de este blog, y de cualquier otro, es la base de datos y los ficheros de imágenes o datos que se puedan haber subido al servidor.

Guardar un backup de los ficheros que puedes conseguir por otra parte es importante en dos casos:

• Para minimizar el tiempo de reacción cuando te das cuenta de que todo ha dejado de ir: imagina que este blog se borra por arte de magia. Si yo tenia un backup, es mejor restaurar el backup, que tendrá las contraseñas de la base de datos, etc, antes que reinstalar y configurar todo wordpress, ya que se tarda mucho menos en que el servidor vuelva a estar en pleno funcionamiento.
• Para prevenir pérdida de datos que no recordábamos que habíamos modificado: imagina que cambias el estilo de la página o que has subido archivos y desconoces si se guardaban en la base de datos o el sistema de ficheros. Si tienes una copia de todo, sabes que luego podrás recuperarlo todo. Fácil.

En el caso de Artypist, el punto crítico sería la base de datos, ya que la web, las lecciones, etc… se podrían recuperar del sistema de control de versiones.

En cualquier caso lo mejor es realizar un backup de todo y así uno se cura en salud, por lo que pueda pasar.

Una vez vistos los motivos, el script ideal que soluciona nuestros problemas debería hacer las siguientes cosas:

• Crear un archivo comprimido (.tgz) para los archivos de cada dominio
• Crear un archivo comprimido (.gz) por cada base de datos de cada dominio
• Eliminar copias de seguridad antiguas (p.ej. eliminar copias de hace más de 10 dias)
• Mandar las copias de seguridad creadas a otro servidor

Una vez se tiene el script, hay que hacer que se ejecute automáticamente de forma periódica. ¿Por qué automáticamente? Porque manualmente se nos olvidaría, o lo iríamos dejando pasar hasta un día en que nos hiciera falta el backup y por pereza ese backup no existiera.

Para ejecutar comandos automáticamente, en linux se usa cron. Así que, nos vamos a una consola y hacemos:

$ crontab -e

Suponiendo que el script de copias de seguridad se encuentra en “/home/usuario/backup.sh”, editamos el archivo de cron para que contenga algo como:

30 3 * * 2,4,7 /home/usuario/backup.sh

Este script se ejecutaría todos los Martes, Jueves y Domingos a las 3:30 de la madrugada. Con lo que tendríamos 3 copias de seguridad a la semana.

Para más información podeis leer este artículo de backups automátios de DreamHost (en inglés)

Para el que quiera echarle un ojo: este es el script de backup en cuestión: Script de Backup

Finalmente, el último paso del script compromete un poco la seguridad, ya que para que no pida passwords hay que crear unas claves y copiarlas en ambos sistemas, así que si el entorno no es del todo seguro, lo mejor es borrar estas lineas.

No soy ningún experto en servidores, y soy consciente de que todo puede hacerse mejor, así que si teneis alguna sugerencia será más que bienvenida.

Nota: dado que el script de backup contiene passwords, etc, hay que ser muy cautelosos acerca de dónde se ubica (para que no sea visible y alguien se lo pueda bajar desde tu web), y acerca de los permisos del archivo (para que otros usuarios del hospedaje no puedan ver su contenido). La recomendación es ejecutar el comando: chmod 700 backup.sh