Una propuesta para el modelo

[DrSlump]

Antes de discutir que framework usar o que patrón de desarrollo es el
ideal creo que lo mejor es empezar a definir un modelo de datos para
la aplicación. Como el UML además de complicado es un dolor de muelas
voy a exponer un posible modelo utilizando Json (más bien literales de
javascript) que lo entendemos todos y es muy sencillo de escribir.

El modelo está pensado con dos prioridades en mente: facilidad de
implementación y máxima flexibilidad. De hecho solo voy a definir dos
tipos de entidades: Tarea y Auditoría. Mi idea inicial era reducirlo
todo a una Tarea pero para facilitar la implementación y pensando en
optimizar el transporte de datos he decidido dividirlo en esas dos
entidades donde la Auditoría es opcional y solo sería necesaria para
generar informes.

Una Tarea sería algo así:

{
id : 'A12HDEF213FG21BC',
code : 'newproject',
title : 'My new Project',
description : {
format : 'html',
value : 'This is my <strong>first</strong> project',
},
priority : 'normal',
status : 'new',
parent : null,
children : [ 'BFA31D8742BCD', '233HGFDAC239C' ],
hours : {
projected : 50.0,
children : 34.0,
worked : 5.3,
},
attachments : [
{
name : 'layout.png',
mime : 'image/png',
size : 485234,
},
],
owner : 'drslump',
cc : [ 'dani', 'gerard' ],
bcc : [ 'in...@cliente.org' ],
tags : [ 'published' ]
}

La idea es utilizar un espacio global para todas las tareas a fin de
facilitar la implementación. Las tareas tienen un estructura de árbol,
lo que permite una organización jerarquica en lugar de relacional que
en mi opinión es más sencilla de comprender y de utilizar.

"id" es el identificador global de una tarea.
"code" es un identificador propuesto por el usuario que debe ser único
en su misma rama del árbol, se puede utilizar para referenciar una
tarea de una forma facilmente recordable (i.e.: /myproject/3 sería la
3 tarea del projecto 'myproject' ).
"title" es simplemente el título de la tarea.
"description" es importante porque además de describir una tarea puede
servir para incluir información del cliente en una tarea raiz (un
proyecto).
"priority" y "status" son simplemente la prioridad y el estado.
"parent" si es Null es que la tarea es una raiz, si es un string es
una referencia a la tarea padre.
"children" un array que por defecto esta vacio con la lista tareas
hijas, pueden ser o bien referencias al id de otra tarea o un objecto
tarea.
"hours" incluye las horas proyectadas, las acumuladas de las tareas
hijas (computadas) y las logeadas para esa tarea en cuestion
"attachments" es una lista de ficheros adjuntos. Solo se incluye el
nombre (que sirve de identificador), el mimetype y el tamaño. El
fichero adjunto en si debe ser obtenido por separado.
"owner": es el usuario propietario de la tarea (podría ser un array
para permitir más de uno pero no creo que sea necesario).
"cc": son los usuarios que están siguiendo esa tarea y que pueden
modificarla.
"bcc": son los usuarios que están siguiendo esa tarea pero que no
pueden modificarla.
"tags": simples tags que pueden usarse para filtrar las tareas

Con esa entidad podemos llevar la gestión de las tareas de una forma
sencilla y dinámica. Con la entidad de auditoría podemos generar
informes y saber todos los detalles de una tarea.

[
{
task : 'A12HDEF213FG21BC',
timestamp : '2007-11-08T09:45:44Z',
action : 'workedhours',
user : 'drslump',
params : [ 2.4 ], // the number of worked hours
log : 'Implemented the menu'
},
{
task : 'A12HDEF213FG21BC',
timestamp : '2007-11-05T18:23:56Z',
action : 'newchild',
user : 'drslump',
params : [ 'BFA31D8742BCD' ], // the id of the subtask added
log : ''
},
{
task : 'A12HDEF213FG21BC',
timestamp : '2007-11-05T12:44:23Z',
action : 'created',
user : 'drslump',
params : [],
log : ''
}
]

Es un array con todos los cambios realizados en un tarea en concreto o
un conjunto de tareas. Basicamente nos permite saber la fecha en que
se hizo el cambio, quien lo hizo y que se hizo.

