Hola y bienvenido al blog personal de Eduardo Valenzuela.
Preparate a dar un paseo por los pensamientos de una de las mentes más brillantes de la casa donde vivo.
¿Por qué "El código en azul"?, te estarás preguntando. Me gustaría decirlo, pero es algo que irán notando conforme vean mis trabajos y mis futuras entradas. Creanme, es tan interesante como hilarante.
Sin más, un gusto saludar a quien esté leyendo esto, y espero contar con tu presencia en el futuro.
P.D.
Hoy llegó mi colchón nuevo. Si no me reporto en varios días, es porque no he salido de la cama.
miércoles, 1 de enero de 3000
miércoles, 3 de diciembre de 2014
TIIIIIIMBIRICHE
BUENAS. Es hora de la tan aclamada actualización. Finalmente concluí mi proyecto final, y éste fué un juego, nada menos que timbiriche, y no hablo de la banda.
El cariñoso proyecto consta de 10 clases, que acomodé en 3 paquetes para la lógica, la vista y la comunicación.
Aqui les dejo un "gameplay" que recorre de principio a fin el desarrollo del juego. Espero lo disfruten, porque yo no.
Como verán, no quedó muy diferente de cuando formulé mis prototipos en Pencil!
Comenzaré mostrando las reglas del juego, las cuales brotarán en la pantalla si aprietas el boton de "ayuda".
El funcionamiento básico del juego es el siguiente:
El tablero de juego consiste en una matriz de botones de 19x19. Algunos de ellos tienen forma de líneas horizontales y verticales, otros son solo pequeños puntos, y algunos otros son cuadrados, donde se guardan los puntos y el nombre de su dueño.
Al presionar una de las líneas (solo esos botones se pueden presionar), la maquina marca ese boton como "tomado" y lo marca de negro, simulando una línea siendo dibujada, y luego envía las coordenadas de ese boton a través del cliente de juego, para que el servidor de destino las reciba, el interprete las reconozca, y ordene a la nueva maquina hacer lo mismo que la primera.
Hablando del interprete, hay varios mensajes que está programado para recibir:
Esta serie de reglas y caminos que le permiten a los dos programas comunicarse apropiadamente son lo que define al protocolo.
Un protocolo bien planeado desde el principio permite agregarle comportamientos tan fácil como poner una ficha sobre otra, y aseguran un correcto funcionamiento del programa.
A continuación mostraré las clases una por una, comenzando con la primera vista, y la que resulta ser el "main" del juego. Es la ventana de configuración inicial, y presenta al jugador con 4 campos que puede o no llenar, al menos en el caso de los primeros dos. En el primer campo deberá introducir su nombre (con un caractér basta) . En el segundo va la dirección IP del segundo jugador. En caso de jugar en la misma computadora, podeis teclear simplemente "localhost" indicandole al programa que el juego será hosteado en la dirección local. En caso de querer conocer tu direccióon IP, basta con preguntarle a Google.
También se presenta la opción "avanzada" de modificar los puertos, pero esto es totalmente opcional, ya que el juego los asigna automáticamente dependiendo de si el jugador crea la partida o se unirá a ella.
Cuando la ventana recibe los datos y no existe ningún problema al validarlos, sea crea la vista principal del juego y la maquina de estados. Ésta última a su vez crea el cliente, el servidor y su interprete.
El cliente y el servidor consisten en los típicos Socket y ServerSocket, que conectan con una IP específica a través de un puerto igual de específico. El cliente y el servidor siempre tienen puertos diferentes y son exactamente opuestos al par del jugador contrario.
El interprete es una de las clases importantes del juego. Es quien decide como responderá la maquina a los mensajes que recibe del otro jugador. Por defecto está acomodado para recibir Strings, y el interprete los desbarata para averiguar su destino y contenido.
Para el correcto funcionamiento del juego, utilizé mi propia clase Boton, que hereda de JButton, para introducir unas cuantas variables que necesitaré.
Para dejar las cosas más claras, estas son las interfaces que conectan todas las clases del juego. Si pusieron atención a lo anterior, notarán que la StartVista conecta a la primera ventana con la vista, VistaMaquina conecta la vista con la maquina de estados, y por último la interfaz Enlace conecta la maquina con el servidor y el interprete.
Para descargar los diagramas de clase, haced click aqui. Recomiendo visualizar el archivo XML en Draw.io
Como alternativa, puede previsualizar los diagramas aqui.
Por último, si desea utilizar el proyecto completo, puede descargarlo aqui.
El cariñoso proyecto consta de 10 clases, que acomodé en 3 paquetes para la lógica, la vista y la comunicación.
Aqui les dejo un "gameplay" que recorre de principio a fin el desarrollo del juego. Espero lo disfruten, porque yo no.
Como verán, no quedó muy diferente de cuando formulé mis prototipos en Pencil!
Comenzaré mostrando las reglas del juego, las cuales brotarán en la pantalla si aprietas el boton de "ayuda".
El funcionamiento básico del juego es el siguiente:
El tablero de juego consiste en una matriz de botones de 19x19. Algunos de ellos tienen forma de líneas horizontales y verticales, otros son solo pequeños puntos, y algunos otros son cuadrados, donde se guardan los puntos y el nombre de su dueño.
Al presionar una de las líneas (solo esos botones se pueden presionar), la maquina marca ese boton como "tomado" y lo marca de negro, simulando una línea siendo dibujada, y luego envía las coordenadas de ese boton a través del cliente de juego, para que el servidor de destino las reciba, el interprete las reconozca, y ordene a la nueva maquina hacer lo mismo que la primera.
Hablando del interprete, hay varios mensajes que está programado para recibir:
- coordenadas de un boton
- mensaje de victoria
- mensaje de derrota
- ping/pong
- mensaje destinado al chat del juego
Esta serie de reglas y caminos que le permiten a los dos programas comunicarse apropiadamente son lo que define al protocolo.
Un protocolo bien planeado desde el principio permite agregarle comportamientos tan fácil como poner una ficha sobre otra, y aseguran un correcto funcionamiento del programa.
A continuación mostraré las clases una por una, comenzando con la primera vista, y la que resulta ser el "main" del juego. Es la ventana de configuración inicial, y presenta al jugador con 4 campos que puede o no llenar, al menos en el caso de los primeros dos. En el primer campo deberá introducir su nombre (con un caractér basta) . En el segundo va la dirección IP del segundo jugador. En caso de jugar en la misma computadora, podeis teclear simplemente "localhost" indicandole al programa que el juego será hosteado en la dirección local. En caso de querer conocer tu direccióon IP, basta con preguntarle a Google.
También se presenta la opción "avanzada" de modificar los puertos, pero esto es totalmente opcional, ya que el juego los asigna automáticamente dependiendo de si el jugador crea la partida o se unirá a ella.
Cuando la ventana recibe los datos y no existe ningún problema al validarlos, sea crea la vista principal del juego y la maquina de estados. Ésta última a su vez crea el cliente, el servidor y su interprete.
El cliente y el servidor consisten en los típicos Socket y ServerSocket, que conectan con una IP específica a través de un puerto igual de específico. El cliente y el servidor siempre tienen puertos diferentes y son exactamente opuestos al par del jugador contrario.
El interprete es una de las clases importantes del juego. Es quien decide como responderá la maquina a los mensajes que recibe del otro jugador. Por defecto está acomodado para recibir Strings, y el interprete los desbarata para averiguar su destino y contenido.
Para el correcto funcionamiento del juego, utilizé mi propia clase Boton, que hereda de JButton, para introducir unas cuantas variables que necesitaré.
Para dejar las cosas más claras, estas son las interfaces que conectan todas las clases del juego. Si pusieron atención a lo anterior, notarán que la StartVista conecta a la primera ventana con la vista, VistaMaquina conecta la vista con la maquina de estados, y por último la interfaz Enlace conecta la maquina con el servidor y el interprete.
Para descargar los diagramas de clase, haced click aqui. Recomiendo visualizar el archivo XML en Draw.io
Como alternativa, puede previsualizar los diagramas aqui.
Por último, si desea utilizar el proyecto completo, puede descargarlo aqui.
domingo, 26 de octubre de 2014
Primer intento de un chat en forma
Como digo arriba, este es el primer chat verdaderamente funcional que he hecho, y a continuación les presento mis clases. Está bastante simple por el momento, con solo 2 clases, pero de que funciona, funciona.
Primero la vista y el socket que envía los mensajes.
Y ahora la clase que funciona comos servidor. Es un hilo que constantemente recibe y actualiza mensajes.
Primero la vista y el socket que envía los mensajes.
Y ahora la clase que funciona comos servidor. Es un hilo que constantemente recibe y actualiza mensajes.
miércoles, 1 de octubre de 2014
Los filosofos comensales (venganza con semaforos)
En mi nuevo intento asistido por internet, verán que mi lógica es muy similar a la anterior, con la excepción de que en lugar de las colas uso semaforos, y que ya se como crear threads en ciclos xD
Esta vez, cambian básicamente tres cosas:
Primero, ya no son tenedores, porque me pareció ridiculo que necesitaces dos tenedores para comer, así que lo cambié por palillos. Tiene sentido, ¿no?
Segundo, guardo los palillos a los que accede cada comensal en una matriz de enteros, donde por defecto el primer valor será el numero de identificación del comensal, y el segundo será 0 o 1, para cada palillo.
Tercero, SEMAFOROS. ¿por qué? Porque me dejo de preocupar por que se mezclen los permisos para tomar los palillos. En mi programa anterior, eran dos sentencias diferentes la que revisa la disponibilidad de los tenedores, y la que efectúa el cambio de disponibilidad, por lo que si dos hilos accedían casi al mismo tiempo a la revisión, era posible que uno de ellos tomara los tenedores e inmediatamente después el otro también, y luego ambos "reportaban" que los tenedores estaban tomados, y luego, muy cinicamente, se ponían a comer. Además así puedo especificar que solo un comensal puede sostener cada palillo.
Oh y también volví aleatorios los tiempos de retardo, porque noté que hay menos problemas así.
Ignoro la razón de esto último.
En la siguiente clase notarán como cree la matriz de la que hablé antes. La gran diferencia en este caso con respecto a mi intento anterior, es que ya solo creo los 5 comensales, y ellos mismos funcionan como buffers.
Y solo para que quede claro, sigo sin usar sincronización.
Esta vez, cambian básicamente tres cosas:
Primero, ya no son tenedores, porque me pareció ridiculo que necesitaces dos tenedores para comer, así que lo cambié por palillos. Tiene sentido, ¿no?
Segundo, guardo los palillos a los que accede cada comensal en una matriz de enteros, donde por defecto el primer valor será el numero de identificación del comensal, y el segundo será 0 o 1, para cada palillo.
Tercero, SEMAFOROS. ¿por qué? Porque me dejo de preocupar por que se mezclen los permisos para tomar los palillos. En mi programa anterior, eran dos sentencias diferentes la que revisa la disponibilidad de los tenedores, y la que efectúa el cambio de disponibilidad, por lo que si dos hilos accedían casi al mismo tiempo a la revisión, era posible que uno de ellos tomara los tenedores e inmediatamente después el otro también, y luego ambos "reportaban" que los tenedores estaban tomados, y luego, muy cinicamente, se ponían a comer. Además así puedo especificar que solo un comensal puede sostener cada palillo.
Oh y también volví aleatorios los tiempos de retardo, porque noté que hay menos problemas así.
Ignoro la razón de esto último.
En la siguiente clase notarán como cree la matriz de la que hablé antes. La gran diferencia en este caso con respecto a mi intento anterior, es que ya solo creo los 5 comensales, y ellos mismos funcionan como buffers.
Y solo para que quede claro, sigo sin usar sincronización.
Los filosofos comensales (first try)
Aqui les traigo mi primer intento a codificar el conocido problema de los filosofos comensales.
"Cinco filosofos se sientan ante la mesa a comer. Cada uno necesita dos palillos para sujetar su alimento, pero solo hay 5 palillos en la mesa. Los filosofos se turnan entre pensar y comer, y siempre hay máximo dos de ellos comiendo"
La primera clase que les muestro es la del filosofo. Aqui básicamente tengo todo lo que requiere éste para cambiar entre pensar y comer. Lo que hace es revisar si ambos tenedores (un objeto por cada uno) están tomados, si no es así, los toma y luego se sitúa al final de la cola de espera.
La clase que sigue es el tenedor. Mi clase main crea 5 de estos junto con 5 filosofos, y funciona con los metodos de colas circulares. Si el filosofo que quiere tomar el tenedor se encuentra hasta arriba de la cola en ambos tenedores, entonces puede tomarlos.
Lo que hace mi clase main es crear 5 de cada uno de estos, y luego los pone a trabajar.
Al principio me pareció una idea bastante buena lo de las colas, pero luego noté que en mi programa solo come un filosofo a la vez. Así que después de moverle por un rato decidí intentar con una estrategia diferente: semaforos. (lo cual es muy parecido a lo que hice, pero es mejor)
Eso lo veremos en el siguiente post.
"Cinco filosofos se sientan ante la mesa a comer. Cada uno necesita dos palillos para sujetar su alimento, pero solo hay 5 palillos en la mesa. Los filosofos se turnan entre pensar y comer, y siempre hay máximo dos de ellos comiendo"
La primera clase que les muestro es la del filosofo. Aqui básicamente tengo todo lo que requiere éste para cambiar entre pensar y comer. Lo que hace es revisar si ambos tenedores (un objeto por cada uno) están tomados, si no es así, los toma y luego se sitúa al final de la cola de espera.
La clase que sigue es el tenedor. Mi clase main crea 5 de estos junto con 5 filosofos, y funciona con los metodos de colas circulares. Si el filosofo que quiere tomar el tenedor se encuentra hasta arriba de la cola en ambos tenedores, entonces puede tomarlos.
Lo que hace mi clase main es crear 5 de cada uno de estos, y luego los pone a trabajar.
Al principio me pareció una idea bastante buena lo de las colas, pero luego noté que en mi programa solo come un filosofo a la vez. Así que después de moverle por un rato decidí intentar con una estrategia diferente: semaforos. (lo cual es muy parecido a lo que hice, pero es mejor)
Eso lo veremos en el siguiente post.
miércoles, 24 de septiembre de 2014
Un ejemplo de hilos no sincronizados (Consumidor y Productor)
He aqui lo último en trabajos sencillos pero efectivos. Un problema de productores y consumidores con hilos en java. 2 productores, 3 consumidores, todo el drama.
El productor
El consumidor
Y finalmente, el main. Aquí llamo a 2 productores y 3 consumidores.
Como pueden ver, los hilos no están sincronizados de ninguna manera. Así que es divertido ver como se pelean por los recursos (literalmente, los recursos).
El productor
El consumidor
Y finalmente, el main. Aquí llamo a 2 productores y 3 consumidores.
Como pueden ver, los hilos no están sincronizados de ninguna manera. Así que es divertido ver como se pelean por los recursos (literalmente, los recursos).
domingo, 21 de septiembre de 2014
La verguenza termina
Este es el cronometro terminado, del que no me averguenzo taaanto.
Primero les paso mi clase lógica, donde manejo el incremento del tiempo segun el estado del thread. Oh si, es un thread.
Ahora esta es mi clase Tiempo, la cual contiene todos los datos de, pues, el tiempo.
Ahora finalmente, mi clase Vista y la interfaz que implementa. El metodo que usa la vista para acomodar todo es el que recibe de la interfaz, y su unico parámetro es un objeto de Tiempo, que contiene todo lo que necesita para acomodar los números.
La clase main simplemente crea el objeto de Vista2 y arranca el thread. No hace nada más.
Y así declaro terminada mi tortura :)
Primero les paso mi clase lógica, donde manejo el incremento del tiempo segun el estado del thread. Oh si, es un thread.
Ahora esta es mi clase Tiempo, la cual contiene todos los datos de, pues, el tiempo.
Ahora finalmente, mi clase Vista y la interfaz que implementa. El metodo que usa la vista para acomodar todo es el que recibe de la interfaz, y su unico parámetro es un objeto de Tiempo, que contiene todo lo que necesita para acomodar los números.
La clase main simplemente crea el objeto de Vista2 y arranca el thread. No hace nada más.
Y así declaro terminada mi tortura :)
Suscribirse a:
Comentarios (Atom)