Scott Hanselman

I got an email recently from a long-time programmer who had to step out of the game for a little while. They basically had a hiatus from programming due to situations out of their control, but now are looking at getting back in.

They asked, quoting from the email:

If you had to “start over,” what are the technologies, languages, paradigms and platforms I need to be up-to-date and mastering in my new world of 2014?

It’s daunting if not downright scary.  I can *learn* anything, and do - quickly.  I feel like I’ve been sooooo out of the loop, it’s not even funny.

I think we can all relate to feeling like this. I've talked about this before in my post "I'm a phony" about imposter syndrome. Technology is changing so fast it's hard to be a "professional" at anything. Ultimately, we're all amateurs.

To the root question, though, what technologies would I learn?

This question comes up a lot. I tell people this. Learn one language you can build large systems with AND also learn JavaScript. For me, that's C# and JavaScript. For someone else, the "systems" language might be Erlang, or Groovy, or Ruby, or Java, or Scala. That language matters less to me. Your goal is to be able to write applications for the web, as well as write other systems.

Pick a language that feels right

Learn a language that has a community behind it and that has been a part of building successful systems. Learn a language that lets you create the kinds of systems you want to create. For me, I picked C# because I can write web apps, Windows apps, Mac apps, iPhone apps, Windows Phone apps, SmartWatch apps, and tiny embedded apps, but above all because I enjoy writing C#.

There are many other languages that have a wonderfully rich breadth of power and expressiveness. Python is one, Java is another, and JavaScript and node can even control robots. Pick a language with personality and breadth, and learn that language the hard way, by doing. Read lots of code and lots of books. Pick a language that fits your brain and helps you learn how to think, and when you do think, think about abstractions'.

Write while you learn your new language. Write about what you discover, what works, what doesn't. Write even though no one may be reading; you may find that they are reading. Join your new language's community and go to its user groups. Remember not to have ego, you are not your code.

Bet on the Web

