Thursday, 31 December 2015

Year in Review 2015

January

February

March

April

May

June

July

August

September

  • This year the concepts and ideas in Release It have proved incredibly useful.
  • A key principle I have applied this year is to write less code, truly following the benefits of DRY and KISS.
  • The use of the self shunt pattern was provided as a simply testing strategy.

October

November

December

Tuesday, 22 December 2015

Recommended Reading List 2015

In a similar manner to previous years here is my recommended reading list for 2015. As before some of these books have been released for a while, but these are some of my highlights for various reasons.

Code

Dependency Injection in .NET
I had put off reading this book for a while despite numerous teams having a copy. It turns out a good chunk of the book is applicable to any language, with the later third being dedicated to actual .NET solutions. The other two thirds of the book has expanded my understanding of DI.
Effective Java: A Programming Language Guide
Many developers recommend this book even for non Java development. Many of the tips and advice included we not new to myself but the book provided further insight and explanation. A good summary of best practices for any OO developers.
Web Application Security, A Beginner's Guide
A good introductory book on security which provided a useful refresher for myself as well as providing a platform for further research on some of the key areas and topics.
Enterprise Integration Patterns
A useful sequel to expand on Patterns of Enterprise Application Architecture. This book focuses more on messaging concepts, going into detail on a number of topics. The content of the book is expressed in technology agnostic terms, which has been incredibly useful when applied to actual implementations.
REST API Design Guidelines
Much of the guidelines in here fall into the category of common sense or industry experience. Despite this the guidelines provide great justifications for API design. An essential reference for any REST API.
57 Exercises for Programmers
A highly practical book in the sense that the book is full of over sixty practical tasks. Many of these fall into code katas which are ideal for learning new languages or just staying sharp.
Practical Object-Oriented Design in Ruby
Despite the name this book applies to OO development in general while the examples use Ruby. The ideas and concepts expressed in this book have changed my view on OO programming. If anything the book will make you think differently about how to design and develop solutions.
Fifty Quick Ideas To Improve Your Tests
A light read with each chapter dedicated to a single, focused topic. Many of the ideas are well known practices but with expanded justifications and recommendations.
HTTP The Definitive Guide
The guide to HTTP if you are a developer. Each area is explained from high level concepts down to the nitty gritty details.

Process

Implementing Lean Software Development: From Concept to Cash
A great summary of applying lean concepts to software development. Much of the content is familiar though the ideas applied to software development makes this book stand out. This acts as a useful refresher for lean processes as well.
The Lean Startup
One of the most inspirational books I've read this year. Full of useful and tested practices that has changed my perspective on beginning a startup. Interestingly much of the advice can be applied to individuals working within larger organizations on smaller projects.

Tuesday, 15 December 2015

Reducing Conditional Logic to a Single Location

My Anti If Campaign post still generates a lot of questions and discussion. In summary:

  • Conditional statements are not bad. They are a core programming construct.
  • If you are working in an OO language, type checks are probably not the best solution to your problem. Rely on polymorphism.
  • You need to perform conditional checks somewhere. In my first example the conditional check was pushed into routing. The conditional statement in this case had been offloaded to the consumer.

A recent real world example was refactored which highlighted the points previously, but inverts the problem and solution. How do you remove conditional statements if your system itself has to make the decisions internally?

Example

The simplified example shows the result of invoking a third party service. This result contained a flag indicating either success or failure. Effectively there were two hidden types here. Finally the result was returned based on the HTTP status code.

After the result of the third party call, the domain would decide how to respond.

Both the client and the domain logic was split over multiple source files. This made noticing the duplication tricky. Both the client and the domain also knew the fact that the result of the third party call can succeed or fail.

Sadly the domain violates the SRP at a method level. While not a requirement yet, if further status codes are required or the contents of responses controlled flow, we are in trouble. The type flag would need to evolve from a boolean to something more complex. The contents of the responses may also need to be provided. This solution could leak HTTP details down into the domain unless careful.

Solution

Recognise the boolean flag is actually hidden two types. Remove the flag and introduce a concrete type for each path. Each concrete type performs the right operation. In this case executing the relevant methods within the domain.

Each concrete type is easy to test, change or throw away. In this example an interface is provided. This contains just the necessary methods that the process requires. The domain is now simplified. The domain instance itself is simply provided as an argument. The concrete instance of each result will perform the right operation.

Benefits

  • Now possible to add and remove additional redemption handling easily.
  • The procedural code remains on the boundary of the system. There is no need to try an use OO concepts here. Keep it simple.
  • The domain becomes flexible and removes the procedural checks. OO concepts can be applied as much as you like here.
  • The redemption service works with anything that can play the role of a redeemer. Open to refactoring.

Closing

Stick the procedural code on the edge of your system and be done with it. Just ensure that you only perform such checks once.

Just because you are not performing explicit type checks, the use of boolean flags usually indicates at least two hidden types.

The anti if campaign is not the removal of all conditional checks. They need to happen somewhere. Just try to limit them.

Tuesday, 1 December 2015

ReactJS and JSHint

The ReactJS Getting Started Guide states that the recommended way of using React is combined with npm.

This is great but poses a problem when trying to use JSHint. The default example outputs a single JS file containing both your code and the React library. The end result is the bundle when linted contains code you don't and shouldn't need to care about.

The guide does provide a solution, though not as clear as it probably should be. Offline Transforms. These will transform your jsx files into plain Javascript without bundling react alongside.

babel --presets react app.js --out-file main.js

Simply take the result of the transform and perform your linting process.

jshint main.js

This may seem obvious but I did lose some time realising the benefit of offline transforms.

Offline transforms do require that you either bundle the transformed file with React, or you simply include the standalone JS scripts in your html. This can be done after the fact. JSHint can then play nicely with your React apps without the need for other tooling such as wrappers or text editor extensions.