We Are Devs

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 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

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

Training I was lucky enough to have had the pleasure of attending an introduction to Domain Driven Design, CQRS (coined - in part at least - by the presenter himself)  and Event Sourcing by Greg Young at Skills Matters in London last week.   It was snappy, contentious - at times - and very informative and definitely gave me  a lot of food for thought, I now have a reading list as long as my arm.    As an added bonus, the people who attended, as well as Greg himself, were approachable and easy going, as the beers after will testify to.  The background to me getting on this course,  is that we are currently going through a massive set of architectural, infrastructural and cultural  change at my current employer, and this course has set me up to be asking more searching questions and provide input on some of the stuff we are currently doing and are planning to be doing soon. I'm not going to write about any of the above though, a quick search will elicit a million articles, and

Static Code Paralysis. 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 leveled at them.   Sod it. I say sod all that, if you or your company aren't using static analysis tools  then you are missing out on improved code quality and productivity (borne out from a consistent approach) and reducing the most banal and mind numbing conversations and sometimes pissing contests associated with discussing the minutiae of standards.   As an aside, having a few years under my belt  in the industry  I've found that people who "really" moan most about this are usually rabble-rousing morale sappers who like to moan about everything, so it stops them doing this and maybe might lead to them getting on with work instead! Makes thin