info@gxopen.uy

1. Mesa Redonda GXOpen info@gxopen.com.uy

2. GXOpen • Objetivo y Esencia • Lo que tenemos para lograrlo

3. Esencia y Objetivo • Compartir y transmitir conocimiento • Consolidar una comunidad • La esencia es la actitud de compartir

4. Lo que tenemos para lograrlo • Creación de proyectos comunitarios • Incluir subproyectos a nuestros proyectos • El foro de GXOpen • El aporte propio

5. GXOpen • Compartir • No reinventar la rueda • Ahorro de tiempo • Aprendizaje continuo

6. GXOpen • Estado actual • Biblioteca de proyectos • Cantidad y variedad • Biblioteca de recursos • Styles • Themes • Iconos

7. GXOpen • Cambio Cualitativo • Planteo de Metas ambiciosas • Proyectos de largo alcance (ej: ERP) • Sistemas Integrados e Integrables • Plan directriz (Donde queremos ir)

8. GXOpen • Hay Lugar para todos los roles • Coordinador de proyecto • Análisis • Documentadores • Testers

9. GXOpen GXOpen • Sistemas que se reinventan una y otra vez: • Stock • Personas • Liquidación de sueldos • Facturación • Seguimiento de Expedientes

10. Patrones de software y Genexus • Patrones de software • Concepto: Un patrón es un documento que captura “best practices” , experiencia en un formato que permite a otros reutilizarla • Origen: Surge en la arquitectura, y luego se aplica a muchas disciplinas, incluyendo la Ingeniería de Software • Definición: ”Cada patrón es una regla conformada por tres partes, que expresa una relación entre un cierto contexto, un problema y una solución” Christopher Alexander

11. Patrones de software y Genexus • Clases de patrones • Cada disciplina requiere un tipo distinto de patrón, de acuerdo al conocimiento que desea capturar • Algunas clases de patrones de software: • Patrones de Diseño de software • Patrones de Análisis de software • Patrones de Implementación de software • Patrones de Arquitectura de software • Existen patrones en la Arquitectura, en la Administración, Gestión de proyectos, etc.

12. Patrones de software y Genexus • Ejemplo Genexus: “Trabajar con” • Es un patrón porque cumple los 3 requisitos • Soluciona un problema recurrente: el ABM de registros • Tiene un nombre conocido por todos • Es una solución abstracta, ya que se describen los componentes y sus relaciones que luego deben ser instanciados al aplicar el patrón • Claro, es un patrón muy simple... Los patrones más útiles presentan soluciones no obvias a problemas recurrentes

13. Patrones de software y Genexus • ¿Por qué patrones? Los patrones recogen soluciones probadas a problemas recurrentes en cierto contexto • Los beneficios de su uso por una comunidad son múltiples: • Se comparte la experiencia o conocimiento de la comunidad • Generan un lenguaje común dando nombres a distintas soluciones de problemas comunes • Homogenizan las aplicaciones construidas • Mejoran la productividad quien los usa • En suma, compartir experiencia y no solo código

14. Patrones de software y Genexus • OK, los patrones son beneficiosos... ¿Y ahora? • En cada comunidad, existen diferentes mecanismos de definición y validación de patrones, desde GxOpen podemos establecer los nuestros • ¿Qué hay para hacer? • Elegir que clase o clases de patrones necesitamos, o sea, que experiencia nos interesa compartir • Escribir una plantilla para patrones • Crear grupos que trabajen sobre cada patrón que se detecte • Motivar al resto de la industria a aportar su conocimiento y experiencia

15. Organización en la Publicación de Proyectos • Objetivos de esta Presentación: Establecer una serie de pasos a seguir a la hora de públicar un proyecto. Se pretende que esta presentación sirva de guía a los integrantes de esta comunidad para que puedan brindar mas información del proyecto que se pública. Con esto se intenta incentivar a la reutilización de código y poder tener una idea clara del proyecto que se esta bajando sin tener que probarlo.

