John Lindal’s Blog

Google

My simmering indigestion from the articles about Google by Coding Horror and Whimsley caused me to burp up the thought that Google might actually be adjusting their search results to optimize revenue. I posted a quick comment on Coding Horror and wasn’t planning to mull it over any further, but then I realized that Google must be doing this. The only question is: To what extent?

If a site is displayed in the paid section, it is actually quite reasonable that Google does not show that site in the unpaid section. But what if moving a particular unpaid result to page 2 increases the number of clicks on the paid results? Almost nobody bothers to view page 2 of the results, so the result effectively ceases to exist! Even moving a result to the bottom of page 1 would have a huge impact, since many people probably don’t even bother to scroll down.

It would be easy for Google to do this kind of optimization. They have so much traffic that they could bucket test small fractions to look for significant increases in CTR without anybody noticing. So from the outside, this seems impossible to prove. Google is a black box, so who can say whether a particular result belongs on page 1 or page 2? But the thought that a particular site might effectively cease to exist in order to satisfy Google’s hunger for profit is pretty scary…

Update (2/18/10): I just noticed that Google does not filter out sites from the unpaid section if they are listed in the paid section.

Apple Rocks

My wife admitted a long time ago that iPhoto really good at making photo books. Recently, we were discussing typing in Chinese, and she didn’t believe me when I said that Apple included it as part of the OS, since on Windows, she has to purchase special software. About 5 minutes later, I had it working on my Mac, and she had to admit that Apple really was good. A couple of days ago, she actually uninstalled both Internet Explorer and Firefox from her Windows XP laptop and loaded Safari instead. And she loves it!

Improved Error Reporting in JSP’s

JSP’s are a pain because all errors go to the server log instead of the screen. This is not conducive to rapid iteration. In my quest to fix this, I first added a catch (ServletException ex) block to the first filter in the chain defined in my web.xml.

Then I discovered that Tiles swallows errors in included JSP’s. This blog confirmed my conclusions from researching into the Tiles source code. You need to implement a custom JspTilesRequestContext. I prefer to configure via web.xml rather than Spring. It works either way. Note that for Tiles 2.0.x, the online documentation is wrong! The key is org.apache.tiles.context.ChainTilesContextFactory.FACTORY_CLASS_NAMES, not org.apache.tiles.context.ChainedTilesContextFactory.FACTORY_CLASS_NAMES. The latter only works for Tiles 2.1.x.

Another important issue is that displaying an error page only works if no output has been committed. If some output has already been written, you have to append to that. Through trial and error, I discovered that the following will close all possible traps, so the error output will always be visible:

""></script></style></head>

Before Tiles 2.0.6, JspTilesRequestContext throws a plain IOException. For JDK 1.5, this cannot contain a cause, so you must look at the logs for the original exception. Tiles 2.0.6 introduces TilesIOException which does include the cause. This cause is always a ServletException.

The exception that my code actually catches is usually an onion. To get at the root problem, you need to drill in until you find an exception with null cause. To make it more confusing, you must call getRootCause() on ServletException and getCause() on all other exceptions. In order to get a line number in the JSP, you must print all intermediate exceptions. One of them will usually include an excerpt from your JSP.

Semantic Markup

JSP has warts. For example, tags built using Java can contain <&...> in the body, but tags built as .tag files cannot. But JSP is wonderful for building a semantic layer on top of raw HTML. Finally, we can get beyond the assembly code level. It’s really simple, too. All you need is a single Java-based tag which can echo from an arbitrary resource bundle. Pass the resource key (and the bundle name, if you want to be generic) as a parameter to the tag. Presto! As long as the name of the key is semantic, you can write <st:tag type="my-semantic-name">...</st:tag> instead of raw HTML. If you want to be sexier, you can group the tags and leverage the tag name: <st:my-tag-group type="my-semantic-type">...</st:tag>. The practical side of semantic markup now becomes obvious: You can change the raw HTML in one place and your entire application updates to the new markup structure.

Of course, you don’t have to stop there. How about a smart replacement for <head> that automatically includes your CSS and JavaScript? Even better, make it load either the debugging or minified versions based on a cookie (signed, of course) so you can serve minified to everybody else, but turn on debugging for yourself!