Probando Google ChromeOS

Por David Asorey Álvarez a las 13:39

Categoria: Internet, Sistemas

20Nov09

Parece que ya hay algunas imágenes de disco disponibles del sistema operativo que propone Google, ChromeOS.

Lo he instalado en una Virtual Box y he estado probándolo un rato. Sinceramente, si uno se lee las especificaciones y requerimientos del invento (ver enlace anterior), no debería decepcionarse.

Edito: En Taringa! explican bien cómo instalarlo.

Básicamente ChromeOS no es más que un navegador ejecutándose a pantalla completa sobre un sistema operativo mínimo.

La cuenta con la que se accede al sistema debe ser una cuenta de Google, del tipo blablabla@gmail.com. Supongo que se podrá acceder en modo local o incluso como root, aunque no me extrañaría nada que las cuentas de root estén deshabilitadas o protegidas (como en el sistema operativo para móviles Android que distribuyen las operadoras o el iPhone).

Pantalla de acceso

Pantalla de acceso

Respecto al gestor de ventanas, está totalmente limitado: no se puede minimizar ni mover la ventana del navegador. Si se cierra (Ctrl+F4), inmediatamente vuelve a abrirse una nueva ventana a tamaño completo del navegador.

Muchas cosas que ahora no funcionan se arreglarán en un futuro, esto no es más que una versión de pruebas. Me ha llamado la atención que no se puedan sincronizar los marcadores. En las últimas versiones de desarrollo de Chromium ya se puede pasando la opción --enable-sync al arrancar el programa.

¿Y el sync?

¿Y el sync?

He intentado “cacharrear” un poco las interioridades del sistema, pero no hay manera. No localizo un gestor de archivos ni una terminal. Desde luego, es un Linux y su sistema de archivos es el típico (se puede “explorar” un poco dándole a guardar un archivo desde el navegador).

Edito: en Barrapunto un comentarista sugiere cómo sacar una terminal, alternar entre escritorios, etc.

Estructura de directorios

Estructura de directorios

Claramente es un sistema orientado a la web exclusivamente. El último sistema que probé con una filosofía similar (Jolicloud) al menos tenía aplicaciones “tradicionales” y se tenía un cierto grado de acceso a las interioridades de la máquina. Con ChromeOS parece que no, que ni siquiera podremos organizar los directorios de nuestra “$HOME” a nuestro gusto.
Como decía al principio, leer la presentación de Google del sistema es muy reveladora. Resalto algunos puntos:

Demo:
- 7 seconds boot time
- the UI is a work in progress
- easy to access favorite apps
- app menu
- panels: persistent lightweight windows (example: Google Talk)
- file browser
- local files open in web apps (including Microsoft Office online apps)
- native video player
Under the hood:
- [...]
- no hard disks, only solid-state drives
- verified boot
- security: the OS does not trust any app
- read-only root file system
- user data synced to the cloud
- automatic updates for the entire OS
[...]
Market:
- reference hardware
- you can’t download Chrome OS and install it on your machine
- the only way to install the OS is to buy a Chrome OS machine

En mi opinión, la tendencia e intención es clara: restringir a los usuarios el acceso a su propia máquina. Como está pasando ahora mismo con algunos teléfonos móviles, que vienen con muchas funcionalidades restringidas.

No niego que sea una aproximación que ofrece bastante seguridad, pero … a mí no me acaba de convencer. Mi ordenador es mío y no quiero que me limiten lo que puedo o quiero hacer con él. Es mi responsabilidad.

Cachés, proxies y CDNs

Por David Asorey Álvarez a las 13:37

Categoria: Desarrollo, Redes, Sistemas

05Nov09

Un concepto fundamental en el desarrollo web es el uso de cachés (contenido que se almacena en algún punto para reutilizarlo y no solicitarlo de nuevo).

En la web tenemos cachés por todos los sitios: en el navegador del usuario se suelen guardar muchos recursos estáticos (hojas de estilo, scripts, imágenes, etc).

