Troubleshooting “500 Internal Server Errors” in the Windows Azure Emulator when Working with Node.JS
On my primary development machine, where I have tweaked and prodded IIS multiple times for many projects over the past couple of years, I get the following 500 – Internal Server Error message when I try to fire up even the simplest “Hello World” Node.JS project included in the default template for each Windows Azure Node Web Role:
However, when I push the default “Hello World” Node.JS app to a production on Windows Azure, I have no issues whatsoever! So what’s the problem?
The issue is that the Windows Azure emulator:
Following Microsoft’s announcements regarding first-class Node.JS support on Windows Azure, I thought it would be helpful to walk newbie Node.JS and Windows Azure developers through the process of getting their Node.JS development environment set up, building their first simple Node.JS application, and then learning how to take advantage of popular NPM packages like Express to build actual web applications on Windows Azure.
Setting Up Your Node.JS + Windows Azure Environment
First, a big disclaimer: all of the Windows Azure deployment and packaging components require Windows in order to work. You will not be able to deploy your application to Windows Azure without a Windows Vista / 7 box.
That being said, the rest of the setup...
In the last post in this series on working with Node.JS in Windows Azure I showed you how to set up your development environment for working with Node.JS and Windows Azure. In this post I am going to show you how to write and deploy a simple web application to Windows Azure using Node.
Step 1 – Create a New Node Project via Windows Azure PowerShell for Node.JS
The first thing we need to do is create a new Node.JS project using the Windows Azure PowerShell for Node.JS tools.
Use the New-AzureService [servicename] command just like how we did in the last part – I named my service “loggity.simple” in this instance.
Next, create your Node web service using the Add-AzureNodeWebRole [rolename]...
In addition to my regular work for Microsoft and the open source projects I create and contribute to on Github, I also like to ship the occasional app or website under my StannardLabs masthead.
I’ve since modified the app pretty drastically so that it now includes touch support, a clean minimalist UI, and a selection of 60,000 plus images to page through, with hundreds more being added every day.
Learn Python the Hard Way is a book designed for people with no programming experience whatsoever, but even as an experienced software developer I got a lot of value out of it. Zed does a great job forcing the reader to develop Python muscle memory early, and he introduces concepts like unit testing in Python and package management from the beginning.
One of the really valuable lessons of Learn Python the Hard Way is in exercise #46, where Zed recommends a great generic folder and file structure for new Python projects, like this one:
Microsoft announced out-of-the-box support for Node.JS on Windows Azure on Tuesday; we pushed both an official Node.JS SDK for Windows Azure services (table storage, blob storage, and queues) and some tools for creating and managing Node.JS roles on Windows Azure, both of which are available through the official Windows Azure page on Github.
I’ve been playing around with Node for a short while and have the pleasure of working with some great startups that utilize Node heavily in production, so I wanted an opportunity to explain to my fellow .NET developers why they should be excited about Node support on Azure and how they can put it to work for them.
Node at a Glance
If you want to spend 90 minutes and get a full 100-level understanding of Node, check out...
Earlier this week I spent some time helping a company troubleshoot some performance issues with Windows Azure – their ASP.NET request queue was growing longer than the maximum amount of queued requests supported by default in IIS (5000) during bursts of high activity, so I had to help them find a way to empty the queue faster.
One way to do this is to modify the number of max/min IO and worker threads available to any web role instance, and these values can only be modified through machine.config settings.
As you know, Windows Azure VMs are not persistent so you can’t modify machine.config and save it to file system like how you might if you were hosting IIS on your own local box.
Thus, I crafted a solution using AppCmd and Windows Azure startup tasks.
Here’s some of the code below:
I love my job at Microsoft, but there are some times when we simply make it really damn hard for people to do business with us. Migrating data from an on-premise SQL Server to SQL Azure is sadly one of those lapses where, for whatever reason, we’ve left people who aren’t full time SQL Server DBAs totally lost in the wilderness with a set of poorly documented and often dysfunctional tools.
After spending a couple of hours shaving yaks myself tonight trying to move a ~250mb data set (small, but not trivially small) from one SQL Azure database to another, I thought it would be best if I documented what I did to make it work.
Scenario: I needed to download an expensive dataset on one SQL Azure account and migrate it to another on a different SQL Azure subscription, but I needed to make and test some schema changes...
I am frankly disturbed by a trend that I’ve seen both in-person and all over Hacker News / Reddit through the past year, and I am going to finally give it a name: “popped collar programming.”
Popped collar programming is the hipsterization of software development, and it’s happening in a co-working space, unprofitable venture-backed startup, or coffee shop near you.
A popped collar programmer’s life begins like this:
[New Technology X] is released and offers a new and interesting view of how to perform [programming chore Y];
Reddit / Hacker News announces the release of [New Technology X] and is greeted with tons of enthusiasm and applause;
Curious developers check [New Technology X] out – it’s an early release and thus they discover [New Technology X] is missing [Critical Features 1….N] and has [Stability Issues 1…N]; most of the early adopters utilize the technology...
I spent a lot of time late last week trying to figure out exactly how to set up dependency injection for a WCF service I was developing on Windows Azure; there’s some documentation out there on how to do it, but it’s not nearly as helpful as I would like it. Thus I decided to document how I made WCF and Ninject play nice with each other, and I even provide a sample template you can use yourself.
Step 1 – Install Ninject.Extensions.WCF via NuGet
The developers who maintain Ninject were kind enough to put together a set of extensions for working with WCF applications specifically, and we can install this via NuGet (install it from CodePlex.)
Simply type this into the “package manager console” in Visual Studio: install-package Ninject.Extensions.Wcf