CodeSegment - Carlos Segura Sanz (blog)

NavarraDotNet - ¡Volvemos a la carga! - El Futuro

csegura — Wed, 10 Jun 2009 15:12:24 GMT

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 Microsoft

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

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

csegura — Tue, 26 May 2009 23:47:39 GMT

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)

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

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

csegura — Fri, 22 May 2009 13:49:40 GMT

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.

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

csegura — Fri, 22 May 2009 09:50:52 GMT

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.

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

csegura — Mon, 27 Apr 2009 13:26:05 GMT

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.

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

csegura — Sun, 19 Apr 2009 19:06:23 GMT

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.