Microsoft releases free Visual Studio Code and Visual Studio 2015 RC | Ars Technica

Microsoft releases free Visual Studio Code and Visual Studio 2015 RC | Ars Technica:



'via Blog this'

Catching Performance Issues in Development

Catching Performance Issues in Development:



'via Blog this'

Sessions in ASP.NET 5

Sessions in ASP.NET 5:



'via Blog this'

Here's the surprising way Amazon decides what new enterprise products to work on next - Business Insider

Here's the surprising way Amazon decides what new enterprise products to work on next - Business Insider:



'via Blog this'

MSDN Blogs

MSDN Blogs:



'via Blog this'

Full Stack JavaScript Development With MEAN

Full Stack JavaScript Development With MEAN:



'via Blog this'

Full Stack JavaScript Development With MEAN

Full Stack JavaScript Development With MEAN:



'via Blog this'

The Languages And Frameworks That You Should Learn In 2015 | Tutorialzine

The Languages And Frameworks That You Should Learn In 2015 | Tutorialzine:



'via Blog this'

The first 5 online resources to use when learning to code

The first 5 online resources to use when learning to code:



'via Blog this'

A new look for .NET Reference Source - .NET Blog - Site Home - MSDN Blogs

A new look for .NET Reference Source - .NET Blog - Site Home - MSDN Blogs:



'via Blog this'

.NET Technology Guidance | Microsoft .NET Framework

.NET Technology Guidance | Microsoft .NET Framework:



'via Blog this'

WebApi C# Proxy Generator - NuGet Must Haves

WebApi C# Proxy Generator - NuGet Must Haves:





https://github.com/faniereynders/WebApiProxy/wiki/WebApi-C%23-Proxy-Generator

https://github.com/faniereynders/WebApiProxy/wiki/WebApi-Proxy-Provider



'via Blog this'

10 things to know about KnockoutJS on day one - Knock Me Out

10 things to know about KnockoutJS on day one - Knock Me Out:

'via Blog this'

5: Implementing the MVVM Pattern

5: Implementing the MVVM Pattern:

'via Blog this'

The ASP.NET developer checklist

The ASP.NET developer checklist:
In the beginning of January, we released the Web Developer Checklist with great interest from the general web community. The checklist helps raising awareness of common best practices for building websites.
It was always the plan to branch the checklist out into technology specific checklists to make it even easier to apply all the best practices.
Today we’re excited to announce the first technology specific checklist – the ASP.NET Developer Checklist. It contains links to many ASP.NET specific tools and solutions to common problems.
Not only is it a great tool for all ASP.NET developers to learn from, but also to track the progress of implementing the various best practices.
We hope it will be received well and add value to the millions of ASP.NET developers worldwide. In the meantime we will be working on finishing another ASP.NET specific checklist that focuses on website performance.
ASP.NET is just the first of many web technologies to receive its own checklist, so remember to check the Web Developer Checklist often for updates.
* $4.95/month ASP.NET Hosting with FREE SQL 2012 DB! – Click Here!

10 Reasons Why You’re Failing to Realize Your Potential as a Developer

10 Reasons Why You’re Failing to Realize Your Potential as a Developer:
Since going full-time on my own startup 6 months ago, I’ve spent a lot of my time recruiting, evaluating, and working with a lot of different developers. My startup, MarkedUp, is an analytics provider for Windows 8 apps (and eventually, other platforms.)
Our technology is sophisticated and difficult even for large companies to master, so the bar is pretty high for developers who join our team. We’re selective about who we work with, but even with careful recruiting practices it’s still difficult to find developers talented enough to pull their own weight on a complex product like ours.
So I want to help average developers who want to improve by calling out 10 performance-killing behaviors that stagnate the careers of most developers.
Most developers stagnate both intellectually and productively after 4-5 years in industry; they adopt some tools, pick up some patterns, learn a language or two, and maybe they’re even able to work at a successful company and contribute to some important products. Great!

But what happens when you hand a developer a blank sheet of paper and the opportunity for them to own a product?
Most of the time: chaos and failure.

