inmensia

Un señor llamado Tobias Schneider se ha currado un runtime de Flash escrito 100% en JavaScript. Sin dependencias externas, todo en JavaScript. Sí señor, con un par. Y además ha tenido el detalle de llamarlo Gordon, por aquello de "Flash Gordon", se presupone.

Para que nos entendamos, es como el plugin de Adobe que hay que descargarse e instalarse en el navegador para ejecutar los ficheros Flash. La gracia es que al estar escrito en JavaScript no hace falta descargar ni instalar nada, se procesa y ejecuta todo por parte del navegador, sin añadidos. Y esto lo hace "en teoría" totalmente independiente del sistema operativo o la plataforma en que se ejecute. O sea, si se tiene un navegador que pueda ejecutar JavaScript entonces se pueden ver ficheros Flash, dando igual que se esté en Windows, Unix, Mac, .... y se use Internet Explorer, Firefox, Chrome, ...

¿Y funciona? Pues parece que sí. El autor ha creado unas pocas demos.

¿Y tiene limitaciones? Pues por ahora bastantes. Sólo procesa ficheros de la versión 1 de Flash. Y teniendo en cuenta que la versión actual es la 10, pues como que más de uno va a echar en falta bastante cosas. En la página del proyecto hay una tabla con las etiquetas SWF soportadas.

¿Y funciona en todos los navegadores? Pues por ahora no. Hay una tabla de navegadores en los que se ha probado. Los básicos están, y llama bastante la atención que no lo hayan probado en IE.

¿Es de código abierto? Sí, mucho que cotillear ahí dentro.

¿Sirve para algo? En realidad no, ahora mismo no demasiado. Aunque indudablemente es una pequeña gran proeza técnica. Tener la posibilidad de ejecutar un fichero Flash en, por ejemplo, un iPhone, a más de uno le habrá dado algo que pensar. El tiempo dirá...

Hoy tenemos una nueva incorporación a Planet Stratos, el blog de Lucera Project, una empresa de videojuegos en ciernes localizada en Alicante.

Actualmente se encuentran desarrollando dos engines, llamados BrainWave (audio) y MindShake (gráficos/creación sencilla de juegos), con los que crear sus propios videojuegos, y que probablemente hagan públicos. A través de los posts de su blog se puede seguir el estado del avance de los mismos.

¡Bienvenidos!

Además de la triple conjunción de nueves que se produce hoy en el calendario gregoriano, se da también la casual circunstancia que esta web cumple, más o menos, otro añito más. Doce meses, o más o menos, cincuenta y dos semanas, ya que a veces parece que la vida avanza a ritmo de semanas más que de meses o de años. O tal vez estas sean meras apreciaciones de una memoria de pez. En cualquier caso, tocaba encender la velita de rigor, aunque no tenga ni idea de donde proviene esta pirómana costumbre, ni suela tener la politicamente correcta necesidad de celebrar aniversarios.

- Pero procedamos. Esto,... ¿alguien tiene un mechero?

Recuerdo que abrí esta web para algo más que complacer a esa asesina de felinos llamada curiosidad. Yo quería aprender exóticas tecnologías nacidas en un extraño medio emergente llamado Internet. No saber utilizar un buscador (google/emule), no tener dirección de correo (gmail/messenger), o no participar en una red social (facebook/youtube), eran motivos de exclusión social inmediata. Y antropológicamente hablando, todos sabemos por reencarnaciones anteriores, que se está más calentito dentro de la cueva con la manada, que fuera de ella a merced de los dinosaurios, aunque hombres y dinosaurios nunca hayan coincidido en el tiempo, salvo en las películas de Spielberg, intemporales todas ellas.

- Vela encendida. ¡Por un calentamiento global sostenible!

