ASP.NET MadGas

TDD 4 everyone

2008-01-17T18:18:00.000+01:00

Desconocido para muchos (para mí hasta hace año y medio), de los pocos que lo conocen, son menos los que lo usan (ni hablo de los que lo usan bien...). No obstante, hay gente que apuesta por TDD y aporta su granito de arena con aplicaciones que lo faciliten y con documentación que realmente merece la pena.

Aquí quiero hacer un breve compendio de recursos, aplicaciones y de blogs que nos acercan TDD, para que nos demos cuenta de que TDD no es exclusivo de una tecnología, es una forma de trabajar:

TDD para Javascript en ASP.NET:

Herramienta: JSNUnit
Walkthrough: A simple TDD Example

TDD para Java:

Herramienta: JUnit
Artículos: JUnit Articles, Getting Started
Libro: Agile Java, by Jeff Langr

Nota: alguien más habituado que yo a trabajar con Java podrá rellenar esta lista, porque en este campo estoy bastante limitado

TDD para .NET

Hay mucha más información, para ello tenéis que ir a una de las mejores fuentes de información sobre TDD... Google.

Un saludo @Madrid

¿TDD de propiedades?

2008-01-17T15:11:00.000+01:00

Las propiedades tienen cierta lógica, de validación por ejemplo. Por ello, no sonaría descabellado que se lanzaran tests contra esas propiedades, pero ¿es realmente necesario?

En este caso es imposible decir un "Sí" o un "No" rotundo. Depende de la cantidad de lógica que tengamos en la propiedad en cuestión, puede ser o no necesario. Muchas veces usamos las propiedades cuando realmente un campo nos proporciona la misma funcionalidad, o cuando usamos clases que requieren inicialización, para inicializarlas y que no nos devuelvan NullException.

Cómo pone en este mensaje de un foro de Yahoo Groups da una guía bastante buena para esta duda y otras muchas:

Here's a rule of thumb for you: don't test anything when the complexity of the test approaches or surpasses the complexity of the code being tested (unless defect-free code is imperative, in whichcase you should expect to pay a high price to achieve it). In the caseof getters and setters, you're as likely to make an error in the test as you are in the code being tested (assuming you manually construct setters and getters; if not, then there can be no mistakes).

En resumen, no hagas tests de algo si los tests que lo prueban son igual de complicados o más que lo que está probando. Igual que puedes cometer un error en la aplicación, puedes cometerlo en el test.

Un saludo @Madrid

¿Por qué usamos y por qué no usamos TDD?

2008-01-17T12:27:00.000+01:00

Bueno chicos, volvemos al TDD, que ya llevaba mucho tiempo desde el último artículo en este sentido. La discusión que quiero plantear hoy es ¿Por qué usamos TDD? y ¿Por qué no usamos TDD?

La verdad es que TDD no es una de las técnicas más utilizadas dentro de las metodologías. He tenido la suerte de conocerla y utilizarla en casos reales, que es donde se ve qué es lo que aporta y que es lo que no.

Varias veces hemos visto el famoso gráfico de los costes de los cambios según la fase en la que está el proceso. Evidentemente, un cambio en la fase de requisitos afecta bastante menos que un cambio cuando la aplicación está a punto de entregarse. Para refrescar la mente, dad un vistacillo a esta página.

Partiendo de que estamos de acuerdo con ese gráfico y, asumiendo que siempre ha habido, hay y habrá cambios no planeados en nuestra aplciación (cambios en los requerimientos, errores en el diseño que obligan a tocar módulos, mejora y optimización del rendimiento...), tenemos que encontrar una forma de poder absorver esos cambios con el mínimo impacto.

La solución es el desarrollo iterativo. Antes de aplicarlo, leed este artículo para poder aplicarlo lo mejor posible. La base de este modelo, es ir desarrollando la funcionalidad de mi aplicación poco a poco. Simplificando mucho este proceso, podríamos tener el siguiente caso con la tan manida calculadora.

Hablamos con el cliente y nos dice que quiere una calculadora. Pero no quiere una calculadora normal y corriente, quiere una adaptada a su negocio. Iniciamos la captura de requisitos.
Conforme llegan los primeros requisitos (que sume y que reste), el equipo de desarrollo comienza a implementar esas dos funcionalidades.
Para cuando nos llegan otros dos requisitos (multiplicar y dividir) nuestra aplicación ya tiene el código necesario para sumar y restar, y estamos probándolos.
El equipo de desarrollo ha acabado de probar los dos primeros requerimientos y empieza a desarrollar los otros dos. Mismo procedimiento: implementacion + pruebas + correccion de errores.
Entre medias, el usuario quiere ver una demo de lo que vamos haciendo hasta ahora. Como nos movemos por funcionalidades concretas, podemos enseñarle la parte de sumar y restar. En caso de que hubieramos hecho todo en bloque, no tendríamos nada acabado, y no podríamos enseñar nada.
Una vez vista la demo, nos dicen que no se deberían poder meter negativos en la suma, pero sí en la resta. El equipo de desarrollo adapta esa parte de la aplicación. La resta no se toca y siguen trabajando con la multiplicación y la división.
Pasa el tiempo y, tras repetirse los puntos 1-6 varias veces, se entrega la aplicación a los usuarios para un UAT (test de aceptación del usuario). Concluyen que falta funcionalidad, que no se acordaron de decirnos porque lo daban por supuesto... No pasa nada, volvemos al punto 1, sabiendo que el resto de la aplicación no debería tener excesivo impacto.

Esto no es siempre tan fácil y tan teórico. Surgen prisas y nos saltamos puntos. O juntamos puntos. Además, el trabajo en equipo tiene particularidades que hacen que algunos pasos sean más complicados que otros.

Este desarrollo por ciclos se coplementa muy bien con TDD. Tests que prueban la funcionalidad (tanto que se cumplen los requisitos, como que los resultados son los correctos). Esos tests siempre están y me pueden decir qué es lo que debo hacer. Como dice Dan North en su blog:

I had introduced a bug. Bad me. Solution: Fix the bug.
The intended behaviour was still relevant but had moved elsewhere. Solution: Move the test and maybe change it.
The behaviour was no longer correct – the premise of the system had changed. Solution: Delete the test.

Son un punto de partida. Nueva funcionalidad necesitará nuevos tests, pero los que estén no cambiarán. Cambios en la funcionalidad necesitarán cambios en los tests e, incluso, algunos nuevos. Errores en la lógica de la aplicación necesitarán cambios en los tests o más tests o tests más precisos.

Nunca tengais miedo de cambiar un test si veis que no prueba lo que debe de probar.

Tras esta introducción, vamos a analizar las preguntas del principio:

¿Por qué no usamos TDD?

Empezamos con la negativa. Las causas más comunes son:

No sabemos que existe, o, si lo sabemos, no sabemos cómo se aplica. Efectivamente, nadie nace sabido, pero existe una cantidad brutal de libros y de documentación sobre Agile, TDD, BDD, Testing...
Es dificil montar un equipo que sepa usar TDD, y sin miedo. Algún día debe ser el primero. Por esa regla de tres, nadie habría empezado a usar OOP o los Web Services. Ante todo, que la gente que debe enseñarlo, se haya documentado muy bien y tenga una mínima experiencia.
Tardamos más en desarrollar la aplicación. Esto es verdad, pero los que lo dicen como excusa deben decir también que el desarrollo es sólo una de las fases de un proyecto, que generalmente no llega a la mitad del tiempo del proyecto. Se alarga la fase de desarrollo, pero a cambio, se acortan la otras. Para ser más precisos, no es que se acorten, sino que se solapan.
Mantener Tests + Codigo es más costoso que Mantener Código. Falso. En una aplicación donde un cambio afecta a 6 proyectos y 40 clases, es mucho más sencillo cambiar el código y ejecutar automáticamente los 300 tests que haya, para ver si afecta en algún otro punto, que ponerte a probar la aplicación exhaustivamente punto por punto y opción por opción.
Tener tests, añade labor de documentación. Sí, totalmente de acuerdo, pero eso era bueno, ¿no? Más documentación, más informción, mejor mantenibilidad.
Desconocimiento de herramientas. Visual Studio Team System 2005 integra el desarrollo y los tests, y permite automatizarlos. Visual Studio 2008 también trae los proyectos de test y, para los más humildes, siempre podéis usar NUnit junto con una Express Edition.

Y ahora, ¿Por qué usamos TDD? Muchas de las respuestas se han dado en los 6 puntos anteriores, pero podemos añadir más.

