En esta entrada no voy a hablaros de montar un servidor SVN, principalmente porque es una tarea compleja que está destinada más bien a administradores de sistemas. Os voy a hablar de como configurar vuestro proyecto para beneficiarse del funcionamiento de un servidor existente. Si lo que necesitas es crear tú mismo un servidor para estos fines, te recomendaría mejor el libro de O’Reilly de SVN.

Para proyectos en los que trabaje más de una persona creo que es una herramienta que una vez se conoce es poco menos que imprescindible. Incluso si trabajamos solos puede servirnos de gran ayuda para no perder ninguno de los cambios que hagamos y poder tener un histórico permanente del proceso de desarrollo.

Antes de adentrarme a explicar la configuración, diré básicamente en qué puede ayudarnos este sistema:

• Cada cambio que se envíe al servidor será guardado sin sobreescritura. Si nos cargamos sin querer un archivo podremos echar mano del SVN para recuperarlo.
• Posibilidad de mezclar dos archivos para ver las diferencias respecto a versiones. Podemos ver, por ejemplo, los cambios que hizo algún compañero en cada línea para comprender como han cambiado las cosas.
• Se añade un comentario a cada subida de archivos al servidor que hagamos. Esto ayuda a saber para qué se tocó ese fichero.
• Todos los cambios de los demás se podrán descargar de una vez, solamente aquellos archivos que tengan cambios. A veces, sobre todo en proyectos de programación web, se tocan archivos diversos de carpetas diferentes y en vez de tener que explorar y mirar las fechas de modificación, con SVN hacer un par de clics hará que ya lo tengamos todo más reciente.
• Control del trabajo de cada uno. Para empresas puede ser muy útil para saber quienes hacen tal cosa. Conocer los porcentajes de código que escribe cada empleado, etc.
• En caso de tratarse de un proyecto de software libre tener un control de versiones es imprescindible, puesto que necesitamos un lugar en el que la gente que quiera aportar cosas al proyecto pueda conectarse. De cualquier otra manera sería un caos.

Hasta aquí la enumeración de algunas de las ventajas, estoy seguro que me he saltado decenas de ellas.

Conseguir servidor:

Bueno, pues lo primero que necesitamos para empezar es un hosting de Subversion. Hostings hay muchos, aunque la mayoría son de pago y hay que saber encontrar el óptimo. Si tu proyecto es de software libre no debes preocuparte lo más mínimo de tener que pagar ni nada, puesto que para apoyar el Software Libre hay hostings gratuitos con capacidades ilimitadas para sus usuarios.

Una comparativa genial de los distintos hostings de Subversion que hay se puede encontrar en http://www.svnhostingcomparison.com/

Para software libre está claro que las dos opciones idóneas deben ser Google Code y SourceForge.net. Hay más que ofrecen capacidades ilimitadas, pero creo que esos están por delante.

Si nuestro proyecto es de software propietario entonces tendremos que ajustarnos un poco más, tendremos que escoger entre pagar para tener algo holgado o encontrar un hosting que permita privacidad en los proyectos y una cantidad de almacenamiento y usuarios aceptable.

Sin duda alguna, la mejor opción gratuita para software propietario es Assembla. Brinda de manera gratuita 2GB de almacenamiento, un número ilimitado de programadores e incluso SSL; sin contar que la velocidad de subida y bajada es super apropiada.

Hay más opciones, aunque la siguiente mejor ofrece 1/4 del almacenamiento que da Assembla, por lo que no merecen la pena. Si queremos pagar ya solo depende de lo que necesitemos y lo que podamos pagar, hay un punto en el que compensa tener un servidor dedicado tanto propio como alquilado para que se encargue únicamente del control de versiones.

Montar servidor:

Para montar el servidor habrá que seguir los pasos por los que nos guíe el sitio web del servicio web escogido hasta que finalmente obtendremos una dirección URL tal que así:

https://subversion.assembla.com/svn/sortea2

Hay que tenerla muy en cuenta puesto que a esta URL es a la que nos conectaremos. El usuario y la contraseña para conectarse será exactamente el mismo que el que tuvimos que usar para loguearnos en la página web.

Programa cliente:

A continuación tendremos que usar nuestro programa de lado del cliente para conectarnos; esto es, un programa en nuestro ordenador al que le daremos URL, password y usuario y estaremos conectados.

Para Windows el que se utiliza casi siempre es el Tortoise SVN, que es un cliente de escritorio de software libre también con una interfaz inmejorable. Una vez lo tengamos instalado este programa lo que hace es añadir unas opciones a los menús contextuales del explorador de Windows relativas a repositorios SVN.

Una nota importante a tener en cuenta para pasos posteriores es que si utilizamos Dreamweaver nos interesará descargar la versión de 32 bits de Tortoise si luego queremos conectar ambos sistemas. Se puede tener instalada la versión de 32 y de 64 bits al mismo tiempo de cualquier manera, pero conviene tenerlo en cuenta.

Conectarse al repositorio:

La primera vez que queramos establecer conexión tendremos que dar click derecho sobre la carpeta y seleccionar SVN Checkout…, en el cuadro que nos saldrá pegaremos la URL del repositorio que nos proporcionó el sistema de hosting y a continuación se nos pedirá un par de usuario/contraseña. Si le damos a “recordar” no volverá a preguntar ni pedir autorización.

Una vez aquí, si todo ha ido correctamente lo que tendremos que hacer es subir los archivos al repositorio. Para ello haremos click derecho sobre la carpeta y le daremos a “SVN Commit”. De ahí seleccionaremos archivos que no estén versionados (“show unversioned files”), seleccionaremos los que queramos y se subirán uno a uno al hosting de SVN.

Si por el contrario nuestro hosting ya estaba montado anteriormente y lo que queremos es descargar las cosas para tener las copias en local, en vez de “Commit” seleccionaremos “SVN Update” y nos descargaremos todo lo que no tengamos descargado.

Integrar con Dreamweaver:

Si utilizas Adobe Dreamweaver como entorno de desarrollo quizás lo que más te interese es tener las posibilidades de envío y recepción de archivos en la misma ventana del programa en vez de estar intercambiando con el explorador de windows para hacer las operaciones.

Dreamweaver desde la versión CS4 incluía un cliente de SVN integrado, el problema viene de que si tenemos un repositorio creado con Tortoise y luego los usamos con el cliente ese de DW no nos servirá, porque tiene una incompatibilidad documentada que Adobe contempla en su sitio web ofreciendonos un parche. Dicho parche está escrito en Python, por lo que si no tenemos instalado Python (90% de los mortales) no funcionará, además hay que tener en cuenta que la versión de Python deberá ser la de 32 bits, porque si no tampoco se iba a poder instalar el parche, debido a que DW dirá que no encuentra una instalación de Python válida.

En definitiva, es mejor olvidarse de todos estos escollos y simplemente usar una extensión para Dreamweaver llamada SubWeaver que actúa como intermediario entre Dreameaver y Tortoise. Ya es cuestión de usar los menús contextuales que nos brinda la extensión y estaremos 100% integrados con Tortoise desde Dreamweaver.

Optimizar MySQL es una tarea que debemos tener en mente desde el minuto cero al empezar a programar. A continuación os mostraré 10 consejos que pueden acelerar los accesos a vuestras tablas:

1. Usa índices:

   Seguramente lo hayas oído cientos de veces, pero al utilizar inteligentemente índices los accesos se hacen de una manera directa. Los campos que solamos incluir dentro del “WHERE” de las consultas debería tratarse de estar indexadas.

   Los accesos vía PRIMARY KEY son, con diferencia los más veloces. Si sabemos que un determinado registro no va a poderse repetir, debemos incluirle un índice UNIQUE y si vamos a realizar búsquedas sobre un campo de fecha por ejemplo, le podemos añadir un INDEX simple.

   Hay que tener en cuenta que los índices son acumulativos y se tienen en cuenta de izquierda a derecha en la definición de la estructura de la tabla. Esto quiere decir que las búsquedas estarán optimizadas en ese orden. El primer campo indexado será el primer criterio en velocidad.

2. Utilización de campos binarios

   Los tipos de dato binario son BINARY, VARBINARY y BLOB que van en consonancia con CHAR, VARCHAR y TEXT. Si el texto que vas a almacenar no va a tener una codificación como UTF-8 es mucho más conveniente utilizar campos binarios, puesto que ocupan mucho menos espacio y las comparaciones se hacen como datos numéricos internamente.

   Por ejemplo, campos que guarden cadenas codificadas como MD5, campos de permalink, nombres de usuario que sepamos que no permiten caracteres extraños, etc. pueden ser puestos como binarios y los accesos y el tamaño de la tabla será muy inferior.

3. Utiliza UNSIGNED

   Si sabes que en ese campo solamente irán números positivos, utiliza UNSIGNED. Esto aumenta al doble la capacidad máxima de los campos sin alterar el número de bytes necesarios para almacenar cada dato. Por ejemplo, todos los campos que utilicen un AUTO_INCREMENT deben utilizarlo, puesto que de la otra manera tendremos un rango enorme de números que jamás utilizaremos.

4. Guarda información redundante

   Si tienes una entidad fuerte con entidades débiles, guarda toda la información que puedas en la entidad padre sobre las entidades débiles, esto es: total de datos de cada una, máximos, mínimos y media (si se utilizarían para algo), último dato introducido, etc. Cada vez que se realice una modificación en las entidades débiles habrá que actualizar a la padre, pero si normalmente nuestra aplicación recibe más consultas que actualizaciones esto supondrá una ventaja en el rendimiento.

5. No uses tipos de datos gigantes

   Me atrevería a decir que el 99% de las personas jamás necesitarán un campo LONGTEXT a no ser que se trate de un gestor de contenidos o algo por el estilo; incluso habrá muy pocas que necesiten un campo BIGINT para uso normal. Un BIGINT ocupa cada número 8 bytes y puede almacenar un número de un 9 seguido de 18 ceros (aproximadamente). El campo LONGTEXT almacena hasta 4 billones y pico de caracteres, que pueden ser mucho más de 50 páginas de Word por ejemplo.

   Los tipos de dato exageradamente grandes ocupan por cada unidad más tamaño y rara vez se utilizan por completo. Es por eso que es más recomendable usar medidas más comedidas de datos.

6. Trata de usar los simplificadores del lenguaje

   MySQL proporciona algunas maneras que ayudan a hacer las consultas más cortas y más fáciles de entender. Estos métodos no solo nos ayudan a nosotros, sino que internamente son mucho más eficientes. Por ejemplo, usar la expresion " WHERE sorteo = 1 OR sorteo = 2 OR sorteo = 5" es mucho menos eficiente que la siguiente: " WHERE sorteo IN(1,2,5)".

   Algunas de estas expresiones pueden ser BETWEEN, IN, LEAST, GREATEST o INTERVAL.

7. Intenta unificar consultas

   Intenta siempre hacer una consulta cuando normalmente lo harías con varias. INSERT puede insertar varios registros al mismo tiempo si se separan los “VALUES” por paréntesis y comas, por ejemplo: INSERT INTO sorteo VALUES (1,23),(4,5,6),(7,8,9).

   DELETE múltiples se pueden construir en vez de en bucle insertando los valores a borrar dentro de un IN() de MySQL.

8. Evita operaciones matemáticas

   No es buena idea hacer cálculos complejos en una SELECT. Siempre que sea posible hay que traer los datos al lenguaje que utilices (PHP por ejemplo) y hacer estos cálculos. Por ejemplo, realizar redondeos, medias, divisiones y demás puede resultar problemático y hay que tener siempre en mente que cuanto menos trabajo haga la Base de Datos, más eficiente será.

9. Utiliza MyISAM si es posible

   Un denominador común en las aplicaciones web es que casi siempre se hacen más selects que inserts/updates/deletes. Si este es nuestro caso, podemos renunciar a las posibilidades relacionales que permite InnoDB para tener un gestor más rápido en las consultas.

10. Emplea frecuentemente el LIMIT

    Esto es a la vez un consejo de rendimiento y de seguridad. Si estamos seguros de que vamos a borrar un registro de la tabla, entonces podemos añadirle un LIMIT 1 al final y así nos aseguraremos que no se borrará en ninguno de los casos nada fuera de control. Esto es aplicable también para SELECTs y UPDATEs.

    Cada vez que tengas claro con cuantos registros estás trabajando, utilízalo.

En definitiva todos los puntos se refieren a que hay que tener control total de los datos que tenemos almacenados, siempre teniendo en cuenta las limitaciones y tratando de mantener una integridad de los datos.

Fuentes: MySQL Certification Study Guide, Building Scalabe Web Sites (The Flickr way).

Sortea2.com S.A.

La empresa Sortea2.com, con domicilio en C/Inexistente sin nº en Madrid, España organiza una acción promocional con el sistema de sorteo aleatorio dirigida a personas residentes en territorio español, mayores de edad.

Objetivo

Sortea2.com organiza este sorteo con el objetivo de incentivar a los usuarios a registrarse en la web de la empresa.

Periodo de la promoción

Esta acción promocional estará activa para los usuarios que se registren en nuestra web entre los días 24 de marzo y 31 de abril de 2009. El sorteo se realizará ante notario el 4 de mayo de 2009.

Mecánica y modo de participación

Para participar es necesario efectuar el registro en sortea2, desde la siguiente dirección: http://www.sortea2.com/registro

Será imprescindible rellenar todos los campos correctamente para conseguir participar. Sortea2.com se reserva el derecho a rechazar algún registro de motu propio y sin previo aviso por parecerle defectuoso. Solo se permitirá un registro por persona.

Entre todos los usuarios que se registren durante el periodo de la promoción se realizará el sorteo de un iPod Touch de 2Gb el día 4 de mayo de 2009 ante notario. El notario extraerá de la lista de participantes a un (1) ganador y a tres (3) suplentes.

En caso de que no se pueda contactar con el ganador, que rechace el premio o que en un periodo de 15 días después de comunicarle que ha resultado ganador no responda, se procederá a contactar con el segundo suplente.

Premios

