UnpredictableIssue.Timeout(1036800)

La conexión al Proyecto entro en un ciclo, del cual, está a punto de salir.

for(force_majeure,force_majeure>=0,absence=1)
{
MobProject.sleep(absence*1000);
}

Sin embargo, el tiempo no se ha desperdiciado y dejo aquí unas ideas que me han caído de distintas fuentes:

1. KISS (Keep It Simple Stupid).- No hay que complicarse, aunque existan reglas y nos apeguemos a ellas por el bien de todos, no debemos alejar de nuestra mente las soluciones simples y obvias aunque estas parezcan romper reglas de oro.
2. SCRIPTS, si la lógica de lo que deseas implementar es "compleja", se la imagina el director, pero si es "simple" va en los guiones. Mantener la parte compleja del código, dentro del mismo, y la parte "simple" fuera de este, en scripts; no solo nos ayuda a administrarlo de manera más eficiente, también proporciona una fuerte base para el desempeño.
3. Evita la Redundancia. Si necesitas algun código en dos o más partes dentro de tu programa, solo debe existir en un solo lugar. Aplica para funciones, datos y derivados. Recuerda "En la Herencia, esta la Evolución"
4. PARSEAR archivos es una de las tareas más comunes del programador, crear editores de texto para diferentes tipos de archivos e incluso un lenguaje propio no deben ser imposibles en su mente. Todo Programador de Videojuegos debe comenzar manipulando archivos de texto.
5. Documentar. Comentar y respetar un estilo de codificar, son reglas que nunca pasaran de moda.

So much to say, So little room.

  Ultimamente, he estado trabajando mucho con java y haciendo muchas cosas por el estilo de las que hacía en la universidad; (complicarme la existencia con tal de lograr algo poco comun) y terminé aprendiendo algunas cosillas que serán útiles.   Pero no puedo poner todas en un solo post, la información se puede confundir, y para consultarla más adelante, sería más complicado.   Por lo tanto, la voy a dividir en tres post, para tratarla de manera independiente:

• Bitwaize mask flags.
• Reference notes and insides of a while.
• Constructor from a Class parameter.

  Esta recopilación de experiencia se dio cuando mi orgullo y curiosidad me llevaron a modificar un simple programa cliente-servidor de barquitos, piratas y puertos para que funcionara de una manera mas... elegante. El resultado resultó satisfactorio hasta cierto punto, todavía hay cosas que se le pueden hacer a ese programa, pero no me debo involucrar mucho con ese, pues se supone que sólo es un ejercicio previo al GRAN proyecto.
  A ver si no termino haciendo un juego online de barcos...

Bitwize mask flags

  Dentro de la programación de java, se pueden manejar enteros int como única variable que represente el estado de un objeto, sobre todo cuando el objeto puede tener más de un estado al mismo tiempo.
  Suponiendo que tenemos un barco, éste puede ser pesquero, pirata, naval, mercante o de pasajeros. Estaremos de acuerdo que no puede ser pirata y naval al mismo tiempo, (siempre y cuando naval implique pertenecer al ejército de un país), pero podrá ser mercante y de pasajeros, o ni pirata ni naval.
  Usialmente, para manejar todo esto, usaríamos un millón y medio de variables, un private boolean para cada estado diferente y un par de public final static boolean por cada estado para un manejo más descriptivo.

  Pero... porqué no usar los bits? Un bit, dentro de un entero para saber cada uno de los estados del barco. De manera meramente lógica resulta un poco complicado, estar haciendo todas las operaciones para saber si un 4 significa que es naval y un 3 significa que es pesquero y pirata. Lo que resulta en demasiados métodos para regrezar un simple true cuando le pregunten si es o no un barco pirata.

  Para eso existen los bitwize operators, comandos para hacer operaciones a nivel de bits dentro de un entero (32 bits)

  Básicamente, tenemos:
|      OR
&    AND
^     XOR
~    NOT

 También podemos utilizar "<<" y ">>" para mover las combinaciones de bits de un lado a otro dentro del mismo entero, y de esa manera inicializar nuestras variables descriptivas:

public static final int NAVAL = 1 >> 3;

 Que en cristiano quiere decir que al entero "NAVAL" le asignamos el valor 1 y lo recorremos 3 lugares ( 0010000 ).
 De esa manera, para verificar si es o no NAVAl, usamos & y comprobamos si el resultado es diferente o igual a 0.

110101 & 001000 = 000000
111000 & 001000 = 001000

 Bien utilizado, nos sirve para ahorrar mucho código en banderas de estado.

Reference notes and insides of a while

  Algo con lo que me topé mucho cuando estuve realizando la aplicación cliente servidor y que en un momento dado me llegó a desesperar, fueron en realidad dos cosas, dos errores que impedían el funcionamiento de la aplicación, pero que permitían que compilara y que "corriera" hasta cierto punto, de manera adecuada.

 El primero fue que la aplicación se trababa y dejaba de "funcionar" al apretar el botón que permitía escuchar lo que la otra parte (el cliente si estabas en el servidor o el servidor si estabas en el cliente) decía y así, poderle responder.
 Durante el debug descubrí que el programa no había dejado de funcionar, seguia corriendo, pero esperaba respuesta de la otra parte. Se había quedado atorado en el ciclo while.
 De alguna manera eso era algo que se suponía debía pasar, pues debe escuchar y recibir todo lo que le manden. Pero también debía permitir al usuario emitir las respuestas.
 La solución en realidad era sencilla, pero no me fue facil dar con ella, había que sacar el ciclo while de la aplicación que permitía al usuario interactuar, pero permitirle a esa aplicación intervenir en los eventos que generaba el while.
 Por lo tanto, el capitán tenía que tener un barco y el barco tenía que tener un capitán, lo que nos llevó al siguiente problema.

 Los objetos en java, siempre se pasan como referencia, y los nativos como valor; o eso es lo que yo creía.
 Al crear un barco, el constructor pedía especificar un capitá (The ship must allways have a captain) y el constructor del capitán pedía siempre un barco (pues todo capitán es capitán de un barco, no?).
 Y entonces surge el problema de las gallinas y los huevos. Mi primer intento de solución fue declarar un capitán y crear un barco, para después crear al capitán, en fin que los objetos se pasan como referencias. Pero no, el compilador me pedía que el capi´tan estuviera inicializado antes de crear el barco.
 Al inicializarlo con null, me mandaba NullPointerException cada que quería llamar al capitán del barco... lo que me parecía increíble, pues yo había creado al capitán con el barco anterior.
 El debug me mostró que el barco tenía un capitán nulo, aunque yo hubiera creado ese "mismo" capitán.

 La solución me tomó más tiempo, pero el resultado fue un valioso pedazo de conocimiento.

  Los objetos, como argumento en un método, pasan como referencia y los nativos como valor.
  Pero NUNCA en un constructor!!!!!

 Creé el barco y el capitán por separado, modificando el constructor, y después los agregué mutuamente.

Constructor from a Class parameter

  Lo más divertido del programa cliente servidor de los barcos pirata y demás, fue un método, que recíbe como parámetro una Class y lanza una Thread de esa Class:

    protected void onTheGo(Class portAttendant) throws Exception {
        while(dockOpen.booleanValue()){
            (portAttendant.getConstructor(Socket.class,PortManager.class).newInstance(dock.accept(), manager)).start();
        }
    }

  Hermoso, no lo creen?
  De esa manera, podemos implementar nuestra propia clase que herede de PortAttendant y utilizar este mismo método, sin tener que implementar además, la clase propietaria de éste método.

Let the Quest Begin !

La QUEST comienza con una serie de largas batallas contra PEBCAT ("Problem Exists Between Chair and Terminal"), un ser despiadado, de apariencia débil y sumisa, pero que esconde un temible sentimiento de impotencia que transmite a los seres que le rodean.

Los intentos por acabar con la vida de este monstruo eran inútiles, solo hasta que incrustamos las gemas (parche y actualizaciones) de manera ordenada, fue cuando pudimos alzar la frente en alto y proclamar con aire de (humilde) grandeza VICTORIA!!

Dichas gemas nos darían el control total sobre Eclipse y ¿por qué no?, sobre sus más secretos y oscuros tesoros.

Con el corazón lleno de esperanza y codicia decidimos ir por su tesoro, el cual escondía en un repositorio lejano, resguardado por archivos necesarios y actualizaciones pendientes.... lamentablemente no pudimos llegar a él, pues siempre que estábamos a punto de obtenerlo un "error" nos marcaba un alto del cual no pudimos salir.Como este era un extra lo pospusimos para cuando nuestro nivel aumentara y tuviéramos mejores tiradas de suerte que en este mes del dragón.

Dimos el siguiente paso en la QUEST "The MOB Project", el cual es localizar un objeto en el antiguo códice de java, que nos permita castear unas bestias a través del "Ciberespacio" e invocar demonios en un ser de otra dimensión. Una vez concluida esta sencilla tarea el siguiente concilio que se celebre (esperemos el próximo jueves) dará inicio a la parte creativa de la QUEST.

Estamos reponiendo energías después de la desgastante batalla y aunque fuimos afectados por el hechizo de PEBCAT nuestros corazones siguen latiendo con la misma fuerza gracias a la protección de unas alas que nos dieron aliento cuando nos sentíamos derrotados.

SVN & DB

La última vez que nos reunimos, no estuvimos peleando con el servidor SVN para que quedara, la buena noticia, como ya han de saber, fue que quedó, ese mismo día, despues de que terminamos la reunión.

El jueves pasado, no pudimos reunirnos físicamente, pero gracias a la tecnología y a TeamSpeak pudimos sostener una "reunión" virtual, aunque alguien (ejemplo "C") no se pudo comunicar correctamente porque tuvo problemas de hardware XD

En fin, pudimos subir y bajar archivos a través del SVN y crear proyectos en Eclipse, manejamos los básicos y establecimos un modo de trabajo.

Queda pendiente la elavoración de un minúsculo cliente, con intefaz gráfica y todo, que se comunique con un servidor, utilizando lo más básico de lo básico, para que en un momento dado, al mismo servidor se pueda comunicar un cliente programado en cualquier otro lenguaje.