Instalar una gem:

gem install nombreGem

Desinstalar:

gem uninstall nombreGem

Actualizar:

gem update nombreGem

Borrar versiones anteriores:

gem cleanup

Listar las gems instaladas:

gem list

Dependencias de una gem:

gem dependency nombreGem

Buscar gems remotamente por el nombre:

gem search -r nombreGem

Buscar gems remotamente en toda su info:

gem query -r criterioBusqueda

Ejemplo: buscar gems remotamente cuyo nombre empiece por “m”

gem query -r -n ^m

Info de una gem:

gem search -r -d nombreGem

Añadir un source nuevo (ej:github):
gem sources -a http://gems.github.com

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!

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.

---

Mac default/serif/times:

---

Windows default/serif/times:

---

Ubuntu default/serif

---

Mac helvetica/sans-serif:

---

Mac arial:

---

Windows helvetica/arial/sans-serif:

---

Mac verdana:

---

Windows verdana:

---

Mac “Trebuchet MS”:

---

Windows “Trebuchet MS”:

---

Mac courier/monospace:

---

Mac “Courier New”:

---

Windows “Courier New”/monospace:

---

Windows 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

En las últimas semanas he ocupado algo de mi tiempo libre en desarrollar mi primer plugin para Rails. Teniendo en cuenta que no soy ningún experto en metaprogramming, en general estoy bastante contento con el resultado: el plugin hace exactamente lo que quería y yo he aprendido cosas. Básicamente lo que hace es crear URL amigables para acceder a nuestros registros de la base de datos. Entrar en su página para obtener más información (en inglés). Lo he publicado en algunos sitios.

Por defecto MySQL crea sus bases de datos en latin1, y para guardar todo tipo de caracteres de forma apropiada es mejor decirle que por defecto las cree con UTF8.

Si tenemos acceso de escritura al archivo /etc/my.cnf le podemos añadir:

[mysqld]
character-set-server = utf8

[client]
default-character-set = utf8

Si no podemos hacer lo mismo con el achivo ~/.my.ini (configuración por usuario)

Despues de reiniciar MySQL ya creará las nuevas bases de datos con UTF8

Otra opción es indicarlo en el momento de la creación:

mysql -u root -e "CREATE DATABASE application_name_development CHARACTER SET 'UTF8';"

Si vamos a crear la base de datos con Rails 2 (db:create:all), ya le asigna el encoding que tengamos definido en database.yml.

Ya estaba tardando en actualizarme a Rails 2:

Descargar MacPorts

Por alguna razon la version para Leopard no modifica los paths, y necesitaremos hacerlo manualmente:
En /etc/paths añadir:
/opt/local/bin
/opt/local/sbin

En /etc/manpaths añadir:
/opt/local/share/man

Actualizamos tal y como indico en este post.

Por cierto en ese post no instalo Mongrel. No es que sea obligatorio pero es mejor que WebBrick (incluido en Ruby):
sudo gem install mongrel

El instalador de MySQL no funciona muy bien en Leopard, así que de esta vez he decidido instalar MySQL vía MacPorts. Basta con:

sudo port install mysql +server

Para que arranque al inicio:
launchctl load -w /Library/LaunchDaemons/org.macports.mysql5.plist

Esto instala las bases necesarias del MySQL
sudo -u mysql mysql_install_db5

Recuerda que por defecto crea el socket en /opt/local/var/run/mysql5/mysqld.sock, y que para invocar mysql desde línea de comandos debemos poner:
mysql5

E instalamos el adaptador de MySQL para Rails:

sudo port install rb-mysql

Ala, a disfrutarlo.

Desarrollo

En una página web es importante no tener scroll horizontal, para tener una buena usabilidad. Por supuesto esto depende de la resolución de pantalla del usuario. Actualmente la menor resolución de pantalla es 800×600, pero cada día es menos usada. La siguiente resolución más pequeña es 1024×768, que es la más usada. De todas formas es aconsejable utilizar el menor ancho necesario para nuestra web, porque muchas veces el usuario no tiene la ventana maximizada, o accede por medio de otros aparatos pequeños, o simplemente para ayudar a la legibilidad.

Otra opción es usar plantillas flexibles, donde las columnas se adaptan al ancho de la ventana, pero el diseño debe ser apropiado para ello.

También podemos usar diferentes presentaciones para cada resolución, y cambiarlas dinámicamente. En este caso deberemos mantener dos diseños/plantillas distintas.

Este es un ejemplo usando una mezcla de plantilla flexible y plantilla dependiente de la resolución.

Testing

A continuación las herramientas/valores que uso para testar las plantillas.

Explorer window size es el tamaño real de la ventana cuando está maximizada en esa resolución. Incluye bordes y barra de tareas desbloqueada. Puedes usar Sizer para cambiarle el tamaño, y testar como funciona in una determinada resolución de pantalla, sin importar la tuya. Explorer tiene el escrollbar más ancho, así que si en Explorer se muestra bien, en el resto de exploradores también. Estas dimensiones son sólo para una configuración normal/media, porque nunca podremos saber el número de barras, posición de la barra de tareas, etc. que tiene el usuario.

Firefox fold (viewport) size es el mismo tamaño interior de ventana en Firefox que en Explorer. Puedes usar el Resize (marcando Viewport) de la Web Developer Toolbar.

CSS max width es el ancho máximo que podemos usar para evitar el scrollbar horizontal. Si ese tamaño lo aplicamos a un elemento no puede tener margins, paddings, o borders.

——–

Screen resolution: 800×600.

Explorer window size: 808×566.

Firefox fold size: 795×440.

CSS max width: 779px.

————

Screen resolution: 1024×768.

Explorer window size: 1032×734.

Firefox fold size: 1019×608.

CSS max width: 1003px.

———–

Puedes calcular el valor para otras resoluciones:

Screen resolution AxB

Explorer windows size: (A+8)x(B-34)

Firefox fold size: (A-5)x(B-160)

CSS max width: A-21px

No se muy bien por qué, pero con Photoshop CS3 hay diferencias de color entre la imagen original y la guardada con Save For Web. A lo mejor en otro monitor no hubiera apreciado la diferencia, pero éste contrasta mucho la imagen (demasiado), y se hace muy incómodo ver los colores cambiados después de salvar. Es cierto que en cada monitor se verá de una forma, por eso en web no hay que preocuparse mucho de conseguir un color exacto. Pero por lo menos quiero ver lo mismo en el diseño que en el navegador.

En teoría deberíamos usar sRGB en el RGB Working Space, puesto que es como se verá la imagen en los navegadores. Si no tenemos sRGB, Save for Web lo convierte automáticamente, y es cuando aparecerían las diferencias.

En teoría, esa es la manera de trabajar, pero con CS3 no funciona, y no soy el único. Debe tratarse de algún bug en CS3, pero el caso es que hay que utilizar una solución que no me gusta pero que funciona.

Si alguien trabaja para imprenta, sabrá que usar el perfil de color del monitor es una salvajada, pero para web no es tan grave.