Story Boads with Windows 8 Elements

I found this as useful for storyboards as follows

Remove Windows 8 Wireless networks

Run 

explorer.exe shell:::{1fa9085f-25a2-489b-85d4-86326eedcd87}

you can retrieve manage wireless networks UI

WCF Web API vs ASP.net Web API

WCF Web API is now ASP.NET Web API!

We are happy to announce that ASP.NET Web API has now shipped withASP.NET MVC 4 Beta!
ASP.NET Web API represents the joint efforts of the WCF and ASP.NET teams to create an integrated web API framework. You canget the bits and find articles, tutorials, samples and videos on the newASP.NET Web API home page. We have also setup aWeb API forum on the ASP.NET site where we will monitor customer questions and discussions.
Some history
For several years now the WCF team has been working on adding support for REST. This resulted in several flavors of REST support in WCF: WCF WebHTTP, WCF REST Starter Kit, and then finally WCF Web API. In parallel the ASP.NET MVC team shipped support for building basic web APIs by returning JSON data from a controller. Having multiple ways to do REST at Microsoft was confusing and forced our customers to choose between two partial solutions. So, several months ago the WCF and ASP.NET teams were merged together and tasked with creating a single integrated web API framework. The result is ASP.NET Web API.
What is ASP.NET Web API?
ASP.NET Web API is a framework for building and consuming HTTP services that can reach a broad range of clients including browsers and mobile devices. It’s also a great platform for building RESTful services. ASP.NET Web API takes the best features from WCF Web API and merges them with the best features from MVC.
The integrated stack supports the following features:

• Modern HTTP programming model
• Full support for ASP.NET Routing
• Content negotiation and custom formatters
• Model binding and validation
• Filters
• Query composition
• Easy to unit test
• Improved Inversion of Control (IoC) via DependencyResolver
• Code-based configuration
• Self-host

What does this mean for WCF Web API?
ASP.NET Web API is effectively the next version of WCF Web API. There will not be a separate release for WCF Web API and we will retire all WCF Web API content by the end of the year. Please post all future discussions to the newASP.NET Web API forum.
Why change the name?
Web APIs have a foot in two worlds: the world of service orientation and the World Wide Web. We decided to align ASP.NET Web API with the rest of the Microsoft web platform, so we went with the brand that communicates this alignment. From a technical perspective we also decided to go with a new HTTP specific dispatcher instead of trying to carry forward the WCF dispatcher, so there is virtually no WCF code in the new stack.
Does this mean I have to host my web APIs in IIS?
You can continue to self-host your web APIs in your own processes just like you could with WCF. ASP.NET Web API is at its core a light-weightHTTP message handler pipeline that is host independent. Our current self-host support is actually based on the WCF HTTP transport, but you can host ASP.NET Web API on any HTTP host of your choosing.
How do I migrate to my WCF Web API code to ASP.NET Web API?
We have started putting together some migration guidance here and we will flesh out the guidance in the upcoming weeks.
Is ASP.NET Web API on NuGet?
Yes, you can find our new NuGet Packages here:

• ASP.NET Web API (Beta)
• ASP.NET Web API Self Host (Beta)

Will ASP.NET Web API support a test client and help page generation?
For the ASP.NET Web API Beta we focused on getting the right framework runtime in place. Unfortunately, this meant that we weren’t able to get the test client and help page support ported onto the new stack in time for Beta. We are working on these features and we expect to ship them before the final ASP.NET Web API release.
Will the source code be made available?
We will publish the source code in the upcoming weeks.
Thank you for your support and please let us know if you have any questions or concerns!


Extracted from - http://wcf.codeplex.com/wikipage?title=WCF%20Web%20API%20is%20now%20ASP.NET%20Web%20API

10 Best Practices for Mobilizing Enterprise Applications

1. Start small, with just two or three key applications.
2. Design for short attention spans.
3. Take full advantage of the mobile device, including the GPS, the phone and the camera.
4. Leverage back-end data properly--use APIs instead of connecting to databases directly.
5. Personalize the user experience.
6. Use a native look and feel.
7. Remember that legacy applications are not obsolete.
8. Run beta testing before you roll it out to everyone.
9. Keep it simple.
10. Keep up with the technology.

Monetizing Windows Phone Apps

Discover the various ways that a Windows Phone application can be monetized. More importantly, learn the situations where the various monetization strategies work best as well as understand where monetization approaches for Windows Phone might differ from phone applications on other platforms.
Extracted From - http://resources.devx.com/MS/mobilephone/Article/47597

Agile Project Management in Visual Studio ALM V.Next

When we first started designing Team Foundation Server, one of our mantras was “Your process, our process or no process”.  What we meant by this was that TFS can play an important role in helping you automate your development process.  Many teams already have a well establish process and aren’t particularly interested in changing it.  TFS can be configured to fit with your process – whatever it is.  Many teams don’t have a well established process and would like to adopt some “best practices” and then evolve them – TFS can do that to, and we provide 3 process templates today you can adopt (Agile, Scrum and CMMI).  And some teams are less structured and pretty skeptical of the “P-word”.  They just want some good tools to help them get their job done and TFS can help there too.

