The @power of #{this.code}

Dart - El nuevo lenguaje de Google

2011-10-11T14:42:00.001-03:00

Google a dado a conocer su nuevo lenguaje de programación, "Dart".
Éste, tiene como objetivo el desarrollo de aplicaciones para la Web. Los cimientos sobre los que fue construido están basados en los siguientes puntos:

Crear un flexible pero estructurado lenguaje de programación para la Web.
Lograr que dar sea natural y familiar para los programados, que sea fácil de aprender.
Asegurar una performance a alta en todos los navegadores Web y distintos entornos desde dispositivos móviles hasta ejecución del lado del servidor.

A continuación, el link del anuncio en el Blog oficial de Google Code y el sitio oficial del Lenguaje para que se animen a probar.

Anuncio en el Blog de Google Code.

El sitio oficial de Dart

¿Qué es GWT?

2011-09-08T14:53:00.006-03:00

Después de un tiempo considerable sin escribir en el Blog, he vuelto para darle un poco mas vida a este espacio.
El tema que me trae a colación es GWT o también conocido como Google Web Toolkit.
GWT es un framework desarrollado por Google y con un gran aporte de la comunidad, nació por el año 2006 y hoy se encuentra muy estable y robusto en la versión 2.4.
Todo aquel que ha desarrollado sistemas web seguramente a lideado con un montón de tecnologías, por ejemplo: Javascript, HTML, CSS en la construcción de sus aplicaciones AJAX. Además, todos hemos sufrido el gran problema de lograr compatibilidad entre los navegadores.
GWT es un plataforma que tiene la capacidad de lograr aplicaciones AJAX compatibles con todos los navegadores del mercado incluyendo móviles y el lenguaje de programación que utilizaremos será JAVA.
Parece confuso, pero la premisa es sencilla, programamos en Java y el framework nos genera nuestra aplicación en javascript.

Para lograr esto, la plataforma en su arquitectura tiene que contemplar la emulación de la JRE, es obvio que no toda la JRE debe ser emulada porque nuestro target es restringido, recordemos que nuestra aplicación resultante se ejecutará en un navegador web.
A continuación les dejo un enlace con descripción de la referencia de la emulación de la JRE: http://code.google.com/intl/es-419/webtoolkit/doc/1.6/RefJreEmulation.html

Otro de los componentes importantes es el compilador, éste es el que hace realmente la magia, toma como entrada nuestro código escrito en Java y genera una salida ofuscada de javascript por cada navegador y si queremos soportar internacionalización se generará una salida por cada idioma soportado y por cada navegador. Cabe destacar que no todo el código es compilado, solo la parte de nuestra aplicación que pretendemos correr en el cliente. Esto es configurable a través de módulos en los proyectos de GWT.

GWT cuenta con un conjunto de APIs que nos permiten la creación de nuestras interfaces gráficas, comunicación con el servidor mediante JSON, XML y un protocolo propio de GWT denominado RPC, soporte de internacionalización, gestión del historial, implementación de patrones como Model View Presenter, soporte para lograr Data binding mediante un framework llamado Editor y mucho más.

La pregunta que ustedes se pueden hacer mientras están leyendo es: ¿Porqué tener que usar GWT, si yo con JavaScript lo puedo hacer? La respuesta viene de la mano de la optimización y de la productividad.
Optimización es porque el compilador de GWT generará una salida optimizada para cada navegador lo que nos permitirá lograr lo que se denomina perfect caching, además de que los recursos están totalmente optimizados, por ejemplo, empleando el uso de la técnica de sprites en las imágenes.

La productividad esta enfocada en el uso de un lenguaje fuertemente tipado. Cuando desarrollamos en javascript, un gran porcentaje de errores vienen de la mano de errores ortográficos y posiblemente de distracción. Estos errores solo son descubiertos en tiempo de ejecución por la misma naturaleza del lenguaje. En Java esto no pasa, todos nuestros errores serán descubiertos en tiempo de compilación, y al usar un IDE como eclipse o netbeans, el mismo IDE nos indica que estamos cometiendo un error, por ejemplo en alguna asignación de variable.

