After going through the FPS Microgame I realised that all these mods required you to pay for them, so I dropped that and searched for something else. It wasn't long till I stumbled across this 2D RPG game called Rubys Adventure.

I've been going through the tutorial on stream, here is the first of a few streams following the tutorial.

As I've started to take up streaming and learn the Unity Engine I decided I would start with one of the in-editor tutorials. They have these "microgames" that are available, I've picked the First Person Shooter one.

Anyway here is a video of me working through it:

Thanks for watching, I'm really excited to see where this goes.

​Cheers :)

So during lockdown I've been looking for something productive to do that will kil the time. I've been gaming a lot and have decided to start doing some Twitch streaming. Whilst doing this I thought what a great opportunity to dive into streaming for my software development. So I decided I would pick Unity back up and give that another whirl.

There has been a pretty steep learning curve with all this, I've had to learn how to setup all the streaming applications and get my system setup, ensuring that my audio is synced properly. I also wasn't aware of how strict the rules are with playing copyrighted music, although it makes total sense really.

Anyway this is just to be a short post, you can find links:
Twitch
YouTube

​I hope to see you on one of my channels,
​Cheers!

So it's been a while since Hacktoberfest and I had actually forgotten about the t-shirt that you get for taking part, but the other day it arrived!

And there it is!

I'm really happy with it and will definitely be taking part next year :)

Over the past few months whilst development has been on-going with the Moodster API, Glen has been prototyping various JS Frameworks for the frontend of the application. The requirements for this were a little more complex than the API.

We wanted the frontend to be able to have ideally one codebase that would be cross platform for  mobile, web and possibly desktop too.

Glen wanted to give some different frameworks a try so he could find the best fit but also to gain some experience in various frameworks as he was looking for a new job at the time.

Some of the options that he's been trying out are:

• Quasar - This is a framework built on top of vueJS with great support for deploying to multiple targets from one codebase.
• ReactNative - I don't think this is likely to be chosen as it's not very easy to have on codebase for multiple platforms.
• Angular - This is another viable option which also supports Native apps on mobile. Larger popularity than Quasar at the moment as well.

Not sure which way it's going to go at the moment but we need to get this nailed down soon so we can start making progress.

I've completed it!

I have done the 4 required PR's for Hacktoberfest, which means I am eligible for the t-shirt. It actually wasn't as easy as I thought. I could probably have been a bit naughty and broken down my PR's into much smaller pieces of work to try and bump the numbers up, but I would have just been cheating myself out of doing as much work as I have.

So to give a summary of the new functionality I've added to Moodster API over this Hacktoberfest, here are my PR's:

​October 02, 2019 00:44 Added the moods table, including default data.
October 02, 2019 21:31 Added test to cover none type token payloads to
October 18, 2019 18:14 Added team creation deafault admin user
October 19, 2019 16:08 Member mood addition

​So that's it, there has been some great additions there which push the functionality further than what the previous Flask-Restplus verison had. Furthemore I believe that the API is probably now MVP complete. Looking back at the original blog post that laid out the MVP the API has endpoints which would allow the frontend to perform all of those actions.

Next up is to try and push development a bit more on the web/mobile app front to try and get that to MVP.

That's right Digital Oceans Hacktoberfest is just about to kick off!

I'm going to give it a go and use it to motivate me to do some more work on the moodster API.

​I've made some real progress and the FastAPI version of the Moodster API is almost functionality equivalent to the previous version.

Wish me luck!

A while ago I began trying to dockerise the moodster API application and it was quite difficult to get started as the project was already under way and I wasn't that experienced with Docker at the time.

Since I'm re-writing the Moodster API I decided I should start off with dockerisation and bake it straight into my development process.

Fortunately the FastAPI documentation already comes with pre-built examples and docker containers for running FastAPI in Docker.

One of the main reasons I've been wanting to do this is that I've recently been looking into the 12 factor app. The 12 factor app is essentially a set of guidelines for how to develop applications that are to be ran as services.

The guidelines in place are to allow you to create services which are as maintainable and scalable as possible. The rule in particular that has driven me to do dockerisation of moodster is called Dev/Prod Parity. This essentially says that the development, staging and production environments should be as similar as possible.

In the Flask-Restplus version of the Moodster API I was using sqlite for development and then I was using PostgresSQL for the unit tests and eventually for deployment. This caused me issues from the off where I was hitting issues with differences between how Postgres and sqlite worked with SQLAlchemy and database migrations. It also made the configuration more confusing as I was having to override lots of things depending on dev vs testing. This is not ideal!

The dockerisation has gone fairly smoothly and I now use docker in development. This allows me to just use Postgres for all the environments and it's just another thing that I now don't have to worry about.

I did find that it slowed some development speed initially but now that I'm used to the docker commands a lot more it's no longer a barrier. Also the amount of time it is going to save me when it comes to deployment means it will be well worth it.

​Cheers

This is not something I normally do and to be quite honest in a work environment I wouldn't do this, but I've decided to re-create Moodster using FastAPI.

FastAPI is a small API focused web framework built on top of a few rather large projects:

• Starlette - An ASGI Web Framework
• Pydantic - Data validation using Type hints

There are a few reasons I've done this:

First of all Flask-Restplus was already giving me issues with data validation as mentioned in this post. They didn't seem to have a proper answer for the correct way to do this yet. On top of that I saw how clean it looked with pydantic to use type hints for data validation.

I have also been hearing about many different web frameworks that are now built with asyncio out of the box and thought it would be a good idea to future proof a little by choosing a framework that was capable of this. Realistically I'm not even going to use the async capabilities straight away as I don't think it's necessary for the scope of the project. It is certainly a plus knowing that it is there if I need to boost performance in that way.

Finally back in this blog post I said one of the reasons I didn't opt for a web framework that was ASGI was due to the lack of the ORM libraries not being async capable. Well the project that the starlette web framework is under also has libraries for async capable ORM's. This final piece put me at ease enough to make the switch.

There is a lot of work ahead essentially re-inventing functionality that already exists but it's also going to give me a chance to do things in a slightly better way as I've learnt quite a bit since starting out the Moodster API project.

Recently I've had one of my Software Developer friends join me on the project to help push the app side of the project forward. Glen has spent the past few years honing his craft as as Web Developer, which makes him perfect to bring on board for this frontend work for the project.

This is a really positive thing for multiple reasons:

1. He can fill in the gaps of my web development knowledge.
2. He will quickly be able to get a Frontend Web/Mobile application up and running.
3. He will bring new found motivation to the project work.

Already he has made a huge impact on the project. We've decided to use React Native for the application portion of the project. This gives us the benefit of utilising Glen's Javascript knowledge while allowing us to create Native Mobile applications for the project.

Anyway lets show off some progress photos!

Here are some of the basic screens we have put together for the moodster mobile apps:
​

So we currently have:

• Login screen.
• Mood submit screen.
• Team member screen.
• Mood history screen.

These are only basic designs and they are mostly filled with dummy data but I think they look fantastic and I'm super excited to have Glen join me on this project.

So the API part of the Moodster project is really coming under way. I've realised that altough the initial size of the original MVP was small there is still a hell of a lot of functionality required to even get those implemented. 

Even with that simple functionality there is still 5+ Database Tables/Models that are needed to make this flexible enough to expand on at a later date.

Although Flask-Restplus is really simple for Parsing payload data and also for marshalling the responses as a model it really suffers with things such as Query Parameters. Looking at the documentation there seems to be what is now a deprected ReqParse module which can be used to do this but I am not a fan of using deprecated functionality.

The alternative and what seems to be suggested online is to use Marshmallow to do this serialisation/marshalling instead. The documentation however doesn't really give you a jumpstart on how to use the Marshmallow in Flask-Restplus.

I'm not 100% on what I want to do here but I think it's something I need to sort out pretty soon.

One thing I've found useful whilst doing this project is to have a travis pipeline setup which will run all my unit tests and ensure that I've not regressed any functionality when doing a Pull Request(PR). I've been really keen to start this project off the right way, and blocking merges based on unit tests seems the right way to go.

Also for this reason I've been making sure I am writing all my unit tests for the new functionality I am creating before even creating a pull request. I've also added the "build passing" Travis badge to the README to make the project look that little extra professional.

I am going to look into adding test coverage soon, I really want to make sure that the project follows as many best practices as I can to give it the best chance to be successful once it's released into the wild. If I see an open source project on Github and I see that It doesn't have any tests or coverage I tend to try and steer clear or at least opt for one that does.

Hoping to keep momentum high!

Here's a link to the Project, if you want to take a look.

So I've just listened to the Talk Python Podcast for digging into visual studio code and been really thinking about how useful this could be to me from day to day. I already use vs code for all my python and robot framework development I do at work and home so it's already part of my workflow. 

So the workflow for development at work is this:

1. Develop on code locally using Eclipse
2. Push changes to the build server.
3. build on the build server.
4. pull down any compiled files to local machine if required.
5. package up the code on the build server.
6. push the package to a piece of hardware for testing.

This whole process could be much simplified with points 2) and 4) if I could simply develop on the build server using the vs code remote development tools. Not only 2) and 4) would be much improved but since you can actually use the terminal built into vscode to operate on the filesystem of the remote machine then I could also run the make commands for doing the whole build and packaging process as well.

This seems ridiculously powerful!

On my home machine I have a separate installation of Linux Mint for doing all my python development on, this is for a couple of reasons:

1. I prefer developing python on Unix based systems as I have full access to the bash shell and installing python and working with packages is much simpler there.
2. Not many video games have installs for Linux so it keeps me productive :)

Well this won't help with number 2 but It will certainly help with number 1.

So Windows Subsystem for Linux seemed really good apart from you can't use any Editors with the WSL files... until now!

I would no longer have to work in vi/vim if I wanted to do any python development in WSL, instead I can use the remote development tools of vscode to have the same workflow as I would on a unix based machine. This would make using WSL on windows a possibility for me and save me some much needed space on my SSD as I will only need one OS :)

A while ago I posted a blog post about a hackathon project I did for work. In this project it required me to run multiple SSH sessions to many machines at once to query the state of the system.

Recently I've been listening to a lot of the Talk Python To Me Podcast, and hearing all about the new async features of Python 3. This got me thinking about this project and how this would be the perfect candidate for some async functionality. Why is this?

So we had a fairly large number of machines that we were wanting to run these SSH Commands on and many of those machines were simply not turned on or currently unavailable for SSH connections. This caused an issue as we simply had to wait for the timeout to occur which was down to about 1 second to ensure we gave enough variance for slow network.

During this 1 second window each of the worked threads were simply waiting there counting down the milliseconds. This was extremely inefficient!

So Python introduced the async and await keywords but unfortunately it is likely going to be a while before there are many ORM's that are async capable. This is really handy as I had decided that the API was going to be fairly stateless other than the in memory cache, which means implementing this new approach should be fairly simple.

So I used Flask for the web framework for the API and there is now a drop in replacement being developed called Quart. This enables the async and await functionality into that same Flask development style that everyone loves with Flask.

​Along with Quart is another python package called asyncSSH which allows the use of async and await for SSH Connections.

So the actual changes required to test out this new approach hopefully shouldn't be too much effort.

The big question is will this actually improve performance?

At work we occasionally have a Hackathon day where everyone in the lab is able to work on any project they like whether that's just practising some Test Driven Development(TDD) or creating something that could help with your day to day work.

So for this Hackathon I got together with Adrian Moldovan and Tom Fletcher to work on a project that would hopefully address a major issue we have at work.

Our problem is that our product has many different platforms and we don't have all the different platforms in each of the teams so we often have to share our hardware. The problem with this is that in juggling the hardware between teams some hardware can often get lost along the way.

The major problems we have are:

• Finding the a specific platform that you need to test.
• Finding hardware on a specific code level.
• Finding hardware that is in a good state for you to borrow.
• Figuring out which hardware isn't being utilised.
• Finding out who you should talk to about borrowing a piece of hardware.

As you can see we have quite a variety of kit on many different levels and this information is invaluable for quickly finding the piece of hardware you require. 

So let's talk about the tech that has been used for this project. Firstly I've been reading a lot about microservices and was intrigued by this concept of splitting out what would normally be on large application into smaller portions. By no means is this a microservice based architecture for this project as it lacks some of the required infrastructure to be that way.

This project is split into two smaller pieces:

1. A Python REST API which performs the same ssh command to multiple machines at once and combines the result into a single response.
2. A React Web Frontend which displays a table of information for multiple machines.

So the basic idea for the project was to run many of the same ssh command to all of the machines and get a point in time capture of all of the state required to solve the above problems. To achieve this we decided to use threads to be able to kick off multiple ssh sessions at once.

I tend to avoid using multi-threading whenever I can because it massively increases complexity but in this situation it seemed like the correct thing to do.

So I really liked the idea of the REST API being a really simple worked that simply ran commands on multiple machines and output the result.