"task" es la referencia a la tarea, es necesario incluirlo porque
puede ser obtengamos una auditoria de un conjunto de tareas.
"timestamp" es la fecha en que se hizo el cambio.
"action" es la acción realizada.
"user" es el usuario que realizo el cambio.
"params" es un vector con los parametros utilizados para realizar el
cambio (un id de una nueva subtarea, el nombre de un adjunto, horas
logeadas...).
"log" un campo textual donde el usuario puede poner una descripción
del cambio. Muy similar al log de un cvs o subversion.

La lista de auditorias nos permite en principio sacar informes sobre
los cambios en un proyecto o consultarlo para generar RSS o emails
automatizados. Sin embargo, con un poco más de código puede permitir
la sincronización de bases de datos o deshacer cambios.

[Daniel Mota]

Hay cosas que no habia tenido en cuenta, como los adjuntos.

Yo lo veo en plan categorías o contextos, pero creo que este modelo se
adapta perfectamente no?

Ejemplo:

Esta tarea va hacia "bugs" y tengo que hacer esto, esto y esto otro.

A mi la idea de tener muchas tareas en arbol me aterra, más que nada
porque en el trabajo suelo ser muy lineal, voy apuntando lo que tengo
que hacer según me llega por email o por msn. Creo que en este sentido
soy muy caótico y no suelo agruparlas, pero si creo que podría
ubicarlas en pequeños bloques o categorías: diseño, bugs ... como una
especie de etiqueta al estilo gmail.


DrSlump ha escrito:
> Antes de discutir que framework usar o que patr�n de desarrollo es el

> ideal creo que lo mejor es empezar a definir un modelo de datos para

> la aplicaci�n. Como el UML adem�s de complicado es un dolor de muelas
> voy a exponer un posible modelo utilizando Json (m�s bien literales de

> javascript) que lo entendemos todos y es muy sencillo de escribir.
>

> El modelo est� pensado con dos prioridades en mente: facilidad de
> implementaci�n y m�xima flexibilidad. De hecho solo voy a definir dos
> tipos de entidades: Tarea y Auditor�a. Mi idea inicial era reducirlo
> todo a una Tarea pero para facilitar la implementaci�n y pensando en

> optimizar el transporte de datos he decidido dividirlo en esas dos

> entidades donde la Auditor�a es opcional y solo ser�a necesaria para
> generar informes.
>
> Una Tarea ser�a algo as�:

> facilitar la implementaci�n. Las tareas tienen un estructura de �rbol,
> lo que permite una organizaci�n jerarquica en lugar de relacional que
> en mi opini�n es m�s sencilla de comprender y de utilizar.

>
> "id" es el identificador global de una tarea.

> "code" es un identificador propuesto por el usuario que debe ser �nico
> en su misma rama del �rbol, se puede utilizar para referenciar una
> tarea de una forma facilmente recordable (i.e.: /myproject/3 ser�a la

> 3 tarea del projecto 'myproject' ).

> "title" es simplemente el t�tulo de la tarea.
> "description" es importante porque adem�s de describir una tarea puede
> servir para incluir informaci�n del cliente en una tarea raiz (un

> proyecto).
> "priority" y "status" son simplemente la prioridad y el estado.
> "parent" si es Null es que la tarea es una raiz, si es un string es
> una referencia a la tarea padre.
> "children" un array que por defecto esta vacio con la lista tareas
> hijas, pueden ser o bien referencias al id de otra tarea o un objecto
> tarea.
> "hours" incluye las horas proyectadas, las acumuladas de las tareas
> hijas (computadas) y las logeadas para esa tarea en cuestion
> "attachments" es una lista de ficheros adjuntos. Solo se incluye el

> nombre (que sirve de identificador), el mimetype y el tama�o. El

> fichero adjunto en si debe ser obtenido por separado.

> "owner": es el usuario propietario de la tarea (podr�a ser un array
> para permitir m�s de uno pero no creo que sea necesario).
> "cc": son los usuarios que est�n siguiendo esa tarea y que pueden
> modificarla.
> "bcc": son los usuarios que est�n siguiendo esa tarea pero que no

> pueden modificarla.
> "tags": simples tags que pueden usarse para filtrar las tareas
>