Esta web fue concebida para albergar disertaciones técnicas, pero en ocasiones la realidad fuera de la matriz consigue mosquear más que un NullPointerException durante una demo. Y es que debe ser por deformación profesional que uno no deje de buscar patrones por doquier, como las tendencias al alza. Todo sube. Como las temperaturas y la líbido, encendidamente consecuentes la una con la otra. O como el paro y la bolsa, absurdamente coincidentes el uno con la otra. O como los impuestos, justo cuando parecía que lo lógico era aliviar la presión fiscal. Extrañas decisiones para un profano al que nunca dejará de resultar extraño que Industria, Economía y Empleo sean tratadas como cosas distintas. Perfectamente compartimentadas. O que en época de crisis el presidente de un ejecutivo asuma la máxima responsabilidad en materia de... ¡Deportes!. Sí, ese mismo que declaró haber firmado un acuerdo con Rusia para follar (sic). +18 en relaciones internacionales.

- Ahora a soplar. Cual control de alcoholemia.

A estas alturas de la película tiene uno el callo del ratón muy endurecido para según que cosas. Motivo por el que, parafraseando una canción de Sabina, esta web lleva una temporada cerrada por derribo. Ha sido un último año muy variado, con altos y bajos muy pronunciados. Similar al perfil de una etapa de alta montaña de una Vuelta a España que transcurre por Holanda. Frase esta última que también podría formar parte perfectamente de una canción de Sabina, como aquella del belga y las soleares. Y además el futuro, apegado a sus costumbres, se muestra incierto.

- Y ya está apagada la vela recién encendida. ¿No resulta a veces genialmente ingenuo el espirítu humano?

Estos días he estado recibiendo un curso de formación introductorio a Struts y Spring. Dos frameworks bastante populares dentro del mundillo del desarrollo, principalmente web, para Java. Es bastante fácil encontrar referencias a ambos productos aquí y allá, pero encontrar a alguien que sepa decir con precisión para que sirven exactamente cada uno de ellos es algo más complicado. Sobre todo por que, a mi juicio, son soluciones que intentan abarcar demasiados aspectos a un mismo tiempo con el objeto de ofrecer una solución completa y exhaustiva, lo que hace que se pierda facilmente la perspectiva del conjunto si no se va cuidado. Hay muchos sitios donde mirar, y al final es fácil no saber donde poner la mirada. A algunos de estos mega-proyectos no les vendría mal una operación de "marketing" para venderse mejor.

Struts me lo han conseguido vender más o menos bien, aunque con matices. Pero Spring no me ha acabado de llegar, posiblemente por las circunstancias de mi proyecto actual, donde ya se encuentran resueltos muchos de los problemas que se plantearon gracias a un framework propio. Pero vayamos por partes.

Todo artículo que trate de Struts parece tener que empezar hablando irremediablemente del patrón MVC (Modelo-Vista-Controlador). Este framework vive de él. Y la idea general que he sacado del curso es que todo gira alrededor suyo, y en la separación de capas que proporciona. Al principio yo esperaba que me iban a mostrar un sistema de plantillas bastante elaborado, a la manera de muchos paquetes PHP, pero curiosamente esa parte la hemos visto al final. Lo primero ha sido ver como se pasa el control al framework de forma transparente a través del fichero web.xml habitual en las aplicaciones web. Lo que en un principio me ha alegrado, hasta que me he dado cuenta de que en realidad lo que se estaba haciendo era poner las referencias a los servlets en otro fichero. El mismo perro con otro collar. Afortunadamente, más tarde ha mejorado mi percepción al entender como se conseguía que las clases de negocio se dedicasen sólo y exclusivamente al negocio, las clases de presentación a lo suyo, y así sucesivamente. Siempre está bien tener este tipo de organización que garantice que todos hacen lo mismo en un mismo sitio, y Struts puede ser un punto de partida tan válido como cualquier otro.

Struts actúa como un proxy intermedio que controla el flujo de vida de las aplicaciones redirigiéndolo a nuestras clases en los momentos adecuados.

Una visión algo parcial de Struts nos permite verlo además como un conjunto de librerias, del que cada cual utiliza las partes que le interesa. Con este enfoque, la primera libreria que vimos fue la de internacionalización, ya que es algo bastante sencillo de entender de entrada, y su uso no implica cambios demasiados grandes en la forma habitual de escribir un JSP. De hecho es bastante simple, consiste en utilizar una fichero de recursos por cada idioma que soporte la aplicación, con las cadenas de texto, y hacer referencia a ellos a través de las etiquetas propias que proporciona Struts. El uso de etiquetas propias embebidas dentro de los propios JSP es una constante en este framework.

