#10 - New Semester, New Possibilities (for risks)!

[AlexMi-Ha]

Welcome back 🍌

We're sure you missed us! 🥺 A new semester has begun, and with it a lot of anticipation to finally work on AMOGUS again! 🥳

A lot has happened in the past two weeks, where we've awoken AMOGUS from its slumber and continued to work on it. 💤
With only half of the time left, we wanted to kickstart development again so...

What's better to start with, than a good ol' Spring-Cleaning session 🧹✨

@AlexMi-Ha and @Annalytic-programming refactored almost the whole backend for better testability later on and cleaner style in general.

Not only that - The Frontend was not forgotten! @jas20202 updated a lot of our Mockups and, with the help of @WachtelHD , started to implemented them in our Angular App.

Lastly, we worked on our Risk Management. Here we looked at our project and tried to identify risks, that could cause problems for AMOGUS 👀

Here, our biggest Risk (by Risk-Score) is leaking private Tokens via our appsettings.json file. This is where we store our database connectionstring and Jwt Secrets. Still, it is not in the gitignore file, but as another team said: What's life without a little risk? 🙃

We need this file in git for our build-automation workflows - so we've saved the real production values only on the server itself and pushed the appsettings file with development values.

But when testing the app with the real database connection locally, and forgetting to undo the changes in the appsettings, the real value could be leaked.

So our Mitigation Strategy is to always check the git status before pushing if you edited the file. At the latest, it should hopefully be detected in the Pull Request Code Review.

But Mistakes happen, if something fails, we need to change our secrets ASAP.🚀

That's enough with all the risky texts.😳

But all in all we are good on track for our final demo. So prepare your brainjuice for some fruity math exercises with AMOGUS 🧠

Yours truly,
CUMGroup

[robin13901]

Great post, CUMGroup!

We enjoyed reading about the progress you've made on AMOGUS, and how you're tackling risks that could potentially cause problems for the project. It's great to see that you're taking proactive measures to ensure the security of private tokens.

We especially liked the Spring-Cleaning session you did to refactor the backend and update the frontend mockups. Could you share more details about the changes you made to improve testability and style?

We are excited for upcoming posts and developments in your project and will be back to hear about all of them :)

Kind regards,
TUDU Team

[AlexMi-Ha]

Hi Robin 🦥,
thanks for the feedback!

My main focus in the refactoring was to further enforce Service abstraction via Interfaces and implementing the Repository Pattern.
When only requiring Interface types from the DI container, mocking will be easier, because we can just implement a dummy partial class to return a specific thing from a specific Method. (See Moq syntax)
This results in a much cleaner abstraction between Services and between Services and the Persistance Layer.

@Annalytic-programming focused on code style and made sure our Methods follow KISS and DRY and made some further abstractions.

If you're interested, these are the PRs: #70, #71, and #74

Yours truly,
CUMGroup

[WeberWr]

Hey CUMGroup :),

We find your Risk Management good and think you have good points and risks. We think with these strategies u can avoid the most risks.

According to your Mock-Ups it is great to have a digital version now. We think your game will look great.

We are exited to see more of your project and maybe a first demo.

Regards
TD-Team

[AlexMi-Ha]

Hi TD-Team,
thank you for checking it our!
We hope we captured a good amount of our Risks and now know how to cope with them.

Concerning the demo, make sure to check our blog posts in the coming weeks. It is coming! 🔥

Yours truly,
CUMGroup

[vans1646]

Hi CUMGroup,
we are also back now and really enjoyed your new Blogpost!

I think that it's really good to go through old code and adapt it in a way, that it's more usable in further implementations concerning testing. So pluspoint for that.

Concerning your risk management: I think you considered many risks that are dangerous to your project so have everything covered. Is the risk of sickness of a teammate considered within the dropout of students? Otherwise that would maybe be a very probable risk to consider.

We are exited to read more from you or even see somethin within a demo.

Cheers,
Capyclue

[AlexMi-Ha]

Hello Capyclue,
great to hear from you again! 😊
Yes, we also thought about sickness too, when collecting risks. But looking back, we should most definitly reformulate the Risk to include it, thank you for the feedback!

Yours truly,
CUMGroup

[BeierKevin]

Hi CUMGroup,
it's really nice to hear that you are back and really to work again.

It's always excellent to refactor code for better maintainability, and the new mock-up looks great!

Your private tokes should be private and never leaked, you really should work on a solution so that you never share any of these Tokens or keys with anyone, you should maybe create a build tool which automatically assigns these values to environment variables or something similar, this is a big deal IMO.

I really hope you can fix this, but over all it looks and sounds great!

Cheers,
VIGAD

[AlexMi-Ha]

Hello VIGAD,
We're currently working on a Solution to reduce the risk of leakage! I'm completely with you on this - very important - top priority. Currently we are trying to avoid using the real Keys in local development as much as possible.
Really sensitive information like the real database connection string for the prod-database is only stored on the server and mustn't be used in local development!

Thanks for the advise!

Yours truly,
CUMGroup