Es una garantía de funcionamiento. Con unos tests bien diseñados, el hecho de pasar todos los tests, implica que nuestro código cumple los requisitos.
Implica mayor conocimiento de la aplicación. Diseñar e implementar un test requiere saber exactamente qué es lo que debe de ejecutar nuestra lógica. Es decir, nos permite ver una caja negra que debe de cumplir los test, que va a hacer que nos centremos en QUÉ hace (funcionalidad) y no en COMO lo hace (código).
No es exclusivo de un lenguaje. No es sólo de C#, ni VB.NET. Ni siquiera es exclusibo a .NET. Se puede usar en Java. Alguien que sabe TDD en un lenguaje lo sabe en todos.
Mezcla gestión de proyecto con desarrollo. Permite que los desarrolladores tengan una visión más global de la aplicación, porque deben saber los requisitos para poder desarrollar los tests.
Permite un análisis de efectividad. Cuanta más información tengamos de la evolución de un proyecto, mejor podremos detectar errores y subsanarlos, bien durante el desarrollo del proyecto, bien en el post-mortem. Los tests aportan información de cuanto código está testeado, cuanto funciona y cuanto no, cuanto influye un cierto cambio...
Da una garantía entre fases. Saber en plena fase de desarrollo que el tiempo de test se reduce da cierta tranquilidad.

Estos son algunos puntos a favor de TDD. Por supuesto, usarlo implica riesgos. Pero, no usarlo también.

Estáis invitados a dar vuestra opinión al respecto.

Saludos @Madrid

Model View Controller Pattern

2008-01-16T18:23:00.000+01:00

No se como es posible, pero, da igual que la aplicación que se está desarrollando sea de Windows Froms o ASP.NET, siempre aparecen líneas de código en los formularios, que no deberían estar allí.

Como pone en este artículo, esto dificulta testear los métodos de ese formulario (habria que hacerlo a mano). Por ello, debemos intentar separar la capa de presentación de la lógica de negocio.

Se puede utilizar el MVC (patron modelo-vista-controlador), que permite separar al máximo lo que corresponde al UI, al BL y la interacción entre ambas. Para ayudarnos, se está desarrollando un MVC Framework (que debería haber salido ya, pero no tengo noticias de ello; si alguien las tiene, feedbacks are welcome). la verdad, tengo ganas de que nos llegue ya esa preview para darle un vistacillo, porque muchas veces no usamos este tipo de patrones, simplemente, porque no abemos que existen.

Aqui teneis un walkthrough para implementar MVC sobre ASP.NET y aquí la guía dentro de la cual está metida, que tiene un link a la versión PDF, para que lo leais en el metro.

Un saludo @Madrid

SPOIL: Simplificando el acceso a SQL

2008-01-14T12:09:00.000+01:00

No te acostarás sin saber una cosa más, pero es que hoy estoy aprendiendo de tirón unas cuantas.
¿Qué es SPOIL? Son las siglas de Stored Procedure Object Interface Layer
Vale, pero ¿Que es SPOIL? Vale, lo pillo. SPOIL es algo así como usar el código que otros han escrito y probado, para que tu código sea más sencillo (programación orientada a objetos, vamos). Los chicos de Microsoft se han currado una librería que hace lo siguiente:

Permite un mapeo más eficaz entre tu DAL y la base de datos (en SQL, eso sí). Esto es, que si tengo que llamar a un SP que se llama Get_LastName y me devuelve el apellido de un usuario a partir de su ID (un entero), bastaría con que creara un método en el DAL con esa firma. Es decir, public string Get_LastName(int ID).
La propia librería se encarga de la converión de parámetros .NET a parámetros SQL. Simplemente hay que especificarle la cadena de conexión y el mapeo de parámetros.

Ya sabemos lo que es, pero, ¿es útil? Buena pregunta. He hecho algunas pruebas, pero no lo he usado en ninguna aplicación "real". Parece que se simplifica el mantenimiento, pero SOLO PARA SQL SERVER. Así, nos libramos de arrays conteniendo parámetros de SQL y líneas y líneas inicializándolos.

En contra, parece que se condensa demasiado el código, y a la hora de buscar errores tendremos que analizar en qué punto exacto está fallando (se acabó el típico mensaje de error y que sepas exactamente a qué parámetro se refiere). Además, debemos mantener una coherencia entre la nomenclatura en el código y en la base de datos. Otro contra es que usa Reflection, algo muy útil, pero muy lento. Tendremos que valorar el trabajo que ahorramos - el tiempo de procesador que añadimos.

En cualquier caso, os invito a hacer unas cuantas pruebas. Por lo menos el walkthrough que nos ofrecen en la MSDN.

Un saludo @Madrid

Errores comunes (I):"Esta aplicación es demasiado pequeña para desarrollarla por capas"

2008-01-14T10:31:00.000+01:00

"Esta aplicación es demasiado pequeña para desarrollarla por capas", "Para dos llamadas a base de datos, en vez de usar procedimietnos almacenados, lo escribo a fuego en el código", "Si solo tengo 5 formularios, ¿por qué usar CSS?",...

Aquí van 3 frases que muchos hemos oído y dicho (me incluyo en ambos grupos, muy a mi pesar). Hay muchas más y la idea de esta sección que hoy se inaugura en este blog es que caigan esos mitos que dicen que "sólo las grandes aplicaciones se desarrollan siguiendo patrones, técnicas para escalabilidad, seguridad...".

Así que hoy empezamos con la primera:
"Esta aplicación es demasiado pequeña para desarrollarla por capas"

¿Quien no ha oído alguna vez esta frase? Generalmente viene acompañada de expresiones como "no tenemos tiempo para andar haciendo capas"... Hombre, si la vida de tu aplicacion es de un par de meses, y se compone exclusivamente de un formulario con dos textBoxes, pues puede que tengas razón. Pero es que la mayoría de las aplicaciones tiene varios formularios, que modifican y leen datos en una base de datos y que procesan algún tipo de información, ¿no?

Basta con que la aplicación deba acceder a base de datos, para que nos planteemos seriamente meter una capa DAL (Data Access Layer). No hace falta meterla en otro proyecto de la solución. Basta con crear otra clase. Lo importante es que todo esté estructurado.
Puede que mañana, esa aplicación que ahora de basa en Acces, pase a basarse en SQL Server (o MySQL, Oracle...) y entonces tendré que tocar clases que no debería tener que tocar.
Y si trabajo en equipo, la justificación es mucho más obvia. Si el experto en aplicaciones y el experto en bases de datos no es la misma persona, es mejor que esté en dos clases distintas, para que puedan trabajar a la vez. Y si el experto en interfaces no coincide con ninguno de los otros, necesitaremos 3 capas...

Por capas, no quiero decir que deba estar cada una en una máquina, insisto, sino es simplemente a nivel de organización (podeis dar un ojo a este post, para ver la opinion que suscita la separación física). En este artículo, David Hayden, nos compara también la división en layers y la de tiers, pero además hace un inciso en la importancia del TDD para mantener las aplicaciones divididas en layers y simples.

¿Cuantas capas debo usar? Bueno, .NET nos permite diferenciar la presentación del código de la página. En caso de que la aplciación sea muy simple, podemos usar ese código para meter la capa de negocio. Pero en caso de que algo, lo que sea, de esa capa de negocio se use en 2 o más formularios, deberíamos usar otra clase aparte. Para el diálogo aplicacion-base de datos, debería haber otra capa. Sirva como truco, que ninguna clase a parte de estas del DAL debería importar ninguna librería que se llame SQL, o JDBC, u Oracle...

Bueno, la próxima vez intentaremos matar otro de esos mitos que ayudar, lo que se dice ayudar, no ayudan demasiado.

Un saludo,

Los 10 consejos para escribir aplicaciones Web con alto performance

2008-01-14T10:22:00.000+01:00

Antes de nada, disculparme por lo de "performance", pero no se me ocurría más que "rendimiento" y eso sería una sintesis excesiva y simplona en este caso.
En este artículo, Rob Howard nos da 10 consejos que deberíamos tener en cuenta todos los desarrolladores de aplicaciones Web. Mucho ojito al punto 1 (no se me había ocurrido, pero ya que lo comenta, se me ocurren una barbaridad de aplicaciones junto con la Enterprise Library) y al punto 9 (ya la he usado en alguna aplicación y, si tienes mucho código estático, como css y javascript externo, funciona genial).

El link es: http://msdn.microsoft.com/msdnmag/issues/05/01/ASPNETPerformance/

Ante todo, recomiendo fervientemente hacer caso de uno de los párrafos iniciales:

you can only learn how to write high-performance Web applications when you're faced with either fixing performance problems or running a high-throughput site.

Algo así como el castizo dicho de "la experiencia es la madre de la ciencia". Cada problema es una oportunidad de aprender, un reto. Y los retos nos hacen crecer (que bonito).

Un saludo :-) @Madrid

Seguridad a nivel de página en ASP.NET

2008-01-11T14:22:00.000+01:00

Buenas a todos, este es uno de los últimos post desde Madrid, y va a tratar sobre seguridad.

Cuando planificamos una aplicación, planificamos también quien va a tener acceso a la aplicacion que estamos desarrollando. La posibilidad más extendida es utilizar el web.config para configurar que usuarios van a poder acceder al site y quienes no.

Sin embargo, aqui vamos a analizar otra posibilidad que permite aplicar una cierta lógica a la autorización, más alla del simple "tú sí", "tú no", más orientada a objetos, pero menos a la escalabilidad que permiten los ficheros de configuración.

Supongamos que tenemos la página Default.aspx, Pagina1.aspx y Página2.aspx, y que quiero que sólo ciertos usuarios puedan acceder a esas páginas. Es un ejemplo simple que se hace facilmente con el web.config. Pero vamos a hacerlo con herencia.