There's lots of talk about App Stores these days. Everyone has them and they are clearly where the money is made. But today's (2014's) App Stores are still broken. Updates are a hassle, even when they are automatic. Apps (on all platforms) get stuck in broken updating states and have to be reinstalled, updates are often huge and rarely use smart patching and deltas. App Stores can become weed-filled gardens if they aren't attended to.

The web persists, though. We have issues like net neutrality to work out, and walled gardens like Facebook, our standards orgs are stuck in committee, and we get a new identity subsystem every few years, but the web is winning. The web will persist and the web will win. That's why I suggest you learn JavaScript. (Learn HTML5 and CSS3 also and learn to create and consume JSON services.) JavaScript is the virtual machine that we all have installed and JavaScript is the language of the web. (For some, JavaScript is Assembly Language.) It's not going anywhere, so that why you should learn it.

Aim to be able to create web sites, web apps, and rich connected apps and systems. Also aim to know a language that lets you write applications that you can put in the App Store for any of a billion connected devices.

That's my advice to someone starting over in 2014.

Sponsor: Big Thanks to Aspose for sponsoring the blog this week! Aspose.Total for .NET has all the APIs you need to create, manipulate and convert Microsoft Office documents and a host of other file formats in your applications. Curious? Start a free trial today.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

About a year ago we thought it would be a good idea to do a talk on "What not to do in ASP.NET?" - basically an anti-patterns talks. We kept seeing folks falling into the same traps and wanted to be prescriptive as there's aspects to ASP.NET that are 10 years old and don't apply to today's internet, but there are also new aspects to ASP.NET that are only a year old, and perhaps haven't soaked into the zeitgeist quite yet.

Damian Edwards gave his version of this talk at NDC 2013 and you can watch the video here if you like, it's very entertaining.

We took the information we gathered from people like Damian, Levi Broderick and others, and Tom FitzMacken put together a whitepaper on the topic. It's not complete, but it covers some of the most common "gotchas" folks run into.

Here are the areas we call out in the whitepaper so far, with highlights below from me.

• Standards Compliance
  • Control Adapters - Control adapters were a good idea in .NET 2, but it's best to use solid adaptive CSS and HTML techniques today.
  • Style Properties on Controls - Set CSS classes yourself, don't use inline styles.
  • Page and Control Callbacks - Page Callbacks pre-date standard AJAX techniques, so today, stick with SignalR, Web API, and JavaScript.
  • Browser Capability Detection - Check for features, not for browsers whenever possible.
• Security
  • Request Validation - While Request Validation is useful, it's not focused and it doesn't know exactly what you app is doing. Be smart and validate inputs with the full knowledge of what your app is trying to accomplish. Don't trust user input.
  • Cookieless Forms Authentication and Session - Don't pass anything auth related in the query string. Cookieless auth will never be secure. Don't do it.
  • EnableViewStateMac - This should never be false. Ever.
  • Medium Trust - Medium trust isn't a security boundary you should count on. Put apps in separate app pools.
  • <appSettings> - Don't disable security patches with appSettings.
  • UrlPathEncode - This doesn't do what you think it does. Use UrlEncode. This method was very specific, poorly named, and is now totally obsolete.
• Reliability and Performance
  • PreSendRequestHeaders and PreSendRequestContext - Leave these alone making managed modules. These can be used with native modules, but not IHttpModules.
  • Asynchronous Page Events with Web Forms - Use Page.RegisterAsyncTask instead.
  • Fire-and-Forget Work - Avoid using ThreadPool.QueueUserWorkItem as your app pool could disappear at any time. Move this work outside or use WebBackgrounder if you must.
  • Request Entity Body - Stay out of Request.Form and Request.InputStream before your handler's execute event. It may not be ready to go.
  • Response.Redirect and Response.End - Be conscious of Thread.Aborts that will happen when you redirect.
  • EnableViewState and ViewStateMode - There's no need to hate on ViewState. Turn it off everywhere, then turn it on only for the individual controls that need it.
  • SqlMembershipProvider - Consider using ASP.NET User Providers, or better yet, the new ASP.NET Identity system.
  • Long Running Requests (>110 seconds) - ASP.NET isn't meant to handle long running requests that are a minute (or two) long. Use WebSockets or SignalR for connected clients, and use asynchronous I/O operations.

I hope this helps someone out!

Sponsor: Big Thanks to Aspose for sponsoring the blog this week! Aspose.Total for .NET has all the APIs you need to create, manipulate and convert Microsoft Office documents and a host of other file formats in your applications. Curious? Start a free trial today.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

Last year, about this time, a bunch of us sat down in a studio to give a full day of tutorials and discussion on "Building Web Apps with ASP.NET." All those videos are online and have lots of good content like:

• 1: What's New in ASP.NET 4.5
• 2: Building and Deploying Websites with ASP.NET MVC 4
• 3: Creating HTML5 Applications with jQuery
• 4: Building a Service Layer with ASP.NET Web API
• 5: Leveraging Your ASP.NET Development Skills to Build Office Apps
• 6: Building and Leveraging Social Services in ASP.NET
• 7: Building for the Mobile Web
• 8: Real-time Communication with SignalR
• 9: Taking Advantage of Windows Azure Services

We headed over to the Microsoft Virtual Academy Studios again just this last week for another full day of discussion, training, as well as a glimpse into the possible future of .NET. Between these two days of videos you'll get a real sense of what's possible and real advice on how to build your next web application.

Today we've got 7 all-new segments for you, each recorded live at the MS Studios.

• 1: What's New in Visual Studio 2013 for Web Developers
• 2: Upgrading Applications
• 3: ASP.NET Identity
• 4: Web Essentials and the Client Side
• 5: Entity Framework
• 6: Katana Project
• 7: ASP.NET "Project Helios"

These videos are featuring folks like Scott Hunter, Levi Broderick, Rowan Miller, Pranav Rastogi, Mads Kristensen, and Louis DeJardin. No marketing folks, just actual developers that work on ASP.NET every day.

1: What's New in Visual Studio 2013 for Web Developers - Learn about the latest features in Visual Studio 2013, including dozens of tips and tricks.

2: Upgrading Applications - Get a deep dive on how to upgrade your older applications to ASP.NET 4.5 and later.

3: ASP.NET Identity - Explore the new ASP.NET Identity system. Learn how to migrate your existing membership data to the new Identity system and how to integrate with other membership systems.

4: Web Essentials and the Client Side - Discover how to build modern client-side applications, more simply and quickly, with a host of new features, tips, and tricks in Web Essentials for Visual Studio.

5: Entity Framework - Have you been using Entity Framework for data access in your web app? In this advanced demo-heavy session, learn the latest features of Entity Framework 6 and get sneak previews of what's coming in version 6.1.

6: The "Katana" Project - Hear the latest on "Project Katana," the Microsoft implementation of Open Web Interface for .NET. It's a glimpse of the future for cloud-optimizing your ASP.NET applications.

7: ASP.NET "Project Helios" - Discover "Project Helios," a prototype representing the re-thinking of the core of ASP.NET. Take a look at the future of web development, with a modular, lightweight OWIN host that runs on Internet Information Services (IIS).

Also be sure to explore the new series "Get Started with Windows Azure today" featuring content from ScottGu himself for a full 90 minutes!

• [01:00] - Windows Azure
• [18:17] - Virtual Machines
• [41:39] - SQL Database
• [49:49] - Web Sites
• [1:31:40] - Storage
• [1:34:47] - Active Directory

I hope you have as much fun watching them as we did filming them.

Sponsor: Big Thanks to Aspose for sponsoring the blog this week! Aspose.Total for .NET has all the APIs you need to create, manipulate and convert Microsoft Office documents and a host of other file formats in your applications. Curious? Start a free trial today.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

I got an email today where someone had built a REST(ful/ish) API with ASP.NET Web API that had a customer who was against the idea of using GET, POST, PUT, and DELETE, and insisted that they only use GET and POST.

Sometimes this is because of a browser or client limitaton, sometimes it's a really tense corporate firewall. They wanted to know what they could do.

One thing you can do is to "tunnel" HTTP Methods inside another HTTP Header. Basically you have a header that says "No, seriously, I know I got here via a POST, but use this one instead." You would still POST, but then you'd have "X-HTTP-Method-Override:PUT" as a header.

Here is a PUT in the Postman REST client:

So that's:

PUT /api/Person/4 HTTP/1.1
Host: localhost:10320
Content-Type: application/json
Cache-Control: no-cache

And here's the same PUT, except as a POST plus an X-HTTP-Method-Override header.

Raw, that's like this:

POST /api/Person/4 HTTP/1.1
Host: localhost:10320
Content-Type: application/json
X-HTTP-Method-Override: PUT
Cache-Control: no-cache

Now, how do you get ASP.NET Web API to respect this new way to route things? You may have a Web API Controller like this:

public IEnumerable<Person> Get() { }

// GET api/person/5
public Person Get(int id) { }

// POST api/person
public void Post([FromBody]Person value) { }

// PUT api/person/5
public void Put(int id, [FromBody]Person value) { }

// DELETE api/person/5
public void Delete(int id) { }

And you likely don't want to change it. Make a MethodOverrideHandler like this one. You can add the code yourself, get it from a NuGet package, or use one from the WebAPIContrib project. It's up to you.

public class MethodOverrideHandler : DelegatingHandler
{
    readonly string[] _methods = { "DELETE", "HEAD", "PUT" };
    const string _header = "X-HTTP-Method-Override";

    protected override Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage request, CancellationToken cancellationToken)
    {
        // Check for HTTP POST with the X-HTTP-Method-Override header.
        if (request.Method == HttpMethod.Post && request.Headers.Contains(_header))
        {
            // Check if the header value is in our methods list.
            var method = request.Headers.GetValues(_header).FirstOrDefault();
            if (_methods.Contains(method, StringComparer.InvariantCultureIgnoreCase))
            {
                // Change the request method.
                request.Method = new HttpMethod(method);
            }
        }
        return base.SendAsync(request, cancellationToken);
    }
}

