Import This: the Tenth International Python Conference
The Zope keynote, "Open Source Content Management", was delivered by Tony Byrne of CMS Watch, an industry portal for content-management issues. What is a content management system (CMS)? It's a set of business rules and editorial processes managed by people. Specifically, it's not a category of software. Anybody with a web site has a CMS even if they do it all by hand. Even the increasingly-popular blogging is arguably a kind of personal content management. Tony calls the software "CM tools"; however, some others call them CMSs, including another author quoted below.
So, why use CM tools in your CMS?
To devolve control and avoid the webmaster bottleneck (meaning, nothing happens unless the webmaster does it).
To allow people to specialize in what they do best (creating and maintaining content), letting the machine do what it does best (the mundane tasks).
To divide content into flexible, reusable chunks.
To easily provide alternate presentation formats for the disabled.
Tony exposed a few industry buzzwords:
- Scalable platform vs out-of-the-box
These are two of Tony's favorites. In fact, they're mutually exclusive. Easy-to-install, out-of-the-box products probably won't work for you unless you situation is exactly like the one the authors envisioned. Conversely, scalable products are difficult to install.
- XML compliant
This is another gem. How can a product be XML compliant when XML itself is changing? Does merely being able to dump a data structure into an XML text file count as XML compliance? Fine, but anybody and their dog can do that.
- Intuitive interface
intuitive to whom? To the program's authors, of course. Were end-users involved in designing the "intuitive" interface?
How? How much effort would be required to take the product as shipped and create the demo program the sales staff initially showed the customer?
- Dynamic content management
This is not always necessary. More and more sites are discovering the value of pregenerating "static" pages for data that doesn't change extremely often. Not only does it cut down on server resources, but it's search-engine friendly. The only time dynamic pages are truly necessary is when the page is customized according to unpredictable user input or changes very rapidly (say, the latest stock quotes). A hybrid approach is also possible: pregenerate the portions of a page that don't change often, and leave a box for the content that must be calculated on the fly. But often you'll find that trivial personalizations ("Good morning, Sara. Your last login was 1 day 12 minutes 3 seconds ago.") are more hassle to maintain than they're worth.
CMS Watch has an article on the six questions you should ask your CMS software vendor regarding security. If they say, "Mega Big Bank uses our CMS and they wouldn't if they weren't sure of the security", the author, Colin Cornelius, responds, "I could tell you a thing or two about how financial institutions select a CMS, and security doesn't always enter into it."
There are three phases of web content management: production (what happens before somebody clicks a link to that page), publishing (what happens after they click) and distribution (how is the content reformatted and sent to alternate output devices). What's the best way to design a workflow system that adequately addresses all three phases and by which you can evaluate potential tools? Use a plain old word processor or spreadsheet.
CMS is really an immature market. There are 220 vendors of CMS software, of varying qualities. Many people use two systems, one for production and one for publishing.
Many CMS companies have gotten out of the search-engine business, and good for them. Designing a good search engine is difficult. Paying $10,000 to a dedicated search-engine company that knows their stuff is well worth it.
Syndication is one thing Tony recommends. That means the sharing of article metadata with other sites, such as LJ's news.rss file or the "recent Slashdot items" links you see on some sites. There's an article about syndication on the CMS Watch site.
Here's Tony's analysis of open-source CM technology, including Zope and all others: good cost, requires substantial support, the support is great but the documentation sucks.
Tony closed with a warning to the Zope community, a list of the top things people say when he mentions Zope:
Why does it have such a funny name?
I looked at Zope, but I still don't understand what it is.
It seems like a kind of religion.
I'd consider it for my Intranet, but it won't necessarily work with my Java or Oracle production server.
We're a Java/COM/Perl shop.
Is the Zope corporation for me or against me? I'm an integration consultant. Does the Zope company want to make me more productive or steal my business?
Tony thinks it's usually better to go with an off-the-shelf content management tool than to roll your own. He predicts that Java will continue to be more and more used for XML and that production and publishing will continue to be separate.
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- RSS Feeds
- Introduction to MapReduce with Hadoop on Linux
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?