Joan Garnet :: RIA Architecture

Papervision3D for dummies: Material

Joan Garnet — Sun, 26 Oct 2008 20:47:56 +0000

Lo prometido es deuda. Todo aquél que esté interesado en el material (slides + ejemplos) de la charla acerca de Papervision3D que ofrecí en Madrid durante el evento MIF onsite III puede descargarlo desde la entrada que he publicado en la web del AUG.

Enlace a la entrada: “Papervision3D for dummies”

Papervision3D for dummies: nueva charla para MIF onsite III

Joan Garnet — Fri, 10 Oct 2008 20:57:11 +0000

Lamentándolo mucho, Alberto Albericio, uno de los ponentes del evento MIF onsite III ha tenido que renunciar a sus 55 minutos de gloria en el estrado, dejando así un vacío importante ya que su charla era interesantísima: “Aplicaciones Colaborativas en Flex”.
Así, a última hora con apenas 1,5 semanas y un montón de trabajo por enmedio voy a intentar rellenar tan gran hueco hablando del único tema que puede llegar a estar al nivel del que propuso inicialmente Alberto:Papervision3D.
La charla, por su naturaleza básica y totalmente introductoria la he bautizado con el nombre “Papervision3D for dummies“, que se podría traducir cómo: Papervision3D para principiantes.
Así que nos vemos en Madrid este viernes que viene en MIF onsite III :)
No puedes faltar!!!

Registro, información y calendario

Made In Flex + Domestika + ASNativos == MIF onsite III

Joan Garnet — Wed, 17 Sep 2008 20:19:22 +0000

MIF onsite III es un evento totalmente gratuito dedicado a profesionales del sector web que trabajan con tecnologías de Adobe.
Esta tercera convocatoría del evento va a ser un festival de grupos de usuarios ya que para la ocasión se han unido tres de los grandes a nivel nacional: Made In Flex, Domestika y ASNativos.
Los ponentes son grandes profesionales todos y las charlas serán muy interesantes. Aquí dejo un resumen del programa. Par más detalle visitar la web del evento.

9.30 - 10.00: Apertura
10.00 - 10.30: Enrique Duvos: Keynote
10.30 - 11.25: Alberto Alcaraz: Optimización en Flex
11.30 - 12.25: Borja Delgado: Domestika, una comunidad online. Integración accesible de tecnologías
12.30 - 13.25: Carlos Rovira: Arquitecturas Avanzadas Flex/JEE - RIAlity
13.30 - 15.00: Comida
15.00 - 15.55: Angel Blesa: WedTool.com,una Startup sobre Flex
16.00 - 16.55: Alberto Albericio: Aplicaciones Colaborativas en Flex
17.00 - 17.30: Entrega premios concurso AIR.
17.30 - 18.30: Joseba Alonso y Xavi Beumala: Qué nos depara el futuro? Quieres ver que te va a aportar la plataforma Flash en un futuro inminente?

Aparte del evento se hará la entrega de los premios del concurso MIF AIR contest.

¿Cuándo? 17 de Octubre de 10:00 a.m a 6:30 p.m.
¿Dónde? Universidad Pontificia de Comillas en la sede de Alberto Aguilera, nº23
¿Cuánto? Gratuito
Formulario de registro en la misma web del evento

Nos vemos por Madrid!

The pragmatic programmer: ‘la ventana rota’ y otros cuentos

Joan Garnet — Tue, 16 Sep 2008 23:41:40 +0000

The Pragmatic Programmer es un libro que tengo hace algún tiempo. Lo voy leyendo y releyendo de vez en cuando porque siempre me sorprende lo ciertas que son las cosas que dice.
Si me preguntaran que qué quiero ser de grande diría que un pragmatic programmer :)
El paradigma del arte de la programación está descrito en este libro de forma brillante, con analogías de lo más acertadas y sentido del humor. Algunos títulos hablan por si solos…. como The cat ate my source code y Stone soup and boiled frogs.
No puedo dejar de citar alguna parte de un capítulo que me sorprendió bastante el día que lo leí por primera vez y que me viene a menudo a la cabeza cuál voz de la conciencia cuando por la razón que sea voy a hacer algo “feo”. Se trata de “la teoría de la ventana rota” (The broken window theory), dentro de un capítulo, Software Entropy, disponible online.
Lo he traducido a mi manera:

En el centro de las ciudades algunos edificios están impecables, mientras que otros son armatostes en descomposición. ¿Por qué? Investigadores en el campo del crimen y el desorden urbanístico descubrieron un mecanismo de activación, uno que muy rápidamente convierte a un edificio limpio, intacto, habitado en uno roto y abandonado.
Una ventana rota.
Una ventana rota, olvidada sin reparar por un tiempo substancial, inculca en los habitantes del edificio una sensación de abandono, de que no se cuida el edificio. Así que otra ventana se rompe. La gente empieza a descuidar el lugar y a dejar deshechos. Aparecen pintadas. Comienza ha notarse cierto daño estructural. En un espacio relativamente corto del tiempo el edificio empeora más allá de lo que los dueño están dispuestos a asumir y la sensación de abandono se convierte en una realidad.

La “Teoría de la ventana rota” ha inspirado departamentos de policía en Nueva York y otras grandes ciudades a atacar las pequeñas cosas para mantener las mayores a raya. Funciona: estando encima de ventanas rotas, pintadas y otras pequeñas infracciones ha reducido el nivel de crimen.

No vivas con ventanas rotas.

No vivas con ventanas rotas (mal diseño, malas decisiones o código pobre) sin reparar. Arregla cada una de ellas tan pronto como la descubras. Si no hay tiempo para repararla como es debido márcatelo con un comentario. Haz algo que evite que el daño se extienda y para demostrar que estas en ello.

Hemos visto sistemas limpios y funcionales deteriorarse rápidamente una vez las ventanas empiezan a romperse.

Pues verdades como ésta, otras explicadas de forma mucho más técnica, todo sea dicho, las hay una detrás de la otra…

Si te gusta aquí hay más info: http://www.pragprog.com/the-pragmatic-programmer/

Barcelona PHP Conference

Joan Garnet — Sun, 14 Sep 2008 21:52:19 +0000

El Barcelona PHP user group ha organizado la PHP international conference un evento que trae ponentes de todo el mundo a la ciudad de Cornellà, muy cerca de Barcelona este 27 de Setiembre (27-09-2008) .
Pinta pero que muy bien! solo hace falta ver la programación y los ponentes.
Éstas son las charlas:

Xdebug, por Derick Rethans
Website releases made easy with the PEAR installer, por Helgi Þormar
SQLite3, por Scott MacVicar
Text indexing and search libraries for PHP, por Zoë Slattery
Rasmus, think again! - Agile Framework == happy PHP Developer, por Arno Schneider
How to pimp high volume PHP websites, por Jens Bierkandt
Email in PHP, por Marcus Bointon
Tuning the usability of online applications using web analytics techniques, por Jordi Roura
eyeOS: Open Source Web Desktop System in PHP, por Pau Garcia-Milà

Si desarrollas con PHP no te puedes perder esta oportunidad… a ver si nos vemos por ahí :)

Enlaces:

Talleres subflash 2008 ( sbfl’08 )

Joan Garnet — Sun, 14 Sep 2008 18:00:19 +0000

Han pasado ya dos semanas desde que finalizaron los VI talleres de verano subflash.
Después de pasar por:

2003 Teruel
2004 Madrid
2005 Barcelona
2006 Oviedo
2007 Málaga [me lo perdí...]

este 2008 hemos estado en Alicante y debo decir que, como de costumbre, ha sido una gran experiencia.
¿Dónde será el año que viene? quién sabe…. cualquiera puede decidirlo. Y es que ése es el espíritu/lema del evento. Por y para los asistentes :)

Este año la gente de Alicante se ha ocupado de buscar un contexto ideal para el evento: La Universidad de Alicante, en San Vicente del Raspeig.
Aparte de la idoneidad del lugar creo que todos nos quedamos alucinados cuando vimos las instalaciones: las habitaciones, la sala de ponencias, el comedor, etc… un diez!

Claro está, el lugar es una parte importante que ayuda a perfilar el posible éxito del evento, pero el contenido acapara otra gran parte, y este año han habido 5+1 personas que se han ocupado de proporcionarlo:
( Todas las ponencias tienen su material colgado en el micro-site del evento: http://www.subflash.com/talleres/2008/php/sesiones.php )

Sábado 30, 10:00h “JSFL para automatizar procesos”:

Luis Adrían Rosas Wiedfeldt se ocupó de poner JSFL en su lugar. A lo largo de una interesantísima charla nos contó sus experiencias personales con esta tecnología en su trabajo diario y cómo la han implementado en su empresa para ahorrar tiempo de compilación y de realización de tareas repetitivas. A mi parecer fue una brillante presentación. Amena, divertida y completa en cuanto a contenido. Todo lo que se le puede pedir a una charla.

Sábado 30, 11:15h “Fundamentos SEO”:

Jorge Quintas habló de la mágia que hay detrás de la indexación en buscadores. Yo no pude asistir porque estuve ultimando mi charla…. pero por lo que he oído estuvo realmente bién! muchos hubieran alargado la ronda de preguntas unas horas :).

Sábado 30, 16:00h “De 2 a 3 en 45′”:

Esta corrió de mi cuenta. La finalidad de la charla fue romper con el mito que hay detrás de Actionscript 3 mostrando su cara más simpática, contrastando ejemplos de la versión 2 y 3 del lenguaje. Teniendo en cuenta que aproximadamente el 90% de los asistentes no han utilizado esta versión del lenguaje creo que fue acertado el escoger esta temática.

Domingo 31, 10:00h “‘Yo aquí he venido a hablar de mi blog”:

Armando Sotoca, la indiscutible perla del evento :) Este entrañable y simpático personaje sacado de los mismísimos [Q]Interactiva headquarters vino a contarnos su historia de blogger de éxito. Una charla realmente inspiradora. Desde el por qué, hasta el cómo pasando por un sinfin de anécdotas personales, datos estadísticos explicados y un largo etcétera. Su charla fue una de las más (la más?) largas! Si es que cuando se tiene el público en el bolsillo uno hace lo que quiere ;) Yo personalmente no dudaré en copiar algunos de sus métodos secretos para mantener viva la llama de este blog :)

Domingo 31, 11:15h “‘Social Networks Interactivas 2.0″:

Elad Rodriguez y Emiliano Velasco dieron una charla acerca de varios aspectos relacionados con las redes sociales. Es todo muy bonito, pero… cómo monetizar tu red social? de hecho… qué es exactamente una red social? y cosas así… Aparte de esto me gustó mucho la parte de la charla en la que nos contaron cosas más internas de su empresa (nitsnets) como por ejemplo el desarrollo e implantación de alguno de sus productos.

Domingo 31, 12h y pico “‘filmoteca”:

Ya es todo un clásico ver a Marc Palau subiendo al escenario y haciendo una sesión de vídeos de lo más freak. Este año no ha sido menos y hasta la hora de “El sorteo” nos estrujamos las abdominales a carcajada limpia.

El domingo, después de las charlas y de la sesión de vídeos los organizadores del evento sortearon un montón de regalos, ni más ni menos que 2 regalos seguros por cabeza! Entre los regalos había camisetas de Adobe, juegos de ordenador, libros, planes de alojamiento de CDMON, suites de aplicaciones de Adobe, cursos de formación y otros objetos como ratones, hubs USB, etc…. todo gentileza de los distintos sponsors: que han apoyado el evento como video2brain, cdmon, fx interactive, indexbook, loring-art, etc..

En resumen han sido 2 días muy intensos. He aprendido un montón de cosas, he podido ver a la gente que solo veo en este evento, he conocido nuevas caras, me he sentido comprendido entre tanto freak :p y finalmente he vuelto a casa con las pilas recargadas hasta el año que viene, y… a ver dónde nos llevarán esta vez!

Gracias a la gente de Alicante y a Sir Marcos González Sancho y la [Q]peolpe por hacer posible este evento!

Media:

Posts:

Andrés Karp: Yo aquí vengo a hablar de Subflash
Ramón Massip a.k.a. Sipi: Talleres Subflash 2008
BlocketPC: Talleres Subflash día 1
BlocketPC: Talleres Subflash Día 2
Emiliano Velasco: Subflash 2008 Alicante
Luis Adrián: Subflash 2008, vivencias
Armando Sotoca: Subflash 2008, despecida y cierre
[Q] Interactiva: Talleres Subflash 2008
Jorge Quintas: Talleres SubFlash 2008 - Más que satisfecho!

UMFlash: de UML a AS3 con StarUML

Joan Garnet — Sat, 16 Aug 2008 22:21:08 +0000

Hay una nueva herramienta disponible para generación de código AS3 a partir de diagramas de clase UML llamada UMFlash. Está basada en StarUML y ha sido desarrollada por UnderMedia a partir de un trabajo inicial de Digitaldogbyte.
No he tenido oportunidad de probarla porque me acabo de enterar pero seguro que le hecharé un vistazo en cuanto llegue de vacaciones (me voy mañana!).
Para los que quieran adelantarse aquí dejo el artículo de presentación de la herramienta.
Si alguien tiene a oportunidad de pegarle un vistazo feedback será bienvenido!

Strategy pattern

Joan Garnet — Sat, 16 Aug 2008 00:57:11 +0000

Descripción

A veces es necesario que ciertas funcionalidades en una aplicación sean intercambiables en tiempo de ejecución. Esto es, que en un punto determinado en el ciclo de ejecución de la aplicación se disponga de un grado de flexibilidad que permita ejecutar una misma acción de distintas formas sin que esto implique tener que implementar en dicha acción todas las posibles formas que puedan existir.
El patrón de diseño Strategy define una metodología que permite que esto sea posible de forma sencilla.
En realidad el concepto de Strategy está fuertemente relacionado con una de las bases de la programación orientada a objetos, el polimorfismo: poli(muchas)morfismo(formas), que es lo que permite que una clase pueda tener más de un tipo, el de la misma clase, el de su(s) superclase(s) y el de las interfaces que implementa (si nos ponemos puristas podríamos dejarlo en "las interfaces que implementa" ya que una clase es en realidad una implementación de una interfaz al fin y al cabo, ¿no?).

Implementación

Desarrollando un sencillo ejemplo se verá claramente cómo funciona.
Vamos a poner por ejemplo un sistema de cobro de una tienda virtual. Las tiendas viruales disponen de distintos sistemas de pago: Visa, PayPal, Google Checkout, etc... cada uno con una lógica de conexión a la pasarela de pago diferente. Sinembargo todos los sistemas de pago tiene algo en común, que se paga :)
Con esto ya tenemos todos los ingredientes necesarios para una implementación del patrón Strategy.
Los actores son la clase principal de la aplicación TiendaVirtual, la interfaz común de todos los sistemas de pago ISistemaDePago y finalmente las distintas implementaciones (estrategias) de dicha interfaz SistemaDePagoVisa, SistemaDePagoPayPal y SistemaDePagoGoogleCheckout.
Esto traducido a código sería así:

PLAIN TEXT

Actionscript:

// clase de la aplicación
public class TiendaVirtual{
private var sistemaDePago:ISistemaDePago;
public function seleccionaSistemaDePago( sistemaDePago:ISistemaDePago ):void{
this.sistemaDePago = sistemaDePago;
}
public function realizaPago():void{
if( sistemaDePago.pagar() ){
trace("Pago realizado!");
}else{
trace("Pago no realizado...");
}
}
}
// la interfaz común de todas las "estrategias" de pago
public interface ISistemaDePago{
function pagar():Boolean;
}
// las distinas implementaciones de ISistemaDePago (estrategias)
public class SistemaDePagoVisa implements ISistemaDePago{
public functino pagar():Boolean{
trace("Pagando con Visa");
// lógica de pago...
return resultadoDelPago;
}
}
public class SistemaDePagoPayPal implements ISistemaDePago{
public functino pagar():Boolean{
trace("Pagando con PayPal");
// lógica de pago...
return resultadoDelPago;
}
}
public class SistemaDePagoGoogleCheckout implements ISistemaDePago{
public functino pagar():Boolean{
trace("Pagando con Google Checkout");
// lógica de pago...
return resultadoDelPago;
}
}
// un posible uso de la aplicación...
var tienda:TiendaVirtual = new TiendaVirtual();
tienda.seleccionaSistemaDePago( new SistemaDePagoPayPal() );
tienda.realizaPago();

Beneficios

Es limpio y permite abstraer a la aplicación de la lógica de pago.
Los distintos proveedores de pasarelas de pago solo deben desarrollar sus estrategias de pago implementando la interfaz ISistemaDePago sin tener que saber cómo funciona cada sistema de tienda virtual.
Por otro lado se puede ver que si en algún momento se requiere añadir más sistemas de pago lo único que vamos a tener que hacer es añadir en nuestro classpath la nueva implementación de ISistemaDePago y compilar.

Inyección de dependencias

Si nos lo montamos de forma más dinámica para evitar el paso de la compilación incluso se podrían inyectar las dependencias cargándolas en tiempo de ejecución de un swf y accediendo a ellas utilizando las nuevas APIs de Reflection de AS3. Algo así:

PLAIN TEXT

Actionscript:

var nombreClase:String = 'SistemaDePagoVisa';
var urlDependencia:URLRequest = new URLRequest( nombreClase+'.swf' );
urlDependencia.applicationDomain = new ApplicationDomain(ApplicationDomain.currentDomain);
dependencia = new Loader();
dependencia.addEventListener(EventType.COMPLETE, dependenciaCargada);
dependencia.load( urlDependencia );
private function dependenciaCargada(e:Event):Void {
var referenciaISistemaDePago:Class = dependencia.loaderInfo.applicationDomain.getClass('com.tienda.'+nombreClase);
var sistemaDePago:ISistemaDePago = new referenciaISistemaDePago() as ISistemaDePago;
tienda.addSistemaDePago( sistemaDePago );// supongamos que TiendaVirtual tiene este método de inyección de sistemas de pago
}

Conclusión

En cualquiera de los dos casos el beneficio es claro, por un lado no hay necesidad de tocar el corazón de nuestra aplicación con el consiguiente peligro de introducir nuevos bugs, por el otro añadir un punto de abstracción que permite dar flexibilidad a un aspecto potencialmente cambiante.

Adapter pattern

Joan Garnet — Tue, 12 Aug 2008 20:23:43 +0000

El patrón de diseño Adapter es un sistema que nos permite que, en un momento dado en nuestra aplicación podamos utilizar una clase de un tipo incompatible como si fuera del tipo que realmente se requiere. Es decir, adapta una clase existente de tal forma que pueda ser utilizada en lugares dónde en principio no debería poder utilizarse.
Implementacionalmente el patrón es muy parecido al Decorator, pero conceptualmente cada uno está muy diferenciado del otro, y como que los patrones tienen mucho de éso, de proporcionar un lenguaje común que nos permita entendernos cuándo hablamos del uno o del otro pues es importante saber ver la diferencia.

Siguiendo la tónica del post anterior he buscado un ejemplo muy básico y casi caricaturesco de lo que sería un Adapter.
El ejemplo es el siguiente:

PLAIN TEXT

Actionscript:

class ConductorIngles{
public function drive(){
}
}
class ConductorEspañol{
public function conducir(){
}
}
// éste el el Adapter
class ConductorInglesAdaptadoAEspaña extends ConductorEspañol{
private var conductorIngles:ConductorIngles = new ConductorIngles();
override public function conducir(){
conductorIngles.drive();
}
}
class CarreteraEspañola{
public function nuevoConductor( conductor:ConductorEspañol ){
conductor.conducir();
}
}
var carretera:CarreteraEspañola = new CarreteraEspañola();
carretera.nuevoConductor( new ConductorInglesAdaptadoAEspaña() );

Igual es un poco drástico... pero supongamos que en las carreteras españolas solo pueden conducir ConductorEspañol(es). Si viene un británico de vacaciones y se trae el coche lo lleva crudo, porque las carreteras no están hechas para él. Entonces lo que tiene que hacer el individuo es ponerse un sombrero Mexicano ( si, en España suele pasar que la gente de fuera piensa que llevando uno de ésos se integra más en el folclore local :) ) y así hacerse pasar por un ConductorEspañol.
El sombrero Mexicano en el ejemplo anterior equivale a la clase ConductorInglesAdaptadoAEspaña y nos permite adaptar ConductorIngles para que se pueda utilizar su lógica de conducción; el método drive(); a través del método homólogo en ConductorEspañol; el método conducir().
Solo de este modo podremos añadir un ConductorIngles en una CarreteraEspañola, ya que como se puede ver el método nuevoConductor() espera como parámetro un ConductorEspañol.

Decorator pattern

Joan Garnet — Sat, 09 Aug 2008 00:26:30 +0000

ActionScript no soporta herencia múltiple, si alguna vez te has visto en una situación en la que te hubiera gustado que así fuera es muy posible que hayas llegado a algún recurso donde se explica lo que es el patrón de diseño Decorator o, porque no, que lo hayas implementado sin saber que tenía un nombre.

Un Decorator es una clase con la que se puede ejecutar funcionalidad de varias clases a la vez. Si se utiliza bien es equivalente a disponer de herencia múltiple pero sin los dolores de cabeza que ésta conlleva.
La idea básicamente pasa por componer una clase con funcionalidad de otra mediante la instanciación de ésta y la implementación de todos sus métodos.

Un ejemplo básico ( dedicado a mi suegra que escribe con las dos manos! ) para ilustrar una implementación:

PLAIN TEXT

Actionscript:

class Diestro{
public function escribeConLaDerecha(){}
}
class Zurdo{
public function escribeConLaIzquierda(){}
}
// ésta es la implementación de Decorator
class Ambidiestro extends Diestro{
private var zurdo:Zurdo = new Zurdo();
public function escribeConLaIzquierda(){
zurdo.escribeConLaIzquierda();
}
}

Aquí podemos claramente que la única forma de que un Ambidiestro pueda escribir con las dos manos es a través de la composición. Esto está bien si queremos adquirir la funcionalidad de un Diestro y de un Zurdo sin más, pero hay un pequeño fallo... podemos tratar a un Ambidiestro como un Diestro porque extiende de Diestro, pero en cambio si queremos tratar a un Ambidiestro como un Zurdo no vamos a poder porque no extiende de Zurdo.
Dicho de otra forma...

podemos hacer:

PLAIN TEXT

Actionscript:

var ambidiestroDeDiestro:Diestro = new AmbiDiestro();

pero NO podemos hacer:

PLAIN TEXT

Actionscript:

var ambidiestroDeZurdo:Zurdo = new AmbiDiestro();

Llegados a este punto la solución es utilizar una interfaz.
El ejemplo completo sería este:

PLAIN TEXT

Actionscript:

interface IZurdo{
public function escribeConLaIzquierda(){}
}
interface IDiestro{
public function escribeConLaDerecha(){}
}
class Diestro implements IDiestro{
public function escribeConLaDerecha(){}
}
class Zurdo implements IZurdo{
public function escribeConLaIzquierda(){}
}
// ésta es la implementación de Decorator
class AmbiDiestro extends Diestro implements IZurdo{
private var zurdo:Zurdo = new Zurdo();
public function escribeConLaIzquierda(){
zurdo.escribeConLaIzquierda();
}
}
// ahora si, un ambidiestro es un IDiestro y un IZurdo:
var ambidiestroDeDiestro:IDiestro = new AmbiDiestro()
ambidiestroDeDiestro.escribeConLaDerecha();
var ambidiestroDeZurdo:IZurdo = new AmbiDiestro()
ambidiestroDeZurdo.escribeConLaIzquierda();

Ahora si podemos tratar a un Ambidiestro como un Zurdo y como un Diestro a través de IZurdo e IDiestro respectivamente.

Un ejemplo en la vida real y muy común de una implementación del patrón Decorator es cuando queremos que una clase sea un EventDispatcher cuando ya hereda de otra clase que no lo es. La clase mx.rpc.AbstractService de Flex es un ejemplo de ello. Esta clase extiende de flash.utils.Proxy, que no es un EventDispatcher y mediante composición de una instancia de EventDispatcher e implementando la interfaz flash.events.IEventDispatcher pasa a ser un EventDispatcher en toda regla.