Elementos Sintácticos de Java

He incluído para descarga en mi sitio web una guía de la mayor parte los elementos sintácticos de Java que servirá de ayuda para quienes programan en otros lenguajes y quisieran aprender Java. El link de descarga es el siguiente:

http://www.juancavallotti.com/home/view/study

Espero se aproveche.

Saludos!

Editor Visual para GWT

Hace poco me enteré que google compró la empresa instantiations (link a la noticia), esta empresa era la dueña del único diseñador gráfico decente para GWT, el cual era un plugin de eclipse y además privativo (había que comprarlo para usarlo). Hace poquito me entero que google publicó estos plugins gratis para todos! (link a la noticia).
Yo estuve probando este editor visual y he llegado a varias conclusiones:

Primero que nada, el plugin es genial! Las interfaces web diseñadas visualmente, o sea arrastrando componentes y realizando todo un manejo visual, terminan en código clásico de GWT, o bien con UI Binder!! El código que se genera es bastante limpio y fácil de entender, podemos utilizar todos los controles disponibles en GWT directamente de forma visual, podemos realizar cambios en el código y éstos se reflejan en el modo visual.

Además de todo esto, permite agregar fácilmente los frameworks de extensión mas populares como GWT-EXT y XGWT.

Acá les dejo un par de screenshots:

Vista de código:
Vista WYSIWYG:

Si combinamos esto con la funcionalidad que nos daba el plugin de google, nos queda como gran conclusión de todo que eclipse es la plataforma ideal e indiscutible para hacer aplicaciones en GWT.

Saludos!

Mis Recordatorios

Ahora la aplicación "Mis Recordatorios" se encuenta abierta para todas aquellas personas que deseen utilizarla.

La url es http://misrecordatorios.appspot.com/

Saludos!

Acerca de los WebSockets

Websockets es una de las tecnologías más interesantes de HTML5, mediante esta tecnología se termina uno de los grandes problemas de las aplicaciones web la falta de estado! Un desarrollador a partir de ahora podrá crear conexiones persistentes con el servidor de aplicaciones y realizar toda clase de cosas convirtiendo a la página web en un cliente común y corriente!

Por ello el desarrollador web deberá comenzar a pensar de otra forma, perderá sentido pensar en "el tiempo de request", la sesión web con su famosa cookie, no mas arquitectura mvc (tal cual la conocemos ahora y la usamos en la web) en pocas palabras, una revolución total. Hoy podemos utilizar esta tecnología si disponemos de dos cosas:

• Un browser compatible (como chrome o safari).
• Un servidor compatible.

Existen varias implementaciones del protocolo websockets (aunque todavía está en desarrollo), como muchos se lo estarán esperando, si vas a probar esto en java, podrás usar mi framework "websockets4j" disponible para descarga en jar en websockets4j.googlecode.com.

Bueno, ahora sin mas preámbulos, a lo importante. Para conectarnos al servidor desde Javascript necesitamos conocer dos cosas:

• La url de conexión.
• El subprotocolo a utilizar. (opcional)

La url de conexión indica a que servidor nos conectaremos, y tiene la siguiente forma:

ws (o wss) ://:puerto/recurso.

Si utilizamos ws, la conexión será sobre un canal desencriptado, y si utilizamos wss la conexión será utilizando "Transport Layer Security" o TLS. (de momento mi framework de websockets no soporta wss).

El subprotocolo, es para ser utilizado por terceros, usualmente se utilizará con una librería de javascript y un servidor del mismo vendedor.

La conexión puede tener tres estados posibles: Connecting, Opened y Closed. El siguiente código muestra la interfaz de WebSocket.

interface WebSocket {
readonly attribute DOMString URL;

// ready state
const unsigned short CONNECTING = 0;
const unsigned short OPEN = 1;
const unsigned short CLOSED = 2;
readonly attribute unsigned short readyState;
readonly attribute unsigned long bufferedAmount;

// networking
        attribute Function onopen;
        attribute Function onmessage;
        attribute Function onclose;
boolean send(in DOMString data);
void close();
};
WebSocket implements EventTarget;

(fuente: w3c)

Los mensajes al cliente serán recibidos por eventos, una función javascript será invocada cuando un mensaje llegue.

