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?.

¿Para que desaprovechar otro curso haciendo pruebecitas que no sirven para nada?

En este no vamos a hacer tontadicas, y dado que nuestra madre IEPALA tiene necesidades nos vamos a remangar y a hacer faena. Hay dos proyectazos:

1.- Memoria de IEPALA.

http://www.memoria.iepala.es/

Existe un blog con wordpress en el que se han ido volcando las actividades de IEPALA para que se puedan ver, y para que sirvan como memoria de la organización. No entraremos a analizar su uso real (eso nos llevaría a procesos internos), pero lo que esta claro es que a medida que de una u otra forma se vaya utilizando, necesitamos “algo mas”, o “algo mas especifico”, o “algo que podamos tocar”,… etc.

Vaya, ideas en el aire, pero que son las que nos ponen en esta situación. Esas “ideas en el aire” son varias cosas que deberíamos analizar. Y al que no se si lanzarme en este post. Ahora me lo voy pensando.

2.- BBDD institucional.

La base de datos institucional básicamente es una aplicación solo de uso interno, que funciona por decirlo mal y rápido como una aplicación de e-mailing. Spam del nuestro. Como en el anterior caso no entraremos a analizar su uso, aunque aquí cabe destacar que es una aplicación mucho mas necesaria de lo que parece, y que tiene un uso sostenido en el tiempo. Está en PHP (para vergüenza mía es un hijo de un servidor de ustedes).

¿Cual es el problema de esta aplicación? Usabilidad. Ese fantástico termino que en esta caso nos viene que ni pintado. La idea es simplificarlo (desde el punto de vista del usuario), quizá unificar algo el modelo de datos, y sobretodo hacer transparente una serie de funciones y chequeos básicos que ayuden a limpiar y ordenar la información.

————-

Este es el ejercicio que tendremos que resolver en este curso. Nos centraremos en el 1. Pero según las fuerzas con las que nos encontremos quizá merezca la pena pensar en el 2.

Pero como siempre he tenido complejo de maestro espiritual vamos a ir a las cuestiones de “fondo” o por el contrario a las cuestiones de “altos vuelos”:

¿Por que?… ¿Por que migrar? ¿Por que en RoR?

Los tags ahora serian cosas como: análisis, adecuación soluciones, procesos, gestión información, cultura RoR, usabilidad,… etc. Osea las que cuestiones que molan. Hoy de momento no me meto con estas cuestiones. Estos post no corren mucha prisa, podemos ir hablándolos poco a poco.

Bueno vamos allá. Primero la referencia Ruby. La web de Ruby-Docs:

http://www.ruby-doc.org/docs

Aqui una Ruby User’s Guide muy “desde el comienzo”. Además tendréis la imprescindible documentación de la API.

Desde ella (aunque  se puede encontrar en muchos otros sitios) al clásico de  Programming Ruby (Pragmatic Programmer’s Guide):

http://www.ruby-doc.org/docs/ProgrammingRuby/

Este libro es: directo, elegante, complejo. Vaya mu bueno.

Evidentemente y poniéndome protocolario, todo el tiempo que se le dedique al núcleo del asunto, el propio lenguaje Ruby, no es tiempo perdido (os lo digo por experiencia por que soy de los que ha aprendido muy mal). Venga y para acabar en español:

http://www.ruby-lang.org/es

En esta web tienen referencias a guías y cosas por el estilo. Tiene un apartado de documentación con varias cosas. (NOTA: en documentación no he visto la traducción del libro Programming Ruby, pero se que en su día si que la hubo osea que sera cuestión de rastrear un poquito)

Vale pues con esto se acabo lo relacionado con Ruby. Ahora pasamos a Rails . Por una lado la web de rails:

http://www.rubyonrails.org

No es que tenga gran cosa, pero bueno, es la web “oficial” ¿No?. Desde puedes llegar a la documentación de la API. Por cierto esa misma documentación también esta accesible con lo que esta en el post anterior (gem server)… O incluso en vuestro propio proyecto generándolo con la tarea Rake correspondiente (ver rake -T).

Pero bueno vamos a libros de calidad. Primero el clásico:

http://www.pragprog.com/titles/rails3/agile-web-development-with-rails-third-edition

Esta ya en su versión para Rails2 (que es la que utilizareis vosotros). Nada que no sea fácilmente conseguible en las fantástiscas redes P2P para compartir (sed legales por favor… canalla el puto Molina). Este libro esta muy bien para enterarte de todo. Es un recorrido de la leche por el framework.

Y finalmente para cosas mas complicadillas, os dejo los libros de recetas de rails. Son recetillas que aunque tu no las necesites de momento es muy recomendable echarles un ojo e ir enterándose

http://www.pragprog.com/titles/fr_rr/rails-recipes
http://www.pragprog.com/titles/fr_arr/advanced-rails-recipes

Además de esto todo lo comentado, y como en cualquier comunidad que se precie de tal, tendréis una serie de listas en castellano.

Salud, gracias por asistir a esta clase, y en fotocopiadora podréis recoger los apuntes…

