Angel "Java" Lopez : Generación de Código

Generando un modelo desde la base de datos usando AjGenesis

lopez — Wed, 02 Dec 2009 11:46:06 GMT

AjGenesis, mi proyecto open source de generación de código, usa tareas, templates (plantillas) y un modelo de libre definición, para generar artefactos de texto, en general código fuente, pero también archivos cualesquiera, como configuraciones, definición de proyectos, etc. Muchos de los ejemplos que están en el proyecto y otros que publiqué aparte, usan modelos serializados como archivos XML o de texto. Pero el modelo inicial puede ser cualquier entrada: no sólo esos archivos, sino cualquier fuente de información que nos dé alguna base de modelo. Hasta podemos armar archivos de modelo (recuerden, el modelo lo deciden uds, dónde va, qué tiene, es todo libre) desde otro modelo. Hace unos dos años, escribí sobre generar el modelo desde la base de datos. En mi opinión, la base de datos no es el modelo más expresivo, pero es uno muy ubicuo: puede servir como punto de partida, y desde la base de datos, generar un modelo que podemos refinar posteriormente.

(sobre el tema de modelos pueden leer Modelos y metamodelos en AjGenesis: los metamodelos no son necesarios ni obligatorios, pero es un tema que estoy agregando en el proyecto, como opcional).

(un tipo de modelo a explorar Otro modelo para AjGenesis)

Hoy quiero entonces volver sobre el tema de generar un modelo desde otro modelo, esta vez usando el esquema de la base de datos que tengamos entre manos. Es sólo un ejemplo “prueba de concepto”. Pero en el proyecto ágil en que estoy participando, el equipo tomó la base que ya tenían y generó un modelo usando técnicas como las de este ejemplo, usando AjGenesis, y ahora, ya abandonaron la base inicial, y usan directamente el modelo generado alguna vez y refinado desde entonces.

Pueden bajar el ejemplo actual de mi Skydrive DatabaseExample01.zip. (el código está en el repositorio de código en Codeplex, bajo el directorio examples\DatabaseExamples). El .zip de Skydrive tiene todo lo necesario, incluso la versión en desarrollo de AjGenesis ya compilada.

Despues de bajarlo y expandirlo, tenemos estas carpetas:

Hay un solo proyecto de ejemplo. EL contenido de Projects\Northwind\Metadata.xml:

<Metadata>
  <Project>
    <Name>Northwind</Name>
  </Project>
  <Database>
    <Name>Northwind</Name>
    <ConnectionString>server=.\SQLEXPRESS;database=Northwind;Integrated Security=true</ConnectionString>
  </Database>
</Metadata>

Describe el string de conexión a usar para llegar a la base de ejemplo. Estoy usando la Northwind, en SQL Server (pueden usar el full o el express). Si no tienen esa base de datos, los scripts de creación están en el directorio Sql.

Para generar el proyecto, el modelos con sus entidades, ejecutar:

MakeModelFromDatabase.cmd

AjGenesis (compilado en el directorio Bin) comienza su trabajo:

El comando que ejecutamos contiene:

Bin\AjGenesis.Console Projects\Northwind\Metadata.xml Tasks\DatabaseProcess.ajg

Este comando carga el contenido de Metadata.xml como modelo en memoria, y ejecuta la tarea DatabaseProcess.ajg escrita en el lenguaje dinámico que uso AjBasic. Esta tarea usa las vista de Information Schema para obtener información acerca de la estructura de la base de datos (usando estas vistas, que están definidas en el estándar SQL, y presentes en varias bases de datos, nos abre la puerta para conseguir trabajar con otras marcas que no sean MS SQL Server; debería probar, por ejemplo, con Oracle).

La tarea crea el archivo Projects\Northwind\Project.xml:

<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>
<Project>
  <Name>Northwind</Name>
  <Model>
    <Entities>    
      <Entity Source="Entities/Customer.xml"/>    
      <Entity Source="Entities/Shipper.xml"/>    
      <Entity Source="Entities/Supplier.xml"/>    
      <Entity Source="Entities/Order.xml"/>    
      <Entity Source="Entities/Product.xml"/>    
      <Entity Source="Entities/OrderDetail.xml"/>    
      <Entity Source="Entities/CustomerCustomerDemo.xml"/>    
      <Entity Source="Entities/CustomerDemographic.xml"/>    
      <Entity Source="Entities/Region.xml"/>    
      <Entity Source="Entities/Territory.xml"/>    
      <Entity Source="Entities/EmployeeTerritory.xml"/>    
      <Entity Source="Entities/Employee.xml"/>    
      <Entity Source="Entities/Category.xml"/>
    </Entities>
  </Model>
</Project>

El proyecto y las entidades son parecidas a las que usé en Generando aplicaciones con AjGenesis (pero no es igual, estoy experimentando con mejoras). Parte del contenido del archivo generado Projects\Northwind\Entities\Customer.xml nos da una idea de lo que se captura de una “Entity”:

<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>
<Entity>
  <Name>Customer</Name>
  <Description>Customer</Description>
  <SetName>Customers</Name>
  <Descriptor>Customer</Descriptor>
  <SetDescriptor>Customers</SetDescriptor>
  <SqlCatalog>Northwind</SqlCatalog>
  <SqlSchema>dbo</SqlSchema>
  <SqlName>Customers</SqlName>
  <Properties>
    <Property>
      <Name>CustomerID</Name>
      <Description>CustomerID</Description>
      <SqlName>CustomerID</SqlName>
      <SqlLength>5</SqlLength>
      <IsKey>True</IsKey>
      <SqlType>nchar</SqlType>
      <SystemType>String</SystemType>
      <IsNullable>False</IsNullable>
    </Property>
....
  </Properties>
</Entity>

La lógica principal de todo este proceso de generación, reside en la tarea Tasks\DatabaseProcess.ajg, de nuevo escrita en AjBasic (I love this language! :-) un fragmento:

cmd = new System.Data.SqlClient.SqlCommand()
cmd.Connection = conn
cmd.CommandText = "select * from Information_Schema.Tables where Table_Type = 'BASE TABLE'"
conn.Open()
PrintLine "Reader"
dr = cmd.ExecuteReader()
Tables = CreateList()
while dr.Read()
  PrintLine "Table " & dr.Item("Table_Name") & ": " & dr.Item("Table_Type")
  Table = CreateObject()
  Table.SqlCatalog = dr.Item("Table_Catalog")
  Table.SqlSchema = dr.Item("Table_Schema")
  Table.SqlName = dr.Item("Table_Name")
  Table.Name = Table.SqlName.Replace(" ","")
  
  if IsPlural(Table.Name) then
    Table.SetName = Table.Name
    Table.Name = ToSingular(Table.Name)
  else
    Table.SetName = ToPlural(Table.Name)
  end if
  
  Table.Descriptor = Table.Name
  Table.SetDescriptor = Table.SetName
  
  Table.Description = Table.Name
  
  Tables.Add(Table)
end while
dr.Close()

Posibles mejoras

Como escribí más arriba, este ejemplo es una “prueba de concepto”; una versión anterior la usamos en un proyecto real. Pero hay varios puntos a mejorar:

- Usar el modelo generado para generar una aplicación que funcione, con scaffolding o no.

- Soportar más metadata que obtengamos via Information Schema

- Probar con otras marcas de bases de datos, y con bases de datos reales

- Tratamiento de relaciones: detectar borrados en cascadas, soportar claves primarias compuestas, otras acciones.

Otros posts relacionados (aparte de los ya mencionados):

Generando Código: Hello World con AjGenesis

AjGenesis: Modelo generado desde los assemblies

Modelo textual para generación de código con AjGenesis

Si es la primera vez que se topan con generación de código con AjGenesis, tengo varios posts escritos. Recomiendo un video, producido gracias a la comunidad ALT.NET Hispano: Resultado de la VAN ALT.NET Hispano sobre Generación de Código

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Generando código con AjGenesis usando archivos de mapeo de NHibernate

lopez — Mon, 23 Nov 2009 09:18:30 GMT

En estos días, estuve trabajando en generar código de clases C#, usando como punto de partida los archivos .hbm, que se usan en NHibernate para especificar el mapeo de clases y tablas de bases relacionales. Como es usual, cuando encaro algo de generación de código uso AjGenesis, mi proyecto open source de generación de código (practico el “dog fooding” :-).

(English version of this post Generating code with AjGenesis using NHibernate hbm files)

Pueden bajar un ejemplo de lo que estoy haciendo de mi Skydrive:

Examples > AjGenesis > NHibernateMappingExample01.zip

(el código en desarrollo está en el trunk, en este change actual, en el directorio examples\NHibernateMappinp:

pero si quieren ir directamente al ejemplo, pueden bajárselo completo desde el Skydrive que mencioné, que incluye el ejecutable de AjGenesis de la versión en desarrollo, no necesitan compilar nada).

Luego de expandir el archivo del ejemplo, tendrán este contenido:

Para crear clases C#, pueden probar de ejecutar los comandos:

GenerateClasses AjFirstExample
GenerateClasses AjTest

Para crear un proyecto .NET con los archivos .cs y .hbm, y una solución, ejecutar:

GenerateProject AjFirstExample
GenerateProject AjTest

Los archivos generados, en ambos casos, quedan en el directorio Build.

Hay dos proyectos ejemplo que son AjFirstExample, con dos mapeos simples, y AjTest, que tiene mapeos más interesantes, con “bags” y relaciones “many to one”.

En el ejemplo, cada proyecto se describe con un simple archivo Project.xml:

<Project Name="AjTest">
</Project>

En cuanto necesite más información, lo agregaré ahí, o en tags meta de los propios archivos de mapeo y configuración.

Este es uno de los archivos de mapeo que sirven de modelo inicial para este ejemplo de generación, en Projects\AjTest\Mappings, Department.hbm:

<?xml version="1.0" encoding="utf-8" ?> 
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
  assembly="AjTest.Entities"
  namespace="AjTest.Entities"
  >
  <class name="Department" table="departments">
    <id name="Id" column="Id" type="Int32">
      <generator class="native"/>
    </id>
    <property name="Description" type="String"/>
    <bag name="Employees" lazy="true" inverse="true" cascade="all">


      <key column="IdDepartment"/>
      <one-to-many class="AjTest.Entities.Employee, AjTest.Entities"/>
    </bag>  
  </class>
</hibernate-mapping>

Este es el código generado para este mapeo, Department.generated.cs:

using System;
using System.Collections.Generic;
using Iesi.Collections.Generic;
namespace AjTest.Entities 
{
  public class Department {
    public int Id { get; set; }
    public string Description { get; set; }
    public IList<Employee> Employees { get; set; }
    public Department() 
    {
      this.Employees = new List<Employee>();
    }
  }
}

Veamos el proceso de generación. Este es el contenido de GenerateProject.cmd:

@echo off
set ProjectName=%1%
if "%1%"=="" set ProjectName=AjFirstExample
Bin\AjGenesis.Console.exe Projects\%ProjectName%\Project.xml Tasks\AddMappings.ajg Tasks\BuildCSharp.ajg
xcopy Libraries\*.* Build\%ProjectName%\CSharp\Src\Libraries /Y /Q

La línea más importante es la que invoca a AjGenesis.Console.exe. El contenido de Project.xml se carga en memoria. La tarea AddMapping.ajg se carga y ejecuta (está escrita en un lenguaje dinámico, afectuosamente llamado AjBasic), y luego, se procesa la tarea BuildCSharp.ajg. Veamos el código de AddMapping.ajg:

' Add mappings from directory if not specified in Project model
Include("Utilities/Utilities.tpl")
if not Project.Mappings then
  Project.Mappings = CreateList()
  
  di = new System.IO.DirectoryInfo("Projects/${Project.Name}/Mappings")
  
  for each fi in di.GetFiles("*.hbm.xml")
    filename = fi.Name
    Project.Mappings.Add(filename.Substring(0, filename.Length - 8))
  end for
end if

Encuentra y agrega los nombres de los archivos de mapeo contenidos en el directorio de Mapping, dentro del proyecto (noten que se pueden usar clases y objetos del framework .NET). Una tarea más interesante es la GenerateCSharp.ajg. Primero, carga la dll de NHibernate, para usar más adelante su parser de archivos hbm:

include "Utilities/Utilities.tpl"
include "Utilities/FileUtilities.tpl"
include "Utilities/TypeUtilities.tpl"
Include("Utilities/NHibernateUtilities.tpl")
include "Templates/CSharp/UtilitiesCs.tpl"
include "Templates/CSharp/CSharpFunctions.tpl"
AssemblyManager.LoadFrom("Libraries/NHibernate.dll")
parser = new NHibernate.Cfg.MappingSchema.MappingDocumentParser()

Crea objetos dinámicos, donde coloca información de la solución y el proyecto a crear:

if not Project.BuildDir then
  Project.BuildDir = "Build/${Project.Name}/CSharp"
end if
message "Creating Directories..."
FileManager.CreateDirectory(Project.BuildDir)
FileManager.CreateDirectory("${Project.BuildDir}/Sql")
FileManager.CreateDirectory("${Project.BuildDir}/Src")
FileManager.CreateDirectory("${Project.BuildDir}/Src/Libraries")
message "Defining Solution and Projects..."
Project.Solution = CreateObject()
Project.Solution.Guid = "FAE04EC0-301F-11D3-BF4B-00C04F79EFBC"
Project.Solution.Projects = CreateList()
message "Defining Entities Project..."
PrjEntities = CreateObject()
PrjEntities.Includes = CreateList()
PrjEntities.Guid = CreateGuid()
PrjEntities.COMGuid = CreateGuid()
Project.Solution.Projects.Add(PrjEntities)
Project.Entities = CreateList()

Ahora, itera sobre cada archivo hbm, lo lee usando el parser del propio NHibernate, toma información sobre las clases a generar:

for each MappingName in Project.Mappings
  filename = "Projects/${Project.Name}/Mappings/${MappingName}.hbm.xml"
  mapping = parser.Parse(OpenAsStream(filename))
    
  for each hbmclass in mapping.Items where IsType(hbmclass, "HbmClass")
    Entity = CreateObject()
    
    Project.Entities.Add(Entity)
  
    Entity.ClassName = hbmclass.name
    Entity.Namespace = mapping.namespace
    
    ' Namespace as default project name for Entities Project
    if not PrjEntities.Name then
      PrjEntities.Name = mapping.namespace
      PrjEntities.Directory = "${Project.BuildDir}/Src/${PrjEntities.Name}"
      FileManager.CreateDirectory(PrjEntities.Directory)
    end if
    
    Entity.Properties = CreateList()
    
    if hbmclass.Id then
      Property = CreateObject()
      Property.Name = hbmclass.Id.name
      Property.Type = HbmTypeToCSharp(hbmclass.Id.type1, Entity.Namespace)
      Entity.Properties.Add(Property)
    end if
    
    for each item in hbmclass.Items
      if IsType(item, "HbmProperty") then
        Property = CreateObject()
        Property.Name = item.name
        Property.Type = HbmTypeToCSharp(item.type1, Entity.Namespace)
        Entity.Properties.Add(Property)
      end if
      
      if IsType(item, "HbmManyToOne") then
        Property = CreateObject()
        Property.Name = item.name
        Property.Type = HbmTypeToCSharp(item.class, Entity.Namespace)
        Entity.Properties.Add(Property)
      end if
      if IsType(item, "HbmSet") then
        Property = CreateObject()
        Property.Name = item.name
        Property.IsSet = true
        Property.Type = HbmTypeToCSharp(item.Item.class, Entity.Namespace)
        Entity.Properties.Add(Property)
      end if
      if IsType(item, "HbmBag") then
        Property = CreateObject()
        Property.Name = item.name
        Property.IsList = true
        Property.Type = HbmTypeToCSharp(item.Item.class, Entity.Namespace)
        Entity.Properties.Add(Property)
      end if
    end for    
  end for
end for

Pueden extender esta capacidades, procesando más tags (debería escribir un ejemplo usando los tags meta que puede contener el hbm; ya utilitarios de Java, como el venerable XDocLet, usaban esos tags para ayudarse en la generación de código, en Hibernate), y detectar más formas de mapeo de NHibernate. Ahora, pasa a la generación de código:

for each Entity in Project.Entities
  TransformerManager.Transform("Templates/CSharp/Entity.tpl", "${PrjEntities.Directory}/${Entity.ClassName}.generated.cs", Environment)
  PrjEntities.Includes.Add(CreateFileCs("${Entity.ClassName}.generated"))
end for

La tarea genera los archivos .cs, y también crea un archivo de solución y otro de proyecto C#, copiando y embebiendo los archivos de mapeo originales:

for each MappingName in Project.Mappings
  filename = "Projects/${Project.Name}/Mappings/${MappingName}.hbm.xml"
  targetfilename = "${PrjEntities.Directory}/${MappingName}.hbm.xml"
  System.IO.File.Copy(filename, targetfilename, true)
  PrjEntities.Includes.Add(CreateFileType(MappingName,"hbm.xml"))
end for
for each CsProject in Project.Solution.Projects where CsProject.ProjectType<>"Web"
  FileManager.CreateDirectory(CsProject.Directory)
  FileManager.CreateDirectory(CsProject.Directory & "/Properties")
  TransformerManager.Transform("Templates/CSharp/CsProject.tpl", "${CsProject.Directory}/${CsProject.Name}.csproj", Environment)
  TransformerManager.Transform("Templates/CSharp/AssemblyInfoCs.tpl", "${CsProject.Directory}/Properties/AssemblyInfo.cs", Environment)
end for
TransformerManager.Transform("Templates/Solution.tpl", "${Project.BuildDir}/Src/${Project.Name}.sln", Environment)

Esta es la solución generada:

Próximos pasos

Debería trabajar en algunos puntos:

- Generar una solución más completa, como en otros ejemplos de AjGenesis (con un proyecto de infraestructura, un proyecto de Service Layer o similar, una presentación web, etc…).

- Soportar más opciones de mapeo de NHibernate.

- Usar los tags meta.

Por ahora, pueden jugar con este ejemplo. Pueden cambiar los templates para generar más artefactos, por ejemplo, código VB.NET.

Gracias a @fabiomaulo por avisarmr de las capacidades públicas de parser de hbm dentro de NHibernate!

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Resultado de la VAN ALT.NET Hispano sobre Generación de Código

lopez — Tue, 27 Oct 2009 16:15:40 GMT

Gracias a la comunidad ALT.NET Hispano, quedó publicado el video de la VAN (des-conferencia virtual) sobre Generación de Código, al que fui invitado. Ahí presenté mi proyecto personal preferido, AjGenesis, generador de código, escrito en .NET, y publicado en código abierto. Pueden ver el resultado en:

VAN – Septiembre 26 de 2009 – Generación de Código

Ahí encontraran el video, enlaces, lecturas, y la presentación que utilicé, para descargar.

Al final de mi presentación, hubo discusión y preguntas. Uno de los puntos mencionados, fue cuales serán los próximos pasos de AjGenesis. Algo comenté ahí, pero me gustaría contestar algo más en detalle por acá:

- En principio, es un proyecto que me gusta, y que me ha resultado muy flexible. Y al que voy a seguir incorporando características.

- Hay desarrolladores que lo usan, pero son pocos, o por lo menos, no publican resultados, o escriben posts (en estos últimos 5 años, debe haber 4 post sobre AjGenesis NO escritos por mí, solamente; tampoco es mencionado mucho en las listas de correo, sobre desarrollo de software en general, que frecuento (debe haber dos o tres menciones en los últimos 3 años)). Entonces, como digo en la des-conferencia, “lo uso yo y mi tía Carlota”… :-)

- Hay que mejorar la documentación. Por ahora, estoy escribiendo posts casi todos los meses sobre el tema.

- Lo que me gustaría encarar, es poner en línea el tema de Code Generation as a Service, que menciono en la charla.

Como comento hacia el final de la presentación, cuando expongo sobre generación de código, lo hago mostrando ideas e implementaciones con AjGenesis, porque me siento más cómodo. Pero, por supuesto, hay multitud de otras herramientas, más documentadas, con más soporte, con más comunidad, que pueden usar. La idea de la presentación es que tengan contacto con lo pragmático de generar código, y que vaya quedando en claro por qué estamos hoy generando código: ante la multitud de tecnologías, frameworks y librerías, es un poco difícil zafar de escribir y escribir código. Y como las tecnologías, frameworks y librerías son buenas, en general, es difícil también, hoy por hoy, prescindir de ellas. He dejado enlaces a otras herramientas en la página de la VAN.

Otro camino a explorar sería abandonar todo eso, y buscar la simplicidad. Algo expongo en ¿Es tiempo de volver a la simplicidad?. Pero, yendo a la realidad, de todos los días, eso todavía no está, y quien sabe cuándo volveremos o conseguiremos eso. Así, que caemos de nuevo en tecnología, frameworks y librerías.

Como expongo en el post citado, otro camino, que algunos de Uds. habrán recorrido, habrá sido armarse su propio framework y librerías. Ante la calidad y cantidad de librerías disponibles, y todas las necesidades a cubrir, es un camino algo difícil de recorrer actualmente. Y aún recorrido ese camino, muchas veces nuestro framework necesita que trabajemos incorporando código o archivos de configuración, que bien podemos generar automáticamente desde un modelo.

Si es la primera vez que visitan este blog, y quieren conocer por qué le dedico tanto tiempo a la generación de código, y encontrar una explicación más detallada de lo que planteo en la charla y en los párrafos de arriba, les recomiendo leer primero mi post Sobre la generación de código. Más enlaces, más relacionados con AjGenesis, en Ver la luz con generación de código y AjGenesis :-)

Como verán en el video, y en algunos enlaces que están en la página de la VAN, y leen los posts anteriores sobre generación de código y AjGenesis que ya he escrito, la idea no es solamente generar código, sino generar código desde un modelo: llevamos años eludiendo modelos, solamente dibujándolos (en UML, por ejemplo), pero sin utilizarlos como instrumentos para implementar efectivamente un sistema. La conversión de un modelo a código concreto, ha quedado en nuestras manos. Y ante la cantidad del trabajo, es hora de “elevar el nivel de abstracción”, y comenzar a basarnos en modelos. De alguna forma, eso es lo que hicimos cuando pasamos de programar en lenguaje de máquina, a ensamblador, y luego, a lenguajes de programación: nos olvidamos de los detalles, y le dejamos ese trabajo a la propia máquina. Estamos generando código cada día: ya no armamos el .exe a mano (como en los tiempos de la ENIAC), sino que hay herramientas (compilador ¿recuerdan?) que pasa nuestro modelo (el programa escrito en un lenguaje de modelado de instrucciones, llamado lenguaje de programación) a código ejecutable (instrucciones para nuestros procesadores).

El tema es que desde hace años, nos hemos quedado en ese nivel de abstracción. Menciono en la charla, que hubo excepciones: hubo algunos avances y adoptamos modelos para olvidarnos de los detalles, en algunos casos. Un caso que menciono: Visual Basic (el clásico, de los noventa). Cuando apareció Visual Basic, ya no hubo que programar ventanas, botones y eventos de Windows, en C, ocupando decenas de líneas para hacer un simple “Hola, mundo” (era lo que yo llamo la “Era Petzoldiana”). Ahora, con un modelo gráfico, arrastramos botones, cajas de textos, y voilá: tenemos el código de un formulario (vean que en .NET, tanto en VB.NET como en C#, todavía es más evidente que generamos código: el diseñador genera el código correspondiente a crear los controles, ponerles las propiedades, por nuestra cuenta y orden).

Bueno, basta por ahora. Pasen y vean el video, vean las discusiones, y participen de la comunidad ALT.NET Hispano.

Si les interesa el tema de la generación de código, hay una lista de correo, sobre el tema, en español. Pueden ver los mensajes y suscribirse, en:

http://groups.google.com/group/codegeneration

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

La generación de código y el trabajo de desarrollo de software

lopez — Wed, 22 Jul 2009 14:04:06 GMT

Antes de ayer, 20 de Julio, @hallo twittereaba:

Recibió varias respuestas, acá va una mía y otra que recibió:

Lo que pasa es que hemos estado generando código por décadas. La herramientas que usamos para eso tiene nombre: compilador. Recuerdan los viejos días? Había que setear los relés en la ENIAC, o usar el panel frontal de la micro Altair para inicializar su memoria. Los compiladores acudieron en nuestra ayuda, generando código desde un modelo de más alto nivel: el lenguaje de programación.

Pero por las últimas tres décadas, no elevamos el nivel de abstracción: seguimos usando lenguajes de programación directamente, para programa. Algunas excepciones: el lenguaje SQL, que nos relevó de recorrer cursores o buscar en índices ISAM, o el diseñador de formularios de Visual Basic, que nos liberó de escribir decenas de páginas de código de Windows a la Petzold.

El generar código desde un modelo (como trato de promover desde mi proyecto personal AjGenesis), es la manera de obtener y usar un nuevo “lenguaje”: sea un DSL, domain specific language, o un DSM, domain specific model, o lo que querramos usar como punto de partida.

Hoy mismo tenemos demasiadas tecnologías, con miríadas de detalles y configuraciones a atender. Pienso en Spring Framework, Hibernate, Struts 2, JavaServer Faces, ASP.NET MVC, Web Services, Windows Communication Foundation, etc… Sabemos más cosas hoy de cómo desarrollar software, pero las aplicaciones actuales están infectadas de toneladas de detalles técnicos, fruto de problemas y errores. Muchos de esos detalles podrían ser derivados desde un modelo, como en mostrado en ejemplos de AjGenesis que he posteado por acá en los últimos años, creando salidas para diferentes tecnologías.

Si lo miran bien, esto es lo mismo que decir: “a=fact(4)” es el modelo, y registros de procesador, manipulación de pila, reserva y liberación de memoria, son los detalles que nos resuelve un compilador.´

Más respuestas en Twitter:

Sí, la manipulación de registros de procesador puede ser interesante la primera vez que la aprendemos, pero después de horas y horas de trabajo, y con fechas de entrega para mañana, puede volverse no sólo aburrida, sino también problemática. Es por eso que hubo motivación para crear assemblers, macro assemblers, lenguajes de alto nivel y compiladores para los mismos.

En mi tweet de arriba, mencion la inteligencia artificial. Bien, debo admitir que es sólo una idea, pero pienso que la generación de código es un campo apropiado para la inteligencia artificial aplicada, que es un término demasiado amplio hoy en día. Daría para otro post en detalle.

Otra pregunta:

Bien, es difícil que en corto y mediano plazo consigamos generar todo desde un modelo. Lo que más afecta: hay muchas tecnologías y cada año aparece un nuevo muchacho en elbarrio (Scala, Clojure, Rest, Cloud Computing, Sharding, aplicaciones móviles… etc…). Entonces, no hay una sola forma de generar software, siempre habrá trabajo para estudiar y aplicar nuevas tecnologías. Pero veo que en cada una de esas tecnologías, hay lugar para aplicar la generación de código, y si partimos de un modelo de alto nivel, el pasaje de una tecnología a otra debe ser menos traumático.

Estoy de acuerdo. Pero déjenme soñar: aplicaciones creando aplicaciones… No podríamos generar en el futuro ese tipo de aplicaciones? … Por lo menos para cuando lleguemos a la Enterprise de Star Trek :-)

Generanción de código: sky is the limit (es la frase directrix de AjGenesis… :-)

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Enlaces y noticias IV

lopez — Sun, 19 Jul 2009 13:51:36 GMT

Sigo con la costumbre coleccionar enlaces, de distintos temas. Los que me llamaron la atención:

PHP

Es el lenguaje más usado para el desarrollo de sitios dinámicos en la web. Tiene la simplicidad necesaria, y también el soporte de clases, librerías, acceso a base de datos como para hacerlo más poderoso. Tal vez se ha quedado en el desarrollo web, perdiendo en el terreno de programas de consola, servicios, o de ventanas. Hay montañas de código de ejemplo para estudiar y aprender. Algunos enlaces:

PHP programming tips and tricks Code Purity
Scripts Directory of PHP, ASP, ASP.NET, Java, Javascript, Perl and more! – Scripts
43 Must Read PHP Articles and Resources Hi, I'm Grace Smith
How To Create Your Own Stats Program (JavaScript, AJAX, PHP) Noupe
25 Resources to Get You Started with PHP from Scratch - Nettuts+
15 Wonderfully Creative Uses for PHP

Hay cantidad de sitios manejadores de contenidos (CMS) pueden ver

10 New PHP Content Management Systems(CMS)

http://php.opensourcecms.com/

Para un rápido Altas, bajas y modicaciones ver AjaxCRUD.com - Use PHP & AJAX to CRUD from a mysql database (create / read / update / delete)

No creo que alguien pueda pasar fácilmente de PHP a ASP.NET pero pueden leer Move from PHP to ASP.NET

Tiene sus años, pero es interesante Understanding MVC in PHP - O'Reilly Media

Un armador de proyectos, a la Apache Ant, pero en PHP: Phing

Comenzando con Joomla Beginners - Joomla! Documentation

Veo implementando el Template Attribute Language en PHP: http://phptal.org/

DEBEN VER PHPCamp: learn something new everyday

Para perderse en enlaces, http://delicious.com/ajlopez/php

.NET

Para los que quieren ver manejadores de contenido (CMS) en ASP.NET:

http://aspx.opensourcecms.com/

El área de código abierto de .NET está bien activo: Open Source .NET projects

Para estudiar: Expert to Expert- Brian Beckman and Erik Meijer - Inside the .NET Reactive Framework (Rx) Going

Un ejemplo de referencia FabrikamShipping – Home con Geneva Framework, autenticación federada y tutti li fiocci.

Un camino a explorar: reemplazar ORM (Object Relational Mapping) en runtime por generación de código: .NET ORM, Object Relational Mapping for .NET Telerik

Librería para Twitter http://tweetsharp.com/

ASP.NET MVC 1.0 ejecutando en Mono shaml-architecture - Google Code Basado en s#arp-architecture

Para mapear objetos http://automapper.codeplex.com/ (menos para el bueno de Rodolfo Finochietti que prefiere hacerse su propio mapeador :-)

