Blogging Roller

Russell Beattie: Correct me if I'm wrong, but I'd say that in a modern developer's virtual toolkit, Google is #2 right after a decent IDE in terms of necessity.

where I went tonight....

1. Maggie's Farm
2. Tonight I'll Be Staying Here With You
3. Tweedle Dee & Tweedle Dum
4. Just like A Woman
5. Things Have Changed
6. Don't Think Twice, It's All Right (acoustic)
7. Cold Irons Bound
8. Watching The River Flow
9. Love Sick
10. Highway 61 Revisited
11. Knockin' On Heaven's Door (acoustic) (Donna and Vickie from the Waifs on backup vocal
12. Honest With Me
13. Floater (Too Much To Ask)
14. Summer Days
15. Like A Rolling Stone (encore)
16. All Along The Watchtower (encore)

Joe Gregorio posted an excellent essay on levels of abstraction and using content:encoded vs. xhtml:body in RSS feeds. While I don't really have a strong preference in this debate, I do find it very interesting that that Mr. Well-Formed-Web takes sides with content:encoded.

I would like to make it possible for Roller users to take either approach with their RSS feeds. BTW, Lance suggested a Roller enhancement today that should make it easier for those who choose the xhtml:body approach (ROL-191: Integrate JTidy into Roller).

Alex, who is six and who can read, has a little brother Linus, who is four and cannot read. This weekend Alex was asking about names. "Does Matthew have a U in it?" he asked. "What about Leo?" After asking about the presence of the letter U in all of his friend's names and finding that only brother Linus has a U, he went back to his room. Later that day, we noticed the following sign on his door:

no budey cum in if you do have a u in side yor name. go a way u names.

What have I done wrong!

I've been watching RSSLibJ for a while and wondering whether we should use it here in Roller. RSSLibJ is a Java class library that allows one to create RSS output in a variety of formats including RSS 0.9X, 2.0, and RDF from a single object model (RSSLibJ is not suitable for RSS parsing because it does not handle badly formed feeds). So, does it make sense to use RSSLibJ for RSS output in Roller? I'm pretty sure the answer is no because:

• Why bother? All RSS aggregators worth consideration already support RSS 2.0, adding support for RSS 0.91, RSS 0.92, RSS 1.0, and RDF does not really add any value to Roller.


• If it ain't broke, don't fix it. Roller already supports RSS 2.0 output using a simple Velocity template that duplicates Mark Pilgrim's RSS 2.0 MT template (you can't get more perfect than the Pilgrim ;-).


• Templates are easier to maintain. If we have a output format problem with RSSLibJ, we'll need to grok the RSSLibJ Java code, tweak RSSLibJ, recompile the jar, and if we want to do things "right" we'll need to submit a patch to the RSSLibJ folks. If we have a format problem with our current solution, we just tweak a simple Velocity template and fix it (worst case: we also have to modify our object model).


• What about performance? More than half the traffic on a big Roller site (e.g. FreeRoller) is RSS traffic, so RSS production needs to be pretty efficient. With support for If-Modified-Since and RSS output caching, this is less of an issue, but it is still an issue. Converting our existing object model of WeblogEntries, WeblogCategories, Comments, etc. into a separate RSSLibJ object model before output can commence seems like a pretty inefficient exercize in terms of memory usage and speed.

If you want to tell me how wrong-headed I am on any of these points, I welcome your comments and trackbacks.

Tim Bray: Standards have nothing to do with innovation; a good standard is what happens when an industry has basically shaken the bugs out of a technology and then, after the fact, writes it down. This is true of all the really successful standards: grams and meters, voltage, the calendar, octane ratings, TCP/IP, XML.

Tim says its time for standardization of RSS, explains why and asks who will do it. Sounds like he favors IETF. Don Box likes OASIS.

In case you missed it, as I did, there were very interesting discussions concerning RSS taking place all over the blogosphere yesterday. I believe they were all kicked off by this:

Dave Winer: Here's how Microsoft is going to fuck all of us. Their blogging tool will support RSS 2.0. Basic stuff like title, link, description, and maybe to be nice, a few extras like guid, category, and generator. Then they're going to define a namespace with poorly documented stuff the rest of us don't understand. [...] Now get this -- it doesn't have to be that way. We could establish a profile of RSS 2.0 and implement strict compliance with that profile in the major blogging tools.

Sam Ruby's site was the focal point of the discussions that followed because Sam has comments on his site and because, of course, Sam is the man. For a recap, look at Sam's Saturday and Sunday archives. Who joins in and posts the first cut of this profile? Don Box of Microsoft.

This is a minor bug fix release, see JIRA for the fix list. The release is available on SourceForge or you can get it via CVS from the ROLLER_0972 tag.

The most significant fix is that all URLs generated by Roller are once again relative (as they were in earlier versions). Also, a new setting has been added to the Website:Config page to allow you to configure the base URL for those URLs that cannot be relative (those in RSS feeds, XML-RPC return values, Trackbacks, etc.). These changes make it easier to run Roller behind an HTTPS configured web server.

The out-of-memory problems reported by users have turned out to be the results of misconfigured JVM, Tomcat, and OSCache settings, so I think Roller 0.9.7.2 is ready for deployment on FreeRoller.

UPDATE 3:02PM EST: If you have already downloaded the build, please download it again. I found a little glitch and had to do a respin.

I agree that Sun could do a much better job of working with the open source community. One of Java's greatest assets is the wealth of open source Java applications, servers, class libraries, and development tools that exist free for the taking. Sun should be exploiting this advantage, not inflaming open source developers. This is a real shame, because when Sun inflames open source developers those open source developers start spewing FUD like this:

Andy Oliver: Who has the utmost confidence in the financial future of Sun? What if you're using SunOne and Sun becomes the next Enron for instance? You're in deep doggy doo.

That just doesn't make a lick of sense. If you have written your SunONE-based app using the standard J2EE APIs such as Servlets, EJB, JMS, etc., as any server-side Java developer does, all you have to do is to tweak a couple of deployment files and move your app over to JBoss, Websphere, or Weblogic, or some other J2EE server.

J2EE developers shouldn't "walk through walls" into container-internals as the JBoss guys advocate, they should stick to the standard J2EE APIs. I'm not saying that all of the JCP foisted standards are good things or that the JCP is a perfect process. They aren't and it isn't, but you only have to use the standards that make sense to you. The standards allow the Java app/message/portal server vendors, both closed and open source alike to compete to provide the best implementations. I don't want my Java code to be locked into any one Java server, not even an open source one.

Just in time for my birthday, Leo takes his first steps. Here is what he looks like now at 10 months old. My Dad took the picture with his fantastic new digital SLR (a Canon 10D).

Michael Yuan points out that a couple of books on Eclipse are about to hit the racks. Very cool. Yet another sign that <a href= "http://www.rollerweblogger.org/page/roller/20021107#the_eclipse_dominates_scenario">Eclipse will dominate. It's not just an IDE, it's the universal tool platform.

In the style of Steal these icons / Steal these buttons:

The blog Raible Designs - We Build Web Apps has claimed your blog Blogging Roller as its parent. You can view your blog's genealogy at this location: http://www.blogtree.com/blogtree.php?blogid=4073 Congratulations!

Thanks Matt. I'm honored.

Charles Miller: I'm aware the Refactoring Browser originated in Smalltalk. What I fail to understand is how truly automatic refactoring is possible when types are indeterminate.

Lance Lavandowska: I've started a wiki for Castor

Andy Oliver: I wish javablogs was opensource.

James Robertson: Gemstone is like Da Vinci - brilliantly ahead of it's time, simply outside the grasp of the current crop of developers....

Rafe Colburn: It's official, the IT job market still sucks.

