Upcoming Manila Presentation: Your website is in production. It’s broken. Now what?

Next month I’ll be spending some time in the Readify Manila office catching up with some local colleagues. While there, I’ll be presenting a user group session at the local Microsoft office. If you’re in the area, I’d love to see you there. (Did you know that we’re hiring in Manila too?)

Manila, Philippines, Wed 12th Dec 2012. Free. Register now.

Big websites fail in spectacular ways. In this session, five-time awarded ASP.NET/IIS MVP and ASP Insider Tatham Oddie will share the problems that he and fellow Readify consultants have solved on large scale, public websites. The lessons are applicable to websites of all sizes and audiences, and also include some funny stories. (Not so funny at the time.)

A tiny subset of your users can’t login: they get no error message yet have both cookies and JavaScript enabled. They’ve phoned up to report the problem and aren’t capable of getting a Fiddler trace. You’re serving a million hits a day. How do you trace their requests and determine the problem without drowning in logs?

Marketing have requested that the new site section your team has built goes live at the same time as a radio campaign kicks off. This needs to happen simultaneously across all 40 front-end web servers, and you don’t want to break your regular deployment cycle while the marketing campaign gets perpetually delayed. How do you do it?

Users are experiencing HTTP 500 responses for a few underlying reasons, some with workarounds and some without. The customer service call centre need to be able to rapidly evaluate incoming calls and provide the appropriate workaround where possible, without displaying sensitive exception detail to end users. At the same time, your team needs to prioritize which bugs to fix first. What’s the right balance of logging, error numbers and correlations ids?

Your application is running slow in production, causing major delays for all users. You don’t have any tools on the production servers, and aren’t allowed to install any. How do you get to the root of the problem?

New Talks: “Neo4j in a .NET World (Graph DBs)” and “You’re in production. Now what?”

Last week I was lucky enough to join an array of great speakers at the NDC Oslo conference.

The recordings of both of my talks are now online, along with 141 other excellent talks you should watch.

Neo4j in a .NET World (Graph DBs)

This year, a small team of developers delivered a ASP.NET MVC app, with a neo4j backend, all running in Azure. This isn’t in POC; it’s a production system. Also, unlike most graph DB talks, it’s not a social network!

https://vimeo.com/43676873

You’re in production. Now what?

A tiny subset of your users can’t login: they get no error message yet have both cookies and JavaScript enabled. They’ve phoned up to report the problem and aren’t capable of getting a Fiddler trace. You’re serving a million hits a day. How do you trace their requests and determine the problem without drowning in logs?

Marketing have requested that the new site section your team has built goes live at the same time as a radio campaign kicks off. This needs to happen simultaneously across all 40 front-end web servers, and you don’t want to break your regular deployment cadence while the campaign gets perpetually delayed. How do you do it?

Users are experiencing 500 errors for a few underlying reasons, some with workarounds and some without. The customer service call centre need to be able to rapidly triage incoming calls and provide the appropriate workaround where possible, without displaying sensitive exception detail to end users or requiring synchronous logging. At the same time, your team needs to prioritize which bugs to fix first. What’s the right balance of logging, error numbers and correlations ids?

These are all real scenarios that Tatham Oddie and his fellow consultants have solved on large scale, public websites. The lessons though are applicable to websites of all sizes and audiences.

https://vimeo.com/43624434

.NET Rocks! #687: ‘Tatham Oddie Makes HTML 5 and Silverlight Play Nice Together’

I spoke to Carl + Richard on .NET Rocks! last week about using HTML5 and Silverlight together. We also covered a bit of Azure toward the end.

The episode is now live here:

http://www.dotnetrocks.com/default.aspx?showNum=687

JT – Sorry, I referred to you as “the other guy I presented with” and never intro-ed you. 😦

Everyone else – JT is awesome.

Node.js on Windows

Thanks to Sharkie’s ongoing organisation efforts, SydJS is a thriving monthly JavaScript meeting here in Sydney. This evening they welcomed me along to talk about Node.js on Windows. Afraid of a mostly non-Microsoft crowd I rocked up with all the anti-Unix jokes I had but they turned out to be all quite friendly and it was a fun little talk.

Here’s what I ran through…

Update 18th July 2011: The latest official builds of node.js now come with a Windows executable. This is thanks to support from Microsoft.

Cygwin

Cygwin gives you a full POSIX environment on Windows. It’s great for running apps designed for Unix, but it’s pretty heavy and not very … Windows-ey. It’d be like creating a “My Documents” folder on Ubuntu.

All that being said, it’s the simplest and most reliable way of getting node running on Windows.

Works for 0.2.6 -> 0.3.1 and 0.4.0+. Anything between 0.3.1 and 0.4.0 won’t compile.

The steps (and common pitfalls) are well documented at https://github.com/joyent/node/wiki/Building-node.js-on-Cygwin-(Windows)

Once you’ve got it running in Cygwin, if you jump out to a standard Windows command prompt and run c:\Cygwin\usr\local\bin\node.exe you’ll get a nice big error. More on this later.

MinGW

The next step up from Cygwin is to compile it under MinGW. MinGW (Minimal GNU for Windows) provides the bare minimum set of libraries required to make it possible to compile Unix-y apps on Windows, avoiding the full POSIX strangehold environment that Cygwin provides.

Works for 0.3.6+.

Again, there are well documented steps for this: https://github.com/joyent/node/wiki/Building-node.js-on-mingw

Once you’ve got it running in MinGW, jump out to a standard Windows command prompt again and run c:\wherever-you-put-your-git-clone\node.exe you’ll get a nice big error.

Standalone

Now that we’ve compiled it with MinGW (you did that in the last step, right?) we’re ready to run it on Windows natively.

From a native Windows command prompt:

  1. Create a new folder (mkdir node-standalone)
  2. Copy in the node.exe you compiled in MinGW (xcopy c:\wherever-you-put-your-git-clone\node.exe node-standalone)
  3. Copy in the MinGW helper libraries (xcopy c:\mingw\bin\lib*.dll node-standalone)
  4. Run node-standalone\node
  5. Voila! It works!

Running as a Service

Next up, I wanted to host node as a service, just like IIS. This way it’d start up with my machine, run in the background, restart automatically if it crashes and so forth.

This is where nssm, the non-sucking service manager, enters the picture. This tool lets you host a normal .exe as a Windows service.

Here are the commands I used to setup an instance of the SydJS website as a service:

nssm.exe install sydjs-node c:\where-i-put-node-standalone\node.exe c:\code\SydJS\server.js
net start sydjs-node

What We Achieved

We now have node.js, running natively on Windows, as a service. Enjoy!

(Just please don’t use this in production – it’s really not ready for that yet.)