jueves
oct042012
Publicada la agenda del Symposium de Liferay en España
liferay
Liferay Symposium MadridYa está publicada la agenda definitiva del Symposium de Liferay en España que se celebrará en Madrid los próximos días 24 y 25 de Octubre. Puedes consultarla aquí:
Las sesiones programadas este año incluyen la intervención de Jesús González-Barahona, profesor de la Universidad Rey Juan Carlos y uno de los más prestigiosos expertos en tecnologías Open Source, que ofrecerá su visión sobre "El papel del software libre en la empresa". También estará presente Rodolfo Carpentier, business angel y visionario tecnológico de relevancia en nuestro país, que se adelantó a identificar hace ya unos años el potencial que ofrecían las redes sociales y las compañías que desarrollan su negocio a través de Internet como Tuenti, Xplane o Buy Vip. Carpentier centrará su ponencia en las claves para el éxito en "La empresa del siglo XXI".
El lema del Symposium, "What will you build?" ("¿Qué quieres construir ?"), aproxima la idea de que todo aquello que quieras crear en Internet, tanto para clientes, como para empleados, proveedores o socios, lo puedes hacer con Liferay. Las últimas funcionalidades añadidas al producto, ejemplos y prácticas reales, así como nuevos servicios y modelos de negocio serán también protagonistas. Además, el Symposium contará con la participación activa de la comunidad Liferay, a través de ponencias y demostraciones presentadas por desarrolladores y expertos nacionales, seleccionados específicamente para esta ocasión.
Por cierto, si tienes un blog y quieres asistir al evento, Liferay está regalando entradas a bloggers tecnológicos. Si estás interesado/a y tienes o escribes en un blog tecnológico, date prisa en pedirla porque no hay muchas entradas y el plazo acaba el 10 de Octubre. Tienes más información aquí: http://www.liferay.com/web/spain2012/freepass
Reader Comments (13)
Recordamos que existe una oferta en el foro de empleo sobre Liferay, y que yo, aquí en Madrid, veo que suena bastante. Yo personalmente no lo conozco, la verdad.
Yo pasé el año pasado metido en un proyecto de Liferay, y mis impresiones son mixtas:
A favor: incluye bastantes componentes que hace posible un sitio web atractivo en un tiempo reducido; la interfaz de administración no está nada mal; toda la aplicación está realizada con portlets; tiene una comunidad bastante activa; incluye un SDK para desarrollar portlets desde Eclipse, modificar los que trae de serie, generar temas (el aspecto) nuevo, etc.
En contra: muchos bugs, sobre todo cuando empiezas a modificar los portlets de serie; desarrollar con el SDK te ata a Liferay; producto complejo con mucha tecnología (los de siempre: Hibernate, Spring, etc.) - algo inevitable para ofrecer la funcionalidad que tiene, pero limita el desarrollo a Javeros con cierta experiencia / habilidad.
La pregunta obvia: ¿Me gustaría trabajar con LR de nuevo? La verdad es que no lo sé, no es lo que más me interesa en estos momentos, pero si tuviera que meterme de lleno en un proyecto J2EE no sería lo peor que me podría pasar...
Estoy bastante de acuerdo con Jim cualquiera que ha trabajado con Liferay a bajo nivel, es decir usando su API en Java, le queda una sensación mixta.
El relativo éxito de Liferay es consecuencia de tres cosas:
1) Open source, gratis, free (la versión community)
2) Las alternativas o son muy pobres o son muy caras y encima peores (según dicen), es decir no hay prácticamente ninguna alternativa Java de bajo de coste decente.
3) La tecnología de portales entra por los ojos al gestor pues ofrece muchas cosas "out de box" (otra cosa muy muy diferente es programar sobre ellas), gran parte de la buena prensa es debida a implantaciones que apenas tienen una línea de código, cuando se entra fondo en el desarrollo sobre Liferay ya no es todo tan bonito.
Es decir no son méritos exclusivamente propios, que no digo que no tenga.
Algunos aspectos negativos de los que me acuedo:
Respecto a los bugs ciertamente tiene toneladas de bugs, el problema es que muchas veces en temas muy básicos, es difícil encontrar una funcionalidad sin un bug importante (hablo de versiones 6.0.x).
Tiene carencias de documentación monumentales, básicamente Liferay te expone su API interna y allá te apañes, con el tiempo vas entendiendo su modelo de datos pero es todo un ejercicio de ingeniería inversa, en muchas muchas ocasiones la única opción para entender algo era ver el código fuente de Liferay.
El problema de rendimiento brutal del Document Library en 6.0.x nos dio un muy severo disgusto hasta que nos dimos cuenta de "no éramos nosotros" los que estabamos haciendo algo muy mal (hasta entonces las broncas circularon...). Afortunadamente es un tema que se solucionó en la 6.1
Las dynamic queries si usas su sistema de modelado de datos (Service Builder), son un chiste, Liferay internamente hace miles y miles de joins, pero la API pública de acceso a datos, incluso a tus propios modelos de datos (usando el Service Builder) que son las dynamic queries, no admite joins. Ciertamente hay formas de saltarse la capa del Service Builder pero tienes la sensación de hacer hacks y forma parte de las internalidades peores documentadas y más obscuras.
A medida que añades entidades el generador de código del Service Builder se ralentiza exponencialmente y en general cualquier cambio en las entidades suele significar generalmente un cambio manual o eliminación manual de clases generadas. El Service Builder es un ejemplo de libro de que la generación de código destinado a ser modificado suele ser casi siempre una muy mala idea.
No hay manera de tener transacciones en tus entidades y a la vez con las de Liferay Liferay internamente es siempre transaccional, la transaccionalidad en Liferay es CRITICA porque liferay renuncia a la integridad referencial por rendimeinto. Por la naturaleza de la coordinación de aplicaciones web necesitas usar transacciones distribuidas (JTA) con JOTM o Atomikos. Atomikos nunca funcionó y JOTM daba errores de timeout con el tiempo, mi sensación después muchas y muchas horas de pruebas y blogs es que "nadie" llega a tener transaccionalidad completa. Al final te toca deshacer las operaciones en caso de fallo de forma manual.
La transaccionalidad de las operaciones se rompe con extrema facilidad en los métodos tuyos persistentes gestionados por el Service Builder, si dejas subir una excepción que no sea System o Portal adios transacción, no se hace rollback absurdamente, por lo que puedes dejar incosistente fácilmente la base de datos. La solución es try/catch a todo lo que se mueva y envolver en System o Portal.
Tiene un problema de cachés muy serio del que parece que no habla nadie, es difícil estar en contra del uso de cachés pero hay que asumir plenamente las consecuencias de su uso, en el caso de Liferay si todo va bien aporta un gran rendimiento, pero si algo falla la transacción de Liferay deshace todo PERO NO en las cachés dejando información inconsistente. Solución: evita que haya un solo rollback, es prácticamente imposible pero es la única solución (o limpia las cachés tras cada rollback que controles lo cual roza el absurdo pues hace que las cachés sean prácticamente inútiles).
El redeploy en caliente cuando se cambia algo (un JSP, una clase Java) via SDK era terrible y absolutamente improductivo, tuvimos que utilizar una técnica alternativa de actualización porque era imposible trabajar (cambiar un JSP o una clase Java y esperar minutos a la actualización), dicen que mejoró mucho en versiones superiores del SDK, no llegué a verlo.
Mi opinión muy resumida es que tienes la sensación de producto que se podría hacer mucho mucho mucho mejor.
Esto ya es una reflexión filosófica: la tecnología de portales fue concebida en la era pre-AJAX y se nota, prácticamente todo incluidos los portlets de Liferay están concebidos para la navegación paginada y en general el uso de AJAX es anecdótico, el que hagas click en un portlet para cambiarlo de estado y todo se recargue (menues, los demás portlets) no es muy del siglo XXI.
Otra reflexión filosófica más: toda tecnología que te da mucho hecho tiene el riesgo de que acabes luchando contra la filosofía de la herramienta, es conveniente adaptarse en lo posible al paradigma de la herramienta pero eso puede dar lugar a que el cliente empiece a oir "esto no se puede hacer en Liferay", la alternativa es luchar "contra" la herramienta para forzarla a un comportamiento muy diferente al concebido o a veces simplemente "rehaciendo", es entonces cuando te planteas si la elección es buena. Esto no es problema de Liferay, es de cualquier tecnología pero Liferay es mucho más invasivo y de alto nivel que la mayoría de las herramientas que se suelen usar en el día a día.
Y otra más: un aspecto negativo y positivo a la vez es la enorme flexibilidad de la tecnología de portales (portlets), si en una aplicación convencional (rígida) basta actualizar del repositorio de código y ejecutar para tener ya el sitio web/aplicación funcionando prácticamente idéntico a como está en producción (pero vacío en datos claro), en la tecnología portlet montar una réplica de producción vacía sin datos tanto para trabajar en local como para implantar en otro lugar, no es en absoluto inmediato porque las comunidades, las páginas, los portlets de cada página etc son también datos, en Liferay se pueden hacer "copias" de páginas etc pero aún así no es trivial. Como decía antes esto no es necesariamente negativo, es simplemente el precio de la flexibilidad.
La parte buena:
- Coste: 0 (community), casi todas las quejas, muchas, se amortiguan mucho con este factor.
- Gestión de usuarios, de permisos, blogs, document library (CMS), sistema de comentarios etc, etc muchas cosas hechas e integradas
- Una extensibilidad cojonuda, aunque a veces llegues al absurdo de copiar código fuente de Liferay para hacerlo funcionar de forma diferente, el tener esa opción es fabuloso aunque sea jugar con fuego.
- Está ahí para quedarse
Yo también tengo opiniones encontradas sobre Liferay.
Para mi gusto le falta toda la documentación y que su SDK se base en Ant, a día de hoy, no me parece ni medio lógico. Se qué hay archetypes para algunos tipos de plugins, pero para el extlet no.
Sobre lo que comenta jmarranz de las transacciones, no he tenido ese problema. Siempre y cuando las hayas configurado bien y tus llamadas sean de *LocalServiceImpl a los múltiples DAOs no le he encontrado problema. Nunca he usado transacciones XA u otro tipo de distribuidas en Liferay.
Sobre las caches, no es un problema 100% de Liferay, parte está en el funcionamiento de ehcache y en cómo lo configura el lportal. El tema está en que sí hacemos un get para la clave X, todas los gets para X quedan bloqueados esperando a que el primero haga un set del valor. En caso de excepción se setea un null y con eso ehcache libera los bloqueos. Igual estoy contando algo que ya sabes o que no tiene que ver con el problema, pero lo comento por sí sirve de algo :)
Mi queja principal esta en las mil ñapas que hace para conseguir funcionar en distintos contenedores. En IBM WAS es un despropósito completo, sobre todo sí rebajas con varios nodos. No puedes desplegar la web app de nuevo porque no es capaz de eliminar los beans registrados en el manager jmx (el WAS modifica los identificadores con el nodeid y otro parámetro más que no recuerdo), la gestión del pool jdbc del WAS tenía problemas con la devolución de conexiones,etc.
Y mi queja secundaria va en contra de la implementación del "nuevo" estándar de portlets, sobre todo de la parte de publicación de eventos y parámetros compartidos/globales. Es otra chapuza y es excesivamente enrevesado de configurar bien.
No está de más conocer este sistema de portal, pero si puedo evitar trabajar con el, lo hago. Pero tampoco me parece el peor agujero en el que puedes caer.
Otra cosa que se me olvido comentar sobre el tema de las caches que comenta jmarranz y las limpiezas de cache es que Liferay trabajando con ehcache en distribuido hace un clear de la cache (de la propia entidad) cada vez que se hace una modificación, no se hace una actualización, si no que en los otros nodos se fuerza un vaciado completo, lo que provoca un porrón de misses.
Esto también se puede cambiar, obviando el tutorial pasoapaso de modo distribuido, en el fichero de configuración de ehcache. Pero aún así sorprende que sea el comportamiento por defecto para este escenario
Samuel respecto a lo de Ant una reflexión: ¿te has preguntado porqué herramientas con procesos de deploy más o menos complejos tal y como Liferay SDK y Android SDK siguen utilizando Ant y no Maven? ¿es porque no son gente "moderna"? Maven es el tipo de herramientas que hacen trivial lo sencillo e imposible lo complicado, el problema es que casi nunca las cosas son sencillas.
Respecto a las transacciones me alegro que no las hayas necesitado, las transacciones son como el que te dice:
"Yo he trabajado de albañil en edificios de muchas plantas y nunca he usado arnés y cuerda"
"Yo conduzco a toda máquina sin cinturón de seguridad y con el air-bag estropeado y nunca los he necesitado"
Si lo puedes contar ciertamente es que no lo has necesitado.
Yo por desgracia sí he notado "su ausencia" en mis entidades a través de registros huérfanos e inconsistentes que hacían fallar la página de turno, porque no siempre es fácil detectar todos los posibles casos de error y hacer eliminaciones manuales.
También en las entidades de Liferay "por mi culpa" lo cual es mucho más grave, un simple NullPointerException en un método persistente (con transacción en las entidades de Liferay) y la transacción no hace commit y voila comunidad creada bajo demanda creada a medias por ejemplo sin páginas asociadas...
Si encontraras un flag que desactivara las transacciones en el núcleo de Liferay pon el cronómetro y calcula lo que duraría la DB sin corromperse, esto es aplicable a cualquier aplicación con base de datos minimamente complicada y sin integridad referencial. ¿Te has planteado por qué TODAS las entidades de las aplicaciones web de Liferay residen en la aplicación ROOT aunque sean usadas en aplicaciones web diferentes del propio Liferay? habrá más razones pero una de ellas es evitar la necesidad de transacciones distribuidas y usar las normales JDBC (gestionadas por Hibernate), el problema es que tus entidades tienen que definirse fuera del núcleo si o si.
Mi comentario anterior es aparentemente muy crítico y ciertamente lo es, pero el balance global no es necesariamente negativo, ***al final salen las cosas y funcionan aceptablemente bien***. Cualquiera que vaya al Symposium sólo verá bondades y casos de éxito, es raro que te inviten a una charla titulada "Liferay arruinó mi proyecto" :)
por lo que no está mal tener una visión más completa y el lado gris (que no negro) que ni el usuario ni el manager no técnico suelen ver :)
Ya que llevo mas de 2 años peleándome con Liferay daré mi opinión.
Liferay es un entorno realmente productivo, pero solo cuando lo dominas realmente bien. Es decir, lo que comenta el amigo jmarranz. Tiene bugs ocultos, la documentación realmente completa es el código fuente, y tardas mucho en que las cosas empiezan a salir, pero una vez que pasas por eso, de repente empiezas a ser extremadamente productivo.
-Te permite un sistema de desarrollo muy modular, en el que puedes ir creando aplicaciones de varios portlets, que comparten navegación, usuarios, permisos, categorización... con lo que la sensación de integración entre ellas es muy alta.
-Te da toneladas de funcionalidades ya hechas, que es verdad que en algunos casos hasta que las consigues enganchar sudas la gota gorda, pero esto evidentemente te pasa la primera vez.
-Todo el tema de montar páginas menús, contenido html, navegación te lo gestiona, y muy bien. Pero ocurre que añade una serie de capas de complejidad que al principio parecen excesivas, y luego cuando tienes el peazo portal agradeces.
Pero eso si, si abordas un proyecto en Liferay que no sea usar lo que viene por defecto, busca "expertise".
Si sirve de algo, los sudores que pasamos (y que en su momento pasó jmarranz con nosotros), han servido para que tengamos clientes muy satisfechos.
Hola,
Soy Jorge Ferrer de Liferay. Quería agradeceros los comentarios tantos positivos como negativos que habéis realizado. Nuestro objetivo es siempre seguir mejorando el producto y este tipo de comentarios nos ayuda tanto a saber tanto qué estamos haciendo bien como qué necesitamos mejorar. Liferay es un producto muy ambicioso que se usa para una gran variedad de tipos de sitios y portales web distintos, funcionar sobre cualquier servidor de aplicaciones y base de datos, incluir mucha funcionalidad de serie, ... por lo que es complejo cubrir todas las necesidades o acertar siempre en los decisiones. Lo que siempre intentamos es escuchar a la comunidad y corregir los problemas lo más rápidamente posible.
Estos días he estado preparando una ponencia"Liferay Architecture: Understanding the inside of Liferay" donde se explican muchas de las decisiones internas de desarrollo del producto (uso de transacciones, serv. apps, caches, ...) . La impartiré en el symposium y también se subirán las transparencias a la web después del evento. También hay otras ponencias muy interesantes relacionadas con lo que comentáis, como por ejemplo una sobre la infraestructura de pruebas automatizadas que hemos montado para poder hacer pruebas unitarias y de integración de una aplicación web tan compleja (y que creo que será útil incluso para los que no usan Liferay).
Tengo algunas invitaciones al symposium para miembros de la comunidad por lo que me gustaría aprovechar estos comentarios para ofrecéroslas a vosotros para que vengáis al evento gratis y podamos charlar con más detalle sobre vuestras ideas para mejorar el producto y conocer a otros miembros activos de la comunidad. De esa manera la próxima vez que hagáis un proyecto con Liferay (y si todo sigue así, es posible que cada vez sean más) en lugar de enfrentaros a esos mismos problemas, sabréis que están corregidos gracias a vuestra colaboración.
@jmarranz, supongo que lo que comentas es una queja general a este tipo de eventos, pero nosotros intentamos que sea diferente. Creemos que el objetivo del symposium es que todo el mundo aprenda tanto a saber cuando usar y cuando no usar Liferay así como qué hacer para que mi proyecto con Liferay tenga éxito. Los que hayan atendido otros años podrán confirmar que en los casos de clientes por ejemplo se habla tanto de lo que ha ido bien como de lo que no. Igualmente en las sesiones técnicas avanzadas del producto decimos tanto lo bueno como lo que sabemos que debemos mejorar y lo qué se está haciendo para ello. Si aún así piensas que el symposium no es interesante hay una quedada del grupo de usuarios el día 24 donde puedes hablar con desarrolladores de proyectos Liferay tomando unas cervezas (o equivalente).
Bastante de acuerdo con lo que dice janatic (los sudores que pasamos entonces espero que sean ahora mucho menores) las cosas salen si consigues lidiar con las muchas cagadas internas (janatic sabe de que hablo) :)
Algún problema que citaba arriba parece que se ha ido arreglando en la 6.1.
"han servido para que tengamos clientes muy satisfechos" de eso último me alegro trabajo costó :)
Jorge hemos escrito el comentario a la vez
Hombre Jorge yo no llegaría a decir "queja", es normal que un evento que organizáis vosotros sea para empujar vuestros intereses, que favorecéis que se muestre la realidad más allá del marketing pues me parece genial, yo ahora estoy en otros mundos (Android) pero en su momento sí me hubiera gustado y creo que alguno pasó pero no me acuerdo si estaba liadísimo (eso seguro) o si era un poco carete :)
Si me permites un consejo: estoy seguro que perdéis muchos muchos clientes directos o indirectos por no cuidar el lado del programador, si te fijas mis comentarios apenas hablan de temas de un nivel muy básico, no entro a valorar la arquitectura ni la API ni nada, ese tipo de cosas deberían estar resueltas aceptablemente ya en la v2.0 y no hablo de curva de aprendizaje. Es verdad que para vender hay primero que pasar por el management no técnico pero al final casi siempre surge la necesidad "maldita" de "customizar" la criatura y no todos los programadores y equipos técnicos tienen un "nivel heroico" para asumir algunas deficiencias.
jmarranz, a lo que me refiero sobre Ant no es que lo sustituyan por Maven, pero hay sistemas más modernos compatibles con la descripción declarativa de procesos del Ant y con una gestión de dependencias sea más avanzada: Apache Ivy, por poner un ejemplo.
Además, el uso del SDK de Ant dificulta el configurar y montar el entorno para los desarrolladores si no quieres tenerlo todo en el SCM, ya que te obliga a mantener un conjunto de carpetas y una estructura fija.
Sobre el tema de las transacciones, cada vez que he necesitado persistir modelo propio y modelo de Liferay en una misma transacción siempre lo he hecho desde el ext. El Ext (o extlets como se llaman ahora) permite aprovechar la misma transacción que el portal, evitando así la transacción distribuida. Desconozco tu necesidad o tu motivo de haberlo hecho desde fuera, pero sí es cierto que tiene bastantes problemas directos el tener esas dependencias (asimismo el efecto secundario de las cachés).
Otra cosa que hemos visto es el problema con el deploy de los extlets (en la versión 6.1). Si existe el fichero descriptor del extlet en liferay (es decir, si has desplegado alguna vez el extlet y se ha copiado el XXXXXX-ext.xml al $TOMCAT/ROOT/) nunca llega a desplegarse de verdad. Para darme cuenta de esto he tenido que llegar a ojear el código de deploy de Liferay.
Igual que hay cosas malas, también las hay buenas. La mejora del sistema de permisos con el tema de la comparación con máscaras (creo que esto fue cosa de Raymond Augé) y la integración son Solr (aunque un poco verde todavía) son partes a destacar.
(otro doble post........)
jmarranz, no me preocupa que tu post sea crítico ni yo, con mi comentario, pretendo hacer crítica sobre el tuyo, más bien intento exponer mi experiencia sobre los problemas que comentas, porque puede que tú no desconozcas algún aspecto o que yo esté equivocado (y espero que me corrijas) en algo y pueda correjirlo, evitando darme de bruces en un futuro.
Creo que parte de la gracia de esto, como comenta Jorge, es intercambiar experiencias.
Buenas noches,
Yo no llevo mucho tampoco con Liferay, cerca de un año, y coincido también con el hecho de que, ciertamente es un producto que, como muchos, cuenta con sus ventajas y con sus desventajas.
Pero con lo que me quedo asombrado, es con la gran cantidad de cosas raras, a veces contra natura, con las que me topo: capas que no permiten inyección (¿aún trabajando sobre Spring?), clases css anidadas (¿por qué?), actions que no son tal sino que resuelven a pelo contra una cadena (¿y Struts?), forzar la mezcla del esquema de base de datos del portal con el del negocio (que se puede externalizar, pero el artículo de la wiki de como hacerlo es "algo denso"), ...
Como CMS funciona bien: han puesto empeño en ofrecer un diseño atractivo, han cuidado la maquetación, te dan la opción de ignorar el AlloyUI, ... Pero como herramienta para el desarrollo, es lo más parecido a un WISIWIG para programadores que he visto nunca.
Si tengo que volver a trabajar en un proyecto de Liferay, mi recomendación será sin duda montar el backend en un servidor a parte.
Un saludo, y disculpadme si digo muchas tonterías.