1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184

using System;
using System.Threading;
 
namespace PatternExplorer {
   /// <summary>
   /// Provides a base implementation of <see cref="IDisposable"/>.
   /// </summary>
   /// <remarks>
   /// 
   /// Derived classes that need finalizers should implement the following
   ///  AND be sealed.
   /// 
   ///    /// <summary>
   ///    /// Finalizer.
   ///    /// </summary>
   ///    ~MyClass() {
   ///       Dispose(false);
   ///    }
   /// 
   /// Derived classes that need to protect against access of disposed state
   ///  can use the following example:
   /// 
   ///    /// <summary>
   ///    /// Member accessing potentially disposed state.
   ///    /// </summary>
   ///    public void MyMethod() {
   ///       ThrowIfDisposed();
   ///       // ... 
   ///    }
   /// 
   /// </remarks>
   public abstract class Disposable : IDisposable {
      /// <summary>
      /// "Not Disposed" state.
      /// </summary>
      private const int NOT_DISPOSED = 0;
 
      /// <summary>
      /// "Disposing" state.
      /// </summary>
      private const int DISPOSING = 1;
 
      /// <summary>
      /// "Disposed" state.
      /// </summary>
      private const int DISPOSED = 2;
 
      /// <summary>
      /// A flag to indicate state of disposal.
      /// </summary>
      private int _State;
 
      /// <summary>
      /// Constructor.
      /// </summary>
      protected Disposable() {}
 
      /// <summary>
      /// <c>true</c> if the instance has been disposed; otherwise, <c>false</c>.
      /// </summary>
      public bool IsDisposed {
         get { return Thread.VolatileRead(ref _State) != DISPOSED; }
      }
 
      /// <summary>
      /// Occurs when the instance is being disposed.
      /// </summary>
      public event EventHandler Disposing;
 
      /// <summary>
      /// Occurs when the instance has been disposed.
      /// </summary>
      public event EventHandler Disposed;
 
      /// <summary>
      /// Notifies listeners that the instance is being disposed.
      /// </summary>
      protected virtual void OnDisposing() {
         if( Disposing != null ) {
            Disposing.Invoke(this, EventArgs.Empty);
         }
      }
 
      /// <summary>
      /// Notifies listeners that the instance has been disposed.
      /// </summary>
      protected virtual void OnDisposed() {
         if( Disposed != null ) {
            Disposed.Invoke(this, EventArgs.Empty);
         }
      }
 
      /// <summary>
      /// Performs application-defined tasks associated with freeing,
      ///  releasing, or resetting resources held by the current instance.
      /// </summary>
      public void Dispose() {
         Dispose(true);
      }
 
      /// <summary>
      /// Disposes the instance.
      /// </summary>
      /// <param name="disposing"><c>true</c> to indicate explicit
      ///  cleanup (i.e. <see cref="IDisposable.Dispose"/>()), otherwise
      ///  <c>false</c> (i.e. implicit cleanup from finalizer)</param>
      protected void Dispose( bool disposing ) {
         // if( _State == NOT_DISPOSED ) {
         if( Interlocked.CompareExchange(ref _State, 
                                             DISPOSING, 
                                             NOT_DISPOSED) == NOT_DISPOSED ) {
            // _State = DISPOSING;
 
            if( disposing ) {
               try {
                  OnDisposing();
               } catch {
                  // intentional suppression
               }
               try {
                  DisposeManagedFields();
               } catch {
                  // intentional suppression
               }
               try {
                  RemoveDelegates();
               } catch {
                  // intentional suppression
               }
            }
 
            try {
               ReleaseUnmanagedResources();
            } catch {
               // intentional suppression
            }
 
            Interlocked.Increment(ref _State); // _State = DISPOSED;
 
            if( disposing ) {
               try {
                  GC.SuppressFinalize(this);
               } catch {
                  // intentional suppression
               }
               try {
                  OnDisposed();
               } catch {
                  // intentional suppression
               }
            }
         }
      }
 
      /// <summary>
      /// When overridden in a derived class, this method should dispose
      ///  all <see cref="IDisposable"/> fields.
      /// </summary>
      protected virtual void DisposeManagedFields() {}
 
      /// <summary>
      /// When overridden in a derived class, this method should remove
      ///  all delegate invocations and references.
      /// </summary>
      protected virtual void RemoveDelegates() {}
 
      /// <summary>
      /// When overridden in a derived class, this method should clean up
      ///  any unmanaged resources.
      /// </summary>
      protected virtual void ReleaseUnmanagedResources() {}
 
      /// <summary>
      /// Derived classes may use this method to prevent member access
      ///  on a disposed instance.
      /// </summary>
      protected void ThrowIfDisposed() {
         if( IsDisposed ) {
            throw new ObjectDisposedException(GetType().FullName,
               @"Access to a disposed object is not allowed.");
         }
      }
   }
}

Get the code here.

Breakout Session :: 300 (Advanced) :: Developer Practices

“In this demo-filled session, you’ll learn the why, what, where, when and how of working with test-driven development using the tools provided in Visual Studio 2010. In addition to seeing ‘testing-in-action’, you’ll learn about when to use what kind of test. You’ll learn both about using TDD with new code and in legacy situations. Code better and discover features in Visual Studio, such as code coverage and more that will help you to be more productive.”

Highlights

The session centered around fluency in TDD, and the requirement to keep your test code of production quality (i.e. refactor where necessary, etc.) – it also introduced the “Approvals” library, as an alternative to having to assert very granular bits of state.

The testing cycle suggested is: Whiteboard (Requirement), English (Translation), Code (Implementation), Test (Regression) and Result (Verification) and aims to promote the notion of “Intentional Code”.

Links

• Approval Tests Library
• Develop Mentor
• Slide Deck

Breakout Session :: 300 (Advanced) :: Developer Practices

“Given that you want to deliver high quality code, when you drive your entire software development lifecycle with tests – you will dramatically improve overall quality. Microsoft’s introduction of Visual Studio 2010 and Microsoft Test Manager provides very powerful tools we can use to begin with tests. In this presentation we specify an entire system with tests. We begin with tests to ensure the business value of an application is testable and we know when we’re done. Using those tests, we clarify the requirements using acceptance criteria expressed as test cases. Finally, we decompose the requirements to specific testable behaviours that will drive our unit tests. Armed with the complete understanding of the application, we begin to work upwards again. We automate the unit tests to ensure our code is tested. Then, as our code begins to take shape, we automate the functional tests to ensure our requirements are met – and stay met as our code continues to evolve. Finally, we automate the system and integration tests to prove to our customers that we have met the end-to-end vision of the application. The final demonstration shows the integration of all tests running during an automated nightly build.”

Video

Breakout Session :: 400 (Expert) :: Developer Tools, Languages and Frameworks

“Whenever doing blocking tasks, particularly service calls in a Silverlight or Windows Presentation Foundation (WPF) client, you will need to make those calls asynchronously. While async calls have been around for a long time in Microsoft .NET, the patterns for addressing them have been changing and improving. This session covers several common patterns for addressing async calls in client applications, including new and emerging approaches to async patterns such as Reactive Extensions that let you treat asynchronous execution like a LINQ collection and the Task-based Async pattern and keywords coming for the C# and VB languages. This session takes the mystery and confusion out of what happens and when — and how to keep your code clean and safe in an inherently asynchronous client world.”

Video

Highlights

This session provided a practical overview of asynchrony from the perspective of the UI (and by extension the affinity that UI objects and ObservableCollection<T> has with the UI thread). Some rule-of-thumb tips are:

• Never block the UI thread. If it takes longer than 50-60ms, async it.
• Never access UI objects from a non-UI thread.
• Don’t access variables from multiple threads with protection.

The asynchronous patterns provided by the .Net Framework are:

• Begin/End Async Pattern
• Async/Completed Pattern
• Task Parallel Library (Task<T>)
• Task-based Async (async and await keywords)
• Reactive Extensions (LINQ + Observables + Schedulers)

Links

• Book: Programming .NET Components, Second Edition
• The Reactive Extensions (Rx)
• Visual Studio Asynchronous Programming
• Mark Pearl

Breakout Session :: 400 (Expert) :: Developer Tools, Languages and Frameworks

