Book Review: 70-502 Training Kit by MS Press

This is a book review on MCTS Self-Paced Training Kit (Exam 70-502: Microsoft .NET Framework 3.5 Windows Presentation Foundation. The author reveals the information set out in each chapter and how using this book will help prepare the reader for the test required to obtain the MCTS certification on WPF.

Source Click Here.

Locking the Screen During a Postback

In a perfect world all web applications would be snappy and responsive, and there would be no such thing as lengthy postback waits. But in the real world there are plenty of scenarios that take seconds to complete. For example, when a user visits a travel booking site like Expedia and enters his origination and destination information, it's not unusual for it to take several seconds before the search results appear. Similarly, I've worked on applications where clicking a button dynamically generated and e-mailed a large PDF file, or that have needed to query a very slow database located in corporate offices halfway around the world. In such cases it was not uncommon for the user to have to wait several seconds between submitting the form and getting a response from the web server.

While browsers provide some feedback to the user that the form has been submitted and a response is forthcoming, these visual cues are usually in the margins of the browser and still allow the user to interact with the page, re-click the button, or interact with some other user interface element on the page. Most travel sites send the user to a "Please Wait While We Process Your Results..."-type page when they submit their query. This does two things: it provides the user with visual feedback that their submission was accepted, and it prohibits them from re-submitting their search query twice.

You can mimic "Please Wait While We Process Your Results..." functionality in a single page with a bit of JavaScript and CSS that locks the screen upon a particular client-side action (typically a form submission), displaying a message and prohibiting the user from interacting with the web page. This article shows how to inject such functionality into an ASP.NET web page. Read on to learn more!
Read More >

Source Click Here.

Tip #35: Did you know.How to add Intellisense from script libraries for JS files?

Here is an example to add intellisense for JS files in VS 2008.

So, you have two Javascript files

Jscript1.js with the following code

function validateForm() {
}

and Jscript2.js (wherein you want current JScript file to show intellisense including objects & functions declared in Jscript1.js)

Now to add intellisense, from the solution explorer drag drop Jscript1.js into Jscript2.js.

You will notice that the following Jscript document comment has been added to the Jscript2.js file.

/// <reference path="JScript1.js" />

And now you can start using the intellisense, try typing in validateForm in Jscript2.js.

Thanks,
Deepak Verma
SDET | Visual Web Developer

Source Click Here.

How my team does agile

As you know, I'm a big fan of agile software development. But what exactly does "agile" mean? If you ask a room full of software engineers that question, you're sure to get as many different answers as there are people. I'm not going to try to tell you what agile is, or what it should be - but a lot of people ask me how our team goes about implementing agile. We don't practice any particular official brand of agile - like most good teams we've combined all of our past experiences to come up with something that works well for our project and team. So I'm definitely not claiming that this is the "right" way to do agile or that it will work for your team. However I'm also not going to accept any arguments that what we're doing is "wrong" (since it works very well for us) - although constructive suggestions are always welcome!

To provide a bit of context, I'm working with a dedicated software engineering team that is part of Microsoft's Solutions Development Centre in Sydney. We have been building a large new system for an external customer for the last 12 months or so. It's largely a greenfield project, but there are a handful of external systems we need to integrate with. The application is in a new business area for the customer so their requirements have been evolving constantly, especially after development began. The project team consists of 2 project managers, 1 solution architect (me), 5-9 developers (the numbers have changed a bit over time), 4-7 testers, a build manager, a release manager (just for the last third of the project), and part-time SMEs focusing on infrastructure, security and database. We also have a full-time product manager from the customer, and around 3 other customer representatives that spend at least a day a week with our team.

The project began with an end-to-end analysis and estimation phase, which lasted a couple of months. While this does not fit in with many people's idea of agile, I believe it's a necessary step for commercial projects (and probably worthwhile even for internal projects). The goal of this period was to get as good an understanding as possible of the business requirements (as they were understood at the time) in a relatively compressed time period. During this period the team produced UI wireframes, flowcharts and very high level requirements and design diagrams. Doing this estimation allowed us to provide a reasonably good estimate of the schedule and budget for the overall project (even with the full awareness that many, many things would change throughout the project). It also helped us identify the most important and most risky areas so we could schedule them in the most appropriate iterations.

Once the estimation phase was out of the way we started our development iterations. We settled on 4 week iterations, involving 3 weeks of development and one week of stabilisation. Here's how we tend to approach each iteration:

• During the second half of the previous iteration, the project managers, architect and customer start planning what requirements should be candidates for the next iteration. For a large project like ours, strict stack-ranking of requirements or stories was not found to be practical. Instead we broke the project into larger "modules" of functionality that each fit roughly into a development iteration and prioritised those. This allows each iteration to have a single theme and vision for the entire team to focus on. Within each module we will prioritise the requirements to ensure we work on the most important features first, and often it will turn out that we don't get time to complete the bottom-ranked requirements (although they may still be resurrected in future iterations). We also find that new, related requirements tend to emerge as we begin development. As long as they are higher priority than other candidates, we try schedule them for the current iteration.
• As the architect, I will spend time in the last week of the previous iteration looking through the candidate requirements for the next iteration and come up with a high-level design. This normally involves a first-cut at a data model, 5-10 pages of documentation (usually with lots of pictures!) and often a "spike" or prototype. The project and product managers will also spend time updating or creating UI wireframes and clarifying the requirements stored in Team Foundation Server. The design documents and wireframes produced during this time are never final, but having a documented starting point has proven to help the development team get on the same page quickly and hit the ground running when the iteration begins.
• On the first day of the new iteration, the entire team gets together to discuss the proposed requirements in detail. This will typically involve reviewing the UI wireframes and design documents on a projector as well as less formal whiteboard discussions. This is also the time when the development team loves to point out problems in my design and how they intend on fixing them :-). Once everyone has a good understanding of the requirements, we'll start assigning work to the developers. For a while we tried variations of "planning poker", but we found it rather time consuming and not overly helpful. So we've settled on a simpler system where developers will volunteer for requirements until they believe they have at least a week's worth of work. They will then go away and break it into finer-grained tasks with estimates. We found that 3 weeks of development is too long to plan for in one go, so we do small planning sessions at the start of the next two development weeks where we "top up" any developers who have less than a week's worth of work with new requirements. In essence, the development phase of each iteration is broken up into three one-week mini-iterations all with a consistent theme.
• We don't have any official design period within the iteration, but for the first couple of days the developers will usually spend a lot of time at whiteboards figuring out how best to approach their requirements, with actual development ramping up quickly after that. As soon as a developer (or sometimes several developers) is finished with a requirement, it is marked in TFS as "ready for test".
• Testing obviously goes on throughout the iteration, but for the first week the testers typically focus on analysing the requirements and writing test cases. By the second week things are usually in full swing, with the testers developing automated test cases as well as performing manual testing. Any bugs that are discovered are logged in TFS. Bugs are considered "blocking" if they preclude the requirement from being effectively tested, but lower priority "non-blocking" bugs are logged too. Any requirements without blocking bugs are marked as "tested".
• The product manager (who represents the customer to our team) gets the final say on whether a requirement is complete. They will go through each of the "tested" requirements and confirm that it meets their needs. If it does, the requirement will be closed. If not, they may raise bugs (if it is not implemented as requested) or new requirements (which generally means "that's what I asked for, but not what I want" :-).
• At the end of the third week we hit our "code complete" milestone for the iteration. This doesn't mean all candidate requirements were completed (in fact we try to have more candidates than we can complete), but it means we have completed all of the highest priority requirements in the time available.
• The final week is for stabilisation. This means the developers will not start any new requirements, and will work solely on fixing bugs. In order to prevent the bug count from getting unmanageable by the stabilisation week, we also impose a "bug cap" on each developer during the development weeks - once a developer's personal bug cap exceeds this value they will need to temporarily stop work on new features to fix bugs. However even with the bug cap in place, there are always enough bugs to keep the team busy for the last week. Testing continues during the stabilisation week as well (in fact it's usually the busiest week in the iteration for the testers). To be completely sure we don't run out of bugs, we also schedule a "bug bash" event at the start of the stabilisation week. This involves the extended team (usually involving people from the customer who are not normally involved with our team day-to-day) spending an hour playing with the application with a goal to discover as many bugs as possible. To make this fun we put on food and drinks, and hand out prizes for the most bugs, the most severe bug and the most obscure bug.
• At the end of the fourth week, the iteration comes to an end. We strive to exit each iteration with zero P1 and P2 bugs, and an agreed limit to the number of P3 and P4 bugs. This effectively means that everything we have built in that iteration is complete and stable and ready to be deployed. That said, for this project we don't actually deploy the application to real users after each iteration. As we get ready for our final release there will be a "final stabilisation" iteration, as well as a number of processes that can only be completed at the time of the final release such as end-to-end security and performance tests, deployment and failover testing.

