Fighting Your Tools

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.

For those that don’t know, TypeScript is a language layer similar to Coffeescript that compiles down to plain old Javascript. It’s got a great syntax that allows you to have typed variables, and just hit 1.0. TypeScript also allows me to be a lazy developer because it integrates natively with Visual Studio’s intellisense. Given that I’m spending most of my time in Visual Studio working on this backend provider, it made sense to give TypeScript a whirl.

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.

  1. Keep going ahead with what I’m doing and hope that one day Windows stops being Windows.
  2. 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.
  3. 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.

CocoaRadio on iTunes

Just a small update to point out that CocoaRadio is now on iTunes if that’s your thing.

Thank you to everyone that has listened and subscribed thus far. I appreciate your support.

CocoaRadio - Brent Simmons Talks Vesper Sync

On the inaugural episode of CocoaRadio, Brent Simmons joins Justin Williams to discuss syncing data between the cloud and your mobile app. Brent has been blogging his experiences building a sync architecture for Vesper using Microsoft’s Azure Mobile Services platform. We discuss why he chose Azure and some pitfalls and successes he’s had in developing the sync architecture. We also go in-depth on how he is storing unique identifiers, handling conflicts, and other things that will forever make “Sync is Hard” a true statement.


I’ve started a new weekly podcast called CocoaRadio where I have conversations with people making interesting tools, libraries, and utilities for Mac and iOS developers.

My first guest is Brent Simmons who joins me to talk about all things related to the sync architecture he’s building for Vesper. You can download it here:

Episode 01 - Brent Simmons Talks Vesper Sync


Before we get to the backstory of this project, let’s get you on subscribed so you can get each week’s episode. The goal is to release each Monday morning so you can start your week off with something new and interesting to listen to.

Subscribe to CocoaRadio:

Subscribe via PocketCasts

Subscribe via iTunes

Talking About The Tech.

One of the shows I listen to regularly is Guy English’s Debug. Besides being a handsome fella, Guy’s show is usually filled with lots of history and stories from each guest’s career. I was on an episode once were we talked about iCloud syncing being a turd, but I mostly remember the ones where Don Melton is telling stories of building Safari or Jeff McLeman on working at DEC. I love that stuff.

I’ll leave the backstories and personal history to Guy. With CocoaRadio, my goal is to bring on people to talk about current projects and technologies they are using at an in-depth level. I could have talked to Brent for hours about NetNewsWire, MarsEdit or even Glassboard, but instead I wanted to focus entirely on the sync architecture he is building and pick his brain on the decisions he’s making. Plenty of people are going to be facing similar situations as he is right now. Hopefully the information he shared will be useful.

A Sprint. Not A Marathon

My biggest issue with most podcasts is length. I can think of at least a dozen things I’d rather spend 90 minutes doing than listening to people talk about tech, sports, movies, or pretty much anything. When Mikel and I did IRQ Conflict, we aimed for 10 minutes because we didn’t want to take up your time rehashing the same stories you’ve likely already heard about for half an hour each.

CocoaRadio isn’t a 10 minute show, but I am making an effort to keep each show at the 30 minute mark. Get in. Get the knowledge. Get out. Hopefully it can be a nice break between your 4 hour shows about Apple’s wearable plans.

The first episode of CocoaRadio doesn’t have an official sponsor. Hopefully that can change by episode two. In order to allocate time to doing this show, I need to justify the time and expense of doing it. This is a chicken and egg problem, of course. Without a large audience, sponsors aren’t interested. Without sponsors, I can’t build a large audience.

If you’re interested in sponsoring CocoaRadio for a portion of our first season (13 episodes), I’ll cut you a sweet deal. Get in touch

You actually read this far? What are you doing? Go listen to Episode 01.

Hosting Jekyll on Azure Web Sites

If you are reading this post, your DNS has successfully updated and you are viewing carpeaqua now hosted on Microsoft’s Azure Web Sites service. As I wrote in Hurdles, the process of publishing this site is a 7-step process using Jekyll. I am in the process of trying to simplify that process, and one of the first things was moving to a new host.

Why Azure? Well, for one I’m a fan of the platform. Glassboard uses it extensively for managing its API, web app, and data.

Second, it allows me to remove a step from my 7-step deployment story. Previously to publish this site, I would have to run a Rake command that would rsync my site’s content to the host. With Azure Web Sites, I’ve connected carpeaqua’s public GitHub repository to Azure and it automatically listens for a new commit to master. When it detects that new commit (it takes just a few seconds), it automatically updates and deploys the updated site.

Configuring Jekyll for Azure Web Sites

Azure Web Sites runs on Microsoft’s IIS web server rather than Apache. As an end-user you likely won’t notice, but if you’re using Jekyll or some other platform that is traditionally hosted on Apache or some other open-source web server, it takes a few extra steps to get everything configured.

Note: I won’t run you through the process of creating an Azure Web Site. There are plenty of tutorials on Microsoft’s site and The Google to do that.

Commit Your Published Site To Git

First you want to ensure that you’re saving a copy of your generated web site in your GitHub repository. Previously I wasn’t since I was just rsyncing from my local Mac to the web. I have my site broken down now by _source for the Markdown files and files I edit and website for the generated site.

You can see this on the repository.

Create A .deployment file

To tell IIS which page directory you want to server, you’ll need to create a .deployment file in the root of your GitHub repository. The contents are fairly basic. Here’s mine:

project = website

Create a web.config file

In your _source directory, you’ll want to create a web.config file. This is IIS’s equivalent to the .htaccess file on Apache. It has a different syntax that is XML based and takes some getting used to.

My web.config file does two things:

  1. Points to a custom 404 page at the root of my websites folder.
  2. Redirects all requests for to (no www).

Technically, you could consider this an optional step, but I think the no-www looks cleaner. I wouldn’t skip it personally.

Pushing Changes To Azure Web Sites

Now that everything is set up, you should be able to generate new posts and share them with your readers? How? After you finish writing just open Terminal and run git push origin master just like you would any GitHub repository.


That’s it. That’s the list.

I’ve now gone from a 7-step publishing process to a 6-step publishing process. I’m not really changing the world here, but it is nice to not have to open 1Password to get my old host’s crazy long SFTP password to publish a new article. I can now spend those extra few seconds refreshing Twitter again.