Como el tiempo de compilación en GWT es grande, la plataforma provee dos modos de ejecución: Development Mode y Production Mode.
El primero, será el modo en el que estaremos la mayor parte del tiempo, en este modo no necesitamos compilar, nuestra aplicación correrá sobre la JVM, eso quiere decir que el código a ejecutar será bytecode. Esto nos ahorra mucho tiempo, porque ante cada cambio en el código del cliente solo debemos precionar F5 en el navegador para visualizarlos.

En Development Mode la plataforma se comunica con los navegadores mediante una conexión TCP, lo único que se impone es que el navegador debe tener un plugin para lograr correr nuestra app en este modo.

La productividad también está garantizada por la velocidad de desarrollo; ¿Alguna vez imaginaron hacer un debug en javascript? Con gwt se puede hacer un debug de toda la aplicación, controlar las variables, sus estados, etc.
Otra ventaja sobre aplicaciones nativas en javascript, es la posibilidad de realizar unidades de test de nuestro código. Esto, sumado a lo anterior mencionado logra agilizar nuestro ciclo de desarrollo.

Production Mode es el modo en el cual correra nuestra aplicación en producción. Para esto es necesario compilarla, lo que generará los archivos necesarios para que esta pueda ser desplegada.

El mundo de GWT es muy grande para comentarlo solo en un post, pero la idea es que sepan que esta tecnología es impulsada por Google, tiene detrás una gran comunidad de usuarios y desarrolladores contribuyendo y que hoy en su versión 2.4 está capacitada para dar solución a desarrollos a gran escala y aplicaciones empresariales.

Hasta la próxima.

Frameworks y ontologías (Parte 2)

2009-01-21T18:38:00.000-02:00

Hace ya un tiempo que no me sentaba a escribir en el blog, la verdad que por motivos de tiempo, trabajo, etc. Pero era hora de que cumpla con lo prometido y termine la segunda entrega del tutorial de Ontologías, sin más preambulos aqui les va ...

Frameworks y Ontologías (Parte 2)

En la Parte 1 de este tutorial sobre tecnologías circundantes al desarrollo de aplicaciones basadas en Ontologías introdujimos una serie pequeña de conceptos teóricos sobre los distintos lenguajes que existen en el mercado actual, ejemplos de éstos son: RDF, RDF Schema, OWL Lite, OWL DL y por último OWL Full. Mencionamos las distintas herramientas que existen para la manipulación de éstos lenguajes: Jena, Pellet, OWL - API, etc.
Comenzamos con una Introducción a Jena, uno de los frameworks más utilizados, y listamos el conjunto de APIs que lo conforman.
Mencionamos como trata el polimorfismo en Java, y describimos algunos conceptos básicos del funcionamiento del framework.
En esta segunda parte seguiremos explorando Jena y como trata los modelos, nos centraremos en algunos ejemplos sencillos.
Veremos cómo poder cargar nuestras ontologías, como cargar modelos, como asociar uno u otro razonador, como persistir un modelo de ontologías y como cargarlo desde la base de datos.

Comenzaremos con lo básico, supongamos que contamos con nuestra ontología la cual está guardada en nuestro disco rígido en formato owl y queremos poder manipularla, ¿cómo hacemos?
Para dar respuesta a esto en primer lugar debemos contar con un entorno de desarrollo, en particular utilizo Netbeans para el desarrollo en java y el jdk 1.6.
Creamos un proyecto en el IDE, bajamos las librerías de Jena (en el caso que no las tengamos) y las adherimos al proyecto.

Para nuestro simple ejemplo vamos a definir la clase OntLoader de la siguiente manera:

Código

