Posts

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

DDD or not to DDD? That may or may not be the question.

DDD I've had/am involved with my first commercial experience of DDD, or at the very least, something heading that way. My team are developing their first DDD software component.  I didn't realise I was at least 10 years behind the leading edge ( the year  which Eric Evans seminal work DDD was published was the same year I started my career as an embedded software developer, which is as close to enterprise development as Pluto is to the Sun)    DDD Quickly After being in a few larger organizations and having dealt with a fair few types of design approaches (ranging from monolithic to typical n-tier), it seems  that DDD has finally achieved mainstream adoption in the industry and the shit kickers - I include myself here -  are just about ready to consume it, and murder it potentially :)  I have read "DDD quickly" on InfoQ, which I would highly recommend to get a flavour for DDD in general, and have recently started reading  "Implementing DDD" by Vaug

Currying and Closures

Just a quick one Closures might be well known amongst many C# practitioners - apart from  me it seems. I read about them ages ago and then haven't knowingly applied them.  Of course, I have been using them  (or at least a variation on the theme) often in C# by virtue of using 'lambdas in lambdas' when using LINQ for example, and lambdas which refer to variables in the method in which they are created.  I mentioned functional programming including Currying in the last post, and this is still my current focus, its satisfying my ADHD for the time being.   Anyway, It turns out that if you want a bit of a better understanding of how Currying works,  then understanding closures can help you  take a leap of faith.  Currying in Haskell The following example is taken from Learn you a Haskell The function multiplies 3 numbers together and returns the result. The  first line defines a function, multThree,  which can be read as  taking 3 arguments and returning a valu