Archive for the '5124' Category

Presentando AjGroups: Librería de Grupos Finitos

Thursday, December 30th, 2010

Estuve escribiendo una librería de clases C# para manejar grupos finitos. Un grupo es un conjunto G de elementos dotados de una operación binaria *, dondee:

a * b  is in G    (clausura)

a * (b * c) = (a * b) * c        (asociatividad)

a * a’ = e     (existencia de inverso e identidad)

a * e = e * a   (identidad)

El código de la solución está en AjCodeKata Google Project, en trunk/AjGroups:

Las principales interfaces son:

IElement tiene un método Multiply, que recibe otro IElement y retorna el resultado IElement. IElement.Order es el número de elementos a ser multiplicados para obtener la identidad:

a * a * a ….. * a = e

IGroup.Elements es la colección de IElements que son elementos del grupo. IGroup.Order es la cantidad de elementos.

Hay dos implementaciones de esas interfaces: una basada en permutaciones, otra basada en elementos con nombre (como “a”, “e”) y una tabla describiendo sus multiplicaciones.

Hay métodos para:

– Obtener los subgrupos de un grupo
– Obtener los subgrupos normales de un grupo
– Determinar si dos grupos son isomorfos

Seguí Test-Driven Development (TDD). Todos los tests en verde:

Buen code coverage:

Debería hacer algún refactoring, pero el proyecto va tomando forma. Escribiré posts describiendo la implementación de permutaciones, y la otra, la basada en elementos abstractos.

Nos leemos!

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

ALT.NET Hispano VAN sobre MVC Turbine

Friday, March 19th, 2010

La gente de la comunidad ALT.NET Hispano sigue preparando eventos. Gracias a su inicitiavi, se han realizado ya varias VANs (DesConferencias virtuales). La próxima es mañana, Sábado 20 de Marzo, a la hora habitual 18 GMT (3 de la tarde acá en Buenos Aires). El bueno de Cristian Prieto (@cprieto) explica el tema en la lista de grupo, y cómo invitó al creador del proyecto MVC Turbine:

De varias semanas para acá he estado conversando con Javier Lozano, creeador de Mvc Turbine y conocido ASP.NET Insider, no sólo le gustó la idea de darnos una VAN acerca de su proyecto MvcTurbine (personalmente una de las mejores opciones para crear futuras aplicaciones composite en ASP.NET MVC.

Javier ha decidido nombrar su VAN "Hablando MVC con Turbine", un poco acerca de la biografía de Javier (en inglés, sorry! el me la pasó!)

"Javier is an ASP.NET Insider and MVP that specializes in ASP.NET, system architecture, and training. He has helped co-found the Iowa .NET Users Group as well as the Iowa Code Camp.

On his blog, http://blog.lozanotek.com, you can find posts on ASP.NET, Silverlight, architecture, and design patterns just to name a few topics. Javier is an avid supporter of the community and likes to give back by speaking at user groups, local/regional .NET events, participating in forums, and by writing articles. In his spare time, Javier loves spending time with his family and enjoys writing about himself in the third person."

Pueden leer un poco más acerca de Turbine en el blog de Javier http://lozanotek.com/blog/archive/2010/02/05/mvc_turbine_v2.0_for_mvc2_rc2_.net3.5.aspx

Pueden seguir a Javier Lozano en @jglozano.

El bueno de Jorge Gamba (@jorgegamba) publicó más detalles en su post:

Extensibilidad y Composición en para tus aplicaciones ASP.NET MVC con MVC Turbine

Leo ahí:

MVC Turbine es un plugin para desarrollar aplicaciones ASP.NET MVC compuestas y extensibles. Normalmente para lograr esto, recurrimos a algún contenedor IoC para inyectar dependencias en nuestros controladores, filtros de acciones, módulos, etc. toda esa configuración y ajustes no son muy difíciles de lograr, pero uno tal vez quisiera que una herramienta se encargara de estos asuntos permitiéndonos despreocuparnos de esos detalles del cómo implementamos nuestra aplicación para concentrarnos en lo que realmente nos debe importar, el qué debería hacer nuestra aplicación, bueno, pues eso es precisamente lo que logra MVC Turbine y veremos en la VAN.

Algunos enlaces a material de lectura (en Inglés) que les pueden resultar útiles para consultar antes de la VAN son estos:

Más información sobre cómo asistir a la reunión virtual, software necesario, enlaces: http://altnet-hispano.pbworks.com/Descripcion-de-Reuniones

El enlace para entrar a la reunión es http://snipr.com/virtualaltnet

Como aclara el bueno de Jorge:

Hay que aclarar que no se requiere ningún tipo de registro, simplemente acudir el día y la hora indicados a la dirección Web http://snipr.com/virtualaltnet, eso sí, deberán tener instalado el programa cliente de Live Meeting; hay más instrucciones sobre cómo hacer esto y otras indicaciones en la página wiki Descripción de Reuniones. Adicionalmente les recomendamos comprobar la hora correspondiente para su localidad, esto lo pueden hacer con la ayuda de la página Historial de Reuniones y nuestro Calendario de Reuniones, al cual se pueden suscribir

Hay un grupo de Google, recién creado, dedicado MVC Turbine:

http://groups.google.com/group/mvcturbine?pli=1

Un interesante post mostrando hacia donde apunta MVC Turbine:

Why MVC Turbine? 

Algo más en

MVC Turbine Redux

Gracias a la comunidad por prepararnos estas VANs!

Nos leemos!

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

Modelos para Generación de Código en AjGenesis

Friday, March 12th, 2010

Quisiera hoy enumerar y pasar una corta revista a las opciones que tenemos para escribir, describir un modelo en  AjGenesis, mi proyecto open source de generación de códgio.

Una de las ideas básicas de AjGenesis es tener un modelo de libre definición, como punto de partida. No es un modelo fijo. ¿Qué significa esto? Que podemos crear y usar nuestro propio modelo. Veamos un ejemplo concreto. Si quisiéramos modelar una clásica aplicación "Hello, World”, podemos comenzar escribiendo un modelo simple como el siguiente:

<Project Company="ajlopez.com">
   <Message>Hello, World</Message>
</Project>

Y si queremos tener múltiples mensajes, lo extendemos en cualquier momento a:

<Project>
    <Messages>
        <Message>Hello, World One</Message>
        <Message>Hello, World Two</Message>
        <Message>Hello, World Three</Message>
    </Messages>
</Project>

Más información sobre este ejemplo sencillo en A Hello World Application in AjGenesis. (Generando Código: Hello World con AjGenesis).

Pero XML no sólo una de las versiones SERIALIZADAS de un modelo (el modelo es abstracto, AjGenesis lo maneja en memoria, y lo recupera desde donde lo digamos, en las primeras versiones, sólo de XML). En la versión del trunk podemos escribir y usar el modelo serializado como texto:

Project
    Messages
        Message = "Hello, World One"
        Message = "Hello, World Two"
        Message = "Hello, World Three"
    End Messages
End Project

Más información sobre modelos textuales en

Textual Model for Code Generation in AjGenesis

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

Si queremos describir una Entidad en una especie de modelo de dominio, podemos escribir algo como este XML de libre formato:

<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>
<Entity>
    <Name>Employee</Name>
    <Description>Employee</Description>
    <SetName>Employees</SetName>
    <Descriptor>Employee</Descriptor>
    <SetDescriptor>Employees</SetDescriptor>
    <SqlTable>employees</SqlTable>
    <Properties>
        <Property>
            <Name>Id</Name>
            <Description>Id</Description>
            <Type>Id</Type>
            <SqlType>int</SqlType>
        </Property>
        <Property>
            <Name>EmployeeCode</Name>
            <Description>Code</Description>
            <Type>Text</Type>
            <SqlType>varchar(20)</SqlType>
        </Property>
        <Property>
            <Name>LastName</Name>
            <Description>Last Name</Description>
            <Type>Text</Type>
            <SqlType>varchar(100)</SqlType>
        </Property>
        <Property>
            <Name>FirstName</Name>
            <Description>First Name</Description>
            <Type>Text</Type>
            <SqlType>varchar(100)</SqlType>
        </Property>
        <Property>
            <Name>IdDepartment</Name>
            <Description>Department</Description>
            <Type>IdRef</Type>
            <SqlType>int</SqlType>
            <Reference>Department</Reference>
        </Property>
    </Properties>
</Entity>

Más detalles del uso de un modelo como éste en Application Generation using AjGenesis. (Generando aplicaciones con AjGenesis).

Pero si leer XML nos hace doler los ojos, podemos volver a escribir el mismo modelo en forma textual. El ejemplo de arriba, abreviado:

Entity Employee
    Description = "Employee"
    SetName = "Employees"
    ...
    Properties
        Property Id
            ...
        End Property
            ...
        Property Name
        End Property
    End Properties
End Entity

 

No lo implementé, pero quiero agregar hojas de cálculo como modelos:

Escribí sobre eso en: Another Model for AjGenesis (Otro modelo para AjGenesis).

Pero a veces, queremos usar algo ya existente como fuente de nuestro modelo. Y con AjGenesis, podemos! Una de las más “populares” fuentes de seudo-modelos es la base de datos misma. En mi opinión, la base de datos no es el modelo ideal, pero, dependiendo del proyecto y de nuestras necesidades, puede ser una solución pragmática (recordemos, AjGenesis y generación de código son soluciones pragmáticas a algunos problemas en el desarrollo de software), así que no dudemos en adoptar fuentes convenientes, sólo hay que estar advertidos de sus limitaciones.

Escribi algún ejemplo en: Generating a Model From the Database Using AjGenesis (Generando un modelo desde la base de datos usando AjGenesis) y en AjGenesis: Generating the Model from the Database (AjGenesis: Modelo desde la base de datos).

AjGenesis nació y fue diseñado para sobrevivir al “fashion development”: no está orientado a una tecnología en particular, a una plataforma, framework, lenguaje determinado. Puede generar cualquier cosa que se un artefacto de texto (y yo diría que más): Java, C#, VB.NET, PHP, archivos de configuración, XML, scripts de base de datos, aún COBOL. Podemos escribir tareas, plantillas y lo que queramos generar, en cualquier momento. Podemos empezar en pequeño, e ir creciendo, agregando más abstraciones y transformaciones. Pero tareas y templates son temas que merecen otro post. Dicho esto, podemos usar como modelo un proyecto complilado. Como ejemplo, escribí sobre el trabajo de Dario Quintana usando .NET y Reflection en at:

AjGenesis: Generating the model from assemblies

AjGenesis: Modelo generado desde los assemblies

En el mundo Java, se acostumbra a generar código desde anotaciones en el propio código (mencionaría como ejemplo al venerable XDocLet). O desde archivos de configuración, la gente de Hibernate tiene hbm2java. NHibernate, la más popular librería open source de Object Relational Mapping en el mundo .NET, no tiene esas herramientas. Como en Java, AjGenesis puede usar los tags meta que se agregab a los archivos de mapeo .hbm, para usarlos en la generación de código. Vean:

Generating Code with AjGenesis using NHibernate Hbm Mapping Files

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

(Tengo un ejemplo más completo en el trunk actual, que genera una solución completa en ASP.NET y NHibernate).

Pueden bajarse el proyecto desde el trunk de código en:

http://www.codeplex.com/ajgenesis

Próximos tópicos: tareas, plantillas, abstracciones vs “technicalities”, modelos en memoria, transformaciones modelo a modelo, completando el modelo, tomando decisiones, sistemas expertos e inteligencia artificial aplicada a la generación de código y AjGenesis.

Nos leemos!

Angel "Java" Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

Hacia un Hospital Information System de Código Abierto

Thursday, January 14th, 2010

Gracias a todos los que comentaron mi anterior post:

Hacia una Historia Clínica Digital de código abierto

Ha sido uno de los post que más comentarios ha recibido últimamente. Y me ha servido de mucho la información y los enlaces que me han pasado.

Desde entonces, he seguido investigando las ofertas de código abierto (y algunas comerciales) de sistemas relacionados con salud. Como comentaba ahí, una forma de que se adopte un sistema nuevo de código abierto, es que comience ha ser utilizado en algún caso real. En este tema, el target a alcanzar, en primer lugar, son clínicas, pequeñas instituciones, que no tengan el presupuesto para alcanzar a comprar un sistema comercial más caro. También ese tipo de target, sirve para ir probando en escala mediana el funcionamiento de un sistema.

Pero no quisiera que la primera implementación fuera para una institución en particular. El hacer un software sin cliente final, es un problema. Pero también es hacerlo para un cliente particular, porque es difícil armar el sistema manteniendo una claridad y flexibilidad que perdure, y que no se vea percutido por decisiones de diseño para satisfacer las necesidades inmediatas de un cliente. Es posible, pero he visto pocos casos de éxito siguiendo ese camino. Se puede hacer un núcleo, una prueba de concepto, sin tener un cliente final, y luego, una vez armado ese núcleo, simplísimo, ver de extenderlo, modificarlo (en poco o en mucho), ponerlo a prueba, cuando se llegue a un cliente real. En este caso, en este proyecto, preferiría un Fresh Start, y por un tiempo, basarse en lo que ya está publicado en otros sistemas.

Uno de los enlaces que mencionaba en mi anterior post era:

List of Open Source Healthcare Software

Ahí encontré la denominación

Hospital Information System

He ido coleccionado enlaces sobre salud (y sistemas de salud) en:

http://delicious.com/ajlopez/health
http://delicious.com/ajlopez/medicine

Ahí guardé varios enlaces a sistemas HIS (Hospital Information System) de código abierto, y dos o tres comerciales, así como ha sitios de información sobre medicamentos, drogas, contraindicaciones, etc… Una lista interesante es:

Hospital Information Systems (HIS): Commercial, free and open source list

como para tener una lista inicial referentes de la oferta actual. Por ahora, estuve viendo el gran trabajo de la gente de:

http://www.care2x.org/

Care2x integrates data, functions and workflows in a healthcare environment. It is currently composed of four major components. Each of these components can also function individually.

  • HIS – Hospital/Healthservice Information System
  • PM – Practice (GP) management
  • CDS – Central Data Server
  • HXP – Health Xchange Protocol

Our Mission

We strive to develop the most useful and practical integrated healthcare information system which is open for others to develop further.

The "Team"

The development team has currently more than 100 members with different skills and backgrounds. They come from more than 20 nations.

Me parece interesante el desarrollo de un HIS, porque:

  • No es trivial
  • Tiene desafíos de extensibilidad
  • Hay un mercado vertical ya existente
  • Hay referentes, contra los cuales medirse
  • Gran parte se podría ofrecer como SaaS (Software as a Service)

Por supuesto, un HIS completo es un trabajo de mucha gente, como demuestra el Care2x de arriba. Pero creo que puedo escribir por lo menos un núcleo, que considere las entidades más importantes, como pacientes, profesionales médicos, entidades financiadoras (Obras sociales, medicina prepaga), drogas y medicamentos, turnos, tratamiento ambulatorio, no sé si internación.

Las tecnologías candidatas que podría usar para encarar una prueba de concepto, son: WinForm, ASP.NET MVC, C#, SQL Server (he visto mucho hecho en Java, PHP y otras, pero no he encontrado tanto en .NET open source, igual tengo que seguir revisando enlaces). Me gustaría aplicar, por un lado, generación de código, y por otro, TDD, si fuera posible. Dejar abierto, en cuanto fuera posible, el consumo del sistema desde otras tecnologías Front End. El dominio en POCO (Plain Old CLR Objects), con lo que no usaría LINQ2Sql o Entity Framework en principio (sé que hay soporte para POCO en EF, pero es un Work In Progress, no quisiera sumar más complejidad a algo que ya es complejo). Podría usar un ORM, pero quiero explorar el camino de ORM por código propio: escribir el mapeo generando código automático para las entidades que vayan surgiendo, con manejo de Lazy Load, y Cache… Pero son ideas técnicas. Lo importante es comenzar con algo, que vaya tomando forma.

Primer candidato a sistema a implementar: un sistema de turnos.

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
http://www.msmvps.com/lopez
http://ajlopez.wordpress.com
http://ajlopez.zoomblog.com

Refactoreando AjLisp: un intérprete Lisp escrito en C#

Sunday, January 10th, 2010

En estos días estuve reimplementando el núcleo de mi intérprete Lisp de código abierto AjLisp. Había escrito sobre la anterior versión en el 2008:

AjLisp: a Lisp interpreter in .NET
AjLisp: un intérprete Lisp en .NET

Es trabajo en progreso. Pueden bajar el código de:

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

(hay otras dos implementaciones en ese repositorio, en desarrollo: AjScheme, un Lisp tipo Scheme, y AjSharpure, que intenta seguir las ideas de Clojure). Debería escribir sobre esas implementaciones. Este post es el inicial en una serie sobre AjLisp. Es una corta introducción al estado actual del proyecto.

El principal cambio en esta nueva versión: el intérprete puede manejar objetos y valores nativos. La alternativa hubiera sido apuntar a esos objetos a través de “wrappers”, alguna clase que implemente SymbolicExpression o similar. Pero elegí manejar directamente objetos nativos. Para eso, cambié las primitivas y clases relacionadas para que recibieran como argumentos objetos en vez de IExpression. Sigue habiendo una interfaz IExpression, defined como:

    public interface IExpression
    {
        object Evaluate(ValueEnvironment environment);
    }

El ValueEnvironment (planeo cambiarle el nombre a BindingEnvironment, y derivarlo de alguna interfaz tipo IBindingEnvironment) mantiene una asociación anidada de nombres y valores:

Hay un interfaz IFunction:

    public interface IFunction
    {
        object Apply(List arguments, ValueEnvironment environment);
    }

que debería ser implementada por cualquier form expression (la cabeza de una lista a evaluar).

Las dos clases principales que representan los tipos núcleo del AjLisp son identificadores y listas:

Todo el proyecto fue armado siguiendo Test-Driven Development, así que no tuve problemas en cambiar la versión anterior: tenía toda una batería de tests que me ayudó en el proceso de refactoring. Este es el estado actual de los test:

Debería escribir sobre:

– La implementación de ValueEnvironment

– Manejo de objetos nativos

– El tipo List y su evaluación

– Evaluación de Identifier

– Las primitivas implementadas

– El Lexer y el Parser

– Operaciones numéricas

– Números racionales (AjLisp puede manejar pares enteros numerador/denominador)

Ahora, luego de lo que aprendí desarrollando estos proyectos (AjLisp, AjScheme, AjSharpure), estoy escribiendo un núcleo mínimo AjCoreLisp, para mostrar cuáles son las primitivas mínimas para crear un intérprete Lisp. Armado con esa implementación, me gustaría explorar alternativas de compilación, en vez de ser sólo intérprete. Mi primer candidato es Dynamic Language Runtime. Otro podría ser la producción de código C# directo. Sería demasiado encarar esa exploración sobre un intérprete “más grande”. Primero, entonces, estudiaré sobre compilar un intérprete con menos primitivas, más condensado.

Nos leemos!

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

AjSharp: objetos y clases dinámicas

Sunday, December 27th, 2009

Estoy escribiendo un intérprete no tipado con sintaxis tipo C#, que bauticé AjSharp. Hace un tiempo escribí sobre este proyecto de código abierto en:

AjSharp Programming Language a C#-like Dynamic Language
AjSharp: un lenguaje dinámico en C#

Pueden bajarse la versión actual desde http://code.google.com/p/ajcodekatas en trunk/AjLanguage (AjLanguage define el árbol de ejecución del intérprete, AjSharp tiene un parser, un lenguaje definido para construir ese árbol; la idea es colocar otros parsers sobre AjLanguage, por ejemplo, AjBasic).

Ayer sábado, agregué una nueva característica, la definición de un objecto. Ya de antes, AjSharp soporta la definición de una clase dinámica:

class Person
{
  var Name;
  var Age;
  
  function AddYears(years) 
  {
    this.Age = this.Age + years;
  }
}

Pueden crear un objecto usando:

adam = new Person();
adam.AddYears(800);
adam.Name = "Adam";

El objeto creado es dinámico: se le pueden agregar variables de instancias y métodos, en cualquier momento:

adam.LastName = "unknown";
adam.EyeColor = "brown";
adam.SayHello = function() { PrintLine("Hello"); };

Pueden crear objetos, con esta notación, inicializando su estado:

adam = new Person() { FirstName = “Adam”, LastName = “Genesis”, Age = 800 };

Y hasta pueden definir un objeto sin tener una clase asociada:

dynobj = new { Name = “Adam”, Age = 800 };

Esto es equivalente a hacerlo más “programáticamente” así:

dynobj = new DynamicObject();
dynobj.FirstName = “Adam”;
dynobj.LastName = "Genesis”;
dynobj.Age = 800;
dynobj.FullName = function() { return FirstName + “ “ + LastName; }

Esto estaba implementado desde hace meses. Ayer agregué la notación:

object Adam
{
  var Name = "Adam";
  var Age = 700;
  
  function AddYears(years) 
  {
    this.Age = this.Age + years;
  }
}
Adam.AddYears(100);

donde se puede definir un objecto único, dándole estructura, conducta y nombre.

La idea de AjLanguage es que pueda acceder a todas las clases y objetos del framework subyacente (en este caso, .NET, pero está pensado para ser reescribible sobre Java, si fuera necesario, claro, cambiando cualquier referencia a tipos nativos):

ds = new System.Data.DataSet();
dinfo = new System.IO.DirectoryInfo(“.”);
foreach (fi in dinfo.GetFiles())
{
    PrintLine(fi.FullName);
}

Desde ayer, seguí implementando constructores. Tengo pensado definir visibilidades privadas y públicas (por ejemplo, las variables y métodos de instancia que comiencen con minúscula, hacerlas automáticamente privadas). También agregar propotipos, como en Javascript, lo que permitiría implementar cosas similares a los métodos de extensión de .NET.

Pero si van hoy al trunk, encontrarán que estuve implementando canales, como en en lenguaje Go de Google.

channel = new Channel();
go for (k=1; k<=5; k++) channel <- k;
for (j=1; j<=5; j++)
	result = result + <-channel;

Pero eso dará para otro post más detallado. Con esa característica quiero explorar temas como programación reactiva, agentes, actores, shared transactional memory, ver:

http://clojure.org/Agents

http://en.wikipedia.org/wiki/Actor_model

http://en.wikipedia.org/wiki/Axum_%28programming_language%29

Por ejemplo, sería interesante que los canales comunicaran no sólo dos códigos en paralelos, sino máquinas diferentes. Y definir esas máquinas en tiempo de deployment, sin cambiar el código del programa. Podría reescribir los ejemplos de Distributed Agents using DSS/VPL Genetic Algorithms with AjAgents and Concurrency and Coordination Runtime (CCR)

Como verán, me estoy divirtiendo!

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

Hacia una Historia Clínica Digital de Código Abierto

Tuesday, September 29th, 2009

Ya desde hace un tiempo, estoy pensando en qué aplicaciones se podrían desarrollar en código abierto. La que estoy encarando personalmente, es en mejorar AjContab, un sistema de “General Ledger” dirían los americanos, sistema contable simple, abandonando mi viejo ejemplo en .NET, escribiéndola primero en PHP, y luego, ir investigando otras formas de implementarla, en Java o en .NET.

Pero también pienso en sistemas más grandes. Uno de los que vuelve y vuelve a mi mente, al leer artículos, repasar libros, y ver lo que hay por ahí, es el de Historia Clínica Digital. Quisiera pasar en limpio acá algunas cosas que estoy investigando y pensando sobre el tema.

Algunos puntos:

  • Es un sistema no trivial e interesante
  • Se puede implementar con una interfaz web, e ir pensando en otras interfaces
  • Podemos aprovechar Java o .NET, como tecnologías maduras
  • La aparición de tecnologías de apoyo a Rich Internet Application, como Silverlight, Adobe Air, permiten pensar en una interfaz que pueda evolucionar a más requerimientos de presentación, si es que la interfaz web resulta limitada para algunos requerimientos
  • Las primeras versiones deberían concentrarse en las prácticas directas, del día a día, más que en la legislación de un país. Buscaría un cliente particular, una clínica, para servir como experto del dominio, y primer usuario que brinde retroalimentación
  • Integraría el papel: muchas de las historias clínicas hoy se llevan en papel, no deberíamos ignorar ese hecho al armar este sistema. Deberíamos poder agregar información simplemente escaneada (con reconocimiento de a texto o no). En un principio, hasta que no se implemente legislaciones en firme, debemos recordar que la historia clínica en papel, o partes de ella, tienen alguna responsabilidad legal. Vería que las primeras implementaciones, sólo se ocupen de facilitar la recuperación, consulta, de la “historia médica real”, la de papel.
  • Deberíamos buscar el apoyo de empresas, como IBM, Oracle, Sun y/o Microsoft, para tener a este proyecto como “flag ship”, producto bandera para incorporar en el mercado vertical de aplicaciones médicas
  • El mundo de las aplicaciones médicas está en permanente evolución
  • Es un sistema lo bastante no trivial para que deba ser el producto del trabajo de varios, más que de una sola empresa de desarrollo
  • Servicios como firma digital, pueden implementarse en cualquier momento, no necesariamente lo pondría en los primeros requerimientos.
  • Tanto firma digital, como seguridad de acceso, se puede ir implementando como servicios a enchufar, que pueden variar de implementación concreta a otra
  • La historia clínica gana en prestaciones, si es compartida (con toda la seguridad) en “la nube”: la persona debería poder permitir el acceso a la historia clínica personal a los distintos profesionales médicos, sin necesidad de ir recolectando información que dejó en tal consultorio, en tal hospital, en tal internación. De ahí, que imagino que el éxito del proyecto, se mediría con un servicio en línea, tipo Software as a Service
  • Otro camino para “crossing the chasm”, sería brindar el servicio para que la propia persona interesada, el “paciente”, vaya registrando su historia clínica, o lo que quiera ingresar de la misma.
  • Como dije arriba, los “early adopter” deberían ser clínicas, no gobiernos. Convencer a un gobierno de usar algo, por lo menos, por estos lares, es tarea digna de las de Hércules.
  • Luego, el próximo nivel a explorar, serían las obras sociales, servicios de medicina prepaga (no sé cuál es la denominación de estas organizaciones en otros países, fuera del mío, Argentina).
  • Una forma a implementar privacidad, es, en una primera implementación inicial, no dejar ningún dato que identifique al paciente, asegurando privacidad por faltar esa información (ejemplo, tener un código que conozca sólo la persona interesada).
  • Se debe producir un resultado visible, más que esperar años para que los usuarios puedan ver algo andando. Es un tema de adopción temprana: no preocuparse tanto por temas de legislación, gobierno, leyes, firma digital, sino de que sirva a los usuarios finales. Hoy podemos construir sistemas de forma ágil, de tal forma que, si el sistema fracasa, no habremos invertido demasiado esfuerzo. Si triunfa, podemos ir armándolo de forma flexible, para que sobreviva a cambios en la legislación, imposición de formatos nuevos, etc.
  • Habrá que ir pensando en HL7 (Health Level 7), ver IHE (Integrating the Healthcare Enterprise) más que para implementarlos, ver qué temas ocupan, y tenerlos en cuenta y estudiar cuánto influyen en los desarrollos de países que no son EE.UU. Y en sistemas de imágenes como DICOM. Este último es un formato de imágenes producido por varios aparatos médicos, con anotaciones agregadas. ¿conocen algún otro estándar de ese tipo?
  • Tendría que estudiar Open Healthcare Framework (OHF) Project de Eclipse, y el Microsoft Health Common User Interface. Microsoft también tiene Microsoft Health Users Group. Para estudiar: Microsoft for the Health Industry. Por su parte, IBM tiene Healthcare and life science. Y en Oracle Healthcare Applications.
  • Otro que parece interesante es el Open Source Clinical Image and Object Management.
  • Encuentro una lista extensa de código abierto para salud: List of Open Source Healthcare Software, en Wikipedia.
  • Y hay una Open Source Health Care Alliance, aunque parece que el último congreso que tuvieron fue en 2007.
  • Es interesante la ontología y terminología que plantea OpenGalen.

¿Conocen ejemplos de proyectos de código abierto, que hayan encarado este tema, el de la historia clínica digital? He visto por ahí, al Proyecto Angel (no, a pesar del nombre, no tengo nada que ver con el mismo…:-)… en todo caso, se hubiera llamado AjAngel… :-), creo haber leído que era de código abierto, pero no encontré ninguna información cierta al respecto, y no veo donde bajarlo, ni que licencia tiene.

