Ay, Google, Google...

...quién te ha visto y quién te ve.

Después de la sonada falta de disponibilidad del servicio de webmail de Google, durante la cual -según parece- iba a acabarse el mundo, como bien comentan Lonifasiko en su txoko o GigA en su blog, me encuentro esta noche con un pequeño error en la página de iGoogle (Google convertido en portal personalizado que, os recuerdo, uso en combinación con Google Reader para organizar las fuentes de RSS que suelo leer). En concreto, acabo de intentar añadir un nuevo feed (realmente actualizar el de un blog que cambió de dirección... sí, vale, sé que soy un raro :P ). El caso es que, tras agregarlo, he intentado volver a la página principal de iGoogle, pero con escaso éxito. Tras esperar un buen rato (y hacer clic un par de veces en el enlace), la página ha dado un error. "Qué raro, me he dicho", y tras volver atrás en mi flamante Firefox, he posicionado el puntero del ratón sobre el enlace y...

¡Ups! ¿Google escucha peticiones en el puerto 2? ¿Desde cuando? Ni corto ni perezoso, he copiado la URL, la he puesto en otra pestaña del navegador, le he quitado el número de puerto y... ¡Tachan! iGoogle a su servicio.

He accedido al sitio de Nap  Online, y no me ha dejado hacer un lindo escaneo de puertos sobre la dirección de Google. Ni corto ni perezoso, he buscado otro escaner de puertos on-line (sí, en mi portátil tengo alguno instalado, en el pendrive también, pero ni tenía el primero encendido ni ganas de buscar el segundo, y el estar en el PC de trabajo de mi pareja, me ha servido para buscar esta herramienta on-line y que la entrada tenga algún enlace útil al menos, aparte de la mera curiosidad de lo que os cuento ;) ). En TCP/IP Port Scanner no le tienen miedo a Google, y me ha permitido darle una pasada a los puertos. Obviamente, el puerto 2 no está abierto ni por asomo.

¿Quién habrá tocado ese enlace en la web del buscador más conocido? ¿Pasarán en Google pruebas sobre la interfaz de usuario con herramientas tan útiles como Selenium? Con estas pruebas evitamos, tras tocar el código existente para incluir nuevas características, que las que ya funcionaban dejen de hacerlo. Y recordad, como dicen en mi pueblo: ¡si algo funciona, no lo toques zagal!

Doubler, automatizando la generación de pruebas unitarias

Cuando llevamos a cabo un desarrollo guiado por pruebas (TDD) ideal, las pruebas serán escritas con antelación al código que deberá implementar la funcionalidad deseada, y a continuación se escribirá este último, de forma tal que supere aquellas. Es decir, como hemos comentado en varias ocasiones, las pruebas unitarias forman parte de las especificaciones de los requerimientos que deberemos cumplir. Sin embargo, este entorno ideal de iteraciones (escribir pruebas, codificar, pasar las pruebas y refactorizar) no siempre puede darse. En ocasiones, por limitaciones de tiempo se prima el que la funcionalidad esté lista sin llevar a cabo pruebas unitarias, o bien “heredamos” código ya implementado, y antes de meternos de pleno con él optamos por crear una batería de pruebas que nos ayude a programar con algo más de seguridad.

En casos como estos, es bastante útil contar con generadores de código que automaticen la creación de un “esqueleto” de pruebas unitarias. En el caso de usar el framework de pruebas MSTest de Microsoft, bastará con tener un Visual Studio para que, seleccionando los componentes a probar, genere un proyecto de pruebas unitarias que podremos “rellenar”. Incluso usando Pex podemos conseguir pruebas unitarias que validen casos extremos, ya que realiza un análisis de nuestro código. Por cierto, esta herramienta de Microsoft que aún está en alfa únicamente funciona con las ediciones Team System de Visual Studio.

Sin embargo, no siempre queremos o podemos usar el framework de pruebas que nos propone Microsoft. Bien por políticas de empresa, por licenciamiento, o porque preferimos cualquier otro, la generación de las pruebas para MSTest requiere realizar una serie de cambios sobre el código autogenerado, como renombrar atributos de clases y métodos y refactorizar un poco los fuentes. Si preferimos NUnit o MbUnit para implementar nuestras pruebas, podemos usar Doubler para, a partir de un ensamblado .NET, generar el esqueleto de pruebas unitarias de forma automática. Doubler está disponible en el sitio de Google Code, y se trata de un add-in para Lutz Roeder’s Reflector, que posiblemente conozcáis bien si soléis trabajar con .NET. Su instalación es muy sencilla (basta con añadir la DLL correspondiente desde el menú de gestión de add-ins), y permite acceder a un menú contextual desde el que le indicaremos qué deseamos hacer con una determinada clase. Desde el mismo podemos llevar a cabo diversas acciones:

• Generación de pruebas: Con botón derecho sobre un tipo inmediato, la generación de pruebas hace aparecer una lista de propiedades configurables (lenguaje de generación, framework de pruebas, que incluye MSTest, NUnit y MbUnit, inclusión de atributos…) para la generación automática de código de pruebas. Tras pulsar sobre el botón de generación (que es tan grande que no lo parece), se creará un fichero de código de pruebas que deberemos completar con los Asserts correspondientes.


• Grabación de un generador: Se aplica a tipo abstractos, creando un stub para las pruebas. Un Test Stub es un objeto usado en un tests para reemplazar al componente real. En nuestro caso, el Recording Test Stub puede ser usado para verificar salidas indirectas de las pruebas. En cierto modo es como crear un inspector de comportamiento para el componente que está siendo sometido a pruebas.


• Generador de Fakes: Crea un falso objeto, basado en una clase abstracta, para ser usado en las pruebas sobre una clase base. El falso objeto, o fake, deberá dar una implementación alternativa a la funcionalidad que el objeto al que reemplaza.


• Wrapper o generador de interfaces: Aplicado sobre un tipo inmediato, crea una copia de la interfaz del tipo seleccionado, así como una implementación de la misma que redirige todas las llamadas a una instancia privada del mismo a través. Esto permite un desacoplamiento de las pruebas respecto al objeto.

La verdad es que el código que crea es bastante claro y nos puede ahorrar, como decía tiempo y trabajo repetitivo con un par de clics de ratón. Si al mismo le sumamos que Pex también cuenta ya con un add-in para Reflector (y que funciona siempre que tengamos Pex instalado en nuestra máquina, es decir, si contamos con un Visual Studio TS), lo cierto es que la herramienta se va a convertir en un compañero aún más inseparable de lo que ya lo era.

A continuación muestro algunas capturas básicas con la generación de unos métodos de prueba para una clase muy simple, a modo de Hola Mundo con Doubler ;) .

Un par de bloques de nuestro código a probar...

La estructura de la DLL para Reflector.

El menú contextual añadido por el add-in Doubler.

Estableciendo las propiedades para el código generado

Y nuestro código de pruebas, listo para ser completado y usado.

ALM, la gestión del ciclo de vida del software

Esta mañana asistí, junto a unos compañeros, a un seminario sobre el ciclo de vida del software (ALM) desde la perspectiva de Microsoft, es decir, mediante el uso de las herramientas que Team Foundation Server y la familia de productos de Visual Studio Team System nos ofrecen.

La verdad es que he de manifestarme como un convencido de las metodologías y su repercusión en el buen resultado de los proyectos de desarrollo. De poco nos sirve contar con buenos desarrolladores si los continuos cambios de requisitos terminan por minar su autoestima y su convicción de que el trabajo que realizan es el adecuado. Es decir, si son profesionales sometidos a todas las ocurrencias que tan genialmente plasma Ender cada semana en su Sinergia sin control.

Volviendo al seminario que nos ocupa, el ponente, Hadi Hariri, recientemente laureado como MVP C# 2008 de Microsoft, afrontó los contenidos con una aproximación que me pareció muy adecuada: plantear los problemas y posibles soluciones desde la perspectiva de la adopción de metodologías ágiles como Scrum y el desarrollo guiado por pruebas (el archifamoso TDD), para después, sin obviar que existen otras herramientas disponibles gratis, o con menor coste, plantear cómo se afrontaría un proyecto de desarrollo con las que nos ofrece Microsoft, con una integración bastante adecuada entre ellas: la gestión de plantillas de proyecto, documentación (especificación de requisitos, o historias de usuario en metodologías más ágiles), la asociación entre tareas, código desarrollado, pruebas unitarias y control de código fuente, integración continua… Sin duda, todo lo que vimos ya está inventado, y en mayor o menor medida, con más o menos configuración, podemos conseguirlo con otras herramientas libres o más baratas, aunque lo cierto es que para desarrollos .NET, la suite de utilidades que nos ofrece Microsoft es bastante interesante, aunque también habría que sentarse a echar cuentas sobre las licencias que tanto software y equipo nos requeriría. Posiblemente para un equipo medio o grande, es una buena opción, pero para desarrollos sobre múltiples plataformas o un equipo pequeño el traje, creo, puede quedarnos algo grande.

También estuvimos viendo un poco lo que está por venir con Visual Studio 2010, su editor de código en WPF, el generador de diagramas de secuencia para los objetos, similar al generado por herramientas como SequenceViz, que probé hace unos meses y me pareció bastante interesante. Y, por último, asistimos a la generación de pruebas sobre la interfaz de usuario, funcionales y de integración, gracias a Microsoft Camano, una herramienta para testers que permite, entre otras florituras, la grabación de videos de pruebas con sus resultados, la reproducción automática de pruebas grabadas en modo “macro”, de forma similar a como se llevan a cabo con NUnitForms o Selenium, para aplicaciones web y WPF (de lo que deduzco que los fans de Silverlight tendrán también aquí motivo de alegría y diversión futuras).