Creamos una clase que se llame BasePage.cs, que herede de Page. Sobreescribimos el evento Init de la página, que nos permitirá ejecutar las acciones que queramos antes si quiera de que se genere el formulario.

La página quedaría así:

public class BasePage : Page
{
public BasePage() { }
protected sealed override void OnInit(EventArgs e)
{
if (!ValidateAccess())
throw new System.Security.Authentication.AuthenticationException();
base.OnInit(e);
}

private bool ValidateAccess()
{
WindowsIdentity identidad = WindowsIdentity.GetCurrent();
return (identidad.Name.Contains("nombreUsuario"));
}
}

Por supuesto, en el método ValidateAccess podríamos meter tanta lógica como quisieramos. Podríamos acceder a base de datos para comprobar si ese usuario tiene permiso para acceder en este momento a esa página, por ejemplo.

A partir de aqui, todas las páginas que hereden de esta clase, ejecutarán esa validación en el Init. Además, puesto que hemos incorporado la clausula "sealed", las páginas que hereden de nuestra clase no podran sobreescribir el método.

¿Y si el comportamiento no es el mismo para todas las páginas? Bueno, es más que probable que unas páginas tengan una lógica determinada, otras otra. Bastará con crear tantas clases como BasePage como criterios de seguridad tengamos y hacer heredar cada página de su correspondiente base.

Otra mejora consistiria en hacer el metodo ValidateAccess "virtual" para que cada página personalice su método para la validación.

Por supuesto, esto no debe aplicarse sin más. Hay ue analizar si es mejor este metodo que usar una distribución en carpetas, cada una con su Web.config. Queda a criterio del desarrolador.

Un saludo a todos :-)

Generar scripts para carga de datos

2007-11-19T11:46:00.001+01:00

Buenas a todos, antes de nada, disculpas por la ausencia pero he andado bastante liadillo... Aprovecho para mandar un saludo a Jaime y los dos David, especialmente al primero que es el que mantiene vivo esto en los últimos meses. Gracias.

Al tema. ¿Cuantas veces hemos tenido que preparar un paso a producción y nos ha tocado preparar los scripts para Sql Server 2005? Vale, es facil, si usamos la opción de Tasks-->Generate Scripts del SqlServer. Bien, pero... ¿y los datos? ¿y todas esas tablas de 1000 o más registros que nos ha llevado semanas ir rellenando? ¿Les damos a los encargados del paso a produccion una copia del excel con los datos y les decimos que copien y peguen?

Bueno, si elegis esa opcion, aseguraos de tener zapatillas deportivas y buena forma física, porque os van a dar yoyas hasta en la sopa.

Por eso os mando un link (y me lo mando a mi mismo), que genera un procedimiento almacenado que se ejecuta contra las tablas y nos devuelve un insert por cada fila. Luego la copiamos a un fichero .sql y todos tan contentos.

Lo han hecho nuestros amigos de CodeProject: http://www.codeproject.com/database/InsertGeneratorPack.asp

Espero que os sirva de algo...

VSS Remover

2007-10-31T09:24:00.000+01:00

Antes de nada un saludo a mis amigos Jesus, David y David. Espero que todo os vaya genial, tenemos que quedar para charlar algun dia no? digooooooooo

Bueno, la idea de este post es crear un programilla en C# para quitar las referencias que deja el Source Safe en nuestras soluciones/projectos. He estado leyendo cositas y generalmente la gente lo hace a mano porque unicamente lo tiene que quitar de una solucion con un par de proyectos. Pero, que pasa cuando tenemos... unas 10 soluciones con, digamos tres proyectos cada una? pues que ni te lo piensas, hay que automatizarlo de alguna manera.

Estos son los pasos que he seguido para quitar el binding:
1 - Go to the folder containing the solution files and delete the following:
mssccprj.scc
MyProject.vssscc
vssver.scc

2 - Open MyProject.sln in your favorite text editor and remove the following section:
GlobalSection(SourceCodeControl) = preSolution
...
EndGlobalSection

3 - Go to the folder containing the project files and delete the following:
MyProject.vbproj.vspscc
mssccprj.scc
vssver.scc

4 - Open MyProject.vbproj in your text editor and remove the following lines:
SccProjectName = "SAK"
SccLocalPath = "SAK"
SccAuxPath = "SAK"
SccProvider = "SAK"

Parece que no pero pero recorrerte toda la estructura de carpetas haciendo esto tiene que ser fatal asi que utilizamos un metodo loopDir para recorrerlo y dos funciones removeSolutionBinding y removeProjectBinding para quitar el texto que hace referencia al vss dentro de los ficheros .sln y .csproj:

private static void loopDir(string dir)
{
string[] dirs = Directory.GetDirectories(dir);
string[] files = Directory.GetFiles(dir);

foreach (string s in files)
{
File.SetAttributes(s, FileAttributes.Normal);
if (Path.GetExtension(s) == ".sln" || Path.GetExtension(s)== ".csproj" || Path.GetExtension(s) == ".vbproj")
{
removeBinding(s);
}
else if (Path.GetExtension(s) == ".scc" ||Path.GetExtension(s) == ".vssscc" || Path.GetExtension(s) == ".vspscc")
{
File.Delete(s);
}

}
// loop subdirs
if (dirs.Length > 0)
{
foreach (string d in dirs)
{
// call this method again
loopDir(d);
}
}
}

De esta manera recorremos el arbol de carpetas. Si nos encontramos un fichero de solucion o proyecto llamamos a eliminar binding y sino, si es un fichero de los que hay que eliminar pues lo borramos directamente.
Aqui estan las funciones de eliminar binding:

private static void removeBinding(string f)
{
switch (Path.GetExtension(f))
{
case ".sln":
removeSolutionBinding(f);
break;
default:
removeProjectBinding(f);
break;

}

}

private static void removeSolutionBinding(string s)
{
string line = string.Empty;
bool flag = false;
FileStream fs = new FileStream(s + ".temp", FileMode.CreateNew);
System.IO.StreamWriter sw = new StreamWriter(fs);
//Create reader
System.IO.StreamReader sr = new System.IO.StreamReader(s);
while (sr.Peek() != -1)
{
line = sr.ReadLine();
if (line.IndexOf("GlobalSection(SourceCodeControl)") == -1 && !flag)
sw.WriteLine(line);
else
//do not write endglobalsection line
flag = (line.IndexOf("EndGlobalSection") == -1);
}

sr.Close();
sw.Close();

File.Copy(fs.Name, s, true);
File.Delete(fs.Name);

fs.Close();
}

private static void removeProjectBinding(string s)
{
string line = string.Empty;
bool flag = false;
FileStream fs = new FileStream(s + ".temp", FileMode.CreateNew);
System.IO.StreamWriter sw = new StreamWriter(fs);
//Create reader
System.IO.StreamReader sr = new System.IO.StreamReader(s);
while (sr.Peek() != -1)
{
line = sr.ReadLine();
if (line.IndexOf("SccProjectName") == -1 && !flag)
sw.WriteLine(line);
else
{
flag = (line.IndexOf(">") == -1);
//need to write symbol ">" to close the tag
if (!flag) sw.WriteLine(line);
}

}

sr.Close();
sw.Close();

File.Copy(fs.Name, s, true);
File.Delete(fs.Name);

fs.Close();

}

Unicamente comentar que si tenemos la solucion y todos los projectos en el mismo arbol de directorios todo irá como la seda pero recordad que a veces para montar nuestras aplicaciones en local los projectos web están ubicados en wwwroot por lo que tendreis que seleccionar dentro de wwwroot la carpeta de vuestro projecto para quitar tambien el binding de ahí.

Un saludo amigos ;)

Como configurar un WebSite con autenticacion 'Forms' y dos paginas de Login.

2007-06-24T21:35:00.000+02:00

Bueno, lo primero saludar a mis amigos Jesús, David y David ;) que me han dejado un sitio en su blog para poder publicar cositas interesantes.

Vamos allá. Lo que necesitamos esta vez es tener un web site al que puedan acceder dos tipos de usuarios distintos a dos partes del site diferenciadas pero dentro de la misma aplicacion. Imaginemos un tipo de usuario alumno y un tipo de usuario centro. Los alumnos se pueden conectar para ver sus notas y los centros se pueden conectar para ver los alumnos que se han presentado a cada examen y las notas que han sacado de tal manera que compaten base de datos. Ahora nos preguntaremos, para que queremos un web site con dos accesos diferentes?, será mejor hacer dos web sites no? uno para cada tipo de usuario, con sus paginas y sus rollos no? pues si! pero..., jeje, el cliente lo quiere así y así lo tenemos que hacer.

La solucion que se nos ocurre a bote pronto es organizar el site en dos partes, una para alumnos y otra para centros. A nivel de root crear un web.config con la configuracion global y luego una carpeta para cada una de las partes con su propio web.config .
Hasta aqui todo bien, ponemos en el root el web.config y declaramos que la autenticacion va a ser del tipo 'Forms' y que redireccione a una pagina de login que pondremos en la raiz del site:

<authentication mode="Forms">
<forms name=".cookiename" timeout="20" protection="All" loginurl="login.aspx">
</authentication>

Ahora si intentamos poner la misma tag en el web.config de la carpeta alumnos para que redireccione a loginalumnos.aspx tachan!!!! application error:
It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS.
Esto es debido a que solo se puede declarar el tag authentication a nivel de aplicacion (en el web.config del root) y una sola vez.
Vaya por dios, entonces? como hacemos? si queremos tener dos paginas de login!.

Bueno pues tendremos que hacerlo de alguna manera que nos permita redireccionar desde la pagina login del root a cada una de las paginas de login dependiendo a donde queramos acceder. Una vez authenticados, crearemos un rol para el usuario (si es alumno 'Alumno' y si es centro 'Centro') y solo dejaremos acceder a las páginas dependiendo de este rol.
Para hacer esto, unicamente tendremos que agregar el tag de autorizacion a cada uno de los web.config:
Para la carpeta de alumnos:
<authorization>
<allow roles="Alumno">
<deny users="*">
</authorization>
Para la carpeta de centros:
<authorization>
<allow roles="Centro">
<deny users="*">
</authorization>

Además, para completar el web.config tendremos que añadir las tag "location path=" para todas las paginas que queramos que puedan acceder tanto usuarios registrados como anónimos (en este caso para la de login y para la de help). Si no ponemos esto, no nos dejaría entrar en la pagina de login porque no tenemos el rol correspondiente.

<location path="Login.aspx">
<system.web>
<authorization>
<allow users="*"/>
<allow users="?"/>
</authorization>
</system.web>
</location>
<location path="Help.aspx">
<system.web>
<authorization>
<allow users="?"/>
</authorization>
</system.web>
</location>

Ahora en la pagina de login,depues de comprobar que el usuario y pass son correctos, tendremos que añadir el rol:

public void CreateNewMemberTicket(string username, Role userRole, bool persistent)
{
//get user roles
string role = GetRoleName(userRole);
// Create a new ticket used for authentication
FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(
1, // Ticket version
username, // Username associated with ticket
DateTime.Now, // Date/time issued
DateTime.Now.AddMinutes(20), // Date/time to expire
persistent, // "false" for a non persistent user cookie
role, // User-data, in this case the roles
FormsAuthentication.FormsCookiePath);// Path cookie valid for
// Encrypt the cookie using the machine key for secure transport
string hash = FormsAuthentication.Encrypt(ticket);
HttpCookie cookie = new HttpCookie(FormsAuthentication.FormsCookieName, // Name of auth cookie
hash); // Hashed ticket
// Set the cookie's expiration time to the tickets expiration time
if (ticket.IsPersistent) cookie.Expires = ticket.Expiration;
// Add the cookie to the list for outgoing response
Response.Cookies.Add(cookie);
}

Con esto conseguimos añadir a la cookie de authenticacion el rol del usuario. Ya solo nos queda crearnos el objeto GenericPrincipal para que el usuario que está logeado pueda ver la pagina que solicita al servidor, es decir, despues de logearse si va a la pagina alumnohome.aspx tendremos que asegurarnos que el rol que tiene el usuario en ese momento es el de 'Alumno' y sino redireccionarlo a la pagina de login.

Esto lo hacemos en el metodo Application_AuthenticateRequest de la Global.asax (si no la tenemos la añadimos al website)

protected void Application_AuthenticateRequest(Object sender, EventArgs e)
{
if (HttpContext.Current.User != null)
{
if (HttpContext.Current.User.Identity.IsAuthenticated)
{
if (HttpContext.Current.User.Identity is FormsIdentity)
{
FormsIdentity id =(FormsIdentity)HttpContext.Current.User.Identity;
FormsAuthenticationTicket ticket = id.Ticket;

// Get the stored user-data, in this case, the roles
string userData = ticket.UserData;
HttpContext.Current.User = new GenericPrincipal(id,roles);
}
}
}
}

En la pagina de login del root debemos tambien redirigir a la de login de alumno o centro:

protected override void OnInit(EventArgs eventArgs)
{

string returnvalue = Request.QueryString.Get("ReturnUrl").ToLower();
if(returnvalue != null)
{

if(returnvalue.IndexOf("/alumnos/") != -1)
{
Server.Transfer("~/alumnos/Login.aspx");

}
else if (returnvalue.IndexOf("/centros/") != -1)
{
Server.Transfer("~/centros/Login.aspx")
}
}

base.OnInit(eventArgs);
}

HTH jeje,

Un saludo desde tierras del norte! Cuidaros ;)

TDD (El test antes del código) (y 3)

2007-05-31T17:06:00.000+02:00

Cogemos el test 1: Dado un -1 (ejemplo de entero negativo) y 2 (ejemplo de entero positivo), obtenemos una excepción (cumplimos la regla de negocio 2)

Codificamos el test:

using System;
using System.Collections.Generic;
using System.Text;
using NUnit.Framework;

[TestFixture]
public class CalculadoraTest
{
[Test, ExpectedException()]
public void Calculadora_Test_001()
{
Calculadora calc = new Calculadora();
calc.sumar(-1, 1);
}
}

Y codificamos lo mínimo para que funcione el test (que funcione no significa que pase):

public int sumar(int a, int b)
{
return 0;
}
}

El tets falla. Evidente, no? Esperabamos una excepción y hemos recibido un 0. Rehacemos el código hasta que pase el test.

public int sumar(int a, int b)
{
if (a < 0)
throw new Exception();
return 0;
}

Ahora pasa. Perfecto. Cogemos el segundo test.

Dado un 1 (ejemplo de entero positivo) y un -1 (ejemplo de entero negativo), obtenemos una excepción (cumplimos la regla de negocio 2)

Codificamos el test, comprobamos que falla…

[Test, ExpectedException()]
public void Calculadora_Test_002()
{
Calculadora calc = new Calculadora();
calc.sumar(1, -1);
}

Y cambiamos el código para que también soporte este caso.

public int sumar(int a, int b)
{
if (a < 0 b <0)
throw new Exception();
return 0;
}

Ahora pasa. Genial, pero no hemos acabado. Lanzamos de nuevo TODOS los tests para ver que el cambio no rompe algo que funcionaba.
¿Funcionan? Si, genial. Antes de ir al siguiente código, miramos a ver si se puede refactorizar algo…
¿Crees que aún es pronto? ¿Qué hay pocas líneas? Jaja Vemos que en los dos tests que hay hasta ahora, creamos un objeto Calculadora. Podríamos sacarlo de allí y meterlo a nivel general.
El código quedaría así:

[TestFixture]
public class CalculadoraTest
{
Calculadora calc;

[TestFixtureSetUp]
public void Init()
{
calc = new Calculadora();
}

[Test, ExpectedException()]
public void Calculadora_Test_001()
{
calc.sumar(-1, 1);
}

[Test, ExpectedException()]
public void Calculadora_Test_002()
{

calc.sumar(1, -1);
}
}

Cogemos el test 3: Dado un 1 (ejemplo de entero positivo) y un 3 (ejemplo de entero positivo), obtenemos un 4 (cumplimos la regla de negocio 1 y la 3). Repetimos los pasos anteriores…

Y falla… Bueno, corregimos el código para que pase (OJO a la jugada). Vamos a hacer que siempre devuelva un 4 (salvo que alguno sea negativo).

El test queda:

[Test]
public void Calculadora_Test_003()
{
Assert.IsTrue(calc.sumar(1, 3) == 4);
}

Y el código queda:
public int sumar(int a, int b)
{
if (a < 0 b <0)
throw new Exception();
return 4;
}

Parece que la jugada no tiene sentido, pero paciencia. De momento, no hemos metido ni una función demás en el código. Hace lo que le piden los test. Ni más, ni menos.

Cogemos el 4º test. Dado un 0 (ejemplo de frontera) y un 1 (ejemplo de entero positivo), obtenemos un 1 (cumplimos la regla de negocio 1 y la 3). Repetimos el proceso.
Ahora hacemos que devuelva siempre 2.

public int sumar(int a, int b)
{
if (a < 0 b <0)
throw new Exception();
return 2;
}

El test pasa pero si ejecutamos todos no. Es ahora cuando metemos el a + b.

Y pasan todos los test… genial.

Y así sucesivamente hasta el test 7 (incluido). Pasar estos tests no requerirá cambios en el código de la calculadora, pero el 8º sí.

Dado un 10001 (ejemplo de frontera numero grande) y 1 (ejemplo de entero positivo), obtenemos una excepción (cumplimos la regla de negocio 4). Esto requiere que metamos otra rama en los primeros IF.

Y así sucesivamente… nuevo test, que pase, refactorizamos, nuevo test, que pase, refactorizamos, nuevo test, que pase, refactorizamos, …

Al final nos queda la clase de test así:

