Planeta Código

MadeInFlex

Anuncio oficial del Packager for iPhone

Septiembre 15th, 2010 - [Enlace local]

Adobe ya ha hecho oficial que el Packager for iPhone estará en Flash Professional CS5, junto con el AIR SDK 2.0.1 para poder desarrollar aplicaciones nativas sobre los dispositivos iOS.

Seguid leyendo la información en la página oficial del producto.

» Leer más, comentarios, etc...

MadeInFlex

El nuevo Flash Builder: Burrito

Septiembre 15th, 2010 - [Enlace local]

Adobe ha anunciado que están trabajando en una nueva versión de Flash Builder llamada “Burrito”. En esta versión quieren da más potencia al IDE y que los developers ganen más productividad.

Aquí os dejo el enlace.

» Leer más, comentarios, etc...

Bitácora de Javier Gutiérrez Chamorro (Guti)

Como hice con CP/M en vivo, hoy os muestro Amiga Workbench 3.1 corriendo bajo un Commodore Amiga 4000.

En en principio de los 32 bits, pude hacerme con un Amiga 500 básico (M68000 a 7,14 Mhz, unidad de disquete de doble densidad, un increíble joystick Telemach, y nada más). Pese a que el Amiga era unos 7-8 años más antiguo, todavía daba bastantes repasos a nivel multimedia a los 386 y 486 de la época, y a mi me hizo pasar grandes ratos.

El declive del Amiga, sobretodo en Europa estaba en marcha, aunque eso no quita que hubiera deseado un Amiga 4000T, con su M68040 (luego muy utilizado por Apple).

Para desquitarme, aquí os muestro un video de un A4000 ejecutando Workbench. Desde ahí, ejecutamos Amiga Spectrum (ASp) 0.75, un emulador de Sinclair Spectrum que ejecuta un +3 en BASIC. Luego se lanza AWeb-II 3.4, una navegador web de Amiga, para que os convenzáis de que no es tan obsoleto como os podría parecer.

» Leer más, comentarios, etc...

Bitácora de Javier Gutiérrez Chamorro (Guti) » Programación

Workbench 3.1 en vivo

Septiembre 14th, 2010 - [Enlace local]

» Leer más, comentarios, etc...

4 bits blog

Forzar validación con JAXB

Septiembre 14th, 2010 - [Enlace local]

Aunque parezca mentira, no son tantas las empresas que saben lo que significa trabajar con XML. Sí, ellos desarrollan una aplicación que utiliza XML, te pasan una DTD o XSD y búscate la vida con las validaciones que ellos no han hecho. Porque validar, lo que se dice validar, debe ser de cobardes. En el mejor de los casos (es decir, cuando no tratan el XML como texto plano), utilizarán algún tipo de DOM que les facilite la tarea de buscar las etiquetas. Pero la labor de garantizar la calidad del XML se deja al Espíritu Santo. Y en ésas llegas tú todo gallo con JAXB, un framework para trabajar con XML.

Lo bueno de utilizar un framework para tratar el XML es que te aseguras la calidad del mismo al trabajar con el modelo de objetos creado a partir de la definición de dicho XML (las mentadas DTD o XSD). De esta manera, si el elemento A pertenece a B y es obligatorio, al construir el XML te saltarán errores si no cumples con el modelo. Pero, ¿realmente te aseguras la calidad del XML? Pues la respuesta es… depende.

Con JAXB vas todo feliz y construyes tus objetos a partir de la XSD de turno, generas todo tu código y haces el marshall con toda confianza. Por ejemplo:

Object mensaje = getMensaje();
ByteArrayOutputStream baos = new ByteArrayOutputStream();
JAXBContext jaxbc = JAXBContext.newInstance(MI_CONTEXTO);
Marshaller mar = jaxbc.createMarshaller();

mar.marshal(mensaje, baos);
StringBuilder sbmensaje = new StringBuilder(baos.toString());
baos.close();
return sbmensaje;

Tú sigues todo feliz porque las pruebas dicen que todo está bien, se lo envías a tu cliente, éste empieza a probar y, claro, cuando te dicen que el XML peta no te lo crees. Pero peta. JAXB, como buena tecnología Java, tiene varios bugs. Y si tu XSD de marras incluye limitaciones de longitud de cadenas o patterns (por poner un par de ejemplos), entonces no valida una mierda. Sí, te construye un XML muy bonito, muy parecido a la XSD que te hayan dado… pero que no tiene porqué ser válido.

¿La solución? Forzar al marshaller a que valide contra el esquema (lo que en teoría no debería ser necesario). El siguiente código iría en la línea en blanco del código anterior, justo antes del marshall:

Schema mySchema;
SchemaFactory sf = SchemaFactory.newInstance("http://www.w3.org/2001/XMLSchema");
mySchema = sf.newSchema(this.getClass ().getResource ("/ESQUEMA.xsd"));
mar.setSchema (mySchema);

Con esto al construir el XML ya se pregunta a cada campo hasta la marca de pasta de dientes que utiliza la placa base. Y os habréis ahorrado un mosqueo de 3 pares con el cliente.

Truco Extra: La clase XmlGregorianCalendar también tiene un bug por el que nunca os escribirá la fecha. O mejor dicho, siempre lo hace en formato UTC. Teóricamente (repito, teóricamente) para el tipo Date debería ser válido, pero si vuestro cliente es un tocapelotas al que además no le caes bien se puede poner muy pesadito con el tema.

» Leer más, comentarios, etc...

Cerebro en la Sombra » Técnico

Adobe AIR XIII – Copiar y pegar desde un DataGrid a Excel

Septiembre 14th, 2010 - [Enlace local]

Una de las típicas cosas que necesitamos siempre en una aplicación que presenta una lista de datos es la opción de exportar a Excel. En el caso del que hablamos hoy, necesitaba copiar los datos que se presentaban en un DataGrid de una aplicación AIR. La solución fácil habría sido lanzar una tarea de servidor que, con ayuda de alguna librería de conversión a formato Excel, devolviese el archivo xls. Pero no me gustaba la idea ya que implicaba una latencia absurda, si ya tengo los datos en mi aplicación, ¿por qué pedirlos de nuevo al servidor?

La solución que se me ocurrió es muy sencilla, copiar los datos del DataGrid al portapapeles de manera que se puedan pegar en un archivo Excel automáticamente, y que, por supuesto, mantenga el formato.

Lo complicado de todo esto no es copiar los datos sino mantener las columnas. En realidad no es que sea difícil, más bien hay que saber como generar la cadena de texto para que Excel la entienda. La solución es simplemente generar una cadena de valores separados por tabuladores y copiarla al portapapeles, automáticamente al pegar en Excel éste entenderá el formato de columnas y filas a la perfección.

Sabiendo la teoría, pasemos a la práctica. Lo que haremos será, para el DataGrid en cuestión, recorrer una a una todas sus columnas y recuperar el valor del DataProvider en ella. Tan sencillo como esto:

private function DataGridToExcel(dataGrid:DataGrid):String{
var cadena:String = "";
var valor:String = "";
var saltodeLinea:String = "\n";
var data:Array;
if (Capabilities.os.indexOf( "Mac" ) >= 0)
saltodeLinea="\r";
for (var i:int = 0;i< dataGrid.columns.length-1)
cadena+= ‘"’ + dataGrid.columns[i].dataField+ ‘"’;
if (i < dataGrid.columns.length-1)
cadena+= "\t" ;
}
cadena+= saltodeLinea;
data= ArrayCollection( dataGrid.dataProvider ).source;
for each (var item:Object in data){
for(var k:int=0; k < dataGrid.columns.length; k++) {
if (dataGrid.columns[k].labelFunction != undefined){
valor= dataGrid.columns[k].labelFunction(item, dataGrid.columns[k]);
}else{
valor= item[ dataField ];
}
var pattern:RegExp;
if (valor){
pattern = /["]/g;
valor= value.replace( pattern, "" );
valor= ‘"‘ + valor+ ‘"’;
}else{
valor= ‘""’;
}
cadena+= valor;
if (k < dataGrid.columns.length – 1){
cadena+= "\t";
}
}
cadena+= saltodeLinea;
}
return cadena;
}

A mi me gusta añadir la opción como menú contextual del DataGrid, de manera que al hacer click con el botón derecho sobre el mismo se abra un menú con la entrada “Copiar a Excel“. Para hacerlo de manera reutilizable podemos hacer una llamada de este estilo en los DataGrid donde queremos utilizarlo:

private function addCopyEventDtg(dtg:DataGrid):void{
var _contextMenu:NativeMenu=new NativeMenu();
var _copyMenuItem:NativeMenuItem = _contextMenu.addItem(new NativeMenuItem("Copiar a Excel"));
_copyMenuItem.addEventListener(Event.SELECT, function(event:Event):void {
System.setClipboard( DataGridToExcel(dtg) );
});
dtg.contextMenu=_contextMenu;
}

Y lo lanzamos de la manera más obvia:

addCopyEventDtg(nombreDeTuDataGrid);

Este sería el resultado:

No se a vosotros, a mi me sirve , y queda muy aparente la cosa .

» Leer más, comentarios, etc...

Picando Código

¡Feliz 25 aniversario Super Mario Bros!

Septiembre 13th, 2010 - [Enlace local]

No quería dejar pasar la oportunidad para homenajear a mi amigo Mario. Hoy se cumplen 25 años del lanzamiento de Super Mario Bros., la misma edad que yo

Mario

Recuerdo perfectamente la primera vez que jugué a Super Mario Bros. Mi padre había ido de viaje por trabajo, y a la vuelta se trajo una máquina medio rara que nunca había visto. La conecta a la tele, y empiezan a aparecer colores raros en la pantalla. “De esos que hay en las maquinitas y en las computadoras”. Se trataba de lo que era conocido en éstas latitudes como “Family Game” – una versión pirata del Famicom japonés.

Mi padre empezó a mostrarme los juegos, y entre ellos estaba Pac-man, Tetris (de los que ya conocía) y ahí aparece Mario. Cuando me dió el control lo primero que atiné a hacer fue agarrar el control de forma vertical (al estilo mando de Wii). Probablemente no habría despegado la mirada de la pantalla en todo el tiempo para ver a mi padre jugando con el control de forma horizontal e imitarlo.

Literalmente hubo un antes y un después de ese momento. A partir de ahí, me volví un fanático de Nintendo, y todas las instancias de Mario que existieran. Hoy en día sigo teniendo mis consolas Nintendo con mucho cariño y coleccionando juegos.

Mi colección está un poco “vieja” ya que cuento con el querido NES (obviamente una copia de Super Mario Bros), Super Nintendo, Gameboy Color, Nintendo 64 y Nintendo DS. Estoy fuera de la generación Gamecube / Wii (por lo que no he probado las nuevas instancias de Mario), pero ya me voy a poner al día.

Así que desde Picando Código, este post como homenaje. Gracias Mario, gracias Shigeru Miyamoto por presentarnos este mundo (además de otros tanto) que nos vienen acompañando de toda la vida, y gracias Koji Kondo por componer esa clásica música.

Comparte:

» Leer más, comentarios, etc...

Picando Código

¡Feliz día del programador!

Septiembre 13th, 2010 - [Enlace local]

13 de setiembre, el día 256 del año, ¡nuevamente el día del programador! El cuarto día del programador que festejo con Picando Código:

Día del programador 2007
Celebré programando en el trabajo con .NET, y algoritmos en C en casa.

Día del programador 2008
Celebré con Java

Día del programador 2009
Tras unos meses trabajando en gestión, me reivindiqué como programador volviendo al código con PHP y jQuery. Terminé el año viviendo en Montevideo

Como todos los años, aprovecho este día para hacer un comentario de en qué he estado programando recientemente. Este año estoy trabajando con Java nuevamente. He aprendido mucho del lenguaje recientemente. Estuve investigando algo de Android, y en lo laboral vengo aprendiendo y usando Spring (la inyección de dependencias es buenísima).

Además, como se acerca la RubyConf, estoy con una idea de implementar un proyecto en RubyOnRails. Así aprendo de una vez a usar esta tecnología tan interesante, y voy un poco más preparado a la conferencia. Probablemente aproveche cuando llegue del trabajo para empezar a leer documentación y diseñar mi proyecto.

Feliz día a todos los programadores. ¿En qué andan programando los lectores este año?

Comparte:

» Leer más, comentarios, etc...

Picando Código

¡Inscripciones abiertas para la RubyConf Uruguay 2010!

Septiembre 13th, 2010 - [Enlace local]

Por julio les comentaba sobre la RubyConf Uruguay 2010. De a poco en su sitio web ha ido apareciendo más información que nos adelanta que se tratará de un evento de primer nivel.

RubyConf Uruguay 2010

En primer lugar, las inscripciones están abiertas a un precio (en mi opinión) muy accesible para la cantidad de oradores internacionales que se estarán presentando. Incluso hay un precio promocional para los que nos inscribamos antes del 30 de setiembre:

El precio para estudiantes es USD 35 y será USD 45 a partir del 1ro de octubre.
El precio para no estudiantes es USD 45 y será USD 60 a partir del 1ro de octubre.

Puede pagar con paypal, tarjeta de crédito, depósito bancario o en efectivo.

La calidad de la conferencia asegura un nivel internacional que vale mucho la pena:

Tendremos oradores internacionales y habrá interpretación simultánea inglés-español para que todos puedan apreciar las charlas en inglés.

Pueden ver la lista de oradores con información sobre cada uno de ellos. Pero aquí están los nombres por orden alfabético: Aaron Patterson, Blaine Cook, Blake Mizerany, Brian Ford, Carmen Diaz Echauri, Charles Nutter, David Chelimsky, Emilio Tagua, Evan Henshaw-Plath, Federico Brubacher, Federico Romero, Gabriel Ledesma, Ian McFarland, Ignacio Facello, Ismael Celis, Juan Maiz, Kevin Gisi, Luis Lavena, Michel Martens, Santiago Pastorino y Scott Chacon.

Agenden en su calendario:

29 y 30 de octubre – aproximadamente de 9 a 20 horas
Auditorio de la Torre de las Telecomunicaciones, Montevideo, Uruguay.

Comparte:

» Leer más, comentarios, etc...

Picando Código

Invitación al 1er Open Space Montevideo

Septiembre 10th, 2010 - [Enlace local]

A los que les interese, se va a realizar un Open Space sobre metodologías ágiles este sábado.
Les paso el link con los detalles:

1er Open Space Montevideo

Te invitamos a participar en el primer Agile Open Space impulsado por el Grupo Scrum de Uruguay.
El evento se realizará el sábado 11 de setiembre de 2010, desde las 10am hasta las 4pm en Microsoft Uruguay, Cebollatí 1474, Mercosur Business Center, piso 5º.

El tema central son los procesos y el desarrollo ágil, ya sean metodologías o herramientas.

Para asistir, no hay que estar preparado para nada. Se puede ir a escuchar y a preguntar cualquier cosa que no sepas / no entiendas, o quieras saber más sobre metodologías ágiles. Van a ver unos cuantos referentes del tema, y los temas de conversación se van a definir en el momento.

Si les interesa, es ideal para ir a aprender más y acercarse a la comunidad ágil en Uruguay.
Además es bastante interactivo, así que cada uno decide su nivel de participación, mas allá de la experiencia o conocimiento que tenga con el tema.

Comparte:

» Leer más, comentarios, etc...

MadeInFlex

Anuncio de Apple: IPhone admitirá aplicaciones Flash

Septiembre 10th, 2010 - [Enlace local]

Apple ha anunciado que levanta las restricciones que afectaban directamente al Packager para IPhone de Adobe, una característica de Flash Professional CS5. De esta manera podremos desarrollar aplicaciones Flash que podrán ser libradas fácilmente a dispositivos iOS.

Os dejo el enlace aquí para que podais leer la noticia.

» Leer más, comentarios, etc...

knocte :: MonoTema

Version Tolerant Serialization with Mono

Septiembre 8th, 2010 - [Enlace local]

(Zoot Woman - Lonely By Your Syde)During the last months I've kept working {with|on} Mono, but not working for Novell anymore.Today I'm proud to blog about a bit of work I've done on Mono towards a better Binary Serialization experience:mono-api-info command now can output ABI instead of API if you append the flag --abi. It has been useful for us in LindenLab while working on binary serialization

» Leer más, comentarios, etc...

Fetishcode

QTJava.zip y JDeveloper no arranca

Septiembre 7th, 2010 - [Enlace local]

» Leer más, comentarios, etc...

Picando Código

Java: StringBuilder y StringBuffer

Septiembre 7th, 2010 - [Enlace local]

Java

A continuación un pequeño conocimiento de la plataforma Java que me gustaría compartir por acá. Recientemente tuve que explicar la diferencia entre usar un StringBuilder y un StringBuffer. Recuerdo perfectamente haber aprendido la diferencia académicamente. Pero al momento de responder, me quedé en blanco.

Para empezar, hay que conocer un poco la clase String. Un objeto String tiene la cualidad de ser un objeto inmutable. Esto quiere decir que una vez que es instanciado, no puede cambiar su estado. Por ejemplo en el siguiente código:

String miString = "   Picando Código   ";
miString.trim(); //método para acortar los espacios
System.out.println(miString);

La segunda línea llama a un método de la clase que devuelve una copia del objeto sin espacios en los extremos del String. Pero al hacer un println, vamos a ver en la salida estándar:

"   Picando Código   "

ya que el String no ha cambiado. Si quisiéramos que el String “cambie”, haríamos algo así:

String miString = "   Picando Código   ";
miString = miString.trim();
System.out.println(miString);

Pero lo que estamos haciendo ahora, es usar una copia del objeto y modificándolo. El println mostrará

"Picando Código"

Pero habremos usado dos objetos para lograr esto. Lo mismo pasa a la hora de concatenar Strings con el operador “+”. Podemos hacer lo siguiente:

String blog = "Picando";
blog += " ";
blog += "Código";
System.out.println(blog);

El resultado final del String será el mismo: “Picando Código”. Pero al ser String un objeto inmutable, con cada concatenación, estamos creando un objeto nuevo. Si bien en pocos objetos no es importante, a la hora de trabajar con muchos String, sería un despilfarro de memoria. Por ejemplo si recorriéramos una colección y quisiéramos agregar algo a un String por cada elemento, tendríamos el heap lleno de objetos String que no nos importan más…

Esto sería la teoría, aunque aparentemente a partir de la versión 1.4 de la JDK, el código:

String miString =  "Picando" + " " + "Código";

Se compilaría a:

miString = new StringBuilder().append("Picando").append(" ").append("Código").toString();

De todas formas, Java provee soporte especial para la concatenación de Strings con las clases StringBuilder y StringBuffer. Un objeto StringBuilder es una secuencia de caracteres mutable, su contenido y capacidad puede cambiar en cualquier momento. Además, a diferencia de los Strings, los builders cuentan con una capacidad (capacity), la cantidad de espacios de caracteres asignados. Ésta es siempre mayor o igual que la longitud (length) y se expande automáticamente para acomodarse a más caracteres.

Un String puede convertirse en StringBuilder instanciando un StringBuilder y pasando el String como parámetro. A su vez, un StringBuilder puede convertirse en un String con el método toString().

Los operadores principales de la clase StringBuilder son append e insert. Éstos se implementaron sobrecargados para aceptar cualquier tipo de datos. Cada uno convierte un dato en String y concatena o inserta los caracteres de dicho String al StrinBuilder. El método append agrega los caracteres al final de builder mientras que insert los agrega en un punto específico. En general entonces es equivalente escribir:

StringBuilder sb = new StringBuilder;
sb.append(x); //equivale a:
sb.insert(sb.length(), x);

He leído varios fundamentos a favor y en contra de concatenar Strings y usar StringBuilder, discutiendo que no hay diferencias. En este momento no encuentro una fuente técnica que ponga fin a esa discusión. Personalmente al ser String un objeto inmutable, me suena a más coherente usar un StringBuilder para esta función, pero con las optimizaciones de la JDK actualmente, parece que en rendimiento sería lo mismo concatenar Strings que usar un StringBuilder.

Bien, hasta acá hice un repaso de las clases String y StringBuilder. Pero no respondí a la pregunta:

¿Cuál es la diferencia entre un StringBuilder y un StringBuffer?

La diferencia entre un StringBuilder y un StringBuffer es que un StringBuffer provee métodos sincronizados por lo que es seguro usarlos en un ambiente multi-hilos. Los métodos son sincronizados donde sea necesario, para que las operaciones en cualquier instancia de un StringBuffer puedan comportarse como si ocurrieran en serie de manera consistente con el orden de las llamadas a los métodos hechas por cada hilo.

Generalmente es más común el uso de StringBuilder. Usar StringBuffer en un ambiente de un solo hilo de ejecución no tiene sentido, y al tener métodos sincronizados, es más lenta en general.

Así que ahí tienen algo que nunca me voy a olvidar, la diferencia entre StringBuilder y StringBuffer
Lo bueno de posts como éste son reafirmar conocimientos, y que generalmente se genera un poco más de conocimiento con el intercambio con los comentarios (bienvenidos sean comentarios, correcciones y demás aportes sobre el tema).

Comparte:

» Leer más, comentarios, etc...

MadeInFlex

¿ Eventos o señales ?

Septiembre 7th, 2010 - [Enlace local]

El sistema de eventos de ActionScript 3 ha sido objeto críticas en los últimos tiempos. Indudablemente es una de las piezas claves sobre las que se sustenta el desarrollo de aplicaciones Flex/Flash y de ahí su amplia utilización. A continuación resumiremos las más relevantes.

Los eventos.

Los eventos se identifican mediante un tipo de dato “String”, definido como una constante pública y estática, el mismo dato que se utiliza para registrar un manejador para ese evento. Eso implica que como desarrolladores debemos ser cuidadosos en escoger un valor que identifique de forma única al evento, de lo contrario podemos observar un comportamiento que no es el esperado en nuestras aplicaciones.

La semántica de este valor es otro elemento a tener en cuenta. Si estamos construyendo un API o un componente que será utilizado por otros desarrolladores es muy importante escoger un valor que exprese lo que representa el evento en sí, no solamente la palabra que representa la acción, sino también el tiempo verbal adecuado, para evitar confusiones acerca del momento en que se despacha el evento.

Si queremos crear eventos personalizados, que porten información relevante del contexto en el que los estamos utilizando tenemos que heredar de “Event”, no hay una interface IEvent o algo similar que permita que una clase del dominio pueda actuar como evento.

Una vez que hayamos heredado de “Event” debemos sobrescribir el método clone, para que cuando el despachador de eventos redespache el evento (en caso que sea necesario) obtenga una copia del evento original. Quiere esto decir que si en nuestra aplicación tenemos muchos eventos personalizados terminaremos escribiendo bastante código (aunque tenemos como alternativa utilizar la clase “DynamicEvent”, no se recomienda esta opción ya que no podremos hacer chequeo de tipos en tiempo de compilación y detectar errores de asignación, etc).

Los despachadores de eventos.

El método addEventListener, de la clase “EventDispatcher” tiene la siguiente definición:

El argumento “useWeakReference” es muy utilizado cuando se quiere que el mecanismo de recolección de basura elimine los objetos que contienen manejadores de eventos, pero como vemos es el último argumento en la lista. De modo que si frecuentemente utilizamos un valor “true” en este argumento y los valores por defecto en los argumentos “useCapture” y “priority”, el método se invocaría de la forma:

Al parecer, es común entre los desarrolladores invocar el método de esta forma, por lo cual se agradecería mucho que la lista de argumentos fuera:

En la clase “EventDispatcher” no existe un método que permita eliminar todos los manejadores de eventos de una sola vez.
Si se hereda de “EventDispatcher” a fin de crear un despachador personalizado y modificar su comportamiento, como un control personalizado de los manejadores de eventos, nos encontramos que no podemos acceder a la lista de manejadores, la clase tiene un diseño cerrado.

Por otra parte, aunque existe la interface “IEventDispatcher”, crear una clase que haga un tratamiento personalizado de los manejadores de eventos y que implemente la interface no funcionaría del todo, ya que la propiedad “target” de la clase “Event” es de solo lectura y solo la clase “EventDispatcher” es capaz de asignarle valor. De modo que la clase “Event” y “EventDispatcher” se diseñaron para trabajar juntas.

aS3-signals.

Existe un proyecto denominado as3-signals que plantea una alternativa al sistema de eventos de ActionScript 3 y que tiene en cuenta todos los inconvenientes anteriores. El proyecto está inspirado en el sistema de eventos de C# y en las signals/slots de Qt. La idea central es que en vez de tener un objeto (”EventDispatcher”) capaz de despachar cualquier tipo de evento a cuanto manejador se haya registrado, se utilizan objetos que contienen su propia lista de manejadores y cuya semántica representa un evento en específico. De esta forma el evento está identificado por el objeto en sí y no por un tipo de dato “String”, como ocurre en la clase “Event” y sus derivadas.

Un objeto “Signal” se define como un mini despachador específico para un solo evento, que contiene su propia lista de manejadores. Cuando se crea un objeto de este tipo se especifican los tipos de datos de los argumentos del método “dispatch”, que es el que invoca a los manejadores que se hayan registrado. De este modo el número de argumentos de los manejadores deben coincidir con los especificados en la creación del objeto.

Como funcionalidad distintiva tiene que permite eliminar todos los manejadores a una vez, a través del método “removeAll”, permite registrar un manejador que sea invocado una sola vez y luego automáticamente eliminado de la lista de manejadores, mediante el método “addOnce”, y permite conocer en cada momento la cantidad de manejadores registrados.
Básicamente el flujo de trabajo sería:

1. – Crear el objeto “Signal”:

O heredando de “Signal”

En este caso el objeto representaría si el usuario ha ingresado a la aplicación, sería el equivalente a

si estuviéramos utilizando un evento personalizado.

2. – Adicionar manejadores

O, si queremos que el manejador se invoque solamente una vez y sea eliminado de la lista automáticamente después de invocado:

La sintaxis del manejador quedaría:

3. – Despachar el evento

Cualquier intento de invocar el método “dispatch” con un argumento que no sea “Boolean” o con 0 o más de un argumento causará una excepción de tipo “ArgumentError”.

En el proyecto se incluyen cuatro tipos de “Signals”,

“Signal”: Representa el comportamiento básico, que hemos descrito anteriormente.
“DeluxeSignal”: Este tipo de “Signal”, a diferencia del anterior, permite asociar el evento a un objeto en particular, el que se pasa en el constructor; de modo que si el argumento del método “dispatch” es de tipo “IEvent”, encapsulará información del objeto asociado, y el propio objeto “DeluxeSignal”, la cual estará disponible en los manejadores. Permite además asignar prioridades a los manejadores.
“NativeSignal”: Permite encapsular un evento nativo de ActionScript, el constructor toma como argumento un “EventDispatcher, un “String” que identifica el tipo del evento y un “Class” que identifica la clase del Evento (”Event” por defecto). Cuando se registra un manejador se registra en el “EventDispatcher”, el mismo que se utiliza para despachar los eventos. Todas las funcionalidades básicas, como eliminar todos los manejadores a la vez, registrar y despachar manejadores que se invocan una sola vez, etc., se ejecutan sobre el “EventDispatcher”. Permite también asignar prioridades a los manejadores. Esta clase da la posibilidad de un manejo homogéneo de eventos dentro de la aplicación.
“NativeRelaySignal”: Ofrece las mismas funcionalidades que “NativeSignal”, pero se diferencia de ésta en que tiene su propio mecanismo para despachar eventos, no delega esta responsabilidad en el “EventDispatcher” que se pasa como argumento en el constructor, como sucede con “NativeSignal”.

Las “Signals” en el contexto de la Inversión de Control.

Normalmente cuando usamos el sistema de eventos de ActionScript el flujo de trabajo consiste en crear un evento (de la clase “Event”) asignándole su tipo en el constructor y despacharlo usando un “EventDispatcher”, ó en muchos casos, creando eventos personalizados (heredando de “Event”), asignar alguna carga útil y despacharlo. Constantemente estamos creando y despachando eventos.

El flujo de trabajo de las “Signals” hace que sea muy conveniente utilizarlas con frameworks que utilicen Inversión de Control, en este caso solo debemos crear el objeto “Signal” como un singleton en el framework (no es necesario implementar el patrón Singleton, solamente se debe indicar al framework que cree una sola instancia de la clase y que devuelva siempre la misma referencia), e inyectar la referencia en cuanto componente sea necesario (vistas, modelos, comandos, mediadores, etc.), de esta manera disminuiríamos notablemente la tarea de creación de objetos relacionada con los eventos, algo que siempre resulta costoso.

Conclusiones.

El proyecto as3-signals ofrece una alternativa interesante al sistema de eventos de ActionScript que podemos utilizar en nuestros proyectos y que puede beneficiarse del uso de frameworks de Inversión de Control.

» Leer más, comentarios, etc...

Picando Código

Debian Squeeze y nombre para Debian 7: Wheezy

Septiembre 7th, 2010 - [Enlace local]

Debian Wheezy

Ya está cerca de lanzarse la versión estable de Debian 6: Debian Squeeze. Mientras tanto los desarrolladores comentaron que seguirán usando nombres de personajes de Toy Story como nombre clave para sus distribuciones. Y así fue escogido el nombre para Debian 7: Debian Wheezy.

Wheezy es un pingüino de goma que apareció en Toy Story 2. Su aparición no era muy feliz, ya que se encontraba juntando polvo en un estante al encontrarse roto. De todas formas más adelante los juguetes lo reparan y se lo puede escuchar cantar el clásico tema “You’ ve got a friend in me”.

La mayoría de las transiciones de paquetes están prontas, quedan algunos bugs críticos, y mucho trabajo por delante para sacar esta nueva versión.

Una de las novedades que me resultan particularmente interesante de este nuevo Debian es el port del sistema operativo Debian al kernel FreeBSD. El instalador de Debian está usando FreeBSD 8.1 (la versión estable más reciente), y ya hay imágenes diarias disponibles. Tengo un DVD con FreeBSD 8.1 quemado, y estoy esperando a la versión final de Debian GNU/kFreeBSD para ver cuál de los dos me animo a probar…
Hace tiempo que tengo ganas de aprender un sistema BSD, pero no he tenido tiempo…

Sigo disfrutando de mi sistema ArchLinux en la computadora de escritorio. Ya respaldé todos los archivos importantes de mi laptop, por lo que estaría en condiciones de ser formateada para experimentar con ella. Ya les comentaré al respecto cuando llegue el momento.

Debian Uruguay

Aprovecho la oportunidad para comentarles que la comunidad de Debian Uruguay ha renacido.

Después de un buen tiempo en la nada, algunos usuarios han ido buscando revivirla y ya se están organizando reuniones para coordinar actividades, objetivos y demás.

Los interesados pueden inscribirse a la lista de correos:
debianuruguay@freelists.org

Es una lástima que últimamente no he encontrado la manera de organizar mis tiempos para poder formar parte de este tipo de actividades que tanto ayudan y enriquecen al ecosistema de usuarios de software libre.

Pero ya me voy a acomodar y empezaré a estar más presente en estas iniciativas. De todas formas lo que me vaya enterando de Debian Uruguay lo iré difundiendo en el blog.

Comparte:

» Leer más, comentarios, etc...

Arragonán

Saraos para programadores

Septiembre 7th, 2010 - [Enlace local]

Para darle un poco de vidilla al blog, que con tanto lío lo tengo un poco olvidado, algunos eventos que pueden ser interesantes para desarrolladores y a los que si puedo intentaré asistir:

El 23 de Septiembre, Google DevFest 2010 en Madrid, la agenda no tiene mala pinta, aunque evidentemente la temática es exclusivamente sobre productos y frameworks de google.

Los días 4 y 5 de Noviembre, la Conferencia Rails 2010 también en Madrid. Todavía están con el call for papers y hace bastante que no trabajo con Rails “de verdad”, pero como el último año no pude ir y que lo están intentando internacionalizar, me pica mucho la curiosidad ver como queda

En Barcelona los días 12 y 13 de Noviembre, Agile Open Spain 2010. Un open space organizado por la comunidad Agile-Spain… no tenía claro cuál era el formato ideal de propuesta para un open space, pero @jjballano me lo ha resuelto rápido. Es un formato de evento diferente de los que he ido hasta ahora, veremos que tal.

¿Más eventos interesantes para desarrolladores?

PD: Un día de estos espero publicar alguna cosilla con más fundamento

» Leer más, comentarios, etc...

Cerebro en la Sombra » Técnico

Adobe Air XII – No se puede instalar la aplicación, este instalador no se ha configurado correctamente

Septiembre 3rd, 2010 - [Enlace local]

Recientemente he tenido que modificar una aplicación AIR y, ya de paso, me dio por convertirla a Air2. Todo iba bien hasta que la subí al servidor para que a todos los usuarios les apareciese automáticamente la actualización pero una vez comenzaba la instalación salía el siguiente mensaje:

No se puede instalar la aplicación, este instalador no se ha configurado correctamente

Tras googlear un poco lo único que encontré es que normalmente se debe a que la has publicado con un certificado distinto al que tenía la versión anterior, pero no era mi caso. Y así, de repente, me acordé que para utilizar la instalación automática se necesitaba el publisherID y pensé, ¿no será algo de eso?.

Así es que revisé el descriptor de la aplicación Aplicacion-app.xml y me encontré con un nuevo nodo comentado:

Lo descomenté y le añadí mi publisherID que se obtiene de la versión anterior instalada en:

\RUTA_DE_INSTALACION_DE_TU_APP\META-INF\AIR\application.xml

Publicas de nuevo la aplicación y todo solucionado, se actualiza perfectamente .

» Leer más, comentarios, etc...

Monocaffe

PermGen Out of Memory

Septiembre 3rd, 2010 - [Enlace local]

Si te encuentras con este error es porque probablemente estés trabajando en una aplicación enterprise bastante grande. El principal problema de este error es que la JVM no muere, por lo que es cuestión de suerte saber que algún nodo de nuestro sistema ha dejado de funcionar.

Intentemos entender lo que es el espacio PermGen. Primero debemos entender sobre los tres mecanismos de recolección del GC de Java:

Young
Tenured
Perm

Podéis leer más sobre estos mecanismos aquí. El Perm(anent) se caracteriza por responsabilizarse del código binario de clases y métodos. De esta forma se separan las instancias de los objetos, del código que los describe. Por lo que si la JVM llena este espacio por completo, no podremos crear instancias nuevas de objetos que no lo hayan sido anteriormente ya que sus firmas no podrán ser metidas en el PermGen.

Dado que cualquier aplicación utiliza hoy en día Spring, Hibernate y cuarenta librerías más, el espacio para PermGen se puede llenar bastante rápido sino tenemos cuidado. Antes de solucionar este problema, vamos a intentar reproducirlo.

Si nuestra aplicación se ejecuta en algún servidor de aplicaciones, lo más sencillo será reducir el tamaño máximo del PermGen al mínimo, tal que el servidor funcione, despliegue nuestra aplicación pero falle con la primera petición. Esto lo logramos variando los valores del argumento para la JVM MaxPermSize.

A continuación vamos a medir esto utilizando jconsole ya que es bastante gráfico. Lo primero será activar el servicio JMX de la JVM añadiendo los siguientes argumentos:

com.sun.management.jmxremote.port=12346"
com.sun.management.jmxremote.authenticate=false"
com.sun.management.jmxremote.ssl=false"

Arrancamos el servidor de aplicaciones y jconsole.

A continuación realizamos una petición a nuestra aplicación y podemos ver como aumenta el uso del PermGen:

Y continuamos hasta que alcanzamos el límite dado (64m):

Después de esto, jconsole se desconecta y no podremos seguir analizando, aunque nuestra aplicación sigue funcionando y es posible que no se pierda funcionalidad, pero es inestable y en el momento en el que se intente crear una instancia de un objeto cuya "firma" no se encuentra en el PermGen, fallará.

La solución inmediata a este problema es claramente aumentar la cantidad de memoria disponible para el PermGen y por ende, de la JVM o seguir analizando el problema. Volvamos a arrancar el servidor de aplicaciones y nos conectamos con jconsole. Hacemos una petición:

¡Casí! Vamos a pulsar el botón "Perform GC" a ver qué sucede:

¿Nada? ¿No se limpia el PermGen? Dado el nombre de este espacio de memoria era bastante obvio el resultado. Otra solución que encontramos en Internet es añadir la siguiente opción a la JVM -XX:+CMSClassUnloadingEnabled veamos qué sucede:

Nada, seguimos igual. Probemos con otra de las soluciones -XX:+CMSPermGenSweepingEnabled

De igual manera parece que no ha habido ningún cambio favorable

 y el rendimiento se ha visto impactado negativamente y la misma petición ha tomado el triple de tiempo en ser procesada.

Puede que sencillamente, nuestra aplicación en realidad necesita tal cantidad de memoria ya que utilizamos una cantidad ingente de librerías. Como se puede ver en el siguiente gráfico, después de una larga sesión de stress, la memoria PermGen se mantiene estable:

Esto es un servidor de aplicaciones el cual utiliza gran cantidad de librerías, contextos y distintas complejidades que pueden hacer que ciertas referencias se mantengan y eviten que el GC haga su trabajo, por lo que vamos a intentarlo con una aplicación J2SE. Esta es sencillamente un servicio REST que nos permite hacer búsquedas contra unos EJB's. Para hacer pruebas es muy útil y como podemos ver, su funcionamiento es similar al servidor de aplicaciones:

Se utiliza cierta cantidad de memoria del PermGen y después de varias peticiones, esta se mantiene estable, incluso después de añadir las posibles soluciones indicadas más arriba no hay ningún cambio.

Dado que no hay un crecimiento continuo y que éste se detiene una vez hayamos pasado por todas las posibles combinaciones y usos de nuestra aplicación, es posible indicar un valor máximo para el PermGen que sea lo bastante como para sostener nuestras aplicaciones y justo en el consumo de memoria.

Redesplespliegues

Ahora hablemos de nuestro amigo el ClassLoader. Un servidor de aplicaciones como Tomcat o JBoss utilizan un artilugio que se encarga de cargar los ficheros .class de los JARs que componen nuestra aplicación.

Los ClassLoader tienen una jerarquia, donde el servidor de aplicaciones tiene uno o varios "propios" y por debajo de estos tenemos a los que se crean para cada una de nuestras aplicaciones. Dentro de ésta jerarquía las clases de nuestro ClassLoader pueden utilizar las de arriba, pero no al revés. Por lo tanto, al crear un nuevo objeto, sucede lo siquiente:

Cada objeto mantiene una referencia a su objeto .class.
Cada objeto .class mantiene una referencia con su ClassLoader.
Cada ClassLoader mantiene una referencia para cada clase que ha cargado.

Dado que cada una de nuestras aplicaciones tiene su ClassLoader, al volver a desplegar se destruyen todas las referencias al anterior para crear uno nuevo. Pues va a ser que no:

El ClassLoader vuelve a ser creado y por ende todas las referencias a clases antiguas se pierden y se crean nuevamente, pero no se realiza ninguna limpieza del PermGen... ever! Si continuamos redesplegando nuestra aplicación y haciendo peticiones, volveremos a quedarnos sin Perm.

Incluso si eliminamos el despliegue, el Perm no es liberado.

Soluciones

Podemos concluir que el PermGen nunca se libera de forma significativa y que debemos controlar su uso siguiendo estos consejos:

La solución más rápida es aumentar su tamaño máximo.
Ordenar y desarrollar nuestras aplicaciones de tal forma que se maximice el uso de las librerías provistas por el servidor de aplicaciones.
Utilizar librerías comunes entre distintos proyectos y añadir dichas librerías al ClassLoader del servidor de aplicaciones. Un buen ejemplo son los conectores JDBC.
Evitar referencias externas a nuestra aplicación a objetos internos de la misma (ClassLoader Leak).

Solución JRockit

JRockit, la máquina virtual de Oracle que era de BEA y utilizada por defecto por WebLogic no implementa un PermGen, por lo que este problema no existe y el GC recolecta de forma normal siempre que se eliminen las referencias, por lo que si la aplicación contiene un leak de este tipo, tendremos un Out of Memory del HEAP que son más fáciles de ver y monitorizar.

Nota final

Mientras he estado realizando las distintas pruebas, he podido comprobar que al añadir la opción CMSPermGenSweepingEnabled el rendimiento baja significativamente, incluso en una aplicacion J2SE por lo que no lo recomiendo para nada.

Más información

http://www.jroller.com/agileanswers/entry/preventing_java_s_java_lang

http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html

http://www.alessandroribeiro.com/?q=en/node/39

http://stackoverflow.com/questions/88235/how-to-deal-with-java-lang-outofmemoryerror-permgen-space-error

http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java

http://docs.jboss.org/jbossas/jboss4guide/r2/html/ch2.chapter.html

» Leer más, comentarios, etc...

Blog del grupo SQUaC

AccUsa v0.2

Septiembre 2nd, 2010 - [Enlace local]

We have published version v0.2 of AccUsa, our support tool for accessibility and usability engineering. It's available in "Descargas" (downloads) section:

AccUsa v0.2 download

Screenshot of AccUsa v0.2

These are some of the new features since previous version v0.1:

Support for thinking-aloud user testing (partial)
Multiple rounds per technique and project
Issue duplication
Multiple options for issues exportation
More views for multiple experts support (issues' status; different views of issues in a single project)

By the way, we will be talking about this tool next week in Interacción 2010, in Valencia, where we... [sigue ...]

» Leer más, comentarios, etc...

Ingenieria de Software / Software Engineering / Project Management

Mejorando la Productividad

Septiembre 1st, 2010 - [Enlace local]

Apenas me entero de esta Herramienta/Metodología (POMODORO) para ser mas productivos, lo que conlleva a una mejor gestión de nuestro tiempo, yo conozco GTD pero POMODORO viene a ser otra opción.

» Leer más, comentarios, etc...

Bitácora de Javier Gutiérrez Chamorro (Guti)

C/C++ interpretado

Septiembre 1st, 2010 - [Enlace local]

Hoy día nos puede parece que el bytecode, y los lenguajes más o menos interpretados son algo puntero, aunque de hecho Visual Basic del 1 al 4 ya lo utilizaban, y anteriormente lo hicieran varios entornos xBase como FoxPro o Clipper, o el popular Quick Basic.

Lo que en mi experiencia resulta un hecho más insólito es un compilador de C/C++, que soporte código interpretado, y ese, era un producto tan conocido como ni más ni menos Visual C++.

En su versión 1, de la que la 1.52 resultó el máximo exponente, y que luego vino como regalo a aquellos que adquirían la versión 4, teníamos la capacidad de compilar todo o parti de nuestro proyecto a p-Code.

Los beneficios era un código más compacto, a costa de una velocidad de ejecución más lenta, y por aquellos 1993, se consideraba ideal para escribir la parte de interfaz de usuario, donde el rendimiento no era crítico, y así conseguir adelgazar el resultado final.

Finalmente el tiempo demostró que las ganancias no eran tantas, y la generación de código interpretado se abandonó sin más.

» Leer más, comentarios, etc...

Bitácora de Javier Gutiérrez Chamorro (Guti) » Programación

C/C++ interpretado

Septiembre 1st, 2010 - [Enlace local]

Hoy día nos puede parecer que el bytecode, y los lenguajes más o menos interpretados son algo puntero, aunque de hecho Visual Basic del 1 al 4 ya lo utilizaban, y anteriormente lo hicieran varios entornos xBase como FoxPro o Clipper, o el popular Quick Basic. Lo que en mi experiencia resulta un hecho más [...]Artículos relacionadosVisual Basic .NET no es Basic
Visual Basic for DOS
Lenguajes y programas

» Leer más, comentarios, etc...

Meta-Info

¿Que es?

Sponsors

¿Cuál es la diferencia entre un StringBuilder y un StringBuffer?

Los eventos.

Los despachadores de eventos.

aS3-signals.

Las “Signals” en el contexto de la Inversión de Control.

Conclusiones.

Debian Uruguay