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.
En Barrapunto se está generando una discusión interesante (con sus trolleadas, como no podían faltar) sobre qué lenguaje de programación aprender para una persona que no pertenece al mundo de las IT. Por ahora va ganando Python, seguido de cerca por Java, C y C#.
Comentan en Barrapunto que se está intentando impulsar un Stack Overflow en español en el Area 51 de Stack Exchange (la zona donde la gente sugiere y vota por nuevos proyectos del estilo Q&A), pero todavía se necesitan bastantes votos para pasar a una fase beta.
Particularmente estoy en contra, ya que considero que el inglés técnico no es tan complicado como para que todos lo utilicemos y el conocimiento se pueda difundir sin entrar en guetos lingüísticos. Me quedo con un párrafo de un comentario de eldaimon.
Esto dificulta enormemente la transmisión de conocimientos y viene precisamente de esa tendencia a convertir todo a nuestro propio idioma, en este contexto, me parece un paso atrás intentar crear un stack overflow hispano, fomenta esa cultura de programar en nuestro idioma y dificulta la transmisión de conocimiento de los programadores hispanos al resto del mundo al haber como hay un idioma común de facto que es el inglés, idioma que me atrevo a decir es fundamental en nuestro trabajo.
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.
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.
Vía Hackers News llego a un artículo para principiantes de cómo (y cómo no) instalar Ruby on Rails (RoR) en un entorno Linux. A continación pego el artículo, con una discusión interesante, tanto en HN como en el propio blog:
Si usáis el CVS Git para la gestión de vuestros proyectos creo que os puede ser de ayuda la siguiente «hoja resumen» o «cheatsheet», creada por Alexander Zeitler y publicada con licencia CC-by-sa 3.o.
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.
Vía Álvaro del Castillo llego a un documento (en PDF) que puede ser interesante para aquellos que necesiten empezar a trabajar con el sistema de control de versiones distribuido Git.
El documento fue publicado en el encuentro de GNOME Hispano, que tuvo lugar en Sevilla, los días 1 y 2 de mayo de 2010.
También disponible por estos lares.