Fuzzy Logic y expresiones lambda

Para un proyecto que estoy realizando, he realizado una prueba de concepto probado a aplicar lógica difusa con el fin de realizar ciertas acciones a partir de una serie de datos imprecisos.


A la hora de expresar las reglas encargadas de modelar nuestro sistema de lógica difusa, (IF-THEN) la mayoría de los sistemas que he visto requerían de un pequeño y simple analizador sintáctico para interpretar las reglas, en este punto me he preguntado si en vez de un analizador sintáctico, podríamos usar expresiones lambda y una interfaz fluida.

FuzzySystem (improvisado)

De modo que he construido un pequeño motor de lógica difusa que tiene la particularidad de usar expresiones lambda y una interfaz fluida para definir el conjunto de reglas.
Este pequeño motor incorpora un par de funciones miembro, una de tipo Trapezoide y otra Triangular, básicamente su uso es el siguiente.
Definimos el sistema, añadimos las variables con sus estados y funciones miembro…

01 public class FuzzyTest
02 {
03     private readonly FuzzySystem _engine = new FuzzySystem();
04  
05     public FuzzyTest()
06     {
07         FuzzyVariable varA = new FuzzyVariable("A");
08         varA.Memberships.Add(new TrapezoidMembership("Cerrado", 0, 0, 5, 5));
09         varA.Memberships.Add(new TrapezoidMembership("Medio", 4, 4, 6, 6));
10         varA.Memberships.Add(new TrapezoidMembership("Abierto", 7, 7, 9, 9));
11         _engine.Variables.Add(varA);
12  
13         FuzzyVariable varB = new FuzzyVariable("B");
14         varB.Memberships.Add(new TrapezoidMembership("Cerrado", 0, 0, 5, 5));
15         varB.Memberships.Add(new TrapezoidMembership("Medio", 4, 4, 6, 6));
16         varB.Memberships.Add(new TrapezoidMembership("Abierto", 7, 7, 9, 9));
17         _engine.Variables.Add(varB);
18  
19         FuzzyVariable varR = new FuzzyVariable("R");
20         varR.Memberships.Add(new TrapezoidMembership("Frio", 0, 0, 3, 3));
21         varR.Memberships.Add(new TrapezoidMembership("Templado", 3, 3, 6, 6));
22         varR.Memberships.Add(new TrapezoidMembership("Caliente", 7, 7, 9, 9));
23         _engine.Variables.Add(varR);

 

La definición de reglas mediante expresiones Lambda

El beneficio en este punto es que el sistema no requiere del analizador sintáctico para evaluar las expresiones si no que será el CLR quien se encargue de ello.
Para llevar a cabo esta evaluación de las reglas he definido una clase FuzzyExpresion que tiene definidos  los operadores && y || para así como el true y el false para poder evaluar las reglas en consecuencia.



Las reglas en la lógica difusa sirven para combinar las distintas proposiciones, no son reglas excesivamente complicadas, y son del tipo IF-THEN, básicamente hay 4 reglas (Implicación Conjunción, Disyunción  y negación) que se corresponden con:

-    Implicación IF variable==estado THEN variable = estado
-    Conjunción, equivalente al AND, si dos proposiciones son ciertas simultáneamente
-    Disyunción, cualquiera de las dos proposiciones es cierta OR
-    Negación, invierte la proposición

Finalmente podemos definir las reglas de este modo

01 _engine.AddRule(x =>
02                 x.Variable("A").Is("Abierto") &&
03                 x.Variable("B").Is("Abierto"))
04                 .Then(x => x.Variable("R").Set("Caliente"));
05  
06 _engine.AddRule(x =>
07                 x.Variable("A").Is("Abierto") &&
08                 (x.Variable("B").Is("Cerrado") || x.Variable("B").Is("Medio")))
09                 .Then(x => x.Variable("R").Set("Templado"));
10  
11 _engine.AddRule(x =>
12                 x.Variable("B").Is("Abierto") &&
13                 (x.Variable("A").Is("Cerrado") || x.Variable("A").Is("Medio")))
14                 .Then(x => x.Variable("R").Set("Templado"));
15  
16 _engine.AddRule(x =>
17                 x.Variable("A").Is("Cerrado") &&
18                 x.Variable("B").Is("Cerrado"))
19                 .Then(x => x.Variable("R").Set("Frio"));

¿Cómo funciona?

Una regla tiene una condición (IF) y una consecuencia (THEN), la condición es una función que recibe el sistema y debe devolver una FuzzyExpresion, (Func<FuzzySystem,FuzzyExpression>), esto es parte de la magia ya que una expresión condicional es siempre reducida a una única expresión y finalmente a un único valor.
Y curiosamente la consecuencia de la regla, es exactamente igual, solo que en este caso la expresión no devuelve nada porque la consecuencia es una acción, aquí hay otro pequeño truco que es que la propia regla contiene los dos elementos separados (condición y consecuencia) fijaros en que:

1 _engine.AddRule(x =>
2                      x.Variable("A").Is("Abierto") &&
3                      x.Variable("B").Is("Abierto"))

Está devolviendo una regla y el método Then es aplicado sobre la regla, y cuando se evalúa la regla si la condición es cierta se evalúa la consecuencia, que lo que hace es únicamente cambiar el estado (ver el método Set de FuzzyExpression)

01 public class FuzzyRule
02 {
03     private readonly FuzzySystem _engine;
04     private readonly Func _condition;
05     private Func _then;
06  
07  
08     public double Value { get; set; }
09  
10     public FuzzySystem Engine
11     {
12         get { return _engine; }
13     }
14  
15     public FuzzyRule(FuzzySystem engine, Func condition)
16     {
17         _engine = engine;
18         _condition = condition;
19     }
20  
21     public FuzzyExpression Eval()
22     {
23         Value = _condition(Engine).Value;
24  
25         if (Value > 0)
26         {
27             return _then(Engine);
28         }
29  
30         return null;
31     }
32  
33     public void Then(Func then)
34     {
35         _then = then;
36     }    
37 }


Defuzzyficando

Para evaluar nuestro sistema ..

 

01     for (int a = 0; a < 10; a++)
02     {
03         for (int b = 0; b < 10; b++)
04         {
05             _engine.Variables["A"].InputValue = a;
06             _engine.Variables["B"].InputValue = b;
07             _engine.Consecuent = "R";
08  
09             var r = _engine.Defuzzy();
10  
11             Console.WriteLine(string.Format("A {0} - B {1} = {2,-6} [{3,-10}][{4,-10}] = {5}",
12                 a,
13                 b,
14                 r,
15                 _engine.GetVariableState("A",a),
16                 _engine.GetVariableState("B",b),
17                 _engine.GetVariableState("R", r)));
18         }
19     }
20 }

Mejoras de diseño

Hay una cosa que no me gusta mucho y es el hecho de que mi clase FuzzyExpression, tiene tanto el método Is como el método Set y esto habría que dividirlo en dos para no llevar a errores a la hora de la usar la interfaz fluida.

Errores de diseño

Pero no todo es de color de rosa, cuando planifique el sistema, pensé en la posibilidad de guardar las expresiones lambda como texto y después compilarlas usando CodeDom, bien tengo que deciros que cuando me he puesto a ello me he llevado la desagradable sorpresa de que CodeDom no soporta expresiones lambda, de modo que mi gozo en un pozo.

Y digo esto porque es de vital importancia el poder mantener las reglas fuera del código, bien un archivo de configuración, un archivo XML, lo que sea… de este modo podemos realizar ajustes sin tener que recompilar todo …

Para una futura versión

Completar estas cositas …

Publicado por Carlos Segura con 5 comment(s)
Archivado en:

Polar RS300x yeahhhh...

Estas navidades el Olentzero, Santa Claus, Papa Noel ó uno mismo, vaya ud. a saber … me dejo un pulsometro Polar RS300x, uno de esos aparatitos que te miden las pulsaciones (para evitar que a los que nos vamos haciendo mayores nos dé un chunguito)



La verdad es que no está nada mal, viene con el transmisor WearLink que es la cinta que te atas en el pecho que se encarga de enviar la frecuencia cardiaca al reloj, con un sensor S1 que es un podómetro que te pones en la zapatilla y una vez calibrado, mide la distancia y la velocidad, y finalmente con el FlowLink que es un dispositivo USB a través del cual puedes enviar la información a una web para (www.polarpersonaltrainer.com) para mantener un histórico de las sesiones de entrenamiento.

El domingo día 3 calibre el sensor S1 recorriendo una distancia de 1km y después probé por los alrededores de mi casa a correr una distancia conocida y me quede impresionado, tan solo medio metro de diferencia. Una maravilla.

El lunes día 4 realice una sesión de entrenamiento y después subí los datos la web, usando el FlowLink y el software de sincronización que viene con el aparato.

Bueno, no es que este mal del todo, pero no se puede decir que la web sea una pasada. La cosa es que me pico el gusanito ese “f-geek” (freak-geek) que llevo dentro ..

De modo que me puse a buscar todo tipo de información acerca de cómo sacar los datos del dichoso relojito … y no encontré absolutamente nada (y mira que ha sido fácil)

Revisando el software de sincronización di con unas .dlls curiosas .. Polar.Transport.dll y Polar.Monitor.dll … que curiosamente están en .Net … también hay una biblioteca de más bajo nivel llamada libpolar.dll a la que las otras dos hacen refencia (Interop) ..

Bueno tras una revisión con el reflector encontré muchas, muchas cosas interesantes .. lo mejor es que me podía conectar al relojito y obtener los datos de las sesiones, de modo que en un primer paso realice un sencillo programita para exportar los datos a XML

Que bonito … en poco más de una hora tenía los datos …

Básicamente basta con crear un proyecto en VS y referenciar Polar.Monitor.dll (como internamente usa libpolar.dll) debéis aseguraros que libpolar.dll está también localizable.

Pero para no perder detalle aquí os dejo un video de cómo hacerlo…



La cosa es que me he liado un poco (¿Cómo no?) y me he metido a hacer un GUI que por el momento tiene este aspecto.

Permite ver un resumen de las sesiones



Permite analizar cada sesión (yo le he activado el modo Auto Lap, de modo que el pulsometro toma datos a cada KM) me muestra el tiempo empleado, la velocidad, la FC Max, y la FC Media. Además emparejo cada dato de FC con la Zona de trabajo.

En el gráfico, se puede ver la FC , la FC Max (puntitos rojos) y ambas dentro de sus zonas correspondientes. En el gráfico de velocidad, se puede ver la velocidad en Km/h y en min/km además la vuelta más rápida queda en verde y la más lenta en rojo.



Por último el gráfico de las Zonas, con el tiempo empleado en cada una de ellas en la sesión de entrenamiento.



Os dejo otro bonito video del programita … (que me he emocionaooo ...)



Ya sabes si eres un f-geek de los ordenadores que además te gusta el running el Rs300x es una magnifica opción

ASP.NET Mvc Delete Link usando DELETE method

Realmente he llegado tarde (seguro que estaba haciendo alguna que otra mala cosa) al MVC de ASP.Net, lo digo porque aunque había jugueteado un poco no me había tenido que poner a hacer cosas un poco serias.

Bueno, la verdad es que estoy encantado ya voy haciendo mis pinitos poco a poco … una de las cosas con las que estaba más a disgusto ha sido el tema de hacer las eliminaciones vía POST (cosas de los que hemos jugado con Ruby)

Sthephen Walter (autor de ASP.NET MVC Framework Unleashed) tiene un post en su blog con una muy buena descripción del problema en su blog.  Resumo.
  • Realizar un borrado mediante HTTP GET es un error de seguridad como la copa de un pino.
  • Realizar un borrado usando Ajax y HTTP DELETE es dependiente del JavaScript.
  • Realizar un borrado usando HTTP POST, según Sthephen es la manera más idónea para no ser dependiente de JavaScript.
  • Problema, un link no puede hacer un HTTP POST
  • Tenemos que usar una imagen o un botó
  • Propone una solución para realizar la eliminación mediante AJAX y java script (demasiado dependiente)
Mi problema (y seguro que el de otros) - Requisitos
  • Quiero realizar un borrado
  • Quiero hacerlo usando un link
  • Quiero que sea seguro
  • Quiero que use HTTP DELETE
  • Quiero poder validar “¿Esta Ud. Seguro?”
  • Quiero poder personalizar el mensaje
  • Quiero que tras borrar pueda dirigirme a una página concreta
  • Quiero controlar los errores
  • Quiero que sea versátil y no tener que escribir JavaScript cada vez
Extendiendo jQuery

Ya está más que dicho, pero jQuery es grande, muy grande. Y una de las cosas que más me gustan es la facilidad con que puede extenderse, básicamente hay dos formas de hacerlo, una añadiendo nuevos métodos que son aplicables a los elementos (jQuery.fn.extend) y otra a través de la cual se pueden añadir nuevos métodos a  jQuery (jQuery.extend).

En este caso, vamos a extender jQuery añadiéndole un nuevo método, un método llamado mvcDelete que podremos usar desde el onclick de un link.

He preferido la este modo de extensión para poder escribir un sencillo HtmlHelper que me ayude a no tener que escribir prácticamente nada de JavaScript cada vez que quiero poner un link para eliminar un elemento.

<%= Html.DeleteLink(“Delete”, new { action=”Delete”, controller=”Page”, id=Model.Id, redirectToController=”Page”}, null) %>

   1:  jQuery.extend({
   2:          mvcDelete: function(options) {
   3:              var defaults = {
   4:                  controller: "",
   5:                  action: "delete",
   6:                  onComplete: function(xhr, status) { },
   7:                  onSuccess: function(data) { },
   8:                  onError: function(xhr, status) { alert("Error"); },
   9:                  message: "Are you sure you wish to delete this item?",
  10:                  confirmAlert: true,
  11:                  id: 0,
  12:                  redirectToController: "",
  13:                  redirectToAction: "index"
  14:              }
  15:              var ajaxError = false;
  16:              var opt = $.extend(defaults, options);
  17:              var deleteRequest = function() {
  18:                  var deleteUrl = '/' + opt.controller + '/' + opt.action + '/' + opt.id;
  19:                  $.ajax({
  20:                      type: "DELETE",
  21:                      url: deleteUrl,
  22:                      async: false,
  23:                      success: opt.onSuccess(data),
  24:                      complete: opt.onComplete(xhr,status),
  25:                      error: function(xhr, status) { opt.onError(xhr, status); ajaxError = true; }                    
  26:                  });
  27:              };
  28:   
  29:              if (opt.controller.length > 0 && opt.id > 0) {
  30:                  if (opt.confirmAlert) {
  31:                      if (confirm(opt.message))
  32:                          deleteRequest();
  33:                      else
  34:                          return false;
  35:                  } else
  36:                      deleteRequest();
  37:   
  38:                  if (!ajaxError && opt.redirectToController.length > 0) {
  39:                      var redirect = '/' + opt.redirectToController + '/' + opt.redirectToAction;
  40:                      window.location.replace(redirect);
  41:                  }
  42:              }
  43:              return false;
  44:          }
  45:   
  46:      });

En donde vamos a poder pasar:

controller -> controlador de la acción de borrado (requerido)
action -> acción de borrado, por defecto delete
id -> elemento a borrar (requerido)
onComplete -> una función a realizar tras completarse el borrado
onError -> una función a realizar si se producen errores
confirmAlert -> si se mostrará o no el mensaje de advertencia
message -> el mensaje de seguridad
redirectToController -> el controlador de salida (por defecto el mismo que de entrada)
redirectToAction -> la acción de la salida por defecto (Index)

Después el helper que se encargará de realizar el link será

   1:  public static string DeleteLink(this HtmlHelper helper,
   2:                                  string text,
   3:                                  object deleteOptions,
   4:                                  object linkHtmlAttributes)
   5:  {
   6:      var linkTagBuilder = new TagBuilder("a");
   7:   
   8:      linkTagBuilder.Attributes.Add("href", "#");
   9:      linkTagBuilder.SetInnerText(text);
  10:   
  11:      var serializer = new JavaScriptSerializer();
  12:      var mvcDeleteOptions = serializer.Serialize(deleteOptions);
  13:   
  14:      linkTagBuilder.MergeAttribute("onclick", 
  15:                                    string.Format("$.mvcDelete({0}); return false;", mvcDeleteOptions));
  16:      linkTagBuilder.MergeAttributes(new RouteValueDictionary(linkHtmlAttributes));
  17:   
  18:      return linkTagBuilder.ToString();
  19:  }
Aquí lo más destacable es como pasamos las opciones a nuestro plugin, usando un método anónimo, convertimos el objeto usando el serializador de javascript de este modo nuestro plugin, recibe los parámetros.


Publicado por Carlos Segura con 1 comment(s)
Archivado en:

NavarraDotNet - Independencia


Ayer tuvimos una sesión de arquitectura que dedicamos por completo a la inyección de dependencias (la llamamos Independencia), en esta ocasión contamos con gente que está trabajando con Java, e incluso con PHP, la verdad es que fue una autentica pasada ya que tras ver algunas demos, (yo flipo con la gente de PHP) mantuvimos una conversación realmente interesante, buen rollito a pasar de las diferentes tecnologías.

•    En Java vimos PicoContainer, NanoContainer, Spring y MicroSpring.
•    En PHP vimos como ejemplo Substrate (y Manu, se llevo el premio arquitecto-friki del día)
•    En .Net vimos StructureMap, Unity, Ninject, Autofac y más….

No obstante y para variar, terminamos con algunas discusiones un poco más acaloradas, y es que hay que ver como se ponen algunos.
Haciendo un resumen discutimos sobre:

-    Cuando se debe usar IoC.
-    Pros y contras
-    Alternativas de configuración XML/Código
-    Sugerencias para la elección de un framework
-    Rendimiento

En cuanto al rendimiento, pudimos hacer una serie de benchmarks con las herramientas de .Net, usamos un sencillo test preparado por (gracias Torkel [http://www.codinginstinct.com]), en donde lo más destacable fue el poder ver cómo se comportan los distintos frameworks, dejo los enlaces abajo, esta prueba es realmente interesante

•    http://www.codinginstinct.com/2008/04/ioc-container-benchmark-unity-windsor.html
•    http://www.codinginstinct.com/2008/04/ioc-benchmark-revisited-ninject.html
•    http://www.codinginstinct.com/2008/05/ioc-container-benchmark-rerevisted.html

Os sugiero variar el número de objetos que se crean y el modo en que se instanciaran.

Bueno, lo próximo serán los talleres de integración continua que haremos en el CES, estos se han llenado en apenas 24 horas. De modo que tendremos que pensar en organizar más

Calendario de eventos del CES para Noviembre


Publicado por Carlos Segura con no comments
Archivado en:

Cuestiones sobre el diseño de soluciones en SharePoint (4)

Continuando con el tema de la organización, como ya he dicho las colecciones de sitios son un punto muy importante a tener en cuenta. Alguna de las limitaciones las podemos superar por medio de la instalación de soluciones y características a través de las cuales podemos hacer un despliegue más rápido sobre distintas colecciones de sitios.

A la hora de organizar, yo, personalmente tengo en cuenta dos cosas, que creo son muy importantes, la primera es el tema de la seguridad.

Seguridad

SharePoint cuenta con una serie de roles, grupos y acciones con las que hay que familiarizarse para poder desenvolverse correctamente.

Establecer a que información debe acceder cada cual, que puede ver y que puede editar, nos va a ayudar a tener una idea clara de cómo debemos organizar otras cosas.

Yo primero suelo hacer esto en dos pasos, en un primer paso repaso la información que va a contener la aplicación y los usuarios que van a acceder a ella; establezco una correspondencia creando una serie de grupos de usuarios. En un segundo paso, una vez tenemos clara la estructura que va a tener nuestra aplicación, colecciones de sitios, sitios y subsitios y la información que va a contener cada uno de ellos, vuelvo a ajustar los permisos.

Por ejemplo en el caso que comente anteriormente en donde teníamos el dilema de si establecer la jerarquía por Delegación o por Departamento, si hemos optado por establecerla por Delegación, tenemos que asegurarnos de que el jefe de almacén pueda acceder al departamento de almacén en cualquiera de las delegaciones, pero no podrá entrar en otros departamentos.

Cuando pensemos en la seguridad y los permisos de acceso también hay que tener en cuenta quien administrará los sitios ¿hay un departamento de sistemas encargado de ello? ¿Van a poderse crear nuevos subsitios? ¿Quién se va a encargar de mantener los permisos?

Existe también una jerarquía de permisos, de modo que podemos asignar permisos que se irán heredando en los distintos subsitios. Hay que recordar que los permisos no son como los de NTFS, es decir que no podemos heredar y tener permisos únicos al mismo tiempo, es o una cosa o la otra.

Acceso y Agregación de la información

La segunda cosa que suelo tener en cuenta es donde se va a localizar la información dentro de la aplicación, aspectos a tener en cuenta como el hecho de cómo se quieren agregar los datos y donde van a estar localizados los mismos son de vital importancia.

En MOSS disponemos del “Cotent Query Web Part” que nos va a permitir agregar datos de la misma colección de sitios, pero en WSS debemos hacerlo nosotros mismos, hay que tener en cuenta que información debemos agregar y como deseamos verla, para poder pensar cómo vamos a hacerlo.

Cuestiones que me han preguntado estos días

Bases de datos de Contenido


Como comente anteriormente cada aplicación web al menos contiene una base de datos de contenido, en ella se almacenará la colección de sitios principal y si lo deseamos otras colecciones. También una aplicación web puede tener más de una base de datos de contenido, que contendrán una o más colecciones de sitios, pero una colección de sitios no puede usar más de una base de datos.

Finalmente todo el almacenamiento de SharePoint recae en una base de datos, tenemos que tener en cuenta la capacidad de almacenamiento que esperamos tengan nuestras colecciones de sitios, no es lo mismo una aplicación web pública realizada con las características de CMS, que una intranet en donde vamos a almacenar miles de documentos de office.

Además y como es lógico debemos prever un plan de contingencias y de mantenimiento para nuestras bases de datos, pensad no es lo mismo una base de datos de 50GB que de 500GB, tiempo de respaldo, soportes necesarios, mantenimiento, horarios, etc…

Publicado por Carlos Segura con 1 comment(s)
Archivado en:

Cuestiones sobre el diseño de soluciones en SharePoint (3)

Uno de los primeros puntos a tener en cuenta cuando se desarrolla una solución para SharePoint es cómo vamos a organizar el contenido y la información.

SharePoint nos ofrece distintas posibilidades que veremos a continuación, pero también hay que tener en cuenta algunos factores importantes.

Granjas, Aplicaciones Web, Colecciones de Sitios, Sitios y Subsitios

En primer lugar tenemos que comprender las opciones que nos brinda SharePoint para estructurar nuestra solución.

Debemos de tener claro que todos los datos de SharePoint son almacenados en distintas bases de datos en un servidor de SQL. Con lo cual desde el punto de vista del diseño de aplicaciones de SharePoint, tenemos que contemplar cuando menos un plan de contingencias y de mantenimiento de las bases de datos que conforman nuestra instalación.

Bases de datos de SharePoint 2007

Dicho esto tenemos que entender ahora 5 piezas fundamentales. No quiero extenderme más de lo necesario, a modo de resumen:

Una granja de servidores es un conjunto de servidores que trabajan en unidos, donde podemos dividir distintas responsabilidades entre distintos servidores. Podemos tener una granja de un único servidor donde todos los servicios funcionen sobre una única máquina (servidor web, búsquedas, Excel services, Forms services, SQL Server …) lo más lógico desde el principio es dividir en dos partes la granja, es decir dejar un servidor para el SQL Server y otro con el resto de servicios. Conforme van aumentando los clientes o la demanda de servicios podemos ir añadiendo servidores y establecer las nuevas funcionalidades de las cuales se ocuparan esos servidores, así por ejemplo podemos añadir un nuevo servidor a nuestra granja que se ocupe únicamente del servicio de búsquedas de modo que descargaremos a otros servidores de dicha responsabilidad.
En el caso de una granja pequeña en crecimiento, pongamos por ejemplo 3 servidores, los roles podrían ser los siguientes, servidor de SQL, servidor Web Front End, y un servidor que se ocupara del resto de los servicios, búsquedas, Excel services, Form Services, Shared Services etc…

En el caso de una instalación de Windows SharePoint Services, también es recomendable dividir siempre que sea posible al menos los roles de SQL Server y de Web Front End.

Obviamente todo esto pasa por un estudio de las licencias necesarias, para montar la infraestructura que deseemos, esto lo dejaremos al margen.

Una vez que tenemos clara la estructura de nuestra granja, tenemos todavía una importante labor, establecer cómo será la jerarquía de nuestros sitios.

En la terminología de SharePoint, tenemos otro punto importante, el de la aplicación web. Una aplicación web será el punto raíz de la estructura de una solución, cuando creamos una aplicación web, SharePoint crea un nuevo sitio de IIS en una dirección y un puerto de nuestra máquina, así como una base de datos en donde albergará el contenido de dicha aplicación web.

Una aplicación web, no es más que un vinculo o una dirección y una base de datos de almacenamiento con el objetivo de albergar cuando menos una colección de sitios. Es por esto que una vez creada una aplicación web a través de la administración central de SharePoint, lo siguiente es crear una colección de sitios que quedará enlazada con la raíz de la aplicación web.

Una aplicación web como mínimo contiene una colección de sitios, pudiendo a través de de la administración central fijar un punto de anclaje para nuevas colecciones de sitios.

En una granja de servidores podemos tener distintas aplicaciones web como una intranet, una extranet, o un sitio web publico), ahora bien, aunque podemos usar la misma dirección web, cada aplicación web deberá tener su propio puerto; no podemos tener dos aplicaciones corriendo sobre el mismo puerto.

Una colección de sitios, es como un árbol, del cual pueden colgar sitios y subsitios, una colección de sitios es el inicio de una jerarquía de sitios, y al igual que en árbol una colección de sitios tiene un sitio raíz. Todo esto es importante porque debemos de tener en cuenta diversos factores como veremos luego que afectan en su conjunto a una colección de sitios.

Antes de continuar, terminaré de matizar que es un sitio y que es un subsitio. Un sitio es un apartado o nivel en el cual encontraremos contenido (entender aquí, páginas, listas, bibliotecas de documentos, subsitios, etc…) y un subsitio es un sitio que tiene padre.

La importancia de las colecciones de sitios consiste en que dentro de una colección de sitios existen ciertos elementos y recursos comunes dentro de la colección y este es un aspecto muy importante a la hora de diseñar una solución de SharePoint.

Dentro de esos elementos comunes estan:

-    Flujos de trabajo
-    Tipos de contenido
-    Columnas de sitio
-    Seguridad por grupos
-    Ámbito de búsquedas (WSS)
-    Características (features)
-    Papelera de reciclaje
-    Informes de uso
-    Web Parts
-    Páginas maestras
-    Plantillas de sitios
-    Plantillas de listas
-    Quotas (limites de espacio)
-    Copias de seguridad

Para que quede claro, dentro de una aplicación web como he dicho anteriormente puede haber más de una colección de sitios, pero todos estos elementos son dependientes de la colección de sitios, de modo que en una colección podemos tener una plantilla personalizada para crear listas de tipo “Pedido” pero en la otra colección esta plantilla puede no existir.

Organización

Al igual que las empresas y corporaciones tienen una estructura determinada debemos establecer cómo queremos estructurar nuestras aplicaciones web en SharePoint. Esto aunque puede parecer sencillo, es sin duda una de las cosas más complicadas.

Veamos un pequeño ejemplo, tomemos una organización dedicada a la fabricación de muebles, supongamos que tiene tres fábricas ó delegaciones en Madrid (central), Barcelona y Sevilla. Dentro de cada delegación, hay diversas divisiones  ó departamentos, Almacén, Fabricación, Ventas, Financiero y Postventa.

Podemos hacer una estructura por delegación

-    Madrid
o    Almacén
o    Fabricación
o    Ventas
o    …
-    Barcelona
o    Almacén
o    …
-    Sevilla
o    Almacén
O bien podemos hacerla por departamentos

-    Almacén
o    Madrid
o    Barcelona
o    Sevilla
-    Fabricación
o    Madrid
o    Barcelona
o    Sevilla
-    ….

Aquí empieza el dilema, ¿Cómo estructuramos nuestra aplicación web?.

Cada organización es muy particular, de modo que no existen formulas magistrales. Por proponer un comienzo, deberíamos analizar qué información es la que va almacenar cada sitio y que seguridad ha de tener cada elemento. ¿Los usuarios de Sevilla solo deben ver lo de Sevilla o pueden ver también lo de Barcelona y Madrid? ¿Deben los del departamento de Almacén ver los datos de Ventas? ¿Le interesan al departamento de Posventa los incidentes de las tres delegaciones?

¿Debo crear una colección de sitios por cada delegación? ¿Por cada departamento? ¿Debería una delegación ser un sitio y un departamento un subsitio? ¿Debería ser al revés? ¿Debería tener dos estructuras, por departamento y por delegación? ¿En colecciones de sitios diferentes o en la misma colección?

A la hora de desarrollar una solución debemos tener en cuenta un montón de aspectos, cuestiones como la seguridad, la información y su flujo, las búsquedas y los recursos con los que va a contar son algunas de las más importantes.

Debemos empezar haciendo un análisis muy cuidadoso de todos estos aspectos para no llevarnos sorpresas luego.

Publicado por Carlos Segura con 3 comment(s)
Archivado en:

Cuestiones sobre el diseño de soluciones en SharePoint (2)

Como comentaba en el post anterior, me gustaría dedicar una serie de artículos a algunas de las consideraciones sobre el diseño de soluciones en SharePoint, el en titulo olvide mencionar que me voy a centrar básicamente en el área empresarial.

FeedBack

Uno de los aspectos que considero más importante es el feedback de los usuarios. Como mencione anteriormente muchos de sus problemas a veces se resuelven con imaginación y creatividad, siempre hay que estar atentos a lo que dicen los usuarios.

Por ello una de las partes principales de un desarrollo en SharePoint, puede comenzar por un simple foro de discusión en donde los usuarios puedan dejar sus opiniones tanto críticas como de mejora.

Evidentemente aquí no hay mucho de diseño, pero esto será un pilar fundamental si se hace un buen uso del mismo.

Para poder categorizar los temas que se tratarán en el foro, a la lista se le puede añadir un tipo de contenido o un campo que contenga los diversos asuntos a los que hace relación un post, así como otro campo que indique si el post es referente a una crítica o a una mejora.

En la mayoría de las organizaciones dinamizar un simple foro como este suele ser un problema si no existe una cultura de colaboración, en ocasiones a la gente le da vergüenza comentar cosas, pensando que lo único que van a decir son estupideces, bien, esto es una labor interna en la que hay que concienciar a la gente (y este es un buen punto de arranque) aludir a que jamás mejoraran las herramientas de las que disponen si ellos no hacen nada por mejorarlas; atacar ese pequeño orgullo que todos tenemos, tocar esa fibra, suele dar un buen resultado.

Esto tiene su contrapartida, si el usuario se expresa y pide cosas hay que dárselas (y rápido) si no toda labor anterior habrá caído en balde. Por parte del departamento de IT, habrá que valorar las peticiones de los usuarios y como mencione (y no dejaré de mencionar en lo sucesivo) deberemos realizar una valoración de dichas mejoras de modo que podamos encontrar quórum para llevarlas a cabo y que encajen en tiempo, coste y complejidad.

Según mi experiencia, el usuario tiende a pedir en ocasiones cosas como ¿no podríamos tener un botón aquí que hiciera tal o cual cosa?, nosotros tenemos que pensar en que es lo que el usuario quiere hacer realmente, ¿Por qué, quiere hacerlo?, ¿Qué ventajas encuentra en ello? Y de qué modo podemos ofrecerle algo que le ayude sin que ello suponga demasiada complejidad; Igual el botón no pude estar allí, pero tal vez podamos poner un hipervínculo aquí para hacer lo mismo o casi lo mismo.

El vocabulario del usuario y el nuestro es distinto, hay que hacer un esfuerzo por entenderle, comprenderle y dar a entender lo que nosotros podemos hacer por él.

Una pequeña encuesta en donde los usuarios voten ó valoren las mejoras, puede ser de gran ayuda a la hora de determinar por dónde empezar, así como de tener una idea de a cuanta gente vamos a contentar y/o enfadar con la realización de los cambios.

Un escenario como este puede complicarse todo lo que uno quiera, pero en la práctica debe ser algo sencillo, empecemos dando algo con lo que todos podamos trabajar, un foro en SharePoint y dos o tres campos personalizados (diseño 0%, evangelización y concienciación sobre el uso 100%) pongámoslo en marcha y escuchemos a nuestros usuarios, ellos tienen cosas importantes que decir.

Vigilancia del Entorno

La rapidez con que una empresa sea capaz de reaccionar a los acontecimientos de su entorno, es una medida de los reflejos corporativos.

Sin duda es una parte muy importante, vigilar nuestro entorno; diseñar un portal de vigilancia del entorno dentro de una empresa es algo que aporta gran valor. Hace algún tiempo ayude a un amigo a realizar un portal de vigilancia del entorno y tuve la oportunidad de aprender algunas cosas importantes.

Gracias a internet tenemos a nuestro alcance una ingente cantidad de datos, muchos de ellos nos pueden ayudar a ver qué es lo que está ocurriendo en nuestro entorno, pero identificar la información que nos es útil entre tantos datos puede ser un problema.

Cuando mi amigo me pidió ayuda él había hecho gran parte del trabajo, el había buscado las fuentes de datos que consideraba más relevantes para el entorno de su empresa, clientes, proveedores, mercado, producto, marketing, competencia, tendencias y noticias del sector, incluso encontró algunos foros donde se mencionaba su empresa, todo ello estaba dentro de un site en donde había usado el web part de transformación de XSLT, para recuperar las feeds que él había considerado importantes y poderlas visualizar en varias páginas en función de las distintas categorías a las que hacían referencia.

El site, era útil, de un plumazo tenia agregadas muchas de las noticias que eran relevantes para la empresa, sin embargo la gran cantidad de noticias apabullaba a los usuarios; la gente entraba veía la ingente cantidad de noticias, leía una o dos y salía.

El site resolvía un problema, pero desde luego no lo hacía de la mejor manera posible, pero había algo por dónde empezar lo cual es como ya hemos comentado, bueno.

Le sugerí, que antes de hacer nada, hablara con los usuarios y les preguntará como se podría mejorar el site de vigilancia, tras unas cuantas sugerencias (feedback) por parte del personal de la empresa, había varios puntos en común, la focalización (o audiencia) de la información y la posibilidad de escalar noticias.

La focalización de la información hace referencia al hecho de donde se debe encontrar la información,  en vez de tener un site en donde concentrar toda la información, los usuarios opinaban que era mejor que cada web de departamento se viese un resumen de esas noticias, de este modo se orienta la información a una audiencia determinada.

En segundo lugar, debería existir un mecanismo de escalar las noticias importantes; cuando se cuenta con mucha información alguien debe poner está en su contexto, y valorarla de manera adecuada. En la empresa de mi amigo fabrican piezas con plásticos inyectados, de modo que la invención de un nuevo compuesto o mecanismo puede parecerle muy importante a la gente de producto pero a alguien de dirección un artículo más bien técnico puede parecerle intrascendente o un autentico coñazo. De modo que la información ha de ser valorada por alguien de las trincheras que la ponga en su contexto y le de la importancia que debe tener y luego la transmita dentro de su contexto al resto de la organización.

Eso dio pie a la creación de un site DAFO, (Debilidades, Amenazas, Fortalezas y Oportunidades).

Se hicieron los cambios necesarios para que cada departamento visualizara la información pertinente a su área, y como complemento de esa información con un simple click se podía llevar la información del agregador de noticias al sistema DAFO, con eso la noticia podía crear una alerta en el sistema, periódicamente se examina el site DAFO y se toman decisiones en función del contenido.

En un primer momento el sistema funcionaba de manera manual, es decir junto a cada noticia existía un enlace a la web DAFO, en donde el usuario debía crear un breve resumen de la noticia, el tipo de alerta Debilidad, Amenaza, Fortaleza o Oportunidad y un comentario personal de ¿Por qué? Se contempla la noticia como una alerta.

La gerencia de la empresa usa la web de DAFO de forma periódica en una reunión quincenal de seguimiento de diversos asuntos, se analizan todas las alertas y se hace un pequeño acta que se deja en ese mismo sitio.

Más adelante cuando el sistema demostró su utilidad, se mejoró sustancialmente incluyendo algo de programación y ahora permite que tras valorar la noticia, esta incluya un enlace a la fuente original, también el site DAFO cuenta ahora con una serie de gráficos y resúmenes quincenales de las alertas que se han producido así como una lista por cada departamento que permite introducir las fuentes desde donde cada departamento va a recibir las noticias así como los filtros que ha de pasar el contenido para ser agregado; de este modo se su pueden añadir y suprimir fuentes y filtros sin necesidad de programar absolutamente nada.

Publicado por Carlos Segura con 4 comment(s)
Archivado en:

Cuestiones sobre el diseño de soluciones en SharePoint (1)

Una de las incuestionables capacidades de SharePoint, es la de poderse adaptarse rápidamente a muchas de las problemáticas que surgen en las empresas.

Sin embargo a la hora de diseñar estas soluciones no todo es tan sencillo, con esto me estoy refiriendo al hecho de que nos encontramos en innumerables ocasiones con problemáticas empresariales que no son excesivamente complejas pero que sin embargo a la hora de trasladarlas a SharePoint, se convierten en un verdadero infierno.

Durante estos años que llevo trabajando con SharePoint, me he encontrado con multitud de casos en los que cosas que parecían relativamente sencillas por que el 80% del trabajo ya estaba hecho, funcionalidades que de por sí contempla SharePoint el 20% restante ha supuesto una cantidad de trabajo terrible. Donde ese 20% has supuesto una cantidad de tiempo y un coste tan elevado que es casi imposible de justificar.

Vamos a dejar al margen las ocasiones en que el diseño de una solución debe ser estrictamente fiel a un procedimiento empresarial, y debe reflejar de manera completa y exacta dicho procedimiento; en este punto la postura es clara; tendremos que hacer lo que sea para que la solución cumpla al 100% los requerimientos del procedimiento.

En el resto de ocasiones, tenemos la disyuntiva de hasta qué punto debemos ser flexibles en el desarrollo de la solución. Según mi experiencia debemos ser flexibles y agiles.

Muchos de estos procesos requieren que seamos agiles, no podemos esperar meses a tener una herramienta para poder gestionar eficazmente. A esto debemos añadir el hecho de que muchos de estos procesos están vivos, es decir se empieza haciendo cosas de una manera, y tras evaluaciones sucesivas del procedimiento así como de la experiencia que se va adquiriendo del uso del mismo, se va optimizando, suprimimos, añadimos y cambiamos pasos, información y flujos de la información.

Tenemos que contemplar el diseño como una negociación Win-to-Win, en donde todos ganamos por una parte tendremos que adaptar los requisitos o los procedimientos para que estos sin perder en esencia su objetivo sean los menores para no tener que realizar complejos sistemas para sustentarlos. De esta manera y solo de esta manera seremos capaces de diseñar sistemas cuyo ROI, sea positivo desde el comienzo.

En esta negociación, se deben poner sobre la mesa los requerimientos y los recursos de que disponemos para trasladar estos a la plataforma.

Un sencillo ejercicio de ponderación, donde valoramos los requisitos de modo que los que más valor aportan tendrán una puntuación más elevada y los que menos valor aportan una puntuación inferior y del mismo modo, evaluamos la complejidad que entrama desarrollar cada una de las partes del sistema, valorando en términos de tiempo, coste y complejidad cada uno de los pasos necesarios para cumplimentar dichos requisitos.

A través de un ejercicio de esta índole, debemos suprimir todo aquello que en esencia sea superfluo y buscar alternativas a aquellas partes del sistema que por su tiempo, coste o complejidad vayan a ser cuellos de botella tanto en el uso como en el desarrollo de las mismas.

Otro punto importante, es el de la rapidez; cuanto antes demos a nuestros usuarios una herramienta y algo básico con lo que trabajar empezaremos a recibir feedback que deberemos tener en cuenta, muchas de las propuestas del usuario final son imaginativas y creativas (y generalmente más baratas).

En muchas ocasiones esto conlleva exprimir lo que tenemos al máximo, más adelante siempre tendremos oportunidades de realizar esas complejas partes que harán de nuestra solución una solución perfecta.

En próximos posts me gustaría comentar algunas experiencias tanto mías como de algunos colegas sobre el diseño de soluciones con SharePoint.

Cualquier comentario o aportación será bienvenido.

Publicado por Carlos Segura con 2 comment(s)
Archivado en:

NavarraDotNet - ¡Volvemos a la carga! - El Futuro

Después de un largo parón debido principalmente a motivos de salud volvemos a ponernos en marcha colaborando en la organización de un evento muy atractivo. Se titula EL FUTURO, tachan! y tiene ponentes de lujo: David Salgado (Microsoft) , el equipo del CES (CES Microsoft) y un servidor [Carlos Segura (navarradotnet)].

Será el 23 de junio, de 10 a 15 en el salón de actos de los Centros Excelencia Software.

La agenda:

10:00-11:10 Windows 7 para desarrolladores. Equipo CES, CES Microsof

Veremos las oportunidades que ofrece Windows 7 para aplicaciones de escritorio, cómo integrarse en la nueva experiencia propuesta por la versión más reciente del sistema operativo Windows y cómo sacar el máximo partido a las nuevas APIs

11:10 – 12:30 Azure Services Platform – Plataforma de Cloud computing. David Salgado,  Microsoft

Podemos considerar Cloud Computing como un nuevo canal para construir y alojar aplicaciones. En ésta sesión repasaremos la plataforma de Cloud Computing de Microsoft, haciendo hincapié en cómo utilizar nuestros conocimientos en .NET para crear aplicaciones para la nube y utilizar servicios de la plataforma Azure

12:30 – 12:50 Descanso y pincho Cortesía de NavarraDotnet  

12:50 – 14:00 Silverlight 3 – Experiencia de usuario. David Salgado, Microsoft

WPF y posteriormente Silverlight y expression Blend marcaron un antes y un después a la hora de crear experiencias de usuario en aplicaciones. Actualmente nos encontramos a las puertas de la versión 3 de silverlight, que incorpora características como la funcionalidad offline, la detección de la red, los servicios para aplicaciones de línea de negocio, etcétera. En esta sesión repasaremos las bases que sitúan a Silverlight como una opción excelente para aplicaciones RIA y sus nuevas funcionalidades en esta versión 3.

14:00 – 15:00 Concurrent Buggy Framework . Carlos Segura, navarradotnet

Presentación para la concurrencia del Buggy Framework.
Conduce a la velocidad que siempre has soñado en tus aplicaciones... 

Entrada gratuita previo registro en

http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032416823&Culture=es-ES

Es de no perdérselo!!! Nos vemos allí :)

El cartel, como ¿no? diseñado por nuestros amigos de Sistema Formación


Publicado por Carlos Segura con no comments
Archivado en:

YACAMLQT (Yet another CAML query tool) Redux (3) in CodePlex

Bueno, esta es la última entrega a partir de hoy el proyecto se encuentra en CodePlex (yacamlqt.codeplex.com).

En esta última parte solo unas pequeñas notas para el usuario final.

Bien, para usar YACAMLQT, dentro de tus proyectos, solo hay que referenciar la dll (IdeSeg.SharePoint.Caml.QueryParser.dll)  y el uso sería el siguiente:


   1:              try
   2:              {
   3:                  var parser = new NParser(textTSql, new ASTNodeCAMLFactory());
   4:                  var generator = new CodeGenerator(parser.Parse());
   5:                  generator.Generate();
   6:                  return _formatTools.FormatXml(generator.Code);
   7:              }
   8:              catch (ParserException ex)
   9:              {
  10:                  _view.Status = ex.Message;
  11:              }
  12:              catch (ScannerException ex)
  13:              {
  14:                  _view.Status = ex.Message;
  15:              }

Instanciamos el Parser (NParser), le pasamos la consulta en TSQL (textSql) y la factoría correspondiente a lo que queremos generar, por el momento solo está disponible la de CAML, en breve completaré la de CAML.Net; Por último inyectamos el Parser en el Generador de código, llamamos al método Generate y recogemos la consulta en CAML en generator.Code.


Las posibles excepciones tanto del Parser como del generador de código se pueden atrapar con ParserException y ScannerException.


En el proyecto se incluye un pequeño subproyecto con una interfaz WinForms (no es que se me de especialmente bien)

Publicado por Carlos Segura con no comments
Archivado en:

¿Por qué son importantes los patrones? - Libros de Referencia

A estas alturas… todavía me encuentro con aplicaciones donde es imposible comprender el diseño e interpretar las intenciones del desarrollador.

Básicamente, pienso que hablan por sí solos, es decir, revelan la intención del diseño, son un lenguaje común; cuando en un equipo de desarrollo se habla en términos de patrones de código, se está hablando de las características, cualidades y restricciones que el patrón representa. Hablamos simplificando los problemas y partes del diseño de nuestras aplicaciones.

Prácticamente no hay API ó Framework (la de SharePoint es una excepción) donde no se haga uso de patrones, esto hace que el uso y comprensión así como las extensiones que realicemos sea mucho más sencillo.

“Cada patrón describe un problema que ocurre una y otra vez en nuestro ambiente y describe el corazón de la solución del problema, de esta manera podemos usar esta solución una y otra vez sin hacerlo de la misma manera dos veces” Christopher Alexander [AIS+77, page x]

Los patrones nos dicen como estructurar clases y objetos para resolver problemas, y es nuestro trabajo adaptarlos a nuestros diseños.

Y esto es lo más grande, porque esa adaptación a un problema particular no oculta las intenciones del programador, viendo que patrón se ha adaptado nos permite vislumbrar en que ha pensado a la hora de tomar decisiones.

En fin, para todos aquellos que comienzan, y para algunos que todavía… os dejo una lista de libros que son (no todos) de obligada lectura.

De arriba abajo:



* Patrones de diseño, edición en castellano de Design Patterns - Lectura obligatoria
* Design Patters (GOF Book) - Lectura obligatoria
* Analysis Patterns - Es un libro más profundo, sobre todo orientado al análisis y diseño de aplicaciones, con ejemplos (sin código) del diseño de aplicaciones de negocio y de aplicación de patrones en el diseño - Lectura Recomendada
* AAgile Principles, Patterns and Practices in C# - Para mi uno de los mejores libros que he leído, no solo hace hincapié en los principios de diseño más básicos, sino que también añade una completa referencia de los patrones más usados. - Lectura Muy Recomendada.
* Patterns of Enterprise Application Architecture - Fantástico, aquí se incluyen muchos de los patrones más usados que no se encuentran en el GOF Book, desde Active Record, Lazy Load, Unit Of Work ... aproximadamente 50 patrones menos conocidos, pero ampliamente usados. - Lectura Obligatoria.
* Refactoring to Patterns,, un pedazo de libro, que es como el eslabón que une refactorizaciones y patrones, perfectamente explicado, realmente impresionante como une el libro de Design Patterns, con el de Refactoring  (Fowler) - Lectura Muy Recomendada.
* Implementation Patterns - Un libro que realmente habla más del estilo de código que de patrones, un poco flojo, recomiendo leer Clean Code de Robert C. Martin. - Lectura Medio Recomendada.
* C# 3.0 Design Patterns - Un libro con ejemplos de patrones (GOF) en C# 3.0 sin más. - Lectura Medio Recomendada.
* C# Design Patterns, los GOF con ejemplos en C#, Libro recomendado para los que comienzan con C#.
* xUnit Test Patterns - Si haces pruebas ó TDD es imprescindible. Lectura Muy Recomendada.
* Design Patterns in Ruby - Si eres un salsas, como yo, no esta de más ver como se implementan los GOF en Ruby, muy entretenido. Lectura Pasatiempo.

Por último tengo un librito que aunque parece que esta en chino, no es así, esta en ingles, pero es una edición Design Patterns para China, a mi me gusta para llevarlo en la maleta cuando doy charlas o cursos.


Publicado por Carlos Segura con 3 comment(s)
Archivado en:

YACAMLQT (Yet another CAML query tool) Redux (2)

Continuando con la explicación del código de YACAMLQT.

Habíamos visto la parte relacionada con el Lexer el analizador morfológico. Como es obvio detrás debe haber un analizador sintáctico y semántico el Parser.

El analizador sintáctico y semántico (NParser) se ha implementado siguiendo el patrón interpeter, (seguramente sea uno de los que menos se ven), el objetivo es obtener los distintos Tokens desde el Scanner y montar un árbol sintáctico (AST) este árbol contiene Nodos (ASTNodeBase) y estos nodos representan de manera abstracta y simplificada la estructura sintáctica de la consulta en SQL.

(diagrama NParser)

A la clase NParser se le puede inyectar una factoria (ASTNodeFactoryBase) en función del código que queramos generar, por el momento solo esta implementado el CAML, pero se puede extender sencillamente para generar CAML.Net.

Partiendo de un nodo abstracto (ASTNodeBase) podemos definir las distintas unidades sintácticas, por medio de la herencia. Estos nodos abstractos (heredados de ASTNodeBase ) conforman las distintas expresiones que se usan en el analizador sintáctico y semántico (NParser), para ello se ha definido una clase para cada uno de los Tokens a modo de plantilla (template),  y estas clases son a su vez son las distintas expresiones abstractas, que se usan en  el patrón interpreter implementado en el parser. (NParser).

Todos estos nodos que forman las expresiones abstractas al fin al cabo son plantillas (templates), y podrían a su vez ser clases abstractas, yo opte por una implementarlas como clases normales. Ya que algunos de los nodos son terminales y otros intermedios y no tienen por qué ser heredados, de este modo la factoria base (ASTNodeFactoryBase) usa miembros virtuales parar crear dichos nodos.

(diagrama parcial de ASTNodeBase)

Para crear todos estas expresiones abstractas existe una factoría abstracta (ASTNodeFactoryBase ) a través de la cual creamos los distintos nodos. Como puede verse, para añadir una variante como CAML.Net, solamente hay que añadir las expresiones abstractas heredando de las ya existentes e implementando PreCode() y PostCode().

Todos estos nodos que forman las expresiones abstractas al fin al cabo son plantillas (templates), y podrían a su vez ser clases abstractas, yo opte por una implementarlas como clases normales, debido a que algunos de los nodos son terminales y otros intermedios y no tienen por qué ser heredados, de este modo la factoria base (ASTNodeFactoryBase) usa miembros virtuales parar crear dichos nodos terminales e intermedios.

Después para poder inyectar en el parser dichas expresiones debemos crear una nueva factoría heredada de la factoría base (ASTNodeFactoryBase).

(diagrama ASTNodeFactoryBase)

Para generar CAML lo que he hecho es heredar de cada plantilla ó expresión abstracta definida, una nueva clase que redefine los métodos virtuales PreCode() y PostCode() que son los encargados de sustituir cada nodo del árbol sintáctico en CAML.

Y crear una factoría (ASTNodeCAMLFactory) que se encarga de crear las expresiones.

Publicado por Carlos Segura con no comments
Archivado en:

YACAMLQT (Yet another CAML query tool) Redux (1)

Hace un mes, John Holliday, me pidió a ver si podíamos integrar su CAML.net con mi YACAMLQT, a la vez que ampliar mi herramienta para soportar otro tipo de consultas como adds y updates.

YACAMLQT, es una utilidad que convierte una sentencia SQL en CAML, el lenguaje de consulta de Sharepoint. (Véase YACAMLQT, YACAMLQT2 y YACAMLQT-CAML.Net)

Estos días entre rato bueno y rato malo, he reescrito totalmente el código de YACAMLQT, para hacerlo más sencillo (por supuesto usando TDD), en principio el objetivo ha sido emular el antiguo YACAMLQT, pero dotándolo de un diseño más sencillo y ampliable.

YACAMLQT, es un programa que convierte una sintaxis tipo SQL en CAML (el lenguaje de consulta de SharePoint).

Es decir esto:

WHERE ((Column1 = "Value1") AND (Column2 = "Value2")) OR ((Column3 = 10)
AND (Column3 <> NULL)) GROUPBY Column1 ORDERBY Column1, Column2 ASC, Column3 DESC

En esto:

<Query>
  <Where>
    <Or>
      <And>
        <Eq>
          <FieldRef Name="Column1" />
          <Value Type="Text">Value1</Value>
        </Eq>
        <Eq>
          <FieldRef Name="Column2" />
          <Value Type="Text">Value2</Value>
        </Eq>
      </And>
      <And>
        <Eq>
          <FieldRef Name="Column3" />
          <Value Type="Integer">10</Value>
        </Eq>
        <IsNotNull>
          <FieldRef Name="Column3" />
        </IsNotNull>
      </And>
    </Or>
  </Where>
  <GroupBy>
    <FieldRef Name="Column1" />
  </GroupBy>
  <OrderBy>
    <FieldRef Name="Column1" />
    <FieldRef Name="Column2" Ascending="True" />
    <FieldRef Name="Column3" Ascending="False" />
  </OrderBy>
</Query>



El proyecto completo lo subiré a CodePlex en unos días, con su código fuente que poco a poco y con ayuda espero ir ampliando.

Por si alguien quiere echar una mano en el proyecto, voy a contar alguno de los entresijos del diseño de la aplicación.

Lo primero que he diseñado es el analizador morfológico (lexer) que se encarga de identificar dentro de un string, las distintas unidades sintácticas (tokens) con las que construiremos un analizador sintáctico y semántico (parser) con el cual construiremos un árbol sintáctico (AST) que por último recorreremos para transformar el SQL en CAML u otra variante como CAML.Net.

El lexer, está compuesto por una clase base, ScannerBase que contiene las partes más básicas del lexer, he extraído esta clase base una vez que tenía el analizador morfológico completo ya que de esta manera podemos realizar otro tipo de analizadores.



Las funciones básicas como comerse los espacios (EatSpaces()), detectar si es el final de línea (EndOfLine()) , saltar caracteres (SkipChar()) son parte de ScannerBase. Lo más importante de esta clase es la propiedad CurrentChar que devuelve el último carácter leído y el método GetCharMoveNext(), que obtiene un carácter y se mueve a la siguiente posición.

Para los que habéis usado el unix flex, GetCharMoveNext() es similar a input().

Esta clase ScannerBase utiliza internamente una clase ScannerState que mantiene el estado para poder releer un token ó unidad sintáctica.

Los tokens en el caso de YACAMLQT, consisten en las palabras reservadas propias de SQL, así como los distintos operadores, los campos y los valores (cadena, fecha, lógico y numérico).

A diferencia del unix flex, esto no se trata de un unput(), ya que mediante este volveríamos al carácter anterior. En este caso, como lo importante del analizador es obtener una unidad sintáctica, o token, lo que he hecho es implementar un método llamado BackToken() que lo que hace es posicionar el lexer justo al comienzo del último token obtenido, de modo que GetToken() volverá a devolvernos el mismo token.

La clase Scanner, hereda como es de suponer de ScannerBase, e implementa GetToken(), el responsable de de devolver un token, y CheckCorrectBracketsAndQuotes() que es el responsable de comprobar que los paréntesis y las comillas están correctamente.

Dentro de la clase Scanner, el método GetToken() es el responsable de identificar cada uno de los tokens, para lo cual he realizado un método para identificar cada uno de los distintos tokens. GetToken() usa los métodos ScanDate(), ScanString(), ScanOperator(), ScanNumber() y ScanReservedWordOrSymbol().

ScanOperator() y ScanReservedWordOrSymbol() usan un diccionario para identificar los distintos operadores y palabras reservadas. En el caso de ScanReservedWordOrSymbol(), si el token leído no se encuentra en el diccionario de palabras reservadas estaremos identificando un símbolo ó identificador.

Para terminar con esta primera parte, y siguiendo el principio de responsabilidad única, se ha implementado la clase Token como un contenedor y TokenFactory como una factória encargada de crear los distintos tipos de tokens ó unidades sintácticas. La clase Scanner es la que usa la factória para crear los distintos Tokens.



La clase Token, puede contener los distintos tipos de tokens, en principio todos aunque pueden ser de diferentes tipos, mantendrán su valor como un string. El resto de propiedades para identificar el tipo de token (TType) ó el tipo de valor (ValueType) son una enumeración.

Publicado por Carlos Segura con 2 comment(s)
Archivado en:

Mi particular visión del Test Driven Development (TDD)

Cuando nos enfrentamos al diseño de un programa sea el que sea, partimos de un estado que podemos llamar “A” problema, y como es obvio un estado “B” en el que tenemos resuelto el problema, por medio de un programa.

Si la programación fuera como las matemáticas, cosa que “no es” aunque  se fundamente en ello; la solución ideal sería la línea recta. Una línea recta que nos lleva del punto “A” al punto “B”, directamente, sin rodeos.

Es la solución más ELEGANTE, por qué es la solución más CLARA y BREVE que se puede dar.

Hay partes de la programación en donde existen uno o varios algoritmos que podemos usar y que son como la línea recta es decir ya están optimizados y no hay manera de mejorar (algoritmos de ordenación, búsqueda, etc..) pero cuando hablamos de un sistema de mayor tamaño, donde se ven involucrados más componentes la cosa cambia.

Existen miles de maneras de llegar de “A” a “B”, podemos hacer tirabuzones, hipérbolas, curvas mágicas y un sinfín de figuras geométricas que nos llevarán también de “A” a “B”. Los programadores somos capaces de crear miles y miles de esas formas mágicas. (Es nuestra naturaleza, como le dijo el escorpión a la rana)

De modo que nos enfrentamos a un problema doble, llegar del punto “A”, problema, al punto “B”, programa  sin morir en el intento. Y hacerlo de la manera más ELEGANTE.

No hace mucho, hablaba Rodrigo, del “Principio KISS” y del “Divide y Vencerás”, este último es sin duda la práctica que seguimos todos los programadores desde que tenemos conocimiento de nosotros mismos, es decir de que somos eso “Programadores”.
 
Debemos resolver un problema, es decir crear un programa “B”, que resuelva “A”, y hay miles de soluciones ó caminos posibles que nos llevarán de “A” a “B”.

Nosotros no disponemos de un algoritmo determinado, de una solución magistral como la ecuación de la recta que pasa por dos puntos, cada programador es un mundo y su percepción tanto del problema como del modo de llegar a la solución (diseño) podemos decir que es casi única, cuya aproximación es inversamente proporcional a la complejidad del problema.

A un problema más sencillo, hay más posibilidades de que dos programadores sigan el mismo camino, a un problema más complejo la desviación entre las soluciones tiende a distar más.

No existe la certeza de que nuestra solución sea la más optima, clara y concisa y lo que es peor tampoco podemos medir desviación alguna, puesto que cuanto más complejo es el programa más variantes tiene y por ende para poder medir dicha desviación, deberíamos conocer la línea recta, cosa que a priori es imposible.

Partiendo como base de que la línea recta sería la solución “perfecta” del problema, tenemos una complicada tarea.

Pero por otro lado una línea no es más que una sucesión de puntos, de modo, que podemos interpretar cada punto como una parte de la solución, y aquí volvemos al “Divide y Vencerás”.

Gracias a que tenemos técnicas como el TDD o ATDD, podemos ir punto por punto trazando nuestra línea.

“Solo escribimos el código necesario para pasar la prueba”, esta frase que resume en esencia que es “Test Driven Development”, también es la mejor manera que conozco de ir punto por punto trazando la solución de “A” a “B”, siguiendo esa imaginaría línea recta que sería la solución más ELEGANTE, CLARA y BREVE que se puede dar.



Publicado por Carlos Segura con 11 comment(s)
Archivado en:

Veneno en los dedos


En la vida de todo programador hay un “día especial”, algunos tendréis que hacer memoria, otros mucha memoria y algunos no lo recordareis pero es el día en que uno toma conciencia de sí mismo y se da cuenta de que es un “PROGRAMADOR”. (¡Qué fea palabra!… léase “CODER” please)

No estoy hablando de ser “programador”, si no de ser “PROGRAMADOR”. Me refiero al momento en que te das cuenta de que el código es importante, que eres una máquina de tirar líneas que buscas mejorar día a día y de que el veneno de los 1s y los 0s está dentro de ti, del momento en que te das cuenta que todo es programable, de que a la silla de ruedas de tu abuelo se le puede poner un motor y programarlo, de que la gameboy de tu primo lleva un Z80 y seguro que hay alguna forma de meterle mano y…..en fin, te das cuenta de que el teclado es una extensión de tus dedos.

Os contaré como fue mi momento.

Yo cacharreaba con ordenadores como muchos de vosotros, que si un ZX81, un Commodore 64, etc…,etc… Allá por el año 1989 (yo tenía 19 años), un amigo de mi cuadrilla (Iñaki) me propuso hacer un programa para la empresa en que trabajaba su padre, era una empresa de excavaciones pequeña, CAMES, que hacía cosas generalmente para empresas más grandes.

El programa demandado consistía en llevar un control de los partes de los empleados y las máquinas; había que controlar el número de horas que se empleaba en cada obra. Tuvimos algunas reuniones en la oficina de la empresa y me explicaron con todo detalle cómo se llevaban los partes manualmente y los controles que se debían hacer semanalmente y mensualmente, así como los trabajos que había que re-facturar a terceros.
Durante las reuniones tome un montón de notas tratando de no perder detalle de lo que querían que el programa hiciera exactamente.
Por aquel entonces, había aprendido algunos leguajes de programación, como Basic, Pascal, C, algo de Lisp y Prolog, y dBase3, para el asunto me decante por dBase3, no por nada especial, pero las librerías btreeve que usaba entonces en Basic y en C, daban bastante guerra. También pensé en la comodidad de que dBase contaba con campos de entrada que admitían validaciones sin mucho esfuerzo, así como poder examinar las tablas y ver cualquier detalle de los datos. Otro de los factores importantes en la decisión fueron los listados, ya que hacer listados con dBase era coser y cantar. En fin dBase era perfecto para hacerlo todo sin demasiado esfuerzo.

De modo que me encerré en casa e hice el programa; unos días más tarde recibí en mi casa (la de mis padres en realidad y en mi habitación más concretamente) a las personas a las que debía enseñar el programa. Estuvimos toda la tarde revisando las especificaciones y surgieron varias cosas. Al terminar, yo no estaba del todo satisfecho con el programa a pesar de que cumplía con las especificaciones salvo en algún pequeño detalle que surgió durante la demo.

Un amigo me hablo de Clipper el compilador de dBase, me dejo un manual y me dijo que sería mucho más profesional hacerlo con Clipper (87). Así que rehíce el programa completamente desde cero.

Finalmente entregué el programa y cobre 60.000 pesetas (un dineral en el año 89) y muy agradecido asesoré a la empresa también acerca del ordenador y la impresora que debían comprar.

Los primeros viernes de cada semana, momento en que se pagaban las horas extras a los empleados, yo tenía que bajar a la empresa exclusivamente por si surgía algún problema o alguno de los cálculos no salían correctamente. El argumento de “Benito”, el encargado,  era que los empleados (tíos muy curtidos de la obra y con carácter más bien duro) sabían mejor que nadie cuanto debían cobrar de modo que, por si acaso, sería mejor que yo estuviese allí en caso de que no coincidieran las cifras.



Lo estuvimos haciendo aproximadamente durante un mes hasta que lo dieron por válido, ya que, los cálculos siempre salían correctamente si se habían introducido bien los datos.

Ese fue mi primer programa de ordenador, y mis primeros ingresos como “programador”.

Aún así, todavía no era un programador.

Tiempo después, mientras estudiaba FP por las mañanas, entre a trabajar por las tardes en una empresa de programación. Ellos programaban en Clipper pero no muy bien, de modo que, les di algunas lecciones, suena chulesco lo sé, pero lo mejor de todo es que mi profesor de COBOL de FP, trabajaba allí por las tardes, de modo que, él por la mañana me daba COBOL y yo por la tarde le daba Clipper a él. Cosas de la vida.

Bueno, estando allí hice multitud de programas, facturaciones, contabilidad,  etc…etc …




Aún así, no era un programador de los que hablaba al principio, pero el momento llegó y lo recuerdo perfectamente.

No estaba satisfecho con algunas de las cosas repetitivas que hacíamos programando, así que, cree un meta lenguaje que nos ahorraba horas y horas de programación de esa repetitiva, lo hice en casa por las noches e incluso hice un manual para que todo el mundo en la empresa pudiese usarlo. Ese fue el momento que arruinó mi vida :-).

