Wednesday April 21, 2004

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 ) Permalink

Monday April 19, 2004

Nail Biter The Giant's had to keep you on the edge of your seat, ya know. After the string of one run loses, it just wasn't exciting enough to give the Pads the beat down.

With San Diego coming in with a 9th inning rally, bowling over the Giant's bullpen you just have to stare in disbelief as the three run lead that the Giant's enjoyed at the onset of the 9th evaporated into one. After coming off the high of Grissom and Bonds launching back-to-back home runs (and Bonds acquiring the number of man, 666), it's just inconceivable to have that victory snatched away. The rain pouring down was making it seem all the more grim.

But no need for dispair! It wasn't so bad. At the end of the night, it's another one run game but this time the G's were on the good side of it and the four game losing streak is snapped. Sighs of relief were audible far and wide.

	Runs	Hits	Errors
San Francisco Giants	4	7	2
San Diego Padres	3	8	1

( Apr 19 2004, 11:28:06 PM PDT ) Permalink


Perl6 and Apocalypse 12 Those wild and crazy guys behind Perl6 are at again. Larry Wall published "Apocalypse 12" the other day and it discusses many of the deficiencies of Perl5's object support.

There are a lot of funky things about Perl5. Paradoxically, sometimes these are beautiful things as well. But oftentimes, they're just funky. As I've said before "I suspect with Perl 6, I'll only hate it on Tuesdays". I could rag about the weak encapsulation and the lack of useful method signature support in Perl5. But since I've really come to love Java's use of interfaces to compose an object's capabilities and disallowed multiple inheritance, I was interested in reading about Perl6's roles. Yes, in Perl6 a class can have a bunch of different roles. Here's a little bit of Larry from Apocalypse 12:

Roles can encompass both interface and implementation of object relationships. A role without implementation degenerates to an interface. A role without interface degenerates to privately instantiated generics. But the typical role will provide both interface and at least a default implementation.

A little later, in discussing how roles are kinda like second class classes but not really, we see some hypothetical code:

If you want to parameterize the initial value of a role attribute, be sure to put a colon if you don't want the parameter to be considered part of the long name:

    role Pet[IDholder $id: $tag] {
        has IDholder $.collar .= new($tag);
    }
    class Dog does Pet[Collar, DogLicense("fido")] {...}
    class Pigeon does Pet[LegBand, RacerId()] {...}
    my $dog = new Dog;
    my $pigeon = new Pigeon;

In which case the long names of the roles in question are Pet[Collar] and Pet[LegBand]. In which case all of these are true:

    $dog.does(Dog)
    $dog.does(Pet)
    $dog.does(Pet[Collar])

but this is false:

    $dog.does(Pet[LegBand])

The universe is a big place. And it keeps getting bigger. I guess I'll wait for Damian Conway to chime in. If Larry Wall writes the bible; Damian has to write the talmud.
Shalom, Salaam, Shalom, Salaam ( Apr 19 2004, 11:06:01 PM PDT ) Permalink

Sunday April 18, 2004

My Baseball Weblogoscope Barry Bonds is a phenomenon. The recent rash of home runs is paradoxically accompanied by a losing streak for the Giants. After witnessing the San Fransisco Giants succumb to El Aye three times in a row in one-run loses, I realized that something must be done. Well, nothing I do is gonna make Woody a strike-out king or Neifi Perez into a long ball hitter. But there's no shortage of opinions on what must be done. There's a lot of talent on the Giants' roster, perhaps some of the rabble and babble sprinkling around the ether has some relavant wisdom. I decided to see if I could pull together the various blogs about the G's into a kind of meta-blog, a weblogoscope.

I could conceivably take on some other topics ("George Bush", "Iraq", "Lies and the lying liars who tell them" and so forth) but for now, I think I'll just enjoy the approach of summertime. And root for the Giants.

The weblogoscope is programmatically generated; it gave me a good excuse to take a close look at the rss, rdf and atom document data structures as well as mess with some of the stuff on CPAN for handling them. It's pretty funny how similar these structures are and yet how divergent their grammars are. And to top it all off, it seems like the timestamp representations are all over the road; the datelines have different elements representing them (why this isn't standardized on Dublin Core is a mystery to me), different formats and various timezone styles. I guess one of these days I'll research more closely how it got to be this way.

Or maybe that doesn't matter. Regardless, perhaps a weblogoscopic view of the baseball season might help the Giants. Maybe it's just another big distraction. ( Apr 18 2004, 11:03:13 PM PDT ) Permalink