In parallel to the evolution of TFS, the world of software development process has matured a great deal.  There’s way more energy and debate around process now than there was 10 years ago – and there are some emerging and established “winners”.  It’s clear that the Agile family of development practices have become very well established now.  Some of the practices that were highly touted in the early days of Agile (like pair programming) have drifted into niche practices and some (like unit testing) have become table stakes that almost every high performing development team has adopted.

We did some work in 2005 (unit testing, for example), 2008 (continuous integration) and 2010 (Agile workbooks, Scrum template, etc) that enabled teams to use TFS to automate their Agile practices.  However, we resisted building very tuned experiences because we were hanging a bit too tightly to process independence (remember – Your process, our process or no process.

As we began our planning for V.Next, it was clear that Agile had become mainstream (I have survey data that says 35% of development teams practice "Agile”).  And new processes are in the offing – Lean continues to gain momentum.  And, in fact, I see lots of people trying to combine the best of Lean and Agile together.  With the growing adoption of a well defined set of processes/practices, we decided that it was time for TFS to invest more in experiences optimized for those practices.  We still hold on to Your process, our process or no process but now we will build tooling optimized for well established practices.

One of the areas we chose to focus on was Scrum based tooling.  I have survey data that says about 84% of teams that say they practice Agile, practice Scrum as part of that.  That makes Scrum the most adopted Agile practice.  Here’s a chart that shows the adoption of methodologies by Agile teams:

Ironically, at the same time we were discussing this, we were deciding to adopt Scrum for our own feature team level development.  We use more of a Microsoft practice for rolling that up through the organization.  This was serendipitous because it would provide us a great opportunity to dogfood the tools and ensure we were building something our customers would love.

Very early we decided to focus on a web based experience for our Agile project management tooling.  A browser based solution makes the experience widely available to everyone on the team.  At the same time, we felt projecting some of this directly into the Visual Studio and Eclipse development environments was also important.

We broke down the basic Scrum project management cycle into the 3 highest priority activities:

• Backlog management – collecting the list user stories (requirements) and prioritizing them.  The backlog is one of the central theories in Scrum.
• Sprint planning – choosing a set of user stories to implement in a sprint based on their estimated cost (story points) and the team’s capacity (velocity).
• Daily stand-up – reviewing the newly completed work, work in progress and newly started work along with any impediments.

We also considered a few other things (like retrospectives, etc) but, after discussing it with many customers and Scrum professionals, concluded that the 3 I listed above were the key areas where new tooling would help the most and that other things could work fine with tooling we already have.

For each of these experiences, we wanted to create a solution that was incredibly easy to use and low overhead – work the way I do and stay out of my way.  We also recognized that if we were going to rely on our web experience this deeply we were going to have some significant work to do.  We wanted to modernize the overall look and feel – we adopted the “Metro” style from Zune/Windows Phone.  We also needed to really work on performance.  Web access, in 2010, relied too heavily on server round trips for user interactions.  We wanted an experience that not only used Java Script to keep the vast majority of processing local, we wanted to make most places where server round trips are necessary (like saving a work item) asynchronous.

As we started to adopt Scrum ourselves and design our Scrum solution, it quickly became clear that we were going to need to introduce the concept of “Team”.  Each of our feature teams have their own backlogs, sprints, etc.  We needed a way to identify the teams, easily select them, define properties for them, report on them, etc.  As such, for V.Next, team has evolved into one of our central elements of our web UI.  You select what project and what team you are working on and then much of the data in the UI is filtered to show you exactly what is relevant for you.

Extracted From : http://blogs.msdn.com/b/bharry/archive/2011/06/14/agile-project-management-in-visual-studio-alm-v-next.aspx

What's New in the Visual Studio Team Foundation Server 11

This post provides an overview of most (but I don't promise ALL!) of the new tools, features, and enhancements available in the Visual Studio Team Foundation Server 11 Developer Preview:

• New Look and Feel for both Team Web Access and Team Explorer
• Agile Project Management
• Agile Requirements Management
• Developing Code and Using Team Explorer
• Version Control: Workspace Improvements, Merge Enhancements, Pending Changes
• Build Definitions, Build Process, and Gated Check-ins
• Work Item Tracking and Alerts
• Administering Team Foundation Server

For a tutorial that illustrates several of these new features by following a fictitious team as they incrementally adopt Visual Studio as its solution for application lifecycle management (ALM), see Adopting Team Foundation and Visual Studio for Application Lifecycle Management.

Extracted From : - http://blogs.msdn.com/b/visualstudioalm/archive/2011/09/20/visual-studio-team-foundation-server-11-developer-preview-what-s-new-for-team-foundation-server.aspx