Usando Debuggers

Si venis de hacer aplicaciones de escritorio o bien Application Servers con lenguajes como Java, probablemente te suene mucho el tema de breakpoints y demás.

Conozco mucha gente que programa sin utilizar las bondades de un buen debugger (o de un debugger cualquiera).

Cuando se encuentran con bugs o problemas, suelen usar prueba y error o muchos prints (o trace, o echo, lo que lo quieras) para poder ir siguiendo la información que tienen los objetos y variables.

¿Por qué usar un debugger?

BreakPoints: Un breakpoint es una interrupción en la ejecución del código, una pausa, que te permite ver el estado del programa en ese punto y luego te permite continuar la ejecución.
De esta manera, podemos evitar que «pinche» el programa antes del legar al punto conflictivo e ir avanzando paso a paso en el código hasta determinar qué linea o sector de código no está generando el problema.

Por otro lado, tenemos la ventaja de revisar el estado en memoria de las variables y objetos que fueron utilizados, sin necesidad de prints raros ni nada por el estilo. En un buen IDE, podemos hacer dropdowns de dichos objetos de manera clara, navegando entre sus propiedades y elementos, por ejemplo si es un Array o Collection.

Además, según el tipo de plataforma que corras, el debbuger ayuda a capturar ciertos errores y excepciones sin que se rompa todo el entorno de trabajo.

Conclusión:

Usar debugger, es bueno. Fue un post muy simple, pero estos días estuve viendo mucha gente no usar debugger y programar en cuasi block de notas creyendose hackers por hacerlo, pero nada mas lejos de la realidad.

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.