Development Experience(s)

Azure WebJobs are awesome and you should start using them right now!  I've been using them for a while and thought I'd share some knowledge: Naming is important Looking in the Azure WebJobs Dashboard, you'll have much better experience if your class and method names describe what their intention is: Rename your Functions.ProcessQueueMessage to something legible (especially if your web job has many triggers): If you, in your dashboard, get a notice of a missing connection string, you'll want to add that in your site's Application settings: Async Task is your friend My job classes are static and my methods are too. Further, my methods are async Task so that I can use other async APIs with minimal friction: You can bind your method parameters to everything storage (and some Service Bus too!) As you could see in the example above (and also in Troy's article linked in the beginning), running a web job method in response to a blob being wri

If you've logged into the Azure Management Portal recently, you might've noticed that we are now able to export templates from our resource groups! That's absolutely amazing and is something that surely will save us a lot of time throughout our Azure careers. If you have any Service Bus resources, you might've also noticed, however, that those are not included in the template! Furthermore, the Service Bus templates are not available in Visual Studio's Add Resources  ARM tooling. Bummer! Here's how you add the necessary nodes into your JSON deployment template: Ok, so what's with all the parameters and variables? Let's go through them together: sbVersion is set to the first available API version within the service bus namespace: "sbVersion": "[providers('Microsoft.ServiceBus', 'namespaces').apiVersions[0]]" sbNamespace depends on the deployEnvironment parameter. In our case, that is either 'te

Having one of my teams looking closer into Polymer, I am looking through the Polymer tutorial today , looking for stumbling blocks ahead of time so that they can be resolved by the time they get there. First off, if you're behind a corporate firewall, you'll want to make sure that bower can traverse any proxy you might have. You'll need a .bowerrc in your project folder, looking similar to this: Second off, you cannot test Polymer from your file system - you'll need to serve your resources from a web server. Provided that you have managed to get things started locally, let's get real - we want to use these components as UI facades to whatever services we might host in the cloud. Fire up Visual Studio and create a Web project. I started a ASP.NET Core project, 'cause that was the shiniest that I had available to me. In my VS solution, I created an elements directory in my wwwroot , pasted in my .bowerrc file in there and opened a console, which I used t