Many developers fantasize about being able to own a product and make big technical decisions, but the truth of the matter is most of developers can’t handle anything more complicated than building formulaic CRUD Rails websites using the same 30 gems each and every time.
So what are the behaviors that limit the growth of average developers?

You’re too afraid of failure to learn new tools / languages / frameworks.

During my first quarter at Microsoft I gave a talk to the LA .NET User’s Group on ASP.NET MVC3, which was in beta at the time. For the most part the attendees asked me thoughtful questions and showed a legitimate interest in what the ASP.NET team was cooking up in Redmond.
However, there was a trio of attendees who kept asking me a very suspicious set of questions:
“What are the weaknesses of ASP.NET MVC3?”
“Isn’t ASP.NET MVC too unstable for use in the enterprise?”
“But doesn’t ASP.NET WebForms already do a better job?”
I realized shortly after the Q&A was finished, when I had a chance to speak to them privately, that they were attending my talk to actively look for reasons why ASP.NET MVC shouldn’t replace WebForms at their place of work!
These developers were so afraid of trying something new and possibly failing that they actually went out of their way to research just the talking points they needed to not have to learn it!
This is an extreme example, but the point is the same: average developers cling to their favorite tools and stop learning new ones because they worry that leaving their pet languages and tools behind invalidates their years of experience.
Strong developers embrace the challenge and opportunity to learn new ways of doing things.

You won’t push your commits until the feature is “done.” (It’s never done!)

We call this “commit hoarding” at MarkedUp. This happens with developers who don’t have the confidence to tolerate criticism or scrutiny from the rest of the development team try to hide their work until it’s in a “finished” state.
Ultimately these developers hurt the productivity of the rest of the team, because we lose visibility into their daily output and they tend not to ask for help in the course of regular development. They’re responsible both for delays in shipping and for lots of last-minute bugs.
Strong developers recognize that they are not their code, and thus will put code out in front of the rest of the team more frequently and take criticism and suggestions with dignity and confidence.

You know just enough to be dangerous.

In an age where it’s become a lot easier for developers to work with threads, concurrent programming, distributed databases, and so forth you run into a lot of devs who can talk a good game. They can tell you all about thread pools, a hot new design pattern, or why a headless database is better than a masterful one in some scenarios.
They are able to know what something is and its potential benefits, but they don’t understand it.
I’ll give you a recent example: in C# 5.0 Microsoft recently introduced the async and await keywords, which make it radically easier to create and manage asynchronous callbacks. These keywords have even lead to the rise of some exciting new concurrent programming patterns like the TAP pattern.
However, do you know what this keyword has also lead to? A ton of average developers who suddenly think they can harness the awesome power of multithreading simply by wrapping every I/O call into a Task object in C#. They do this blindly, without any thought as to the costs of context-switching, multi-thread access to shared resources, and more.
And this creates dangerous, unpredictable, and very-difficult-to-test code in the hands of average developers who blindly uses this new toy everywhere.
Good developers not only know what something does, but they seek to understand why it was done this way and under what conditions it should be used.

Analysis paralysis.

Sometimes you’ll hear a member of our development team say “dude, stop Gandalfing the documentation and start coding something,” referring to the scene from The Lord of the Rings depicted above.
Analysis paralysis is a classic problem that affects lots of average developers; it’s often a problem of over-analysis, but in my experience the root cause is usually fear of making a bad decision.
Research is easy – implementations are hard! As a developer, you don’t want to make a mistake when it comes time to do the actual work. So just research the issue until the heat death of the universe and you’ll make a perfect decision for which you won’t ever be criticized!
Average developers worry about looking bad or making a mistake – they want to get it right on the first try.
Strong developers who are in unfamiliar territory don’t care – they’ll write shit code, unit test it, and throw it away in 45 minutes if they don’t think it can get the job done. Strong developers actively limit the amount of time they spend researching, because they recognize that it’s a trap – it feels like work but often isn’t.

You don’t invest in your tools or development process.