Saturday April 17, 2004

What Is The Matrix? I just noticed that TheServerSide has posted a comparison matrix of J2EE servers.

TheServerSide apparently has had this little gem published for a while, their Application Server Matrix provides links to downloads, data sheets and product reviews. Great resource! ( Apr 17 2004, 10:28:29 AM PDT ) Permalink

Friday April 16, 2004

Dumping Java object contents If you've ever exploited Perl's Data::Dumper to inspect a Perl object, you know how useful it can be. For Java programmers, the reflection API provides tools to perform a similar interogation but the API has long lacked a higher level tool. The Jakarta commons-lang jar has a goodie to help.

I first ran across the ToStringBuilder class looking for a tool to standardise the formatting of toString() -- it's annoying to trace a set of objects' contents to a log file and find that they all implement toString() with different levels of completeness or with different formatting conventions. Well, this class has another little gem in one of it's static methods. Check this out:
  System.out.println("An object: " + ToStringBuilder.reflectionToString(anObject));
      <Emeril Lagasse>BAM!</Emeril Lagasse>
That's it.

By providing a higher-level wrapper API, ToStringBuilder makes using reflection to dump a Java object contents a little bit easier. Of course, seeing as how I started off talking about Perl, it's worth a mention that TMTOWDI'ness presents itself in this case. The Java bean API's XMLEncoder can be used to serialize a Java object to XML. ( Apr 16 2004, 10:59:39 PM PDT ) Permalink
Comments [2]

Wednesday April 14, 2004

PHP versus J2EE I don't like language wars, different languages and frameworks usually have a mix of strengths and weaknesses. However, I'm presently looking at some fixes (mostly resiliency issues) that have to be applied to a web tier built on PHP and am thinking about what's over the horizon for future scaling requirements.

I first used PHP in 1996 (it was called PHP/FI at the time) -- it offered a very innovative alternative to Perl and CGI generated content by making the execution flow out UI embedded logic. I liked it. The language was easy; very Perl-ish. But over the years, other frameworks have emerged that, despite the many improvements PHP has enjoyed, easily eclipse PHP.

PHP's primary strength is its enablement of rapid development of database backended web applications. For prototyping and providing "functional mockups", that's all well and good. But what I'm seeing is that as soon as you want to scale the application along some axis (runtime traffic, i18l, collaborative development, multiple presentation formats), it's difficult to justify sticking with PHP. From what I reckon, a J2EE web tier (servlet container, JSP w/jstl taglibs, MVC i.e. struts, etc) offers a lot of high level infrastructure and, when contrasted with PHP, is a clear winner:

	PHP	J2EE
Runtime scaling	There are opcode caching extensions but it's not a core component of the PHP runtime environment PHP is not thread-safe. You pretty much have to run PHP on a pre-forked Apache server. That's not too bad but it means that if you have a large Apache process pool, each process has to have its own connection to a database. If you have multiple persistent connections and a few hundred Apache processes, you're taxing the databases (because of the large number of open connections) and taxing the OS (because of the large number file descriptors open and memory consumption). And every forked process is an island of process space; sharing data between them is a PITA (you have to manage shared memory) and sharing resources is impossible (e.g. forget about pooling your persistent database connections).	Servlet container hosted runtime engines (such as JSP or Velocity) usually have code caching out-of-the-box. Higher level caches such as OSCache promise to provide even more to reduce the computational burden on the web tier. They easily take advantage of resources shared between threads such as database connection pools, external service interfaces (e.g. remote and/or local EJB factories; the home interfaces) and the container itself.
Content format scaling	If you want to co-brand a PHP site, plan on having conditional logic scattered and tangled all over the UI code. This quickly degrades down into a maintenance nightmare.	A J2EE MVC framework such as Jakarta Struts (with tiles) provides a centralized mechanism to declaritively and programmatically control how content is assembled for presentation.
Locale scaling	PHP allow you to extend the runtime with the GNU gettext framework. IMO, this is a difficult to use system; you have to manage PO files that have a peculiar file format.	The standard Java library has ResourceBundle support built-in with a simple file format (properties files) and, again, web tier infrastructure such as the servlet container, JSTL and Struts provides easy-to-use tools to access ResourceBundles.
Functional scaling	Extending PHP often requires recompiling the PHP runtime to statically link in different extensions. This results in closely binding your runtime requirements and your infrastructure compilation requirements. Maintaining persistence flexibility is difficult with PHP; while the PEAR abstraction layer provides a baseline of RDBMS independence the language is still bloated with database function calls with every backend you use. Furthermore, as outlined above, changing backends requires platform dependent code, perhaps recompiling PHP itself and then having client libraries installed where the runtime is executing.	Most Java libraries are available as "Pure Java" i.e. jni support, deploying OS-native libraries, isn't an issue. You never have to recompile Java to extend it. JDBC provides a standard interface to different database backends. While this won't help with things like SQL implementation differences, higher level tools like Hibernate's object-relational framework potentially will. Furthermore most database drivers are "Pure Java" i.e. there's no need to recompile anything and no need to, say, make sure LD_LIBRARY_PATH is set properly to enable your database drivers.
Collaborative scaling	The distinction between UI code and business logic is fuzzy and requires lots of developer discipline to keep it cleanly separated; there's little support in the framework itself. This pretty guarantees closely mingling formatting and display code with lots of logic. Yuck.	While it's certainly possible to write horrible applications with J2EE web infrastructure (i.e. the the fact that you can embed Java code, er, scriptlets, directly into a JSP is a terrible fact of life), the wealth of framework support (JSTL, Struts, etc) makes it easy to follow practices that keep the separation of concerns clean.

