En el Proyecto Medusa, donde estoy trabajando, se está reimplementando en .NET un sistema de salud, que originariamente estaba escrito en Clipper. Es un sistema bastante grande, que tiene varios casos de uso, desde temas administrativos y contables, hasta turnos, farmacia, stock de medicamentos, cocina para dietas, y seguimiento de pacientes.
Recuerdo que en los ochenta, me topé con DBase II, en varios sistemas operativos, el venerable intérprete, y más adelante, a fines de los ochenta, me encontré con la sorpresa de un compilador, el Clipper de Nantucket, para DOS. Otros recordaran al Fox, que luego, al ser adquirido por Microsoft, pasó a Windows como Visual Fox (no recuerdo si primero Fulton y cía pasaron su producto a Windows y luego Microsoft lo compró, o si primero pasó Fox de DOS a Microsoft, y ahí lo portaron a Windows).
Para los que quieran recordar cómo era el lenguaje, encontré estos enlaces:
CA-Clipper 5.3 . Guide To CA-Clipper – Menu
Clipper (programming language) - Wikipedia, the free encyclopedia
Hay ejemplos con código en:
The Oasis Clipper Source. Over 300,000,000,000 bytes served!
Preguntas frecuentes sobre Clipper y sus sucesores en:
Frequently Asked Questions (FAQ 2.31) about CA-Clipper and CA-Visual Objects
Como comentaba un miembro del equipo Medusa, Clipper mientras fue de Nantucket, se mantuvo actualizado, cuando lo compró Computer Associates, entró en un derrape del que no se recuperó.
Si todavía tienen archivos Fox, Clipper, DBase dando vueltas por ahí, pueden probar los productos de:
CodeBase Products Overview
Y parece interesante, con soporte de SQL Server, y de varias plataformas, el Proyecto de código abierto:
Harbour Project
Como lenguaje, Clipper tenía sus “quirks”, como:
- El uso de SET, como SET EXACT OFF, SET EXACT ON, que cambiaban todo al conducta del programa
- El uso de work areas para acceder a datos
- Cosas como MEMVARS, que todavía tengo que recordar que era… :-)
Por mi parte, estoy divirtiéndome escribiendo un intérprete, AjClipper:
Ya tengo dos simples programas corriendo en mi intérprete:
y
? "This is a test"
foo := "Hello"
bar := "World"
? foo, " ", bar
Pueden ejecutarlo con
AjClipper.Console HelloWorld.prg SimpleTest.prg
No será, “Uy, qué bruto, qué programa”, pero va tomando cuerpo. Pueden seguir mi avance en el trunk de AjCodeKatas:
http://code.google.com/p/ajcodekatas/source/browse/#svn/trunk/AjClipper
Están escritos los tests (dando verde, por ahora):
Buen Code Coverage:
Cualquier enlace interesante sobre Clipper, bienvenido! Iré agregándolos en http://delicious.com/ajlopez/clipper
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez
Hace ya un tiempo que vengo pensando en reflotar AjContab:
http://www.ajlopez.com/ajcontab/
Encuentro este mensaje viejo, en la lista de Arquitectura del MUG de Argentina
http://www.mail-archive.com/arquitectura@mug.org.ar/msg00504.html
AjContab es un viejo ejemplo que daba en mis cursos de .NET 1.x, hace unos años. Debería reescribirlo, en ASP.NET 2, VS2008, tal vez ASP.NET MVC? Veré. Pero en estos días habia tweeteado:
http://twitter.com/ajlopez/status/2258288758
La idea es tener:
- Múltiples Tenants
- Múltiples Empresas
- Múltiples Planes de Cuenta por Empresa
- Múltiples Ejercicios
- Usuarios y Roles
- Minutas/Asientos
- Reportes como Balance, Libro Diario, Libro Mayor
Al escribirlo en PHP/MySql, podría colocarlo fácilmente en línea. Me serviría como ejercicio de repaso de PHP, y comenzaría a tener un proyecto con Ajax, Javascript, JQuery quizás? Trataría de codificarlo liviano, para no ponerle demasiada arquitectura o parafernalia al principio. En todo caso, eso lo dejaría para la versión .NET o Java.
Será interesante ver cómo los usuarios reciben la idea de tener un sistema así en la web. En el Proyecto Medusa (que mencioné hace poco, en Generación de código con AjGenesis para Mere Mortals Framework), está incluido el desarrollo de un sistema contable en web. AjContab me serviría para afilar las uñas en el tema de poner este tipo de aplicaciones andando.
En cuanto tenga algo publicado, escribo por acá. Keep tuned! :-)
Sugerencias? Bienvenidas!
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Ayer, gracias a un tweet de @chillicoder, me enteré de la aparición del primer número de la revista de la gente de Pragmatic Programmer:
http://www.pragprog.com/magazines
Les recomiendo bajarse la edición actual, de Julio. Yo la bajé desde esa página en formato PDF, pero también está disponible para otros formatos (notablemente, para Kindle). Esta edición no tiene desperdicio.
Encuentro una editorial y artículo de Michael Swaine, un buen reencuentro con este autor, que debo estar leyendo desde que escribía en la Dr. Dobb’s.
Leo un artículo donde explican su posición para poner a disposición este material, sin restricciones, y sobre cómo lo producen, en formato PDF (usando iText). Cada artículo tiene enlaces al final, sobre los temas y productos mencionados. Es bueno ver cómo uno de los primeros artículos explica cómo producen la propia revista y otros materiales. Es parte de lo ágil: explicar, dejar algo, que sirva para que las buenas prácticas o cosas aprendidas, puedan difundirse más allá del equipo que lo usa.
Hay un artículo de Andy Lester (programador desde hace 20 años, visitar su blog http://www.theworkinggeek.com/), sobre “The layoffs are coming”, donde explica tips para conseguir trabajo, o mantenerse en el mismo. En un mundo cambiante y en crisis, vemos que también el programador americano promedio se ve afectado.
Michael Swaine entrevista a Rick Hickey (que creó Clojure, un dialecto muy popular de Lisp, que corre sobre la máquina virtual de Java, que por alguna extraña razón, es más popular que AjLisp… :-). Un artículo sin desperdicio, que tengo que leer en detalle. Pueden visitar http://clojure.org/ y he coleccionado enlaces que me parecieron interesantes en http://delicious.com/ajlopez/clojure. (bueno, vería también http://delicious.com/ajlopez/lisp y http://delicious.com/ajlopez/functionalprogramming si están aburridos un fin de semana…. :-). Esta misma revista incluye un artículo técnico sobre Clojure, sobre su manejo de exceptions.
El bueno de Dave Thomas es entrevistado por Swaine, sobre el proceso de publicación de los libros y revistas, y el mercado de libros electrónicos. Son temas importantes: qué va a pasar con el libro impreso? Hay cambios, y Thomas explica su visión.
Hay un artículo de autor John Shade, sobre Microsoft, Google, y Wolfram Alpha, cómo es la pelea por la arena de los buscadores. Finalmente, hay un calendario de eventos que vienen (me temo que algo centrado en eventos de EE.UU.)
Y si alguien todavía no lo conoce, les recomiendo la visita a todo el sitio
http://www.pragprog.com
y los blogs de Andy Hunt http://andy.pragprog.com/ y Dave Thomas http://pragdave.pragprog.com/. Tienen videos y podcast, yo prefiero lo escrito: http://www.pragprog.com/articles
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Luego del éxito de Agiles 2008, en Buenos Aires, Argentina, este año se está organizando la nueva edición en Florianápolis, Brasil, para el 6 al 9 de Octubre de 2009. Esta es la llamada a participar:
Estimado colega,
Qué opinas de formar parte del equipo de expositores que reune nombres como Brian Marick, Diana Larsen, Matt Gelbwaks, Naresh Jain, Dave Nicolette, Alan Cyment, Alexandre Magno, entre otros? El próximo lunes 6 de julio será la última oportunidad para presentar tu propuesta de charla en Ágiles 2009!
Ágiles 2009, a realizarse en Florianópolis, Brasil, es un evento sin fines de lucro, organizado por profesionales entusiastas del tema, unidos por el objetivo de crear un espacio amplio de discusión sobre las metodologías ágiles y su adopción en América Latina.
Como expositor, tendrás acceso libre a la conferencia y otras ventajas que los organizadores están preparando para ti! Puedes proponer una presentación, un tutorial, un reporte de experiencias o un workshop. Accede a http://www.agiles2009.org/es/submissions.php para ver la información que debes proporcionar para presentar tus propuestas.
Esperamos contar contigo en Ágiles 2009!
Comité Organizador
www.agiles2009.org
Tienen más información en español en:
http://www.agiles2009.org/es/index.php
y el programa del congreso en:
http://www.agiles2009.org/es/program.php
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
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
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
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
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
Sandra, de la provincia de Tucumán, Argentina, produjo este video, usando el lenguaje Logo, parece que con el FMSLogo.
Durante el video, visita el sitio del bueno de Daniel Ajoy:
http://neoparaiso.com/
Donde tenemos información sobre el lenguaje y trabajos relacionados de Logo:
http://neoparaiso.com/logo/
Ya escribí sobre Logo, mostrando el trabajo del bueno de Marcelo Dushkin sobre ese lenguaje, en la variante XLogo, con robótica:
Mi primer robot, con XLogo y Rasti
Mi primer robot
No tengo más información sobre Sandra. Pueden visitar su usuario en Youtube
http://www.youtube.com/user/educainformatica
El foro que menciona en el video, al que estoy suscripto, es:
http://groups.google.com/group/logoes
Más información sobre versiones de Logo en:
http://neoparaiso.com/logo/#sect3
http://neoparaiso.com/logo/logoes-mswlogo.html
Mis enlaces sobre este lenguaje, desde:
http://delicious.com/ajlopez/logo
Para los que les gusta más la programación, recomendaría darle un visita al NetLogo:
http://ccl.sesp.northwestern.edu/netlogo/
NetLogo is a cross-platform multi-agent programmable modeling environment.
Si, imaginaron bien, hay un pichón de AjLogo en:
http://code.google.com/p/ajlogo/
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez
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
Desde los 80, trato de ser desarrollador de software, más que programador. Un programador es programador de un lenguaje, o de pocos lenguajes, y se ocupa sólo de programar. Encuentro hoy el artículo:
Small ISVs: You need Developers, not Programmers
de Eric Sink, desarrollador y empresario, fundador de SourceGear. Quiero comentar brevemente con mis palabras algo del post, les recomiendo leer el original en inglés.
Como dice Eric, el contexto es crítico: un buen consejo para una empresa, no tiene que ser bueno para otra. Cuando escribió ese artículo (2003), SourceGear tenía seis años de vida, y 25 empleados.
Eric escribe que más que programadores, su empresa necesita desarrolladores. Cuál es la diferencia? Un programador escribe programas, un desarrollador contribuye de múltiples maneras al éxito de un producto.
Yo pienso que eso se necesita aún en empresas grandes. Pero ese tipo de empresas se puede dar el lujo de tener especialistas. Un empresa chica, tiene que contar entre sus filas, no programadores especialistas, sino desarrolladores, y gente que pueda ponerse distintos “sombreros”.
Un desarrollador, entonces, además de programar, tiene que involucrarse en:
- Escribir especificaciones
- Manejo de configuración
- Revisión de código
- Pruebas
- Pruebas automáticas
- Documentación (ug!…. :-)
- Resolver problemas del cliente
Puede ser difícil conseguir gente que pueda hacer todo eso, además de codificar, especialmente para una empresa chica. Pero muchas personas tienen la capacidad de hacer eso, no se necesita “rocket science”. La solución? Formar a la gente. Dentro de una empresa, un programador puede evolucionar a desarrollador.
En un equipo ágil, se puede entrenar a los “juniors” en estas habilidades adicionales, haciendo el trabajo de a pares, rotando los roles entre los miembros del equipo, etc…
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
http://www.facebook.com/ajlopez
Hoy me encuentro con el post
AML (Arbitrary Modeling Language)
Lo que se plantea ahí es que UML (Unified Modeling Language) es un fracaso. A ver, veamos.
Los que recuerdan aquellos años de los 90, cada autor venía con su propia forma de dibujar los distintos modelos que iban surgiendo para describir software y sistemas. Como lo que construimos no es una casa o edificio, no es fácil describir lo que vamos a crear, codificar, armar, y explicarlo, sólo en texto. Impulsados por la adopción de objetos, muchos de los diagramas informales que se usaban, y de los formales que aparecían en herramientas CASE, se fueron adoptando, hasta que finalmente, los “Tres Amigos” se juntaron en un vuelo de avión, y se unificaron sus ideas, en lo que fue luego apoyado por la OMG como UML.
Todo UML es un avance, por ser una forma estándar de comunicarnos.
Pero hay que acordar con Neal Ford, el autor del post, que la mayor parte de nosotros, terminamos usando el AML (lenguaje de modelado arbitrario): usamos nuestras propias cajas, círculos y líneas. En medio del auge de lo ágil, yo pienso que es un buena práctica, SIEMPRE Y CUANDO, se mantenga el objetivo principal: poder comunicar nuestras ideas. Ningún dibujo es auto explicativo, o es difícil que lo sea. Como Eric Evans apunta en su libro sobre DDD, los diagramas tienen que estar acompañados por texto, y los textos, ser explicados con diagramas.
La comunicación es la clave. Como desarrolladores, tenemos que entrenarnos en esa habilidad. Ya pasó el tiempo del programador aislado, trabajando solo en su máquina. Hoy, cualquier software no trivial, es producto de un equipo de trabajo. Si en nuestro equipo usamos diagramas, que sean UML o AML, es secundario. Lo que debe importar es que se usen consistentemente, y sean entendibles.
Lo importante, también, es tener modelos. Modelos que simplifican y explican mejor lo que estamos construyendo. Y no olvidar que el modelo, como el mapa, no es el territorio.
UML lo que tiene de bueno, es que es “entendible” para el que lo estudió. El problema es que no todos los involucrados en un proyecto puede entenderlos, y hoy, son más personas no técnicas las que están involucradas en un desarrollo de software.
También, UML ha sufrido de la “ilusión del desarrollo”: pensar que dibujando, se crean sistemas. Muchos desarrolladores o managers, o gente interesada, estudia UML como si fuera la forma mágica de crear software, sin pagar el precio de codificación.
Independientemente de usar UML o AML, recomendaría no pasar horas con un software de diagramas. Para muchos días de nuestra actividad diaria, bastan los diagramas en el pizarrón, tomar la foto, y enviarlo a la lista de desarrollo.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
http://www.facebook.com/ajlopez
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
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
En estos días estoy repoblando de software mi notebook. Una de las aplicaciones que he instalado, para comenzar a usar con más frecuencia, es el Maven de la gente de la Apache Foundation. Durante años, muchos proyectos de código abierto basan su armado y empaquetado en un utilitario como el Ant. Pero más y más proyectos están pasando a basarse en este otro utilitario Maven. Así que aprovecho que mi nueva notebook está limpia de anteriores versiones, para probar este utilitario.
Pueden visitar el sitio del proyecto (código abierto, en Java):
http://maven.apache.org/index.html
Ahí leemos
Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information.
If you think that Maven could help your project, you can find out more information about in the "About Maven" section of the navigation. This includes an in-depth description of what Maven is, a list of some of its main features, and a set of frequently asked questions about what Maven is.
No nos revela mucho esa descripción, pero les cuento algo: Maven es un Ant con esteroides. Basado en la descripción de un proyecto con el Project Object Model, puede armar la estructura de ese proyecto, para que podamos después completarlo en programación, bajarse las librerías que necesitemos (p.ej. Hibernate, Spring..), y hasta armar un sitio del proyecto, como los que tienen los proyectos de la fundación Apache (de hecho, fue así como nació Maven, como un automatizador de la creación de nuevos proyectos a incubar en la fundación Apache).
Yo me bajé la última versión, según su página de downloads:
http://maven.apache.org/download.html
En mi caso la versión binaria apache-maven-2.1.0-bin.zip.
Estoy trabajando en un Windows Vista, así que expandí ese .zip en el directorio c:\Program Files\apache-maven-2.1.0 y armé dos variables de ambiente, M2 y M2_HOME como pide la documentación del producto, además de asegurarme que existe la variable JAVA_HOME :
Agregué el valor de M2 (el directorio de los binarios de Maven) a la lista de directorios contenida en mi variable de ambiente PATH.
Una vez que hice eso, pude ejecutar una prueba desde la consola, que muestre la versión de Maven que estoy usando. Vean que el comando a invocar es mvn:
Estoy siguiendo los pasos del
Maven in 5 minutes
Para probar de crear un proyecto mínimo, un típico Hello World. En un directorio Dev, ejecuté el comando:
El maven comienza a armar la carpeta del proyecto, y a bajar cualquier dependencia que decida que necesite. Vean que van a tener que estar conectados a Internet la primera vez que lo ejecuten, porque lo más probable es que Maven vaya bajando software adicional que necesita. El repositorio de Maven se va creando en un directorio .m2 dentro del directorio home del usuario. En mi caso
Durante el proceso, va mostrando el avance de la creación del proyecto:
El resultado, es una carpeta como:
En el directorio inicial se encuentra el archivo pom.xml que describe al proyecto:
1: <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
2: xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
3: <modelVersion>4.0.0</modelVersion>
4: <groupId>com.ajlopez.app</groupId>
5: <artifactId>my-app</artifactId>
6: <packaging>jar</packaging>
7: <version>1.0-SNAPSHOT</version>
8: <name>my-app</name>
9: <url>http://maven.apache.org</url>
10: <dependencies>
11: <dependency>
12: <groupId>junit</groupId>
13: <artifactId>junit</artifactId>
14: <version>3.8.1</version>
15: <scope>test</scope>
16: </dependency>
17: </dependencies>
18: </project>
El próximo paso, es, desde el directorio del proyecto, invocar al Maven nuevamente, con otra instrucción, de empaquetar (compilar y armar un .jar con nuestra aplicación):
Ahora podemos ejecutar nuestro programa empaquetado, con el comando
Un comando más interesante, es el que genera el sitio del proyecto:
Dentro del directorio target\site deja un sitio con la descripción del proyecto, que podemos ver en nuestro navegador:
Espero que sirva como descripción de los primeros pasos para probar Maven, aunque todavía no queda claro toda la potencia que tiene el producto. Tengo que describir más en detalle lo que es el Project Object Model, las dependencias, el ciclo de vida de un proyecto, los distintos “verbos” que tenemos, además de package o test.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez
El bueno de Martín Baldassarre (que, teniendo problemas de vista, firma sus emails con “¡Nos vemos, y sino nos chocamos!” …. ;-), siempre ha luchado por el tema de la accesibilidad. Estamos rodeados de tecnologías, como Silverlight, Flash y demás, pero a veces nos olvidamos de lo más simple e importante: llegar a las personas, más que a los ojos.
Ya había escrito sobre otra reunión que había difundido Martín en
Accesibilidad para todos- SIDAR y sus 10 años
Ahora, se viene la tercera jornada "Por una Web Sin Barreras para las Personas con Discapacidad". Esta es la gacetilla de prensa:
3ª Jornada "Por una Web Sin Barreras para las Personas con Discapacidad"
El martes 16 de junio se realizará la 3ª Jornada "Por una Web Sin Barreras para las Personas con Discapacidad" donde se difundirá información sobre las dificultades que encuentran para utilizar Internet quienes tienen alguna discapacidad y las normas que deben aplicarse al construir páginas web para evitar la creación de estas barreras.
Esta Jornada es organizada por el Capítulo Argentina de Internet Society (ISOC-AR) y se desarrollará en Microsoft de Argentina, Bouchard 710 Piso 4. Es una actividad no arancelada que requiere inscripción previa.
Se realizará transcripción simultánea para personas hipoacúsicas.
Participarán Diputados, funcionarios, especialistas en accesibilidad web y expertos en discapacidad.
Inscripción: Enviando Nombre, Número de Documento y empresa/organización a: acc@isoc.org.ar
PROGRAMA
3ª Jornada "Por una Web Sin Barreras para las Personas con Discapacidad"
martes 16 de junio de 2009
8:45 hs. ACREDITACIÓN
9:15 hs. APERTURA
Ezequiel Glinsky: Gerente de Nuevas Tecnologías, Microsoft de Argentina
Sebastian Bellagamba: Manager - Oficina Regional para America Latina y el Caribe, Internet Society (ISOC)
Raquel Tiramonti: Presidenta de la Comisión Nacional Asesora para la Integración de Personas Discapacitadas (CONADIS)
María José Lubertino: Presidenta del Instituto Nacional contra la Discriminación, la Xenofobia y el Racismo (INADI)
Claudio Morgado: Diputado Nacional, Presidente de la Comisión de Discapacidad
Nicolás Trotta: Subsecretario de Tecnologías de Gestión, Secretaría de la Función Pública
10:00 hs. "Porque, para que y como de la Accesibilidad Web"
Jorge Plano: Internet Society Capítulo Argentina (ISOC-AR) y UTN Fac. Reg. Buenos Aires
10:40 hs. CAFE
11:00 hs. "Discapacidad, Tecnología y la Convención sobre los Derechos de las Personas con Discapacidad"
Carolina Buceta: Red por los Derechos con las Personas con Discapacidad (REDI)
11:45 hs. "Nuevas Tecnologías de Texto para las Telecomunicaciones para Personas Hipoacúsicas"
Arnoud van Wijk: Disability Projects Coordinator, Internet Society (ISOC)
12:15 hs. RECESO PARA ALMUERZO
13:30 hs. Principios tecnológicos para la accesibilidad web
Claudio Segovia: Internet Society Capítulo Argentina (ISOC-AR) / Fund. SIDAR
Martín Baldassarre: Internet Society Capítulo Argentina (ISOC-AR) / Fund. SIDAR
Martín Salías: Southworks
14:45 hs. CAFE
15:10 hs. Experiencias de accesibilidad web en Argentina
Maria Dolores García: Programa para la Sociedad de la Información (PSI-SECOM)
Karina Rojo: Administración Nacional de la Seguridad Social (ANSES)
Norma Bonora: Soles de Buenos Aires
Nicolas Boccacci: Universidad Católica Argentina (UCA)
16:30 hs. CIERRE
Mónica Bianchi: Presidenta Asociación Civil para la Integración Social (ACIS)
Mónica Abalo Laforgia: Presidenta del Capítulo Argentina de Internet Society (ISOC-AR)
Actividad no arancelada que requiere inscripción previa: enviando Nombre, Número de Documento y empresa/organización a: acc@isoc.org.ar
Se realizará transcripción simultánea para personas hipoacúsicas.
Patrocinan:
Microsoft
Administración Nacional de la Seguridad Social (ANSES)
Instituto Nacional contra la Discriminación, la Xenofobia y el Racismo (INADI)
Fundación La Nación
Más información en:
http://www.isoc.org.ar/accesibilidad.html
Hubo dos jornadas anteriores:
Aquí pueden leerse detalles de la Segunda Jornada, incluyendo las presentaciones
Aquí pueden leerse detalles de la Primera Jornada, incluyendo las presentaciones
Para conocer más sobre el tema referencias a sitios sobre accesibilidad web
Favor de difundir estas jornadas!
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
La gente de PyCon Argentina http://ar.pycon.org/ está organizando la Primera Conferencia Argentina de Python, a realizarse en Buenos Aires, el 4 y 5 de Setiembre de 2009.
Pueden encontrar más información en
http://ar.pycon.org/2009/about/
Hay Charlas Plenarias, Charlas Programadas, Charlas Relámpago (hay que ir preparado para hablar!) Todavía faltan definir varios puntos, creo que no está decidido el lugar de la reunión.
Pero ya hay un “Call for Papers”
http://ar.pycon.org/2009/charlas/
PyCon Argentina - http://ar.pycon.org/
Primera Conferencia Argentina de Python
Buenos Aires - 4 y 5 de Septiembre de 2009
PyAr, el grupo de usuarios de Python de Argentina llama a la participación de la comunidad de usuarios de Python y Software Libre a la Primera Conferencia Argentina de Python.
En este evento nos juntaremos desarrolladores avanzados y principiantes de Python para intercambiar información, compartir experiencias, analizar nuevas tecnologías, y en general aprender más de este lenguaje a través de la comunidad de Python Argentina.
El autor de cada charla seleccionada podrá participar presencialmente, como orador en el evento. En los casos en que la charla sea realizada por varios autores, se permitirá un máximo de 3 oradores.
Aclaración: Por cuestiones presupuestarias, sólo podrá abonar algunos de los pasajes, total o parcialmente, a los autores seleccionados que residan fuera de Capital Federal o Gran Buenos Aires.
Agradecemos la contribución de todos en la difusión de este llamado y del evento en si mediante los banners diseñados para tal fin y que se encuentran la sección Ayudanos - Difundir
Dónde enviar las Charlas
Las charlas deben ser enviadas para su aprobación a través de este sitio, en Conferencia - Propuestas - Enviar La fecha límite de envío de charlas es el 29 de Junio inclusive. En caso de consultas o inconvenientes, contactarse con charlas@ar.pycon.org
Cómo enviar las Charlas
El envío de la propuesta de charla debe tener los siguientes datos:
- Título:
- Autor(es): Nombre y apellido, breve descripción de cada uno, foto, asociación, grupo de usuarios, organismo, o empresa a la que pertenece, si corresponde.
- Tiempo estimado de duración: Las charlas generalmente son de 45'. En caso de que sea mayor o menor el tiempo requerido solicitamos su justificación.
- Breve descripción de la charla: Uno o dos párrafo(s) que explique -no tan brevemente- el contenido de la presentación.
- Nivel objetivo de la charla: Clasificar dentro de: introductorio/intermedio/avanzado/experto
- Tipo de publico: Desarrolladores avanzados, desarrolladores principiantes, empresarios, docentes, público en general
- Conocimientos previos: Especificar que conocimientos previos deberán tener los asistentes.
- Tags: web, gui, databases, frameworks, orm, ide, ciencia, educación, juegos, comunidad, etc.
- Teléfono del/los autor/es: Para poder comunicarnos.
- Ciudad de residencia del/los autor/es.
Qué formato deben tener las Presentaciones
El envío de las diapositivas y/o presentaciones debe tener alguno de los siguientes formatos:
- Openoffice.org presentation
- HTML standard
- Postscript
- PDF
- Texto plano
Licencia
Debe especificarse una licencia que permita que PyAr distribuya el material en un CD-Live o de Documentación y que permita ser descargado del sitio web de PyAr. Se recomienda Creative Commons o similares.
Es interesante que la comunidad de desarrolladores de Python vaya organizando este tipo de eventos. Espero que sea un éxito.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Estuve trabajando creando una solución .NET que contiene un ejemplo mínimo de NHibernate 2.x. Estoy usando la distribución binaria NHibernate GA 2.0.1, siguiendo las instrucciones del manual de referencia.
Pueden bajarse el código fuente de la solución de mi Skydrive:
NHibernateExample1.zip
Estuve usando la documentación en línea de
http://nhforge.org/doc/nh/en/
y armé el mismo manual en formato .pdf, usando comandos del trunk de SVN:
https://nhibernate.svn.sourceforge.net/svnroot/nhibernate
Si quieren, pueden bajar el manual en .pdf de este enlace:
nhibernate-reference.pdf
La solución contiene dos proyectos: una librería de clases, y una aplicación de consola:
El dominio sólo contiene una clase, Cat (estoy siguiendo el primer ejemplo que se describe en la documentación):
namespace NHibernateExample1.Domain
{
public class Cat
{
private string id;
private string name;
private char sex;
private float weight;
public Cat()
{
}
public virtual string Id
{
get { return id; }
set { id = value; }
}
public virtual string Name
{
get { return name; }
set { name = value; }
}
public virtual char Sex
{
get { return sex; }
set { sex = value; }
}
public virtual float Weight
{
get { return weight; }
set { weight = value; }
}
}
}
Hay un recurso embebido que describe el mapeo Cat.hbm.xml:
<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
namespace="NHibernateExample1.Domain" assembly="NHibernateExample1.Domain">
<class name="Cat" table="Cats">
<!-- A 32 hex character is our surrogate key. It's automatically
generated by NHibernate with the UUID pattern. -->
<id name="Id">
<column name="CatId" sql-type="char(32)" not-null="true"/>
<generator class="uuid.hex" />
</id>
<!-- A cat has to have a name, but it shouldn' be too long. -->
<property name="Name">
<column name="Name" length="16" not-null="true" />
</property>
<property name="Sex" />
<property name="Weight" />
</class>
</hibernate-mapping>
Hay un ExecuteAll.cmd en el directorio Sql, que crea la base de datos a usar (pueden darle como parámetro el servidor de MS SQL Server a usar, .\SQLEXPRESS es el valor asumido):
La aplicación de consola es simple: configura NHibernate, obtiene una sesión, inserta nuevos objetos en una transacción, ejecuta una consulta, y lista el resultado:
static void Main(string[] args)
{
ISessionFactory sessionFactory = new Configuration().Configure().BuildSessionFactory();
ISession session = sessionFactory.OpenSession();
ITransaction tx = session.BeginTransaction();
Cat cat;
cat = new Cat() { Name = "Moe", Sex = 'M', Weight = 9.0f };
session.Save(cat);
cat = new Cat() { Name = "Larry", Sex = 'M', Weight = 8.5f };
session.Save(cat);
cat = new Cat() { Name = "Sue", Sex = 'F', Weight = 7.5f };
session.Save(cat);
tx.Commit();
IQuery query = session.CreateQuery("select c from Cat as c where c.Sex = :sex");
query.SetCharacter("sex", 'M');
foreach (Cat kitty in query.Enumerable())
System.Console.Out.WriteLine("Male Cat: " + kitty.Name);
session.Close();
System.Console.ReadLine();
}
Ejecutando la aplicación de consola se inserta en la base estos datos:
El ejemplo es simple. Ahora que está funcionando con NHibernate 2.0, pienso actualizar mis templates de AjGenesis para usar esa versión.
No dejen de visitar el sitio de comunidad de NHibernate, para conseguir más información:
http://nhforge.org
Si tienen dudas sobre NHibernate, pueden preguntar en el grupo en español:
NHibernate-Hispano
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
El desarrollo de la computación ha sido impresionante, desde la mitad del siglo pasado. Mucho de su avance se debió, en aquellos años, a la inversión en investigación de EE.UU. durante la guerra fría. Uno de los ámbitos donde hubo mucha investigación fue en la simulación gráfica. Recuerdo las primeros pasos de Sutherland y cía, en la creación de escenarios en tres dimensiones.
Hoy, la investigación también debe tener un componente gubernamental, pero veo más iniciativa privada. Cualquier avance puede llegar hoy a un mercado global, y eso permite que la investigación y desarrollo “se financie” con la expectativa de recupero de la inversión.
Una de las empresas con mayor compromiso con la investigación es Google. Y en el evento Google I/O (donde también presentó Wave, que merecería un post aparte), mostró a su aparato a la Holodeck de Star Trek, pueden ver fotos en
Google Holodeck: StreetView In 360 Degrees
Bueno, no será todavía como el de la Enterprise, pero algo es algo.
Pero es impresionante cómo algoritmos, hardware, software han ido avanzando, desde aquellas primeras pantallas con escenas de “alambre” en 3D, a estos resultados. Parece que es sólo cuestión de potencia de cálculo el alcanzar mejores resultados.
Bueno, un enlace de postre, para los que les gusta la ciencia ficción:
Where I Write - Main Page
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Llegó el nuevo producto de Microsoft, que presentan, no como un buscador, como un engine de búsqueda, sino como un motor de decisiones:
http://www.decisionengine.com
Como empresa gigante, Microsoft se puede dar el lujo de tener un gran equipo de research, y llega el momento en que todo ese conocimiento y esfuerzo se vuelca en algún producto (no siempre).
Yo todavía tengo que probar ese producto, que no está liberado al público. Como muchos productos globales, hoy se anuncian de esta manera, con un video viral, como el de arriba, que no sólo está en el sitio, sino que también está en Youtube, y lo puedo embeber en mis blogs.
A simple vista, es un producto que montado sobre ideas (no implementaciones) de web semántica, apunta a no tener tanto agentes recorriendo y obteniendo información, sino a presentarla y organizarla para que el usuario tenga una experiencia distinta.
Veremos si cumple con la expectativa. Pero es interesante ver cómo la fuente de la información es la propia web. También es interesante notar que la información de la que parte, no estaba pensada para ser consumida de esa forma. Eso es lo que imagino que va a pasar con las ideas de web semántica. Las páginas publicada sólo va a comenzar a contener información semántica, cuando este tipo de aplicaciones se popularicen. Mientras tanto, el “trabajo sucio” de obtener información de los datos de una página, quedará a cargo de las aplicaciones.
No veo que sea una “killer application” para Google. Más bien, como Wikipedia, va a brindar otra experiencia de usuario. Así como hay temas que investigamos con Google, así como habrá otros más estructurados que investigamos partiendo de Wikipedia, habrá consultas, tareas, comparaciones, donde preferiremos (o no) a Bing.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
More Posts
Next page »