Durch den letzten Commit von Nick ist sämtlicher Code, den ich die letzten Tage geschrieben habe, verschwunden.
In der Commithistory sieht man gut, dass ich gewisse Dateien am 14.2. geändert habe.
Im Repository stand beim spotifyPlayground "geändert vor 11 Tagen". (bereits gefixt)

Scheinbar wurden meine Änderungen durch Nicks push rückgängig gemacht.
Jedenfalls habe ich das Repository nun gefixt und ich bitte euch diese Version zu klonen.
Die neue Version des urlGenerators wurde bereits implementiert.

Als ich den Code ausführen wollte, stellte ich fest, dass mir scheinbar etwas fehlt.
Ich werde in der Dokumentation von Spotify mal nachschauen, jedoch sollten wir dieses Problem lösen, da das proof_of_concept nicht einfach so ausführbar ist.

Currently the matching of a mood and a drink is done rather random. Since this project is originally a university project a proof of concept did suffice. Therefor we decided for ourselves which drink matches with a certain mood. There is currently no real matching algorithm.

A matching algorithm could make use of the drinks description and match certain keywords to a mood. This would mean, that the description of each cocktail would have to be parsed.

Another solution would be to associate certain alcohols with certain moods. This way the cocktail database could be searched for drinks with the alcohol as an ingredient. Since moods can't just be randomly associated with certain alcohols a scientific approach would be preferred (maybe there are papers that examined the correlation between different alcohols and moods?).

Dazu sollte eine eigene Wikiseite erstellt werden, wo die zusammengefassten Daten stehen.

Hi Markus,
wir stehen vor dem Problem, dass wir uns unsicher sind wie wir mit mehreren Nutzern umgehen sollen.
Im unseren Webservice kann man bspw. Präferenzen festlegen, das Problem ist jetzt jedoch wie wir diese abspeichern sollen.
Bekommt jede Präferenz bzw. Liste von Präferenzen eine eindeutige ID und der jeweilige Nutzer kann nur auf die Liste mit der entsprechenden ID zugreifen, ODER ist ein Nutzer eingeloggt und die Variablen gehören daher sowieso zu diesem Nutzer?
Allerdings würde solch eine Nutzerverwaltung ja unsere jetzigen Programmierkentnisse übersteigen.

(nach Stand auf dem Bild wären die Präferenzen theoretisch global und demnach für alle Nutzer gleich)

Die dritte Möglichkeit wäre, den Code einfach so zu schreiben, als wäre es nur ein Nutzer.

Welche der Varianten ist für dieses Projekt gewünscht und soll demnach umgesetzt werden?

Vielen Dank im Voraus

Die File spotifyPlayground.js wird vermutlich demnächst eine neue Schnittstelle/Methode besitzen, wobei
explizit Neuveröffentlichung eines Genres geliefert werden, wenn die Spotify API dies zulässt.

Spotify möchte nur BIS ZU 5 SEEDS für die GET Recommendations erhalten. Da wir keine spezifischen Artists und Tracks vorgeben wollen, greifen wir NUR mithilfe der Genres auf die Schnittstelle zu.
Unter lib/data/spotifyGenres.json finden sich alle aktuell verfügbaren Genres.

Zudem sollte der Parameter limit und evtl. market angegeben werden, weil:

1. market: gewisse Songs sind evtl. in einem Land für den Endnutzer nicht verfügbar, aber in der Liste enthalten.
2. limit: default liegt bei 20 Tracks und sollte änderbar sein.

Hallo zusammen. Habt ihr eine Schnittstellenmodellierung vorgenommen? Wenn ja, wo finde ich diese in eurem Repository?

https://github.com/nickcrisci/GDWWS2021_Crisci_Johne_Brock/blob/696e4f9242c221c0aa522559c280e0da01a7912c/lib/modules/urlGenerator.js#L43

Durch das Hard Coding der URL ist der Generator noch nicht generisch genug.
Zu Schönheitszwecken kann/sollte das Query-Symbol erst an die URL gehangen werden, wenn der erste Parameter angehangen wird.
Außerdem sollte an einem Punkt der Logik das angegebene Genre mit der spotifyGenres.json geprüft werden. @sebastianbroc sollte diese Aufgabe übernehmen, da er bereits eine ähnliche Umsetzung gelöst hat.