“Asynchronous programming is no longer an option; it’s become a must on various platforms, including Silverlight, Windows Phone 7, and various data-centric frameworks. Unfortunately, dealing with asynchrony is way too hard in today’s world of development tools and frameworks. The huge amount of manual and error-prone plumbing leads to incomprehensible and hard to maintain code. As we reach out to services in the cloud, the desire for asynchronous computation is ever increasing, requiring a fresh look on the problems imposed by reactive programming. In this session, we explore various methodologies to address asynchronous programming, and explain how they relate and differ. First, we’ll explore existing patterns and libraries – such as the TPL – to sketch some of the pain-points. Armed with this knowledge, we’ll approach the problem from different angles, including a language-centric view with F#’s asynchronous workflows and the upcoming asynch and await features in C# and Visual Basic. Next, we’ll move beyond sequential composition of asynchronous computations, and introduce the Reactive Extensions (Rx) that enable you to express rich queries – even using LINQ syntax – over asynchronous push-based “reactive” event streams.”

Highlights

The discussion starts by introducing the concepts of Asynchrony (multiple parties evolving in time independently), Concurrency (order in which multiple tasks execute is not determined) and Parralelism (multiple tasks working together), and some wording (“Reactive”, “Callbacks”, “Events”) that typically describe asynchronous situations.

Abstractions in .Net that support asynchrony are: Asynchronous Programming Model (uses callback functions), Event-Based Asynchronous Pattern (uses completion events), and the BackgroundWorker Component.

New tools and abstractions being introduced in upcoming versions of C# and .Net include:

• await keyword suspends the code that follows the keyword into a continuation for the asynchronous operation completion. The keyword (and the code following it) can be safely wrapped in standard control statements such as while{}, or try{} catch{} blocks.
• Task<T> is a representation of computations (.StartNew()), and hooks (.ContinueWith()) for continuations (which allows for sequencing). Task.Result blocks the calling thread.
• BeginVerb-EndVerb patterned functions and VerbAsync functions are complemented with VerbTaskAsync functions that return Task<T>.

Some code examples:

Example 1

1
2
3

var report = Task.Factory.StartNew(() => GetFileData())
			 .ContinueWith(x => Analyze(x.Result))
			 .ContinueWith(y => Summarize(y.Result));

Example 2

1
2
3
4
5
6
7
8
9
10
11
12
13

async void DoWorkAsync() {
	var t1 = ProcessFeedAsync("x");
	var t2 = ProcessFeedAsync("y");
	await Task.WhenAll(t1, t2);
	DisplayMessage("Done");
}
 
async Task ProcessFeedAsync( string url ) {
	var text = await DownloadFeedAsync(url);
	var doc = ParseFeedIntoDoc(text);
	await SaveDocAsync(doc);
	ProcessLog.WriteEntry(url);
}

Reactive Extension (Rx)

Rx is a library for composing asynchronous and event-based programs using observable sequences. Think IObservable<T> and IObserver<T> (subscribe, push) vs. IEnumerable<T> and IEnumerator<T> (pull, blocking).

The concepts introduced by Rx are best studied through additional research into some of the functions it provides:

• .Throttle()
• .DistinctUntilChanged()
• .TakeUntil()
• .ObserveOn()
• .Subscribe()

The relationship between the various paradigms is best visualized on a graph representing (Axis Y): Single Value vs. Multiple Values over (Axis X): Syncrhonous vs. Asynchronous … the four distinct quadrants of this graph are:

• Single-Value Synchronous: Func<T>
• Single-Value Asynchronous: Task<T> (and await)
• Multiple-Value Synchronous: IEnumerable<T>
• Multiple-Value Asynchronous: IObservable<T> (and .Subscribe())

Lunchbox Session :: 300 (Advanced) :: Developer Practices

“This session compares the architectural patterns of Model-View-Controller (MVC), Model-View-Presenter (MVP) and Model-View-View Model (MVVM). Each pattern creates testable, maintainable and reusable application components, however, there are differences that suit each approach to specific types of developer tooling. The presentation first looks at the basic theory and differences between the approaches; then uses demos that show how each apply to Microsoft ASP.NET, Microsoft Silverlight/Windows Presentation Foundation (WPF) and Microsoft SharePoint developer application projects.”