Los proxies por los que salen las peticiones de una empresa también suelen cachear los contenidos. Los proveedores de Internet (ISPs) también suelen hacerlo. Las aplicaciones web también cachean el contenido que generan (por ejemplo, para servir una noticia se hace la consulta una vez y la aplicación guarda el resultado para no sobrecargar la base de datos).

Finalmente, existen cachés distribuidas en las Redes de Distribución de Contenidos (Content Delivery Network, CDNs en inglés).  Estas CDNs son unos servicios muy convenientes y eficientes, pero son bastante caros y su utilización sólo es recomendable para sitios con mucho tráfico.

¿Cómo funciona una CDN?

Una CDN suele tener un montón de servidores distribuidos por todo el mundo, o al menos en los CPD (Centros de Proceso de Datos) más importantes. En los DNS (Sistema de Nombres de Dominio) se crea un “alias” para que la dirección de la página (por ejemplo, www.misitio.org) “apunte” realmente a la CDN (por ejemplo, www-misitio-org.cdn.net).

Cuando un usuario pide la página www.misitio.org la petición llega de forma transparente a la CDN y ésta se encarga de que el servidor (o nodo) más cercano o con mejor respuesta le devuelva la página al usuario.

¿Cómo le llega el contenido a la CDN desde el sitio original? Se suele definir una configuración en la CDN en la que se establece de qué máquina o dirección la CDN lee el contenido (origin en la nomenclatura de estas herramientas). Obviamente, este origen no es accesible públicamente y se ejecuta en la infraestructura del cliente.

Esquema básico del funcionamiento de una CDN

Esquema básico del funcionamiento de una CDN

TTLs, Expires, Last-Modified

Cuando se utiliza una CDN es crítico poder controlar cada cuánto tiempo el contenido del origin se refresca en la CDN, o cada cuánto ésta debe consultar al origen para comprobar si el contenido ha cambiado y recuperarlo de nuevo si es necesario.

Configurar este comportamiento y optimizarlo no es una tarea trivial, requiere un buen conocimiento del protocolo HTTP y de las necesidades “de negocio” del sitio origen. Una política de caché muy agresiva puede conducir a que el contenido se vea desactualizado. Por contra, establecer cachés muy cortas en la CDN puede saturar al origen y se pierde una de las ventajas de las CDNs, que es “amortiguar” el tráfico en la infraestructura del sitio origen.

Las CDNs, por lo general (al menos las tres que conozco), funcionan en dos “modos”:

  1. Estableciendo tiempos de vida prefijados en la CDN:
    En la herramienta de configuración pertinente se establece cuánto tiempo (TTL) permanece en la CDN el contenido del origen cacheado y, por consiguiente, cada cuánto tiempo la CDN refresca el contenido almacenado solicitándoselo al origen.
    La configuración suele ser flexible, estableciendo distintos tiempos de vida para diferentes rutas, tipos de archivo, etc.
    Por ejemplo, una regla típica es la siguiente: “Todas las imágenes, swf y pdf bajo la dirección /recursos tienen un tiempo de vida de 1 día”.
    Esto implica que la primera vez que un usuario solicita, por ejemplo, www.misitio.org/recursos/pdf/fichero1.pdf, la CDN a su vez lo solicita al origen y no lo vuelve a pedir hasta el día siguiente. Las siguientes peticiones a este recurso son servidas exclusivamente por la CDN.
  2. La CDN consulta al origen para saber cuándo refrescar:
    Si el servidor de origen se configura adecuadamente puede enviar dos cabeceras HTTP denominadas “Expires” y “Last-Modified“. La CDN puede basar su funcionamiento en estas cabeceras que le envía el servidor de origen y decide qué hacer con las peticiones que le llegan, si servirlas desde su caché o volver a solicitarlas al origen.
    La cabecera “Expires” determina cuándo un recurso “caduca”. La cabecera “Last-Modified” informa al peticionario cuándo se modificó el contenido por última vez, de tal forma que si ya ha expirado y además se ha modificado el recurso en origen, se vuelve a solicitar.
    Todo este trasiego de peticiones HTTP entre la CDN y el origen permite un control mucho más fino del tiempo que “vive” un recurso en la caché de la CDN, pero hay que ser muy cauteloso con su utilización.
    Aunque estas peticiones de cabeceras no son muy pesadas (no se pide el contenido completo, sólo información sobre él) pueden saturar el servidor de origen si no están bien configuradas (hablo por experiencia propia ;-)

