Confidare Weblog

En principio, es buena la idea de los patrones \w y \W en las expresiones regulares PCRE de PHP. Según la documentación, el patrón \w debe calzar con cualquier carácter de “palabra” (esto es, letras, dígitos y la barra inferior “_”), considerando el locale actual. Cito:

Un caracter de “palabra” es cualquier letra o dígito, o el caracter de subrayado, esto quiere decir, cualquier caracter que pueda ser parte de una “palabra” en Perl. La definición de letras y dígitos es controlada por las tablas de caracteres de PCRE, y puede variar si se están efectuando coincidencias específicas a localidades. Por ejemplo, en la localidad “fr” (Francia), algunos códigos de caracteres mayores a 128 son usados para letras con acentos, y éstas coinciden con \w.

Esta última característica haría que, por ejemplo, la función preg_replace fuera idónea para sanitizar datos ingresados por el usuario; por ejemplo, podríamos reemplazar fácilmente cualquier carácter “extraño” por un espacio mediante un simple:

preg_replace(’/\W/’, ‘ ‘, $q)

La gracia sería que no reemplazara los caracteres acentuados, ni a nuestra querida letra “Ñ”. Según la documentación, todo lo que habría que hacer para lograrlo es asegurarse de que el locale esté ajustado al valor correcto. Sin embargo, miren este caso de prueba:

< ?php
echo setlocale(LC_ALL, ‘es_CL.UTF-8′) . “\n”;
echo preg_replace(’/\W/u’, ‘ ‘, ‘año’) . “\n”;

La salida es:

$ php -f test.php
es_CL.UTF-8
a o

De manera que la “ñ” no es considerada un carácter de “palabra”. ¡Bien, PHP! En devnetwork.net un tipo llegó a probar todo el juego ASCII para finalmente concluir de que el locale es ignorado por las funciones PCRE de PHP.

Ah, por supuesto. ¿Tiene que haber otra manera de lograrlo, no? Claro que no es tan elegante:

preg_replace(’/[^A-Za-z0-9áéíóúÁÉÍÓÚñÑ_]/’, ‘ ‘, $q);

En tardes como ésta puedo llegar a entender a los php-haters.

Actualización: Gracias a Roberto dimos con una mejor alternativa para evitar este “bug”. Mira en los comentarios para más detalles.

Nada más quería advertir a quienes pasen por aquí que acabo de perder media hora tratando de descubrir por qué el lenguaje del calendario dynarch de la aplicación Symfony en que estoy trabajando volvió a cambiarse de español a inglés, con los consiguientes errores a la hora de almacenar las fechas en la base de datos (por el formato).

Resulta que, por alguna razón (ahí está el misterio), —y a pesar de que mi default_culture está en “es” en el archivo settings.yml— a la hora de incluir los archivos JS del calendario Symfony se encontraba con que la “cultura” del usuario era “en” en lugar de “es”. Después de varios cabezazos y por pura prueba y error, descubrí que el problema residía en la sesión. En la sesión simplemente la cultura había quedado como “en”.

Así que, bastó con borrar las cookies involucradas (gracias a San Web Developer Toolbar) para resolver el problema.

¿Cómo llegó a meterse esa cookie venenosa ahí? Ahora que lo pienso, a la otra aplicación en la que estoy trabajando no le he configurado aún el default_culture, de manera que de ahí debe venir la contaminación. Increíblemente, la reflexión que tuve que hacer para escribir este post me ayudó a encontrar la raíz del problema. ¡Gracias por su ayuda!

Durante este año hice dos presentaciones para el Ciclo de Charlas Técnicas del DI, una dedicada a Subversion y la otra a Symfony; en el contexto del Ciclo, me pidieron que repitiera la primera. La segunda despertó tanto interés que me invitaron a la Feria de Software, en Santiago, para repetirla.

Los PDF con las diapositivas están publicadas en la web del Ciclo de Charlas Técnicas, pero creo necesario tenerlas también aquí en el Weblog, así que a a continuación los enlaces para las descargas y el texto promocional de las presentaciones:

Subversion, la Piedra Angular del SCM

Descargar las diapositivas en PDF

Subversion es un sistema de control de versiones centralizado y multiplataforma, orientado a reemplazar al vetusto CVS en proyectos de código abierto.

A pesar de lo limitado de sus objetivos, la herramienta tiene el potencial para convertirse en la piedra angular del SCM (Software Configuration Management) en proyectos de todo ámbito y tamaño.

A lo largo de la presentación se muestra problemas típicos y recurrentes relacionados con el SCM, y cómo Subversion puede ayudar a resolverlos. Algunos de los escenarios analizados son:

• Desarrollo cooperativo.
• Separación del desarrollo en ramas.
• Control de entregas.
• Inclusión de bibliotecas de terceros.
• Control general del proyecto.

Symfony, el Nirvana del Programador Web

Descargar las diapositivas en PDF

Symfony es un framework orientado a acelerar la creación y mantenimiento de aplicaciones web, que elimina la necesidad de repetir tareas tediosas de un proyecto a otro. Su único requisito es PHP 5, y es compatible prácticamente con cualquier motor de bases de datos disponible en el mercado. La herramienta puede reducir considerablemente los costos asociados a un proyecto de desarrollo de software, pues proporciona apoyo especial a las siguientes tareas:

• Separar las capas lógicas de la aplicación.
• Generar el mapeo relacional-objeto, necesario para acceder a los datos desde la aplicación.
• Administrar en forma declarativa y sencilla la configuración del proyecto.
• Crear y aplicar tests sistemáticamente al software.
• Documentar la API del software.
• Poner en producción la aplicación (deployment).
• Usar caching para acelerar la ejecución.
• Poblar una base de datos con registros de prueba.
• Manejar autenticación y autorización.
• …y un largo etcétera.

La presentación consta de una introducción a los conceptos en los cuales Symfony está basado.

Habiendo adquirido una consola Atari 2600 Junior (¡ah…! ¡la nostalgia!) a través de un conocido portal de remates en Internet, me apresuré en completar la transacción para que el vendedor me la enviara cuanto antes (de Talca). Cuando finalmente obtuve el número de flete de Tur Bus, fui directamente a la página de seguimiento de carga de su web), ingresé el numerito, presioné “Realizar seguimiento” y el resultado fue:

La situación del paquete era “PENDIENTE ENTREGA”. ¿Y qué significa eso? O sea, claramente se indica que falta entregar el paquete, pero ¿a quién? ¿al bus que lo va a transportar? ¿a la oficina de Valparaíso? ¿a mi? ¿a alguien más que esté en el camino?

En vano busqué en la web el significado de dicho código. Miré la sección de “Datos útiles”, busqué en otras páginas, incluso usé google para ello, pero nada.

Lo único que pude hacer, resignadamente, fue telefonear a la oficina de Valparaíso para preguntar por el estado del paquete. Entonces escuché a una operadora teclear el código (quizá en la misma página en la cual lo había hecho yo minutos antes) y decirme con voz gangosa “su paquete está acá, tiene que venir a buscarlo”.

De manera que Tur Bus invierte en un sistema para hacer el seguimiento de los paquetes de carga que transporta, el cual, a pesar de su aparente sencillez, tiene un costo no despreciable. Sin embargo, en su construcción se olvida un pequeño detalle: un simple glosario de los estados posibles de un paquete (cuyo compañero perfecto sería un diagrama de estados); ese sí es un costo despreciable, pero por no haber detectado dicha necesidad, seguramente por la sencilla razón de no haber visto la aplicación desde la perspectiva del usuario, su utilidad es nula en el caso de clientes como yo, que no la hemos utilizado más que un par de veces.

Habría enviado un comentario al encargado de la mantención de la aplicación, pero no encontré como contactarlo.

Hablando de usabilidad, un ejemplo de mensaje de error confuso (Office 2003):

Perdón, pero… si digo “sí”, ¿estoy aceptando continuar o estoy aceptando esperar?

No costaba nada poner dos botones “Esperar” y “Continuar”, pero de lo poco que he programado en Visual Basic, sé que crear un diálogo con alternativas “sí/no” significa menos trabajo que crear uno con etiquetas genéricas, así que, esta dificultad para el usuario debe ser producto sólo de la flojera de los programadores de Office…

La ISO define la usabilidad como:

La medida en la cual un producto puede ser utilizado por usuarios dados para lograr objetivos específicos con efectividad, eficiencia y satisfacción en un contexto de uso dado.

Jakob Nielsen va un paso más adelante y enumera las componentes de la usabilidad de un sistema:

1. Facilidad de aprendizaje.
2. Eficiencia en el uso.
3. Facilidad de memorización.
4. Pocos errores, y no catastróficos.
5. Satisfacción subjetiva.

Luego, para evaluar la usabilidad de un software, es necesario considerar preguntas como: ¿Cuán facilmente logran los usuarios realizar sus tareas? ¿Cuánta capacitación requieren para usar el sistema? ¿Qué recursos de documentación están disponibles para los usuarios? ¿Cuán fácil es encontrar respuesta a sus interrogantes en ellos? ¿Cuán comprensibles son para los usuarios los mensajes que aparecen cuando cometen un error? ¿Cuán fácil es recuperar al sistema de un error? ¿Existen canales de interacción dedicados a usuarios con discapacidades?

