No Fluff Just Stuff

WPF Composite Application Guidance is Live

Brad Abrams — Sat, 05 Jul 2008 16:00:02 CDT

A very common pattern for business focused applications is the "Composite Application Pattern". Over the last few months our P&P team has been working with industry leaders and the product teams in Microsoft to develop an sample application and a framework for building composite applications in WPF.

If you are looking at building a WPF business focused application, you should really check this out.. all the documentation, source code and even unit tests are included!

Check it out! Composite Application Guidance for WPF

Coolidge Park by night [Flickr]

Aaron Gustafson — Sat, 05 Jul 2008 13:00:02 CDT

Aaron Gustafson posted a photo:

Testing Cocoa Controllers with OCMock

Erik Doernenburg — Sat, 05 Jul 2008 11:00:02 CDT

For a few releases the Apple development tools have included OCUnit and many developers have now started to write unit tests. There are lots of tutorials that explain how this is done for the straight-forward cases but there’s one area of testing that has proven difficult on most platforms, and that is testing of the user interface. That said, there are a few things that make this an easier problem to solve with Cocoa and in this post I’ll explain why.

Let’s look at an example. CCMenu is a small application that displays the status of CruiseControl continuous integration servers. As part of adding a new project to be monitored the user has to enter the URL for the CruiseControl server and a combox provides a history of previously used servers.

The same dialog has a matrix of buttons to set the type of the server. Actually, by default CCMenu detects the server type automatically but that’s beside the point. What we’re interested in is the piece of functionality that is responsible for selecting the correct server type for the URL chosen by the user. In our case, this would be Cruise Control Dashboard.

One difference between Cocoa and most other UI frameworks is the fact that the user interface is stored by serialising the objects, rather than generating code. For this reason I’m happy to not insist on test-first for the actual interface. What I do want to test is the code in the controller classes.

Obviously, I could load the serialised objects, locate the elements involved and then use methods such as performClick: to trigger the actions. Sounds convoluted? Yes, I agree. Luckily there’s a better way.

This is a case where testing is tricky because the object under test interacts with objects that are difficult to deal with. In such cases dynamic mock objects have proven extremely useful. A good introduction can be found here and mockobject.com lists papers and implementations. For Objective-C I created OCMock. Let’s look at how this helps us testing our controllers.

Here are the relevant parts of the interface declaration of the controller. Given that I’m doing test-driven development there’s currently no implementation of the methods. I simply created the interface of the controller based on my needs while designing the dialog.

@interface CCMPreferencesController : CCMWindowController
{
    IBOutlet NSComboBox *serverUrlComboBox;
    IBOutlet NSMatrix *serverTypeMatrix;
}

- (IBAction)historyURLSelected:(id)sender;

In my test I want to use mock objects instead of loading the actual user interface. So, in the test setup, after creating my controller, I create appropriate mock objects and set up the controller to use these.

@implementation CCMPreferencesControllerTest

- (void)setUp
{
    controller = [[[CCMPreferencesController alloc] init] autorelease];
    serverUrlComboBoxMock = [OCMockObject mockForClass:[NSComboBox class]];
    [controller setValue:serverUrlComboBoxMock forKey:@"serverUrlComboBox"];
    serverTypeMatrixMock = [OCMockObject mockForClass:[NSMatrix class]];
    [controller setValue:serverTypeMatrixMock forKey:@"serverTypeMatrix"];
}

You notice that I’m using key-value coding to set the variables (outlets). I’m doing this because the variables are not public and at the same time I don’t want to write accessor methods for them.

Now, we can start writing the actual test for the functionality. Have a look at the full test first.

- (void)testSelectsServerTypeWhenHistoryURLIsSelected
{
    NSString *selectedUrl = @"http://localhost/cctray.xml";
    [[[serverUrlComboBoxMock stub] andReturn:selectedUrl] stringValue];
    [[serverTypeMatrixMock expect] selectCellWithTag:CCMCruiseControlDashboard];
    [controller historyURLSelected:nil];
}

What’s going on here? Firstly, I tell the mock object that stands in for the actual combox box that it should stub the stringValue method. This means that when somebody invokes stringValue on this object it will return the string @”http://localhost/cctray.xml”. This is all we’d have done with the real combo box anyway.

Secondly, I tell the mock that stands in for the server type matrix that it should expect that the method selectCellWithTag: is called with CCMCruiseControlDashboard as an argument.

Lastly, I invoke the method I want to test. What happens, once the implementation is complete, is that the code will go the the combo box and ask it for its string value. The first mock will return the stubbed value. Now, the code should do whatever it needs to do to figure out which server type this corresponds to and then set that in the server type matrix by selecting the cell with the appropriate tag, and this is what we’ve told the second mock to expect.

Wait, you might say, we don’t have an implementation yet. So, how does this test fail? It doesn’t yet. We’ll have to tell the mock objects to verify that everything we told them to expect actually occurred, and a logical place for this is the test tearDown.

- (void)tearDown
{
    [serverUrlComboBoxMock verify];
    [serverTypeMatrixMock verify];
}

Strictly speaking, we don’t have to verify the combo box mock because it doesn’t have any expectations but it’s good practice to verify all mocks in the tear down, especially if the same mocks are used for multiple tests. By the way, by default the mocks also have fail-fast behaviour; when they receive a method that wasn’t stubbed or expected, they raise an exception right away. Detecting something that wasn’t expected can be done right way, detecting that something that was expected didn’t occur must be trigger by the user.

Now, if we run this test with an empty implementation of historyURLSelected: it will fail when we tell the server type matrix mock to verify because the expected method hasn’t been called. The error message will look something like this:

Unknown.m:0: error: -[CCMPreferencesControllerTest testSelectsServerTypeWhenHistoryURLIsSelected] : OCMockObject[NSMatrix]: expected method was not invoked: selectCellWithTag:0

Adding an implementation like the following one adds the right functionality and makes our test pass.

@implementation CCMPreferencesController

- (void)historyURLSelected:(id)sender
{
    NSString *serverUrl = [serverUrlComboBox stringValue];
    [serverTypeMatrix selectCellWithTag:[serverUrl cruiseControlServerType]];
}

In summary, testing controllers becomes relatively easy when we follow this pattern:

1. Replace all UI elements with mocks; using key-value coding to access the outlets.

2. Set up stubs with return values for UI elements that the controller will query.

3. Set up expectations for UI elements that the controller should manipulate.

4. Invoke the method in the controller.

5. Verify the expectations.

I find tests following this pattern easier to write and understand than tests that load a NIB file and interact with the actual user interface elements.

Catching up on performance with the SitePen crew

Ryan Breen — Sat, 05 Jul 2008 08:00:06 CDT

There’s been so much going on in the performance space lately that I’ve been snowed under. It’s difficult to know where to begin chronicling all of the progress. I’ll start with a few updates from Sitepen.

Back in April, Kris Zyp had a great article for IBM developerWorks called Ajax performance analysis. The developerWorks crew puts out some great material, and this is no exception. Simply put, it’s one of the best articles I’ve seen on the topic, and it should be required reading for every Ajax developer. He discusses Firebug, YSlow, and some client-side instrumentation techniques.
Old friend of the Perf, Tom Trenka, had a nice post about string operations across browsers in May. One of the more interesting takeaways is with regards to IE7 versus IE6. The net — there’s no longer any justification, if there ever was, for special casing string concat operations for IE.
One of my favorite tools, Firebug Lite, has seen some “>dramatic improvements in the Dojo Toolkit version, as discussed by Mike Wilcox in early June. The features discussed: a popup mode that remembers size and position, ReCSS (so you can reload stylesheets without reloading the app), a DOM Inspector, an Object inspector, and a command line. They’ve definitely taken Firebug Lite a long way past the initial goal of offering a bare subset of Firebug functionality to IE developers.
A few days ago, Mike posted another article — this time with a nice addition to the recent swell of client-side profiling articles. Mike whipped up a nice generic mechanism for tracker client side performance in a cookie to remove some of the tedium from generating a statistically relevant data set in your own browser.
Finally, Alex Russell expands on the concept of lazy loading by creating a stub loader for Dojo. Weighing in at a slim 6kB (gzipped over the wire), this build of dojo.js is just the bootstrap code necessary for loading the main functionality, all of which is deferred until it’s actually called within an application. John Resig posted a follow-up regarding some of the clear downsides of this approach, such as the potential violation of user expectations.

ASP.NET Ajax Roadmap Published

Brad Abrams — Fri, 04 Jul 2008 16:00:02 CDT

Bertrand recently published our roadmap for ASP.NET Ajax.

Our goal is to describe some of the proposed features that we are considering investing in future releases of ASP.NET AJAX, Visual Web Developer, and the ASP.NET AJAX Control Toolkit.
We really appreciate your feedback, so this document is intended as much for you to provide an input to our direction as well as to give some indication of what the teams are investing in.

We'd love to hear your thoughts!

My Clutter is Different

Johanna Rothman — Fri, 04 Jul 2008 13:00:02 CDT

On the long weekends, Mark and I make a concerted effort to clean up the house. That means I have to address all my little piles: go through them, recycle what I can, throw out what can’t be recycled, file others, figure out what to do with the rest. While Mark was helping me bring some of my paper and books downstairs, he nudged me about finishing the living room. “I know you don’t like clutter,” he said. “Yes, but I know where everything is. Besides, you have clutter, too.” “But I don’t like your clutter,” he responded. I started to say, “Yeah, but my clutter is different” at which point we both cracked up.

My clutter is comfortable for me, otherwise I would have dealt with it already.�� You could call my clutter technical debt, and you’d be right. I don’t mind paying it off on long weekends. Otherwise, I would do something about it more often. But the reason my clutter is different is because it fits with my mental model of the world.�� I’m sure when Mark reads this, he’ll try to change my mental models. He’s unlikely to be successful.

These same kinds of discussions occur at work, but we tend to laugh at them less. (Maybe we should.) The next time you find yourself perturbed by someone else’s perspective, consider this question: What would have to be true for the other person to be happy (or content or satisfied) with the situation?�� Partly, my clutter helps me see all the things I do, which is helpful. More clutter does not make it more helpful — there’s a point at which even I think there’s too much clutter. But seeing clutter doesn’t help Mark, and since we share a house, I need to flex a bit. I’ll continue cleaning up now.

On the radio

Richard Monson-Haefel — Fri, 04 Jul 2008 11:00:02 CDT

Just in case you were fortunate enough to miss it, I was on the RIA Weekly radio show yesterday. Actually, The RIA Weekly Show hosted by Michael Cote of RedMonk (a favorite analyst company) and Ryan Stuart of Adobe (a stand up guy) is a great show. Every week they talk about current events in the RIA industry and mix in a good amount of chuckles.

I was the guest on Episode 17. I spoke mostly about Curl and how its different from other RIA solutions. We also spoke a little bit about JSF, SOA, programing languages, and other topics. Over all I think it went pretty well, but its never fun to see yourself on video or listen to yourself on a voice recording. Apparently I do an in-take-of-air after every sentence as if I'm living on a respirator and need to get the mask back on or suffocate.

