Un dia sin CSS

Nos unimos a un dia sin CSS, la verdad que no se muy agradable mi blog.. jajaaja
9 de abril, 3er. CSS Naked Day

Este año, en vez de ser día 5 (como los anteriores), será el día 9 de abril de 2008.

Hace casi un año, los desarrolladores web desnudamos nuestras webs convirtiendo internet en un gran playa nudista de contenido sin estilo, este año no va a ser menos, el día 5 de abril volveremos a unirmos para enseñar a todo el mundo que el contenido es el rey.

El día 9 de abril se celebra el CSS Naked Day, un día en el que nos deshacemos de nuestros estilos y capeamos el temporal con lo que realmente debe tener relevancia en toda web, el contenido.
¿Como participar?

Para participar en este día, únicamente debes eliminar todos los estilos CSS que compongan tu página para que pierda completamente el estilo y que se base enteramente en su estructura.

SOA + RIA [ Emisor, receptor y mensajes!]

[ Abstract ]
La evolución de las arquitecturas empresariales están forzando a un cambio radical en la forma de pensar las aplicaciones web, hoy no solo no se piensa en un solo origen de datos sino que además se requiere completa independencia del lenguaje a utilizar. Es por esto que ahí se crea un nuevo nicho de Frameworks web que Appcelerator viene a cubrir.

[ Resumen ]

Las Arquitecturas Orientadas al Servicios o SOA ya están aquí y están marcando el paso, hoy que una empresa no este implantando esta visión o no este planificando llegar a ella es impensado. Los cambios vertiginosos del mercado y la gran interoperabilidad de estos hacen casi imposible operar sin la visión de servicios. Por otro lado las interfaces de usuario son cada vez mas sofisticadas lo que demandan un gran esfuerzo en su construcción, y si a esto le agregamos que deben soportar la adaptación con servicios provenientes desde distintas organizaciones esto se complejiza.

Es por ello que ha nacido Appcelerator un framework que viene a unir estos dos mundos RIA + SOA un nicho que hasta hace poco estaba desocupado y que este framework supo llenar de una excelente manera, pasemos a verlo…

La globalización ha hecho evolucionar la comunicación de una manera sorprendente, hoy las empresas para poder ser competitivas no solo deben ofrecer buenos servicios sino que también deben ser permeables a otras organizaciones, colaborando entre si para la generación alianzas o simplemente para externalizar ciertos servicios. Esto empuja a las organizaciones a depurar sus mecanismos de comunicación he integración, donde SOA a dado una respuesta concreta solucionando muchos de los problemas tecnológicos que las aquejan. Por otro lado las tecnologías web también han dado su golpe y gracias al conjunto de soluciones RIA (Aplicaciones Ricas de Internet) se han logrado aplicaciones web mucho mas usables y versátiles.

Sin embargo toda esta evolución nos ha planteado un nuevo escenario donde la interoperabilidad de los servicios ha hecho que no estemos preocupados concretamente de las plataformas que los proveen, dando lugar a que las aplicaciones que consumen estos servicios estén construidas en una fauna de lenguajes en crecimiento (Java, .Net, Ruby, PHP, etc).

La proliferación de lenguajes en la organización trae como consecuencia la utilización de mas de un framework para la generación de aplicación RIA por ende nace la necesidad de tener personal capacitado en todas estas tecnologías, lo que a su vez genera un riesgo para la mantención de las aplicaciones y su evolución.

Para evitar tener este riego una nueva solución tecnológica ha visto la luz en el mercado, la cual permite la construcción de soluciones RIA asumiendo la complejidad de la diversidad de lenguajes proveedores de servicios. Esta solución es un framework multilenguaje para la construcción de aplicaciones RIA, basado en una Arquitectura Orientada a Mensajes.

Appcelerator es el nombre que la compañía con el mismo nombre le ha dado al framework, es una herramienta open source, que nos permitirá asumir la complejidad de estandarizar la forma en la que se construyen las aplicaciones RIA en nuestra organización.

Appcelarator esta basado en una arquitectra orientada a mensajes o lo que quiere decir que toda la plataforma está manejada por mensajes, los cuales permiten la comunicación entre el modelo y a su vez entre los componentes o partes que conforman la interface RIA a travez de estos mensajes. Estos mensajes son de tamaño pequeño lo que hacen que la comunicación sea rápida y eficiente. Una gran característica que Appcelerator logro es que los elementos HTML pueden enviar o recibir mensajes para cambiar su aspecto (mensajes locales) o para solicitar datos al Appcelerator Service (mensajes remotos), el cual es el responsable de gestionar todos los mensajes de la aplicación a/hasta los clientes.

La arquitectura de Appcelerator esta formado por tres componentes principales

• SDK (Software Developer Kit) RIA

• SOA Integration Point

• Appcelerator Plug-in Architecture

El SDK RIA o kit de desarrollo de software RIA esta formado por el Appcelerator Widget Framework, un lenguaje de exprecion web, el Client Message Broker, y SOA Integration Points.

Appcelerator Widget Framework

Consiste en una API javascript que nos permite la construcción de widbet´s RIA. Con esta API podemos crear nuevos componentes visuales o reutilizar (envolviendo) componentes de terceros como los de DOJO, YUI, ExtJS o Flex. Sin embargo este framework contiene componentes ya creados y listos para ser usados en nuestras aplicaciones dándonos la libertad de utilizar lo ya existentes o construir nuestros propios compontes visuales.

Su utilización es muy sencilla y consta de agregar un nuevo espacio de nombre a nuestras páginas WEB por medio de la siguiente línea:

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:app="http://www.appcelerator.org">

Luego utilizamos los tag´s comenzando con el prefijo app, quedando nuestro código de la siguiente manera:

<app:calendar title="Pick a Date" on="l:show.calendar then execute" inputId="mydate">

</app:calendar>

<input type="text" id="mydate" value="click me" on="focus then l:show.calendar"/>

Aprovechando la capacidad de generación de eventos de los componentes HTML como un “onFocus” y la capacidad de enviar mensajes (gracias a Appcelerator) podemos aplicar patrones de diseño que nos ayudaran a escribir aplicaciones mucho más mantenibles con respecto a sus antecesoras.

Para el manejo de eventos y el envió de mensajes locales y remotos el framework nos proporciona un lenguaje de expresión web muy simple e intuitivo. Gracias a este lenguaje podremos manejar eventos, manipular el árbol DOM y usar Ajax. Utilizar este lenguaje es tan simple que, con solo agregar el atributo “on” en una etiqueta HTML ya estamos listos para escribir nuestra expresión web, un detalle muy importante es que no hace falta la utilización de java script lo que descongestiona el código de fallas asociadas a este lenguaje de scripting.

Su estructura se basa en el siguiente esquema

on="[condición] then [acción]"

Dentro de las condiciones que podemos capturar se encuentran, click, focus, blur, change, keyup y algunas de las acciones que se pueden disparar son effect[el nombre de un efecto], value, hide, show, toggle[display].

Esto hace que la escritura de aplicaciones ricas de internet sea una tarea divertida y fácil.

Este lenguaje de expresión web depende directamente del Client Message Broker, este componente se encarga de realizar la orquestación de los mensajes, estableciendo la forma de ejecución (asincrónica, sincrónica) y su alcance (local, remoto).

En el siguiente grafico observamos como el Message Broker orquesta un mensaje local.

La siguiente imagen muestra como es resuelto el envió de un mensajes donde se involucra procesamiento de mensajes locales y remotos.

Este componente nos abstrae de todos los aspectos que se ven involucrados a la hora procesar el conjunto de datos que son necesarios para generar el contexto en el envió y recepción de mensajes, haciendo que su utilización sea sumamente sencilla. Podemos observar en las imágenes que el cliente no se preocupa de indicar si el mensaje es local o remoto.

Dado que Appcelerator es multilenguaje el Client Message Broker para desempeñar su tarea necestia de la colaboración de un componente llamado SOA Integration Point, el cual esta formado por un conjunto de herramientas que son las encargadas de realizar la integración entre los mensajes enviados por el Clint Message Broker y el backend que procesa estos mensajes.

Este componente nos permite escribir nuestros servicios en cualquiera de los siguientes lenguajes Java, PHP, Ruby, .NET, Python y Perl. Para cada uno de estos lenguajes este componente nos provee un mecanismo muy simple de declaración de mensajes, donde el también se encarga del marshalling de los datos involucrados en dicho mensaje y el tiempo de vida de los mismos.

Appcelerator Plug-in Architecture

Gracias a la visión de acoplabilidad de Appcelerator, es posible integrarlo con herramientas como Spring, Hibernate, Web Services, etc. Esto es posible gracias a una lista extensa de plug-in´s que hacen que la integración con estas tecnologías sea sencilla y mantenible.

Con todas las características que vimos de Appceleratos podemos concluir que es una herramienta poderosa que esta camibiando la forma de hacer aplicaciones web empresariales, no solo por su versatilidad y curva de aprendizaje baja sino que también por su característica de ser multilenguaje que favorece a la no proliferación de frameworks web dentro de la organización, homogenizando la forma en la que se construyen las RIA.

Esta claro que no podemos asegurar que el futuro se escribirá en Appcelerator pero si que el le esta marcando el paso a los demás frameworks exitentes en el mercado. Sabemos que el fututo esta en SOA ya que la tangenciabilidad con el negocio que esta arquitectura nos ofrece es altamente demandada en las organizaciones asi que lo que claramente lo que podemos esperar es que los demás competidores de Appcelerator evolucionen hasta esta arquitectura. El primer pasó ya esta dado y muy firme por lo tanto quienes adopten esta tecnología pronto verán los frutos muy rápidamente.

Tomas Vera

El mundo de los Closures

La ejecución de un método manipulando variables dependientes de otro método o contexto, se denomina “CLOSURE”, o simplemente podemos decir que es una función definida dentro de otra función donde las variables son ligadas en el momento de ejecución, para ser un poco mas puristas diríamos que podemos enviar como parámetro de un mensaje, un bloque de código capaz de ser ejecutado en este nuevo contexto.
Este concepto nació al rededor de los años 60 con el lenguaje SCHEME y es aprovechado por muchos otros lenguajes como Smalltalk, Ruby, ML, Lisp, Haskell, etc. y si todo sale bien pronto tendremos soporte nativo en Java.
Vamos a ver unos ejemplos prácticos para entender un poco mas el concepto, los ejemplos los voy a escribir en Javascript para que puedan probarlos rápidamente sobre el navegador y luego les mostrare una forma de implementar CLOSURES en java 5.

El siguiente CLOSURE es muy simple pero es para que vallan viendo el manejo de contexto, ademas observemos como se accede a las variables.

function addOne(aNumber)
{
var result = 1 + parseInt(aNumber);
var viewResult = function() { alert(result); }
viewResult();
}

En el ejemplo anterior vemos que pudimos guardar comportamiento dentro de una variable, es decir dentro de la variable viewResult nos guardamos la función que nos muestra el resultado en pantalla y los imprimimos.
No es un CLOSURE muy útil pero la idea del mismo es que comprendamos la utilización de una variable para poder guardar una función y ejecutarla después.
Ahora lo que aremos es dar la posibilidad de que nuestra funcion de visualizacion del resultado sea utilizada en otro momento, para eso cambiamos un poco la funcion anterior.

function addOne(aNumber)
{
var result = 1 + parseInt(aNumber);
var viewResult = function() { alert(result); }
return viewResult;
}

Ahora en vez de ejecutar la función la estoy devolviendo, con esto puedo transportar mi CLOSURE donde quiera y ejecutarlo cuando sea conveniente.
Algunos puntos a tener en cuenta es la forma en la que se realiza la ligadura de variables (binding) miremos este ejemplo para observar que pasa dentro de nuestro CLOSURE.

function addOne(aNumber)
{
var result = 1 + parseInt(aNumber);
var viewResult = function() { alert(result); }
result++;
return viewResult;
}

Bien ahora probemos la nueva función

var myClosure = addOne(4);
myClosure();

Cual sera el numero que arroje? 6 correcto!! Eso es porque el CLOSURE tiene como colaborador interno a la variable result y cualquier modificación sobre el se vera reflejada en nuestro CLOSURE.
Ahora veamos una aplicación un poco mas real (eso espero) para poder utilizar la potencia de esta característica.
Pensemos en que debemos actualizar precios de monedas con respecto al precio del dólar, claramente se que en sus cabezas esta el patrón “Observer”, pero dejemos de pensar en el un rato y veamos la aplicación de los CLOSURES en el problema. Como el ejemplo lo vamos a codificar en Javascript definiremos los CLOSURES pertinentes para actualizar el precio del dólar y las otras monedas, ademas de la lista de monedas.

//Funcion que actualiza el precio de una moneda con respecto al dólar.
function _updateWith(aDolarPrice)
{
this.value = aDolarPrice * this.ratio;
}
//definimos la lista de monedas
var moneyList=[{value:1,ratio:1.1,updateWith:_updateWith},
{value:1,ratio:1.2,updateWith:_updateWith},
{value:1,ratio:1.3,updateWith:_updateWith}];


function setup() {
// Inicializo el valor del dolar
var dolarPrice = 430;
// Guardo la referencia dentro de los CLOSURES
printDolarPrice = function() { alert(dolarPrice); }
setDolarPrice = function(x) { dolarPrice = parseInt(x); }
refreshAMoney = funtion(aMoney) { aMoney.updateWith(dolarPrice);return aMoney;}
}

Bien ahora con estos datos debemos tener una manera de poder recorrer toda la lista de monedas y actualizarlas una a una, para esto construiremos una función llamada map (los amantes de funcional lloran de la emoción...).

function map(list, _function)
{
var result;
for (var i = 0; i < list.length; i++) {
var item = list[i];
result = _function(item);
list[i] = result;
}
return list;
}

Ahora estamos listos para utilizar nuestros CLOSURES y actualizar la lista de monedas!

//inicializamos todo;
setup();
//luego actualizamos el precio del dólar en todas las monedas.
map(moneyList,refreshAMoney);
//modificamos el precio del dólar
setDolarPrice(700);
//y ahora actualizamos el precio de las monedas...
map(moneyList,refreshAMoney);

Se ve con claridad la potencia de disponer de CLOSURES para poder transportar bloques de código capaces de encapsular comportamiento especifico a través de todo nuestro código, lamentablemente hoy en java no disponemos de esta capacidad tan natural como lo es en Javascript.
Sin bien dentro de Java podemos emular a los CLOSURES por medio de generics, se esta discutiendo la posibilidad de incluir en la nueva versión del lenguaje soporte nativo a estos. Las alternativas de CLOSURES actuales son tres BGGA, CICE, FCM sus diferencias varían desde como se escribirán hasta su compilación, tipado, etc. pero como nosotros somos muy inquietos les voy a pasar una forma de implementar CLOSURES con generics y no tener que esperar hasta la versión 7!!!

Lo primero que implementaremos sera una función, por medio de una clase abstracta modelamos el método de aplicación.

// Haskelianos (a->a)
public abstract class Function <A,B>
{

public abstract B apply (A x);

}

Ahora debemos crear una función concreta, nosotros crearemos la función addOne.
public class AddOne extends Function<Integer,Integer> {

public Integer apply(Inetger x) { return x + 1; }
//funciona gracias al outboxing e inboxing.
}

Ahora implementemos el map

<A,B> Iterator<B> map(Function<A,B> f, Iterator<A> xs) {

LinkedList<B> l = new LinkedList<B>();

while (xs.hasNext())

l.add(f.apply(xs.next()));

return l.iterator();

}

Como se observa podemos crear CLOSURES en java con generics (de la versión 5 en delante) , pero no es la unica manera. Si nosotros estamos usando una version de Java menos a la 5 podemos crear CLOSURES por medio de clases anonimas, de todas maneras igual es tediosa la escritura, veamos un ejemplo.

public interface UnaryFunction
{
Object apply(Object o);
}

Ahora creemos una función unaria concreta.

UnaryFunction addOne = new UnaryFunction() { public Object apply( Object o)
{
return ((Integer)o) + 1
}}

Como conclusión los CLOSURES son muy utilices para el programador reduciendo (no en caso de java) el código y ayudando a la reutilización, esperemos que dentro de poco podamos tener una forma nativa de escritura de CLOSURES en java asi podremos disfrutar de esta característica mas sanamente.

Tomas Vera

Javastallk ?

Hay un antes y un después de JavaOne, y la verdad que esta brecha es muy grande, con noticias como la implementación de la JSR 299 (Web Beans), o tan locas como la liberacion de el core de Java. Pero sin dudas una de las noticias que me a puesto mas que contento es la de la implementación de la JSR 292. Y que es la JSR 292? Es la especificacion de Sun que planea extender la JVM para incluir soporte que permita la ejecución eficiente de lenguajes dinámicos ( del estilo Smalltalk ). Sun Digging Deep for Dynamic Language Support es el nombre elegante de esta iniciativa que ha tomado oficialmente la forma de JSR 292, sus promotores Gilad Bracha (Teólogo computacional) y Graham Hamilton ( que capo le queda chico..) en Sun. Fundamentalmente se trataría de incluir dos nuevas características a nivel de máquina virtual:

• Una nueva instrucción: invokedynamic. Similar a la instrucción invokevirtual pero sin verificado de tipos. Sí hay chequeo de tipos, pero en vez de incluirse esta información de forma estática en el bytecode, la comprobación se hace de forma dinámica durante la ejecución.

Para hacerlo mas claro seria...
Usando invokevirtual

Object x;
...
x.equals("hello");
el compilador escribiría algo como...

aload_1 ; push de la variable local (i.e. 'x') dentro de la stack
ldc "hello" ; pone el string "hello" en el stack

; invocamos al método “equals”
invokevirtual java/lang/Object/equals(Ljava/lang/Object;)Z
; pone el resultado booleano en la pila
Ahora en el nuevo mundo de invokedynamic

Object x;
...
x.equals("hello");
el compilador escribiría algo como...

aload_1 ; push de la variable local (i.e. 'x') dentro de la stack
ldc "hello" ; pone el string "hello" en el stack

; invocamos al método “equals”
invokedynamic java/lang/Object/equals(L?;)?
; pone el resultado booleano en la pila
Donde ? son los tipos que seran descubiertos en tiempo de ejecución.

• La posibilidad de hacer hotswapping. Modificación del código "al vuelo", es decir, sería posible añadir/quitar métodos, atributos etc..., en tiempo de ejecución. Esta posibilidad parece ser la más problemática de implementar, de hecho, el JSR no se moja al respecto y sólo afirma que hará todo lo posible.

La intención de Gilad sería poder incluir este JSR en la version Java SE 7 "Dolphin", pero antes tendrá que convencer a un sector importante dentro del mundo Java que ve en esta iniciativa un ataque directo a toda la filosofía Java basada en la programación estática, e incluso para el propio lenguaje Java. Para este sector el soporte previsto en Mustang para la ejecución de lenguajes de scripting desde código Java es lo más apropiado, donde además vendrá de serie un nuevo paquete con la implementación Rhino de JavaScript.

Por el contrario, sus partidarios piensan que la iniciativa está aún demasiado verde, y que para cuando vea la luz será demasiado tarde, y se temen también, que será demasiado reducida. Mientras tanto sería la plataforma .NET de Microsoft y su clon multiplataforma Mono el entorno más adecuado para el desarrollo de las nuevas iniciativas que involucran lenguajes dinámicos.
Esto viniendo de la mano por ejemplo de Visual Smalltalk ( que en la próxima entrega les voy a mostrar Jabber con Smalltalk y .Net )
Para las personas que miramos con mucha, mucha desconfianza a los productos del Microsoft esto es un avance muy importante par esta plataforma y por lo menos a mi me hace mirar a .Net con un poco mas de cariño (pero eso sera contado en otro post je je je).

Retomando el pobre Gilad es consciente del reto y de las dificultades, apunta a la posibilidad de que, al menos al principio, hacer que estas nuevas características no estén activadas por defecto, y que para su utilización fuese necesario utilizar una opción de comando que se podría llamar ¿-dynamic? o Dios sabe como.... De esa manera no impones a nadie nada y le darían la libertad para poder implementar la JSR 292.


A diferencia de muchos comentarios sobre esta JSR a mi entender que este proyecto vea la luz seria un aporte muy importante para Java, cambiando la filosofía de como muchas personas actualmente ven a java... como un lenguaje estático mas...

Saliendo de la cueva y todavía bostezando

Después de tanto hibernar, este Blog sale a flote, un poco falta de tiempo, un poco falta de inspiración, un poco de pachorra, va un poco de todo hizo que no escribiera nada. Con una nueva cara y con las pilas cargadas eMundo intentara dar lugar a discusiones del mundo informático. Tocaremos temas tanto tecnológicos, como administrativos y me tomare el atrevimiento de apostar por ciertas tendencias, sin dejar de lado, que algún día pase detalles de mi vida, como experiencias laborales o estudiantiles... o algún recreo que me tome. En principio tengo un montón de cosas para contarles, pero obvio, no tengo 23 manos así que intentare ir de apoco.. solo les pido un poco de paciencia. Es obvio que cualquier persona que quiera ayudarme en la difícil tarea de llevar este blog adelante, no tiene mas que escribirme ;) Espero hacerles buena compania y que entre todos hagamos un lugar común de reunion, haciendo que este lugar se transforme en el bar de charla informática.

Que es el LIFIA? - Su parte de invetigacion

LIFIA es un laboratorio de investigación que vuelca sus conocimientos y sus desarrollos informáticos de avanzada a la comunidad académica y de negocios, nacional e internacional.Su fundación en 1988 en la Universidad Nacional de La Plata (Argentina), ha ganado el respeto por su habilidad para concebir, diseñar, desarrollar e implementar sistemas en una variedad de instituciones y compañías nacionales e internacionales en sectores como el financiero, comunicaciones, gobierno, salud, educación, industria del software. Para ello combinaron experiencia en Ingeniería de Software y Métodos Formales para construir soluciones para clientes en tiempos Internet, implementando modernas aplicaciones Internet y GIS, software seguro y otras.El equipo del LIFIA está constituido por profesionales experimentados en la investigación, desarrollo, implementación y capacitación de sistemas de avanzada. Por lo general son docentes universitarios o estudiantes avanzados y reciben una capacitación continua tanto en universidades argentinas como en el exterior.

Biemvenidos a eMundo

Hola Internautas
Bienvenidos eMundo, la intención de este Blog es muy amplia pero sobre todas las cosas esta creado para tener un espacio de expresión, donde cada uno de ustedes pueda dejar su marca y así poder compartir opiniones, criticas, comentarios, etc. Espero que les sea de su agrado y desde ya muchas gracias por su colaboración!

Tomas Vera