Posts

Showing posts from June, 2014

The woes of coding by assumption

In a project we have a scheduler type service that polls an Azure Queue for work and does it, e.g. sending some emails. I've been confused about our number of storage transactions ever since I joined the project. It was at least 100 times more than my back of an envelope calculation estimated there should be. I installed Application Insights to try it out and, after I published, it informed me that one of the apps (the scheduler) was sending 250+ requests per second to Azure Queues. What the hell right? I took at look at the code and it was the sort of thing I was expecting: void Start() { _timer = new Timer(PollQueue, null , _queuePollingInterval, Timeout.Infinite); } void PollQueue( object state) { // check the queue for new work and do it. if (_timer != null ) _timer.Change(_queuePollingInterval, Timeout.Inifinte); } All looks good right? The entry point called Start() which in turn sets up a timer to called PollQueue(null) after the specified _queuePo

Exporting data from SQL Server by generating an insert script

Image
I was moving some data between a couple of databases the other day (just data from a couple of the tables). Basically, I'd created a new feature, tested it a bit which had generated some entries in a new database table and I wanted to move these to the test system. I was about to do my normal "right click source database -> tasks -> export data..." dance when a colleague mentioned that I could just generate an insert script for the data to either a file, my clipboard or a new query editor window. I couldn't believe I hadn't found this gem before... Although it is reasonably hidden! I gave him the Control+Shift+R short cut for refreshing SSMS intellisense local cache so I guess we're even now. Anyway, the steps: Open up SQL Server Management Studio Expand the databases node in the Object Explorer Right click the database that you want to generate a script for and go to Tasks -> Generate Scripts   Database node context menu

Common pitfall with async in C#

Just a quick rant today... :) I love how easy it is to write asynchronous code with Tasks and the async and await keywords in C#. One problem that I keep running into is this kind of thing in code examples on line. public static T Value<T>( this HttpContent content) { var task = content.ReadAsAsync<T>(); task.Wait(); return task.Result; } Now there's a couple of problems with the above code. Whoever wrote it obviously thought it was going to do something magic, after all - they've chosen to use the  ReadAsAsync<T>()  method! Unfortunately, the very next line calls Wait()  on the returned  Task . So the  Thread  that could have been doing other work while the content was being read is just blocking anyway. I.e. there is no benefit at all to using the Async code. There's also the fact that accessing  task.Result  would have blocked anyway meaning the  Wait()  was pointless. This code was checked in with the comment "Repopul