PDF Creator y el error que no era un error

Curioso como muchas veces salen a producción errores como el siguiente. Lo he visto en más de una máquina, y es que al tratar de usar PDF Creator sale una ventana de alerta sin mensaje.

PDF_creator

Y lo más sorprendente es que toda la gente a la que se lo vi sabían que era un mensaje de actualización y pulsaron en el botón «No».

Skype y la ejecución múltiple

Curioso el error que encontré al tratar de arrancar 2 veces Skype. En vez de permitir una única instancia dejan arrancar múltiples, capturan una excepción y muestran un aviso de lo que posiblemente esté sucediendo. Creo que es una solución poco elegante desde el punto de vista de UX.

Skype_multiple_instancia

Conflicto entre Apache (XAMPP) y Skype que no me permite arrancar Apache

Habitualmente desarrollo web en un servidor local, concretamente un XAMPP, que me permite disponer en un entorno Windows de Apache, PHP y MySQL sin tener que andar sincronizando con servidores remotos.

XAMPP dispone de un interfaz que permite arrancar con un clic Apache y MySQL. Hoy traté de acceder y obtenía el siguiente error:

[Apache] Error: Apache shutdown unexpectedly.
[Apache] This may be due to a blocked port, missing dependencies,
[Apache] improper privileges, a crash, or a shutdown by another method.
[Apache] Check the «/xampp/apache/logs/error.log» file
[Apache] and the Windows Event Viewer for more clues

Tras mucho buscar he encontrado el error en Stack Overflow, y no era otro que Skype, que utiliza el puerto 80 y el 443 para las conexiones entrantes.

Para solucionar el problema simplemente hay que ir a Herramientas -> Opciones -> Avanzada -> Conexión y ahí deseleccionar el campo de selección «Usar puertos 80 y 443 como alternativas para las conexiones entrantes«.

Tras cerrar Skype (no minimizarlo) Apache arrancará corrrectamente.

Conflicto_entre_XAMPP_y_Skype

 

 

Entrevista a Carlos Domingo, Telefónica I+D, sobre Firefox OS

Interesante la entrevista que le ha hecho la gente de Xataka a Carlos Domingo, de Telefónica I+D, sobre Firefox OS. Los temas centrales son:

  • Historia e involucración de la empresas de telecomunicación y de Mozilla.
  • Búsqueda del nicho de la gama baja de smartphones.
  • Gobernanza del proyecto.

Medir la velocidad de carga de una web

Últimamente este blog y otros sitios que tengo alojados en Godaddy, en un hosting compartido, tardan mucho más de lo habitual en cargar (si me sigues por RSS ni te habrás enterado).

Para comprobar que no es problema de mi conexión ni de mi ubicación geográfica he estado probando una serie de webs, que me resultaron útiles para tener claro dónde está el problema, pero también son interesantes para optimizar el tiempo de carga de una web en condiciones «normales»:

  • Pingdom, que permite usar el servicio desde 2 lugares en USA y 1 en Europa.
  • Web Page Test, que permite medir la velocidad de carga desde varios lugares del mundo (1 en España) y con diferentes navegadores.
  • Google PageSpeed.
  • GTmetrix.
Además también existen varias extensiones que permiten realizar estas mediciones:

 

La dirección de correo electrónico como nombre de usuario

Para acceder a muchos sitios web (Facebook, Amazon, …) utilizamos como nombre de usuario nuestra dirección de correo electrónico. Para el desarrollador web es una forma sencilla de obtener una dirección de correo electrónico, que puede ser utilizada para varias acciones útiles dentro de la web: validar la inscripción en el sitio web, obtener o recuperar la contraseña de acceso, enviar notificaciones,… En otros sitios utilizan un nombre de usuario (Slashdot, Barrapunto, …), decisión que me gusta menos, ya que necesitas pedir más datos al usuario para realizar su registro, con los posibles abandonos en el registro que esto puede acarrear. Incluso bastantes sitios (Menéame, Stack Overflow,…) permiten registrarse y autenficarse con el usuario de Facebook, de Twitter o de Google+, con lo que el tiempo de registro es mucho menor y, por lo tanto, el porcentaje de abandono también es menor. Es un punto clave en el comercio electrónico, ya que muchas tiendas permiten añadir productos al «carrito de compra virtual» sin estar registrados y se solicita el registro al finalizar la compra, momento en el que se produce la mayor parte de los abandonos, perdiendo la venta.