GeSHi (java):
public class OntLoader {
    private File file = null;
    private OntModel model = null;
    public OntLoader(File file) {
    java.io.InputStream input = null;
    try {
        this.file = file;
        //Creación del modelo, que contendrá la representación de la ontología
        model = ModelFactory.createOntologyModel(OntModelSpec.OWL_DL_MEM );
        //Este input es la ontología en formato owl
        input = new FileInputStream(file);
        //Carga del modelo con la ontología en el input
        model.read(input, "");
        } catch (FileNotFoundException ex) {
            Logger.getLogger("global").log(Level.SEVERE, null, ex);
        } finally {
            try {
                input.close();
            } catch (IOException ex) {
                Logger.getLogger("global").log(Level.SEVERE, null, ex);
            }
        }
    }
}Created by GeSHI 1.0.7.18

El código anterior muestra de manera sencilla la carga de una ontología en un modelo Jena, en el constructor de la clase nos llega un objeto de la clase File, el cual representa nuestro archivo owl.

La siguiente línea model = ModelFactory.createOntologyModel( OntModelSpec.OWL_DL_MEM ) significa que se va a crear un modelo en memoria y basado en OWL-DL.
Si la linea hubiese sido model = ModelFactory.createOntologyModel(), el modelo se creara con la configuración por defecto que se lista a continuación:

* Lenguaje OWL-FULL
* Almacenaje en Memoria
* Inferencia basada en RDF – Schema

Existen algunas variantes para la creación de nuestro modelo dependiendo del tipo de raciocinio o el perfil del lenguaje que necesitemos. Esto puede ser especificado utilizando constantes definidas en la clase OntModelSpec, las cuales definen ciertas configuraciones pre-establecidas haciendo un wrapper, de las URIs que representan los lenguajes (buscados en la clase ProfileRegister), el tipo de almacenamiento y el razonador. Si precisamos una configuración propia, podemos crear una instancia de OntModelSpec y a través de setters establecer los valores apropiados.

Pero hasta el momento no tenemos nuestra ontología cargada, es el método read() el que se encarga de esta tarea, como lo demarca la siguiente línea model.read(input, "");
Existen algunas variantes del método read() que a continuación se enumeran:

* read( String url )
* read( Reader reader, String base )
* read( InputStream reader, String base )
* read( String url, String lang )
* read( Reader reader, String base, String Lang )
* read( InputStream reader, String base, String Lang )

Cuando cargamos nuestro documento en el modelo, por defecto se cargan todos los import que nuestra ontología realiza. Es decir todo import que se realice sera cargado como un sub-modelo del modelo que se esta construyendo. Este import es recursivo, pero existe un chequeo para evitar ciclos.
Cada modelo tiene asociado un Document Manager que es el encargado de manejar todos los documentos relacionados, por conveniencia existe un Document Manager global que es compartido por todos los modelos y es accesible a través de OntDocumentManager.getInstance(). Para muchos casos, cambiando las configuraciones generales mencionadas anteriormente es suficiente, pero para casos específicos uno puede crear un Document Manager particular y setearlo a la instancia de OntModelSpec que será pasada al Factory que nos creará el modelo.

Código

GeSHi (java):
OntDocumentManager mgr = new OntDocumentManager();
// ...... codigo de usuario .......
OntModelSpec s = new OntModelSpec( OntModelSpec.RDFS_MEM );
s.setDocumentManager( mgr );
OntModel m = ModelFactory.createOntologyModel( s );Created by GeSHI 1.0.7.18

Existen dos maneras de configurar un OntDocumentManager, una es programáticamente y la otra es a través de un archivo de configuración (policy file), el cual está expresado en RDF. La implementación de OntDocumentManager tiene una lista de URLs donde busca estos archivos, el primero que resuelve es el que cargara como configuración por defecto. Si es necesario se puede cambiar la ruta donde busca la implementación con el método setMetadataSearchPath().
Existe mucha configuración relacionada al modelo, por ejemplo la manera de tratar los imports si se procesan o no, como resolver en el caso que la URL no sea encontrada, como trabajar localmente y cómo manejar el caching de modelos cargados con imports. Todo esto es simple y puede encontrarse en forma detallada en la documentación de Jena o en el javadoc del API.

Para seguir detallando un poco más el API de Jena e ir profundizando en sus funcionalidades, pasaremos a describir la interface OntResource.
Todas las clases del API de OWL de Jena que representan un valor en la ontología implementan o extienden esta interface. OntResource, a su vez extiende la interace Resource (RDF).
Algunos atributos comunes en la ontología son representados como métodos en la interface, por ejemplo