En la actualidad la usabilidad está cobrando importancia creciente en la ingeniería de software, lo que redunda en mejores soluciones para los usuarios; sin embargo, nuestro país parece quedarse atrás al respecto, y creo que ello tiene que ver con lo siguiente.

Cada vez que un nuevo concepto surge con fuerza y personas “influyentes” comienzan a utilizarlo en sus artículos y conversaciones, pareciera que el ciudadano común se siente amenazado por el hecho de no saber el significado de “eso de lo que todos están hablando” y en lugar de tomar el camino correcto y documentarse formalmente al respecto, asume lo primero que atisba a entender (y que generalmente es incorrecto o, a lo menos, incompleto). Sumen a esto el hecho de que dichos “ciudadanos comunes” suelen utilizar estos “conocimientos” en sus conversaciones diarias y obtendrán como resultado una serie de concepciones erradas, pero fuertemente arraigadas en ellos gracias a la reafirmación que surge al compartirlas con otros.

Así, hoy en Chile tenemos un sinfín de personas que creen saber qué es la usabilidad, pero en realidad asocian al término un significado equivocado. Según he observado, ellos tienden a pensar que la usabilidad tiene relación sólo con la gráfica de una aplicación, y sólo le evalúan a través de una inspección subjetiva del uso de formas y colores.

Me imagino que a estas alturas se estarán preguntando: “¿Va este artículo a alguna parte?”. Pues sí.

Permítaseme explicar lo relativo a la presentación al cliente de las maquetas de las pantallas de una aplicación. Dichas maquetas se construyen durante la fase de análisis y son bosquejos cuyo objetivo es unificar tempranamente las visiones de la aplicación que tienen tanto el cliente como los ingenieros de software; además sirven para determinar si se ha considerado todos los elementos que incluirá el sistema y para discutir su mejor distribución en la pantalla con la usabilidad en mente.

Cuando preparo estas maquetas hago uso sólo de mi editor de textos favorito y una CSS frugal que se limita a destacar campos obligatorios y hacer notorio el título de la página por sobre el resto de los elementos; fuera de esto, el fondo es blanco y hay cero (¡cero!) gráfica en las pantallas. Lo hago así porque:

• En este punto del proceso se debe enfatizar los contenidos de las pantallas por sobre las formas y colores que se utilizará para presentarlos. La atención del cliente / usuario debe enfocarse a evaluar la relevancia y distribución de los elementos de interacción propuestos.
• Un ingeniero de software no debe hacer el trabajo de un diseñador gráfico (y viceversa).

Pues bien, hace unos días tuve que presentar las maquetas para una aplicación a unos clientes que en varias ocasiones me habían manifestado su interés por maximizar la “usabilidad” de mi solución. Yo había trabajado con esmero organizando con lógica los controles y otros elementos de cada página para facilitar la interacción con el sistema; me había asegurado de que cada etiqueta tuviera texto entendible desde el punto de vista del usuario, había asociado a cada INPUT su correspondiente LABEL para proporcionar un área de clic más grande, etc.

Sorpresivo fue que los clientes mostraran poco interés por estos detalles, y se limitaran a pedir la remoción de ciertos elementos que quedaban fuera del ámbito de la solución. Cuando la exposición, que yo no estaba dirigiendo, terminó, dijeron:

— OK.
— ¿Alguna observación? —dijo quien dirigía la exposición.
— Usabilidad, solamente.

La respuesta me pareció extraña, pero no fue sino hasta mucho después del fin de esa reunión que entendí qué era lo que había detrás de ella. ¡Claro! estos clientes pertenecen a la masa de ciudadanos de nuestro país que entiende “gráfica” por “usabilidad”. O sea que cuando me manifestaban su interés por maximizarle, en realidad se referían a las formas y colores de las páginas, no a la facilidad de uso, ni al esfuerzo de aprendizaje y memorización que deben invertir los usuarios, ni a la eficiencia con que usarán el sistema, y tampoco a la cantidad y gravedad de errores que podrán cometer al hacerlo.

Triste es que mientras en otros países se está llevando a cabo loables esfuerzos por mejorar la usabilidad de los sistemas, en nuestro país ni siquiera entendamos de qué se está hablando y confundamos la urgencia de mejorar las relaciones hombre-máquina con la necesidad subjetiva de satisfacer nuestros gustos estéticos.