The Rabid Paladin

If you have the eye of a good copy editor, you might have noticed some volatility in the ole Tag Cloud on the right. I made some changes at the request of people on the SubText developers list and reworked some stuff—most of which is completely invisible. The biggest visible change is that I decided that assuming an even dispersion around the mean might work in natural statistics, blog post tags tend to be more of a declining curve however.

What that means is that most algorithms for displaying tag clouds use a formula that allocates about half their categories to styles that are never visible. Most tag clouds I saw had slots for up to seven different visual styles that only really displayed three or four.

Well, that's just a waste of a good idea, I say! So I mucked with the weighting formula so that I'd see more visual variation in my clouds. We'll have to see if my theory holds after scrutiny and on blogs with larger traffic.

I just completed some SubText hacking and the results should be visible now. In addition to upgrading to version 1.9.5 (which should officially release here shortly), I implemented a new feature: Tag Clouds. I'd had enough of my feature envy from all the cool kids who had them, so I went and rolled my own. If you're at my actual site (as opposed to a feed reader), the Tag Cloud is off on the right.

This was a non-trivial feature to add. In an email conversation on the SubText developers' list a couple months ago, Phil Haack (semi-benevolent project dictator) indicated that he planned on tags being first-order objects—meaning that they'd have their own table and post cross-reference. They'd also be allowed to penetrate into other public interfaces (as they'd pretty much have to do). The main point from the majority of developers in that discussion was that they wanted Tags to be done well and fully and support all the different tag providers out there.

Like RSS and other Internet wonders, tags are fundamentally simple in concept. A tag is defined as simply any hyper link with a "rel" attribute of "tag". Something like this:

The biggest gotcha in this setup is that officially, the "name" of the tag is determined by the link and not by the text of the link. So if your link were like this:

 The tag is officially "competence" even though it displays "incompetence".

Which means that the core of the feature is scanning posts on insert and update to catch any tags they might contain and adding/updating the links needed for the tags in the post. All I can say is thank heavens for RegEx. It's a pain in the pinky toe to understand, learn, or debug, but you just can't beat it for parsing text. For the curious, and to open myself to ridicule, I'll give you the expressions I used (both case insensitive).

To find a link: <a(?<element>.*?href=[\"'](?<url>.*?)[\"'].*?)>.*?</a>

To figure if the link is a tag: rel=[\"']tag[\"']

Oh, be careful there if you use or copy those expressions; this was done in C# so quote characters are escaped using the \ character.

Anyway, it's done now, and I'd appreciate hearing any trouble you might have. I already caught a choke when the tag includes a "." in it. Fortunately that one just took a RegEx change in web.config so the tag display handler would pick it up. I'll create another post later detailing how to add a tag cloud to a random skin once this upgrade gets added to the SubText project officially.

Well, it turns out that, like Simone, I am a DHSB programmer. I can't say that I'm surprised. The only part I'm a little leery of is that S. It just sounds so unfriendly to be a Solo programmer. I've worked in some excellent teams in the past, but coordinating with others is something I had to consciously learn to be good at.

Here's the breakdown:

• Doer
• High Level
• Solo
• liBeral

Have you ever hacked a product to do something it wasn't intended to do in order to "simplify" things for your users and have that blow up in your face? This is an account of my experiences doing just that with MS Reporting Services.

If you've used Reporting Services at all, you'll know that there are two virtual directories that are created on IIS when you first install it to a server: ReportServer actually serves up the reports by passing the requested data to external applications via whatever protocol you have configured and Reports (aka ReportManager) which serves as a user interface for reports on the server.

ReportManager is, by far, the most visible of the two. Using ReportManager, you can organize your reports and data sources and set permissions on who can view and change them. Often, this is enough of a user interface that it is a viable deployment mechanism to simply point your users to the Url for a report under the ReportManager directory.

Ingenious people, like myself, will often designate a new Web instance on IIS just for Reporting Services, generally naming it something clever like "reports". When you do this, it is very tempting to point the root directory of that web instance to the ReportManager directory. This means that you can point your users to "http://reports/Invoice" instead of "http://reports/Reports/Invoice". You can see why you'd want to make this change (assuming you are similarly obsessive).

There is, however, an unintended side-effect to this change. Once you do this, your ReportServer will begin throwing errors if you ever decide you want to use direct Url access to display reports. Not a lot of people do this unless they're using a Reporting Services "Integration" that uses this functionality for showing reports. Personally, I ran into this situation when trying to tie our Reporting Services forms into Great Plains. Since Great Plains integrations (both native and third party) expect to use ReportServer for the report display, I was shocked and dismayed to find myself staring at this error:

The type Microsoft.ReportingServices.UI.WebControlConnection, ReportingServicesWebUserInterface, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91 does not implement IReportServerConnection or could not be found

Hitting Google for this error is more than a little bit frustrating because the vast majority of issues where it shows up is in mis-configuring a ReportViewer object in an ASP.Net web application. This is manifestly not the case here.

This was a dome-scratcher for a lot longer than I like to admit. All of the advice pieces that I could find for this error are simply inapplicable. Fortunately, I ran across a Usenet post by Dave Green from last July. Dave reported that he could fix ReportServer if he removed a couple of settings from the <appSettings> section of the ReportManager. This is most odd because the two simply shouldn't be linked--at least, in that direction. If they were linked, I'd expect that link to go the other way (i.e. something in ReportServer breaking ReportManager). After all, ReportManager is essentially a UI on top of ReportServer.

I tested his findings and sure enough, removing the appSettings fixed ReportServer for me. Since removing those settings broke ReportManager, this was an unappetizing solution.

It was then that I remembered that IIS does an interesting little trick with web.config files and subdirectories. You see, each subdirectory on a website inherits the configuration from parent directories (also machine.config, but that's not relevant to our story). It doesn't matter how those directories are physically arranged, what is important is that IIS uses the Url to determine inheritance. So in a situation where "http://reports" is pointing at ReportManager and "http://reports/ReportServer" is pointing to ReportServer, that means that ReportServer is inheriting the web.config settings from ReportManager. Thus, the appSettings for ReportManager are being read by ReportServer and misapplied (I've no idea why the presence of an appSettings entry would break ReportServer)

Fortunately, the fix for this issue is pretty simple. The <appSettings> element includes a spec for a clear directive that will wipe out all inherited values. Adding an appropriate entry to the web.config in ReportServer cleared the problem right up. Here's the section for the curious (and/or lazy):

<appSettings>
    <clear />
</appSettings>

So there you go. I hoisted myself by my own petard. Fortunately, I was able to figure out how to get myself unhoisted. I now have both ReportManager and ReportServer humming along nicely without having to undo my clever directory mapping. Since I haven't been able to find this solution anywhere, I figured I'd post this for those in similar situations.