From EIF to log4net

You've seen my posts from time to time about Microsoft's Enterprise Instrumentation Framework (EIF). We were using it at one of my clients for quite some time to log all of our errors to various places. But recently we started experiencing massive slowdowns that I was unable to rectify, but that seemed to be attributable to EIF initialization. Some of our unit tests went from taking 5 seconds to taking 50 seconds.

I probably would have worked longer to fix it, but at the same time we were facing some serious configuration issues with EIF as well. Specifically, we were trying to instrument our code to record a pair of start/stop log messages for each method, which we could turn on or off at runtime based on our need for diagnostic information. While EIF certainly supports this, its configuration mechanism requires that we then list the name of every method in the EIF config file. While possible, that was impractical.

So I decided to see what it would take to switch to log4net. As it turned out, it only took one day. I'd isolated most of the logging code already, so I just had to change things in one place. And at the end of it, I was much happier. Not only does log4net appear to do pretty much the same things as EIF, it appears to be faster (although the jury is still out), it appears to be easier to extend, and it is definitely easier to configure. The last point is an important one for us - log4net has a hierarchical configuration scheme, meaning we can set defaults at the root and have them propagate to all our logging statements, rather than having to set them explicitly, as we do with EIF.

I'm not saying EIF is bad, mind you. It could be that I was doing things wrong. I know that Microsoft is overhauling it, so maybe their next version will be better. log4net does have a head start, being a port of log4j, which has been around for a long time. But for now, log4net meets our needs better...your mileage may vary.

There's a decent article on theserverside.net that goes more in depth, but here are what I found to be the major differences:

• Ease of use. log4net felt easier to get started with. That might have been because I had already used EIF. The two are fairly similar.


• Typed vs. untyped. log4net is “untyped“ in the sense that you log strings. In EIF, you log typed objects. This turns out largely to be a philosophical distinction except for:


• Extensibility. Because log4net allows you to attach arbitrary name-value pairs to a logging thread (they call this MDCs), it's actually easier to extend. In EIF, the reliance on strongly-typed object hierarchies means I have to extend their schema. That turns out to be difficult for a variety of reasons.


• Manageability. Like I said, the fact that log4net lets you inherit log settings down a hierarchy of loggers makes it easier to manage a large application. EIF, by contrast is “flat“, and forces you to manage every log source independently.

Other than that, I found the two pieces of software to be very, very similar. Which means I'd generally choose log4net in the future.

FlexWiki Available on SourceForge

Finally, finally, finally, FlexWiki has completed its long transition from its old home at GotDotNet to its new home at SourceForge. David Ornstein - the father of FlexWiki - has a post talking about it from his perspective. Here's mine.

Way back in February or March, I became disillusioned with the state of affairs at GotDotNet. I'd been working a lot on my tools FlexWikiPad and FwSync, and wrestling with the GDN tooling was becoming so annoying that it was starting to make me dread working on my stuff. So, I took matters into my own hands and moved my code to SourceForge, which I'd found much easier to work with. Not perfect, but better.

At the same time, I was still contributing to FlexWiki itself. Since that code was still on GDN, I started to agitate for a move to SourceForge. Why? Because I wanted it to be easier for me. :) But I also truly believed that it was a better place for FlexWiki to grow, and that the other developers would find the experience better, too. Of course, that was selfishly motivated as well, because more people working on it means more cool features.

David Ornstein was thinking along the same lines at the time, so we started to work together. Because I was complaining the loudest, I felt an obligation to help, particularly because I'd set up or help set up a few other projects on SourceForge before.

Thus began the long, long process of moving to SourceForge. For me, it was pretty easy, because my tasks were mostly technical: I'm the buildmaster for FlexWiki now, so I wrote a build script and set up a CruiseControl.NET Continous Integration server at http://builds.flexwiki.com. David's part was much harder; in addition to the technical tasks that he took on, he had to convince Microsoft (his employer) to allow this to happen. Since FlexWiki is only Microsoft's third open source project (after WiX and WTL), it was a very big deal, involving much coordination on David's part.

And it took months. This was highly frustrating for many people, but particularly so for would-be FlexWiki contributors. Several of them emailed me periodically saying, “When will the move be done?“ To which I could only respond: “Soon.“ Before long, it became obvious to me that I should switch that to the more truthful, “We don't know, but we're still working on it.“

But last night, at long last, all the legal documents had been signed, all the crucial technical details had been taken care of, the CNET article posted, and the word came down: the FlexWiki project site is now live. We've even got a release posted that has a few new features, like better support for Firefox. Plus, with continuous integration set up and (hopefully) working, I think we can more easily and frequently release contributions to the public.

Moving forward, we're definitely hoping that we can once again rally the FlexWiki development community, which has languished while David and I (mostly David) were working to get things transitioned. We'd particularly like to focus on bugfixes for a while - a fair number of defects have been logged but not addressed. There's still a fair amount of administrative work to do, too, like moving the bugs from the wiki where they live now to the SourceForge tracker where we'd like them to be. But we are finally blocked only by technical issues, which are the ones we know how to solve.

One of the questions I expect people will ask is, “How do I get involved?“ To start with, join either the users or developers mailing list, according to your inclinations. If you're of a developing mind, grab the source code and start poking around. Just be aware that we're going to be fairly careful with handing out write access - David talks about that more in his post.

Oh, and one exciting thing I almost forgot to mention: Ward Cunningham is a member of the FlexWiki project. Ward quite literally invented wikis, so we're really happy to have him involved.

This is the second major software release for me in as many weeks (the other being the MSDN Alpha), so it's a very exciting time for me. Unlike MSDN, though, I'm still very much a part of the FlexWiki effort. I'm sure we'll have a lot to do as people start to stretch the new system and we figure out how to run things, but I'm looking forward to it!