El premio consiste en un iPod Touch de 2Gb valorado en 00,00€.

Comunicación al ganador

En un periodo máximo de una semana después del sorteo, se contactará con el ganador mediante correo electrónico. En caso de que no responda, se contactará con el primer suplente.

Cancelación del sorteo

El sorteo solo no se podrá cancelar, una vez iniciado el periodo de la promoción, ya se debe continuar.

Disponibilidad del premio

En caso de que el premio no se pueda entregar exactamente el mismo modelo, se procederá a regalar un premio de el mismo valor o superior. No se permitirá canjear el premio por dinero en metálico.

Publicidad

Sortea2.com se reserva el derecho a publicar el nombre de usuario del ganador con fines promocionales.

Aceptación de las bases

El mero hecho de participar en el sorteo implica que el usuario acepta totalmente las condiciones de estas bases legales.

En Madrid, a 24 de marzo de 2009

Para cualquier duda, no dudeis en insertar algún comentario y os responderemos a cualquier cuestión.

Para un sorteo así, la herramienta ideal es la página de sorteos simples. Se introduce la lista de nombres y se pulsa sortear. Con el resultado que obtengamos copiamos los nombres o imprimimos la pantalla y podemos felicitar a los vencedores.

Sorteo simple de ejemplo

Nadie verá quiénes eran los participantes ni siquiera quienes fueron los vencedores. Esta información no se almacenará en ninguna parte, con lo que el autor del sorteo puede hacer con ella lo que quiera sin preocuparse de que miradas indiscretas se enteren de que él ha sorteado algo.

Si se desea realizar un sorteo más completo, y sobre todo aprovechar la posibilidad de programar un sorteo para que se realice a una fecha y hora determinadas (lo cual es especialmente útil para tareas rutinarias, pues se pueden programar numerosos sorteos y esperar a que se vayan publicando los resultados cuando llegue esa fecha), se puede usar la herramienta de sorteos avanzados.

Sin embargo habrá quienes no quieran ver su nombre en las páginas web, quienes no quieran que se sepa que ha participado en un sorteo que no ganó. Si se quiere aprovechar la enorme utilidad de los sorteos avanzados manteniendo la privacidad, lo ideal es hacerlo usando alias o nicknames.

Por ejemplo supongamos que queremos sortear algo comprometido, digamos un jamón entre los clientes de un sex shop. Podemos usar la primera opción, de sorteos sencillos, porque nadie verá los nombres que se introduzcan. Pero también podemos hacerlo programando el sorteo, diciendo “el lunes 3 de agosto a las 21:00 horas se realizará el sorteo”. En este sorteo, en lugar de introducir los nombres de los concursantes, que tratamos de mantener en el anonimato, utilizamos por ejemplo una tabla de números:

Celestino Corbacho –> 100
Cristina Garmendia –> 200
Miguel Sebastián –> 300
Beatriz Corredor –> 400
Bibiana Aído –> 500

sorteo-avanzado-ejemplo

A los participantes les decimos con qué número participan, y le podemos quizás dar una papeleta donde se indique esto.

Y luego simplemente programamos el sorteo, con total anonimato, usando los números o el alias, en lugar de sus nombres.

Así, si algún curioso lo consulta (en la dirección del sorteo), no sabrá nada de los clientes de esta tienda, mientras que cualquiera de los participantes podrá saber si ha sido premiado o no, al mismo tiempo sabrá que el sorteo ha sido real y no que le han dado el premio al cuñado del dueño del sex-shop.

Usando sortea2 se consigue transparencia y además con toda la privacidad que uno quiera mantener.

En este artículo trataré de explicaros las técnicas que hemos utilizado para tratar de facilitarle el trabajo a Google:

Estructura

Crea un código simple y legible
No es para nada recomendable el uso de multitud de tablas anidadas unas en otras ni la utilización de marcos o cosas por el estilo. Evita siempre complicar las cosas e intenta que todo el código esté bien estructurado.

Relaciona unas páginas con otras
Trata de enlazar páginas relacionadas entre sí, porque eso es algo favorable de cara a Google. Intenta crear secciones tales como “Temas relacionados” dentro de una página o cosas por el estilo.

Enlaza a fuentes que amplien información
Siempre que sea posible, enlaza a fuentes originales o a páginas que aclaren un determinado tema. Un ejemplo corriente puede ser el enlazar a algún artículo de la wikipedia que explique algún término que utilicemos.

Uso correcto de etiquetas HTML

Usa la etiqueta apropiada en el lugar apropiado
Un ejemplo habitual puede ser el uso de las etiquetas strong en vez de b y las etiquetas em en vez de i. Estas etiquetas cumplen una de las funciones iniciales del HTML: ser descriptivas, mientras que cualquier elemento de una web puede estar en negrita (gracias a CSS), es necesario que se pueda especificar explícitamente que esa zona está resaltada por algo, no que están en negrita por ser una especie de encabezado ni nada. En resumen, intentar usar todas las etiquetas html posibles, cada una en su sitio; si hay que usar un h3 en vez de un span, mejor que mejor.

Usar tablas lo menos posible
Las tablas son un lío para Google, usarlas solamente en el caso de que sean imprescindibles.

Contenido

Haz a las imágenes descriptivas
Las imágenes son muy buenas para el posicionamiento, pero si están bien usadas. Hay que tratar de ponerles un nombre descriptivo al archivo, incluirle un atributo alt y escribirles algo en el atributo title. Hay que tener en cuenta que el Googlebot tan solo podrá leer los textos y las etiquetas, no lo que ponga en la imagen.

Añade etiquetas meta
Una de las mejores maneras de posicionar la web es añadiendole meta-tags descriptivas. Estas etiquetas se añaden dentro del head y las hay de dos tipos:

Etiqueta descripción:

<meta name='description' content='Sortea2, la herramienta para sortear. Realice sorteos entre todos los participantes que desee, puede guardarlos, programarlos, comentar los sorteos, votarlos y mucho más.'/>

Hay que escribir una descripción buena. Ojo con repetir mucho alguna palabra que eso no le gusta nada a Google.

Etiqueta tags:

<meta name='keywords' content='viaje,Estados Unidos,star wars,nocilla,marzo 2009, sorteos, sortear, to raffle, rifas, raffles, lotería, programar, participantes'/>

Aquí debes escribir algunas palabras que estén relacionadas con una página en particular o de toda la página. Si la web es dinámica (como Sortea2), es altamente recomendable crear etiquetas variables. Por ejemplo, en las páginas de sorteos, una parte de las keywords de esta etiqueta meta son las propias tags del sorteo.

Crea contenido propio
Hay que tener en cuenta que si copias y pegas texto de otras webs, evidentemente la web que creó ese contenido antes es la que va a estar delante en las búsquedas, así que es mejor ni intentarlo. Hay que crear contenido escrito por uno mismo, y en caso de tener que copiar un fragmento de texto, indicar la fuente original.

Consideraciones de compatibilidad

Tratar de pasar el W3C Validator
Una medida genial para posicionarse es hacer una web accesible a todos los navegadores. En Sortea2 ya escribimos un artículo sobre como pasar el W3C Validator.

