migo315

OK, Thema "Verein" scheint soweit also erstmal uninteressant. ? Das Phantasialand hat seine neue Webseite veröffentlicht. Wie es der Zufall will, arbeite ich aktuell auch an einem kompletten Rework. Und damit meine ich nicht nur ein paar neue Farben sondern ein komplett neues, modernes Design. Dabei wird die Webseite komplett auf Javascript setzen, wodurch das surfen sehr "smooth" wirkt und Performance Vorteile bringt. Ich plane das Design bis Sonntag Online zu nehmen - aber mit einem kleinen Nachteil: Es wird nur das "Frontend" sein. Also das, was man als normaler Besucher sieht. Das Backend (Anmelden, Park bearbeiten, Attraktion bearbeiten) wird Schrittweise bis Ende des Monats nachgezogen. So kann ich euer Feedback zum Design frühzeitig erhalten und entsprechend Lösungen entwickeln bzw. Bugs fixen. Hat hier irgendjemand denn "Schmerzen" wenn die Bearbeitungsfunktion für ca. 2 Wochen nicht funktioniert? Soviel Aktivität ist ja gerade sowieso nicht. By the way: Der Grund für das neue Design ist nicht, weil ich unbedingt ein neues Design will. Um die Bearbeitung zukünftig noch eleganter umzusetzen und komplexere Formulare anbieten zu können (zb. für Kalenderdaten etc) möchte ich stärker auf Javascript setzen (VueJs). Anstatt aber nun das bisherige umzubauen sah ich die Chance direkt auch mal nen frisches Design mit rauszuhauen. Zudem wird die Pflege der Webseite für zukünftig weitere Entwickler einfacher, weil lediglich VueJs Know-How notwendig sind.

Ich finde die Seite weitaus übersichtlicher als vorher. Und das man sich auf Mobil konzentriert ist völlig normal. Ein großteil der Besucher der Seite wird diese Mobil oder per Table aufrufen. Das gehört zur heutigen Zeit dazu. Der Desktop Bereich wird in Zukunft für solche Seiten immer weniger eine Rolle spielen. Das die Seite zum Start nicht unbedingt rund läuft, ist auch völlig normal. Ein Go Live einer neuen Seite läuft kann immer mal Probleme hervorrufen. Das hat auch nicht immer zwangsläufig mit fehlender Qualitätssicherung zu tun. Wobei ich bisher keine Fehler festgestellt habe. Einzig die Video's lahmen die Seite echt extrem. Und dabei scheinen diese schon runterskaliert zu sein. Das ist tatsächlich nervig. Das bekommen die aber sicher noch im Griff.

Als ich letztens meinen Sohn (5 Jahre) aufklärte, dass die Colorado keine Holzachterbahn ist, meinte tatsächlich jemand in der Schlange dagegen zu argumentieren und zu diskutieren. Das hat mich selber schon echt genervt.

Wie angekündigt, nur internals gemacht. Aber hier mal was interessantes: Ich spiele mit den Gedanken ein Verein zu gründen. Hierzu rede ich seit ein paar Tagen mit einem Kollegen, der bereits selber einen Verein führt. Das Ziel des Vereins wäre dann der Betrieb und die Entwicklung von coaster.cloud. Dabei sollen die Mitglieder die Möglichkeit haben coaster.cloud mitzugestalten. Das hätte folgende Vorteile: 1. coaster.cloud wäre nicht mehr auf einer Person angewiesen, sondern ein kompletter Verein steht dahinter (Zukunftssicher) Sogut wie die meisten Blogs, Foren etc. steht eine Hauptperson dahinter. Bei coaster.cloud ist es nicht anders. Wenn diese Person mal, aus welchen Gründen auch immer, nicht mehr kann oder will, kann so ein Projekt schnell verenden. Durch ein Verein gibt es diese Situation nicht mehr. Es gibt keine Hauptperson. Coaster.cloud gehört dann den Verein und nicht einer Person. Und der Verein kann entscheiden, was damit passiert. Das halte ich für sehr zukunftssicher. 2. Durch die aktive Mitgestaltung der Mitglieder könnten sich einige Leute finden die sich aktiv engagieren Wie in Punkt 1 erwähnt, gibt es keine Hauptperson mehr. Der Verein und die Satzung entscheiden, wie das Projekt weiter geführt wird. Das gibt zwangsläufig mehr Chancen seine Ideen durchzusetzen, da keiner ein "Veto" rausbringen kann. Es entscheiden dann zwangsläufig die Demokratie. Ich stell mir das vereinfacht so vor: Jedes Mitglied kann einen "RFC" einstellen (zb. "coaster.cloud soll zukünftig Instagram einbinden"). Ein RFC enthält dann eine genaue Beschreibung was man vor hat. Andere Mitglieder können darauf kommentieren, Fragen stellen. Irgendwann geht es zur Abstimmung. Jedes Mitglied im Verein kann Online dafür oder dagegen stimmen. Die Mehrheit gewinnt. 3. Zukünftige Kosten könnten über kleine Mitgliedsbeiträge gesammelt werden Den Punkt sehe ich zum aktuellen Zeitpunkt eher nachlässig. Aber theoretisch gibt es die Möglichkeit durch Vereinsbeiträge zukünftig manche Sachen finanzieren zu können. Was haltet ihr davon? Natürlich bleibt coaster.cloud immer kostenlos und für jeden Verfügbar - egal ob Mitglied oder nicht. Aber Vereinsmitglieder könnten eben die Zukunft des Projekts aktiv mitbestimmen. Ich sehe das als klaren Vorteil (und das obwohl ich durch Punkt 1 und Punkt 2 quasi meine eigenen Rechte beschneide, da auch ich mich der Vereinssatzung fügen müsste).

