Software Development With Scott

After three years of using Windows Live Spaces, I have finally decided to bite the bullet and move my blog to a more capable blogging platform.  From now on, you will be able to find me at http://www.scottmcmaster365.com/, also known as http://scottmcmaster365.blogspot.com/.  If you are so inclined, show me a little link favor in the coming days so that I can get this site established in the search rankings.  And if you're subscribed, please update your feed, and I hope to hear from you soon.

In the past, I've used soapUI for validating and testing WSDL-based web services.  Now it also has REST support.  This is great timing for me, because I've been standing up some new RESTful services using Restlet.  I had been performing ad-hoc testing of my services using silly little custom C# applications for the things that aren't readily available directly from the browser address bar (like HTTP PUT and DELETE).  I was hoping that the new functionality in soapUI would allow me to ditch that approach.

And I wasn't disappointed.  This wasn't a big surprise given my past experience with the tool, but creating new REST resource requests for my API using soapUI was very easy and intuitive.  In fact, the logic (and URL template syntax) is quite reminiscent of defining routes in Restlet.  I won't go through the UI in any detail because Sanjay Acharya does that very well here.

Just messing around, I also generated WADL files for my services.  I had actually never heard of WADL before, but it ostensibly addresses in a lightweight fashion one of the main problems I've always had with REST, namely, the lack of any means to formally and machine-readably specify the interface.

I expect to be able to leverage all of the new soapUI goodies going forward.  What a great tool!

After mentioning in my last post how one can always use the Google cache to work around web sites that expose different content to the Googlebot, it occurred to me that I could accomplish the same thing in one less step by using the User Agent Switcher for Firefox.  This add-on does exactly what you'd expect it to do, which makes it a handy web testing tool to the extent that modern versions of Firefox can deal with renderings presumably customized for other browsers.  But it doesn't come with a lot of pre-configured User Agents.  No matter -- people have posted XML files of agents which can easily be imported.  I use a good one from here.  One of the agents in this file is the Googlebot.  To use the User Agent Switcher, you just pick an agent under the Tools menu in Firefox.  So browse to a random page that customizes its content for the Googlebot, such as -- oh, I don't know -- this one, with and without the Googlebot User Agent switched on in FF, and notice the difference.

Sometimes I check out the Referrer URLs to my blog because it's pretty much the only way that Windows Live Spaces gives you to figure out which entries generate the most interest.  (A very inaccurate, limited, and lame way.  Is anyone from Microsoft listening?)  Fairly often, I see incoming links for Experts Exchange.  I don't subscribe to Experts Exchange, primarily because I have never figured out why I would want to pay for information that is generally just as easily available for free elsewhere.  (Specific example below.)

I was curious, however, about the context from which they were linking to a couple of my popular NHibernate posts.  So I Googled and found the following:  http://www.experts-exchange.com/Programming/Languages/.NET/ASP.NET/Q_23086354.html.  Of course, Experts Exchange lets you see the question but ostensibly makes you pay for the answer.

No matter, I just checked the Google cache.  Experts Exchange obviously gets their answers to rate highly on Google by exposing full, unprotected content to the Googlebot.  Back when I was learning about SEO, I got the impression that this style of User Agent bait-and-switch was a huge no-no and could get you severely penalized in the rankings, but, whatever -- the net result is that their full content is basically available for free to anyone who thinks about it.

What I discovered was that the "Accepted Solution" from the Exchange's "Expert" was simply a list of links to six posts, two of which were mine.  No value added whatsoever.  So who are the real "experts" in this picture :-)?

Last year I wrote a short post questioning whether the advent of multi-core processors would really impact the day-to-day live of most programmers and force them to be more explicitly aware of concurrency.  The latest issue of Communications of the ACM contains an article by Bryan Cantrill and Jeff Bonwick of Sun that sums up the current situation regarding concurrency better than anything else I've seen.  I would encourage anyone who read my earlier post to check this out, because much of it meshes nicely with what I was trying to get at (but it's much better thought-out and written).

In my last post, I opined a bit on eager versus lazy loading in object-relational mapping.  At the end as an aside, I lamented that frameworks such as Hibernate are unnecessarily restrictive in requiring that you specify fetch behavior in the mappings.

Ayende (who must still follow me once in awhile even though I've been doing mostly Java-related blogging lately ;-)) pinged me to point out that NHibernate (as well as Hibernate) allows you to override the Default values at runtime.  (Thanks Oren.)  He didn't say, but I presume he's referring to the setFetchMode API, which allows you to specify SELECT (a.k.a. LAZY) or EAGER.  This solution can be a bit of a nuisance, though, because it forces you to do a Criteria query even when you want to select a single instance by primary key, where ordinarily the more idiomatic get or load would suffice.

Yesterday I came across an article entitled "Optimize LINQ to SQL Performance" by Roger Jennings, in which the virtues of eager loading in LINQ are extolled, generally at the expense of lazy loading.  I don't have any major quibbles with anything Roger did in his performance evaluation.  (Beyond, that is, demonstrating yet again the scary practice of pushing hierarchical resultsets directly into grids in .NET, that being the root of much performance evil, at least in web applications.)

The thing I wanted to comment on are the notions conveyed by the article (perhaps unintentionally) that eager loading is somehow "better" than lazy loading, and database round-trips are always what must be optimized in a data access strategy.  In a networked application, usually what you really want to optimize is the amount of data that gets shipped over the wire to the client.

If I could impart one piece of advice to those of you building data access layers, it would be to always consider your user scenarios and usage patterns.  Then, try not to retrieve data that you don't have a fairly good reason to believe the user will look at.  The easiest way to do this is to wait as long as possible before fetching and marshaling data.  This is where lazy loading can be incredibly helpful.

In the Customers->Orders->OrderDetails scenario described in the article, it might be best to load just the top level (Customer), providing a drill-down UI.  When the user drills into a Customer, only then would you (lazily) load up the Orders rows.  In a web application, you could AJAXify this operation.  Depending on how many Orders rows there are and how likely it is that the user will then want to see details on some substantial number of them, you might eagerly load OrderDetails at this point.  Or not.  The point is that it all depends on the application.

(One good thing about LINQ is that the loading behavior can be specified at retrieval time using DataLoadOptions, and it is not strongly coupled to the object-relational mappings themselves.  This is a major improvement over traditional Hibernate and Toplink mappings where the load behavior is specified in the mappings, thereby making it difficult to follow my advice in many situations.)