¿Quién utiliza CDNs?

Muchísimas webs grandes utilizan CDNs. Hay CDNs de pago o se puede montar una CDN propia si se disponen de los suficientes recursos.

Otra opción es no utilizar ninguna CDN y confiar en que nuestra infraestructura “aguante” las visitas que le lleguen. Lo bueno de las CDN es que no sólo amortiguan las peticiones que llegan al origen: también distribuyen el contenido a los usuarios desde la ubicación más próxima o eficiente: si un usuario de Asia pide una página a la CDN, lo más probable es que la respuesta le llege desde un nodo de la CDN situado también en Asia aunque el servidor de origen esté en cualquier otro continente.

Vamos a hacer una ronda por los principales medios:

david@chatarrilla:~$ ping www.elpais.com
PING a1749.g.akamai.net (194.224.66.88) 56(84) bytes of data.
 
david@chatarrilla:~$ ping www.elmundo.es
PING www.elmundo.es (193.110.128.199) 56(84) bytes of data.
 
david@chatarrilla:~$ ping www.abc.es
PING a1159.g.akamai.net (194.224.66.66) 56(84) bytes of data.
 
david@chatarrilla:~$ ping www.lavanguardia.es
PING www.lavanguardia.es (88.87.219.56) 56(84) bytes of data.
 
david@chatarrilla:~$ ping www.lainformacion.com
PING a1296.g.akamai.net (194.224.66.107) 56(84) bytes of data.
 
david@chatarrilla:~$ ping www.publico.es
PING a1548.g.akamai.net (194.224.66.91) 56(84) bytes of data.

Llegamos a la conclusión que Akamai tiene bastantes clientes entre los medios “online” españoles ;-)

¿Alguna experiencia interesante que contar sobre CDNs?

CSS Sprite

Por Matteo Batazzi a las 11:40

Categoria: Diseño

05Nov09

Cada web tiene su lote de imágenes, por un lado las relativas al diseño, como el logo o los iconos del menú y por otro las fotos de las noticias. Así que al final, hay muchas (aunque pequeñas) imágenes que cargar, y esto aumenta el peso de la web y las peticiones HTTP. Afortunadamente, esto se puede mejorar gracias a los CSS Sprites.

¿CSS Sprites, WTF ?
El sprite es simplemente una única imagen, generalmente muy grande y en formato .png donde se reúnen todas las imágenes del site relativas al diseño.
Es mejor utilizar el formato PNG 24, aunque pese más, para mejorar la calidad de la transparencia. Sin embargo el navegador más odiado de los diseñadores y programadores actualmente, el famoso Internet Explorer 6, no soporta bien este formato, es decir, añade un fondo gris en lugar de la transparencia.
Si bien existe algún que otro “parche” para evitar este problema, usando un sencillo Javascript por ejemplo (pngFix.js)

¿Que aspecto tiene este Sprite?
Pues la verdad, es que parece una orgía de imágenes… ;) Lo mejor es tener bien organizado el diseño desde el principio para que el Sprite sea más claro. Como siempre es mejor una imagen que mil palabras, aquí tenéis algunos Sprite de los sitios web más famosos:

Sprite de Apple

Sprite de Apple

Sprite de Google

Sprite de Google

Como podéis ver, todas las imágenes están contenidas sólo en una. Cuando entramos, por ejemplo, a Google, se carga una imagen sola, para toda la gráfica de la página. Esto es muy útil para hacer rollovers casi instantáneos o navegar por el sitio sin que nos cargue nuevas imágenes, mejorando la rapidez.

Si se hubieran cargado dos imágenes aparte, por ejemplo estas dos:

Apple button store 1

Apple button store 2

Al pasar el ratón encima de la superior, se tiene que ver la inferior, pero tendría que cargar esta nueva imagen del botón (la oscura), con lo que tardaría muy poco tiempo pero el suficiente para que se note el “error”.

