Showing posts from August, 2013

How do they do it – the right way to write software

[Concrete / Interesting] Sitting at my desk and looking at the plans for the next scheduled release of our enterprise application and, oh boy, this looks like it’s gonna take forever. Not an unusual thought to pass through the mind of a development manager. But wait, does it really have to be this difficult? Is there a better way. How do they do it?On another subject, one of the guys in the team shows me Trello ( – 5 minutes in and it looks like the right tool for the job.It’s a line of business application and it does what it says on the tin. Then my mind wanders and I find myself asking “how do these guys make any money? how do they write this stuff and sell it for nothing? how do they do it?”. So I dig a little deeper and the clue to how is to be found at the following URL:, behind the web client, iOS, Android and Windows 8 clients, there is a business level REST API. And take a look at the structure, API nouns based on key business entitie…

Performance Boost for XML Stored Procedures

[Concrete / Mildly Interesting] Sometimes SQL Server makes you want to pull your hair out. If you are using XML types in your stored procedures and seeing some  very poor performance, I may have an answer for you in this post. XML is working, but maybe a little too hardToday I was looking at the performance profile of one of our applications and after a little digging I noticed that a stored procedure was performing rather poorly. We pass a lot of parameters to some of our stored procedures and when we do this we use XML. This technique allows you build parameters using LINQ XElement types and with LINQ to SQL, simply pass the XElement as a parameter to the stored procedure. It’s a great technique so it’s even more disappointing to see it perform so badly. And what’s worse, it seems it’s the simple operation of fetching out the data using nodes() that causes all the problems.To illustrate this, take a look at the following XML:<Transaction>