desarrollo

El test de Joel adaptado al desarrollo web

Leyendo blogs, me encuentro con este artículo que trata sobre una revisión del sencillo test de Joel Spolsky sobre la calidad del software. Esta nueva revisión, de la mano de Brandon Savage, propone 12 pasos adaptados al desarrollo web hoy día. Los pasos se responden con un sí o un no. Estos son los posibles resultados:

  • 12 síes. Perfecto.
  • 11 síes. Aceptable.
  • 10 o menos síes. Tienes un serio problema.

Ahora veamos las preguntas:

  1. ¿Usas algún sistema de control de versiones?
  2. ¿Puedes generar fichero para distribuir tu software en sólo un paso?
  3. ¿Usas integración continua?
  4. ¿Guardas un registro de bugs?
  5. ¿Corriges los bugs tras escribir nuevo código?
  6. ¿Cumples los hitos a tiempo?
  7. ¿Documentas las especificaciones?
  8. ¿Disfrutan tus programadores de un entorno de trabajo tranquilo?
  9. ¿Usas las mejores herramientas, y gastas dinero en aquéllas que son necesarias y caras?
  10. ¿Escribes test unitarios?
  11. ¿Tus nuevos candidatos demuestran sus conocimientos de programación con alguna prueba tangible durante la entrevista?
  12. ¿Tienes testers?

En mayor o menor medida, todas me parecen propuestas muy acertadas. No deja de ser una curiosidad más, pero posiblemente este “juego” sea una métrica de calidad de software equiparable a otros sistmas varios órdenes de magnitud más complejos.

Por cierto, yo obtengo un 6 sobre 11 (La pregunta número 11 no se aplica en mi caso).

Mejora progresiva

De un tiempo a ahora, cada vez leo con más frecuencia el término progressive enhancement, o en catellano, mejora progresiva. ¿Qué es exactamente? Como desarrolladores web, debemos lidiar con numerosos navegadores, cada uno con una serie de prestaciones y recursos. Como veremos a continuación, normalmente hay 4 formas de abordar esta situación:

  1. Impedir el acceso a determinados navegadores. Creedme, existen páginas a las que no se puede acceder con según qué navegadores. No me refiero a que se muestren defectuosas, es que directamente te muestran un mensaje de error. Tratad de acceder a una página de El Plural cambiando el user-agent de vuestro navegador y sabréis a qué me refiero. Ésta es una pésima solución.
  2. Quedarnos en el mínimo común denominador. Esto es, diseñar la página de modo que sólo contenga recursos disponibles por todos los navegadores. No es una solución muy escalable, puesto que se está limitando a las funcionalidades mínimas (Funcionalidades que, por otro lado, normalmente se corresponden con las de nuestro querido IE6). Visto con un enfoque más visual, esto significa que la manada debe ir a la velocidad del más lento. Por ejemplo, querémos posicionar un <div> de forma ‘fixed’. IE6 no lo permite, de modo que, o no lo hacemos, o dedicamos esfuerzos en buscar retorcidos hacks para lograrlo en este navegador. Mmmm no me gusta. ¿Qué más hay?
  3. Graceful degradation. Durante mucho tiempo ésta ha sido la tendencia reinante, y seguramente seguirá siéndolo. Consiste en partir del máximo de prestaciones de forma que, a medida que se usen navegadores menos avanzados, la página se mantenga usable con pequeños defectos. Un ejemplo perfecto es el uso de imágenes PNG con semitransparencias: Mientras que los usuarios de Firefox o Safari las verán sin problemas, los de IE6 se encontrarán con imágenes corruptas. En estos casos es frecuente dividir la página en dos niveles: El nivel 1 corresponde a una buena experiencia para el usuario, el nivel 2 con una versión degradada de la página. Encontramos un ejemplo en el servicio de correo de Google Gmail, con su versión avanzada (Por defecto) y una versión básica.
  4. Mejora progresiva. Y al fin llegamos a la mejora progresiva. ¿En qué consiste? Es exactamente igual que graceful degradation pero al revés. En lugar de partir de una versión avanzada, se parte de la versión mínima, de forma que, a medida que un navegador ofrece mejores recursos, la página también se ve mejorada. En este caso, se parte de un mínimo razonable, por ejemplo, que sea compatible con HTML 4. Podría, por ejemplo, usarse transparencias en GIF, y sin embargo, en aquéllos navegadores que sí lo soporten, semitransparencias en PNG.

Lógicamente las dos mejores soluciones son las dos últimas. ¿Cuál es mejor? Realmente depende del caso. Pero como método general yo prefiero la mejora progresiva, pues a diferencia de graceful degradation parte de una experiencia de usuario razonablemente buena. Además, con esto siempre ganaremos en accesibilidad.

Si bien cada día existen más navegadores con sus respectivas versiones, también es cierto que disponemos cada vez más de recursos que nos permiten abstraernos de ellos, como los numerosos frameworks javascript como jquery o mootools, además de brillantes soluciones como Google Chrome Frame.

