Breve resumen.
Nuestra segunda reunión ha sido todo un éxito!
El expositor, Carlos Zuñiga; inicio practicamente puntual a eso de las 6 y media, después de una breve bienvenida, empieza la exposición comentando las características principales del lenguaje Groovy:
Lenguaje Script y Dinámico (Hot deployment) principalmente orientado a programadores Java, Groovy posee una compatibilidad al 100% con clases Java, pues corre directamente en el Virtual Machine de Java, lo que quiere decir que puede tanto Groovy usar clases Java como Java clases Groovy.
Seguidamente nos comenta de la herramienta Groovy Console, nos señala que es una herramienta que nos permite correr segmentos de código en un archivo Groovy de forma dinámica, con solo seleccionarlo. Carlos continua con una serie de ejemplos, a medida va afinando puntería con la ya mencionada consola de Groovy.
Entre varias cosas, nos muestra el funcionamiento de los GString (Tangas en Ingles y nos señala que el nombre fue hecho a propósito y con algo de sátira o humor, en efecto).
También nos muestra los Heredocs, comenta el duck typing, el autoboxing y la recalca el hecho que Groovy sea full orientado a objetos, pues hasta los primitivos a diferencia de Java, son objetos.
Por ultimo nos da una introducción al manejo de collecciones: Listas, Mapas, Vectores para finalizar con algunos buenos ejemplos del uso de Closures.
Una vez cocinado los closures y de un pequeño debate entre su servidor y Carlos, entramos en un receso acompañado de pan de Ajo y deliciosa pizza, patrocinada por BackCountry, ehh todo el anuncio.
Despues del intermedio, volvemos al auditorio de la ULatina para iniciar con Grails; Carlos retoma la charla, comentando que Grails es la versión de Rails para Groovy, es un tool/framework para hacer aplicaciones Web, utiliza la convención sobre configuración, utiliza Ant para la construcción (en realidad es GANT y se parece demasiado a Maven, osea reinventaron la rueda), usa SpringMVC y Flow para el control, GSP (Groovy Server Pages para la presentación), Hibernate para la persistencia, entre otras cosas.
La forma de funcionar, resulta muy similar a un generador de código, en particular a OpenXava, en el ultimo se anotan los beans con JPA y se genera todo un IMEC, basado en porlet's por defecto, en Grails se espera simplemente una estructura estándar de paquetes y por convención se hacen mapeos basados en mapas asociativos en variables estáticas que deben llevar cierto nombre.
Por ultimo demuestra el Hot deploy con el cual cuenta Grails y de las ventajas del mismo, así como el ejemplo, además nos da por enterados de una serie de plugins para mejorar la interface, entrelazarse con otros sistemas, tener mas control y extender Grails.
La charla termina con un Set de preguntas, en gran parte hechas por su servidor, ahora desde mi humilde opinión y mi completa ignorancia, claro y con mas calma, mis impresiones.
1) Groovy es Java 2, el 85% de las características que tiene el lenguaje, simplemente excelentes y además son cosas que ya no se le pueden agregar o no deberían, a la actual arquitectura de Java; un claro ejemplo son los closures; espero que todos los ángeles y demonios por igual caigan a Sun y al Java Community, para evitar este sacrilegio, de lo contrario vamos a tener una librería util, mas demoniaca que nunca, con mas parches de los que ya tienen a raíz de las anotaciones, enumeraciones y templates (generics a.k.a) introducidos en la versión 5, no confundan, me cuadran, pero el lenguajes no fue pensado para ellas, al menos no, para anotaciones y generics, por ultimo diré que Groovy fue considerado y solicitado por el Java Community como un Fork de Java, al cual algunos le apodan Java 2 y con mucha razón, pues este es un super conjunto de Java, como en su momento lo fue C++ de C.
2) Programador Java que quiera conservar su trabajo como desarrollador en esta área del conocimiento, debe aprender Groovy, pues en el futuro la programacion Java apoyada en ciertos segmentos por scripting, fijo va a ser la moda si no la regla.
3) Para seguir en el futuro, Groovy con sus inconvenientes de desempeño y todo, sera el lenguaje VM mas usado, las cosas que realmente necesitemos "perfomance" seran en Java, asi como hace algunos años, se escalaba el desempeño a traves de JNI y C++, e igual siempre queda ese tercer nivel para lograr aun mejores resultados o cuando la plataforma Java necesita cosas muy especificas del sistema operativo en donde es huesped.
4) Grails: pienso que este enfoque aun esta muy en pañales e inclusive me atrevo a decir que Grails, puede ser un buen intento de algo que fracasará y en el futuro evolucionara a algo mas intermedio, es decir facil de usar pero mas flexible y proporcionando mas control, asi como le sucedio a los EJB version 2, practicamente muertos y relevados por JPA y EJB 3 que es una version super Pojo y sin tanta interface.
Otro punto bajo recae en el hecho que Grails utiliza una serie de framework's que aunque muy buenos y todo, primero no son estandar (aunque no tengo ningun problema con eso ;) y segundo no estoy del todo seguro de la facilidad de meter por ejemplo otro framework de persistencia (aunque por estar con Spring, de fijo se puede, aunque sea fuera del caminito de oro), digamos iBatis y por que iBatis; con base en los comentarios hechos por la gente de LinkedIn, por solo poner un ejemplo de escalabilidad, ellos no usan un ORM por que simplemente no tienen sentido, usan JDBC directamente con unas clasesillas que les apoyan en lo repetitivos, supongo algo como dbutils de common apache, ya que ellos tienen la base de datos distribuida, osea una tabla en una base de datos, otra en otra base de datos, etc; Hibernate hasta donde yo se, no puede manejar este tipo de cosas pues aqui no existiría integridad referencial, para iBatis por el contrario, es una situación perfecta; bases de datos no normales y nefastas, con select moustrosos, venga, a iBatis le vale un comino, simplemente toma el resultado de la consulta y juazzzz, te retorna un bean, si bien no es un ProxyBean y el manejo de transacciones no es el mismo, es mil veces mejor que JDBC y muy util para diferentes escenarios (Notese la aficcion a iBatis, creo que soy un psicopata del control en mis app's me gusta saber que pasa y como :). Y asi pienso que se pueden sacar muchos mas escenarios donde Grails se queda corto, claro no le quito merito, la velocidad de desarrollo y demas, es super cool, GORM y sus campos "buscables", super cool, sin embargo aun permanezco algo retraido a este tipo de soluciones, genera todo. Si me preguntan, Grails te ofrece una solución al estilo .Net, cero opciones, pero funca y rapido, pero con restricciones, en el caso por ejemplo de ASP, no se puede tener mas de un formulario, entre otro monton de pegas, la diferencia es que Grails usa un pseudo Java para implementarlo todo. Jajaja, espero que no me llamen ateo o me acusen de sacrilegio por eso, pero al chile, no quiero ver clientes pidiendome hacer un facebook con Grails en 2 meses.
5) Como Carlos menciono, los test cases son un escenario bastante bueno para introducir Groovy, estoy de acuerdo, pero como comente en el cuarto punto, Grails si se pasa de esa raya. Un enfoque donde los DAOS y Servicios sean Java, digamos expuestos por XFixe o Axis, etc y un Aplicativo MVC, donde Actiones de Struts inyectadas por Spring, sean Script's Groovy o Jython, Scala, etc; con Hot Deployment, seria super cool, de hecho yo lo hago asi y si bien es cierto, el IDE aun le falta bastante y el classpath al compilar a veces queda super perdido, la velocidad para probar y hacer cambios lo justifica.
En resumen, muy buena confe y aguante al grupo de Java CR.
Nos vemos en la proxima!
Saludos,
J
Nuestra segunda reunión ha sido todo un éxito!
El expositor, Carlos Zuñiga; inicio practicamente puntual a eso de las 6 y media, después de una breve bienvenida, empieza la exposición comentando las características principales del lenguaje Groovy:
Lenguaje Script y Dinámico (Hot deployment) principalmente orientado a programadores Java, Groovy posee una compatibilidad al 100% con clases Java, pues corre directamente en el Virtual Machine de Java, lo que quiere decir que puede tanto Groovy usar clases Java como Java clases Groovy.
Seguidamente nos comenta de la herramienta Groovy Console, nos señala que es una herramienta que nos permite correr segmentos de código en un archivo Groovy de forma dinámica, con solo seleccionarlo. Carlos continua con una serie de ejemplos, a medida va afinando puntería con la ya mencionada consola de Groovy.
Entre varias cosas, nos muestra el funcionamiento de los GString (Tangas en Ingles y nos señala que el nombre fue hecho a propósito y con algo de sátira o humor, en efecto).
También nos muestra los Heredocs, comenta el duck typing, el autoboxing y la recalca el hecho que Groovy sea full orientado a objetos, pues hasta los primitivos a diferencia de Java, son objetos.
Por ultimo nos da una introducción al manejo de collecciones: Listas, Mapas, Vectores para finalizar con algunos buenos ejemplos del uso de Closures.
Una vez cocinado los closures y de un pequeño debate entre su servidor y Carlos, entramos en un receso acompañado de pan de Ajo y deliciosa pizza, patrocinada por BackCountry, ehh todo el anuncio.
Despues del intermedio, volvemos al auditorio de la ULatina para iniciar con Grails; Carlos retoma la charla, comentando que Grails es la versión de Rails para Groovy, es un tool/framework para hacer aplicaciones Web, utiliza la convención sobre configuración, utiliza Ant para la construcción (en realidad es GANT y se parece demasiado a Maven, osea reinventaron la rueda), usa SpringMVC y Flow para el control, GSP (Groovy Server Pages para la presentación), Hibernate para la persistencia, entre otras cosas.
La forma de funcionar, resulta muy similar a un generador de código, en particular a OpenXava, en el ultimo se anotan los beans con JPA y se genera todo un IMEC, basado en porlet's por defecto, en Grails se espera simplemente una estructura estándar de paquetes y por convención se hacen mapeos basados en mapas asociativos en variables estáticas que deben llevar cierto nombre.
Por ultimo demuestra el Hot deploy con el cual cuenta Grails y de las ventajas del mismo, así como el ejemplo, además nos da por enterados de una serie de plugins para mejorar la interface, entrelazarse con otros sistemas, tener mas control y extender Grails.
La charla termina con un Set de preguntas, en gran parte hechas por su servidor, ahora desde mi humilde opinión y mi completa ignorancia, claro y con mas calma, mis impresiones.
1) Groovy es Java 2, el 85% de las características que tiene el lenguaje, simplemente excelentes y además son cosas que ya no se le pueden agregar o no deberían, a la actual arquitectura de Java; un claro ejemplo son los closures; espero que todos los ángeles y demonios por igual caigan a Sun y al Java Community, para evitar este sacrilegio, de lo contrario vamos a tener una librería util, mas demoniaca que nunca, con mas parches de los que ya tienen a raíz de las anotaciones, enumeraciones y templates (generics a.k.a) introducidos en la versión 5, no confundan, me cuadran, pero el lenguajes no fue pensado para ellas, al menos no, para anotaciones y generics, por ultimo diré que Groovy fue considerado y solicitado por el Java Community como un Fork de Java, al cual algunos le apodan Java 2 y con mucha razón, pues este es un super conjunto de Java, como en su momento lo fue C++ de C.
2) Programador Java que quiera conservar su trabajo como desarrollador en esta área del conocimiento, debe aprender Groovy, pues en el futuro la programacion Java apoyada en ciertos segmentos por scripting, fijo va a ser la moda si no la regla.
3) Para seguir en el futuro, Groovy con sus inconvenientes de desempeño y todo, sera el lenguaje VM mas usado, las cosas que realmente necesitemos "perfomance" seran en Java, asi como hace algunos años, se escalaba el desempeño a traves de JNI y C++, e igual siempre queda ese tercer nivel para lograr aun mejores resultados o cuando la plataforma Java necesita cosas muy especificas del sistema operativo en donde es huesped.
4) Grails: pienso que este enfoque aun esta muy en pañales e inclusive me atrevo a decir que Grails, puede ser un buen intento de algo que fracasará y en el futuro evolucionara a algo mas intermedio, es decir facil de usar pero mas flexible y proporcionando mas control, asi como le sucedio a los EJB version 2, practicamente muertos y relevados por JPA y EJB 3 que es una version super Pojo y sin tanta interface.
Otro punto bajo recae en el hecho que Grails utiliza una serie de framework's que aunque muy buenos y todo, primero no son estandar (aunque no tengo ningun problema con eso ;) y segundo no estoy del todo seguro de la facilidad de meter por ejemplo otro framework de persistencia (aunque por estar con Spring, de fijo se puede, aunque sea fuera del caminito de oro), digamos iBatis y por que iBatis; con base en los comentarios hechos por la gente de LinkedIn, por solo poner un ejemplo de escalabilidad, ellos no usan un ORM por que simplemente no tienen sentido, usan JDBC directamente con unas clasesillas que les apoyan en lo repetitivos, supongo algo como dbutils de common apache, ya que ellos tienen la base de datos distribuida, osea una tabla en una base de datos, otra en otra base de datos, etc; Hibernate hasta donde yo se, no puede manejar este tipo de cosas pues aqui no existiría integridad referencial, para iBatis por el contrario, es una situación perfecta; bases de datos no normales y nefastas, con select moustrosos, venga, a iBatis le vale un comino, simplemente toma el resultado de la consulta y juazzzz, te retorna un bean, si bien no es un ProxyBean y el manejo de transacciones no es el mismo, es mil veces mejor que JDBC y muy util para diferentes escenarios (Notese la aficcion a iBatis, creo que soy un psicopata del control en mis app's me gusta saber que pasa y como :). Y asi pienso que se pueden sacar muchos mas escenarios donde Grails se queda corto, claro no le quito merito, la velocidad de desarrollo y demas, es super cool, GORM y sus campos "buscables", super cool, sin embargo aun permanezco algo retraido a este tipo de soluciones, genera todo. Si me preguntan, Grails te ofrece una solución al estilo .Net, cero opciones, pero funca y rapido, pero con restricciones, en el caso por ejemplo de ASP, no se puede tener mas de un formulario, entre otro monton de pegas, la diferencia es que Grails usa un pseudo Java para implementarlo todo. Jajaja, espero que no me llamen ateo o me acusen de sacrilegio por eso, pero al chile, no quiero ver clientes pidiendome hacer un facebook con Grails en 2 meses.
5) Como Carlos menciono, los test cases son un escenario bastante bueno para introducir Groovy, estoy de acuerdo, pero como comente en el cuarto punto, Grails si se pasa de esa raya. Un enfoque donde los DAOS y Servicios sean Java, digamos expuestos por XFixe o Axis, etc y un Aplicativo MVC, donde Actiones de Struts inyectadas por Spring, sean Script's Groovy o Jython, Scala, etc; con Hot Deployment, seria super cool, de hecho yo lo hago asi y si bien es cierto, el IDE aun le falta bastante y el classpath al compilar a veces queda super perdido, la velocidad para probar y hacer cambios lo justifica.
En resumen, muy buena confe y aguante al grupo de Java CR.
Nos vemos en la proxima!
Saludos,
J
Comentarios
Pero weno, q dicha q le fue bien...
Bendiciones
Por ultimo agradecer tus comentarios y deberias hacer el intento de ir a las reuniones del grupo, son realmente muy buenas.
Concuerdo con jsanca, cuando dice que le gusta tener el control, resulta que si perdemos eso en las aplicaciones, despues no vamos a saber donde modificar o cambiar algo para incrementar el performance, o mejores X o Y caracteristica.
En cualquier caso, creo tambien que todavia esta muy en pañales, como bien lo acoto el colega Carlos Zuñiga, RoR tiene todavia más funcionalidad que todavia a Grails le falta.
Excelente conferencia, y aguante el CRJUG
Por cierto es mejor las convenciones y usar las varas mas comunes sin andarle metiendo tantas personalizaciones ni cambios de mierda, amenos de q estes realmente trabajando en algo de acceso masivo o algo asi que ocupe varas demasiado excepcionales, es mejor mantener las varas faciles de dar mantenimiento y de que cualquier soplas lo entienda luego, que hacer un despiche y compilar tus propios frameworks con cambios o extensiones, para lograr un 9.5% mas de eficiencia, pero q complica la jugada un 80%.
esa es mi humilde opinion de programador no "super genio" .