Recta final!

Algunos detalles con la conexión en la base de datos fueron corregidos, pero aún falta guardar en un archivo la configuración.

El jar ya funciona con la última versión generada.

La documentación fue al fin generada en un sólo archivo, bueno en dos, uno para server y otro para client.

También, comenzamos a generar ideas para el storyboard que se verá en nuestro video final.

Avance 4/26/10

Al fin la aplicación ya está disponible tanto en su versión local como en su versión de cliente-servidor aunque aún no esta creada la opción para elegir cuál de las dos se quiere usar, pero ambas están listas y funcionan!

Por otro lado, se sigue desarrollando el lado de configuración del puerto, host y dirección de la base de datos, así como tratar de implementar lo más que se puda las recomendaciones de interfaces de java.

También estamos intentando hacer pruebas para empaquetar nuestro proyecto en un archivo jar.

Avance 4/19/10

El día de hoy la aplicación del servidor comenzó a desarrollarse.
Se implementó el método read que se especifica en la interface, aunque tuvo que cambiarse de nombre a read-record porque read ya existe dentro del core de clojure.

Un pequeño detalle se corrigió del servidor local, aunque no causaba errores anteriormente.

La aplicación cliente-servidor se implemetará totalmente haciendo algunos cambios a como se hacía anteriormente para poder acoplarnos a la interface que se nos pide. Después, se acoplará la versión local para que también pueda funcionar bajo las mismas especificaciones.

Avance 4/13/10

El día de hoy logramos mandar de un servidor a un cliente un mapa de clojure serializándolo en el servidor y deserializándolo en el cliente, usando algunas funciones de clojure, ahora solo falta que el mapa que se envíe, sea el mapa de la base de datos.

Por otro lado, la interfaz para las configuraciones de conexión comenzó a desarrollarse.

The GUI strikes back!

Al fin pudimos subir una versión decente de la interfaz al repositorio. El principal problema fue que el desarrollo de interfaces utilizando clases de Java es completamente horrible (sin ayuda de algún Swing Builder claro =P). La interfaz es simple, pero cumple su función.

El segundo problema fue la traducción a lenguaje Clojure, ya que primero se diseñó la interfaz en Java. Durante la 'migración' entre lenguajes nos pudimos dar cuenta de que el lenguaje Clojure es mucho más limpio que en Java, no solo en extensión del código sino en legibilidad y en redundancia de código. Es oficial, Clojure es hermoso. Swing con Clojure es horrible. =P

Quinta reunión en equipo

En esta sesión se siguió trabajando en el diseño de la interfaz gráfica, pero como aún no hay nada funcional, no se subió al repositorio de control de versiones.
También se continuó con los métodos para buscar los registros. De igual forma, no hay todavía nada funcional para subir al repositorio.
La interacción con la base de datos se movió a un paquete para hacerse cargo de ello, y que los demás paquetes solo lo llamen a él.

Debido a que el lunes no hay actividades, nuestra siguiente reunión será en una semana, pero trabajaremos en nuestras casas para seguir avanzando.

Cuarta Reunión en equipo

En la cuarta reunión de proyecto, tuvimos una pequeña charla sobre como podríamos hacer que la edición sobre un mismo campo (apartado de un cuarto) se realizara de manera sincronizada. Se planteó el uso de un token sobre el registro para que la persona que lo tuviera pudiera hacer su apartado y que nadie más pudiera hacer algo sobre el mientras tuviera el token. Ahondamos un poco en la forma en la que se iban a pasar los datos desde la interfaz para hacer la búsqueda y el apartado de un cuarto.

Todos los integrantes asistieron de manera puntual a la junta.

Terecera reunión de equipo

En esta reunión nos centraos en aanalizar cada uno de los requerimientos del proyecto. Decidimos poner las excepciones que creemos en el paquete que le corresponde.

i.e. noPuedoLeerException iría en el paquete io.

Definimos los criterios para implementar la búsqueda y la atualización de estados en los registros.

Segunda reunión del equipo

Revisamos lo que la interfaz gráfica debía de llevar junto a las funcionalidades principales del sistema.

Además se comenzó a trabajar en el archivo writer.clj que escribe la base de datos en el sistema, hasta ahora solo escribe los números mágicos del principio y las cabeceras de los campos.

Primera reunión del equipo

Hoy fue la primera reunión 'formal' para comenzar a trabajar en el proyecto urlybird. Félix, Favio y yo nos quedamos de ver en el CCI para definir cómo vamos a trabajar durante estas semanas. Por cierto, Favio no llegó (vive cruzando la calle del tec) -_- ... pero estuvo presente a través del chat n_n.

Acordamos seguir la práctica de time-boxing, dividiendo nuestras actividades a través de sprints o iteraciones de una semana de duración. ¿Porqué una semana? Bueno, debido a que consideramos que ponernos pequeñas actividades por semana aumenta el avance general, es decir, tendremos un avance incremental. La duración de una semana por cada iteración lo dejaremos en un estado de 'veremos', ya que tenemos que ver si es nuestro ritmo de trabajo o lo modificamos.

También definimos que tendremos reuniones los días Lunes y Jueves de 8 am a 9 am, en donde platicaremos del avance de nuestro proyecto, los problemas encontrados y nuestras próximas actividades. Trataremos de variar el lugar de las reuniones, a veces en el edificio EGAP-EGADE (a.k.a. CCI), otras veces en la biblioteca y otras veces en la cafetería o en las tortas (¡los programadores tenemos que desayunar también!). Las reuniones serán objetivas y un tanto informales.

La forma de llevar un registro de nuestras actividades será a través de un documento de google docs, donde se dividen las actividades generales, por iteración y responsables. Si les interesa echarle un ojo a nuestro documento, mándenme un email y con gusto les doy acceso.

¡Comenzamos con todo! :)

"Change that does not result in success is mere movement." Venkat Subramaniam (@venkat_s)