Conseguir links externos

Conseguir links externos mejora el pagerank
El pagerank es una de las medidas que utiliza Google para determinar los resultados. Este número depende del número de links que tenga nuestra página de otras páginas.

Esta parte es la que más ayuda en el posicionamiento en buscadores, pero también es la que menos depende de uno mismo. Podemos tratar de colocar algunos links a nuestras páginas en algunos sitios, aunque en esta parte lo único que se debería hacer es crear contenido de calidad que haga que la gente te enlace por sí misma.

El principal rival que tenemos en este tema es el no follow dentro del atributo rel de los links. Esto lo que hace es decirle a los buscadores que ese link no lo tengan en cuenta a la hora de valorar esa web enlazada. Se suele utilizar en los comentarios de los blogs para que la gente no haga spam.

Este servicio puede validar HTML indicando la URL de la web, subiendo un archivo .html o escribiendo el HTML directamente.

Pasar correctamente estas validaciones y por consiguiente conseguir el logo de “W3C validator” es bastante complicado, sobre todo en el caso de intentar pasar este test una vez finalizada la parte de desarrollo en la página web; a nosotros nos sucedió ese problema: tratamos de solucionar la mayor parte de problemas de compatibilidad posibles, pero no fue posible en todos los casos.

A priori puede parecer que, mientras la página funcione y se vea más o menos bien en la mayoría de los navegadores, es suficiente; pero no deberíamos conformarnos con esto porque el principal motivo para esforzarse en este tema es que Google indexa mejor páginas que sean W3C compatible, esto es debido a que para el robot de Google le es más fácil leer nuestra web, por lo que obtendríamos mejores resultados en las búsquedas de Google.

A continuación voy a detallarle las cosas que suelen dar errores y que hay que tratar de evitar porque dan problemas con el validador de W3C:

Dejarse etiquetas sin cerrar:
Esto puede parecer obvio, pero no lo es tanto. A veces se nos puede olvidar cerrar un div, es normal, y este validador nos lo indicará.
Pero hay casos en los que hay que cerrar las etiquetas aunque no haga falta, por ejemplo, en el caso de utilizar XHTML, las etiquetas img deben terminar con />, las etiquetas meta , link, input, etc. necesitan ser cerradas de manera explícita.
Otro caso es el de las etiquetas que aparentemente no es necesario cerrar, sino que el navegador sobreentiende que ya han finalizado. Este es el caso, por ejemplo de las etiquetas <option> y <li> no son imprescindibles de cerrar, porque cuando empieza la siguiente etiqueta de este tipo ya se sobreentiende que se han cerrado. Esta práctica no cumple con los estándares, por lo que deberíamos evitarla.

Uso excesivo de tablas
Este es un problema dificil de diagnosticar, puesto que el validador nos mostrará un montón de errores cuando una página tiene muchas tablas. Para que las tablas sean compatibles, tienen que estar compuestas de la siguiente manera: <table><tbody><tr><td>, en caso de que el tbody se nos olvide o algo, ya nos dará error.
El consejo sería evitar el uso de las tablas, aunque, como a veces es inevitable, se pueden o bien ignorar los errores, o tratar de usar todas las etiquetas necesarias.

Elementos que están donde no deben
Este problema es típico cuando se define unos estilos dentro del body o cuando se tratan de usar etiquetas meta dentro del body. También da error en caso de introducir una etiqueta que dibuje algo en la pantalla dentro del head.
Estos errores son habitualmente fáciles de solucionar, aunque hay veces que hay problemas inevitables. Se trata de situar cada elemento en su sitio y ya está; si nos es imprescindible que un elemento esté fuera del sitio, tampoco nos tenemos que obsesionar.

Atributos que una etiqueta no tiene
Este tipo de errores se suele dar en páginas en las que se aplica Javascript, como nos es necesario acceder a los elementos de la página a través de atributos id, name, class, etc., a veces podemos tener el caso de que nos hagan falta más atributos o algo así.
Un caso puede ser tener un elemento <td> en el que hemos aplicado un atributo id para ponerle estilo CSS, si este id se repite (más adelante veremos que esto también da problemas), entonces tenemos que tener otro atributo que se refiera a este elemento td. Una posible solución es usar un atributo name, esta práctica no es muy recomendable, puesto que da errores de compatibilidad; siempre hay que tratar de usar un atributo id y que sea único.
El atributo name se debería utilizar solo para formularios y para anclas.

Problemas con IDs
Un ID es un identificador único, por lo tanto, se debe utilizar tan solo para una etiqueta hml. En caso de usarlo para aplicar un estilo CSS, se debe tener en cuenta que si ese estilo solo se va a usar en una etiqueta de la misma página, entonces si se puede usar un ID; en caso de tener que reutilizar el mismo estilo varias veces en el mismo documento, entonces hay que usar una class.
Los IDs no pueden empezar por un número sino que deben empezar por una letra o un guión bajo o similar. Esto puede suponer un problema cuando, para aplicar Javascript nos es necesario aplicar un ID a un elemento que sea su número identificador; por ejemplo, en la pantalla de lista de sorteos cada sorteo tiene en el botón de borrar sorteo asignado un id que es el número de sorteo. En nuestro caso nos es imprescindible, puesto que así se facilitan mucho las operaciones internas; podríamos haber evitado esta práctica, aunque no lo hemos visto necesario.
En resumen, que se evite empezar por un número, aunque tampoco tiene que ser algo que complique mucho la programación interna en Javascript o PHP.

Resumen
Concluyendo, hay que tratar de pasar el W3C validator aunque tampoco debe ser una obsesión que haga que pongamos todos nuestros recursos en pasar con éxito. Es más importante saber como evitar los errores que saber cómo arreglarlos; esto es debido a que a veces es tan avanzada la programación interna, que es muy complicado modificarla a posteriori para que se tomen en cuenta los cambios.

En sortea2 hemos tratado de pasar el W3C validator, aunque en la mayoría de las páginas no nos ha sido posible. Lo importante es saber qué técnicas evitar a la hora de programar y es por eso por lo que os escribo este artículo.

¿crees que faltan errores de compatibilidad comunes? comunícanoslo a través de los comentarios.

Este problema lo tuvimos en la pantalla de sorteos simples, queríamos que los usuarios sin javascript pudieran explotar todas las posibilidades de nuestro sistema para sortear. Para ello, creamos una página alternativa a esta, la de sorteos simples sin javascript. Como vemos, visualmente es practicamente idéntica, pero a la hora de darle al botón de ¡sortear! el resultado necesita que la página se actualice.

Bien, ya teníamos las dos páginas, pero ¿cómo hacer que la gente que no tenga javascript sepa facilmente que hay otra página que hace exactamente lo mismo y que sí le funciona?. La solución que pensamos que era la más fácil era usando la clásica etiqueta de <noscript></noscript>. Esta etiqueta lo que hace es ejecutar lo que haya dentro en el caso de no tener javascript. Entonces lo que había que hacer era que lo que hubiera dentro fuera una instrucción que redireccionara la página a otra.

La instrucción es una etiqueta meta, la siguiente:

Más tarde veremos por qué en el atributo URL ponemos una variable de javascript, pero si unicamente necesitas redireccionar una página, puedes poner directamente la página a la que quieres que se redireccione.

Con este código ya podría funcionar todo correctamente, aunque nosotros tuvimos que ir más allá, porque hicimos una función que, entre otras cosas, miraba que página quería ser redireccionada y la redireccionaba donde debía.

Un fragmento de la función sería este:

A esta función se la llama con el parámetro $noscript, y ya hace lo que predeterminadamente hemos programado.

En nuestro caso, necesitábamos que las páginas de registro, de login y de sorteos avanzados fueran a una página auxiliar, porque no habíamos creado ninguna página que hiciera su misma función pero sin javascript, en estas páginas lo que se hace es informar al usuario de que no puede utilizar esas funciones. Puede que en el futuro habilitemos estas páginas para este tipo de usuarios.

Internet Explorer tiene una manera de entender CSS muy “peculiar” que  hace que todos los diseñadores web tengan que dedicar gran parte de su tiempo en hacer que su proyecto funcione particularmente en Internet Explorer. Esto es una gran pérdida de tiempo y puede que de dinero, pero que no hay más remedio que afrontar, por esto:

Hay que preocuparse por el volumen de visitas que van a llegar al website por parte de Internet Explorer, porque es tal que no se puede despreciar.

Caso particular

Particularmente, en Sortea2, nuestra página de sorteos, también tuvimos que lidiar con estos problemas, tuvimos que tomar medidas porque la página, que se visualizaba correctamente en firefox, opera, etc., era impresentable en Explorer, las cosas normalmente se montaban unas encima de otras y tal.

Qué cosas dan problemas

Tras haber terminado el diseño de Sortea2, he llegado a la conclusión de que estas cosas son las que dan problemas:

1. Listas.
2. Márgenes negativos para posicionar.
3. Posicionamiento normal.
4. Desbordamiento de divs.
5. Imágenes de fondo.

1.  Las listas es lo que habitualmente más problemas da, cuando quieres formatearlas con padding y margin suelen tratar las cosas de diferente manera que los navegadores normales. Por ejemplo, no puedes variar el valor de margin-left en las listas para que estén alineadas a la izquierda con tan solo poner: “margin-left:0px;”.
También suelen dar problemas las listas que se colocan a lo ancho (float:left;), hay que ir probando con qué valores funcionan bien. Por ejemplo, en nuestro menú horizontal, el valor float:left; había que ponerlo en #menu_horizontal li a {} para que funcionase, mientras que en otros lugares se podía colocar directamente en #menu_horizontal li {}.

2. Los márgenes negativos no sé exactamente por qué dan tantos problemas. A veces funcionan, otras veces no, y otras veces hay que poner valores distintos a lo habitual para que se coloque en el lugar que se desea. El mejor ejemplo es en la parte de arriba de sortea2, en la que se ve una diferencia de colocación entre cualquier navegador y Internet Explorer, esto es debido a que a veces los márgenes negativos no funcionaban y tuvimos que intentar colocar las cosas con otros valores.

3. El posicionamiento normal, con “position:relative y absolute” no suele dar muchos quebraderos de cabeza, simplemente algunas veces hay que cambiar los valores un poco para que las cosas cuadren.

4. El desbordamiento de divs tiene su “particularidades” en Internet Explorer cuando se quiere hacer “overflow”. Normalmente al desbordarlo suele tener después un tamaño extraño que cuesta colocar. Esto nos pasó con el div #resultado, que se despliega en la pantalla de sorteos simples al hacer un sorteo, en firefox funciona perfectamente, pero en internet explorer se ve como se contrae un poco cuando la lista de ganadores es demasiado grande y hace que salga el scroll en el div.

5. Las imágenes de fondo se suelen colocar correctamente y tal, el problema es el orden en que se cargan. Por ejemplo, al principio, en las pestañas que se utilizan cuando se utiliza el buscador o en la pantalla de Mis Sorteos, utilizábamos un hover que consistía en otra imagen, Bien, pues firefox y opera cargaban esa imagen antes de que terminara de cargar la página, por lo que el efecto se hacía correctamente; el problema lo daba Internet Explorer, porque se cargaba la imagen en el momento en que se hacía el hover, con lo que había que esperar un tiempo para ver el efecto. Fue tan desastroso el resultado que optamos por subrayar esos links al pasar por encima y listo, de camino lo dejamos igual para ambos navegadores.

Soluciones

La solución por la que optamos nosotros fue:

• Una hoja de estilos común, en la que las propiedades que funcionasen en ambas estuvieran recogidas.
• Una hoja de estilos para Internet Explorer, con todas las correcciones posibles para que se mostrase bien la página.
• Una hoja de estilos para los demás navegadores. Para evitar que unas propiedades se pisaran a otras, optamos por poner en una hoja de estilos independiente todas las propiedades que daban problemas en Explorer, pero con los valores que serían normales.

Ahora bien, ¿cómo sabemos qué navegador está mostrando la página y por lo tanto qué hoja de estilo abrir?
Bien, nuestra página está hecha con PHP, por lo que os voy a mostrar un método para hacerlo con este lenguaje (también se podría hacer con javascript).

Abrir una hoja u otra dependiendo del navegador

Bien, PHP recibe por parte del navegador una serie de variables de servidor (idioma, navegador, versión de este último, etc.), pues tenemos que recoger lo que diga la variable que dice qué navegador está mostrando la página:

$idnavegador = $_SERVER['HTTP_USER_AGENT'];

Esto es lo que obtendríamos de firefox:
Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5

Y esto es lo que nos devuelve Internet Explorer:
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; InfoPath.2; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)

Debe haber alguna manera universal que distinga ambos códigos, porque Internet Explorer da problemas igualmente en su versión 6 como en su versión 7.
Bueno, pues vamos a buscar las diferencias entre ambas cadenas para ver qué podemos sacar que nos diga que estamos en Explorer.

En Mozilla/X.0 no se puede sacar mucho, la verdad, porque es casi idéntico y con PHP no se podría hacer un cálculo. Pero si nos metemos dentro del paréntesis  empezamos a ver cosas interesantes, y ya si nos metemos en ver que hay después del punto y coma, ya lo tenemos.

Uno nos devuelve una U y otro nos dice MSIE X.XX, ahí está la diferencia; pero queremos detectar cualquier explorer, no una versión determinada; bien, pues recoges la palabra MSIE y listo, con un parseo veremos que se puede hacer fácilmente:

Es cierto que puede ser un poco lioso, pero es simple: se busca el punto y coma, se coge lo que hay después de él, y luego se cogen 5 caracteres (con 4 recuerdo que dio problemas una vez) de lo que se haya sacado. Con esto ya tenemos esto: “MSIE “, ¡era lo que queríamos!, bueno, pues ahora con un if abrimos una hoja u otra y ya está todo listo.

Ya está, ahora ponemos las propiedades que dan problemas en ie-hacks y ya solo se verán en ese navegador.

Conclusión

