Desarrollando desde la trinchera.

Durante un tiempo estuve desarrollando con GeneXus X Ev1, con el generador Java.  Antes había desarrollado con GeneXus 9.0, pero el completar todas las propiedades del modelo java para lograr configurarlo y dejarlo operativo desalentaba muchísimo su uso. Cuando empecé a usar la GeneXus X, descubrí la maravillosa funcionalidad que hace que se completen en forma automática la mayoría de las propiedades que son necesarias para compilar y ejecutar una aplicación web con Genexus y Java. La he usado desde muchas veces, creando varias KB con mi anterior notebook y no tenia ningún problema. Cambié a un nuevo notebook de 64bits y para mi desgracia comprobé que nuevamente tengo que llenar manualmente las propiedades de los ambientes java (SAC # 28180) y veo que estoy bastante atrofiado con eso. Me da una pereza horrible ponerme a llenar algo, que GeneXus ya se sabe como completarlo. Aunque parezca una nimi...

Leia en Case Study: Migrating a VB6 Large Application to .NET el caso de una migracion de una aplicacion de 950.000 lineas de codigo a .NET de un ERP y dicen (las negritas son agregado mio): The entire ERP application was migrated in 9 months by 3 developers totaling “ 3,650 developer-hours to migrate the code, 3,400 hours for code review and refactoring, and 1,300 hours for testing.” The code review was requested because the code would need further development in the future and none of the original developers were available. Total cost: 750,000 Euros , much less than the required one for a customized ERP. The process evolved in phases: when a module was done, it would be integrated with the rest of the VB application until the entire application would have been migrated to .NET. Siempre me gustan estos articulos donde se detallan numeros pues permiten hacer comparaciones en la vida real dentro de nuestra industria. Nosotros hicimos (en el 2004) una migración "similar", un...

Algunas veces el trabajo nos sorprende. Esta ves me permitió poder comprobar algo que intuyo pero que es dificil de comprobar en la práctica, pues no es facil conseguir elementos comparables. La hipotesis a probar, es que las metodologias de programacion basadas en modelos y/o en generacion de codigo (y en particular GeneXus) permten una mejor productividad en el desarrollo de aplicaciones comerciales y tambien que se las puede mantener con un esfuerzo menor que las metodología de desarrollo tradicional. Una forma de comprobarlo sería tener dos grupos que desarrollen una aplicacion, uno usando GeneXus y otro con una metodologia de desarrollo tradicional y luego de algunos años comparar el resultado y los tiempos que insumen mantener las aplicaciones. Raramente se van a conseguir esas condiciones por los costos asociadas con el doble desarrollo. En un trabajo reciente, me tocó hacer una consultoría en la que debía hacer sugerencias para mejorar un sistema que es mantenid...

Hice un encuesta ** sobre como estaban utilizando código externo en aplicaciones GeneXus. La idea es hacer un pequeño resumen de cuales son las funcionalidades que exigen a los programadores a usar funcionalidades propias del lenguaje que no pueden resolverse con GeneXus. Dejé en la pagina Código externo en aplicaciones GeneXus en el wiki de la comunidad los principales resultados. Estaría bueno que los que quieran completen la lista con sus necesidades, de forma de poder hacer solucionar estas necesidades de una forma que sea mas fácil de integrar con GeneXus. Si se pueden solucionar estos problemas, vamos a poder hacer aplicaciones mas poderosas en forma mas fácil. Esta lista es una buena base para la realización de algún proyecto colaborativo por si alguno lo quiere resolver para su uso propio y para ponerlo a disposicion de la comunidad. Si alguno quiere dejar comentarios en el blog en vez de editar la pagina, tambien es bienvenido. ** Bueno, en realidad revisé algunas KB y le pr...

Este post, puede considerarse un post egoista, pues sirve es simplemente para acordarme, pues hoy perdi un buen rato tratando de solucionar algunos problemas que nos pasaron al pasarnos al U4 de Java (en GeneXus 9.0). Por suerte ninguno es grave, pero igual da bastante trabajo aislarlos y encontrarle la vuelta. 1) Tamaño personalizado de la Impresion. Cuando hay un formulario de tamaño personalizado, en el Gxprn.ini hay que poner PaperSize= 256 PageLength=xxx PageWidth=yyy porque sino no le da bolilla al largo y al ancho fijado. 2) Codificacion de Mails. Los headers de los mails empezaron a tener un formato diferente que en el U3. Esto hizo que el campo Para: aparezca codificado de una forma extraña. En algunos clientes de mail se ve bien y en otros se ve mal. Esto creo que se lo debemos a nuestros hermanos orientales y sus caracteres extraños. Si nosotros con la Ññ y 5 letras acentuadas tenemos problemas, ellos con algunos caracteres mas supongo que deben sufrir lindo. 3) Algo relacio...

Para algunas aplicaciones desarrolladas con GeneXus 9.0 y java, estamos utilizando el driver JDBC iNET - UNA. Es muy rápido, funciona bien y en general no nos ha dado dolores de cabeza. Si se lo usa con cursores firehose, es de lo más rápido que hemos encontrado. Este es uno de los drivers que GeneXus tiene en la lista de "pre-configurados" con lo que se puede armar la url de conexión sin mayores dificultades. Al elegirlo GeneXus utiliza una URL como ésta: jdbc:inetdae:servidor:puerto?database=base El problema que ocasiona esto, es que si se tienen campos de mas de 255 caracteres, los mismo se ven truncados a este tamaño. Esto es porque trabaja en compatibilidad SQLServer 6.5. En un cliente (donde había surgido el problema de los datos truncados) habíamos cambiado a : jdbc:inetdae 7 :servidor:puerto?database=base lo cual nos solucionó dicho problema, pero nos ocasionó otros. La performance de la aplicación pasó a ser bastante mala, y algunos bloqueos de registro ESCALABAN a ...

Hace unos días, en Concepto se terminó la migración de una aplicación a su funcionamiento full web. Esta migración (otra mas y van.....) esta trae de yapa un cambio del modelo de negocio, por lo que pasaría a ser algo del tipo de SaaS. Veremos como nos va. Cuando hicimos las pruebas en la intranet, todo funciona muy bien. La segunda etapa era hacer lo mismo en internet, para empezar a ver como podría ser para un usuario real, estar todo el día con una aplicación en el web, con sus latencias, interrupciones y demás. Si bien tenemos mucha experiencia en poner aplicaciones en internet, cada aplicacion tiene sus particularidades y esta era la primera hosteada con tomcat que ibamos a usar en para cosas de "mision crítica". Las primeras pruebas que realizamos en internet, vimos que la performance si bien no era espantosa, no era apta para poder trabajar todo el día sobre ella. Haciendo algunas mediciones, se ve que las páginas demoran un tiempo fijo (unos 8 segundos) para cargar, e...