The bottom line for me is: I want to be able to easily test stuff outside of the containers and the mandatory interface implementations. Traditional J2EE, the practices promoted around it and the tools provided haven't accounted for that requirement. So the grassroots have.
Sun, consider yourself put on notice!
Due to space constraints, I couldn't get into it in my article about AOP (Aspect Oriented Programming: An Introduction) earlier this month but as I was looking around the landscape of AOP implementations and the related technologies (i.e. Inversion of Control) it's become increasingly apparent that Hibernate, Spring and an array of other projects that've gained momentum from the grassroots level are really the important story this year in J2EE, not Java Server Faces or EJB 2.1 or EJB 3.0 -- the J2EE developers in the trenches are tired of Sun groping around trying to get it right and they're pressing ahead with real-world solutions without Sun's official blessing. If useful standards can arise out of the open source ecosystem, then Sun's JCP, the insular and opaque JSR working groups and the Decisions From On High about what's important at JavaOne are likely to see their relevance ebb.
Hasta La Vista, Baby
( Apr 21 2004, 11:31:18 PM PDT )
Why Content Management Fails Jeffrey Veen of Adaptive Path published an essay, Why Content Management Fails, pointing out that all of the good technology in the world isn't going to provide a successful Content Management System (CMS) installation; getting the users on board is the real challenge.
Yes, you need a good software support system and competent IT help but if the users don't see themselves as publishers, if it's not ingrained in their psyche, it's not going to be a part of the core concerns. Dropping a bunch of tools in someone's lap doesn't necessary stoke their enthusiasm to use them. Creating structured content and collaborative creation is human activity that requires a mindset comfortable with the process. The tools are just there to help.
While Why Content Management Fails emphasizes CMS failures as a "people problem", IMO it also has a technical element: CMS developers aren't grokking their customer's requirements. Instead of imposing upon the users This Is How You Shall Work the toolset should be flexible enough to work the way the users want to use them. And Veen backs up my point
To have any chance of success, a content management project must follow the same user-centered design practices as any other project. Task analysis, rapid prototyping, usability testing - all of these methods are crucial to a CMS rollout. It is foolhardy to unveil a mammoth, nine-month project to an unsuspecting user community and expect adoption.I predict that the proliferation of low end tools such as blogware (as in low cost, limited templating, story structure flexbility and workflow support) will drive increased awareness right down Main Street that the web is a read-write medium, that you can be a consumer and an author of content and that authoring will become just another part of how people think about their work and their lives. This will drive the demand for publishing tools more feature rich than blogware but without the bloat and absurd price points that most people associate with enterprise content management.
It used to be supposed that with Vignette's and Interwoven's fat market capitalizations in the dot boom daze that the CMS market is done, it's a solved problem. But look around and it's clear that it's still an open issue. The big enterprise vendors with their jumbo price tickets are in trouble. And the market is ripe for a new generation of tools. The writing is on the blog.
( Apr 21 2004, 01:47:51 AM PDT )