Otra de las características más visuales del nuevo Internet Explorer son los Web Slices:

A Web Slice is a preview of your favorite site or service available directly from the Favorites Bar of your browser.

En la galería de complementos española hay ya un montón para todos los gustos, desde reproductores de vídeo (como el de Telecinco) o el del tiempo de Terra, ambos en Silverlight.

Desarrollar un Web Slice es muy sencillo, funcionar como nosotros queremos y que además sea atractivo visualmente mucho más complicado. Durante los próximos posts iremos viendo las distintas “configuraciones” que puede tener un Web Slice, los problemas con los que nos podemos encontrar y cómo solucionarlos :)

Y sin más preámbulos… ¡empezamos!

hslice, entry-title & entry-content

Para hacer un Web Slice de un contenido en una página ya hecha solo tienes que acordarte de estas tres palabras.

Imaginemos que tenemos un div como el siguiente en una de nuestras páginas y queremos convertirlo en un Web Slice

   1: <div>

   2:     <h1>El Top Ten de XBOX</h1>

   3:     <ul>

   4:         <li>Mass Effect</li>

   5:         <li>Fallout 3</li>

   6:         <li>Gears of War 2</li>

   7:     </ul>

   8: </div>

Lo único que tendríamos que hacer es añadir un id y la clase hslice al contendor principal, entry-title al título que queremos que tenga nuestro Web Slice en la barra de favoritos del usuario, y entry-content al contenido que se le mostrar al usuario cuando el usuario pinche sobre el título. El resultado sería el siguiente:

   1: <div id="topten"class="hslice">

   2:     <h1 class="entry-title">El Top Ten de XBOX</h1>

   3:     <ul class="entry-content">

   4:         <li>Mass Effect</li>

   5:         <li>Fallout 3</li>

   6:         <li>Gears of War 2</li>

   7:     </ul>

   8: </div>  

Una vez publicadas las modificaciones y si nos vamos a la página veremos que al pasar el ratón por encima del contenedor este es rodeado por un cuadrado verde y el icono de Web Slice aparece en la esquina superior izquierda. También podemos observar que el “Feed Discovery Button” ha cambiado la imagen que tenía antes de RSS por la de Web Slice:

Pinchando en cualquiera de los dos icónos de Web Slices el usuario podrá suscribirse y recibir las actualizaciones que hagamos directamente en su barra de favoritos.

Y ya tenemos nuestro primer Web Slice :) No ha sido tan doloroso, ¿verdad?

El menú para los próximos posts es: tipos de Web Slices (¡hay varias formas de hacerlos dependiendo de lo que busquemos!), estilos en los Web Slices, funcionamiento del sistema de actualización, navegación y links, Web Slice con contenido rico (Silverlight y Flash),  Autenticación y problemas frecuentes (y cómo resolverlos), ¡y no precisamente en ese orden!

FAQ del día

• ¿Por qué necesito añadir un id? En una misma página puede haber varios Web Slices. El navegador tiene que ser capaz de identificarlos inequívocamente para que su motor de actualizaciones sea capaz de reconocer cuando ha habido una actualización. El id es necesario incluso en el caso de que tengamos un solo Web Slice
• ¿Tengo que definir hslice, entry-title y entry-content en mi hoja de estilos? No, estas clases están pensadas solo para indicar a IE8 la presencia de un Web Slice.
• ¿Qué pasa si ya tenía definidos esos estilos? No pasa nada, esos estilos se seguirán aplicando y el navegador seguirá reconociendo que es un Web Slice. No obstante es altamente recomendable no modificar el comportamiento de hslice (que aparezca un cuadrado verde y el icono correspondiente) para mantener la homogeneidad a lo largo y ancho de la web :)

Pequeño post para que los cuatro gatos que me lean sepan que sigo vivo y que últimamente he estado muy ocupado con la preparación de un gran evento. Además parece que durante las próximas tres semanas no voy a poder postear nada tampoco (es lo que tiene irse de viaje a Japón :D) pero a la vuelta publicaré un par de extensiones para blogengine que he programado y una aplicación para descomprimir, ordenar y borrar series automáticamente (perfecta cuando bajas tus torrents por RSS y tu nivel de vagancia ya llega a niveles insospechados). Amén de las otras cosas pendientes que tengo (más Javascript y “Big Ball of Mud”).

A disfrutar, y si no queréis ya lo haré yo por vosotros :P

No importa lo cabreado que esté. Este vídeo siempre me alegra el día :)

wherethehellismatt

Algunas de estas técnicas han sido guardadas celosamente por los grandes gurús de Javascript (y en general de cualquier lenguaje un poco moderno) pero hoy por fin verán la luz para que todo el mundo pueda convertirse en uno de ellos:

Arrays

Lo mejor para saber el número de elementos que tiene tu array no es usar la propiedad length ya implementada de serie. No. Lo mejor es tener una variable numeroElementos que vamos actualizado cada vez que hagamos una operación. De esta manera conseguimos varia ventajas:

• Para eliminar el último elemento añadido en un array no merece la pena usar el método pop(). Es "más mejor" hacer numeroElementos--;
• Seguro que alguna vez habéis tenido que hacer operaciones con los elementos de un array del tipo "el primero y el segundo, segundo y tercero, tercero y cuarto..." y siempre había un problema con el último (nos salíamos del array y teníamos una excepción, o teníamos que crear un caso especial o...). Pues gracias al consejo anterior nos olvidamos de esos problemas ya que ¡el elemento seguirá estando a pesar de hacer numeroElementos--!
• La mejor manera de vaciar por completo un array en JS no es hacer Array.clear(myArray); o myArray = []; o myArray = new Array();  Lo mejor es hacer myArray.length = 0;  El porqué no es mejor hacer numeroElementos = 0; es todavía un misterio para mí.

Condicionales

Como los compiladores a veces son un poquito tontitos, siempre está bien verificar dos veces (o más) que algo es cierto. if(variableBooleana == true)

Y vosotros, ¿qué secretos informáticos habéis descubierto en vuestros proyectos y podéis compartir?

Si alguna vez os ha tocado programar (o copypastear) algo en Javascriptquizás desconozcáis que Javascript es un lenguaje orientado a objetos y más concretamente basado en prototipos. ¿Qué quiere decir esto? Que si pensáis que sabéis programar en Java o C# y os mandan a un proyecto donde solo hay Javascript más os vale que os informéis un poco de cómo funcionan las cosas antes de poneros a tirar líneas como locos.

Orientación basada en prototipos

La principal diferencia con los lenguajes más comunes es la ausencia de clases (ya puedo sentir tu cara de escepticismo). ¿Cómo obtenemos herencia, polimorfismo y todas esas cosas tan grandiosas de la programación orientada a objetos? Pues principalmente mediante la "clonación" de objetos ya existentes (que sirven como prototipos) y añadiéndoles nuevos comportamientos. La otra manera es crear objetos nuevos de la nada (ex nihilo). Con Javascript además podemos añadir nuevas funcionalidades a objetos ya predefinidos.

Objetos ya predefinidos:

function outputBackwards(){
	for (i=this.length-1;i>=0;i--)
		document.write(this.charAt(i))
}

String.prototype.writeback=outputBackwards

Con esto hemos añadido un método (writeback())que nos permite imprimir una cadena de caracteres en sentido inverso al objeto String.

Objetos propios

function Person(){}
var anton = new Person();
anton.edad = 25;

Con esto creamos un objeto del tipo persona llamado anton y le añadimos la propiedad edad que tiene como valor 25. Para añadir nuevos comportamientos a nuestros objetos se haría de la siguiente forma:

function Person(){}

Person.prototype.dormir = function(){}

Va quedando más clara la cosa, ¿no? La herencia se resuelve aplicando el prototipo del objeto "madre" a nuestro nuevo objeto:

function AnObject(){}
function AnotherObject(){}
AnotherObject.prototype = new AnObject();

AnotherObject recupera el prototipo de AnObject (todas sus propiedades y métodos). Si queremos añadir nuevos comportamientos habría que hacer como en el ejemplo anterior. Creo que la flexibilidad y la cantidad de cosas horribles que se pueden hacer como meta alguien que no sabe, han quedado patentes :)

Y ahora que lo tenéis todo claro, de los dos códigos siguientes ¿cuál os parece que se ajusta mejor a la forma de pensar del lenguaje?

function myObject1(){
	this.method1 = method1;
	this.method2 = method2;
}

function method1(){
	//Something here
}

function method2(){
	//Something here too
}

function myObject1(){	
}

myObject1.prototype.method1 = function(){
	//Something here
}

myObject1.prototype.method2 = function(){
	//Something here too
}

En el primer caso solo le veo sentido si method1 y method2 se fueran a compartir entre varios objetos (no era el caso cuando lo vi), aunque siempre nos quedaría copiar el protoype del original como hemos visto antes. Si me equivoco que alguien me lo diga :)

Para el próximo post sobre Javascript pondré algo sobre la modificación de funciones y métodos de forma dinámica, que es algo curioso.

Seguro que alguna vez os ha tocado algún proyecto en el que al ver el diseño o el código habéis dicho: "pufff, esto tiene un tufillo a mierda fresca que no veas". Pues ese es el olor de vuestro software. Y es que es cierto aquello de que la mejor métrica para media la calidad del código es la siguiente:

El proyecto en el que estoy trabajando ahora huele tanto que ninguno de la empresa se quiere acercar al grupo de desarrollo. Por supuesto, el código tiene infinitos años y a cada nueva versión se le han ido añadiendo nuevas funcionalidades que más bien eran parches sobre un diseño pobre y mal pensado. Pero... ¿cómo identificar esos olores? Brian Foote y Joseph Yoder han realizado hace ya tiempo un artículo que se llama Big Ball of Mud que probablemente os suene a todos (y sino ya lo estáis leyendo, no tiene desperdicio).

While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed. This paper examines this most frequently deployed of software architectures: the BIG BALL OF MUD. A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture.

En el paper se identifican las principales causas y los patrones que llevan a que una arquitectura sea considerada una "Gran Bola de Mierda". Durante los próximos posts los iré comentando además de poner algún ejemplo relacionado con el glorioso proyecto en el que tengo el honor de trabajar. Hasta entonces, happy coding!

Por si alguien tenía interés en volver a leer algo de lo que había escrito en la v1.0 del blog, he subido todos los posts anteriores. Que los disfrutéis :)

se está de vacaciones :)

Y aún me queda otra semana!!

Una de las nuevas características de Vista que más me gustan (porque aunque no os lo creáis tiene nuevas cosas y algunas hasta útiles) es el Reliability Monitor. Esta pequeña maravilla le da una puntuación de estabilidad (o fiabilidad o como os de la gana) de 0 a 10 a tu ordenador. Que le has instalado un montón de mierda, tu puntuación baja. Que además las aplicaciones dejan de funcionar sin más, también baja. Que has instalado algún parche de seguridad, para abajo arriba. Que hace 10 días que no se te rompe nada, pues ganas unas decimillas. Se acabó eso de que tus familiares te digan "Pero si nosotros no hemos hecho nada". Ahora sabrás qué día instalaron(y des) Kazaa porque un vecino suyo se lo aconsejó.

En el nuevo proyecto en el que estoy me he tenido que instalar un montón de programas y librerías absurdas de GIS, y esta es mi nota (un pin para aquel que adivine cuál es la aplicación que más veces me ha bajado la puntuación en toda la historia de esta instalación):

Por los pelos no llego al aprobado. A ver si en septiembre consigo quitármela de encima :P