Ese momento en que no te basta con lo que los lenguajes te dan, cuando empiezas a crear bibliotecas de código, a optimizar en ensamblador rutinas lentas, cuando creas un sistema que es capaz de ahorrar multitud de horas de programación, cuando los días y las noches se funden en la pantalla tirando líneas de código, leyendo programas de otros para aprender más y más, cuando no puedes pasar sin programar algo, lo que sea aunque sea solo por auténtico ocio, por ver si eres capaz de hacerlo o por la razón que sea, que seguro que es lo suficientemente buena como excusa para teclear.

¿Cómo te entro a ti el veneno?
Publicado por Carlos Segura con 11 comment(s)
Archivado en:

Testeo unitario para SharePoint: La importancia de llamarse "Test"

Testing es algo que todos los desarrolladores deberíamos hacer, y muy pocos hacen. Por no decir “Testing intensivo y consecuente”, pues los números se reducen a prácticamente cero... si le da curiosidad, revise las estadísticas mostradas en:

Especialmente el segundo vinculo es interesante, aunque por experiencia propia me arriesgaría a decir que los porcentajes de aplicación de testeo son mucho, mucho mas bajos.

Siendo sincero, escribir software es una de las cosas más divertidas para hacer en el mundo (lo digo por deformación profesional, probablemente), pero hacer pruebas para ese mismo software es una de las más aburridas. Y en algunos casos, es simplemente imposible, como lo es hacer pruebas para SharePoint.