Definitiv! Damals fand ich die Show ebenfalls lustig.

Ich muss zugestehen, dass ich die Crazy Cops Show auch einfach nur grottig finde (Stunts sind gut, aber die Show ansich finde ich einfach nur schlecht). Der "Hype" für diese Show ist für mich auch nicht verständlich.

Gilt die MP Jahreskarte überhaupt noch, wenn die Saison im MP durch ist? Da war doch mal ein Hinweis, dass die Angebote auf der Karte, wenn nicht anders angegeben, zum Saisonende nur gelten ... ?!

Ich fahre auch immer ohne, weil mein Sohn noch keine haben darf. Bisher habe ich aber noch kein einzigen gesehen, der ebenfalls keine Brille auf hat. Ich denke, der Aufwand das zu organisieren lohnt sich nicht.

In den Awards tut sich doch generell nicht so viel - mal abgesehen von Neuheiten, oder? Ich verfolge die ehrlich gesagt nicht. Aber richtige Überraschungen oder große Änderungen von Jahr zu Jahr sind doch eher selten?

Ich war im September und vergangenen Mittwoch auf Crazy Bats. Und bei beiden Male wurden die Brillen ebenfalls sofort wiederverwendet, was die Abfertigung verlangsamt hat. Das scheint also ja Wochen so zu laufen (oder ich hatte einfach Pech)

Das kommt auf jeden Fall noch. Das ist auch schon länger geplant. Aktuell geht folgendes: - Abfrage der aktuellen Wartezeiten eines Parks - Abfrage der Wartezeiten eines Parks zu einem bestimmten Zeitpunkt (zb. gestern um 14:00 Uhr) Folgendes soll noch zukünftig gehen: - Abfragen der aktuellen Wartezeit für eine Attraktion - Abfrage der Wartezeit für eine Attraktion zu einem bestimmten Zeitpunkt - Abfrage einer Wartezeitliste für eine Attraktion innerhalb einer Zeitspanne - Abfrage einer Wartezeitliste für einen Park innerhalb einer Zeitspanne Das wird aber vermutlich noch ein wenig dauern. Aktuell werden die Daten direkt aus der Datenbank abgefragt. Alle anderen Daten (Parks und Attraktionen) dagegen von der Search Engine aus einem Cache. Das hat enorme Geschwindigkeitsvorteile. Bevor ich die neuen Abfrage für die Wartezeiten einfügen, möchte ich auch die Wartezeiten in die Search Engine implementieren. Und da bin ich zur Zeit noch dran.

BTW: Jeder der den Thread mitverfolgt sollte es eigentlich wissen, aber hier nochmal als Info: Die alte (legacy) REST API wird am 30. November (also heute) abgeschaltet! Auch die subdomain "api.coaster.cloud" wird heute abgeschaltet. Aufrufe können dann ausschließlich über die (viel geilere) GraphQL (aka Open Coaster Interface) gemacht werden. Intern baut auch sehr viel auf die alte REST API auf, deren Code mit der Abschaltung mit der GraphQL Struktur ausgetauscht wird. Immerhin über 2.700 Lines entfernt.

Ok, nehme ich als "Feature request" nachher auf. Genauso wie mit den Stationen. Im Changelog habe ich die letzten Änderungen einmal gesammelt. Ua. die neuen GEO Location Felder für Attraktionen, ein neues "label" wird für die Geschichtseinträge, Zeitzonen für den Park, Sortierung nach GEO Location* und ein neuer Parameter für Debugging von Requests. Dieses Wochenende wird nicht viel "offensichtliches" passieren. Ich werde viel an interne Code Struktur und Optimierungen arbeiten. Gestern Abend habe ich Lasttests durchgeführt und ein paar Baustellen erkannt. Vielleicht werde ich zwischendurch ein paar Parks weiter pflegen. * Sortierung nach GEO Location: Wenn ein Location Filter gesetzt wird (also man Parks oder Attraktionen nach Koordinaten filter), wird das Ergebnis nun nach "Entfernung" sortiert. Das also am nächsten gelegene Park / Attraktion zuerst, das am weitesten entferne zuletzt. Sobald man aber eine andere Sortierung angiibt (zb. Alphabetisch), wird dies natürlich danach sortiert. Auch hier nachzulesen: https://github.com/migo315/open-coaster-interface/blob/master/examples/location_filter.md

