These are the top ten reasons why you should use tagging in CQ5:

10. CQ5 is great when dealing with structured information thanks to the nesting of pages and paths. It is also great when dealing with unstructured information thanks to the built-in full-text search. Tagging allows you to combine the strengths of structure and flexibility.

9. Tags have many names and faces: tags, taxonomy terms, categories, labels and many more. They are flexible in their content model and flexible in the way they can be used, for instance for outlining target demographics, categorizing and rating content or to create a secondary content hierarchy.

8. Tags can be created by anyone who needs a quick way to annotate a page. This helps you with search-engine optimization, as tags will automatically show up in the meta-tags of the page, and ensure your page will be found by search engines.

7. Tags combine Web Content Management, Digital Asset Management and Social Collaboration. The tagging system is a core component of CQ5 and it is used by all CQ5 Applications to categorize content. Additionally it is available to developers for their own tagging-enabled applications.

6. Tags can be simple and sophisticated at the same time. To create a tag all you need is a word and the touch of a button. That's simple. But afterwards you can add a title and description to it to add more semantics. There are no limits on the labels you select for your tags.

5. Tags improve your search experience. You can search for tags and for content that has tags. This is used in CQ5's default search component, so your users can drill down to see only the results that matter in the search result pages.

4. Tags powerful organizators. With the ability to create tags and sub-tags it becomes possible to express whole taxonomic systems of terms and subterms and their relationships. This allows you to create a second (or third) content hierarchy next to the official one.

3. You can never have too many tags. And if you have, you can create namespaces to sort and organize your tags. With namespaces you can make sure that tags that belong together are together and create categories of tags.

2. Tags can be controlled. With all the flexibility and simplicity of tags, you have still full control over all your content. Apply permissions to tags or namespaces to control who can create or use your tags.

And the number one reason why you should use tagging in CQ5 is:

1. Tagging makes your life easier by giving you a better way to organize content without too much thought.

Mark Baker who recently joined Day as a Senior Solution Engineer has been interviewed about the REST architectural style by Jon Udell.

Very well worth listening to, especially if you are interested in REST in the enterprise. Also, there is SOAP vs. REST, HATEOAS, B2B message exchange and the question if REST is equivalent to "Get an API key".

Mark Baker has always worked with distributed systems, starting with DCE and CORBA. When he learned about the Web's REST architectural style, he embraced it as a better way. When the Web Services movement veered away from key RESTful principles -- a uniform interface, hyperlinked representations -- he campaigned vigorously for them. Now, he tells host Jon Udell, REST has won the web, although not yet the enterprise.

The tweet says it all:

We launched our website on Day's CQ5 platform. Check it out: http://www.citytechinc.com

Congratulations guys, the site looks great!

In the last months I had the nice and interesting opportunity to try out several portal servers - ranging from open source to the big commercial ones. As a summary upfront, the first time experience of nearly all solutions is REALLY ANNOYING; in some cases it's unbelievable how poor and confusing everything is. Just as a disclaimer, this is my personal opinion after playing around with these servers for just a short time.

But let's be more precise...I started with looking for open source portal servers implementing the JSR 286. Due to bad experience in the past I avoided the JBoss portal (this might be unfair as my experience is two years old.). Apache Jetspeed does not support the standard yet, so I looked for Exo and Liferay. I think their web sites are overloaded, they look too much like a brochure for me and getting to the real downloads requires too many clicks.

After downloading Exo, I found a nice README in the root directory which tells you briefly how to start the portal and what the admin credentials are. Nice and easy. Unfortunately after starting the whole thing, I got lost as I found no way to deploy my portlet. Afer downloading the docs (again some clicks) I found out that the downloaded version does not support the deployment of portlets through the UI. I think deployment through the UI is a number one feature. So I immediately stopped here and went to Liferay.

They have the same shiny web site, sigh, and after downloading you have "something" extracted. The provided README is the Apache Tomcat README, so no real clue about how to start this thing. As I'm able to start Tomcat and know the default port I could get the portal running easily. Looking for the admin credentials required to download the docs and search for it. It took me some more reading that for Liferay everything is a plugin, even a portlet. So I uploaded my portlet through the UI and got it running immediately. I didn't found any spec related problems with my portlet, however the AJAX based UI of Liferay seems to have sometimes problems with render parameters.

Then it was time for the commercial ones. Fortunately I had someone else downloading and installing WebSphere and Weblogic Portal for me and providing me the admin credentials. Of these two, WebSphere is slow, has an overloaded admin UI, but deploying your portlet through the UI is nice and easy. I didn't found any spec related problems. Nothing more to say about this one :)

But the nightmare of every portal developer is Weblogic Portal. It seems to be even slower than WebSphere, is full of bugs and has a more than overloaded and unstructured admin UI. There is no menu for deploying a portlet. So I went to the website, and really got lost. It took me some time to find a small guide explaining how to deploy JSR 168 portlets...hmm but I had a 286 portlet. Ok, let's try it anyway. The unbelievable thing is that the UI for uploading a portlet is not linked from the portal admin console. It seems that this vendor is rather ashamed of having this. And after you type the secret url in your browser, you know why. Honestly, I'm really bad in doing nice looking html pages, but I think I could have done even this one better. Ok, good looking is not important in this case, so I ignored that and happily uploaded my portlet. Then I knew why these things cost a fortune....it took the server three minutes to deploy my little portlet - at least that's what was displayed after three minutes. So back to the real admin console and trying to find my latest deployed stuff...hmm, where is it? Ok, consulting the same docs again, it explained that I have to configure a WSRP provider. Wait a minute...did you say WSRP, like in WSRP = Web Serices for Remote Portlets? Oh well, my portlet is running locally (hopefully), so it makes sense to configure something running remotely. Indeed. Shrug, just follow the docs and you will find success...of course, not! Ok *something* is wrong. Now, if you've seen one of these server beasts you know that they have a separate server console where you can see and configure millions of things (the more configurations you have the better the product is, I guess), so after several clicks I found out that my portlet application had not been deployed correctly. How could this be? It wasn't my fault, so it should be the servers fault..ok to keep a really long story short, in order to deploy a portlet application you have to copy it physically to the hard drive on the portal server, invoke the browser based UI and upload the application through the browser (again). This must be some strange security feature or one of those evil developers still laughing today in his cubicle about this funny joke he did. (Oh and btw, don't use Firefox 3 to upload your portal applicaiton, the server is not capable of handling the requests correctly...but fortunately the server happily accepts the requests and pretends that everything is fine)