Where the hell is Matt?

Richard Monson-Haefel — Fri, 04 Jul 2008 08:00:02 CDT

"Matt is a 31-year-old deadbeat from Connecticut who used to think that all he ever wanted to do in life was make and play videogames. Matt achieved this goal pretty early and enjoyed it for a while, but eventually realized there might be other stuff he was missing out on. In February of 2003, he quit his job in Brisbane, Australia and used the money he'd saved to wander around Asia until it ran out. He made this site so he could keep his family and friends updated about where he is.A few months into his trip, a travel buddy gave Matt an idea. They were standing around taking pictures in Hanoi, and his friend said "Hey, why don't you stand over there and do that dance. I'll record it." He was referring to a particular dance Matt does. It's actually the only dance Matt does. He does it badly. Anyway, this turned out to be a very good idea."
- Patrick Drury

See Matt dancing video.

Json-lib: 2 years and counting

Andres Almiray — Thu, 03 Jul 2008 16:00:03 CDT

Yikes! been so busy at work that missed Json-lib's second anniversary by two days. Don't have exact download stats as sourceforge.net decided to give broken links for projects statistics for over a week now, last time I checked we were over the 78K mark

20 releases, 71 bug reports, 72 feature requests, 6 patches, 123 forum messages and countless direct emails we are still up and going strong. Thanks to everybody that has contributed to the project, and to the users too, we wouldn't be here if it wasn't because of you.

“Physical” Request-Scoped Attributes for JSF in Portlets

Scott O'Bryan — Thu, 03 Jul 2008 13:00:03 CDT

One of the more frustrating parts of portal development is the fact that the Portal Specification does not follow good “design by contract” principals.�� One of the more annoying aspects of this deficiency is how the behavior of request-scoped attributes is defined in the portlet specification.

In the servlet world, there is one Request object for each physical request from the the browser.�� This is called a single-phased request.�� Because of their complexity and the need to enable applications to perform better, the Portlet 1.0 specification introduced a multi-phased request in which certain types of requests are run in response to certain types of requests.�� This means that rendering logic can be light and fast in its implmentation while data-fetching logic and processing could be done only when a portlet is the target of its own request.

Although this approach has merit, the Portal Specification does not clearly outline the lifespan of a request-scoped attribute.�� Many portal vendors (quite incorrectly in my opinion) say that items added to the request during the processAction will NOT be available durring the render.�� While other vendors, including the R.I. do preserve these attributes between an action and it’s following render request.�� This means that different containers behave differently depending on their implementation, which is something that directly violates “Design by Contract” principals.

JSR-301 Portlet Bridge’s Take

The JSR-301 Specification tries to address this inconsistency for JSF applications by stating that Request Attributes which are added during a JSF Action phase of the lifecycle, should be available during the following render and all subsequent renders.�� This allows a situation where a JSF portlet which needs to be rendered as a result of another portlet’s action, can simply continue by running the render portions of the lifecycle.�� This behavior happens regardless of behavior and although there may be some challanges in dealing with this nuance, it will remain consistent across portal boundries.

For those attributes that should NOT be around for subsequent renders, like per-request state information, JSR-301 added a special configuration as well as an “@ExcludeFromManagedRequestScope” attribute which allows an attribute to remove itself from this feature.�� For example, let’s say a renderkit stores an attribute on the request which holds a flag telling the renderkit to render in XML (for an Ajax request) rather then html.�� If this bean persisted to multiple requests, you might find that your renderkit would render ajax content directly into your portlet’s window on the portal page.�� This is NOT the desired result.

Where JSR-301 falls short, however, is that it does not enforce any sort of consistency when a bean is excluded from the managed request scope, instead it defers to the logic defined by the portal container.�� As such, attributes which are excluded from the managed request scope suffer from the same implementation-specific problems that the Portlet 1.0 containers suffer from.

The good stuff

There are several ways to handle this situation.�� The first is to make sure that beans are able to be re-created on an as-needed basis, even from a portlet render request.�� This is a challange in a portlet environment because parameters which are passed into the action are not available durring the subsequent render request unless they are explicitly added.�� Furthermore, if the parameters are added, they will be added to every Render request until either a render request is called specifically or until antoher action is called on the portlet.�� In either case, this suffers the same pitfalls as the bridge’s managed request scope, so if your initializaion state is dependent on incomming parameters for your initialization, it will be very difficult for you to manage this manually.

Another approach, and the one which I will concentrate on here, is to develop your own mechanism for preserving request attributes from action to render.�� Before I get started, I also want to make some comments about the code.�� This code it an example which I’m using to illustrate an idea.�� As such, I’m not worrying about thread safety and robustness so much as I’m trying to illustrate an idea.�� If you want a pre-canned solution, I will likely be adding one to the configurator mechanism that I currently have under development, so keep watching this blog for further details.