Siempre es molesto el DataBinding a propiedades simples, habría que ver qué tal funciona http://www.codeproject.com/KB/cs/ObjectBindingSource.aspx (nested property binding)

Más de todo esto en http://delicious.com/ajlopez/dotnet

Generación de código

El proyecto Sculpture está muy bien armado, aunque focalizado en .NET http://sculpture.codeplex.com/ Es open source, se trasladó a la empresa:

http://www.dawliasoft.com/

Tienen una implementación de referencia: VotingManager.zip que partiendo de 55 líneas, consiguen generar una aplicación de 4111 líneas. Bueno, nada que el AjGenesis no pueda hacer… :-) … pero es más bonito.

Hibernate Class Generation Using hbm2java - O'Reilly Media Estoy reviendo esto, quiero comenzar a usar el tag <meta> para usar hibernate.cfg.xml y archivos .hbm.xml para alimentar como modelo a AjGenesis.

Para estudiar dos “approachs” Angle Bracket Percent - CodeDom vs T4- two approaches to Code Generation

Veo el editor de T4 T4 Editor - tangible T4 Editor plus UML tools

Desde AjGenesis puedo leer el archivo .dbml de Linq2Sql, que se puede generar desde la línea de comando con SqlMetal, tengo que estudiar Oleg Sych - » T4 Toolbox- LINQ to SQL classes generator

Yo tenía esta idea, pero la deseché por ser algo “convoluted”, pero es interesante: Using ASP.Net for Code Generation . En su tiempo, usé también PHP como lenguaje de generación, pero me gustó tener un lenguaje dedicado a generación con objetos dinámicos (AjBasic) con acceso a un framework de base (.NET por ahora), cosa que no tiene PHP en principio. Y en cuanto a usar ASP.NET, me obligaba a usar un lenguaje tipado .NET, que me resistía a hacerlo.

Siguiendo con T4, el lenguaje de templates de Visual Studio, a estudiar Angle Bracket Percent - The MVC T4 template is now up on CodePlex, and it does change your code

Parece interesante Sample Fluent NHibernate T4 Templates for Code Generation via LINQ To SQL

Steven Kelly siempre tiene algo interesante sobre DSM (Domain Specific Models) y generación de código. Comenta sobre Code Generation 2009 en Code Generation 2009 round-up

Para los que estén con el framework .NET de Lohtka, CSLA, pueden visitar el

CslaGenerator Google Groups

Ruby es un lenguaje que se presta a la generación de código, ver esto, de hace algunos años, pero a cargo del bueno Jack Herrington, autor de Code Generation in Action (alguien que vió la luz!!! :-) :

Como siempre, más información en http://delicious.com/ajlopez/codegeneration

Lenguajes de Programación

Descubriendo un clásico: Let's Build a Compiler

Un texto corto How does a an interpreter compiler work

Para estudiar Create a Language Compiler for the .NET Framework Using C# usa Reflection.Emit, bien a lo macho… :-)

Hay que escribir intérpretes y compiladores, “compiler generators are for sissies” :-), pero si quieren, pueden ver The Compiler Generator Coco/R

Más para ver Free Compiler Construction Tools- Lexers, Parser Generators, Optimizers (thefreecountry.com) y Basics of Compiler Design (pdf)

Para estudiar:

Michael Feathers on Programming Languages

Synrc Io Language CLR

Io (programming language) - Wikipedia, the free encyclopedia

InfoQ- The Ioke JVM Language- The power of Lisp and Ruby with an intuitive syntax

Ending the Era of Patronizing Language Design

Un volver a vivir:

History of the BASIC family of languages

Otro para el canal “Volver”, entorno de desarrollo xBase:

Xailer - El entorno de desarrollo definitivo en xbase

Free Pascal compilers and Pascal Programming - Freebyte's Guide to

Se acuerdan de MUMPS? MUMPS - Wikipedia, the free encyclopedia

Para leer APL, COBOL, & Dijkstra Paul Murphy ZDNet.com

Podría volver a estudiar: COBOL Programming Course, The COBOL Programming Language

Lista para buscar recursos Free Programming Tools, free compilers, free software components and

Excelente contenido Google Code University Programming Languages

Hay que ir viendo:

Clojure ver InfoQ- Rich Hickey on Clojure's Features and Implementation

Scala

Yo sigo trabajando en reimplementar las ideas de Clojure en C#, lo llamaba AjClojure, pero Rick Hickey (el creador de Clojure) me pidió que le cambiara el nombre (al fin tengo evidencia de que alguien lee mi Twitter!!! :-) Así, que en un rapto de imaginación, se llama AjSharpure. Pueden ir viendo mis avances en:

http://code.google.com/p/ajlisp/source/browse#svn/trunk/AjSharpure

Más para ver sobre los lenguajes que me interesan en:
http://delicious.com/ajlopez/programminglanguages
http://delicious.com/ajlopez/smalltalk
http://delicious.com/ajlopez/logo
http://delicious.com/ajlopez/scala
http://delicious.com/ajlopez/lisp
http://delicious.com/ajlopez/forth
http://delicious.com/ajlopez/haskell
http://delicious.com/ajlopez/python
http://delicious.com/ajlopez/ruby
http://delicious.com/ajlopez/functionalprogramming
http://delicious.com/ajlopez/cobol

MVPs

El bueno de Rodolfo Finochietti fue nombrado Microsoft MVP por segundo año consecutivo. Felicitaciones @rodolfof! MVP for another year. También felicitaciones para el pibe Woloski, que renovó el nombramiento.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Un caso de Uso de AjGenesis

lopez — Tue, 30 Jun 2009 10:04:02 GMT

En el grupo Google de Code Generation:

http://groups.google.com/group/codegeneration

encuentro este mensaje de Fernando Claverino

Usos de AjGenesis

Gracias a Fernando, por compartir su experiencia. Es importante, para AjGenesis, que los que lo usen compartan y comenten su experiencia, para poder ir viendo los usos, facilidades y problemas que tenemos con la herramienta. Comento acá gran parte del mensaje. Fernando usa AjGenesis para generar reportes, usando SQL Server por lo que entendí. En proyecto Medusa, estamos también generando reportes usando Reporting Services. Fernando escribe:

Modelo:

No definimos un archivo models.xml que apunta a cada item del modelo.
Tenemos una carpeta models y hay una task que la recorre
recursivamente y levanta todos los archivos del modelo (*.mod.xml).
Cuando se hace esto, seteamos dinámicamente a cada objeto cargado una
propiedad con el path relativo, que luego usamos en otras tasks. Los
artefactos se generan en la misma estructura de carpeta, pero dentro
de la carpeta build.

Este es un ejemplo de modelo obtenido de otra forma. Podemos partir de uno o varios modelos, obtenerlos de archivos o de otra fuente de información (como una base de datos).

Plugins:

Aca estamos haciendo algo de trampa. Si bien todos los artefactos
generados deberían construirse a partir del modelo, hay algunas cosas
que son dificiles de modelar. En nuestro caso generamos las consultas
MDX. Es muy difícil definir un modelo que soporte la riqueza de este
lenguaje. Asi que lo que hicimos fue definir en el archivo de
tecnología cual es el plugin a utilizar. El plugin es un template (que
genera la consulta MDX a partir del modelo). Vi en los ejemplos que en
la tecnología se suele definir el dialecto (esto sería algo parecido,
me parece).

Esta técnica que nosotros llamamos plugin, la usamos siempre que
queremos generar un caso particular no cubierto por los templates que
ya tenemos. En el archivo de tecnología podemos definir el onrows,
oncols y where de la consulta, pero en muchos casos esto varía en
función del modelo. Es como favorerer convención sobre configuración.
Si no configuro nada, uso el template que corresponde. Si defino un
plugin, uso ese.

Interesante. El usar un template dinámicamente, indicándo cuál usar en el propio modelo, en vez de en código duro de tares, es una capacidad que AjGenesis tiene desde el principio. Recuerdo los tiempos de ASP clásico (los noventa), donde se podía incluir otro archivo por nombre en el proceso de un archivo/página, pero el nombre debía ser especificado como constante, no podía ser especificado en ejecución. PHP influyó bastante en el diseño de AjBasic, y se permiten cosas como:

include "Tasks/Build${Technology.Programming.Dialect}.ajg"

Donde el archivo a incluir y procesar como tarea es determinado en ejecución a partir del estado del modelo (o de lo que sea).

Nivel de abstracción:

Aprovechamos la libertad del modelo para trabajar en un nivel más
abstracto. Es decir, en lugar de definir un reporte, definimos una
sección (grupo de reportes) y las posibles navegaciones. La
combinación de estas definen los reportes. Es decir, a partir del
modelo definido, una task lo combina y genera un nuevo modelo a partir
del cual se aplican los templates.

Exacto. Podemos elevar el nivel de abstracción en cualquier momento, si no lleva demasiado costo. Es la idea de AjGenesis: podemos modelar entidades, o mensajes, o lo que descubramos en nuestro dominio que es interesante modelar. Y al descubrir eso a modelar, vamos elevando el nivel de abstracción.

Fernando concluye que no encontraron, en su tiempo, otra herramienta que le diera tanta libertad en la definición de los modelos. Ciertamente, esa libertad es parte del diseño inicial de la herramienta.

Si Ud. tiene algun caso de uso de AjGenesis, podrá publicar su experiencia?

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Modelos y metamodelos en AjGenesis

lopez — Mon, 29 Jun 2009 09:28:30 GMT

AjGenesis genera código partiendo de un modelo, de libre definición. El modelo se lee desde un archivo .XML (en la versión AjGenesis 0.5) pero también se puede leer desde un archivo de texto. Sobre un modelo sencillo, y sobre la forma de modelo en texto, pueden leer:

Generando Código- Hello World con AjGenesis
Modelo textual para generación de código con AjGenesis

Ha sido una elección inicial de diseño que el modelo sea totalmente libre. El ejemplo más simple de modelo es el que especifica una aplicación Hello World, modelando el mensaje a mostrar:

<Project Company="ajlopez.com">

<Message>Hello, World</Message>

</Project>

Pero de vez en cuando, nos gustaría tener una especificación, algo que indique qué se puede poner o no en un modelo. Esto serviría, para poder construir, por ejemplo, programas que permitan validar el modelo a usar. Es como cuando uno tiene un Schema o DTD que define cómo es un tipo de documento XML, y es usado por distintos utilitarios, para validar y ayudar en la construcción del documento XML final.

Como desde el inicio, el modelo no es XML, sino un concepto abstracto, que por razones de implementación, en la versión actual está en XML, nunca agregué o me apoyé en schemas de XML para definir una estructura al modelo, en ningún ejemplo. Pero siempre quise, en algún momento, agregar, opcionalmente, que se pueda definir el modelo. Y que los mismos formatos que AjGenesis usa, puedan servir para definir esos modelos. La descripción del modelo debería ser otro modelo: es un metamodelo expresado de la misma forma a la que ya estamos habituados en AjGenesis (noten que, históricamente, los DTD siempre algo molestaron en el mundo XML, al no ser ellos mismos XMLs, aunque me apresuro a agregar que hubo otras razones más para reemplazarlos).

Como ejemplo inicial, el modelo de arriba es una instancia de todos los modelos que cumplen con este metamodelo:

<Metamodel Name="SimpleHelloWorld">

    <Types>

        <Type Name="Project">

            <Properties>

                <Property Name="Message"/>

                <Property Name="Company"/>

            </Properties>

        </Type>

    </Types>

</Metamodel>

Cada modelo tiene Types, que se describen en detalle. Si luego, tenemos un modelo de HelloWorld con múltiples mensajes:

<Project>

    <Messages>

        <Message>Hello, World One</Message>

        <Message>Hello, World Two</Message>

        <Message>Hello, World Three</Message>

    </Messages>

</Project>

lo podemos expresar en un metamodelo como:

<Metamodel Name="MultipleHelloWorld">

    <Types>

        <Type Name="Project">

            <Properties>

                <Property Name="Messages" ListOf="String" ItemName="Message"/>

            </Properties>

        </Type>

    </Types>

</Metamodel>

Ahora, tenemos una propiedad que no es simple, sino una lista, de strings. Pero que sus items tienen como nombre a Message (son de la forma <Message>String</Message>).

Tomemos un modelo más complejo. Puedo usar el “clásico” modelo de entidades, de:

Generando aplicaciones con AjGenesis

El proyecto más simple es AjFirstExample (dos entidades simples):

<Project>

    <Name>AjFirstExample</Name>

    <Description>First Example using AjGenesis</Description>

    <Prefix>AjFE</Prefix>

    <Domain>com.ajlopez</Domain>

    <CompanyName>ajlopez</CompanyName>

    <Model>

        <Entities>

            <Entity Source="Entities/Customer.xml"/>

            <Entity Source="Entities/Supplier.xml"/>

        </Entities>

        <Lists>

            <List Entity="Customer"/>

            <List Entity="Supplier"/>

        </Lists>

        <Forms>

            <Form Entity="Customer"/>

            <Form Entity="Supplier"/>

        </Forms>

        <Views>

            <View Entity="Customer"/>

            <View Entity="Supplier"/>

        </Views>

    </Model>

</Project>

Como ejemplo, recordemos la entidad Customer:

¿Cómo podemos representar esto en un metamodelo? De esta forma:

<Metamodel Name="EntityModel">

    <Types>

        <Type Name="Project">

            <Properties>

                <Property Name="Name"/>

                <Property Name="Description"/>

                <Property Name="Prefix"/>

                <Property Name="Domain"/>

                <Property Name="CompanyName"/>

                <Property Name="Model" Type="Model"/>

            </Properties>

        </Type>

        <Type Name="Model">

            <Properties>

                <Property Name="Entities" ListOf="Entity"/>

                <Property Name="Lists" ListOf="List"/>

                <Property Name="Views" ListOf="View"/>

                <Property Name="Forms" ListOf="Form"/>

            </Properties>

        </Type>

        <Type Name="Entity">

            <Properties>

                <Property Name="Name" />

                <Property Name="SetName" />

                <Property Name="Description" />

                <Property Name="Descriptor" />

                <Property Name="SetDescriptor" />

                <Property Name="SqlTable" />

                <Property Name="Properties" ListOf="Property" />

            </Properties>

        </Type>

        <Type Name="Property">

            <Properties>

                <Property Name="Name" />

                <Property Name="Type" />

                <Property Name="SqlType" />

            </Properties>

        </Type>

        <Type Name="List"/>

        <Type Name="View"/>

        <Type Name="Form"/>

    </Types>

</Metamodel>

(Faltaría completar los tipos Property, List, View, Form). Y la prueba de fuego, es que el propio metamodelo pueda expresarse como metamodelo:

<Metamodel Name="Metamodel">

    <Types>

        <Type Name="Metamodel">

            <Properties>

                <Property Name="Name"/>

                <Property Name="Types" ListOf="Type"/>

            </Properties>

        </Type>

        <Type Name="Type">

            <Properties>

                <Property Name="Name"/>

                <Property Name="Properties" ListOf="Property"/>

            </Properties>

        </Type>

        <Type Name="Property">

            <Properties>

                <Property Name="Name" />

                <Property Name="ListOf" Reference="Type" />

            </Properties>

        </Type>

    </Types>