Ok, but the best part was still to come. I went back to the portal admin console, configured the WSRP consumer (still, can someone explain me why? - ok, I've an idea why it could be this way, but I think it's wrong to impose technical decisions on the UI.). From here everything went smoothly, I configured the portlet, added it to the page, got some server crashes and broken pages and finally came to the page with my portlet. Remember that this was a JSR 286 portlet deployed through the JSR 168 import tool? Ah well, everything went fine until my portlet should render itself. Some wired exceptions occured.

After some experiments it turned out that the server exposes the portlet 2.0 API and is able to deploy portlets relying on this API and using the new deployment descriptor. And if you inspect the API version from within your portlet it confirms to be a 2.0 compliant portal server. BUT as soon as you invoke a 2.0 feature you get an exception. I have zero idea what the intension of such an implementation is. Perhaps it's again this developer in his cubicle? Or is it a whole team making fun of dumb users like me?

So after reducing my portlet to just use JSR 168 features it nearly worked - except for some more quirks and errors in the implementation of the spec. As a summary, I don't want to use the WebLogic Portal server again.

In general, Liferay seems to be a good open source solution, if they only would add a small README to the downloaded archve. Without a deployment functionality, Exo is of no interest for me. If you're into complicated UIs, slow running servers with zillions of features noone needs, use WebSphere - forget about WebLogic. The portlet API 2.0 spec compliants seems to be given with Liferay and WebSphere. So now I'm waiting for Jetspeed to finalize their support :)

Since I have recently been involved in a number of performance optimization exercisesI dug up some ancient slides on the "CQ Performance Optimization Methodology" and compressedthem methodology to five very simple rules that can be followed to avoid performance issuesfrom the get go.

It is important to understand that these rules apply mostly to web projects in generaland I think this guide is mostly relevant to project managers and managers to ensure thattheir projects do not turn into being performance challenged when launch time comes.

Rule #1: Plan.

While one would assume that it is obvious to plan for performance optimization it isa matter of experience to understand how to plan for performance optimization the rightway

In my experience there it is good practice to leave a around 10% of the projects effortsfor the performance optimization phase. While depending on the level of complexity of yourproject and the experience of your project team you may not use up the allocated time itis definitely good practice to plan for it.

I always recommend to have a soft-launch to gather real-life experience without havingbig communication internally or externally to avoid additional "political" pressure if possible

Once you are "live" performance optimization is definitely not over since this is thepoint in time where you experience the "real" load on your system and it is important toplan for "clean-up" from a performance stand-point after the launch.

Since your system load changes and the performance profiles of your system shifts overtime I definitely recommend to do a performance "tune-up" or "health-check" every 6-12 months.

Rule #2: Iterations.

Performance tuning is an iterative process that involves, measuring, analysis, optimization and validationuntil the goal is reached. It needs to be planned that way.

Try to implement an agile validation process in the optimization phase rather than aheavy-weight full blow testing after each iteration. This largely means that the developerimplementing the optimization has a quick way to tell if the optimization actuallyhelped reach the goal

one more thing: If you reached your goal, optimization is over.

Rule #3: Goal.

To get a good solid performance goal really is one of the trickiest areas, but I wouldreally recommend to get real-life logs from a comparable website (for example the new website'spredecessor). While it is absolutely ok to add margin on top of the website since one willgrow the website it is under no circumstances acceptable to just make assumptions about the traffic.

In my experience this is a very important step and once people are locked into theirperformance goals, even if they are based on wild assumptions, it is very hard to change themafterwards

Rule #4: Get Real.

If you go live with a website and you find out after the launch you run into performanceissues there is only only one reason for that: Your load and performance tests did notsimulate reality close enough.Simulating reality is difficult and it is up to the project how much effort you want toinvest into getting "real". "real" means not just "real code" but also "real content"especially size and structure wise. Keep in mind your templates may behave completelydifferently depending on the size and structure of the repository.

Rule #5: One at a time.

It is important to optimize one bottleneck after the other. If you do things in parallelwithout validating the impact of the optimization one will lose track of which optimizationmeasure actually helped.

Comply with Day's performance guidelines

Please find the performance guidelines for CQ applications and templates here:Guideto good CQ performance. Generally speaking, keep your uncached html requests to less than 100ms.

Usual suspects

Based on experience there are a certain number of issues that frequently contribute to performanceissues which mainly revolve around (a) dispatcher caching inefficiency and (b) the use of query innormal display templates.

JVM and OS level tuning usually don't lead to big leaps in performance so I usually avoid themto the very tail end of the optimization cycle.

Your best friends during a usual performance optimization exercise are the request.log, component based timingand last but not least a java profiler.

Full Presentation