Otras librerías que vimos fueron las enfocadas a la creación y gestión de formularios, elementos muy frecuentes en la mayoría de aplicaciones webs transaccionales. Desde facilidades para tareas comunes, como el mantenimiento de los valores previos introducidos entre llamada y llamada al servidor, pasando por un tratamiento casi transparente de las excepciones, hasta el control de errores y validación de campos de entrada de forma centralizada. Todo ello mediante la escritura de clases que reciben directamente la información a tratar en cada caso, y que son llamadas por el propio framework que controla en todo momento el flujo de proceso de la aplicación. Siendo quizás la parte más representativa de esta parte, el hecho de que los nombres de las clases a las que tiene que llamar el framework residen en ficheros XML, aunque lógicamente las clases que escribimos están obligadas a implementar determinadas interfaces para que puedan ser llamadas correctamente.

Por lo que respecta a Spring, su patrón de diseño clave es el de la inversión de control, aunque el framework en su conjunto abarca muchas áreas. Por una parte la gestión de la capa de acceso a datos (DAO y ORM), por otra parte la de gestión del negocio (J2EE), y por otra parte la capa de presentación. Lo que viene a ser otra vez el omnipresente patrón MVC. Como curiosidad, hay que mencionar que Spring ofrece soporte de forma nativa para el uso de programación orientada a aspectos, de forma que nos permite inyectar código propio en clases ajenas. Sobre esto último, durante el curso, vimos la evolución que ha sufrido el framework, y las posibilidades mejoradas que ofrece al respecto la versión 2.0, aunque a mi parecer no tantas como otras soluciones creadas especificamente para este propósito. De hecho, esto es un incoveniente que se plantea para muchas de las funcionalidades que ofrece el framework. Como su gestor de transacciones por ejemplo, que se queda corto frente a un servidor de aplicaciones normal.

En la práctica el uso de Spring es similar al de Struts, en lo que al uso de ficheros XML se refiere. El peso de la configuración recae en el uso de "contextos", ficheros en los que a grandes rasgos se definen las clases concretas que debe utilizar el programa. Lo que de entrada puede sonar algo extraño, ya que estamos acostumbrados a instanciar objetos de un paquete específico en nuestro código fuente. La ventaja de este enfoque es que permite modificar los paquetes que debe utilizar una aplicación de manera indirecta, minimizando así las dependencias "hardcoded" entre componentes. No obstante, esto es sólo una minúscula parte de la potencia que ofrece este enfoque. Por ejemplo, en un fichero de contexto podemos indicar que un determinado objeto se trate mediante el patrón Singleton, de forma que sólo se instancie una única vez a lo largo y ancho de toda la aplicación. Pero las ventajas no acaban ahí, ya que es posible incluso indicar las clases a utilizar al instanciar los parámetros de los constructores, e incluso de variables de instancia. Es evidente que en la práctica todo esto tiene un carácter bastante técnico.

Spring, entre otras muchas cosas, permite reducir las dependencias entre los componentes de una aplicación declarando de forma independiente las clases concretas a utilizar en cada caso. Y proporciona patrones, interfaces y facilidades para la integración con otros paquetes populares, como Hibernate, por citar sólo uno, e incluso con el propio Struts, minimizando el impacto del uso de los mismos.

En cualquier caso, hablando ya de una forma más general, lo que no me ha convencido de ninguna de las maneras, es la aseveración de que estos frameworks permiten cambiar el comportamiento de una aplicación sin tener que tocar el "código fuente". Y por una razón muy sencilla. En el momento que me obligan a escribir el nombre de una clase en un fichero XML, ese fichero pasa a formar parte de mi "código fuente". Ese fichero XML se tiene que distribuir junto el resto de la aplicación, y ese fichero XML hace referencia a una parte de mi código. Tratando de ser un poco magnánimo, es fácil entender que en realidad esto es algo que llevamos haciendo toda la vida, como cuando parametrizamos el nombre de un driver de acceso a base de datos en un fichero de configuración. La clase del driver no suele ser parte de nuestro código, pero no por ello deja ser código. Eso sí, por favor, que no me lo vendan como si ambas cosas fueran casos distintos.