The code below outlines the usage of a custom FacesContext Decorator.


  public class FacesContextImpl implements FacesContext
  {
    private FacesContext _orig;
    public static final String STATE_NAME = "scottobryan.STATE";
    public FacesContextImpl(FacesContext context)
    {
      _orig = context;
      ExternalContext ec = getExternalContext();
      Map<String, Object> saved = null;
      if(ec.getRequest() instanceof RenderRequest)
      {
        /*
         *First we look to see if we have a stored state
         *For this example I'm using the session but you can
         *use other scopes
         */
        saved = (Map<String, Object>)ec.getSessionMap()
                                         .remove(STATE_NAME);
      }

      if(saved == null)
      {
        saved = new HashMap<String, Object>();
      }

      ec.getRequestMap().put(STATE_NAME, saved);

      //TODO your other logic here
    }

    //TODO all other methods should delegate except release
    @Override
    public void release()
    {
      ExternalContext ec = getExternalContext();
      if (ActionRequest) instanceof ec.getRequest())
      {
        Map<String, Object> state =
         (Map<String, Object>)ec.getRequestMap()
                                  .remove(STATE_NAME);
        ec.getSessionMap().put(STATE_NAME, state);
      }

      _orig.release();
    }
  }

Lines 17 and 18 are responsible for trying to get the state off the session if it exists.�� If it does not then a new state map is created regardless of environment.

Lines 33 to 46 will save the map to the session when the FacesContext is release by the bridge.�� It will only do this on an action request since that’s the only usecase we care about.�� For cleanliness I go ahead and remove it from the request, but an uglier (albeit faster) technique might be to try to leave it on the request so that durring the next render you can figure out whether you are in a container which preserves request attributes and are therefore able to disable this caching alltogether.

The code will make sure that there will be a map stored on the request attributes by the name of STATE_NAME and that any attributes which are appended to it will be available throughout the lifetime of the physical request.�� If you have a container that is not tolerant of non-serializable data on the session (by spec it should be, just not for failover), you can either make all your stuff serializable or you can play around with appending it to the Application scope.

Also, it might be good to be able to encode some sort of id that can be used to tell whether the state belongs to a certain render request or not in case something happens and the render does not follow the action for which is was intended.�� This could happen as a result of a network hickup on a remote (WSRP) portal, but I’m hoping that in such curcumstances portals are able to recover better.

Enjoy!

Across the bridge [Flickr]

Aaron Gustafson — Thu, 03 Jul 2008 11:00:02 CDT

Aaron Gustafson posted a photo:

Links for 2008-07-02 [ma.gnolia]

Aaron Gustafson — Thu, 03 Jul 2008 08:00:02 CDT

Composition

Somewhere in this film is one of my photos of the Sydney Opera House. Very cool short film.

Saved By: Aaron Gustafson | View Details | Give Thanks

Tags: "Sydney Opera House", film, creative commons

Hidden folders in OS X file dialogs

Brian Pontarelli — Wed, 02 Jul 2008 16:00:03 CDT

Found a good shortcut for getting access to hidden folders in OS X file dialogs and the Finder. It requires some typing and it doesn’t auto-complete like Linux does, but it is better than nothing. Just hit Shift-Command-G to open the “Go To Folder” dialog and then type the path to the hidden file or folder. The path can be relative.

Now, just need to figure out how to access hidden files from the Finder and file dialogs.

Compass 2.1.0 M1 Released

Shay Banon — Wed, 02 Jul 2008 13:00:03 CDT

Compass version 2.1.0 M1 released. The release includes several features including a much improved XSEM support (namespace xpath, better stax integration, jdom integration), Dynamic mappings removal and additions, JSEM - JSON to Search Engine Mapping support, and Collocated integration and distributed search with GigaSpaces. It also includes several bug fixes (with the important ones backported to 2.0 branch). Enjoy!.

Where the hell is Matt?

Richard Monson-Haefel — Wed, 02 Jul 2008 11:00:02 CDT

I really needed this today.

"Matt is a 31-year-old deadbeat from Connecticut who used to think that all he ever wanted to do in life was make and play videogames. Matt achieved this goal pretty early and enjoyed it for a while, but eventually realized there might be other stuff he was missing out on. In February of 2003, he quit his job in Brisbane, Australia and used the money he'd saved to wander around Asia until it ran out. He made this site so he could keep his family and friends updated about where he is.A few months into his trip, a travel buddy gave Matt an idea. They were standing around taking pictures in Hanoi, and his friend said "Hey, why don't you stand over there and do that dance. I'll record it." He was referring to a particular dance Matt does. It's actually the only dance Matt does. He does it badly. Anyway, this turned out to be a very good idea."
- Patrick Drury

It’s ok to wet yourself every once in awhile

Andrew Glover — Wed, 02 Jul 2008 08:00:02 CDT

Dan North, the veritable progenitor of behavior driven development (or BDD), recently blogged about unnecessary DRYness (meaning don’t repeat yourself) with respect to clarity of intent when it comes to testing (in generic terms of the word). Essentially, in the case of a JUnit test, for example, by utilizing a setUp method and possibly other helper methods, the test itself becomes somewhat cluttered– one must jump around the code to truly understand the intention of the test in the first place.

In fact, Dan says it quite nicely– tests (or stories, baby) are:

“examples [that] tell a story about what the code does… [and] clarity of intent is found in the quality of the narrative, not necessarily in minimising duplication.”

Thus, over utilizing the DRY principle can be ineffective when it comes to testing; indeed, he makes a great point! If tests or stories are intended to serve as “executable documention” doesn’t it make sense to make them as easy to read and understand as possible?

As such, because it’s my bag, I took the liberty of pondering the depth of favored term DRY and decided that when it comes to clearly expressing intent with respect to stories (as in the case of easyb) or tests, it often pays to be WET– that is, wholly express your tactics, baby.

You see, applying WET to, say, an easyb story then yields perhaps more text, but it leaves no room for misinterpretation, man. For example, imagine a story regarding discounts (this is my touchstone example that is in danger of itself becoming dry– no pun intended either, man). The high level story is such that VIP customers receive varying discounts depending on the amount of money a particular order has– you could even require a minimum number of items too (if you were attempting to move inventory). Thus, one scenario could be:

scenario "VIP customer with 3 items, over $30 receiving 10% discount", {
  given "a VIP customer"
  and "given they have at least 3 items totaling over $30"
  when "they proceed to checkout"
  then "they should receive a 10% discount"
}

Of course, from here, stakeholders, through a collaborative effort, realize more scenarios are possible– for instance, the VIP customer has 3 items totaling over $100– thus, a higher discount is applied. A first stab of staying WET (that is, wholly expressing your tactics, man) yields this scenario:

scenario "VIP customer with 3 items, over $100 receiving 15% discount", {
  given "a VIP customer"
  and "given they have at least 3 items totaling over $100"
  when "they proceed to checkout"
  then "they should receive a 15% discount"
}

Reading these scenarios (which are executable, by the way!) leaves no room for missing the boat– the tactics involved are wholly expressed!!– reading them is somewhat effortless from the standpoint that you don’t necessarily need to jump around the file to gain a clear understanding of context.

If you prefer staying DRY, the story can become more concise–

before_each "a VIP customer with 3 items is assumed", {
  given "a VIP customer"
  and "given they have at least 3 items"
}

scenario "VIP customer with 3 items, over $30 receiving 10% discount", {
  given "the 3 items total at least $30"
  when "they proceed to checkout"
  then "they should receive a 10% discount"
} 

scenario "VIP customer with 3 items, over $100 receiving 15% discount", {
  given "the 3 items total at least $100"
  when "they proceed to checkout"
  then "they should receive a 15% discount"
}

Both stories convey intent– it is just that the WET one is more clearly expressed– in the DRY example, as more and more scenarios are added (and they surely will), one needs to jump to the top to gain an understanding of the underlying assumption (that is, a VIP customer with 3 items in their shopping cart).

DRY is fundamentally a sound principle– I’m not here to deny that; however, like all good things, it can be overused without regard for a particular situation. In fact, Johann Wolfgang von Goethe (of Faust fame, baby) is quoted thus:

“The phrases that men hear or repeat continually, end by becoming convictions and ossify the organs of intelligence.”

Because it is everyone’s bag, baby, think through DRYness from time to time and realize that in some cases, it is perfectly acceptable to WET yourself (I mean, to practice WET). Can you dig it, man?

I also blog at testearly.com | My company is hiring gurus

Loving the South African Developer Community

Brad Abrams — Tue, 01 Jul 2008 16:00:05 CDT

I just got back from South Africa and I am happy to report that the .NET Developer community is very strong there.

User's Group Meetings in in Johannesburg and Cape Town

User group meeting in Johannesburg - thanks for setting this up Craig Nicholson.. I had a great time showing off Silverlight 2. We had lot of fun talking about Silverlight wit these slides and demo that I did. I also showed HardRock DeepZoom, the video wall and HSN.TV
User group meeting in Cape Town - Thanks to Hilton Giesenow for setting this up. This time I did a drill down into the ASP.NET MVC framework. The response was excellent! Thanks folks for your questions and interest! Here is the slides and demo..

Mix Essentials in Johannesburg and Cape Town

We had over 664 developers\designers attend the events in both cities… A little over 3/5^th of them were developers and the vast majority of them were active ASP.NET developers. Just about everyone was already on VS2008.

Keynote:

We kicked off the day with keynote highlighting Microsoft’s investment in UX. I got drafted to do a breif bit on to show off some of the great work we are doing in WPF for SP1. So I showed the very cool WPF Bitmaps effects demo ScottGu showed at Mix '08 in Vegas… Judging from the comments afterward, I think it got a few people thinking about what is possible with a desktop applications. People were impressed that the CPU was not being chewed up by this..

For the rest of the day we split up – the designers when to a different room and I kept all of the developers. I did three sessions covering the full web development space. The retention rate was really good… just about everyone stuck around for the end.

Silverlight 2:

Next up I did an hour fifteen minute demo on Silverlight 2 development. I focused on end-to-end development, not just the UI glitz side of Silverlight and the audience responded very where. Rather than going through a bunch of slides I created an application from scratch that does read\write data access via WCF and LINQ as well as local storage via Isolated storage Here is part of the flow I used: http://blogs.msdn.com/brada/archive/2008/06/26/data-focused-silverlight-demo.aspx and http://blogs.msdn.com/brada/archive/2008/06/23/using-asp-net-authentication-in-a-web-service-with-silverlight.aspx. Thanks Scott Morrison for your help with this! Here are the slides I used to kick it off.

Ajax:

I had a great time doing this ajax demo… It was basically a reprise of my Mix 08 talk which is an all demo talk.. I could tell people really loved it! Because I had just come back from Safari, I re-themed it with my pictures.

MVC:

I split the last talk on the “future of ASP.NET” into two parts… Part 1 was on MVC. The “no viewstate” and the “IDs not mangled” were winners! Folks generally seemed to get that they did not have to move to ASP.NET MVC. The two consistent big asks where for better\more ajax support and some sort of reusable component support. I think we are well on our way to address both of those. Here are the slides and demo I used.

Dynamic Data:

This talk was a real crowd pleaser. I started off by showing how to change an existing site into being Dynamic Data aware and this really drove home the point about the value Dynamic Data adds. http://blogs.msdn.com/brada/archive/2008/06/20/asp-net-dynamicdata-an-introductory-demo.aspx . By this point ½ the room was already sold… but there was much more. I then used the wizard to show off all the customization capabilities of DD. That pulled the rest of them in. http://blogs.msdn.com/brada/archive/2008/06/27/asp-net-dynamic-data-customizing-the-ui.aspx . The questions here were all about support for different data sources. NHibernate, plain old objects, etc. I think we have a great story here and I wish I would have had time to demo it. Here are the slides I used

