En esta versión hay un calendario con un resumen semanal de las sesiones de entrenamiento

También he ajustado algunos de los gráficos para que se muestren más claramente, el gráfico de sesiones por defecto muestra las 10 últimas sesiones salvo que se seleccionen otras

Una cosa interesante es la agregación, en el momento que hemos seleccionado un conjunto de sesiones podemos ver agregados los resultados, mostrando el total de Km, el total de entrenamiento y las medias de velocidad y pulsaciones,

Las “Auto Laps” quedan agregadas de modo que podemos ver un gráfico completo por ejemplo de una semana completa.

Una cosa interesante es que ahora se pueden editar los archivos xml que hemos extraído del reloj pudiendo añadir notas, una clasificación de cómo te has sentido en el entrenamiento y una url (por ejemplo a GPSSies) con la ruta que has seguido.

También como no he solucionado un montonazo de bugs…

Podeís descargar esta versión desde aquí.

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…

    public class FuzzyTest
    {
        private readonly FuzzySystem _engine = new FuzzySystem();

        public FuzzyTest()
        {
            FuzzyVariable varA = new FuzzyVariable("A");
            varA.Memberships.Add(new TrapezoidMembership("Cerrado", 0, 0, 5, 5));
            varA.Memberships.Add(new TrapezoidMembership("Medio", 4, 4, 6, 6));
            varA.Memberships.Add(new TrapezoidMembership("Abierto", 7, 7, 9, 9));
            _engine.Variables.Add(varA);

            FuzzyVariable varB = new FuzzyVariable("B");
            varB.Memberships.Add(new TrapezoidMembership("Cerrado", 0, 0, 5, 5));
            varB.Memberships.Add(new TrapezoidMembership("Medio", 4, 4, 6, 6));
            varB.Memberships.Add(new TrapezoidMembership("Abierto", 7, 7, 9, 9));
            _engine.Variables.Add(varB);

            FuzzyVariable varR = new FuzzyVariable("R");
            varR.Memberships.Add(new TrapezoidMembership("Frio", 0, 0, 3, 3));
            varR.Memberships.Add(new TrapezoidMembership("Templado", 3, 3, 6, 6));
            varR.Memberships.Add(new TrapezoidMembership("Caliente", 7, 7, 9, 9));
            _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.

    public class FuzzyExpression
    {
        private readonly FuzzyVariable _variable;
        private string _state;
        private double? _value;

        public double Value
        {
            get
            {
                if (_value.HasValue)
                    return _value.Value;
                _value = _variable.Fuzzify(State);
                return _value.Value;
            }
        }

        public string State
        {
            get { return _state; }
        }

        public FuzzyExpression(FuzzySystem engine, string literal)
        {
            _variable = engine.Variables[literal];

            if (_variable == null)
            {
                throw new FuzzyException("variable not found.");
            }
        }

        public FuzzyExpression(double value)
        {
            _value = value;
        }

        public FuzzyExpression Is(string state)
        {
            _state = state;
            _value = _variable.Fuzzify(_state);
            return this;
        }

        public FuzzyExpression Set(string newState)
        {
            _state = newState;
            return this;
        }

        public static FuzzyExpression operator |(FuzzyExpression a, FuzzyExpression b)
        {
            return new FuzzyExpression(Math.Max(a.Value, b.Value));
        }

        public static FuzzyExpression operator &(FuzzyExpression a, FuzzyExpression b)
        {
            return new FuzzyExpression(Math.Min(a.Value, b.Value));
        }

        public static bool operator false(FuzzyExpression a)
        {
            return 0 > a.Value;
        }

        public static bool operator true(FuzzyExpression a)
        {
            return a.Value > 0;
        }
    }

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

            _engine.AddRule(x =>
                            x.Variable("A").Is("Abierto") &&
                            x.Variable("B").Is("Abierto"))
                            .Then(x => x.Variable("R").Set("Caliente"));

            _engine.AddRule(x =>
                            x.Variable("A").Is("Abierto") &&
                            (x.Variable("B").Is("Cerrado") || x.Variable("B").Is("Medio")))
                            .Then(x => x.Variable("R").Set("Templado"));

            _engine.AddRule(x =>
                            x.Variable("B").Is("Abierto") &&
                            (x.Variable("A").Is("Cerrado") || x.Variable("A").Is("Medio")))
                            .Then(x => x.Variable("R").Set("Templado"));

            _engine.AddRule(x =>
                            x.Variable("A").Is("Cerrado") &&
                            x.Variable("B").Is("Cerrado"))
                            .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:

   _engine.AddRule(x =>
                        x.Variable("A").Is("Abierto") &&
                        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)

    public class FuzzyRule
    {
        private readonly FuzzySystem _engine;
        private readonly Func _condition;
        private Func _then;

        public double Value { get; set; }

        public FuzzySystem Engine
        {
            get { return _engine; }
        }

        public FuzzyRule(FuzzySystem engine, Func condition)
        {
            _engine = engine;
            _condition = condition;
        }

        public FuzzyExpression Eval()
        {
            Value = _condition(Engine).Value;

            if (Value > 0)
            {
                return _then(Engine);
            }

            return null;
        }

        public void Then(Func then)
        {
            _then = then;
        }
    }

Defuzzyficando

Para evaluar nuestro sistema ..

            for (int a = 0; a < 10; a++)
            {
                for (int b = 0; b < 10; b++)
                {
                    _engine.Variables["A"].InputValue = a;
                    _engine.Variables["B"].InputValue = b;
                    _engine.Consecuent = "R";

                    var r = _engine.Defuzzy();

                    Console.WriteLine(string.Format("A {0} - B {1} = {2,-6} [{3,-10}][{4,-10}] = {5}",
                        a,
                        b,
                        r,
                        _engine.GetVariableState("A",a),
                        _engine.GetVariableState("B",b),
                        _engine.GetVariableState("R", r)));
                }
            }
        }

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 …

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

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.

   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)

Parte 2 http://www.ideseg.com/YACAMLQTYetAnotherCAMLQueryToolRedux2.aspx
Parte 1 http://www.ideseg.com/YACAMLQTYetAnotherCAMLQueryToolRedux1.aspx

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.

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.

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.

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.

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?