I decided that we should try and keep this fairly stateless and so the only real state that the API has is a simple in memory cache which wouldn't even be necessary if it wasn't for the sheer number of machines that we are trying to perform the commands on.

The caching itself is only held for 15 minutes for each machine to ensure the data isn't too stale.

So this portion of the project is where all the shiny things happen, without this the user would need to be able to easily read and interpret JSON data which is not a skill many people have.

For ease of use we added a search functionality along with some filter buttons which will allow the user to quickly narrow down the choice that they are after. There is also a refresh functionality which will call to the API and tell it to do a full refresh not including cached data. This is mostly for people who really need the most up to date information.

For this project we really wanted to try out using Docker as we wanted to be able to deploy these two applications as simply as possible. After all this was a Hackathon and so it is a perfect opportunity to try and harness new skills.

Both projects were there own separate containers and the frontend simply needed an argument on run which passed in the address for the API.

I think the biggest things I learnt were to do with application architecture specifically how this style of application level separation of concerns allows for extendable and reusable functionality. The API itself can be used by any frontend client. If React is no longer the flavour of the month then a new frontend could be made, or if someone wanted this functionality on mobile then they could still simply call the same API.

This whole idea of containerisation I now see if incredibly powerful, it is much easier developing on the same platform that you are deploying to and also this ability to deploy anywhere that has just the one dependency of being able to run Docker is so useful. 

I will definitely be doing a lot more with Docker in future.

There are always improvements that can be made, specific ones I would like to look into are:

• Support for the OpenAPI /Swagger API Specification.
• Adding Docker Compose support for deploying both of the Containers together.

I've just started the API portion of the Moodster project and I wanted to talk a little about my decisions for the tech stack.

I've decided I'm going to stick with Python as my language of choice as I have become fairly proficient with it and it does allow you to get things up and running pretty quickly.

I was tempted to try out  Golang for this as I have heard that it is well suited to api's/services. I decided against that in the end opting for something that I already know. This comes back round to the whole idea of trying to actually get something completed.

So I've been listening to the Talk Python To Me lately and heard a hell of a lot about the new async capabilities of python 3. I've been looking around and found Quart, which is a async capable version of the Flask API. 

I've been really tempted to start off with this but I have now decided against it. At the moment of writing there are only some of the Flask Plugins which are guaranteed to work with Quart and I think picking a framework that is still in its infancy could also end up tripping me back in the long run for the benefit of potentially getting some speed increases.

This seems to scream out the old adage "premature optimisation is the root of all evil".

Secondly from what I can see at the moment there doesn't seem to be a great story on using the SQLAlchemy ORM with async which would be the main usecase/potential speed increase for asycn and await.

I've ended up settling on Flask and the Flask-Restplus plugin as my starting point for this project. Flask Restplus gives you some added functionality for pretty much free when concerned with REST API's.

Some of these are:

• Built in OpenAPI Spec Documentation generation.
• Response Marshalling.
• Request Parsing.

That's my overall starting point with this project, who knows what additional plugins/tools I will venture towards later on.

So I recently posted about an idea I had to create a digital mood marble application which would allow scrums/teams/squads to track their mood over time. I've now come to the point where I want to kick start this project.

Firs things first I need to come up with an MVP (Minimum Viable Product) which I can use to ensure that I actually get to deployment of version 1 without feature creeping.

Team Leader:

• Create a Team.
• Add a team member to a team.

Team Member:

• Join a team.
• Submit a Mood for the day.

Anyone in the Team:

• View Team Mood Overview/Statistics.

So that is the bare minimum application that I need to create for me to be happy to release it to the public.

For a while now I've been thinking about a potential project that I could undertake that is small enough for me to carry all the way to completion/deployment.

This is something has been a struggle in the past as I've tended to choose projects that are simply too large for me to keep the motivation when working on it in my spare time.

Recently I've come up with an idea that I think is small enough in scope to be accomplishable whilst still being a useful project to undertake.

At work we've been focusing on using Agile methodologies for quite a while and one of the tools that people often use at work is 'mood marbles'. The concept is that each member of the team can place one marble into a jar and the colour of the marble they choose depicts the mood they felt that day. 

The whole idea of this, is that you can use this semi-anonymous jar to depict the mood of the team over time. When you come to look at the jar for a current period and the marbles in it are mostly red/orange then you know the team has not been happy recently and it can then open doors to address why that might be.

The problem that I see with mood marbles is:

1. It doesn't help well for remote team members.
2. It's not fully anonymous as someone could see you place your marble in the jar.
3. It doesn't provide any useful metrics for the periods between the jar being emptied.

So this is when I came up with the idea of digitalising this!

After doing some research I realised that this isn't actually a new project and it's been done before by other companies.

What hasn't been done is creating this mood marble software and making it completely free and open source, so that is what I'm going to do.

The basic idea I have in my head right now is to create a small REST API that will be used to perform all the core business logic/storing of the data, then having thin mobile/web/desktop clients that will simply interact with the API to perform the necessary tasks.

​I'm going to really give this a go so watch this space!

Okay so I've been doing a lot of work on the Colour Match Project and I wanted to show an update on the current state of the project. I currently have:

• Title screen
• Level screen
• UI navigation
• Colour hue rotation
• Touch to start level functionality
• Release touch to choose matching colour
• Scoring for how close the colour is to the original colour for that level
• Pickups that will also add to the level score
• Multiple levels with differing starting colours
• Level and user game data loaded in from files

As you can see I've been very busy but I think a picture or more to the point a video tells a much better story so here is a video of a basic run through of the game:

I know it's been quite a  while since my last post about this but I've been making  quite good progress. A lot of my time has been spent learning general Godot practices and getting to grips with the GDScript language. It is actually fairly simple as it is fairly similar to python but with it's own quirks.

The only thing I'm not a huge fan on is that unit testing isn't baked into the engine/language like it is with python so for larger projects I think I will try using the python bindings to gain that ability to unit test the functionality and also make use of many of the great python packages out there.

​You can see all the updates and clone/fork it for yourself at the Github repository.

Thanks :)

A week ago we had a code retreat at work. This is essentially a day spent away from our normal work in which we can learn about an aspect of software development.

This code retreat was all about Clean Code and Test Driven Development. The day was ran by Chris Sharp who is an STSM at IBM.

The day was a complete success in my eyes. I've already been pushing for people at work to begin reading the series of Clean Code books and this day re-inforced why it is valuable.

I think there were a number of things that people were quite surprised by:

• ​It is actually quite difficult to develop in a strict TDD way. (people often forget the Red, in the Red, Green, Refactor cycle)
  
• The outcome of the code was much simpler and a lot of people agreed that they likely wouldn't have reached that outcome without TDD.
• Software Development is a craft. We tend to get used to churning out code and it can be easy to forget that practice is important.

So those are just a few of the notes that the group had after the session.

I really want to get clean code and TDD brought into our every day work so that we can all benefit from it, although this is going to be a challenge.

I am going to have to lead by example with this, reinforcing it in my scrum's social contract and showing the results.

Finally we are having a second code retreat as only half of the Lab got to go to the first one. I have put myself forward as an "Advocate for Clean Code" in which I will help Chris run the session by going round and giving people guidance whilst they are performing the Kata's.

​Thanks :)

I recently read an article about hyper casual games and also have been watching a few videos on YouTube from Dilmer Valecillos where he talks about some of the simple games that he has released on the app store. This really intrigued me as I've always struggled to stay motivated on some of my personal projects and I believe a lot of this was due to project scope. I was simple choosing projects that were too large for a single person to stay motivated enough to complete.

That's when I decided to come up with a really simple game Idea and see if I could take it to completion.

Along with choosing a project of a small enough size I also needed to choose the correct tooling that would enable me to keep that project scope small. I decided to pick up the Godot game engine as it's a fairly established engine and also is free and open source.

There will be some what of a learning curve to learning the engine but that would be the case if I had chosen Unity/Unreal/Other Game Engine. Also I though I am focusing on making small mobile games that something like Unity might be overkill. Finally I found out that Godot has bindings for Python which really impressed me. I am going to focus on doing everything using the GDScript for this first project to make following the tutorials and documentation as easy as possible. It is always good to know that the option is there though.

Okay so the game idea I have currently thought of is a colour match game. Here is the basic process for a single level:

• The player will be shown a particular colour for a number of seconds over the whole screen and the player is expected to memorise what colour it was.
  
• The player will then need to press their finger on the screen, which will begin the level.
• A starting colour will be shown on the background and will begin cycling through the colour ranges.
• The player will remove their finger from the screen when they think the matching colour is on the screen.

