migo315

Am 19.10.2019 um 20:14 schrieb Tommy:

Wichtig ist wie gesagt nur, dass es ausführlich dokumentiert ist.

Das komplette GraphQL Schema ist im Online IDE (https://oci.coaster.cloud) dokumentiert (also rechts, wenn man die DOC öffnet). Ansonsten werde ich nun immer mehr auch in diesem neuen Repository  https://github.com/migo315/open-coaster-interface dokumentieren und auch das Changelog dort zukünftig pflegen. Ich denke, dass entspricht dann ungefähr deinen Erwartungen?

Oder einfach Augen schließen

Da sich keiner gemeldet hat, gehe ich mal davon das keiner Einwände hat

Ich habe bis spät in der Nacht (bis ~2 Uhr morgens) und heute Morgen nochmal bis vorhin durch gemacht, um alle Anpassungen durchzuführen. Nun gibt es, wie im vorherigen Thread geschrieben, nur noch ein einziges Freitextfeld was je nach Sprache individuell befüllt werden muss (die Kurzbeschreibung). Und dies kann nun auch für jede Sprache (aktuell ja deutsch und englisch) einzelnt gepflegt werden. Alles andere ist direkt "Multilingual".

Egal ob also ein Deutscher oder Engländer die Historie zum Beispiel pflegt, für beide Sprachen wird diese passend angezeigt,

Am 14.11.2019 um 07:36 schrieb PasXal:

Aber wenn man so verfährt wie die letzten Jahre, das man immer eine Attraktion saniert, dann wäre ich dafür das man Time Riders neu macht.

Was denn sanieren?  Gefühlt ist Time Riders von den alten Attraktionen noch eine, die noch halbwegs ansehnlich ist. Da nerve mich eher die ganzen halbstarken, die sich dauernt abschnallen und damit die Fahrt versauen. Ein Grund, weshalb ich dieses Jahr trotz mehrmalige Besuche nicht im Time Rider war.

Die API hat nun den offiziellen Namen Open Coaster Interface (OCI -  https://oci.coaster.cloud/). Klingt einfach außergewöhnlicher als "API".

Bisher haben wir immernoch "offene Baustellen" bei der Übersetzung für folgende Felder:

Kurzbeschreibung, Besonderheiten, Feld "Thema" und Historie

Das sind alles Freitextfelder.

Ich will dies endlich abschließen und gedenke folgende Anpassungen:

- Kurzbeschreibung kann zukünftig separat für englisch und für deutsch gepflegt werden. Zukünftig können bis zu 500 Zeichen (anstatt wie bisher: 255) pro Sprache geschrieben werden.

- Besonderheiten wird komplett entfernt. Eine Besonderheit einer Attraktion / Park kann in der Kurzbeschreibung erwähnt werden (ala "Erste Achterbahn Deutschlands" etc)

- Thema wird komplett entfernt. Das Thema kann in der Kurzbeschreibung erwähnt werden (ala "Moviepark ist ein Freizeitpark zum Thema Film und Hollywood")

- Historie wird auf bestimmte Ereignisse eingeschränkt / alle Freitextfelder werden entfernt.

Somit gibt es dann nur ein einziges Freitextfeld wo je nach Sprache separat gepflegt werden muss (Kurzbeschreibung). Die Beiden Felder Thema und Besonderheiten können, soweit ich die bisherigen Daten mir angesehen habe, in der Regel mit einem Nebensatz auch in der Kurzbeschreibung erwähnt werden. Die Historie wird "geführter", da der Contributor nur noch aus einer Handvollen "Typen" wählen kann und es keine Freitextfelder mehr gibt. Die ein oder andere Historie könnte dadurch kürzer werden.

Hat da irgendjemand große Bedenken oder ähnliches? Grundsätzlich bedeutet dies ja nicht, dass dies nicht alles wieder mal eingebaut wird. Sofern mal eine "größere" Community mit vielen Contributor aus verschiedenen Länder am Projekt teilnnimmt und Daten pflegt, wären viele dieser Freitextfelder vermutlich kein Problem. Aber solang eben nur eine kleinere Gruppe pflegt, sollten wir diesen zusätzlichen Aufwand erstmal vermeiden.

Am 11.11.2019 um 23:04 schrieb BochumerJunge:

Das sie sich bisher an ihr "Best Price" Versprechen halten. ...

Ich glaub rechtlich wäre es ja auch nicht erlaubt mit einer Best Price Garantie Werbung zu machen um die im nachhinein noch günstiger anzubieten (Vermutung, hab dafür kein Beleg).

Generell finde ich die Preise völlig in Ordnung. Werden uns in den nächsten Tagen wohl auch wieder eine holen.

Serverumzug ist durch. Das Filterhandling habe ich nochmal angepasst und vereinfacht. Wenn ich zum Beispiel nach Achterbahnen von Vekoma suche, die man ab mindestens 120cm Größe fahren darf und sich in einem Radius von 50km meiner aktuellen Position befinden, sieht so eine Abfrage wie folgt aus:

vor 20 Stunden schrieb Goudurix:

Auf kurz oder lang will man den Tempel doch abreißen. Er passt optisch nicht mehr ins PHL. Crazy Bats ist eine Zwischenlösung.

Ich habe mal den Hinweis bekommen, dass man die Halle nicht abreißen wird, da man eine erneute Baugenehmigung für ein Objekt solcher größe an dieser Stelle nicht bekommen würde. Was in der Halle daraus gemacht wird, ist dann aber eine andere Sache.

Inwiefern dieser "Hinweis" wirklich auf Tatsachen beruht oder Spekulation war, kann ich nicht sagen. Plausibel klingt dies aber durchaus.

Nur zur Info: In den letzten Tagen sowie den nächsten Tagen wird man nicht viel von mir hören. Ich plane einen Serverumzug und werde leider(!) meinen aktuellen Hoster heroku.com verlassen. Die letzten Tage habe ich mehrere Hoster gestetet und den Umzug vorbereitet. Da mache ich die nächsten Tage auch weiter. Daher wird hier diese Woche nicht viel passieren.

Heute habe ich mich dem Thema Sortierung, Filterung und Facetten (Auswahlmöglichkeiten für Filter) gewidmet. Bisher war es so, dass ich 1:1 die Syntax erwarte, welche meine Such Engine benötigt. Ich habe diese quasi nur weitergegeben. Das hatte zwei Vorteile: Es war mega flexibel, da quasi jedes Feld aus der Such Engine frei zur Verfügung stand und ich musste keine "Zwischenschicht" einbauen. Nachteil war aber, dass es dadurch X mögliche Kombinationen gab die ich nicht dokumentieren wollte und das jede Änderung in meiner Such Engine ggfs. die oder andere Abfrage verfälscht.

Beispiel Sortierung:

Wenn man nach Name Sortieren möchte, musste man bisher über die REST API die Sortierung via Query Parameter mitgeben:

https://api.coaster.cloud/parks?sort=name.keyword.desc

"name.keyword" ist dabei das Feld in der Such Engine. Mal davon abgesehen, dass ja eigentlich nur ich die Feldnamen aus meiner SuchEngine kenne, könnte das Feld theoretisch auch jederzeit umbenannt werden. Uncool für Entwicker. In Zukunft will ich diese "flexibilität" auflösen und tatsächlich alle Sortierungen hart definieren. In GraphQL dann als ENUM darstellen. So kann jeder Entwickler über die GraphQL Doku leicht sehe, welche Sortiermöglichkeiten es gibt und kann bei der Syntax keine große Fehler machen (dank Validierung und Autocomplete). So stelle ich mir dies vor:

Das gleiche auch bei Facetten. Hier war jedes Feld möglich und man musste 1:1 den Feldnamen aus der SuchEngine verwenden. Beispiel:

https://api.coaster.cloud/parks?facet[]=address.country.translation.de&facet[]=types.translation.de

Auch das möchte ich mit ENUMS lösen. Dieses Beispiel, um die Liste aller Länder und Park Typen zu erhalten, würde dann ca so aussehen:

Und Filter ähnlich. Auch da definiere ich die Filtermöglichkeiten demnächst vor. Statt so ...

https://api.coaster.cloud/parks?filter[]=address.country.code:"DE"

... dann so um alle Parks aus Deutschland zu erhalten:

Der Vorteil: Alle Sortier- Filter- und Facettenmöglichkeiten sind fest definiert. Dadurch sind diese auch Dokumentiert (samt Validierung und Autocomplete). Und alle drei sind nicht mehr hart an der SuchEngine gefesellt, so dass interne Änderungen in der SuchEngine (oder gar der Austausch der SuchEngine) zu keine Veränderungen in der API führt.

Je mehr ich mit GraphQL arbeite, desto mehr merke ich, dass für eine so große öffentliche API diese weitaus geeigneter ist als REST.

Ich finde es echt immer wieder traurig, wenn in Wartezeit Diskussionen eine Preispolitik als Lösung erachtet wird. Ja, über Preise kann man einen Markt so regulieren, so dass einigen Menschen etwas nicht mehr wahrnehmen können oder wollen. Sozial ist aber was anderes ...

Versteht mich nicht falsch: Alles soll seinen Preis haben. Und wenn der Movie Park aus wirschaftlichen Gründen eine Preis pro Maze verlangt, ist dies völlig legitim. Wenn aber nur an der Preischraube gedreht werden soll damit weniger Leute sich den Park leisten können und entsprechend man weniger Warten muss, ist das einfach nur traurig.

Am 31.10.2019 um 07:40 schrieb Tommy:

Aber hier optimierst Du sicher noch.

Habe heute mal was gemacht. Die REST API und die bisherige GraphQL API hat die Daten immer live aus der Datenbank gezogen, verarbeitet und ausgegeben. Ab heute werden die Daten aus der GraphQL aber bereits vorab verarbeitet und serialisiert gespeichert. Bei Abfragen wird daher keine einzige Datenbank Query mehr ausgeführt. Die Such Engine gibt das seralisierte Ergebnis zurück, welches dann nur noch ausgegeben werden muss. Das steigert die Performance. Hier der Vergleich:

REST API: 700 - 800 ms im Schnitt

Alte GraphQL: 300 - 500 ms im Schnitt

Aktuelle GraphQL: 100 - 200ms im Schnitt

Damit lässt sich arbeiten. Im November werde ich vermutlich auch den Hoster wechseln und auf eine Machine mit mehr Power gehen. Dann könnte sich der Wert auch noch verbessern.

Anmerkung: Sobald man Wartezeiten in der GraphQL abfragt sind die Zeiten eher bei ~400ms. Dann werden auch Datenbank Abfragen gemacht, da diese Daten noch nicht in der Such Engine gespeichert werden.

Kollegen von mir waren da. Montag werde ich wohl mehr Erfahren.

Denn diese Meinung ...

Am 26.10.2019 um 10:54 schrieb ParkRider1:

Allerdings bin ich spektisch was die Kostüme angeht. An anderen Orten sicher kein Problem. Im Ruhrgebiet klingt das für mich sehr explosiv. Hoffentlich kommen nicht zu viele "Funken" aus dem Ruhrgebiet am 31. 

... teile ich.  Das Publikum im Movie Park sind sowieso oft nicht die "nettesten". Ich kann mich an recht alten Zeiten erinnern, wie damals schon halbstarke Versucht haben am HHF Leute zu erschrecken und dabei ein wenig zu weit gingen.

vor 10 Stunden schrieb Tommy:

Und was mir auffällt ist, dass eine Abfrage dieser Art doch relativ langsam ist:

Uiuiui, als ich das heute morgen direkt nach deiner Nachricht getestet habe, ist mir schon die Kinnlade runtergefallen. Die Antwortzeit lag bei ~3 Sekunden. Kurios: Die REST Api war weiterhin zügig. Dabei verwenden beide den identischen Code unter der Haube. Letztendlich lag die Ursache daran, dass die GraphQL API einen PHP Warning geschmießen hat. Und die werden nach Sentry gesendet. Wenn der Fehler also bei 25 Parks auch 25 mal Auftritt, wird dies 25 mal an Sentry gesendet. Und das hat die Performance runtergezogen.

Ich habe den PHP Warning gelöst, jetzt liegt die GraphQL wieder bei den ähnlichen Geschwindigkeit wie die REST Api.

Ich denke ebenfalls das die Rate der Jahreskartenbesitzer höher ist. Zur Preis Leistung muss man ja ebenfalls erwähnen, dass die Saisonkarte für 70 € ja den Zugang in drei Parks in direkter nähe (Bobbejaanland, Movie Park, Slagharen) für eine komplette Saison einschließt. Das ist eigentlich schon fast "unverschämt" günstig. Ja, der Movie Park kann vom Niveau her nicht mit dem Phantasialand mithalten. Aber sowohl im Movie Park (als auch Bobbejaanland) kann man Spaß haben. Sowohl als Erwachsener als auch mit Kinder. Und das für 70 € ein ganzes Jahr. Einfach unschlagbar.

Das viele den vollen Tagespreis zahlen ist mir aber auch schon aufgefallen. Und verstehen kann ich es nicht, dass man es nicht schafft, mal eben auf die Movie Park Seite zu gehen. Denn konkrete Vergünstigungen braucht man gar nicht. Der Movie Park bietet eine Tageskasse für 29,50 € an. Aber eben nur Online und mit 2 - 3 Tage Vorlauf - dafür aber fast jeden Tag. Ohne Gutscheine und Co kann man also für quasi fast jeden Tag eine Tageskarte für unter 30 € erhalten. Ein Guter Preis. Alles darüber wäre zu teuer.

Movie Park sehe ich daher auch in einem ganz anderen Preisniveau als Phantasialand. Du hast die Chance, ohne jegliche Rabattaktionen, unter 30 € in den Movie Park zu kommen. Das schafft man im Phantasialand nicht - da ist man zwingend auf eine Aktion angewiesen. Und diese ist meist auch zeitlich begrenzt. Einzige Ausnahme sind da der VVK für die Wintertage. Da finde ich Phantasialand tatsächlich günstig. Hab erst gestern die Karten für 23 € gekauft.

Den großteil der Park- und Attraktiondaten ist mittlerweile abgreifbar: https://api.coaster.cloud/playground

Die lokalisierung habe ich nochmal angepasst. Statt eine Ebene runter zu gehen, kann man die Sprache als Argument mitgeben. Wird keine Sprache angegeben, wird als Standard "englisch" genommen. Beispiel um den Status vom Phantasialand zu bekommen:

Ich habe dies angepasst, da ich stäker mit Argumenten arbeiten möchte in Zukunft. Eine Idee wäre zum Beispiel, dass der Entwickler bei Attributen (zb. die Höhe einer Attraktion) die Einheit angeben kann. Statt Meter zum Beispiel die Höhe in Fuß (auch: fiktives Beispiel):

Zitat

query {
  park(id: "f7328b4a-3308-4823-b4b6-58fb9a254199") {
    name,
    attributes {
      height(unit: "feet") {
        value
      }
    }
  }
}

Habt ihr Lust euch mal den aktuellen Stand (siehe https://api.coaster.cloud/playground) anzusehen und Feedback zu geben? Passt das für euch? Ist etwas unklar dokumentiert?

Ich habe immer wieder das Problem, seit ein paar Wochen, dass der Werbebanner über den "Antworten" Button gelegt wird. Muss dann immer mit FF Devtools das ganze HTML gedöns entfernen.

FireFox 70.0

Imho können die aktuelle, jungen Generationen nichts mit dem Bermuda Dreieck mehr anfangen. Daher war ein Thema Wechsel durchaus Sinnig um etwas "greifbares" zu haben. Auch wenn ich selber die Bermuda Geschichte eher mag.

Nein, die Seite wird einfach nur nicht richtig gepflegt. Siehe aktuelle Zeiten auf https://coaster.cloud/de/parks/phantasialand/waiting-times oder https://queue-times.com/parks/56/queue_times

// Edit: Da waren ein paar schneller

Für die vollständige Umsetzung der GraphQL werde ich wohl noch ein wenig länger dauern. Ich muss bei manchen Sachen echt noch ausloten, was wie am Besten umgesetzt wird. So sieht mein Plan aus:

- Die GraphQL wird in den nächsten Tagen immer weiter ausgebaut.

- Die REST API bleibt bis zum offiziellen "Release" der GraphQL ebenfalls bestehen

- Nach Release der GraphQL wird die REST API entfernt.

- Ich werde morgen bereits mit einem fetten Hinweis daraus aufmerksam machen, dass die REST API deprecated ist und mit der in Entwicklung befindlichen GraphQL ausgetauscht wird.

Ich plane die GraphQL bis zum 3.November fertig zu haben und zu releasen.

Mittlerweile habe ich einige Verbindungen gesetzt. Wenn man Efteling abfragt, kann man dazu nun auch die Wartezeiten (Queues) abfragen. Und zu jeder Queue die verknüpfte Attraktion (Attraction !== Queue, da eine Attraktion mehrere Queues haben kann). Die Abfrage sieht dann so aus:

Zitat

{
 park(id: "49f00560-9b8d-4c11-a3ed-f548192ef5d9") {
    name,
      state {
      label {
        de
      }
    }
    waitingTimes {
      name,
      minutes
      attraction {
        name
      }
    }
  }
}

Die "lokalisierung" von übersetzbaren Texten überlege ich so zu lösen, dass der Entwickler einfach die Sprache auswählt (siehe state.label.de im Beispiel oben). In der REST API hat der Entwickler immer die Sprache als Query Parameter einmal gesetzt. Zwar muss der Entwickler so an diversen Stellen die bevorzugte Sprache angeben, kann dafür flexibel an jeden Knoten entscheiden ob er deutsch oder englisch oder beides haben will.

vor 9 Stunden schrieb Tommy:

lso zum Beispiel Wartezeiten eines bestimmten Parks (via ID o. ä.), Wartezeiten größer als x Minuten

Sehr gut! Bisher filter ich immer in der App anstatt bereits die API filtern zu lassen. Macht Sinn so ein Filter in der API einzubauen!

vor 9 Stunden schrieb Tommy:

und das auch bei anderen Elementen wie Attraktionen. Dort fände ich es zum Beispiel sehr cool, wenn man nach Attraktionen filtern könnte, die für Personen ab 100cm genutzt werden können o. ä. 

Das geht je bereits über die REST API. Wenn man zum Beispiel alle Attraktionen vom Phantasialand haben möchte, die man 100cm und einem Alter von 4 Jahren fahren darf, funktioniert folgende REST URL: https://api.coaster.cloud/parks/f7328b4a-3308-4823-b4b6-58fb9a254199/attractions?filter=regulation(100,4)

Alles, was die REST API kann, würde natürlich auch die GraphQL API dann können. Alles ändere wäre ja sonst witzlos. In der GraphQL API habe ich die Attraktionen mal (mit Namen) ebenfalls testweise umgesetzt. Die Abfrage der Größenbestimmung sieht dann so aus:

Zitat

{
  park(id: "f7328b4a-3308-4823-b4b6-58fb9a254199") {
    name,
      allAttractions(filter: "regulation(100,4)") {
        attraction {
          name
        }
      }
  }
}

Oder man möchte nur die aktuellen Wartezeiten vom Phantasialand:

Zitat

{
  park(id: "f7328b4a-3308-4823-b4b6-58fb9a254199") {
    name,
      waitingTimes(sort: "minutes.desc") {
        name
        minutes
      }
  }
}

Wie erwähnt: Setzt euch noch nicht mit der Syntax fest. Ich "spiele" gerade nur rum. Die finale Fassung wird wohl erst Mitte / Ende der Woche fest stehen. Langsam fang ich aber an GraphQL immer mehr zu lieben

Testweise schon etwas online: https://coaster.cloud/graphiql

Um die Wartezeiten aller Parks (für die wir LIVE Daten haben) abzufragen, kann zum Beispiel diese Abfrage genutzt werden:

Zitat

{
  allParks(filter: "tags.name:has_waiting_times") {
    park {
      name
      waitingTimes(sort: "minutes.desc") {
        name
        minutes
      }
    }
  }
}

 

Sowas wäre mit der REST API nicht möglich. Da müsste man jeden Park einzeln Abfragen.

Aber Wichtig: Das was online ist, habe ich in 2 Stunden gebaut. Es ist nicht fertig oder groß durchdacht. Es war lediglich um ein wenig damit "warm" zu werden. Daher noch nicht dagegen entwickeln, da sich Felder und Co sicherlich in den nächsten paar Tagen ändern werden.

Ich habe heute mal testweise ein wenig angebunden, um ein Gefühl zu bekommen. Und bin ehrlich gesagt bisher begeistert. Es fühlt sich "sauberer" an, weil man sich wirklich alles ziehen kann was man will ohne weiteren Belast.

Bisher alles nur lokal. Aber ich denke das ich die nächste Tage die GraphQL Schnittstelle Online habe. Dann können wir ja einmal zusammen evaluieren, was zukünftig sinnvoller ist. Beide Schnittstellen (REST und GraphQL) will ich zwecks Wartung nicht behalten. Es wird sich dann Entscheiden müssen, auf welche wir setzen.

vor 4 Minuten schrieb Tommy:

Die Veröffentlichung warte ich noch ab, da der Name im Augenblick auch sehr an Dein Projekt angelehnt ist (Coaster Cloud) und das sicher nicht ganz so in Ordnung ist.

Ja, bitte ruhig was anderes nehmen. Coaster Cloud soll nur die Platform heißen. Alles andere sind eigenständige Produkte, die nur Daten daraus ziehen. Ich mache das selber auch nicht anders. Der Alexa Skill, den ich geschrieben habe, heißt deswegen "Park Guide": https://www.amazon.de/migo-Park-Guide/dp/B07WRGM736/

Vor 2 Wochen habe ich auch mal mit ner App rumgespielt. Das Projekt nannte ich "Themepark Companion".

Wobei das wirklich nur zum "rumspielen" war. Ich hab gar nicht die Zeit neben Coaster Cloud noch irgendwelche andere Dinge zu entwickeln. Das überlasse ich dann euch

Auch den Alexa Skill will ich eigentlich irgendwann mal abgegeben.

vor 8 Minuten schrieb Tommy:

Kann sie auch für IOS anbieten, ist kein Thema - kostet mich nur Geld

 Das nervt mich selber auch. Einmalig 99 $ wäre ich ja noch einverstanden. Aber jährlich finde ich da schon nervig. Zumindest für Anbieter for kostenlosen Apps könnte die da entgegegen kommen. Aber Apple eben ...

Habe leider kein Android mehr im Haus zum testen. Weißt du, wann ca die App komplett veröffentlichst? Ab dem Zeitpunkt darf ja defintiv kein Breaking Change mehr in der API vorkommen.