> Con esa entidad podemos llevar la gesti�n de las tareas de una forma
> sencilla y din�mica. Con la entidad de auditor�a podemos generar

> "action" es la acci�n realizada.

> "user" es el usuario que realizo el cambio.
> "params" es un vector con los parametros utilizados para realizar el
> cambio (un id de una nueva subtarea, el nombre de un adjunto, horas
> logeadas...).

> "log" un campo textual donde el usuario puede poner una descripci�n

> del cambio. Muy similar al log de un cvs o subversion.
>
> La lista de auditorias nos permite en principio sacar informes sobre
> los cambios en un proyecto o consultarlo para generar RSS o emails

> automatizados. Sin embargo, con un poco m�s de c�digo puede permitir
> la sincronizaci�n de bases de datos o deshacer cambios.

[Daniel Mota]

Creo que me he liado jeje, porque aunque yo las agrupe por bloques en
mi ejemplo el TODO list pueden ser perfectamente tareas hijas.

Ainss.

> >         bcc              : [ 'i...@cliente.org' ],

[Luis Merino]

Muy buena idea.
Al final de todo yo cambiaría log por changes para diferenciar realmente y puesto que en ese texto solo habrá cambios es más correcto. El key params no me queda muy claro, porque si es de este tipo estará restringido a un orden... Si no me equivoco (corrígeme si es así), sería mejor pasar valores con propiedad.

{

               task            : 'A12HDEF213FG21BC',
               timestamp       : '2007-11-05T12:44:23Z',
               action          : 'created',
               user            : 'drslump',

               params          : {'attach': 'photo.jpg', 'id_subtask': 'WHATEVER', 'time_loged': '4.5'},
               changes         : 'I killed your mother...'
}

El día 21/11/07, DrSlump <drSl...@gmail.com> escribió:

[Daniel Niquet]

Me parece estupendo el modelo del DrSlump... Respecto a lo del árbol
no sé...me parece bien en árbol.... pero tmb con etiquetado tipo
gmail....que tal ambos?

[DrSlump]

> @Luis Merino

> Muy buena idea.
> Al final de todo yo cambiaría log por changes para diferenciar realmente y
> puesto que en ese texto solo habrá cambios es más correcto. El key params no
> me queda muy claro, porque si es de este tipo estará restringido a un
> orden... Si no me equivoco (corrígeme si es así), sería mejor pasar valores
> con propiedad.
>

Creo que 'log' es semanticamente más correcto ya que 'change' sería
todo el objecto en si mismo. Aunque esto es simplemente ponerse de
acuerdo en una nomenclatura y listo :)

Respecto a "params" si que me parece buena idea utilizar un hash en
lugar de un vector. Realmente queda más claro y tampoco es que
complique mucho la persistencia de la entidad respecto al uso de un
vector.

En cuanto al uso de una estructura jerárquica (en árbol) mirarlo de
momento como algo a muy bajo nivel. Es decir, ahora mismo no sabemos o
no hemos concretado si la aplicación deberá estar organizada en
proyectos/tareas, listas/todos o simplemente tareas, lo que intenta
resolver este modelo es como representar una tarea de una forma
eficiente y flexible. La aplicación después deberá aplicar
'restricciones' sobre las posibilidades que ofrece el modelo de
inicio. El elegir una estructura en árbol es por razones de eficiencia
y de claridad, ya que todos estamos familiarizados con ese tipo de
estructura.
De todas formas una estructura jerarquizada permite realizar algunas
cosas interesantes como que cada uno aplique la organización que mas
le convenga (proyectos, contextos, grupos de desarrollo, secciones,
módulos...) e incluso hacer fácilmente una implementación simple de
dependencia entre tareas haciendo que una tarea 'padre' no pueda
marcarse como completada si alguna de las 'hijas' no está cerrada.

Implementar relaciones N:M (una tarea puede pertenecer a más de un
padre) puede parecer sencillo pero la cosa se complica bastante. Si no
mirar los problemas que han tenido históricamente los 'garbage
collectors' de maquinas virtuales :)

@Daniel Mota

A mi también me aterran las estructuras jerarquizadas rígidas pero
como explico arriba no es necesario agrupar las tareas en un árbol.
Las tareas están en un espacio de direcciones global, por lo que
aplicar una estructura a las tareas es en primer lugar una decisión de
la capa aplicación y en segundo lugar una opción para el usuario.