[TestFixture]
public class CalculadoraTest
{
Calculadora calc;

[TestFixtureSetUp]
public void Init()
{
calc = new Calculadora();
}

[Test, ExpectedException()]
public void Calculadora_Test_001()
{
calc.sumar(-1, 1);
}

[Test, ExpectedException()]
public void Calculadora_Test_002()
{
calc.sumar(1, -1);
}

[Test]
public void Calculadora_Test_003()
{
Assert.IsTrue(calc.sumar(1, 3) == 4);
}

[Test]
public void Calculadora_Test_004()
{
Assert.IsTrue(calc.sumar(1, 1) == 2);
}

[Test]
public void Calculadora_Test_005()
{
Assert.IsTrue(calc.sumar(1, 0) == 1);
}

[Test]
public void Calculadora_Test_006()
{
Assert.IsTrue(calc.sumar(10000, 1) == 10001);
}

[Test]
public void Calculadora_Test_007()
{
Assert.IsTrue(calc.sumar(1, 10000) == 10001);
}

[Test, ExpectedException()]
public void Calculadora_Test_008()
{
calc.sumar(10001, 1);
}

[Test, ExpectedException()]
public void Calculadora_Test_009()
{
calc.sumar(1, 10001);
}

[Test]
public void Calculadora_Test_010()
{
Assert.IsTrue(calc.sumar(9999, 1) == 10000);
}

[Test]
public void Calculadora_Test_011()
{
Assert.IsTrue(calc.sumar(1, 9999) == 10000);
}
}

Y el código…

public int sumar(int a, int b)
{
if (a <> 10000 a > 10000)
throw new Exception();
return a + b;
}

Curioso que hayamos dedicado más de 50 líneas para testear 3, no? Puede parecer poco rentable, pero AHORA SABEMOS QUE EL CÓDIGO FUNCIONA Y CUMPLE LAS REGLAS DE NEGOCIO. A PARTIR DE AHORA, SI AÑADIMOS MÁS CÓDIGO, SABREMOS QUE EL FALLO ES DE LO QUE VAYAMOS AÑADIENDO, PORQUE EL CÓDIGO DE A SUMA, ESTÁ PROBADO.

Un saludo

TDD (El test antes del código) (2)

2007-05-31T17:03:00.000+02:00

Vamos a hacer un ejemplo sencillo. Una calculadora que suma y resta.
Primero, analizamos las reglas de negocio.
1- Dados dos numeros, debe sumarlos o restarlos.
2- Los numeros deben ser enteros y positivos.
3- El resultado debe ser también entero y positivo
4- La entrada no puede tener ningún valor mayor que 10000

Segundo. La lista de test. Nos tomamos nuestro tiempo para hacerla.
Vamos a verificar también que cumplimos las reglas de negocio.

Antes de hacer la lista, es conveniente hacer una lista de valores frontera que pueden ser causantes de problemas o, por una u otra razón, tienen alguna importancia.

En este caso, los valores frontera serían: 0 (por ser el límite entre positivos y negativos, que mencionan las reglas de negocio 2 y 3), 10000 (para comprobar la regla de negocio 4) y -1 y 1, por ser el anterior y el posterior al valor frontera 0 y 10001 y 9999, por ser el anterior y el posterior al valor frontera 10000.

Analizamos también que facetas de IDE de Visual Studio hacen que no tengamos que testear algunas reglas. Por ejemplo, no deberemos testear que pasaría si metemos un número decimal, pues el método SUMA no admitirá esos valores y fallará por sí mismo.