Por eso el Sprite se está extendiendo tanto, sólo tiene ventajas, se carga más veloz una imagen de 40Kb que cuatro de 10Kb. Es más, podríamos incluir más imágenes en el Sprite y pesarán menos ya que la optimización la haremos sobre una única imagen.

Vale, pero ¿cómo podemos posicionar todo en su lugar?
Es muy sencillo, se hace con la propriedad CSS background-position que permite de posicionar una imagen con eje horizontal X y eje vertical Y.
Para entenderlo mejor, vamos a coger el ejemplo de Público.es. Esto es nuestro Sprite

En este Sprite el logo esta arriba a la izquierda, así que en el CSS se pondrá:

background: url(sprite.png) no-repeat 0 0;

El primer 0 siendo el eje X y el segundo el eje Y.
Bueno, este ejemplo era fácil, el primer elemento del Sprite tiene siempre:

background-position: 0 0;

Otro ejemplo, con el pájaro (mucho más fácil escribirlo que pronunciarlo para un extranjero) de nuestro módulo Síguenos en Twitter:

Síguenos  en Twitter

Síguenos en Twitter

background:url(sprite.png) no-repeat -915px -1390px;

La posición que está en el CSS es -915px -1390px lo que significa, que al leer la imagen, nuestro CSS va a moverla de 915 píxeles a la izquierda, y la sube 1390px para llegar a la imagen del pájaro.

Fácil, ¿no?

El problema que puede crear el Sprite…
Hay una problema que puede crear nuestro Sprite si se usa en un div sin ancho o alto fijo. Lo que pasaría, es que se podrían “colar” imágenes del sprite en este div.
Para evitar este problema, se pueden poner más espacios entre los elementos del Sprite (como en el de Público.es) o poner un width o height o ambos fijos en el div.

¿Y ahora, mi vida va a cambiar?
No, lo siento, no tengo este poder, aunque me gustaría. Pero os aseguro que vuestros sitios web se cargarán mejor y más rápido.

Como sabemos que esto tiene su dificultad, si tenéis cualquier duda al respecto ¡no dudéis en comentárnosla!

Links (en inglés) que hablan de los CSS Sprites

Hablando de diseño web

Por Daniel Solana a las 00:33

Categoria: Diseño, Internet, Miscelánea, labs.publico.es, publico.es

05Nov09

Si la información en un diario es lo más importante, quizás la forma y la apariencia en la que se presenta esta información también juega un papel muy importante, al fin y al cabo un buen diseño web en un diario debería ser claro y limpio.

Hemos visto en Smashing Magazine una recopilación de tendencias y ejemplos de diarios online bien diseñados.

Y ya que tenemos en mente hacer mejoras en Público.es en este sentido, nadie mejor que vosotros y otros diarios, en este caso sólo internacionales, para aportarnos ideas al respecto. De esta lista creemos que el mejor, y el que más se adapta a nuestro diario es el periódico británico The Guardian.

the guardian

the guardian

Tanto la disposición de las columnas como las tipografías son muy “cómodas” para leerlo. Así como el menú superior y las secciones, enseguida identificas por los colores si estás leyendo un titular de deportes o de culturas en la portada.

the guardian

the guardian

Y esto sin tener que recurrir a fondos de color o “cajas” que cargarían un poco al leer en pantalla (esto nos pasa un poco a nosotros mismos).

Así que como todo es mejorable, incluso The Guardian ;) , esperamos poder “evolucionar” una vez más y sorprenderos ¿quizá?

Publico.es: Estadísticas de navegadores (Octubre 2009)

Por Rodrigo Díez a las 21:14

Categoria: Internet, publico.es

03Nov09

Si hay algo que me gusta de trabajar en la web de un diario nacional, dejando a un lado el hecho de relacionarme con un equipo joven y magnífico – en serio, nadie me coacciona, ejem – es poder manejar las cifras de visitas que aquí tenemos y ver como el trabajo que realizamos repercute, inmediatamente, en mucha, mucha gente.

Somos un diario pequeño, alejado de los grandes números de elpais.com y elmundo.es, sin embargo somos una web grande y es un auténtico placer para un técnico como yo consultar estadísticas de, por ejemplo, los diferentes navegadores que usan nuestros lectores, la distribución horaria de las visitas, los sistemas operativos, etc.

Es por esto que me dispongo a mostrar algunos datos que, estoy seguro, saciarán la curiosidad de más de un lector sin comprometer nuestro trabajo. Datos que, quizá, sorprendan.

¿Qué tal si comenzamos con el ya clásico reparto de los navegadores?

Lista de navegadores

Lista de navegadores

Reparto de navegadores

Reparto de navegadores

Lo primero que llama la atención es que, aunque Internet Explorer aun es el rey indiscutible, la web está cerca de tener una mayoría de accesos a través de navegadores con corazón libre como son Firefox (Gecko), Chrome (Webkit) y Safari (Webkit).

Y esto nos agrada personalmente. Creemos que es bueno para todo internet porque ayudará a que los estándares se respeten y a que el consenso técnico entre los actores se convierta en un factor más importante que los intereses inmediatos de una gran empresa. Internet antes que un negocio es una industria, que se rige por estándares. Epa :)

Es muy significativo el uso de Firefox, en segundo lugar con un 36% ¡Menudos zorros estáis hechos! Pero lo que realmente sorprende es ver a Chrome el tercero acaparando un 5.92% de nuestras visitas y superando incluso al Safari de Apple, que ocupa el cuarto lugar con un 5.85%.

Opera está en quinto puesto rozando el 1%. A más de uno en este equipo le gustaría que tuviera una difusión más amplia, se lo merecen por todo lo que aportan.

El resto se reparte entre navegadores Mozilla, y diversos dispositivos móviles. ¡Hay incluso gente que nos visita desde su Playstation 3 o su PSP!

En la siguiente entrega: Sistemas operativos. No se la pierdan ustedes por nada del mundo.

Ahora os toca. ¿Qué os parecen las cifras?

Edit:

Varias personas nos han pedido el desglose específico de las diferentes versiones deInternet Explorer y Firefox así que… ¡vamos!

Comencemos por Explorer:

Internet Explorer: Listado de versiones

Internet Explorer: Listado de versiones


Internet Explorer: Reparto de versiones

Internet Explorer: Reparto de versiones

La versión 6 de Internet Explorer tiene un 25% de las visitas que vienen a través de la familia de navegadores de Microsoft que, recordemos, representa un 50% del total de las visitas de Publico.es. Esto significa que, aproximadamente, un 12,5% de las visitas a nuestro sitio se producen a través de Internet Explorer 6.

Es una cifra que experimenta un descenso lento pero continuado. Si no recuerdo mal hace aproximadamente un año el porcentaje sobre el total rondaba el 25%. Llegará el día en que podamos olvidarnos de dar soporte a Internet Explorer 6 pero, desgraciadamente para nosotros, un 12,5% de nuestros lectores aun es demasiado.

Eso si, haremos todo lo posible para informar y ayudar a los usuarios más rezagados a actualizarse. Como en nuestra aplicación de charlas, donde el usuario que accede mediante Internet Explorer 6 recibe un mensaje de aviso animándole a migrar a navegadores más modernos:

Aviso para Internet Explorer 6

Aviso para Internet Explorer 6

Desgraciadamente creemos que el porcentaje de Internet Explorer 6 tampoco bajará mucho más en un futuro cercano. Mucha gente nos lee desde su puesto de trabajo donde carecen de privilegios de administrador para instalar o actualizar su navegador.

También hay que tener en cuenta que algunas intranets o aplicaciones web corporativas se encuentran atadas a esta versión del navegador de Microsoft :(

Es el turno de Firefox:

Mozilla Firefox: Listado de versiones

Mozilla Firefox: Listado de versiones


Mozilla Firefox: Reparto de versiones

Mozilla Firefox: Reparto de versiones

Casi el 60% de los accesos por Firefox se producen desde la versión 3.5.x mientras que aproximadamente el 30% vienen de versiones anteriores de la rama 3.x. Los usuarios que acceden mediante Firefox 2.x casi pueden considerarse residuales.

Da gusto ver como el usuario de Firefox se mantiene actualizado :)