Closing

I had a little fun to close out the event. Through the day I had been throwing out giveaways (t-shirts\balls\hats) whenever someone asked a question or pointed out a bug I had made (there were a few!). But I was left with a big Microsoft keyboard that I didn’t want to through. So I ask for a volunteer to come up and code something on stage like I had done all day! I chose creating a LINQ model over top of Northwind as I did that like 5 different times during the event so I thought it was fair. The victims.. ah, I mean volunteers at the Cape Town and Johannesburg events did well! They started off kind of shaky and made me nervous, but they got in and nailed it! It was a good fun time for all as the audience “helped” out a bit by yelling suggestions. One guy even said “you owe me ½ that keyboard” when he finally go it ;-). Oh, and some folks asked me about the zooming tool I used to zoom in on the screen. It is called ZoomIt.

Here are a few blog posts I have already seen from the event..

http://liamb.com/2008/06/23/brad-abrams-visits-south-africa/
http://metallemon.blogspot.com/2008/06/mix-essentials-2008.html
http://www.fremus.co.za/blog/2008/06/first-experiences-with-visual-studio-2008/

I'd love to hear your feedback\thoughts on this... and if you blogged on the event please let me know and I will add your link here.

Oh, and I did spent a few days on Safari at Mala Mala adjacent to Krueger national park. I was amazed at the big game viewing... I highly recommend it. Here are some photos.

Public Speaking - Great Beginnings

Josh Holmes — Tue, 01 Jul 2008 13:00:02 CDT

I'm giving a talk next week at the Microsoft Worldwide Partner Conference (WPC). I happen to be in the fun position where I'm directly following the keynote. I've sat in on content reviews and keynote writing sessions so I know the messaging from that talk and the overlap that there will be with my session.

One of the services that they offer to their speakers is a speech coach. It's the first time that I've worked with one one on one. I sat through a class offered by a different conference a number of years back. It was fairly useless so I didn't have high hopes for another speaker coach. Boy was I wrong.

I met with Cathy Banks of Communication Power, Inc. I cockily told her that I have spoken at hundreds of conferences and typically get 8s or better on my evals. Turns out I'm not the only speaker out there that's had Cathy change the way that they speak - here's a post by Lee Lefever talking about his 10 lessons learned from his speaking coach.

I talked to her about the fact that it often takes me 3-4 times to really nail the ending on a talk. It's been a constant problem that I've had on how to end a talk. I often run over time because I'm rambling trying to figure out how to finish a session.

Cathy, to my surprise, insisted that we start on the opening. I'm not usually concerned about the opening. I have a fairly casual style that sets the audience at ease and gets their attention.

It was brutal. She had me do the opening, asked me how I thought it went. I was relatively pleased. Then asked me what the point of the talk was because she obviously didn't get it from my opening. I ran through the highlights of the talk and pointed out the top level message that I was targeting.

All of the sudden, I saw the issue with the opening that she was pointing out. I was rambling through the opening without clearly framing the overall message for the talk. My opening was entertaining, but really didn't succinctly tell the audience what they needed to get out of this session. That's the hook that gets the audience to listen for the rest of the session.

Then she asked me what I knew about the crowd. I felt good about this because I knew the target demographics pretty well and was able to talk to that. It's mostly going to be business level folk in the room. These are management, business-development folk, business owners and so on at this conference. But then she turns it on me asking how my overall message related to this crowd. My message was far to technical and this audience really doesn't care. I need to give them the couple of technical sound bytes but really hit on how they are going to make money from all of this.

With all of that in mind, I tried my opening again. It felt better but was still a little off.

She took a crack at an opening off the top of her head. And nailed it. As I parsed out what she had just said, I thought through my version of the opening. It was funny but was not nearly crisp enough. It wasn't well defined as an opening. It was talked to the crowd now but still didn't hit the 2-3 high level points that I was going to dive deep in for the rest of the session.

I tried it again. And again. And again. Somewhere in here, she started goading me on saying, "Come on Josh! How'd you get through those hundreds of conferences? Tell me that story. I know you're a story teller so tell me the story!". Yes it stung, but wow it worked.

Things started to crisp up. I started off my opening with a continuation of a story from the previous talk. I carry over some of the language from the keynote as well. This will help with continuity and really draw the connection between the keynote and my session. I hit the two points that I wanted to hit, gave a solid hook, did all that in a humorous manner and in less than a minute. WOW! I was thrilled.��

Now that I had my opening down, Cathy asked me to jump to the closing. The first one was a little rough. Then she asked me to run through the opening again and jump immediately to the closing. That was killer. I got a fairly solid closing on the second try. Two more refinement rounds and I was set. I carried the language through from the opening, tied off the ends on the two points that I wanted to get across in the session and had a solid call to action.

As Cathly pointed out to me VERY clearly, the reason that I couldn't close a session crisply was that I didn't have a good opening. With a good opening comes a good closing.

All that's left is the stuffing in the middle.

Keys to a good opening

Understand the audience. This helps you target the content at the right level.

Understand the message. I put this second because there are a lot of messages that don't apply to all audiences. But this is a critical part of the talk. Many talks that I see don't really have a "message". They just want to demo a technique or something. The best talks had a solid call to action and are trying to motivate people to do something.

Set up the language for the rest of the talk.

Write it out. Apollo Ideas has a post called Prepare yourself that discusses the different levels of preparation you can have for a great presentation. I talked about it a little in my post Prepare Yourself To Give a Great Talk. This is especially true for the opening and closing of your session. These are the times that you are in the most control of your session.

Don't worry about establishing credibility. Because you're onstage, you already have the credibility that you need. The conference has given you that. It's your credibility to lose, not gain. Nobody cares how smart you think you are. They care what you're going to be talking about and the points that you're goign to be making. Chris Bernard usually does his whole opening and then gives people his contact information. I'm going to steal this idea.

Have fun. If you're not having fun, the audience won't either.

More reading

Kathy Sierra: Better Beginnings: How to Start a Presentation, Book, Article

John Kinde: Winning Your Speech At the Starting Line

Technorati Tags: Speaking,Opening

James Gosling

Richard Monson-Haefel — Tue, 01 Jul 2008 11:00:02 CDT

I own most of my success to the Java Platform and therefor, in my opinion, to the team that developed Java - including James Gosling. I've always been in awe of James Gosling mostly because he is deemed "the father of Java" and has been the top guy in the Java industry for as long as I can remember (stretching back to my introduction to Java in 1995).

My admiration for him is based on that fact that he invented a platform that was not only interesting and exciting but a platform that is perhaps the most successful programming platform in history. There are more Java software developers and more Java software than just about anything else - the possible exception might be C/C++.

There is a pretty good article about James Gosling and the future of Sun Microsystems, called Java Computing: Second Cup?, which was published in Canadian Business magazine - its an example of great reporting which in my opinion is missing from technical press these days.

I always wanted to write an accurate but populist account of the history of Java, but I'll probably never get around to do it. Computing history is fascinating to me. I hope someone writes a book about the invention and subsequent ups and downs of the Java platform and Sun Microsystems. It would be fascinating.

Testing Anti-Patterns: Overspecification

Jason Rudolph — Tue, 01 Jul 2008 08:00:02 CDT

Tests increasingly serve multiple roles in today’s projects. They help us design APIs through test-driven development. They provide confidence that new changes aren’t breaking existing functionality. They offer an executable specification of the application. But can we ever get to a point where we have too much testing?

Enough is Enough

Consider the following test that you might come across in an application with a less-than-ideal test suite. (We’ll pick on some badly-written Rails code for this example, but the ideas we’ll discuss are certainly not unique to just Rails or Ruby or even just to dynamic languages. Unfortunately, these problems are quite universal.)

require File.dirname(__FILE__) + ‘/../test_helper’
class ProductsControllerTest < ActionController::TestCase
def test_something
product = Product.create(:name => "Frisbee", :price => 5.00)
get :show, :id => product.id
assert_response :success
product = assigns(:product)
assert_not_nil product
assert product.valid?
assert product.name == "Frisbee"
assert product.price == 5.00
end
end

Whoa! That sure is a lot going on in a single test case. What exactly is it that we’re trying to test here? Let’s take a step back and see if we can figure it out. [1]

Line 5 - We start off by creating a new product. We give the product a name and a price and call #create. Since we’re in a Rails app, without looking elsewhere in the code, we can make an educated guess that Product is an ActiveRecord subclass and that calling #create will persist the product to the database.
Line 6 - We send an HTTP GET request to a #show method and pass along the ID of the product we just created. Since we’re in ProductsControllerTest, we can safely infer that we’re calling the #show action in the ProductsController class.
Line 7 - We assert that the controller action responded with HTTP status code 200 (i.e., success).
Lines 8-9 - We look for an object stored in the assigns hash (i.e., the hash of variables that will be available to the view template) with a key of :product and we assert that it’s not nil.
Line 10 - We verify that the product object satisfies all the product validation rules (though we can’t know what those rules are without taking a look at the Product class).
Lines 11-12 - We assert that the attribute values we provided when creating the product (in line 5) match the attribute values stored in the object we fetched from the assigns hash.

For a class called ProductsControllerTest, it sure feels like we’re doing a fair bit more than just testing the code we’d expect to find in ProductsController (assuming ProductsController conforms to the traditional responsibilities of a controller). Let’s take a look at the controller code to better understand exactly what it is that we’re testing.

class ProductsController < ApplicationController
def show
@product = Product.find(params[:id])
end
end

It turns out that our controller code is notably simpler than our test case would have led us to believe. The #show action does indeed stick to the expected behavior of a controller, and in this case, it’s able to provide that behavior in a single line of code (despite the 8 lines of test code currently employed above). That single line satisfies all of the expectations of the #show action: look up the product with the given ID and place the product object in an instance variable for use by the view.

If the #show action isn’t responsible for knowing how to successfully save a new product record into the database, why does our test case attempt to provide the data for creating a new product? What will happen to our test case when someone adds a new validation rule requiring that all products also include a quantity attribute? Unfortunately, the test as it’s currently written will break. And while a failing test is often a welcome warning that our changes have inadvertently broken a part of our application, it’s far from desirable for a model-level rule related to creating new records to cause a failure in a controller test related simply to displaying existing records. In short, we’ve given our test case too much responsibility, and in doing so, we’ve made it fragile.

We can see from the #show action above that not only is the controller not responsible for knowing how to create a valid product, it’s also not responsible for ensuring that a product’s attributes are properly populated when the record is read from the database. However, if we take another look at the last few lines of the test case, we might think otherwise. That brings us to the second problem with this particular test: it’s a rotten source of documentation for the code being tested. As we increasingly move toward tests as specifications of our application’s behavior, it’s vital that those specifications clearly communicate the expected behavior. As it’s currently implemented, the overspecification in this test case leaves the reader having to do way too much work to figure out the true expectations of the code being tested.

