Un problema notable del desarrollo Java Empresarial es su inherente complejidad. Tanto si usamos el estándar JavaEE como Spring, nuestros equipos de desarrollo nunca serán tan productivos como los de VisualBasic, PHP, RubyOnRails, 4GL e incluso COBOL. La complejidad del Java Empresarial requiere de desarrolladores expertos, y además éstos han de escribir bastante código.
La solución ideal para esto problema podría ser el Desarrollo Dirigido por el Modelo (MDD). Básicamente MDD establece que únicamente la parte modelo de la aplicación se ha de desarrollar, y el resto de la aplicación se generará desde este modelo. De esta forma, el desarrollador escribe menos código y además más simple, y aun así seguimos obteniendo una potente aplicación empresarial Java.
Sin embargo, de momento, el uso de MDD es todavía demasiado complejo. Es necesario una gran inversión de tiempo, pericia y herramientas; usualmente construyendo nuestro propio DSL y combinándolo con una factoría de software, y esto supone bastante esfuerzo. Por lo tanto, solo las grandes compañías pueden acometer MDD, y esto solo se amortiza cuando se usa varias veces en diferentes proyectos. Y, por supuesto, MDD es una alternativa generalmente fuera del alcance de las PYMEs.
Afortunadamente, podemos disfrutar de las bondades de MDD sin sus dolores. Simplemente hemos de eliminar MDA, DSLs, UML y la generación de código de MDD y así obtendremos una forma simple y efectiva de hacer Desarrollo Dirigido por el Modelo.
El libro blanco Better Software with Less Code explica como hacer Desarrollo Dirigido por el Modelo de una forma liviana, para que sea asequible para las empresas medianas y pequeñas, y más barato para las grandes.
No habia escuchado MDD? algún sitio donde se pueda obtener mas informacion al respecto?
Si bien estoy siempre abierto a estudiar todo aquello que permita realizar la labor de desarrollo de una aplicación (en todas o cualquiera de sus fases) de una forma más sencilla y/o rápida, lo cierto es que hasta ahora no conozco ninguna máquina que procese diagramas UML ni de ningún otro tipo, por ello me empeño en que se dedique tiempo, esfuerzo y personal lo más cualificado posible a cada una de las fases, incluyendo la de picar código.
La verdad es que no estoy nada de acuerdo con lo primer parrafo, dices:
"Un problema notable del desarrollo Java Empresarial es su inherente complejidad"
En mi opinión lo que es complejo es desarrollar software, y si el software que tenemos que desarrollar además tiene unos requisitos complejos en cuanto a escalabilidad, extensibilidad, mantenibilidad etc, etc pues más complejo todavía. No es que el desarrollo con JEE sea complejo, es que desarrollar software complejo es complejo! (se que suena de perogrullo, pero en mi experiencia no todo el mundo tiene esto muy claro).
Siempre que leo algo así sobre la supuesta productividad (palabra totalmente sobrevalorada, mucho habría que discutir sobre que es y que no es productividad) de tecnologias tipo vb, 4gl o similares me acuerdo de una frase que lei hace tiempo "El desarrollo con Visual Basic facilita el 90% del desarrollo a costa de hacer imposible el 10% restante" (se referia a vb5 o 6, antes de .net vamos). Me encanta esta frase porque lo he visto muchas veces, tecnologías con las que te montas un CRUD en tres minutos hasta con el desarrollador más inexperto, pero que luego en cuanto empiezan a surgir los primeros requisitos que se alejan del CRUD y no hay un checkbox para que la herramienta lo haga solo en el wizard de turno empiezan los verdaderos problemas. A costa de en muchos casos una falsa sensación de productividad pierdes una flexibilidad que al final termina siendo necesaria.
Eso sin hablar del más que habitual codigo spaghetti intratable e inmantenible que termina generandose en proyectos donde se utilizan herramientas de este estilo, y cuidado que la culpa no suele ser de las herramientas sino del enfoque "programar es facil con tal o cual herramienta que te lo da todo hecho" donde se ponen a cuatro programadores inexpertos para un proyecto que inicialmente "son dos tonterias" y que luego se termina complicando y complicando, parcheando y parcheando hasta convertirse en una madeja que no hay quien la mantenga.
No quiero decir con esto que tengamos que programar en ensamblador claro esta, pero que tenemos que ser conscientes de que para hacer un trabajo complejo se necesitan unos conocimientos solidos de diseño, programación, ingeniería del software etc,etc, y que esto no lo suple ninguna herramienta ni ninguna metodología magica.
no se si MDD será la resuesta, a mi personalmente no me convence en abosluto, lo que si tengo claro es que en el estado actual del desarrollo de software no existe ninguna herramienta, framework o similar que pueda hacer que desarrollares inexpertos desarrollen software complejo, y creo firmemente que si muchas empresas aceptaran esta realidad se resolverian muchos más problemas que con ningún framework RAD, MDD o DSL's variopintos.
@Remoh "El desarrollo con Visual Basic facilita el 90% del desarrollo a costa de hacer imposible el 10% restante"
Mi experiencia de bastantes años en VB fué que excepto por un tema parecido al "Class.forName("").newInstance()", en VB pude hacer todo lo que quise y si algo no se podía hacer, entonces hacía una llamadita al API de Windows y problema solucionado (No creo que fuera tan dramático que ya somos mayorcitos).Aun me acuerdo como manejava los servicios de Windows desde VB usando el API. Además tengo que decir que nunca usé un wizard.
Otro ejemplo era el de los Interfaces de VB, por aquel entonces nadie sabía lo que eran pq todos estaban acostumbrados a la herencia de C++.Así que ponían a caldo a VB por no tener herencia y tener esa "mierda" de interfaces. Han pasado 10 años y ahora todos estamos cansados de oir que "hay que programar para interfaces y no para clases".Por suerte yo esa lección la tuve muy bien aprendida gracias a VB.
El problema de VB fué que cualquier chapuzas podía hacer aplicaciones y se asoció VB a programas hechos por esos chapuceros. Pero en VB había malos programadores que hacían aplicaciones inmantenibles y había buenos programadores que hacían aplicaciones mantenibles.
@javierpaniza: "Tanto si usamos el estándar JavaEE como Spring, nuestros equipos de desarrollo nunca serán tan productivos como los de VisualBasic, PHP, RubyOnRails, 4GL e incluso COBOL"
Eso se aregla usando el framework adecuado a tus necesidades que no tiene pq ser siempre MDD. De hecho el framework que me hecho en Java es una copia del que usaba en VB y ahora soy tan productivo en Java como en VB.
PD: Lo importante en los proyectos no son las herramientas sino las personas. Un buen equipo en Java será mas productivo que un mal equipo en VB y viceversa.
Saludos.
nuestros equipos de desarrollo nunca serán tan productivos como los de VisualBasic, PHP, RubyOnRails, 4GL e incluso COBOL
Disiento. Comparar peras con manzanas nunca lleva a ninguna conclusión realmente útil. :)
En cuanto al problema principal, yo estoy con remoh. La cuestión básica es que le pedimos peras al olmo y queremos que programar cosas complejas sea sencillo, que programadores inexpertos hagan aplicaciones empresariales como quien hace una tostada, que nuestras aplicaciones sean sencillas pero escalables hasta el infinito sin tocar nada, que los programas distribuidos funciones como programas locales... etc. etc. Pero vaya, se ve que la realidad es bastante tozuda y no da su brazo a torcer.
@greeneyed: "Comparar peras con manzanas nunca lleva a ninguna conclusión realmente útil".
¿Porque dices eso?¿No se puede comparar lo que se tarda en hacer una aplicación Cliente-Servidor usando Java o VB? Lo que sería menos util sería comparar aplicaciones Web contra Cliente-Servidor porque tienen requerimientos distintos y obviamente saldrían productividades poco comparables.
@greeneyed: "que programadores inexpertos hagan aplicaciones empresariales"
No es necesario que hagan una aplicación entera pero una aplicación empresarial está llena de pantallas de mantenimiento relativamente sencillas. Ese tipo de pantallas si que debería poder hacerla un programasdor inexperto si le damos las directrices de como hacerlo.
En una fabrica de coches el trabajador más inepto puede ayudar a fabricar un coche, siempre y cuando le demos las directrices exactas de su trabajo. Lo que no vamos a pretender es que nos diseñe el coche o la fabrica. Lo mismo pasa con el software. Desarrollar software debe dia a dia ser un proceso menos "creativo" y mas "repetivivo". Usar personal cualificado para la parte "creativa" y para la parte "repetitiva" usar gente poco cualificada. Y eso no hace que se baje la calidad del programa.
Hola javierpaniza,
no se si la pregunta es indiscreta, pero en tu empresa cuando usais OpenXava,¿Todo el personal está altamente cualificado o para tareas mas repetivivas como puedan ser mantenimientos usais programadores de un perfil mucho más bajo explicandoles claramente las reglas de OpenXava?
Saludos.
Hola Anonimo,
"No habia escuchado MDD? algún sitio donde se pueda obtener mas informacion al respecto?"
Bajate el WhitePaper, tiene algunas referencias que te pueden ser útiles.
Hola Peyrona,
"no conozco ninguna máquina que procese diagramas UML"
A lo mejor no he entendido bien el comentario, pero MDA es justo para eso.
Yo me acuerdo que antes de que existiera esto de MDA trabajé durante un tiempo de la siguiente forma: Dibujaba mi clases del dominio con TogetherJ, las exportaba a XMI, y desde VisualAge importaba el XMI a EntityBeans v1.0. Trabajaba así porque era la forma más rápida de escribir código EJB con EntityBeans en aquel momento.
¿No es esto procesar diagramas UML?
Hola Remoh,
"En mi opinión lo que es complejo es desarrollar software, y si el software que tenemos que desarrollar además tiene unos requisitos complejos en cuanto a escalabilidad, extensibilidad, mantenibilidad etc, etc "
Totalmente de acuerdo, así que no voy a discutir contigo. Cuando Brooks dijo eso que tu acabas de decir diferenció entre esencia y accidente. Digamos que tu hablas de la esencia, y yo me refería al "accidente", que de eso en el Java Empresarial hay demasiado. Se trata de que escribir algo con lógica sencilla sea sencillo, y por supuesto si la lógica es complicada, como seguro que llega a ser si la aplicación no es trivial, será complicado. Pero ha de ser la complejidad de tu aplicación lo que añade complicación no la tecnología.
Hola Longogas,
"PD: Lo importante en los proyectos no son las herramientas sino las personas. Un buen equipo en Java será mas productivo que un mal equipo en VB y viceversa."
Totalmente de acuerdo. De hecho, se hizo un experimento llamado "guerra de código" que consiguió demostrar lo que tu has dicho. De esto se habla en uno de mis libros favoritos: Peopleware.
@javierpaniza
Hola de nuevo Javier.
Como he dicho, de verdad que estoy siempre interesado en cualquier cosa que facilite/mejore el de desarrollo de aplicaciones.
Por otro lado, no conozco MDA ni MDD, pero hasta donde sé, no hay nada que ejecute diagramas UML: claro que puedes generar código (Java p.ej.) a partir de un diagrama UML de clases, pero eso dista muchísimo de ser una aplicación, vamos que si la compilas y ejecutas aquello "no hace nada"; porque hay que "rellenar" todos los métodos.
Y si bien se están haciendo muchos avances, todavía hay un trabajo de "bajo nivel" que hacer. Lo que denuncio es que (en general) a este trabajo no se le dedican recursos del mismo nivel ni experiencia que al de hacer los diagramas y que ese es uno de los mayores problemas que tiene el software que producimos especialmente en España: su pésima calidad de implementación. Salvando claro está, todas esas honrrosas excepciones.
Hola Longogas,
"¿Todo el personal está altamente cualificado o para tareas mas repetivivas como puedan ser mantenimientos usais programadores de un perfil mucho más bajo explicandoles claramente las reglas de OpenXava?"
Todos los programadores que entran tienen un perfil bajo, normalmente ni siquieran saben Java. Y empiezan a desarrollar las partes más sencillas (mantenimientos y listados) de las aplicaciones de inmediato. Con el tiempo, a medida que aprenden no solo más Java, sino también más sobre la lógica de negocio de su aplicación, van haciendo cosas más complicadas.
Lo bueno de OpenXava es que desde el primer día ya hacen cosas y ven el resultado; ya tendrán tiempo para aprender, pero mientras tanto ya están hacen cosas útiles.
Hola Peyrona,
"pero hasta donde sé, no hay nada que ejecute diagramas UML"
Al menos existe algo con ese nombre: UML ejecutable. Aunque yo estoy muy a favor de UML, de hecho, si te has leido el White Paper, mi sugerencia es eliminarlo
"generar código (Java p.ej.) a partir de un diagrama UML de clases, pero eso dista muchísimo de ser una aplicación"
Creo que subestimas a donde puede llegar el ser humano. Prueba AndroMDA o OpenMDX. Aunque yo no soy partidario de MDA.
"hay un trabajo de "bajo nivel" que hacer"
Eso está bien. Lo que no está bien es que casi todo sea trabajo de "bajo nivel".
Con OpenXava tratamos de que casi todo el trabajo de "bajo nivel" esté dentro de OpenXava y no en la aplicación. Si el programador de la aplicación tiene la suficiente pericia puede hacer un esfuerzo para mover su código de "bajo nivel" a OpenXava, y convertirlo en algo reutilizable.
El debate que propone Javier no va en la línea VisualBasic vs Java.
El artículo (sí me lo he leído os lo juro) va más en la línea de aumentar la productividad utilizando herramientas Lightweight Modeling Driven (LMD), como Javier lo llama, tipo OpenXava, respecto a la técnica general o Model Driven Architecture (MDA) estandarizada por la OMG.
Lo del Visual Basic, RubyOnRails era una excusa para encender el debate (y desde luego lo ha encendido), pero el artículo va más en la línea:
1) LMD vs MDA
2) LMD vs desarrollo habitual Java (tipo MVC, Spring, JavaEE y demás sabores)
Mi posición en este asunto es que depende de para qué queremos las cosas, en qué contexto estamos, qué requisitos tenemos, en qué tipo de mundo vivimos...
Respecto al asunto 1) LMD vs MDA, hasta donde conozco el mundo MDA (la teoría sí pero concreto muy poco), coincido casi plenamente con Javier (el casi es porque quizás haya gente a los que el MDA les va bien y tengan poderosas razones), el MDA es tan ambicioso que su supuesta gran mejora de productividad está cuestionada.
De todas formas Javier eres muy injusto con la MDA, la MDA es MUY ambiciosa pues pretende ser multiplataforma y multitecnología, es decir un sólo modelo => múltiples plataformas y tecnologías. En el caso de OpenXava es unica plataforma y dentro de esa plataforma usa herramientas muy concretas (Java, AJAX web, JPA).
De todas formas estoy de acuerdo contigo, enfoques tipo OpenXava (y otros que tú mismo sueles citar como NakedObjects, RomaFramework etc) siendo mucho menos ambiciosos son los que tienen más posibilidades de éxito en proyectos concretos.
Respecto al segundo punto 2) LMD vs desarrollo habitual, yo creo que tampoco eres justo en este tema, cada herramienta tiene sus pros y sus contras, y tú sabes que OpenXava está enfocado para aplicaciones de gestión internas en donde lo importante es la obtención rápida de una aplicación que simplemente funcione, aunque no se adapte totalmente a requisitos que se salgan de lo que ofrece OpenXava, y que no es apropiada para webs muy a medida (hoy día cualquier web es ya una aplicación) pues el trabajo de adaptación puede ser tan grande que los beneficios de productividad se perderían respecto a una solución convencional.
De la misma manera que yo no enfoco ItsNat a aplicaciones intensivas en efectos visuales y fastuosos componentes prediseñados orientados a deslumbrar al usuario pero que no funcionan en montones de navegadores y fastidian la vida al programador "que necesita otra cosa y no sabe como hacerlo".
logongas: y ahora todos estamos cansados de oir que "hay que programar para interfaces y no para clases"
No te me enfades, además la frase no es originalmente tuya, pero es en mi opinión una solemne tontería, es el tipo de conclusiones infantiles que se llegan cuando se abusa de algo, y ciertamente se abusó mucho de la herencia en los primeros tiempos de la orientación a objetos, se quería meter en el mismo árbol de herencia un montón de cosas hasta que se convertía dicho árbol en un monstruo forzado, por tanto la conclusión es "la herencia es mala". Es como cuando un niño rompe un cristal con la pelota, luego la pelota es mala, luego no volverás a jugar nunca más con la pelota.
Las interfases son para lo que son, una forma light de aplicar herencia múltiple y una forma de hacer diseño por contrato en donde se independiza la interface (el contrato) con la implementación. De ahí a concluir que cada clase tiene que tener una interface o que sólo hay que heredar de interfaces es llegar muy lejos.
En la parte de implementación de ItsNat (no la API pública que son todo interfaces) hay hoy día 520 clases (y 30 interfaces de uso interno), hay montones de herencias, pero como comprenderás las 520 clases no están obviamente en el mismo árbol de herencia (cosa que antiguamente se quería hacer).
La (estúpida) mala prensa de la herencia de clases tiene que ver mucho con lo que estamos hablando hoy, y es la tendencia antigua a los modelos inflados en donde al modelo de clases de datos se le añadía clases base de utilidad para la vista, para la persistencia etc por ello al final se evolucionó al MVC-P (P de persistencia, me refiero a DAOs y similares) para descargar el modelo de tanta parafernalia y aplicar una sana "separación de responsabilidades".
Hoy día parece que estamos volviendo al modelo inflado aunque con técnicas afortunadamente menos intrusivas que la herencia (dicese anotaciones).
Hay quien hasta le "mola" que una clase del modelo de datos herede de una clase "Record", pero en fin es lo que tienen las modas, ahora lo "viejuno" (como dicen en Muchachada Nui un programa de humor de la TV española) lo llamas "vintage" y parece otra cosa.
peyrona: que ese es uno de los mayores problemas que tiene el software que producimos especialmente en España: su pésima calidad de implementación. Salvando claro está, todas esas honrrosas excepciones.
Estoy contigo, lo de la división entre analista, arquitecto y programador tiene una motivación más clasista y de salarios que práctica, que quizás tenga algún sentido en equipos de 50 personas en un mismo proyecto (y que Dios les ampare). El infierno está en los detalles, el infierno está en el código, en los diagramitas sólo se ve el cielo. Alguna vez me planteo como se verían en un diagrama UML las 550 clases e interfaces de implementacióny las 178 interfaces públicas de ItsNat, quedaría bonito pero ni su padre (que soy yo) sería capaz de diseñar ese arbolito de una sola vez y decirle al programador "ale ahí lo tienes, prográmalo", es una absurda y pretenciosa utopía que dudo que en la práctica vaya más lejos del boceto inicial.
Hola, buenas. Me gustaría dar mi opinión sobre este tema, que me parece muy interesante - el tema, no mi opinión - :). Yo soy un defensor del MDD por varios motivos: Te permite generar código basado en patrones, tienes un código uniforme, se desarrolla más rápido, se tienen menos errores, etc...
A pesar de eso, MDD no es la panacea ni mucho menos. Estoy con remoh en que desarrollar software es complejo, hay partes mecánicas, que se pueden hacer con MDD y partes "artísticas" en las que hay que pensar. por regla general pienso que el código generado por las herramientas MDD no es fácilmente modificable si te sales de las líneas marcadas y esto se acentúa cuanto más general quieres hacer la herramienta. A más general, más parámetros a la herramienta, más complejo, menos versátil.
No creo en las dietas milagrosas, por eso yo soy partidario de los MDD... ¿personalizados?. No sé cómo llamarlo pero la idea sería algo así como: tener un programa para dibujar diagramas (¿DIA?), en el que puedas definir tus objetos, con sus dibujitos, sus propiedades, sus valores, sus asociaciones... exportarlo a, por ejemplo un xml, y por medio de tareas personalizadas (¿maven, ant...?) generar tu código a partir de ese xml por medio de algún lenguaje de script y algún lenguaje de plantillas (¿freemarker?). No es genérico pero... a uno le podría servir, generaría sólo código para tu "framework web", tu "framework ORM", tu...
Quizá las herramientas deberían enfocarse a ayudarte a crear tu MDD.
P.D.: Es cierto que AndroMDA tiene cartuchos y puedes personalizar muchas cosas pero... sinceramente me parece un tostón para aprender y ya a mi edad no puedo malgastar neuronas.jmarranz:"No te me enfades, además la frase no es originalmente tuya"
No te preocupes, no me enfado , pero no creo haber dado la impresión que la frase fuera mia.
Respecto a los interfaces y la herencia,no quería decir que uno fuera mejor que otro.En la época de VB se atacaba a VB por no tener herencia y tener esa cosa rara llamada interfaces y ahora los hemos puesto en un pedestal. Y simplemente lo que quiero es romper una lanza a favor de VB.
@jmarranz:"Las interfases son para lo que son, una forma light de aplicar herencia múltiple"
Los interfaces no son para tener herencia múltiple, se usan para eso por una limitación de Java al no haber permitido herencia múltiple de verdad.
@jmarranz:"Hay quien hasta le "mola" que una clase del modelo de datos herede de una clase "Record""
No se si era una indirecta, pero yo aun hago que mis clases del modelo de datos hereden de mi clase "Record" ;-)
Saludos.
PD:Ya me ha pasado unas cuantas veces que me pedís disculpas por discrepar conmigo.Criticar una opinión no debería molestar a nadie siempre que se haga con educación y de buena fe.
La verdad es que desde mi experiencia la teoria se aleja muchas veces de la realidad, las supuestas buenas practicas muchas veces lo unico que hacen es hacer complejas cosas que deberian ser simples. Por ejemplo, mucho se nos ha recomendado que en una aplicacion multicapas (dominio, vista, controladores, daos y servicios) los daos y servicios deberian ser interfaces con sus respectivas implementacion dependiendo del caso, para poder hacer cosas como: DaoPersona (interfaz) --> JpaDaoPersona (impl 1) HibernateDaoPersona (impl 2) o XmlDaoPersona (impl3). Pero yo jamas he necesitado hacer mas de una implementacion por esas interfaces, y me canse, ahora sigo un modelo mas ligero sin tantas complicaciones. Ahora mi DaoPersona es una clase concreta para lo que necesito y mi ServicioPersona tambien es una clase concreta.
La unica parte donde si que es necesario y se justifica el uso de interfaces es cuando necesito exportar servicios para invocaciones remotas o separar las vista y el controlador de lo servicios y daos en servidores diferentes. Los clientes NO necesitan y NO deben tener una implementacio. Obviamente hablo desde el punto de vista de una aplicacion empresarial, para otro tipo de aplicaciones como los frameworks las interfaces se justifican cuando quieres colocar puntos de extension o diferentes implementaciones dependiendo del caso de uso.
@Juankar: Quizá las herramientas deberían enfocarse a ayudarte a crear tu MDD.
Totalmente de acuerdo, y en mi caso con mi herramienta preferida (Netbeans IDE) cree un pequeño plugin que me muestra un Wizard para generar un CRUD que se ajusta a mi estilo y necesidades. Utilice el soporte de freemarker que trae el IDE para crear las plantillas y el soporte para crear wizards para enviarle los datos que necesito en esas plantillas, Tiempo de desarrollo: 4horas. De esa forma, me puedo concentrar en la parte artistica: implementar la logica de negocio en los servicios y crear vistas bonitas
¿Porque dices eso?¿No se puede comparar lo que se tarda en hacer una aplicación Cliente-Servidor usando Java o VB? Lo que sería menos util sería comparar aplicaciones Web contra Cliente-Servidor porque tienen requerimientos distintos y obviamente saldrían productividades poco comparables.
Claro que se puede comparar, de forma limitada, hacer aplicaciones cliente/servidor usando Java y VB, y aun así comparar una aplicación multi-plataforma con otra que solo se puede ejecutar en Windows ya da para desviaciones, pero la mayoría de gente cuando hace comparaciones Java vs VB son aplicaciones web vs cliente servidor, como lo son comparar PHP vs VB o similares.
OX es para hacer aplicaciones web, así que en este contexto esta claro de que tipo de comparativas estamos hablando.
No es necesario que hagan una aplicación entera pero una aplicación empresarial está llena de pantallas de mantenimiento relativamente sencillas. Ese tipo de pantallas si que debería poder hacerla un programasdor inexperto si le damos las directrices de como hacerlo...
En una fabrica de coches el trabajador más inepto puede ayudar a fabricar un coche, siempre y cuando le demos las directrices exactas de su trabajo. Lo que no vamos a pretender es que nos diseñe el coche o la fabrica. Lo mismo pasa con el software. Desarrollar software debe dia a dia ser un proceso menos "creativo" y mas "repetivivo". Usar personal cualificado para la parte "creativa" y para la parte "repetitiva" usar gente poco cualificada. Y eso no hace que se baje la calidad del programa.
Con todo el respeto por los animales, así como lo pintas daría lo mismo que esa parte la hiciera un mono, jejeje, pero no es eso a lo que me estoy refiriendo.
Me refiero a la cantidad de programadores hoy en día que "aparecen en los foros" con una presentación tal que "hola, no tengo ni p.i. de Java y tampoco de web pero me han encargado que haga una aplicación para mi empresa que pueda tener tantos accesos y use tales BDD, claro, yo he leido que si EJBs, que si Spring y todo estoy es muy complicado... ¿como hago para pintar una JTable en mi JSP?".
Y luego la culpa es de Java por que es muy complicado, por que "es obvio" que leyendo dos paginas de un tutorial por Internet, uno tendría que saber perfectamente hacer aplicaciones web, multiplataforma, usando patrones, con codigo reusable y que escalen hasta el inifinito y más alla.
Y yo he programado en VB y para lo que lo tenía que usar, me parecio estupendo. Así que no es "contra VB", es contra las comparaciones "estupidas" en las que se usa.
Lo del Visual Basic, RubyOnRails era una excusa para encender el debate (y desde luego lo ha encendido), pero el artículo va más en la línea:
Ahí le has dao y precisamente por eso lo he dicho yo. Empezar un artículo con semejante doblez es, IMHO, "periodismo barato" del que no puede salir más que calentar fugazmente el ambiente y es innecesario para promover las virtudes de OX, que van por otra linea.
Y por si todavía no ha quedado claro, no tengo nada en contra de VB, al contrario, ni de OX, si lo he empezado a usar y hasta he propuesto mejoras! Es sólo mi alergia a caer en el recurso fácil en las noticias para llamar la atención (con todo el cariño a javier ;) )
lolongas: En la época de VB se atacaba a VB por no tener herencia y tener esa cosa rara llamada interfaces y ahora los hemos puesto en un pedestal.
Yo jamás pondré VB <= 6 en un pedestal, la simple ausencia de herencia me invitó a estar lo más alejado del mismo, otra cosa es el actual VB.Net que es un sabor más de la plataforma "y el metalenguaje" .Net de forma similar a lo que ocurre en los lenguajes actuales JVM.
logongas: No se si era una indirecta, pero yo aun hago que mis clases del modelo de datos hereden de mi clase "Record" ;-)
Estaba pensando en RubyOnRails. Después de años de lucha para que la herencia sea algo normal en persistencia te da cierto cabreo que ahora sea lo moderno derivar de forma intrusiva en tu modelo de datos de una clase orientada a la persistencia, precisamente el camino contrario al que se ha estado trabajando durante años en múltiples ORMs (JDO, Hibernate, JPA...).
Hola José María,
"el artículo va más en la línea:1) LMD vs MDA"
Exacto
"Javier eres muy injusto con ... tampoco eres justo en este tema..."
¡Verdad, verdad! Pero si tienes un asador no te pones hablar de los beneficios de la comida vegetariana, más bien intentas que el olor de la carne a la brasa se huela a kilometros.
Hola Daniel,
"Es sólo mi alergia a caer en el recurso fácil en las noticias para llamar la atención"
No era mi intención. Estaba simplemente describiendo un hecho, que Java no es lo suficientemente productivo, para después empezar a hablar de las soluciones. Para mí la comparación de Java con otras tecnologías más tradicionales como VB, 4GL, COBOL, RPG, etc. es algo natural, porque trabajo en una empresa en que las misma aplicaciones se desarrollan con Java y con RPG en AS/400. Y ellos si que pueden comparar: ¿por qué en RPG esto cuesta un día y en Java 5 días? Entonces háblales de las 3 capas, la multiplataforma, multibase de datos, la interfaz web y todo lo que quieras, su mente está nublada, solo ven que cuesta 5 veces más.
La comparación de Java con VisualBasic la uso desde el principio de los tiempo, de hecho aparece en el FAQ oficial de OX.
Lo que veo es que algunas tecnologías nos atrapan emocionalmente, por eso simplemente citar un lenguaje o un marco de trabajo puede "calentar fugazmente el ambiente".
Recuerda, que soy un simple programador, yo sé programar, pero no sé como se promueve un marco de trabajo de código abierto. Así, que tengo dos opciones, no hacerlo o hacerlo mal. Y he optado por la segunda, espero que con el tiempo ese mal se convierta en regular.
Saludos.
Para Javier,
Recuerda, que soy un simple programador, yo sé programar, pero no sé como se promueve un marco de trabajo de código abierto. Así, que tengo dos opciones, no hacerlo o hacerlo mal. Y he optado por la segunda, espero que con el tiempo ese mal se convierta en regular.
Bueno, si te consideras un programador que hace un producto malo que con el tiempo se hace regular...
Entonces no te quiero hablar de la calidad de mi trabajo.
Respecto a los productos como VB, RPG, Ruby, 4GL etc, han sido concebidos para hacer las cosas de manera muy intuitiva, y los resultados se ven muy rápidamente, que llevan incorporado gran parte de las cosas que te hacen falta y que estan bien !documentadas! (hay un montón de referencias bibliográficas y tutoriales) y están muy bien acabados. Es decir han montado un escenario donde todo lo tienes a mano, y te mueves bien.
Respecto a Java, pues, si, en estos momentos estoy trabajando con Java y GWT, y la verdad, me está costando mucho mas de lo que esperaba el confeccionar las aplicaciones que tenia hechas con VB. Pero, también me sucede que he heredado un montón de vicios del VB, que me complican la vida, y me cuesta mucho desprenderme de ellos.
Pero también, hablamos de Java, pero Java es mucho mas, es un amplio ecosistema donde conviven un motón de subsistemas (Ant, Maven Hibernate, JSP, GWT, servlets, HTTP, XML, javaScript, navegadores, protocolos.....) por tanto, ya es un reto meterse en esto. Por tanto, la productividad parece ser pequeña porque tienes que torear muchos toros a la vez.
De todas formas, eres un gran referente en mi trabajo. Ánimos
Para jmarranz
Alguna vez me planteo como se verían en un diagrama UML las 550 clases e interfaces de implementacióny las 178 interfaces públicas de ItsNat, ...
Jose Maria, espero suponer que gran parte de esas 550 clases sean para definir wrappers para poder correr en cada navegador. Por desgracia, en muchos frameworks, cuando te hacen referencia a la API (cuando hay un número tan grande de clases) és como si te soltaran en medio de la jungla amazónica en una noche interminable, estás completamente perdido.
Yo sinceramente pienso que, si bien el UML a veces peca de ser demasiado pesadillo, no estaria mal que intentes documentar de alguna manera con distintos niveles de detalle como interactuan los distintos paquetes y sus respectivas clases.
Con lo de las 550 clases, me has dado un susto.., pero de ello se puede deducir tu capacidad de trabajo y lo que es mas importante, tu capacidad de orquestar toda esa biodiversidad de clases. La verdad es que sorprendes.
Como puedes ver, no me atrevo a hablar respecto a la calidad de tu trabajo (pues no tengo el nivel suficiente), solamente puedo hacer alguna referencia estadística (tus 550 clases puden desprender algún Ohhh! entre los seguidores de JavaHispano) y poca cosa mas puedo decir u opinar.
Como siempre, animarte a que nos ofrezcas estas intervenciones que dejan las cosas muy sentadas y de las que todos aprendemos mucho.
Animos.
Eduard
@jmarranz:"Yo jamás pondré VB <= 6 en un pedestal"
Me referia a poner en un pedestal a los interfaces no a VB. :-)
Y por cierto mi nick es "logongas" no "lolongas" :-)
@greeneyed:"Me refiero a la cantidad de programadores hoy en día que "aparecen en los foros" con una presentación tal que "hola, no tengo ni p.i. de Java y tampoco de web pero me han encargado que haga una aplicación para mi empresa que pueda tener tantos accesos y use tales BDD, claro, yo he leido que si EJBs, que si Spring y todo estoy es muy complicado... ¿como hago para pintar una JTable en mi JSP?"
Lo primero que hay que decir a esas personas es que su jefe es idiota aunque desgraciadamente eso ni ayuda ni se puede cambiar. Pero lo siguiente es decirles que programar es dificil, que programar en web es dificil, que hacerlo escalable es dificil,etc. Pero lo que yo propongo para esas persona es: ¿No hay software que me ayude a todo eso? Si, ya hay frameworks especializados como OpenXava que para un problema concreto han encontrado la solución y funciona. Así que no tienen mas que usarlo para evitarse todos los problemas.
Lo que pasa es que estamos acostumbrados a frameworks mas generalistas pero a su vez mas complejos como pueda ser Spring pero para la mayoría de los mortales quizas no necesiten tanta versatilidad sino restringirles a cambio de facilitarles la vida.
Saludos
Para mí la comparación de Java con otras tecnologías más tradicionales como VB, 4GL, COBOL, RPG, etc. es algo natural, porque trabajo en una empresa en que las misma aplicaciones se desarrollan con Java y con RPG en AS/400.
Ahí es donde creo que se peca mucho y donde, para mí se tuerce mucho la cosa. ¿Como podemos comparar una aplicacion cliente/servidor en VB que haya que instalar puesto a puesto, solo para windows etc. etc. con una aplicacion web de instalacion cero, para cualquier tipo de cliente sin instalación previa? ¿Como podemos comparar una tecnología para hacer aplicaciones multi-plataforma, con sus distintas implementaciones, su cantidad de librerías, el poder cambiar de S.O. etc. con una tecnología especifica que sirve para algo concreto en una plataforma concreta? No es por que uno sea mejor o peor, es que no son comparables.
Por eso no digo que VB ni RPG sea malo, pero es como decir que una navaja suiza es una mierda por que un bisturí corta mucho mejor y pesa menos. Por supuesto que sí, y un bisturí es perfecto si quieres operar a alguien, pero no tiene sacacorchos o diferentes hojas, unas más gruesas otras menos, y lima, y además el tiempo de vida de un bisturí es muy corto por lo que se tiran en seguida. ¿Y alguien querrá que le operen con una navaja suiza? Pues yo no, pero tampoco me iré a una excursión con un bisturí.
Y algo así es lo que "sufrimos" los desarrolladores web en nuestra industria (y conste que ya no hablo de Java o de MDD o lo que sea). Pedimos una aplicación multi-plataforma, escalable, que funcione en todos los navegadores que el cliente pueda usar, sin que se tenga que instalar nada, accesible desde todo el mundo y queremos que se haga en "los mismos tiempos" y "con las mismas herramientas" que cuando las aplicaciones eran, como mucho, cliente-servidor, para unos S.O. concretos, con unos procesos de instalación/actualización pesados, donde el cliente se tenia que j|@#~ y aprender con un manual etc.
En mi pueblo eso es pedirle peras al olmo, pero es lo habitual. Que levante la mano al que no le hayan dicho alguna vez algo parecido a "vaya mierda el desarrollo web, pero como se puede tardar tanto, si esto lo hacía yo con el XX (access,forms...) en dos patadas". Y sí, es cierto que es una "nublez" de la que es difícil sacar a los que mandan (IMHO, disonancia cognitiva para evitar afrontar el hecho de que los plazos que querrían no se pueden cumplir). Y por eso me parece desencaminado "luchar" contra ese fantasma, es imposible vencerle (cualquier tiempo pasado siempre fue mejor) así que no vale la pena gastar energías contra él.
Y yo tambien soy un "mero" programadorzuelo, pero con alergia a las gramíneas y a la publicidad "moderna" ;), así que tampoco me hagas mucho caso. Sólo es que creo que productos como OX no necesitarían caldear el ambiente así para hacer notar su valía, que la tiene.
Pero lo que yo propongo para esas persona es: ¿No hay software que me ayude a todo eso? Si, ya hay frameworks especializados como OpenXava que para un problema concreto han encontrado la solución y funciona. Así que no tienen mas que usarlo para evitarse todos los problemas.
Yo es que creo que no es realmente solución, por que OX o simlares es aplicable para unos problemas concretos, cosa que no sabrán distinguir, y te cubre el 90% de fábrica, estupendo, pero para el 10% que hace falta que le pongas, van a seguir sin tener ni idea. ¿Eso es que OX es malo? Ni de coña, solo que no hace milagros, como ningún otro.
Para que no parezca que es en contra de OX, pongamos Hibernate/JPA/JDO por ejemplo. ¿Para que lo usa mucha gente? Para no tener que lidiar con SQL y trabajar como si supieran lo que están haciendo. ¿Son malos los ORM? No, pero no hacen que alguien sepa trabajar con BDD, sólo permiten que "funcione" hasta que se encuentre un problema más gordo. Y luego si la BDD funciona como un perro cojo, es por culpa del ORM que es una mierda. Que el programador que lo ha usado no sepa que es un indice o que en esa aplicacion en concreto le hubiese ido mejor Ibatis o JDBC a pelo o otra cosa es "lo de menos".
Por eso para mi, visión personal, cuando uno no sabe, la solución no es darle una herramienta que le permita "no aprender". Así que OX, los ORM y muchas otras son herramientas cojonudas pero que no deben usarse para evitar aprender como funcionan las cosas. Y ante la obvia pregunta de donde te paras de "poder entender lo que hace por debajo", pues acudir a la "Law of Leaky Abstractions" de Joel Spolsky. Si la abstracción que usas es "leaky" -> no lo cubre todo y deja huecos de la capa de abajo que has de cubrir, entonces mejor aprender como funciona la capa de abajo o buscarse otra abstracción mejor. Y en un entorno tan nuevo y dinámico como las aplicaciones Internet, en los niveles medios hay más fugas que en el Titanic :)
tavernes: tus 550 clases puden desprender algún Ohhh! entre los seguidores de JavaHispano
No es eso, el ejemplo de las 550 clases lo pongo para indicar que es una falacia lo de que el "analisto" pueda diseñar un sistema completo desde cero con su herramienta de UML y luego pedirle al currillo que lo programe. Esas 550 clases son el resultado de meses de desarrollo, de iteraciones, de refactorizaciones... yo tiendo de todas formas a generar muchas clases pues desde mi punto de vista funciona la paradoja de más clases => más control => más mantenible => más extensible (evidentemente tienen que servir para algo).
Lo difícil no es programar 550 clases, lo verdaderamente difícil es que alguien te diga "mira lo mismo que tu en 10 clases", eso sí que motiva decir "Ohhh" aunque al mismo tiempo notes que le tiemblan las manos, que tiene la mirada perdida y que balbucea, porque meter mucho código en pocas clases suele ser muy malo para la salud mental, me da mucho mucho más miedo una clase de 500 líneas que un sistema de 500 clases :)
Nota: si no estuvieras casado te pediría una cita con cena, velas, música romántica y cosas así, porque me tienes totalmente ganado, tu mujer tiene motivos para estar celosa XD
Saludos,
para jmarranz
me da mucho mucho más miedo una clase de 500 líneas que un sistema de 500 clases
Si, este es el lema de "divide y vencerás".
pues me has pillado! Voy a ver como descompongo estas clases tan enormes en otras mas manejables, ya que me daba pánico hacer cualquier modificación! La verdad es que estas clases, aunque grandes, estan muy fraccionadas en métodos, pero verlas tan grandes asusta un montón!
Respecto a la cena.., bueno, no se este año como tendré el tema de la asistencia a las jornadas. Lo que si que és importante, es compartir ideas e impresiones. Respecto a las velas..., yo soy muy patoso y acabaré derribando las velas y quemando a alguien. Respecto a la música romantica..., la mas romántica és la de mi hijo a altas horas de la madrugada llorando, que viene a ser normal casi todos los dias. Respecto a mi mujer.., como socióloga creo que incluso lo encontraria interesante al principio..
Bueno, bromas a parte, voy a dividir el código en mas clases a ver como sale. Por cierto, a la hora de tomar la decisión de crear nuevas clases, no tengo muy claro cuantas líneas de código debe tener una clase, para no pasarse por exceso ni por defecto. Espero alguna opinión geresosa.
Gracias
Eduard
42 :)
@greeneyed:"Por eso para mi, visión personal, cuando uno no sabe, la solución no es darle una herramienta que le permita "no aprender". Así que OX, los ORM y muchas otras son herramientas cojonudas pero que no deben usarse para evitar aprender como funcionan las cosas"
Greeneyed, tienes razón siempre y cuando haya tiempo y dinero.Pero una situación normal es que la app tenga que estár para dentro de dos meses, que no haya presupuesto para contratar a personal cualificado, que el único que está libre no tenga ni puta idea, etc, etc.
Entonces para app empresariales es perfectamente factible usar frameworks tipo OpenXava.
¿Pero que ocurre con los problemas que has comentado?:
a) El 10 % que falta: Encima que se hace con 4 duros, rápido y sin personal cualificado, no querremos que se pueda hacer también ese 10% que falta. Si lo quieren que contraten a alguien que sepa del tema.
b) La BBDD funciona como un perro cojo: Encima que se hace con 4 duros, rápido y sin personal cualificado, no querremos que encima funcione rápido.Si lo quieren que contraten a alguien que sepa del tema.
Resumiendo, yo lo veo desde el punto de vista de un empresario que lo único que quiere es ganar dinero. Al fin y al cabo la mayoría de nosotros nos ganamos la vida con el software y la empresa nos contrata para darle soluciones y ganar dinero.
Saludos,
tavernes: no tengo muy claro cuantas líneas de código debe tener una clase, para no pasarse por exceso ni por defecto.
No hay una regla universal, una clase agrupa métodos, es decir acciones, convendría que dichos métodos estuvieran relacionados con un solo tema, es decir el tema de la clase, e intentar que el tema de la clase no sea demasiado amplio.
Un ejemplo muy muy tonto, imagina que necesitas métodos para sumar, restar, dividir etc números reales pero también necesitas métodos para formatear números reales como cadenas con muchas variantes por ejemplo mostrarEnComaFija o mostrarEnComaFlotante.
Podrías usar una misma clase TodoSobreReales y ponerlos todos ahí, ciertamente todos los métodos son sobre enteros pero te darás cuenta que hay dos grupos de métodos, los de cálculo y los de cadenas y por tanto podrían dividirse en dos clases CalculoReal y FormateoReal pues posiblemente necesites hacer algo similar con enteros, double, números complejos etc y posiblemente acabes derivando de clases genéricas como Calculo y Formateo.
Date cuenta de que hay varios "temas" que se intersectan: el tipo de datos y los dos tipos de operaciones, las de cálculo y las de formateo. En el anterior ejemplo la estructuración se ha hecho en torno al tipo de operaciones (Calculo => CalculoReal y Formateo => FormateoReal) pero podría también hacerse por tipo de datos, es decir a partir de una clase base MundoReal derivar CalculoReal y FormateoReal.
Como ves "la arquitectura" elegida no es obvia y dependerá de cual se adecue mejor a tu problema y en cual puedas aplicar un mayor grado de reutilización de código, que SIEMPRE es deseable.
Fin del minitema, que el hilo es sobre OpenXava.
Sí, si no digo que no pase y no se haga. Sólo que debemos darnos cuenta de que en realidad no es que hayamos solucionado el problema, por que luego acabamos teniendo que buscar otras soluciones para problemas que en realidad no existirían si hubieramos solucionado el problema real.
Peyrona
"Lo que denuncio es que (en general) a este trabajo no se le dedican recursos del mismo nivel ni experiencia que al de hacer los diagramas y que ese es uno de los mayores problemas que tiene el software que producimos especialmente en España: su pésima calidad de implementación. Salvando claro está, todas esas honrrosas excepciones."
¡¡Por dios!! ¡A este hombre que le hagan presidente! No se puede tener mas razon en un solo parrafo...
@diversas referencias a "El 10 % que falta":
Como todos sabemos "el primer 90% del proyecto se lleva el 90% del esfuerzo del proyecto. El 10% que falta representa el otro 90% del esfuerzo del proyecto."
Lo que hay que plantearse es... ¿estamos queriendo que el primer 90% del proyecto sólo requiera digamos el 30% del esfuerzo, pero que a cambio el 10% que falta requiera el otro 300%? Porque es exactamente eso lo que hacen "determinadas plataformas". (Ejercicio para el lector aventajado: Argumentar cuáles son las "determinadas plataformas" a las que se hace referencia en este párrafo)
Hola foro
Esta buena la polemica y sobre todo el comentario de eso de la productividad y la madeja inmantenible de codigo en VB. Tengo ya un rato (10 años) de andar en consultoras y de mantenimientos a desarrollos en VB Client-Servidor, aplicaciones WEB, etc, etc y bueno entrando en materia, en el transcurso de ese tiempo me he encontrado como dicen con codigo espagueti sin estructura, sin una logica coherente, sin comentarizacion de que hace tal o cual funcion, en fin resultaba mas facil replantear una reingenieria de la aplicacion que seguir parchando el moustro, pero como lei el comentario de logongas no es que la herramienta fuera mala. Creo que el desarrollo exitoso de una aplicacion no es debido a que se y utilizo tal o cual plataforma, lenguaje o la matodologia milagrosa, es todo el equipo que interviene, por que se pude tener un lenguaje poderoso, un programador cinco estrellas y un analista inexperto que no supo recopilar todos los requerimientos del usuario y despues de un rato de estar desarrollando y finalmente se tiene un aplicativo para realizar las primeras pruebas con el usuario resulta que olvido mencionar que en el proceso X del calculo de las cuentas que son de Y tenian que ser procesadas de otra forma cada 2do viernes del 6to mes si es año biciesto y como ya esta encima la fecha de entrega pues hay que hacer los cambios para cumplir el rquerimiento que el "tonto" del usuario no le dijo el "tonto" del analista y que el "tonto" desarrolloador no adivino y si esto se repite con mas requerimientos que no se analizaron, comienza una caceeria de brujas y mas de una vez se concluye "la herramienta VB no sirve mejor vamos a rehacer el sistema pero ahora con C++ que es mas poderoso" pero si el analista, el arquitecto, el programdor no conocen ni la correcta aplicacion de una metodologia ni el uso del lenguage (el que sea) el exito del desarrollo de una aplicacion seguira lejos.
Con todo esto no quiero decir que la falla esta en una fase del desarrollo del software, si no que todas son importante y cuando se trata de un sistema de alta complejidad es necesario tener a la GENTE correcta en cada etapa del ciclo de vida de sftw.
Solo un comentario sobre la productividad, que hablamos mucho de productividad pero me da la sensación de que generalmente se asocia simplemente a "terminar la aplicación más rapido", productividad no es eso, se trata de generar los mayores beneficios con el menor gasto posible y esto no siempre pasa por terminar más rapido.
Si desarrollamos con una plataforma/framework determinado que me permite montarme las pantallas de mantenimiento en cuatro minutos pero luego resulta que cualquier requisito que no este contemplado en el framework de forma directa me toca implementarlo de forma chapucera "esquivando al framework", si resulta que luego (como con VB) mi aplicación sólo se ejecuta en una plataforma determinada y no puedo llegar a muchos clientes interesantes, si resulta que mi aplicación tiene un proceso de instalación pesado y de actualización de nuevas versiones ni te cuento (instalar una aplicación de escritorio en 300 puestos cuesta tiempo y dinero), si resulta que producto de caer en "esta aplicación la puede desarrollar cualquier inexperto que la herramienta futanito te lo da to echo" el código es un horror que no hay quien lo ha mantenga cuando vengan los bugs o se pidan modificaciones empiezan los verdaderos problemas.
¿donde queda la productividad entonces?, si nos limitamos a hacer comparaciones entre una tecnología y otra y decimos que tal es más productivo que pascual porque hago un mantenimiento de una tabla en menos tiempo estamos en mi opinión equivocandonos de pleno.
Con esto no quiero decir que frameworks tipo OX no tengan su utilidad, la tienen, y en manos expertas seguro que suponen un ahorro en tiempo de desarrollo y en estabilidad del producto al tratarse de un framework probado. No estoy en contra (seria absurdo) de frameworks que automatizen las partes mecanicas de un desarrollo, lo que digo es que no podemos centrar el debate de la productividad en estos frameworks porque son sólo una pequeña parte de lo que realmente significa ser productivo dentro de un desarrollo. ¿Que estos frameworks suponen una ayuda?: sin duda. ¿Que son la respuesta para alcanzar el santo grial de la productividad?: ni de lejos.
Por eso no me gustan afirmaciones del tipo "un equipo de desarrollo java nunca será tan productivo como uno VB, ruby en rails.." eso es cojer un caso concreto donde se desarrollan aplicaciones en un contexto muy restringido y elevarlo a la categoría de regla general.
Y esto sin entrar en el debate que marca la verdadera diferencia de productividad en nuestra industria: la capacidad y talento del equipo de desarrollo, que es donde las diferencias son realmente abismales y hacen que el debate de la productividad de tal o cual herramienta sea en realidad cuasi irrelevante.
Muchas de las cosas en contra de los entornos de "desarrollo rápido" que se han dicho en este hilo sí aplican a un RAD tracional (como VB o Delphi), pero no a los Marco de Trabajo dirigidos por el Modelo Ligeros (LMDF), como OpenXava, Roma Framework, Trails, NakedObjects o JMatter.
En VB dibujamos la pantalla y la lógica de negocio ya veremos donde la ponemos, es muy tentador ponerla directamente en los eventos de los controles.
En OpenXava si quieres una aplicación tienes que diseñar las clases del dominio con Java, con sus propiedades, referencias, colecciones, herencia, etc. y si no no hay aplicación. El comportamiento es obligado ponerlo en los controladores (grupo de acciones), y estos son reutilizables por naturaleza (es obligado que los definas y registres). La lógica de negocio la puedes poner en el controlador o el modelo (siempre es mejor un modelo más gordo y un controlador más fino).
Es decir, con un LMDF es bastante dificil hacer código espagueti.
La interfaz gráfica es generada automáticamente, la ventaja es que puedes tener diferentes interfaces gráficas desde el mismo modelo, pero siempre existe la opción de hacerla a mano.
Es decir con LMDF nos acercamos a la productividad pero mantenemos un código claro y orientado a objetos.
En cuanto al 10% que no resuelve OX, lo tienes siempre, uses o no uses OX, pero OX solo tienes ese 10%.
Hola a todos,
Estoy alucinando ya que acabo de leer algunos post.
"Realizar aplicaciones sencillas con las herramientas magicas que surgen con cualquier tecnologia, es sencillo, realizar aplicaciones complejas es complejo" No tengo el link original a la frase en ingles.
Hace 15 años un programador senior le dijo a un consultor no cito la empresa, "con estas herramientas vamos a tardar 2 años en hacer el teleproceso" el consultor le respondio, "llevo 5 teleprocesos cada uno se realiza con las ultimas herramientas y metodologias del mercado, al principio todos van a tardar 2 años y acaban tardando 5".
Por otra parta, aqui parece que solo hay "chicos para todo" en un proyecto mediano, siempre hay alguien llamalo arquitecto o guru que hace el 20 % que se necesita para que funcione el 80 %, ademas se dedica a hacer un 10 % de chapuzas que no puede resolverlo el 80 %.
Si java es tan bueno para web, porque estan triunfando Rubi, asp.NET o PHP, seguramente porque son framework mas restrictivos y que para poner un clavo no hay que fabricarse el martillo.
Un buen ejemplo de esto puede ser
http://www.joomlaspanish.org/ que esta siendo ampliamente usado.
Java es el peor lenguaje posible para desarrollos empresariales.
Esto ya esta quedando claro para todo el mundo.
La decepcion con Java en las empresas es una realidad palpable.
La Orientación a Objetos, tal como se la usa en Java, ha demostrado ser como el Comunismo. En teoria, funciona ... pero en la practica, no.
Do not feed the troll :-)
batch4j: Si java es tan bueno para web, porque estan triunfando Rubi, asp.NET o PHP, seguramente porque son framework mas restrictivos y que para poner un clavo no hay que fabricarse el martillo.
¿Donde está el triunfo de Ruby, ASP.Net y PHP?
Yo no lo veo (y que conste que tengo bastante respeto al mundo .Net) y creo que el resto del mundo todavía tampoco
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
y mira que PHP y ASP.Net tienen ya años a sus espaldas.
Precisamente has dado en el clavo, "más restrictivos", por esa misma razón en Java tienes, desde OpenXava que simplemente con el modelo de datos ya tienes una aplicación web a frameworks en donde puedes hacer aplicaciones web imposibles de hacer con cualquier otra tecnología, pasando por el JSP+JDBC a pelo y pudiendo optar por multitud de enfoques: céntrico en el servidor, céntrico en el cliente, estilo declarativo, imperativo, templates ejecutables, templates puro HTML etc etc.
Es lo que tiene la libertad que a muchos les abruma y en vez de aprender a elegir optan por alternativas más restrictivas.
Ya que tú mismo lo muestras como fuente válida, dejaré a un lado lo discutible que es ligar directamente TIOBE a "triunfo". Ahora bien, digo yo, ¿estar en el 4º puesto no se considera "triunfo"?
¿Rubi y PHP frameworks? no confundamos. Creo que en todo lenguaje pueden haber cosas que tengan pegada. Eso me parece bien. En el caso de Joomla, tiene éxito porque es un producto acabado y extensible, y además tienes muchos plugins. Yo creo que la comunidad PHP es grande (sobre Rubi o .Net no opino porque no lo sé) pero creo que su mercado usualmente es diferente al de Java, por lo cual coexistirán. Por ejemplo, recuerdo que la web de Eclipse estaba hecha con PHP y me parece que lo sigue estando y no creo que por eso la fundación eclipse piense que PHP es mejor para todo; seguramente será por motivos económicos o de infraestructura. Uno de los puntos fuertes de PHP es ese, en cualquier parte encuentras un servidor PHP y a un precio super-económico.
@jmarranz:"Es lo que tiene la libertad que a muchos les abruma y en vez de aprender a elegir optan por alternativas más restrictivas."
Quizas no sea cuestion de libertad sino de oportunidad. Mi experiencia de casi de 10 años como desarrollador fué que TODAS (excepto una) las aplicaciones que hice fueron aplicaciones de bases de datos (con mayor o menor complejidad) . ¿Para que necesito toda la libertad de Java si solo hago un tipo de aplicaciones?
Lo que realmente me sorprende es que no haya más gente aun usando ese tipo de alternativas (Rails, OpenXava, etc.) Quizas se tiene miedo a ese 10% que no se puede hacer con el framework. Pero , ¿cuántas aplicaciones habrán tenido infinidad de problemas lo cuales se podrían haber reducido mucho al usar un framework del estilo de OpenXava?.
Saludos.
Si quieres hacer un mantenimiento CRUD de un par de tablas, seguramente el MDD irá bien (tampoco veo la dificultad de hacerlo en J2EE, pero bueno, hay gente que se complica enormemente la vida, además de que las cosas van cambiando).
Ahora nos imaginamos que quieres hacer un sistema de reservas en web de algo con calendarios, drag & drop, información contextual y 1000 pijadas más (y creo que no he puesto nada del otro mundo). ¿Qué tipo de solución da el MDD?
MDD tiene su nicho de mercado, pero fuera de ahí sirve de bien poco.
Ahora nos imaginamos que quieres hacer un sistema de reservas en web de algo con calendarios, drag & drop, información contextual y 1000 pijadas más (y creo que no he puesto nada del otro mundo).
Sí, pero esa aplicación web tan espectacular se conecta a un sistema ya existente, seguramente con cientos de programas en COBOL corriendo en HOST. Es ahí donde el Java Empresarial clásico se queda corto, y OpenXava puede ser útil. Es decir, para hacer un "banco en casa", utiliza Seam, JSF, GWT, lo que quieras, pero para la gestión interna del banco, OpenXava es mucho mejor.
Javier, aparte de las demos que están en www.openxava.org, ¿puedes facilitarnos algún link a aplicaciones que hayan sido desarrolladas con Openxava?
Gracias!
¿puedes facilitarnos algún link a aplicaciones que hayan sido desarrolladas con Openxava?
Si lo que quieres es el código fuente es dificil, porque las aplicaciones OpenXava que conozco son comerciales.
A lo mejor si lo pides en el foro de OpenXava, alguien te lo puede ofrecer. Yo no porque el código de las aplicaciones OpenXava no me pertenece.
Por otra parte, si lo que quieres ver es una aplicación de verdad funcionando, eso es más fácil. Contacta conmigo directamente, y lo arreglare para que veas una demo del Padron Municipal de Habitantes, Inventario y Patrimonio, Nóminas, o alguna de este estilo.
Escribe tu comentario