About Links Archives Search Feed Albums of Note

DDD East Anglia in Review

And so it was that, inspired by the grand prix at Silverstone, we found ourselves pelting towards Cambridge at somewhat naughty speeds for the debut DDD East Anglia. A glorious day it was with good weather, good talks and good meets with friends and new faces alike. The rooms were perhaps a little stuffy but that small gripe aside, Phil Pursglove [http://twitter.com/philpursglove] and crew deserve a massive vote of thanks for organising it all, the staff at the Cole Hauser forum (not named after the actor [http://en.wikipedia.org/wiki/Cole_Hauser]) for the food and drink, and the speakers for the sharing of their knowledge.

I was able to attend four sessions today as well as the grok talks which I presented with Dave Sussman [http://twitter.com/davesussman] and Richard Dutton [http://twitter.com/dutts303].


Pragmatic Dependency Injection - Ian Russell (@ijrussell [http://twitter.com/ijrussell]) Ian’s talk focussed on demonstrating the four main patterns in refactoring your apps to use dependency injection:

  1. Constructor Injection : allows you to set your dependencies in a single composition root using the Decorator pattern to add functionality to our classes. However this “poor man’s DI” can get quite complicated quite quickly (as Ian demonstrated). A DI container helps to alleviate that problem. 2. Property Injection 3. Ambient Context pattern : allows you to get around non-deterministic functions and classes like DateTime.Now, Guid.NewGuid() etc 4. Abstract Factory pattern : allows you to inject the right class at runtime perhaps based on user input.

He then wrapped up by refactoring his demo code to use a DI container – in this case, he used Ninject which makes use of generics and eschews XML. He showed how to set up the container and then how to use the “Register, Resolve, Release” pattern to use the container within our code. Finally, he noted that you have to get your code in a good state before you should start using a DI container else it will start ‘fighting the container’.

The code for this talk can be found at https://github.com/ijrussell/DDDEastAnglia.

Ready Set Go!! – Mark Rendle (@markrendle [http://twitter.com/markrendle]) More a demonstration to show exactly how much you can achieve in one hour (after three hours sleep and a tyre blowout on the M11 the night before) if you really know your stuff, the ever affable Mark Rendle provided wry commentary while writing his own to-do web application using Simple.Web, Simple.Data, TypeScript, and AngularJs. Points also go to Mark for originality, spending at least five minutes trying to get an exception thrown when the app seemed to be working fine. Inspiring stuff.

Proving how much power this particular toolset has, Mark pointed out that his start-up Zudio [https://zud.io/] uses exactly the same setup to implement its alternative Azure administration UI.

Better Unit Testing – Isaac Abraham (@isaac_abraham [http://twitter.com/isaac_abraham]) Isaac’s talk focussed not on what unit testing is, or the basics of it, but rather how teams should approach it to make it work better and give a better return on investment, noting that it is very hard to do well and that each team will have a different definition of what a good unit test is. Additionally, the main question is how to reduce the time it takes to write them before they improve your code and reduce your cost of development.

Unit tests must be trustworthy. Developers must have confidence the code works by passing tests rather than pressing F5. Unit tests must be treated as first class citizens in the code base, easy to maintain and well documented.

Developers must identify units precisely and ensure there is full test coverage of a unit in order to realise the benefits of TDD. This is not the same as 100% code coverage. If units are only partly covered by tests, hidden bugs may appear in the code and confidence lost in the test suite. Furthermore, it is harder to add unit tests retrospectively to brownfield code, and it can be the case that the false sense of security allows additional bugs to enter the codebase purely because you’ve forgotten to completely cover your units.

Isaac also offered the following suggestions for writing unit tests.

In conclusion, the aim of every development team with respect to TDD should be to believe, trust and listen to their tests.

An Intro To Octopus Deployment – Joel Hammond-Turner (@rammesses [http://twitter.com/rammesses]) Octopus is a Continuous Deployment server built around Powershell and nuGet that creates a robust and reliable way to commit and rollback deployments of your software into various different environments : CI server, development machines, integration testing, UAT, Live, etc. In this talk, Joel gave an overview of how Octopus achieves this and then a live demonstration. He also made the following notes

Posted on July 3, 2013   #Attending Events     #Speaking  

← Next post    ·    Previous post →