La trama tiene forma de caracteres unicode UTF-8 y se recibirá en forma de mensajes que pueden tener longitud variable.

Para realizar la conexión, basta con la siguiente línea Javascript:

var socket = new WebSocket("ws://some.host:10123/resource", [subprotocol]);

Una vez realizado esto, podemos setearle funciones para los cambios de estado:

socket.onopen = function() { alert("Opened!") };
socket.onmessage = function (e) { alert("Message: "+e.data); };
socket.onclose = function() { alert("Closed!") };
socket.onerror = function() { alert("Error!") };

Para enviar un mensaje, simplemente podremos utilizar la función "send" del socket.

Para cerrar la conexión, podremos utilizar la función "close" del socket.

Con esto concluyo esta guía sobre esta tecnología que va a cambiar a la web para siempre.

Saludos!

Pesadilla Microsoft: Internet Explorer

Esta entrada va a ser con el contenido en una página especial de mi sitio web donde explica por qué los usuarios no deberían utilizar internet explorer de una forma muy sutil:

http://www.juancavallotti.com/index.php/home/view/home

Internet explorer es por lejos el peor navegador del mundo y aún así el mas utilizado, gracias Bill por tanta magia!

Framework de WebSockets: websockets4j

Este fin de semana he estado trabajando duro en un framework para WebSockets que sea conectable a Glassfish 3 y Tomcat 7. Aunque no es solamente conectable a eso, sino que mientras el servidor tenga permitida la creación de hilos y levantar ServerSockets, esto va a andar. El framework es open source con licencia Apache 2, bien permisiva!!.

El framework puede ser descargado de: http://websockets4j.googlecode.com y tiene como interesante que soporta la versión 75 y 76 del borrador del estándar de WebSockets, trataré de irlo actualizando a medida que los browsers vayan soportando versiones nuevas del estándar. Por ahora Google Chrome soporta la versión 75 y Safari 5 la versión 76.

Les dejo acá un videito de una aplicación de chat de ejemplo que hice para demostrar el funcionamiento del framework. Está en inglés porque pertenece al sitio de mi proyecto.

Dicen.. que se puede ver en hd.

Un dato curioso es que el framework no está hecho para funcionar con servlets incluso cuando el handshaking del protocolo es parecido a una solicitud http, bien, la especificación de servlets dice claramente que los servlets son para protocolos de solicitud y respuesta, como el HTTP, pero los websockets se comportan de forma muy distinta. Espero que le sirva a alguno, y pronto estaré trabajando en agregarle soporte para TLS.

Saludos!!

Pesadilla Microsoft: FAT32

Comienzo esta sección del blog digamos, este tag llamado Pesadilla Microsoft donde pienso escribir en la medida de lo posible como microsoft arruina el progreso de la computación simplemente por ser el sistema operativo que más se usa.

Para empezar, voy a hablar de un problema que debe ser común en muchas personas y que no deben saber que pasa. ¿Qué pasa cuando queremos grabar en un flash drive archivos de 4 gigas o mas? La respuesta puede ser variada, me dice que el pen está lleno, me tira error, etc, pero la realidad es muy simple FAT 32 no admite archivos de 4 gigas o mas.

El gran problema es que hoy en dia los archivos pesan mucho mas que eso. Por ejemplo, podría ser una película en alta definición que queremos grabar en un pendrive para enchufarla a nuestro dvd y verla en la tele. Bueno amigos, lamento decepcionarlos, pero los flash drives se formatean en FAT 32 porque sino no pueden ser capaces de reproducir música (si es que son mp3) o el dvd ni los va a leer.

¿Por que eligieron FAT 32 los tontos fabricantes?

La respuesta a esta pregunta por parte de un adepto a microsoft podría ser "porque el sistema NTFS le sobra por todos lados al dispositivo" y es válido, una respuesta de criterio, pero los adeptos a otros sistemas operativos me dirán "existen un montonaso de sistemas de archivos" y si, totalmente cierto, pero olvidamos el detalle de que para fabricar un dispositivo que sea rentable, tiene que poder usarse en windows "out of the box" (o sea, de movida) porque sino se venden muy pocos, y windows actualmente soporta sólo 2 sistemas de archivos (excluyendo a ISO 9660 y UDF que son para cd/dvd), NTFS y FAT 32. Entonces finalmente aplicando el criterio los diseñadores de los dispositivos llegaron a la única opción: FAT 32.