[Daniel Mota]

Buenos dias chicos :), he tenido un finde bastante liado en el EBE07.

Tengo varias ideas que he estado pensando a lo largo del finde, parece
que los modelos los damos por validos hasta que empecemos a trabajar
con ellos y puedan variar según necesidades. Solo he visto una cosa
que a lo mejor no es importante y es una pequeña información sobre el
proyecto, en la identidad tenemos una id única para el proyecto pero
no estaría mal tener algo de información (titulo, descripción,
empresa, email).

He pensado que como hay muchas formas de trabajar y secciones que se
pueden implementar estaria muy bien crear un sistema de filtros como
lo hace gmail. Así la escalabilidad la pone el usuario y no la
aplicación.

Ejemplo: Crear filtros para mostrar mis tareas, o para saber las
tareas no terminadas o las asociadas a un tag.

Creo que los filtros si lo hacemos en formato JSON o XML ya tendríamos
una mini API para aplicaciones externas.

Ejemplo:

{
tags: ['dani','job2time']
}

{
scope: 'project',
status: 'new'

[DrSlump]

On 26 nov, 18:14, Daniel Mota <daniel.m...@gmail.com> wrote:
> Buenos dias chicos :), he tenido un finde bastante liado en el EBE07.
>
> Tengo varias ideas que he estado pensando a lo largo del finde, parece
> que los modelos los damos por validos hasta que empecemos a trabajar
> con ellos y puedan variar según necesidades. Solo he visto una cosa
> que a lo mejor no es importante y es una pequeña información sobre el
> proyecto, en la identidad tenemos una id única para el proyecto pero
> no estaría mal tener algo de información (titulo, descripción,
> empresa, email).
>

Bajo mi punto de vista ese tipo de atributos (titulo y descripción ya
están incluidos) es tan variable de persona a persona (e incluso entre
proyectos) que no deberían incluirse como atributos de la entidad. Mi
idea es utilizar el campo de descripción para meter toda esa
información. Por eso puse el atributo 'format', para poder poner texto
plano, html, micro formats, un xml con un format en concreto... Sería
tarea del 'cliente' mostrar esa información de una forma correcta.
Especialmente el uso de micro formats creo que serviría para el
propósito de documentar contactos.

Un campo que creo que es importante y se me olvidó poner es 'type'
para indicar que tipo de tarea es (bug, todolist, todoitem,
enhancement...). Se podrían utilizar tags pero creo que es bastante
importante y común su uso como para incluirlo como atributo de la
entidad.

> He pensado que como hay muchas formas de trabajar y secciones que se
> pueden implementar estaria muy bien crear un sistema de filtros como
> lo hace gmail. Así la escalabilidad la pone el usuario y no la
> aplicación.
>
> Ejemplo: Crear filtros para mostrar mis tareas, o para saber las
> tareas no terminadas o las asociadas a un tag.
>
> Creo que los filtros si lo hacemos en formato JSON o XML ya tendríamos
> una mini API para aplicaciones externas.
>
> Ejemplo:
>
> {
> tags: ['dani','job2time']
>
> }
>
> {
> scope: 'project',
> status: 'new'
>
> }
>

Por lo que entiendo lo que propones son 'vistas computadas', es decir,
definir unos atributos con sus valores que componen un expresión
boleana entre ellos (AND) y devuelva todos los registros que cumplen
esa expresión. Me parece buena idea la verdad. Yo incluso añadiría los
campos que tienen que devolverse con la consulta, para optimizar el
caudal de datos. Por ejemplo:

{
// los campos que se deben devolver.
// Si es Null se devuelven todos.
// 'id' siempre se devuelve aunque no se indique.
fields: [ 'code', 'title', 'hours', 'owner' ],
// el filtro a aplicar para encontrar los registros que buscamos
(ANDed)
match: {
parent: null, // Para señalar que es una tarea padre
status: [ 'new', 'assigned' ], // con estado 'new' o 'assigned'
tags: 'test' // que contenga el tag 'test'
}
}

Se podría discutir el añadir también atributos para la paginación como
el 'LIMIT' de MySQL, pero eso nos obligaría a incluir también
atributos para ordenar las entidades en el servidor, lo que
complicaría exponencialmente la implementación. Creo que dado que no
se prevé el tener 1000s de tareas lo mejor es devolver el result set
completo y aplicar la ordenación y paginado en el cliente.

De todas formas, esto a los ojos de un puritano de REST no estaría
bien hecho, ya que para obtener los resultados se tendría que hacer un
POST en lugar de un GET. Una solución sería asignar identificadores a
una 'vista', es decir, primero creamos la vista asignándole un
identificador (PUT) y para obtener los resultados simplemente hacemos
un GET al url de esa vista, esto además permitiría optimizar el
'servidor' ya que se podría cachear la definición en lugar de tener
que parsearla continuamente, incluso crear 'views' de bases de datos
si se usa un backend SQL.

Una definición de una 'vista' quedaría así:

{
id: 'simple',
fields: [ 'code', 'title', 'hours', 'owner' ],
match: {
parent: null, // esta vista solo devuelve las tareas sin padre
status: '{$estado}', // aqui ponemos un 'place holder'
tags: 'test' // que contenga el tag 'test'
}
}

Para consultar esa vista se utilizaría un URL parecido a este para
obtener todas las tareas raiz con el tag 'test' y con estado 'new' o
'assigned':

http://.../$view/simple/?estado[]=new&estado[]=assigned

Siento alargarme, prometo que esto es lo último que escribo.
Dependiendo de las necesidades que veamos podriamos incluso extender
una definición para incluir operandos de tipo OR. No sé hasta que
punto es necesario pero no estaría de más discutirlo.

{
id: 'simple',
fields: '......',
match: [
{
parent: null,
status: 'new',
},
{
parent: null,
status: 'assigned',
tag: 'test'
}
]
}

que correspondería a todas las tareas raiz con estado 'new' o con
estado 'assigned' y un tag 'test'

ciao

[Daniel Mota]

Perdo ivan por tardar en contestar.

Lo de los microformatos es una pedazo idea como un camión, no había
caido en ellos y nos resuelve la papeleta un monton.

El planteamiento de los filtros me parece perfecto, es exactamente lo
que yo pensé, aunque bueno lo mío era mas confuso jeje.

Hay 3 cosillas que tengo que decir.

Lo del placeholder para que lo usamos?.
Los limites de paginado no hacen falta, no hay tantas tareas pero
quizas a lo mejor un ORDER o GROUPBY puede ser interesante.
Yo puse el tema de scope porque me di cuenta que si queremos mostrar
tareas del proyecto seleccionado tienes que saber que proyecto, porque
sino crear los mimos filtros por cada proyecto es un rollazo :S.

Chicos esto tiene una pinta increible, poco a poco tenemos todo para
comenzar a ver frutos.

[DrSlump]

On 28 nov, 17:46, Daniel Mota <daniel.m...@gmail.com> wrote:
> Perdo ivan por tardar en contestar.
>
> Lo de los microformatos es una pedazo idea como un camión, no había
> caido en ellos y nos resuelve la papeleta un monton.
>

Me alegra que te guste la idea. Es poner más peso en la parte 'GUI'
pero creo que con la calidad de las librerías de Javascript hoy en día
no es nada descabellado empezar a darles más protagonismo que solo
hacer animaciones.

> El planteamiento de los filtros me parece perfecto, es exactamente lo
> que yo pensé, aunque bueno lo mío era mas confuso jeje.
>
> Hay 3 cosillas que tengo que decir.
>
> Lo del placeholder para que lo usamos?.

Un 'placeholder' es simplemente un parámetro, si has usado PDO en PHP
verás que cuando se prepara una consulta en esta se ponen signos de
interrogación para indicar que hay debe ir un valor variable. Esto es
algo parecido, una vista define la consulta en general pero para darle
más flexibilidad se permite el uso de 'variables' que son definidas
por el que hace la llamada a esa vista.

> Los limites de paginado no hacen falta, no hay tantas tareas pero
> quizas a lo mejor un ORDER o GROUPBY puede ser interesante.