</Metamodel>

¿Y para qué tanto trabajo? Para poder usar esa información para validar el modelo, es una razón. Pero también, recordemos, AjGenesis genera código. Podríamos generar el código de un diseñador, de un modelador web o gráfico, que permita:

- Leer y grabar el modelo
- Ver sus datos (gráficamente, o en formularios)
- Ingresar su contenido

Por ejemplo, podríamos armar un programa .NET WinForm, que muestre un árbol a la izquierda con la estructura de nuestro modelo (ej. Entidades) y que permita agregar las ramas de ese árbol. Podemos generar las clases tipadas que representen ese modelo en memoria. Y los códigos de los serializadores del modelo en XML o en texto o en lo que elijamos. También se podría leer el metamodelo desde un programa genérico, y que éste maneje el mostrado y el ingreso de datos del modelo, dinámicamente, en runtime:

Pero todo esto no es necesario para trabajar hoy por hoy con AjGenesis. Quería mencionarlo, porque lo tengo en suspenso desde hace unos años como idea. No es un tema prioritario por ahora, lo que más se necesita es documentación, ejemplos mejorados y ejemplos con nuevas tecnologías.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Transformando plantillas en AjGenesis

lopez — Sat, 27 Jun 2009 06:59:32 GMT

AjGenesis se base en modelo libre, y usa plantillas (templates) para facilitar la descripción y generación de un archivo de texto final. La forma más simple de transformar un archivo de plantilla en un archivo destino es con un comando como:

AjGenesis.Console Model.xml ModuleVb.tpl HelloWorld.vb

Donde Model.xml puede tener

<Project Company="ajlopez.com">

<Message>Hola, Mundo</Message>

<Author>Pepe</Author>

</Project>

ModuleVb.tpl es la plantilla:

' Automatically generated by AjGenesis

' http://www.ajlopez.com/ajgenesis

' Company ${Project.Company}

Module Module1

    Sub Main()

        System.Console.WriteLine("${Project.Message}")

    End Sub

End Module

Produciendo HelloWorld.vb

' Automatically generated by AjGenesis

' http://www.ajlopez.com/ajgenesis

' Company ajlopez.com

Module Module1

    Sub Main()

        System.Console.WriteLine("Hola, Mundo")

    End Sub

End Module

(Los ejemplos de HelloWorld que describo los pueden encontrar en la versión liberada 0.5, dentro del directorio examples, hay varios directorios HelloWorld*) (Más detalle en Generando Código- Hello World con AjGenesis)

La otra opción es desde una tarea, programáticamente:

AjGenesis.Console Model.xml Build.ajg

donde Build.ajg es un archivo de tareas, escrito en AjGenesis:

PrintLine "Generating HelloWorld"

TransformerManager.Transform("ModuleVb.tpl", "HelloWorld.vb", Environment)

El objeto TransformerManager es un objeto auxiliar, de los que están ya definidos en AjGenesis, para que podamos aprovecharlo. Su “gran método” es .Transform que toma:

- Nombre del archivo de plantilla
- Nombre del archivo a generar
- El Environment

Environment es otro objeto predefinido, que es un diccionario donde están definidos los nombres y valores de variables en curso. Tanto “TransformerManager” como “Environment” son claves/keys dentro de ese directorio. Cuando uno escribe en AjBasic:

a = 1

agrega automáticamente la entrada “a” y el valor 1 en el Environment.

Es común que la transformación de plantillas se escriba en tareas más complejas. Fragmento de un ejemplo (ver examples/HelloWorldNet20/Tasks/Build.ajg):

PrintLine "Creating Solution File"

TransformerManager.Transform("Templates\Solution.tpl", "${Project.BuildDir}\${Project.Name}\${Project.Name}.sln", Environment)

PrintLine "Creating VB.Net Project"

TransformerManager.Transform("Templates\ModuleVb.tpl", "${Project.BuildDir}\${Project.Name}\${Project.Name}Vb\Module1.vb", Environment)

TransformerManager.Transform("Templates\AssemblyInfoVb.tpl", "${Project.BuildDir}\${Project.Name}\${Project.Name}Vb\My Project\AssemblyInfo.vb", Environment)

TransformerManager.Transform("Templates\VbProject.tpl", "${Project.BuildDir}\${Project.Name}\${Project.Name}Vb\${Project.Name}Vb.vbproj", Environment)

'TransformerManager.Transform("Templates\VbProjectUser.tpl", "${Project.BuildDir}\${Project.Name}\${Project.Name}Vb\${Project.Name}Vb.vbproj.user", Environment)

PrintLine "Creating C# Project"

TransformerManager.Transform("Templates\ClassCs.tpl", "${Project.BuildDir}\${Project.Name}\${Project.Name}Cs\Program.cs", Environment)

TransformerManager.Transform("Templates\AssemblyInfoCs.tpl", "${Project.BuildDir}\${Project.Name}\${Project.Name}Cs\Properties\AssemblyInfo.cs", Environment)

TransformerManager.Transform("Templates\CsProject.tpl", "${Project.BuildDir}\${Project.Name}\${Project.Name}Cs\${Project.Name}Cs.csproj", Environment)

'TransformerManager.Transform("Templates\CsProjectUser.tpl", "${Project.BuildDir}\${Project.Name}\${Project.Name}Cs\${Project.Name}Cs.csproj.user", Environment)

Un problema que encontré, es que si regeneramos desde el modelo todos estos archivos finales, los pisamos, los creamos de nuevo. Supongamos que sólo queremos generar el archivo destino, si no existe de antes (una táctica destinada a preservar el archivo destino, por si lo hemos modificado nosotros). En un proyecto (el proyecto Medusa que mencionó en Generando y regenerando texto y código con AjGenesis, Generación de código con AjGenesis para Mere Mortals Framework), usamos esta rutina, que definimos en AjBasic:

sub TransformNewFile(tpl, target, tm, env)

    if System.IO.File.Exists(target) then

        return

    else

        tm.Transform(tpl, target, env)

    end if

end sub

Que invocamos, por ejemplo, con:

TransformNewFile("Templates\ClassPartialVb.tpl", ".\${Project.Name}BO\${Project.Name}BO\${Table.Name}\${Table.Name}.Partial.vb",TransformerManager, Environment)

Pero nos ha resultado muy útil, tener otra rutina, que reemplaza el archivo destino, pero si éste existe, solamente lo reemplaza si su contenido actual es distinto del contenido nuevo que vamos a generar:

sub TransformFile(tpl, target, tm, env)

    if System.IO.File.Exists(target) then

        target2 = target & ".tmp"

        tm.Transform(tpl, target2, env)

        content1 = System.IO.File.ReadAllText(target)

        content2 = System.IO.File.ReadAllText(target2)

        if content1 <> content2 then

            System.IO.File.Copy(target2, target, true)

        end if

        System.IO.File.Delete(target2)

    else

        tm.Transform(tpl, target, env)

    end if

end sub

Se puede mejorar (usar un stream en memoria, en lugar de un archivo temporal). Un ejemplo de uso:

TransformFile("Templates\DefaultAspx.tpl", ".\${Project.Name}Web\Default.aspx",TransformerManager, Environment)

TransformFile("Templates\DefaultAspxVb.tpl", ".\${Project.Name}Web\Default.aspx.vb",TransformerManager, Environment)

TransformFile("Templates\GlobalAsax.tpl", ".\${Project.Name}Web\Global.asax",TransformerManager, Environment)

TransformFile("Templates\MasterPageMainMaster.tpl", ".\${Project.Name}Web\MasterPageMain.master",TransformerManager, Environment)

TransformFile("Templates\MasterPageMainMasterVb.tpl", ".\${Project.Name}Web\MasterPageMain.master.vb",TransformerManager, Environment)

TransformFile("Templates\UserLoginAspx.tpl", ".\${Project.Name}Web\UserLogin.aspx",TransformerManager, Environment)

TransformFile("Templates\UserLoginAspxVb.tpl", ".\${Project.Name}Web\UserLogin.aspx.vb",TransformerManager, Environment)

TransformFile("Templates\WebConfig.tpl", ".\${Project.Name}Web\web.config",TransformerManager, Environment)

La rutina TransformFile nos ha resultado muy útil, al usar un sistema de repositorio de código. Cuando cambiamos el modelo, y regeneramos todo lo que determinamos que se genera (contrapuesto a lo que tenemos como archivos manuales en nuestra solución), ahora, cuando vamos a guardar en el repositorio de código, los archivos que no cambiaron su contenido (ni su fecha y hora de grabación) son los que se envían al servidor. Esto ha simplificado todos los commits, y hasta sirve para darse cuenta cuál es el efecto de un cambio en el modelo inicial: el propio software de repositorio de código nos avisa qué archivos quedaron cambiados.

Esas dos rutinas las pusimos en un archivo Templates\Utilities.tpl y las incluimos en nuestras tareas con:

include "Templates/Utilities.tpl"

Seguramente, comenzaran a aparecer en los ejemplos que vaya publicando.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez
http://www.facebook.com/ajlopez

Generando y regenerando texto y código con AjGenesis

lopez — Fri, 26 Jun 2009 09:25:00 GMT

En estos días de Junio, se ha desarrollado el interesantísimo congreso de generación de código (digamos, “el mundial” del Code Generation), con un programa envidiable:

Code Generation 2009 - Daily Event Programme

Encuentro en Twitter

(uso TweetDeck, con search “code generation”)

el enlace a este post de Steven Kelly (de MetaCase) sobre

Code Generation 2009 round-up

donde levanta y comenta impresiones sobre la conferencia. Curiosamente (o no, ya a esta altura), Kelly también usa Twitter para tomar feedback:

EelcoVisser: keynote by @markusvoelter and Steven Kelly at #cg2009: great overview of issues in model-driven development

HBehrens: Steven Kelly at #cg2009 keynote: "wizard based generators create a large legacy application you've never seen before"

A esta última referencia, Kelly comenta y responde:

The reference was to vendor-supplied wizards, often found in IDEs or SDKs, that create skeleton applications for you based on your input. Since the vendors take pride in just how much boilerplate they can spew out, you're left with a mass of generated code that you've never seen before, but must extend with your own code. Worse, you're responsible for maintaining the whole ensuing mixture, and there's no chance of re-running the wizard to change some of the choices -- at least not without losing or invalidating the code you've added. That's in sharp contrast with generation in DSM, where your input is in the form of a model which you can edit at any time. You get the speed of generation but can remain at a high level of abstraction throughout

Con DSM se refiere a Domain Specific Model. Pueden ver mis enlaces en http://delicious.com/ajlopez/dsm

Más info visitando el DSM Forum

Mi proyecto de código abierto AjGenesis está basado en modelo, en modelos de libre definición, justamente, orientados al dominio que uno quiera modelar. No son modelos gráficos, que son más “fancy”, pero hasta ahora, me han resultado útiles y flexibles. Traduciendo la cita de arriba, una de las quejas de Kelly es que hay herramientas que generan código, como un wizard dentro de un entorno de desarrollo, pero luego, cuando trabaja agregando código propio en la solución, ya no puede volver a regenerar código. Y que él ve una solución si partimos de un modelo específico de dominio. El modelo a partir puede ser la base de datos, un modelo abstracto de entidades, un modelo más orientado al sistema que estamos tratando de construir (me imagino modelos dedicados a CRM, o a mercados aún más verticales).

Bueno, el tema da para discutir. Prácticamente, ningún modelo produce todo lo que queremos, así que tenemos que dejar en nuestra aplicación, lugares, puntos de extensibilidad manual, forma de agregar código nuestro, sin que tengamos que perder lo generado. Y que sigamos teniendo la posibilidad, al cambiar el modelo inicial, de volver a generar la parte automática, sin perder lo agregado manualmente.

Desde hace algunos años, incluyo este “slide” en mis charlas sobre el tema. Explico que uno no genera todo, y que tiene que estar claro, cuales archivos de texto son generados, y luego regenerados desde el modelo cuantas veces uno quiera, cuáles son generados de una sola vez, y cuáles son agregados manualmente:

Uno tiene que decidir qué genera desde el modelo, y qué genera o agrega manualmente. Me encontrado con gente que utilizó AjGenesis sólo para generar los procedimientos almacenados. En el proyecto Medusa (que mencioné en mi post

Generación de código con AjGenesis para Mere Mortals Framework

)

estamos adoptando una solución en el sentido de la figura. Cuando lanzamos la generación automática desde el modelo, que incluye:

- Generación de scripts de generación de las tablas
- Generación de los procedimientos almacenados
- Generación de un proyecto de Business Objects (como pide el Mere Mortals Framework)
- Generación de una aplicación web ASP.NET (usando nuevamente el Mere Mortals Framework, por ejemplo, sus controles web)

hemos codificado las tareas, de tal forma que:

- Hay archivos que siempre se generan (se “pisa” la anterior versión, pero solamente si la nueva tiene un contenido distinto)
- Hay archivos que no se generan si ya existen (pocos archivos, que se han decidido ser “one shoot”, generados de una sola vez, y no más)
- Hay archivos que se respetan y no se generan (archivos que vamos agregando a los proyectos que vamos armando)

Estamos usando .NET. En el caso 2, caen las clases parciales, que es una forma de seguir especificando una clase, en un archivo adicional al original. En otras tecnologías, podríamos generar un archivo ClaseBase generado automáticamente, y un ClaseReal donde pudiéramos luego poner todo nuestro código manual.

Con esta estrategia, hemos alcanzado hasta ahora, gran parte de lo que imaginaba en la figura de arriba: poder generar siempre desde el modelo, sin tener que perder lo que ya tenemos.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Generación de código con AjGenesis para Mere Mortals Framework

lopez — Mon, 22 Jun 2009 10:37:00 GMT

En un proyecto en el que estoy trabajando, el equipo ágil del que soy miembro está desarrollando una aplicación completa de salud (es el Medusa Project), usando Mere Mortals framework como base para objestos de negocios, persistencia, y presentación en WinForm y ASP.NET. Pueden bajarse una versión de prueba de este framework en:

http://www.oakleafsd.com/

Hay una lista de características en

http://www.oakleafsd.com/MMNetFeatures/pgMMNetFeatures.htm

Pueden bajarse la guía de desarrollo de

MM .NET Developer's Guide

El framework fue desarrollado por Kevin McNeish, Microsoft MVP, presidente y arquicecto jefe de Oak Leaf Enterprise. El framework soporta entidades tipadas, pero por abajo, está basado en datasets. Podemos generar un proyecto de business objects con templates de VS que vienen con el framework, y tiene un generador de código provisto por el producto, podemos generar las clases de objetos de negocios, derivadas desde la base de datos.

En mi equipo, alimentamos metadata leyendo información de la base de datos, y con esa información, generamos una aplicación web completa en ASP.NET, un librería de objetos de negocios, procedimientos almacenados, y DDL para regenerar la base. Todo usando AjGenesis, mi proyecto abierto de generación de código. Espero escribir algún post sobre esa experiencia. Las tareas y plantillas que usamos, han sido derivadas del ejemplo:

AjGenesis- Generating the model from the database
AjGenesis- Modelo desde la Base de Datos