Lista de Test para la SUMA
(1) Dado un -1 (ejemplo de entero negativo) y 2 (ejemplo de entero positivo), obtenemos una excepción (cumplimos la regla de negocio 2)
(2) Dado un 1 (ejemplo de entero positivo) y un -1 (ejemplo de entero negativo), obtenemos una excepción (cumplimos la regla de negocio 2)
(3) Dado un 1 (ejemplo de entero positivo) y un 3 (ejemplo de entero positivo), obtenemos un 4 (cumplimos la regla de negocio 1 y la 3)
(4) Dado un 0 (ejemplo de frontera) y un 1 (ejemplo de entero positivo), obtenemos un 1 (cumplimos la regla de negocio 1 y la 3)
(5) Dado un 1 (ejemplo de entero positivo) y un 0 (ejemplo de frontera), obtenemos un 1 (cumplimos la regla de negocio 1 y la 3)
(6) Dado un 10000 (ejemplo de numero grande) y 1 (ejemplo de entero positivo), obtenemos 10001 (cumplimos la regla de negocio 1 y la 3)
(7) Dado un 1 (ejemplo de entero positivo) y 10000 (ejemplo de numero grande), obtenemos 10001 (cumplimos la regla de negocio 1 y la 3)
(8) Dado un 10001 (ejemplo de frontera numero grande) y 1 (ejemplo de entero positivo), obtenemos una excepción (cumplimos la regla de negocio 4)
(9) Dado 1 (ejemplo de entero positivo) y un 10001 (ejemplo de frontera de numero grande), obtenemos una excepción (cumplimos la regla de negocio 4)
(10) Dado un 1 (ejemplo de entero positivo) y 9999(ejemplo de frontera de numero grande), obtenemos 10000 (cumplimos la regla de negocio 1 y la 3)
(11) Dado un 9999(ejemplo de frontera de numero grande) y un 1 (ejemplo de entero positivo, obtenemos 10000 (cumplimos la regla de negocio 1 y la 3)

No cerramos la lista, porque si encontramos algún otro test, lo añadiremos.

A programar!!!!!

TDD (El test antes del código) (1)

2007-05-31T17:02:00.000+02:00

¿Qué es TDD?

TDD son las siglas de Test Driven Development (desarrollo guiado por pruebas), que no es más que una manera de tirar código basandonos en los resultados que debe dar.
Es una de las técnicas del eXtremme Programming, y tiene bastantes ventajas e inconvenientes.
Las ventajas:
El código es más fiable al estar más sometido a tests que el código normal.
Se desarrolla el código justo para que funcione. No se tiran lineas que no aporten valor.
Ahorramos tiempo en fases posteriores a la de build.

Los inconvenientes
La lista de tests con la que contamos debe ser lo más completa posible. Eso requiere conocer muy bien las reglas de negocio.
Hay que tener una cierta experiencia a la hora de desarrollar, que permita completar las (casi siempre) incompletas listas de tests.
Alarga la fase de build (acorta las posteriores), lo que no siempre se entiende en los proyectos.

El proceso para desarrollar con TDD sería:
(1) Analizar las reglas de negocio.
(2) Obtener una primera lista de tests (mala señal si es la definitiva) con lo que deberíamos obtener ante una serie de datos de entrada.
(3) Codificamos el primer test, lo lanzamos y comprobamos que el test falla.
(4) Codificamos lo justo para que el test pase y lo comprobamos.
(5) Pasamos al siguiente test.
(6) Lo codificamos, lo lanzamos y comprobamos que falla.
(7) Codificamos lo justo para pasar este test y comprobamos que pasa.
(8) Comprobamos que pasan TODOS los tests hasta ahora, por si hemos roto algo.
(9) Refactorizamos el código (en el test y el código)
(10) Volvemos a 5

Importante: si creemos que son necesarios más tests, porque hay situaciones que no hemos comprobado, añadimos los tests. No hay que tener miedo a corregir, sino a pensar que está bien algo que no lo está.

SQL Server 2005 y el tipo de datos XML: Configuración del esquema

2007-05-30T15:49:00.000+02:00

Escenario inicial

Tenemos una tabla donde una (o más) de las columnas son de tipo XML
Queremos crear un esquema que represente el contenido de esa columna para acelerar las queries que vayan contra esa columna.

Procedimiento

Cogemos un XML que sea representativo, que tenga todos los campos que vamos a necesitar.
Guardamos el fichero en disco.
Usando la aplicación XSD (Visual Studio Tools a Visual Studio 2005 Command Prompt) ejecutamos el comando XSD [nombre_fichero.xml]

Nota: es posible que de fallos porque haya caracteres extraños. Hay que quitar las Ñ, %, $, €, …

Abro el fichero que se ha generado (misma ruta y nombre que el origen, pero con XSD de extensión) con el Notepad.
El contenido es el esquema del XML elegido.
Voy al SQL Server 2005 y hago una nueva query:

IF EXISTS (SELECT *
FROM sys.xml_schema_collections
WHERE name = N'mySchema')
DROP XML SCHEMA COLLECTION mySchema
GO

CREATE XML SCHEMA COLLECTION mySchema
AS
'
CONTENIDO DEL FICHERO XSD
'
GO

Donde pone CONTENIDO DEL FICHERO XSD, meto el contenido del XSD.

Ejecuto la query. Si todo ha ido bien, se habrá añadido a la lista de esquemas de SQL Server.
Voy a la tabla, con el fin de modificarla. Voy a la columna XML y en propiedades, configuro la sección de XML.

Elijo el esquema que acabo de crear, del combo de Schema Collection y configuro Is XML Document como Yes.

Nota: si no aparece es posible que haya fallado el refresco. Cerramos la pestaña y la volvemos a abrir.

Damos a guardar los cambios de la tabla. Si todos los XML que estén presentes (si los hay) concuerdan con el esquema, no habrá problema y se guardará. Si alguno no concuerda, habra que hacer modificaciones en el esquema para que encaje. Uno de los posibles cambios que, seguramente, habrá que hacer, es distribuir los elementos simples (que no tienen sub-elementos), ya que la herramienta XSD suele colocarlos juntos al crear el esquema. De todas maneras, en los errores que da al guardar, nos indica qué campos esperaba encontrar y cuales ha encontrado realmente.

Documentando nuestra base de datos

2007-05-30T15:45:00.000+02:00

Muchas veces nos encontramos con una base de datos con gran cantidad de tablas, claves primarias y columnas. Y algunas veces, nos gustaría tener un pequeño inventario de todos estos datos, para poder sacar, de un vistazo, una visión global de la base de datos con la que trabajamos.

Hacer un documentador es muy fácil si sabemos lo que queremos buscar y cómo podemos obtenerlo.

Primero vamos a definir qué queremos buscar. Supongamos que queremos hacer un inventario con las tablas de nuestra base de datos, sus columnas y los procedimientos almacenados que están asociados.

¿Cómo obtenerlos?
Vamos a buscar en 2 vistas que nos ofrece SQL Server: Sys.Objects y Information_Schema (con sus variantes).

Paso 1
Obtener las tablas de la base de datos. Lo haremos con la query:

Select * from sys.objects where [Type]='U'

Para sacar otros elementos, basta con cambiar el tipo o no poner clausula Where, para obtener todas las filas.
Algunos tipos son:

F FOREIGN_KEY_CONSTRAINT
FN SQL_SCALAR_FUNCTION
IT INTERNAL_TABLE
P SQL_STORED_PROCEDURE
PK PRIMARY_KEY_CONSTRAINT
S SYSTEM_TABLE
SQ SERVICE_QUEUE
U USER_TABLE
UQ UNIQUE_CONSTRAINT
V VIEW

Paso 2
Vamos a buscar las columnas de la tabla en cuestión.

Select *
from Information_Schema.columns
Where Table_Name = 'nombreTabla'
And Table_Catalog = 'nombreBaseDeDatos'

Con esta query sacamos toda la información relativa a las columnas de la tabla en cuestión, como el nombre, si puede o no ser NULL, tipo de datos que admite, etc.

Ya tenemos toda la información relativa a las tablas y sus columnas. Ahora vamos a buscar información acerca de los procedimientos almacenados.

Paso 3
Obtener todos los procedimientos almacenados de la base de datos.

Select * From INFORMATION_SCHEMA.ROUTINES
Where Routine_Type = 'Procedure'
And Specific_Catalog = 'nombreBaseDeDatos'

Con esto obtenemos el nombre, la definición del procedimiento, la fecha de creación y de modificación, entre otras cosas…

Paso 4
Obtener los datos relativos a esos procedimientos almacenados. Usaremos la siguiente query para ello:

select *
From INFORMATION_SCHEMA.ROUTINES ISR
Inner Join INFORMATION_SCHEMA.PARAMETERS ISP
On ISR.ROUTINE_NAME = ISP.SPECIFIC_NAME
Where
ISR.Routine_Type = 'Procedure'
And
ISR.Specific_catalog = 'nombreBaseDatos'
And
ISR.Specific_Name = ‘nombreProcedimientoAlmacenado’

Esta query nos dará los parámetros de ese procedimiento almacenado, su tipo, su dirección, su nombre….

Con estos simples pasos puedo ir sacando la estructura de mi base de datos. Tirando de esas queries, es posible que encontréis mucha más información que la que os muestro.

Un saludo,

Buscando el Report ideal... (2)

2007-05-30T15:23:00.000+02:00

Cosas a tener en cuenta cuando damos formato a un report

Aquí van unas guías para que no se olvide qué hay que comprobar a la hora de dar formato. Es una checklist para confirmar que no nos dejamos nada cuando demos formato.

- ¿Está el Report dividido en Header, Body y Footer? Si falta algún elemento, justificarlo.
- ¿Está configuarado el ancho y alto de la página, así como los márgenes? Si no, al exportar no va a funcionar.
- ¿Está el mapa del report bien construido, aunque no se muestre en pantalla? Tened en cuenta que, por defecto, al exportarlo a Excel, se exporta el mapa en una hoja aparte. Cuidado que lo que se muestra en el mapa sea significativo (por ejemplo, que no se vean los identificadores que hemos usado para ordenar)
- Comprobar las columnas, que cada celda mantiene la anchura y altura a lo largo de los reports. Esto es, la columna “Nombre de cliente” deberá tener el mismo ancho y alto en todos los reports que hagamos.
- Las imágenes a mostrar son coherentes.
- Si se usa algún elemento para listas (“-“, “*”,…), nos aseguramos que se usa siempre y que se usa siempre el mismo.
- Cada campo se corresponde con su cabecera de columna… que el copy-paste es peligroso…
- Exportar a los formatos a los que el usuario pueda exportar y comprobar que se exporta bien (que no quedan columnas separadas en una sola hoja, que los símbolos que he usado se exportan bien, etc…)
- Hacer pruebas con campos largos y comprobar que están alineados tanto en horizontal como en vertical como deseamos.
- Si usamos drilling-down, expandir todos los campos posibles para ver como queda el report en el peor de los casos.
- Hacer una batería de pruebas en el servidor de reporting, puesto que hay cosas que con la preview del diseñador no se pueden comprobar, como son los tooltips y el javascript que hayamos podido meter.
- Comprobar los links, que van donde van y que encuentran las páginas o reports como esperan.

Una gran idea sería hacer un report con todo lo que queremos y definir una serie de pautas para los siguientes (definir pautas no significa copy-paste). Podríamos definir:
- El ancho que va a tener cada columna
- Los bordes de las celdas que se van a mostrar
- Que celdas tienen tooltip y cuál es el formato
- Como se va a definir la navegación, si la hay (va a ser sobre toda la fila o va a haber una celda concreta para navegar)
- La cabecera del report y el pie de pagina
- Los tipos de letra de cada celda, alineación vertical y horizontal y posibles efectos.
- Preparar unos datos de reporting que nos permitan “someter” a nuestros reports a las más descabelladas situaciones (esas que son imposibles de darse, pero que el cliente siempre lo logra…, y menos mal que muchos ni saben de informática)

Un saludo

Buscando el report ideal...

2007-05-29T15:38:00.000+02:00

¿Qué características debe tener el report ideal? Cuantas más y mejores herramientas tenemos, tenemos tentaciones de dejarnos llevar por aburridos wizards o complicar en exceso los reports.

Mi “mini-guia” del report ideal se basaría en los siguientes puntos:
1. Un report es específico: la información que se muestra es concreta. No debería tener información que no aporte valor al usuario. Tener un mega-report no es una buena solución, aún cuando el usuario crea que sí. La información debe estar estructurada.

2. Un report no debe reflejar TODO el estado de la empresa: hacer un report que no filtra por nada lo que viene de la base de datos, no tiene sentido. Un report que hoy me parece adecuado aunque no filtre por fechas, dentro de 10 años moverá tanta información que no será válido. Vale que en 10 años ese report habrá sido sustituido “n” veces, pero eso no es excusa…

3. Un report debe ser agradable al usuario. Ojo con los scrolls (el scroll horizontal es bastante incómodo para el usuario). Ojo con el formato del texto y ojo con el formato de la tabla.

4. Un report debe permitir cierta interactividad con el usuario. Incluir una cierta dosis de navegación permite al usuario organizar y leer más fácilmente la información.

5. Un report no es infinito. Si quiero mostrar demasiados datos, es posible que tenga que incluir un subreport o un link a otro report.

6. Lo que se muestra no tiene por qué ser lo único que hay. Incluir tooltips para mostrar más información poede ser una buena idea, en su justa medida. Meter tooltips en todos lados equivoca al usuario y le acaba haciendo pensar que tiene que ponerse encima de todos los campos para ver más datos.

7. El usuario debe saber qué va a pasar cuando haga clic en el report. Meter links a otros sitios sin ton ni son, puede equivocar al usuario, a menos que esté muy claro lo que hace.
Javascript, sí, pero sólo si ayuda. Mostrar un pop-up con información extendida, puede ser una buena idea. Mostrar pop-ups en todos lados, no es buena práctica.

8. El report se genera rápido (si es posible). Para ello, debo:

- Delimitar la información a mostrar
- Mejorar las queries que recogen los datos
- Minimizar al máximo el peso del report (imágenes, las justas)

9. La imagen del report es la imagen de la empresa. Lo cual requiere que TODOS los reports matengan unos criterios de formatos. Misma letra, mismo tamaño, mismas imágenes, mismo estilo en header y footer…

10.Un report no es una aplicación web. Si se da demasiada interactividad a un report, de la sensación de que es una página web más y eso no debería ser así. Si es así, es posible que no necesitemos Reporting Services, sino una página ASP.NET.

Un saludo

PD: Pido disculpas a David por usar tantas veces el término "report"... jaja

XSLT Debugging?????? Si, y muy fácil

2007-05-25T09:45:00.001+02:00

Si hace unos años me hablan de la posibilidad de debuggar .NET al nivel que se debuga ahora con Visual Studio, seguramente preguntaría "¿Qué es eso de .NET?".

Pues bien, en un momento en el que XML parece que se convierte en un standard de intercambio de información y en el que aparecen montones de tecnologías que, bien lo mejoran, bien lo complementan, bien hacen uso de él, voy poco a poco descubriendo herramientas que facilitan la vida.

Si hace poco descubrí la potencia de XSLT, ahora Visual Studio me sorprende con un debugger de XSLT.

¿¿¿Sorprendido??? Yo bastante... :-)

