As I mentioned recently, I am working on a refactoring of how Glassboard handles its push notifications system. The short-version is that the current incarnation uses an Azure Worker Role to handle messages of a Storage Queue via C# and a lot of custom written code for tying into each push notification provider we use.
When we last spoke, I was pretty convinced with throwing out the C# code in favor of a Node and TypeScript flavored solution. I was also debating using Azure’s Notification Hub service for delivering the pushes to further lessen my code liability. I have been working on this for the past few days, but it hasn’t been going exactly as I had hoped.
If you’re interested in seeing some sample TypeScript, here’s a snippet from Glassboard. I really like the syntax, though having to write my own accessor methods is very cave man.
Microsoft also recently went to a 1.0 beta with their NodeJS tools for Visual Studio that make it super easy to build and deploy Node to Azure. Since I am working with Azure’s storage and CPU emulators in Windows already, using these tools made sense too. I’ve never had much luck bridging the emulators from my VMWare instance to my Mac’s network stack anyway. The Node tools also have built-in support for debugging Node both locally and remotely, which is super awesome.
So, good language. Good toolchain. What’s the matter?
It turns out that Windows has a really annoying problem with long file directory paths. In short, a file name must be less than 260 characters, and a directory path must be less than 248 characters. Otherwise, you get this error constantly.
Unable to copy file ".\node_modules\azure\node_modules\request\node_modules\form-data\node_modules\combined-stream\node_modules\delayed-stream\test\integration\test-handle-source-errors.js" to "obj\Debug\.\node_modules\azure\node_modules\request\node_modules\form-data\node_modules\combined-stream\node_modules\delayed-stream\test\integration\test-handle-source-errors.js". The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Node.js Tools\Microsoft.NodejsTools.targets 74 5 Cloud
Now, imagine you are working with a framework like Node that relies heavily on package modules, which also rely on package modules, which also rely on package modules. You’re going to run into this pretty much every time you build.
I tried working around it at first by mapping a virtual drive for my Development projects, but the nested node modules still became too much for Windows 8 to cope with.
This is a bummer for a variety of reasons. For one, using the Node tools for Visual Studio is nearly impossible for any development situation that relies on a suite of npm modules. As you can see from the error above, I’m trying to use Microsoft’s own Azure module and running into the issue. It pretty much prevents me from building my project and testing it locally in Visual Studio.
And as a developer, I’m bummed for the people working on the Visual Studio Node Tools project. They’ve built something really great, but I’m struggling to use it because of a long-time Windows bug (yes, this is a bug).
I will never complain about HFS+ again.
I have a few options to deal with this issue.
- Keep going ahead with what I’m doing and hope that one day Windows stops being Windows.
- Work on getting the Azure Emulator to work through VMWare to my host Mac so that I can write the TypeScript code in Sublime Text natively on my Mac.
- Throw away two or three days worth of work and go back to a C# solution that likely won’t run into this issue since its dependency model relies on namespaces rather than directory structure.
I’m leaning towards option 2 or 3 even though the Stubborn Developer wants to take option 1.
Option 2 is nice because I can still use TypeScript and Node to manage this portion of the project. I’m pretty sure I can figure out the VMWare issues I’ve had if I sit down for a few hours and tackle it. The tradeoff is that Sublime’s TypeScript support isn’t nearly as powerful as Visual Studio. I’m a lazy developer. I like my tools to enable me to be as lazy as possible.
Option 3 is appealing because I have a good chunk of the code already written in the legacy system. Since I’m switching to Notification Hubs, I can trash a good chunk of the existing code base and wrap it in the Azure SDK’s handling library.
Thanks to an Azure Friday series of videos I’ve got a better understanding of how to handle not using threads to manage the processing on the Worker Role as well.
I’m taking a day to weigh the pros and cons so I can choose which route I want to take. Until then, the lesson learned from this is that new and shiny doesn’t always mean better. Now I’m behind on my ship goal by several days.
Back to work.