Other articles


  1. The QA Test Matrix

    Published: Mon 03 April 2017

    tags: testing

    Historically teams I've worked with have taken a few varying approaches when designing tests against acceptance criteria. One is to have the business define the feature, while the team help define the acceptance criteria. Ultimately the business gets the final say if they agree, and further acceptance criteria is either …

  2. Be Humble

    Published: Wed 18 January 2017

    tags: retro

    Some of the best developers I know treat everyone with mutual respect. Not only this they are open about what they do know and what they don't know. In fact they'll often proclaim “I don't know” and go about finding out how they can answer your question or solve a …

  3. Convention Based Tests

    Most projects have some form of convention. Examples would include:

    • Attributes/Properties for REST API's
    • Inheritance for third party base types
    • Assemblies/Packages for third party code that is loaded dynamically
    • Folder or namespace conventions
    • And many other forms of conventions

    In a few of these examples static analysis can …

  4. Finance For Software Developers

    Published: Wed 04 January 2017

    tags: tutorial

    Back at the start of 2016 I set about sorting my personal finances out, inspired by Soft Skills. The book makes a point to consider passive income as a viable solution to wealth building. The reason for this is simple, software developers tend to get paid well if working professionally …

  5. DDD - Events

    Published: Tue 01 November 2016

    tags: tutorial

    The act of something happening is one of the most crucial aspects of implementing Domain Driven Design (DDD). I missed the importance of domain events when first exploring DDD.

    Why

    Most requirements come in the form when something happens, do this. Something in this case would be an action, and …

  6. Constant Object Anti Pattern

    Most constants are used to remove magic numbers or variables that lack context. A classic example would be code littered with the number 7. What does this refer to exactly? If this was replaced with DaysInWeek or similar, much clarity is provided. You can determine that code performing offsets would …

  7. The New Guy

    Published: Sat 01 October 2016

    tags: retro

    Everyone is new at some point. No matter your experience level. You're either new to the team or new to the business. Being the “new person” is both a blessing and a curse.

    You're New

    When you're new you come with no baggage. You're full of questions and curiosity.

    • Why …
  8. New and Shiny Things

    Published: Thu 01 September 2016

    tags: retro

    There is risk with upgrading anything, be it language, framework, library, OS or third parties.

    In the past I was rather gung-ho about upgrading. New version out? We need it. In fact, this need is often a want. The new version often seems better. Developers seem addicted to the latest …

  9. Past Mistakes - ORMs and Bounded Contexts

    Sticking with the theme of documenting past mistakes, it's worth expanding a real life scenario where I was unaware of the use of bounded contexts and fully understanding the tools you use.

    Ignoring a Bounded Context

    A fellow developer set upon a quest to rid numerous projects of duplicated records …

  10. Test Your Live System using Live Service Tests

    Published: Mon 01 August 2016

    tags: testing

    Traditionally there are three categories of functional tests.

    • Acceptance
    • Integration
    • Unit

    This is often refereed to as the testing pyramid. Unit tests form the bulk of your suite, followed by a smaller subset of integration tests. Acceptance tests that cover features should be the tip of your testing strategy, few …

  11. Why You Should Do Code Katas

    Code katas are simple exercises that are meant to be repeated. They are great for learning a new language or tool. The goal is to learn something, not to complete them. In fact, if you don't finish a kata that is perfectly normal as long as you take something away …

  12. Notes on Building and Deploying Software

    Builds and Deploys

    Ideally a build and deploy should be a single step, included within the check out of the repository. Additionally the build should include and install pre-requisites if missing. You can safely assume the target OS is at least configured, but any missing packages should be installed as …

  13. Ten Lessons from Rewriting Software

    Published: Fri 01 July 2016

    tags: retro

    1. It Will Take A Lot Longer Than Estimated

      • Its navie to actually think this but if a system has been in production for say five years, expecting to reproduce it in five weeks is not possible. You may be able to get 80% of the core functionality done, but the …
  14. Anaemic Domain Models and Code Smells

    An anaemic domain model (ADM) is considered a code smell in many cases. An ADM is present when you have a entity representing your domain, but void of any behaviour. Any logic is separate and operated upon in isolation. Such domain models can be thought of as simple property bags …

  15. I Need to Stop Misusing Divs

    Published: Fri 01 July 2016

    tags: retro

    I a certainly not a skilled or expert front end developer. While I'm more than capable of creating pages I lack any design magic to make them look half decent. Despite this one area where improvement can be made is in my markup itself.

    Over the past few months I've …

  16. UI Composition Techniques for Services

    When using services be it SOA, microservices or some other hybrid approach, at some point you will need to display an aggregation of data onto a UI. This simple task can actually involve some complexity and hidden pitfalls.

    As an example, this blog could be powered by three independent services …

  17. DDD - Bounded Contexts

    Published: Tue 14 June 2016

    tags: tutorial

    A single domain can grow large when applying Domain Driven Design. It can become very hard to contain a single model when using ubiquitous language to model the domain. Classic examples prevalent in many domains would be Customer or User models. A bounded context allows you to break down a …

  18. Given When Then Scenarios vs Test Fixtures

    There are two common ways of writing automated tests which apply from unit to acceptance tests. These are typically known as test fixtures and Given-When-Then scenarios.

    Test Fixture

    • Traditional method of writing tests.
    • The common JUnit/NUnit approach. Other languages have very similar concepts.
    • Single test fixture with multiple tests …
  19. Foreign Key Constraints and Microservices

    Database constraints when used in relational databases are great. They ensure data integrity at the lowest level. No one would argue against using them in practice. Essentially constraints can be thought of as assertions against your database. Rules such as requirement, default values and foreign key constraints double check your …

  20. Past Mistakes - Out of Process Commands

    Some of the best lessons you can learn are from failure. I figured a series on mistakes I've made in the past would highlight where I went wrong and more importantly what to remember going forward. These real life examples vary from my early days of programming all the way …

  21. You Rarely Need Custom Exceptions

    Implementing custom exceptions usually gives a hint as to why you rarely need custom implementations. They are often nothing more than sub classes where the only difference is the type name and containing message.

    In this C# example there is a lot of code for nothing. When checking logs or …

  22. Your Job Isn't to Write Code

    Solving problems is the role of software developers first and foremost. The most interesting aspect is that in many cases it is possible to perform this role without writing a single line of code.

    Low Tech

    I once worked with a digital dashboard which monitored applications. One of the yet …

  23. Project Setup Tax

    With microservices gaining popularity, one consideration prior to adoption is new project setup. In fact this statement holds true for any new project that you decide to create.

    Each new project requires at a minimum

    • Source control - somewhere to actually store the code.
    • A project base - API, executable, library, application …
  24. X% of Configuration is Never Used

    Code configuration is essentially for the likes of URLs, credentials or other per deployable settings. Sadly configuration seems to fall into examples where there is simply too much configuration, or the system has so many configuration points the actual code becomes far too complex for its own good.

    Too Much …

Page 1 / 5 »