Looks Like It Works

It seems that the MSDN Product Feedback Site works: the System.Decimal bug that I complained about will be fixed in Whidbey Beta 2. Nice to see the loop closed.

MSDN Alpha Available

For the past two years, I've been working on a complete overhaul of the MSDN publishing system. Tim Ewald was one of the principal forces behind this effort, but there were plenty of other really smart people involved, too: I am not at all kidding to say that merely keeping up with them was difficult.

Well, quietly, last week, the first publicly accessible incarnation of what we've been doing went up at http://msdn2.microsoft.com/library/. We weren't supposed to spill the beans yet, but Jenfeng Zhang broke the news, and we've gotten the go-ahead to blog about it.

This is a complete rewrite of the MSDN publishing engine, from the ground up; we started with zero code. Of course, you'll notice that the look-and-feel of the docs remains largely the same: most of the changes lurk beneath the surface. For example, the entire publishing process is now deeply XML-oriented. Content comes in as XML, gets processed as XML, gets stored as XML, and even gets rendered as XHTML. This is going to allow MSDN to introduce a lot more services around their extremely rich set of documents...just wait and see.

Of course, some of the changes are visible, too. You've probably noticed that the URLs are vastly improved. For example, you can now surf to http://msdn2.microsoft.com/library/System.IO.Compression.GZipStream to get documentation about the new GZipStream class. We call this an alias. The “real” URL for this document is http://msdn2.microsoft.com/library/zs4f0x23.aspx, where “zs4f0x23” is what we call the short ID for the doc. We did a lot of work to make sure that this identifier is stable, so that URLs won't break.

Even though I've now finished my involvement with the project, I'm pretty excited about this release. It is the most significant (largest scale) piece of software I've ever shipped, and a lot of my code is running in it. Not that I was the primary developer, but there will be MSDN devs maintaining my code for quite some time to come. I learned a ton, not only from Tim, but from a woman named Kim Wolk without whom this software literally never would have shipped. She hates it when I mention her name, but I think she deserves more credit on this release than any other single person on the team, and it would be a crime if no one came out and pointed her out as the hero of this project.

So go give it a test drive and let MSDN know what you think. It's only an alpha, so don't be too surprised if something breaks or doesn't work the way you'd expect, but take my word for it: this is a huge step forward for MSDN, and by extension, for the developers that rely on it.

FoamHenge

My wife and I had ourselves a little getaway this weekend, as she will be starting school again soon, followed shortly thereafter by the birth of our son/daughter/other. In other words, it was basically our last chance to do this (easily).

As we were driving around rural Virginia, we saw this:

I thought, "No, it couldn't be." But it was, indeed, a full-scale replica of Stonehenge, only made out of foam. Hilarious.

Viewing EIF Trace Service Logs

I've talked here before about problems I've had with EIF, the Microsoft Enterprise Instrumentation Framework. At the time, I thought that the bug I was seeing manifested itself as “I'm unable to open a remote logfile written by the EIF trace service.” Well, recently I had a chance to come back to this problem at my client, and after close to a week working on the problem, I finally found out that it has nothing to do with the remoteness of the files at all. Instead, it seems that because Windows 2003 and Windows XP use a different format to write the file, what's written on one system cannot be read on another. Since our webfarm runs 2003, and our desktops run XP, we were hitting the bug.

The real bummer is that there doesn't seem to be a way around this that doesn't involve rewriting the EIF trace service. It's really a problem with the fact that (according to Maros) the EIF trace service uses the Win32 OpenTrace/ProcessTrace APIs, and these are implemented differently on the two systems. D'oh!

The sort of good news is that other sinks still work fine. So you can write events to the Windows Event Log or to WMI right out of the box no problem...just not to the high-speed trace service that they provide. And they don't give you the source to the service, either, so I can't even fix the problem myself. Sigh.

Complexity is in the Eye of the Beholder

I've got a few things in the pipeline, which is why it's been quiet around here. More on that later. In the meantime...

Ian has an interesting post here about complexity in APIs. Since he doesn't have a comment facility, I can feel justified in using it as an excuse to post here instead. :)

The part I found interesting was his analogy with cars, wherein he compares automatic and manual transmissions.

So the big problem is that in attempting to provide a simple abstraction, automatic transmission reduces the drivability of a car. I've found that the only way to get the best out of a car with automatic transmission is to learn what its behaviours are so you can anticipate the bad choices that it will make, and adapt your driving style to make it do the right thing. The irony is that this means you not only need to understand the underlying reality of the characteristics of the engine and gear ratios, you also need to understand how the abstraction placed on top of this works in order to be able to work around it.

Seen in this light, the manual transmission looks a whole lot simpler by comparison. It might have more levels, pedals and selectable options, but at least you know exactly what each control will do. There is no need to try and outsmart the abstraction simply to get it to do what you want.

The part that's interesting, of course, is that this is all completely subjective, and based on a rather large number of assumptions. Note, for example, “at least you know exactly what each control will do”. Living on Earth as I do, I've seen plenty of counterexamples to this on the roads every day. I'm sure we all know drivers who still can't operate a clutch properly, for all they've been driving one for years. And frankly, I think I'd rather the cell-phone-jabbering-morons of the world have that extra hand free. But for drivers like Ian, more precise control (probably) means more safety.

All of this is a way to say that the same interface can simultaneously be simpler and more complex, correct and incorrect, appropriate and inappropriate. It depends on the user. Which is why car companies give us a choice of manual or automatic, and why some software programs offer “expert” modes or other customizations.

It's not that I don't think Ian gets this - I'm sure he does - but after reading his piece I was left with the impression that manual transmission is superior, when in fact that just begs the definition of “superior”, which is inherently subjective.