Rants, rambles, news and notes from another geek

WS-I Basic Security Profile Sample App Preview

It is that time of year around here…

WS-I Basic Security Profile Sample Application Preview

One of the most requested deliverables we have heard since Enterprise Library has been released, is an end-to-end sample that shows the blocks in action. The great news is that we now have this, in the form of the WS-I Basic Security Profile Sample Application. In addition to showing the use of the Enterprise Library blocks, the sample app also demonstrates how to build secure and interoperable web services based on the WS-I group’s basic and security profiles. The current release of the sample application uses .NET 1.1 and WSE 2.0; an early preview for .NET 2.0 and WSE 3.0 is due for release this week at the WS-I Sample App Community Site.

(via Tom Hollander)

CAB Training Event in Redmond

Eugenio Pace, the Product Manager on the Composite UI Application Block (my current project), is offering a chance for you to come here and learn about CAB from us.

CAB training event in Redmond

We are pleased to announce a 2 day, instructor-led training event for the upcoming Composite UI Application Block (CAB) in Redmond, WA, USA.

**When?
**Monday, July 25th (Introduction & key subsystems) - Tuesday, July 26th. (drill down and roadmap)

**Where?
**Microsoft Corporation, Redmond, WA USA - Building 20

**Who should attend?
**Anyone interested in jumpstarting their adoption of the CAB as their underlying architecture for rich UIs.

**What will you cover?
**We will cover all subsystems in CAB, we will provide extensive exercises to understand how to leverage CAB in your applications, and we will have architecture discussions for the most common scenarios. You’ll also have the chance to interact directly with the team that created the block as the training will be given by our own team members.

For more information and to request a seat, please visit Eugenio’s original blog post.

The .NET Guy Is Now on AgileProgrammer.com!

A few minutes ago I helped Brad Wilson (aka The .NET Guy and fellow patterns & practices developer) move his blog over from his old UNIX MT blog site and onto agileprogrammer.com with me and Brian Button.

Brad wrote a very cool Ruby script do the import that I’m hoping he’ll post to his blog. 200-ish lines of code to do the whole job from MT/RSS into MetaWeblogAPI and my .TEXT derived blog engine. Ruby is such a great language for this kind of thing.

Please welcome Brad to AgileProgrammer.com. You can read his new blog at http://www.agileprogrammer.com/dotnetguy

Excellent Article About Running LUA in eWeek

As you know, I’m a big proponent of running LUA on your machine. Sure, there are challenges, but those are mostly caused by developers who run as admin and assume that you will too. (You’ve stopped developing as an admin, right?)

Apparently, the press is starting to listen to all the great people who have been blogging and writing about this. I just saw this article on eWeek go by on one of our internal mailing lists. (In addition to the DropMyRights tool mentioned in the article, I would recommend looking at MakeMeAdmin if, like me, you’d rather go the other way.)

The article also talks about some new stuff in Longhorn and IE7 that will start to improve the LUA experience in the future. Check it out!

And of course, keep an eye on the nonadmin wiki at http://nonadmin.editme.com/.

Scott Hanselman's 2005 Ultimate Developer and Power User Tool List

I don’t know how Scott finds the time to keep up with all this stuff. I will admit that I either use or have used 75% of the stuff on this list, though, so it is nice to have this page when I need to find something quickly.

http://www.hanselman.com/tools/

Too bad the URL isn’t easier to remember. Scott.. you listening?

UPDATE 2005-07-15: Scott was listening and I have updated the long line-wrapping link that used to be on this page with the nice one that is now there.

Second Community Drop of CompositeUI Application Block

I know I haven’t been posting much latelyΓǪ sorry. Been busy busy busyΓǪ

One of the things I’ve been working on is the CompositeUI Application Block (CAB). CAB is basically a framework for building complicated Windows Forms applications from other simpler parts. I’ll be blogging a lot more about it in the coming weeks and months, but for now I wanted to let you all know that we have just posted our second community drop on our GDN Workspace.

So, if you are interested in seeing the kinds of things we are doing in this block, or how we are using Whidbey features, please join the workspace and download it.

Thanks!

Now playing: Kyuss - Caterpillar March

Unit Testing Events With Anonymous Delegates in .NET 2.0

There has been a lot of discussion comparing anonymous delegates to closures and blocks in Ruby, so I’m not going to get into that whole thing…

What I want to talk about for a minute is how cool it is to use anonymous delegates to test that events on your classes fire as expected.

Suppose, for example, that you have a class like this:

1
2
3
4
5
6
7
8
9
10
11
public class MyContainerContainer
{
	public event EventHandler<ItemAddedEventArgs> ItemAdded;
	public void Add( object item )
	{
		// Store it in an internal list or something, then
		// fire the event
		if( ItemAdded != null )
			ItemAdded( this, new ItemAddedEventArgs(item) );
	}
}

Now before anonymous delegates, you would have had to introduce a private method in your test fixture to attach to the ItemAdded event. And as shown here, you probably would have had to introduce a private field to pass data between the event handler method and the test method. (Sure, you could have created a mock class to hold the state and the event handler, but that would have been even more code to read/parse/grok.)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
[TestFixture]
public class ContainerMonitorFixture
{
	private object addedItem = null;
	[Test]
	public void AddFiresAddedEventWithCorrectArgs()
	{
		MyContainer container = new MyContainer();
		container.ItemAdded +=
			new EventHandler<ItemAddedEventArgs>(this.ItemAdded);
		object item = new object();
		container.Add( item );
		Assert.AreSame( item, this.addedItem );
	}
	private void ItemAdded( object sender, ItemAddedEventArgs e )
	{
		addedItem = e.AddedItem;
	}
}

With anonymous delegates, you can now write very clear, very clean tests like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[TestFixture]
public class ContainerMonitorFixture
{
	[Test]
	public void AddFiresAddedEventWithCorrectArgs()
	{
		object expected = new object();
		object actual = null;
		MyContainer container = new MyContainer();
		container.ItemAdded += delegate( object sender, ItemAddedEvent args e )
		{
			actual = e.AddedItem;
		}
		container.Add( expected );
		Assert.AreSame( expected, actual );
	}
}

There are a couple of cool things in this code:

  • The delegate can modify variables in the test method, outside the event handler itself
  • The entire test’s meaning is clearly stated within the test–you don’t have to look in some other method or class to see what’s happening
  • Because the entire test is self encapsulated, it is easier to move/copy/change should you need to do any refactoring to either the class under test or the test fixture itself.

Enjoy!