En esto post, uso otra aproximación, más clásica en los ejemplos de AjGenesis: partir de un modelo abstracto, generando desde allí:

- Scripts para crear la base de datos
- Business Objects a la Mere Mortals en una librería de clases
- Proyecto WinForm con formularios de mantenimiento

Escribí sobre generación de aplicaciones en distintas tecnologías, desde un modelo abstracto, en:

Application Generation using AjGenesis
Generando aplicaciones con AjGenesis

pero recuerden: AjGenesis se basa en modelos de libre definición. Podemos modelar lo que querramos. Como ejemplo trivial:

Code Generation with AjGenesis- A Hello World application
Generando Código- Hello World con AjGenesis

El modelo

Pueden bajar el ejemplo desde la página de ejemplos del proyecto, en Codeplex:

MereMortalsExamples200906.zip

Contiene:

El modelo resido en el archivo Projects/AjFirstExample/Project.xml

<Project>

    <Name>AjFirstExample</Name>

    <Description>First Example using AjGenesis</Description>

    <Prefix>AjFE</Prefix>

    <Domain>com.ajlopez</Domain>

    <CompanyName>ajlopez</CompanyName>

    <Model>

        <Entities>

            <Entity Source="Entities/Customer.xml"/>

            <Entity Source="Entities/Supplier.xml"/>

        </Entities>

        <Lists>

            <List Entity="Customer"/>

            <List Entity="Supplier"/>

        </Lists>

        <Forms>

            <Form Entity="Customer"/>

            <Form Entity="Supplier"/>

        </Forms>

        <Views>

            <View Entity="Customer"/>

            <View Entity="Supplier"/>

        </Views>

    </Model>

</Project>

Referencia a dos entidades, Customer and Supplier. La entidad Customer:

<Entity>

    <Name>Customer</Name>

    <Description>Customer Entity</Description>

    <SetName>Customers</SetName>

    <Descriptor>Customer</Descriptor>

    <SetDescriptor>Customers</SetDescriptor>

    <SqlTable>Customers</SqlTable>

    <Properties>

        <Property>

            <Name>Id</Name>

            <Type>Id</Type>

        </Property>

        <Property>

            <Name>Name</Name>

            <Type>Text</Type>

            <SqlType>varchar(200)</SqlType>

        </Property>

        <Property>

            <Name>Address</Name>

            <Type>Text</Type>

            <SqlType>text</SqlType>

        </Property>

        <Property>

            <Name>Notes</Name>

            <Type>Text</Type>

            <SqlType>text</SqlType>

        </Property>

    </Properties>

</Entity>

Hay un modelo que describe la tecnología que vamos a usar en Projects/AjFirstExample/Technologies/VbNet3.xml:

<Technology>

    <Programming>

        <Dialect>VbNet3</Dialect>

    </Programming>

    <Database>

        <Dialect>MsSql</Dialect>

        <Name>AjFirstExampleMM</Name>

        <Host>(local)</Host>

    </Database>

</Technology>

Puede cambiar el host a .\SQLEXPRESS si no tiene un servidor MS SQL. Puede agregar <Username> y <Password> si quiere usar la seguridad de SQL. Si no están, el ejemplo usa seguridad integrada de Windows.

Generando la aplicación

Debe bajarse la versión liberada actual de AjGenesis, la 0.5, desde http://ajlgenesis.codeplex.com. Agregue el directorio bin a su lista de directorios en PATH. Hecho esto, podemos ejecutar desde el directorio del ejemplo:

GenerateProject.cmd AjFirstExample VbNet3

El primer parámetro es el nombre del proyecto, el segundo es la tecnología a usar. El comando invoca

AjGenesis.Console Projects\%Project%\Project.xml tasks\BuildProject.ajg  Projects\%Project%\Technologies\%Technology%.xml tasks\BuildTechnology.ajg tasks\BuildProg.ajg tasks\BuildSql.ajg

Esto lee el modelo de proyecto, ejecuta la tarea BuildProject, carga el modelo de tecnología, ejecuta la tarea de BuildTechnology. Finalmente, la tarea BuildProg genera el código, y BuildSql genera el DDL necesario para crear la base de datos.

Se crea un nuevo directorio, Build, que contiene el resultado:

En el directorio Sql, encontramos el comando ExecuteAll.cmd que crea la base de datos

Podemos ejecutarlo con un parámetro, especificando ahí el servidor:

ExecuteAll.cmd Bombadil

Si ejecutamos el comando sin parámetro, usa el host especificado en el modelo de tecnología.

En directorio Src encontraremos recién generada una solución .NET completa, con dos proyectos:

Podemos levantarla en Visual Studio 2008, y compilarla (necesitamos tener una versión de Mere Mortals Framework instalada).

La librería de clases contiene definiciones de objetos de negocios de Mere Mortals (usando clases parciales, clases de acceso a datos usando procedimientos almacenados, reglas….)

El proyecto WinForm tiene dos formularios de mantenimiento, para Customers y Suppliers:

Bueno, no será “uy que bruto, que aplicación”…. :-)… pero ejecuta:

Si no quieren seguir estos pasos, pueden bajarse la solución generada, de mi Skydrive

AjFirstExampleMereMortals.zip

Conclusiones

Usando un modelo abstracto, podemos generar los artefactos de textos que requiere el framework de Mere Mortals (o cualquier otro framework o tecnología como describí en Generación de código, AjGenesis, y Dunga dunga a la tecnología). Con clases parciales, y archivos separados, podemos regenerar código desde el modelo, sin perder el código manual que hayamos agregado. Podemos extender el código generado agregando validaciones automáticos, nuevas reglas, y cualquier estándar de codificación que estemos usando.

Pero el punto principal, para mí, es que usando un modelo abstracto, estamos separando el núcleo importante de nuestra aplicación, de los detalles técnicos´. Podemos regenerar la aplicación usando otro framework, otros lenguajes, otras tecnologías, y nuestro modelo podría ser el mismo. El modelo describe lo que queremos. Tareas, y plantillas terminan siendo un sistema experto, que conoce COMO obtener lo que queremos como aplicación.

Nos leemos!

Angel “Java” Lopez

http://www.ajlopez.com/en
http://twitter.com/ajlopez

Generación de Código, AjGenesis y AjBasic

lopez — Mon, 15 Jun 2009 16:09:00 GMT

En el post que comenté ayer

Sobre la generación de código

el comentador Emmanuel escribía:

Pregunta: Ya que tu apodo es "java" :), porque no utilizar StringTemplate en vez de crear tu propio generador?

http://www.stringtemplate.org/

http://antlr.org/about.html

La respuesta es corta y es larga. Si vieron los ejemplos que he publicado, y cómo funciona AjGenesis:

AjGenesis (posts en español con ejemplos)

sabrán que he implementado mi propio lenguaje interpretado AjBasic (con una implementación ahora separada en http://code.google.com/p/ajbasic/), que ahora está evolucionando a ser un lenguaje, con el mismo núcleo que el AjSharp:

AjSharp: un intérprete a la C Sharp, trabajo en progreso

También está pensado que se pueda utilizar otro lenguaje para los templates:

Escribiendo templates de AjGenesis en otros lenguajes

Pero hoy por hoy, se puede usar sólo AjBasic en la generación de código de AjGenesis. Lo adopté, porque pienso que el lenguaje de templates Y DE TAREAS (porque eso tiene AjGenesis, no sólo es templates, sino también contiene código que organiza la generación de artefactos de textos), es tan fundamental en lo que quería construir, que no pensé en montarme sobre otro proyecto. Creo que, pasado el tiempo, ha sido una sabia decisión. Veo que el proyecto actual, tengo un dominio total sobre algo que es parte del núcleo de AjGenesis.

Recordemos que AjBasic se usa en las tareas. Y permite el uso de objetos dinámicos. Por ejemplo:

if not Project.Title then

    Project.Title = Project.Name

end if

if not Project.Version then

    Project.Version = "1.0.*"

end if

Este ejemplo, tomado de una tarea típica de los ejemplos que vienen incluidos con el sistema, muestra dos características muy usadas: una, preguntar por Project.Title y si Project o Project.Title no están definidos, eso vale falso para el if (una extensión de ideas de lenguajes anteriores como PHP). Me evito preguntar por Nothing o cosas así. Y otra característica: como Project es un objeto dinámico, le puedo agregar propiedades en cualquier momento.

También se le pueden sembrar, en el environment (entorno de valores definidos en el sistema en ejecución), objetos .NET “duros”, y el lenguaje los maneja por reflection.

Esto es algo que todo lenguaje interpretado de hoy en día debería tener: explotación fácil y directa de cualquier framework de clases que lo sostenga. He programado AjBasic de tal forma que podría reimplementarlo fácilmente en Java, usando entonces la librería de clases de Java. Y tiene una estructura (intérprete que ejecuta un árbol abstracto), que puede reimplementarse en cualquier lenguaje en que sea necesario. Por ahora, no he visto la necesidad de hacerlo. Estas razones hacen que no me haya preocupado por compilarlo a bytecodes de la máquina virtual, usando CodeDom, o Emit, porque no es el núcleo de lo que estoy persiguiendo: no necesito velocidad, necesito flexibilidad.

Otro pequeño e importante detalle:

include "Tasks/Build${Technology.Programming.Dialect}.ajg"

Este tipo de instrucción, de nuevo inspirado en PHP, permite la inclusión dinámica de código. Dependiendo de lo que diga el modelo de tecnología, puedo incluir en la ejecución a Tasks/BuildCSharp2.ajg o a Tasks/BuildJava.ajg o lo que sea, dinámicamente.

Y en un proyecto actual, del que espero postear en breve, hasta puedo incluir en la expansión de un archivo de template, a otro, dinámicamente:

Imports System

Imports System.Collections.Generic

Imports System.Text

Imports OakLeaf.MM.Main.Business

Imports OakLeaf.MM.Main.Collections

Imports OakLeaf.MM.Main.Data

Partial Public Class ${Table.SqlName}

    ''' <summary>

    ''' Hook method automatically executed from the mmBusinessObject constructor

    ''' </summary>

    ''' <remarks></remarks>

    Protected Overridable Sub HookPartialConstructor()

        '' Place code here to be executed when the business object instantiates

    End Sub

<#

    if System.IO.File.Exists("Templates/${Table.Name}PartialVb.tpl") then

        include("Templates/${Table.Name}PartialVb.tpl")

    end if

#>

End Class

Y tengo más usos para un lenguaje flexible, dentro de AjGenesis. La idea final, es usarlo para tomar decisiones, para convertir el proceso de generación, en un sistema experto. Algunas decisiones ya toma. Por ejemplo, dada un entidad X, que tiene relaciones con otras, puede decidir incluir una página de “ver entidad X” que tenga enlaces o directamente los datos de las entidades con las que se relaciona. O al ver que en el modelo hay entidades, y una de las entidades modela una persona, saber que para mostrar en algun lado (una lista desplegable, una grilla….) a qué persona estamos refiriendo, deberá mostrar nombre, apellido, y tal vez algún de legajo. O que si estoy armando una aplicación distribuida en Java, sepa deducir qué servicios web debo implementar, que DTOs hay que definir, según los casos de usos que estén descriptos en el modelo, y que escriba los ensambladores de esos DTOs.

Esos sos ejemplos pequeños y grandes de decisiones. Pero la idea es ir avanzando en tener más decisiones, y más reglas, implementadas no con un rígido sistema de reglas forward chaining o backward chaining (que no lo descarto, de ahí mi implementación de AjProlog en curso y de otras ideas), sino ir viendo de explorar la inserción de decisiones en cualquier momento del proceso de generación de código.

Otro ejemplo: en el proyecto en curso, un sistema real, se implementó con AjBasic/AjGenesis una serie de reglas que examinan la base de datos de desarrollo, y detectan inconsistencias en los nombres de las columnas o relaciones de uno a muchos mal definidas. Y podemos seguir implementando más reglas, que nos avisen de otros problemas.

Por todo esto, es que no adopté un lenguaje de templates existente: AjGenesis necesitaba, desde su concepción, un lenguaje que fuera más que un lenguaje de templates. Esto me lo hizo ver mis primeros trabajos en el tema, en los 80, cuando implementé algo parecido en C, pero con limitaciones. Y cuando leí en estos años, el libro de Kathleen Dollard Code Generation in Microsoft .NET donde ella no se animaba a implementar un lenguaje, y adoptaba uno existente, como XSLT sobre XML (mala elección), y luego en cada capítulo, tenía que hacer malabares con el modelo, para poder conseguir algún resultado, al leer eso, me decidí por un lenguaje flexible.

Y no tardé mucho en construir el prototipo. Resultó, como muchas otras veces, divertido! :-)

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez
http://www.facebook.com/ajlopez

Generación de código, AjGenesis, y Dunga dunga a la tecnología

lopez — Sun, 14 Jun 2009 17:20:00 GMT

En un post mío

Sobre la generación de código

comentaba sobre AjGenesis y generación de código en general. En uno de los párrafos declaraba:

Dunga dunga un ratito

De alguna forma, un generador de código ideal no estará atado a una tecnología. Siempre habrá alguna "better mousetrap", siempre alguien inventará alguna nueva forma de hacer algo, siempre habrá un ruso con insomnio, o un hindú sin novia, que no tiene otra cosa que hacer que crear algo nuevo, ya sea en forma de librería, framework, patrón, o estilo arquitectónico. Un generador de código debe ser agnóstico de la tecnología, de las modas, de las soluciones actuales y futuras.

El generador de código que adoptemos, debe poder adaptarse a lo que queramos hoy y mañana y pasado mañana. La estrategia es: no importa la tecnología, el patrón o el framework que aparezca, nuestro generador deberá aprovecharse de lo que surja. Es lo que llamo la estrategia "dunga dunga": si aparece una nueva tecnología T1, le hacemos "dunga dunga" a T1, si aparece un nuevo framework PiruloStruts, adaptamos nuestras plantillas a aprovecharse de ese framework, "dunga dunga" a PiruloStruts. Es como un maestro de aikido: siempre habrá alguien más fuerte, sólo hay que utilizar la fuerza del otro, para vencerlo.

Un comentador Emmanuel escribía:

Un resumen y secciones mas especificas ayudarían (tienes que admitir que "Dunga dunga un ratito" es un titulo sobre el cual es difìcil sacar conclusiones :).

Bien, me refería a un viejo chiste, que no encontré ahora en la web, así que trataré de transcribirlo aquí, como pueda:

Resulta que un explorador se pierde en la selva, y ya exhausto, se encuentra con una tribu de indígenas, con caras de pocos amigos. Lo rodean, el que parece el jefe, se le acerca, y le despacha:

“Hombre blanco! Elige! Dunga dunga o muerte!!”

El explorador no entiende qué es eso de “dunga dunga”, así que acepta eso, antes que la muerte. Los miembros de la tribu sonríen, y le empiezan a dar al pobre explorador, de formas que éste no se lo imaginaba…

Lo dejan, y el explorador, maltrecho, sigue su camino, se encuentra con otra tribu, otro jefe, y la ya clásica frase:

“Hombre blanco! Elige! Dunga dunga o muerte!!”

El explorador, escarmentado, responde:

“No!! No dunga dunga de nuevo!! no!!! Prefiero la muerte!!””