Volvamos al registro que utiliza la dirección de correo electrónico como nombre de usuario. Algo tan sencillo para el usuario final como introducir su dirección de correo electrónico al registrarse o al acceder a la aplicación web plantea varias cuestiones al desarrollador de la aplicación web. Entre ellas está la que trataré de analizar en esta entrada, algo que puede parecer tan trivial y sencillo como qué hacer ante dos direcciones idénticas pero una escrita con minúsculas y otra con mayúsculas, como por ejemplo pepe@example.com y PePe@example.com

Lo primero que se nos puede pasar por la cabeza es convertir todo a minúsculas, de tal forma que tanto la inserción en la base de datos como las comprobaciones al tratar de encontrar usuarios ya existentes en el proceso de registro o al tratar de acceder al sistema el en proceso de autentificación utilicen siempre comprobaciones en minúsculas. Este planteamiento puede ser correcto, o no. Voy a plantear su análisis desde tres puntos de vista: el técnico, el del usuario final y el «estándar de facto» o lo que están haciendo las grandes compañías.

Técnico

Para analizar cómo debe afrontar un desarrollador este problema hay que ver cómo se define una dirección de correo electrónico. Esta está formada de la siguiente forma

user@example.com

La parte local de la dirección de correo electrónico («user» en el ejemplo) solo puede utilizar  los caracteres ASCII indicados en la sección 3.2.3 del RFC 5322 (Internet Message Format), entre los que se encuentran las letras minúsculas y mayúsculas del alfabeto inglés. Aquí ya se hace una primera distinción de mayúsculas y minúsculas. En la sección 2.4 del RFC 2821 (Simple Mail Transfer Protocol) se aclara totalmente:

The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts. Mailbox domains are not case sensitive. In particular, for some hosts the user «smith» is different from the user «Smith». However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged.

Lo que viene a decir aquí es que los servidores de correo deben de ser sensible a mayúsculas, pero se recomienda mantener una política interna en la organización que evite estos problemas de colisión.

Además indica que la parte de dominio (lo que va despues de la @, en el ejemplo sería example.com) no es sensible a mayúsculas, tal y como se puede comprobar a lo largo del RFC 1035 (Domain names – Implementation and specification), leyendo los párrafos donde aparacen las palabras «case-insensitive» y como se aclara en el RFC 4343 (Domain Name System (DNS) Case Insensitivity Clarification).

Aclarándonos, lo que va antes de la @ es sensible a mayúsculas (aunque no se recomienda su uso para evitar problemas de interoperatibilidad) y lo que va después no es sensible a mayúsculas.

Aquí llega el primer problema, que es el de las colisiones si normalizo todas las direcciones de correo electrónico a minúsculas antes de insertarlas en la base de datos o antes de hacer las comparaciones (usuario existente en el proceso de registro, proceso de autentificación,…).

Un ejemplo claro es qué pasa si un usuario PePe@example.com se registra en mi sistema web y el servidor de correo electrónico de «example.com» tiene otro usuario cuya dirección de correo electrónico es pepe@example.com. Si este servidor de correo es sensible a mayúsculas la confirmación de la inscripción en el sitio web o la recuperación de la contraseña tendría que ser enviada al usuario PePe@example.com, pero llegaría a otro buzón de entrada, al del usuario pepe@example.com, con el consiguiente problema de seguridad que acarrea. Este tipo de problemas se pueden atacar de varias formas en el sistema web, como podría ser guardar el nombre de usuario en el formato original (PePe@example.com) y hacer que las comprobaciones no sean sensibles a mayúsculas. Pero nos encontraríamos con otro problema, ya que aunque el sistema podría registrar a los dos usuarios (PePe@example.com y pepe@example.com), ¿qué hago en el proceso de autentificación o de recuperación de la contraseña? ¿A quién le envío el token de recuperación de la contraseña?