Communicate Essence

Let’s take another pass at writing a test for the #show action, this time with an eye toward removing the fragility of the previous test case and increasing the value of the test as a specification.

require File.dirname(__FILE__) + ‘/../test_helper’
class ProductsControllerTest < ActionController::TestCase
def test_should_show_product
product = create_product
get :show, :id => product.id
assert_response :success
assert_equal product, assigns(:product)
end
end

In this implementation, we’ve abstracted away the logic for creating a new product in line 5. We’ve defined a helper method for use by any and all tests in our application that have a need to create a new product. If and when the rules for successfully creating a new product change, we’ll update the #create_product method, and we won’t have to touch the code in ProductsController or ProductsControllerTest at all. [2]

As for the four assertions that appeared at the end of our first attempt at this test case, we’ve replaced those assertions with a single (stronger) assertion. Where we previously asserted that the assigns hash held a non-nil product, that the product was valid, and that its attributes matched the attributes used at the beginning of the test, we now simply verify that the product object in the assigns hash is equal to the product object that we created at the beginning of the test. That single line more accurately and more concisely expresses our expectation: that the product whose ID we provide in the request to the #show action is the same object that’s made available to the view.

By focusing our test case on the essence of the code under test, we’ve ended up with less test code to maintain. And with the extraneous setup and assertions removed, the remaining test code provides a clearer and less fragile specification of the behavior being tested. [3]

May I Take Your Order, Please?

In the previous example, we might have detected the overspecification by the significant mismatch between the lines of test code and the lines of production code, or seeing model-specific assertions in a controller-specific test may have caught our eye. But, overspecification comes in more subtle forms as well. Consider the following method provided by ActiveRecord::Base for fetching the list of columns that hold domain-specific content from a model class in Rails.

# Returns an array of column objects where the primary id, all columns ending in "_id" or "_count",
# and columns used for single table inheritance have been removed.
def content_columns
@content_columns ||= columns.reject { |c| c.primary || c.name =~ /(_id|_count)$/ || c.name == inheritance_column }
end

To test this method, we’ll need a sample ActiveRecord model class. Let’s use the Topic model, which is backed by the following table.

create_table :topics, :force => true do |t|
t.string :title
t.string :author_name
t.string :author_email_address
t.datetime :written_on
t.time :bonus_time
t.date :last_read
t.text :content
t.boolean :approved, :default => true
t.integer :replies_count, :default => 0
t.integer :parent_id
t.string :type
end

In our first attempt at testing the #content_columns method, we might come up something similar to this:

# (Naive) First Attempt
def test_content_columns
content_columns = Topic.content_columns
content_column_names = content_columns.map {|column| column.name}
assert_equal %w(title author_name author_email_address written_on bonus_time last_read content approved), content_column_names
end

Can you spot the overspecification? To give you a hint, compare that test to the actual test employed in the ActiveRecord test suite:

# The Real Deal
def test_content_columns
content_columns = Topic.content_columns
content_column_names = content_columns.map {|column| column.name}
assert_equal 8, content_columns.length
assert_equal %w(title author_name author_email_address written_on bonus_time last_read content approved).sort, content_column_names.sort
end

If you’ve ever written a test for something that returns an ordered list of items where the actual order either doesn’t matter or isn’t guaranteed, you’ve probably been bitten by this breed of overspecification, and there’s a good chance your solution matched the solution used in the ActiveRecord test code above. Because the #content_columns method doesn’t guarantee that the columns will be returned in any particular order, it’s inappropriate (and fragile) for our test to specify a certain order.

While the actual ActiveRecord solution above works, it too could be better. First, since we know that the two arrays in line 6 won’t be equal unless they have the same length, we can safely remove the extraneous length assertion in line 5. Second, when we see the calls to #sort on line 6, we’re forced to pause (if even for just a moment) to think about why it might be important to sort the two arrays. We don’t really want to sort the arrays; we’re just using that technique to get around the fact that order doesn’t matter to us, but it does matter when Ruby compares two arrays for equality. Since we really only want to assert that the arrays have the same elements, why not do exactly that?

# Don’t Make Me Think
def test_content_columns
content_columns = Topic.content_columns
content_column_names = content_columns.map {|column| column.name}
assert_same_elements %w(title author_name author_email_address written_on bonus_time last_read content approved), content_column_names
end

By using an assertion like Shoulda’s assert_same_elements method, our test can clearly and concisely express the expected behavior.

Use It Wisely

Overspecification comes in many flavors, and the examples above in no way represent a comprehensive list. As developers, we frequently strive to write as little code as possible to accomplish the task at hand. When it comes to writing tests, we should very much keep that goal in mind as well. Good tests communicate the essence of the scenario being tested and nothing more. While I doubt a project will ever suffer from too much testing, it can certainly suffer from tests that specify too much.

Notes

[1] If this test seems absurd to you, good! Your ability to detect this type of overspecification will serve you well.

[2] The actual implementation of the #create_product method isn’t particularly pertinent in this discussion. (In the Rails space, there’s certainly no shortage of options.)

[3] With all the excessive thoroughness that went into overspecifying the the current behavior of the #show method, is it possible that we’ve been too distracted to identify other functionality that’s still missing from that method? In the next post, we’ll take a look at overspecification’s more lethargic cousin: underspecification.

Thanks to Justin Gehtland, Muness Alrubaie, and Glenn Vanderburg for reading drafts of this post.