diveflo / fair-teams-ai Goto Github PK
View Code? Open in Web Editor NEWLicense: MIT License
License: MIT License
GitHub changed the way dependabot pull requests are handeled.
TL;DR: Dependabot PRs cannot access secrets defined for the GitHub actions, which makes our tests fail currently.
We should remove skill, profilePublic and steamName from the request body because it is not needed. As a first step this attributes should be optional, so the application is still working after the api change.
[
{
"name": "string",
"steamName": "string", //remove
"profilePublic": true, //remove
"steamID": "string",
"skill": {} //remove
}
]
Add optional queryParameter hltv=true/false to scramble teams by hltv
Eieiei wer macht denn sowas ¯_(ツ)_/¯
We have a hard-coded Steam Web API key in the Player.cs
class....we should discuss how to correctly handle such secrets without adding too much extra efforts during development.
api endpoint structure
request:
{
"players": [
"name1",
"name2",
]
}
response:
{
"statistics": [
{
"description": "",
"values": [
10,
20,
30
]
}
]
}
same order in response as in request. Or do we need no request body and deliver the stats of each default player?
Currently we have a hardcoded list of players in the webui, with a hardcoded map to their SteamID in the frontend.
It would be great if we could add players to that list during runtime/in the webui if someone new wants to play with us spontaneously.
I'll add required tasks to enable this for both the back and frontend.
Dude. I didn't see any changes when using the map selector...Niggo noticed and told me that it actually does something :D
Currently, unit testing feels clunky as the different ratings (HLTVRating, KDRating, DummyRating) are created within SkillBasedAssigner rather than somehow provided from the outside via DI or something similar.
Rethink and (as appropriate) rework design.
Currently, a wrong or missing SteamID results in an exception from the backend as it can neither find the corresponding steam user name nor (once that's implemented) scrape the rating from csgostats.gg.
If/once we want to add the possibility to add new players live/in production on the frontend page, the backend needs to be able to gracefully handle such a case:
As we still will want to notify the user that the SteamID wasn't valid and therefore a default rating was used, we need to figure out how to gracefully fail while still returning the expected data in ASP.NET Core
Maybe helpful documentation
As we now have separated workflows for the frontend and backend, we should configure our CIs to only run the corresponding workflows if changes have been made to that codebase, i.e., only run the backend CI when something in the backend changed and vice versa.
Currently we use sqlite as our db provider for the backend.
As this is very entangled with the backend itself, it causes some downtime for the backend even if we just need to make some fixes for the db.
Using a different db, e.g. PostgreSQL or MariaDB, as a separate docker container, we could reduce this downtime.
Currently, our CI/GitHub actions manually calls flutter build web
and subsequently uses the flutter-gh-pages action to deploy the resulting app.
The flutter-gh-pages
action should however, at least if I read this file correctly, already run flutter build web
. So it looks like we're building it twice at the moment.
Currently our frontend is deployed on GitHub pages while the backend is deployed to a linode VM.
The backend REST Api is wrapped in an nginx proxy hosted locally on my network.
Deploying the front and backend together would have multiple advantages:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.