* versionInfo
* comment
* label
* seeAlso
* isDefinedBy
* sameAs
* differentFrom

y para cada un de ellos sus patrones correspondientes get, add, is, has, list, remove.

Para terminar con esta entrega damos un pequeño ejemplo de como utilizar ciertos métodos de la interface, tomamos el ejemplo de la página de Jena para el caso de creación de un editor de ontologías y listar los tipos inferidos y los tipos afirmados (inferred vs asserted):

Código

GeSHi (java):
//creación del modelo base
String SOURCE = "http://www.eswc2006.org/technologies ontology";
String NS = SOURCE + "#";
OntModel base = ModelFactory.createOntologyModel( OWL_MEM );
base.read( SOURCE, "RDF/XML" );
//creacion del modelo inferido a travez del modelo base
OntModel inf = ModelFactory.createOntologyModel( OWL_MEM_MICRO_RULE_INF, base );
//creacion de un individuo
OntClass paper = base.getOntClass( NS + "Paper" );
Individual p1 = base.createIndividual( NS + "paper1", paper );
//Listado de los tipos asertados
for (Iterator i = p1.listRDFTypes(); i.hasNext(); ){
   System.out.println( p1.getURI() + " is asserted in class " + i.next() );
}
//Listado de los tipos inferidos
p1 = inf.getIndividual( NS + "paper1" );
for (Iterator i = p1.listRDFTypes(); i.hasNext(); ){
   System.out.println( p1.getURI() + " is inferred to be in class " + i.next() );
}
 Created by GeSHI 1.0.7.18

En la próxima entrega veremos en más detalle el API de OWL de Jena, algunos ejemplos sencillos que sirvan de introducción y de guía a los que se inician en el tema. Cumpliremos con la promesa de la persistencia y nos introduciremos en el API de inferencia. Cuando culminemos con el API de Jena, comenzaremos a ver OWL-API y luego una introducción a Pellet.

Hasta la próxima….

2008-04-10T17:02:00.000-03:00

Frameworks y Ontologías (Parte 1)

El concepto de Ontologías viene desde hace un tiempo tomando fuerza en el mundo de los sistemas de información. Todos o una gran mayoría de ustedes tienen que haber escuchado mencionar el término “Web Semántica”. A grandes rasgos este proyecto trata de dotar de semántica a las páginas web que conocemos actualmente con el motivo de hacer búsquedas más elaboradas en donde el agente que está buscando no obtenga resultados que no sean de interés. Al mismo tiempo se busca lograr interoperatibilidad entre sistemas de información.

La pregunta es: ¿Cuál es el rol que tienen las ontologías? La respuesta es sencilla, la información semántica anexada a la Web necesita de algún formalismo, es ahí donde interviene el término ontología. Una ontología hace referencia a la conceptualización exhaustiva y rigurosa de un dominio determinado facilitando la comunicación y la compartición de información entre diferentes sistemas.

De esta manera es como aparecen los frameworks que hoy conocemos, RDF, RDF Schema y OWL, los cuales nos permiten definir los metadatos necesarios en forma de ontologías.

Este tutorial no intenta brindar un marco teórico al tema de Ontologías, como tampoco pretende abordar tópicos relacionados a las distintas metodologías que existen para de creación de éstas. Pero cabe destacar que se necesitará un entendimiento previo del tema debido a que el texto intenta ser una explicación práctica de la manipulación de las tecnologías circundantes al tema.

Por ende no pretendo dar una descripción en detalle de los lenguajes mencionados anteriormente, pero si a fines prácticos mencionar que cada uno de estos formalismos está codificado en XML, si bien, el estándar no solo propone la codificación en XML (para un procesamiento adecuado por las máquinas), sino que también provee una sintaxis abstracta la que pudiera ser llevada a otros lenguajes.