This is only the simplest form of the idea and what I'm considering MVP(Minimum Viable Product). There are other ideas I have for scaling the difficulty and player interaction up but I don't want to start with too much at once.

Okay so that's my simple game idea, I am hoping to make good progress on it.

Thanks

So I've decided to move my home office around, mostly so I could fit in my new whiteboard. There was some deconstructing of a wardrobe and some drives to the tip but that's all done with now and I'm pretty happy with the result.

It's not all that exciting really but it has been a positive move for me, as it's been one of a few things I've been doing to try and get myself more organised. I love whiteboarding so having one of a decent size at home is going to allow me to think about architecture and design a lot easier on my home projects.

So a while ago I came across the Self Journal by Best Self Co and thought it was a really great idea. At the time I didn't think that I really needed everything from it though so I decided to roll my own with similar sections but I would write the template out myself for each day/week. This worked for a little while but I got bored of spending so much time simply writing out the template for the day before even getting the planning part, so I soon dropped it.

Recently I've decided that I need to get more organised again and then I recalled how effective I was being when I was using my journal. So I've decided to give it another go, except this time I've gone full force and had my templates all printed out and bound together into a fairly professional looking journal. By no means does it rival the quality of the self journal but at least it won't get torn or damaged from being carried about in my laptop bag.

So I've been using the journal for a 3/4 days now and I'm actually stunned out how effective it's been. I've started a project which is my "13 week Goal" for the Journal and It's going so much better than other projects that I've started in the past.

Not only have I been working on development at home more I have also been getting more done at work, doing general chores, DIY and even looking after my health.

Needless to say so far it's all going well, I just hope that I can keep it up.

Cheers :)

Recently I saw an advert for some Stack Skills courses. On seeing it I remembered I had purchased a load of courses on an offer a while ago so I decided to take a look at what I had.

One of the courses I purchased was a python course. A lot of it was python basics, but there was also a couple of more advanced ones:

• ​Create a Web Application with Flask
  
• Create a Web Application with Django
• Create a Flappy Bird Clone with PyGame

I've already created web apps with Flask before and may try the Django one soon but today I decided to follow the PyGame tutorial.

I managed to complete the tutorial but there are definitely aspects I want to improve. I followed the tutorial fairly closely as to make it easier and only changed subtle things.

The problem with the tutorial is that the code is fairly inconsistent, the structure isn't particularly great and there is no testing or comments.

Examples of this, are things like variable naming:

block_move = 3
x_block = surfaceWidth
y_block = 0
block_width = 75

Why wouldn't you just call it block_x and block_y to follow convention, also the use of camel case is interchanged with snake case a few times, such as the surfaceWidth variable above and also with functions as well:

gameOver():
replay_or_quit():

Okay so maybe I'm being a little harsh and those things I didn't actually add into my version but it does make you wonder about a lot of the information out there. How much of the tutorials and courses are actually written by people who have just about learnt enough about the subject to be able to tell it to someone else?

​

So now that I've completed the tutorial I've taken a step back and taken a look at the code and I already want to refactor a lot of it. So here is a list of the things I want to do (regardless of whether I ever get round to doing them:

So like I said earlier there was not a single sign of a test in the whole tutorial, which is no surprise really. Most tutorials are simply to give someone the basics of how something works so they can then go away and work on it. They don't tend to care about good practices too much or thinking about software development as a craft. This showed in that a couple of times in the tutorial there were bugs, some that I spotted instantly and others that he had to go back through and try and spot them.

Before I start refactoring any of the code I really need to write some unit test, that way I can confirm that the functionality doesn't change whilst performing the refactoring.

I would like to split out some of this functionality into a few different files/classes as this one python file is pretty bloated. It works okay for a simple tutorial for pygame but I would certainly want to split things out if I wanted to take this any further.

All the functionality in the main game loop is crazy, and certainly doesn't have just one single responsibility.

I would want to create a python module from the game so that you can install it and all it's dependencies with pip. I'll also want to update the readme to explain the dependency on PyGame and also how to install it.

I actually had a lot of fun following the tutorial, It's been a while since I've done any game development really and now I know how easy it is to do with PyGame I would be tempted to throw together some simple 2D games with it.

I will probably do the changes I mention above as I always think that If it's a Repo on my GitHub Account, then it's essentially a representation of my work and I'm not currently happy with how it is.

Thanks :)

So as mentioned in the README, I have a few stages of development that I would like to take this project to.