Internet Explorer es un navegador problemático y tenemos que poner nuestros medios para hacer que esos problemas desaparezcan porque tiene una cuota de mercado espectacular y merece la pena dedicarle tiempo.
Puede que nuestro método de obtención del navegador no sea precisamente la mejor y la más simple, pero lo cierto es que funciona y que jamás ha dado ningún problema.

Consejo final

Como consejo final te diré que cada vez que hagas algún cambio relativamente importante en tu web, si no eres un asiduo a Internet Explorer, que la pruebes ahí antes de seguir con otra cosa, porque luego volver atrás para resolver problemas antiguos es muy molesto.

Cuando se utiliza Jquery una de las mayores ventajas que se esgrimen es la existencia de innumerables plugins, a cual más útil. Y es verdad. Pero también es complicado adaptarse a cada uno de ellos. Cada programador tiene sus manías, sus ideas propias, su forma de hacer las cosas diferente. El uso de plugins tomados cada uno de un sitio, creados por programadores diferentes, da una absoluta falta de homogeneidad en el código.

Si uno se acostumbra a copiar trozos de código de aquí y de allí, es un script kiddie, un niñato que no sabe programar, sólo mal reutilizar.

Pero ante la ingente cantidad de herramientas tecnológicas, cada una con sus peculiaridades, se debe elegir entre eso o luchar vanamente por tratar de conocer un lenguaje para que pocos días después surja uno nuevo y también imprescindible. Por eso creo que es justificable el copypasteo de código ajeno, aunque a veces obtengamos resultados poco coherentes. Pero operativos.

Siempre luchando por entender las peculiaridades de cada uno de los plugins, a veces uno se frustra al ver que no hay forma de hacer funcionar uno en particular. Esto no se suele comentar mucho, porque se mira la página del desarrollador, con la demo operativa, se da plamas, se guarda el link y luego cae en el más oscuro de los olvidos, sin pensar la utilidad de aquello.

Por eso si vas a desarrollar un plugin para Jquery, te recomendaría en que emplearas el máximo tiempo posible en tener una demo que funcione, con diseño excelente. Que luego el plugin sea operativo o no, es lo de menos porque no se va a usar tanto como parece.

En fin, que paso a detallar los plugins que hemos usado en Sortea2.com, y cuales no y por qué. No trata de ser una lista de “mejores plugins”, sino simplemente de plugins que han funcionado.

1. Calendario.

Hemos empleado el plugin datePicker.
Su funcionamiento no es muy complejo de configurar y el resultado es sencillo, admitiendo días y fechas en castellano.
Lo tenemos en la ventana de sorteos programados, para ver la fecha en que se programa un sorteo.

Por contra, aunque existen varios plugins para seleccionar la hora que nos podían haber servido en esa misma página, tras probar con varios siempre obtuvimos resultados poco satisfactorios. No dudo que el plugin funcione, pero para nuestro caso no servía. Y no pedíamos nada especial, simplemente un selector de fechas.

Tanto este TimePicker, com este otro timepicker llegaron a funcionar, pero la hora no había forma de ajustarla al control indicado, siempre aparecía en la parte de abajo de la página. También existe un tercer plugin para seleccionar horas, pero ya es suficiente por el momento.

Seguramente la causa no era otra que algún tag de html mal cerrado por nuestra parte, o una mala configuración de las propiedades. El caso es que tras mucho tiempo perdido, decidimos descartarlo definitivamente.

Preparar un selector de horas y minutos es trivial, ni siquiera hace falta javascript, por lo que al final tomamos ese camino, con el resultado que podéis ver en la página de sorteos avanzados.

Quizás falte coherencia en el diseño entre la selección de fecha y hora. Es algo que podemos mejorar con el tiempo.

2. Cookie.

El que hayamos usado un plugin para manejar las cookies lo veo más como un error y un síntoma de la paranoia que hay en torno al uso de los plugins. Hasta para la tarea más sencilla se buscan utilidades hechas por otros. Creo que si hubiéramos usado javascript puro y duro, habríamos necesitado menos código que con este plugin. Pero al menos permite el uso sencillo de cookies.

En la aplicación tenemos dos cookies, una para controlar el idioma con el que se accede a la página y otra para gestionar las identidades de los usuarios.

El plugin al que me refiero es este.

3. Subida de ficheros mediante Ajax.

Una de las peores ideas que tuvimos al desarrollar la página fue permitir el subir un listado de nombres cargándolo desde un fichero. Es una de estas funcionalidades que consumen mucho tiempo de desarrollo y que luego nadie usa. O peor aún, nadie usa para bien porque son una puerta abierta a las vulnerabilidades.

Al final la hicimos. También en la ventana de sorteos avanzados, se puede cargar una lista de nombres de un fichero, idealmente un .txt en que cada nombre ocupa una línea.

De nuevo aquí tiramos de un plugin que permite hacer una subida de fichero en forma totalmente asíncrona, sin tener que recargar la página y sin causar problemas.

Este es el plugin para subir ficheros con Jquery. Causó numerosos problemas conseguir adaptarlo al funcionamiento de la página, en gran parte porque fue una de las primeras tareas desempeñadas, cuando aún estábamos iniciándonos con el Jquery.

La idea inicial y algo que llegamos a hacer era mostrar la lista de nombres en un espacio dentro de la ventana, para que el usuario pueda ver quiénes participarán en el sorteo. Pero con el tiempo se nos fue acabando el sitio en la ventana y ya era todo muy complicado. Costó quitar una funcionalidad que ya estaba hecha, pero era necesaria una mayor simplicidad.

4. Livequery.

Livequery es posiblemente el plugin más útil de todos los que hemos empleado.

Nuestro problema es que cuando creábamos controles dinámicamente (como las listas de nombres y la de premios, que se amplian conforme el usuario va añadiendo más) era complicado hacer que estos controles heredaran los eventos de los controles iniciales en la página.

La tarea de añadir un listener a los eventos para nuevos controles era un motivo de quebraderos de cabeza. Y sin embargo con usar livequery esto se solucionó automáticamente.

Además fue el plugin más sencillo de implementar, pues es casi trivial. ¡Estamos enamorados de Livequery!

5. Dynacloud.

También tenemos una nube de etiquetas, como toda aplicación que quiera parecer 2.0. Y para ello lo primero era buscar el plugin correspondiente. En este caso, Dynacloud, para hacer una nube de tags.

Pues bien, no conseguimos hacerlo funcionar en la forma en que nos hubiera gustado. De nuevo mil historias, y cuando lográbamos que apareciera algo, estaba fuera de formato o al final de la página. Hicimos la funcionalidad desde cero, no es nada difícil.

6. Sugerir tag.

Finalmente, un plugin para sugerir un tag cuando estás escribiendo un nuevo sorteo. Como se hace en delicious, cuando introduces las primeras letras realiza una consulta y obtiene tags similares ya empleados para crear mayor uniformidad en la información.

No sin algo de sufrimiento, también se pudo poner en marcha con un resultado que consideramos muy bueno.

Como se hacen consultas continuas al servidor, para cada uno de los caracteres, en orden a aliviar la carga sobre la base de datos, optamos por cargar todos los tags en un fichero. De esta forma, no se realiza ninguna consulta a base de datos, simplemente se abre el fichero, se vuelca directamente sobre un array y se buscan las coincidencias.