La aparición de estos lenguajes provocó el desarrollo de un conjunto de frameworks, APIs, la mayoría escritas en Java que nos permiten manipular las ontologías casi en su totalidad y también razonar en base a ellas. Así fue como aperecion Jena, Pellet (Razonador OWL-DL), OWL API, etc. És aquí donde haremos incapié, es decir, en como utilizar todas éstas herramientas para nuestro beneficio.

En esta primera entrega vamos a hablar de Jena y como dar los primeros pasos acerca de la manipulación de las ontologías y en la segunda parte abordaremos lo relacionado al razonamiento.

Jena es un framework que nos provee de un entorno de desarrollo para RDF, RDFS, OWL y SPARQL, como también nos provee de la capacidad de contar con un motor de inferencia basado en reglas. Por todo lo dicho anteriormente Jena cuenta con el siguiente conjunto de APIs que enumeramos a continuación:

APIs de RDF
API de OWL
API ARQ para manejo de SPARQL (lenguaje utilizado para realizar consultas a la ontología)
Soporte de persistencia

Comenzaremos viendo como utilizar el API de OWL. Vamos a suponer que los lectores están familiarizados con la terminología de RDF y que poseen conocimientos en Java.
Como bien se describía anteriormente, existen distintos lenguajes RDF, RDF Schema, OWL, etc. En el orden en que fueron mencionados es en el orden en el cual van aumentando su poder de expresividad semántica. A su vez OWL tiene tres variantes las cuales son OWL-Lite, OWL-DL y OWL-Full, lo mismo para ellos, donde OWL-Full es más rico en expresividad que OWL-DL y éste mas que OWL-Lite.

El API de OWL de Jena utiliza un lenguaje neutral, es decir, los nombres de las clases no hacen mención al lenguaje subyacente que están representando (OWL, RDF, etc). Por ejemplo, la clase OntClass puede hacer referencia a una Clase OWL, o de RDF Schema, etc. Para representar las diferencias entre los distintos lenguajes, cada uno posee un profile que lista todos los contructores permitidos como los nombres de las clases y propiedades. Éste profile está unido al Ontology Model (OntModel) que es una versión extendida de la clase Model de Jena. La clase Model permite acceso a las sentencias en formato de recursos RDF. La clase OntModel extiende Model, agregando soporte para las sentencias que conforman OWL, como clases y jerarquías de clases, propiedades y jerarquías de propiedades e individuos. Cabe destacar que toda la información del modelo subyacente sea con OntModel como con Model esta almacenada en forma de tripletas RDF. Por ejemplo, supongamos que tenemos un objeto OntClass representando una determinada clase de nuestra ontología. Ésta clase tiene un método para determinar sus superclases, listSuperClasses() que se corresponde al valor de la propiedad rdf:SubClassOf de RDF. Cuando llamemos al método, Jena, obtendrá la información desde el modelo subyacente (Tripletas RDF), con lo que quiero dejar en claro que el objeto OntClass no guarda ninguna información de éstas características.

Continuando con los conceptos básicos acerca de como maneja Jena los recursos, presentaremos como el framework trabaja la manera del polimorfismo en Java. Supongamos que tenemos la siguiente afirmación de declaración de un recurso.

Código

GeSHi (xml):
<owl:Class rdf:ID="Persona">
</owl:Class>
 Created by GeSHI 1.0.7.18

Ésto representa un recurso que declara con la URI relativa #Persona una Clase OWL. Entonces podríamos decir que la manera más obvia de declarar esto en Java sería instanciando la clase OntClass. Ahora supongamos que agregamos la siguiente información en forma de tripleta RDF al modelo, agregando más información a la declaración anterior.

Código

GeSHi (xml):
<owl:Class rdf:ID="Persona">
<rdf:type owl:Restriction />
</owl:Class>
 Created by GeSHI 1.0.7.18

Esto significa que Persona es una OLW:Restriction. Una owl:Restriction es una subclase de owl:Class. El problema que tenemos en Java es que no podemos de manera dinámica cambiar la clase del objeto que representa el recurso. El recurso no cambio, porque sigue teniendo la URI #Persona, pero se puede optar por el modelo que ha cambiado de Class a Restriction. Por el contrario, si yo subsecuentemente elimino del modelo la rdf:type owl:Restriction ésta no sería más adecuada.