You see it checks if it's a post, looks for the extra header, then changes the request's Method property after the message has been received, but before it's been sent through the pipeline. It'll show up on the right method just as if a PUT had been sent, because from its perspective, a PUT was sent.

You need to register this new MethodOverrideHandler in your WebApiConfig like this, just by adding to the MessageHandlers collection, next to the rest of the configuration and routing code.

public static void Register(HttpConfiguration config)
{
    config.MessageHandlers.Add(new MethodOverrideHandler());

    //OTHER REGULAR STUFF HERE

    // Web API routes
    config.MapHttpAttributeRoutes();

    config.Routes.MapHttpRoute(
        name: "DefaultApi",
        routeTemplate: "api/{controller}/{id}",
        defaults: new { id = RouteParameter.Optional }
    );
}

On the client side, you can keep sending a post with your .ajax call in jQuery, for example, just make sure the override header in there.

$.ajax({
  url: "http://localhost:10320/api/Person/4",
  type: "POST",
  data: JSON.stringify(whatever),
  headers: { 
      "Content-Type": "application/json",
      "X-HTTP-Method-Override": "PUT" },
})

That's the general idea, enjoy!

Sponsor: Big Thanks to Aspose for sponsoring the blog this week! Aspose.Total for .NET has all the APIs you need to create, manipulate and convert Microsoft Office documents and a host of other file formats in your applications. Curious? Start a free trial today.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

