sábado, abril 22, 2006

Del tiempo y otas hierbas - o como hacer una prueba de concepto

Hace poco hice un comentario respecto al desarrollo en serio. Es fácil hacer ese tipo de comentario sin más, cualquiera que lo lée puede decir, pero si yo lo hago bien, yo no soy de los que este hombre habla, yo si me tomo mi trabajo en serio.

Por eso mismo, decidí plantear un ejemplo explícito y solucionar a la vez un "problema" diario, o si se prefiere, una tarea habitual.

Concretamente hoy vivo en la cota mil, y aunque he pensado en cambiarme de casa eso no será tan rápido como quisiera. Y aunque lo haga, la idea igual es cambiarse a un lugar que está más o menos a la misma altura, con nieve en invierno y un clima algo diferente al de Santiago propiamente tal.

Por lo mismo, mi señora, diariamente, para saber que ponerse al día siguiente debe consultar algún sitio, o ver las noticias, y muchas veces yo soy el encargado... no, no es una gran tarea, usualmente consulto Accuweather, el problema es que en este sitio tengo que hacer varios pasos para ver el tiempo de Santiago.

Repito, no es gran problema, sólo hay que cargar la página principal y allí la opción World, y luego ingresar Santiago, Chile y entonces revisar el pronóstico, que además, presenta diferente dependiendo de la hora.

Si, un link en favoritos facilitaría las cosas, si, no me toma más de tres o cuatro minutos. Pero es un ejemplo fácil de como se puede construir una aplicación.... asi que el primer objetivo, desarrollar un programa que sea capaz de conectarse al sitio, bajar la página correspondiente y procesarla para sacar los datos del clima y enviárselos por mail a mi señora y a mi, así, lo único que tengo que hacer es ver mi correo y voilá, asunto resuelto.

Ok, el proyecto está definido y es simple. Ahora, ¿cuales son los pasos a realizar? El primero y más simple, ver que tecnología es la apropiada y hacer una prueba de concepto. Es decir, verificar que la tecnología seleccionada (si no la hemos usado nunca) opera como pensamos.

Pues bien, la tecnología seleccionada es .Net y C#, en particular, los mecanismos integrados que tiene de WebClient.

Con eso en mente, escribí el siguiente código:


using System;
using System.IO;
using System.Net;

namespace TestConcept
{
class Program
{
static void Main(string[] args)
{
WebClient web = new WebClient();
String data;

// Lee sitio y carga en un string
using (StreamReader reader =
new StreamReader(web.OpenRead(args[0])))
{
data = reader.ReadToEnd();
reader.Close();
}

// Graba el string en un archivo
using (StreamWriter writer = new StreamWriter(args[1]))
{
writer.Write(data);
writer.Close();
}
}
}
}


Primer resultado, el código es simple y bastante elegante (aún podría ser más corto, haciendo que no pasara por un string como buffer auxiliar, pero haría que fuera algo más difícil de leer y tendría menos puntos de control en el caso de que uno necesitara debugear), .Net se encarga de realizar la mayor parte de la tarea, por lo cual, por el momento voy a aceptar el nivel de abstracción que esto significa (sin ponerme a pensar, por muy cierto que sea, en lo que se puede ver en este link)

Segundo, la aplicación, pasándole los siguientes argumentos:

http://wwwa.accuweather.com/world-forecast.asp?partner=accuweather&myadc=0&traveler=0&
zipcode=SAMCLCI011SANTIAGO&metric=1


y

c:\temp.html

Funciona exactamente como uno esperaría, en menos de un segundo se genera un archivo de 52 Kb con el html que usualmente el browser parsea, listo para comenzar a procesarlo, pero, claro, esa es la continuación de esta historia.

Nota: Una cosa que es bueno indicar, el código anterior tiene 27 líneas, de las cuales 10 corresponden a abrir llaves y cerrar llaves, al final 8 líneas de código hacen todo, pero igual, en 8 líneas de código se pueden reflejar diferencias fuertes de estilo.

Lo más notorio, pues bien, el código anterior es Data Drive, es decir, tiene un comportamiento genérico que cambia dependiendo de los datos que se le entreguen, por ejemplo, yo podría pasarle el link a Emol y guardar el resultado en otro archivo.

Alguién puede decir, pero si eso es lógico y evidente, pero no es habitual que los desarrolladores hagan eso, lo habitual es que vengan direcciones en duro, que en un programa como este puede no tener efecto, pero cuando uno lo lleva a desarrollos más grandes demuestran por que hacemos artesanía en vez de ingeniería.

No hay comentarios.: