[Php-avanzado] [Fwd: Re: Vencimiento Cursada 2010 - 2do cuatrimestre]

Jue Dic 1 19:49:24 ART 2011

Hola Maia,

espero que te mejores pronto!

Las ultimas clases de este curso seran el 15/12 y el 22/12

Lo mejor seria que vengas el 15/12 para instalar todo o mostrarme lo que tenes hecho, porque si venis el 22/12 no tendras tiempo de hacer algun ajuste en caso de ser necesario.

Recorda que las funcionalidades del trabajo final las tenemos que chequear contra la SRS... y asi, de memoria, no recuerdo que me la hayas entregado (la normalizacion no me preocupa en tu caso porque es un tema que manejas bien y dificilmente tenga algo mal ahi)

Me envias por favor la SRS?

PD: estoy en una PC con el teclado mal configurado... me faltan los acentos :-(

On Thu, 1 Dec 2011 18:48:28 -0300, Maia Cordero wrote
> Hola Leo, disculpa que no me comunique con vos con anterioridad. Estuve muy complicada por asuntos de salud y las exigencias del ultimo año de facultad.
> Actualmente estoy con principio de neumonía. 
> 
> Estoy retomando la tesina que quiero entregarte. Queria consultarte hasta que fecha estas ahi en la facultad para así me acerco y te llevo las cosas.
> 
> Saludos.
> 
> Maia
> 
> El 12 de agosto de 2011 00:23, Leonardo Tadei - Pegasus Tech Supply <leonardot en pegasusnet.com.ar> escribió:
> Hola Maia,
> 
>        lamento que te sientas mal: ojalá te recuperes pronto.
>        Te respondo intercalado:
> 
> El jue, 11-08-2011 a las 18:43 -0300, Maia Cordero escribió:
> 
> > Hola Leo. Estoy en cama, ayer me sentia mal y hoy me siento peor. No
> > voy a poder ir a mostrarte los avances. El martes me acerque a la
> > facultad y pedi la prorroga, quedaron de informarme sobre la
> > respuesta.
> 
>        Bueno, veremos como sigue ese trámite.
> 
> > Tenes razón respecto a la normalización de la base de datos, aunque yo
> > no quise hacerlo así porque me parecia demasiado "engorroso" tener que
> > hacer +tablas +stores +clases por datos no críticos al sistema. Pero
> > si se que se tiene que normalizar así como decís vos. Así que ya lo
> > modifique.
> 
>        No sabría que criterio aplicar para saber si un dato es crítico o no,
> sin conocer detalles del software ni el ámbito de aplicación.
>        A mi también me daría fiaca hacer todo eso... sobre todo cuando se
> podría obtener el mismo resultado con menos código: si es estructurado,
> querys a las tablas para ahorrarse los store procedures; y si es en
> Objetos, escribiendo solo las clases y usando un mapeador
> Objeto/Relacional.
> 
> > Un usuario se crea unicamente gracias a la existencia de una persona.
> > Pueden haber personas cargadas en el sistema que aun no posean un
> > usuario para acceder al sistema, como así personas que dejaron de ser
> > usuarios del sistema en ese caso se cambiara el campo estado del
> > usuario a false ( inactivo ).  Los datos personales del usuario que
> > una vez se cargaron en el sistema, persistirán y no serán borrados. Al
> > tomar esta decision, las entradas nunca tendrán incosistencia al tener
> > el campo id_usuario.
> 
>        Te entiendo... pero para esta situación, no sería mejor que Entrada
> tenga una referencia a una Persona, que existe siempre??? y solo en caso
> de que tenga esto que llamás "usuario" podrá poner una Entrada???
>        Cuando pienso tu modelo de datos como entidades, veo más naturalmente
> relacionados Entradas -> Personas -> Usuarios, que lo que vos planteás
> como Entradas -> Usuarios -> Personas... es meter entre dos entidades
> del almacenamiento un RNF...
> 
> > El grant_usage lo ejecute debido a que no me gusta trabajar con el
> > usuario root de mi base de datos, en todo caso cuando contrate un
> > hosting tendre el usuario evitando ejecutar esa instrucción.
> > Unicamente cambiare los datos de acceso en el archivo
> > configuracion.php por los datos del hosting.
> 
>        A mi tampoco me gusta trabajar como root: creo usuarios y DBs, y luego
> ejecuto las querys en el contexto de la conexión del usuario.
> 
> > Respecto a los objetos me guie bajo el patron de diseño "Active
> > Record". Lo vi aplicado en cakephp y me gusto la forma de trabajo.
> > Tambien vi que lo usa ruby on rails.
> 
>        Esto no suma ni resta para tu trabajo final, porque no es un tema dado
> en el curso.
>        En lo personal, los patrones de diseño recomentados son los del GoF y
> las extensiones que tiene. El Active Record y el Scaffold son
> directamente descartados por los diseñadores (Kent Beck, Wirf-Brook,
> Gamma et al, Rumbaugh, Jacobson, Booch, etc) por dar como resultado un
> "modelo anémico" y por provocar diseños orientados a los datos en lugar
> de orientados al comportamiento.
>        Toda esta gente que te nombré ni siquiera considera "patrones" a los
> que propone Martin Fowler... y dan sus buenos motivos de por qué no lo
> son. Fowler sí tiene importantes contribuciones en el campo de la
> integración continua, pero no tanto en arquitectura ni en diseño de
> software, si bien tiene cosas publicadas en ese área.
> 
>        Por favor, no cambies tu código por mi comentario de más arriba: quería
> aprovechar para contarte superficialmente las contras de esa
> aproximación, y las fuentes que pueden orientarte hacia buenos diseños.
> 
>        Porque, que mucha gente lo haga, no significa que esté bien.
>        (Gabriel hace unos minutos me decía esto, citando a su profesor de
> programación)
> 
> > Estoy modificando los procedimientos almacenados para que paginen.
> 
>        Ok. En el vuelco de la DB que me enviaste, no estaban los
> procedimientos almacenados, así que medio los adiviné entre las tablas y
> las llamadas en el código.
>        Recordá enviármelos la próxima vez!
> 
> > Gracias por las sugerencias. Te mantengo al tanto.
> > Cuando termine de acomodar mejor las cosas mando el modelo por la
> > lista.
> 
>        Por nada!
>        Ya seguiremos charlando de todo esto.
>        Me serviría de veras mucho que completes la SRS (parece que hiciste el
> software primero, y escribís la SRS después... obviamente no afecta a tu
> calificación, pero haciendo las cosas en ese orden, no podés validar tu
> software!)
>        Recordá también clarificar, mejor dicho, darle un nombre que no sea tan
> genérico a tu "usuario", porque si no es muy difícil que descubras
> vicios en los datos o en el software, como pareciera ser la relación de
> las Entradas con el Usuario en vez de con la Persona.
> 
> > Saludos
> 
>        =mente!
>        Que te mejores.
> 
> --
> Leonardo Tadei
> leonardot en pegasusnet.com.ar
> Blog: http://blog.pegasusnet.com.ar
> Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key
> 
> _______________________________________________
> Php-avanzado mailing list
> Php-avanzado en pato2.fi.mdp.edu.ar
> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
>

-- 
Leonardo Tadei 
Pegasus Tech Supply <http://www.pegasusnet.com.ar> 
Prometeus Technology <http://www.prometeustech.com.ar>

------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://www3.fi.mdp.edu.ar/pipermail/php-avanzado/attachments/20111201/56de2567/attachment.html>