Blogging Roller

Monologue aggregates weblog entries from Mono bloggers, all 10 of them. That is a nice start.

Ben Maurer In that spirit, I make a plea to the Open Source community: please, please, think about other platforms. In the end, making your software not run on Mono will just hurt both projects, helping no one. I realize for a Windows developer who has never programmed for Linux writing with compatibility in mind does not come naturally. If there is enough community demand, I would be happy to write some guidelines and pointers for software authors to ease this process.

Can Dot-Net developers be convinced that cross-platform portability is important? I'm not talking about "it runs on Windows 2000 and Windows XP" type portability, I'm talking about the real deal. Sounds like a hard sell, doesn't it. Most Microsoft devotees seem to believe that "cross-platform is a silly concept that only works on paper." And don't forget, Microsoft is the company that made it so easy to build non-portable applications with Java that the Justice Department ordered them to put warning popup in Visual J++.

Maybe Mono and Linux will succeed where Java and the Java platform failed. They will finally make convince Microsoft and Microsoft developers that cross-platform works, or at least the Windows/Linux part, and is no longer just a silly concept. There is some evidence of success. Ben Maurer of Ximian has been working on porting Dot-Net applications to Mono and hasn't thrown up his hands in frustration quite yet. Jason Alexander is working the evangelism angle and urging Dot-Net heads to be Mono Aware. As Jason Alexander's co-star might say "good luck with all that."

Update: due to my sarcasm and poorly chosen words, at least one person did not get my meaning. I certainly don't believe that cross-platform portability is a silly concept. I made some changes indicated by strikes and underlines above to try to clarify my point.

<a href= "http://www.usnews.com/usnews/issue/031020/usnews/20black.peo.htm?track=rss"> Jack Black: I am going to do an exercise book. You shouldn't exercise. It's like you don't want to put too many miles on a car; why would you want to put a lot of miles on your body? Keep it in the garage, cover it with a tarp.

Joel Splodsky has written an excellent <a href= "http://www.joelonsoftware.com/articles/Unicode.html">summary of unicode and character sets. Email it to all of your co-workers right now.

Finally, some help for newbie JRollers.

<img src="http://www.rollerweblogger.org/resources/roller/jrolling-handbook.png" alt="image of Joint Rolling book" />

Jon Udell, Why Mozilla Matters: The pros and cons of the browser's always-connected page-refresh model are well-understood. Zero-footprint, cross-platform ubiquity is the upside, a clumsy UI tied to a Net umbilical cord is the downside.

People seem to understand the need for XDoclet code generation in the EJB world where there is a lot of boiler plate code and lots of ugly deployment descriptors to be written, but I've had a harder time convincing people to use XDoclet to generate web.xml, tag library descriptors, and Struts configs.

My coworkers understand the Servlet specification and they know the details of the web.xml DTD, so they see XDoclet as just another quirky tool to be learned. It seems to get in the way, it has bugs, and it is not always updated quickly enough for folks want to use the latest stuff (Servlets 2.4 for example). Learning to use the XDoclet tags is not all that difficult, the open source allows capable programmers to make bug and enhancements, but this is not very reassuring to folks who just want to add another Filter Mapping to web.xml, right now, damnit.

I've gone a couple of rounds with folks discussing pros and cons and I forgot the most obvious argument - continuous integration. The best reason to use a tool like XDoclet to generate web.xml, tag library descriptors, Struts configs, and other goodies is refactoring. If you have a bunch of Servlets, JSP Tags, and Struts Action classes in your code and you want to refactor your code by renaming classes and moving them between packages then you will have to carefully edit web.xml, your TLDs, and your struts-config.xml to correct all of the changed class and package names. If you were using the XDoclet @servlet, @jsp.tag, and @struts.action tags you would have no worries - all of your deployment files would be auto-magically updated.

Rumor has it that Eclipse 3.0 M4 will be released shortly and that a JSP editor will be included. Update: it is out now and the new feature list looks good. Another update: Werner Ramaekers provides a nice  summary of the new release.

A couple of weeks ago, I opened up the RollerWiki again. I quietly removed the security and hoped for the best. A number of people have been making small additions, corrections, and other good things but tonight I found that the whole front page was replaced with this:

This Website Has Been Hacked By KingSerb

KingSerb@linuxmail.org - synx_10@hotmail.com
"Check Mate, Admin !"

GreeTz: SCriptX, GUL7, OffSet, JuXta, El Matador.

Pretty funny. This guy thinks editing a wiki page qualifies as hacking a website? What an idiot. According to the revision history the attacker's IP is 207.44.154.35.

At my day job, our product is finally approaching feature complete. Monday is the day we go to QA, so I'm working hard now to avoid working hard this weekend. The product and the new job in general has been a lot of fun. I've been able to learn a lot more about Struts, Struts Validator, Struts Tiles, XDoclet, JavaScript, JSP, and code generation.

The amount of code generation going on in our build process is just amazing. We start with a database schema definition DDL file that is marked up with funky XDoclet-style comments. From that we generate all of our business obects, JDBC code to persist these objects, auditing code, workflow code, Struts forms, and the english version of our I18N properties file. Our internally developed and Scheme-based code generator generates something like 90,000 lines of code based on a 900 line DDL file in about 3 seconds. Next, we run XDoclet over our code based to generate our Struts config file, Struts validator file, and our TLD. XDoclet is the dog of the build process; it takes about 10 seconds to generate a couple of hundred lines of code.

I don't know how we would have written this product in the time allowed if we had not used the code generation approach. Everybody is amazed at the progress and the agility we have in adapting to data model changes. The only problem raised by the code generation is customization. How can our consultants in the field customize our system when most of the code is "GENERATED CODE - DO NOT MODIFY"? The answer is that we won't consultants customize the code. Instead we'll try to make everything customer configurable through the product UI. That is our next challenge.

The new bloggers are rolling in over at JRoller. It is amazing and a little scary. Some of the bloggers do not seem to have any idea what a blog is. I'm sure this will result in a lot of ghost blogs, but I'm also sure that we'll see some great new blogs popping up.

Rick Ross: it is my great pleasure to announce that we have formally adopted the Java-powered and Java-centric blogging system formerly known as "FreeRoller.net" and begun the process of re-launching it as "JRoller.com."

Thanks to Rick Ross, Matthew Schmitt, Anthony Eden, and the Roller contributors for making this happen.

I've been making progress on a series of bug fixes for Roller 0.9.8. You can check the progress on Roller's JIRA issue tracker.

I just deployed Roller 0.9.8.1-dev to this site to test the new RSS 2.0 template. The old template was based on a very old Mark Pilgrim template and it used a bunch of Dublin Core elements like <dc:date> and others - it was pretty funky. If you complained that all posts appear to be new posts on JRoller, this site, and other Roller-based blogs then please give my new feed a try. Does this change fix the problem?

There are still a couple of issues to be resolved, so I'm not quite ready to deploy anything to JRoller.

I just received an email that asked the question "could you please tell me the differences between Blojsom and Roller Weblogger? Which one is better or what could you tell me about these both projects?" Below is my reply.

I think the main advantages that Roller has over Blojsom are full multi-user support and a web-based UI for editing blogs, managing bookmarks, configuring blogs/themes, and for configuring the system. Blojsom doesn't have an extensive web-based UI like Roller's. The main disadvantage of Roller is that it requires a database and this requirement makes installation and maintenance a little more difficult. If you are going to build a community site like ruckyou.com or jroller.com, then Roller seems like the obvious choice. For comparison: the Roller Installation Guide and User Guide.

The main advantages that Blogsom has over Roller are that it is small, easy to setup, has an extensible architecture with excellent support for plugins. One example: with Roller, your page templates must use Velocity macros. With Blojsom, there are a number of plugin options for page templates. If you are going to run a single user blog, you don't want the hassles of setting up a database, and you are happy without a web UI for managing your blog, then Blojsom seems like the obvious choice. For comparison: the Blojsom Installation/User Guide

If you looking for a good blogging tool, you might want to widen your search. Is there a reason that you are looking only at Java-based blogging software? If you are a Java programmer and you want to be able to customize your blogging software or contribute to it's development then Roller or Blojsom are good choices. If you are techically saavy, you want to setup you own bogging software on your ISP's site, and you don't care what language was used to write the blogging software, then expand your search to include other choices like MovableType. If you don't want the hassles of setting up your own blogging software then look at JRoller, Blogger, Typepad, or one of the other blogging services.

Jeremy Zawodny discusses the options for fighting weblog comment spam. Right now, my only weapon is seek and destroy enabled by select w.title,w.pubtime from comment as c,weblogentry as w where c.entryid=w.id and c.content like '%viagra%'.

Werner Ramaeker speculates that Hibernate will become JDO 2.0 compliant.

OK, we don't know what the JRoller terms of service are going to be, but now is definitely the time to take a stand against the giant freedom hating global JavaLobby comglomerate that has taken over FreeRoller. As Chiara has pointed out, JavaLobby is obligated to provide free weblogs, free bandwidth, free file storage, free system adminstration services, and free support to anybody and everbody who wants a weblog - all without charging a dime to anybody, placing any advertisements, or restricting anybody elses right to place advertisements. If JavaLobby somehow weasels out of this obligation, then Anthony Eden must do it. He should be put under house arrest and forced to again serve the community that he started. If Anthony escapes house arrest, then the Roller authors should be put into bondage, have their assets siezed, and be forced to comply with Chiara's every wish. As I have said before: if, at this point, you do not know that I am kidding, then you are an idiot.

Those are the largest "1 oz." beers I've even seen. Cheers, Matt.

Joe Gregorio: room-mate from hell.

Some have noticed that FreeRoller has become JRoller and some have started to wonder just what in the blue blazes is going on. Fear not Java bloggers, good things are happening. The JavaLobby will probably be making a more formal announcement at some point, but now that the cat is out of the bag, I'll give you my take on this story.

Now that the Roller software that drives the site has proven itself, JavaLobby is stepping in to support, administer, and nurture the JRoller community. JavaLobby is putting in place scheduled backups, issue tracking (via everybody's favorite: JIRA), and customizations to tie JRoller into the JavaLobby community. I'm going to take an active role, along side other JavaLobby volunteers, in the support of JRoller.

Here are a couple of anticipated FAQs:

Why is the JavaLobby doing this? Blogging fits in perfectly with the JavaLobby charter because it gives individual Java developers a voice and a platform for sharing, learning, activism, and community building.

What does this mean to JRoller users? With JavaLobby backing and support, JRoller users can expect better levels of service and better support. JRoller will remain free and there are no plans for adding or allowing advertising on user weblog pages or RSS feeds.

What does this mean to the Roller Weblogger software? As before, Roller will remain a separate an independent product and project, but Roller releases will now be tested on JRoller (as we did with Roller 0.9.8) before they are released on SourceForge. JRoller will remain on the bleeding edge of Roller development, sound like fun?

What about the links to my blog, will they be broken? FreeRoller founder Anthony Eden has agreed to continue to point the FreeRoller domain at JRoller so that FreeRoller links will remain valid, but requests are are now being redirected to JRoller.com. I encourage you to start using the new name JRoller and the new URL in your links to JRoller based blogs.