In September 2001, Alex Zanardi was involved in a horrific accident in a CART race at the EuroSpeedway Lausitz in Germany. He spun on the pit road re-entering the track with 13 laps remaining, and was hit by another car moving at nearly 200mph. He lost both of his legs in that accident.

Today, CART returned to Lausitz, and before the race, Alex was allowed to run 13 laps in a specially prepared car with hand controls. Not one to take it easy, Alex was flat on the throttle by the 4th lap, and ran a lap over 194mph. It’s hard to know if the car was in qualifying trim, but if so, that lap would have put Zanardi on row 3 of the grid for today’s race.

Alex, congratulations on what must have been an amazing day for you. You’re an inspiration to drivers everywhere.

This is going to sound like a strange question, but here goes. Did NewsGator get some press today, somewhere, without a direct link? Like in print, maybe? Today was a huge traffic day on http://www.newsgator.com, but referrers aren’t telling the whole story.

There were a very large number of google hits for the phrase “NewsGator” – we get a fair amount every day, but nothing like today…

So did anyone see anything I might have missed?

More on the interface extension that Luke, Simon, Matt, and I have been talking about.

Let’s first think of this from purely a weblog-posting extension point of view, then we’ll come back to the other options.

HasEditingGUI was designed for those aggregators that do have a built-in editor; the idea is, a user could edit their new post within the aggregator, and pass the finished ready-to-post text off to the extension. Thinking about it more, however, makes me wonder if maybe the interface semantics are wrong here. What we need is a way to distinguish between an item that has been edited and is completely ready for posting, and an item which requires further editing. Most IBlogThis implementations I’ve seen handle the latter category, but this is insufficient for our needs.

What I’m thinking is keep the HasEditingGUI function, so aggregators that do have editors can make (or expose) choices about which editor to use, but add a parameter to the BlogItem function indicating whether the item has been edited and is ready to post.

 void BlogItem(IXPathNavigable rssFragment, bool edited);

Where edited would be true if the user has edited the item in the aggregator, and false if not. Aggregators without editing GUI’s would always pass false. The plug-in can then make choices about the GUI it displays, if any.

Luke mentions that maybe we need a HasConfiguration property to indicate whether or not the plug-in has any interesting configuration information – I agree.

For the case where a plug-in has not yet been configured, but BlogItem is called, I agree with Matt – the plug-in should gracefully handle this case, perhaps popping up a dialog for the user to complete the configuration.

On the integrated configuration question, I’d vote for keeping it simple for now – let’s just have a single function for the plug-in to pop up its configuration information; if in the future, it seems we need it, we can extend the interface (or add a new one) to allow integrated configuration in a tabbed dialog or whatever.

And about inheriting from IBlogThis, Luke brings up another good point about being incompatible with IBlogThis extensions. I think we could work around it for the particular problem he mentions; however, we won’t be able to fix the need for another parameter to BlogItem. So, the new proposed interface below no longer extends IBlogThis.

public interface IBlogExtension
{
 // Name of plug-in, suitable for display to a user
 string DisplayName { get; }

 // return true if plug-in has configuration settings
 bool HasConfiguration { get; }

 // Display configuration dialog to user, if applicable
 void Configure(IWin32Window parent);

 // Return true if an editing GUI will be shown to the
 // user when BlogItem is called. In this case, the
 // aggregator will not display its own editing UI.
 bool HasEditingGUI();

 // Post item to weblog. If plug-in is going to show a
 // GUI for editing, it should return true to HasEditingGUI().
 void BlogItem(IXPathNavigable rssFragment, bool edited);
}

Keep the comments coming!

Some good feedback. Simon suggests deriving from the existing IBlogThis – sounds fine to me, especially since there seem to be a fair amount of IBlogThis implementations out there already.

Matt confirms the need for this extra functionality…glad to know I’m not the only one who thinks we need this. :-)

Douglas asks why we don’t just use attributes for the extra information. A good thought; however, I think there is then an additional, implicit contract. I might get the name of a type that implements the configuration GUI, but what do I do with it then? There are implicit assumptions if we go this way; I’d much rather have an interface method, and let the implementor decide how it should work.

