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!

KeyLed

Debido a un accidente navideño con el teclado del ordenador, que incluyó el agravante de la sidra ecológica, tenemos desde hace poco uno nuevo, inalámbrico, que con estas ideas brillantes para abaratar costes, resulta que no tiene LEDs indicadores del estado de las teclas de bloqueo de mayúsculas, numérico y de desplazamiento. A resultas de esto, me ha picado el gusanillo de la programación rápida, y he creado una aplicacioncita en .NET que se encarga de controlar el estado de esas teclas e informa al usuario mediante un icono de notificación en la barra de sistema.

La verdad es que es una aplicación bastante simple, pero ya que hacía tiempo que no subía nada de programación al blog, me ha parecido interesante dejarla aquí por si interesa a alguien y, de paso para recabar la opinión de los incondicionales ;) . Su nombre es KeyLed.

También incluyo la parte relevante del código, que no es demasiado extenso: Se trata de un WinForm que muestra el estado de las teclas en varios checkboxes, y que al ser minimizada queda en el systray. En todo momento, muestra un bocadillo con el estado de las teclas de bloqueo, mediante el uso de un temporizador que va comprobándolo cada cierto tiempo (500 milisegundos). He probado utilizando un delegado para el evento Idle de la aplicación, pero no se refresca tan a menudo como debiera, de ahí el uso final del temporizador.

[Csharp]
{
public partial class KeyLed : Form
{
const int Interval = 500;

public KeyLed()
{
InitializeComponent();

KeyLedTimer.Interval = Interval;
KeyLedTimer.Enabled = true;
}

[DllImport("user32.dll", CharSet = CharSet.Auto, ExactSpelling = true, CallingConvention = CallingConvention.Winapi)]
public static extern short GetKeyState(int keyCode);

private void KeyNotifyIcon_MouseDoubleClick(object sender, MouseEventArgs e)
{
//Hacemos visible el formulario
this.Show();
this.WindowState = FormWindowState.Normal;
//Ocultamos el icono de la bandeja de sistema
KeyNotifyIcon.Visible = false;
}

private void KeyLed_Resize(object sender, EventArgs e)
{
//Si el estado actual de la ventana es "minimizado"...
if (this.WindowState == FormWindowState.Minimized)
{
//Ocultamos el formulario
this.Hide();
//this.Visible = false;
//Hacemos visible el icono de la bandeja del sistema
KeyNotifyIcon.Visible = true;
}
}

private void KeyLedTimer_Tick(object sender, EventArgs e)
{
this.CapsLockCheckBox.Checked = (((ushort)GetKeyState(0x14)) & 0xffff) != 0;
this.NumLockCheckBox.Checked = (((ushort)GetKeyState(0x90)) & 0xffff) != 0;
this.ScrollLockCheckBox.Checked = (((ushort)GetKeyState(0x91)) & 0xffff) != 0;

KeyNotifyIcon.ShowBalloonTip(Interval, "", _numLock + _capsLock + _scrollLock, ToolTipIcon.Info);
}
}
[/CSharp]

Se me ocurren diversas mejoras, por ejemplo, que muestre la información de los leds cambiando el icono asociado al objeto NotifyIcon, de hecho funciona sin problema. Pero crear ocho iconos para esto me parece un pasote. Como con System.Drawing no he tenido que pelearme demasiado, a ver si existe una opción más eficiente que la que os presento. A partir del icono inicial, es posible usar el método ToBitmap() de la clase Icon para obtener un BMP en memoria sobre el que trabajar (por ejemplo, cambiando el color de un determinado pixel con SetPixel. Sin embargo, me parece poco adecuado tratar dinámicamente el icono, porque posiblemente sea mayor el tiempo de volver a dibujar el estado de los leds que cargar un icono distinto. ¿Alguna opinión al respecto? ¿Monto ambos sistemas y le hacemos pasar unos pocos benchmarks? ¿Merece la pena, realmente, todo esto? Jajaja.

Un saludo.

Actualización:
Acabo de darme cuenta, al encender el altavoz, del molesto efecto de "pop, pop" en el refresco del estado, al volver a pintar el bocadillo. Así las cosas, me da que no hay más opción que diseñarme el icono adecuado y actualizarlo dinámicamente. Así las cosas, vuelvo a la pregunta que planteaba al final de la entrada: ¿lo "repinto" en memoria, o cargo uno de una colección de iconos previamente almacenados?