Pueden ver algunos enlaces sobre el tema historia clínica y sobre historia clínica digital, en:

http://delicious.com/ajlopez/medicalrecord

Sobre temas de medicina a encarar en este proyecto:

http://delicious.com/ajlopez/hl7
http://delicious.com/ajlopez/dicom

Tengo entre manos, terminar AjSharpure (con post explicativos) y seguir con AjContab, publicando algo (con post explicativos). Pero podría armar alguna prueba de concepto, algún prototipo, de lo que esperaría de un sistema como éste. Otra opción, es ir armando un pequeño sistema a adoptar por las clínicas, como “caballo de troya” benigno. El más potable, me parece, sería un sistema de turnos, que puede brindarse también como Software as a Service, o instalarse local en la empresa.

¿Qué les parece? ¿Es factible? ¿O tengo que ir abriendo mi propia historia clínica psiquiátrica? 🙂 🙂

Nos leemos!

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

Proyecto Colaborativo en ALT.NET Hispano

Saturday, August 15th, 2009

Va tomando cuerpo la propuesta lanzada por Alberto Arroyo en el grupo ALT.NET Hispano, de formar una alianza, para producir una aplicación. Algo había comentado en este post:

Proyecto, producto, empresa

Se realizó una reunión virtual el sábado pasado, pueden leer un resumen de las conclusiones, y ver el video de toda la reunión, en:

http://altnet-hispano.pbworks.com/altnetcafe-2008-08-08#

Una sugerencia: se podría armar alguna encuesta para los que no asistimos a las reuniones? No sabía que iba a haber encuesta en la misma reunión, pensé que se iba a discutir decisiones también por otros medios.

Pueden asistir a la segunda reunión, hoy sábado, a las 18hs GMT (en Argentina, que tiene huso GMT-3) son 15hs. Pueden ver más detalles en la portada de:

http://altnet-hispano.pbworks.com/

donde se describen cómo son las reuniones VAN y qué software se necesita para participar.

En la reunión pasada (a la que no pude asistir), presentó su propuesta Alberto Arroyo, basado en lo que ya ha estado armando para Codesol:

http://www.codesol.info

Hubo un momento en que los participantes se inclinaron por desarrollar un CMS (Content Management System):

Mi opinión: el mundo no necesita un CMS más. Creo que el mercado ya está saturado de ese tipo de aplicaciones.

Algo parecido planteó Daniel (perdón, no tengo el nombre completo): de esos proyectos hay un montón.

Lo que puede servir es como proyecto de entrenamiento del grupo. Yo ahí disiento: prefiero que si el proyecto final será un CRM, entonces, hay que comenzar con algo chico, pero relacionado con CRM. Si se comienza con un CMS como entrenamiento, veo mejor que el primer proyecto, sea ya orientado al proyecto final.