Hopefully this gives you an idea of the rhythm of our iterations. However we also have a daily rhythm within our team room:

• At 9am we have our daily stand-up meeting. We're lucky enough to have our entire team working in the same location, so this doesn't involve any fancy technology like conference calls. The goal of the stand-up meeting is to make sure everybody knows what's going on in the team. Each team member gets up to 2 minutes to describe what they did yesterday, what they are going to do today, and what impediments (if any) they might have.
• After the stand-up everyone starts work - although it's normally quite a noisy affair (well it is when I'm involved!). We have our own dedicated team room so we can make as much noise as we like, and we encourage face-to-face collaboration on problems as much as possible. Many times a day, someone will raise interesting and difficult questions that may require the customer to clarify requirements, project managers to reprioritise or modify requirements and plans, and surprise changes to the design and test cases.
• We encourage our developers to check in at least once a day to prevent painful integration and long periods where the testers can't make progress. Before anyone in the team can check in (yes, me included!) they must go through a code review and a test review. Any developer or tester can perform these roles for anyone else, and we encourage as many combinations as possible. For the code review, the reviewer and the reviewee will share a computer and go through each of the changed code files and discuss the changes. The reviewer has the right to veto the check-in if they find problems, which can include inadequate unit test coverage. The test review is much the same but normally involves running the application through whatever obscure scenarios the tester can think of to see if it holds up. Once both the code and test reviewer are happy, the developer can check in.
• We run a continuous integration build after each check-in, where the application will be compiled and all of the unit tests run on the build server. If the build breaks, noisy sirens will alert everyone in the team to the problem, and whoever caused the problem needs to fix it immediately as everyone else is blocked from checking in. A good CI build will result in a much more cheerful "Yippee!" sound.
• At 4pm we do our daily bug triage. This involves the test lead, one of the project managers, the customer product manager and the architect (me). We will go through each of the bugs raised in the last 24 hours, debate its priority, decide if and when it needs to be fixed, and (if it's not closed) assign it to the most appropriate developer to fix.
• Also at 4pm we commence our daily build. In addition to compiling the code and running the unit tests, this involves deploying the application to our test server and running a suite of automated Build Verification Tests. Again, if any of this fails, the appropriate people need to down tools and get it all fixed.
• Once the build is declared "good", we will start our nightly run of automated test cases. The next morning the testers will analyse the results of the previous night's run and raise bugs for any regressions, or sometimes update the automated tests to deal with failures caused by changing requirements.

I hope this gives you some insight into one way of using agile methods to deliver a complex project. As I mentioned at the start of the post, this isn't textbook agile, and we've needed to constantly evolve our process to address various challenges and to suit the personalities and experiences of our team. However I'm very happy to say that this is the most passionate, energetic and productive team I've ever worked with, and despite the fact that the requirements continue to evolve at what often seems like a frightening pace, we've continued to hit all of our milestones and targets. So I hope some of this will be of use to your team as well, and of course I'd love to hear about what you do differently in your team and how it's working out for you.

Source Click Here.

Redirect Routes and other Fun With Routing And Lambdas

ASP.NET Routing is useful in many situations beyond ASP.NET MVC. For example, I often need to run a tiny bit of custom code in response to a specific request URL. Let's look at how routing can help.

First, let's do a quick review. When you define a route, you specify an instance of IRouteHandler associated with the route which is given a chance to figure out what to do when that route matches the request. This step is typically hidden from most developers who use the various extension methods such as MapRoute.

Once the route handler makes that decision, it returns an instance of IHttpHandler which ultimately processes the request.

There are many situations in which I just have a tiny bit of code I want to run and I'd rather not have to create both a custom route handler and http handler class.

So I started experimenting with some base handlers that would allow me to pass around delegates.

Warning: the code you are about to see may cause permanent blindness. This was done for fun and I'm not advocating you use the code as-is.

It works, but the readability of all these lambda expressions may cause confusion and insanity.

One common case I need to handle is permanently redirecting a set of URLs to another set of URLs. I wrote a simple extension method of RouteCollection to do just that. In my Global.asax.cs file I can write this:

routes.RedirectPermanently("home/{foo}.aspx", "~/home/{foo}");

This will permanently redirect all requests within the home directory containing the .aspx extension to the same URL without the extension. That'll come in pretty handy for my blog in the future.

When you define a route, you have to specify an instance of IRouteHandler which handles matching requests. That instance in turn returns an IHttpHandler which ultimately handles the request. Let's look at the simple implementation of this RedirectPermanently method.

public static Route RedirectPermanently(this RouteCollection routes,       string url, string targetUrl) {    Route route = new Route(url, new RedirectRouteHandler(targetUrl, true));    routes.Add(route);    return route;  }

Notice that we simply create a route using the RedirectRouteHandler. As we'll see, I didn't even need to do this, but it helped make the code a bit more readable. To make heads or tails of this, we need to look at that handler. Warning: Some funky looking code ahead!

public class RedirectRouteHandler : DelegateRouteHandler {    public RedirectRouteHandler(string targetUrl) : this(targetUrl, false) {     }      public RedirectRouteHandler(string targetUrl, bool permanently)      : base(requestContext => {        if (targetUrl.StartsWith("~/")) {          string virtualPath = targetUrl.Substring(2);          Route route = new Route(virtualPath, null);          var vpd = route.GetVirtualPath(requestContext,             requestContext.RouteData.Values);          if (vpd != null) {            targetUrl = "~/" + vpd.VirtualPath;          }        }        return new DelegateHttpHandler(httpContext =>           Redirect(httpContext, targetUrl, permanently), false);      }) {      TargetUrl = targetUrl;    }      private void Redirect(HttpContext context, string url, bool permanent) {      if (permanent) {        context.Response.Status = "301 Moved Permanently";        context.Response.StatusCode = 301;        context.Response.AddHeader("Location", url);      }      else {        context.Response.Redirect(url, false);      }    }      public string TargetUrl { get; private set; }  }

I bolded a portion of the code within the constructor. The bolded portion is a delegate (via a lambda expression) being passed to the base constructor. Rather than creating a custom IHttpHandler class, I am telling the base class what code I would want that http handler (if I had written one) to execute in order to process the request. I pass that code as a lambda expression to the base class.

I think in a production system, I'd probably manually implement RedirectRouteHandler. But while I'm having fun, let's take it further.

Let's look at the DelegateRouteHandler to understand this better.

public class DelegateRouteHandler : IRouteHandler {    public DelegateRouteHandler(Func<RequestContext, IHttpHandler> action) {      HttpHandlerAction = action;    }      public Func<RequestContext, IHttpHandler> HttpHandlerAction {      get;      private set;    }      public IHttpHandler GetHttpHandler(RequestContext requestContext) {      var action = HttpHandlerAction;      if (action == null) {        throw new InvalidOperationException("No action specified");      }            return action(requestContext);    }  }

Notice that the first constructor argument is a Func<RequestContext, IHttpHandler>. This is effectively the contract for an IRouteHandler. This alleviates the need to write new IRouteHandler classes, because we can instead just create an instance of DelegateRouteHandler directly passing in the code we would have put in the custom IRouteHandler implementation. Again, in this implementation, to make things clearer, I inherited from DelegateRouteHandler rather than instantiating it directly. To do that would have sent me to the 7^th level of Hades immediately. As it stands, I'm only on the 4^th level for what I've shown here.

The last thing we need to look at is the DelegateHttpHandler.

public class DelegateHttpHandler : IHttpHandler {      public DelegateHttpHandler(Action<HttpContext> action, bool isReusable) {      IsReusable = isReusable;      HttpHandlerAction = action;    }      public bool IsReusable {      get;      private set;    }      public Action<HttpContext> HttpHandlerAction {      get;      private set;    }      public void ProcessRequest(HttpContext context) {      var action = HttpHandlerAction;      if (action != null) {      action(context);      }    }  }

Again, you simply pass this class an Action<HttpContext> within the constructor which fulfills the contract for IHttpHandler.

The point of all this is to show that when you have interfaces with a single methods, they can often be transformed into a delegate by writing a helper implementation of that interface which accepts delegates that fulfill the same contract, or at least are close enough.

This would allow me to quickly hack up a new route handler without adding two new classes to my project. Of course, the syntax to do so is prohibitively dense that for the sake of those who have to read the code, I'd probably recommend just writing the new classes.

In any case, however you implement it, the Redirect and RedirectPermanent extension methods for handling routes is still quite useful.

Technorati Tags: aspnetmvc,routing

Source Click Here.

Always run WPF App in Maximized View

I have been playing around with WPF Applications and one of the annoying things about WPF as well as Windows Forms is that they always open up in a Normal View (which is like a Restored View) and you have to maximize it to have a full view of your application. I know this is a simple setting right from the VB Days and was wondering where to set it up in case of WPF.

The solution was to just to add the following line of code under the "InitializeComponent()" call in your Window1.xaml.cs or whatever is the startup Window.

      InitializeComponent();

      this.WindowState = WindowState.Maximized;

I am sure there are different ways to achieve this and it can be set at the configuration level etc., But this post is just for simply doing it quickly.  

If there are caveats, best practices, please post in the comments..

Cheers !!!

Source Click Here.

Boris Johnson's Wiff Waff

One of the most amusing quotes of 2008 must be this: At a party to mark the handover of the Olympic flag in Beijing, newly elected Mayor Boris Johnson laid claim to Britain's sporting inventiveness.

One of the most amusing quotes of 2008 must be this: At a party to mark the handover of the Olympic flag in Beijing, newly elected Mayor Boris Johnson laid claim to Britain’s sporting inventiveness.

Virtually every single one of our international sports were invented or codified by the British. And I say this respectfully to our Chinese hosts, who have excelled so magnificently at Ping-pong. Ping-pong was invented on the dining tables of England in the 19th century, and it was called Wiff-waff! And there, I think, you have the difference between us and the rest of the world. Other nations, the French, looked at a dining table and saw an opportunity to have dinner; we looked at it an saw an opportunity to play Wiff-waff. And I say to the Chinese, and to the world, that Ping-pong is coming home!

Source Click Here.