Average developers will spend a lot of time learning how some fancy new language feature or API works. They’ll invest a ton of time mastering the minutia of the Windows runtime or some new D3-based charting framework, but at the end of the day that doesn’t change the fact that they’re still average developers who churn out mediocre work at a glacial pace.
If you want to be a talented developer, you have to invest time into improving your skills and knowledge, and the number one factor that separates the men from the boys in most software markets is the ability to turn out production-grade code quickly. You can have both good code and speed – but you have to invest in your process you use for building it first!
Average developers don’t invest in their tools, their process, or their environment.
Think about it – when was the last time you took a step back and thought about the way you test your code or how you look for bugs? Have you tried experimenting with different types of abstractions for the same problems and seen which one produces more maintainable code? Have you tried picking up a new IDE or text editor to see if it can help speed up common tasks? What about investing in build or deployment automation?
Often times, the biggest improvement you can get as a developer isn’t focusing on improving the code you write – it’s optimizing your process for writing it.
Free protip for anyone who follows my blog regularly: the biggest improvement I’ve made in my own development process easily is decreasing my usage of interface-driven design and dependency injection. I do a lot more work using static classes and compositions these days and it results in radically less code to test and maintain.

You’re too embarrassed to ask for help.

When we started digging into the guts of Hive for some of our work at MarkedUp, we got a little stuck on how to tackle some problems we had specific to our use case. So what did we do? We reached out to one of the guys who wrote the O’Reilly book on Hive and asked him over LinkedIn. And he replied back!
We try to be self-sufficient developers to the furthest extent possible, but we also know when it’s more economical to simply ask someone for a favor versus beating our heads against our desks for hours on end.
Average developers get embarrassed and don’t want to reveal their ignorance, so they pretend they know what’s up until they commit some sort of horrible fuck-up in the codebase itself.
There is nothing wrong with saying “I don’t know how to do this.” Strong developers know this, so they go and ask for help when they’re stuck.

You don’t know how to make it easy for other programmers to work with your code.

Like an only child growing up, you never learned how to share your toys with anyone else. The same goes for your code – you developed some bad habits and an over-abstracted style that is impossible for other developers to follow.
An important part of working on any technical team is human parallelism – the ability for multiple people to be able to work simultaneously on the same codebase. But it’s also important for teams to be able to work asynchronously too – I should be able to make changes to your code when you’re away, and vice versa.
Average developers don’t think about their code this way – they simply set out to do a task and write it through to completion with the assumption being that they will always own that piece of code. Strong developers understand technical debt and try to limit it by designing code that is as maintainable and self-explainable as possible.
Writing readable code really requires developers to change their outlook – your code should last longer in the organization that you.

You don’t know how to read someone else’s code (or don’t want to.)

It’s an interesting paradox – average developers can’t handle a blank sheet of paper very well, but they can’t write the last 30 pages of a novel in progress either. Average developers are really hesitant to try to learn an existing codebase and often have to be handled all the way through it until they’re able to produce something.
A drastic example is when an average developer is brought in on a codebase written in a language / framework that they aren’t familiar with and will immediately want to rewrite it without a second thought to business value or time to market. It’s a type of pain avoidance – having to live with the precipitation of some other programmer.
Strong developers accept that the business costs in a rewrite are usually unacceptable and should be avoided, and they’ll diligently try to understand, learn, and modify the existing codebase sitting in front of them.
Reading code is harder than writing code, but strong developers invest time into learning how to excel at it.

You can’t code from the end-user’s point of view (you think too small.)

Average developers who manage to make it a lot closer to the “great programmer” end of the bell curve usually trip up here. You may have mastered some of the technical details and you may know how to work with other developers, but you’re still missing the most important piece: being able to see your code from the point of view of the real-world.

As a programmer, you job isn’t really to solve technical problems – you solve technical problems in order to solve business problems.

An average-to-bad developer will chase technical problems down deep rabbit holes without remembering why they were solving the problem in the first place. You’re not upgrading the version of MongoDB you’re using because there’s inherent value in upgrading – you’re upgrading because your team agreed that it was worth taking the risk to upgrade because of potential business upside due to new features / performance / reliability / whatever.
More offensively, average developers struggle and fail to produce anything of business value from scratch. When asked to design a new feature based off of a simple customer story average developers will take a rigid, literal interpretation of the story or spec and ship something that is barely useable by a human.

Average developers don’t anticipate other related use cases; don’t think about the end-user’s experience; and basically have to be managed heavily when working on anything user-facing. This is why so many of them get stuck writing line of business apps instead of products.

Great developers look at their code from the perspective of the end-user. How do I make this easier to solve my user’s problem? What are some other facets outside the literal content of the story that might make this feature even better for an end user?
If you’re a developer and don’t ask yourself these questions, then you’re not a great developer. You’re passable at best.

You aren’t able to judge the business value of any programming task.

Related to the previous issue – many technically strong developers fail to realize their potential due because they aren’t able to take a step back and look at their work from the perspective of the business or organization itself.
Strong developers are able to self-manage and make good business decisions about how they choose to invest their time. They’ll ask questions like:
Is this the most valuable thing I should be working on right now? How much time should I invest into doing this? Given the deliverables I have due in two weeks, is there something I can invest in right now that will make it a lot easier for me to hit that target?
Average developers don’t – they’ll take a spec and blindly implement it until it’s finished, without accounting for how their work relates to the company’s business goals and impacts other members of the team / other business groups.
The highest cost of any engineering team is development time, and average developers waste lots of it on minutia and technical tasks that are ultimately low business value.

Wrap up

If you want to be a better developer, it starts with changing the way you look at your code and how you program.
You have to understand and appreciate the business costs behind each line of code you write. You have to be able to step outside of your text editor or IDE and look at your work from the perspective of a customer or end-user.
You have to accept that your code will outlast you in any organization your work with, so design everything to be inherited by other developers one day.
Most importantly, never be afraid to take on new challenges and ask for help along the way. You won’t improve working alone in the corner on technologies you’re already familiar with. Software development is inherently social – learn how to bring other people into the experience.

If you enjoyed this post, make sure you subscribe to my RSS feed!

The Complete Guide to Building HTML5 Games with Canvas & SVG

The Complete Guide to Building HTML5 Games with Canvas & SVG:
After spending most of his time explaining to students, hobbyists, professional developers and teachers how to build games using HTML5, David thought to himself, rather than keeping all these details for small audiences, wouldn’t it be smarter to share it with you? This article is then based on his own experience in doing so and helping other to build HTML games with Canvas and SVG.

Is JavaScript the Future of Programming?

Is JavaScript the Future of Programming?:

JavaScript is the programming language that makes a website interactive. Slideshows, advertising pop-ups and Google's autocomplete feature are all examples of JavaScript at work. It was first created by Brendan Eich at Netscape in 1995 -- nicknamed Mocha during development, released in beta as LiveScript and ultimately named JavaScript in order to piggyback on the popularity of Java (another programming language) for marketing reasons.
At first, developers didn't take JavaScript seriously, because it wasn't seen as a serious development language like Java, Ruby or Python, which are server-side languages. JavaScript was the frosting on the cake, only responsible for user experience. B…
Continue reading...
More About: Ajax, Did You Know, features, front end, mashable, node.js, programming

Ten - oh, wait, eleven - Eleven things you should know about the ASP.NET Fall 2012 Update

Ten - oh, wait, eleven - Eleven things you should know about the ASP.NET Fall 2012 Update:
Today, just a little over two months after the big ASP.NET 4.5 / ASP.NET MVC 4 / ASP.NET Web API / Visual Studio 2012 / Web Matrix 2 release, the first preview of the ASP.NET Fall 2012 Update is out. Here's what you need to know:

1. There are no new framework bits in this release - there's no change or update to ASP.NET Core, ASP.NET MVC or Web Forms features. This means that you can start using it without any updates to your server, upgrade concerns, etc.
2. This update is really an update to the project templates and Visual Studio tooling, conceptually similar to the ASP.NET MVC 3 Tools Update.
3. It's a relatively lightweight install. It's a 41MB download. I've installed it many times and usually takes 5-7 minutes; it's never required a reboot.
4. It adds some new project templates to ASP.NET MVC: Facebook Application and Single Page Application templates.
5. It adds a lot of cool enhancements to ASP.NET Web API.
6. It adds some tooling that makes it easy to take advantage of features like SignalR, Friendly URLs, and Windows Azure Authentication.
7. Most of the new features are installed via NuGet packages.
8. Since ASP.NET is open source, nightly NuGet packages are available, and the roadmap is published, most of this has really been publicly available for a while.
9. The official name of this drop is the ASP.NET Fall 2012 Update BUILD Prerelease. Please do not attempt to say that ten times fast. While the EULA doesn't prohibit it, it WILL legally change your first name to Scott.
10. As with all new releases, you can find out everything you need to know about the Fall Update at http://asp.net/vnext (especially the release notes!)
11. I'm going to be showing all of this off, assisted by special guest code monkey Scott Hanselman, this Friday at BUILD: Bleeding edge ASP.NET: See what is next for MVC, Web API, SignalR and more… (and I've heard it will be livestreamed).

Let's look at some of those things in more detail.

No new bits

ASP.NET 4.5, MVC 4 and Web API have a lot of great core features. I see the goal of this update release as making it easier to put those features to use to solve some useful scenarios by taking advantage of NuGet packages and template code.
If you create a new ASP.NET MVC application using one of the new templates, you'll see that it's using the ASP.NET MVC 4 RTM NuGet package (4.0.20710.0):

This means you can install and use the Fall Update without any impact on your existing projects and no worries about upgrading or compatibility.

New Facebook Application Template

ASP.NET MVC 4 (and ASP.NET 4.5 Web Forms) included the ability to authenticate your users via OAuth and OpenID, so you could let users log in to your site using a Facebook account. One of the new changes in the Fall Update is a new template that makes it really easy to create full Facebook applications.

You could create Facebook application in ASP.NET already, you'd just need to go through a few steps:

1. Search around to find a good Facebook NuGet package, like the Facebook C# SDK (written by my friend Nathan Totten and some other Facebook SDK brainiacs).
2. Read the Facebook developer documentation to figure out how to authenticate and integrate with them.
3. Write some code, debug it and repeat until you got something working.
4. Get started with the application you'd originally wanted to write.

What this template does for you: eliminate steps 1-3.
Erik Porter, Nathan and some other experts built out the Facebook Application template so it automatically pulls in and configures the Facebook NuGet package and makes it really easy to take advantage of it in an ASP.NET MVC application.
One great example is the the way you access a Facebook user's information. Take a look at the following code in a File / New / MVC / Facebook Application site. First, the Home Controller Index action:

[FacebookAuthorize(Permissions = "email")]
public ActionResult Index(MyAppUser user, FacebookObjectList<MyAppUserFriend> userFriends)
{
    ViewBag.Message = "Modify this template to jump-start your Facebook application using ASP.NET MVC.";

    ViewBag.User = user;
    ViewBag.Friends = userFriends.Take(5);

    return View();
}

First, notice that there's a FacebookAuthorize attribute which requires the user is authenticated via Facebook and requires permissions to access their e-mail address. It binds to two things: a custom MyAppUser object and a list of friends. Let's look at the MyAppUser code:

using Microsoft.AspNet.Mvc.Facebook.Attributes;
using Microsoft.AspNet.Mvc.Facebook.Models;

// Add any fields you want to be saved for each user and specify the field name in the JSON coming back from Facebook
// https://developers.facebook.com/docs/reference/api/user/

namespace MvcApplication3.Models
{
    public class MyAppUser : FacebookUser
    {
        public string Name { get; set; }

        [FacebookField(FieldName = "picture", JsonField = "picture.data.url")]
        public string PictureUrl { get; set; }