Hi,
Ihr habt euch noch nicht zum Fachgespräch zum Workshopteil eingetragen. Bitte holt das noch heute nach.
https://ilias.th-koeln.de/goto.php?target=wiki_1201563_FgWorkshop20Alterauge

1. Ist der begonnene Weg zur Domänenerschließung ersichtlich?

Wir sind bei unserer Domänensuche auf das Problem der Kombination von Cocktail & Musik im Barsektor gestoßen. Da nicht jeder Besucher einer Bar nicht seine explizit nur seine eigene Musik wahrnehmen kann, fällt dies vermutlich schon raus. Da wir allerdings "nur" eine eher "neutrale" Backend-Idee realisieren, würde die konkrete Umsetzung eher ein Problem des Frontends sein, oder?

• beantwortet

2. Ist die Eingrenzung der APIs, welche sich im Wiki-Protokoll vorfinden soweit für eine solche Idee von Vorteil?

Link zum Wiki-Protokoll

• beantwortet

3. Um Eigenschaften der Cocktails festzulegen, haben wir uns dazu entschieden, eine eigene JSON-File mit Daten sämtlicher Cocktails zu schreiben. Ist dieses Format gut, um auf eine "Datenbank" zurückzugreifen?

• beantwortet

Der URL Generator enthält aktuell folgenden Code, um an die URL die gewollten Properties anzuhängen:

    for (const property of properties) {

        if (!property["name"]) {
            return callback(new Error("Name of the property is missing"));
        }
        if (!property["value"]) {
            return callback(new Error("Value of the property is missing"));
        }

        let suffix = `&${property["name"]}=${property["value"]}`;

        queryUrl += suffix;
    };

Eine beispielhafte (auf Beatdrinks) zugeschnittene URL sollte so aussehen:

https://api.spotify.com/v1/recommendations?limit=3&market=US&seed_genres=disney%2C%20movies

Die einzelnen Attribute sind mit & getrennt, während mehrere Seed per %2C%20 getrennt werden.
Außerdem ist mir die genaue Übergabe der Property-Liste nicht bekannt.
Meine Ideen waren:

1. Als Objekt: {limit: 2, market: "US", seed_genres: "disney", seed_genres: "movies"}
2. Als Array: [limit = 2, market = "US", seed_genres = "disney", seed_genres = "movies"]

Eventuell kann man mit ...args die Elemente übergeben, ich bin mir allerdings gerade nicht mehr ganz sicher.

Mein Code funktioniert auch ohne das new-Präfix.
Allerdings bin ich mir nicht ganz sicher, wann der new-Operator benötigt wird.

Currently the "cocktail database" is a simple json file with some crawled cocktails in a single language (german). The problem with this is, that the data is incosistent and hard to translate to other languages.

A better aproach would be to incorporate a cocktail database (or api). By using an already existing database or api the data would be easier to maintain and possible already in mutiple languages.

Additional context
It is important, that the data provided by the database or api allows for some way of matching the drinks to a mood (e.g. by associating a certain alcohol with a certain mood, or correlating certain keywords in the drinks description to a mood).

Aufpolieren

@Paul-Johne @sebastianbroc ich habe vor das Projekt mal ein wenig aufzupolieren. Also Refactoring zu betreiben, vielleicht die Dokumentation ein wenig aufzuräumen und mehr.
Die Idee dahinter ist, dass wir das Projekt in unser persönliches Portfolio aufnehmen können (falls gewollt).

To-Do

Hier sind ein paar meiner persönlichen Todos, ihr könnt gerne in der Diskussion des Issues noch weitere Punkte hinzufügen.

• Code Linting (z.B. durch ESLint)
• Secrets (z.B. Spotify Client Secret etc...) aus dem Code auslagern
• Dokumentation verbessern
• Funktionalität hinzufügen (von uns angedachte Ideen, die wir im Projekt noch nicht umgesetzt hatten)