Otro ejemplo problemático sería ¿qué hacer si tengo un sistema sensible a mayúsculas, el usuario se registra con la dirección PePe@example.com (por equivocación), recibe el correo electrónico de confirmación de la inscripción en la dirección pepe@example.com (sistema de correo no sensible a mayúsculas, que hay unos cuantos, como mostraré posteriormente) y al tratar de acceder posteriormente con el usuario pepe@example.com se le indica que el usuario no existe, ni es posible que recupere su contraseña.

Los casos problemáticos son unos cuantos si nos paramos a analizarlos, con la reducción de usabilidad del sistema, y, consecuentemente, con la frustración por parte del usuario en el uso de la aplicación web, que puede llevar a su abandono.

Usuario

Vistos algunos de los problemas que pueden plantearse cuando tratamos de ceñirnos a los RFC, ahora enfoco el problema desde el punto de vista del usuario final, del que va a registrarse y a utilizar nuestro sistema web. Deberíamos buscar un sistema usable, que no le haga pensar este tipo de cuestiones al usuario ni en el registro, ni en la autentificación ni en el proceso de recuperación de la contraseña. Que le pida una dirección de correo electrónico, una contraseña (por duplicado o no), que le pida (o no) confirmación del registro y…. listo.

Analizado el problema desde este punto de vista, tendríamos que tratar como el mismo usuario y la misma dirección de correo electrónico a PePe@example.com, a pepe@example.com, a PEPE@EXAMPLE.COM y a PEPE@example.com. Lo más cómodo para el desarrollador será realizar una conversión a minúsculas en la dirección de correo electrónico antes de utilizarla para cualquier tipo de procesado o almacenamiento.

El único problema es que si el servidor de correo electrónico de la organización «example.com» es sensible a mayúsculas y en mi sistema trata de registrarse PePe@example.com, el correo de confirmación nunca le llegará a él, sino a la cuenta pepe@example.com, en el caso de que exista.

Los «big players»

En estos momentos los tres principales proveedores de cuentas de correo gratuitas (Gmail, Yahoo y Hotmail), y quizás las más utilizadas por los usuarios en su ámbito personal no son sensibles a mayúsculas. No busqué ningún documento para comprobarlo. Simplemente envié un correo electrónico a mis direcciones en los tres servicios, pero cambiando el nombre de usuario, que en todos los casos está en minúsculas, por otro en el que intercalaba una letra mayúscula y una minúscula. Los correos llegaron de forma casi instantánea.

Conclusiones

Lo primero sería plantearse si es lo correcto utilizar una dirección de correo electrónico como usuario en el portal. Los portales web que utilizan un nombre de usuario único pueden mantener la dirección de correo electrónico original, sensible a mayúsculas, en su base de datos, de tal forma que se utiliza el usuario para el proceso de autentificación y el correo electrónico para la confirmación de la inscripción y para la recuperación de la contraseña. Ya serán los servidores de correo electrónico los que se encarguen de gestionar la problemática con cómo esté escrita la dirección de correo electrónico que el usuario utilizó al registrarse. Los principales portales (Facebook, Twitter,…) no están utilizando este formato ni es la tendencia actual.

Descartado este sistema, si queremos ser estrictos y cumplir a rajatabla los estándares de Internet, sin lugar a dudas hay que desarrollar un sistema sensible a mayúsculas.

Pero viendo cómo operan los grandes proveedores de correo electrónico, analizando qué es lo más usable y adecuado para el usuario final (que será el que dictamine el éxito o fracaso del sistema web) y viendo que ni en el RFC 2821 (el de SMTP) lo recomiendan (exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged.) , si yo tuviera que desarrollar un sistema en el que el nombre de usuario fuera una dirección de correo electrónico, no lo haría sensible a mayúsculas. Trabajaría en todos los casos con un sistema en minúsculas, sabiendo de antemano que ni estaría cumpliendo los estándares RFC (pero sí los «de facto») y que un mínimo número de usuarios puede que tengan problemas en el registro en mi sistema web.

Error en la ejecución de Zend Framework

