Posts

Testing, Testing, 1.2.3.4.5.6..ad infinitum

Before testing... I've now been in development/engineering/coding/hacking or whatever you want to call it for more than 10 years.  Testing has always been important, but it  - in my line of work - is now at the forefront of everything I do.    For the business this is great, every line of code, component and group of components is covered by some set of tests. Be it unit, integration, component...the overloaded terms go on.   This means that a set of requirements -  to some degree  - have been determined to have been met by these tests and the business is getting what it wants (all manner of development and agile practices not withstanding - they all get us to the same place) It struck me today though that earlier in my career, when testing was still important but lines were  - perhaps - a little more blurred and things were a bit more hit and miss, things were less clinical, less contrived and quite frankly less boring.  This is obviously not a good model for delivering qual

1..2…3…Freeze….Peak

I haven’t written anything for ages as  I’ve been the busiest I have ever been at my current employer – a large E-Commerce Website -  as a result of preparation (planned and unplanned) for its largest ever “Peak” weekend, my company’s name for the Black Friday weekend.     Sorry this is a long read so grab a coffee or skip to the Summary, or don't read it! I’ve started writing this on the train coming back from London where I was required to provide extra-support for the Payments Platform (Domain)  - where I ply my trade – a group of Microservices and Legacy components supporting Payment processing for the Website and sitting very closely to the Orders Domain.  I expected to be bleary eyed and wired to the hilt, full of coffee and adrenaline as me and my colleagues worked like mad to pull out all the stops to make our giant incredible machine work properly. But no, as our CIO put it, everything just worked (well 99% of the time – more on this later).  The freeze

Learning to TDD is like learning to drive a car

Its true (well sort of) When I was learning to drive I was pre-occupied with where to put the gear stick, where it actually was, when to use the clutch and so on and so forth and being flustered all the time. But, quite quickly, with continued practice and with growing familiarity and confidence with a car, I could think about where I wanted to go instead of every detail of what I needed to do, to get there, and now I drive like Lewis Hamilton. Before  I could start to TDD fairly well (In my .NET C# world) and be able to decide what works for me (for example choosing when to use classic and mockist TDD) I had to become comfortable with some pretty basic things including a good refactoring tool - ReSharper , a good test runner and Unit testing framework like NUnit and a good test isolation (mocking) library, like Moq (all of these tools have their proponents and detractors)  but this is what I use for the majority of the TDD I do at the moment, this could change, but the principl

Newline character is 1 character

I will never forget the above When using substring and you can't work out why "\n" is not 2 characters refer back to this title.  Does it make me look stupid, Yes, hopefully I will work this out sooner next time.  To be fair to myself its like and and.  That is all. 

A Beautiful Solution?

Image
^^Perhaps^^ For various reasons me and my team hadn't been spending a lot of time at the coal face, coding.  From spikes, POCs and analysis to release activity -  coding opportunities have been few and far between. Thankfully this changed over the last couple of weeks. As part of the Payments Platform we have been given the opportunity to chip away at some of the Legacy processes to provide more flexibility in our Payments offering.  Part of this process see's us hoping to consolidate some existing logic to manage the integration with a 3rd party Payment Solution Provider more flexibly.  Specifically around handling particular types of payment which are handled differently based on certain criteria such as a customers Billing country, what currency they are paying with and the card type they are using.   Stuck In essence the work we are carrying out is a redesign and re-factor of some logic which is spread out in a number of places.  Bringing it all in, has been both  i

Book Review: The Software Craftsman: Professionalism, Pragmatism, Pride

Spur There were a few things that made me read this:  I saw it lying on my dev managers desk We have a coach from the company that the author co-founded in our place at the moment I was cynical about the software craftsman idea and thought it was about self-serving, elitist and pumped up self publicists Inspirational   I'm not a soppy or effusive person, but I have to say this book really resonated with me and, like a really good rally call,  made me feel positive about my current position and how to sustain and develop my career further and just how I might achieve this. The thing is , I knew most of this already but just hadn't bundled the virtues, thoughts and values that are described, under a particular banner.  The Software Craftsman Manifesto It actually exists!  A set of values to which a software craftsman can hang their hat.  Now, like the author says, there are people who don't like to call themselves craftsman and I am one of them, but the ide

Book Study: Patterns-Principles and Practices of Domain Driven Design

Book Study: As title Summary In summary this is an excellent book.  It is really accessible but some of the more advanced areas will need further reading elsewhere. For example, things like Aggregate design  If you are involved in Enterprise application development and you haven't yet been able to take advantage of the Domain Driven Design (DDD) philosophy, this book will show you the way. I know this because it is almost like a narrative to my experiences of the philosophy at a large e-commerce website in terms of some of the problems experienced, practices adopted, conversations with the business and stakeholders, patterns used, misused, abused and not used and every conversation about everything in DDD in-between. Go Compare I previously read the fist 3 chapters  of Vaughn Vernon's Implementing DDD book and I ran out of steam for various reasons (the birth of my second son primary amongst them). Its not that it isn't a good book (I refer to it later on and why