Blog

Juan Mellado, 8 Junio, 2012 - 13:56

He desarrollado un emulador de ZX Spectrum en Dart. ZX Spectrum fue uno de los ordenadores más populares durante la década de los ochenta, y este año se cumplieron treinta desde su creación. Dart es un nuevo lenguaje de programación que está desarrollando Google. He llamado zx-dart al proyecto y lo he liberado como código abierto.

zx-dart

La versión de código nativo en Dart se puede ejecutar en Dartium, que es una versión de Chrome que incluye la máquina virtual de Dart. Aunque el rendimiento es pésimo, no alcanza ni un frame por segundo. Hay que tener en cuenta que Dart todavía está en desarrollo, las mejoras tienen que ir llegando poco a poco, además de que la especificación oficial del lenguaje cambia cada pocas semanas, por lo que el código escrito hoy puede que no funcione mañana.

Dart viene acompañado de una herramienta llamada (actualmente) dart2js que convierte el código Dart a JavaScript, de forma que se pueda ejecutar directamente en Chrome sin necesidad de la máquina virtual de Dart. Afortunadamente esta versión alcanza los 20 FPS en mi máquina y el emulador se deja probar, aunque para una simulación realista de un Spectrum debería alcanzar al menos 50 FPS.

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

El emulador que he implementado está basado en JSpeccy. Realiza una emulación básica de un Spectrum 48K, con carga de ROM y ejecución de BASIC. Le faltan muchas características básicas, como la generación de sonido o la posibilidad de cargar snapshots por ejemplo. Pero hoy en día hay muchos emuladores bastante completos para casi cualquier plataforma, por lo que no merece la pena complicar el desarrollo para reinventar la rueda. Quizás un port a Dart de algún emulador ya existente escrito en JavaScript podría ser una mejor opción.

Ha sido emocionante el primer arranque, después de múltiples fallos, y ver el famoso mensaje de copyright.

Temas: Java
Juan Mellado, 5 Junio, 2012 - 19:13

DukeHe subido un par de artículos nuevos a la serie que estoy dedicando a revisar algunas de las especificaciones para la web de J2EE. Los dos nuevos artículos tratan sobre Java Server Faces (JSF), el framework estándar para el desarrollo de aplicaciones que nació para sustituir a los tecnológicamente deprecados JSP.

La especificación de JSF es bastante extensa, por lo que he dividido el contenido en dos partes:

- JSF (1): Este primer artículo explica algunos de los conceptos básicos. Desde la configuración que se debe realizar para que una aplicación web utilice JSF, hasta como escribir páginas utilizando Facelets, así como definir beans, inyectar dependencias, definir reglas de navegación, implementar validadores, conversores y listeners, e incluso como construir plantillas y componentes.

En cada tema he procurado comentar las distintas alternativas, ya que por lo general la configuración se puede hacer utilizando ficheros XML o, preferentemente, anotaciones.

- JSF (2): En este segundo artículo me he centrado exclusivamente en las librerías de acciones estándar introducidas con JSF. Para cada tag hay una descripción y un pequeño ejemplo.

Las librerías de acciones de JSF incluyen una acción equivalente para elemento HTML estándar, acciones específicas para crear plantillas y componentes, y una librería auxiliar de acciones complementarias de propósito general.

A pesar de suponer una mejora considerable con respecto a JSP, en particular por la introducción de las plantillas y la orientación a componentes reutilizables, sigue siendo bastante el código que hay que escribir y la configuración que realizar, por lo que el uso de un IDE que permita diseñar las vistas de forma gráfica y genere automáticamente el código es hoy en día una opción bastante recomendable. No obstante, sigue siendo vital conocer el detalle de funcionamiento a más bajo nivel, sobre todo cuando aparecen los problemas o se quiere ir más allá de las opciones que facilita un IDE.

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.