El problema de los ORDER es que implican aplicar una lógica. No es lo
mismo ordenar números, que fechas, que estados ... Estamos mal
acostumbrados a utilizar el orden alpha numérico para todo, lo que
luego nos obliga a hacer apaños como poner las fechas en epochs de
unix, utilizar prefijos numéricos para items de listas, etc. Mi idea
es que sea la parte cliente la que ordene los resultados a su antojo,
aplicando la lógica que le vaya mejor. Se que no es algo común pero
realmente creo que puede ser muy interesante, principalmente porque le
da más poder al que implementa la interfaz, que muchas veces se ve
limitado por los datos que le vienen del 'backend'.

Lo del GROUPBY no lo veo. Agrupar solo sirve para aplicar funciones de
agregación sobre un conjunto de datos (COUNT, SUM, CONCAT...), no le
veo la utilidad con este modelo, aunque igual si que la tiene y no se
la veo. Para lo único que les veo un servicio es para calcular el
número de horas totales de una tarea con subtareas, por lo que ya
incluí el campo computado 'hours.children'. Si hacen falta este tipo
de datos creo que es mejor hacerlo mediante campos precomputados o
meta-datos que complicarlo todo con lógica de conjuntos.

> Yo puse el tema de scope porque me di cuenta que si queremos mostrar
> tareas del proyecto seleccionado tienes que saber que proyecto, porque
> sino crear los mimos filtros por cada proyecto es un rollazo :S.
>

Lo que pusiste con scope y los filtros entiendo que es lo que yo
propuse después de una manera uniforme para facilitar la
implementación. Se podría decir que en la definición de la vista lo
que tu llamas scope serían valores fijos mientras que lo que llamas
filtros serían lo que yo llamo 'placeholders' o variables.

> Chicos esto tiene una pinta increible, poco a poco tenemos todo para
> comenzar a ver frutos.
>

Sip, creo que ya va siendo hora que alguien se lance a sacar una API
del modelo. Preferiría no hacerlo yo porque así es más fácil detectar
posibles errores graves de diseño ya que yo lo tengo todo muy
'mascado' ya en la cabeza y haría las cosas sin reflexionarlas de
nuevo.

Solo para aclarar, porque a veces puedo parecer un casca rabias al que
todo lo que sea complejo le parece mal :)
La idea que persigo desde el principio es hacer un modelo lo
suficientemente simple como para que la implementación no esté ligada
a un servidor. Tal como está ahora el modelo, ha excepción de los
ficheros adjuntos se podría implementar con Google Gears facilmente.
Eso no quiere decir que sea malo hacerlo para un servidor (PHP/ASP/
Perl/Python...) sino que el 'core' debe ser muy liviano para que sea
sencillo crear funcionalidad adicional desacoplada, como un interfaz
por e-mail, notificadores Rss, web gui, html para dispositivos
móviles... En definitiva, crear un 'data store' especializado para
este dominio en concreto. Teniendo eso crear interfaces eficientes y
elegantes es solo cuestión tiempo, talento e iteración constante.

[Luis Merino]

Y perdonad que os haga una pregunta, porque aún estoy al 50% en esto de los Modelos de datos. El cliente en nuestro caso que sería finalmente?

El día 28/11/07, DrSlump <drSl...@gmail.com> escribió:

[DrSlump]

On 28 nov, 22:39, "Luis Merino" <alonglistofna...@gmail.com> wrote:
> Y perdonad que os haga una pregunta, porque aún estoy al 50% en esto de los
> Modelos de datos. El cliente en nuestro caso que sería finalmente?
>

El proyecto se inicio con un diseño de Daniel para una aplicación web.
Así que imagino que el principal cliente sería una web aunque hay
algunos que también necesitamos una interfaz por email.

[Luis Merino]

Supongo que me refería a la Vista, XSL, XHTML?

El día 28/11/07, DrSlump <drSl...@gmail.com> escribió:

[DrSlump]

Pues ni idea la verdad, en la discusión sobre maquetación vi que
tenían ya el diseño en html/css. Supongo que una primera
implementación podría hacerse directamente en Javascript.

On 28 nov, 23:03, "Luis Merino" <alonglistofna...@gmail.com> wrote:
> Supongo que me refería a la Vista, XSL, XHTML?
>

> El día 28/11/07, DrSlump <drSlum...@gmail.com> escribió: