Saturday, September 11, 2010

Liferay 6 Web Coast Simposium Part 2

Brian Cheung Introduced the LESA system. It is an internal to Liferay team support system that resolves some of the issues JIRA has (for example multiple language support, issue response ranking to give for example 1 star for an engineer saying "won't fix, period", audit capabilities, simpler interface for example just responding is enough to reassign the issue. I asked if the product would be available as open source however there is not decision still taken on this regard.

Mike Hon spoke about plans for the document library like mounting from other datasources (repositories), windows explorer kind of user interface, version control for layouts, workflow engine integration to control document changing. He went through integration of a workflow backed form engine (Workflow forms). There are improvements on Message Center (which is a more complete solution than the email portlet), Contact Center, Expertise Locator: for large developer teams, Knowledge Base, blog (anti spam for example). He gave an introduction of DSL and Drools for portal assets. He spoke about the upcoming "Workflow Designer for Kaleo" a visual tool that will allow to manage workflows. Currently there are efforts to build a console for tomcat a la Websphere management console. There will be broader support for caching technologies. I asked about Workflow forms and expando and the response was that expando is just one of the possibilities for the workflow forms. I had the opportunity to talk to him about Workflow Engine. As it is today is very limited as it does not support any DSL however that seems to be enough for the needs of the community. In addition the workflow engine integrates very easy with Intalio or JBPM thanks to the pluggable architecture so for more complex needs the architecture is pluggable.

I talked again with Raymond about OSGI modularity and liferay and the lack of documentation on this regard. This is because it is indeed a brand new subject that the Liferay team is considering with very high priority. Raymond talked about improvements in WCM. He presented the new WYSIWYG editor. There are better indexing capabilities. Freemarker support has been added for those looking for a better alternative to talk to Java from templates. More things coming up: Support for local and Remote Live environment support, scheduling publishing to update the site just with the delta changes, locale buckets per articles. He showcased on Content Portlet,
Enhanced SEO support through smart tags, support for custom html header (h1, h2...) styles forward compatibility of exported LARs, support for liferay tags (Alloy UI) from Freemaker, very powerful feature indeed. He talked about Site branches: For example brand new skinning of the site been worked out months ahead a time. The reality is as I pointed out that this is more like a fork rather than real SCM. Merging concept for example does not exist and its indeed not needed. Content people (CSS, HTML) are able to work on this without any help from developers. He talked about the Web Based RAD, a neat product coming up (officially still unnamed) which would allow RAD capabilities right from the Web Interface. About OSGI, Liferay will be able to be patched at runtime for example thanks to OSGI. Java Class loaders will not longer be a problem. This will make Liferay of course a more scalable platform. I asked the question about why not using an existing SCM for WCM branching and the response was that pages have other components associated to them and they are all in the database and so they have developed the SCM themselves.

Ivan and Wesley talked about Liferay best practices: LDAP when a user logs in is a best practice as the data is brought into liferay just when it is needed. HA environment: synch ehcache for consistent data on nodes, clustering indexes for consistent search, centralize document library repository. Recommended of course to use SAN/File System option for file storage over DB. It caught my attention the existence of a Data Migration tool Portlet to mitigate the conversion of files to a new document file system. Hardening Liferay: Change admin password, default timezone and locale, default communities and roles.
nightly or hourly backup of DB. Schedule backups, use SCM to store code and Disaster recovery (remote data backups, secondary servers). Disaster recovery: Have a preproduction environment for minimizing downtime. Swap pre and production environments when new features are considered stable. On data changes: Avoid touching data, go always through the GUI and web service APIs, use absolute paths for deployment directory, specify in portal.properties where the liferay home is (license key, lucene search, deployment folder are stored there). On code maintanance: keep core and custom code separated, apply EE Service packs and emergency patches (hot fixes)

James Min talked about Performance and scalability. There is a white paper with data about benchmarks on the Liferay website. He presented the following showcase: 1 http server (xeon qc 2.4GHz, 2GB RAM) 2 app servers (xeon qc 2.4GHz 8GB RAM), 1 db (xeon qc 2.4GHz 4GB RAM, 1HDD 1500rpm). Got user data (1MM) taken from US census data (max 400MM users) ramp up period of 1 user every 100 msec from multiple injectors, warme up for 5 minutes.
They used Grinder from linux servers. For the Login transaction (one of the most expensive operations in the current Liferay implementation) they simulated 3000 users during 30 min and they got responses of second and a half with a maximum of 81% processor utilization. This is a point where it is clear more servers will be needed in the cluster as over 1.5 sec response time would not be a good user experience. For WCM, Message boards, Blogging and other scenarios data is available as well. He talked about standby times like hot-hot, hot-warm and hot-cold. They use VisualVM as a good tool to measure performance. He recommended several best practices to create scenarios that reflect actual usage like having ready load tester and test scenario (configuration, test script). Disaster recovery procedure should be tested every quarter at a minimum. Caching mechanisms: replicated distributed EhCache is available out of the box, just search for Cluster in portal.properties and that is enough to identify how to use cache. More advanced caching would be using sharded distributed cache: terracota and memcached are examples of it. He went ahead and recommended Mika's blog for terracota.


There was also a JSF presentation from Triton lead architect. He is one of the main contributors to the project. Certainly as we both agree this is a good solution for those teams with lack of Javascript, CSS and HTML skills (No front end developer/designer on board). Andy Shwartz blog was recommended. He explained ICEfaces and IcePush, PortletFaces-Bridge was introduced. Declarative programming is what IFaces and JSF in general promotes. He showed the EVENT_PHASE of the portlet API to show inter portlet communication (with the bridge). ICEPush is now bundled with ICE Faces. I asked the questions for the plans towards a semantic markup and that would be resolved with the new widgets in version 2.0 which basically will be based on guess what ... YUI. I asked the question why xml for AJAX and the response was that as there is markup coming back from the server that is a must have. The reality is that I can see Liferay supporting more Icefaces in upcoming versions. The big and most important thing is though to provide as an end result semantic markup.

I spoke to some senior developers and consultants about supporting transactions in Liferay Portal. Now with the increased support at plugin level you can use the Liferay APIs in transactional way. Search for JTA in portal properties to find out how to support transactions in Liferay.

Finally I asked the question to several people backing up the whole environment. Code to svn, WCM in DB etc ... a way for automation? Data Migration tool? and in general that is a difficult task because Liferay is not opinionated but rather is trying to support any environment. I keep on defending that someone must come with a rapid development environment setup (most likely based on Maven) that could allow thousands of developers with scarce resources in their teams to catch up with Liferay way of developing fast enough. America at least is driven by small business and teams of 4 developers are more common than teams of over 20 developers. If the learning curve is high Liferay will not be addressing a broader community that could give up for more agile frameworks and languages in the near future.

One of the aanouncements was aboutFacebookConnect supported as opensso solution (OAth 2.0). I asked the question because I keep on writting and consulting about this: True SSO is not just a transparent login, it must implement keep alive and logout for a complete reach user experience. The Facebook solution is so far a transparent login and not a real SSO solution.

Brian Kim taked about Partner recognition and Brian Cheung concluded with a funny history of the company. I really enjoyed this part. It reminded me my trip to Rome and staying in a hostel very similar to the one he described. I found out how the Liferay logo comes from what we call in spanish "Vitros", those sensational glasses you find in Churches.

Jeff Handa talked about Liferay templates (page and site templates) This is an important step that addresses the issue of creating from scratch whole coomunities, pages and portlets. LAR import/export is not enough. Page templates Admins can define permissions on those templates and also other settings like Page type, layout template, portlet placement and configuraton. All that then can be reused when creating new communities. When creating new pages a drop down allows to pick the template provided you have permissions to view them. Site Templates (similar concept but for a collection of pages) were also visited. These features are available programatically: Service Builder managed entities(LayoutPrototype, LayoutSetPrototype) See the code for default-site-templates-hook to see how to use this programatically. See util classes LayoutLocalServiceUtil LayoutPrototypeLocalServiceUtil. Somne recommendations provided: Establish good naming conventions when building templates and set the right permissions from the beginning. Once the templates are used to create a new community they become final sites and pages and so they not longer get updated after changes.


Greg Amerson presented a workshop on Liferay Development Studio. Showed how to point to the portlet SDK. Support for Maven is coming up before the end of the year. He has published several videos online showing how to use eclipse liferay Interface. He mentioned that under the hood velocity templates are responsible for the magic behind the wizards and he has plans to expose that to the community so developers can create their own more complicated wizards. This will increase productivity for sure. He mentioned he will try to fix in the future the false negatives (red exes) that eclipse shows up on JSPs. Seriously I will follow up on this one with him, JSP support in Eclipse is not good in comparison with Netbeans and that is well simply not fair ;-)

