You owe it to yourself to check out Beatallica, a band that mixes Metallica and the Beatles in a highly amusing way. I've mentioned them here before.
Well, now they need your help. They're being sued by the a-holes at Sony for copyright infringement of The Beatles work, despite the fact that they're doing parodies, which is legal. You can help them by signing their petition.
Hacknot has a new article titled Wikiphilia - The New Illness. Given my work on FlexWiki, you might think that I would violently disagree with his take on wikis. Well, I don't. In fact, I largely agree with him: people tend to apply wikis to way too many problems. A classic example of this is the so-called “thread mode”, where people use a wiki page to host a discussion. It sucks - mailing lists are about 10,000 times better at this particular task. The same goes for a bunch of other tasks, like formal documentation, blogs, and anything where images are important.
Really, it's the classic circle of (software) life. When you first see a cool technology, you think it's great at everything. Later, as you internalize the concepts, you realize that there are inherent tradeoffs, and that therefore the software has limitations. Or at least, hopefully you get that far. Sadly, some never do, clinging loyally but irrationally to claims of “it's a dessert topping and a floor wax!”
That said, I think that while Hacknot correctly identifies Wikiphilia as a condition that needs correcting, the overall tone of the article is disappointing. First of all, it's too dismissive, poo-pooing wikis in general, despite the fact that they are enormously useful for the things they're good at, like helping a team of people to quickly create lots of informal documentation. Informal documentation is quite often worlds better than none at all, and having an easy way to create it is a massive boon to just about every software project I've ever been on.
But I find the Hacknot article disappointing in a more general sense, too. Previously, he's applied the concepts of scientific skepticism to deflate the hype around things like XP - which is great. Enthusiasm unbacked by evidence should be questioned. But in this case he's just made a series of unscientific observations that offer no proof of his assertions. Which to me just makes him sound like a cranky old man. Here's hoping he does better in the future.
I still get comments and questions about my XmlSerializerSectionHandler, even though I wrote it two years ago (hey, two years ago this week, in fact!). People seem to love it. What's funny is that I never use it any more. I realized a long time ago that using XmlSerializer directly to slurp a file into an object is only one or two more lines of code, and has the advantage of not making me store information in the program installation directory: a no-no for many reasons. Instead, I can put it wherever it belongs.
When I started doing Test Driven Development, doing things this way presented me with the same conundrum that many face: do I test configuration by writing data to the current user's profile directory (potentially destroying whatever application settings they had stored there), or is there some other way to do it? (This is a variation of “Should I test against the database?”) Well, after having answered that question a few hundred times, I settled on this pattern. I know I'm not the first (or even the thousandth) person to settle into it, but I've found it useful, and hope someone else out there will too.
The basic idea is to make the thing that gets the configuration pluggable. Then you can have the real one that reads from the user profile directory, and a mock one that returns whatever test data you like. I usually also couple it with the idea of making the one that pulls from the real location the default, so that you can use the class in normal scenarios without having to do anything special. Something like this:
public interface IGetConfigData {
ConfigData GetConfigData();
}
public DefaultConfigGetter : IGetConfigData {
public ConfigData GetConfigData() {
// Gets "real" config data
}
}
public class MyClass {
private IGetConfigData _configGetter = new DefaultConfigGetter();
public IGetConfigData ConfigGetter {
get { return _configGetter; }
set { _configGetter = value: }
}
}
public MockConfigGetter : IGetConfigData {
private ConfigData _data;
public MockConfigGetter(ConfigData data) {
_data = data;
}
public ConfigData GetConfigData() {
return _data;
}
}
[TestFixture]
public class MyClassTests {
private MyClass _mc;
[SetUp]
public void SetUp() {
_mc = new MyClass();
_mc.ConfigGetter = new MockConfigGetter(GenerateTestConfig());
}
private ConfigData GenerateTestConfig() {
// Whip up test data and return it
}
}
Schneier reports that SHA-1 has been broken. If true, this is an enormous deal - it could have very real security implications on tons of applications.
Of course, you have to wonder if the NSA knew about this years ago.
One of the best things about working on MSDN2 was getting to work with my longtime friends Kim and Tim. Well, I see via Chris they've teamed up to release XSLTO (XSL Transform Objects, if I have the abbreviation correct). It's a deceptively simple little bit of code. Although I've talked with Tim about the idea several times over the last few months, this is my first chance to see the code. I think it's an extremely excellent idea, and I'll tell you why: because NAnt sucks.
What? What does a build tool have to do with an object-based XML transformation utility? Well, over the last few years, I've been doing a lot of build script work. And I've come to really like the stuff that NAnt has built in, like named filesets, the solution task, integration with CruiseControl.NET, etc. It has tons of useful utilities for doing most of the things you'd want to do as part of a build, and extension points for doing stuff the NAnt team didn't think of. I like it a lot.
So if I like it so much, why do I say it sucks? I guess I should have been more precise and said that while NAnt the tool is great, NAnt the language sucks. I'm constantly looking in the documentation to remember what the form of various tasks is, and it's a fair bitch to read. More, it's yet another language that my clients have to support when my contract ends and I'm out the door. Frankly, I'd much rather that NAnt-the-language looked like C#, even though it would limit some of the funky things you can do with NAnt. That's not a big deal to me because I rarely do those funky things.
Another language that has this same problem is XSLT. It's really great at the things it's great at (specifically, recursive descent processing of XML), but it also is Yet Another Language for me to remember and support, and I don't get all the nifty tool support I get in C#. I think XSLT is probably one of the reasons people are excited about things like Comega - because they get the natural mapping to XML data types but in a way that's comfortable for C# developers.
Which brings us back to XSLTO. What Tim and Kim have done is to give you the same recursive descent processing that XSLT does so nicely, but all in C#. The core of the idea is captured in the MyTransform class from their sample. I'll reproduce it here in its entirety:
public class MyTransform : Transform {
[Match("/person")]
public void Person(XPathNavigator nav) {
Console.WriteLine(nav.Name);
ApplyTemplates("*");
}
[Match("name")]
public void Name(XPathNavigator nav) {
Console.WriteLine(nav.Name);
ApplyTemplates("text()");
}
[Match("age")]
public void Age(XPathNavigator nav) {
Console.WriteLine(nav.Name);
ApplyTemplates("text()");
}
[Match("text()")]
public void Text(XPathNavigator nav) {
Console.WriteLine(nav.Value);
}
}
If you're familiar with XSLT, the structure should look really familiar: a series of chunks of code (methods in XSLTO, templates in XSLT) that are declaratively matched to pieces of the input document (via the [Match] attribute in XSLTO, via the match attribute in XSLT). In this case, they're just printing out the value of each node, but they could just as easily have used an XmlWriter to emit a transformed version of the input document, just as you'd do in an XSLT. They've even got an ApplyTemplates() function that has the same essential meaning it does in XSLT: “Please continue finding matches and calling the appropriate bits of code.“ When all is said and done, it does exactly what you most often need to do with an XML document: crawl over all the nodes and take some arbitrary action whenever you encounter a certain node.
Will this technique enable all the same things you can do with XSLT? Certainly not. But I've written a fair amount of XSLT in my time, and I'd bet that 80% of it could have been done this way no problem. That figure probably goes up to 90% if they were to make the simple addition of supporting an equivalent of the apply-templates mode attribute - a change I suspect would be nearly trivial. To quote myself from earlier in this posting:
Frankly, I'd much rather that NAnt-the-language looked like C#, even though it would limit some of the funky things you can do with NAnt. That's not a big deal to me because I rarely do those funky things.
Well, substitute “XSLT” for “NAnt” - the argument is the same.
And if that weren't enough, it's impressive that it's already useful, and it's only about 300 lines of code, including comments and sample code! I'm looking forward to seeing where they go with the tool.
It's been a really long time since I've done any DirectX writing. So as I was going through my email this weekend, trying to get caught up (sorry to those who've been waiting for answers - I'm getting there!), it was fun to sit down and answer a Direct3D question from a reader. He wanted to know how to save something he'd rendered out to a file. As it turns out, it's dead simple; as long as you set PresentationParameters.SwapEffect to either SwapEffect.Discard or SwapEffect.Copy, you can just use this line of code:
SurfaceLoader.Save(filename, ImageFileFormat.Jpg, _device.GetBackBuffer(0, 0, BackBufferType.Mono));
You have to love Managed DirectX.
I've posted the code here. It's not a full-blown tutorial - those take at least a few full days each to write - just a little sparsely-commented code. Maybe I can start to post a few more little snippets like this on the DirectX wiki to make it more useful.
FlexWiki needs a logo, so we're having a contest. Check out the contest page over on the wiki. Right now there are only a couple of submissions, so your chances of winning are pretty good. :)
What do you get if you win? Well, we haven't decided yet. But given that FlexWiki has been downloaded nearly fifteen thousand times in the last six months, I doubt winning would do much harm to your resume. Enter early, enter often!