Patrick Chanezon: Guido van Rossum (Python creator) started a weblog, at Artima.

David Czarnecki: FindBugs is already proving to be useful with the blojsom codebase.

Don Box: Honestly, I'm not sure why folks in the Java camp don't just use Tomcat + Xerces + Axis and declare victory.

In case you haven't noticed Matt Raible is goin' nuts with cool ideas for Roller development including integration of Struts menu into the Roller Editor UI, blogging via Jabber, and moblogging via Russell Beattie's Manywhere Moblogger.

I just noticed that Arjun Ram has a nice list of Roller enhancements. All of them sound good, but I'm not sure why we would want the my.yahoo.com look and feel. Maybe he just wants Roller to be a Portal or a Portlet within a Portal. He also requested some Steal These Buttons (actually he suggested these) style Roller badges. Here are my feeble first attempts (UPDATE: I took down the badges that included Sun logo images):

  

Stuart Halloway also has some words on Ted Neward's persistence posts.

Lance discusses how well Roller meets Matthew Thomas' requirements for the Ultimate Weblogging System.

I've been thinking about Java persistence and O/R mapping a lot over the last year or two, so I was excited to see Ted Neward's latest items from his upcoming book Effective Enterprise Java. According to Ted, there are four approaches to Java persistence: object-first, relational-first, procedural-first, and hierarchical-first. I really like the way Ted introduces the approaches, exploring the history and the developer motivations behind each, but I do think there is room for improvement. Here are the short-comings from my point-of-view.

The approaches need more differentiation. Apart from the hierarchical-first approach, which I will ignore because it involves using XML rather than a relational database, the approaches, in the end, are very similar. When you get right down to it, they all involve building an encapsulation layer that stores and retrieves objects. The approaches differ only in the extent to which either the underlying database schema is exposed or the overarching object model is preserved.

More guidance is needed on choosing an approach. How do you know when to use each of these different approaches? For example, if you have an existing database schema, possibly one that is imposed upon you by your database administrator, does that mean you have to use the relational-first approach and use JDBC, RowSets, or SQLJ as Ted shows? I would say no, but Ted does not really make this clear. Conversely, if you start with a nice object model, does that mean you have to use the object-first approach and use O/R mapping, JDO, or EJB? I think the answer is no here too, but Ted does not explain this. How do you choose an approach and how do you know when circumstances have imposed an approach on you?

Characterizing the approaches as procedural-first, relational-first, and object-first is useful from the story-telling historical perspective, but I think it might be lacking for the practical how-to perspective. For an alternative, take a look at the way the Hibernate guys break it down, cookbook style. The Hibernate site describes four approaches to O/R mapping: top-down, bottom-up, middle-out, and meet-in-the-middle. These terms/approaches are useful even if you are not using Hibernate. Here are my summaries of the four approaches (from an earlier post of mine):

• Top-down: Starting with an existing JavaBeans object model, develop a mapping that maps those objects to tables in your database, generate DDL to create your database, and then use a persistance API to persist those objects to that database.
• Bottom-up: Starting with an existing database schema, describe your database schema using using XML or some other meta-data representation, generate your JavaBeans object model, optionally add business logic to those objects, and use a persistence API to store and retrieve your objects.
• Middle-out: Starting with a meta-data description of your object model, generate your JavaBeans object model, generate DDL to create your database, and use a persistence API to store and retrieve your objects.
• Meet-in-the-middle: Starting with an existing database schema and an existing JavaBeans object model, develop a mapping to map between the two, and use a persistence API to store and retrieve your objects.

I was kind of hoping that I would read Ted's new chapters and realize "damn, I'm doing it all wrong" but that didn't happen and I guess that is not all bad. The chapters and the talk I attended this week by Ken Hygh both confirmed that the Persistence Manager/DAO encapsulation layer approach is a good approach to take in a database-driven web application. All of that being said, I think Ted's book is going to be a great resource for Java developers and I'm looking forward to buying a copy.