Otro ejemplo, en OWL – Full toda clase puede ser una owl:ObjectProperty, ésto indica que no podemos hacer un mapeo único entre los recursos RDF y las clases de Java, porque un objeto sería OntClass y ObjectProperty a la vez.

Jena resuelve el tema de los distintos niveles polimórficos de RDF y la abstracción de clases en Java (OntClass, Restriction, DataTypeProperty, ObjectProperty, etc) considerando a estas abstracciones como una vista del Recurso. Es decir, existe una relación uno a muchos, un recurso puede ser representado por varias vistas. Por ejemplo si el recurso es una clase owl (owl:Class), éste puede ser representado por la vista OntClass, Jena provee de un método as() que permite mapear desde RDF a una vista permitida.

En Java podríamos tener el siguiente código:

Código

GeSHi (java):
Resource r = myModel.getResource( myNS + "Persona" );
OntClass cls = (OntClass) r.as( OntClass.class );
 Created by GeSHI 1.0.7.18

En el código anterior, podemos observar que existe un modelo representado por myModel, en la Parte 2 del tutorial explicaremos como instanciar modelos y cargar ontologías, por ahora nos valemos que el modelo ya está creado. La variable myNS, es el namespace del recurso. Con el método getResource() obtenemos el recurso en cuestión y aplicando el método as() mapeamos el recurso a OntClass. Si el recurso fuera también una ObjectProperty podríamos hacer lo mismo. y mapearlo a la clase corespondiente.

Como mencionamos anteriormente en la Parte 2 del tutorial veremos como Jena instancia los modelos, y también como se manejan los import de las ontologías y como se realiza la inferencia, estos conceptos, como los de persistir los modelos en Bases de Datos serán tratados en las próximas entregas.

Espero que hallan obtenido la información necesaria y que sea de interés y agrado la lectura de este tutorial. Para mi fue un gusto redactarlo.

Saludos y hasta la entrega de la segunda parte.

2007-11-01T22:33:00.001-03:00

Es un gusto anunciar que Juglar.org, JUG del Litoral Argentino cuenta con un blog dedicado a publicar las noticias de relevancia en el foro. También en el blog se pueden encontrar vínculos de interés, todos relacionados a la plataforma Java y sus tecnologías.
Invito a todos a visitarlo, como también a los que no están registrados en Juglar a registrarse y pasar a formar parte de la comunidad.

2007-10-26T07:37:00.000-03:00

Ayer 25 de Octubre, se realizó una jornada organizada por Santa Fe Tecnológica, la misma tuvo lugar en el auditorio de la Facultad Tecnológica, en la ciudad de Santa Fe, Argentina.
En la misma disertaron, Andrés Testi miembro fundador de Juglar, del cual también soy miembro fundador. Juglar, es una Java User Group (Grupo de usuarios de Java), aproximadamente tiene 1 año de vida y cuenta con casi 200 usuarios activos, los cuales debaten sobre las tecnologías allegadas a la plataforma Java.
También estuvieron presentes, la gente de Google, los cuales hicieron una disertación sobre tecnologías como adSense y adWords. Estas tecnologías son esenciales para que una empresa pueda ganar prestigio y presencia en Internet.
La gente de .FOX también integro la jornada, realizando una exposición sobre las tendencias publicitarias en Internet.

2007-10-26T00:40:00.000-03:00

Este post es la inauguración del Blog. El contenido de My Blog será especialmente dedicado a lo referente a Sistemas de Información, desarrollo de software, nuevas tecnologías, etc.
Si en algún momento se da, temas relacionados con la música y demás cosas de la vida, pero éstos en menor medida.
Espero que la información que aquí recida sea del agrado y del interés de las personas que lo lean y por supuesto de las que comenten y sugieran ideas.
Quedo inaugurado, ahora a escribir cosas importantes.
Saludos a todos, desde Argentina para el mundo.