October 2007 - Posts
¿Qué tienen en común Windows, Windows Live, Internet Explorer, Home Server, y Expression Blend? En todos esos productos de Microsoft, Powerpoint tuvo un parte en el proceso de diseño. Dentro de la propia Microsoft, el PowerPoint es una herramienta popular para armar prototipos.
Usando prototipos para la experiencia de usuario, puede armarse una maqueta rápida, para poder tomar decisiones y hacer pruebas de usabilidad.
Pueden ver una presentación sobre su uso en la presentación de Manuel Clement:
Expression arount the clock
Argumenta Clement que en vez de gastar tiempo y esfuerzo con otras tecnologías, que posiblemente involucren mucho código, prefirieron usar directamente PowerPoint, sobre Visio, Flash, HTML, Silverlight. Explica el uso de presentaciones PowerPoint sin que fluyan linearmente (implica ir a opciones avanzadas del programa, y deshabilitar el uso del click de mouse para avance automático).
Mientras, Long Zheng ha liberado un toolkit de controles para usar en PowerPoint 2007:
Prototype Toolkit 0.1
Más sobre PowerPoint en
Microsoft Design prototyping with PowerPoint
Gracias a Paulo Arancibia, por este dato del uso del PowerPoint.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
Siguiendo con la serie
Generando código para NHibernate (Parte 1)
Generando código para NHibernate (Parte 2)
del ejemplo de Omar del valle Rodriguez, tengo una nueva versión del ejemplo, que genera aplicaciones con AjGenesis. Gracias desde acá, a las sugerencias de Omar, y de Fabio Maulo. He incorporado algunas características, como:
- Uso de NHibernate 1.2
- Manejo de mapeo de subclases en .hbm por separado
- Propiedades virtuales en las entidades
- Dos nuevas aplicaciones generadas
Pueden bajar el ejemplo AjOmar Versión 1.1 (es el archivo AjOmar-v1.1.zip) desde la página de ejemplos de AjGenesis.
El modelo
Como siempre, la idea de AjGenesis es basarse en un modelo libre, donde uno especifica lo que le interesa modelar. En el caso de este ejemplo, se modelan entidades, y a partir de esa información se generan aplicaciones completas. El modelo prácticamente no cambió desde la anterior versión (ver Parte 2), en el archivo Projects/AjOmar/Project.xml:
<Project>
<Name>AjOmar</Name>
<Description>Example AjOmar for (N)Hibernate</Description>
<Prefix>AjOm</Prefix>
<Domain>com.ajomar</Domain>
<CompanyName>ajomar</CompanyName>
<Model>
<Entities>
<Entity Source="Entities/Client.xml"/>
<Entity Source="Entities/Company.xml"/>
<Entity Source="Entities/User.xml"/>
</Entities>
</Model>
</Project>
Como había pedido Omar, Company y User heredan de Client. En la base de datos se usan tres tablas, y el NHibernate hace la magia del mapeo en este dominio con entidades relacionadas por herencia.
Como antes, también se especifican los elementos de tecnología, como la base de datos a usar, el usuario y contraseña a usar en los strings de conección, y otros detalles. Esto permite cambiar la tecnología, sin cambiar el modelo de arriba. Un ejemplo en el archivo Projects/AjOmar/Technologies/VbNet2Nh.xml:
<Technology>
<Programming>
<Dialect>VbNet2Nh</Dialect>
</Programming>
<Database>
<Dialect>MsSql</Dialect>
<Name>AjOmar</Name>
<Username>sa</Username>
<Prefix>ajom_</Prefix>
<Host>(local)</Host>
</Database>
<NHibernate>
<Dialect>NHibernate.Dialect.MsSql2000Dialect</Dialect>
</NHibernate>
</Technology>
Deberá adaptar este archivo si necesita ajustar esos datos.
Siguiendo algunas recomendaciones de Fabio Maulo, ahora hay un .hbm por entidad. Ejemplo generado en Build/AjOmar/VbNet2Nh/Src/AjOmar.Data/Company.hbm.xml:
<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
assembly="AjOmar.Entities"
namespace="AjOmar.Entities"
>
<joined-subclass name="Company" table="ajom_companies" extends="Client">
<key column="Id" />
<property name="CompanyName" type="String"/>
<property name="ContactName" type="String"/>
</joined-subclass>
</hibernate-mapping>
Las aplicaciones
Se pueden generar aplicaciones completas, con proyectos y solución web. La generación se invoca con comando de línea, como se explica en la Parte 2. Hay que agregar el directorio bin del AjGenesis en el path de ejecución para que funcionen.
Ahora están habilitados cuatro generaciones de soluciones:
GenerateProject AjOmar VbNet2Nh
GenerateProject AjOmar CSharp2Nh
GenerateProject AjOmar VbNet2DDDNh
GenerateProject AjOmar CSharp2DDDNh
Los dos primeros generan aplicaciones VB.NET y C Sharp, con ASP.NET 2.x, y acceso a datos usando DAOs que usan NHibernate.
Los dos nuevos comandos generan aplicaciones con VB.NET y C Sharp, que utilizan algunas ideas de Domain-Driven Design.
Generando DDD
Las nuevas soluciones generadas, tienen varios proyectos de librerías de clases:
- AjNHibernate: contiene las clases para el manejo de las llamadas al NHibernate, como configuración, factoría y obtención de sesiones.
- AjOmar.Domain: contiene las Entities, Services, y Repositories, a la Evans. No hay conceptos de Value Objects, o Aggregates. Los servicios se llaman Manager, para distinguirlos de la fachada de servicio que uso en Application.
- AjOmar.Application: la capa que coordina las llamadas al Dominio, desde la presentación.
Y como antes, hay una aplicación web AjOmar.WebClient.
Próximos pasos
Tengo que generar aplicaciones similares para Hibernate, Java, y MySql. La idea es que sirva como prueba de concepto: desde un mismo modelo, se pueden generar aplicaciones implementadas con distintas tecnologías.
Habrá que estudiar e implementar el manejo de nulos, restricciones por tamaño de campo, y mejorar la apariencia de las aplicaciones generadas.
Hay que mejorar (y probar) el manejo de relaciones uno a varios, o varios a uno. Lo tengo implementado en los ejemplos AjGenesisExamples3, pero debería pasar ese código de plantillas y adaptarlo para este ejemplo.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
Hace dos años, tuve el gusto de dar una charla con Martín Salías, en Microsoft de Argentina, sobre lenguajes de programación en .NET. Uno de los que presentamos (además de Lisp, Prolog y cosas así, Martín expuso sobre LINQ que estaba entonces apareciendo), fue el lenguaje F#.
Siendo un proyecto de investigación de Microsoft, pueden ver más información sobre el lenguaje en:
F# site
Don Syme's WebLog on F# and Other Research Projects
F# - A Functional Programming Language
Robert Pickering's F# Resources
F# es un lenguaje mixto, es imperativo y es funcional, basado en lenguajes funcionales como Caml, y con sintaxis C#.
Tiene seguridad de tipos, rendimiento, soporte de scripting. Algunas características mencionadas en el sitio de F#:
- Scripting interactivo como en Python
- Inferencia de tipo y seguridad de tipos como en ML
- Un perfil de rendimiento como en C#
- Acceso a todo el framework .NET
- Simplicidad en sus fundamentos, como en Scheme
- La rapidez de ejecución de código nativo, usando el soporte de concurrencia y distribución del framework .NET
Algunos artículos iniciales, tomados del sitio de Microsoft:
Y ahora, en estos días, se anunció el inicio de un proyecto esperado por la comunidad F#: la inclusión del editor del lenguaje en el Visual Studio. Más detalle en:
F# makes its way to VS.NET
Algunos comentarios de Soma Somasegar, en el post mencionado:
F# - A Functional Programming Language
sobre la iniciativa de Microsoft de tener F# ahora en el Visual Studio, como ciudadano de primera clase en el mundo .NET (Somasegar es vicepresidente en Microsoft encargado de las herramientas de desarrollo):
Nuestro interés en F# es motivado por varios factores.... Queremos continuar con el flujo de buenas ideas desde la programación funcional hacia la corriente principal de desarrollo. Además, la notación algo matemática de F# parece naturalmente atractiva para aquellos profesionales cuyo domino principal es descripto en notación matemática, dominios como el financiero, científico y la computación técnica. Sobre el atractivo de la sintaxis, el sistema de tipos fuerte provoca la clase de garantías que es frecuentemente crucial en esos dominios, y permite una experiencia de la herramienta superior con Visual Studio.
Otra motivación es continuar invirtiendo en hacer del framework .NET una gran alternativa para uso académico. Muchos departamentos de ciencia de la computación en el mundo enseñan programación funcional. Creemos que a través de F# y lenguajes como IronPython y IronRuby nosotros podemos ofrecer a los estudiantes y educadores alternativas más allá de la actual corriente principal, y habilitar el uso de estos lenguajes en la enseñanza. Esto ayuda a los educadores a tener una opción a usar el Visual Studio como una herramienta de curso a curso.
Esperemos ver qué sucede. Es simpático el F#, aunque hay que habituarse a sus sintaxis e ideas (siento algún escalofrío recordando mis días con el APL, A Programming Language), pero veamos como la comunidad académica lo toma. Me parece más difícil verlo adoptado en entornos de desarrollo, pero si prende en la academia, seguramente podrá tener su nicho en la industria. Es interesante leer en los comentarios del post de Somasegar, la opinión de James Plamondon: "esto es un preludio al día en que los programadores podrán elegir el mejor lenguaje para escribir cada parte de su tarea de codificación, así como un carpintero usa un martillo para una y una sierra para otra".
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
Quería escribirles hoy de un grupo de usuarios de Mendoza, provincia de mi país, Argentina, dedicado a difundir el lenguaje y la tecnología Java.
http://mendozajug.com.ar
Tienen un excelente sitio, donde van ingresando las actividades del grupo. Son de destacar, la iniciativa Pattern Reactor:
Pattern Reactor
Pattern Reactor es una base de conocimiento acerca de patrones de diseño, implementada por medio de un wiki, donde todos los usuarios aportan ejemplos de situaciones reales en las que aplicaron cierto patrón. De esta manera, se hace posible consultar la existencia, explicación y la realidad de cada uno de los patrones de diseño.
Los patrones se cargan a la base con una plantilla que unifica el formato de la información de cada patrón. Esta plantilla contiene el nombre del patrón, una explicación del mismo, los posibles entornos donde se puede encontrar, un diagrama que explique el uso del patrón en forma gráfica y por supuesto, la lista de casos reales o ejemplos, que irá creciendo a medida que cada uno aporte su experiencia. Otro aspecto fundamental del proyecto, es la posibilidad de discutir y comentar libremente, por medio del foro, los casos de aplicación que han expuesto los usuarios.
Vean también el notable:
Diseño de escenas Java3d
Y los artículos
Trabajando con Db4o en Java describiendo persistencia de objetos en Java
Analizando el nuevo Swing Application Framework (Parte 1) sobre el nuevo framework para organizar aplicaciones Swing
Precisión Infinita sobre el uso de clases de Java para operar sin límite de precisión, el Inertial Math de Javier Quiroga.
Bueno, espero que actividades y grupos como éstos sigan adelante. Un saludo desde acá, en Buenos Aires.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
Hace unos días, Scott Guthrie dió más detalles sobre la implementación que se viene de MVC para ASP.NET de la mano de Microsoft:
ASP.NET MVC Framework
One of the things that many people have asked for over the years with ASP.NET is built-in support for developing web applications using a model-view-controller (MVC) based architecture.
Last weekend at the Alt.NET conference in Austin I gave the first public demonstration of a new ASP.NET MVC framework that my team has been working on. You can watch a video of my presentation about it on Scott Hanselman's blog here.
Algunos comentarios de Scott:
Qué es un framework MVC?
MVC divide la implementación de una aplicación en tres roles: modelos, vistas y controladores.
- "Modelos" en una aplicación MVC son los componentes de la aplicación responsables de mantener el estado. Frecuentemente este estado es persistido en una base de datos (por ejemplo: podemos tener una clase Producto que es usada para reprensentar datos de una tabla Productos en un SQL).
- "Vistas" son los componentes responsables de presentar la interfaz de usuario. Típicamente esta UI es creada desde los datos del modelo (por ejemplo: podemos crear una vista "Editar" de producto que coloque cajas de textos, listas desplegables y checkbos, basados en el estado actual del objeto Producto).
- "Controladores" son los componentes encargados de manejar la interacción con el usuario final, manipulando el modelo, y finalmente elegir la vista para mostrar la UI. En una aplicación MVC la vista es sólo para exhibir información: es el controlador el que maneja y responde a la entrada del usuario y su interacción.
Detalles de implementación
Sigue Scott:
Uno de los beneficios de usar una metodología MVC es que ayuda a reforzar una clara separación de las responsabilidades entre el modelo, vistas y controladores de una aplicación. Mantener esa clara separación hace que la prueba de la aplicación sea más fácil, ya que el contracto entre los diferentes componentes está más claramente definido y articulado.
Algunos detalles que describe de la implementación de Microsoft:
- Permite la separación de responsabilidades, testeo y uso de TDD. Todos los contratos principales del framework MVC son interfaces que pueden ser simulados (ahora hay interfaces para IHttpRequest-IHttpResponse). Se puede usar el framework de testeo que uno quiera (incluyendo NUnit, NBUnit, MS Test, etc).
- Es altamente extensible y admite plugins. Todo en el framework MVC de Microsoft está diseñado para que pueda ser fácilmente reemplazado o adaptado (por ejemplo, uno puede opcionalmente agregar su propia maquinaria de vista, política de ruteo, serialización de parámetros, etc.). También soporta el uso de inyección de dependencias y modelos de contenedores IOC (Windsor, Sprint.NET, NHibernate, etc..).
- Incluye un muy poderoso mapeador de URL que nos permite armar aplicaciones con URLs limpias. Las URL no necesitan tener extensiones, y están diseñadas para soportar fácilmente patrones de nombres para SEO (Search Engine Optimization) y REST. Por ejemplo, uno puede fácilmente mapear /products/edit/4 a la acción del botón "Editar" en un controlador de productos, o mapear /Blogs/scottgu/10-10-2007/SomeTopic/ a la acción "DisplayPost" de una clase BlogEngineController.
- El framework MVC soporta el uso de los archivos ASP.NET ya existentes, como .aspx, .ascx, .master, como "plantillas de vista" (siginfica que uno puede usar las capacidades de ASP.NET como master pages anidades, código <% %>, controles del servidor, plantillas, enlace a datos, localización). No usa, sin embargo, el modelo postback de interacción con el servidor. En cambio, uno rutea toda la interacción del usuario a una clase Controller, lo que ayuda a separar una clara separación de responsabilidades y testeo (eso implica que no hay viewstate o ciclo de vida de página en las vistas MVC).
- El framework ASP.NET MVC soporta totalmente las características de ASP.NET como autenticación Forms o Windows, autorización por URL, membresía y roles, caché de datos y salida, manejo de perfiles y session, monitoreo de salud, sistema de configuración, la arquitectura de providers, etc.
Bueno, es una parva de novedades. Veremos cuándo queda disponible para que podamos evaluarla y usarla.
Vean los comentarios en el post de Scott: tienen mayores detalles muy interesantes.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
Siguiendo las ideas del proyecto Fabriq, estuve escribiendo un ejemplo de una aplicación servidora que puede recibir y procesar mensajes OneWay de Windows Communication Foundation (WCF). El servidor ejecuta un concepto lógico, una aplicación: cada aplicación tiene nodos, que a su vez contienen acciones. El ejemplo puede bajarse de AjMessagesWCF-0.1.1.zip
El mensaje
El mensaje a comunicar es un mensaje WCF (en la versión original de Fabriq no se usa WCF). La información principal que AjMessages usa está en la propiedad Headers.Action. Ese texto tiene el nombre de la aplicación destino, el nodo y la acción a invocar.
La acción
Tiene el formato:
<application>/<node>/<action>
Una aplicación tiene un conjunto de nodos. Un servidor puede albergar uno o varios nodos de una aplicación. Un nodo puede ejecutarse en distintos servidores. De esta forma, el proceso interno del servidor puede reenviar un mensaje a otro servidor: la acción no es una dirección física, sino que es lógica. Cada server conoce la dirección y nodos en ejecución de los demas, porque se le informa en un archivo de configuración, o dinámicamente durante la misma ejecución. Con esa información puede reenviar un mensaje a otra máquina.
La aplicación
Un archivo de configuración XML define las aplicaciones que un servidor conoce. Una aplicación tiene:
- Nodes: cada nodo es un conjunto de acciones a procesar. Nodo es a acción, como clase es a método.
- Handlers: los objetos que procesan un mensaje. Un handler puede estar compuesto de otros handlers.
- Actions: los puntos de entrada con nombre a un handler
Un ejempl de definición de aplicación:
<Application Name="App1">
<Node Name="Node1">
<Handler Name="PrintMessageHandler" Type="AjMessages.PrintMessageHandler, AjMessages"/>
<Handler Name="PostHandler" Type="AjMessages.PostHandler, AjMessages"/>
<Handler Name="DecrementHandler" Type="AjMessages.Console01.DecrementHandler, AjMessages.Console01"/>
<Handler Name="Pipeline1">
<Handler Name="DecrementHandler"/>
<Handler Name="PostHandler">
<Property Name="Action" Value="App2/Node1/Process"/>
</Handler>
</Handler>
<Action Name="Process" Handler="Pipeline1"/>
</Node>
<Node Name="Node2"/>
</Application>
El handler
Un handler debe implementar la interfaz:
public interface IHandler
{
void Process(Context ctx);
}
El contexto tiene una propiedad Message, que apunta al mensaje WCF en proceso. También tiene otros métodos para usar: una propiedad Server que referencia al servidor en ejecución, y un método Post para enviar un nuevo mensaje. La idea es colocar en el contexto todo lo necesario para que un handler se comunique con el proceso en ejecución.
Esta es una diferencia con la implementación original de Fabriq, donde un handler recibe un mensaje, no un contexto.
El host
Un host es una unidad lógica que se ejecuta dentro de un servidor AjMessages. Un servidor conoce via configuración cuáles son los hosts que tiene disponibles remotamente, y cuáles levantar localmente. Un ejemplo:
<Host Name="Host1" Address="http://localhost:50000/AjMessages" Activate="true">
<Application Name="AjMessages">
<Node Name="Administration"/>
</Application>
<Application Name="App1">
<Node Name="Node1"/>
<Node Name="Node2"/>
</Application>
</Host>
Configuración dinámica
Uno de las características claves implementadas es un handler que reconfigura al servidor durante la ejecución, en runtime. Recibe una nueva configuración XML, en un string, y con eso actualiza la configuración que tenga en ese momento. Usando este handler, una aplicación puede enviar un mensaje al servidor AjMessages, y cargar, parar, actualizar hosts, aplicaciones y nodos.
La solución
El proyecto de librería de clases AjMessages contiene la implementación del ejemplo. Los otros proyectos son tests manuales que muestrar el uso de la librería.
Dentro de la carpeta Configuration hay clases definidas para leer la configuración desde un XML.
La carpeta Handlers contiene algunos handlers ya definidos, el más importante es el ConfigurationHandler que permite reconfigurar dinámica al servidor mientras está en ejecución.
La carpeta Ports tiene implementaciones de endpoints para recibir y enviar mensaje a otro servidor AjMessages.
El PipelineHandler.cs es el hadler compuesto, que contiene otros handler.
LocalHost.cs es la implementación de un host que se está ejecutando en el mismo server. Mantiene una lista de los nodos activos.
RemoteHost.cs mantiene la información asociado a los hosts que se ejecutan en otros servidores. Con esa información, el servidor local conoce cómo reenviar un mensaje, al saber qué servidores remotos tienen un nodo apropiado para la acción del mensaje.
Ejecutando el ejemplo
Hay un proyecto de consola AjMessages.Console01 que puede ser usado como un test manual, para probar el funcionamiento del ejemplo.
Se puede ejecutar el ejemplo, y al lanzarlo, pide comandos por la consola. Una prueba posible es la siguiente:
load ConfigurationServer1.xml
load ConfigurationHost1.xml
load ConfigurationHost2.xml
send App1/Node1/Process 20
El primer comando crear el servidor, usando el archivo de configuración. El segundo y tercer comando reconfigura el servidor para instalar y ejecutar dos hosts, con sus aplicaciones y nodos. El último comando envía un mensaje entero usando la acción App1/Node1/Process.
Luego, podemos ingresar:
unload
fork
Esto lanza otro servidor de consola. En el primer servidor, ingresamos:
load ConfigurationServer1.xml
load ConfigurationHost1.xml
load ConfigurationRemoteHost2.xml
y en el segundo:
load ConfigurationServer2.xml
load ConfigurationHost2.xml
load ConfigurationRemoteHost1.xml
En cualquier de los dos, ingresamos:
send App1/Node1/Process 20
y vermos a los dos servidores intercambiar mensajes.
En cualquier momento, al ingresar:
help
obtenemos una lista de comandos a usar.
Próximos pasos
En una futura versión, reescribiré el ejemplo para usar un Message propio, capaz de ser transportado via WCF o DSS (Decentralized System Services). Así, el servidor podrá albergarse en otras tecnologías. Debo refactorizar algunas clases, como Server, que ha quedado con muchas responsabilidades.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
En estas semanas, estuve estudiando el código del proyecto Fabriq. Es un proyecto .NET de hace unos años, pueden bajarse el código desde este post de Arvindra Shemi:
FABRIQ has gone public!
Más información sobre el proyecto original:
Arvindra Shemi Fabriq Articles
Clemens Vasters Fabriq Articles
Una imagen de la documentación:
Según la documentación del proyecto:
FABRIQ is an infrastructure for constructing networks of nodes processing and relaying messages. These nodes are hosted in machines running into a serviced application.
Uno puede tener varias máquinas ejecutando una o varias aplicaciones. La "red" es la aplicación, un node es una colección de acciones, y cada acción procesa un mensaje. Más de la documentación:
These nodes can be hosted in any distribution on several machines according to a defined configuration, so there may be machines running a single node or several nodes, this association are made by specifying the host-name or machine identification associated with each node in the network.
Each of these machines is running a serviced application responsible for starting and stopping its Host and Nodes which are the application main components. The host is responsible for handling the configuration, loading and unloading nodes and receives the messages and delivers them to the appropriate Node.
Un post interesante que va al núcleo del problema:
Positioning FABRIQ - What? Why? Apple or Orange?
Otros artículos más técnicos:
FABRIQ Terminology
A simple FABRIQ config file
FABRIQ Message Handlers and Pipelines
FABRIQ Networks and Nodes
Configuring FABRIQ Networks and Nodes
Creo que todas estas características pueden ser reimplementadas usando las tecnologías .NET actuales, y con un poco de trabajo, en Java (el proyecto publicado usa .NET 1.x, y hostea bajo COM). En .NET podemos usar Windows Communication Foundation, o los nuevos servicios distribuidos aportados por el Microsoft Robotics (DSS).
Con WCF, el mensaje a intercambiar y procesar podría ser de la clase System.ServiceModel.Channel.Message. Otra idea podría ser tener una clase propia Message, que pueda ser serializable con diferentes transportes: WCF, DSS, Remoting, Web Services, otras.
Estoy trabajando en reescribir desde cero la idea de Fabriq, con configuración dinámica, balanceo de carga, usando WCF u otra tecnología de base. He traido algunas ideas de mi viejo proyecto AjServer:
Hacia el AjServer
Un avance de lo que estoy haciendo, un archivo de configuración:
<?xml version="1.0" encoding="utf-8" ?>
<AjMessages>
<Application Name="AjMessages">
<Node Name="Administration">
<Handler Name="ConfigureHandler" Type="AjMessages.ConfigureHandler, AjMessages"/>
<Handler Name="PrintHandler" Type="AjMessages.PrintHandler, AjMessages"/>
<Handler Name="PrintMessageHandler" Type="AjMessages.PrintMessageHandler, AjMessages"/>
<Handler Name="ConfigurePipeline">
<Handler Name="PrintHandler">
<Property Name="Text" Value="Reconfiguring server..."/>
</Handler>
<Handler Name="PrintMessageHandler"/>
<Handler Name="ConfigureHandler"/>
</Handler>
<Action Name="Configure" Handler="ConfigurePipeline"/>
</Node>
</Application>
<Application Name="App1">
<Node Name="Node1">
<Handler Name="PrintMessageHandler" Type="AjMessages.PrintMessageHandler, AjMessages"/>
<Handler Name="PostHandler" Type="AjMessages.PostHandler, AjMessages"/>
<Handler Name="DecrementHandler" Type="AjMessages.ManualTest02.DecrementHandler, AjMessages.ManualTest02"/>
<Handler Name="Pipeline1">
<Handler Name="PrintMessageHandler"/>
<Handler Name="DecrementHandler"/>
<Handler Name="PostHandler">
<Property Name="Action" Value="App2/Node1/Process"/>
</Handler>
</Handler>
<Action Name="Process" Handler="Pipeline1"/>
</Node>
<Node Name="Node2"/>
</Application>
<Host Name="Host1" Address="http://localhost:50000/AjMessages">
<Application Name="AjMessages">
<Node Name="Administration"/>
</Application>
<Application Name="App1">
<Node Name="Node1"/>
<Node Name="Node2"/>
</Application>
</Host>
</AjMessages>
Tengo una versión andando, con WCF y sin WCF. Espero postear algo sobre el tema en estos días.
Angel "Java" Lopez
http://www.ajlopez.com/en
En estos días, escribí un ejemplo mínimo, para explorar algunas ideas, usando el Concurrency and Coordination Runtime, la librería de Microsoft library que viene en su Robotics Studio. Más sobre CCR en el artículo:
Concurrent Affairs: Concurrency and Coordination Runtime
Mi idea es implementar el pase de mensajes entre componentes, de manera asincrónica. El código de ejemplo puede bajarse de AjAgentsCCR-0.1.zip
El agente
En el ejemplo, la interfaz a implementar por cada componente, que llamamos agente, es:
public delegate void ReturnHandler<T>(T t);
public interface IAgent
{
void Post(Message msg);
void Post(string action,
params object[] parameters);
void Post<T>(string action,
ReturnHandler<T> handler,
params object[] parameters);
}
El agente puede recibir mensajes (que son objetos de una clase Message, ver más abajo). En el mensaje viene un texto con la Action a ejecutar (como si fuera un nombre de método) y una lista variable de parámetros.
El tercer método Post implementa un delegado, un método a ejecutar cuando el envío del mensaje produce una respuesta, un valor de retorno. Esa vuelta se produce en el futuro, no se queda esperando la respuesta. Podemos enviar un mensaje a otro agente, sin esperar la respuesta, o podemos escribir el delegado para procesar esa respuesta cuando llegue.
El mensaje
Es una clase con
action: un nombre que identifica la acción asociada al mensaje
body: el contenido del mensaje
response port: la puerta CCR donde enviar el valor de retorno, si es necesario
He aquí el código de esta clase:
public class Message
{
private string action;
public string Action
{
get { return action; }
set { action = value; }
}
private object body;
public object Body
{
get { return body; }
set { body = value; }
}
private Port<object> returnport;
internal Port<object> ReturnPort
{
get { return returnport; }
set { returnport = value; }
}
public Message()
{
}
public Message(string action)
{
this.action = action;
}
public Message(string action, object body)
{
this.action = action;
this.body = body;
}
public Message(string action, object[] bodyvalues)
{
this.action = action;
if (bodyvalues != null && bodyvalues.Length == 1)
this.body = bodyvalues[0];
else
this.body = bodyvalues;
}
}
Notemos que el mensaje tiene puede manejar un arreglo de valores en el body, y que puede enviar un objeto dentro de su contenido.
La implementación
En este ejemplo inicial, la interfaz IAgent tiene una implementación basado en Invoke, via Reflection, que termina invocando un método en el agente, que tiene el mismo nombre que la acción recibida. Se pueden pensar otras formas de manejar el mensaje, pero esta manera permite codificar el agente como una clase más, con métodos normales.
El mensaje, una vez recibido, se coloca en una puerta CCR, para que se pueda manejar de manera asincrónica. Hay un Receive arbiter de CCR para atender los mensajes entrantes, que son ruteados al correspondiente método en el objeto.
Creo que es una solución interesante: se puede escribir una clase con métodos normales, y convertirla en agente, heredando de la clase Agent.
Podemos enviar un mensaje con
agent1.Post("Decrement",20);
Puede "consultar" algún valor con:
agent1.Post<int>("GetCounter", PrintCounter);
Próximos pasos
Estoy trabajando en:
- Escribir un Enviroment, o clase Host, donde los agentes "vivan". El Host sería responsable de mantener una lista de agentes por nombre.
- Escribir un archivo de configuración donde pueda especificar qué agentes crear y cargar a comenzar a funcionar el Environment o Host, y que los relacione usando alguna implementación de inyección de dependencias. Me imagino servidores de agentes que pueda cargar un agente remoto de assemblies que se encuentren en otros servidores de la red.
- Usar estos agentes en forma distribuida, con Windows Communication Foundation (WCF), o con Decentralized System Services (DSS). En este último caso, un servicio DSS podría ser un agente o podría representar la entrada a un Environment
- Implementar algún patrón Subscribe/Notify entre agentes.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
En la Altnetconf, Scott Guthrie ha revelado la implementación de Microsoft de un MVC para ASP.NET.
Leemos en
altnetconf - Scott Guthrie announces ASP.NET MVC framework at Alt.Net Conf
que el nuevo framework será soportado dentro del propio framework de .NET, y tendremos:
Natively support TDD model for controllers. Provide ASPX (without viewstate or postbacks) as a view engine Provide a hook for other view engines from MonoRail, etc. Support IoC containers for controller creation and DI on the controllers Provide complete control over URLs and navigation Be pluggable throughout Separation of concerns Integrate nicely within ASP.NET Support static as well as dynamic languages Tanto los web forms como el nuevo modelo son soportados dentro de la misma aplicación.
Ahora, una URL puede tener la forma
/<Ruta>/<Acción>/<Parámetro1>/<Parámetro2>
donde la ruta se mapea a un controlador. Múltiplas rutas pueden ser mapeadas al mismo controlador.
Pienso que esto puede ser aplicado a aplicaciones SaaS. La Ruta puede representar a un Tenant+Sistema. Espero que el mapeo pueda ser dinámico, es decir, que pueda ser especificado en ejecución. Al parecer, como en otras tecnologías de .NET, podremos tener la capacidad de configurar distintas partes, como el ruteador de la entrada, factoría de controladores y demás.
Veamos algunas características citadas en ese artículo:
Controladores
Pueden heredar de cualquier clase, implementan una interfaz IController, o pueden heredar de una clase base de controladores. Las acciones y parámetros, de la URL, nos llegan en un DTO llamado RouteData. Y hasta aparece un IHttpContext, una interfaz a lo que era el HttpContext clásico.
Vistas
Lo novedoso es que la tecnología de vistas puede ser tanto ASP.NET, como otras "engines" como NVelocity. En el caso de ASP.NET, las páginas heredan de ViewPage, en lugar de Page (supongo que será parecido a lo que hace Spring MVC). Se le pasa un modelo, en un DTO, que en vez de ser un "bag", es tipado.
Más información en
ScottGu MVC Presentation and ScottHa Screencast from ALT.NET Conference
Chris Holmes- ALT.NET Conference- Brave New World
Nima Dilmaghani - Microsoft announces new MVC architecture for Web Apps
Gary Sherman - Microsoft is changing the world - at least part of my world - for the better
MVC Framework
Rod Paddock - AltNetConf Day2 - Agile and MVC Goodness
Dos videos sobre la presentación de ScottGu
ScottGu on MVC at ALT.NET Conference
ScottHa on MVC+DLR=Love at ALT.NET Conference
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
El bueno de Gabriel Szlechtman , me avisa de este congreso, que se realizará en diciembre. Acá está la nota de difusión:
--------------------------------------------------------------------------
Smalltalks 2007
--------------------------------------------------------------------------
El Lunes 10 de Diciembre de 2007, desde las 9:30 hasta las 18:00 horas
se llevará a cabo en la Facultad de Ciencias Exactas y Naturales (FCEN) de
la Universidad de Buenos Aires, el Primer Congreso Argentino de Smalltalk,
denominado "Smalltalks 2007"
Todas aquellas personas que estén relacionadas con Smalltalk, sean
docentes, alumnos, investigadores, desarrolladores o empresarios, están
invitados a participar como oyentes o expositores de manera gratuita
inscribiéndose en http://www.dc.uba.ar/smalltalks2007 .
El objetivo de la conferencia es reunir a la comunidad Smalltalk Argentina
para estrechar vínculos compartiendo un día de exposiciones de trabajos,
experiencias y vivencias relacionadas con esta tecnología o temas afines.
La jornada estará dividida en dos secciones:
1) Sección de Investigación/Educación
2) Sección de Industria
En la "Sección de Investigación/Educación" se expondrán aquellos trabajos de
investigación y educación que se estén realizando o se hayan realizado con
Smalltalk, en ámbitos de universidades y establecimientos públicos o
privados.
En la "Sección de Industria" se expondrán trabajos relacionados al
Desarrollo de Software en Argentina utilizando Smalltalk.
Algunos temas sugeridos para las presentaciones, de manera no excluyente son:
* Prácticas Ágiles (XP, TDD, etc)
* Herramientas de Desarrollo
* Desarrollo con Prototipos
* Model Driven Development
* Desarrollos de Aplicaciones Web
* Meta-Modeling
* Nuevos Modelos o Frameworks implementados
* Nuevos Frameworks de UI
* Material Educativo
* Sistemas Embebidos y Robótica
* SOA y Web services
* Reportes de Experiencias de Desarrollo o Investigación
* Sistemas comerciales
Aquellos interesados en exponer, deben tener en cuenta los siguientes
hitos y tareas:
1) Deben presentar un Abstract de la presentación a más tardar para el
Lunes 5 de Noviembre de 2007. Dicho Abstract no debe superar dos carillas
y debe incluir mínimamente una descripción del trabajo a presentar sin
omitir el objetivo del mismo y la sección a la cuál se apunta la presentación.
Debe detallarse también si la presentación incluirá una demostración en vivo
del modelo Smalltalk relacionado. El Abstract se puede presentar enviando un
email a smalltalks2007@gmail.com indicando como subject "Presentación"
2) El Comité de Programa de la Conferencia definirá para el Lunes 19 de
Noviembre aquellos trabajos que serán elegidos para ser presentados durante
la jornada a partir de los Abstracts recibidos según lo especificado
en el punto anterior. Se dará mayor importancia a aquellos trabajos con
capacidad de mostrar ejemplos dinámicos y no únicamente presentaciones
estáticas.
3) Aquellos que sean seleccionados para realizar las exposiciones, deberán
como mínimo generar un presentación con Power Point o herramienta similar.
(Por restricciones de tiempo, no se exigirá presentación de paper, pero se
agradecerá a aquellos que puedan hacerlo). Todo material utilizado para
la exposición (presentación, paper si corresponde, etc.) deberá ser
entregado en su totalidad a más tardar el Miércoles 5 de Diciembre para la
realización de los Proceedings de la Conferencia.
4) La definición del Cronograma de la Conferencia se publicará a través
de la página web el Lunes 26 de Noviembre.
Las actividades se llevarán a cabo en el aula Magna del Pabellón de
Industrias de Ciudad Universitaria. Para más información sobre cómo llegar,
dudas, fechas, programa, etc., pueden acceder a
http://www.dc.uba.ar/smalltalks2007
Los esperamos a todos!
Comité Organizador de Smalltalks 2007
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
En medio de tantas tecnologías, desde Flash a Silverlight, desde AJAX en sus diversas implementaciones, hasta WebParts, y demás, a veces nos olvidamos que muchas de las aplicaciones que usamos, no son fácilmente manejables por todas las personas.
Hay una organización SIDAR:
http://www.sidar.org/
que cumple diez años en estos días. Leemos en
http://www.sidar.org/2007/aniversario/
El 27 de junio de 2007 se cumplen diez (10) años desde la celebración del primer «Seminario sobre Diseño y Accesibilidad en la WWW», por tanto ¡El SIDAR está de cumpleaños!.
Desde su nacimiento, el SIDAR ha servido de punto de encuentro y discusión para usuarios, diseñadores, desarrolladores y expertos; ha difundido, promovido, informado y formado a la comunidad Iberoamericana en la eliminación de barreras en la Sociedad de la Información y del Conocimiento.
El Seminario es lo que sus miembros hacen de él, y a lo largo de estos 10 años ha sido liderado, en sus distintos grupos de interés y de trabajo, por personas voluntarias de varios países de Iberoamérica. Todos ellos han sido los impulsores, los tejedores, de esta extensa red que derriba barreras y construye una Sociedad de la Información accesible e inclusiva para todos. A todos ellos ¡Gracias!.
Tienen preparados actos en España, Argentina, Colombia, Perú, México. Vean en esos enlaces los detalles.
En mi país, se viene una conferencia en el Microsoft User Group:
Introducción a la accesibilidad. "Diseñando Para Todos"
a cargo de Martín Baldassarre (quien me informó de estas actividades) y Claudio Segovia. Es gratuito, en Buenos Aires, y se realizará el martes 16 de Octubre, de 18:30 a 21:30hs. El temario:
• Conceptos de Accesibilidad, Usabilidad, Web Semántica, Diseño Centrado en el Usuario.
• Beneficios del Diseño Para Todos.
• Características de Accesibilidad en los distintos Sistemas Operativos y las aplicaciones de escritorio.
• Uso de Estándares, Buenas Prácticas, Patrones,y la Iniciativa por una Web Accesible (WAI)
• El diseño para Todos según las Grandes Empresas (Microsoft, SUN, Adobe, IBM, etc.).
• Las barreras digitales y la brecha digital.
• Ayudas Técnicas .
• Legislación sobre accesibilidad digital.
• Herramientas de validación y revisión.
• Metodologías de revisión.
• Demostración de los mas importantes problemas de accesibilidad.
Luego, el viernes 19 hay un acto en Buenos Aires:
Décimo Aniversario del SIDAR: Celebración en Buenos Aires.
Diez años difundiendo, promoviendo y formando, en toda el área de habla hispana y portuguesa con el objetivo de conseguir que nuestra Sociedad de la Información y del Conocimiento sea accesible, adaptable, usable e interoperable. La penetración de estas ideas ha sido especialmente relevante en Argentina, por ello los miembros del SIDAR queremos celebrar con todos nuestro aniversario.
Se trata de un acto muy sencillo, mediante el que queremos agradecer, y brindar con, todos cuantos han participado directa o indirectamente en la consecución de nuestro objetivo: Construir y mejorar la Sociedad de la Información y del Conocimiento para que sea accesible e inclusiva para todos.
En su primera parte nos dirigirán unas palabras, los miembros y colaboradores argentinos del SIDAR, los cuales nos contarán brevemente: que es el SIDAR, como colaboran con él, y como desde su profesión trabajan para mejorar la Sociedad de la Información. También asistirán miembros del capítulo argentino de ISOC, representantes de la administración pública, responsables de empresas privadas, como de Microsoft Argentina...
Es bueno informarse de estos temas: creo que la web (e Internet) cada vez más se está integrando a la historia humana (o por lo menos, a los que vivimos en un ambiente que nos permite disfrutarla y usarla, hay todo un mundo que está lejos aún de estas herramientas). Y sería excelente, que cada vez más, sea accesible para más personas.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
Desde hace más de una década, el sistema de componentes gráfico Swing ha acompañado a Java. Basado en trabajos previos de Sun y James Gosling, permite tener un sistema de ventanas, componentes gráficos, independiente del sistema operativo y la librería de dibujo que tengamos disponibles en la máquina destino.
Los componentes son dibujados usando Java (AWT en particular). En los últimos años, ha tenido una competencia fuerte de SWT de la gente de Eclipse e IBM, que tiene otro "approach": aprovechar los controles del sistema anfitrión.
Pero hacer una aplicación Java Swing, ha dado siempre trabajo. Para ayudar en el armado de tal aplicación, se ha escrito la JSR-296 llamada Swing Application Framework. Se lanzó en el 2006, y hasta ahora es una implementación prototipo de un conjunto de clases java.
Soporta:
- Ciclo de vida de aplicación, como comienzo y parada de la GUI
- Soporte para el manejo y carga de recursos, como strings, mensajes formateados, imágenes, colores, fonts, y otros tipos
- Soporte para definición, manejo y enlace de Actions, incluyendo las asincrónicas.
- Persistencia del estado de la GUI, automático y selectivo, para que vuelva a aparecer en la próxima ejecución en el mismo estado
- Source code: AppFramework-1.01-src.zip
Algunos enlaces:
Pueden leer más información en
Swing Application Framework
An Introduction to the Swing Application Framework API (JSR-296)
En español, tenemos este muy buen artículo de la gente del JUG de Mendoza, Argentina:
Analizando el nuevo Swing Application Framework (Parte 1) Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/