Más información:

FirePHP – Integra logs de PHP en Firefox

En todo desarrollo se hacen necesarias herramientas que permitan hacer un seguimiento del código. Hoy voy a mostrar cómo mostrar logs desde PHP directamente a una consola en Firefox. ¡Di adiós a los “echos” y a los “var_dump”!

Expresiones Regulares

La primera vez que ves una de ellas sientes nauseas. A partir de ese momento cada vez que te enfrentas a ellas sientes mareos, hasta que poco a poco empiezas a entender su idioma. Llega un día en el que te sientes capaz de dialogar con ellas. La amistad se ha forjado.

Con las expresiones regulares ocurre como con los frameworks de desarrollo. La curva de aprendizaje suele ser lenta, pero siempre acaba mereciendo la pena. Son las encargadas de poner orden en los caos con los que muchas veces tienen que lidiar nuestros pobres procesos.

Gracias a ellas podemos confeccionar laboriosas expresiones como por ejemplo “Quiero saber cuales son todas las palabras que preceden a todos los números de 4 cifras que no terminan en 2″. Inventate una condición, seguro que se puede construir.

AVISO: No he sometido a prueba ninguno de los ejemplos que aquí pongo.

Escribe mejor CSS con lesscss

Vía SitePoint descrubo una joya :) Se trata de una herramienta programada en Ruby que permite escribir código CSS de forma más efectiva: LESS. En palabras de sus creadores, LESS extiende CSS añadiendo variables, mezclas, operaciones y anidamiento de reglas.

Por ejemplo, podemos definir una variable que contiene un color en notación HTML, y desde ahí se definen estilos con ese color. De esta forma, si mañana lo cambiamos, sólo tendremos que actualizar esa variable.

El anidamiento mejora enormemente la legibilidad del código. Si a eso le sumamos las operaciones que podemos realizar, como por ejemplo multiplicaciones, el resultado es sensacional.

Prometo usarlo :)

Biblioteca ActionScript3 para OpenSocial

La Fundación OpenSocial ha lanzado una nueva biblioteca del lado del cliente que permitirá programar aplicaciones OpenSocial utilizando el lenguaje de programación de Adobe ActionScript 3.

Sin duda este paso puede ayudar en gran medida a la consolidación de OpenSocial como estándar, pese a que parece que Facebook solito está poniéndoles las cosas difíciles.

Mientras tanto, esperaremos a ver si llega el día en que Facebook se una a OpenSocial.

Lanzado PHP 5.3.0

Hoy por fin PHP ha lanzado su última versión, la 5.3.0. Se ha hecho esperar, pues desde noviembre de 2006 estamos con la rama 5.2. Esta release mayor trae numerosas novedades que seguro nos ayudarán muchísimo en nuestros futuros proyectos. Además, es igualmente útil para ir adaptándonos a las funcionalidades que traerá PHP 6.0.

Para aquéllos que queráis actualizaros a PHP 5.3.0, han creado una guía de migración. desde donde tenemos acceso a la lista de incompatibilidades con la rama 5.2 al igual que una lista de nuevas funcionalidades:

  • Añadido soporte para espacios de nombres.
  • Añadido soporte para Late Static Bindings.
  • Añadido soporte para salto a etiqueta (limited goto).
  • Añadido soporte para Clausuras (funciones Lambda/Anónimas).
  • Hay dos nuevos métodos mágicos: Se han añadido __callStatic y __invoke.
  • Soporte para sintaxis de Nowdoc, y funciona como Heredoc pero con comillas simples.
  • Ahora es posible utilizar Heredoc para inicializar variables estáticas y constantes de clases.
  • Ahora la sintáxis de Heredoc puede declararse usando comillas dobles.
  • Ahora se pueden declarar Constantes usando la palabra clave const fuera de la definición de una clase.
  • El operador ternario ahora tiene un operador atajo ?:.
  • El wrapper de flujos HTTP ahora considera exitosos todos los códigos de estado entre 200 y 399.
  • Ahora es posible el acceso dinámico a métodos estáticos.
  • Se pueden anidar Excepciones.
  • Se ha añadido y activado por defecto el Recolector de Basura.

El staff de PHP responde a los consejos de Google

Esta semana Google ha presentado (Estos tíos no paran) una serie de consejos para mejorar el rendimiento de nuestras páginas web. ¡Escalabilidad, escalabilidad, escalabilidad! Prácticamente no lo he leído, ya que imagino que la mayoría de los trucos serán muy similares a los que Yahoo! ofrece desde hace tiempo (Por cierto, viva Yslow :D (Tampoco he probado el equivalente de Google, Page Speed)).

Lo que sí he hecho es revisar por encima los consejos que Google ofrece sobre PHP. Hasta yo, que no conozco prácticamente nada de las entrañas de PHP, me he percatado de que esos consejos eran a menudo erróneos, bulos que circulan, o relativos a versiones de PHP muy antiguas.

El staff de PHP ha contestado

Resumen de lo que sí son hechos:

  1. Don’t copy variables for no reason – Falso. El Zend Engine hace que cuando copias una variable, ambas apuntan a lo mismo salvo que se realicen modificaciones. Por tanto, la memoria usada será y es la misma.
  2. Use single-quotes for strings – Falso. Hace tiempo que el rendimiento es prácticamente equivalente al usar dobles comillas que comillas simples (Personalmente uso comillas simples por costumbre desde tiempo ha).
  3. Use echo to print – No siempre es mejor.
  4. Don’t use concatenation with echo – Falso. Ocurre al revés. Es más efectiva la concatenación que el uso de múltiples argumentos.
  5. Use switch/case instead of if/else – Sin sentido. La diferencia entre uno y otro es de estilo, no de rendimiento.

En fin, al menos todos estos tips son de buena fé :)

Google lanza un teclado virtual

Vía programmable web me entero de que Google acaba de lanzar un teclado virtual especialmente útil para páginas con soporte multi-idioma. ¿Qué vamos a poder hacer con esto? Podremos incluír un teclado en otro idioma directamente en nuestra web sólo con unas pocas líneas de javascript.

Actualmente están disponibles:

  • Árabe (العربية)
  • Hindi (हिन्दी)
  • Polaco (Polski)
  • Ruso (Русский)
  • Tailandés (ไทย)

Estoy seguro que tanto mi hermana Olalla como mi cuñado Samer se alegrarán de tener esta herramienta, y seguro que la utilizarán :)

Páginas web modulares en PHP con Zend Framework

Jeroen Keppens está escribiendo en su blog una serie de artículos muy muy interesantes acerca de cómo implementar módulos autocontenidos empleando Zend Framework. Esta estrategia es increíblemente potente ya que, al ser módulos autocontenidos, podremos copiarlos directamente a un proyecto nuevo y ya funcionarán. Si se programan de forma suficientemente versátil, se podrán encajar entre sí como piezas de un lego que dan forma a la aplicación final. ¿No es genial? :)

En el primero de ellos nos muestra cómo crear el esqueleto de un módulo. Los pasos básicos a seguir son:

  1. zf create project .
  2. zf create module nombremodulo
  3. zf create controller index 1 nombremodulo
    1. Bug – Renombrar el nombre de la clase del controlador añadiendo el prefijo Nombremodulo_.
  4. Añadir configuración de módulos en application.ini:
    resources.frontController.moduleDirectory = APPLICATION_PATH “/modules”
    resources.modules[] =

Básicamente con eso ya lo tenemos, accesible en el path relativo /nombremodulo. ¡Ha sido sencillo!

Por supuesto cada módulo se comporta como una mini-aplicación, por lo que podremos completarlo con su propio fichero Bootstrap.php. Nota: A mi me surgió la duda de cómo poder asegurarse de que un determinado método del Bootstrap principal se ha ejecutado (Por ejemplo, el resource db). Nada más tenemos que llamar a $this->getApplication() y obtendremos el Bootstrap principal. ¿Y esto por qué? Porque al estar contextualizados dentro de un módulo, no obtenemos el objeto Application como cabría esperar, sino el Bootstrap.

Llevado por la emoción, y teniendo en cuenta varios proyectos que tengo pendientes, me puse manos a la obra a programar mi primer módulo autocontenido: Usuarios. Será un módulo muy configurable que permita manejar sesiones, mostrar captchas, registro libre de usuarios o sólo por parte del administrador, acl, facebook connect, y más. Cuando tenga algo presentable lo liberaré :)

El caso, necesitaba que mi módulo fuera configurable. Por ejemplo, ¿se muestran captchas para hacer login? ¿Tras cuantos intentos fallidos? ¿Y qué tipo de captcha? ¿Dónde se almacenan los usuarios? ¿Y en qué campos? Para resolver eso necesitaba de un fichero de configuración. En lugar de tratar de que el propio módulo ejecute sus propios resources en su Bootstrap, opté por la solución fácil: Cargar a mano el fichero de configuración, y revisar sus opciones.

Pero de nuevo Jeroen Keppens ha dado en el clavo proponiendo la solución pro. En su segundo artículo sugiere un ingenioso y completo método para manejar configuraciones a nivel de módulo. No implementa aun manejo de errores, pues se trata de una pre-beta, pero ilustra a la perfección cómo solucionarlo.

Sólo le veo una pega a las soluciones que propone: Dependen en gran parte de su biblioteca extendida, es decir, es necesario tener accesibles a nivel de aplicación numerosas clases desarrolladas por él. Por supuesto, siempre hay una segunda opinión, y en mi caso ubico dichas bibliotecas en /modules/modulename/library/, pese a que en un futuro eso suponga ficheros repetidos. ¿No se trataba de tener módulos autocontenidos? ;)