Es interesante que Alberto Arroyo mencionó el caso del framework CSLA como ejemplo de proyecto colaborativo pero que ha generado un “mundillo” alrededor, de desarrollo, de empresas que lo usan. Alberto dejó en claro que quiere plantear un producto X que genere dinero. Tal vez, lo que veo que enturbia un poco esa visión, es que también Alberto menciona un asociación para “validar” el software de código abierto. Creo que ese es un proyecto interesante, pero no sé si necesario, y que dejaría de lado en esta discusión.

En otro momento, se discutió cómo generar ingresos desde un proyecto open source que, por ejemplo, implemente un CRM. Creo que fue Alberto Arroyo @beyondnet el que comentó el tener un núcleo open source y que luego se puede extender y adaptar a cada país, y ahí vendría la ganancia: cada empresa que lo extienda para su mercado, tendría ingresos del proyecto original.

Lo que yo veo de inconveniente es esto: ese modelo no genera ingresos para los que participan del proyecto, pero no montan una empresa o no tienen un mercado adecuado o las inclinaciones y capacidades comerciales para llevar adelante esa extensión y conseguir ingresos. El “cada quien haga su propio negocio” no me cierra como modelo. Eso lo he visto en otros proyectos de código abierto: lo que pasa, es que sólo algunos de los participantes pueden conseguir ingresos de esa forma.

