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.

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!