Hope this post was large for something. I congratulate again the Liferay team for the effort they are making and I got a very positive experience from the Simposium. Hopefully Liferay will become an agile tool no matter its completeness and complexity.

6 comments:

Paul Hinz said...

One change - the name of the new support applications is LESA (Liferay Enterprise Support Application). We like the sound of LESA ;-)

Nestor Urquiza said...

Hi Paul,

Nice hearing back from you! I have corrected the post.

Cheers,

-Nestor

Unknown said...

Nestor, I know it was essentially a developer-centered symposium, but was there any talk about benefits for designers apart from abandoning table-based layouts for divs?

As you know, our own attempt at liferay is a nightmare for me as a designer. Without easy access and full customization of 100% HTML and CSS, I wonder if designers are going to keep migrating to the PHP world where they're attracted by CMSs that focus on being designer-friendly (like Expression Engine or even Drupal).

Without full HTML/CSS control, a designer can't address all the concerns that modern web apps should embrace: cross-browser compatibility, rich user experiences, accessibility, mobile support.

I always suspected that perhaps our own problems were simply due to starting with themes that were already bloated with bad html/css rather than simple and semantic portlets.

Nestor Urquiza said...

Hi Jorge,

You have total control of the markup of the site through themes.

Just modify your portal_normal.vm file (a velocity template).

This file should be updated in the _diffs directory, for example:

/your-liferay-path-to-plugin-development/plugin/themes/your-theme/docroot/_diffs/templates/portal_normal.vm

The file contains the whole structure of the site (starting at the doctype and enving in the closing html tag).

Of course you need to deploy the theme and be sure it is included in Liferay.

You can modify completely liferay without any doubt. Take a look for example to http://www.sesamestreet.org/ It has nothing similar with the traditional Liferay sites, still a liferay site.

Cheers,

-Nestor

hiena said...

Nestor,

I agree with Jorge. Portal_normal.vm is just a part of designing whole portal. Portlets don't use velocity (Asset use them ONLY for showing full text of web content), their code is bloated with bad html (even with nice looking Alloy UI) and you can't change that with themes. That is why Liferay is not designer friendly. Maybe they should MVC in portlets?

Nestor Urquiza said...

Hi "hiena",

I have written about portlets and the correct (IMO) way to develop them to keep separation of concerns ( http://thinkinginsoftware.blogspot.com/2010/07/liferay-refactoring-moving-existing.html )

I have not used Liferay 6 so I cannot tell how much of the new code is actually plugin-environment-friendly. One thing for sure is that the first step towards agile development in Liferay is related to having all portlets natively in the plugin environment.

It is easy to accomplish MVC in the plugin environment. With Liferay 6 support for JSR268 you could even have a full BHUB approach ( IMO AJAX the right way ) Regardless if you use JSPPortlet, MVCPortlet, Spring or Struts your backend developers should be able to provide good MVC code for the framework to be designer friendly, I agree.

I recommend you raise this question in Liferay forums, I would appreciate if you provide back some feedback as to what you get from the Liferay team.

I personally keep developing my backend out of Liferay and use Liferay just for those out of the box features it would take me forever to build. I would like of course Liferay to have all out-of-the-box portlets using the plugin environment so I could have a softer time with Designers. Unfortunately that is still hard (better though with Liferay 6).

You mentioned AlloyUI. Is there any bad markup comming out of the AlloyUI tags? I think you are rising an issue related to Liferay embedded portlets where even though they use AlloyUI and the markup got better there is still bad markup (out of AlloyUI) that stayed there and that is difficult to change as the portlets are not developed using the plugin environment (which allows a Designer to literally drop CSS/JS/HTML/GRAPHICS without even restarting the server, a must have in agile Java software development)

Thanks!
-Nestor

Followers