Si la idea es

contribuir a la comunidad Y ganar dinero

, eso de tener un core, y luego que cada cual consiga dinero sobre eso, se va a derivar en

contribuir a la comunidad

lo que me parece magnifíco, y

Y ALGUNOS ganaran dinero

A lo cual no veo gran problema, es lo que pasa todos los días, con muchos productos de código abierto, pero me parece que hay un camino mejor.

Mi propuesta es: hay un “core” de participantes del proyecto, dedicados ya sea a diseño, desarrollo, documentación, difusión, entrenamiento, etc… Cuando alguno de esos participantes genere ingresos con el producto/proyecto, podría aportar una parte a un fondo común del proyecto. Se puede discutir el reparto entre los participantes.

Se mencionó el problema legal (disculpen, no tengo el nombre de quien puso en la discusión el tema, creo que es de México, nombre Daniel?): no veo que haya problema. Cada uno de los participantes puede facturar desde su empresa o como individuo, pero aportar a un fondo común a repartir, con facturación entre los miembros.

Alberto mencionó que no le gustaría que alguna empresa tome el producto a desarrollar, lo nombre a su manera, y prefiere una licencia “más compacta” que la GPL. A mí tanto no me preocupa ese caso. Si el producto, y el grupo que lo forma, es fuerte, no tendría que preocuparse de los forks comerciales o no. Es parte del juego: el grupo inicial tiene que luchar siempre por la colina, y me parece bien. La fortaleza vendrá de la popularidad y reconocimiento del proyecto inicial en la comunidad y ámbito empresario, y por el soporte del grupo núcleo, más que por la licencia a usar.

No veo problema en que el proyecto a producir sea de código abierto, y se piense en un mercado comercial, con ingresos. En mi anterior post, puse como caso paradigmático a JBoss. Podría apuntar otro, que se mencionó en la reunión VAN, como el Compiere. Vean cómo el modelo de este último, permitió tener un producto con un mercado. No hizo falta una asociación aparte para validarla, Compiere es fuerte por lo que brinda. Lo mismo pasó con JBoss, MySql, Mono, etc. Y yo podría hacer un fork de Compiere, cambiarle el nombre, y eso no afecta la fortaleza del proyecto inicial.

Las debilidades, pienso, vienen por otro lado:

– La falta de objetivo claro (idea, producto, mercado, estilos de llevarlo a cabo…)

– La formación de un equipo nuevo

Me pareció interesante, lo que mencionó Jorge, creo: sobre que al principio se apuntan 15 y luego trabajan 5. Eso siempre pasa. El tema, como dice Jorge, es que el núcleo inicial perservere.

Pero independientemente de todo esto, lo interesante y bueno es ver que estando dispersos, podemos ir coordinando algo. La tierra es plana, más para nosotros, los desarrolladores de software.

Nos leemos!

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

Proyecto, producto, empresa

Tuesday, August 4th, 2009

En la lista de ALT.NET hispano, se planteó una interesante discusión:

[altnet-hispano] Re: ¿Porqué no formar una alianza, un equipo?

Partió de una propuesta de Alberto Arroyo (@BeyondNet en Twitter)

Para los que aún no he tenido la oportunidad de conocer me presento. Mi Nombre es Alberto Arroyo Raygada, soy natural de Perú, profesional
en Tecnologías de la Información y fiel seguidor  de las alternativas abiertas de software. Actualmente vengo promoviendo y apoyando algunas comunidades de software como son www.cslanet.org y www.codesol.info. Mi nickname es BeyondNet.

La propuesta:

…siempre he tenido el interes y las ganas de poder desarrollar un producto de software con un esquema de licencia OSI, ¿Porqué OSI?, pues por la posibilidad de variantes que da el software abierto.

Si miramos un poco el mercado, en este momento se han marcado mucho más los diferentes  perfiles comerciales de las empresas que han
madurado productos de software abiertos orientados a diferentes especialidades como por ejemplo: OpenBravo, MySQL, Mono Project, Distribuciones Linux, etc, etc. La lista es grande, pero  la idea es la misma “PRODUCIR Y GENERAR INGRESOS”.

Ese un tema. Yo mencioné que una cosa es hacer un proyecto de código abierto, y otra es hacerlo con la idea de producir ingresos:

a) O hacemos un proyecto de codigo abierto, como otros

b) O hacemos un proyecto de codigo abierto que, desde el vamos, apunte a formar una empresa, movimiento, lo que quieran, que beneficie a los
que participen activamente, en la actividad que sea que aporten.

En el primer caso, podemos tener como ejemplo a NHibernate, excelente proyecto de codigo abierto, vivo, que hace historia, pero en el que cada cual vive como puede.

En el segundo caso, veo como ejemplo a JBoss, que desde la vision de Marc Fleury, sobre un producto de codigo abierto, monto una empresa.

Quería explayarme un poco más, por acá. Pueden leer sobre Marc Fleury en:

http://en.wikipedia.org/wiki/Marc_Fleury

Marc’s research interest focused on middleware, and he started the JBoss project in 1999. JBoss Group, LLC was incorporated in 2001 in Atlanta, Georgia. JBoss became a corporation under the name JBoss, Inc. in 2004.

Pueden leer su blog (escrito con su esposa) en:

Maison Fleury

Volviendo al tema. Una cosa es hacer un proyecto de código abierto. Tenemos varios ejemplos, y muchos de nosotros los usamos día a día. Mencionaba como caso paradigmático, el NHibernate. Podría mencionar también Hibernate (curiosamente ambos quedaron con el tiempo, bajo el paraguas de JBoss). A partir de una idea, un grupo reducido de desarrolladores crea una herramienta excelente, usando por miles de desarrolladores. Pero no se producen ingresos directos para esos desarrolladores (y otros colaboradores, no todo es codificar). Y faltan cosas para hacerlo un producto.

Un producto, me imagino, tiene documentación completa, soporte organizado, presentación para un mercado, cursos y difusión, capacitación ya empaquetada, es algo más que un proyecto.

Pero tanto proyecto como producto, no bastan para lo que yo apunto. Un producto no genera ingresos. Lo genera el mercado, un mercado de clientes, que no buscan un producto, buscan soluciones a problemas.

Veo en muchos emprendedores, que se enamoran de la “idea”, pero les falla ya ejecución: no la ponen nunca en marcha, o no logran plasmarla en producto. Luego, se puede caer en otra trampa: enamorarse del producto, y no ver que en realidad, lo que se vende, son soluciones a problemas. Y no logran llegar a identificar el mercado al que apuntan.

Pero Fleury, pienso, tuvo bastante en claro su camino desde el principio. Vió cómo el mercado iba a seguir a Sun (posiblemente, era una apuesta), en sus sugerencias de cómo implementar aplicaciones escalables, multiplataforma, y que en ese mercado iban a subirse empresas grandes. Sun armó la especificación EJB (Enterprise Java Beans), que, en mi opinión, es bastante horrible. Pero eso no importa ahora. Fleury vió que no tenía nada para ofrecer, pero tenía una idea distinta: en vez de producir un producto cerrado, iba a crear un producto de código abierto, el JBoss. Mientras que otras empresas luchaban por vender su servidor de J2EE, a miles de dólares, Fleury puso su marca en el mercado, simplemente dando a bajar al JBoss. Muchos pensaron que (como se dice acá en Argentina) “no le llegaba el agua al tanque”, o “no tenía todos los patitos en línea”, pero el que ríe último, ríe mejor, y Fleury y cía. se posicionaron como líder en un mercado difícil, y hoy es, prácticamente, el rey de la colina.

Pero desde el principio, él montó todo como una empresa. Antes de comenzar a codificarlo, visitó gente con su plan de negocios. No era un proyecto de código abierto más. JBoss, el producto, sirvió como cabeza de playa, como producto bandera, para crear y sostener la empresa. JBoss, la empresa, se posicionó como proveedora de soluciones, capacitación, asesoramiento, y otros productos.

Yo pienso que es hoy la forma de armar una empresa. Ya no está el “filón” en tener un producto cerrado, sino en abrirlo, formar comunidad, y tener claro qué problemas soluciona, y posicionarse en esa colina, como proveedor de soluciones. Si otros también usan el producto de código abierto para hacer sus ingresos, de alguna forma, eso valida nuestra posición en el mercado, y nos da más fuerza y valor.

¿Qué opinan de la propuesta de Arroyo? ¿y de la discusión que se armó? Pueden participar en la lista de correo, si quieren.

Nos leemos!

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

Recordando a Clipper

Monday, July 6th, 2009

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:

? "Hello World"

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