El jefe asiente, pero se le acerca, le pasa brazo por el hombre, y con afecto y sonriendo, le dice:

“Bueno, muerte, pero antes… dunga dunga un ratito, eh?”

:-) :-)

A eso me refería cuando escribí ese post. AjGenesis, como generador de código, no está especializado en producir artefactos para una tecnología. No es como Xdoclet que sólo produce Java, o está muy orientado (por lo menos en sus comienzos) a EJB (Enterprise Java Beans).

No, lo que hace AjGenesis, es aprovecharse del conocimiento del programador o equipo de programación, de las tecnologías, frameworks existentes o futuros, y generar gran parte de una solución (o por lo menos la parte repetitiva).

Recordemos que AjGenesis puede partir de un modelo abstracto y generar artefactos de textos (que pueden ser una solución completa):

Notemos que puede haber más de un modelo inicial. En muchos de los ejemplos que publiqué, hay un modelo independiente de la plataforma (por ejemplo, que describe que nuestro sistemas tendrá departamentos, empleados, clientes, proveedores…) y un modelo de tecnología (que indica que vamos a usar tal base de datos, y tal lenguaje, y una interface web, etc..)

Pero también puede partir de la base de datos, y generar un modelo de base, que puede ser completado, ajustado, y usado más adelante la generación de código:

El modelo a usar es totalmente definible. Y las tareas y plantillas a usar, totalmente definibles. Si lo que Uds. necesitan, es generar aplicaciones con interfaz web, usando Struts 2, es cuestión de armarse las plantillas y tareas que generen ese tipo de solución. Si luego necesitan generar una aplicación en ASP.NET 3.5, con persistencia resuelta en NHibernate, de nuevo es cuestión de definir las tareas y plantillas adecuadas.

Pero si el día de mañana, aparece un nuevo ORM (Object Relational Mapper), o hay una nueva forma de implementar la persistencia, podemos “instruir” al AjGenesis para que genere los artefactos de textos que necesitemos.

Ya he publicado ejemplos, explicaciones de todo esto en

Posts sobre AjGenesis

desde una explicación de Hola Mundo:

Generando Código- Hello World con AjGenesis

hasta aplicaciones completas en distintas tecnologías:

Generando aplicaciones con AjGenesis

En esos ejemplos, el modelo se define en archivos XML, pero también pueden tomarlo desde texto:

Modelo textual para generación de código con AjGenesis

y desde otras fuentes menos convencionales:

AjGenesis- Modelo desde la Base de Datos

AjGenesis- Modelo generado desde los assemblies

Si hasta pueden implementar una solución web que genere código para cualquiera que lo necesite:

Code Generation as a Service

Así que no tienen excusas: no pueden quejarse de que no les avisé, o que me encanuté, oculté algo bajo la manga. Tienen todo eso disponible desde hace años. Sólo falta poner cabeza y cerebro, en descubrir los modelos de base que necesitamos, y escribir las tareas y plantillas. Recomiendo siempre partir de una aplicación de ejemplo, que resuelva lo que Uds. necesitan, usando la tecnología que hayan elegido, y desde ahí, ir construyendo las tareas y plantillas que necesiten.

Como siempre aclaro, no toda la aplicación puede crearse por generación de código. Pero se pueden aplicar técnicas, como generar desde el modelo que elijamos, sólo algunos artefactos de texto, y otros, los generamos manualmente.

Lo interesante, es que así, cuando pasen las tecnologías, cuando aparecen nuevas, podemos reaprovechar nuestro conocimiento anterior, al haber definido un modelo que describa nuestro problema, y luego, al conocer una nueva tecnología, y cómo resolver los mismos problemas de otra forma, podemos generar código para la nueva forma de hacer las cosas.

Yendo a un ejemplo concreto. Desde hace décadas, estamos haciendo ABM (Altas, Bajas y Modificaciones) de valores, como países, provincias y demás. Cuando resolvimos eso en Visual Fox, un cliente nos pidió hacerlo en ASP clásico. Cuando resolvimos eso en ASP clásico, otro cliente nos pidió eso en ASP.NET, o en JSP o en JSF (JavaServer Faces) o en lo que aparezca mañana. Pero el problema a resolver es el mismo: mantener una lista de valores. Si luego cambia la tecnología, cambia la solución a aplicar, pero el problema inicial se mantiene. En AjGenesis, podemos definir un modelo independiente de la tecnología (por ejemplo, definiendo las entidades que tenemos que manejar, como Cliente, Factura, Remito, etc… y sus relaciones), y por otro, instruyendo sobre qué tecnología usar (aportando uno o varios modelos dependientes de la tecnología), como ASP.NET, ASP.NET MVC, WCF, JSP, JSF, Struts 1 o 2, etc…

Otro camino hubiera sido lo que muchos de nosotros encaramos: hacer nuestro propio framework. He visto muchas consultoras de software, “casarse” con una tecnología (ej. Visual Fox), estudiarla, armar un framework sobre ella (que resuelva los problemas clásicos, como ABMs, seguridad, autorización, validaciones, etc…) y luego ver cómo, ese trabajo de años, se diluye, porque la tecnología cambia.

Si nosotros elevamos el nivel de abstracción, identificamos los problemas a resolver (ABMs, listas, buscadores, seguridad, procesos, validaciones, reglas de negocio), y luego los resolvemos en una tecnología (ya sea viendo código de ejemplo, armando nuestros propios ejemplos, et…), podemos describir ese mapeo de problema a solución concreta, usando las tareas y plantillas de AjGenesis.

Como ejemplo: cuando comencé con el proyecto, no existía ASP.NET 2.x. Sin embargo, los modelos que construí como ejemplos de base, pudieron ser usados para luego generar aplicaciones de ASP.NET 2.x. Actualmente, en un proyecto, estamos adaptando conocimiento previo, para generar código sobre .NET y Mere Mortals Framework. Y el modelo que construimos, fácilmente podría ser reusado para otras aplicaciones, y otras tecnologías,como Clipper o COBOL, hasta ASP.NET MVC o Wicket. El construir el modelo, pone de manifiesto qué es lo que queremos resolver, los problemas básicos, que terminan expresándose de forma independiente de la tecnología de moda, o el framework popular del momento.

Y aunque usemos una sola tecnología, el ejercicio de definir el modelo, definir las tareas y plantillas, aporta una clara separación entre lo abstracto, y lo que llamo las “technicalities”, los detalles técnicos de implementación, que el día de mañana pueden cambiar.

Entonces, no importa la tecnología: AjGenesis le puede hacer dunga dunga a la tecnología que venga. Si Uds. creen que la tecnología que Uds. usan actualmente, va a durar para siempre, lamento desilusionarlos. Vean la historia de la programación, los últimos 30 o 50 años, y verán que lo único permanente es el cambio.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
http://www.facebook.com/ajlopez

AjGenesisCF: generación de código para generation for .NET Compact Framework

lopez — Fri, 29 May 2009 05:09:00 GMT

Gracias al trabajo de Federico Boerr y su equipo, tenemos una nueva versión de AjGenesis, escrita para ejecutarse desde .NET Compact Framework:

http://ajgenesiscf.codeplex.com/

Esta versión sólo usa las características soportadas por el Compact Framework. Entonces, no tenemos todas las del proyecto original. Por ejemplo, sólo usa las características de reflections soportadas por CF, una de las que queda fuera es la capacidad de crear una instancia con pasando parámetros en el constructor. Pero podemos compilar AjGenesis como .DLL, e invocarla desde un programa nuestro, usar templates, tareas y AjBasic. El código publicado por Federico contiene un programa de uso de ejemplo.

Más información sobre el proyecto original:

http://ajgenesis.codeplex.com
http://ajlopez.wordpress.com/category/ajgenesis/

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Modelo, decisiones, inteligencia artificial y AjGenesis

lopez — Sun, 22 Mar 2009 20:28:16 GMT

En el recientemente creado grupo de Google AltNet-Argentina, el bueno de Fabio Maulo planteó una pregunta en el thead:

ORuM

donde escribía

Quien me conoce un poco, o me ha leido en algún lado, conoce ya la acronimo
ORuM.La realida es que nunca tuve la ocasión de una buena confrontación
sobre el tema.
Para titular la mesa sería:
Object Relational unMapping
Mas allá del ORM.

Quisiera compartir, confrontar, ampliar algunas ideas y verificar la
factibilidad.

La idea es tener en claro, cómo se toman algunas decisiones, en el caso de tener un dominio de clases, y llegar al mapeo de en una base de datos, no preexistente. Es un caso tipo, como escribía el propio Maulo:

Yo quisiera llegar a : "che, yo tengo este dominio que tendría que persistir en ORACLE, fijate vos! a mi lo que me interesa es que persista."
El DSL sería:
Che.Tengo("MiDominio.dll").Que.TieneQuePersistirEn("ORACLE").FijateVos();

Para mí, esto es parecido a lo que trato muchas veces de resolver con AjGenesis:

"Tengo X quiero resolverlo con Y", donde X puede ser un dominio de entidades, un dominio más tipo DDD, una lista de servicios, lo que sea, e Y sería JSP, Struts2, JSF, ASP.NET MVC, NHibernate, Hibernate, MySql, SQL Server, y demás. Es lo mismo que hace un programador: toma decisiones, ante lo que tiene que hacer.

Es por eso que en AjGenesis tomé algunas decisiones tempranas, para poder ir avanzando en un camino, que menciono en:

Sobre la generación de código

... el modelo a usar ... PUEDE SER GENERADO por el propio sistema, más un sistema experto. No imagino una aplicación más inmediata de la "inteligencia artificial". Imagino agentes inteligentes, que colaboren en una red compartida, cada uno generando parte del modelo, cada uno consumiendo algo que otro produce, y colaborando, para generar un sistema... Sí, ya sé, tengo que tomar la píldora verde, en lugar de la roja... ;-)

Esa es una de las razones de tener en AjGenesis:

- un modelo
- más que sólo un lenguaje de templates
- aplicar el lenguaje en tasks, que modifican y completan el modelo

Si sólo tuviera templates, sólo haría transformaciones X -> Z, de una forma, digamos, lineal, desde, para poner un ejemplo, una clase o un modelo que describe una clase, a un código o archivo de configuración de persistencia.

A lo que voy, es que el camino que quiero para AjGenesis, en algún momento (no para que todos lo usen así), es que sea un sistema experto, que tome decisiones. De ahí que, desde el principio:

- tenga un lenguaje completo, con toma de decisiones, que pueden ser complejas
- tiene acceso al framework de .NET, para poder ser extendido de cualquier manera.
- invoque a tareas, no simplemente a transformar el modelo X usando el template T

Eso explica también, algunos caminos que estoy explorando, como AjLisp, y AjProlog (aunque son más para entrenarme, que para aplicarlos directamente en AjGenesis). Habrá que investigar si este camino es posible, pero me parece que está relacionado con el tema planteado en el grupo. Veamos, volvamos al problema inicial.

De clases a persistencia

Las opciones de mapeo que podemos considerar, son las mostradas por el bueno de Martin Fowler:

Single Table Inheritance

Class Table Inheritance

Concrete Table Inheritance

En una situación ideal (no costo en tiempo de queries o de update, sin limite de memoria en disco), todo seria igual.

Como la situación no es ideal, me imagino que los costos de cada decisión se mediran en:

- Rendimiento de actualización y consulta

- Espacio de almacenamiento

A primera vista, me imagino que el primer punto es el mas peliagudo.

Para concretar, tomemos un modelo sencillo. Sea clase Empresa, subclases Cliente, Proveedor.

Habría que ver qué consecuencias tiene entonces, el tener una tabla empresas, con un campo discriminador de si es cliente o proveedor. ¿Qué pasa si hay muchos campos en comun? ¿O si hay muchos campos de diferencia? Pienso que mas va a influir el tema: ¿pero queda ahí el dominio? Si el día de mañana aparecen más subclases, ClienteExtranjero, ProveedorExterno, ¿no se complicará el haber adoptado una sola tabla?

Si ponemos tablas Empresa (con los datos comunes), Clientes (con los datos adicionales), Proveedor (con los datos adicionales), habrá que hilar fino en las consultas. No sólo está el tema del rendimiento de actualización y consulta. Tambien esta la frecuencia de algunas operaciones. Es decir, si una consulta determinada tarda X tiempo, habrá que ponderarla tambien por la frecuencia de esa consulta en la operación normal del sistema.

Con tablas Clientes, Proveedores, habra que comprobar que la actualizacion sea mas rapida que en el anterior caso. Y vigilar que pasa, y con cuanta frecuencia, se necesita una consulta sobre Empresas (que imagino debera implicar un UNION).

Entonces, no sólo es el modelo de clases, sino cómo se usa, lo que puede influir en cómo hagamos el mapeo.

ESTO ES LO QUE YO VEO EN MUCHOS MODELOS ya existentes, que no tienen todo LO QUE SE NECESITA DE UN MODELO. Un modelo de clases se queda corto, para tomar algunas decisiones. Lo mismo, si partimos desde una base ya diseñada. Partir de esos modelos, implica que en algún momento lo tenemos que enriquecer, con anotaciones en el modelo de clases, o agregando información en metadata o en algún momento, si partimos desde la base de datos.

Partir de un modelo de clases o de la base de datos, tiene la ventaja de partir de algo conocido. Pero para muchas de las operaciones que quisiéramos hacer (en este caso "simple", mapeo a relacional, imaginen otros casos como servicios distribuidos, seguridad, cache en el cliente, etc.), hace falta más información de contexto.

De ahí, que yo esté a favor de un modelo distinto, más enriquecido.

De Aristóteles a Kant

En los noventa, en una revista Byte, leí una breve reseña, sobre gente que estaba armando algo que lo llamaban KANT. En honor a las categorías del filósofo alemán (yo diría que se referían más a categorías de Aristóteles), ellos planteaban que todo en, lo que hoy llamaríamos, modelo, está incluído en alguna categoría como:

- Persona
- Organización
- Bien Físico
- Lugar Físico
- Documento
- Suceso
- Lapso

y demás. Por ejemplo, un Empleado entraría en la categoría Persona, un Cliente o Proveedor, en la categoría Organización. El que un Empleado estuviera contratado por una Empresa, era un Lapso (un intervalo, posiblemente abierto, de tiempo) establecido entre una Persona y una Organización. A partir de las categorías, se podía inferir que toda Persona tiene fecha de nacimiento, y otros atributos, que un Lapso puede tener tiempo de inicio y tiempo de final. (Escribo sin tener la referencia, de memoria).

Esa reseña siempre influyó en lo que quiero hacer con un modelo rico, abstracto. Sirve para poner más semántica sobre lo que estamos describiendo, más de lo que daría un modelo de código o de base de datos. Sigo pensando que algo así debe ser el modelo del que partir, en la generación de código o en otras ideas.

Apenas una punta de eso (el tener categorías llamadas prototipos, que sirvan de base para generar un modelo simple), está desde hace tiempo en AjExamplesExamples3.zip, en el directorio Prototypes, y Seeds. Es una idea con implementación mínima, a explicar en detalle en otro post.

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez
En estos días, revival de los 80s en mi vida http://www.youtube.com/watch?v=dgwmErO_nlQ