Video

Highlights

The MVC pattern is distinct in that the user interacts directly with the Controller objects, while both others represent patters where the user interacts with the View objects. MVC is primarily suited for use in the ASP.Net MVC Framework, as the underlying concepts are fundamentaly built in to the framework itself. With some effort however, MVC can be implemented directly onto standard ASP.Net (which is of course what the MVC Framework essentially does for you). WinForms applications could also fit into the MVC paradigm, and can be built on this pattern with even less effort than standard ASP.Net. In this pattern: M = Model, V = View and C = Controller; where M is unaware of V and C, V is aware of M, and C is aware of both V and M.

MVP lends itself well to “standard” ASP.Net projects and SharePoint development, with the assumption (and indeed “requirement”) that while Views are the point of entry and interaction with the user, they “dumb [themselves] down” and relinquish control to the Presenters that they instantiate. In this pattern: M = Model, V = View and P = Presenter; where M is unaware of V and P, V is aware of P, and P is aware of both M and an interface representative of V.

MVVM is the most recent evolution of these “separation of concern” patterns, and is most useful in the XAML (Silverlight and WPF) environment, which has strong data- and command-binding support. Similar to MVP, Views in MVVM also defer all business logic to the ViewModel. Communication between View and ViewModel is facilitated through a combination of Command Bindings and Events (behaviour-driven communication) and Data Binding (data-driven communication). In this pattern: M = Model, V = View and VM = ViewModel; where M is unaware of V and VM, V is aware of VM, and VM is aware of M.

Breakout Session :: 300 (Advanced) :: Developer Tools, Languages and Frameworks

“Coded UI tests allow developers to create fully-automated, functional UI tests which can be used to quickly alert a team about regressions. These are easy to create, but can become tricky to build in a robust manner which can sustain changes to your application over time. In this demo-rich session we will examine patterns and practices you can employ for building great coded UI tests.”

Highlights

• Using a combination of Visual Studio (Premium or Ultimate), Feature Pack 2 (from MSDN subscription), C# or VB, and (optionally) Microsoft Test Manager, coded UI tests can be used to run functional regression tests manually (from VS or TM) or as part of an automated build process.
• Tests are created by recording actions from within Visual Studio, or using an existing action recording from Test Manager.
• The UI Map Designer serves as a mapping between the test code and application UI, and allows editing of test methods, control search- and filter properties, etc.
• Extended functionality includes the ability to add validation with test builder by inspecting control properties, data-binding tests to a database, CSV file or XML file (where test will run for every row in the data), etc.
• Tip: To record validation inspections, a test can be automated into a specific state by running the previously recorded test up until the point of validation.
• The TestContext object is used to access test data, add result files, etc.
• Test results can be published to TFS and attached to a new work item.

Links

• Brian Keller
• TestApi – a library of Test APIs
• Walkthrough: Using multiple Coded UI maps in test automation
• CUITe (Coded UI Test enhanced) Framework
• Configuring Playback in Visual Studio 2010
• Description of the Windows Automation API
• Using Coded UI Tests in Load Tests

Further Reading

• Lab Management
• Hyper-V
• “How we test software at Microsoft”
• Book: Professional Application Lifecycle Management with Visual Studio 2010
• Book: Professional Team Foundation Server 2010

Breakout Session :: 200 (Intermediate) :: Developer Practices

“The popularity of agile software development processes and methodologies is imminent and fast growing. Many organizations and projects turn towards agile to help solve the problems of traditional software development. Scrum, extreme programming, test driven development, and lean are no longer the new kids on the block. However, with the rising popularity of agile, mainly due to lack of experience or management over-expecting results, in coming years many agile projects will fail miserably. Agile is not the silver bullet.”

Video

Highlights

List of Anti-Patterns:

1. Traditional approaches are evil
2. Velocity is unimportant
3. Senior guy estimates the work
4. Open plan office and cubicles
5. Missing product owner
6. Mini waterfall
7. Change iteration length
8. Changing requirements intra-sprint
9. Task boards are old school
10. Documenting everything perfectly
11. Pick the low hanging fruit
]]> http://pj.lightfoot.cc/2011/10/agile-anti-patterns/feed/ 0 http://pj.lightfoot.cc/2011/10/what-code-db-gap-introducing-project-juneau/ http://pj.lightfoot.cc/2011/10/what-code-db-gap-introducing-project-juneau/#comments Tue, 18 Oct 2011 20:32:01 +0000 Peter-John http://pj.lightfoot.cc/?p=306 Continue reading →]]> Info

Breakout Session :: 300 (Advanced) :: Developer Tools, Languages and Frameworks

“Project Juneau is a new toolset being release with Project Denali which provides a rich database design and editing environment directly within Visual Studio. Some of the features include rich versioning of databases, dependency checks, rich intelligence, debugging support and database refactoring tools. Join William as he guides you through a few of his favourite offerings coming from Juneau.”

Highlights

Project Juneau addresses these major pain points (among many others):

• Database versioning
• Database dependency management
• Production drift

This is one talk I’m not even going to attempt to summarize, as even the talk itself was a summary of but a small subset of features introduced by Juneau. I’ll simply list those here, along with the clearly stated goal of Project Juneau, which is to enhance the continuous, integrated development experience between database and code (which is to say that these and many other “SQL-like” features are being brought forward into Visual Studio by this toolset:

• SQL Explorer
• Intellisense
• Column Tooltips
• Table Designer / Script / Model Diagram (all synchronized based on customizable user settings)
• Preview Database Changes (warnings, highlights, user actions)
• SQL/CLR
• T-SQL Debugging with Step Through, Watch Variables, etc.
• Local Database Runtime with VS Integration, Schema-based Files
• Schema Compare with Visual Diff
• Refactoring (Expand Wildcards, Rename, etc.) and other “Managed Code”-like features (“Go to Definition”, etc.)
• Compile-time Validation of Schemas
• Database Publishing (target platform aware, with Direct / Script / DAC modes)

Data can be managed through Pre- and/or Post-Deployment Scripts.

TechEd 2011 Slide Decks

]]> http://pj.lightfoot.cc/2011/10/what-code-db-gap-introducing-project-juneau/feed/ 0 http://pj.lightfoot.cc/2011/10/javascript-jquery-and-ajax-patterns/ http://pj.lightfoot.cc/2011/10/javascript-jquery-and-ajax-patterns/#comments Tue, 18 Oct 2011 20:14:29 +0000 Peter-John http://pj.lightfoot.cc/?p=302 Continue reading →]]> Info

Whiteboard :: 300 (Advanced) :: Developer Tools, Languages and Frameworks

“Do you get lost in your client side code? Do you find debugging client side JavaScript painful? Is working with JavaScript ‘fiddly and annoying’? If you answer ‘yes’ to any of these questions then this is stuff you want to hear. In this talk we take on a hands on approach to some of the more useful tips ‘n tricks and patterns when working with JavaScript. The examples have been drawn from real issues hit during development so they are practical solutions to real problems we’ve hit. Find out more about ways to make working with JavaScript easier in the team, useful patterns in talking to the server, debugging tips and tricks, code layout, fetching data from the server, posting data to the server.”

Highlights

Some best practices outlined in this session include (see the accompanying code snippets):

• JavaScript Encapsulation
• One-to-one mapping between UI and .js (e.g. Index.aspx and Index.js with function Index() { ... }

• JS Outlining (see link)
• Use a JS and CSS minifier
• Don’t overuse JSON post back patterns

UI Code

1 2 3 4 5 6 7 8 9

<script> var x = new Index(); x.PathToUrl = "http://mysite"; x.Load(); </script>   <!-- snip -->   <button id="SaveButton"/>

JS Code

1 2 3 4 5 6 7 8 9 10

function Index() { PathToUrl = ""; Form = null;   this.Load() { $("#SaveButton").click = this.Save(); }   this.Save() { ... } }

Links

• Visual Studio 2010 JavaScript and CSS Outlining
]]> http://pj.lightfoot.cc/2011/10/javascript-jquery-and-ajax-patterns/feed/ 0