Claro está que podrían haber utilizado un sistema de archivos apropiado y escalable pero escribir un driver de sistema de archivos para windows no es una tarea trivial (y a veces resulta imposible), porque sino podríamos disfrutar de drivers para sistemas de archivos buenos como reiserfs, ext4 y HFS.

Conclusión: Por malas decisiones en el diseño de windows, nosotros no podemos grabar archivos de 4 gigas o mas en nuestros pendrives. Y esto habría sido muy fácil de evitar si en windows se pudieran instalar fácilmente drivers de sistemas de archivos como pasa en mac o en linux (con Fuse o MacFuse).

Esto es una de las formas en que microsoft nos fastidia la vida.

Saludos!

Por qué son tan malos los productos de Microsoft?

Hace algún tiempo conocí la consola xbox 360, realmente es muy mala, hace un ruido de ventiladores infernal y se cuelga a cada rato, y yo me pregunto:

¿No está harta ya la gente de lidiar con productos de mala calidad?

Realmente, en serio y no jodo, siendo usuario de linux o de mac, una persona básicamente puede hacer lo que quiere en su computadora sin tener que preocuparse cosas como: virus, formateadas, pantallas azules, lentitud en la operación, ver mal los sitios web, tener un sistema operativo innecesariamente pesado que ni siquiera se adapta bien a las pantallas de las netbooks.

Hoy en día la vida de una persona normal pasa detrás de un browser, y tanto en linux como en mac tenemos a nuestra disposición los mejores browsers que puede ofrecer el mercado: Chrome, Safari y Firefox. En este sentido, un aspecto indignante es que gracias a microsoft es que la web evoluciona tan lentamente, ya que la mayoría de las personas utilizan internet explorer y éste evoluciona muy lentamente y de una forma super inestándar.

Por otro lado, a la gente le gusta tener sus configuraciones, fondo de pantalla, correo y documentos organizados perfectamente y realmente después de cada formateada, es un fastidio tener que volver a dejar todo como estaba, realmente ¿quién puede querer eso?

La única cosa "buena" que ha hecho microsoft en su existencia ha sido su planilla de cálculo, y le pongo comillas porque es tán versátil que la gente lo termina usando para cosas que no tienen sentido, pero bueno, la mitad de la información del mundo, si no es que más, está guardada en esa maldita planilla.

Otra cosa que me molesta es que los programas de microsoft son innecesariamente difíciles de usar, la interfaz de usuario de windows por ejemplo no le da ninguna facilidad a las personas que saben que quieren y quieren llegar rápido, además no entienden que las personas hacen muchas cosas con las ventanas, y no proveen ninguna forma útil de cambiar entre ellas. Además tratar de encontrar algo en el bendito panel de control es una pesadilla.

El set básico de aplicaciones de windows es super apestoso, en efecto, las aplicaciones básicas no sirven absolutamente para nada desde el browser hasta el editor de texto. El paint ha pasado por tantas versiones y no ha ganado un miserable feature, solo han cambiado las barras de herramientas de sheridan toolbars a Ribbon! PUAJ!! Sólo sirve para pintarle bigotes a la gente de las fotos.

Otra cosa apestosa son sus herramientas de desarrollo, sólo sirven para lograr productos de gama baja y encima hay que pagarlas y salen carísimas. Realmente si nos ponemos a comparar con linux en donde tenemos todo un set de lenguajes y frameworks multiplataforma con los que podemos hacer todo tipo de aplicaciones, de todas formas y colores y escalables a todos los mercados. Un buen programador .net es como los gatos esos que los chinos meten en un frasco y los mantienen vivos, además obligan a sus usuarios a usar productos de microsoft. Apple, si bien hace esto, al menos nos da gratis el kit de desarrollo.

En cuanto a hardware, las cosas de microsoft andan bien... al principio, pero se deterioran rápidamente y pronto hay que tirarlas a la basura, ¿quien no se acuerda del famoso teclado ergonómico que venía en ángulo?