Das geht bereits. Hier als Beispiel:

Uh, sehr interessant! Ich mach mir mal Gedanken wie ich das technisch am Besten verwurzeln kann. Die beiden Attraktionen im Movie Park habe ich GEO Daten ergänzt. Heute (spät) Abend stelle ich dir dann die GraphQL Methoden zum bearbeiten der GEO Daten bereit. Dann musst du das nicht mehr händisch machen ?

Ist der fliegende Teppich in der nähe von Jimmy. Kann ich nachpflegen. Das war früher die "Swiper" Attraktion, Wurde umthematisiert für Paw Patrol. Kann ich ebenfalls nachpflegen.

Ein Besucherplus muss ja nicht zwangsläufig für ein Plus in den Kassen gesorgt haben. Bzw. selbst wenn, nicht zwangsläufig 1:1 im Verhältnis. Soweit ich aber mal mitbekommen habe (Vorsichtig: Flurfunk ohne Quelle), soll der Movie Park sowieso schon eines der "lukrativeren" Parks der spanischen Gruppe sein. Leider bleibt das Geld aber nicht dort und fehlt somit für Investitionen.

Hast du das Beispiel auf https://github.com/migo315/open-coaster-interface/blob/master/examples/location_filter.md einmal ausprobiert? Das sollte eigentlich funktionieren und als Ergebnis Phantasialand zurück bekommen.

Ja, sowas gabs schon seit der REST API. In der GraphQL habe ich dies ebenfalls eingefügt. Ich habe die Beispiel Dokumentation auf Github mal eben ergänzt: https://github.com/migo315/open-coaster-interface/blob/master/examples/location_filter.md Sollte es mal bei dem ein oder anderen Park fehlen, müssen dort noch die GEO Koordinaten eingepflegt werden. Kannst mir ja bescheid geben oder eben schnell selbst pflegen ?

Sehr cool! Dann bin ich mal gespannt. Gibst schon nen Termin wann es Ready sein soll? Die neue GraphQL API wird wie geplant morgen Vormittag versioniert (1.0.0) und wird keine Breaking Changes mehr erhalten. Dann kann auch zukunftsicher darauf entwickelt werden. https://github.com/migo315/open-coaster-interface

Ah ok. Ärgerlich wenn man das nicht mitbekommen hat ?

War heute im Park und habe Crazy Bats verpasst, da diese schon "regulär" um 16 Uhr dicht gemacht hat. Ist das normal?

Aktuelles Beispiel:

Irgendwie strange, aber für mich macht das tatsächlich auch nen Unterschied. Also ich kann ohne Probleme mit Augen zu fahren, aber sorgt bei mir für ein anderes "Empfinden" der Fahrt als mit offenen Augen im dunklen. Keine Ahnung weshalb ... ?

Ich muss zugestehen, dass ich nicht versionieren wollte. Eigentlich will ich mir die Arbeit, dass vll irgendwann 2-3 Versionen existieren die ich gleichzeitig warten muss, nicht machen. Aus dem Grund ersetzt auch die GraphQL Schnittstelle die REST API anstatt diese zu ergänzen. Allerdings ist dies vermutlich zu kurz gedacht. Wenn ich in einem Jahr vll doch versionieren will, habe ich das Problem die Versionierung ohne Breaking Change reinzubkommen. Also versioniere ich nun doch von Anfang an. Ohne aber die Absicht zu haben in nächster Zeit eine neue "Major" Version rauszubringen. Die Dokumente samt neuer Endpunkt habe ich soeben angepasst: https://github.com/migo315/open-coaster-interface Dort habe ich nun auch geschrieben, dass die Version ab Montag festgesetzt wird. Sprich bis Sonntag könnten theoretisch noch Breaking Changes vorkommen. Vermutlich wird es aber keine mehr geben - und wenn, dann höchstens das ein Feld umbenannt wird. Ich will mir einfach bis Sonntag Zeit geben die Schnittstelle zu prüfen* bevor diese dann für Jahre quasi so festgesetzt wird. * Als Beispiel: Ich kenne eine Schnittstelle, die hat einen Bestell Endpunkt namens "oder" statt "order". Da dies aber so Live genommen wurde und erste Consumer dies verwendet haben, konnte sie diesen Rechtschreibfehler nicht mehr korrigieren. Genau sowas würde ich gern verhindern ?