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 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.


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,, and scrolling down the screen, polluting your blog. Turn it off.


JBoss, Inc. Considered Toxic?

In a move either personal or political, The Middleware Company, parent of 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.


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


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.


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?


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