The first stage was to simply use TDD to implement the Coding Kata to pass the Tests. The next stage and the one I am currently working on is to visualise the Minesweeper Board using Monogame. 

As I still wanted to progress with practising TDD I decided that I should carry it on throughout the other stages of this development and this brought up some interesting results.

As I began the visualisation phase I quickly realised that I will have to be conscious about which part of the code I test. For example, I decided I wasn't going to test any of the draw functions and these are the reasons why:

• The drawing functionality is so closely linked to Monogame that I would essentially be writing tests to ensure that Monogame is working correctly, which I'm sure Monogame already has plenty of.
• I could test that when I draw a particular square I could then check that against an image to ensure that It matches up perfectly. Of course If I ever changed font, changed background colours or provided any tweaks to the visuals then these tests would need to be re-worked. Not ideal.

​

The advantage of this forward thinking is that I could make clear decisions about what I would test. These are the decisions I ended up making:

Due to the fact that I knew that I had fully tested the Board Class and that if we are using SOLID principles then that should now be "Closed to modification". I Created a new class called BoardVisualiser which takes a Board Class as it's constructor argument which would then deal with purely visualisation of the Board. 

In the past I may have been tempted to just add some Monogame Classes to the Board class and add a draw function to it. By doing TDD that thought never even crossed my mind, which is a great sign that performing TDD leads to better architecture.

As I knew I was not going to test the draw functions themselves, that didn't mean I couldn't test anything that would be a part of the BoardVisualiser class. I realised that I would need a method to find the origin that I would need to provide to the draw calls to say where I would like each square to be drawn. It's this sort of application logic that I could quite easily test. 

I was careful to try and keep this function to use as many primitive types as I could, It would have been fairly easy for me to pass in a Monogame class to this function but that would have put a dependency on Monogame in my tests which wasn't really necessary for this particular function.

Something that is fairly interesting, is that I actually found a bug whilst performing the TDD on GetSquareOrigin function. It was a simple copy and paste error but I wouldn't have caught it until much later on when trying to draw the squares to the screen and by that point it would have been much harder to find.

​Cheers :)

So I've been working on the Minesweeper Kata mentioned in my previous blog post (When I don't have work, or a one year old to entertain) and I've finally got it checked into Github. 

​It is available here.

There are still plenty more pieces of functionality that I would like to add, most of which I've listed in the README on Github. Before doing so I thought I would write a little post mortem of how I got on with the Kata.

This isn't going to be a list of advantages/disadvantages of TDD but more what aspects of using TDD for this worked well for me.

Pros:

• By forcing myself to do strict TDD I believe the end result was much higher quality, there were a few cases where my first attempt actually failed in some not so obvious ways. These would have slipped through the net normally.
• Focusing on the Testing/Requirements rather than just implementing the functionality actually became a bit of a game. e.g. "Hmm, what are the failure cases of this function? What Inputs can I give it to make it fall over?"

Cons:

• Due to the fact that I've not done strict TDD for a while I did find myself having to delete some code as I had started adding more code than was necessary to pass the test I was working on.

Overall I've really had fun doing this little Kata so far and can't wait to carry on adding functionality and plenty more tests to the project. 

​Cheers :)

So we'eve been doing some test driven development at work but not enough to really feel as though I'm getting the most out of it. To improve my ability to write good unit tests and become a TDD star I've decided to start completing some coding Kata's. A term I've picked up recently from the Uncle Bob's Clean Code series of books.

Kata is a Japanese word that is used for a concept used in Martial Arts. The term refers to a repetitive exercise or pattern of movements that is used as a training technique for Martial Arts.

So how does this apply to programming?

Well the terminology has taken off quite a bit and there are now multiple Coding Dojo sites around that will have a list of different Kata's that a programmer can pick up and start using as a exercise to improve their coding.

Personally I'm using the Kata's as an opportunity to test myself using techniques such as TDD or to practice picking up a new language without resorting to some of the boring example programs.

So the Kata I'm taking up is a recreate of the level generation for the Minesweeper game was on the early Windows Machines. You can take a look at the Kata here.

So the main things I'm trying to achieve from this are:

• Improve my Test Driven Development (TDD) skills
• Refresh myself using C#, in particular using Monogame as I haven't used it before.

The Monogame work will actually be an extension, I will first be completing the Kata as is and then extending it using Monogame to add some Visual appeal to it.

​Okay so that's it for now I'll let you know how I get on.

Cheers