A clean separation of concerns is important. Collaborative web application development usually has different roles (the Java programmer providing business API's and beans, the UI layout coder developing the HTML structures, the UI logic programmer writing tag libraries and/or integrating them with the HTML structures) -- even if you're one person coding all of these out, having the different work elements clearly defined and cleanly separated will make your job easier. When you're working in a collaborative environment, the separation of concerns is essential.

There are other little things in the pro's and con's. PHP can support URL rewriting session tracking without doing anything special in the markup code -- nice that it can do that unintrusively but icky on other counts

• Markup has to parsed outside of PHP's normal tokenization; it's a post-processing of the markup
• It doesn't adaptively enable URL rewriting when cookies are disabled at request time, it has to set at runtime

I'd rather use a taglib in a servlet container to keep track of the URL rewriting needed, if any.

All of these points of contrast lay atop the basic structural differences between the PHP and Java languages: Java has Object Oriented Programming (OOP) as a core part of it's design, PHP has OOP as an odd afterthought. Java has real exception handling, PHP awkwardly provides function calls to register error handlers and function to trigger an error. OO is a core element of code modularization, reuse and extension.

Additionally, while I have my misgivings about EJB's and their misuse, EJB's are an established framework for separating the business and persistence tiers from that of the UI. Service oriented architecture (SOA) patterns are also well established amongst the J2EE development community -- this also better enables collaborative development and clean separations of concern, ergo, long term maintainability.

A final point of comparison and contrast is how closely bound PHP is to the web server in a typical architecture. It's nice to have the ability to scale the HTTP interface independently from the application layer. With PHP, the only option there is to run another webserver; a reverse proxy to offload all of the HTTP servicing. With a servlet container there are various options to connect the HTTP interface to the Java engine via a connector. For example with Apache and Tomcat, you can use mod_jk to connect them, and just to sweeten the deal a bit, mod_jk provides a bit of scaffolding to support load balancing.

It's not my intention to sweepingly indict PHP. For the simple stuff, I like it. And I know it's extremely popular ("50 Million Elvis Fans Can't Be Wrong!"). But when you get beyond needing "Server Side Includes On Steroids" and have to deploy a scaled up database backended application, PHP's weaknesses come to the foreground. Yea, yea... I know that Yahoo! uses PHP and I bet there's a lot to learn from their experiences with it -- I expect PHP creator Rasmus Lerdorf's employment with Yahoo! to drive a lot of innovation in PHP's future. But at this point in time, for the web application requirements I'm looking at, I gotta give it to J2EE.

Other links of interest

• Nukes: the Open Source Java CMS
• The word on the street is PHP
• PHP versus J2EE reagrding speed of developpers (sic)
• Another Performance Comparison of Middleware Architectures

( Apr 14 2004, 12:12:22 PM PDT ) Permalink
Comments [2]

Monday April 12, 2004

YAQPM: Debian's software package manager Over the weekend, I had my initiation with Debian's package manager(s). While I've never been in love with RPM's or Solaris packages, I wasn't particularly eager to have to contend with Yet Another Quirky Package Manager.

At first I started messing around with Debian's vt100 utility, dselect (which it turns out is just a cheesey wrapper around dpkg) hoping to find something of the same caliber of the FreeBSD's package manager. 90% of the time, the FreeBSD tool won't give you too many surprises, it JFW's. I was not so lucky with dselect, what a POS! If you misfire some selection keystrokes and then leave your dselect session, you'll never be able to just undo what was there -- you can item-by-item set flags to "hold" the current state of individual packages but there's no way to just say, "the current state of the packages is how it is, don't flag anything for installation, removal, holding or whatever."

In the end, I read the man pages for apt-get and apt-cache; between the two of them, it looks like everything you'd want as far as package management tasks are available. My next foible was realizing that an installation can have a mix of packages from stable and the amusingly named unstable streams of Debian's deliberate development branches. Geez, I just needed libperl5.8 so I could compile something that embedded perl but the requirement to go to a different branch wasn't readily apparent from the dpkg -l listing (i.e. it required poking around a little research to discover that unlike the rest of the stable goodies, perl-base was from unstable).

And while I'm bitchin about how braindead linux distro's can get, what's with having libraries and header files in separate packages? What's I recall being so righteous about FreeBSD's ports-n-packages was that when you installed, say, zlib, you got the libraries and the headers -- there should be no need to install zlib-dev or something just to get the header files! What, are we concerned about diskspace usage? Why not just install the ding dang headers with the base package??

I remember a few years ago celebrating the news that the Open Packages project was going to bring the ports-n-packages thing of beauty to Linux and hopefully do for Linux what it'd been done for the BSD's a long time ago: a consistent, reliable and yet flexible package management system. IMO, RPM, Debian packages and Solaris packages all fall short. ( Apr 12 2004, 09:03:53 PM PDT ) Permalink

Tuesday April 06, 2004

Technorati Rocks! I'm very pleased to join the fine folks at Technorati. I feel that the changes that are afoot with the way content is developed and published presents huge opportunities.

As the jack-of-all-tradesman in LAMP, J2EE and web operations, I'm confident that I will be adding valuable new capabilities to Technorati's business and great things will be upon us. The Technorati team is sharp, inspired and with those added special ingredients of timing and luck, on the cusp of greatness. ( Apr 06 2004, 04:05:45 PM PDT ) Permalink
Comments [2]

Monday April 05, 2004

Buy me some peanuts and crackerjacks I was busy with other stuff but the post-game reports on today's season opener sounds awesome.

While I'll miss Jeff Kent's contributions to the Giants, it's hard not to take a little pleasure in seeing a little late inning beat down with Bond's 3 run HR in the 8th (number 659 for his career, Say Hey!)

	Runs	Hits	Errors
San Francisco Giants	5	10	0
Houston Astros	4	9	0

It's the most wonderful time of the year: "Play Ball!"

Happy Opening Day! ( Apr 05 2004, 09:21:23 PM PDT ) Permalink


Building software could be like layering a cake, which could be good I did a little write up on Aspect Oriented Programming (AOP), titled "Aspect Oriented Programming: An Introduction," I'm more than just a tad stoked that it's the lead story currently on CMP/TechWeb's DeveloperPipeline (ya know, I'm just having a great day today, there's lots of good stuff happening).

Anyway, I believe we are entering an age of non-intrusive frameworks (unlike traditional J2EE) that serve as lightweight application servers, or lightweight containers, if you will. AOP isn't a piece of software or a container, it's a different and complementary approach to ye olde Object Oriented Programming. AOP is about layers. It's about being able to layer on supporting functionality and weave it into your core functionality. AFAIC, Sun is put on notice: your big overdone API's for J2EE aren't necessarily the best way to develop all of the components for a scalable OO architecture.

A lot of the things that J2EE provides (such as security and persistence) might be better served as application aspects, layered onto the core OO model. And technologies such as Hibernate are here to help as well.

Layers involve complexity, but that's not a bad thing. Why, there are even bits of wisdom on the matter to be found in everybody's favorite DreamWorks feature film:

SHREK: For your information, there's a lot more to ogres than people think.
DONKEY: Example?
SHREK: Example? Okay, um, ogres are like onions.
DONKEY: [Sniffs] They stink?
SHREK: Yes. No!
DONKEY: They make you cry?
SHREK: No!
DONKEY: You leave them out in the sun, they get all brown, start sprouting' little white hairs.
SHREK: No! Layers! Onions have layers! Ogres have layers! Onions have layers. You get it? We both have layers. [Sighs]
DONKEY: Oh, you both have layers. Oh. [Sniffs] You know, not everybody likes onions. Cake! Everybody loves cakes! Cakes have layers.
SHREK: I don't care... what everyone likes. Ogres are not like cakes.

Who can argue with that? ( Apr 05 2004, 08:55:55 PM PDT ) Permalink


Deadwood: a heavy metal western

I'm not a big TV watcher but I really dig HBO's new series, Deadwood, it's such a departure into the heavy metal underbelly of human tendencies and vices, I can't stop watching it.

The dialogue gets a little tiresome with the "f*ck'ing this" and "c#ck s*cker that" every other sentence. Don't get me wrong, I can cuss like a sailor, when inspired to (I have colleagues who can attest to this fact), it just gets a little old having it be such a dominant aspect of the script. I could complain that the ugly people are really damn ugly and the pretty/handsome ones are too much so but overall, I think it's a great show. The cinematic mise en scene of Deadwood is truly awesome: tough, gritty and grueling.

The next thing I'd like to see on Deadwood is a role for Ian Kilminster (AKA Lemmy), it'd be perfect!

( Apr 05 2004, 11:37:28 AM PDT ) Permalink

Friday April 02, 2004

Content Event Listeners Content publishing events should be like the ripples of a stone landing in a pond. Concentric circles of information modulation should eminate from the blessed event when new content is born.

Discovering that a stone has penetrated the surface of the water has traditional been discovered by scanning the bottom for new debris. What a waste of effort! Publication is an explicit, active event, why is it sufficient to discover its occurance after the fact, passively? These are the days of miracles and wonders indeed, we can tell those who have a registered interest in knowing that a publish even we should be concerned with has happened. Content event listeners will make it happen.

Metadata is your friend, my friend. It will be used to enrich us. ( Apr 02 2004, 05:49:22 PM PST ) Permalink
Comments [1]

Thursday April 01, 2004

Content Management Systems in the 21st Century Building a general purpose CMS isn't easy. My last effort at it was carried forth after my departure from Salon.com and eventually turned into Bricolage.

These days, there are so many open source content management systems, it's difficult to keep 'em all straight. When I'm evaluating these things, the first thing I look at is how close is the CMS to the content serving? If they're closely bound, then any efforts at scaling one function (say, serving content) has to be considered for it's impact on another (such as, inputting and managing the content). This is why I outright refuse to deal with products such as Vignette. And yet a lot of products seem to follow that same "the appserver is the content repository, serving engine and workflow manager" model that makes Vignette such an awful product.

I understand that Plone is similarly modeled, albeit on top of a Zope app server. A lot of the blogware (such as the one that I'm using now) that masquerade as CMS' also closely couple the data management with the serving of templatized content output.

I say: get with it. It's the 21st century already -- we know better than to mingle our high request rate content with our low request rate administrative interfaces, don't we? The talk I gave at the O'Reilly Open Source Conference in 2000 is posted online and there are loads of other resources out there. And yet people are still ponying up huge mega-buck deals for Interwoven and Vignette, they're rolling their own one-off solutions, they're making compromises by limited their content to blog-style articles and it's sad. The fact that crap that requires an application server closely bound to the CMS functions to deliver the content are still being developed and deployed tells me that the CMS problem is still a wide open issue. It's my opinion that the there's huge uptapped market there.

If someone wants to hire me to re-write Bricolage in Java so it can be more easily boxed up and sold, I'm available (insert evil grin here). ( Apr 01 2004, 03:23:33 PM PST ) Permalink

Wednesday March 31, 2004

Take me out to the ballgame! I'm gonna be in The City tomorrow evening for some stuff; when it's all said and done, I'd love to take a trip down to PacBell^H^H^H^H^H^H^H SBC Park to see the San Francisco Giant's return home in a night game against the Texas Rangers.

I don't understand how anyone can find baseball boring. Sure, some games are more exciting than others but when you've got a got a guy throwing a ball between 85 and 95 MPH through a little window in front of the batter and the batter's job is to launch it past the squad that he's facing, it's great! I mean, damn, you try it sometime! Baseball is the perfect mix of strategy, psychology and the boundaries of human athletic abilities.

I'm so glad spring time is here! Now if any readers happen to have an extra ticket to the game, I'm all over it, lay it on down :) ( Mar 31 2004, 10:41:31 PM PST ) Permalink