Posts

Sql Static Code Analysis (revisited)

Static Code Analysis. You may remember my opening gambit in a post about SSDT code analysis talking about coding standards back in May 2014 (but most probably not)  It went something like.... Coding standards (and more latterly styles) in any organisation of any size are liable to incite religious wars and makes zealots out of even the most considered or apathetic of us.   Inconsistency and subjectivity,  lack of enforcement and heavy handedness all contribute to the contempt often levelled at them... blah blah Contributing to solving the problem. As part of one of our projects we had some funding to invest some time  and dev into SQL static code analysis, after researching what was available we had the green light to incorporate analysis written to leverage the SSDT code analysis framework into our own CI/CD ALM framework.  The appetite for this waned somewhat with the DB community having their own take on what they wanted to use, but the code lives on and some small bits of w

Async/Await Revisited

I put up an article back in November '14 about using async/await for a toy project I had created.   I have now had a chance to use it for "real work" and, as a result, have had a chance to research the language feature in more depth and have come up with a list of considerations, resources, gotchas and tid-bits.    Must Reads There is a lot of literature available for this feature and plenty of MSDN articles and Stack Overflow related help, however, I'd highly recommend the following books for greater insight into TAP, TPL and async/await:  CLR via C# (Fourth edition for async/await content), Jeffrey Richter Concurrency in C# Cookbook, Stephen Cleary Async in C# 5.0 ,  Alex Davies Blogs by the latter two also cover this feature in great detail. They all overlap in their coverage on async/await. As an aside, the first book I would recommend to any serious C# developer anyway, I'd say its on a par with the "C Programming language by Kernighan

A little bit of powershell in my life

Things were so simple then. Having used 'nix at University and a bit beyond  I came to love scripting, using things like Bash and tcl,  prior to that I had just written a few simple batch scripts in DOS.    Excluding JavaScript from the fray which doesn't, arguably, fit in the same category as lower level scripting languages I really haven't done much apart from a bit of Perl and  although its called a scripting language it is a high level programming language.  Years later, and after having been indoctrinated into the Microsoft Stack, I have hardly written any scripts or have had any need to, but that is changing. ALM My current place has a few bits of software that use Powershell and, some,  lots of it. Its the tool/language of choice for the ALM framework developed in house, used to push software out from local environments to production  environments (in some cases).  The framework consists of 100s of scripts and XML configuration files, to map to the myriad of

Messaging and transient issues.

Messaging and transient issues. A small post but something worth considering.  Recently when discussing a situation where a MongoDB replica set was in the process of failing over, concern was raised about writing data - whilst a new primary was being elected.  This is going to be a transient issue and issues similar to it - such as temporary server outages and routing  are too .   They are going to take a little time to resolve but should resolve fairly quickly. In the meantime, there a re a few solutions available whilst this transient issue sorts itself out:   Do nothing.  In this case give up and find another job  you lazy hacker. Let the process fall over, report  the failure to users and let them try again via a button click. A users experience might be sullied - in the opinion of some -  but it still could be a reasonable way to recover (this depends on what stakeholders/business think really).  This might not be reasonable for important information which must stored

Async/Await

Async/Await As I am sure you are aware, this is not a new feature in .NET - having been around for over a year as part of .NET 4.5. There have been plenty of posts about it, and so I'm not going to go into a great deal of depth, as I am not an expert and there are people who have gone into it in more depth than I could.  I just want to get a couple of  the key concepts up and provide a laymans tilt on it.  I've been using the language feature as part of a site I am developing as a platform to testbed a few technologies including: Knockout.Js,  The continuous integration and continuous deployment capabilities of  Visual Studio Online (formerly Team Foundation Service) WebAPI and integrating with 3rd party  web services Some of the newer C# language features  Bootstrap templates  Stanford Core NLP for .NET    The site is work in progress and is available @ http://wearedev.azurewebsites.net/ The main purpose of the site is as a front end for a simple aggregatio

MongoDB

Mongolicious MongoDB training, provided by MongoDB themselves, was up for grabs recently, so I put my name in the hat to get a keener insight into MongoDB and NoSQL databases, having used them only a few occasions. The training was attended by a near 50/50 split of devs and DBAs and this led to some interesting debates and reactions.   Like lots of the stuff I've been introduced to/have started looking at recently (I am late to nearly every technology party there is) they (Mongo and NoSQL) have been around for a while and have become established as a viable alternative persistence solution to the likes of MSSQL.  The main features: Its schema less Document oriented/No support for JOINs  Querying performed using JS/JSON Indexing Replication/Redundancy/High availability Scaling out via Sharding  Aggregation (unfortunately we ran out of time so this is not covered here) Authorisation (again ran out of time on this one)  Its schema less You'l

TFS and integration test builds from Shelvesets.

Image
Our team have been involved in a fair bit of release activity, as of late. We are gearing up for our wagile (our previous CTO's term not mine) project's big bang release to production. Due to the release pipeline we have been forced to release our changes with another team.    The code resides in 2 different branches, both of which are branched off of a main branch.  However, in TFS terms, these are unrelated until at least one merge has taken place (a baseless merge).  Quite simply we have the following arrangement: a (main) b (us)   c (them) It was decided that we should merge our changes in (b) into their changes in (c) and then use the build resulting from the merge to push out to an integration environment, where our testers would run any remaining manual tests (or kick off any semi automated service/integration tests)  Forgetting the fact this would actually be a baseless merge in the first instance, actually performing the merge and getting it out,  would