Este fichero de tags se va actualizando cada cierto tiempo mediante una tarea y santas pascuas. Nos libramos de tener que estar machacando la base de datos realizando consultas poco eficientes (el “like” en SQL no es lo más rápido y directo que digamos).

Como resumen, espero que esta entrada le sirva a alguien de ayuda para ver cómo los plugins te solucionan problemas y ahorran tiempo, pero a veces pierdes mucho tiempo sin poder hacerlos funcionar y otras es más eficaz codificar uno mismo la tarea que necesita.
También puedes ver plugins que a lo mejor no son muy espectaculares, pero son operativos y necesarios para el funcionamiento de una página.

Cuando escribimos nuestra página de sorteos consideramos que sería útil que los usuarios pudieran realizar un sorteo a una fecha y hora determinadas. Por si desean darle un poco de emoción o dar claridad a un sorteo. No es lo mismo que tú publiques unos resultados sino que digas “en esta página ofrecerán los resultados”. Es una forma de mostrar que no influyes en el resultado.

Al querer realizar los sorteos a una hora concreta detectamos que era problemática la situación de cara a los usuarios que no usasen la misma zona horaria que nosotros (que es la de España). Una solución sería dar todas las fechas con nuestro horario. Es exigir a los clientes que se adapten a nuestras condiciones. Aunque hay muchos que optan por ella, me parece inadmisible.

Nuestra primera idea fue la de mostrar un desplegable con zonas horarias, mediante una función sencilla:
Se muestra una zona horaria e internamente se guarda un valor numérico: el número de horas de diferencia respecto de la hora de Madrid.

Lisboa(-1)
Madrid(0)
Canarias(-1)
Nueva York(-6)
México DF (-7)

Esta aproximación es una de las más frecuentes. Es sencilla y fácil de tratar. Cuando un usuario de México solicita que su sorteo sea a las 13:00 horas, convertimos el horario al de España (sumamos 7 horas) y lo guardamos (20:00 horas). Luego cuando ese usuario decida consultar el sorteo, volvemos a realizar la conversión inversa, restando siete horas.

Sin embargo la vida no es tan fácil. Quizás el mayor de los problemas es la maligna DST (Daylight Saving Time, Horario de verano en castellano).

Porque cuando nos acercamos a estos días en que se suma o resta una hora, los resultados pueden ser impredecibles.

a) Hay países que no cambian nunca de horario (sabia decisión). Entonces respecto a ellos habrá veces que España tenga X horas de diferencia y el resto del año X +1 horas.

b) Hay países que cambian de horario en fechas diferentes, como sucede con Estados Unidos. No se puede ignorar a Estados Unidos, que tiene más usuarios de castellano que la propia España.
Estados Unidos es aún más complejo por cuanto las elecciones presidenciales pueden cambiar la fecha en que se realice el cambio de hora. Además, tiene potestad para realizar cambios en el día seleccionado para la modificación horaria, sabemos cuando cambiarán el año que viene, pero dentro de tres años puede cambiar de sistema (ya lo han hecho varias veces). Vamos, que es todo un caso a tratar por separado.

c) Hay países que incluso cambian la regla. Muchos países decidieron dejar de cambiar de hora hace algún tiempo. De cara al futuro no es problemático pero si queremos hacer una correcta conversión de fechas, su situación debe ser tenida en cuenta.

d) Hay países que no tienen zonas horarias exactas. Ya sea porque tengan diferencias de cuarto de hora respecto de una zona (como Nepal, +5:45) o Venezuela (-4:30). Además, el caso de Venezuela, en que dicho cambio de zona horaria es muy actual, es problemático para fechas del pasado reciente.

Por todas estas razones, el método de sumar o restar horas, sencillamente no sirve.

Zonas horarias y PHP

Para nuestro caso, al estar desarrollada la página con PHP, tras buscar soluciones posibles por Internet, sin mucho éxito y tratando de hacer alguna cosa bien, optamos por mirar algunas funciones propias de PHP.

Las funciones propias de PHP para zonas horarias en la versión actual (4.4) son las siguientes:

# timezone_abbreviations_list
# timezone_identifiers_list
# timezone_name_from_abbr
# timezone_name_get
# timezone_offset_get
# timezone_open
# timezone_transitions_get

No creemos que sea necesario dar una enumeración de las mismas, máxime cuando se puede consultar la completa documentación online. Lo importante es saber que la forma en que PHP guarda las zonas horarias. Aunque hay posibles conversiones de texto (siempre más fáciles si el texto está en inglés), lo suyo es usar los pares Continente/País que presenta PHP en su lista de zonas horarias soportadas.

Por ejemplo:

Europe/Madrid
America/Mexico_City
America/Buenos_Aires
Atlantic/Canary

La lista de zonas horarias admitidas es extensísima. En muchos casos estas zonas horarias son idénticas, como sucede con Madrid, Berlín o París. De ahí que no tenga mucho sentido mostrar desplegables casi infinitos en sus posibilidades (sólo para la Antártida PHP soporta ¡Ocho zonas horarias!).

Se realiza una selección de países y ciudades representativas. Lo ideal es mostrar junto a dicha ciudad la zona horaria correspondiente para que así un usuario de un lugar recóndito pueda localizar la zona que mejor se adapte a su ubicación:

Buenos Aires (GMT -3)

La Paz (GMT -4)
Caracas (GMT -4.5)
Montreal (GMT -5)

Desplegable zonas horarias

Por lo tanto, trabajamos con tres valores:

a) El código de zona horaria de PHP: America/Buenos_Aires
b) La descripción para seres humanos de dicha zona: Buenos Aires
c) Un indicativo para usuarios que no encajen exactamente con dicho país: GMT -3

Esto ya sugiere que crear una tabla donde se guarde la información de las zonas horarias puede ser de gran ayuda.

Si te interesa la que usamos en nuestra página, puedes descargártela de aquí, en formato de creación para MySQL (fácilmente adaptable a otras bases de datos).

Zonas horarias. ¿Qué convertimos?

Antes de continuar una buena tarea sobre la que meditar es cómo vamos a guardar las fechas y horas en nuestra base de datos. Si nos centramos en la ciudad en que vivimos, nos podemos encontrar con que el servidor que alberga nuestra página esté ubicado en otra zona horaria. Cierto es que a veces podemos manipular esta hora, pero en hostings compartidos, a veces esto no es posible.

Así, uno puede encontrase con que:

a) Su zona horaria es de Madrid, España.
b) Quiere guardar una fecha y hora de Canarias, España.
c) El servidor está situado en Los Ángeles, Estados Unidos.

Con lo cual los problemas están casi garantizados.

Tampoco hay que volverse loco ante las diferencias de fechas. Salvo que tengas una situación tan especial como la nuestra, en que necesitamos programar tareas futuras, quizás puedas sobrevivir sin problemas y sin saber nada de todo esto. Pero el conocimiento siempre es útil.

En las tablas de datos es común guardar un registro con la fecha y hora de la última modificación. ¿Debemos convertir esa fecha y hora?