Primero, buscar el botón de XSLT Debugging.
En el menú: Tools-->Customize-->Pestaña de Commands. Busco la categoría de XML. Me aparecerán 4 posibles botones. Arrastro el “Debug XSLT” a la barra de herramienta. También vamos a arrastrar el “Show XSLT Output”, porque vamos a ver un pequeño “truco” al final.

Bien, ahora necesitamos un XSLT, lo abrimos. Doy al botón de debuggar XSLT y, si no tengo definido ningún XML que transformar, me pedirá que lo especifique. Lo selecciono marcando la ruta y ¡empieza la fiesta!

Se muestran dos ventanas: el XSLT y el XSLT output. El XSLT (poned puntos de interrupción, si no no vamos a ver nada… :-) ) aparecerá con la siguiente instrucción a debuggar.

Con F10 voy poco a poco navegando por las instrucciones y, a medida que los elementos HTML se van completando, irán apareciendo en la ventana de la derecha.
Por completar me refiero a, por ejemplo, tablas completas (no filas o columnas), labels, etc…

Si tenemos presente el XML y predecimos el flujo que debería seguir a lo largo de los Xsl:Otherwise y Xsl:If, podemos comprobar que el XSLT funciona como debe.

Mmmm ¿¿¿pero podría usar también la ventana de Watch para ver en que estado están las variables??? La respuesta es SÍ!!!
Pero no es tan facil como arrastrar la variable a la tabla. Ahora la ventana Watch entiende XPath. Es decir, si hay una tag en el XML que es Cliente/Nombre y quiero ver su valor, lo que debo hacer para comprobar que valor tiene ahora mismo esa variable es escribir en la ventana de Watch Cliente/Nombre/text()… XPath puro y duro…

Y también puedo comparar, buscar atributos…. Todo lo que XPath permite para consultar sus nodos. Ojo porque la ventana Watch no es una ventana para hacer queries contra el XML… porque analiza el XML según sonde está la ejecución del XSLT. Esto es, si estoy navegando por Empleados/Empleado, si accedo al nombre, será por medio de ./Nombre.

Y a partir de aquí, imaginación…

Un regalito, el botón de XSLT Output que hemos añadido antes abrirá la salida que produce el XSLT sin debuggar. La buena noticia, que vemos a la vez el XSLT y el resultado que produce. ¿La buenísima? Que lo que cambiemos en el XSLT se traduce directamente en el output.

Si es que programar está chupado….
Más fuentes:

http://msdn2.microsoft.com/en-us/library/ms255602(VS.80).aspx

http://www.google.com

Links para Patterns

2007-05-24T17:13:00.000+02:00

Hacer lo que otros ya han hecho es lograr despues del tiempo que ellos estuvieron trabajando en ello, llegar al mismo sitio que ellos llegaron (si no un poco menos lejos).

Es así, siempre ha sido y siempre será. Para eso nacen los patterns. "Cosas" que están hechas, probadas, requeteprobadas y documentadas. No se nada de patterns (nada de nada). Lo poco que he hecho en ese campo ha sido usar un par de patterns, pero no considero que sepa nada al respecto. No asbría explicarlo.
Mi amigo Jaime uso un día un Singleton, pero de verdad... sabiendo porqué y cómo. Así da gusto... :-)

Por ello, y a modo de referencia y compendio, ahí van una serie de links de la gente que SÍ sabe de esto:

About the Design Patterns in VB.NET (una buena guia de iniciación, con un poco de todo)
C# - State Pattern Example (un pattern para manejo de estado, en 1.1)
Model-View-Controller in ASP.NET 2.0 (pattern para simplificar la capa UI)

Un saludo

Diseño de aplicacion multi-capa (para arquitectos... y para todos los que teclean)

2007-05-24T16:26:00.000+02:00

Buenas,

Este artículo Introduction to Object-Oriented Tiered Application Design, es un gran redumen de qué es y como funciona el N-Tier design, incluyendo algunas consideraciones de validación y seguridad que no están nada mal.

Un artículo que todos deberíamos leer para entender porqué separamos en capas la aplicación... Entender lo que hacemos hace que seamos capaces de entender los retos que plantea.

2007-05-24T16:21:00.000+02:00

Vamos a dar una vuelta de tuerca más al control XML de ASP.NET.
Ya hemos visto como configurar un control XML. Ahora vamos a darle un poco de dinamismo.
Vamos a mostrar datos sacado de una base de datos.
Tenemos una tabla de empleados. Así mismo, como quiero que varios clientes puedan consultar la lista, voy a proporcionarles un Web Service que va a dar un XML con la lista de empleados. Así, cada uno podrá customizar como mostrar unos datos.
Esto es, vamos a proporcionar un Web Service que va a proporcionar a lo usuarios un XML con la lista. Luego, cada usuario tendrá un XSLT que mostrará lo que le interese, y como le interese.

Paso 1: La query

Mmmm queremos una query que nos devuelva un XML. En esta web tenéis varias formas de lograr ese output. Nos quedamos con la siguiente:

SELECT (CAST(( SELECT '') +
( SELECT EmpleadoId,
RTRIM([EmpleadoNm]) AS Nombre
,RTRIM([EmpleadoSNm])AS Apellidos
,RTRIM([EmpleadoAge]) AS Edad
,RTRIM([EmpleadoSabiduria])AS Sabiduria
FROM [TestingDB].[dbo].[Empleados]
FOR XML PATH('Empleado')) +
(SELECT '')
AS XML))

Bien, ya tenemos la lista de empleados, cada uno de ellos con el tag Empleado.

Ahora, a por el web service. Vamos a hacer que nos devuelva un XmlDocument (System.Xml). Esto permitirá al cliente manipularlo antes de darlo a la capa de presentación.

El Web Service sería así:

[WebMethod]
public XmlDocument GetEmpleados()
{

XmlDocument doc = new XmlDocument();

SqlConnection connection = new SqlConnection(@"Data Source=localhost\sqlexpress;Initial Catalog=TestingDB;Integrated Security=SSPI;");

SqlCommand command = new SqlCommand();
command.CommandText = "GetEmpleados";
command.CommandType = System.Data.CommandType.StoredProcedure;
command.Connection = connection;
connection.Open();

XmlReader reader = command.ExecuteXmlReader();

while (reader.Read())
{
doc.InnerXml = reader.ReadOuterXml();

}
reader.Close();
connection.Close();
return doc;
}

Ahora, ¡a consumir el web service!

Creamos un site y añadimos la referencia web. Añadimos un control XML, solo con ID y Runat=”Server”, nada más.
Vamos a usar un fichero cualquiera de transformación.
En la página, vamos a recogerlo con forma de XmlNode.

El codigo en el Load, sería:

protected void Page_Load(object sender, EventArgs e)
{
EmpleadosWS.Service servicioEmpleados = new EmpleadosWS.Service();
XmlNode node = (XmlNode )servicioEmpleados.GetEmpleados();
xmlViewer.DocumentContent = node.OuterXml;
xmlViewer.TransformSource = "~/App_Data/Transformador.xslt";
xmlViewer.DataBind();
}

No olvideis el DataBind!!!!!

Un saludo

Nota: es muy posible que se pueda hacer más optimizado... sobre todo la query. Cualquiera que quiera sugerir como hacer o mejorarlo, por favor, hagálo :-) .... y gracias

Object Oriented Programming con Javascript

2007-05-24T13:24:00.000+02:00

"Javascript es un lenguaje de niños", "Con javascript no se puede hacer casi nada" .... ¿Cuantas veces hemos dicho u oido esto?

