A través de Reddit, he encontrado este video que compara el desarrollo de interfaces web con diferentes frameworks y plataformas. J2EE ("parcial" y "completo"), Ruby on Rails, Zope/Plone, TurboGears y Django.
Empieza con una comparativa muy simple de cómo trabaja cada uno,analizando el código necesario, el uso de configuraciones, en general la facilidad y comodidad de uso de cada uno. Posteriormente compara el desarrollo de una aplicacioncilla un poco más real, aunque en este caso ya no lo hace en vivo si no que sólo cuenta los resultados. Eso último es un poco una pena, pero aún así el video sigue siendo bastante interesante.
Como comparativa me parece infantil y sesgada. A los 2 minutos de empezar ya estaba claro por donde iban a ir los tiros.
Y no sabia yo que usar Maven formaba parte de J2EE... o que J2EE mismo fuera un "framework". Etc.
Para mi, personalmente, un descrédito para las ventajas que realmente tienen otros entornos frente a usar todo el mamotreto J2EE hasta en la sopa.
estoy de acuerdo. A nosotros nos lo pasaron en la empresa donde estoy y me pareció pueril y curiosamente no hablaba d elos entornos que existen en la actualidad para desarrollar en jee.
creo q hemos mejorado mucho (y aún podemos aprender más d enuestros errores) desde los primeros dias de j2ee y con la aparición de jee 5.0 estamos en un momento álgido de madurez. Me pareció muy engañoso la temática del video y tiemblo si cualquier CEO q lo viera pudiera elegir un Ruby on Rails para desarrollos de empresa (con todo mi respeto a Ruby) integraciones con SAP, entornos alatamente transaccionales (2pc,..) debido a su sencilleza. No conozco profundamente Ruby y respeto dsu filosofia, pero como arquitecto no me veo desarrollando aplicaciones en Ruby.
Curioso q no hablara de las anotaciones, curioso q no hablara de spring, seam, frwks mvc como struts(2), spring mvc, tapestry etc..
en fin son opiones del autor algunas de las cuales no comparto
jejeje yo he parado en el minuto 6 cuando han dado las dos primeras métricas: CoC y No XML Sit-up... Prometo verlo cuando tenga tiempo, pero me parece que el final de esta peli ya la he visto.
Salu2
Quizá. Depende de lo que estés esperando, Ibon. Si, por ejemplo, esperas que Zope/Plone quede por encima del resto, pues quizá sí lo hayas visto.
Al Anónimo decirle simplemente que no se pretende (y se aclara al principio del video) valorar estas plataformas para desarrollar sistemas transaccionales, ni para hacer integraciones con SAP, sólo para el desarrollo rápido de interfaces web.
"Quizá. Depende de lo que estés esperando, Ibon. Si, por ejemplo, esperas que Zope/Plone quede por encima del resto, pues quizá sí lo hayas visto."
O si espero que la opción elegida no sea J2EE habiendo elegido esa métrica. Es otra posibilidad de espera.
Ibon, te has perdido la métrica "fun factor" y la de "usando esta opcion me equivoco pero en las otras no, que casualidad". Aunque visto lo visto no creo que nada de lo que viene despues te sorprenda mucho.
No, si estoy de acuerdo con la primera parte del video: cualquiera que programe una aplicación web en java sin la ayuda de un IDE, o un framework (como de hecho es RoR o Plone que es un CMS!) se va a cagar en Java y en todo el XML que tiene que escribir a mano. Ahora bien, en el 2007!!! comparar como lo ha hecho este tío no me parece ni justo ni real. Le ha faltado crear un EJB que traiga desde una base de datos un campo VARCHAR con el "Hola Mundo". Lo siento, pero lo dejo a los 12 minutos... Desde luego J2EE tiene mejores críticos.
Salu2
No deja de ser gracioso que un tio considere el "fun" como una de sus metricas y utilize el emacs para editar código java, vamos fun y más fun.
Una aplicación holamundo con netbeans/eclipse/cualquierIDEDecente se hace exactamente con 0 lineas de código (las escribe el ide) y dos click de raton, uno elegir "proyecto güeb" y el otro en una flecha verde, no tiene perdida.
Sobre el "convetions over configuration" que tanto mola ultimamente, las convention no son más que nomenclaturas escritas a fuego en el código de un framewok, un IDE de java que de soporte para un framework pude seguir las mismas convenciones, la diferencia es que escribe esas convenciones en un fichero XML (que en exceso es malo, pero no es el demonio tampoco, que no tenemos termino medio), por ejemplo creo un sevlet en netbeans y me crea un mapeo en el web.xml. La única ventaja de las convenciones es escribir menos y ir mas deprisa, si un IDE escribe por mi los ficheros de configuración estoy en el mismo punto, no entiendo tanto escandalo con este tema la verdad.
Y luego las convenciones estan muy bien hasta que quiero hacer algo que no encaja en la convención de turno, entonces a buscarse la vida claro. Me recuerda un poco a los RAD de antaño como visualBasic, quedaba muy bien para hacer demos tipo "holamundo" pero luego resultarón un infierno, alguien decia "Vbasic te facilita el 90% de las tareas diarias de desarrollo a cambio de hacerte casi imosible el 10% restante".
Mmm... Convention over configuration va un poco más allá de "no escribir XML", remoh.
De lo que va es de tener ya hechas una serie de decisiones razonables, de tener un funcionamiento por defecto ya establecido y "estandar" (dentro de esa arquitectura). No se trata de no escribir XML si no de no tener que escribir XML. No se trata de no definir una configuración, si no de no tener que definirla.
Es Convention Over Configuration, no es Convention Instead Of Configuration. La posibilidad de hacerlo siempre está ahí. Igual que está la posibilidad de crear o usar herramientas que generen configuraciones, sea un IDE, o sea tu propia macro en tu entorno favorito (que puede ser emacs, sí, que si crees que Eclipse te genera mucho código, no has visto lo que te puede generar emacs).
En fin, a mi el video me parece interesante, aunque por supuesto tiene problemas. El principal es que la comparación, efectivamente, es poco coherente. Lo de meter a Plone es claramente poco justificable. Sin embargo, en el caso de J2EE, donde quizá sería más apropiado meter algún framework como Struts, partes de Spring (pero no Spring entero) o, qué sé yo, Wicket. Pero en casi ninguno de los casos creo que variara mucho el tema del uso del XML y esas cosas.
Por cierto, veo que habéis ignorado bastante el tema del ciclo de reinicio... Por curiosidad, ¿no os molesta?
Por cierto, veo que habéis ignorado bastante el tema del ciclo de reinicio... Por curiosidad, ¿no os molesta?
Simplemente ignorado por que es cuestion de eleccion suya. Yo creo una aplicacion web con una pagina JSP que diga hola mundo sin escribir una sola linea de XML y si me apuras, con el servidor en marcha y sin reiniciar. Pero claro, ni uso Tomcat ni me pongo a escribir XMLs en Maven ni tengo que borrar los directorios antes de hacer un redeploy... por favor.
Yo uso un framework en el que todo es recargable en tiempo de ejecucion y con Java 6 hasta las clases, y si no, el contenedor reinicia el contexto por mi.
venkman, he visto trabajar a autenticos "magos" del emacs, si no digo yo que no sea potente, pero esas cosas no las hace ecmacs, las haces TU si te programas tropecientos scripts. Eclipse o netbeans ya lo hacen de serie y para programarte las refactorizaciones de código o el soporte para jee de estos IDE's en emacs necesitas tres camiones de scripts, me da la risa sólo de pensarlo, es un poco convention over configuration aplicado a un IDE :P
A lo que voy con lo del COC es que no veo tanta ganancia practica con el tema, que si, que no tengo que escribir la configuración porque ya esta escrita dentro del framework de forma "razonable", pero si tengo un IDE que me escribe esas convenciones (la configuración por defecto que ponga) pues la verdad, ni me quita el sueño ni me parece la nueva "silver bullet" del desarrollo güeb como predican muchos.
La ventaja de Convention Over Configuration no es el hecho de no escribir la configuración o que ya esté escrita o que la escriba un IDE, remoh.
La ventaja es que es una decisión razonable implantada en la propia plataforma. Si el plugin (*) A de Eclipse te escribe una configuración X para [tal framework] y el plugin B de NetBeans te escribe una configuración Y para ese mismo, ¿son necesariamente iguales X e Y? ¿siguen al menos las mismas directivas?
De lo que trata COC es de que el propio framework toma una serie de decisiones por ti. Nadie dice que sea la solución definitiva para todo, pero es una buena ayuda para muchos casos.
(*) plugin... por cierto, que para emacs no tienes que hacerte tú todos los scripts, los puedes bajar y tal.
COC no es un problema, a no ser que te creas que es un principio universal y la solución a todos los males, como parece ser la moda. Esta muy bien y es muy comodo mientras tengas una forma sencilla de podertelo saltar si no se adapta a tu problema, pero cuando tienes que todo lo que haces se basa en ese principio y para cambiarlo tienes que hacer muchisimo trabajo y cambiar toda tu forma de trabajar, entonces es un obstaculo a no ser que simplemente te dediques a hacer aplicaciones de juguete para poder fardar en tu blog de lo fácil que es.
Como todo, en su justa medida y para lo que es apropiado.
> creo un sevlet en netbeans y me crea un mapeo en el web.xml
Por cierto, ¿Netbeans aún te crea el método processHtm() para encapsular doGet() y doPost() cuando creas un servlet?
Por Dios! por Alá!!! Que un GET y un POST no es lo mismo, que es una muy mala práctica de programación!
P.D.: un GET se usa para obtener datos del servidor y un POST para modificar datos en el servidor, por ejemplo una búsqueda en Google es un GET (aunque use un formulario). Si no se usan bien las páginas no se almacenan correctamente en los proxy-cachés y hacemos que internet funcione peor y salen granos y te quedas calvo (o calva).
"Si no se usan bien las páginas no se almacenan correctamente en los proxy-cachés y hacemos que internet funcione peor y salen granos y te quedas calvo (o calva)."
Yo si que prohibiría los proxy-cachés por ley.
Por cierto, desde tiempos inmemoriales (me parece que desde NB 3.5) NB te permite modificar los templates que te ofrece para los ficheros nuevos. Está en Tools/Templates. Los abres en el editor y lo modificas a tu gusto.
Salu2
Ibon: "te permite modificar los templates que te ofrece para los ficheros nuevos"
Eso es twampa! (Por lo menos según algunos xD)
jejejeje, si debe ser trampa, que de siempre los IDE's tienen que hacer las cosas como yo quiero desde el principio. En serio, NB puede tener otras criticas muy buenas: como que no seguía las recomendaciones de Sun para presentación del código. Aunque ahora (desde la 5 me parece) puedes configurar hasta el más pequeño detalle de presentación de tu código (Tools/Options/JavaCode).
Salu2
Creo que desde el momento que se comparan cosas distintas (j2ee vs. frameworks vs. un cms) la comparativa pierde toda validez. Al parecer su intención es resaltar Zope/Plone, del cual por cierto no dijo nada de integración con aplicaciones de legado.
Un saludo
PAFFF...@Ibon ahora al año 2010, todavía no puedo hacer las mismas cosas en Java que en RoR...simplemente para RoR sólo necesitas leer 2 libros (uno de Ruby y otro de Rails) y sí a caso leer la documentación (o algunos ejemplos) de las gemas.
Lo que para una aplicación Java necesitas:
Manejador de persistencias de DB (Hibernate, Ibatis, Terracotta)
Framework de presentación (Wicket, Struts, Tapestry)
IDE (forzoso, si no te llegan a año nuevo)
¡VAMOS! ...Hay que reconocer, que no todo lo que brilla es oro. Tengo un amigo que en 1 semana hace aplicaciones tan buenas cómo las que yo hago en 2 meses(él en Ruby on Rails, yo en Java; y el factor no es la experiencia ni la lógica ya que yo le explico muchas veces el flujo de algún proceso de manera algoritmica).
Si comparamos wicket (un framework sencillo de Java) contra Rails, veremos que Wicket le queda muy lejos. Y a struts (1 o 2) ni se diga, struts con tanta configuración te marea.
Escribe tu comentario