En resumen, una más que interesante charla, que nos hace augurar un futuro a medio plazo bastante prometedor para todos aquellos a quienes nos gusta “cacharrear” con el software. ¿Y vosotros, habéis jugado un poco con la (algo inestable aún, eso sí) CTP de Visual Studio 2010? ¿Qué os parece la tendencia de Microsoft a “reinventar la rueda” (haciéndola, eso sí, un poco más redonda y aplicándole mejoras como los radios al invento :) )?

¿Quién apunta a mi web?

En ocasiones echo un vistazo a las estadísticas que me va mostrando uno de los plugins que mantengo en el blog. Son menos detalladas y exhaustivas que las de Google Analytics, por ejemplo, pero lo suficientemente interesantes como para encontrar, por ejemplo, desde donde llegaron los visitantes a través de su HTTP_REFERER, y saber si nos están llegando desde lugares “normales”, o tenemos de nuevo a los amigos spammers dando la nota.

Uno de los enlaces que encontré hace unos días me llamó la atención, así que acudí al sitio web a ver por qué andaba un enlace a Lobosoft por allí, encontrándome con una interesante herramienta que puede ayudarnos, como otras que hemos presentado por aquí , a saber quiénes nos están enlazando desde sus páginas. Recordemos que el parámetro link: del buscador de Google nos permitía conocer páginas indexadas por el mismo que contuviesen enlaces a nuestra web, pero lo interesante de Backlink Watch es que, además, nos indica el tipo de enlace (si contiene, por ejemplo, modificadores como nofollow para que no cuente a efectos de PageRank), o el texto que contiene el enlace, por citar alguna de sus características.

Una sencilla e interesante herramienta que puede ayudarnos a conocer cómo “ve” Internet a nuestra web.

El triángulo mágico de Google

Mucho se ha escrito sobre usabilidad web y la mejor manera de presentar la información en un entorno en el que, o captamos la atención del visitante en unos instantes, o lo perdemos irremisiblemente. Sin embargo, hasta no hace mucho no era posible, salvo por estudios subjetivos, conocer cómo nos comportamos, de forma intuitiva, ante la presentación de un nuevo documento, de una nueva web.

Un ojeo rápido de la información que nos aparece en primer lugar, seguido de la lectura en diagonal de la misma, parecen ser las principales características del usuario típico de Internet. Así, se han publicado recientemente estudios que, según afirman, han encontrado el “triángulo mágico” del éxito de Google, por el cual la información relevante que el famoso buscador nos presenta está, justamente, donde debe estar. Un buen ejemplo de esto es el documento Eyetracking Search Marketing.

Aun estando de acuerdo en la importancia de un diseño adecuado para captar la atención y el interés inicial de los lectores, lo cierto es que considero que los usuarios habituales de un sitio web modifican sus hábitos al encontrar siempre en la misma posición determinados elementos. Es decir, que si yo visito el dominio www.loquesea.es y sé que en un lugar determinado de la página voy a encontrar el bloque de categorías, o las novedades, me dirigiré de inmediato allí. Igualmente, si en Google sé que los enlaces de la derecha y superiores son los patrocinados, posiblemente ni los mire, o si se me va la vista allí por lo llamativo del diseño (por ejemplo, por poner un mapa de Google Maps de la zona de los negocios publicitados) posiblemente no le preste la más mínima atención y de inmediato me dirija a los resultados que me interesan.

Todo esto, insisto, desde mi perspectiva. Por ello, aunque el tipo de estudio me parece más que interesante, me parece demasiado “ideal” para los objetivos de Google. O lo mismo soy el único “bicho raro” que elude la publicidad del buscador. ¿Qué os parece a vosotros? ¿Soléis caer en las redes de la empresa publicitaria más global que jamás existió?

Computación verde

Entre las revistas electrónicas que suelo leer o que, al menos, me gusta examinar, se encuentra The Architecture Journal, de Microsoft. Es posible, como en otros casos, suscribirse a la edición impresa de la misma, o bien descargarla gratis de Internet. Aunque es editada en español (y en otros idiomas sólo aptos para mentes inquietas, como el chino), estas ediciones suelen ir retrasadas en varios números con respecto a la anglosajona.

El caso es que el último número de la revista, el 18, trata sobre computación verde, o lo que es lo mismo, saber qué podemos hacer los desarrolladores, ingenieros de sistemas y personal informático en general para contribuir con un pequeño granito de arena, desde nuestro trabajo, a impactar algo menos en nuestro ya maltratado medio ambiente.

Trata este número, entre otros temas, el de la traída y llevada virtualización para el ahorro de costes de inversión y energéticos, sobre técnicas de enfriamiento en granjas de servidores o acerca de la impotancia del diseño de nuestras aplicaciones para hacerlas más eficientes y, por tanto, más ecológicas. En resumen, un número más que recomendable para aquellos que deseen contribuir con su trabajo a la mejora de nuestro medio ambiente y, por lo demás, a todos aquellos que deseen ser mejores profesionales. ¿Se escapa alguien? Me parece que no ;) . Pues venga, ¡a descargar el The Architecture Journal nº 18!