lunes, 17 de mayo de 2010

Final


Hola a todos, este fín de semana (y hasta hoy), hemos estado trabajando en varios aspectos importantes del proyecto. Podemos finalmente decir que el proyecto trabaja al 100% tanto de manera local, como en forma distribuida. Además de terminar la parte de servidor y cliente, estuvimos de igual forma haciendo pequeños ajustes en el funcionamiento del sistema a nivel local.

Decidimos usar referencias como mecanismo de concurrencia, para garantizar consistencia en las operaciones sobre la base de datos.

Estuvimos trabajando además en la edición del video, quísimos hacer algo distinto de lo que habíamos visto en videos de semestres anteriores y de las ideas que nos habían expresado otros equipos y estuvimos buscando enfoques interesantes, aunque siempre tuvimos en mente que se involucrara la escritura en papel (en el video, interactuamos con un prototipo en papel de nuestro proyecto).


Quizá el único punto negativo, es que hasta este momento estamos teniendo algunos problemas con la creación del archivo jar, esperemos que el día de mañana ya estén resueltos.

viernes, 14 de mayo de 2010

Sockets!

Sesión llevada a cabo el 26 de abril de 2010


Hola gente, en esta ocasión nos reunimos en el tec con la intención de empezar a planear como va a funcionar la versión distribuida de Urlybird. La reunión consistió básicamente en ampliar lo visto en clase sobre los Sockets de Java, y comenzar a barajear opciones sobre la funcionalidad de cliente y servidor. Nos dedicamos a jugar un poco con los códigos escritos en clase. Y además nos dimos la oportunidad de llevar un libro de Java para echarle un vistazo a sus ejemplos sobre servidores y clientes.

Mientras leiamos el libro vimos que existia otra opcion para llevar el proyecto a una version distribuida que era llevando a cabo el model RMI. Lamentablemente a la hora de preguntarle a los compañeros si podiamos utilizar este método nos mencionaron que no era posible, que era obligatorio el uso de sockets :(

viernes, 9 de abril de 2010

Cuarta sesion


Esta fue la última sesión que tuvimos antes de salir de vacaciones de semana santa.

La sesión tuvo lugar en Tec de Monterrey, en el edificio de CCI, en la cual estuvimos presentes Carlos, Carlos y un colado Alex Chivas.

En dicha sesión estuvimo platicando, sobre la forma que agregaríamos un nuevo record a nuestra base de datos, y decidimos que sería buena idea crear una nueva pantalla para que el usuario solo llenara los datos que se le piden.

En la sesión nos dividimos el trabajo, Carlos Garcia fue el responsable de realizar la GUI, y Carlos Fabela fue el encargado de realizar la logia del programa para agregar los datos a la base de datos.

El problema que tuvimos y que aun tenemos es que los datos nuevos se agregan al final de la base de datos y no re usan un registro eliminado, esperamos que en el transcurso de la semana del 11 al 16 de Abril quede esto.


miércoles, 17 de marzo de 2010

Sesión 2 atrasada



Para la sesión 2 se repartieron los distintos métodos del servidor que le corresponde a cada Carlos, esto fue realizado con el objetivo de disminuir la carga de trabajo y hacer que cada quien tenga las mismas responsabilidades.

Al ser la segunda reunión nuestra mayor complicación fue adaptarnos a clojure ya que en muchas ocasiones es necesario escribir la prueba o lo que se desea hacer en java para poder identificar lo que se tiene que utilizar dentro de clojure, un aspecto negativo de esto es que toma mayor cantidad de tiempo repetir las cosas y más si existe algún problema dentro de java.

Los avances que se lograron fue dar inicio y comprensión a cada método que se va a realizar, esto incluye nuevos métodos que por ahora no se consideran como parte fundamental del proyecto pero se tiene considerado que sean bastante benéficos para facilitar el uso de los campos de las búsquedas.

(foto1-> carlos y carlos)

(fotógrafo -> carlos)

Tercera sesión









(foto1 -> carlos)

(foto2 -> carlos y carlos)

(fotografo -> carlos)

Nos encontramos en nuestra tercera sesión de trabajo, para esta sesión nuestro principal objetivo es que se puedan ingresar datos a la tabla de la interfaz gráfica, donde se necesitó de buscar alguna alternativa para facilitar esta escritura. Se puede decir que la manera más sencilla y eficiente es utilizando DefaultTableModel, en donde solo consta de dar formato a lo que se va a agregar en cuanto a columnas y renglones. Un aspecto importante es que al utilizar un arreglo este de manera sencilla se puede agregar al renglón que se necesita llenar.

Por otra parte están surgiendo otras complicaciones como en el caso de escribir en un archivo usando DataOutputStream, donde al utilizar el método de “writeInt” no escribe el valor del entero a diferencia en java hace lo contrario respeta el número que se esta asignando al archivo final.

También el crear un arreglo basándose en la información del mapa esta resultando bastante complicado ya que es necesario para ir desplegando los campos en su respectiva posición de la tabla. La mejor manera de manejar esta información es separarla por loops y creando métodos que tengan como base el mapa que contiene toda la información necesaria para separarla de manera rápida.



miércoles, 3 de marzo de 2010

Licencia GPL v3

Decidimos utilizar GPL3 por que la compatibilidad con otras licencias de distribución de software libre como MIT License hace que el código sea mucho más compatible ya que si se llegara a utilizarse otra licencia, aunque este basada en gpl, podría llegar a generar muchos conflictos en los que tendría que intervenir un experto que inicialmente era lo que se buscaba con gpl. Aunque la libertad de generar licenciamientos existe y estos estén en base a gpl estos podrían generar conflictos como ambigüedad, y entre otras razones que pudieran llegar a ser incompatibles al código con otras licencias obligaría a los usuarios y programadores a reescribir el código en lugar de reutilizarlo que causaría el incremento del tamaño de los archivos y por ende mayor consumo en el disco duro y memoria RAM que causaría una mala eficiencia de la administración de recursos como la repetición de ciclos por programas repetidos.

Por otro lado la opción de patrón de software no sería muy viable ya que creemos que las ideas, el intelecto, o la forma de pensar de los seres humanos no debería limitarse a aquella persona que lo pensó primero siendo que cualquiera podría llega a la misma solución o mejor y es por esto que no creemos que el patentar una idea sea apropiada para la constante evolución del intelecto de las personas, claro sin menos preciar el esfuerzo que trabajo en dicha solución.