Pero para comenzar por el principio, hay que hablar algo sobre testing en general.

El mundo del testing es amplio y ajeno: hay tantos tipos de testeo como tipos de desarrolladores... pero mirándolo desde una perspectiva global, podemos decir que hay:

- “Unit Test” (Prueba unitaria) – verifica que las unidades individuales de código fuente funcionan como se espera. Normalmente la unidad de código más pequeña es una función, método o propiedad.
- “Regression Test” (Pruebas de regresión) – Cuando se modifica algo que ya ha sido probado que funciona (con el Unit Test), es necesario garantizar que sigue funcionando apropiadamente después de algún tiempo: este es el trabajo de Regression Test
- “Integration Test” (Pruebas de Integración) – Cuando todas las unidades (que ya han sido probadas con Unit y Regression Test) se unen para trabajar conjuntamente, es necesario garantizar que todas funcionen como una unidad apropiadamente. Este es el trabajo del Integration Test
- “System Integration Test” (Pruebas de Integración de sistemas) – puede ser visto como una ampliación del anterior: este test garantiza que nuestro sistema (que ya ha sido probado con Unit, Regression e Integration Tests) puede funcionar con otros sistemas externos apropiadamente

En cuanto a metodologías, mis dos hermanas sicólogas me enseñaron que hay tres tipos de pruebas: Black Box, White Box y Grey Box testing (el modelo ha sido tomado “prestado” de la psicología).