No suelo hablar de temas tan técnicos aquí, pero creo que es interesante dejar este apunte para aquellos a los que les pueda resultar interesante, ya que he tenido que buscar bastante por foros para llegar a la solución a este error.

En mis ratos libres estoy dando mis primeros pasos con Zend Framework, un framework de  código abierto para desarrollar aplicaciones y servicios web con PHP 5. Estoy llevando a cabo pruebas en un hosting compartido Linux en Go Daddy.

El mensaje de error que me aparecía de forma continua al tratar de ejecutar zf.sh, la herramienta de línea de comandos, era el siguiente (en vuestro mensaje variará la ruta donde se encuentra zf.php):

<br />
<b>Parse error</b>: syntax error, unexpected T_STRING, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or ‘}’ in <b>/home/content/x/a/m/user/html/zf/ZendFramework-1.11.11/bin/zf.php</b> on line <b>38</b><br />

La versión de PHP era la correcta (superior a la 5.2.4), comprobada mediante un script php que ejecuta la función phpinfo(), así como ejecutando en línea de comandos «php -v». La versión instalada era la 5.2.14.

Además, mediante un sencillo código que utiliza las librerías Zend Framework, comprobaba que las librerías de Zend están incluídas en las rutas del php5.ini, mediante la línea

include_path = «/home/content/x/a/m/user/html/zf/ZendFramework-1.11.11/library»

El código que realiza la comprobación es el siguiente

<?
require_once ‘Zend/Mail.php’;
$mail=new Zend_Mail();
echo ‘it is working’;
?>

La solución a este problema es muy sencilla, y llegué a ella a través de este blog. Es tan sencilla como editar el archivo zf.sh e incluir después del código

if test «@php_bin@» != ‘@’php_bin’@’; then
PHP_BIN=»@php_bin@»
elif command -v php 1>/dev/null 2>/dev/null; then
PHP_BIN=`command -v php`
else
PHP_BIN=php
fi

La línea

PHP_BIN=/usr/local/php5/bin/php

que indica donde se encuentra el ejecutable (no el directorio) de php5. Esta ruta, así como el nombre del ejecutable, pueden variar dependiendo de la instalación de Linux o del proveedor de hosting (ISP) utilizado. En mi caso es un hosting compartido Linux de  Go Daddy.

Linus Torvalds’s Lessons on Software Development Management

A través de Slashdot llego a una entrevista interesante a Linux Torvalds, que recomiendo leer. No se centra en temas demasiado concretos, sino que menciona temas como la importancia del usuario, la importancia de las herramientas de desarrollo, la importancia de las listas de correo en proyectos del tamaño del Kernel y la delagación de funciones cuando se dirige un proyecto con centenas de desarrolladores.

Me quedo con una frase, para mi muy importante, ya que se centra en el usuario de ese código, no en la calidad del código:

“The other thing—and it’s kind of related—that people seem to get wrong is to think that the code they write is what matters,” says Torvalds. Most software development managers have seen this one. “No, even if you wrote 100% of the code, and even if you are the best programmer in the world and will never need any help with the project at all, the thing that really matters is the users of the code. The code itself is unimportant; the project is only as useful as people actually find it.”

Merece la pena dedicarle 10 minutos.

Dropbox accesible sin contraseñas

Parece que la gente de Dropbox subió a producción una actualización con un ligero bug de seguridad: permitía acceder a cualquier usuario sin utilizar una contraseña válida.

Curioso el comentario en el blog:

This should never have happened. We are scrutinizing our controls and we will be implementing additional safeguards to prevent this from happening again.

Me imagino la situación:

  • Programador junior. «Listo, actualización acabada. Ya compila».
  • Programador senior. «Pues venga, a producción».
  • Programador junior. «¿Pero no lo probamos ni le pasamos ningún tipo de batería de pruebas?»
  • Programador senior. «Qué baterías ni que hostias. Compila, así que a producción!!!!»

Pues si empresas de este tamaño cometen errores tan gordos como éste, no quiero ni saber qué tipo de controles de calidad están usando hasta ahora, si es que los estaban usando. Digno de las mejores viñetas de Coderfacts.

Vía Slashdot.