pypyme-giotto Mailing List for pyPYME (Page 10)
Status: Planning
Brought to you by:
pyneo
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(93) |
Dec
(231) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(12) |
Feb
(43) |
Mar
(27) |
Apr
(47) |
May
(55) |
Jun
(68) |
Jul
(98) |
Aug
(59) |
Sep
(91) |
Oct
(7) |
Nov
(3) |
Dec
(2) |
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(5) |
Aug
(9) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Cesar P. V. <ces...@ya...> - 2005-07-11 23:55:56
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Gente <br> <br> Continuo con mis ideas sugerencias de la interfaz de usuario:<br> <br> La ventana principal se podría dividir en las siguientes áreas:<br> <br> <img alt="" src="cid:par...@ya..." height="386" width="538"><br> <br> Donde:<br> <ul> <li>La <b><i>Barra de Titulo</i></b> será el título de la ventana del sistema operativo. Como título de la ventana se colocará "pyPYME - Bienvenido Cesar Verdes", donde "Cesar Verdes" es el nombre largo del usuario logoeado.</li> <li>El <b><i>Menú Principal</i></b> será el menú del sistema pyPYME, con funcionalidades comunes a cualquier tarea, y el menú se modifica dinámicamente al activar una vista en el "Area de Trabajo" la cual puede agregar sus propias opciones de Menu y Submenues.</li> <li>La Barra de Herramienta de pyPYME tendrá las opciones comunes a la navegación del sistema y funcionalidades intrínsicas a la UI o comunes a muchas tareas.</li> </ul> <blockquote>Propongo la siguiente <i>Barra de Herramientas de pyPYME</i>:<br> <img alt="" src="cid:par...@ya..." height="55" width="756"><br> <br> Donde el significado de los íconos de izquierda a deracha son:<br> <ol> <li>Terminar la Tarea</li> <li>Cancelar la Tarea</li> <li>Ir a la pantalla anterior caso la tarea tenga varias ventanas, o volver a la pantalla de donde se llamó la tarea.</li> <li>Grabar todos los datos registrados en la tarea hasta el momento (sin darla por terminada)</li> <li>Buscar un tecto en la vista actual</li> <li>Imprimir (caso esté habilitada la funcionalidad para la vista activa)</li> <li>Cortar</li> <li>Copiar</li> <li>Pegar</li> <li>Ir a la pantalla principal del usuario (su "home" con las tareas usadas recientemente, sus tareas preferidas, los elementos sobre los cuales suele trajar y otra información que le pueda ser de utilidad)</li> <li>Mostrar u ocultar el Área de Servicios a fin de ganar más espacio para el Área de Trabajo</li> <li>Ayuda de como realizar la tarea de la vista activa (es una ayuda contextual que se despliega en el Área de Trabajo, mostrando en el Área de Servicios ayudas relacionadas.<br> </li> <li>Campo donde el usuario experto puede tipear el código de una tarea para abrirla directamente en el "Área de Trabajo" (no requiere buscarla en ningún menú ni arbol de tareas). Este campo es un campo desplegable donde se muestran las tareas ordenando primero las tareas llamadas recientemente por ese usuario.</li> <li>Bloquea la Interfaz Gráfica para que ningún otro usuario pueda realizar cambios sin cerrar área ni tarea. Esta opción puede ser útil cuando el usuario desea levantarse de su escritorio por unos minutos.</li> <li>Deslogonea al usuario actual, volviendo a la pantalla de login del sistema.</li> </ol> </blockquote> <ul> <li>En el <i><b>Área de Servicios</b></i> se despliegan opciones útiles de búsquda de tareas y elementos sobre los cuales el usuario desea realizar alguna operación.</li> </ul> <blockquote>Propongo la siguiente <i>Área de Servicios</i>:<br> <img alt="" src="cid:par...@ya..." height="404" width="297"><br> <br> Donde en la parte superior se encuentra una serie de íconos de acceso a los servicios.<br> Entre los servicios propuestos incluyo de izquierda a derecha:<br> <ol> <li>Árbol de tareas de los módulos instalados</li> <li>Tareas relacionadas con la tarea o elemento actual</li> <li>Elementos relacionados con la tarea o elemento actual</li> <li>Links a las tareas preseleccionadas por el usuario</li> <li>Enviar mensajes a otros usuarios conectados y ver los mensajes recibidos por otros usuarios.</li> </ol> </blockquote> <ul> <li>El <i><b>Área de Trabajo</b></i> es donde se despliegan las vistas de los componentes. TBD</li> <li>La <i><b>Barra de Estado</b></i> es usada principalmente para que pyPYME envie mensajes al usuario en respuesta a sus acciones (mensajes, advertencias, errores, indicación de tarea en proceso, etc) y otra información útil como la hora y el día con posibilidad de desplegar un calendario. TBD</li> </ul> <i><b>Nota:</b></i> Los íconos son sacados de la base de íconos de SAP, luego podemos solicitar la ayuda de un diseñador gráfico para darle una personalidad única a pyPYME.<br> <br> Mañana continúo.<br> <br> Espero sus comentarios. <span class="moz-smiley-s1"><span> :-) </span></span><br> <br> C.<br> </body> </html> |
From: Jose <coo...@py...> - 2005-07-11 14:46:18
|
El lun, 11-07-2005 a las 01:16, Cesar Pablo Verdes escribi=F3: > Desde ayer que no puedo ingresar. Parece ser que tuve un corte de conexi=F3n y no lo he observado hasta ahora. Jose |
From: Cesar P. V. <ces...@ya...> - 2005-07-10 23:13:06
|
Desde ayer que no puedo ingresar. C. :-( ___________________________________________________________ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar |
From: Cesar P. V. <ces...@ya...> - 2005-07-10 23:11:28
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> <meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8"> <title></title> <meta name="GENERATOR" content="OpenOffice.org 1.1.0 (Linux)"> <meta name="CREATED" content="20050709;20182400"> <meta name="CHANGED" content="20050709;21035400"> <style> <!-- @page { size: 8.27in 11.69in; margin: 0.79in } P { margin-bottom: 0.08in } H2.cjk { font-family: "Andale Sans UI", "Arial Unicode MS" } H2.ctl { font-family: "Tahoma", "Lucidasans" } H5.cjk { font-family: "Andale Sans UI", "Arial Unicode MS" } H5.ctl { font-family: "Tahoma", "Lucidasans" } --> </style>Hola Gente,<br> <br> Desde el miércoles hasta el viernes de la semana pasada estuve muy complicado con mi "trabajo remunerado" y no tuve tiempo para trabajar en pyPYME. <span class="moz-smiley-s2"><span> :-( </span></span><br> <br> Durante el fin de semana he comenzado a redactar el documento sobre mis ideas/sugerencias para la interfaz gráfica que adjunto al final de este mail.<br> <br> He tratado de respetar los estandares de documentación del proyecto. Les alcanzo el primer borrador de los Roles y las Historias Epicas. Comencé a redactar el documento como si se tratara de un módulo nuevo. A medida que desarrollaba el documento observé que tenía muchas cosas en común con el componente "Centro de Control", aunque con mayor alcance.<br> <br> Les ruego que no se asusten por la aparente ambición de alcance y complejidad del módulo planteada en este documento. Son ideas que creo convenientes implementar en la interfaz gráfica de pyPYME basadas en conceptos de la SAPGui, la teoría Inductive User Ineterfase de Microsoft, conceptos e ideas de otros productos como Compiere, FacturaLUX, TinyERP, Eclipse y Groove; las teorías de UIs basadas en patrones y task oriented UIs, así como también de mis necesidades como usuario de ERP.<br> <br> Desearía que analicen cada punto en forma objetiva sin pensar en el código existente o la posible complejidad que su implementación podría implicar. Les pido que critiquen este documento con una visión de "Nice to Have".<br> <br> Tras analizar sus comentarios, y en caso que Uds. no observen ningún inconveniente importante procederé al análisis de "Composición" y la documentación de cada uno de los componente (Historias de usuario y Tests de aceptacion)<br> <br> Espero ansiosamente vuestros comentarios. <span class="moz-smiley-s1"><span> :-) </span></span><br> <br> C.<br> <br> <h5 class="western">Encargado el organizar el diálogo entre el usuario y los componentes a traves de una interfaz gráfica estandarizada y la administración de las vistas y controladores de los componentes de los demás módulos.</h5> <h2 class="western">Roles</h2> <dl> <dt>Usuario</dt> <dd style="margin-left: 0.49in;"> Cualquier persona que hace uso de esta aplicación, independientemente del perfil de seguridad bajo el que opere.</dd> <dd style="margin-left: 0in;"> Usuario especializado</dd> <dd style="margin-left: 0.49in;"> Usuario que utiliza frecuentemente un número de acotado de funcionalidades del sistema las cuales conoce en detalle y opera muy rápidamente.</dd> <dd style="margin-left: 0in;"> Usuario esporádico</dd> <dd style="margin-left: 0.49in;"> Usuario que periódicamente debe realizar alguna tarea en el sistema al cual no operándolo con fluidez</dd> <dd style="margin-left: 0in;"> Soporte funcional</dd> <dd style="margin-left: 0.49in;"> Usuario especializado en determinadas funcionalidades del sistema cuya función es ayudar a los otros usuarios a utilizar el sistema.</dd> <dt> Administrador</dt> <dd style="margin-left: 0.49in;"> Usuario que actúa bajo un perfil de seguridad especial que le permite acceder, usar y configurar cualquiera de los elementos de la aplicación</dd> <dd style="margin-left: 0.01in;"> Programador </dd> <dd style="margin-left: 0.49in;"> Cualquier persona que programa nuevas vistas y controladores.</dd> <dt> Diseñador</dt> <dd style="margin-left: 0.49in; margin-bottom: 0.2in;"> Cualquier persona que produce imágenes y estilos aplicables a los estándares de la interfaz gráfica.</dd> </dl> <h2 class="western"> Historias épicas</h2> <ul> <li> <p>Los usuarios podrán “navegar” por el sistema accediendo a distintos niveles de detalle de la información, entidades y tareas relacionadas a la tarea que están ejecutando o desea ejecutar.</p> </li> <li> <p>Los usuarios especializados podrán acceder y ejecutar rápidamente cualquier tarea.</p> </li> <li> <p>Los usuarios esporádicos serán guiados por el sistema a fin de localizar y completar las tareas que necesiten ejecutar.</p> </li> <li> <p>Los usuarios podrán operar el sistema con tiempos razonables de respuesta conectados a la red con anchos de banda limitados como los que presentan las conexiones dial-up.</p> </li> <li> <p>La interfaz gráfica será autocontenida en una sola ventana segmentada en distintas áreas funcionales, aunque los usuarios podrán abrir más de una instancia de la interfaz en caso que lo desearan.</p> </li> <li> <p>Las vistas se desplegarán en una área de la interfaz gráfica llamada “área de trabajo”.</p> </li> <li> <p>Los usuarios podran mantener abiertas en la misma “área de trabajo” en forma simultaneamea varias tareas en distintos estados de ejecución.</p> </li> <li> <p>Será simple para los usuarios identificar la tarea que están ejecutando en cada momento, podrán comprender facilmente cuales son los pasos necesarios para concluirla, como cancelarla y como comenzar una tarea nueva.</p> </li> <li> <p>Los usuarios encontrarán en las vistas de los componentes todas las funcionalidades necesarias para ejecutar una y solo una tarea a la vez, la cual será claramente especificada por su título.</p> </li> <li> <p>La cantidad de widgets utilizables por los programadores para crear las vistas será limitada y estandarizada tanto en funcionalidad como en estética por el documento de “Guia de Estilo”.</p> </li> <li> <p>Los programadores contarán con patrones para facilitar la implementación de las vistas de los componentes de la aplicación.</p> </li> <li> <p>La programadores contarán con un stock acotado de imágenes e iconos para diseñar las vistas. Los diseñadores podrán definir y agregar al stock del sistema nuevas imágenes e íconos a medida que los programadores lo requieran.</p> </li> <li> <p>Los usuarios podrán acceder a la cola de impresión del sistema y visualizar en el área de trabajo los documentos y reportes que se haya solicitado antes de ser impresos, o eliminarlos de la cola de impresión sin imprimirlo.</p> </li> <li> <p>La interfaz gráfica facilitará el trabajo en equipo de los usuarios y el soporte remoto.</p> </li> </ul> </body> </html> ___________________________________________________________ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar |
From: Patricio V. <pat...@mu...> - 2005-07-09 16:33:25
|
Patricio Valarezo wrote: >> Tambi=E9n ten en cuenta que el soporte i18n bajo PyQt a=FAn no lo he >> analizado y, adem=E1s, creo recorder que en alg=FAn caso tuve que hace= r "un >> apa=F1o" creando m=E9todos __tr y __trUtf8 para que el c=F3digo de alg= una >> clase pudiera compilar. =BFAlguno se anima a realizar este estudio? >> > mmm... pienso que deber=EDa ir junto con la documentaci=F3n de usuario = de la=20 > primera versi=F3n, me parece demasiado trabajo al menos para estas etap= as=20 > del proyecto y en cierto sentido podr=EDa ser en vano, tengo la leve id= ea=20 Me refiero a tener que pegarse el camello(trabajo) de dar soporte=20 multilenguaje, ahora averiguar como est=E1 el soporte i18n en pyqt creo=20 que si se deber=EDa hacer, voy a averiguar un poco de esto y les comento saludos --=20 patoValarezo Linux User#155545 "Poder disfrutar de los recuerdos de la vida es vivir dos veces. --=20 Marcial. (40-102) Poeta Latino. " |
From: Patricio V. <pat...@mu...> - 2005-07-09 16:11:58
|
Jose wrote: >=20 > Despu=E9s de ejecutar pyuic yo no hago nada. Incluso puedo ejecutar > directamente el c=F3digo, as=ED qu=E9 no s=E9 que puede estar pas=E1ndo= te. Si me > das alguna pista adicional tal vez pueda ayudarte. Sabes que estuve haciendo otras cosas con el qtdesigner y al incluir el=20 par=E1metro -x vi que se generaban estos m=E9todos en el .py, en realidad= no=20 se que pas=F3 voy a tratar de volver a recrear el error y te comento con=20 mayor claridad... Ya me extra=F1aba que modificases el .py generado me do= y=20 cuenta que no es as=ED. >=20 > Si te fijas en el c=F3digo generado por pyuic, ver=E1s m=E9todos __tr y > __trUtf8 que lo =FAnico que hacen es encapsular el soporte i18n de Qt. = Se > definen como m=E9todos de la clase generada, as=ED que si los usas en =E9= sta o > en una clase 'hija' no tienes por qu=E9 tener ning=FAn problema. >=20 claro, como te comentaba arriba voy a volver a hacer pruebas, solo tengo=20 un peque=F1o warning al iniciar app.py respecto a pyqt, pienso que el=20 problema es que mi plataforma no evoluciona de la misma manera que la de=20 ustedes, espero no tener problemas el el cambio de qt o tendr=EDa que=20 evaluar la posibilidad de crear widgets mas gen=E9ricos :-(. > Tambi=E9n ten en cuenta que el soporte i18n bajo PyQt a=FAn no lo he > analizado y, adem=E1s, creo recorder que en alg=FAn caso tuve que hacer= "un > apa=F1o" creando m=E9todos __tr y __trUtf8 para que el c=F3digo de algu= na > clase pudiera compilar. =BFAlguno se anima a realizar este estudio? >=20 mmm... pienso que deber=EDa ir junto con la documentaci=F3n de usuario de= la=20 primera versi=F3n, me parece demasiado trabajo al menos para estas etapas= =20 del proyecto y en cierto sentido podr=EDa ser en vano, tengo la leve idea= =20 de que python se lleva bien con GNU gettext y no creo que ser=E1 un=20 problema en el futuro... Por otro lado el soporte utf8 lo veo inmaduro=20 en algunos lados, yo no he podido dar soporte completo a mi gentoo noto=20 que algunas aplicaciones se resbalan demasiado con esto (incluso eclipse) > Por cierto, acabo de incorporar el contenido del fichero go_pyuic.py en > la documentaci=F3n [2] junto con un aviso sobre su uso. >=20 eso! aunque me las arregl=E9 con un script en bash. saludos! --=20 patoValarezo Linux User#155545 "Poder disfrutar de los recuerdos de la vida es vivir dos veces. --=20 Marcial. (40-102) Poeta Latino. " |
From: Jose <coo...@py...> - 2005-07-09 15:41:57
|
El s=E1b, 09-07-2005 a las 00:37, Patricio Valarezo escribi=F3:=20 > Hola Jose y compa=F1eros, > Ayer sincronize la revisi=F3n 63 (creo que era), me alegra ir entendien= do=20 > cada vez mas el c=F3digo (por lo menos ahora no me pierdo jaja :-) ),=20 > bueno asi que te tengo algunas preguntas, algunas te podr=E1n sonar alg= o=20 > raras te ruego paciencia :-): >=20 > - No puedo encontrar en dev.pypyme.org/doc en donde estaban los=20 > diagramas de clases del core de thalassa no existe un vinculo desde la = doc. Como indicas m=E1s abajo el documento est=E1 redactado pero faltaba referenciarlo en la secci=F3n correspondiente de la documentaci=F3n (en [1]). Ya est=E1 hecho. He incorporado, en la Agenda de Desarrollo, la descripci=F3n de la versi=F3n 0.0, correspondiente a 'core' y 'widgets'. Tambi=E9n tengo que documentar lo que estoy desarrollando ahora: el controlador gen=E9rico de formularios-lista. En cuanto lo acabe redactar=E9 la documentaci=F3n de este tipo de formularios y actualizar=E9 la del 'core', la de los 'widgets' y redactar=E9 la del 'acceso a bases de datos= ' (y revisar=E9 la de PyContainer y XML-RPC). Entonces la documentaci=F3n d= e Thalassa estar=E1 al d=EDa. > - Podr=EDas documentar el an=E1lisis para las clases de soporte que est= an en=20 > core?, Yo lo veo muy bien y tamb=EDen lo suficientemente abstracto como= =20 > para amoldarse a diferentes situaciones, sin embargo me gustaria saber=20 > de donde salieron, no se si me hago entender. Todo lo que hay bajo 'core' ha ido evolucionando las =FAltimas semanas a partir del desarrollo de los formularios-ficha y formularios-lista. No he partido de un an=E1lisis previo sino de las necesidades que han ido apareciendo. Por eso est=E1 documentado el dise=F1o (realizaci=F3n) y no = el an=E1lisis (planificaci=F3n). En relaci=F3n al 'core' (y, de hecho, a cualquier funcionalidad que no pertenezca al dominio de la aplicaci=F3n) tengo una cierta dificultad par= a redactar el an=E1lisis: las historias de usuario no acaban de encajar bie= n cuando no participan "usuarios" sino "artefactos de software" (clases, entidades, etc). Si no suger=EDs alguna alternativa lo que har=E9 es "impersonar" los objetos de c=F3digo en "roles". Algo parecido a lo que h= e hecho con la documentaci=F3n de PyContainer y XML-RPC. > - Ayer hice una modificaci=F3n en el frmmain.ui para hacer unas pruebas= ,=20 > al general la interface con pyuic (no tengo el script go_pyuic.py que=20 > comentas en la doc) tuve un error por m=E9todos que estaban definidos e= n=20 > el view del frmMain,(__tr y __trUtf8) que se heredaban del widget, esto= s=20 > metodos los agregas luego de generar la interface? me imagino que son=20 > clases para i18n y soporte unicode, las camb=EDe para la clase frmMain = del=20 > control, ahora puedo generar independientemente el GUI. Apoyame si lo=20 > estoy haciendo mal. Despu=E9s de ejecutar pyuic yo no hago nada. Incluso puedo ejecutar directamente el c=F3digo, as=ED qu=E9 no s=E9 que puede estar pas=E1ndote= . Si me das alguna pista adicional tal vez pueda ayudarte. Si te fijas en el c=F3digo generado por pyuic, ver=E1s m=E9todos __tr y __trUtf8 que lo =FAnico que hacen es encapsular el soporte i18n de Qt. Se definen como m=E9todos de la clase generada, as=ED que si los usas en =E9= sta o en una clase 'hija' no tienes por qu=E9 tener ning=FAn problema. Tambi=E9n ten en cuenta que el soporte i18n bajo PyQt a=FAn no lo he analizado y, adem=E1s, creo recorder que en alg=FAn caso tuve que hacer "= un apa=F1o" creando m=E9todos __tr y __trUtf8 para que el c=F3digo de alguna clase pudiera compilar. =BFAlguno se anima a realizar este estudio? Por cierto, acabo de incorporar el contenido del fichero go_pyuic.py en la documentaci=F3n [2] junto con un aviso sobre su uso. > PD. usando el buscador encontre los diagramas de clases y del core en > http://dev.pypyme.org/doc/proyecto/modulos/thalassa/core/view?searchter= m=3Dcore >=20 Saludos, Jose [1]http://dev.pypyme.org/doc/proyecto/modulos/thalassa/ [2]http://dev.pypyme.org/doc/proyecto/giotto/guias/eclipse/document_view |
From: Patricio V. <pat...@mu...> - 2005-07-08 22:39:53
|
Jose wrote: > Hola, >=20 > Acabo de subir a SVN una versi=F3n algo m=E1s completa del formulario-l= ista. > Ahora incluye: >=20 > - un combo-box donde presentar y poder ejecutar filtros pre-definido= s > aplicables al mantenimiento en curso (p.e. todas las facturas pendiente= s > de cobrar). Falta implementar la l=F3gica > - el bot=F3n 'Nuevo' (del mantenimiento de tipos de impuestos) carga= el > formulario-ficha (del mantenimiento de un tipo de impuesto). Falta puli= r > este punto ya que no he logrado integrar el controlador del > formulario-ficha dentro del 'Centro de Control' (algo que ya esperaba) > - la cabecera est=E1 definida mediante el widget 'CustomHeader', lo = que > permite unificar la apariencia respecto del formulario-ficha > - tanto el formulario-ficha como el formulario-lista pueden > personalizar el logo, titulo y subtitulo de la cabecera. Falta pulir > este tema >=20 > Saludos, > Jose Hola Jose y compa=F1eros, Ayer sincronize la revisi=F3n 63 (creo que era), me alegra ir entendiendo= =20 cada vez mas el c=F3digo (por lo menos ahora no me pierdo jaja :-) ),=20 bueno asi que te tengo algunas preguntas, algunas te podr=E1n sonar algo=20 raras te ruego paciencia :-): - No puedo encontrar en dev.pypyme.org/doc en donde estaban los=20 diagramas de clases del core de thalassa no existe un vinculo desde la do= c. - Podr=EDas documentar el an=E1lisis para las clases de soporte que estan= en=20 core?, Yo lo veo muy bien y tamb=EDen lo suficientemente abstracto como=20 para amoldarse a diferentes situaciones, sin embargo me gustaria saber=20 de donde salieron, no se si me hago entender. - Ayer hice una modificaci=F3n en el frmmain.ui para hacer unas pruebas,=20 al general la interface con pyuic (no tengo el script go_pyuic.py que=20 comentas en la doc) tuve un error por m=E9todos que estaban definidos en=20 el view del frmMain,(__tr y __trUtf8) que se heredaban del widget, estos=20 metodos los agregas luego de generar la interface? me imagino que son=20 clases para i18n y soporte unicode, las camb=EDe para la clase frmMain de= l=20 control, ahora puedo generar independientemente el GUI. Apoyame si lo=20 estoy haciendo mal. en fin, sigo revisando el c=F3digo y espero pronto ponerme al d=EDa para=20 colaborar productivamente. saludos, PD. usando el buscador encontre los diagramas de clases y del core en http://dev.pypyme.org/doc/proyecto/modulos/thalassa/core/view?searchterm=3D= core --=20 patoValarezo Linux User#155545 "La =E9tica es un mal sastre para vestir las carnes de la realidad. -- P=ED= o=20 Baroja --" |
From: Jose <coo...@py...> - 2005-07-08 18:41:30
|
Hola, Acabo de subir a SVN una versi=F3n algo m=E1s completa del formulario-lis= ta. Ahora incluye: - un combo-box donde presentar y poder ejecutar filtros pre-definidos aplicables al mantenimiento en curso (p.e. todas las facturas pendientes de cobrar). Falta implementar la l=F3gica - el bot=F3n 'Nuevo' (del mantenimiento de tipos de impuestos) carga e= l formulario-ficha (del mantenimiento de un tipo de impuesto). Falta pulir este punto ya que no he logrado integrar el controlador del formulario-ficha dentro del 'Centro de Control' (algo que ya esperaba) - la cabecera est=E1 definida mediante el widget 'CustomHeader', lo qu= e permite unificar la apariencia respecto del formulario-ficha - tanto el formulario-ficha como el formulario-lista pueden personalizar el logo, titulo y subtitulo de la cabecera. Falta pulir este tema Saludos, Jose |
From: Patricio V. <pat...@mu...> - 2005-07-07 20:56:09
|
Marcelo G Ametller wrote: > Gente: >=20 > Ya que algunos han expresado que podriamos ampliar los canales de > comunicacion o complementar el mail les paso mi direcciones: >=20 > nick: maram >=20 > msn: mam...@gm... > jabber: mam...@ja... >=20 > (No soy muy afecto a los canales irc pero si hay alguno avisen...)=20 >=20 > Lo importante es que si se habla de algo relevante para el proyecto, > luego posteen la comunicacion, o concluciones a la lista... para no > excluir al resto. >=20 Bueno, mi propuesta de una comunicaci=F3n mas directa no tiene como=20 finalidad eliminar el correo electr=F3nico sino mas bien apoyarlo, es par= a=20 esas peque=F1as consultas que podr=EDan ser m=E1s interactivas para apoya= r el=20 proceso de aprendizaje y saber que se esta por buen camino antes de=20 haber recorrido bastante trecho y al final llegar a la conclusi=F3n de qu= e=20 nos hemos perdido :-). mi direcci=F3n en msn es: pat...@ho... saludos. --=20 patoValarezo Linux User#155545 "El casamiento y el caldo pelando. " |
From: Jose <coo...@py...> - 2005-07-07 15:33:04
|
El jue, 07-07-2005 a las 01:56, Cesar Verdes escribi=F3: > --- Jose <coo...@py...> escribi=F3: >=20 > > Por lo que la relaci=F3n quedar=EDa: > >=20 > > customers (1 a n) areas_composition > >=20 > > =BFQu=E9 os parece? =BFDemasiado liado para incluirlo en > > la v1.0 de Charon? >=20 > En base a la filosof=EDa que plantearon en todos los > mails anteriores (que comparto en general y a la que > me quiero alinear en las diferencias a fin de > participar en el proyecto) suguiero dejar lo de las > Areas para mas adelante... cuando algun otro > componente lo requiera. > A primera vista me parece que le falta una vuelta de > tuerca para cerrar el tema, suena un poco abstracto. +1 |
From: Cesar V. <ces...@ya...> - 2005-07-06 23:56:55
|
--- Jose <coo...@py...> escribió: > Por lo que la relación quedaría: > > customers (1 a n) areas_composition > > ¿Qué os parece? ¿Demasiado liado para incluirlo en > la v1.0 de Charon? En base a la filosofía que plantearon en todos los mails anteriores (que comparto en general y a la que me quiero alinear en las diferencias a fin de participar en el proyecto) suguiero dejar lo de las Areas para mas adelante... cuando algun otro componente lo requiera. A primera vista me parece que le falta una vuelta de tuerca para cerrar el tema, suena un poco abstracto. C. __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar |
From: Jose <coo...@py...> - 2005-07-06 23:26:49
|
El mi=E9, 06-07-2005 a las 22:15, Marcelo G Ametller escribi=F3: > On 7/6/05, Jose <coo...@py...> wrote: > > El mi=E9, 06-07-2005 a las 16:53, Marcelo G Ametller escribi=F3: > > > Estaba viendo la estructura de taxes: > > > > > > PYP_TAXES > > > ************ > > > > > > CREATE TABLE PYP_TAXES > > > > > > ID BIGINT NOT NULL, > > > ID_GROUP BIGINT NOT NULL, > > > CODE VARCHAR(20) NOT NULL, > > > NAME VARCHAR(50) NOT NULL, > > > DESCRIPTION VARCHAR(255), > > > PERCENTAGE NUMERIC(5,2) > > > > > > ************ > > > > > > Me parece que ademas de Percentage , debiera ir algun tipo de funci= on > > > o expresion regular. > > > Al menos en Argentina, casi siempre hacen falta mas datos ademas de= l > > > porcentage, generalmente hay muchos impuestos y en ocaciones con un > > > calculo complicado. > > > > > > Hace falta saber cual es la base imponible... , compras del mes y o= tras > > > caracteristicas... que pueden depender de varios factores. > >=20 > > Al menos en Espa=F1a la base imponible se asocia al importe "base" de= una > > factura/albar=E1n y no a un impuesto. > >=20 > > Lo de las compras del mes y otras caracter=EDsticas tal vez tambi=E9n= puedan > > definirse de forma complementaria (e independiente) a los impuestos. = No > > s=E9 d=F3nde utilizas esa informaci=F3n. > >=20 > > Creo que lo mejor ser=E1 asumir que tendremos que ir cambiando los > > esquemas de datos a medida que vayamos desarrollando los procesos. En > > este caso, cuando encontremos un proceso que exija cambiar la estruct= ura > > de los impuestos, ser=E1 la propia necesidad la que dictar=E1 y docum= entar=E1 > > los cambios a realizar. Es mi opini=F3n. > >=20 >=20 > Por ejemplo el IVA, impuesto al valor agregado, tiene un porcentage > fijo del 21% sobre el Neto... si perteneces a la categoria de RI > Responsable Inscripto. >=20 > Luego lo modificaron para que si el producto vendido es especifico=20 > (digamos una impresora) en vez del 21 va el 10,5% y si es xxx va 7,5 % > . En este caso se tratar=EDan de distintos tipos de IVA (el de 21%, el de 10,5%, el de 7,5%, etc) > De lo cual surgiria que para el mismo "impuesto" IVA categ RI, hay > distintos netos y porcentages segun el producto. O simplemente distintos tipos de IVA. > Se podria resolver de la siguiente forma: >=20 > tabla "taxes" >=20 > code code_grupo name porcentage > RIa IVA IVA Resp Inscripto 21 > RIb IVA IVA Resp Inscripto 10,5 > RIc IVA IVA Resp Inscripto 7,5 >=20 > no se si es del todo correcto. Yo lo veo correcto: tomar como distintos impuestos los distintos tipos de IVA. As=ED es como se suele aplicar en Espa=F1a. > luego tenemos el caso de "Aporte lucha contra incendios" >=20 > se cobra un importe fijo, segun la categoria del cliente... > independiente del neto >=20 > tabla "taxes" >=20 > code code_grupo name porc fijo? categ? > ALFa Ersep Aporte c/Inc - 1,50 RI > ALFb Ersep Aporte c/Inc - 0 CF > ALFc Ersep Aporte c/Inc - 50 GC >=20 > Por ahora si no hay alguna solucion mas amplia, dejamos la bases > "Taxes" como esta planteada. > Luego vemos ? Podr=EDamos considerar una tabla adicional de cargas impositivas fijas "fixed_taxes" de aplicaci=F3n opcional. |
From: Marcelo G A. <mam...@gm...> - 2005-07-06 20:16:04
|
On 7/6/05, Jose <coo...@py...> wrote: > El mi=E9, 06-07-2005 a las 16:53, Marcelo G Ametller escribi=F3: > > Estaba viendo la estructura de taxes: > > > > PYP_TAXES > > ************ > > > > CREATE TABLE PYP_TAXES > > > > ID BIGINT NOT NULL, > > ID_GROUP BIGINT NOT NULL, > > CODE VARCHAR(20) NOT NULL, > > NAME VARCHAR(50) NOT NULL, > > DESCRIPTION VARCHAR(255), > > PERCENTAGE NUMERIC(5,2) > > > > ************ > > > > Me parece que ademas de Percentage , debiera ir algun tipo de funcion > > o expresion regular. > > Al menos en Argentina, casi siempre hacen falta mas datos ademas del > > porcentage, generalmente hay muchos impuestos y en ocaciones con un > > calculo complicado. > > > > Hace falta saber cual es la base imponible... , compras del mes y otras > > caracteristicas... que pueden depender de varios factores. >=20 > Al menos en Espa=F1a la base imponible se asocia al importe "base" de una > factura/albar=E1n y no a un impuesto. >=20 > Lo de las compras del mes y otras caracter=EDsticas tal vez tambi=E9n pue= dan > definirse de forma complementaria (e independiente) a los impuestos. No > s=E9 d=F3nde utilizas esa informaci=F3n. >=20 > Creo que lo mejor ser=E1 asumir que tendremos que ir cambiando los > esquemas de datos a medida que vayamos desarrollando los procesos. En > este caso, cuando encontremos un proceso que exija cambiar la estructura > de los impuestos, ser=E1 la propia necesidad la que dictar=E1 y documenta= r=E1 > los cambios a realizar. Es mi opini=F3n. >=20 Por ejemplo el IVA, impuesto al valor agregado, tiene un porcentage fijo del 21% sobre el Neto... si perteneces a la categoria de RI Responsable Inscripto. Luego lo modificaron para que si el producto vendido es especifico=20 (digamos una impresora) en vez del 21 va el 10,5% y si es xxx va 7,5 % . De lo cual surgiria que para el mismo "impuesto" IVA categ RI, hay distintos netos y porcentages segun el producto. Se podria resolver de la siguiente forma: tabla "taxes" code code_grupo name porcentage RIa IVA IVA Resp Inscripto 21 RIb IVA IVA Resp Inscripto 10,5 RIc IVA IVA Resp Inscripto 7,5 no se si es del todo correcto. luego tenemos el caso de "Aporte lucha contra incendios" se cobra un importe fijo, segun la categoria del cliente... independiente del neto tabla "taxes" code code_grupo name porc fijo? categ? ALFa Ersep Aporte c/Inc - 1,50 RI ALFb Ersep Aporte c/Inc - 0 CF ALFc Ersep Aporte c/Inc - 50 GC Por ahora si no hay alguna solucion mas amplia, dejamos la bases "Taxes" como esta planteada. Luego vemos ? --=20 Marcelo Ametller www.maramsis.com.ar - www.aeroenlace.com.ar Ubuntu Linux User. |
From: Jose <coo...@py...> - 2005-07-06 20:00:00
|
El mi=E9, 06-07-2005 a las 16:53, Marcelo G Ametller escribi=F3: > Estaba viendo la estructura de taxes: >=20 > PYP_TAXES > ************ >=20 > CREATE TABLE PYP_TAXES >=20 > ID BIGINT NOT NULL, > ID_GROUP BIGINT NOT NULL, > CODE VARCHAR(20) NOT NULL, > NAME VARCHAR(50) NOT NULL, > DESCRIPTION VARCHAR(255), > PERCENTAGE NUMERIC(5,2) >=20 > ************ >=20 > Me parece que ademas de Percentage , debiera ir algun tipo de funcion > o expresion regular. > Al menos en Argentina, casi siempre hacen falta mas datos ademas del > porcentage, generalmente hay muchos impuestos y en ocaciones con un > calculo complicado. >=20 > Hace falta saber cual es la base imponible... , compras del mes y otras > caracteristicas... que pueden depender de varios factores. Al menos en Espa=F1a la base imponible se asocia al importe "base" de una factura/albar=E1n y no a un impuesto. Lo de las compras del mes y otras caracter=EDsticas tal vez tambi=E9n pue= dan definirse de forma complementaria (e independiente) a los impuestos. No s=E9 d=F3nde utilizas esa informaci=F3n. Creo que lo mejor ser=E1 asumir que tendremos que ir cambiando los esquemas de datos a medida que vayamos desarrollando los procesos. En este caso, cuando encontremos un proceso que exija cambiar la estructura de los impuestos, ser=E1 la propia necesidad la que dictar=E1 y documenta= r=E1 los cambios a realizar. Es mi opini=F3n. |
From: Jose <coo...@py...> - 2005-07-06 19:48:51
|
El mi=E9, 06-07-2005 a las 02:15, Cesar Pablo Verdes escribi=F3: > Jose wrote:=20 > > El mar, 05-07-2005 a las 15:27, Marcelo G Ametller escribi=F3: > > =20 > > > On 7/4/05, Jose <coo...@py...> wrote: > > >=20 > > > =20 > > > > S=F3lo falta la informaci=F3n relativa a 'zonas'. No s=E9 si segu= iste la l=EDnea > > > > de razonamiento (no recuerdo ni qui=E9n lo propuso ni qui=E9n lo = sigui=F3) > > > > pero acordamos, en su d=EDa, agrupar los clientes en 'zonas' de t= al forma > > > > que cada direcci=F3n podr=EDa asignarse a una zona definida por e= l usuario. > > > >=20 > > > > As=ED, quedar=EDa: > > > >=20 > > > > customers_addresses (1 a 1) areas > > > >=20 > > > > La tabla de zonas s=F3lo contiene un t=EDtulo y el tipo al que se= refiere > > > > junto con una tabla de detalle: > > > >=20 > > > > AREAS > > > > ----- > > > > ID BIGINT NOT NULL, > > > > CODE VARCHAR(20) NOT NULL, > > > > NAME VARCHAR(50) NOT NULL, > > > > TIPUS INT NOT NULL > > > >=20 > > > > AREAS_COMPOSITION > > > > ----------------- > > > > ID BIGINT NOT NULL, > > > > ID_AREA BIGINT NOT NULL, > > > > NAME VARCHAR(50) NOT NULL > > > >=20 > > > > donde TIPUS puede tomar los valores: > > > >=20 > > > > 1=3Dlocalidad > > > > 2=3Dprovincia > > > > 3=3Dpais > > > >=20 > > > > y la columna NAME contendr=E1 el nombre del elemento que forma pa= rte del > > > > =E1rea. Este elemento puede ser una poblaci=F3n, una provincia o = un pa=EDs. > > > >=20 > > > > Observar=E1s que no he incorporado estas 2 tablas porque prefiero= conocer > > > > vuestra opini=F3n al respecto. > > > > =20 > > > no me queda claro.. voy a revisar el historico... pero me podrias d= ar > > > un ejemplo con el contenido de las tablas ? > > > =20 > > Areas: > >=20 > > name: EMEA (Europe and middle-east asia) > > tipus: 3 (paises) > >=20 > > Areas_Composition: > >=20 > > name: Espa=F1a > > name: Francia > > name: Alemania > > name: B=E9lgica > > ... > > =09 > > o > >=20 > > Areas: > >=20 > > name: Hispano Am=E9rica > > tipus: 3 (paises) > >=20 > > Areas_Composition: > >=20 > > name: M=E9jico > > name: Brasil > > name: Argentina > > name: Ecuador > > name: Espa=F1a > >=20 > > (o divisi=F3n por c=F3digos postales dentro de un pa=EDs o por ejes > > cardinales, Norte, Sur, Este o Oeste, o por...) > >=20 > > =20 > > > en customers_addresses seguiria habiendo provincia, pais ? > > > =20 > > S=ED, porque la gesti=F3n de =E1reas sirve como clasificaci=F3n indep= endiente a > > la asignaci=F3n de direcciones f=EDsicas. Se tratan de conceptos dist= intos. > > =20 > Jose, >=20 > Vos decias: > customers_addresses (1 a 1) areas >=20 > Pero... =BFNo ser=EDa customers_addresses (1 a n) areas?=20 > o mejor dicho... =BFcustomers_addresses (1 a n) areas_composition? >=20 > Aun no me resulta claro el concepto :-( >=20 > =BFPodrian ayudarme a comprender con un ejemplo de Areas en relaci=F3n = a Clientes? >=20 > Gracias y disculpen la dureza mental :-) Tal vez tengas raz=F3n y est=E9 planteando mal la gesti=F3n, incluso definici=F3n, de las =E1reas. Primero hemos de tener en cuenta su cometido: facilitar la segmentaci=F3n/agrupaci=F3n de clientes. As=ED que, en vez de asociar una direcci=F3n a un =E1rea, tal vez deber=ED= a asociarse a un cliente. Y ya que un cliente puede segmentarse de acuerdo a distintos criterios, deberia establecerse una relaci=F3n 1 cliente <-> = n areas_composition. Por lo que la relaci=F3n quedar=EDa: customers (1 a n) areas_composition =BFQu=E9 os parece? =BFDemasiado liado para incluirlo en la v1.0 de Charo= n? |
From: Jose <coo...@py...> - 2005-07-06 17:21:17
|
El mi=E9, 06-07-2005 a las 01:51, Cesar Pablo Verdes escribi=F3: > Ahora en serio, como suger=ED en mi mail anterior, creo que el sitio > http://dev.pypyme.org/dev es nuestro "punto de venta" y mejor > "publicidad" a fin de captar adeptos al proyecto. > No para todo, pero por ejemplo la explicaci=F3n que me pasaste por mail > sobre el patr=F3n de dise=F1o tal vez sea conveniente ponerla en el sit= io, > y tu respuesta por mail podr=EDa haber sido solamente el link a una url= . Yo lo veo justo al rev=E9s: primero utilizamos la lista de correo para proponer ideas, comentarlas y perfilarlas y, una vez dadas por v=E1lidas, se documentan en el sitio web. Como ves no pretendo (ni deseo) que la lista de correo sustituya al sitio web como repositorio de documentaci=F3n. No tendr=EDa sentido ya que es una herramienta que no es adecuada para ese tipo de cosas. Por lo dem=E1s estoy de acuerdo contigo en que el sitio Plone es nuestro "punto de venta". > Recuerdo un proyecto donde defin=EDamos y escrib=EDamos "solutions > papers", documentos donde escrib=EDamos los temas acordados y las > desiciones tomadas a fin de continuar con el proyecto... si bien habia > escepciones, el concepto era no modificarlos hasta la pr=F3xima vuelta > del proyecto (versi=F3n, revisi=F3n o como lo quieran llamar en un > proyecto "agil"). >=20 > Los "solution papers" eran documentos en Lotus Notes con los > siguientes campos (seg=FAn recuerdo): > - Titulo > - Descripci=F3n breve > - Alternativas planteadas > - Alternativa elegida y por que > - Fecha > - Participantes >=20 > Los "solution papers" se clasificaban e indexaban para su b=FAsqueda y > referencia. Por ejemplo nosotros lo podr=EDamos clasificar en > "Nomenclatura", "An=E1lisis", "Desarrollo", "Documentaci=F3n Tecnica", > "Control de Calidad", "Documentaci=F3n del usuario" y "Distribuci=F3n". >=20 > =BFRecuerdas cuando me contaste que hab=EDan elegido QT sobre XUL y wx?= ... > ese ser=EDa un caso ideal para escribir un "solution paper". >=20 > Jose =BFpodr=EDamos implementar el concepto de "solutions papers" en el > sitio web? Por supuesto que s=ED. De hecho el que no hayamos inclu=EDdo hasta ahora nada parecido no quiere decir que no lo considerase =FAtil. M=E1s bien al contrario. Lo que pasa = es que, como ya coment=E9, mi tiempo he preferido dedicarlo a montar infraestructuras, postergando parte de la documentaci=F3n t=E9cnica y de = los "solution papers" (que en la documentaci=F3n yo los denomino "estudios"). Jose |
From: Jose <coo...@py...> - 2005-07-06 17:08:57
|
El mar, 05-07-2005 a las 15:23, Marcelo G Ametller escribi=F3:=20 > On 5/13/05, Jose <coo...@py...> wrote: > > Hola Marcelo, > >=20 > > El vie, 29-04-2005 a las 15:05, Marcelo G Ametller escribi=F3: > >=20 > > > P/D: lo de las qSizePolices en qt no lo pude solucionar... > >=20 > > Creo que s=E9 cu=E1l es el problema. > >=20 > > Acabo de instalar un equipo con Ubuntu Hoary y, al pasar la aplicaci=F3= n, > > he obtenido el mismo error. > >=20 > > Despu=E9s de investigar un poco he descubierto que el problema est=E1= en un > > conflicto de versiones entre pyuic y sip. > >=20 > > Yo lo he solucionado sustituyendo el pyuic que ven=EDa con Ubuntu por= el > > =FAltimo publicado en Debian unstable y recreando (con el nuevo pyuic= ) > > todos los formularios. >=20 >=20 > probe lo que decis... pero sigo con la misma falla... cuando genero > una pantalla partiendo del .ui aparece en QsizePolicy(0,0,0,0) en > lugar de QsizePolicy( QsizePolicy.Expand, QsizePolicy.Expand,0,0) . >=20 > supongo que es un problema de versiones... podrias pasarme las > versiones que estas usando nuevamente... y si son de debian o de > ubuntu? (de eric, pyuic, pyqt, sip, etc ...) He actualizado mi Ubuntu Hoary con la versi=F3n de desarrollo de KUbuntu = y se v=E9 genial. Para desarrollar no utilizo Eric sino Eclipse. Estas son mis versiones (que creo se corresponden con las instaladas por KUbuntu): KDE 3.4.1 qt 3.3.3 sip 4.2.1 pyqt 3.13 |
From: Marcelo G A. <mam...@gm...> - 2005-07-06 14:53:37
|
Estaba viendo la estructura de taxes: PYP_TAXES ************ CREATE TABLE PYP_TAXES ID BIGINT NOT NULL, ID_GROUP BIGINT NOT NULL, CODE VARCHAR(20) NOT NULL, NAME VARCHAR(50) NOT NULL, DESCRIPTION VARCHAR(255), PERCENTAGE NUMERIC(5,2) ************ Me parece que ademas de Percentage , debiera ir algun tipo de funcion o expresion regular. Al menos en Argentina, casi siempre hacen falta mas datos ademas del porcentage, generalmente hay muchos impuestos y en ocaciones con un calculo complicado. Hace falta saber cual es la base imponible... , compras del mes y otras caracteristicas... que pueden depender de varios factores. --=20 Marcelo Ametller www.maramsis.com.ar - www.aeroenlace.com.ar Ubuntu Linux User. |
From: Marcelo G A. <mam...@gm...> - 2005-07-06 13:22:42
|
Gente: Ya que algunos han expresado que podriamos ampliar los canales de comunicacion o complementar el mail les paso mi direcciones: nick: maram msn: mam...@gm... jabber: mam...@ja... (No soy muy afecto a los canales irc pero si hay alguno avisen...)=20 Lo importante es que si se habla de algo relevante para el proyecto, luego posteen la comunicacion, o concluciones a la lista... para no excluir al resto. --=20 Marcelo Ametller www.maramsis.com.ar - www.aeroenlace.com.ar Ubuntu Linux User. |
From: Marcelo G A. <mam...@gm...> - 2005-07-06 13:19:21
|
... > Al tratarse de una metodolog=EDa "Agile" otorga mucha libertad en aras de > agilizar su redacci=F3n. y de codificar... >=20 > > A lo que me refiero es que por ejemplo, por lo que entiendo Marcelo > > est=E1 produciendo la parte de clientes, pero la documentaci=F3n del > > componente "Charon/Ficheros maestros/Clientes" est=E1 vacia (Marcelo po= r > > favor no lo tomes a mal este comentario, lo pongo como ejemplo). =BFNo no lo tomo a mal... es excelente la participacion y los comentarios hacen a la mejora del proyecto. > > ser=EDa mejor documentar el an=E1lisis para que las personas que lo des= een > > pueda opinar antes de ponerse a codificar componentes espec=EDficos? En general, la opinion la recibi mediante el debate en los mails...=20 De echo yo tenia otra idea, para la estructura de clientes... pero por lo que se hablo en la lista la modifique... No obstante... si surgen nuevas ideas, se modifica lo echo... por suerte esta bastante modular para que los cambios no sean dificiles de hacer... No se olviden que en la primera etapa no vamos a hacer un "supersistema" con todas las opciones... ya que no somos muchos desarrolladores... Lamentablemente hay que relegar o suspender mejoras para proximas versiones= ... >=20 > Por una parte soy yo el que est=E1 desarrollando Charon. Marcelo est=E1 > poniendo en pr=E1ctica lo que todos debemos hacer: participar en el > desarollo de los m=F3dulos de los dem=E1s. y ademas como para el modulo que esta a mi cargo (portia) necesito varias cosas de charon, trato de hacer algunas y de paso aprendo el "estilo" de desarrollo de pypyme... y voy probando ideas... saludos a todos... --=20 Marcelo Ametller www.maramsis.com.ar - www.aeroenlace.com.ar Ubuntu Linux User. |
From: Jose <coo...@py...> - 2005-07-06 13:07:41
|
El mi=E9, 06-07-2005 a las 15:01, Marcelo G Ametller escribi=F3: > Gente: >=20 > Sobre los ultimos hilos de la lista me gustaria decir que: >=20 > Estoy ha favor del modelo de desarrollo estilo "Agile" o "Programacion > Extrema", no se si sera mejor o peor que el sistema tradicional o UML, > con sus casos de uso y demas... pero lo creo mas conveniente para el > proyecto... >=20 > Generalmente por experiencia propia, en los proyectos colaborativos > estilo open source... el exito depende de que se alcancen objetivos > rapidamente y se vaya liberando funcionalidad (codigo) > frecuentemente. >=20 > Muchos desarrolladores / colaboradores se suman a un proyecto, cuando > ven el "avance" de este, ya que a su vez lo necesitan para instalarlo > a un cliente o empresa... >=20 > Muchos proyectos fracasan por exceso de an=E1lisis y pocos resultados e= n > la practica... > Otros fracasan por ... falta de analisis y mucho desarrollo que no va > a ninguna parte... >=20 > Se que dicho equilibrio es complicado de lograr... y que muchos no lo > compartiran. >=20 > En el estilo Agil, mucho depende de la "intuicion" de los > desarrolladores... y de que trabajen varios mirando el codigo del > otro... > Me refiero a "intuicion" basada en la experiencia y razonamiento... en > este punto y por lo que vi hasta ahora me parece que Jose como > coordinador lo lleva por buen camino... >=20 > Me parece que el objetivo principal es tener una version funcionando a > la brevedad... y paralelamente desarrollar la documentacion... y > completar los analisis... >=20 > Si se sumara mas gente al proyecto... se avanzaria mas rapido, ya que > se podrian delegar mas tareas y realizar las que faltan... pero mucha > gente no se suma porque no sabe a donde va ha ir a parar el > proyecto... no saben si sera "... uno mas que pinta bien pero no se > termina nunca..." >=20 > En resumen... prefiero que haya menos documentacion y mas codigo... en > esta etapa del proyecto (Remarco en esta etapa), hasta alcanzar cierta > funcionalidad... Totalmente de acuerdo, Marcelo. Yo no lo podr=EDa haber explicado mejor. Jose |
From: Jose <coo...@py...> - 2005-07-06 13:03:36
|
El mi=E9, 06-07-2005 a las 01:31, Cesar Pablo Verdes escribi=F3: > Cuando decis "para que los dem=E1s pod=E1is participar cuanto antes", =BF= te > refieres a codificar? S=ED. > Si =E9ste fuera el caso entiendo tu decisi=F3n, aunque suguiero en esta > etapa trabajar en la documentaci=F3n del an=E1lisis a fin de no caer en > codificar sin una guia (manteniendo la filosof=EDa de producci=F3n "Agi= l" > y como capas de cebolla, aclaro que no me refiero a al "Analisis" de > RUPS ni nada por el estilo). La forma de redactar los an=E1lisis ya est=E1 documentada. Al tratarse de una metodolog=EDa "Agile" otorga mucha libertad en aras de agilizar su redacci=F3n. > A lo que me refiero es que por ejemplo, por lo que entiendo Marcelo > est=E1 produciendo la parte de clientes, pero la documentaci=F3n del > componente "Charon/Ficheros maestros/Clientes" est=E1 vacia (Marcelo po= r > favor no lo tomes a mal este comentario, lo pongo como ejemplo). =BFNo > ser=EDa mejor documentar el an=E1lisis para que las personas que lo des= een > pueda opinar antes de ponerse a codificar componentes espec=EDficos?=20 Por una parte soy yo el que est=E1 desarrollando Charon. Marcelo est=E1 poniendo en pr=E1ctica lo que todos debemos hacer: participar en el desarollo de los m=F3dulos de los dem=E1s. En cuanto a lo de documentar el an=E1lisis antes de codificar, eso es lo ideal y lo que se indica en la metodolog=EDa propuesta, pero en un mensaj= e anterior coment=E9 por qu=E9 no lo he cumplido en esta =FAltima parte del proyecto. De hecho la idea es: 1. documentar un an=E1lisis 2. dar una semana para comentar el an=E1lisis 3. modificar el an=E1lisis para reflejar las conclusiones del punto 2 4. codificar > Estamos elaborando muchas cosas por mail que leemos solo los > suscriptos a la lista, en vez, un an=E1lisis plasmado en la web lo pued= e > ver y opinar cualquiera, y a su vez atraer a mas colaboradores. Aclaro > que yo en lo personal me vi atraido al proyecto por tu claridad de > conceptos y organizaci=F3n que lograste trasmitir en el sitio > /dev.pypyme.org/doc/ >=20 > =BFQue opinan? La lista de correo no pretende sustituir la documentaci=F3n sino ayudar a discutir y aclarar conceptos. Se trata de una herramienta para llegar a un fin, que no es otro sino crear y documentar c=F3digo. > > Lo que s=ED necesitaremos es idear una forma de correlacionar las > > historias de usuario con los tests de aceptaci=F3n. Como no hemos mon= tado > > (ni nadie se ha asignado dicha tarea) la infraestructura necesaria pa= ra > > ejecutar tests de aceptaci=F3n, este tema ha quedado pospuesto. > > =20 > Suguiero como algo importante para luego simplificar el montaje de la > infraestructura de tests de aceptaci=F3n, definir y utilizar una > codificaci=F3n de las historias de usuario. > Se me ocurre utilizar un c=F3digo como el siguiente: > HU-xxx-yyy-nnnn >=20 > donde: > - "HU" es la abreviaci=F3n de "historia de usuario" > - xxx es una abreviaci=F3n del m=F3dulo... por ejemplo "THA", "CHA", > "UMB", "POR", "OBE", "THE" y "ELA" (o cualquier otra que Uds. > sugieran). > - yyy es una codificaci=F3n del componente... por ejemplo "PYC" para > PyContainer "adaptado" de Thalassa. > - nnnn es un n=FAmero correlativo de Historias de usuario. >=20 > En la documentaci=F3n espec=EDfica del componente bastar=EDa solo con > numerarlos, pero se deber=EDa utilizar el c=F3digo completo cuando se > refiere desde otro sitio de la documentaci=F3n. >=20 > Siguiendo el mismo razonamiento tal vez sea bueno codificar y enumerar > todo a medida que se va produciendo para facilitar su futura > identificaci=F3n. Por ejemplo podemos utiliar los siguientes prefijos: > - "RO": Roles > - "HE": Historias =E9picas > - "TA": Tests de acptaci=F3n >=20 > =BFLes parece conveniente? La metodolog=EDa basada en historias de usuario no precisa codificaci=F3n alguna. Tan s=F3lo necesitaremos codificar las historias de usuario para poderlas relacionar con los tests de aceptaci=F3n correspondientes. Por otra parte, la codificaci=F3n que propones para las historias de usuario me parece buena. > > > > 4) =BFHay alg=FAn componente espec=EDfico encargado de la "docume= ntaci=F3n del > > > > usuario"? Tal vez lo pensaron como una funcionalidad de cada > > > > componente... pero =BFno deber=EDa haber en Charon un componente = espec=EDfico > > > > que preste servicios de busqueda, indesaxion, etc? > > > > =20 > > > Creo que faltaria ese modulo... > > > Pense en en un componente separado de charon... digamos "manual" , = que > > > imitando a deploy para armar los menus dinamicos... busque en cada > > > modulo... (charon, portia...) un componente "manual" especifico de > > > cada uno... y lo agregue como un "grupo" independiente... > > >=20 > > > Visualmente quedaria una barra de menus... > > >=20 > > > - charon - portia - manual > > > I > > > I- manual comun > > > L manual charon > > > L manual portia > > >=20 > > > obviamente... en lugar de charon dira tablas generales, en lugar de > > > portia tesoreria... etc... > > >=20 > > > esto permitiria que deacuerdo a la configuracion de modulos que se > > > carguen, el manual acompa=F1e a cada uno... dinamicamente... > > > =20 > > A pesar de lo que muchos digan yo creo que no podemos documentar el u= so > > de una herramienta hasta que no dispongamos de ella. Por ello, y aun > > valor=E1ndola como un requisito imprescindible, no he prestado mucha > > atenci=F3n al tema de la documentaci=F3n de usuario. > >=20 > > Creo que es algo que podemos dejar para m=E1s adelante, para cuando > > dispongamos de la v1.0. > >=20 > > Marcelo: no estoy seguro de si C=E9sar se refiere a c=F3mo integrar l= a > > documentaci=F3n de usuario o a otra cosa. En cualquier caso queda > > registrada tu idea 8-). > > =20 > Totalmente de acuerdo. No tiene sentido documentar la ayuda ahora, me > refer=EDa al enfoque de Marcelo... un componente o m=F3dulo que utiliza= ndo > servicios de los compontes arme la ayuda para el usuario > (independientemente de texto de la ayuda, o ayuda sobre que tema).=20 > Por ejemplo, la vista que est=E1 usando el programa tiene campos de > ingreso de datos, por lo tanto los controladores podr=EDan informar al > componente "ayuda" un texto descriptivo sobre que espera el sistema > que el usuario ingrese en cada lugar. A su vez cada vista tiene una > funci=F3n dentro de una tarea de un flujo de trabajo. La vista tambien > podria registrar informaci=F3n en el componente "ayuda". > Es solo para dejar registrada la idea a nivel an=E1lisis de servicios d= e > componentes (no de documentaci=F3n espec=EDfica)... tal vez no sea mome= nto > para preocuparse por =E9sto. Es un tema que habr=E1 que tratar. S=F3lo que no creo que sea el momento. > > > > 5) Desde que trabaj=E9 con SAP me ha obsecionado el dise=F1o de i= nterfaz de > > > > usuario de los sistemas y he estudiado bastante sobre el tema. Al= g=FAn d=EDa > > > > me gustar=EDa conversar sobre el tema (tal vez sobre la base de e= scribir > > > > un documento de sugerencias espec=EDficas). > > > > Tras leer el apartado de "Interfaz de usuario" de la documentaci=F3= n me > > > > surgen muchas ideas/sugerencias. Posiblemente en este momento del > > > > proyecto sea conveniente dise=F1ar e implementar una interfaz b=E1= sica como > > > > la planteada... o tal vez sea conveniente profundizar en su an=E1= lisis > > > > inicial. =BFCual es tu opini=F3n? > > > > Pongo a tu disposici=F3n mi tiempo, si lo consideras conveniente,= para > > > > trabajar en esta =E1rea a fin de realizar un An=E1lisis mas detal= lado con > > > > visi=F3n de futuro de la interfaz de usuario de pyPYME. > > > > =20 > > Creo que a todos nos gustar=EDa disponer del documento del que hablas= , con > > tus propuestas y sugerencias. Lo adjuntar=EDamos a la documentaci=F3n > > t=E9cnica y as=ED podr=EDamos iniciar una conversaci=F3n acerca de si= incluir o > > no algunas (o todas) tus ideas. > > =20 > Ma=F1ana mismo comienzo a trabajar en =E9sto! Si les parece bien > diariamente ir=E9 presentando los progresos en la documentaci=F3n. > Tal vez convenga hacerlo por mail para ver si vale la pena incluir las > ideas o no... de decidir incluirlas, pasar=EDa a trabajar documentar > sobre la Web (con tu permiso obviamente). Me parece bien. > > > > =BFQue te parece m=E1s conveniente para el proyecto?... que dediq= ue un > > > > tiempo a realizar un an=E1lisis m=E1s global de la interfaz del u= suario (el > > > > menos en lo referente a Historias =E9picas, Composici=F3n, Histor= ias de > > > > usuario, Test de aceptaci=F3n, etc) o que comience con el an=E1li= sis del > > > > M=F3dulo Contable paralelamente a la lectura y estudio del c=F3di= go ya > > > > programado? > > > > =20 > > Perdona pero no acabo de entender la relaci=F3n entre el an=E1lisis d= el > > interfaz de usuario y la metodolog=EDa de desarrollo. =BFMe puedes de= tallar > > un poco m=E1s este p=E1rrafo? > > =20 > Mi pregunta era para consultarte como "coordinador" del proyecto sobre > tu parecer sobre que es m=E1s =FAtil en este momento. Por raz=F3n de > disponibilidad de tiempo no puedo hacer ambas cosas simultaneamente. > Si est=E1n de acuerdo y dado el inter=E9s en el tema de interfaz de > usuarios presentado en el mail de Patricio y el tuyo, me dedicar=E9 a > plasmar en palabras todos los conceptos y sugerencias sobre interfaz > de usuarios, dejando para m=E1s tarde el an=E1lisis del m=F3dulo contab= le. Ok. Jose |
From: Marcelo G A. <mam...@gm...> - 2005-07-06 13:01:48
|
Gente: Sobre los ultimos hilos de la lista me gustaria decir que: Estoy ha favor del modelo de desarrollo estilo "Agile" o "Programacion Extrema", no se si sera mejor o peor que el sistema tradicional o UML, con sus casos de uso y demas... pero lo creo mas conveniente para el proyecto... Generalmente por experiencia propia, en los proyectos colaborativos estilo open source... el exito depende de que se alcancen objetivos rapidamente y se vaya liberando funcionalidad (codigo) frecuentemente. Muchos desarrolladores / colaboradores se suman a un proyecto, cuando ven el "avance" de este, ya que a su vez lo necesitan para instalarlo a un cliente o empresa... Muchos proyectos fracasan por exceso de an=E1lisis y pocos resultados en la practica... Otros fracasan por ... falta de analisis y mucho desarrollo que no va a ninguna parte... Se que dicho equilibrio es complicado de lograr... y que muchos no lo compartiran. En el estilo Agil, mucho depende de la "intuicion" de los desarrolladores... y de que trabajen varios mirando el codigo del otro... Me refiero a "intuicion" basada en la experiencia y razonamiento... en este punto y por lo que vi hasta ahora me parece que Jose como coordinador lo lleva por buen camino... Me parece que el objetivo principal es tener una version funcionando a la brevedad... y paralelamente desarrollar la documentacion... y completar los analisis... Si se sumara mas gente al proyecto... se avanzaria mas rapido, ya que se podrian delegar mas tareas y realizar las que faltan... pero mucha gente no se suma porque no sabe a donde va ha ir a parar el proyecto... no saben si sera "... uno mas que pinta bien pero no se termina nunca..." En resumen... prefiero que haya menos documentacion y mas codigo... en esta etapa del proyecto (Remarco en esta etapa), hasta alcanzar cierta funcionalidad... Saludos y disculpen lo largo del mail... --=20 Marcelo Ametller www.maramsis.com.ar - www.aeroenlace.com.ar Ubuntu Linux User. |
From: Cesar P. V. <ces...@ya...> - 2005-07-06 02:53:27
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=iso-8859-15" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Jose wrote: <blockquote cite="mid...@de..." type="cite"> <pre wrap="">El mar, 05-07-2005 a las 15:27, Marcelo G Ametller escribió: </pre> <blockquote type="cite"> <pre wrap="">On 7/4/05, Jose <a class="moz-txt-link-rfc2396E" href="mailto:coo...@py..."><coo...@py...></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">Sólo falta la información relativa a 'zonas'. No sé si seguiste la línea de razonamiento (no recuerdo ni quién lo propuso ni quién lo siguió) pero acordamos, en su día, agrupar los clientes en 'zonas' de tal forma que cada dirección podría asignarse a una zona definida por el usuario. Así, quedaría: customers_addresses (1 a 1) areas La tabla de zonas sólo contiene un título y el tipo al que se refiere junto con una tabla de detalle: AREAS ----- ID BIGINT NOT NULL, CODE VARCHAR(20) NOT NULL, NAME VARCHAR(50) NOT NULL, TIPUS INT NOT NULL AREAS_COMPOSITION ----------------- ID BIGINT NOT NULL, ID_AREA BIGINT NOT NULL, NAME VARCHAR(50) NOT NULL donde TIPUS puede tomar los valores: 1=localidad 2=provincia 3=pais y la columna NAME contendrá el nombre del elemento que forma parte del área. Este elemento puede ser una población, una provincia o un país. Observarás que no he incorporado estas 2 tablas porque prefiero conocer vuestra opinión al respecto. </pre> </blockquote> <pre wrap="">no me queda claro.. voy a revisar el historico... pero me podrias dar un ejemplo con el contenido de las tablas ? </pre> </blockquote> <pre wrap=""><!----> Areas: name: EMEA (Europe and middle-east asia) tipus: 3 (paises) Areas_Composition: name: España name: Francia name: Alemania name: Bélgica ... o Areas: name: Hispano América tipus: 3 (paises) Areas_Composition: name: Méjico name: Brasil name: Argentina name: Ecuador name: España (o división por códigos postales dentro de un país o por ejes cardinales, Norte, Sur, Este o Oeste, o por...) </pre> <blockquote type="cite"> <pre wrap="">en customers_addresses seguiria habiendo provincia, pais ? </pre> </blockquote> <pre wrap=""><!----> Sí, porque la gestión de áreas sirve como clasificación independiente a la asignación de direcciones físicas. Se tratan de conceptos distintos. </pre> </blockquote> Jose,<br> <br> Vos decias:<br> <pre wrap=""> customers_addresses (1 a 1) areas Pero... ¿No sería customers_addresses (1 a n) areas? o mejor dicho... ¿customers_addresses (1 a n) areas_composition? Aun no me resulta claro el concepto :-( ¿Podrian ayudarme a comprender con un ejemplo de Areas en relación a Clientes? Gracias y disculpen la dureza mental :-) C. </pre> </body> </html> ___________________________________________________________ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar |