Informática para tod@s

Cerramos

Compartir:

Internet Explorer 8: problemas en clase

Compartir:

El nuevo IE8 lleva unos días disponible en su versión definitiva, y, en la mejor tradición de los navegadores de Microsoft, ya nos está dando quebraderos de cabeza a los diseñadores y desarrolladores web.

Ésta es la página web de Público (www.publico.es) vista en algunos navegadores:

Mozilla Firefox	Opera	Apple Safari
Google Chrome	Konqueror	MS Internet Explorer 6

Como pueden ver, la “cajita” con las previsiones metereológicas se ve bien, tres elementos que internamente son una lista que se crea dinámicamente con JavaScript y a los que se les ha dado estilo con CSS, alineándolos usando la propiedad float y eliminando el “bolo” que suelen tener las listas por defecto.

Todos los navegadores en los que hemos probado hasta ahora muestran este módulo correctamente, incluido el vetusto Internet Explorer 6.

Al probar la página en el nuevo IE8, nos hemos llevado una pequeña sorpresa:

La caja en las que se muestran las previsiones meteorológicas es como si no entendiese los estilos: los elementos de la lista no se muestran alineados horizontalmente y cada uno de ellos muestra el “bolo” típico de las listas. Podría pensarse que es un problema de los diseñadores, que no han sabido maquetar estos elementos correctamente, pero las reglas que han aplicado en este módulo son correctas.

Sin embargo, si activamos el botón de “Vista de compatibilidad“, la página se muestra correctamente, como con los demás navegadores, incluido el predecesor, IE7.

Según la página web de Microsoft, “no todos los sitios web están preparados para IE8″ — el original es éste:

“Internet Explorer 8 is a new release and some websites may not yet be ready for Internet Explorer 8″.

Tras una breve investigación, al final Rodrigo y Daniel encontraron el problema: IE8 parece que tiene algunas incompatibilidades con una de las librerías de JavaScript más usadas (Prototype), el atributo HTML “class” y la propiedad DOM “className“.
Los demás navegadores trabajan bien con el mismo código JavaScript, IE8 no. ¿Quién lo está haciendo bien y quién lo está haciendo mal?

Hasta ahora teníamos que hacer los desarrollos y diseños con tres navegadores: IE6, IE7 y el  resto de navegadores. Ahora tendremos que incorporar otro. Por fortuna, ya hay trucos para forzar a IE8 para que se comporte como su antecesor.

Las elecciones desde el punto de vista informático

Compartir:

Pasada la resaca electoral, les voy a contar un poco por encima cómo trabajamos y lo que hacemos cuando hay elecciones.

Lo habitual es contactar unas semanas antes con el organismo responsable y solicitar una acreditación. En las elecciones que hemos cubierto hasta ahora (Generales 2009, Galicia y País Vasco 2009) el mecanismo ha sido similar: el organismo nos facilita una página web de acceso restringido desde la cual podemos descargar los ficheros con los datos de los recuentos.

Por lo general, antes del día “D” se ofrece una simulación con datos de prueba para que los medios podamos comprobar que nuestros desarrollos funcionan.

El formato de los datos no es estándar, cada organismo ofrece el que mejor le parece. En las pasadas elecciones generales se nos ofrecían un fichero de texto (comprimido) con los datos del recuento a nivel estatal, autonómico y provincial y otro conjunto de ficheros (también comprimidos) con el desglose del recuento por municipios.

Con antelación se nos facilitó la documentación sobre el formato de estos ficheros (por ejemplo: campo 1, tres posiciones, código del municipio; campo 2, dos posiciones, provincia; ….; campo n, código del partido, campo n+1, votos, …)

Por fortuna, en las elecciones gallegas han utilizado un sistema informático similar, que emitía ficheros de datos muy parecidos, así que gran parte del trabajo ya lo teníamos hecho. Variaba la forma de desglosar: a nivel autonómico, provincial, comarcal y por municipios.

El Gobierno Vasco facilitaba los datos en un fichero XML único, en el cual también se desglosaban los datos a nivel autonómico, provincial y por municipios.

Una vez que hemos escrito el programa o “script” que analiza estos ficheros de datos, lo más conveniente es guardarlos en una base de datos relacional y escribir las consultas contra esta base de datos.

Como los ficheros de datos se van actualizando cada poco tiempo, lo más práctico es dejar que la computadora haga ella sóla el trabajo. En el caso de los datos del País Vasco, la dirección y nombre del fichero de datos ha sido toda la noche la misma, con lo que pudimos dejar un “script” corriendo cada minuto mientras pedíamos una pizza.

Los ficheros de datos del recuento en Galicia cambiaban de nombre cada vez que se actualizaba el recuento. Esto nos obligó a hacer un poco de trabajo manual, aunque lo teníamos también “semi-automatizado”: llamábamos a un “script” pasándole el nombre de fichero de datos y se disparaba la actualización.

Por otra parte, en la página web se iba mostrando una especie de “marcador” con los datos parciales, el porcentaje escrutado, etc. Obviamente, estos datos provenían de nuestra base de datos, pero no podíamos arriesgarnos a que cada página vista disparase una consulta a la base de datos: saturaríamos los (ya bastante congestionados) servidores rápidamente.

La solución que adoptamos fue la siguiente: un “script” generaba un fragmento de HTML (haciendo las pertinentes consultas) cada 30 segundos, lo escribía en un fichero y lo que la página web mostraba era este HTML “precompilado”. Bueno, bonito y barato ;-)Por otra parte, el lunes por la mañana, previendo que íbamos a tener muchas consultas para buscar municipios, resultados por comarcas, etc, en las páginas de resultados, decidimos “cachear” o guardar los resultados de las consultas, ya que estaba todo escrutado. De esta forma nos ahorramos muchas consultas a la base de datos, que suele ser el cuello de botella de las aplicaciones web.

Si usted busca los resultados electorales de su pueblo y la página tarda un poco en mostrarle los resultados, está de enhorabuena: es usted la primera persona que busca los resultados de este municipio, y, además, los siguientes usuarios que busquen los resultados de este mismo sitio tendrán una respuesta mucho más rápida.

Espero que les haya interesado esta entrada. Si quieren que les cuente algo más, dejen un comentario. Contestaré lo que mejor pueda.

¿Dependemos en exceso de algunas compañías?

Compartir:

Tras la caída de Gmail ayer, mucha gente se está empezando a replantear si tenemos una dependencia excesiva de Google (u otras empresas) y si estamos ante un nuevo monopolio.

Personalmente, mi relación con los productos de Google es de amor/odio. Su buscador me parece muy bueno, Gmail es el correo web que más me gusta de todos los que he probado y otros “inventos” suyos me parecen geniales (GTalk, Maps, Groups, muchas de las APIs para desarrolladores, …).

El odio viene provocado por la envidia
Como desarrollador web no puedo dejar de admirar, desde el punto de vista técnico, lo bien que han hecho algunas cosas.

Sin embargo, reconozco que puede que estén acumulando demasiado poder. Muchos responsables de sitios web viven pendientes del PageRank de su web, la publicidad AdSense (una de las principales fuentes de ingresos de Google) no es del agrado de todo el mundo y su actuación en algunos países es bastante cuestionable (p. ej., en China).

Pese a todo, veo dos diferencias muy importantes respecto a otros monopolios existentes:

1. Sus productos, por lo general, son buenos. Algunos, muy buenos. De otras compañías no puede decirse lo mismo (estoy pensando en los navegadores de Microsoft).
2. Este monopolio es consentido por los usuarios. No viene preinstalado en nuestros ordenadores. Nadie nos obliga a utilizar Google para hacer nuestras búsquedas, ni usar Gmail para nuestro correo, ni pinchar en los anuncios AdSense.

¿Qué opinan? ¿Estamos dando mucho poder a esta empresa?

El desarrollo de una página web

Compartir:

Me ha dado mucha envidia José Pujol con sus “posts” en los que explica el día a día de su trabajo, así que en esta entrada voy a hacer lo mismo.

En la web de Público tenemos dos partes muy diferenciadas: el gestor de contenidos y las páginas que genera (básicamente, la portada, las subportadas y las páginas con noticias) y el resto (blogs, video, sección de cine, archivos estáticos, etc).

Hoy voy a tratar de contar cómo hemos construido la página web del concurso Foto Libre.

Lo primero que hicimos fue reunirnos con la gente del periódico que organizaba el concurso (departamentos de fotografía, “marketing” y sistemas). En esta reunión se estableció la mecánica del concurso desde un punto de vista genérico, sin entrar en detalles técnicos.
Esta fase se suele denominar “toma de requisitos” y es fundamental para que un proyecto salga adelante. Tienen que quedar perfectamente especificadas todas las características deseables.

Con esta información, desde la parte de diseño y programación web (nosotros) se hicieron unos bocetos o esquemas de las páginas. Por ejemplo: “pantalla de inicio, desde ahí el usuario puede ir al formulario de registro o a la galería de fotos”, o “pantalla de registro, el usuario introduce sus datos para participar y se le envía un correo de confirmación”, etc.
Existe un término llamado “casos de uso” que sirve para documentar las posibles interacciones y flujo de trabajo de una aplicación.
En este punto, todavía no se ha escrito nada de código, pero son pasos necesarios para que todo salga bien. Si no está claro qué se quiere obtener, difícilmente el proyecto será del gusto del peticionario.

Cuando todos los implicados han dado el visto bueno a estos bocetos, empieza el trabajo de los diseñadores (Matteo y Daniel) y programadores (Rodrigo y el autor de estas líneas).

El separar funciones es bueno y productivo y permite avanzar en paralelo. Mientras los diseñadores van esbozando las distintas pantallas, los programadores vamos haciendo el trabajo “de trastienda”: diseño de la base de datos (si es necesaria, claro), elección de la tecnología que se utilizará en el desarrollo (lenguajes de programación, “frameworks”, etc), diseño funcional de la aplicación (separación de las distintas funcionalidades de la aplicación), etc.

En este punto, los diseñadores nos proveen con algunos archivos HTML y CSS estáticos. Los programadores los “desmenuzamos” y asignamos a cada parte de la aplicación una labor, algunas de estas unidades funcionales son las que se encargan de generar el HTML de forma dinámica (obteniendo los datos de las fotos de una base de datos, validando los datos que introducen los usuarios cuando se registran o suben fotos, etc).
Es la llamada “capa de presentación”.

Hoy en día muchas webs se diseñan siguiendo un patrón o modelo muy conocido: MVC (Modelo, Vista, Controlador).
La capa M (modelo) abstrae, representa y ofrece mecanismos de acceso a los datos “crudos” de la aplicación, la capa C (controlador) se ocupa de gestionar las peticiones de las distintas páginas y solicitar los datos para generar estas páginas.
Por último, la capa V (vista o presentación) “pinta” o representa los datos en un formato determinado (en nuestra aplicación de Foto Libre, en HTML).

Para muchas páginas web sencillas o informales esta separación está casi más en la mente de las persona que escribe el código, pero en desarrollos de mayor entidad conviene separar físicamente estas funcionalidades.

Espero no haberles aburrido mucho. Es difícil condensar en unas pocas líneas tanta información. Otro día les contaremos más cosas sobre el trabajo que hacemos.