Blog

Temas: Chrome Dart
Juan Mellado, 1 Junio, 2012 - 10:17

DartAndo otra vez trasteando con Dart, el nuevo lenguaje de programación de Google para la web. Aunque ellos en vez de "lenguaje" lo llaman "plataforma". He cogido un proyecto viejo y lo estoy adaptando al nuevo lenguaje, sobre todo para probar la nueva versión del IDE, de Dartium, que es un build especial de Chrome que lleva incluida la máquina virtual de Dart, y dart2js, que es el tercer conversor de Dart a JavaScript que liberan.

Dart está todavía en desarrollo, lo que quiere decir que ahora mismo lo único que se puede hacer es trabajar sobre la versión alpha. Todavía le queda mucho camino por recorrer, pero las primeras sensaciones es que es mucho mejor que JavaScript para proyectos grandes que requieran un mínimo de organización. Tiene más de "Java" que de "Script".

En el IDE han añadido algunas cosas básicas que las primeras versiones que liberaron no tenían. ¡Ya se puede renombrar ficheros! Aunque lo más importante es que han añadido un pequeño depurador. Desgraciadamente está muy verde. La depuración paso a paso no está muy fina todavía, por ejemplo en los switch/case obliga a pasar por cada case en vez de ir directamente al que cumple la condición como es lo habitual. Aunque lo peor es que no se pueden añadir watches, por lo que al final se acaba depurando a la antigua usanza, tirando mensajes por consola, convirtiendo los desarrollos actuales en toda una heroicidad.

Por lo que respecta al lenguaje en sí, poco que decir, es parecido a Java por ejemplo, con sus clases, interfaces y demás. Aunque me preocupa un poco la diferencia de tipos con JavaScript, en particular de los enteros. En Dart los enteros no tienen un tamaño fijo predeterminado, a diferencia de JavaScript que son de 64 bits. Esto hace que las operaciones de manipulación de bits se comporten de forma distinta en un lenguaje y otro. Sobre todo porque en JavaScript además este tipo de operaciones se truncan a 32 bits. Muchas aplicaciones no utilizan este tipo de operaciones, pero curiosamente en el tipo de desarrollos que yo suelo hacer son bastante habituales, ya que manipulo grandes cantidades de información a nivel binario.

El API está evolucionando bastante rápido, aunque eso implica que es normal encontrar algunas discrepancias entre la documentación y la implementación. Por ejemplo, el generador de números aleatorios es una función de la clase Math, aunque la documentación indica que se encuentra en una clase aparte Random. En realidad no tiene mucha importancia, y si me he dado cuenta es porque el generador no funciona bien, siempre genera la misma secuencia de números, y tratando de resolverlo estuve estudiando un poco más a fondo la documentación.

Por último, un tema importante a tener en cuenta es que las aplicaciones en Dart están pensadas para ejecutarse desde línea de comandos o desde un navegador, pero la única forma de tener una interface gráfica hoy en día es ejecutarlas desde un navegador. Tengo curiosidad por saber como evolucionará esto, sobre todo porque tener que implementar una aplicación típica de escritorio es un requerimiento normal. Quizás la solución sea desarrollar bindings con algunas librerías ya existentes. De hecho, desde Dart se pueden realizar llamadas a código C/C++, a la manera de los métodos native de Java por ejemplo. Es una vía interesante a estudiar.

Temas: Java
Juan Mellado, 21 Mayo, 2012 - 18:21

DukeAprovechando esta dualidad mía, que lo mismo me permite escribir el código de una librería de visión artificial en JavaScript, que escribir el código de una aplicación empresarial Java de corte clásico siguiendo el patrón MVC, sin que me estalle la cabeza por el switch tan brutal, he estado estos días revisando la especificación de J2EE, en concreto la correspondiente a la parte web.

He abierto una nueva serie de artículos en la web con las notas que he ido tomando, aunque he cambiado un poco el formato con respecto a la serie que hice hace poco revisando la documentación de Spring. Esta vez he preferido agrupar el contenido y activar la paginación sobre los temas principales en vez de tenerlos divididos en muchas partes individuales.

De entrada he revisado el API de los servlets, la construcción con JSP, y el uso de la librería de acciones JSTL:

- Servlets: Los servlets son los componentes básicos de una aplicación web Java. Su API siempre me ha gustado, aunque es de bastante bajo nivel. Entendiendo como funciona un servlet se puede entender todo lo demás.

He revisado la especificación entera incluyendo apartados en el artículo que comprenden la organización de un war, la implementación básica de un servlet, el mapeo de urls, el objeto respuesta, el objeto petición, el contexto, las sesiones, el ciclo de vida, los distpatchers, filtros, listeners, e incluso una introducción al API 3.0 que posibilita la ejecución de servlets de forma asíncrona.

- JSP: Un JSP es un servlet, pero escrito de forma que parezca una página HTML. Curiosamente, y a diferencia de los servlets tradicionales, los JSP nunca me han terminado de gustar. Supongo que porque aún recuerdo el horror que produjo en su día ver que se podía embeber código Java dentro de ellos. Algunas alternativas como el CodeBehind con C# siempre me han gustado un poco más.

La especificación de JSP no ha estado nunca entre mis favoritas. No obstante, en el artículo reviso lo que es un JSP, las páginas JSP, los documentos JSP, las directivas, las declaraciones, los objetos implícitos, las expresiones, los scriptlets, el Expression Language, las acciones estándar, e incluso una explicación de como construir una tag library propia.