——————-

PD: existen dos blogs de gente en castellano, que por ser majetes y conocidos os los pongo aquí para que tengáis referencias:

El de la compañera de proyectos Amaia: http://apuntesderails.amaiac.net/
El de Jaime Iniesta: http://www.jaimeiniesta.com/

Pues la clase primera evidentemente es la de instalar RoR. En realidad no habrá muchas mas clases de estas. En realidad no creo que haya muchas mas clases. No voy a ponerlo todo fácil, asi es que dare solo las ideas generales.

Por cierto y antes de empezar que todas estas cosas se encuentran fácilmente por todas partes, por ejemplo aquí:

http://agileweb.wordpress.com/2008/07/18/how-to-install-rails-21-on-ubuntu-in-5-steps/

Adelante. Primero las cosas con apt. Mas o menos supongo que todos tenemos Ubuntu.

(apt-get) Instalar ruby. Pero cuidado: nada de la ruby1.9, si no el ruby1.8. (hace poco que me comentaron esta gracia)

apt-get install ruby

(apt-get) Instalar rubygem. Y claro: que sea coherente con lo anterior, por que hay dos paquetes de el 1.8 y el 1.9. DETALLE: este 1.8 y 1.9 no son la versiones del paquete rubygem si no la versión de ruby que utiliza ese gestor de gemas.

apt-get install rubygems

NOTA (deprimente para los buenos programadores): En Ruby, pero especialmente en Rails, no hay mucho respeto por el tema de mantener integridad (no recuerdo el termino informatico) entre las versiones. Suena chapuzas, pero es asi.

Bueno, y se acabo volver a utilizar el apt-get, a partir de ahora usaremos las gemas.

Pero la cosa graciosa es que ahora que la versión que tenéis de las gemas (que posiblemente será la 1.2.0) querréis actualizarla (a la 1.3.0). ¿Por que? según las webs es “recomendable” (Mmmm… que misterioso… en realidad mi conclusión es que hay mucha ignorancia, pero como yo tampoco me libro de eso, me callo). Asi es que intentar un:

gem update –system

Pues resulta que casca verdad. Algo de que:

“gem update –system is disabled on Debian….”

Pues vaya catxondos. Si queréis actualizarla probad esto:

http://apuntesderails.amaiac.net/archives/2008/12/2/actualizar_rubygems_a_la_versi%C3%B3n/

Es de amaia que tiene muchas cosas de rails.

Sigamos. Con esto tenemos el gestor de gemas actualizado. Si queréis probad a ver el gem –help y esas cosas. De todas formas a lo importante:

gem install rails

Podríais especificar la versión de la gema añadiéndole -v version

Y ahi os instalara las 4 cositas básicas. Quizá algo os va lento, o quizá algo falla, repetirlo, o intentar instalar alguna gema por separado. Es un consejo poco riguroso, pero mas de una vez me ha funcionado. En cualquier caso y en esencia tendréis varios paquetes importantes, y que componen el núcleo del framework. Hacer un:

gem dependency rails

Y veréis:

Gem rails-2.0.2
rake (>= 0.7.2, runtime)
activesupport (= 2.0.2, runtime)
activerecord (= 2.0.2, runtime)
actionpack (= 2.0.2, runtime)
actionmailer (= 2.0.2, runtime)
activeresource (= 2.0.2, runtime)

En mi caso tengo la 2.0.2 por que es en la que esta mi desarrollo. De todas formas hoy no voy a explicar conceptos (aunque es lo que mas me gusta) así es que si queréis buscaros una guía. Por otro lado si queréis ver las nuevas cosas que tiene cada actualización de Rails acabo de ver a un brasileño que se ha impuesto la penitencia de que cada vez que hay una nueva versión de rails hace un nuevo libro de “Whats new on Rails x.x.x”.

http://www.nomedojogo.com/

Bueno con esto esta casi todo, para tener una aplicación os colocáis donde consideréis de vuestro sistema de ficheros y hacéis un:

rails mi_aplicacion

Una vez tenéis hecho solo detallo que por defecto rails quiere utilizar una base de datos sqlite por detrás así es que para utilizar mysql tendréis que configurar el fichero config/database.yml adecuadamente. Esto os lo dejo a vosotros (tanto la instalacion de mysql como sqlite, como su configuracion en rails).

Pero para ello en la clase 2 os dejare una serie de referencias para que podáis ir leyendo.

——————–

Apéndice 1

Si quieres ver la documentación disponible de cada una de las gemas que has instalado solamente:

gem server

Esto levanta en el 8808 un índice con toda la documentación RDoc de las gemas instaladas en tu sistema.

———————

Apendice 2

Este es una cosa nueva bien fardona. En vuestro primer proyecto de prueba hacer:

rake doc:guides

Os creara en la carpeta doc/guides de vuestro proyecto una serie de guías de documentación para empezar con rails. Pijadas de esta gente. Por cierto si queréis ver todas las tareas rake que tenéis por defecto en vuestro proyecto creado con rails hacer:

rake -T

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”