It’s Only Software

A month ago, I posted about using inline SVG to simulate the Web 2.0 “shiny floor technique” (SFT) for a mirrored reflection effect on page headings. I have not had time to perfect it, but I figured I’d publish it and see if people are interested in enhancing the technique. Note that this has only been tested thus far on 2 browsers that natively support inline SVG, Firefox 2 and Safari.

Demo Page

For those not running one of the aforementioned browsers, here’s what it looks like:

There are several reasons why this is currently impractical for real-world use (although I’d like to change this):

• This technique will only work if the page is served up as XHTML (content-type application/xhtml+xml, aka “true XHTML”). Since some browsers do not like proper XHTML, this will prevent a large percentage of your audience from seeing this technique in action.
• Currently, the inline SVG is embedded in the page.
• The demonstration of this does not use true headings (h1, etc.)
• The text “SWOOSH” is repeated twice in the page - once in the heading and once in the SVG.

The latter three will be changed in the next published iteration of this technique. In the next iteration, I plan on adding Javascript so that this effect can be added unobtrusively on top of headings on an existing page. This will also allow the effect to degrade gracefully on browsers that do not support inline SVG.

Based on the way that inline SVG is implemented in current browsers (requiring support in the render engine of XML namespaces), I’m not sure whether the requirement of serving the content as true XHTML is a technical hurdle that can be overcome.

As far as I’ve been able to research, this is the first time anything has been published that uses SVG for this type of effect, using only plain text. Prior examples of the SFT have required Photoshop, required Flash, or only work on images.

I’m excited to take it to the next level (as noted above) and hopefully provide something that people find useful.

In my [admittedly] limited 3 years of using Hibernate, I’ve found that a lot of folks are confused about what loggers to use when trying to debug Hibernate issues.

These people (myself included, on occasion) will end up opening the floodgates and doing something like this (log4j) syntax:
<logger name="org.hibernate"> <level value="DEBUG"> </level> </logger>

While this (obviously) works, Hibernate is nothing if not verbose in its logging, and this will easily generate megabytes of Hibernate logs.

Hibernate uses the standard logging pattern of naming loggers after the classes they’re enclosed in, as suggested by Sun itself. So if you’re familiar with the Hibernate code, it can be fairly easy to pick out the right package qualifier in your logging configuration to get logging where you want it.

Unfortunately, many/most developers aren’t familiar enough with the Hibernate source code to know these things off the top of their heads.

Thankfully, the Hibernate folks have kindly documented some logging settings, including logging of SQL (which is the simple shortcut org.hibernate.SQL.

I have a couple more useful loggers to add to the list:

• org.hibernate.engine.query.HQLQueryPlan - which will display the source of any HQL query executed prior to execution and parameter binding
• org.hibernate.engine.QueryParameters - will display the name / value pairs of query parameters bound to HQL queries

I’ll plan on updating this post with additional information as I run across it.