Deploying to Windows Azure is very easy from Git. I use the Azure Cross-Platform Command Line (open source on github, written in node) that I get from npm via "npm install azure-cli --g" to make the sites.

When you make a new site with the Azure command line, you'll usually do this:

azure site create --location "West US" MyFirstSite --git

And the tool will not only make the site, but also add a git remote for you, something like https://username@MyFirstSite.scm.azurewebsites.net:443/MyFirstSite.git. When you push to that git remote, Azure deploys the site. You can git push sites with PHP, node, ASP.NET, and Python.

You may have multiple remotes with your git repository, of course:

C:\MyCode>git remote show
azure
origin

When you push a folder with code to Azure via Git, unless you're pushing binaries, Azure is going to compile the whole thing for you when it gets pushed. It will restore npm modules or restore NuGet packages, and then build and deploy your app.

If your repository has a lot of .NET projects, you usually only want one project to be the actual deployed website, so you can add a .deployment file to specify which project contains website you're git deploying:

[config]
project = WebProject/MyFirstSiteWebProject.csproj

However, in lieu of a .deployment file, you can also set an application configuration setting with the Azure Portal to to the same thing.

Or, of course, set the configuration values for each site using the Azure Command Line:

c:\MyCode>azure site config add Project=WebProject/MyFirstSiteWebProject.csproj [sitename]

What's nice about setting the "Project" setting via site configuration rather than via a .deployment file is that you can now push the same git repository containing two different web sites to two remote Azure web sites. Each Azure website should have a different project setting and will end up deploying the two different sites.

I do this by setting the git remotes manually like this, using the correct git remote URLs I get from the Azure Portal:

C:\MyCode> git remote add azureweb1 https://scott@website1.scm.azurewebsites.net:443/website1.git
C:\MyCode> git remote add azureweb2 https://scott@website2.scm.azurewebsites.net:443/website2.git
C:\MyCode> git remote show
azureweb1
azureweb2
origin
C:\MyCode> git push azureweb1 master

I have a number of solutions with two or more web sites, or in one case, a web site I want separate from my web api, and I deploy them just like this.

Hope this helps!

Sponsor: Big Thanks to Aspose for sponsoring the blog this week! Aspose.Total for .NET has all the APIs you need to create, manipulate and convert Microsoft Office documents and a host of other file formats in your applications. Curious? Start a free trial today.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By