        public string Email { get; set; }
    }
}

You can add in other custom fields if you want, but you can also just bind to a FacebookUser and it will automatically pull in the available fields. You can even just bind directly to a FacebookUser and check for what's available in debug mode, which makes it really easy to explore.

For more information and some walkthroughs on creating Facebook applications, see:

• 
  

  Deploying your first Facebook App on Azure using ASP.NET MVC Facebook Template (Yao Huang Lin)

• 
  Facebook Application Template Tutorial (Erik Porter)
  

Single Page Application template

Early releases of ASP.NET MVC 4 included a Single Page Application template, but it was removed for the official release. There was a lot of interest in it, but it was kind of complex, as it handled features for things like data management. The new Single Page Application template that ships with the Fall Update is more lightweight. It uses Knockout.js on the client and ASP.NET Web API on the server, and it includes a sample application that shows how they all work together.



I think the real benefit of this application is that it shows a good pattern for using ASP.NET Web API and Knockout.js. For instance, it's easy to end up with a mess of JavaScript when you're building out a client-side application. This template uses three separate JavaScript files (delivered via a Bundle, of course):

• todoList.js - this is where the main client-side logic lives
• todoList.dataAccess.js - this defines how the client-side application interacts with the back-end services
• todoList.bindings.js - this is where you set up events and overrides for the Knockout bindings - for instance, hooking up jQuery validation and defining some client-side events

This is a fun one to play with, because you can just create a new Single Page Application and hit F5.

Quick, easy install (with one gotcha)

One of the cool engineering changes for this release is a big update to the installer to make it more lightweight and efficient. I've been running nightly builds of this for a few weeks to prep for my BUILD demos, and the install has been really quick and easy to use. The install takes about 5 minutes, has never required a reboot for me, and the uninstall is just as simple.



There's one gotcha, though. In this preview release, you may hit an issue that will require you to uninstall and re-install the NuGet VSIX package. The problem comes up when you create a new MVC application and see this dialog:



The solution, as explained in the release notes, is to uninstall and re-install the NuGet VSIX package:

1. Start Visual Studio 2012 as an Administrator
2. Go to Tools->Extensions and Updates and uninstall NuGet.
3. Close Visual Studio
4. Navigate to the ASP.NET Fall 2012 Update installation folder:
   
   1. For Visual Studio 2012: Program Files\Microsoft ASP.NET\ASP.NET Web Stack\Visual Studio 2012
   2. For Visual Studio 2012 Express for Web: Program Files\Microsoft ASP.NET\ASP.NET Web Stack\Visual Studio Express 2012 for Web
5. Double click on the NuGet.Tools.vsix to reinstall NuGet

This took me under a minute to do, and I was up and running.

ASP.NET Web API Update Extravaganza!

Uh, the Web API team is out of hand. They added a ton of new stuff: OData support, Tracing, and API Help Page generation.

OData support

Some people like OData. Some people start twitching when you mention it. If you're in the first group, this is for you. You can add a [Queryable] attribute to an API that returns an IQueryable<Whatever> and you get OData query support from your clients. Then, without any extra changes to your client or server code, your clients can send filters like this: /Suppliers?$filter=Name eq ‘Microsoft’

For more information about OData support in ASP.NET Web API, see Alex James' mega-post about it: OData support in ASP.NET Web API

ASP.NET Web API Tracing

Tracing makes it really easy to leverage the .NET Tracing system from within your ASP.NET Web API's. If you look at the \App_Start\WebApiConfig.cs file in new ASP.NET Web API project, you'll see a call to TraceConfig.Register(config). That calls into some code in the new \App_Start\TraceConfig.cs file:

public static void Register(HttpConfiguration configuration)
{
    if (configuration == null)
    {
        throw new ArgumentNullException("configuration");
    }

    SystemDiagnosticsTraceWriter traceWriter =
        new SystemDiagnosticsTraceWriter()
        {
            MinimumLevel = TraceLevel.Info,
            IsVerbose = false
        };

    configuration.Services.Replace(typeof(ITraceWriter), traceWriter);
}