- “Black Box Testing” – la prueba no sabe nada sobre cómo funciona internamente el sistema a probar... solamente que si se le entregan algunos parámetros de entrada, deben salir algunos resultados. Black Box Testing le entrega parámetros a una función (correctos e incorrectos) y observa los resultados que la función devuelve
- “White Box Testing” – por el contrario, la prueba conoce perfectamente el funcionamiento interno del sistema a probar, y crea las pruebas basado en el.
- “Grey Box Testing” – ya se imaginaran lo que es, una mezcla de los dos.

Finalmente, es necesario hablar de algo que está de moda, “Test-driven development” (TDD). Esta es una técnica de programación basada en escenarios de prueba o de funcionamiento (Test o User Cases), bastante ligada a metodologías de desarrollo como Agiles, que indica que primero hay que hacer el diseño del software (sus clases, métodos, propiedades y eventos), luego generar las definiciones (el “esqueleto” del código), luego crear los métodos de prueba ANTES que el código mismo, y finalmente, crear el código para rellenar el esqueleto.

Bien, esto es más o menos la parte teórica. Como los desarrolladores de código que somos, ¿Qué es lo importante de todo esto?

  1. Primero que todo, y antes que nada, Unit Test. Unit Test me permite dormir tranquilo, pues me asegura que mi código funciona correctamente y seguirá funcionando después de que lo he modificado (¿se puede usar Unit Test como Regression Test? Esta es una discusión bizantina a la que nunca nadie llega a una conclusión, algo por el estilo a que es mejor CSharp o Visual Basic, o Windows o Linux. Vea por la ejemplo la discusión que surgió en el ultimo PDC al respecto en http://channel9.msdn.com/pdc2008/TL61/).
  2. Como segunda medida, si se está usando (o se quiere usar) TDD, la decisión de usar Black o White Test es importante... o, mejor dicho, si se quiere usar TDD, hay que usar Black Box Testing. Punto. O hay que iniciar una nueva discusión bizantina sobre si es posible iniciar el desarrollo en Black Box y luego continuarlo en White Box, lo que lleva al modelo de Grey Box...

Noten que hasta ahora he intentado no tomar partido por ninguno de los puntos mencionados. Todo porque mi punto es SharePoint, no discusiones teológicas sobre cómo, cuando y donde hacer testeo de software. Pero llegamos a la parte interesante: SharePoint.

Cuando se trata de crear Testeo Unitario para software creado por uno mismo, es decir, en donde se tiene el código fuente, construir las clases de prueba es largo y tedioso, pero es posible de hacer con las herramientas estándar para el efecto (como las que tiene Visual Studio mismo, por ejemplo). Cuando lo que se desea es testear código que utiliza el Modelo de Objetos de otro programa, como ocurre cuando se escribe software para SharePoint o cualquier otro servidor (SQL, Exchange, BizTalk, etc), es necesario “hacerle creer” a nuestro código que esta interactuando con el servidor, pero sin que lo haga en realidad, porque no se desean tener dependencias con él.

Imagínese una situación no tan hipotética: se crea un método que comprueba los derechos de una Librería de SharePoint; si se utiliza una instalación real de SharePoint para hacer las pruebas, es necesario mantener esa configuración por todo el tiempo del desarrollo y mas allá para garantizar que los resultados de las pruebas sean consistentes en el tiempo. Peor aún, todos los desarrolladores del grupo tienen que disponer de la misma instalación para que sus pruebas también sean consistentes entre desarrolladores. Esto es prácticamente imposible de conseguir y, además, muy engorroso. Para solucionar el problema existen diferentes tipos de herramientas que “falsifican” el Modelo de Objetos del servidor (Mockers, Stubbers, etc)

Como ya hemos dicho varias veces Carlos y yo, el problema con SharePoint y Unit Test es que el Modelo de Objetos de SharePoint tiene muchas clases selladas o sin constructor público. Este ha sido el gran problema hasta ahora para poder usar Mockers y Stubbers, pues ellos no saben qué hacer con un objeto sellado o sin constructor público. El posting “Testeo Unitario para SharePoint: acercándose a la respuesta definitiva – parte 1” que escribimos anteriormente comenzó a mostrar cómo se puede iniciar el testeo unitario para SharePoint usando la última versión de TypeMock. Las próximas partes continuaran con la parte práctica de la creación y codificación de las clases de prueba. Pero en esta segunda parte se trata de discutir la importancia de Unit Test, Regression Test, Black y White Box Testing y TDD.

Uno de las características más importantes de TypeMock es la relación intrínseca entre el código de trabajo y el código de testeo, es decir, el fabricante ha escogido por un modelo de “White Box Testing”. Veamos un ejemplo el ejemplo de una función que simplemente imprime los elementos de una Lista de SharePoint:

Código de trabajo:

        public void GetCollection01()
        {
            SPSite mySite = new SPSite("http://wsses");

            using (SPWeb myWeb = mySite.OpenWeb())
            {
                foreach (SPList myList in myWeb.Lists)
                {
                    foreach (SPItem myItem in myList.Items)
                    {
                        Console.WriteLine(mySite.Url + " - " + myWeb.Title + " - " + myList.Title + " - " + myItem.ID.ToString());
                    }
                }
            }
        }

Código de Prueba:
        [TestMethod()]
        public void GetCollection01Test()
        {
            SPWeb fakeWeb = Isolate.Fake.Instance<SPWeb>(Members.ReturnRecursiveFakes);
            SPList fakeList = Isolate.Fake.Instance<SPList>(Members.ReturnRecursiveFakes);
            SPItem fakeItem01 = Isolate.Fake.Instance<SPItem>(Members.ReturnRecursiveFakes);

            using (var recorder = RecorderManager.StartRecording())
            {
                SPSite myFakeSite = new SPSite("");
                recorder.ExpectAndReturn(myFakeSite.Url, "fakeSiteUrl").RepeatAlways(); 
                recorder.ExpectAndReturn(myFakeSite.OpenWeb(), fakeWeb);
            }

            Isolate.WhenCalled(() => fakeWeb.Title).WillReturn("fakeWeb");
            Isolate.WhenCalled(() => fakeWeb.Lists[2].Title).WillReturn("fakeList");
            Isolate.WhenCalled(() => fakeItem01.ID).WillReturn(1);

            Isolate.WhenCalled(() => fakeWeb.Lists[2].Items).WillReturnCollectionValuesOf(new List<SPItem>
               {
                    fakeItem01
               });

            Class1 target = new Class1();
            target.GetCollection01();

            var fakeItemList = fakeWeb.Lists[2].Items;

            foreach (SPItem item in fakeItemList)
            {
                Isolate.Verify.WasCalledWithAnyArguments(() => item.ID);
            }
        }

Para la prueba unitaria se está usando una combinación de “Natural Mocks” y el nuevo “AAA API” de TypeMocks. Observe un par de puntos específicos:

  • Cada objeto “real” necesita un objeto “mockeado”: myWeb -> fakeWeb, myList -> fakeList, etc
  • Para cinco líneas de código de trabajo se necesitan 17 líneas de código de prueba

Esto conlleva las siguientes consecuencias generales:

Para poder crear un objeto “fantasma” (un mock) que sustituya efectivamente al objeto “real” en la clase de trabajo, es necesario conocer explícitamente su construcción. Esto excluye directamente la utilización de TDD: código de prueba debe ser escrito antes del código de trabajo

  • Una consecuencia de esta consecuencia es que el código unitario deberá ser escrito por el desarrollador mismo que está escribiendo el código de trabajo: al final, es él/ella el que sabe que está haciendo. El peligro con esta construcción es que se van a escribir clases de prueba que casi siempre van a pasar el examen... voluntaria o involuntariamente, el desarrollador va a omitir las pruebas que tienen más posibilidades de fallar
  • Una segunda consecuencia de esta consecuencia es que el desarrollador probablemente utilizara más tiempo creando las clases de prueba que las clases de trabajo
  • Por la relación tan estrecha entre código de trabajo y de prueba, cuando se modifica algo en el código de trabajo, hay que modificar también el código de prueba. Es decir, Regression Test es imposible de realizar

El fabricante de TypeMocks está trabajando intensivamente para darle solución a estos problemas, y los primeros resultados van saliendo: ciertas partes del Framework de TypeMocks es capaz de crear mocks para trabajar con Black Box Testing, es decir, entregando un objeto “mockeado” al método de trabajo y revisando los resultados producidos, sin tener conocimientos de su funcionamiento interno.

En cualquier caso, la discusión de si testeo blanco o negro es el mejor, o si Test-Driven Development es realmente valido continuaran hasta el fin de los siglos. Lo importante para nosotros, los que estamos metidos en el lio de hacer que código funcione apropiadamente no son las discusiones teóricas, sino los Frameworks que nos permitan trabajar confortablemente. TypeMocks es hasta el momento lo que más se acerca a una solución viable para hacer testeo de código de SharePoint, así que vale más que la pena de darle por lo menos una mirada e intentar hacerlo funcionar.

Publicado por Carlos Segura con no comments
Archivado en:

Drupal and SharePoint. Dos formas de hacer una tortilla (charla en Navarra)

El próximo día 18 de diciembre tendremos en el Grupo de Usuarios de Navarra la charla (de los huevos y de los CKarlos), Karlos G. Liberal y un servidor hablaremos de algunas de las bondades de nuestras herramientas de trabajo (Drupal y SharePoint).

El magnifico cartel ha sido realizado por nuestros amigos de Sistema Formación.

La Agenda del evento es la siguiente:

La jornada será el jueves, 18 de diciembre
Hora de recepción: 18:00

Centros de Excelencia Software
Salón de actos
Plaza Cein, 1, Polígono Mocholi
Noáin Navarra 31110
España

AGENDA
18:30 - 19:30: Drupal and SharePoint. Dos formas de hacer una tortilla. Los CKarlos.
19:30 - 20:00: Celebración 2º aniversario de NavarraDotNet: zorionak zuri y tarta de cumpleaños
20:00 - 21:00: Drupal and SharePoint. Dos formas de hacer una tortilla. Los CKarlos
21:00 - ... : Cena!

Para apuntarse podéis hacerlos desde este enlace*
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032393640&Culture=es-ES

Publicado por Carlos Segura con no comments
Archivado en:

Cenando, Buenas Practicas, Historia de terror

Cenando

El otro día paso Unai por Pamplona y estuvimos cenando y departiendo sobre todas esas cosas frikis que nos gustan. Una suerte para los que habéis podido asistir a los cursos que ha impartido de Entity Framework  y WCF.

Durante la cena, [[degustábamos unos “Penne Arrabiata” (no seáis mal pensados, que son macarrones con tomate un poco picante) y un “Ochoa Tempranillo” (recomendado)]], hablamos de; libros, de código, de más código, de bugs, de depuración, de tecnología, del bien y del mal (lo típico), no sé si ayer hablamos de sexo (no me acuerdo, pero con el frio que hacía es posible que no :-).

Bueno, la cosa es que le comenté algunas de las cositas del Api de SharePoint.

¿Buenas Prácticas?

Como ya he contado en alguna ocasión, las colecciones de SharePoint, son a la antigua usanza (Net 1.0), es decir que implementan IEnumerable, en una clase contenida, esto lo hacen en una clase abstracta SPBaseCollection del cual heredan el resto de colecciones de SP.

Bien, hasta el momento no hay mucho problema, es un tema de diseño, necesario para implementar las serializaciones de los objetos además de la persistencia que realiza sharepoint via COM.

Si realicemos una consulta usando SPQuery, (SPQuery nos permite recuperar elementos de una lista usando CAML, que es un meta-lenguaje basado en XML que tiene SharePoint para muchas cosas, entre ellas recuperar elementos de las listas)

<Where>
  <Geq>
    <FieldRef Name=”ID/>
    <Value Type=”Integer>10</Value>
  </Geq>
</Where>
Nos devolverá todos los elementos de una lista donde el ID sea mayor que 10.

Para poder ejecutar una consulta CAML sobre una lista tenemos una clase llamada SPQuery a través de la cual montamos la consulta.

SPQuery query = new SPQuery
                {
                   Query = "CONSULTITA EN CAML"
                };

Para recuperar una colección de Items que cumplen esta consulta basta con indicar a la lista los items que queremos pasandole un SPQuery:
SPListItemCollection ítems = lista.GetItems(query);
Bien, como muchos ya sabéis que no es muy buena práctica devolver null, para no tener que comprobar si ítems es null antes de acceder, de modo que lo correcto es devolver una colección vacía (en este caso, como veremos luego tiene otro fundamento).

GetItems internamente nos devuelve una nueva colección
public SPListItemCollection GetItems(SPQuery query)
{
    return new SPListItemCollection(this, query);
} 

Pero qué pasa si la consulta está mal formada ó es incompleta.  Lo que cabe de esperar es:

1.- Que nos devuelva una excepción en el momento de crear SPQuery (cosa que no hace)
2.- Que nos ofrezca una propiedad o algo para comprobar si la consulta es correcta (cosa que no hace)
3.- Que nos devuelva una colección vacía (cosa que hace peligrosamente a medias)

¿Por qué lo hace a medias? Porque aparentemente nos devuelve una colección vacía, es decir si la consulta está mal, ítems no es null. Pero OJO no es una colección valida.

SPQuery query = new SPQuery
                {
                        Query = "MI mala CAML Query"
                };

SPListItemCollection items = list.GetItems(query);

if (items!= null)
{
    Debug.WriteLine("Soy una colección no nula. Parece que valgo...");
    
    // Ahora reviento
    foreach (SPListItem item in items)
    {
    }
}

Las colecciones de este tipo en SharePoint, son de carga retardada de modo que la colección se carga cuando realmente vamos a usarla (Lazy-Load / Proxy), en ese momento se hace una petición SPRequest que es al que se encarga de recuperar el contenido y obtener la colección de elementos. (fundamento)

En ese momento se usa la consulta SPQuery que le hemos pasado para recuperar los datos, y al tratar de cargarla, como la consulta está mal formada, da una excepción (no advertida ni documentada), y la colección sigue siendo una colección hasta que usemos alguna de sus propiedades o tratemos de recorrerla. Es decir no es una colección vacia, si no una colección donde todo se ha quedado mal inicializado si intentas un items.Count antes de recorrer la colección tambien dará una excepción ya esta va a producirse de igual manera al cargar los datos.

De modo que la buena práctica se convierte en mala práctica ya que se pasa de hacer una comprobación de null antes, a tener que hacer un Try/Catch en el momento de recorrer la colección (como decimos por aquí, cojonudo).

Como alternativa, se puede implementar un método por ejemplo, vía extensión;  para comprobar que la consulta es valida y en caso de no serla que nos devuelva una colección bien formada cuando menos. Otra alternativa podría ser otro método como EnsureCollection, a través del cual podamos recuperar la excepción si nos interesa comunicar que la consulta esta mál formada.

La cosa sería algo así:

public static SPListItemCollection TryGetItems(this SPList list, SPQuery query)
{
    SPListItemCollection items; 

    try
    {
        items = list.GetItems(query);
        int count = items.Count;
    }
    catch(SPException ex)
    {
        query.Query = string.Empty;
        items = list.GetItems(query);                
    }
    
    return items;
}

JA, pero ahí no termina la cosa …  los señores de SharePoint son unos fenómenos optimizando y lo que hacen SPQuery internamente es generar una Vista (propiedad ViewXml de SPQuery), para optimizar el rendimiento, esta vista en Xml, se genera reuniendo todas las propiedades de SPQuery, y se genera siempre y cuando no se ha generado antes (optimización)

De modo, que si cambiamos la propiedad Query de SPQuery, la consulta interna ViewXml no cambia (ya se genero antes), manteniendo la última consulta generada, para lo cual debemos limpiar ViewXml.

query.Query = string.Empty;
query.ViewXml = string.Empty;
items = list.GetItems(query); 

¿Por qué que les habría costado implementar un flag de suciedad y reconstruir la ViewXml cada vez que el objeto este sucio? ¿por qué no documentarlo?

En fin, la cena estuvo genial.

Publicado por Carlos Segura con 4 comment(s)
Archivado en:

He leido "Code Clean", de Robert C. Martin

He terminado de leer el último libro de Robert C. Martin, Clean Code. 

De Robert, había leído otros dos libros, “UML para programadores Java”, una guía práctica y sin rodeos de cómo usar UML en proyectos reales; y cuando digo práctica es que no se anda por las ramas y en ocasiones en un tono incluso “irónico” explica perfectamente cómo debemos usar UML.


El otro libro es Agile Principles, Patterns, and Practices in C# (Robert C. Martin Series), que puedo decir de este libro ampliamente comentado, uno de los que se deben tener.  (Ya sabéis que se lo recomiendo a todo el mundo)

Bueno, de modo que “Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series) ” tenía todos los boletos de ser un gran libro. No ha defraudado en absoluto.