Pues salvo que sean tareas críticas, probablemente no. Las fechas de creación de registro bien se pueden quedar en el horario que tenga el servidor. Sólo aquellas que requieran de ser mostradas en pantalla pueden y deben ser tratadas con mayor consideración. En el caso de sortea2.com, las horas a las que se programan los sorteos. Para ellas no sólo se guardará la fecha y hora, sino también la zona horaria en que se realizaron.

Por lo tanto, por sentido común, no es muy lógico guardarlas en una horario tan poco estándar como el de Madrid. Hay dos opciones principales:

Guardar la hora y decir “son las 14:30 con el horario de Buenos Aires”.
Convertirla al estandar GMT (Hora de Greenwich, Inglaterra) e indicar la zona horaria deseada. “son las 16:30, zona horaria preferida Buenos Aires”.

Esta segunda opción nos parece mejor porque permite en un momento dado comparar fechas de inmediato. Del otro modo casi siempre habrá que hacer una conversión antes de poder continuar.

Como resumen: se guardan las horas en estandar GMT, sólo en los casos en que no sean necesarias manipulaciones posteriores.

Zonas horarias y PHP. Las transiciones.

Tras planear el desarrollo de la página, sólo queda un problema: cómo convertir entre dos zonas horarias dadas. No sé cómo lo habrán desarrollado en otros lenguajes de programación, pero en PHP el método es realmente ingenioso y complicado.

Vaya por delante que en internet hay numerosas clases realizadas por otros que explican cómo realizar estos cambios. Hay incluso clases hechas en PEAR que se supone son totalmente estándar. Tras la nefasta experiencia de usar una de ellas y descubrir que estaba mal (no distinguía los cambios de hora), decidí seguir el camino difícil y propio.

Siempre es más fácil usar algo ya hecho y que funcione. Y uno puede vivir dignamente sin conocer las transiciones de PHP.

Pero si quieres continuar, las transiciones son un array de fechas correspondiente a cada una de las zonas horarias. Es un array monstruoso en que se muestran los días del año en que se produce un cambio de hora para dicha zona horaria. Por ejemplo, para la zona horaria Europe/Madrid dice:

( [0] => Array ( [ts] => -1661734800 [time] => 1917-05-05T23:00:00+0000 [offset] => 3600 [isdst] => 1 [abbr] => WEST )

Que traducido al cristiano es algo así como:

• A la fecha y hora UNIX (segundos desde el 1 de enero de 1970) (correspondiente a GMT, hora estandar de Greenwich) es la de -1661734800).
• Que se corresponde con la fecha y hora “en inglés” de 1917-05-05 23:00:00+0000.
• Se produjo un cambio de hora que deja a la hora de Madrid respecto de la de GMT en 3600 segundos (una hora más).
• Dejando la zona horaria en GMT+1.
• Quedando en la zona horaria la WEST.

El listado de transiciones de la zona horaria de Madrid nos avisa de cada cambio de hora que se ha producido en la historia, desde el verano de 1917 hasta el año 2037. Si se necesita tratar fechas anteriores o posteriores, aparte de considerar la opción del suicidio, habría que tirar de enciclopedias y realizar un tedioso trabajo manual.

Este extensísimo array es la pieza fundamental para realizar conversiones entre zonas horarias en PHP.

Veamos por ahora cómo obtener el fichero de transiciones para una zona horaria:

$timezone = “Europe/Madrid”;
$timezoneinfo = new DateTimeZone($timezone);
$arraytime = $timezoneinfo->getTransitions();

En la primera línea definimos la zona horaria a tratar, según las zonas horarias que PHP entiende.

En la segunda creamos un objeto de tipo zona horaria, relativo a dicha zona inicial.

En la tercera obtenemos las transiciones: cuándo se produjeron los cambios de hora respecto de GMT para esa zona horaria.

Es curioso ver el fichero de transiciones. Ahora solemos cambiar de hora los sábados de 2:00 am a 3:00 am, pero en 1917 decidieron hacerlo a las 0:00 horas. Se nota que se trasnochaba menos por aquel entonces. Durante la II Guerra Mundial hubo cambios de hora a las 11:00 de la noche. Luego se volvió a las 12:00 y en los ochenta se pasó a hacerlo a la 1:00 am.

Como podemos ver, y evitemos dispersarnos, los cambios de hora son una verdadera pesadilla en lo que al horario de verano se refiere.

Con el array de transiciones ya es más o menos fácil. Si tenemos una fecha en formato GMT, junto con una zona horaria deseada y deseamos convertirla a la hora propiamente dicha, basta con:

Tomamos la hora en GMT y recorremos el array de transiciones, hasta que encontramos una hora superior a la nuestra.
Por ejemplo, si tenemos las 20:00 del 15 de Enero de 2012, y el horario deseado es el de Madrid, vemos que el último cambio de horas se produce el 30 de octubre del 2011. Y que entonces España tendrá una hora más que la hora GMT. Esto sucederá así hasta el 25 de Marzo del 2012, por lo que efectivamente, si queremos convertir esa hora en GMT a hora de Madrid, debemos sumarle una hora (3600 segundos) más.

[110] => Array ( [ts] => 1319936400 [time] => 2011-10-30T01:00:00+0000 [offset] => 3600 [isdst] => [abbr] => CET )
[111] => Array ( [ts] => 1332637200 [time] => 2012-03-25T01:00:00+0000 [offset] => 7200 [isdst] => 1 [abbr] => CEST )

Este proceso es mucho más delicado si la hora está en el mismo borde del cambio de hora. Por ejemplo, si queremos convertir las 01:00 horas del 25 de marzo de 2012, de horario GMT al horario de Madrid.

Para afinar completamente la regla es la siguiente:

• Partimos de una hora.
• Recorremos las transiciones hasta pasarnos de dicha hora.
• Miramos el registro anterior. Obtenemos la diferencia de segundos.
• Se la sumamos a la hora que teníamos. Si nos hemos pasado de la siguiente transición, tomamos esa siguiente, sino (lo habitual) nos quedamos con la que teníamos.

La verdad es que esto se entiende mejor con el código que escrito con palabras:

Nos recorremos el array de transiciones. Cuando la transición + las horas de diferencia sean mayores que nuestra fecha de partida, quiere decir que hemos llegado y es el momento de tomar ese valor, sumarlo a la fecha que teníamos y voilá, ya hemos convertido la fecha.

Zonas horarias y PHP. Funciones de conversión.

Básicamente ya hemos expuesto todo el proceso. Lo único necesario son dos funciones: una que parta de una zona horaria y una hora expresada en dicha zona horaria y la transforme en GMT y otra que partiendo de una hora en GMT y una zona horaria, realice la transformación inversa.

Pueden servir las dos siguientes funciones:

Las horas siempre se expresan en horario UNIX. ¡Bastante quebradero de cabeza dan las zonas horarias para sufrir aún más con los formatos locales de fecha y hora!

Creo que ha quedado todo bien expresado pero si tienes alguna duda o aclaración déjala en los comentarios. Las correcciones también son bienvenidas.