As you can see, this is using the standard trace system, so you can extend it to any other trace listeners you'd like. To see how it works with the built in diagnostics trace writer, just run the application call some API's, and look at the Visual Studio Output window:

iisexpress.exe Information: 0 : Request, Method=GET, Url=http://localhost:11147/api/Values, Message='http://localhost:11147/api/Values'
iisexpress.exe Information: 0 : Message='Values', Operation=DefaultHttpControllerSelector.SelectController
iisexpress.exe Information: 0 : Message='WebAPI.Controllers.ValuesController', Operation=DefaultHttpControllerActivator.Create
iisexpress.exe Information: 0 : Message='WebAPI.Controllers.ValuesController', Operation=HttpControllerDescriptor.CreateController
iisexpress.exe Information: 0 : Message='Selected action 'Get()'', Operation=ApiControllerActionSelector.SelectAction
iisexpress.exe Information: 0 : Operation=HttpActionBinding.ExecuteBindingAsync
iisexpress.exe Information: 0 : Operation=QueryableAttribute.ActionExecuting
iisexpress.exe Information: 0 : Message='Action returned 'System.String[]'', Operation=ReflectedHttpActionDescriptor.ExecuteAsync
iisexpress.exe Information: 0 : Message='Will use same 'JsonMediaTypeFormatter' formatter', Operation=JsonMediaTypeFormatter.GetPerRequestFormatterInstance
iisexpress.exe Information: 0 : Message='Selected formatter='JsonMediaTypeFormatter', content-type='application/json; charset=utf-8'', Operation=DefaultContentNegotiator.Negotiate
iisexpress.exe Information: 0 : Operation=ApiControllerActionInvoker.InvokeActionAsync, Status=200 (OK)
iisexpress.exe Information: 0 : Operation=QueryableAttribute.ActionExecuted, Status=200 (OK)
iisexpress.exe Information: 0 : Operation=ValuesController.ExecuteAsync, Status=200 (OK)
iisexpress.exe Information: 0 : Response, Status=200 (OK), Method=GET, Url=http://localhost:11147/api/Values, Message='Content-type='application/json; charset=utf-8', content-length=unknown'
iisexpress.exe Information: 0 : Operation=JsonMediaTypeFormatter.WriteToStreamAsync
iisexpress.exe Information: 0 : Operation=ValuesController.Dispose

API Help Page

When you create a new ASP.NET Web API project, you'll see an API link in the header:



Clicking the API link shows generated help documentation for your ASP.NET Web API controllers:



And clicking on any of those APIs shows specific information:



What's great is that this information is dynamically generated, so if you add your own new APIs it will automatically show useful and up to date help. This system is also completely extensible, so you can generate documentation in other formats or customize the HTML help as much as you'd like. The Help generation code is all included in an ASP.NET MVC Area:

SignalR

SignalR is a really slick open source project that was started by some ASP.NET team members in their spare time to add real-time communications capabilities to ASP.NET - and .NET applications in general. It allows you to handle long running communications channels between your server and multiple connected clients using the best communications channel they can both support - websockets if available, falling back all the way to old technologies like long polling if necessary for old browsers.

SignalR remains an open source project, but now it's being included in ASP.NET (also open source, hooray!). That means there's real, official ASP.NET engineering work being put into SignalR, and it's even easier to use in an ASP.NET application. Now in any ASP.NET project type, you can right-click / Add / New Item... SignalR Hub or Persistent Connection.

And much more...

There's quite a bit more. You can find more info at http://asp.net/vnext, and we'll be adding more content as fast as we can. Watch my BUILD talk to see as I demonstrate these and other features in the ASP.NET Fall 2012 Update, as well as some other even futurey-er stuff!

The Truth About Structuring an HTML5 Page

The Truth About Structuring an HTML5 Page:
Part polemic, part instruction manual, The Truth About HTML5 has ignited an interesting debate. Here we present an exclusive excerpt on the problems around structuring in HTML5