I was reading this post on the definition of a blog and it got me thinking of a conversation that I have with many of my clients. Often companies that are interested in replacing their content management systems have resorted to an intermediate solution of side-stepping their difficult to use, rigid web content management system by using a blogging platform to power a section of their site. They are attracted to the immediacy and ease of use of the blogging platform and conclude that they love blogging. But what do they really love? And could they achieve the same results on their WCM platform?
If you really break it down, a blog could be seen as a website design that can be implemented by most WCM platforms: short-form articles with immediate publishing (no workflow) organized chronologically on the site with an alternative XML (RSS) view and some interactive features like commenting. There is also trackback and pings but most companies don't even know what those things are. What WCM platform can't do that? Probably yours. And the reason is not the technology. It is just that you have designed your implementation around processes that you hate: complicated workflows, overly elaborate content models, lots of metadata, periodic publishing, etc. You may have gone too far down the path with your current WCM platform to introduce the simplicity that you love about the blogs. If you are replacing your core WCM platform, you may consider including a blog-post-like article in your implementation design. You may call it a blog. You may not. It doesn't really matter.
What if you like this blog-like behavior so much that you realize that you can get by without all the features of your classic WCM platform (navigation management, page composition, template selection, multi-step workflows, versioning, etc.)? In that case, a blogging platform may be all you need. Many of the blogging platforms on the market are building in foundational WCM capabilities and are becoming lightweight web content management systems themselves. While not as feature rich as the incumbent WCM platforms, they are typically easy to use and are certainly cheap enough.
So, if you find yourself in the position of happily blogging but want to replace your onerous WCM platform, you should consider the following options:
Use a blogging tool to power your whole website. This sounds crazy and may well be but just the act of considering the idea will force you through the exercise of discussing your requirements. It is easier to understand the importance of a requirement if you think through removing it. The discussion can also lead to creative new ideas. I liken this to Edward de Bono's creativity exercise where you put forth a crazy idea and you discuss why it would be good and why it wouldn't work and then try to harvest the good aspects of the crazy idea. If you are familiar with this exercise you know that the proposition of "the plane lands upside down" led to the tilting nose of the Concorde that allowed pilots to see the runway better.
Design your new WCM platform and website to be more blog-like. Base your simplicity and usability bars on a blog and only introduce complexity where you absolutely need it. Do not destroy the freedom, spontaneity and casualness that made blogging so fun. You may find that you could get away with a less expensive CMS than you thought you needed.
Fix your old WCM platform. Use what blogging taught you about content production and use it to refactor your existing CMS implementation. Simplify your content structure. Streamline your workflows. Hide features that clutter the UI. You might find that the WCM platform you have doesn't have to be as bad as you made it. You could even continue to use the blogging platform contribution interface and feed content into your main CMS.
Recently I have been helping a client establish standards for software development and configuration management. The developers are all very excited about instituting practices like unit testing, code reviews, and continuous integration but there is concern whether the pressure and pace of development would allow for taking the time to things right. Despite the fact that management brought me in to establish these practices, there is doubt as to whether the business could abstain from setting unrealistic expectations that force hurried work.
So the big question is - does doing things the "right" way take longer and jeopardize short term deadlines? I think the conventional wisdom is that process investment starts to pay off toward the end of the project or in subsequence releases of the system. But when is the break even point? I have heard lots of claims but very little hard data - mainly because it is impossible to compare different projects because no two projects are alike. I think the only way to get evidence that is even close to conclusive is to do a study like the following.
Take a large group of under graduate computer science majors and randomly assign them to three independent classes taught by the same professor. The course work for the semester is a series of software development projects to build an application where each project builds on the previous project. Each class gets the same projects. None of the classes has visibility as to what the next project will be or what the other classes are doing. All students track time spent on the projects. The different classes are instructed as follows:
Class A is given very aggressive deadlines and is graded solely on how well the application meets the requirements.
Class B is given less aggressive deadlines and is graded on development standards (unit tests, configuration management, and code structure and style) as well as the application's satisfaction of the requirements.
Class C is given the same deadlines as Class B but is only graded on the same criteria as Class A.
At the end of the test, you compare the time spent by the three classes and the overall quality of the three applications (defect rate, adherence to the requirements, etc.)
If widely considered best practices in software development are as effective as believed, Class B will end the semester with the best software and the least stress. Class A will be totally stressed and their application will be barely hanging together. I would guess that Class C starts the semester off breezing through and enjoying their free time but has to do a bit of cramming in the end.
One of the only things I have been missing on the Mac has been a good Subversion client. Yes, there is the Subclipse plug-in for Eclipse but unless I am doing prolonged Java coding, I don't want to wait for Eclipse to start up. There is also the command line client but I like a GUI to easily visualize what has changed (yes, I know you can do that on the command line if you can remember the commands). I was looking for something like TortoiseSVN - actually better than Tortoise because Tortoise has the annoying tendency of slowing down Windows Explorer.
For a while I was using the Syncro SVN client. It came with Oxygen and was fine. A couple of days ago my friend Brian told me about Versions and Cornerstone. I have been playing around with both of them and am really impressed. Both are really new (Versions is still in Beta) and they feel like native Mac apps. Versions looks a little like another favorite program of mine: Things. Cornerstone costs $59 for a single user license. Versions hasn't announced prices yet.
Both Versions and Cornerstone are more powerful than their thin documentation would have you believe. For example, neither have instructions on how to branch a folder and neither have menu or contextual menu items to execute this action. However, by holding down the alt key and dragging a folder you can effectively branch.
After going back and forth between Cornerstone and Versions, I am finding Cornerstone a little more intuitive. In particular, I like how Cornerstone shows how many files you changed in Mail.app kind of style. Also, I found the notion of "repository" and "working copy" bookmarks a little confusing although I am sure it wouldn't take long to get used to it.
This summer I have had a crazy travel schedule so I was not able to attend the OSCON conference in Portland. I really need to get out there one of these days. Fortunately, the O'Reilly bloggers and Matt Raible have great notes from the conference. The speaker presentations are posted on the OSCON site and the keynotes are supposed to be available on BlipTV but I just checked and they don't seem to be there yet. While "virtually" attending a conference doesn't provide all the social and interactive benefits of physically being there, it is better than nothing.
The Google
blog posted that they passed the 1 Trillion pages milestone. They go on to say that the web is actually infinite thanks to websites like online calendars with "next" buttons that go into the future indefinitely. It makes my little corner of the web feel even smaller than usual. Even "billions and billions" seems small.
I remember hearing somewhere that Google is better positioned than anyone to handle large volumes of pages because their indices use a unique proprietary database and storage technology that can scale far beyond traditional relational databases. It looks like they are going to need it.
I can't remember if I knew this before but someone recently mentioned that the Eclipse project was named as a dig on Sun Microsystems. Get it? Sun, Eclipse? I always questioned Sun's lack of involvement in Eclipse. I don't know if it was only the Eclipse project itself but I would say that the Eclipse supporting companies (like IBM, Oracle, and Borland) are eclipsing Sun in their Java-oriented businesses. Hostility aside, this is a good example of using an open source project as an opportunity for companies to collaborate and cooperatively force market change. Other examples include the many open source projects that were established as reference implementations to push forward a standard.
Other hostile open source project names:
Fuzed is for F-U Zed. Zed is the guy who wrote Mongrel
Through my research and my client work I have been running across this recurring pattern of exposing a content repository through a REST interface. In the past, I have written about the JCR and Sling and Alfresco's Web Scripts architecture. I really like both of those implementations. More recently, I have been working with a client who has built their own REST interface on top of Day's CRX. They started their project before Sling was a glimmer in Apache's eye and they took a slightly different approach. Instead of using Sling's repository-oriented request handling, or Alfresco's model of registering a Web Script (written in Javascript) to a particular path, my client has built out a full URL based query syntax through a servlet. Right now, the syntax focuses on searching retrieving content and is very powerful.
The strategy of using a REST API for your repository solves a central problem with the JCR and other Java base repositories: remote connectivity. Without a remote connectivity infrastructure like JDBC or ODBC, technologies wishing to talk to a Java repository must resort to connectivity like RMI (Remote Method Invocation) that are inefficient and do not necessarily play nicely with firewalls. While not particularly efficient (lots of protocol layers and text processing), REST offers a nice foundation for enabling remote connectivity at the appropriate layer of abstraction (that is, how content is logically stored - not how it is physically persisted). There are many reasons why REST is a good strategy but I think that the most important ones are:
There is great infrastructure available for optimizing and controlling HTTP traffic. For example, reverse proxy technologies like Squid can stand in front of the REST interface and serve repeated requests out of cache. Firewalls can be used to filter traffic with rules that evaluate the requested path and requester origin (beware IP Address spoofing).
REST is entirely technology neutral. Everything talks HTTP and XML. You can replace the implementation of either the server or the client with little risk to the overall architecture.
I think the only downside is that developing your own API is tricky business. While you are free to change your underlying data structures, once you publish your API and start writing applications on it, you lock yourself in. Where possible, it is best to support standardized query syntax like XQuery or the JCR query language in addition to your domain-specific methods.
I expect to see this pattern of REST-based repository access to be pretty much the standard as we get into Web 2.0 architectures that support mash-up applications. If they can address the overhead of all the text handling, more and more systems will use REST API's to de-couple the various components in the application stack. Something to consider the next time you design a content-centric application.
The Django community recently announced the first official Django conference. DjangoCon 2008 will be held at Google's Mountain View headquarters on September 6th and 7th to coincide with release 1.0 of the platform. Admission is free (as in beer) but they are capping the attendance at 200.
If you are new to Django, Django is am open source web application development framework written in the Python programming Language. Despite its sub-1.0 status, Django is quite mature. It was first developed by the folks over at Lawrence Journal-World for sites like ljworld.com, lawrence.com, and KUSports.com. Later, Rob Curley assembled a team over at the Washington Post to build a bunch of local sites. Now Django is bundled and actively used in Google App Engine. There area also a number of books on Django. I am currently reading the Definitive Guide to Django by Adrian Holovaty and Jacob Kaplan-Moss. So far, so good. I see a lot in common with Rails and the two definitely seem to get along at least at a philosophical level.
I will be covering Django in an upcoming report about web content management in media and publishing because of Django's widespread use in that industry. There is a small commercial CMS called Ellington that is specifically designed for the newsroom. Do you have any experience with Django or Ellington? I would love to talk to you about it.
Nuxeo just announced the first official release of their WebEngine. I have been hearing updates about this project for a while and have been meaning to check it out. From glancing through the slides, WebEngine seems very similar to Apache Sling and has many of the things that I like about Sling: a RESTful interface and a lightweight, content-centric programming model. In WebEngine templates are written in FreeMarker and you can script in your choice of Groovy, Python, Ruby, Javascript and other languages (thanks to JSR 223) which provides a scripting interface for Java applications). I am looking forward to playing around with WebEngine. In my past experiences with Nuxeo applications, I found them to be well engineered.
If you are new to Nuxeo, they have a legitimate claim to being the first open source ECM company. Their primary geographic focus is in France and they are less well known in the US. Nuxeo's original ECM product (which combined Document Management, Collaboration, and Web Content Management) was written on the Zope platform. In 2006, they ported their product (then called CPS for Collaborative Portal Server) to a Java stack (using JBoss Seam). Long time readers of this blog may remember me being skeptical of whether they could pull it off. It turns out that they did a great job with the migration and have been aggressively pushing the platform forward.
Like, Alfresco, Nuxeo's experience and customer base leans towards the document management side of ECM. Web content management is a newer focus that is (I think) well timed as more companies are looking for ways to rapidly build internally and externally facing content centric web applications.
