All the Tech Ed 2006 photos

Click here for the photos

Tech Ed - Unit Testing Best Practices with VSTS 2005

Went to a lecture by Mark Seeman (who is a senior MS Consultant) about Unit Testing with VSTS. This was a good lecture as an introduction to unit testing as a concept as well as what VSTS gives us out of the box.

He started off by giving his opinion of a unit being a whole assembly, so he believes that we should be thinking of testing an assembly as a whole, but always abstract away from any volatile dependencies such as other changing components or db. Interestingly he was very adamant that we only test the public interface of the component. After explaining his reasons it really gave me a much better picture of what exactly the aim of the game is :). We are really setting out to test the component from a black box aspect and test the contract.

I really liked the agile type testing that he demoed where you create a test and then build the code to meet it, this really gives you a clear sense of a goal and will keep you from going off on a tangent :)

With VSTS he showed us how we can create a test project (and he recommends a test project for each component you test) and then create test methods within this which form our actual tests. We use a declarative TestMethod attribute to the methods to let VS know that the method is a test. Within the methods we can use the assert object to test the results of calls etc. by comparing our expected result with the actual result. When we build up our tests and run them we can use the test manager to check our results and the code coverage tool to see how much of our code we have tested.

He mentioned the following best practices:

• Always keep tests simple.
• Always aim to test all your code by aiming for code coverage of around 90%.
• All logic should be in components so they can be tested, don’t put any login in the UI.
• Test cases must be independent (should setup and clean down tests)
• Test cases must be deterministic (you should not do things like create random values)
• Reproduce bugs as test cases
• Place tests in separate projects
• Have a test project per test target
• Use source control on test projects

Tech Ed - Asynchronous ASP.NET Programming

Went to a lecture by Jeff Prosise about Asynchronous ASP.NET Programming which was really interesting. The first thing to note is that this subject is really under documented considering its such an important architecture to use as it can allow you to scale your site.

He explained that when IIS receives an ASP.NET requests it is passed to the worker process, which then allocates it a worker thread from its managed pool of available threads. This thread will remain with the request for its entire lifetime. The worker process also manages an IO thread pool for allocating to any processes that require to carry out any IO.

As there is a finite number of worker process threads that can serve requests it is possible for a busy site to become saturated with requests that cannot be served and clients will start to receive 503 errors. If this occurs we need to scale out the site so serve more requests. One way of doing this is buying more hardware, but the better option is to write our code to utilise the thread by writing asynchronous code. If our code is asynchronous the worker thread can return to the pool to serve more requests whilst we wait for any long running actions such as IO or db actions to occur.

He showed us a couple of ways to make our ASP.NET pages asynchronous, they both involved setting the Async attribute to true in our page directive and then either do the following:
Call AddOnPreRenderCompleteAsync in the page load to register our two Begin and End delegates which can then be used in the page to do the long running process.
or
Create a PageAsyncTask delegate that contains our two Begin and End delegates and register this with the RegisterAsyncTask. This method has the advantage of being able to maintain the thread context, create many tasks, and have a timeout value.

The Async delegates will be called just after the preRender event.

We can use ADO.NET BeginExecuteReader to return the IAsyncResult object to pass up to the return of BeginAsyncOperation method. We also have to complete the EndAsyncResult.

I think if we do make all of our IO methos asynchronous we could really improve the scaleability of our sites – I certainly we be pushing to get some of these changes included in the next releases of my sites :)

He then spoke about creating http handlers which are just classes that adhere to the IHttpHandler object. You can register these with specific file types (not that useful) or create a ashx file with a webhandler directive and ASP.NET will automatically use this object when it is requested by the client. Using this instead of a classic aspx file is great for requests that will not be returning form/asp.net type data such as images as it does not have all the overhead of the pipeline that a aspx request moves through.

He showed us a demo of using a ashx object to return pictures by having a normal img tag on a page that had its src set to navigate to the ashx file with a set of params. When the page renders it calls off to the ashx file which returns the graphic without having to go through the same pipeline that a aspx page would have had to. This results is a much quicker response for the client.

He explained that by default an http handler is synchronous but we can make them asynchronous by conforming to IHttpAsyncHandler instead. You just have to have an empty ProcessRequest method and then fill in the BeginProcessRequest and EndProcessRequest with the work. This is then called asynchronously by ASP.NET.

He showed a good demo of a site pulling back images from virtual earth which render much quicker when using asynchronous calls.

He noted that more improvements could be made by editing the max no of concurrent connections in machine.config.

