Bueno pero este post es para presentar una definición de requisitos para la memoria. Eso, dicho asi, con ese peso, no lo voy a poder llevar palante. Así es que lo que voy a hacer es presentar algunas ideas de lo que tendría que ser la aplicación (que quizá son también parte del análisis).

La idea general de la aplicación es que los diferentes trabajadores de iepala, entren periódicamente al sistema y reflejen información sobre las actividades que están desarrollando. Con esto se va elaborando colectivamente la memoria de la organización, que puede ser accesible online (con todos los temas de transparencia que esto conlleva) y que podría tener una salida “por atrás” en forma de documento unificado (para presentar a patronatos y cosas de esas).

Echarle un ojo a la web y os haréis una idea: http://www.memoria.iepala.es

Pongo una especie de modelo de datos simplificado con lo primero que se me ha ocurrido:

La idea central del mismo es que todo se podría resolver con simples (o complejas “etiquetas”, pero la realidad de IEPALA demuestra que gustan de las jerarquías. Entonces en vez de crear una campos para cada tema vamos a categorizar las etiquetas. Por otro lado esas categorías deberían tener 2 características basicas:

• Poder bloquear el editar o añadir etiquetas en una determinada categoría.
• Poder clasificar esas categorías en algo asi como “descriptivas” (serian las que tenemos en la barra de navegación derecha) o “contenidos” (medios de comunicación, organizaciones,… etc)

Lo bueno de dejar este modelo de etiquetas y categorías es que puede crecer conforme se les vaya ocurriendo. Y además refleja una jerarquía que le aporta control a la gente. Finalmente añada una batería de fechar que se pueden asociar con una actividad y el tema de vincular adjuntos (esto es para que empecéis a utilizar plugins). Por supuesto cualquier idea en en el modelo de datos sera bienvenida.

Por otro lado aqui os pongo el diagrama de casos de uso

Rápidamente describo:

• Evidentemente hay dos tipos de usuarios registrados: El editor y el administrador (no hace falta mas complejidad para nuestro sistema).
• El administrador gestiona usuarios y categorías. (NOTA: Y además tiene permisos para modificar cualquier “post”)
• Un editor puede crear, modificar y eliminar sus actividades.
• El visitante vera el sistema como un blog (aunque por defecto las actividades aparecerán en orden de realización de la misma y no de creación en el sistema) y podrá hacer filtrados por las etiquetas (algunas le aparecerán a la izquierda) y búsquedas mas complejas.

Evidentemente un tema clave para esta aplicacion lo tendremos en el tema de la impresion de informes. Pero eso no sera para esta proxima clase.

Vale pues con esto nos juntaremos en otra clase presencial y unificaremos en un solo código.

Salud.

—————-

Como nota final dejar constancia de que lo mas importante aun no lo hemos abordado: ¿Por que estamos migrando esta aplicación? ¿Por que a Rails?.

Será sin ritmo, con un profesor un tanto novato, pero creo que interesante para todos. Confirmar vuestra presencia (se admiten comentarios).

El plan es tener un par de sesiones presenciales preparadas, y luego ir viendo posibles quedadas, mientras avanzamos por comunicación diversa (correo, y este blog).

OBJETIVO GENERAL: Que os lancéis a poder hacer cosas en RoR.

OBJETIVOS ESPECÍFICOS:
* Manejarse en Ruby.
* Entender el framework Rails.
* Debatir la cultura Rails.
* Que podáis empezar a desarrollar o tocar cosas en RoR.
* Debatir RoR en el marco de problemas/soluciones concretas.

OBJETIVO TANGENCIAL:
Definición conjunta de buenas practicas en el desarrollo. SVN, TRAC,
Testing.

METODOLOGÍA:
* Guiada por el desarrollo de una aplicación.
* Encuentros presenciales para unificar ritmo.
* Correos o posts sobre referencias y pasos básicos.
* Solucionar por correo problemas o dudas (al ritmo que se pueda).

Tiempo total del curso: Pendiente de negociación, pero asi de arranque un par de meses (Febrero y Marzo).

Bueno, en definitiva, este primer post era para crear el tag: “curso RoR 09”