Apenas empezarlo, en la introducción ya me había pillado. (Ilstración de la introducción)

http://www.osnews.com/images/comics/wtfm.jpg

El libro explica cómo escribir buen código, código legible y eficiente.  Los ejemplos son en Java, pero tener en cuenta que estamos hablando de cómo escribir buen código, habla del significado de los nombres, de las funciones,  de los argumentos, del tipo de retorno, de cómo comentamos el código, de las reglas de formato, de objetos y estructuras de datos, de la gestión de errores, de las pruebas unitarias, del diseño simple, de sistemas, de concurrencia, de refinamiento, de olores y heurística.  Habla de estilo, de buen estilo.

De veras, me ha parecido un libro impresionante, con unos ejemplos claros, con un estilo cuidado y detallado, sin dejar cosas fuera, insistiendo en las cosas importantes (esto a mí me gusta, así entran mejor las cosas)

Vamos un libro que entra de lleno en mi TOPTEN.

Publicado por Carlos Segura con 5 comment(s)
Archivado en:

Resumen del DevCamp en NavarraDotNet

Un "poquito" tarde (y con mucha ayudita) os dejo el resumen con todos los detalles del DevCamp en el blog de NavarraDotNet

http://www.navarradotnet.com/post/navarradotnet-en-el-7bdev_camp7d.aspx

Y la información sobre el próximo evento el University Tour

http://www.navarradotnet.com/post/el-University-Tour-viene-a-la-UPNA.aspx 

(Para los que no lo sepan, en la Upna se esta organizando un DotNetClub)

http://www.navarradotnet.com/post/se-esta-cociendo-un-DotNetClub-en-la-UPNA!!.aspx

y como no, siempre vuelve a casa por navidad ... (como el turron)

http://www.navarradotnet.com/post/Chema-Alonso-en-CuatroVientos-Una-sesion-dirigida-a-estudiantes.aspx

Toda la información sobre el paso del Guille por Pamplona (Gracias Guille)

http://www.navarradotnet.com/post/gracias-Guille.aspx

 

Publicado por Carlos Segura con no comments
Archivado en:
Más artículos Página siguiente >