CEIBO

Domingo 15/junio/2008

Juego de Cartas Web 2.0 ¡En linea!

Filed under: General — Hernan Galante @ 11:54 pm

Estas son algunos de los screenshots que hemos tomado del juego de cartas. Está en línea en este URL. Obviamente, esta en una fase de prueba y puede presentar alguna inestabilidad a corregir. A continuación presentamos algunos ScreenShots del mismo:

Carga del Juego de Cartas
Fig 1. Carga del juego de Cartas

Login del Juego de Cartas
Fig. 2 Login del Juego de Cartas

Registro de usuario
Fig. 3 Registro de nuevo usuario

Configuración del avatar
Fig. 4 Configuración del avatar

Configuración del pelo del avatar
Fig. 5 Configuración del pelo del avatar

Bienvenida al Juego
Fig. 6 Bienvenida al Juego

Jugando entre dos participantes
Fig. 7 Jugando entre dos participantes un juego de Solitario

Participante entrante al juego compartido saludando al oponente 
Fig. 8 Participante entrante al juego compartido saludando al oponente

Hasta aquí hemos presentado unas imágenes del juego que está en versión beta. Aún, por ejemplo, no se ha implementado la persistencia, por lo cual, la registración del juego está en memoria. En caso de reiniciar el servidor, las registraciones se perderían por el momento.

¡Espero que os guste!

Eligiendo la persistencia adecuada

Filed under: General — Hernan Galante @ 11:53 pm

En casi todos los proyectos de software tradicional una de las primeras estructuras que se eligen es la base de datos. Se elige en que motor va a guardarse los datos, antes de saber de que datos hablamos, cantidad, volumen y si la solución adecuada es apropiada. Muchas herramientas de programación incluso, no permiten o no dan soporte prácticamente para trabajar con otra alternativa.
En los proyectos Smalltalk en general, la persistencia, es una de las últimas cosas que se plantean y estudian.

¿Porqué estudiar la persistencia a último momento?

Esta pregunta es interesante contestarla para quienes estén familiarizados con la acción inversa. Todos sabemos que en un proyecto orientado a objetos, el uso de una base de datos puede ser una tarea compleja. Para hacer una analogía, sería como pensar que cada vez que guardamos nuestro vehículo en nuestra cochera, de ante mano debemos desarmarlo hasta los tornillos para poder guardarlo. Y para volver a usarlo como tal, debemos rearmarlo nuevamente. Por lo que podemos deducir claramente que no es natural esta táctica. Alguien le puso un nombre en inglés a esto como “impedance mismatch”. Podría traducirse como “acople de impedancia”, pero a efectos de nuestro objetivo no tiene más significado de que estamos conectando dos tecnologías incompatibles. Para compatibilizarlas, generalmente se usan frameworks de persistencia, que no son otra cosa que “adaptadores”. Como en la electricidad, que usamos transformadores para pasar de 220 a 110v, aquí es lo mismo. Estos frameworks suelen tener su complejidad por supuesto.

En los proyectos de lenguajes tradicionales orientados a objetos, ya usan un estándar o estándares que la misma industria les recomienda, como Spring o Hibernate. Este ultimo resuelve exactamente esta incompatibilidad, para lo cual, la mayoría piensa que ha sido una buena elección y sin dudarlo solo acata elegir el motor de base de datos. La realidad, es que en la mayoría de los proyectos usan herramientas inapropiadas sin analizar sin más detalles si realmente la requieren o si con una solución más simple pudieran obtener una solución perfectamente adecuada. La pregunta que se harán muchos es ¿Que está mal al elegir un framework gigante como hibernate para guardar los datos? Bien, la respuesta es simple, si el sistema probablemente use miles de usuarios y miles de datos, la alternativa sería correcta, pero sería mejor post-poner el uso de la persistencia hasta que el modelo esté maduro. Recién allí, nos inclinamos a hacer persistir el modelo, ya maduro, en la base; optimizando y haciendo lo ajustes necesarios. Si esto lo hacemos mucho antes de lo necesario, traerá complicaciones, que se traducen en más tiempo y al final es dinero malgastado. Esto, debería ser así para cualquier proyecto, pero no, la industria en general opta por complicarse de antemano, tener que echarle mano a scripts SQL para migrar cuando el modelo “inmaduro” va cambiando drásticamente su forma o directamente para evadir esto empiezan a dejar residuos en la base de datos. Claro, hay que aclararlo, una base de datos es una entidad absolutamente pasiva, y ni siquiera sabe que datos son usados y que datos podrían ir a parar a la basura. Como los datos son pasivos, al contrario que los objetos que son entidades activas. Estos últimos pueden aplicar la capacidad de un “Garbage Collector” o recolector de basura, que puede decidir por si solo si ciertos objetos ya no están siendo usados, por lo tanto, pueden borrarse. Si imaginamos esto en una base de objetos, entonces, tenemos que las bases de objetos tienen información más confiable que una base de datos por simple naturaleza.
Muchas veces he visto, por ejemplo, que se usa un tremendo y complejo framework de persistencia para solo “persistir” unos 10 objetos en el modelo, lo que se traduce a unas pocas tablas. Y ni hablar que quizás ese sistema solo tenga unos pocos usuarios. Es decir, tranquilamente se puede optar por sistemas de persistencia más simples y menos complejos. ¿Y que soluciones nos traería algo así? Bueno, para seguir dando ejemplos para entender, hace uno tiempo vi como un producto en el mercado tenía esta “sobredimensión” y el producto competencia en el que trabajé solo mantenía la información que requería en un archivo de formato propio (que no era otra cosa que un sistema de persistencia basado en diccionarios, muy simple). A la hora de competir, este sistema nuevo no paga ningún licenciamiento y requería muchísimos menos requisitos para funcionar. El otro sistema requería instalar por separado el motor, y luego los clientes. Como se imaginarán, no solo a nivel técnico hablamos de menos complejidades, a nivel negocio, era más rentable aquel que tenía menos. O sea, menos es más muchas veces. Como moraleja, deberíamos asumir que no hay que intentar matar mosquitos a cañonazos, o mejor dicho, no intentemos solucionar todo a cañonazos. Aunque algunos políticos ese problema sistémico no lo han entendido, esperemos que la gente que desarrolla sistemas si lo entienda.

¿Qué soluciones serían alternativas a usar una Base de datos relacional?

Dependiendo de la magnitud del proyecto y las de exigencias de este, podemos ir desde persistir en archivos, en el image de Smalltalk, en esquemas de persistencia, usar frameworks de persistencia a Base de datos, o base de objetos.

¿Que soluciones son opciones para este proyecto?

Dentro del marco de investigación para lo que necesitamos, van a desde sistemas de base de objetos como Magma o Goods, a un framework de persistencia sobre Base de datos.

Las solución que se elija debe contemplar:

  • Múltiples usuarios
  • Las 4 leyes básicas de persistencia: ACID (Atomicity, Consistency, Isolation, Durability) o en castellano, Atomicidad (ante cualquier eventualidad ninguna acción queda a medias), Consistencia (Es decir, que cada operación que se realice sobre la información asegura que siempre quedará integra), Aislamiento (Una operación no afectará a otras operaciones) y Durabilidad (es decir, que la información se guardará y permanecerá en el tiempo)
  • Pool de Sesiones, generalmente en un proyecto web, donde existen múltiples clientes no vamos a abrir una conexión por cada conexión web que se realice. El tema principal es que no siempre estamos persistiendo y podrían quedar sesiones abierta contra la base sin demasiado sentido más que malgastar los recursos computacionales preciados. Es por ello que se piensa en un pool de conexiones habilitadas para realizar las operaciones, y ciertos planes de contingencia.
  • Loqueo optimista, es de preferencia para un sitio web. El loqueo optimista asume que siempre hay conflictos y traza su política es base a esto. En el pesimista, pretende estar solo, y si va a haber conflicto debes loquear el objeto antes de usarlo.

Resumen

Se estudiarán varias alternativas de persistencia para el proyecto, la que mejor se adecue será la opción final a usar. Por lo pronto, por cada opción haremos una entrada en el blog para recordar los puntos positivos, los puntos negativos y los puntos interesantes de la cada opción.

Domingo 27/abril/2008

¿Como empezar con SWT?

Filed under: General,Programación — Hernan Galante @ 7:49 pm

Introducción

Una de las principales tareas a realizar cada vez que comenzamos con un nuevo framework o herramienta es saber rápidamente algunos detalles de como manejarnos. Ejemplo de esto son entender la arquitectura básica, saber como realizar las tareas básicas (arrancar, suspender, o detener el proceso) y como obtener las actualizaciones. Mínimamente con estos tres conceptos claros sobre una herramienta podemos usarla y explotarla satisfactoriamente. En este artículo pretendemos dar estos tres conceptos al lector.

Arquitectura del SWT

Smalltalk Web Toolkit es un framework para la construcción de aplicaciones web. Sus principales diferencias con respecto a otros frameworks es su arquitectura basada en Comet y un ambiente Smalltalk cliente hecho en JavaScript a través de un traductor de código Smalltalk-JavaScript. Estas dos diferencias hacen que las aplicaciones web rompan la desincronización del protocolo HTTP (gracias a Comet) pudiendo el server enviar contenido a sus clientes conectados, y gracias al traductor, todo el JavaScript necesario se escribe en Smalltalk sin tener que manipular en un proyecto varios lenguajes y tecnologías, pudiendo el desarrollador enfocarse más en el núcleo de su problema y no tanto en el entorno de como resolverlo.

Tareas Básicas

Algunas de las tareas básicas que requerimos conocer para hacer uso del framework son las siguientes:

1) Como arrancar el ambiente y el servicio
2) Como monitorear el servicio
3) Un “Hola Mundo”

Arrancando Squeak (Linux)

Squeak es un Smalltalk multiplataforma, más allá del ejemplo que citaremos aquí puede correr en muchos otros operativos.

Running Squeak
Fig. 1 - Corriendo el ambiente

Una vez dentro del ambiente, debemos arrancar el servicio. Para ejecutar una expresión Smalltalk la seleccionamos (de manera que todo el texto quede pintado) y luego podemos ejecutarlo con la combinación de teclas ALT+d ó ALT+p.

Arrancando SWT

La manera más fácil de saber si el framework está corriendo es apuntar nuestro navegador a su dirección default: http://127.0.0.1:2222. Si nos muestra la página (Fig. 2) con todas las aplicaciones disponibles, entonces el framework está corriendo.

Presentation web page
Fig. 2 - Página principal de SWT con todas las aplicaciones

En caso de que no esté corriendo, presentamos una serie de expresiones útiles a ser evaluadas en un Workspace de Smalltalk.
Estas expresiones nos permiten parar, arrancar o resetear el servicio.

SWTApplicationRunner start.
SWTApplicationRunner stop.
SWTApplicationRunner reset.
SWTApplicationRunner cleanUp.

¿En que casos debemos hacer uso del reset?
En caso de que se esté produciendo algún error inesperado grave, el #reset para el framework, mata la instancia actual del servicio y lo arranca de nuevo.

¿Cuál es la diferencia con el #cleanUp y el #reset?
El #cleanUp para el servicio, y es un proceso más profundo, hace una limpieza de las instancias de todos los aplicativos y del traductor de Smalltalk-JavaScript. Aunque no vuelve a arrancarlo explícitamente al servicio. Este método es usado cuando queremos hacer alguna actualización o mantenimiento.

Monitoreando el Servicio

El framework loguea actualmente todos sus pasos importantes, la principal salida es el Transcript de Smalltalk. Como vemos en la figura a continuación, en este Transcript nos muestra que se ha “salvado” la imagen del ambiente, y que luego hemos arrancado el servicio con el #start. Allí nos muestra de donde está tomando los recursos (imágenes, sonidos, etc) y en donde está atendiendo el servicio.

SWTApplicationRunner start
Fig. 3 - Arrancando SWT

También podemos ver el log en la consola de Linux, como en la pantalla que continua

Linux console log
Fig. 4 - Log en la consola de Linux

El clásico “Hola Mundo”

No es el objetivo de este artículo como programar sobre SWT, pero explicaremos un simple “Hola Mundo” que nos puede servir como base para comenzar a entender al framework.
La arquitectura del framework para construir aplicaciones se base en una parte cliente (la que correrá sobre el navegador) y la parte servidora (la que correrá sobre el servidor web y será la encargada de manipular a los clientes y proveerlos de la información, eventos y actualizaciones). Las clases en cuestión son: SWTClientApplication y SWTServerApplication. Para crear un nuevo aplicativo solo necesitaremos crear una subclase para el cliente y otra para el server. Tomaremos como ejemplo al aplicativo de “Ping/Pong” el cual es una especie de “Hola Mundo”.

Ping-Pong
Fig. 5 - El aplicativo Ping/Pong

El código del Ping/Pong es bastante simple, la idea detrás del aplicativo es que el cliente muestre una página muy simple, y al cliquear en el botón se envíe un mensaje #ping al servidor, y este le conteste al cliente, con un mensaje #pong.

Existe otro articulo llamado Mini aplicaciones sobre Smalltalk Web Toolkit (SWT) que abarca a este ejemplo de “Hola Mundo” en profundidad.

Actualizando SWT

¿Como mantener actualizado el código en SWT? Para responder esta pregunta, vamos a explicar como un proyecto en Squeak, en general, también se actualiza y mantiene. Existe un servicio, que es un repositorio de código para Squeak llamado SqueakSource.

Squeak Sourcepage
Fig. 6 - SqueakSource

En este sitio hay docenas de proyectos open source para la comunidad. SWT es un proyecto más publicado de esta manera. El sitio oficial dentro de SqueakSource es http://www.squeaksource.com/SWT.html. La mejor forma de mantenerse informado es apuntar nuestro lector de RSS favorito a http://www.squeaksource.com/SWT/feed.rss. Cada nueva versión que se publique será publicada de forma automática. Para actualizar nuestro ambiente Squeak a esta nueva versión usaremos una herramienta llamada Monticello. (Fig. 7)

Actualizando con Monticello 1
Fig. 7 - Creando un nuevo paquete en Monticello

¿Como actualizar usando Monticello?
Monticello se abre desde el menú principal de Squeak (dando click sobre el escritorio de Squeak se despliega un menú). En el menú, elegir las opciones “Open” y luego “Monticello browser”.

Menu para abrir Monticello
Fig. 8 - Secuencia para abrir Monticello

Una vez que tenemos abierto el Monticello, debemos crear un nuevo paquete (Package), nos pedirá el nombre, al cual nombraremos como SWT o como nos sea útil. Luego, que tenemos el nuevo paquete, le vamos a indicar donde está el repositorio, dando click en el botón que dice “+Repository”. Elegimos la opción HTTP, e ingresamos la dirección en el cuadro http://www.squeaksource.com/SWT.

Actualizando Monticello 2
Fig. 9 - Después de crear el paquete, creamos el repositorio, y seleccionamos el HTTP

Una vez creado el repositorio, lo seleccionamos y presionamos el botón “Open”. Esto hará que se conecté al repositorio, y nos abra otra ventana donde nos mostrará las versiones disponibles para cargar desde el repositorio en nuestro ambiente.

Actualizando Monticello 3
Fig. 10 - El repositorio mostrando los distintos frameworks y sus versiones para ese proyecto

Para actualizar nuestra versión simplemente elegimos la versión, y luego apretamos el botón “Load” (cargar).
Cuando esta operación termine nuestro ambiente estará con la versión que hemos seleccionado. Si una versión es dependiente de otra versión, nos preguntará si también lo deseamos cargar.

Resumen

En este artículo hemos visto como arrancar el ambiente, como actualizarlo y como hacer los mantenimientos básicos.

¿De donde bajar Smalltalk Web Toolkit?

Filed under: General,Programación — Hernan Galante @ 7:49 pm

¿De donde se puede bajar la versión?

Se ha publicado una versión del framework actual en la siguiente dirección:

http://smalltalk.consultar.com/varios/SWT-full.zip

¿Que contiene el archivo Zip?

El Zip contiene los archivos necesarios para correr el ambiente para SWT en las plataformas de Linux y Windows.

Contiene los siguientes directorios:

  • Files: Contiene las bibliotecas javascript para SWT
  • Packages-cache: Es utilizado por la herramienta de paquetes de Squeak
  • Resources: Son todos los recursos (imágenes, sonidos, etc.) que usan las distintas aplicaciones sobre SWT
  • Sm: Es utilizado por la herramienta de paquetes de Squeak

Contiene los siguientes archivos:

  • Archivos independientes de la plataforma:
    • Squeak3.8.1-6747full.38.changes: Es el archivo de cambios del ambiente
    • Squeak3.8.1-6747full.38.image: Es el archivo imagen de Squeak.
    • SqueakV3.sources: Es el archivo que contiene los fuentes de Squeak.
    • Splash.bmp: Es la imagen visual que se ve al arrancar el ambiente.
  • Archivos exclusivos para Linux:
    • Squeak-3.9-8.i686-pc-linux-gnu.tar.gz: Contiene la máquina virtual para instalar en Linux
  • Archivos exclusivos para Windows:
    • SqueakFFIPrims.dll: Librería para primitivas exclusivas para Windows
    • Squeak.ini: Configuración de la máquina virtual sobre Windows
    • Squeak.exe: Ejecutable para Windows

¿Cómo lo corro desde Linux?

En un Linux, recordamos que esta versión ha sido probada en Ubuntu 7.10, instalar la máquina virtual que se encuentra en el archivo Zip, Squeak-3.9-8.i686-pc-linux-gnu.tar.gz. Dentro de este archivo encontrarán las instrucciones para llevar a cabo la instalación de la máquina virtual sobre Linux.

¿Cómo lo corro en Windows?

En Windows correr el archivo Squeak.exe y este nos abrirá el archivo .image que encuentre dentro del mismo directorio.

En Windows encontraremos un error, dado que esta versión está siendo desarrollada para Linux.  Para ello hay que desactivar (simplemente comentando el código) en

Alogger>>logMessages:
....
   "Try to log to stdout, using OSProcess"
   "Smalltalk at: #OSProcess ifPresent: [:osProcessClass |
    osProcessClass thisOSProcess stdOut
     nextPutAll: msg;
     nextPut: Character lf.
   ]."
....

¿Otras plataformas?

Dado que Squeak es un ambiente Smalltalk multiplataforma, podemos encontrar en su sitio oficial muchas máquinas virtuales para correr la imagen (que no depende de la plataforma ni del sistema operativo). Con solo seguir las instrucciones de como instalar para una plataforma en especial para Squeak, también lo estamos haciendo para SWT. Sólo deberemos descomprimir la imagen (archivo extensión .image) y correrlo con el ejecutable o binario de nuestra plataforma y SWT estará corriendo.

¿Sobre que Sistemas operativos ha sido probada esta distribución?

La versión está preparada para Linux. Pero también ha sido probada sobre Windows. Ver en las preguntas anteriores los detalles de como instalar.

Miércoles 5/marzo/2008

Diseño de baraja en 3D

Filed under: Diseño,General — Diego Gomez Deck @ 11:00 am

Ya tenemos bastante avanzado el diseño de una de la barajas que incluiremos en el juego.

cartas3d.png

Pueden descargar los PNGs desde forjamari. Más información en http://igosoftware.wordpress.com/

Miércoles 26/diciembre/2007

Bienvenidos a Ceibo

Filed under: General — raquelmartinez @ 12:51 pm

Ceibo es el nombre que hemos elegido para este proyecto. ¡Seguramente ha influido mucho que haya argentinos en él!.

Pues bien, Bienvenidos al blog que utilizaremos para desarrollar este proyecto: “Desarrollo de Videojuegos en Software Libre. Tipología: Inteligencia, Habilidad, Puzzles.

La Vicepresidencia Segunda y Consejería de Economía, Comercio e Innovación de la Junta de Extremadura ha adjudicado el concurso abierto “Desarrollo de Videojuegos en Software Libre” a la U.T.E compuesta por Fomento y Medio Ambiente de Extremadura y ConsultAr.com.

Se trata de un videojuego de cartas web con la baraja española. Habrá juegos monojugador (solitarios) y multijugador (Burro, Mus, Cuatrola, Tute, Brisca, Escoba), no necesita ningún tipo de instalación ni agregado alguno y es totalmente extensible.

Estado actual

Para el desarrollo del motor y de los juegos de cartas se utilizará el lenguaje y entorno de programación Squeak, responsable de proveer la infraestructura para las partidas de los diferentes juegos y de infraestructuras de comunicación en tiempo real entre los participantes incluyendo un chat por cada partida.

La interfaz gráfica de usuario será completamente dimensionable. El usuario accederá desde un portal principal donde se mostrará toda la información disponible de forma resumida. Desde la página de entrada, el usuario podrá ver la lista de juegos disponibles, los usuarios conectados, las partidas abiertas, los torneos… Además puede darse de alta y configurar su avatar.

El motor de juegos incluirá funcionalidades para creación y juego de torneos.

Como uno de los objetivos es aumentar la sensación de interacción entre las personas, los usuarios pueden configurar la apariencia del avatar que los represente dentro de los juegos.

El motor incluirá la opción de descarga de juegos individuales para su uso desconectado.

Otra característica es que los juegos podrán utilizar temas para cambiar su aspecto y también incluirán efectos visuales y de sonido.

Usaremos este espacio para ir informando del avance del proyecto. Iremos publicando diferentes notas sobre las nuevas características y funcionalidades del juego y además intentaremos que este blog se convierta en una herramienta más para el proyecto.

Desde aquí os invitamos a que participéis, se admiten quejas y sugerencias.
¡Manos a la obra!

Crea un blog o un sitio web gratuitos con WordPress.com.