En cualquier caso, a mi me parece un atraso que en pleno siglo XXI se sigan escribiendo JSP y XML prácticamente a mano. Los ficheros de texto son muy complicados de validar, y los editores normalmente no pueden detectar los errores semánticos que se cometen habitualmente al escribir cadenas de texto. Y de los "scriptles" mejor ni hablo.

En estos cursos tan intensivos de paquetes tan grandes es fácil verse saturado por la cantidad de información que se recibe. Uno está acostumbrado a hacer las cosas de una forma determinada en el día a día, y de pronto se te plantea, no una, sino cuatro, cinco, seís, ... formas distintas de hacer una misma cosa con una herramienta que estás viendo por primera vez. Agravada además la experiencia por el hecho de que todo este tipo de software en particular se encuentra saturado por una cantidad ingente de abreviaturas, siglas, acrónimos, etiquetas, y los omnipresentes ficheros XML con sus inmumerables posibilidades disponibles como hilos conductores de todo el proceso.

Sin embargo, superado el "shock" inicial, es recomendable hacer una pausa y pararse a analizar todo desde la distancia. A mi juicio, la principal dificultad de estos frameworks la plantea el hecho de que requieren una visión estratégica del desarrollo del software, es decir, a muy largo plazo. Las ventajas de los patrones de diseño que implementan estas soluciones son el tipo de artificio que se supone que debe tener presente en todo momento un "arquitecto de sofware". Para un "programador de a píe" no dejará de ser una forma de hacer las cosas, un poco rebuscada quizás. La separación de capas, la posibilidad de poder cambiar el comportamiento de diversos aspectos de una aplicación modificando un, llamémosle "fichero de configuración", la reducción de dependencias entre paquetes, o la posibilidad de inyectar código de forma casi arbitraria, es algo grande, muy grande en realidad.

Si trabajas para una empresa/proyecto que usa un framework propio, puede que estos paquetes no te resulten demasiado atractivos, aunque resuelvan ciertas cosas de mejor forma que los estás haciendo tú. Pero si no estás trabajando con ningún paquete de estas características, entonces son una alternativa seria a considerar. Aunque abrumen un poco, requieran paciencia al principio para entender la filosofía de diseño, no se presenten como el típico IDE visual de drag and drop, y haya que dedicarles un tiempo hasta conseguir definir un buen flujo de trabajo que se ajuste a nuestras necesidades.

Después de conseguir generar un gráfico de fondo más o menos decente con GIMP, ahora me tocaba buscar una forma rápida de crear controles de GUI personalizados, con la idea de poder adaptarlos a la temática de los juegos. He optado por usar Inkscape, y el resultado, como puede apreciarse en la imagen, ha sido bastante espectacular.

He puesto los botones con texto y sin él, ya que varía mucho el aspecto final en función del tipo de letra utilizado. He tratado de escoger unas fuentes de texto que se adaptasen bien al estilo de cada botón en concreto, aunque la verdad es que elegir fuentes es algo que se me hace bastante pesado.

El botón azul es el que enseñan a hacer en prácticamente todos los tutoriales. Muy elegante, con ese brillo redondeado en la parte superior tan característico. De hecho, he estado mirando algunas webs y me ha hecho gracia empezar a reconocer ese estilo. Antes no era más que un botón, ahora aprecio la forma, los degradados, las transparencias, ... como un oido entrenado distingue entre los distintos instrumentos de una orquesta, en vez de apreciar sólo el conjunto.

El botón rojo ha sido mi primer experimento después de hacerme los tutoriales. La verdad es que me recuerda un poco al estilo de la marca Coca-Cola, aunque no era mi intención. Yo lo que quería era un superficie de brillo que no fuera una simple región uniforme en la parte superior, sino algo más estilizada. La fuente de texto no me gusta mucho, o quizás su color.

El botón verde tiene un aspecto un poco "retro". Ha sido otro pequeño experimento en busca de un estilo más burdo en vez de con tantos brillos como los anteriores. Tiene un compañero rojo que pone "Stop" y con el que forma una bonita pareja.

Inkscape mola mucho.