Finalmente la suite de oficina, que engorroso de usar es por dios!! uno no es capaz de concentrarse en lo que está haciendo porque lo que uno quiere hacer está siempre como a 20 clicks de distancia, por dios!! Y encima de eso, si grabamos nuestros documentos en su formato no los vamos a poder ver bien en ninguna herramienta de oficina como la gente, lo peor de estas "herramientas" son su super inestabilidad, no vaya a ser que estemos haciendo algo importante y el programa se cierre cuando queremos guardar, pero si! esas cosas pasan en el mundo de bill. Otra cosa que es impresentable es la aplicación web "Sharepoint" por dios!! es una planilla de excel hecha web y que encima no anda en otro browser que no sea internet explorer, el cual es la peor basura que puede haber tocado una pc.

Bueno, eso es todo por ahora, jajaja seguro me deben estar imaginando como si fuera violencia rivas. Quieranse y no usen productos de microsoft, van a ver como llega la felicidad, al acto!

Saludos!!

Encuesta de Sistemas Operativos

Hace tiempo ya cerró la encuesta de sistemas operativos que hice en el blog, realmente los resultados no fueron tan sorprendentes salvo porque la mayoría utilizaba linux, lo cual no es tan raro ya que la mayoría de mis amigos usan linux. De todas formas, es un mensaje de esperanza de que algún día, se dejen de usar los productos de microsoft.

Les dejo acá la imágen.

Saludos!

Mañana Nevada en Mendoza

Acá dejo cómo se veía mi jardín la mañana nevada del 15 de Julio, la verdad que daba fiaquita salir de Casa.

Mac y Windows 7

Muy gracioso este video de Mac y Windows.


Saludos!

MacPorts

Una de mis principales preocupaciones al migrar a la plataforma Mac es la de no conseguir las aplicaciones que estaba acostumbrado a utilizar en linux. Pues bien, buscando en internet encontré el sitio MacPorts el cual provee muchos paquetes de software libre para la plataforma Mac OS, e inclusive se encarga de las actualizaciones de software como estaba acostumbrado en linux.

Mediante este sistema puedo instalar grandes aplicaciones como:

• Amarok
• KDE Pim
• Kile
• Muchos Otros.

Resulta realmente sorprendente y me agrada mucho el esfuerzo de apple por participar de la comunidad del software libre.

Saludos!

Muchas cosas libres en Mac OS X

Hace poco he comenzado a ser usuario de Mac OS X y sinceramente me ha sorprendido la cantidad de software libre que tiene. El viaje comenzó al abrir la consola, como digno usuario de linux empecé a tirar comandos y con sorpresa vi que funcionaban. Herramientas como bash, vim, subversion y otras son las que se utilizan en mac, incluso su sistema de ventanas es X.org y su núcleo "Darwin" es un proyecto open source basado en el kernel de FreeBSD.

Acá les dejo un link del sitio web de apple explicando las formas en las que se encuentran involucrados con el software libre.

Resulta muy extraño que una empresa tan comercial tenga una base tan importante en software libre, pero sinceramente creo que es la única forma que un sistema operativo comercial sobreviva en los tiempos actuales.

Acá dejo un link que amplía bastante la explicación sobre darwin.

Y finalmente un link de un sistema operativo basado en GNU y Darwin.

Saludos!

Video Mac PC y Linux

Novell También hace de las suyas, realmente muy entretenido.




Ciertamente linux corre mejor en mac que en pc, pero corre en ambos!




Saludos!

Videos de Mac versus PC.

No solo es para reirse por las diferencias, sino que también el doblaje en español me resulta muy gracioso. Espero que lo disfruten.



Saludos!

Google Guice, breve reseña.

Google Guice es un framework para inyección de dependencias. Cuando nos encontramos frente al desarrollo de aplicaciones grandes (o al menos potencialmente grandes) en las que distintos equipos de desarrolladores codifican distintos módulos de una misma aplicación es el caso donde se presenta como obvia la necesidad de un bajo acoplamiento entre dichos módulos. Normalmente se presenta la necesidad de realizar tests automatizados de una o mas clases, o colaboraciones y dicho código posiblemente dependa de código de otro módulo que ni siquiera se encuentre desarrollado, o que resulte extremadamente costoso en tiempo o en recursos realizar dichos test. Aquí es cuando entra en juego la inyección de dependencias. No pretendo en este post explicar la inyección de dependencias en sí, para mayor información sobre ésta ver el siguiente enlace.