Yo mismo lo encontraba (aún hoy lo encuentro, porque no se usarlo bien :-( ) tedioso, complicado e inmanejable... Lo que hace el no saber. No obstante, usarlo bien abre muchas posibilidades (usarlo mal hará que acabemos con un proyecto en el que cada fallo implique horas y horas de debugging).

Para usarlo bien, he aqui una serie de guias al respecto:
Create Advanced Web Applications With Object-Oriented Techniques
Ejemplo de menú usando OOP javascript

Un saludo, espero que os guste

FindAll de Generics

2007-05-24T13:11:00.000+02:00

Buenas a todos. Una de las ventajas de las listas, son la posibilidad de obtener otras listas con los datos filtrados de una primera.
¿Cómo lo haríamos? Supongamos que tenemos una lista de enteros y que queremos sacar dos listas, una con los pares y otra con los impares. El codigo sería el siguiente:

using System;
using System.Collections.Generic;
using System.Text;

namespace Pruebas_Lenguaje_C_Sharp
{
public class Find_All_Generics
{
public Find_All_Generics(List enteros)
{
if (enteros != null)
__enteros = enteros;
else
throw new Exception("List passed cannot be null");
}
private List __enteros;

public List Enteros
{
get
{
if (__enteros == null)
__enteros = new List();
return __enteros;
}
set
{
__enteros = value;
}
}
public List GetPares()
{
return Enteros.FindAll(FindPares);
}
public List GetImpares()
{
return Enteros.FindAll(FindImpares);
}
// Esta funcion debra devolver true para aquellos elementos que queramos filtrar.
// El metodo FindAll ejecutara este metodo por cada elemento de la lista y, si el
// resultado es True, lo añadirá al resultado
bool FindPares(int entero)
{
return (entero % 2 == 0);
}

bool FindImpares(int entero)
{
return (entero % 2 != 0);
}
}
}

En el Main, ponemos:

static void Main(string[] args)
{
List enteros = new List();

for (int i = 0; i < 10; i++)
enteros.Add(i);

Find_All_Generics exampleList = new Find_All_Generics(enteros);

Console.WriteLine("Pares: ");
foreach (int i in exampleList.GetPares())
Console.WriteLine(i);
Console.WriteLine("Impares: ");
foreach (int i in exampleList.GetImpares())
Console.WriteLine(i);
Console.ReadKey();
}

Y comprobamos el resultado.

Esto es muy útil para realizar filtros sobre las listas. Por ejemplo,
- De una lista de empleados, puedo querer sacar una lista de los que son mayores de 40 años.
- De una lista de eventos deportivos, puedo querer filtrar los que son el domingo que viene
- etc...

Muchísimas gracias a Gloria por enseñarme el "fántastico mundo del FindAll" :-)

XSLT avanzado

2007-05-24T13:02:00.000+02:00

Ojo al articulo linkado aqui.

El articulo va de como hacer un arbol para navegar por los elementos de un XML basado en XSLT y algo de Javascript. Mi consejo es que os bajeis el ZIP de ejemplo y le echeis un vistazo.

Os va a gustar :-)

XSLT y el control XML de ASP.NET

2007-05-23T16:07:00.001+02:00

Uno de los controles menos ducumentados de ASP.NET en su version 2.0 es el XML Control. Tampoco hay mucho que documentar, pues basta con configurar cual es el origen de datos (el XML) y quien lo va a pintar (el XSLT). Con esto conseguimos varias cosas:
1. Independizamos cada componente de los demás- XML solo sabe de datos, no tiene ni idea de cómo se pintan en pantalla
- XSLT solo sabe como pintarlos. No sabe cuales son. Sólo sabe que espera recibir unos campos, sean los que sean.
- La pagina Web con su control XML no sabe ni que va a pintar ni como. Solo sabe en que posición de la página van.
2. Logramos que cambios en el futuro afecten a una capa solamente, no a todas.

Para aprender a manejar XSLT, conviene ver los siguientes links:

Meter Javascript y código .NET en XSLT
Tutorial de iniciación a XSLT
Trucos y cosas curiosas de XSLT

XQuery-SQL Server 2005 - La guia

2007-05-23T15:24:00.000+02:00

Hace tiempo que empecé a escribir sobre XQuery y apunté unos cuantos links útiles. Ahora vamos a dar una vuelta de tuerca y vamos a poner varios ejemplos.

Para ello vamos a usar un XML que tenga, más o menos variedad de cosillas: campos que se repiten, campos que no, elementos simples, complejos... para aplicar lo que aprendamos.

El XML podría ser el que sigue:

Vale, ya tenemos el XML, vamos a empezar a hacer consultas basicas:

Antes de nada, vamos a ver la estructura que tienen las queries.

for $A in /Encuesta/Contenido/Pregunta
where $A/Respuesta = “SI”
return $A/Texto

Esta query nos va a buscar dentro de todas la preguntas. Va a filtrar las que cumplan que la respuesta es si, y nos va a devolver el enunciado (texto) de la pregunta

Abrimos una nueva Query en SQL Server y escribimos:

select @xmlText.query('for $A in /Encuesta/Contenido/Pregunta
where $A/Respuesta = ''SI''
return $A/Texto
')

Nos devolverá:
¿Le gusta el cine?
¿Le gusta el futbol?

Vamos a refinar un poco… Ahora solo queremos que nos devuelva el contenido, sin tags xml. La query seria:

select @xmlText.query('for $A in /Encuesta/Contenido/Pregunta
where $A/Respuesta = ''SI''
return $A/Texto
').value('(//Texto/text())[1]','VARCHAR(MAX)')

Al ejecutarlo, hay un problema: solo nos devuelve el primero de los campos… Esto nos vale SOLO cuando sabemos que sólo hay un campo. Por ejemplo, en nuestro caso sería una busqueda del nombre de un encuestado.

Vamos a solucionar el problemilla… Vamos a hacer dos técnicas:
Mostrar los dos en el mismo campo: Para ello vamos a hacer uso de una cuncion de XQuery: concat. Vamos a concatenar todas las preguntas.

select @xmlText.query('for $A in /Encuesta/Contenido/Pregunta
where $A/Respuesta = ''SI''
return concat($A/Texto[1]," - ")
')

Mejor, ahora nos devuelve las preguntas concatenadas…

Mostrar una fila por cada coincidencia: es posible que queramos mostrar una fila por pregunta, para ello haremos uso de la siguiente query. Necesitamos que el XML esté en una tabla, porque necesitamos hacer un CROSS. La query sería:

SELECT
cast(R.EncuestaDetails.query('.')
.value('(/Texto)[1]','VARCHAR(MAX)')
AS VARCHAR(100))
AS ClienteNm

FROM
[Encuesta] C
CROSS APPLY
C.[EncuestaXML].nodes('/Encuesta/Contenido/Pregunta)
AS R(EncuestaDetails)

Esto nos devolvería todas las preguntas (una por fila) que haya en los XML de la tabla.

Genial!!!! No?

Sharepoint 2007

2006-11-07T13:58:00.000+01:00

La llegada inminente de una herramienta del poder que, aparentemente, tendrá Sharepoint 2007 no debría dejar indiferente al mundo de los programadores y desarrolladores y arquitectos y...
Como consejo, apuntarse a los cursos gratuitos de e-learning de Microsoft en este sentido, que nos darán una imagen general de que vamos a poder hacer (clinic 5045) y, por supuesto, enredar por los blogs de los expertos:

Caracteristicas de SPS 2007
Videos varios sobre la nueva tecnología

Gran documento sobre modelado de amenazas

2006-11-03T14:03:00.000+01:00

En las aplicaciones actuales, donde Internet empieza a ser un hábito cada vez más habitual, es necesario hacer un estudio muy serio de las aplicaciones que construimos.
Para ayudarnos (no para darnos las respuestas a todas nuestras dudas), aquí va este documento que nos ayudará.

Convertir ficheros de formato

2006-11-03T11:44:00.000+01:00

Aqui mando un link con un metodo para convertir ficheros de formato en .NET 2.0.
Podremos cambiar de UTF-8 a 16, etc..

XQuery

2006-11-02T16:28:00.000+01:00

Que es evidante que Sql Server 2005 representa una gran evolucion en lo que entendemos acerca de las bases de datos es evidente.
Una de las facetas que mas rendimiento nos aporta es el tratamiento de XML. Poder buscar dentro de los nodos de un XML es algo bastante útil, sobre todo ahora que la evolución de la información tiende a XML.
Para buscar datos, basta con usar XQuery (un formato de búsquedas similar a lo que ofrece SQL para tablas). No voy a dar ninguna lección, pero voy a incluir unas referencias de gente que sabe bastante de esto:

http://msdn2.microsoft.com/es-es/library/ms189075.aspx

Información de Microsoft:
http://msdn2.microsoft.com/en-us/library/ms345122.aspx
Tutorial de XQuery:
http://media.datadirect.com/download/docs/ddxquery/tutorial_query.html
Más XQuery, libro incluido:
http://www.datadirect.com/developer/xquery/xquerybook/index.ssp
Genial tutorial. Muy recomendable, aunque igual muy básico:
http://www.developer.com/db/article.php/3565996

Comparar 2 XML en SQL Server 2005

2006-11-02T16:05:00.000+01:00

Ojo porque no se puede compara tan alegremente los XML como unos varchar o int en SQL Server 2005.

Por ello, hay que meterse en el CLR de SQL. Para solucionar este problema, mirad este link:

http://pluralsight.com/blogs/dan/archive/2006/09/01/36829.aspx

SQL Server 2005 no entiende UTF-8

2006-11-02T15:55:00.000+01:00

Haciendo una pruebas sobre almacenamiento y manejo de ficheros XML con el SQL Server 2005, me he encontrado con un problema, y es que SQL Server 2005 sólo maneja formato UTF-16.
El problema es que, por ejemplo, un fichero Infopath tiene la cabecera:

Y al guardarlo falla, evidentemente.

Para solucionarlo, no nos queda otra que convertirlo de encoding. En .NET 2.0, tenemos métodos como Encoding.Convert(src,fnl,byte[]).

Otra fuentes interesantes sobre el tema:

http://msdn2.microsoft.com/es-es/library/ms187107.aspx
http://geekswithblogs.net/vkamat/archive/2006/01/20/66561.aspx

Error Text::: "XML parsing: line 1, character 38, unable to switch the encoding"