- JSTL: JSTL es la librería de acciones JSP estándar. La mayoría de los frameworks ofrecen librerías propias, pero lo normal es utilizar JSTL para realizar algunas operaciones básicas.

En el artículo he incluido una revisión de todas la acciones que proporciona JSTL en sus cinco librerías, desde las básicas ofrecidas por core, functions e i18n, hasta las menos utilizadas sql y xml, y que deberían evitar usarse.

JSP es un tecnología deprecada hoy en día en favor de JSF, probable tema de artículos posteriores, aunque puede que me la salte directamente en favor del análisis de algún framework.

Juan Mellado, 12 Mayo, 2012 - 20:15

He liberado los fuentes de js-handtracking, una librería escrita en JavaScript que captura la imagen de una webcam y la procesa con el objetivo de detectar la presencia de piel humana, preferentemente una mano, y extraer sus características estructurales más importantes.


La librería realiza las siguientes operaciones:

- Detección de las áreas de la imagen que contienen piel
- Extracción de los contornos de las áreas
- Determinación del contorno de mayor área
- Optimización del contorno
- Cálculo de la envolvente convexa del contorno
- Cálculo de los defectos de convexidad

Demo online:
http://www.inmensia.com/files/handtracking/demo/index.html

Para probar la demo es necesario utilizar un navegador moderno con soporte para WebRTC, que es la tecnología que permite a JavaScript acceder a la webcam directamente desde el navegador. Por ejemplo, Chrome 18 o superior, con el flag --enable-media-stream.

Para la detección de piel al final he optado por convertir los colores desde RGB hasta HSV y comprobar los valores de los canales H y V para determinar si están dentro del rango de la piel humana:

v >= 15 and v <= 250

h >= 3 and h <= 33

Las condiciones de iluminación son muy importantes y hacen que los colores sean detectados de forma muy distinta por la webcam. He tenido bastantes problemas ajustando los parámetros. Al final eliminando el equilibrado automático de blancos he conseguido una detección bastante estable.

Lo realmente importante es darse cuenta que hace sólo unos pocos meses era impensable pensar en realizar este tipo de aplicaciones sencillas de visión artificial en JavaScript.

Juan Mellado, 9 Mayo, 2012 - 18:54

Estoy trabajando en una nueva librería escrita en JavaScript. Esta vez estoy tratando de implementar un sistema de tracking, en especial de manos. Mi objetivo es ser capaz de detectar una mano que se encuentre dentro de una imagen y destacar sobre ella sus características principales. Ya tengo un prototipo bastante avanzado, como puede verse en la siguiente imagen:

Hand Tracking

La librería segmenta una imagen dada dividiéndola en regiones que contengan colores dentro del rango que caracteriza la piel humana (blanco). Asumiendo que la región más grande encontrada corresponde a una mano, ya que ese es el objetivo de uso de la librería. A continuación encuentra el contorno de la región (rojo), y sobre ese contorno calcula la envolvente convexa (azul) y sus defectos de convexidad (verde).

Los defectos de convexidad suelen ser de bastante utilidad, ya que se pueden usar para contar el número de dedos que tiene levantados la mano por ejemplo.

Viendo la imagen está claro que la librería ya cumple su objetivo, pero aún me quedan varias pruebas que quiero realizar antes de liberar los fuentes. La parte más complicada del proceso está siendo la primera, la detección de la piel humana. Ya había trabajado antes en el tema, pero me estoy encontrando con problemas debido a que mi webcam es MUY mala y no hay forma de que me proporcione fotogramas con los colores correctos. De momento me estoy limitando a utilizar imágenes estáticas, aunque tengo una demo que acepta como entrada vídeo directamente.

En el apartado de la documentación de referencia, para la detección de piel he probado tres sistemas distintos. Al final el que se encuentra ahora mismo implementado es el que se describe en esta página (en chino):

- http://blog.csdn.net/scyscyao/article/details/5468577

De hecho, la imagen de la mano que he puesto es de esa página. La he estado utilizando para comparar resultados. Espero que no haya problemas de copyright.

Antes de liberar la librería me gustaría revisar la implementación que tiene OpenCV de una técnica llamada "adaptive skin detection", que ajusta los parámetros de detección de piel humana en función de como varía la imagen fotograma a fotograma. Pero no estoy muy convencido, ya he hecho una primera prueba en JavaScript de la parte básica sobre una imagen estática y detecta menos piel que el método que tengo ahora mismo funcionando.

Temas: Java Spring
Juan Mellado, 7 Mayo, 2012 - 09:25

Spring FrameworkLa última tanda de artículos de la serie dedicada a Spring tratan el desarrollo de aplicaciones web, que es donde se utiliza el framework de forma más habitual. Los artículos son un repaso rápido de la documentación oficial de referencia, enumerando algunas de las facilidades más importantes que ofrece Spring a la hora de implementar servlets y handlers:

- Web MVC (1) - Configuración

- Web MVC (2) - Servlets

- Web MVC (3) - Controladores

- Web MVC (4) - Handlers

- Web MVC (5) - Modelos

- Web MVC (6) - Vistas

- Web MVC (7) - Tag Library

Esta parte de la documentación, junto a la dedicada a base de datos, es la más extensa. Y no es casual. Son las capas a las que normalmente más tiempo se le dedica durante el desarrollo de una aplicación. Y eso que me he dejado muchas cosas en el tintero, como la integración con otros frameworks, la creación de portlets, la escritura de webservices, ... y un largo etcétera.