Aunque he encontrado algunas de las charlas muy básicas/aburridas (Sitemaps, SEO, OpenSocial…) en general la conferencia ha sido buena, descubriendo y provocando curiosidad en algunas nuevas cosas. Desde luego es un placer asistir a esta clase de eventos. Los puntos que destacaría son los siguientes:

• La capacidad de procesamiento del lado del cliente (navegador) están empezando a ser más y más usadas. JavaScript se está volviendo más fuerte.
• jQuery es la librería más usada por los ponentes
• Google Gears está empezando a ser más y más usado, y está empezando a ser el standard ‘de facto’ para llevar aplicaciones web offline. Será compatible con Firefox 3, Safari, Opera (ya es con Explorer/Windows Mobile). Otras mejoras son: mejoras en la creación de accesos directos, notificaciones al SO, multiple subida de archivos directamente desde el sistema de archivos, parar/reiniciar subida de archivos mostrando %, geolocation de las peticiones.
• Dustin Diaz explicó que, como OOP lenguaje, JavaScript Design Patterns pueden transformar código JavaScript en código leíble y elegante. Usando librerías JavaScript raramente hace falta aplicarlos.
• Interesante servicio: AJAX Libraries API. Google hospeda las librerías, por lo que tendríamos CDN automático/rápido/gratis, además de que estarían en caché si otras webs también lo utilizan.
• Interesantísima charla de Steve Souders. Aparte de las bien conocidas 14 reglas de oro para optimización de páginas web, expicó otras técnicas para la descarga en paralelo de archivos JavaScript, que incluirá junto con otras técnicas en su siguiente libro: High Performance Web Sites, que estará disponible a principios del 2009.
• Para los sitios sociales, Social Graph API. Utiliza XFN y FOAF standards para encontrar automáticamente nuestros amigos (o nosotros mismos) en otras aplicaciones web. En la demostración lo utilizaban con sgnodemapper para la canonicalización de URLs.
• Interesante demo de Google AJAX API (search, feeds, language) creando de forma relativamente sencilla una aplicación mezclando datos de diferentes feeds con diferentes orígenes, con búsqueda y traducción automática. La API de lenguaje reconoce automáticamente el lenguaje de origen, y lo convierte al lenguaje que queramos. Cada vez las traducciones son más correctas y espera un gran futuro en este campo.
• Interesantes novedades para la Google App Engine, chalas a las que atendió mi compañero Marcin Ciszak, pero yo no me voy a preocupar de ellas hasta que no permitan Ruby :).

Por cierto: San Francisco MOLA!

Pues eso, TrafficBroker me manda a Google I/O, y yo intentaré aprovecharlo al máximo. Ya os contaré…

Acabo de publicar unos plugins para jQuery que he utilizado en mis recientes trabajos para TrafficBroker. De los que más orgulloso me siento es de hSlides y jOdometer (coñero el nombre eh?). Puedes echarles un vistazo en mi página de proyectos.

Con tanto lío casi ni he podido anunciar mis últimos trabajos: TrafficBroker y Forward. Como ya sabéis yo trabajo para TrafficBroker, pero ahora tenemos una “holding company”, que engloba tanto a TrafficBroker como al resto de nuestros proyectos. Es decir que Omio ahora también pertenece a Forward. Por cierto Omio ha cambiado un montón desde la última vez que lo mencioné. De esta vez no he tocado código, pero he supervisado el trabajo del coder de ThoughtWorks en India.

Pero bueno a lo que iba: me he encargado íntegramente del desarrollo de TrafficBroker y Forward websites. Tanto front-end (HTML/CSS/JS) como back-end (Ruby on Rails). Con estos dos trabajos he aprendido un montón de cosas nuevas: soltura con SVN, jQuery, trucos del TextMate, más confianza con Rails, deployment con Capistrano, website performance, técnicas de internacionalización, NginX config… en fin, las bases para el buen desarrollo. Incluso he creado unos cuantos plugins para jQuery de los que estoy bastante orgulloso y que publicaré debidamente cuando acabe la documentación.

El ambiente de trabajo ha sido muy bueno, los diseñadores aprendieron también conmigo y ahora el proceso es más ágil. En general me he asentado bien en el equipo, y las cosas pintan que cada vez va a ser mejor. Se me nota que estoy contento?

He decidido comprobar manualmente cómo renderizan las fuentes los navegadores en los distintos sistemas operativos:

• Windows: Firefox, IE 6, IE 7.
• Mac: Firefox, Safari.
• Linux (Ubuntu): Firefox.

Las fuentes testeadas son las las típicas browser-safe fonts: times/”Times New Roman”, arial/helvetica, verdana , “Trebuchet MS”, courier/”Courier New”; y las genéricas: serif, sans-serif, monospaced.

Resultados

• Todos los sistemas operativos renderizan lo mismo en los distintos navegadores.
• Todos los sistemas operativos usan como fuente por defecto serif.
• Todas las llamadas browser-safe fonts no son reconocidas en Ubuntu y renderizan serif.
• Ubuntu para las fuentes genéricas tiene una fuente con ese mismo nombre: por ejemplo la fuente para serif se llama serif.
• times es lo mismo que “Times New Roman”
• arial y helvetica renderizan lo mismo en Windows, pero en Mac/Firefox la posición varía un poco y en Mac/Safari el borde es ligeramente distinto (parece más suave el de helvetica).
• serif es times en Windows and Mac.
• sans-serif es arial=helvetica en Windows y helvetica en Mac.
• monospace es “Courier New” en Windows y courier en Mac, pero a un 85% en tamaño comparado con poner directamente courier.

Conclusiones

• Las llamadas “browser-safe fonts” no son tal, por lo que debemos poner siempre el genérico de nuestra fuente al final de la declaración para que al menos tengamos el tipo de fuente correcto.
• Siguiendo esta regla hay otras fuentes que renderizan en Mac y Windows (no Linux), pero la verdad es que se ven tan feas en Windows que merece la pena quedarse sólo con las sencillas.

Teniendo esto en cuenta mi lista de opciones se queda en:

• times, serif
• helvetica, sans-serif
• verdana, sans-serif
• “Trebuchet MS”, sans-serif
• “Courier New”, monospace