Top 10 games

It is difficult to come up with a top 10 list of anything.

For a start no two people will agree on these things. With video games there are so many it is impossible that everyone will have played all the best games.

I also find that my list changes over time, a lot of the time depending on mood.

Then, what does it mean to say best – how are you judging? With games, best gameplay, best graphics or most ground breaking. Most lists are a combination of these.

So instead of going for best – I’ll go for my favourite right now at this moment in time. The list is pretty nostalgic and I guess is in order of my attachment to them. It might be different this time next year.

Here is 20 while I’m at it. I did not give great thought to the order, particularly as I went further down.

The only series to appear twice are Zelda and Halo. In general I just went for my favourite in a series.

  1. Zelda Ocarina of time
  2. Goldeneye
  3. Halo 2
  4. Metal Gear Solid
  5. Half Life
  6. Resident Evil 2
  7. Tekken 3
  8. Mario 64
  9. Metroid Prime
  10. Banjo Kazooie
  11. Mario Kart 8
  12. Street Fighter 4
  13. Devil May Cry
  14. Gears of War
  15. Wind Waker
  16. Halo
  17. Monkey Island
  18. Lylat wars
  19. Crazy taxi
  20. Fifa 11
  21. Shenmue

Updated – forgot metroid prime

Premature Abstraction

In an ideal world every abstraction is pure. We don’t live in an ideal world (yet) though. Abstractions can be hard. They can cause frustration and people to give up on them or wait for the perfect solution.

In my experience, often the right thing to do is wait for the perfect abstraction but I think in a lot of cases it is right to go ahead and do the abstraction. You can always replace it or refactor it if need be but I think the key is not over doing it if not sure – keep it simple.

You want a good return on your investment and you dont want to make a brittle abstraction which limits peoples options down the line or causes tears and frustration.

Also, as with everything you should talk to people and get advice before creating your monster.

DIP vs DI vs IoC

There can be a lot of confusion at times about these terms. Part of the reason for this I believe is that there are a lot of different descriptions floating around – just google. Also all 3 are very much related and their names and functions overlap. I guess you are also getting deep into the belly of the beast so there is a little complexity there.

Here is what they mean to me.

Inversion of Control is a generic term, meaning rather than having the application call the framework, the framework calls into the application. To my mind that is all it means really, perhaps the difficulty is visualising this in your head. Part of this might be because there are so many different ways – this is why you can be forgiven for sticking to DI. None the less, IoC is a collection of different solutions to the same problem, including Dependency Injection (DI), Factory Pattern, Strategy Pattern, Service Locator and perhaps others.

Service locator is a little controversial and considered to be an anti pattern by some – I don't know about Strategy Pattern.

Dependency Injection simply means that a class has deferred and is a type of IoC. Responsibility of obtaining or providing its own dependencies; instead that responsibility resides with whatever wants to create an instance (there might be a better description out there than this). This can be constructor, interface or property injection. We tend to do a lot of constructor injection. Interface injection leads us to the DIP.

The Dependency Inversion Principle is about abstractions and has two parts (borrowed from elsewhere):

  1. High-level modules should not depend on low-level modules. Both should depend on abstractions.
  2. Abstractions should not depend upon details. Details should depend upon abstractions.

DIP is more of a natural fit with static languages but in my opinion is often desirable irregardless. DIP does add complexity in itself though and might not be worth it in smaller scale applications (micro-services) in organisations or legacy code / code that does not change a lot.

DIP seems to be considered less desirable and actually stirs strong, (I would say unnecessary) feeling and emotion in Node. This is because Node is dynamic (difficult to implement – is easier with Typecript) and projects tend to lean towards Microservices (not worth the complexity).

Can go deeper into the principle here:

A final point is that IoC Containers such as (DryIoc above) tend to facilitate all 3 and looser coupling of your code. As I said before, it can be a confusing topic of conversation but I think is a great thing for a few people to discuss together.

Single Reponsibility and Seperation Of Concerns in the real world

A straight forward example I encountered recently in a common lib I use at work.

The library is reasonably new and a work in progress I guess but the code has been in production for a while and the task was actually to merge the library with another ironicaly enough (side note: I read before that as opposed to the related principle Seperation of Concerns, Single Responsibility does not encourage over seperation). There is very little structure or code in both repos as is, the code to be merged was a utils library and the the other repo was a broader sdk. So I guess it did make sense to merge the two. 

I didn't want to complete the merge without dealing with a broadly named class called 'utils'. I had problems with the name anyway as the lib already had utils in the name. I have heard it said many times before that if you can't think of a good name for a class then you should probably consider splitting it up. This was particularly true here – and so I did. The utils class essentially contained file upload and file download functionality. The code in itself had been ported from one language to another and so I would consider it a little hairy. It was essentially an untidied grouping of functions relating to the two purposes already mentioned.

The upload and download functionality shared very little in the way of common functionality – I would have been less inclined to touch the class if they did. The download relied on axios and the upload the s3 sdk (Javascript). The upload had a little more complexity around security whereas the download was from a standard url (usually a signed url but not always). In my opinion there is no advantage at all in having these two concerns threated as one. So I seperated and the code base is better for it hopefully.

One thing I didn't do was group the File download and upload functionality into a files module – I left them with other utils such as a retry calculator and page counter.  As I said before the code base is quite small and I didn't want to over engineer. Also I am aware that I work with others who are less keen on abrstactions and so I don't want to step on toes or be rude. Thats important too!

Cheers to WordPress

I have probably said it before but will say again … WordPress is great. I spend most of my day writing and reviewing code at work and is nice to be able to write in words for a change. 

Word press is built with PHP – I know PHP has it's critics and sure there is a lot of hacked together PHP scripts out there but I am sure there are is a lot of good code also. WordPress is it's real success story (sorry not a facebooker) in my opinion.

In the past I have dug into the code base and found it a little hairy (used to OOP) – this was years ago though. I don't know what it looks like now, and whatever about the code base the ui seems to be orgainzed very well.

WordPress is just so flexible and straight forward and is great fun. Not sure about using it for businesses to be honest – have been there before and I think eventually you out grow it. Small businesses should be fine!

The Art of a good PR

This article is quite old now but feels like there is some good advice in here:

In my experience, pull requests can serve multiple purposes. The principal use is a peer review before merge but I think you can use them as points of conversation or discussion also and I don't think this is done often enough.

Also I think it is really important to convey respect and be nice. 

C# and NodeJs – a brief comparison

In the past these two had very little in common, however I thought I’d briefly compare as they are increasingly used together and becoming quite similar in places.

JavaScript is said to be a functional programming language with object oriented aspects and c# is the reverse really.

C# is compiled – modern JavaScript is compiled in a sense but not to the same degree.

C# was designed and implementation in a thoughtful and considered way – it is said JavaScript was built in 10 days (which is actually impressive if true). This is clear throughout the structure of the languages. Although JavaScript is very fluid – it has a lot of curious behaviours – equality statements as an example.

One of the biggest differences in the two is that c# relies on threading to support concurrency whereas node js does not, although threads are used under the hood.

They are quite different but increasingly more a like. Async await was first in C# but now also JavaScript. 

Classes are now also supported in JavaScript but not interfaces. Typescript is an option for those who want to go further in this direction.

C# has also adopted implicit typing with the use of “var”. And JavaScript as evolved by adding const and let. In C# you would add modifiers to make a variable a constant.

One of the biggest challenges I encountered recently was with array / collection mapping and filtering. Linq is the way to do it in C# whereas js gives you a few different options – lodash is what is used in my place of work. They are similar but a little different. I won’t go into detail here.

There are many more similarities and differences these are but a few….


Node Js


a departure from what is normal, usual, or expected, typically an unwelcome one


This is not meant be an insult or even a critism but more just a statement of how it probably is. It’s also not necessarily a bad thing although the use of the word aberration usually is as the the second part of the citation above states.

Node started off as a neat attempt at solving concurrency problems. Mainly, I think, due to the popularity of JavaScript and ease of adoption, it has snow-balled and in London at least, it seems node skills are very much in demand.

Ryan Dahl himself has said that he left Node behind as he felt that golang provided a better solution the issue of concurreny:

Perhaps if he stayed in charge of the languages development things would be different but I'm not sure if that would be for better or worse. From what I understand Ryan was for callbacks and against promises. I think he has since changed his stance but from what I read, there are still a minority of node developers who believe node should be callbacks alone and if you organize your code correctly callbacks are easy to read – perhaps they are right.

Both callbacks and promises seem very unintuitive to those not used to them and fit with the term abberation in that you need to think differently to the previously traditional ways of doing things. I have been happy to adopt async await as I am pretty comfortable with that from C# at this stage.

It is probably fair to say that Node and JavaScript don't represent the safest way of programming though. Dependencies seem chaotic at times. Package lock was introduced to make things better but is it's own special brand of chaos. Many of the packages up there seem to be well intentioned but maybe lacking in let's say 'polish'.

I think Node has helped a lot of people to get started with programming as it is so easy to get going. Issues are being ironed out as I speak.

JavaScript is the language of the browser so designers and people with a little coding experience are able to get more easily involved. In many cases the role of designer and developer have probably merged and I think JavaScript is partially responsible for this fushion of skills, although languages like PHP existed before and arguably have the same properties in terms of ease of use and learnability.

This is good and bad. There is more code but the code is not always better, and the problems tend to come further down the road. The point is though, Node and JavaScript have influenced the industry a lot. As well as getting more people involved, it has probably influenced the way other languages have developed, see C# and NodeJs – a brief comparison.

I’ve been programming with Node for 5 or 6 years (on and off) now and Javascript longer and I appreciate some of its advantages but I also see and understand a lot of the issues it creates.



Messaging Systems


Why use messaging at all ?

Recover-ability – if all else fails hopefully you will still have messages and once normal services have been restored, then you can proceed getting your systems back online, hopefully with minimal damage done.

Dealing with spikes in traffic – you want to make sure that you systems can handle load above it's capacity even if takes a long time to process each message.

There are probably other reasons also but those are two main ones I can think of right now.


I have used a few and here is a brief discription of each and a comparison of their value. 


Rabbit is written in Erlang. It is an interesting language and has the following characteristics, from wikipedia  – it is functional, fault-tolerant, highly available, soft-realtime (soft means tolerable if there is a delay in processing):

It is also known for it’s pattern matching capabilities which I guess are useful with topics (more later) and above all I guess concurrency is it’s principal strength – which is great when you are dealing with millions of messages.

I once spoke to guy who programmed in Erlang and he seemed so engrossed in the language that I am sure he swapped English for Erlang and was speaking to me like so.

It uses a protocol called AMQP.

It also has many client libraries in Js, C# and many other languages which are pretty well implemented. This shouldn’t be taken for granted!

Messages are submitted to exchanges and queues are bound to the exchanges. You can have one to one relationships or indeed one to many.


You can submit with topics which ensures only the consumers with that specific topic receive those messages.  Subscribing to the relevant queue with the correct topic ensure that you only get messages you desire.

You can host yourself or use something like cloudAmqp.


To SNS or not to SNS

This is Amazons messaging system. Can be used in conjunctions with SNS or on it’s own. When used with SNS – SNS works as a sort of exchange and SQS as the queue.

SQS uses standard http underneath and offers a polling model for subscription. Is a little primitive in my opinion. The client libraries are also pretty basic although people are starting to build better libraries on top. With dotnet as an example though, easynetq is much more complete than any client offerings in SQS – we have had to essentially roll our own.

It’s not as sophisticated as something like RabbitMq. It’s strengths lie in it’s simplicity and it’s ability to scale, also the fact that hosting is taken care of by aws means we don’t have to worry about that side of things and also that it plays well with other AWS technologies such as lambda Dynamo db.


JMS is from the Java community and is an API specification as opposed to a protocol like AMQP. It can use a number of different protocols underneath – we use tcp in our implementation.

Coming from a dotnet background I found it a little difficult as had to consume using a c# library called NMS.

It has various implementations and the one I used was called ActiveMq. It us open source and relatively easy to install although creating and consuming messages is a little trickier.


All three options are useful depending on your needs. Rabbitmq probably has the nicest feature set but is not the easiest to get setup and started. Sqs is a better option if already using aws and I guess jms / active mq is nice for those who use Java. 

There are other options also such as Kafka but I would encourage you think if you really need the complexity of a messaging system before implementing as it does add it's own complexity.