General

JRoller looks like crap in FireFox

Update: Or not. Perhaps I had an old stylesheet floating around, or someone changed a template. Either way, the new layout looks much cleaner, and in fact, much more professional than the old jaggy version.

I wish I had a link to give you with a screen capture, but it looks seriously like nobody tested the new JRoller layout under FireFox (v0.8). Something about the positioning of the DIV elements that causes the left panel (jagged blue image, “logged in as” text, or “Recent Drafts” when looking at your edit screen) to not be wide enough, and the main content ends up overlapping underneath it. Further, I’m noticing that the labels on buttons, etc. are sporadically being replaced with getMessage(“main”) or something like that.

Hope 0.9.9.1 is coming soon. Kudos to the roller team for putting the work into a release, but looks like it still needs a bit of work.

Technology

For Instant Popularity, add a Referrer list to Your Blog

A quick look at the so-called “most popular weblogs” on the front page of jroller shows some unfamiliar names. Surprised at seeing some of the new names, I clicked through, wanting to see if they had something incredibly interesting to say today. Nope. One of them has only one new entry this year. Easily a third of these weblogs have a referrer list on the front page, with less than 10% of their hits coming in direct, and a long list of obvious referrer-spam.

Turn off the referrer list on your blog’s main page. If YOU want to know how people have been arriving at your site, it’s available in the configuration pages. Nobody else cares. Sure, seeing your name on the jroller front page might be a nice ego stroke, but it doesn’t mean squat. You’re just increasing adding more noise to the internet, twice over. First because your blog gets top billing, even if you have nothing interesting to say that day. Second because even when you DO have something interesting to say, there’s a crappy list of useless referrers like cowsearch.com, seekmoose.com, and dontyouwanttofindsomeporn.net scrolling down the screen, polluting your blog. Turn it off.

Java

JBoss, Inc. Considered Toxic?

In a move either personal or political, The Middleware Company, parent of TheServerSide.com has terminated their relationship with JBoss.

This decision is, in many ways, symbolic of the damaged relationship between JBoss and the Java community. Many users or potential users of JBoss will take a step back and reconsider that decision, not questioning the merits of the application server, but questioning the integrity of the company. Marc Fleury has always been a colorful character, but with more of a reputation of keeping things interesting.

Now, the JBoss name is tarnished rather than textured. Before, it was a curiosity. Now, it is a pariah. Do you want a business relationship with a company that will not apologize, not even admit wrongdoing, but just say that they won’t do it in the future (not that they necessarily did it in the past). With their current hiring push, how many talented developers and staff will shy away, fearing that the JBoss name could hurt their future job prospects or harm their reputation? I’m not suggesting that all, or even most will… but it’s enough to matter.

At the foundation, JBoss has been a novel piece of software, and one that has succeeded both through colorful PR and through word of mouth. The latter depends on the community, and this blunder may have just sucked the energy out of their raving fans. $10 million in investment cash is nice, but happenings like this will certainly erode the value of the IPO they have their eye on, and it certainly isn’t enough to try and replace that flattened community buzz they had with marketing efforts to take IBM and BEA head on. Can they recover? Quite probably. But any bump they got from astroturfing can’t possibly make up for the credibility gap they’ve earned.

Java

SOA = Same Old Architecture

Credit goes to Dion for bringing this (witty) alternate abbreviation to my attention. The TSS posting about BEA pushing Service Oriented Architecture brought to my attention how SOA is a magic marketing term that pretends to somehow wrap SOAP/Web Services in a way that precludes bad design. (My full comments here.)

Just more bait for PHBs to think they need to spend money on something they can already do today. In fact, SOA may itself be bad design if applications are unnecessarily decoupled in this way (which seems a likely result, given the way it’s being pushed).

Java

IBM Best Practices: Fish In a Barrel

IBM has posted a flamebait article detailing “best practices for J2EE application development”. Lists such as this can be helpful, but they’ve forgotten the simple complexity of the number of layers and complexity matching the complexity of the app. Many of the practices are good starting points, but by no means should they be rules.

The best practices

   1. Always use MVC.
   2. Apply automated unit tests and test harnesses at every layer.
   3. Develop to the specifications, not the application server.
   4. Plan for using J2EE security from Day One.
   5. Build what you know.
   6. Always use Session Facades whenever you use EJB components.
   7. Use stateless session beans instead of stateful session beans.
   8. Use container-managed transactions.
   9. Prefer JSPs as your first choice of presentation technology.
  10. When using HttpSessions, store only as much state as you need
      for the current business transaction and no more.
  11. In WebSphere, turn on dynamic caching and use the WebSphere servlet
      caching mechanism.
  12. Prefer CMP Entity beans as a first-pass solution for O/R mapping
      due to the programmer productivity benefits.

1. Always? What if I’m writing a one page app? What if all I want is a page that displays the time? There are such things as apps too simple for MVC.

2. Units tests at every layer? I’ve challenged for some time the degree to which some people suggest that you test your data access layer. Suppose you want to test a simple DAO class that retrieves an object by its id from a database using Hibernate. If that method simply calls Session.load(Class c, Object id), what are you really testing there? Hibernate? Your configuration? What database do you test against, and which values do you compare to determine success? The value/effort ratio is pretty low here.

3. The point is not to get into app server specific configuration and coding. The problem is that they use the example of J2EE security. What’s the issue? Well, in order to use J2EE security, you have to configure JAAS in a way that is app server proprietary. A good general principle, but it can’t be strictly followed.

4. A topic near and dear to my heart, security. Turn it on always? What if your app doesn’t need security? What if you need 2 factor authentication, which isn’t supported by J2EE security? Favor the use of J2EE security, yes. Always turn it on? No way.

5. Build what you know – an okay philosophy, I suppose. Basically, build your app a layer at a time instead of building it all at once. I’d say to at least fire a tracer bullet first.

6. ALWAYS use session facades with EJB components? Even if your app only has two stateless session beans? Overengineered. Refactor the session facade in later when complexity justifies it.

7. Avoid stateful session beans when possible. Fair enough – they’ve given some wiggle room here, which makes it reasonable.

8. Use container managed transactions. Fine.

9. Prefer JSPs. I actually generally agree with this. This step actually suggests that developers fight the urge to get fancy with XML/XSL when the requirements don’t justify it. Tapestry users get a pass here – though I personally find Tapestry to be a bit cumbersome, it can’t be equated with the whole XSLT to generate HTML crowd.

10. Use the HttpSession only for what you immediately need for this business transaction. The goal is noble – keep the session small so you can persist sessions and improve performance. Saying to only put info for the current transaction is a bit limiting. It seems plausible to also store general into about the application, or data about another transaction recently completed. Keeping the session small should be the actual suggestion.

11. In websphere… … turn on caching. Maybe – don’t know enough about their caching implementation to comment.

12. Prefer CMP Entity Beans for the productivity benefits. Although EJB 2.0 has made great strides, the Entity Bean model is already so cumbersome and has some limitations that make it a questionable choice at best. This is typical vendor-speak.

Technology

HTML Fails, CSS perils – apparently some layouts are impossible without frames

As mentioned yesterday, I’ve been looking to do a not to complicated layout in HTML that I’ve nearly verified to be impossible – I think I could do it with some Javascript to put the finishing touches on it, but needing Javascript to ensure my site doesn’t look like garbage doesn’t seem like a wise path.

The target was a frameless version of this layout. Left panel is a fixed width, and the full height of the screen (variable). The header is fixed height, with a variable width that fills the remainder of the available space. The content panel should be of variable height and width, filling whatever rectangle isn’t used by the other 2, but should not exceed the height of the window – the pane should scroll to show the rest of the content.

Community suggestions were well-intentioned but fruitless. Browsers seem to completely disrespect my pleas of height=”100%” or even max-height=”100%” – like I was joking or something. This site has the right idea, but it appears they’ve cheated by making their content pane full height – notice how the scrollbar extends through the header. The layout doesn’t seem that difficult – it’s trivial in frames. All that’s really needed is the concept frames has of weighted layout where an element with a height of * will take the rest of the available dimension (assuming all other dimensions are fixed width). Add that to CSS and tables and your set. Why is this so hard? I can make text blink, appear, or disappear when my mouse is over it. I can have text flow around inset panels of info… why not a simple, non-frames, non-vertical scrolling layout?

Java

HTML – a sorry excuse for display markup

A rant driven by an HTML shortcoming. I want something simple – I want to be able to create a layout like this without using frames. But I can’t. Simple desire – I want a left menu and a top header that are fixed, and a content area that fills the rest of the browser area, and can scroll, but the content scrollbar should be the only scrollbar on the screen, and the header and navigation should remain fixed.

The fact of the matter is that frames suck – the page you see is driven by frames. Many mobile devices that support HTML don’t support frames, and it’s silly to have to load 4 different html pages to display that one screen. It’s nearly impossible using Struts to get a good Tiles template together to use frames. The main option seems to be using the getAsString tag in your layout file to indicate which page should be loaded into that frame. The problem is that you really want a more detailed template than that. You’d like your template to be define parts of each frame as well, but since the user’s browser loads the frameset, and the browser then requests each of the 4 pages, you lose your request context, and you can’t use tiles:insert in each frame. Further, any data that you stored in request scope is lost by the time you get to rendering actual content.

I’ve tried this technique to render the same view using scrollable DIV areas, but it failed. The problem is that the header needs to be a fixed size, and the content area should be able to take up the rest of the page. Frames have the * operator to indicate that an area should take whatever space is available. A COLSET can use the same thing. Strangely, for rows, there’s no such attribute. It’s as though the idea of a page designer wanting the height of the page to match the height of the browser window is completely foreign. It truly amazes me that we’ve been using HTML for so long and there’s still no way to express such a simple idea without using the atrocity (and web app unfriendly construct) that is frames.

Addendum: I realize that HTML was never intended to do half the things it does currently. What amazes me is that we haven’t managed to standardize something better (where standardize means cross-browser compatible).

Java

Metadata for Struts & Hibernate

Recent entries from Emmanuel and Cedric have me seriously thinking about the long term impact of JSR 175, the standard metadata interface for Java. I don’t think the average user will have much use for defining their own metadata interfaces, but I do think there is a great deal of room for application frameworks to rethink the way they configure their apps.

The use of XDoclet and the creation of this spec seem to be a reaction to the XML hell that many frameworks create. In frameworks like Struts and Hibernate, the idea of using XML to decouple your mappings from your objects is somewhat of a red herring, in that the very objects you’re writing are tied to that framework, tied to that metadata. What good is a StrutsAction without Struts? And for Hibernate, you have to include information about your class in the mappings, so they’re still tightly coupled. The only other flexibility given by xml configurations is the ability to tweak the application without rebuilding the app, but how often will you roll in a production change without first at least running some tests on it in another environment? Is typing “ant” really that hard?

Still, the inability of XDoclet to handle many scenarios for frameworks (Hibernate composite-id generation) and its non-standard nature have prevented its full adoption as a means of code generation. The metadata spec seems to offer enough flexibility to overcome this, and combined with the ability to inspect the metadata programmatically at runtime I believe it can be a powerful alternative to XML config files.

What if a Struts action looked like this?:

@StrutsAction(
  @ActionMappings({
    @ActionMapping(
      path=”index”,
      @ActionForwards({
        @ActionForward(name=”success”, path=”index.jsp”),
        @ActionForward(name=”failure”, path=”error.jsp”)
      })
    )
  })
)
public class IndexAction extends Action
{
….

So when ActionServlet initializes, it can search the classpath for classes with StrutsAction annotations and register them into its configuration. Additional metadata provided in an extension of ActionServlet could give instructions on what classpath to search for annotated struts elements. ActionForm could be similar designed and discovered.

Does it make your code pretty? Not necessarily. But are XML mapping files pretty? No. But metadata can simplify the number of files we need to maintain for these frameworks while still giving full control over the configuration. It’s more standard, more complete, and more strongly defined than XDoclet.

The following metadata interfaces would back up the suggested approach:

public @interface StrutsAction {
  ActionMappings mappings();
}

public @interface ActionMappings {
 ActionMapping[] value();
}
public @interface ActionMapping {
  String path();
  String form() default””;
  String input() default “”;
  ActionForwards value();
}

public @interface ActionForwards {
  ActionForward[] value();
}

public @interface ActionForward {
  String name();
  String path();
}

P.S. – If I’ve got the syntax wrong, let me know. There’s not much example code out there at the moment.

Update: After looking at Matt Raible’s thoughts on the look of this code, I cleaned it up a little bit – consolidating the lines for the ActionForwards.

General

Fahrenheit 9/11 is not a documentary

Nor is pretty much anything Michael Moore puts on film. It’s flat out appalling how much credence the media lends to Moore’s films by surrepetitiously calling them documentaries. What’s a documentary?

doc·u·men·ta·ry -  2. Presenting facts objectively without editorializing or 
inserting fictional matter, as in a book or film.

That’s right, objectively without editorializing. Moore’s Fahrenheit 9/11 is detailed on the Cannes Film Festival Site as “a documentary that denounces the errors of the Bush government’s policies”. How can an a film “objectively without editorializing” denounce the errors of anyone? Denouncing implies judgement, which obliterates objectiveness. To the average person, calling a film a documentary suggests that it has taken an objective, fact-based approach to the subject matter. By calling the film a documentary rather than a film editorial, they are advancing the agenda that this film is fact rather than what it is – a slanted look at current events – an opinion editorial on film.

Moore intentionally refuses to cover different angles on his subjects, because that wouldn’t satisfy his political agenda. Clearly he has an agenda, his books and public comments are sufficient to establish that. A better documentarian could separate opinion from fact, and give an issue that intrigued them a fair treatment – the director of “Super Size Me” has made it a point that his goal is not to blame the fast food industry, and that the subject also involves personal choice. Moore invokes no such balance in his filmmaking, choosing to give topics treatments that serve his subjective purposes. He deserves a category all his own for feature-length editorials.

Java

Hibernate Metadata Explored

JSR-175, standardized metadata, may have more potential to simplify configuration of Hibernate than of Struts. Why do I say this?

  • Hibernate has a one-to-one relationship between mapped objects and mapping files.
  • Shortcomings in XDoclet make it impossible to generate composite-id mappings, so there’s an immediate value-add.
  • Unlike Struts, there’s no large configuration file shared by the whole framework. hibernate.properties is small and used only for configuration.
  • The mappings are generated at the attribute level, so more of the bindings (return type, etc) can be determined by reflection rather than the user needing to enter them (Xdoclet can generate this).

Let’s take a look at an example (supplemental code will be at the bottom):

@HibernateMapping( table="employees")
public class Employee
{
    private Name name;  //Yes, name as primary key is dumb
    private String job;
    private Date startDate;

    @HibernateCompositeId({
      @HibernateCompositeIdAttribute(name="firstName", column="first_name"),
      @HibernateCompositeIdAttribute(name="lastName", column="last_name")
    })
    public Name getName() { return name;}

    @HibernateAttribute(column="start_date")
    public Date getStartDate() { return startDate; }

    @HibernateAttribute(column="current_job")
    public String getJob() { return job; }

    //The setters go here

In this case, the metadata approach almost matches the line length of the XDoclet tags to accomplish the same task, and as mentioned, exceeds XDoclet’s capabilities in capturing the composite-id in metadata. (Don’t get me wrong, I like and use XDoclet.)

Don’t give me this story about the advantage a separate config file gives you (in this specfic case). There’s 2 main types of change that affect an hbm.xml file – one is changes to the class. That’s where the existing approach can be a pain – you have to add/remove/change the attribute in the class and the mapping. The other case is a database change, which isn’t a trivial thing. The planning that goes into making changes to a production database can certainly include planning to change the metadata and rebuild your app. It could help you if you have different table and column names in your different environments, but that sounds like a recipe for disaster anyhow.

Because annotations can be reflected at runtime, Hibernate could automatically detect @HibernateMapping classes and add them to its Configuration. Clearly, an @Configuration annotation would be needed to specify some configuration parameters, and could even give a limited classpath to search (e.g. com.kischuk.*) to speed the search for persistable classes. The metadata approach also causes at least some constraints on the format of the metadata to be enforced at compile time rather than runtime.

Supporting code follows (4 different interfaces):

public @interface HibernateMapping
{
   String table();
}

public @interface HibernateAttribute
{
    public String column();
}

public @interface HibernateCompositeId
{
    public HibernateCompositeIdAttribute[] value();
}

public @interface HibernateCompositeIdAttribute
{
    public String name();
    public String column();
}