16. Organización en la Publicación de Proyectos • Con qué nos encontramos a la hora de descargar un Proyecto? • No es clara la idea del Proyecto • La descripción de las versiones no es buena o no existe • No existe buena documentación • No se indica la versión de GX en la que fue desarrollado • No hay guía de desarrollo ni de implementación

17. Organización en la Publicación de Proyectos • No se documentan las mejoras en las versiones • En ocasiones no se entienden los criterios a la hora de publicar distintas versiones de un mismo proyecto • Se utiliza mucho código externo a la hora de desarrollar • No se siguen estandares de desarrollo para nombrar atributos y variables

18. Organización en la Publicación de Proyectos Que proponemos para organizar y mejorar la publicación de Proyectos • Dejar clara la idea del proyecto por medio de documentación o en la descripción del mismo. • Mejorar las descripciones de las versiones que se públican. No poner descripciones que son iguales al título de la versión. • Acompañar los proyectos de documentación descriptiva que puede ser técnica o simplemente de usuario.

19. Organización en la Publicación de Proyectos • Indicar la versión de GX en la que se desarrollo el Proyecto e indicar Generador • Hacer una pequeña guía de implementación e indicar si es necesario hacer referencia a alguna DLL o OCX si fuese necesario • Crear una breve documentación de las mejoras cuando se públican nuevas versiones de un Proyecto

20. Organización en la Publicación de Proyectos • Ser ordenados a la hora de incrementar las versiones de un Proyecto. Seguir todos el mismo críterio • Evitar la utilización de código externo a GeneXus. Si es pósible no utilizar código que no sea GeneXus. Esto para poder probar las versiones en cualquier generador sin tener que saber un lenguaje en especial. • Para poder facilitar la reutilización de código proponemos que se utilize la nomenclatura GIK para nombrar atributos

21. Organización en la Publicación de Proyectos • Nomenclatura GIK ARTech ha definido un Standard para la nomenclatura de atributos, el GIK (GeneXus Incremental Knowledge Base). Puede gustarnos más o menos que otros. Lo importante es que es el utilizado por la comunidad de usuarios GeneXus. Esto viabiliza reutilización de conocimiento entre ellos. Nombre de atributo> Objeto + Categoría + Calificador Objeto: Es el nombre del Objeto al que pertenece el atributo Categoría: Es la categoría semántica del atributo Calificador: Puede existir uno o dos calificadores.

22. Organización en la Publicación de Proyectos • Ejemplo de Nomenclatura GIK • Transacción Clientes Objeto Categoría Calificador Atributo Cli Cod CliCod Cli Nom CliNom Cli Fch Nac CliFchNac Cli Fch Ing CliFchIng

23. Organización en la Publicación de Proyectos • Conclusiones: Acompañar el XPW o XPZ de los siguientes archivos: • Readme.txt que contenga: • Idea y descripción general del Proyecto • Versión y Generador de GeneXus en el que fue desarrollado • Versión.txt que contenga: • Versión del Proyecto • Descripción de la Versión • Mejoras incorporadas con la versión • Cambios realizados con respecto a la versión anterior

24. Organización en la Publicación de Proyectos • Desarrollo.txt que contenga: • Notas sobre el desarrollo • Documentar si se necesitan hacer referencias a dll o OCX • Indicar si se tienen que registrar DLL • Si se necesitan utilizar procedimientos externos hacer comentarios de cómo hacerlos y si es posible utilizar archivos IGX • Otros: • Según la magnitud del proyecto se pueden incluir manuales de usuario, de administración y de desarrollo • Comentar los programas realizados en GeneXus • Para saltar de versión tener en cuenta lo propuesto anteriormente

25. Most Active Members • La tabla de "Most Active Members" es actualizada con el siguiente criterio: • Reviews • Very Aceptable 20 • Aceptable 10 • Medium 0 • Not Aceptable -10 • Rejected -20

26. Most Active Members • La tabla de "Most Active Members" es actualizada con el siguiente criterio: • Proyectos: • Cada proyecto el usuario a creado 100 • Cada download de su proyecto 10 • Cada versión el usuario ha creado 50

27. Usuarios

28. Proyectos