ShortCuts Flash Builder 4

Usar un buen IDE siempre es bueno, pero usarlo bien es todavía mejor. La comodidad y la fluidez para trabajar son indispensables para aumentar la productividad y, sobre todo, sentirse menos frustrado haciendo cosas molestas.

Les voy a dejar una serie de shortcuts y tips para FlashBuilder 4, sin duda muy cómodos.

Si sos usuario de MacOs solo reemplazá la tecla Control por Command, como seguro ya sabés.

Asistente (Control + Space): Un viejo conocido de muchos desarrolladores, más si vienen de cualquier Eclipse o derivado. Nos muestra el asistente según donde estemos posicionados y nos da una guía de como seguir (completando variables, métodos, etc).

Comentario en bloque (Control + Shift + C):  Sumamente útil, cuando lo descubrí fui muy feliz. Básicamente comenta (/* */) el sector de código que tengas seleccionado.  Si ya está comentado, lo descomenta.

Organizar Imports(Control + Shift + O): Se encarga de organizar los statement de los import, eliminando los no usados y acomodando por package si hace falta. No es un comando que vivas usando pero es realmente util.

Rapido acceso al Outline (Control + O): Amo este tipo de Shortcuts. Nos permite visualizar y dirigirnos rápidamente las variables y métodos del archivo que tengamos abierto. He visto algunos (incluyendome a mí tiempo atrás), hacés Control + f (find-search) buscando el método o variable en cuestión y navegando entre comments y demás. Este shortcut es indudablemente más práctico y veloz.

Abrir recurso (Control + Shift + R): Como el anterior, un shortcut para amar. Nos permite buscar rápidamente por nombre cualquier clase o recurso de nuestro proyecto. Se puede incluir caracteres ? y * en la búsqueda (la ventanita explica para que sirven). Un tip interesante es que podemos buscar escribiendo solo las mayúsculas. Por ejemplo, si tenemos una clase ResourceLoader, podemos escribir RL y la encontrará.

Encontrar la llave Perdida (Control + Shift + P): Suena a una aventura de Indiana Jones, y, a veces, es medio parecido encontrar donde cierra una llave ({ y }). Con este shortcut se soluciona facilmante 🙂

Encontrar Declaraciones (Control + G): autoexplicativo

Encontrar Referencias (Control + Shift +G):  idem

Ir a la declaración (F3): sumamente práctico. Si tenemos una variable que estamos usando, o un metodo al que estamos incvocando, un objeto creando, etc, con colocarnos encima y tocar f3 accedemos a la declaración del mismo.

Volver a la última posición de edición (Control + Q): A veces nos emocionamos tocando f3 o buscando cosas o abriendo recursos y nos olvidamos dondes estabamos o hay que ir buscando entre archivos cuál era el punto del que partimos. Con este shortcut podemos retroceder en dicha cadena de movimiento y búsqueda.

 

Hay varios shortcuts más, pero estos son los que más uso y realmente agilizan mucho el trabajo. Si me doy cuenta alguno más lo sumo!

 

 

 

Object Pooling

Hace un tiempito estaba haciendo un juego en Flash, en el cual iban apareciendo enemigos cada vez en mayor cantidad y llegaba un momento en que la perdida de rendimiento era muy fuerte.

Una solución (o al menos un enfoque para mejorar la situación) a este tipo de situaciones es lo que se conoce como Object Pooling.

El término pool significa literalmente pileta, pero para conceptos como este, no se me ocurre una traducción correcta, pero basicamente hace referencia a un conjunto de recursos a los que se puede acceder para ser usados en algo (se usa no solo en la informática).

Object Pooling es un Design Pattern en concepto muy simple. Se trata de mantener un pool de objectos constantemente instanciados e ir accediendo a ellos según los necesitemos en vez de ir instanciandolos y disposiandolos de memoria on demand. Cada vez que accedemos a un objeto, sin duda, necesitamos resetearlo, así que que también hay que «limpiar» los objetos una vez liberados.

¿Cuándo usar Object Pooling?

La idea de object pooling es ahorrar memoria y tiempo de cpu en la instanciación y liberación de objetos, además de prevenir memory leaks y la fluctuante situación del garbage collector (supiendo que usemos un lenguaje que lo tenga). Por lo tanto, esta técnica es ideal para cuando instanciamos mucho una clase  y/o el costo de instanciación es muy alto.

Tomemos el ejemplo de un survival mini game. Si, de esos que empiezan a venir chobis y chobis y chobis. Digamos, zombies (todos amamos los zombies). Con el paso del tiempo, la cantidad de zombies es cada vez más grande.

Bien, acá tenemos  un buen caso para usar (casi seguro) Object Pooling.

Vamos a usar ActionScript3 para los ejemplos. Y el objecto  que vamos a poolear es,claramente, un Zombie.

Zombie.as

public class Zombie extends Sprite{
        public static const OUT_SCREEN_X   : Number  = -2000;
        public static const OUT_SCREEN_Y   : Number  = -2000;
        // -- Class Constructor
        public function Zombie(){
        }
        public function reset():void{
             this.x=OUT_SCREEN_X;
             this.y=OUT_SCREEN_Y;
        }
}

Como vemos,es una clase muy básica. Simplemente estamos hablando de herencia de Sprite. Ahora nos ocuparemos del pool:

ZombiePool.as

public class ZombiePool {
        public static const MIN_ZOMBIE_QTY    : int  = 50;
        private m_pool : Vector.<Zombie>;
        public function ZombiePool(){
            m_pool = new Vector.<Zombie>();
            var i:int =MIN_ZOMBIE_QTY   ;
            while (i-->0){
                m_pool.push(new Zombie());
            }
        }
        public function getAZombie():Zombie{
              if(m_pool.length==0)
                   m_pool.push(new Zombie());
              return (m_pool.pop()).reset();
        }
        public function freeZombie(_zombie:Zombie):void{
                m_pool.push(_zombie);
       }
}

Revisemos rapidamente el código. Como podemos ver,  la pool propiamente dicha es un Vector de Zombies. Esta pileta es inicializada con cierta cantidad de zombies definida en la constante MIN_ZOMBIE_QTY. Por supuesto que podria haber sido inicializada por inyección en el constructor o
seteada en algun init del ZombiePool, es indistinto.
Entonces, el uso es sumamente simple. Cuando un cliente (por ejemplo.. una clase Level, o GameManager
o Map,etc) necesite crear un zombie, en lugar del clásico

var zombie:Zombie = new Zombie();

deberá utilizar:

var zombie:Zombie = ZombiePool.getAZombie();

Tras eso, lo inicializa como desee, siempre que el zombie tenga un metodo para inicializar
e inyectar valores o bien estos sean públicos.
De esta manera evitamos crear y eliminar de memoria constantemente (y esto, en un juego como este,
puede ser muy constantemente) Zombies, evitamos el mal uso del garbage collector, memory leaks
y el costo de una instanciación.
En este ejemplo simple usamos un pool incremental, es decir, si la pool se encuentra vacía,
automaticamente crece. Existen otros enfoques (pool limitada, pool que empieza vacía, etc),
pero son básicamente lo mismo.

Cuando no Usarlo , el Anti-Pattern
Aunque no me pasó, existen casos donde aparentemente es copado usar Object Pooling pero,
la realidad, termina siendo muy distinta (lo que se conoce como Anti-Pattern, es decir,
usar un patrón creyendo que es la mejor solución pero que termine teniendo un efecto contraproducente.)
Se trata de casos en los que limpiar el objecto (resetearlo) es más costoso que instanciarlo
o casos donde las referencias al objecto del pool pueden ser conflictivas y al liberarlo
al pool puede generarse problemas con los punteros y demás. Pero no creo que sea para
alarmarse, la mayoría de los mortales no tenemos ese problema.

Así que, a llenarse de zombies!

Desacomplando Código y Buenas Prácticas , parte I

Si estudiás informática en algún lugar académico (facu o similar), seguro escuchaste hablar que una buena práctica es buscar que el código que hagas esté lo más desacoplado posible (decoupled). Por supuesto me refiero a una práctica que POO permite (quizás otros paradigmas no dan tanta libertad, pero no puedo hablar mucho al respecto).

Una mala costumbre que tienen muchos programadores, sobre todo aquellos que ignoran buenas prácticas de la ingenieria de software (design patterns y demás), es justamente acomplarlo todo. ¿Qué significa que nuestro código esté acoplado?

El término coupled (acoplado) es bastante autoexplicativo. Hace referencia a tener distintos sectores del código tan unidos que no podemos independizarlos, generando dependencias muy fuertes entre objetos, métodos, etc. Esto, indudablemente, es un problema.

Como una de  mis especialidades es la programación de videojuegos, mis ejemplos van a ser medio juegos. Pero creo que también son ejemplos más didácticos, ya que las abstracciones hechas en los juegos suelen ser bastante claras. Por el mismo motivo voy a usar ActionScript 3 como ejemplo de código, pero no se queden en eso.

Imaginemos que tenemos las clases Auto, Conductor. Implementemoslas de una «mala manera» (no soy experto en autos y motores asi que no creo qeu sea un buen modelo de la vida real, pero ignoren mi ignorancia):

Emepecemos por Auto:

public class Auto{
        public var funcionando : Boolean;
        public var velocidad   : Number;
        public var direccionRuedas : int; // -1,0,1 (izq, neutro, der)
        public var cantCombustible : Number;
        public function Auto(){
                cantCombustible = 20;
                direccionRuedas = 0;
                velocidad       = 0;
                funcionando     = false;
        }
}

Y ahora la clase Conductor:

public class Conductor{
        public var miAuto : Auto;
        public var nombre : String;
        public function Conductor(){
             nombre = "Juan Perez";
             miAuto = new Auto();
        }
        public function comenzarAManejar():void{
             miAuto.funcionando= true;
        }
        public function doblarDerecha():void{
            miAuto.direccionRuedas= 1;
        }
        public function doblarIzquierda():void{
            miAuto.direccionRuedas= 1;
       }
        public function update():void{
                 miAuto.cantCombustible-=5;
                 if (miAuto.cantCombustible <= 0) {
                     miAuto.funcionando= false;
                 }
        }

}

Bien. Sí. Disculpen si el código es sumamente feo, aquellos que tengan algo de conocimiento y práctica.
Estoy enfocando el artículo principamente a quienes no la tiene, al menos desde el comienzo y además,
Intentando ser sumamente explícito, así que mejor que sea bien feo.

Asumamos que el método update de Conductor se llama cada X cantidad de tiempo (por ejemplo en un OnEnterFrame) y que en ese delta de tiempo, el Auto consume 5 de combustible. Bien. Un programador inexperto diría «bueno.. el código es correcto, funciona» . FUNCIONA. Tenemos que tener un increíble cuidado con ese término. Puede funcionar.. pero.. ¿A qué costo?

Supongamos que deseamos cambiar el consumo de combustible, y supongamos que Conductor no es la única clase que utiliza el auto… deberíamos cambiar todas esas clases a su vez, y .. muy probablemente nos pasemos de alto cosas. En este ejemplo parece algo pequeño, pero en grandes aplicaciones… te vas a querer matar.

Una buena manera de desacoplar este comportamiento (el gasto de combustible), es simplemente delegar la responsabilidad del gasto de combustible al auto. Al fin y al cabo.. uno no le dice a su auto «che, coche, gastá tu combustible», él lo gasta solito, él sabe como hacerlo.

Lo mismo sucede con la siguiente línea, donde se controla si el auto debe detenerse al quedarse sin combustible.

Así que simplemente podemos agregar el siguiente método a Auto:

public function update():void{
   cantidadCombustible-=5;
   if (cantCombustible <= 0) {
                     funcionando= false;
    }
}

y reemplazar el update del Conductor por algo como:

public function update():void{
       miAuto.update();
}

Sumamente básico, pero muchísimo mejor. Existen otros enfoques ya un poco menos básicos (para que no se quejen) para desacoplar este comportamiento, pero pienso comentarlos en el siguiente artículo de la serie.