Máquinas de Estado en C# 3.0 usando AjGenesis

lopez — Tue, 21 Oct 2008 09:39:39 GMT

Recientemente encontré el trabajo de Andrew Matthews:

Permanent Link to State Machines in C# 3.0 using T4 Templates

Tomé el ejemplo y lo reimplementé usando mi proyecto de generación de código AjGenesis. Para correr este ejemplo, tenemos que bajar la última versión publicada 0.5 desde la página del proyecto en Codeplex.

(más información sobre el proyecto, ejemplos, explicación del funcionamiento en mis anteriores posts).

Pueden bajar el código de este ejemplo.

El modelo que usé es el mismo del post original de Andrew:

<?xml version="1.0" encoding="utf-8" ?>
<StateModels>
  <StateModel ID="My" start="defcon1">
    <States>
      <State ID="defcon1" name="defcon1"/>
      <State ID="defcon2" name="defcon2"/>
      <State ID="defcon3" name="defcon3"/>
    </States>
    <Inputs>
      <Input ID="diplomaticIncident" name="diplomaticIncident"/>
      <Input ID="assassination" name="assassination"/>
      <Input ID="coup" name="coup"/>
    </Inputs>
    <Transitions>
      <Transition from="defcon1" to="defcon2" on="diplomaticIncident"/>
      <Transition from="defcon2" to="defcon3" on="assassination"/>
      <Transition from="defcon3" to="defcon1" on="coup"/>
    </Transitions>
  </StateModel>
</StateModels>

(Andrew escribió que ha sido influido un poco por la serie de TV 24, al elegir los estados del ejemplo... ;-)

Modifiqué la solución original:

Ahora, hay un archivo Model.xml que contiene el modelo de arriba. El archivo MyStateModel.cs es automáticamente generado desde el modelo. Cambié la solución para tener un evento de Pre-Build en el proyecto TestHarness:

$(ProjectDir)..\VsMakeStates.cmd

El archivo .cmd contiene:

cd ..\..\..
c:\ajlopez\ProyectosNet2\AjGenesis-0.5\bin\AjGenesis.Console TestHarness\Model.xml GenStates.ajg

(TENEMOS que cambiar la segunda línea para apuntar al directorio binario de AjGenesis 0.5)

Con este comando, AjGenesis.Console carga el modelo desde el archivo .xml, y aplica una tarea, GenStates.ajg, escrita enwritten in AjBasic:

for each StateModel in StateModels
TransformerManager.Transform("State.tpl","TestHarness\${StateModel.ID}StateModel.cs",Environment)
end for

Hay otro comando, que podemos lanzar directamente desde la línea de comando, MakeStates.cmd, conteniendo:

c:\ajlopez\ProyectosNet2\AjGenesis-0.5\bin\AjGenesis.Console TestHarness\Model.xml GenStates.ajg

Amo mi template AjBasic en GenStates.ajg ;-) un fragmento:

using System;
using System.Collections.Generic;
using Aabs;
using Core;

namespace ${StateModel.ID} {
    public enum ${StateModel.ID}States : int
    {
<#
    sep = ""
    for each State in StateModel.States
#>
        ${sep}${State.ID}        // ${State.name}
<#
        sep = ","
    end for
#>
    } // end enum ${StateModel.Id}States

...

Está basado en archivo .tt de Andrew Matthews. Notemos que no hay referencia a nodos .XML o similares. AjGenesis carga el modelo en memoria, como un objeto dinámico. El lenguaje AjBasic puede acceder al modelo, usándolo como un objecto cualquiera. El uso de ${ } reemplaza la salida con algún valor, tomado de las variables o del modelo en proceso.

El principal punto en este ejemplo es que está basado en un modelo libre (AjGenesis puede cargar cualquier modelo, no se usa uno predefinido). Si uno quiere agregar más información, podemos escribir más atributos, elementos, en el archivo .xml. Y usarlos desde el código de template. No hay un esquema fijo.

Otro punto a destacar: el ejemplo podría ser modificado para generar la solución Visual Studio completa, o para generar una solución en otro lenguaje (un ejemplo generando una solución VS completa:
Code Generation for LINQ and C# 3.0 with AjGenesis
)

Gracias a Andrés por un ejemplo tan interesante. Pueden leer más sobre su implementación en el post mencionado:

Permanent Link to State Machines in C# 3.0 using T4 Templates

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Otro modelo para AjGenesis

lopez — Fri, 03 Oct 2008 11:07:12 GMT

En este post voy a describir una idea, no hay implementacion todavía. AjGenesis, mi proyecto de código abierto de generación de código, está basado en modelos, tareas y plantillas. Cada artecfacto a ser usado, podemos definirlo nosotros, y así se consigue generar salidas, archivos, código para cualquier tecnología, framework o plataforma.

El modelo reside en memoria, durante su proceso. Podemos cargar en memoria varios modelos a la vez: en los ejemplos que he publicado, un modelo abstracto describe la solución en términos generales, y otro modelo de tecnología define el lenguaje, base de datos, patrones, que se usaran en el proceso de generación de código.

Ambos modelos pueden ser cargados desde archivos XML, o desde archivos de texto (esta es una nueva característica, todavía en prueba). Ahora, quisiera proponer otro camino: modelos en planillas de cálculo.

El ejemplo

En un post reciente:

Modelo textual para generación de código con AjGenesis
Textual model for code generation in AjGenesis

Presenté ahí un modelo simple, en dos representaciones: XML y textual. Ese modelo podría ser expresado en una planilla Excel, como:

El alcance de una descripción de objeto está determinada por la indentación: Entity Customer es un elemento de Entities (vean que no importa dejar filas en blanco). Podemos usar una tabla para describir un elemento compuesto de varios. Una propiedad simple puede ser descripta en dos columnas consecutivas: la primera conteniendo el nombre de la propiedad, la segunda nos da el valor. Si queremos describir un objeto en otra hola de la misma planilla, ponemos el nombre entre corchetes [...], como en "Entity [Employee]", que nos podría llevar a otra hoja como:

El principal beneficio de este modelo es la clara representación que conseguimos. Colores y tipos de letras mejoran la presentación, pero son ignorados en la carga del modelo. Pero la presentación se mejora. Como siempre digo, no somos vulcanos (al Sr. Spock le bastaría un archivo XML), y una buena presentación nos ayuda a procesar información.

Próximos pasos

Si consideran que esta propuesta es útil, podría escribir un nuevo Object Builder que se alimente de archivos Excel, para cargar un modelo. Debería elegir la librería a usar: podría tomar el modelo de objetos de Excel, aunque eso implica que para usarlo, se deba tener el Excel instalado. Como siempre, sugerencias, comentarios, bienvenidos!

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Generación de código para LINQ y C# 3.0 con AjGenesis

lopez — Wed, 01 Oct 2008 10:51:18 GMT

AjGenesis, mi proyecto open source de generación de código, usa un modelo definido por el usuario. Podemos definir tareas y templates, para transformar el modelo a código y archivos de texto. Podemos escribir nuestro propio modelo, agregar tareas y transformaciones. Desde una tarea, se puede invocar a objetos .NET o código AjBasic, en el medio del proceso de generación. Es un proceso flexible: genera lo que Ud. quiera generar, no tiene un patrón predeterminado.

Como el modelo lo define uno, el sistema no está limitado a un tipo de proyecto. Al estar basado en templates y tareas definidas, genera artefactos de código que no están ligados una sola tecnología. Podmos generar archivos para cualquier tecnología, framework, línea de negocios y plataforma. Podemos generar scripts de DDL, o una aplicación completa de base, o cualquier cosa en el medio. Es nuestra decisión hasta donde llegar.

Cuando comencé a escribir y usar el sistema, no existía .NET 2.0. Cuando la nueva tecnología se hizo pública, escribí tareas y templates adicionas para aprovechar las nuevas características como master pages, themes y nuevos controles ASP.NET, sin necesidad de tocar el código núcleo de AjGenesis. Una vez los nuevos templates y tareas estuvieron escritos, pude generar aplicaciones ASP.NET 2.x, a partir de los mismos modelos que ya tenía armados para mis otros cursos y trabajos.

Ahora, como una prueba de concepto, escribí un nuevo ejemplo, que genera código usando LINQ, en nuevo chico en el barrio de .NET 3.x. El resultado fue publicado como AjGenesisExamplesNet3.zip en la página de ejemplos de AjGenesis en CodePlex. Para ejecutar el ejemplo, necesitamos la actual versión 0.5 (incluye código fuente, ejemplos iniciales, y binarios). (Hay una versión 0.5.1 en desarrollo que pueden ir viendo en el repositorio de código del proyecto).

El ejemplo

Hay sólo un modelo en el ejemplo: AjFirstExample, con un simple modelo XML describiendo a dos entidades planas, Customers y Suppliers. Es el mismo modelo que usé en otros ejemplos anteriores.

<Project>
    <Name>AjFirstExample</Name>
    <Description>First Example using AjGenesis</Description>
    <Prefix>AjFE</Prefix>
    <Domain>com.ajlopez</Domain>
    <CompanyName>ajlopez</CompanyName>
    <Model>
        <Entities>
            <Entity Source="Entities/Customer.xml"/>
            <Entity Source="Entities/Supplier.xml"/>
        </Entities>
        <Lists>
            <List Entity="Customer"/>
            <List Entity="Supplier"/>
        </Lists>
        <Forms>
            <Form Entity="Customer"/>
            <Form Entity="Supplier"/>
        </Forms>
        <Views>
            <View Entity="Customer"/>
            <View Entity="Supplier"/>
        </Views>
    </Model>
</Project>

El directorio Templates contiene dos conjuntos de archivos .tpl , que son templates AjGenesis. Los de MsSql son usados en la generación de scripts DDL. En el folder CSharp3, hay nuevos templates que generan un LINQ DataContext, y clases simples, como entidades y servicios.

Ejecutando el ejemplo

El directorio principal del ejemplo hay un archivo de comando:

makeajfirstexample.cmd

que al ejecutarse, carga el modelo abstracto y el de tecnología en memoria, y ejecuta dos tareas, creando códidog y scripts de generación de base de datos.

Lo generado reside en un nuevo directorio Build, con código fuente y scripts para MS SQL:

El archivo Build\AjFirstExample\CSharp3\Sql\CreateDatabase.sql crea la base y tablas, un fragmento:

create database AjFirstExampleNet3
go

...

use AjFirstExampleNet3
go

...

--
--        Entity:        Customer
--        Description:    Customer Entity
--


if exists (select name from sysobjects 
         where name = 'Customer' and type = 'U')
    drop table Customer
go

create table Customer (
        [Id] [uniqueidentifier] not null 
    CONSTRAINT [DF_Customer_id] DEFAULT (newid()),    
        [Name] nvarchar(200),    
        [Address] nvarchar(2048),    
        [Notes] nvarchar(2048)
 CONSTRAINT [PK_Customer] PRIMARY KEY CLUSTERED 
(
    [Id] ASC
)WITH (PAD_INDEX  = OFF, IGNORE_DUP_KEY = OFF) 
    ON [PRIMARY]
)
go

La solución puede cargarse directamente en Visual Studio 2008:

La clase AjFirstExampleDataContext.cs es un simple LINQ DataContext:

    public partial class AjFirstExampleDataContext : 
        System.Data.Linq.DataContext
    {
        public AjFirstExampleDataContext() 
....
        public Table<Customer> Customers;
        public Table<Supplier> Suppliers;
    }

Podríamos reemplazarlo por un DataContext generado por el wizard de Linq To SQL que viene en el Visual Studio. Hay una opción en el modelo de tecnología para especificar qué estrategia usar: o genera un archivo nuestro, o deja al desarrollador poner manualmen luego, al levantar la solución, un DataContext generado por el propio IDE. El resto de las clases funciona igual contra cualquiera de las dos opciones.

La solución tiene 3 proyectos: datos, servicios y presentación ASP.NET. La página inicial es espartana (ya me conocen, soy desarrollador, no diseñador gráfico... :-)):

Desde la opción de Administration, podemos explorar, agregar, editar y borrar clientes y proveedores:

Próximos pasos

Quiero convertir otros ejemplos anteriores a estos nuevos templates (el modelo de AjTest es el más desafiante, con relaciones uno a varios y varias entidades). Sería interesante generar páginas ASP.NET MVC, en lugar de ASP.NET plano. Y algunos proyectos adicionales, de infraestructura de testo. Estoy viendo el código de ScrumLite como un ejemplo base a seguir.

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com
http://delicious.com/ajlopez
http://twitter.com/ajlopez
http://friendfeed.com/ajlopez

Diez reglas principales en generación de código

lopez — Mon, 25 Aug 2008 07:38:42 GMT

Cualquiera puede reconocer en mí a un entusiasta de la generación automática de código, con un agregado: usar un modelo como el punto de partida del proceso. He adoptado esa idea cada semana, practicando "dog fooding", usando mi propio proyecto de generación de código AjGenesis. Esta semana, estoy leyendo el libro ya clásico "Code Generation in Action" , de Jack Herrington, editado por Manning. Este libro es un "debe ser leído" por cualquiera ineresado en generación de código. Es una muy interesante lectura para desarrolladores: el autor expone un caso a favor del uso de la generación de código, apelando al incremento en calidad y productividad en proyectos de software, incluyendo equipos ágiles.

En el primer capítulo, Herrington lista las reglas "top ten" que quiero comentar en este post. Los párrafos indentados que siguen son extraídos del libro (sección 1.7), seguidos por mis propios comentarios:

De el debido respeto a código generado a mano

Ud debe respetar y rechazar el´código manal. Ud. debe respectarlo porque hay casos especiales en el código que son pasados por alto en una inspección somera. Cuando reemplaza código manual por código generado, necesita estar seguro de haber contemplado esos casos especiales. Ud. debe sentirse disgustado con el código manual porque el tiempo de desarrollo es extremadamente valioso, y gastarlo en tareas repetitiva es casi criminal. El objetivo de su generador de código debe ser siempre optimizar el activo más valioso de su organización: la creatividad y el entusiasmo del equipo de desarrollo.

Cierto, la base de la generación de código es hacer fácil el delegar las tareas repetivivas a la máquina. Nosotros tenemos que usar herramientas que hagan más fácil nuestro trabajo: ésa es la razón por la que usamos compiladores hoy en día, en lugar de estar "seteando" los bits en la memoria (o "seteando" los relés en la vieja Eniac a mano). La razón que sustenta la generación de código no es destruir el código manual: su misión es soportarlo.

Primero escriba a mano

Ud. debe entender completamente su framework antes de generar código. Idealmente, debería escribir a mano una amplia y significativa cantidad de código con el framework, primero, y luego entonces, usarlo como base para los "templates" de su generador.

Absolutamente de acuerdo. A veces, los nuevos usarios de AjGenesis comienzan a usarlo directamente de los ejemplos. Eso es bueno, pero seria mejor generar un ejemplo usando el framework y la tecnología que tengan que encarar. Si Ud. conoce cómo programar usado Struts/Hibernate, entonces puede separar las variaciones técnicas de lo esencial. Llegado a ese punto, podrá comenzar a escribir los artefactos de generación de código que necesite (templates, tareas).

Controle el código fuente

No puedo dejar de enfatizar la importancia de tener un sistema de control de código robusto. Es crítico para el éxito de un proyecto de generación de código. Si su generador trabaja directamente sobre los archivos de implementación que contiene código generado a mano, asegúrese que tiene el sistema de versionado funcionando para que pueda proteger su trabajo.

Otro camino: si Ud. genera código desde el modelo, incluya en el repositorio de código sólo al modelo. El resto de los artifactos vendrán producidos por el proceso de generación. Con la actual tecnología, no se puede generar TODO la aplicación, pero Ud. puede separar, con cuidad, la parte manual de la generada.

Tome con cuidado una decisión sobre el lenguaje de implementación

Las herramientas que use para armar el generador no tienen que ser las mismas que usa para escribir las aplicaciones finales. El problema que el generador está tratando de resolver es completamente diferente del las aplicaciones. Por esa razón, Ud. debe ver al generador como un proyecto independiente y diferente, y elegir sus herramientas de acuerdo a lo que necesita.

Esta es una de las razones por que adopté un nuevo lenguaje (llamado afectuosamente AjBasic) para mi proyecto AjGenesis. Yo quería un lenguaje dinámico que estuviera bajo mi control, para extenderlo en cualquier dirección que el proceso de generación requiera. En uno de mis pruebas iniciales, intenté usar PHP, pero he preferido usar un lenguaje dedicado y pensado para este trabajo, como AjBasic.

Integre el generador en el proceso de desarrollo

El generador es una herramienta para ser usada por ingenieros; entonces, debería encajar claramente en algún punto del proceso de desarrollo. Si es apropiado, puede integrarse en la IDE que use, o en el proceso de build o de check-in en el repositorio de código.

Al haber hecho que el núcleo del AjGenesis sea una librería de clases .NET, pude integrarlo con otras herramientas. Ahora, puedo usarlo desde el NAnt. Una herramienta que se integre a la IDE del Visual Studio o del Eclipse, es una tarea pendiente.

Incluya advertencias

Su generador debe siempre dejar advertencias en el código para qu ela gente no vaya y toque ese código. Si se agrega código agregado a mano y se ejecuta de nuevo el proceso de generación, perderemos las modificaciones. No debe culpar a la gente: el que estén usando su herramienta es un gran paso adelante. En cambio, ponga mayores advertencias, y mejore la documentación del generador. Ud. es el emisario de su herramienta.

En AjGenesis, este problema es atacado por los templates que el usuario escriba. Ud. puede agregar cualquier texto que Ud. quiera, con las advertencias correspondientes: éste es el poder de poder escribir sus propios templates, Ud. tiene la propiedad del código generador, no depende de la herramienta.

Hágalo amigable

Sólo porque el generador es una herramienta para programadores no significa que tenga que ser críptico su uso. El generador debe decir al desarrollador lo que está haciendo, y qué archivos ha alterador o creado, y debe manejar los errores con una razonable cuota de decoro. Puede parecer tonto, pero una herramienta que es difícil de usar o que no es amigable será ignorada y sus esfuerzos por promoverla serán en vano.

El núcleo de AjGenesis es una dll, que puede ser invocada desde una aplicación. Hace años, escribí tareas para invocarlo y ser usado desde el NAnt. Gracias a Jonathan Cisneros, tenemos el AjGenesis Studio, desde el año pasado. He mejorado el código original, y a principios de 2008, agregué el AjGenesis Web Studio, para generar desde una interfaz web. El manejo de errores debe ser mejorado, especialmente para los nuevos usuarios de AjBasic.

Incluya documentación

La buena documentación es un punto a favor de la venta del generador. Su documentación debe ser abarcativa, sin ser intimidante, y cubrir los puntos principales: qué hace el generador, cómo se instala, cómo se ejecuta, y qué archivos afecta.

Actualmente, éste es un punto no bien cubierto por AjGenesis. Pero a cambio, hay varios posts explicando el proceso y los ejemplos (AjGenesis posts) (AjGenesis posts en Español). Usuarios de la herramienta están comenzando a escribir también (ver los posts de Carlos Marcelo Santos). Hay una lista de correo en español donde los usuarios pueden discutir sob ela herramienta y su uso (Code Generation group). Y en la la página del proyecto en Codeplex, hay ejemplo para generar Java, .NET, y PHP, varios usando el mismo modelo (una prueba ácida para un generador).

Recuerde que la generación es un tema cultural

Uducar a sus colegas con documentación, seminarios, y encuentros uno a uno es crítico para instalar y usar su generador. La gente es escéptica a las nuevas cosas, y un buen programador es el doble de escéptico que una persona promedio. Ud. necesita romper con esa resistencia y dudas, y emfatizar que el generador que ha diseñado los beneficiará.

Yo doy de tres a cuatro charlas por año, sólo dedicadas a explicar la herramienta y su potencial. Adicionalmente, la explico en casi cada curso que doy (de Java, .NET, PHP o de software en general). Pero para ser adoptada por una compañía o en un proyecto, un usuario debe tomar el cargo de campeón del producto. No es fácil elevar el nivel de abstracción, escribir el modelo y sus transformaciones, en el medio del trabajo del día a día.

Mantenga el generador

A menos que el generador sea una medida temporaria, necesitará ser mantenido en el largo palzo. Si el generador maneja una cantidad grande de código, trátelo como Ud. trataría a un ingeniero manteniendo ese mismo código. Su presupuesto debe incluir tiempo y dinero dedicado a mantener y actualizar este recurso.

AjGenesis no es parte de las "cosas" a mantener. Estas son los templates y tareas que usará en su trabajo. Si Ud. adopta la herramienta para generar aplicaciones, digamos, .NET, Ud. tiene que cambiar e ir mejorando los templates cuando nuevas tecnologías aparezcan (LINQ, ASP.NET MVC....). Y cuando Ud. gana experiencia, Ud. tiene que mejorar el mismo modelo, si descubre nuevas maneras de representar las líneas de producto en las que su compañía se interesa.

Yo podría agregar algunos puntos más:

- El código generado debe ser de la clase de código que Ud. mismo hubiera producido, y del que se sienta orgulloso. La herramienta no debe dictar la forma y la apariencia de su código. Ud. debe estar a cargo.

- El uso de un modelo eleva el nivel de abstracción que manejamos. Esta estrategia separa la paja del trigo, pone los detalles técnicos en el lugar que merecen: lo importante es el modelo.

Bueno, bastante por ahora. Como pueden darse cuenta, la generación de código es un tema que me apasiona. No es la bala de plata. Pero es un arma que quisiera tener, por si la necesito.

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com

"Ver la luz" con generación de código y AjGenesis

lopez — Tue, 10 Jun 2008 14:02:59 GMT

Ayer dí una charla gratuita sobre generación de código, usando AjGenesis. Espero haber transmitido la idea de que es más que generación de código, y que va más allá de la tecnología actual.

Quisiera enumerar algunos posts relacionados con el tema, y comentarlos, así como enumerar enlaces y recursos.

Posts sobre generación de código

Sobre la generación de código

Este es el primer post a leer. Vemos ahí que el cambio de tecnología es una constante en la historia de desarrollo de software, y que no se ve en el horizonte una unificación de nada, ni de lenguajes ni de plataformas. Cada año que pasa, sabemos más de hacer sistemas, pero curiosamente, cada sistema nuevo necesita más codigo que el anterior, en general. Aún usando tecnologías que nos alivian el trabajo, por ejemplo, algún ORM (Object Relational Mapper), si la tecnología triunfa, el propio mercado nos lleva a hacer sistemas más complejos y grandes, y lo que ahorramos en código a escribir, luego lo perdemos en la mayor complejidad de lo sistemas que tenemos a nuestro alcance construir.

También se enumeran otras alternativas a la generación de código, y sus problemas. Las herramientas CASE son muy rígidas, o generales o abarcativas, así como UML y otras iniciativas. Lo que necesitamos son modelos específicos de nuestro dominio, y poder generar lo que querramos, de la forma que nos convenga. De ahí la necesidad de contar con un generador de código que no esté orientado a una tecnología a generar en particular, que sea de código abierto, y que genere lo que nosotros le indicamos, no lo que los autores de la herramienta quieren o pensaron inicialmente.

El usar frameworks propietarios, quedarse en una sola tecnología, tratar de generar todo en runtime apelando a metadata, o generar código desde XML aplicando transformaciones XSLT, son alternativas que creo que son inferiores o más complejas, como se explica en ese post.

Generando Código- Hello World con AjGenesis

Esta es la "prueba ácida" de todo generador de código. Si una herramienta de ese tipo no nos ayuda a crear programas "Hola mundo", con variantes, en distintas tecnologías, entonces no es lo bastante flexible. AjGenesis hace hincapié en la flexibilidad, la adaptibilidad a lo que Uds quieran producir, sin atarlos a una forma o metadata en particular.

Generando aplicaciones con AjGenesis

Un post algo viejo, pero que muestra cómo se pueden generar aplicaciones no triviales con esta herramienta.

AjGenesis- Modelo generado desde los assemblies
AjGenesis- Modelo desde la Base de Datos

Posts sobre cómo el modelo puede partir de otras fuentes, cualquiera que Uds. vean que sea conveniente. Luego, la propia herramienta puede mejorar, completar el modelo, hacer inferencias, o Uds. mismos completarlos, por ejemplo, si el modelo de base de datos no es lo bastante rico para darnos algo de semántica sobre el sistema que tenemos entre manos.

Generando código para NHibernate (Parte 3)
Generando código para NHibernate (Parte 2)
Generando código para NHibernate (Parte 1)

Para ver que pueden usar AjGenesis para facilitar el desarrollo usando alguna librería reconocida por la comunidad, pueden leer esta serie de enlaces, donde gracias a una idea de Omar del valle Rodríguez, se desarrollaron templates para usar NHibernate, y generar hasta una capa de presentación web para probar lo generado.

Hacia el AjGenesis Recipes

Es un trabajo en progreso, para incorporar interacción con el usuario durante el proceso de generación de código.

Usando AjGenesis y NAnt

Explicación y enlaces para usar AjGenesis desde NAnt. Si alguien necesita una interfaz gráfica NAnt-GUI, pueden bajarla desde NAnt-GUI (preparado por Carlos Marcelo Santos, del grupo de generación de código)

Genesis Studio- una IDE para AjGenesis

No todo lo tienen que hacer desde la línea de comando, o desde el NAnt/NAnt-GUI. El bueno de Jonathan Cisneros desarrolló esta herramienta WinForm, con sintaxis de color y muchas mejoras en la experiencia de usuario, que pueden bajar desde:

http://www.codeplex.com/ajgenesisstudio

Preservando código en AjGenesis

Si necesitan generar código, pero luego modificarlo, pueden usar algunas capacidades de AjGenesis para delimitar qué parte regenerar y cuales conservan.

Code Generation as a Service

La última adición al AjGenesis: ahora pueden generar código usando una interfaz web. Esto permite que ya sea en Internet, o desde la intranet de su empresa, puedan generar código controlado, que cumpla con los estándares que se hayan adoptado.

Más posts sobre AjGenesis en

AjGenesis

Si necesitan pasarle información a alguien que no maneja el español, pueden probar con mis artículos en "Anglish" (Angel's English):

http://ajlopez.wordpress.com/category/ajgenesis

Enlaces

EL sitio sobre generación de código es

http://www.codegeneration.net

Ahí encontraran comentarios, herramientas, preguntas frecuentes sobre generación de código en general. Tienen una base de datos de herramientas publicadas. Hay enlaces sobre generación de código para distintas tecnologías, como Java, .NET, PHP y también temas de MDA (Model-Driven Architecture).

Otros enlaces que tratamos en las charlas son:

CodeSmith Tools

MyGeneration Software

AndroMDA.org - Home

Mantengo todo tipo de enlaces relativos a generación de código en

http://del.icio.us/ajlopez/codegeneration

Lista de correo sobre generación de código

Existe un Google Group que se puede consultar por email, en español, dedicado a la generación de código. Ahí, además de otros temas, se trata de generación de código con AjGenesis, la generación de templates. En los archivos del grupo se publican ejemplos armados por los miembros.

Pueden ver los mensajes y suscribirse, en:

http://groups.google.com/group/codegeneration

Conclusión

Espero que quede claro que lo importante es usar generación de código como solución pragmática, pero basado en la abstracción de un modelo. Hacer el ejercicio de abstracción de generar un modelo adecuado para lo que necesitemos, es un "must" que me parece el primer paso para separarnos de los problemas de cambios en las tecnologías, herramientas y plataformas.

Luego, el modelo debe ser de libre definición. Y el texto o código generado, también: debe ser el tipo de texto o código que hubiéramos generado nosotros mismos. Finalmente, la herramienta de generación de código tiene que estar disponible en código totalmente abierto, para que se pueda extender, entender o usar de la forma que querramos.

Tengo que escribir más sobre la importancia del modelo, y que pueden hacer el suyo propio: no hay modelo fijo, pueden partir desde la base de datos, desde los archivos XML de los ejemplos, o desde donde quieran. También tengo que escribir sobre la posibilidad de hacer modelos que se deriven de otros modelos. Y escribir haciendo énfasis en que lo que construimos, en realidad, es un sistema experto. De ahí, que desde el principio, incorporé un lenguaje de programación que puede tomar decisiones, completar y modificar el modelo.

Como ven, con AjGenesis, ¡sky is the limit! :-)

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/

Charla gratuita sobre generación de código

lopez — Fri, 06 Jun 2008 13:48:42 GMT

Casi todos los cursos y charlas que doy, termino mencionando generación de código, desde un modelo, como una solución pragmática a varios problemas que tenemos al desarrollar sistemas. El lunes que viene, doy una charla gratuita sobre el tema, en el Club de Programadores, acá en Buenos Aires.

Más información e inscripción:

Curso Generacion de Código

Objetivos
Durante la charla, examineremos el concepto de modelo independiente de la plataforma de un sistema, y mediante tecnologias de templates, generaremos codigo para gran parte de una aplicacion, en distintas tecnologias, como PHP, Java con JSP, .NET con ASP.NET, contra MySql o SQL Server, usando distintas estrategias de persistencia, como procedimientos almacenados o NHibernate. Todo basado en un mismo modelo, con distintas plantillas de generacion de codigo, manejados desde el proyecto de codigo abierto AjGenesis.

Plan de Estudio
- Modelo independiente de la plataforma
- Generacion de artefactos de texto con logica y plantillas definibles por cada usuario (no produce algo fijo, sino codigo como el que hubiéramos producido en nuestro equipo de programacion)
- Capacidad de ejecutar varias tareas adicionales (compilacion, instalacion en la base, ....)
- Organizacion de esa tareas de generacion y adicionales en forma automatica y repetible
- Adaptacion a varias tecnologias destino

Lo mío es un apostolado, espero que puedan "ver la luz" .... :-) ;-)

Hay bastante sobre el tema publicado en este blog en:

AjGenesis
Generación de Código

Artículo inicial a leer

Sobre la generación de código

Algunos enlaces a recursos en la web:

http://del.icio.us/ajlopez/codegeneration

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/