Techie Head

I've been reading a lot about cloud patterns recently (e.g.  from microsoft ) and one thing I've really wanted to do is move background processing to a worker role. To get started I decided to move our recurring jobs that we were running in the web role to a worker role because there are  some limitations  that are hard to avoid when running background work in ASP.NET. The idea was simple - set up an Azure scheduler to put items on an Azure Storage Queue and have a worker role polling the queue and reacting to the messages. For simplicity, I created a simple wrapper for the queue messages  public class CustomMessage { public string TypeName { get ; set ; } public string Payload { get ; set ; } } Then when I queue a message I serialize an object to JSON with JSON.Net and create an instance of the CustomMessage class to put on the Queue. I actually have a service which maps from the CustomMessage to a CloudQueueMessage and vice vers...

This post is more of a warning to other people than anything particularly ground breaking. Please, please, please check the collation you're using when you create a new database on SQL Azure. Choosing the wrong one can be a major annoyance and a source of subtle bugs. On one of our databases we have a default collation of 'Latin1_General_CP1_CI_AS' but it was migrated from a server with a collation of 'Latin1_General_CI_AS' - so most of the columns in the tables had that collation. This may not seem like much of a problem but we have had a few bugs due to it: Entity Framework - collation conflicts (not sure if still an issue), silent failures... Foreign key problems when adding new tables etc. In order to make sure we don't have any conflicting collations lying around I wrote a simple script: select '[' + t . name + '].[' + c . name + ']' as ColumnName , c . collation_name as Collation_Name from ...

I used to work with SharePoint and it gave me some of the most frustrating days of my life. On the plus side, I've been complimented on my "tenacious" approach to problem solving that I'm fairly sure I can give SharePoint the credit for creating. One of the most annoying things I found about SP was deploying packages. I used to hand off a .wsp to the infrastructure team who would valiantly go off and deploy it. As soon as something went wrong, they'd just come back and ask for help - they had enough to deal with without having to learn SharePoint's nuances. In order to help them, I created a simple script that was mostly fire and forget. The code is available as a  gist  it's only designed to work one feature at a time but I think that should be easy enough to modify. ############################################################################################# # This script deploys a feature to a SharePoint 2010 farm. ...