I also forgot a couple of things. First, we need to pass a parent to the Configure function, so the implementation can use it to parent any dialogs if necessary. And we need a way to get the display name of the plug-in, to be shown to the user in a list of plug-ins (which could be an attribute, but I’ve left it as a property for the moment). So my new proposed version:

public interface IBlogThisEx : IBlogThis
{
 // Name of plug-in, suitable for display to a user
 string DisplayName;
 
 // Display configuration dialog to user, if applicable
 void Configure(IWin32Window parent);
 // Return true if an editing GUI will be shown to the
 // user when BlogItem is called. In this case, the
 // aggregator will not display its own editing UI.
 bool HasEditingGUI();
}

Keep the comments coming!

Simon Fell has defined an IBlogThis interface, which an aggregator plug-in can implement. In this model, the aggregator passes an existing post to the plug-in. The plug-in will then display a GUI for the user to enter the post, and the plug-in will then post to the weblog.

This is a good start; however, I’ve recently been looking into adding posting capability to NewsGator, and we need more intelligence in the plug-in to deliver a rich and consistent user experience. Since you can edit HTML from within Outlook, we’d like to leverage that capability in some cases; and in other cases, we’d like the plug-in to handle the UI. I’d like to leave it up to the plug-in to decide; this way, we can support rich posting plug-ins like w.bloggar, as well as quick-and-dirty plug-ins whose only job in life is to take some data and post it to a weblog, never prompting the user.

We need an interface for NewsGator to use to communicate with the plug-ins. The intent would be that other aggregators can support this as well – it should be very easy for them to implement. It should also be easy to implement for the plug-in authors. With that said, here’s a first cut:

public interface IBlogIt
{
 // Display configuration dialog to user, if applicable
 void Configure();
 // Return true if an editing GUI will be shown to the
 // user when BlogItem is called. In this case, the
 // aggregator will not display its own editing UI.
 bool HasEditingGUI();
 // Post item to weblog. If plug-in is going to show a
 // GUI for editing, it should return true to HasEditingGUI().
 void BlogItem(IXPathNavigable rssFragment);
}

Configure – this is necessary to allow the plug-in to prompt the user for configuration information, such as URL, port, etc. to post to.

HasEditingGUI – if the plug-in returns false to this, the aggregator will be expected to pass in a complete, ready-to-post article. If the plug-in returns true, the aggregator will pass in whatever it likes, and the user will edit the post from within the plug-in.

BlogItem – Passes a post into the plug-in for optional editing, and posting.

This should allow us to use rich posting tools with GUI’s, as well as non-GUI post-only tools. I’d like this plug-in interface to cover all of the immediate needs we can think of for communicating with posting tools. Comments?

Dare points to a Slate story about front and rear wheel drive, titled “Why Front-Wheel Drive Sucks.” There are a couple of points in the story about oversteer and understeer that I want to address, as they’re a bit misleading, in my opinion.

First, he makes sweeping generalizations about front or rear drive cars and their handling balance. There are other variables which are in some cases even more important – like where your engine is. Mid- and rear-engine cars will tend to oversteer more than front-engine cars; it’s all about inertia and weight transfer.

He talks about how to recover from a understeer vs. oversteer skid, and mentions that you have to turn the wheel the opposite direction in each case. Well, as a race driver, this is way too hard to remember – when you’re at the limit in a car, and you start to skid one way or the other, you don’t think to yourself “hmm, ok, oversteer, turn the wheel in the opposite direction, right?”.  There isn’t time – it’s instinct. Here’s the secret – if you’re in a skid, whether understeer or oversteer, look where you want to go. Let me say that one more time, because it’s so important – look in the direction you want to go. Your hands will naturally turn that way too, and you’ll be doing the right thing.

If you look at the wall, you’ll hit the wall. Seriously.

So now that we’re steering the right way, we have to figure out what to do with the gas as well, and this is where there’s a valid point to be made in the article, but he doesn’t get it quite right. If you’re understeering (driving off the edge of the track/road), you need to lift off of the throttle a bit. This will shift more weight to the front wheels, which increases their grip, which will bring the nose back in. Don’t get crazy with the lift – too much and your understeer will become oversteer before you know it. So far so good – lifting is intuitive for most people in a skid.

If you’re oversteering (rear end is sliding around), it gets more interesting. Let’s consider a non-power oversteer, which means you didn’t induce the oversteer purposely by mashing on the throttle. The rear end is of course sliding because it doesn’t have enough grip. If you lift in this situation, weight transfers to the front of the car, from the rear. The rear tires now have less weight on them, which means they have LESS grip, which makes the problem worse. You actually need to give a little bit MORE throttle in this case – transfer more weight to the rear wheels, they then have more grip, hopefully enough to drive out of the skid. And you’re looking where you want to go, and you’re turning that way too.

The article says of rear-drive cars:

“But you can still feel the front end starting to plow wide a bit. What to do? Step on the gas!”

Well, this might happen when you’re driving to the grocery store, but if you’re anywhere near the limit, behaving like this is guaranteed to drive you right off the track. Don’t do it!

Any comments? I love driving, and talking about cars – it’s much more fun than working. :-)

Ok…as mentioned in the comments for my Event Log Monitoring with RSS post, I have been thinking a bit about generating a RSS feed for NNTP newsgroups. This would be a one-way feed, but I think many people might find use for something like this.

If you’d like to try the (very-beta) NNTP RSS feed, let me know. Because of the resources used by this feed, I’m not opening it up to the public completely at this time; but if you email me, I will send a URL and credentials so you can try it. This will probably be limited to the first 10 or so people. I’m not sure how long I will keep this running; however, I will most likely post the source at the end of this exercise.

Note that this beta feed is limited to groups on news.microsoft.com.

On a related note, we are considering adding the ability to read NNTP newsgroups into NewsGator in a read-only manner. Subscribing to this test RSS feed will give you an idea what that might be like from the user’s perspective, so you can decide if you’d think it would be a valuable feature.

If you participate, you’ll be expected to provide feedback on whether you think this would be a useful feature to have built into NewsGator…and even if you don’t participate, I’d love to hear your thoughts. Please leave comments on this post!

Here’s an interesting article I found by accident – PR Tactics – Using RSS for corporate communications by Phil Gomes.

…since not all announcements are wire-worthy — despite what your “Assistant Marketing Director, Luxembourg Region,” might try to tell you — company events of slightly less significance might be posted to the company’s RSS feed as the sole means of transmission, giving subscribers a richer view of the company.

This is exactly what we do for NewsGator – some news is wire-transmitted, but all news is in the news/updates RSS feed.

I’ve written some sample code to generate a RSS feed from the Windows Event Logs. This is very handy for monitoring servers – perhaps a poor man’s SNMP monitor. :-)

Here’s an screen shot showing it in NewsGator (click for larger version):

You can specify in the URL how many entries to return, and which logs to use. For example,

http://example.org/Rss.aspx?num=20&logs=Application,System

would return the 20 most recent entries, looking in both the Application and System event logs.

Download here – requires ASP.NET. If your server is on the internet rather than local, try it with my HTTP security samples [Basic, Digest] to securely monitor the event log of the remote server – very handy for those hosting on remote, dedicated servers.

I have not posted anything about the war on my weblog before, and I don’t intend to make it a habit. But I’m going to just this one time. I had lunch with my sister today, and she told me of a good friend of hers whose son is a marine in Iraq. This young man wrote a letter to his mom, which included two questions (paraphrased here):

I hear a lot about the protests, and how people back home are so opposed to this war and what we’re doing…why?

and

It doesn’t seem like there’s a big display of patriotism back home right now, like there was after 9/11 (people displaying flags, etc.). Why not?

Good questions – and not questions I want our troops to have to think about, while bullets are flying past their heads.

I, for one, am totally 100% behind our troops and what they’re doing. I don’t necessarily agree with everything our administration does, but once the decisions are made, they have my full support. The time for protest has passed.

And I’m going to look for a flag to put outside my house. I’m proud to be an American. And if any of our troops or their families read this, I’d like to say thank you.