He also told us to Avoid thread.start Threadpool.queueuserworkitem and Asynchronous delegates and that we should use custom thread pools if necessary as otherwise you can steal a thread from the same pool as the ASP.NET worker process.

Tech Ed - UK Country Drinks

We were invited to Shoko a really cool far east style contemporary lounge club with a terrace that overlooked the beach. It was a really good evening. We got on a coach from the main event to the club, but it turned out it was really close to our hotel and we probably could of walked it quicker and had a chance to get changed - but never mind :)
Once in it was free drinks on tap :) and loads of different tapas to try, and a yummy chocolate fountain :) This was a really good night, nice one M$ ;)

Tech Ed - Patterns & anti patterns with SOA

We went to this lecture by Ron Jacobs who is fast becoming one of our favorite speakers, he is really interesting and engaging :)

Basically he was saying that using SOA technologies does not guarantee success and there is never a right answer coz as usual everything has pros & cons.

The goal of this is to have a friction free interaction between systems so there are no problems such as different file types or transportation methods.

He made an interesting point that SOA is not a noun; it’s a style of architecture which emphasizes on standard based communication.

He highlighted that tightly coupled systems defiantly have there place as if everything is lose its slow as hell :)

We must aim when designing SOA for a good set of explicit behaviors over implicit where the client has to ‘try things out’ to find out how things work.

He told us to think of service granularity at a business process level and that each of these have their interface.

As all boundaries should be explicit he gave a great metaphor of an explicit boundary being an international boarder between countries and that you know where they are clear and when you cross them you are not in control of anything. So when we are not in control of things such as server or config we know we have an explicit international boundary that will be an interface to a service. As with international borders we need to think carefully about how many we have and how we control them as they are expensive and problematic if they are not controlled. For internal business boundaries you can do anything you want and this includes tightly coupled objects to improve performance.

He spoke about Anti Patterns (patterns that show how to do things wrong so that you can make sure you don’t do the same). He discussed the following:

• CRUDy interface - when you create an interface with simple CRUD commands on it when this should be a full business process with logic.
• Enumeration - should not have enumeration commands such getnext() that go against the atomic nature of a service and causes the server to hold a big amount of data whilst a client navigates it.
• Chatty interface - bad when a service offers lots of methods that must be called in a sequence of calls by the client to carry out an operation. The client may call one command but never get to call any others and the service is left in an inconsistent state. We should design larger web service method and do all the steps in there.
• Loosy Goosy :) - where a service tries to be uber generic with a single command that takes a lump of xml and returns a lump of xml and uses a word doc to define the contract. This is hard to test and hard for the client to use as it may implicitly change. Sometimes this is done to stop versioning problems. Now this is easier with serialization improvements in .NET 2.0, but the message is to “receive liberally and send explicitly”.

He explained that the best way to start a SOA design is to start with the process and understand it. Then create the contract by defining the messages, operations and by group them.
Use portable types - returning datasets is not good, this can be used internally but for external service we should decouple internal and external objects by unloading one internal object into another external object.

His advice is to think of moving bits of paper not calling methods.

Ron has some really good web casts that he has shown at the event we can take a look over at http://www.arcast.net/

Tech Ed - Unified Process and VSTS

WOW we were so looking forward to seeing Ivar Jacobson, the legend!!!!
However, the seminar was just way too sureal.
Ivar has down a total U turn ... moving from his strict methodology to now almost anything goes!!!! What was very clear is Ivar's goal is simply to help people produce good software and the means to getting there is fairly flexible. He admits that Agile has the correct emphasis on people rather than process and that the language is correct.

He also told us that he knows most developers just don't read books - they just buy them :)

His consultancy firm have developed a framework called the Unified Process model that allows you to use different processes from different methodologies to get the job done. There seems to an interesting "game" you play in this model with activities!! Explanations of the different processes are displayed on small cards with further reading available. It was not totally clear how to start on this or how exactly this model works but I'm sure Ivar will be writing a book on it :) More info at http://www.ivarjacobson.com/home.cfm

The whole integration with VSTS was the most confusing demo and piece of software we have ever seen. We really have no idea how to use it or how it works!!!!

Tech Ed - C# whiteboard session with Anders Hejlsberg

Lots of cool questions but an interesting feature was discussed was partial methods where a method call is put in a partial class to a partial method. This partial method can then be implemented in another partial class.

Anders talking about what he would do different with C# said;

• He would of liked better difference between reference equals and value equals.
• No goto.
• Go straight to lambda instead of using annoymous types.