Goolge Guice es un excelente framework, el cual implementa el standard JSR 330 para la inyección de dependencias. Posee entre otras las siguientes características:

• Inyección de dependencias en constructor.
• Inyección de dependencias utilizando setters.
• Inyección de dependencias directamente en los atributos de la clase.
• Intercepción de métodos con filtro por anotaciones (especialmente útil para AOP).
• Configuración programática de los módulos de la aplicación.
• Definición de Fabricas (proveedores) y ámbitos para las instancias inyectadas.
• Otras.

Gracias a estas características, estre framework resulta especialmente útil, algunos de los beneficios de utilizarlo son:

• Generalización de aspectos en las aplicaciones y su consiguiente reducción de errores.
• Escribimos código mas mantenible.
• Escribimos código mejor testeable.
• Escribimos código mucho más reutilizable.
  

En el siguiente ejemplo demostramos el uso de Google Guice para el módulo de recordatorio de cumpleaños en el appspot de este blog.

Primero demostraré un framgento de la clase encargada de la lógica de negocio de esta pequeña aplicación:

@Singleton
public class BirthDateManager {

private EntityManager em;

@Inject
public BirthDateManager(EntityManager em) {
   this.em = em;
}
...
}

Podemos observar 3 cosas:

1. Utilizamos el annotation @Singleton para indicarle al inyector que esta clase deberá instanciarla una única vez.
2. Definimos el constructor que recibe las dependencias de esta clase de reglas de negocio de acuerdo con el patrón inyección de dependencias.
3. Con la annotation @Inject le indicamos al inyector que debe inyectar dependencias.

Ahora observamos la clase que define el módulo donde configuraremos el inyector:

public class BirthDateModule extends AbstractModule {

@Override
protected void configure() {
    bind(EntityManager.class).toProvider(PersistenceFacade.class);
}

}

Con esta simple línea le indicamos al inyector que debe obtener la dependencia de un proveedor, en este caso una fachada de persistencia. A continuación el código interesante de dicha fachada:

public class PersistenceFacade implements Provider<EntityManager> {

 @Override
 public EntityManager get() {
     return emf.createEntityManager();
 }
 ...
}

Vemos que nuestra clase proveedora deberá implementar la interfaz Provider para que Guice sepa cual es el método que nos provee la dependencia.

Finalmente vemos el código que pone todo junto. Obtenemos la clase de las reglas del negocio con las dependencias ya satisfechas a través de un inyector:

        Injector in = Guice.createInjector(new BirthDateModule());
       BirthDateManager bdm = in.getInstance(BirthDateManager.class);

Como se puede ver resulta bastante simple:creamos un inyector a partir del módulo y luego le pedimos la clase de reglas del negocio a dicho inyector. Toda la magia ocurre en estas 2 líneas.

Con eso concluyo esta breve demostración de Google Guice. Espero que sea de utilidad.

Saludos!

Little Wings SRV

Acá les dejo un video de Stevie Ray Vaughan tocando una gran versión de un tema de Jimi Hendrix "Little Wings". Espero que lo disfruten.





Saludos!

Google AppEngine: Protegiendo el contenido web.

En un post anterior vimos como utilizar las cuentas de google para hacer login y logout en app engine. Ahora veremos una de las opciones para proteger contenido en nuestra aplicación, mediante la definición de reglas declarativas en el archivo web.xml. Para una referencia completa de las cosas que podemos hacer en el web.xml para app engine, ver el siguiente enlace.

AppEngine provee una forma estándar (llamando a estándar a compatible con JAAS) para proteger recursos declarativamente. Por ejemplo en la aplicación del appspot de este sitio se definió:

    <security-constraint>
       <web-resource-collection>
           <url-pattern>/seguro/*</url-pattern>
       </web-resource-collection>
       <auth-constraint>
           <role-name>*</role-name>
       </auth-constraint>
   </security-constraint>

Diciendo que lo que hay dentro de la carpeta "/seguro/" puede ser sólamente accedido por el rol "*".
AppEngine nos provee 2 roles distintos para nuestra aplicación:

• El rol de cuenta de google: "*"
• El rol de administrador: "admin"

El primero se aplica a cualquier persona logueada con su cuenta de google, y el segundo sólo a aquellas cuentas de google que definimos en la configuración de la aplicación como "admin".

Esta definición resulta suficiente para proteger cualquier contenido en nuestra aplicación, sin embargo cuando trabajamos con GWT, las consideraciones son un poco distintas, ya que debemos por un lado proveer una lógica que oculte o deshabilite opciones que no son accesibles y, debido a que se trata de código en el cliente, debemos proteger las llamadas remotas.

El escenario ideal para proteger las llamadas remotas es el de los servlets con programación orientada a aspectos o AOP y posiblemente anotaciones para asegurar métodos en forma declarativa. En un post futuro investigaremos estas posibilidades y utilizaremos filtros, algo realmente poderoso, para armar la seguridad de la forma menos trabajosa.

Saludos!

Google AppEngine: Acceso a las cuentas de google.

Una de las facilidades que nos provee Google AppEngine es la de acceder a las cuentas de google. He estado experimentando un poco con esto y puedo remarcar los siguientes puntos:

• El acceso a la info del usuario logueado se realiza a través del mecanismo estándar de JAAS.
• Pueden protegerse urls del sitio mediante el mecanismo estándar de la web tier, esto es definiéndolas en el archivo web.xml.
• El mecanismo de login y logout es no estándar.

En este post demostraré el uso que le he dado a esta funcionalidad en el appspot del sitio. En próximos post demostraré alternativas para proteger urls del sitio.

El ejemplo es la implementación un servicio RPC de GWT. Primero echemosle una mirada a los import.

import com.google.gwt.user.server.rpc.RemoteServiceServlet;
import appspot.client.CommonService;
import com.google.appengine.api.users.UserService;
import com.google.appengine.api.users.UserServiceFactory;
import javax.servlet.http.HttpServletRequest;

Lo primero que vemos entonces son los import comunes de GWT para los servicios RPC, también vemos importada la interfaz necesaria para que la magia funcione "CommonService" (ese nombre lo elegí yo). Luego vemos las clases de google para acceder a sus cuentas, la "UserService" y "UserServiceFactory", de los nombres mismos ya se puede inferir el uso.

Lo próximo que veremos es la implementación de la clase de servicio, en la cual accedemos a las api.

public class CommonServiceImpl extends RemoteServiceServlet
       implements CommonService {

   @Override
   public String getUserMail() {

       UserService us = UserServiceFactory.getUserService();
       if (!us.isUserLoggedIn()) {
           return null;
       }

       HttpServletRequest req = getThreadLocalRequest();
       String name = req.getUserPrincipal().getName();
       return name;
   }

   @Override
   public String getLoginUrl(String baseUrl) {
       UserService us = UserServiceFactory.getUserService();
       return us.createLoginURL(baseUrl);
   }

   @Override
   public String getLogoutUrl(String baseUrl) {
       UserService us = UserServiceFactory.getUserService();
       return us.createLogoutURL(baseUrl);
   }
}

Vemos que nuestro servicio tiene 3 métodos:

• Obtener el usuario logueado.
• Generar una URL que nos llevará a una pantalla de login.
• Generar una URL que nos deslogueará del servicio.

En el primer método utilizamos el userService para preguntar si el usuario se encuentra logueado. Esta es una manera no estándar, pero realmente simpática y prolija.
Luego utilizamos una forma estándar para obtener el "User Principal", el cual traducido del lenguaje JAAS, es el usuario logueado.

Los métodos de generar urls son prácticamente iguales, en uno pedimos de una manera no estándar que nos entreguen una url de la página de login diciendo también la url a la cual queremos ir despues de estar logueados. Esto es realmente una ventaja comparado con la forma estándar en la cual definimos en web.xml un formulario de login al cual llegamos tratando de alcanzar una url no permitida, ya que la lógica de navegación para el login debe ser inferida y no puede leerse del propio código. Con eso le damos fin a nuestra demostración. Espero que haya sido de utilidad.

Saludos!