GeneXus vs desarrollo tradicional con eclipse. Una comparación de la vida real
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 mantenido por un grupo profesional muy bien formado que esta desarrollado en java en otro país.
Por las casualidades de la vida ( y por encontrarnos en un nicho de mercado muy específico) tanto el sistema en el cual estamos trabajando desde hace años, como el que usan ellos hoy en dia, son una derivacion del mismo sistema, desarrollado por un grupo de desarrolladores extranjeros.
La historia fue mas o menos asi:
Grupo 1 - Visual FoxPro.
1996 - Se desarrolla un sistema en Visual FoxPro / Oracle. (v1.0), siendo su interfaz totalmente Win.
Grupo 2 - GeneXus
1999 - Se implementa dicho sistema por nuestra parte y empieza la migracion del mismo a Genexus. Durante un tiempo funciona en Visual Foxpro programado a mano y con modulos desarrollados con GeneXus generando Visual Foxpro y con C++ para las consultas WEB.
2001 - Se convierte toda la aplicación a Genexus. Se empieza a migrar de WIN a WEB.
2002 - Se abre una nueva version para un nuevo cliente, con SQL Server, con muchas adaptaciones. Se genera en C#. A partir de este momento se mantienen 2 versiones paralelas.
2003 - Dejamos de generar Visual FoxPro y C++ y pasamos a generar C# sigue la transición a WEB.
2009 - Ambas aplicaciones incorporan nuevas funcionalidades y estan en mantenimiento permanente por arreglo de errores.
Grupo 3 - Java
2002 - Migran la aplicación original (de Grupo 1) en Java/WEB con Oracle, con algunos módulos en Visual Foxpro.
2009 - El sistema se encuentra en desarrollo, agregandole nuevas funcionalidades y en mantenimiento de errores que aparecen.
Lo que me interesa comparar, es la productividad del Grupo 2 que trabaja con GeneXus y la del Grupo 3 que programa con Java y EclipseLink (Ex: Toplink).
Las características generales son:
| Grupo 2 | Grupo 3 | |
| Herramienta de Desarrollo | GeneXus (generando C#) | Eclipse + EclipseLink |
| Base de datos | Oracle y SQL Server | Oracle |
| Grupo de trabajo (Capacitacion) | Buena capacitacion | Buena capacitacion |
| Grupo de trabajo (personal) | 20 | 25 |
| Grupo de trabajo (rotación) | Muy baja | Baja |
| Cantidad de aplicaciones | 2 | 1 |
| Cantidad de tablas | 700 | 850 |
| Documentacion | Pobre | Pobre |
La situación de ambos grupos luego de mas de 7 años de mantenimiento de la aplicación es bien diferente.
En el grupo que mantiene la aplicación de forma tradicional, se quejan que los cambios le llevan demasiado tiempo y que se introducen muchos errores no deseados.
También se quejan de problemas que les resulta difícil alterar la estructura de la base de datos, pues no pueden determinar cuales programas pueden ser afectados.
Otros de los problemas que tienen:
- Tablas no normalizadas
- Tablas repetidas
- Faltan contraints de integridad referencial.
- Programas con Code Injection en SQL
- Javascript no compatible con nuevos navegadores (poco Ajax)
- No funciona con nuevas versiones de java
- Hay progrmas que tienen sentencias "Select * from..." lo cual da problemas cuando se agregan / quitan campos.
- Un usuario tiene diferentes usuario/contraseña para diferentes modulos (seguridad no integrada)
- Falta de una arquitectura definida.
- Problemas de usuabilidad en la integracion entre módulos.
- Aun quedan algunos modulos en Visual Foxpro a cambiar.
Están evaluando seriamente cambiar de sistema para poder bajar los costos de mantenimiento pues sienten que no pueden hacer los cambios a la velocidad deseada.
En el Grupo2 con GeneXus, la situación es diferente pues no está en consideración el cambiar el sistema, sino que estamos incorporando nuevas funcionalidades a buen ritmo.
Los problemas son que hay son:
- Sentencias con problemas de performance
- Falta de constraints de integridad referencial
- Problemas de diseño de pantallas (no son lindas).
Estamos en versiones razonablemente actuales del software utilizado (base de datos, .net framework, browsers).
Resumen.
Si bien las condiciones no son totalmente comparables por no ser ninguna organización igual a otra y tampoco tener los mismos objetivos, creo que las diferencias entre la situación de un grupo con el otro, son lo suficientemente grandes como para mostrar que las ventajas de desarrollar con GeneXus superan a las que brinda el desarrollo con Eclipse..
En resumen, si bien el desarrollo de aplicaciones con GeneXus dificultan un control fino de los detalles tanto de presentación, como detalles de las sentencias que se pueden ejecutar, el costo de mantener la aplicación en el largo plazo es mucho menor.
Ademas las personas que desarrollan con GeneXus tienen mas tiempo para dedicarse a entender el negocio y no necesitan preocuparse tanto por las tecnologias aplicadas en los proyectos.
Ademas las personas que desarrollan con GeneXus tienen mas tiempo para dedicarse a entender el negocio y no necesitan preocuparse tanto por las tecnologias aplicadas en los proyectos.
Enrique,
ResponderBorrarMuy interesante la comparación, mas que nada porque es sobre un caso real, pero lo que no me termina de cerrar es que primero comentás que el grupo Java es profesional y muy bien formado, pero luego cuando detallas los problemas que tienen me lleva a pensar lo contrario. Tablas no normalizadas, repetidas, falta de constraints, mal manejo de SQL y como si fuera poco no tienen una arquitectura definida, completito…
En lo personal desarrollo en Java hace mas de 6 años, pero no soy fanático, también soy analista Genexus, adapté varias ideas de ésta última para los sistemas que realizo en Java, logrando una productividad muy buena.
Me tomo el atrevimiento de linkear un post que escribí hace un par de años sobre la comparación de las distintas plataformas de desarrollo:
http://federicovarela.blogspot.com/2007/12/guerra-de-plataformas.html
Saludos
Federico
Enrique, de todas maneras, la migracion de sistemas siempre es un dolor de cabeza, exista GeneXus o no, hoy en dia en la empresa en la que trabajo tenemos un sistema que aun se continua desarrollando con GX 7 (Pasar de trabajar con la 9 a la 7 fue una experiencia nada agradable) y parece que la idea que prima en la empresa a futuro es migrar todo a JAVA a Mano que seguir con GX.
ResponderBorrarHay varios puntos que se han discutido mucho, el gran problema con GeneXus es que siempre estas atado a el, la mayoría de las veces no podes esperar meses y meses hasta que salga un upgrade que corrija un error, y aveces ni siquiera se corrige.
Muchas veces hay que hacer malabares para hacer cosas que con una sentencia SQL se hace muy fácilmente. También han surgido muchas cosas nuevas para JAVA que nos permiten abstraer todo el manejo básico de las bases de datos para centrarnos en lo que realmente necesita de nuestra atención (JPA por ejemplo)
Yo desarrollo JAVA con Eclipse para mis proyectos personales, y la verdad que es que siento que con JAVA siempre hay una solución sencilla para todo, cosa que con GX no logro.
Saludos.
Creo que todas las tecnologías han evolucionado mucho, tanto Java como GX.
ResponderBorrarCreo que si hoy en día se empezaría una nueva comparación (un proyecto como el que contás Enrique por ejemplo), realmente hay muchas cosas nuevas a tener en cuenta en ambos mundos.
Lo que si me parece que no se puede comparar Java de hoy en día con GX 7.5 o GX Ev1 con Java 1
Como dijo un profesor de la FING, cuando nuestra única herramienta es un martillo, todos los problemas son un clavo.
En definitiva, me parece que si bien no podemos ser expertos en todo como profesionales tenemos que tener amplitud para saber en que casos utilizar cada herramienta.
Estoy convencido que GX y su paradigma hay muchas "partes" de nuestro sistema que las podemos hacer de mucho mejor manera que con Java o .Net "pelado".
saludos, muy bueno el artículo
Federico:
ResponderBorrarEl grupo tiene un buen nivel y son profesionales.
Las tablas no normalizadas, surge cuando tienen que juntar varios modulos independientes que comparten algunas tablas. El problema se da mayormente en las tablas que se quieren compartir entre varios modulos y las mismas quedan mal normalizadas, pues al cambiarla en un modulo, afecta al otro.
Cuando digo que no tienen UNA arquitectura, es porque tienen varias. A lo largo de los años, han logrado incorporar nuevas arquitecturas, pero no sustituyen totalmente las anteriores, por lo que se van superponiendo.
El mal manejo de SQL, si es un problema que se podría haber evitado, pero por lo que vi se da por la evolución de los modelos de datos y su cambio paulatino que lo empeoró.
Lei tu articulo (esta bueno, gracias!) y concuerdo contigo que se pueden hacer proyectos exitosos en varias plataformas. Lo que yo intentaba medir, es el COSTO de llegar a esa solucion y me importaba mas EL COSTO DE MANTENIMIENTO.
Para el tipo de aplicaciones que me toco comparar (comercial, grandes,con base de datos, mucha informacion, 20 modulos, intenso mantenimiento y que duran años) el COSTO FINAL, es menor con GeneXus.
Para otras aplicaciones, la realidad puede ser muy diferente.
Para hacer aplicaciones con GeneXus (y con cualquier herramienta) hay que hacer algunas concesiones y adaptarse a la misma para poder sacarle mas jugo a la misma.
GeneXus no sirve para todos los casos y pero para algunos proyectos que van a durar muchos años, el costo de mantenimiento es menor.
Gracias por el comentario.
Diego:
ResponderBorrarLa migración de sistemas siempre es un proyecto en si mismo.
La diferencia es que con Genexus generalmente no implica la reprogramacion de la solución, haciendo que la evolución se mas sencilla.
Tambien es cierto que muchas veces hay soluciones en lenguajes como java o .net que son mas faciles en el corto plazo y que muchas veces lograr con GeneXus una sentencia SQL dada, puede ser complicado o imposible.
Segun mi experiencia (y en los proyectos que he realizado) esas son las excepciones siendo necesario tomar medidas para solucionar esos casos en forma puntual, pero puede solucionarse la mayoria de la programación con GeneXus.
Me parece que dentro de unos años, la programación java, va a ser mas difícil de mantener que lo que esté realizado con GeneXus, pero es solo mi opinión y puede estar equivocada.
Como empresario me toca definir año a año, que herramienta vamos a utilizar en los nuevos desarrollos y por el momento, la evaluación es que con GeneXus es mas barato en el largo plazo, aunque al principio nos de un poco mas de trabajo, para algunos casos.
Recuerdo que esto no pretende ser una evaluación técnica, sino mas bien económica de la herramienta que conviene utilizar.
MelliMatias:
ResponderBorrarTodas las tecnologías han evolucionado y van a seguir evolucionando. Posiblemente cada vez mas rápido, y eso es parte importante de la ecuación.
Cada elección que uno hace es un compromiso. Si programo en java, me ato a las decisiones que pueda tener Oracle con los standards de java (porque compro a SUN hace un tiempo).
Si uso GeneXus, me ato a las funcionalidades y errores que tenga dicha herramienta.
En esta evaluacion, la idea fue medir el costo de mantenimiento en unos 10 años de desarrollo. La cuenta me sigue dando favorable a GeneXus en este nicho de aplicaciones.
Gracias por el comentario.
"el gran problema con GeneXus es que siempre estas atado a el, la mayoría de las veces no podes esperar meses y meses hasta que salga un upgrade que corrija un error, y aveces ni siquiera se corrige."
ResponderBorrarEsto si que es un problema !!!
Por lo que decís, GeneXus NO trae lo fuentes consigo, o NO es para nada fácil de modificar el código mismo de GeneXus.
Acá hay un problema de dependencia, que puede llegar a ser grave - según el caso claro. Si la empresa no saca el "fix", por lo menos vos tenes que tener el código para hacer el "fix" vos.
Como se hace en el caso de una empresa que el costo de bajada de su aplicación es USD 800.000 la hora ?
Si con GeneXus para cada cambio hay que recompilar y reorganizar.
Saludos
Bruno
PS: interesante planteo pq es de la practica
Bruno:
ResponderBorrarEn el caso que una herramienta no logra solucionar algo, es conveniente o indispensable para ese caso puntual, solucionarlo con otra herramienta.
Excepciones van a existir algunas y para todas ellas vas a tener que encontrarle la vuelta.
Los que programan en java, tienen que resolver algunas cosas con javascript (otro lenguaje).
En el caso de Genexus, se puede complementar con programación en java para casos puntuales.
El tipo de aplicación que estaba comparando, tiene costos de bajada bastante altos, por lo que hay que minimizar el tiempo de downtime.
El deployment de una aplicacion java y una GeneXus que genera java, es similar. Como java es compilado, para cada cambio hay que compilarlo, pues no es un lenguaje interpretado. En esto no le encuentro diferencia entre lo que estaba comparando yo.
Si hay diferencia entre un lenguaje compilado como java, con otros lenguajes interpretados que son mas fáciles de instalar.
Enrique,
ResponderBorrarOk, entiendo. Podes "mechar" codigo Java en una aplicacion GX si es necesario. Pero si no tenes los fuentes y el bug es el core de GX se complica, aunque esta claro que son pocos los casos (pero urgentes).
Un sistema puder ser compilado y no necesariamente hay que recompilar. Una aplicacion compilada puede usar JIT (just in time), que modificas algo y NO se recompila ese pedazito hasta que se este por usar, este proceso lo hace la Virtual Machine. JIT se utiliza en lenguajes dinamicos como tecnica de optimizacion.
El tema para mi no es si es interpretado o compilado, si es compilado y no tenes una VM marcharste, si es compilado y tenes una VM --> ok.
Por lo que vos decis si hoy tuvieras que elegir entre Java+Eclipse y GX, te quedarias con GX ?
Saludos,
Bruno
Bruno:
ResponderBorrarLa aplicacion generada es java + algunas bibliotecas de las cuales se dispone de los fuentes, por lo que si hay algo urgetne, siempre podes arreglarlo.
O sea, la aplicacion generada con GeneXus puede ser 100% open source (pidiendo los fuentes de las gxclasses a Artech)**
Si un lenguaje es compilado, debe compilarse (en diseño o en ejecución). Entiendo tu punto..
Si tengo que elegir hoy, para este tipo de aplicaciones, entre eclipse + java y GeneXus, me quedo con GeneXus.
** Sería bueno que Artech publicara los fuentes sin tener que pedírselo en cada caso, pero eso ya fue motivos de otros post en este blog.
Mi experiencia es que GX sube el piso y baja el techo.
ResponderBorrarSin duda programadores con poca experiencia pueden hacer un sistema razonable con GX pero los mejores programadores se ven muy limitado con la herramienta. Lamentablemente no me resulta facil atraer a los mejores para que trabajen en GX, simplemente no es atractivo, no es motivador, y es muy limitante.
Por otra parte, la comparación GX con Java es interesante sin duda, esas situaciones son únicas, si es que existe en realidad, suelen presentarse demasiados factores externos como para que sean comparaciones validas pero aun así son interesante.
Seria aun mas interesante GX con herramientas modernas (y completamente abiertas) como Ruby On Rails.
En los casos que se han podido medir Ruby es de 2 a 10 veces mas productivo que Java.
Por ultimo, sin bien GX facilita enormemente la evolución de la base de datos es muy pobre en dar soporte a las técnicas modernas de desarrollo de sistema. Testing, refactoreo, integración continua, etc. que a la larga hace que el mantenimiento sea innecesariamente caro.
Alejandro,
ResponderBorrarTal como comentás me ha pasado bastante de escuchar que mucha gente que programa en GX tiene ganas de programar en Java o está buscando un laburo que pueda programar en Java.
Yo tuve la oportunidad de programar en plataforma PeopleSoft que creo que es muy comparable a GX y pasaba lo mismo con la gente.
Creo que es un tema que pasa en general cuando subís el nivel de abstracción de las cosas. Porque te hago la generalización? porque con nuestro producto (GXtest, sorry por el chivo) que plante hacer casos de prueba de manera más abstracta (sorry por el chivo de nuevo), nos pasó en algunas ocasiones que gente que esta acostumbrada a hacer los casos de prueba con Selenium u otra herramienta de scripting, le parecía aburrido utilizarla porque le limitaba los desafíos.
Creo que como todo dependiendo el perfil de la persona (y no necesariamente que sean los mejores y los peores) que le va a gustar más, si el enfoque GX o el enfoque Java o .NET.
Con respecto a las herramientas para GX, creo que el tema de la versión X lo cambia todo ya que es muy sencillo hacer extensiones u herramientas en general para automatizar el trabajo con GX ya sea para lograr integración continúa o lo que necesites hacer.
Como dije antes creo que hay muchos sistemas para los cuales está muy bueno programar en GX y creo que hay otros que está muy bueno para programarlos en Java o en .NET.
También creo que hay personas con un perfil determinado para trabajar con GX y personas con otro perfil para trabajar en Java o .NET.
Saludos!
Alejandro:
ResponderBorrarEl trabajar con Genexus, no excluye el uso de otros lenguajes (.net, java, ruby) para hacer las cosas que no se puedan resolver en forma economicamente viable con GeneXus.
Lo que quiero decir es que no es GeneXus o java, sino que es GeneXus y Java.
En cuanto a que algunas personas se sienten limitadas con GeneXus lo entiendo, pero creo que es una tendencia clara de toda la industria para lograr una mejor productividad. Lo que da mas libertad, es programar en assembler, pero no es rentabla hacerlo, por lo que hace unos años nos dimos cuenta que habia que programar a mas alto nivel. Creo que la situacion aqui es la misma, y la industria se ha empezado a dar cuenta de esto. Hibernate, Oslo, Intentional software, Eclipse Modeling Framework, etc son todos señales de una tendencia que (creo) va a ser predominante en el futuro.
Ahi los buenos programadores van a ver que es necesario utilizar herramientas mas poderosas para resolver los problemas mas comunes y repetitivos.
Me dejaste pensando sobre la capacidad de GeneXus de atraer buenos o malos programadores.
Es cierto que con GeneXus una aplicacion puede mantenerse con menor cantidad de programadores estrellas y se hace mas necesario los programadores que dominen la parte funcional. No hemos tenido problemas para lograr que excelentes desarrolladores trabajen con nosotros y la metodologia que hemos desarrollado en los ultimos 20 años.
En cuanto a la comparacion con Ruby on Rails, estoy de acuerdo que seria bueno tenerla. Como decia en el post, es dificil y muy caro lograr una comparacion de un sistema de estos, en un periodo prolongado que es cuando la misma tiene sentido.
Me encantaría poder tener vigente a Ruby on Rails dentro de unos años para poder hacer una comparación. Muchas veces pasa que estas herramientas son sustituidas por otras en el transcurso de pocos años.
MelliMatias:
Coincido que hay diferentes perfiles en la forma de programar y en las herramientas que se utilizan. Lo lindo de trabajar en equipos mas o menos numerosos, es lograr un buen equilibrio y lograr que todos puedan dar lo maximo con las herramientas que usan.
Enrique,
ResponderBorrarNo entendí si el sistema fue originalmente el mismo?
Igualmente, me gustó el artículo.
El comentario que hace Federico con respecto a que si aparecen esos problemas que mencionas son casi inevitables al tratar de que el diseño original deba adaptarse a los cambios, sin estar diseñado para estos cambios.
Con respecto a lo que dice Diego, es cierto, existen cosas simples que se complican infinitamente con GeneXus, para mi son un misterio. Pero el hecho de que elija Eclipse y JAVA tiene varias cuestiones una es la cantidad de tablas, la cantidad de personas desarrollando,... etc. no es tan trivial. Creo que programando a mano, el programa final, puede tener mayor ajuste a las necesidades pero el costo para obtenerlo definitivamente tiene que ser superior.
Saludos,
gab
Gabriel:
ResponderBorrarEl sistema es originalmente el mismo, programado en Visual FoxPro/Oracle y fue migrado por un equipo a Genexus y por otro equipo a java.
Coincido que el costo de hacerlo en java (en el largo plazo) parece mayor. Ademas si le agrego el costo de mantenerse en las ultimas tecnologias, la diferencia es mayor.
Yo soy desarrollador .NET en C#.
ResponderBorrarCreo que en el desarrollo de aplicaciones, el utilizar un framework de persistencia de datos junto con herramientas y controles a medida (en mi empresa contamos con algunas hechas por nosotros), para de esa forma seguir un patron controlado por nosotros mismos, es dificil de superar. La productividad puede equipararse con aplicaciones hechas con Genexus, con el valor agregado de saber como cambiar las herramientas, adaptarlas, hacerlas crecer y evolucionar... Y no tenemos que gastar tanta plata en licencias genexus ni quedar atados a los problemas que pueda haber. Uno de mis mayores temores seria encontrarme con un escollo en el camino que no pueda superar por limitaciones de la herramienta...
Agustin:
ResponderBorrarCoincido que puede lograse una buena productividad con .NET y una metodologia ordenada.
Lo que es dificil de predecir es que va a pasar si Microsoft decide cambiar el .NET Framework por alguna otra tecnología en el futuro. Los paradigmas de desarrollo cambian, y las empresas desarrollan nuevos entornos para abarcarlas.
A todos nos puede pasar lo que le paso a los desarrolladores VB6 o Visual FoxPro, que venian programando de una forma y cuando MS lanzo el .NET Framework, tuvieron que reprogramar las aplicaciones si las querian mantener tecnologicamente actualizadas. Lo mismo te puede pasar a vos (o a mi) con cualquiera de las herramientas que usamos.
Lo que queria comentar en el post, es que en los ultimos 20 años Genexus ha logrado pasar varios de estos escollos con elegancia.
El .NET Framework fue liberado en el 2002, y la aplicacion que comentaba, funciona desde antes de esa fecha, en C y Visual FoxPro y la pudimos pasar a .NET gracias a GeneXus.
Con respecto al costo de las licencias, es cierto que hay herramientas que tienen costo de licenciamiento menor a GeneXus en el mercado, lo cual dificulta mucho su adopcion para personas que comienzan o para realizar proyectos chicos.
Gracias por tu comentario.
Enrique:
ResponderBorrarEstoy de acuerdo que GX te da cierta protección contra la obsolescencia tecnológica. Tengo algunos colegas que se quedaron atrapados en VisualFox y la están pasando mal.
No coincido en el planteo sobre si a Microsoft se le ocurre cambiar la tecnología, me parece un argumento débil. MS es una empresa enorme, con millones de clientes, simplemente no pueden evolucionar sin preservar la compatibilidad. En todo caso el riesgo es mayor con GX porque Artech no tiene la mismas capacidades.
Personalmente, la sensación que tengo al usar GX es que no logra aprovechar la tecnología plenamente.
Recuerdo mi primer curso en GX. Fue con la versión 9, específicamente para desarrollo de aplicaciones en Internet. El instructor especializado provisto por el representante en Argentina de Genexus no sabia lo que era CSS!!!
Esta pequeña anécdota muestra en blanco sobre negro lo que es GX.
Permite usar las tecnología actuales sin conocerlas pero paga el costo de un pobre desempeño.
De todas manera no creo que todos estén preparados o que necesiten trabajar con tecnología de punta.
En mi experiencia personal las grandes empresas suelen ser muy conservadoras y están mas interesada en que los sistema sigan funcionado que en usar la última tecnología.
En este contexto es en donde Genexus es rey...
En empresas que sin querer estar en la punta, necesita que los sistemas sigan funcionado al tiempo que no quedan obsoleto por el cambio tecnológico.
Alejandro:
ResponderBorrarGX tiene una ventaja sobre otras metodologias de desarrollo, pues esta trabajando a un nivel de abstraccion mas alto, lo cual permite modificar lo generado y aislarse algo mas de la tecnologia de moda.
Si comparo a Microsoft y Artech en los ultimos 20 años, puedo decirte que Microsoft ha hecho mas cambios que cortan con la compatibilidad hacia atras que las que hizo Artech. Esto no es garantia ninguna para lo que pueda pasar en el futuro, pero es un antecedente. Lo que trataba de comentar en el post, es que GX estuvo mejor situado para los ultimos cambios tecnologicos y los logro pasar mejor.
Concuerdo que se le puede sacar mas jugo a toda la tecnologia, pero tambien te digo que es dificil.
La capacitacion es otro tema interesante. GX tiene una curva de aprendizaje empinada (para lograr aprovecharlo en serio). Conseguir buena capacitacion en algunos paises que no son Uruguay, es complicado y seria bueno que no fuera asi.
Concido contigo que para las empresas (chicas o grandes) deben preocuparse en que sus sistemas los ayuden a cumplir sus objetivos, y deberia importarle poco en que tecnología esta implementado. El problema es cuando atrasarses tecnologicamente pone en riesgo el negocio, por no tener soporte o no conseguir personas que programen en ese lenguaje.
En fin, el tema da para bastante mas, pero el comentario quedo muy largo.
Gracias por tu comentario.
A Agustín Meriles,
ResponderBorrarTomando como totalmente cierto, lo que dices del
"Framework de persistencia de datos junto con herramientas y controles a medida"
Creo que la comparación con GeneXus le queda un poco grande, un framework, como dices, puede darte productividad, calidad, excelencia, en particular ambiente elegido. Pero qué pasa si por algún motivo vuestro cluiente necesita AS/400 RPG?, un ambiente sumamente lejos de lo corriente, o si por el contrario exige un ambiente creciente de aplicaciones mundiales e incluso dominante en forma creciente en la omnipresente web como lo es Linux? (allí GeneXus llega con Ruby, Java, MySQL, PostgresSQL, etc.) o si por ejemplo, deben pasar a aplicaciones mobiles, en Pocket-PC, y ahora en los nuevos y crecientes paradigmas como los son las aplicaciones en los nuevos dispositivos móbiles omnipresentes con sus nuevos Linux, como Maemo (http://bit.ly/GxMaemo) desarrollado por NOKIA, o Android (http://bit.ly/GxAndroid) desarrollado por GOOGLE, y así me pregunto que harás con el framework desarrollado en C#?... . Claro, que seguramente puedas migrarlo, por usar el proyecto MONO, pero aún así, creo que no estarías teniendo en cuenta la primera premisa que nos planteamos los que hemos elegido a GeneXus, "Preocuparnos del desarrollo de la Aplicacion, de nuestro conocimiento" y dejar en manos de GeneXus, que nos lleve a la última tecnología y seguimos satisfechos con tal elección, no digo conformes, uno no es de conformase fácil, cuando busca la excelencia, pero igual, te cuento, en 1990-1992, participé en el desarrollo de un "framework" en mi empresa, salvo que dicho desarrollos servía para, xBase, prototipabamos en dBase III+, compilabamos con Clipper '87, luego habíamos ya sufrido un par de migraciones, usábamos una herramienta administradora de Forms Saywhat!, aplicaciones sobre NOVELL Netware, intentábamos hacer applicaciones con Database Server como Advantage DBMS, Ya no uso ese framework, que quede claro, teníamos dudas sobre si no era mejor opción Paradox, de Borland, que dominaba el mercado de Bases de Datos en MS-DOS, dBase IV, fue un fracaso que llevó a quebrar a Ashton-Tate y luego a Borland, había aparecido Windows y algunos empezaban a considerar ese ambiente tan precario que ofrecía Windows 3.1, más tarde CA-Visual Object quizo rescatar a los desarrolladores de Clipper fracasando rotundamente, Access, fue en el comienzo la primera acción de Microsoft, que luego coronó con un innovador Visual Basic, el primer lenguaje Visual & event-driven exitoso en el mundo (DOS-Windows) de ventanas y ratón. En fin, muchisimas opciones, que como sabemos, muy pocas sobreviven en nuestros días, en el año 1992-1993 descubrí GeneXus 3.0 para DOS, y a pesar de todas las críticas que yo mismo le hacía, las ventajas eran por lejos muy superiores a sus desventajas, y nuestro esfuerzo de hacer nuestra herramienta de generación o framerwork, quedó abandonado y así fue que pronto GeneXus nos llevo del mundo DOS, al Windows -habíamos pensado hacer cosas en Windows, y estabamos estudiando como-, después nos sorprendio con JAVA, Internet, también AS/400 sin mayor esfuerzo que saber GeneXus, y algún trabajo de configuración... . Recuerdo que en el 2000, apenas se había liberado C#, y ya GeneXus tenía su generador para C#, cuando muy pocos sabían programar en ese prometedor lenguaje... . Y así, hemos ido superando los paradigmas uno a uno, y podemos mover nuestra aplicaciones a los nuevos mundos de desarrollo... . Perdonen la perorata, yo sólo quería decir, que de alguna manera uno siempre depende de muchas cosas, no existe la independencia absoluta, pero el "framework" que han desarrollado en tu empresa, quizá tenga mucho futuro no solo para Uds. sino para otros desarrolladores, y me gustaría conocerlo... . Aún así, supongo que tiene mucho camino que recorrer para ser comparable a GeneXus. Saludos, gab.
Creo que no es posible comparar el desarrollo en serio con Java y el andar mariconeando con Genexus. Esto de Genexus es para gay, te metes con genexus y te sientan por el resto de tu vida. Ya no quedan programadores como los de antes. Los sistemitas con genexus son un asco. Si seguimos asi, al final tendremos un monton de giles hablando y hablando de genexus y sin saber que carajo hay abajo. Locos dejen de darles de comer a Genexus.
ResponderBorrarAnonimo:
ResponderBorrarPorque decis que no es posible comparar el desarrollo en Java con el desarrollo en GeneXus?.
Es verdad que quedan pocos programadores como los de antes, pues antes programabamos en Assembler, Cobol y Fortran y cada vez quedan menos personas que programen en eso.
Enrique
Anónimo,
ResponderBorrarTus convicciones acerca del caracter de los que programamos con GeneXus, y de la calidad de los programas están bastante lejos de la realidad. Tu fundamentación "ad hominen" nos indica acerca de que no podemos tomarte muy en serio, por un lado, y por otro parece que terminás diciendo de ti bastantes cosas a pesar de tu anonimia: 1) Un tipo muy poco flexible 2) Limitado de pensamiento 3) Discriminatorio, y por último cobare... muy gracioso no?.
Pensar diferente a ti, ya me da felicidad. Seguiré con GeneXus.
Saludos,
gab
Jejej, mi dios querido.. las cosas que uno lee.
ResponderBorrarAnónimo: programar es de flojo, laburo duros son estos:
http://tiny.cc/uaJ3Q
salu2, otro anónimo
el link era este:
ResponderBorrarhttp://tiny.cc/vCA8V ...
no podremos los hombres hacer las 2 cosas a la vez? programar y hacer esto?
La comparación é muy interesante.
ResponderBorrarFaltó comentar que Genexus no és un producto estable y que tiene muchos errores.
Jose Garrido:
ResponderBorrarHas tenido errores que te han dificulado el desarrollo?. Mi experiencia es que hemos tenido bastante menos errores en las ultimas versiones, pero la situacion puede ser muy diferente, para las diferentes plataformas o generadores.
Bueno creo que el framework que hemos desarrollado, obviamente no se compara con el alcance que tiene GX, pero es que no es ese el punto...
ResponderBorrarSi algo esta bien desarrollado, a nosotros no nos costará demasiado adaptarlo a los nuevos lenguajes o plataformas, ya que Microsoft seguramente seguirá basandose en .NET, es algo MUY distinto a VB6 o FoxPro que, a mi modo de ver, eran casi juguetes que se usaban para hacer programas, y si lo abandona, tendremos el Know How suficiente para cambiar de plataforma, debido a esta experiencia, buen diseño y que las plataformas y lenguajes OO no difieren en tanto.
Pero a lo que iba, es que siempre es mejor saber que ignorar, y con Genexus tenderemos a lograr lo ultimo. A mi, y a mucha gente, si debemos realizar una interoperacion con GNU/Linux, y debieramos desarrollar ese componente, CON GUSTO LO ESTUDIARIA Y DESARROLLARIA (disfrutamos con el aprendizaje y no nos cuesta tanto al estar "metidos" en esto). Yo domino muchos lenguajes y tecnologias actuales y siempre tratamos de estar a la vanguardia de los desarrollos, no solo para windows. (ademas creo q Windows Presentation Foundation, Communication Foundation y EntityFramework creo que todavia ni asoman por Genexus) y antes de que digan que es costoso y dificil y etc, yo creo que si genexus lo puede "generar" entonces es porque no lo es tanto.
He visto muchas aplicaciones generadas con Genexus y la verdad, TODAS se veian muy "antiguas", sin respeto por estandares y funcionaban como clones una de otra. No creo que sea porque GX no permita personalizarlas, pero sino por esta tendencia a IGNORAR que genera (como en el caso de CSS que comentaban arriba).
Por ultimo, la tendencia actual nos lleva a una orientacion a servicios y aplicaciones distribuidas, algo que facilita enormemente la comunicacion entre arquitecturas y SOs y no creo que Gx sea una bala de plata para solucionar este tema. En fin, GX creo que tiene su nicho, pero es muy reducido y no puede abarcar la magnitud a la que se enfrenta hoy por hoy el desarrollo de software, que es amplisimo. Y sino hagamos algo simple, busquemos en Google Trends el uso de Genexus y lo comparemos con el de cualquier otra plataforma...
Agustin:
ResponderBorrarNo dudo que el desarrollo de un framework para tu aplicacion, es una buena salida tecnica. Lo que a mi me gusta evaluar, es que costo tiene eso, para desarrollarlo para cada plataforma nueva que va saliendo y es solicitada por los usuarios.
Vos decis que a ustedes no les costara demasiado. Es ese costo el que hay que evaluar en las migracion
No estoy de acuerdo que con Genexus se tienda a ignorar. Lo que si es cierto es que esconde bastante complejidades lo que hace que las personas puedan tener mas conocimiento funcionales y no sea indispensable tanto conocimiento tecnico.
Esto que puede verse como una gran ventaja, algunas personas lo ven como una limitante, pues los analistas genexus no tienen conocimiento de detalles profundos de la plataforma.
Me da la sensacion que esto va a irse modificando con el tiempo y van a aparecer cada vez herramientas con mayor nivel de abstraccion, que van a alejar a los programadores de los detalles de mas bajo nivel.
En cuanto a lo que decis de WPF, WCF, EntityFramework, ya tenemos web services con WCF, no hay nada de WPF y creo que la solucion que se tiene en GX es mejor que la que tienen MS con el EntityFramework.
Tu dices que has visto aplicaciones GX y que son todas muy viejas y feas. No dudo que pueda ser asi.
Tambien se pueden hacer malas aplicaciones con java o .NET.
El tema es si se pueden hacer aplicaciones buenas.
Tambien hay que ver que determinadas aplicaciones no necesitan ser "modernas" para ser utiles y funcionales.
Como tambien dices en tu comentario
GeneXus NO ES una bala de plata y es una herramienta de nicho, que aun no se compara con lenguajes y plataformas de uso general como .net y java.
Mi post, es para hacer una comparacion de un caso real al cual pude acceder y conocer de cerca, que me parece que aporta a la discusion del tema y para comparar metodologias. Como tu dices, solo funciona para algunos grupos y tipos de aplicaciones.
Gracias por el comentario.
Tengo muchísimos años programando y gerenciando proyectos en Java. Hace unas semanas tomé un curso de Genexus EV 1 y me pareció una herramienta realmente buena. Creo realmente que no debemos comparar Gx con Java porque es comparar peras con manzanas. Java es un lenguaje de programación, Gx es una herramienta CASE. En lo personal me parece que la metodología orientada al conocimiento de Gx eventualmente será dominante en el mercado y se harán herramientas CASE similares.
ResponderBorraryamirito:
ResponderBorrarCreo que es necesario GeneXus con herramientas como Eclipse y Visual Studio porque es lo que deben definir las empresas que desarrollan.
Discutir que es una herramienta CASE y que no, es algo medio complicado, pero coincido con tu comentario que vamos a tener mas herramientas "parecidas" a GeneXus en el futuro.
Como mi comparacion pretendi mostrar la evolucion de una aplicacion durante un periodo largo, con diferentes herramientas, donde si creo que la comparacion es valida.
gracias genexus, fui despedido porque no recompilas o haces lo que se te pega la gana, realmente intente hacer todo bien, y ahora estoy exiliado del grupo de programadores, todo gracias a su inteligencia artificial para generar sistemas supuestamente estables!
ResponderBorrarEstoy de acuerdo con Agustin Meriles, yo trabajo hace 13 años en desarrollo de software y todos en la empresa opinan que genexus no puede superar un buen framework propio. Las aplicaciones resultantes son extremadamente fácil de mantener y rapidamente implementables. Y tenes y conoces todo el codigo desde la primera a la ultima línea. Estoy hablando de software con 500 o mas usuarios concurrentes y en plataformas clusterizadas. Con genexus al final las cosas complicadas las tenes que resolver por afuera y al final te queda una mezcla genexus con algún otro lenguaje que hace lo que genexus no te puede dar. Reconozco que para sistemas de mediano porte y siempre del tipo programas de gestion que se piden datos, hacen reportes, etc contra una rdbms. Hay otro tipo de software en el mundo !!
ResponderBorrarUna duda parecería que el colega almeida es fánatico de genexus. Será Revendedor ?
PD: Ya tiraste la Packard Bell o la guardaste de recuerdo ?
Anonimo:
ResponderBorrarEntiendo que para varias aplicaciones GeneXus no se ajuste a tus necesidaes.
No soy fanatico de GeneXus, sino que lo uso para desarrollar aplicaciones, pues nos ha dado buenos resultados. El dia que encuentre una herramienta mejor para desarrollar grandes sistemas, por periodos largos de tiempo, vamos a hacer una migracion a dicha herramienta. Lo que ha pasado es que no la hemos encontrado.
El problema que veo del desarrollo de un framework propio, es que muchas veces no es facil migrarlos de plataformas a medida que pasa el tiempo. Conozco gente que tenia herramientas para vb 6 y tuvieron que regenerarlas para generar .NET y les salio carisimo.
El que la mayoria de los desarrolladores del mundo usen herramientas como Eclipse y Visual Studio, nos da una ventaja grande en el largo plazo pues somos mas productivos con GeneXus y por lo tanto nuestra solucion es mas competitiva.
No soy revendedor de GeneXus, aunque no me importaria serlo, pero no me considero capacitado para venderlo.
No entendi lo de Packard Bell.
Hola Muy Buenas Noches yo no tengo un gran Conocimieneto de programacion yo solo se como el 80% en Access y un poco visual basic. yo si entiendo el tema de es post si se ahorra vastante en migracion con genexus, con respecto a GeneXus, e visto aplicacion hechos y son bien completos estoy de acuerdo en un comentario que dicen que la apariencia es muy vieja y fea pero en mi opinion no me inporta la apariencia sino la efectividad que me de la aplicacion en procesos, donde yo trabajo es una empresa que tiene en Centroamerica vastantes regionales y usan una aplicacion hecha en Genexus y SQL Server 2008, no se que version de Genexus este hecho pero este empresa lo usa desde 1997 y estamos 2012 son casi ya 15 añso y funciona todo bien lo unico que pusieran es un programa hecho en Visual foxpro para procesos que no tiene el programa, lo icieron porque el programador que lo avia hecho en Genexus ya no lavora en esta empresa soy de Honduras y aqui no se escucha muchos de Genexus pero para que la empresa no cambiara de sistema quiere decir que funciona bien este programa es casi de la misma nivel de SAP Business One 2007 eso si SAP Business One 2007 es mucho mas completo pero la diferencia es como 70% a 100% yo consigue una copia de Genexus 9.0 y quisiera aprender me an dicho que es muy facil no saven donde puedo hayar Videostutoriales para aprender.
ResponderBorrarIrwing,
ResponderBorrarPodes encontrar vídeos de como usar Genexus en training.genexus.com
La idea de Genexus es buena pero su inteligencia no es tan buena, le falta mas neuronas, codigo redundante, soluciones no adecuadas. Pero si creo que a futuro se usaran mas herramientas de ese tipo para ahorras tiempo de desarrollo.
ResponderBorrarYo creo que GeneXus tiene 10 para proyectos muy simples donde no es requerido una interfaz pulida. En pocas palabras es GeneXus es un producto que promete mucho...si pero para proyectos muy básicos.
ResponderBorrarRespecto al tema de los problemas al que se enfrentó el equipo 3 estos no corresponden a las herramientas o al lenguaje sino que estás demostrando que dicho equipo no tiene la capacidad suficiente para hacer software de calidad.
Hola amigos
ResponderBorrarDe casualidad me tope con este artículo y los comentarios que se hacen desde varios ángulos, todos ellos interesantes, desde mi modesto punto de vistas todos tienen sentido y razón por la realidad y momento en que se presentaron. Les voy a comentar una experiencia real con Gx desde el año 1990 aproximadamente - las fechas que les voy mencionar van a ser referenciales dado que estoy confiando en mi memoria de "elefante".
La experiencia esta ubicada en el siguiente contexto:
-----------------------------------------------------
- Año 1990
- Tipo de empresa Textil
- Tecnología usada: Hardware: As/400 lenguaje de programación: RPG III
- Topología de red: Estrella para el As/400 y Bus para las las Pc´s (Ethernet recién estaba tomando fuerza en el
mercado).
- Sistema operativo: Os/400 y Novell 2.10 (Aún no salia el windows NT)
- Metodología de desarrollo: Programación tradicional (manual).
Problemas enfrentados por el área de sistemas:
- Alta rotación de personal
- Insatisfacción de los usuarios por los servicios del área de informática
- Avance nulo con nuevos proyectos
- Mantenimiento continuo de las aplicaciones heredadas
Problemas externos de realidad país
- Hiperinflación.
- Incremento de costos de tecnología IBM
Retos del área de informática - 1990
- Bajar los costos de tecnología del área de sistemas - alternativas redes de Pc's (Gran decisión para esos tiempos.
- Cambiar a lenguajes de programación de Pc´s - Clipper con Dbf´s (Una locura bajar de un sistema robusto a un "Juguete" de Pc´s )
- Atender a los usuarios de planta todo era manual en la planta.
Continua....
Continuación...
ResponderBorrarLo que experimentamos con Gx:
------------------------------
Así como encontré este artículo de casualidad encontramos Gx 2.0 que corría en DOS y generaba aplicaciones para Clipper, RPG y Cobol nos contactamos con el distribuidor se hicieron algunas pruebas desarrollando una aplicación pequeña en clipper en una semana que era un tiempo bastante bueno a mano esa aplicación pequeña nos hubiera tomado unos 3 meses en RPG, decidimos embarcarnos con Gx y desarrollamos las aplicaciones para las áreas de tintorería y parte de tejeduría para ello se ampliaron las redes de Pc's, todo bien en cuanto al desarrollo de las aplicaciones pero apareció un gran problema los indices de las bases de datos se corrompían bueno este problema era de la "BD" del Clipper pedimos a Artech nos de alguna alternativa de solución para ese tiempo habían sacado el generador de FoxPro que según decían su "BD" era mas fuerte que la de clipper, nos dieron el generador y migramos nuestras aplicaciones a FoxPro lo que nos alivio en algo el problema, continuamos avanzando terminamos el sistema de tejeduría nuestra data seguía creciendo la "BD" de FoxPro estaba reventando pedimos nuevamente a Artech alguna solución nos contestaron que regresemos al As/400 Ups! mil veces Ups!, felizmente IBM comenzó a mejorar sus precios del As/400 por lo que optamos por la compra de uno de estos equipos, el gran reto: migrar todo lo que habíamos echo a RPG y DB2, se invirtió 3 meses en esta migración (de programas y Base de datos con las pruebas respectivas)luego de ello continuamos trabajando tranquilos.
Al tiempo salio la versión de Gx para windows nosotros continuamos con la versión DOS esperando que madure la nueva versión, recién cambiamos de versión de Gx cuando estaba en la versión 5.X lo que nos permitió hacer interfaces gráficas de nuestras aplicaciones posteriormente saltamos a la versión 7,8 lo que nos permitió hacer aplicaciones de BI
dado que recién con estos generadores podíamos leer y escribir en BD diferentes en este caso era leer DB2 y escribir en SQL que era nuestro repositorio de datos para el BI.
Uno de los proyectos que desarrollamos y me pareció espectacular fue el desarrollo de un sistema que trae la información de los telares (Máquinas de planta que sirven para tejer tela)los deposita en la base de datos y a partir de ahí las aplicaciones Gx toman el control y muestran la información a los usuarios tal como ellos la entienden, esta es una aplicación un poquito diferente a las que se hacen con Gx, la diferencia esta en que hicimos conversar las aplicaciones de Gx con unos dispositivos de planta llamados PLC´s que en buena cuenta son Pc´s que trabajan conectados a máquinas industriales capturan la data de las máquinas en forma de señales eléctricas y las transforman a data que conocen las Pc´s convencionales.
Resumiendo:
-------------
- Se ha pasado por diferentes escenarios a nivel país/empresa y Gx a permitido movernos de una a otra plataforma en el tiempo y combinar tecnologías para sumar y dar el producto que necesita la empresa.
Espero sirva en algo esta experiencia para que miren desde otro angulo a Gx, que en lo personal al inicio a mi me costo mucho cambiar de manera de pensar en cuanto a la programación manual y al desarrollo con Gx pero los resultados son los que hablan por si solos.
Saludos a todos
Carlos Benites
mail: carlosorlando2001@hotmail.com
Muy interesante tu experiencia Carlos Bonitos, y actualmente con que tecnologías usas Gx Carlos Banitas.
ResponderBorrar