La edición de este año promete, tiene una agenda muy atractiva y unos speakers de auténtico peso: Rasmus Lerdof, Fabien Potencier o Carlos Buenosvinos, para citar a algunos. Habrán charlas y temas más que interesantes como “Caching on the edge” (técnicas de cacheado, cabeceras y demás), Team Engaging o el indispensable resumen de PHP que dará Rasmus Lerdof.

Van a ser 2 días intensos de mucha agitación, de aprender mucho muchísimo (espero), y como no, aprovechar para volver a ver caras conocidos y viejos compañeros de trabajo. Solo por esto último ya merece la pena ir.

Nos vemos en la #pbc11 (hashtag del evento) !!!

Si tú también vas a estar allí o quieres seguir de cerca mis impresiones, sígueme en Twitter.

Con la línea siguiente:

Event.observe(window, 'load', function() {});

Podremos ejecutar algo una vez la página esté completamente cargada. Muy útil si queremos asegurar por ejemplo que un div al que queremos interactuar está ya cargada en la página, o si queremos realizar cualquier acción tras la carga completa de la página. Esto es que están todos los elementos del DOM renderizados y todo el resto de elementos web cargados también: js, css e imágenes incluidos. Las peticiones AJAX no entrarían en este saco ya que son peticiones asíncronas y no se carga secuencialmente en el waterfall de la carga de la página.

Hasta aquí todo perfecto. Pero también tenemos otra condición que se usa mucho que es:

document.observe('dom:loaded', function(){});

Esta línea es muy similar a la anterior pero no son exactamente iguales. ¿En qué se diferencian?

Similares pero no iguales

¿Cuál es la diferencia? Pues en el caso del ‘dom:loaded’, éste avisa de cuándo están todos los elementos DOM cargados, independientemente de si están todas las imágenes descargadas.

Conocer la diferencia de estas dos técnicas de control de carga permitirá dominar con más precisión cómo y cuándo queremos ejecutar nuestros scripts, y podremos mejorar la velocidad de carga de la página, y prevenir posibles bugs.

Con jQuery es lo mismo

Antes he mencionado de los métodos que se usan en Prototype, pero con jQuery ocurre exactamente lo mismo. La sintaxis varía ligeramente, eso sí. La relación sería la siguiente:

// Carga del window.onload
// En Prototype
Event.observe(window, 'load', function() {});
// En jQuery
$(window).load(function(){});

// Carga del dom
// En Prototype
document.observe('dom:loaded', function(){});
// En jQuery
$(document).ready(function(){});

Los listeners son una herramienta muy potente, y no solo sirven para observar la carga de la página sino que se le puede dar muchos más usos.

Comentemos esta gráfica…

El tema es que me mudo de piso y como suele pasar durante una mudanza, uno aprovecha para deshacerse ciertas pertenencias que ya no usa, o no interesa llevarse al nuevo piso. Este es mi caso,  y estas son las cosas que pongo en venta, en mi particular “mercadillo”!

Si te interesa alguna cosa, deja un comentario aquí y me pondré en contacto contigo. El escritorio y las altavoces, idealmente debería ser para alguien de Barcelona o alrededores, ya que son productos que pesan mucho y no creo que salga a cuenta enviarlo por correo postal.

Entre las novedades que explica Sitepoint, me ha parecido interesantísimo:

console.timeStamp

Han añadido un nuevo comando API console.timeStamp(), que permite marcar una linea de tiempo en la gráfica de tiempo-carga que hay en el panel Red. Esto me parece buenísimo ya que permitirá depurar más y mejor, se podrá trabajar mucho mejor temas de optimización y velocidad de carga de la web, etc.

Solo por esta característica ya me lo estoy bajando.

Preview del color

Otra característica chula es que ahora Firebug muestra los colores en los formatos hex, rgb, rgba, hsl y hsla; y además te muestra en una tooltip pequeñita una previsualización del color.

También se destacan otras características como formato de dimensiones de cajas CSS3, Opciones del panel DOM, dirección IP en el panel Red, preview HTML en el panel Red (útil para ver respuestas JSON que devuelven html) y opciones adicionales para editores externos.

Puedes encontrar un resumen más completo en el artículo de Sitepoint o en el sitio oficial de Firebug.

Descargar Firefox 5

Descargar Firebug 1.8

Los pasos para instalar el plugin son*:

1. Ir a “Help -> Install New Software -> Add”
2. Introducir datos
   1. Name: “Rockstar Optimizer”
   2. Url: “http://update.rockstarapps.com”
3. En la lista que se carga debajo, checkear los componentes que quieres instalar (yo puse todos)
4. Ir dando al botón NEXT hasta finalizar la instalación.
5. Te pedirá que resetees el Eclipse. “Yes”.

* La versión Eclipse que he usado para instalar el plugin es “Eclipse IDE for JavaScript Web Developers. Version: Helios Service Release 1. Build id: 20100917-0705″

Cómo usar Rockstar Optimizer

Una vez instalado el plugin, es muy fácil de usar. Tan solo has de seleccionar el archivo JS (o los archivos JS) que quieres comprimir y/o minimizar y darle al botón derecho. Aparecerá una opción nueva denominada “Rockstarapps”. Dentro de esta opción aparecerán las diferentes acciones que puedes aplicar como:

• Comprimir Javascript
• Validar JsLint
• Concatenar Javascripts (si seleccionaste varios)

La primera acción de comprimir es la que más me interesa y está bastante bien porque la acción es altamente personalizable. Te da a elegir diferentes modos de compresión como el YUI Compressor, o el Closure Complier de Google. Después hay una serie de opciones para configurar el nivel de compresión y validación que se quiere aplicar.

La ventajas de añadir un paso “Build” en la fase de desarrollo

Optimizar los ficheros JS y reducir el número de peticiones está en el orden del día. En la actualidad hay una gran variedad de opciones y alternativas para realizar un “Build”. Se pueden crear procesos Ant en el Eclipse o Netbeans, se puede incluso automatizar este proceso para que lo haga el propio servidor, existen herramientas online que te minimiza y comprime cualquier script o fichero JS, etc.

Lo que me ha gustado de este plugin Rockstar Optimizer es su facilidad de uso y que está integrado en el editor que uso a diario para programar.

¿Lo has usado? ¿Cuál es tu impresión?

Fuente: rockstarapps

El uso de fuentes de letra chulas en nuestras webs siempre había sido mucho más complicado de lo que debería. Suerte que hoy en día tenemos a disposición distintas técnicas y scripts como el Cufon que nos ayudan renderizar las páginas con la tipografía que mejor le sienta al diseño.

Google (como no) nos trae una alternativa más, y ha sacado una nueva versión 2 de su Google Web Fonts. ¡La pinta no puede ser mejor!

Usar fuentes en la web nunca fue tan fácil

Google Web Fronts es una herramienta online con una colección generosa de fuentes a elegir, y el uso es algo tan sencillo como introducir una línea en el HEAD como:

<link href='http://fonts.googleapis.com/css?family=Redressed&v2' rel='stylesheet' type='text/css'>

font-family: 'Redressed', cursive;

Aquí estáis para aprender a ser vagos. Un informático es vago. El informático más vago es el que más lejos llega. ¿Por qué? Porque es un experto en “hacer lo máximo con el menor esfuerzo”.

Dicho de otra manera, automatizar todo lo que sea automatizable, para que la máquina haga el trabajo por ti.

Para dicha reunión recopilé un par de frases que encontré por Internet y que me resultaron conceptos muy interesantes. Dicen así:

HTML que tenga sentido sin JS no debería ser creado por JS.

HTML que únicamente tenga sentido con JS debería ser generado por JS.

Es un concepto sencillo de entender pero no tan sencillo de aplicar. Entender el concepto permitirá al programador tomar decisiones más acertadas de cuándo o dónde han de generar el código HTML: directamente en la plantilla o desde JS. Incluir este concepto en la metodología de trabajo de todos evitará que de forma totalmente arbitraria nos encontremos con casos mezclados y sin coherencia.

Por lo demás, usamos – al igual que muchos – las convenciones de codificación que recomienda Crockford en su página:

http://javascript.crockford.com/code.html