migo315

Die ganze Wartezeit Prognose Diskussion bringt mich auf eine Idee. Theoretisch würde ein Kalender, bei dem sämtliche Ferienzeiten und Feiertage relevanter Länder für die Öffnungstage der Parks ja schon viel helfen, um das Risiko eines vollen Parks abzuwägen. Oder gibt es sowas schon? In meinen Fall vor 2 Wochen hatte ich selber die deutschen Ferienzeiten schon auf denn Schirm gehabt, aber nicht die unserer Nachbarländer.

Wenn jemand spontan noch eine coole Idee hat um den Reiz etwas zu pflegen zu erhöhen - nur her damit ? Die Tage möchte ich noch den Ersteller und letzten Bearbeiter prominent am Park / Attraktion anzeigen. Ansonsten könnte ich mir vorstellen, dass Nutzer die Sachen pflegen, die Möglichkeit erhalten ihr eigenes Projekt (zb. seinen Blog) auf coaster-platform.org vorzustellen. Gibt es Blogger oder Leute mit eigenen Projekten hier? Und wenn ja, wäre das ein Anreiz für euch?

Bisher waren wir mit dem Essen immer zufrieden. Letzte Woche Donnerstag allerdings gab dann doch nen Negativen Erlebnis. Zweimal Kindermenü mit Nuggets, einmal 10er Nuggest - und alle samt gefroren. Nicht Kalt oder Lauwarm - sondern wirklich steinhart gefroren. Wie dies passieren konnte, konnte sich keiner erklären.

Ich als Vater von zwei Paw Patrol verrückten Kindern kann nur sagen: Mega! Leider befürchte ich, dass Adventure Bay ab Eröffnung für den Rest dieses Jahr extrem voll sein wird.

Das kann man auch vorher holen. Waren Donnerstag dort und haben es so gemacht ?

Hier mal ein paar News. - Die "Detaillisten" für Attraktionen und Parks sehen mittlerweile recht gut (siehe Anhang). Man kann beliebig zwischen den Listentypen wechseln. - "Spielplatz (innen)" und "Spielplatz (außen)" sind zusammengefügt worden (zu "Spielplatz"). Ob es Indoor / Outdoor ist kann man ja mittlerweile in den technischen Daten vermerken (das gabs zu Anfang noch nicht). Und was größeres: Bei Datumsangaben sind nun auch Formate ohne Tag und ohne Monat möglich. Also bei "Eröffnung" kann nun auch einfach ein Jahr oder ein Jahr und Monat angegeben werden. Es komplettes Datum ist nicht mehr notwendig. Allerdings ist das eine "massive" Änderung. Bei der Eingabe des Datums muss nun ein Format beachtet werden. Folgende Daten sind nun erlaubt "1989", "1989-05" oder "1989-05-31". Sowas wie "31.5.1989" geht zum Beispiel nicht. Auch Browser Hilfen zur Datumnsauswahl sind nicht deswegen nicht mehr vorhanden (die beruhen eben darauf, dass man ein komplettes Datum auswählt). Ich werde aber zeitnah Hilfen bereitstellen, damit dies einfacher ist. So sieht dies dann aus, wenn man nur ein Jahr angibt https://coaster-platform.org/parks/phantasialand/attractions/f-l-y oder eben ein Jahr mit Monat https://coaster-platform.org/parks/movie-park-germany/attractions/bandit Das hat leider auch ein Breaking Change in der API zur folge, weil die API immer ein kompletten Zeitstempel zurück gab. Aber da nun auch "unvollständige" Daten gepflegt werden können, kann kein Zeitstempel mehr zurück gegeben werden. Die Dokumenation zur API folgt noch im Lauf des Tages.

In der Attraktionsliste (sowohl die allgemeine als auch bei Parks) kann man nun den List Typen wählen. Dafür gibt es zwei Icons, die wahlweise das bisherige "Bilder-Grid" Anzeigen oder eine Liste ohne Bilder aber mit mehr Informationen. Die neue Liste sieht noch nicht so fit aus - da werde ich noch was ändern und vermutlich auch noch mehr Informationen anzeigen. Aber die Grundidee, das man zwischen Listentypen wählen kann, wollte ich trotzdem schonmal veröffentlichen ? Hier, falls man nicht sofort erkennt was ich meine:

Heute gibt dann doch mal mehr neues "zum zeigen": - Ein Fehler bei der Ausgabe von "Ja / Nein" Feldern wurde behoben (es wurde immer nur das grünr Häkchen angezeigt) - Folgende Elemente sind hinzugekommen: In-Line Twist, Sidewinder, Batwing, Cobra Roll, Double Down, Double Up, Non Inverting Loop, Wing Over Drop, Top Hat, Roll-Over, Pretzel Loop, Cable Lift - Das Feld "Sitzart" heißt jetzt "Rückhaltesystem" und hat zwei weitere Auswählmöglichkeiten: "Westenbügel" und "keins" - Bei Attraktionslisten kann man nun rechts nach dem Eröffnungsjahr filtern (wenn man zb. "2020" eingibt erscheint FLY, bei "2016" erscheint zb. Taron) - Eine erste "Alpha"-Version einer Javascript Library zur Abfrage von Daten (für die Entwickler unter euch) liegt nun auf NPM: https://www.npmjs.com/package/coaster-platform.js Vielen Dank nochmal an alle.

Über einen Monat habe ich mittlerweile nichts zum Projekt geschrieben - in den vergangenen 30 Tagen habe aber dennoch fleißig dran gearbeitet: Auszug aus Github: Also 89 Dateien bearbeitet und an ca. 5.000 Zeilen Code verändert. Und das Resultat ... seht ihr nicht. ? Sogut wie alles was ich gemacht habe, war rein technischer Natur. Das einzige Änderungen, die vll auffalen: - "Commits" habe ich in "Logs" umbenannt, da dies für Verwirrung in Gesprächen gesorgt hat - Der Playground für die API wurde ausgelagert - Über die API können nun auch die Logs abgefragt werden Stück für Stück soll es in den nächsten Wochen zu diesem Ziel kommen: - Parks / Attraktionen können auch über die API aktualisiert und angelegt werden ( @Tommy ich glaub das hattest du auch mal angefragt?) - Benutzerhandling geht komplett über die API - Das komplette Frontend ist eine reine Javascript Anwendung welches zu 100% auf die API zurückgreift. Ansonsten bin ich weiterhin für weitere Ideen / Vorschläge zum Projekt offen ?

Naa - Paw Patrol! Das sieht man schon an den Autogrammplätzen, wenn man die Schlangen vergleicht und spätestens noch dieses Jahr, wenn Adventure Bay fertig ist und jedes Kind aus ganz Deutschland dort hin will (meine Söhne inklusive). Mit Paw Patrol hat der MP eine Punktlandung gemacht. Spongebob wird mehr von den älteren gesehen als von Kindern ? (und ja, auch ich kenne wohl mehr Spongebob Folgen als meine Söhne zusammen :-D)

Mega geil! Wurde soeben mein neuer Wallpaper auf mein (Arbeits)-Laptop!

Heute mehrere kleinigkeiten zu vermelden: - Die Felder "Themenbereich" und "Thema" waren bisher immer Textfelder. Ich hatte damals nicht dran gedacht, dass man mehrere Werte reinschreiben könnte. Diese Felder sind nun "Tags" Felder, wodurch die Werte getrennt gespeichert werden (siehe Bild section.png). - Bei der Attraktionsliste innerhalb der Parks kann man nun nach dem Themenbereich filtern (siehe facet.png). - Fehler im Javascript bei Park / Attraktionsbearbeitung behoben - Die Coaster API erlaubt nun auch die Zugriff via Javascript von anderen Seiten Sollten sich hier Javascript Entwickler befinden: Auf CodeSandbox habe ich ein jQuery Beispiel gebaut um Daten abzufragen. https://codesandbox.io/s/l91ypr26z

Die API wurde soeben aktualisiert. Beim Punkt mit den Filtern muss ich ein wenig zurück rudern. Nachfolgend einmal nochmal die Möglichkeiten: 1. doppelt "filter=" /api/parks?filter=types.name:"themepark"&filter=types.name:"waterpark" Hier wird "filter" ersetzt, bevor ich überhaupt dran komme. Daher hat sich hier nichts geändert. 2. doppelt "filter[]=" /api/parks?filter[]=types.name:"themepark"&filter[]=types.name:"waterpark" Das verarbeitet die API prinzipiell richtig. Nur wird dann eine "UND" Verknüpfung gemacht. Also werden nur Parks gefunden, die sowohl als Themepark und Waterpark gekennzeichnet sind. Ob man nun eine UND oder eine ODER Verknüpfung erwartet ist dann wohl Geschmackssache. 3. Search query /api/parks?filter=types.name:"themepark" OR types.name:"waterpark" /api/parks?filter[]=types.name:"themepark" OR types.name:"waterpark" Beides war schon vorher möglich. Hier wird eine Query gebaut die 1:1 an die Such Engine geht. Da kann man dann eben "OR" oder "AND" nutzen. 4. any / all Methode /api/parks?filter=any(types.name,themepark,waterpark) /api/parks?filter=all(types.name,themepark,waterpark) Die habe ich soeben neu gebaut und soll eine vereinfachung aus den Punkt 3 sein. Bei "any" muss nur eines der Begriffe aus types.name zutreffen (also eine OR Verknüpfung). Bei "all" müssen alle vorhanden sein (AND Verknüpfung). Du kannst dein Filter Problem also mit der Search Query (Punkt 3) oder mit der neuen "any" Methode lösen. Des Weiteren werden bei Parks unter "attractions" nun die Anzahl der Attraktionen mitgegeben. Ich werde übers Wochende die API Dokumentation mal stark zu verbessern. Hilft dir das denn soweit weiter?

Ah guter Punkt. Ich vermute mal, du machst es so: ?filter=types.name:"themepark"&filter=types.name:"waterpark" oder ?filter[]=types.name:"themepark"&filter[]=types.name:"waterpark" Dann ersetzt das letzte das vorherige. Ist ein Bug. Das passe ich an. Folgende Syntax funktioniert schon out of the box: ?filter=types.name:"themepark" OR types.name:"waterpark" bzw. ?filter[]=types.name:"themepark" OR types.name:"waterpark" Wird asap kommen. Gute Idee. Noch ist ja kein Traffic drauf. Das Projekt ist ja quasi nur hier veröffentlicht. Aber ich versuche tatsächlich auch die API so performant wie möglich zu halten. Wird sich dann Zeigen je mehr Daten und Traffic reinkommen, wie sich das entwickelt. Die Filterung läuft extra über eine Search Engine anstatt über die Datenbank. Und durch Hosting bei heroku.com kann sehr schnell skaliert werden, wenn plötzlich mal die Performance einbricht. Danke fürs Feedback!

Ahh, das ist selbstverständlich. Ich versuche ja was faires für alle rauszuholen. Soeben ging die Mail für die neuen Nutzungsbedingungen raus. Ab den 1. März ist diese dann "gültig". Solltet euch da noch was auffalen gebt ruhig bescheid. Ansonsten gebt es kaum berichtbares. Paar technische Themen wie eine Sitemap sind raus. In den nächsten Tagen werde ich wohl wieder mehr Richtung Bearbeitung und Anzeige von Parks / Attraktionen ein paar Optimierungen raushauen. Als richtiger "Go Live" Termin peile ich den 18. März an.

@flofen Neben Benutzername und Vor- und Nachname kann jetzt auch eine dritte Option ausgewählt werden: Domain Dann wird deine Domain als Name angezeigt. Vielleicht für dich interessanter? Der Link zu deiner Domain wird ja sowieso schon gesetzt.

Soeben die neusten Änderungen hochgeladen. Sogut wie alles ist aber nur Code Optimierung. Sollte daher für euch alles so sein wie bisher. Sofern euch aber vor allem beim Hochladen, Voten, Anzeigen oder Löschen von Bildern ein Fehler auffält, gibt ruhig bescheid. Die ganzen Optimierungen wurden in den Bereich gemacht. Eine kleine für euch relevante Änderung gibt es aber dennoch: Es können nur noch 6 Bilder pro Park / Attraktion hochgeladen werden. In Zukunft könnte die Zahl noch nach oben korrigiert werden aber aktuell setzen wir diese auf 6. Das hat mehrere Gründe: Zum einen nützt uns es nichts, wenn wir 20 Bilder von Taron haben und andere Attraktionen bleiben auf der Strecke. Zudem kosten gerade die Bilder recht viel "Traffic" - je mehr desto mehr Traffic und Speicherplatz. Für euch hat dies sogar Vorteile - zumindest für die, die die Platform zu Anfang unterstützen. Die, die jetzt anfangen Bilder reinzustellen, können dadurch sicher sein, dass die Bilder in Zukunft nicht untergehen.

Mach dir keinen Stress. Es drängt nicht ?

In den Profil Einstellungen ("Mein Account" => "Bearbeiten") kann man nun zwei neue Werte setzen: 1. "Copyright Name": Hier kann man einstellen, ob der Name aus deinem Account oder dein Benutzername an den Bildern angezeigt werden sollen. Standard ist "Benutzername". 2. "Copyright Url": Hier kann man eine URL angeben, die beim Klick auf deinen Copyright Hinweis gesetzt wird. Wenn man keine URL angibt, wird die URL zu deinem Profil genommen (wie bisher). Wenn du eine URL angibst, wird stattdessen diese verwendet. Ideal um auf seinen eigenen Blog oder Instagramm Profil zu verweisen. Die Einstellungen können jederzeit geändert werden. In der API wird bei jedem Bild ebenfalls der ausgewählte Name und die URL mitgegeben. @flofen, möchtest du das einmal testen / sagen was du davon hälst?

Ah cool. Ich werde morgen Abend das mal entwickeln zwecks Testing. ?

Hey, die letzten Tagen ist kaum was passiert, da ich mit meinen beiden Söhnen mehr unternommen habe. Es gibt nun auf der Startseite eine "Suggest Box". Ein Suchfeld um einen Park oder Attraktion direkt zu suchen. Einfach tippen (zb. "Taron") und kurz warten. Ansonsten gab es mehr technische Änderungen, die im Hintergrund nur relevant sind. Eine Sache gibt es aber noch: Bilder Dieses Thema habe ich die letzten Tagen sehr lange und immer wieder mit Kollegen diskutiert. Die letzte Idee war ja, dass der Author selbst entscheidet welche Lizenz er anwendet (keine oder CC). Vom Prinzip her kann ich eigentlich damit gut leben, aber wir befürchten, dass diese Lösung für die Authoren eher unpraktisch ist. Selbst wenn wir auf der Webseite und in der API Kennzeichnen, ob das Bild unter der CC liegt oder nicht, werden vermutlich andere das nicht verstehen oder übersehen und ggfs. dann Bilder verwenden, die nicht unter der CC stehen. Das ist dann für Authoren noch ärgerlicher. Daher kommt nun doch eher die Idee, alle Bilder unter die CC zu nehmen. Dann ist jedem Author sofort klar, worauf er sich einlässt. Entschieden ist dies aber noch nicht - mir fällt die Entscheidung echt schwer. Einerseits möchte ich eine einfache und klare Regulung für alle Daten - andererseits kann ich die Stellung von @flofen und vermutlich auch von dem ein oder anderen vollkommen verstehen! Vor allem wenn man noch eigene Projekte hat, wo man die Bilder verwendet. Um jetzt keine Unruhe reinzubringen, hier aber nochmal kurz nen Q&A zwecks Bilder: Unter welcher Lizenz stehen die Bilder aktuell? Aktuell stehen die Bilder unter keiner Lizenz. Der Hochlader ist der Author und Urheber und hat Coaster-Platform lediglich das Recht eingräumt die Bilder anzuzeigen. Das beduetet, keiner darf die Bilder kopieren / verwenden. Unter welcher Lizenz könnten die Bilder zukünftig stehen? Alle Textdaten stehen unter der CC-BY-ND. Daher liegt es nahe, auch die Bilder unter dieser Lizenz zu stellen. Die CC-BY-ND erlaubt es jeden (zb. App oder Blogs), das hochgeladene Bild in einem eigenen Projekt zu verwenden, sofern am Bild der Author (also dein Name) + Link genannt wird. Es muss also immer dein Name am Bild als Urheber stehen - egal in welcher App oder Webseite (dafür steht das "BY"). Außerdem darf das Bild nicht bearbeitet werden - zb. keine Person reineditieren (dafür steht das "ND"). Ihr bleibt selbstverständlich weiterhin Author und Urheber. Die CC Lizenzen wird zb. auch i.d.R. für Wikipedia Bilder verwendet. Im Klartext heißt es, dass jeder das Bild verwenden kann solang er das Bild nicht verändert und dich als Author benennt. Darf man die Lizenz für die bereits hochgeladenen Bildern ändern? Nein - nicht ohne eure Erlaubnis. Ich kann nicht die Bedingungen einfach so ändern, die ihr damals eingewillt habt. Selbst wenn ihr morgen oder die nächsten Tage Bilder hochlädt, sind diese wie bisher ohne Lizenz. Sobald eine Entscheidung über die Lizenz gefallen ist, werden die Bedingungen angepasst. Diese müsst ihr dann zustimmen, sofern ihr neue Daten hochladen wollt. Zudem könnt ihr dann mit einem Klick entscheiden, ob ihr eure bereits hochgeladenen Bilder unter die neuen Bedingungen stellt oder nicht. Bei letzteres würden dann ggfs. die Bilder aus der Platform entfernt werden. Und wann passiert das alles? Bisher ist nichts entschieden. Es wird nur "laut drüber nachgedacht". Sobald es feststeht, werden alle Benutzer per eMail informiert. @flofen Gibt es für dich ggfs. eine Möglichkeit, was sowas wie die CC attraktiver machen könnte? Ich denke da zum Beispiel an die Möglichkeit, dass jeder Benutzer für sich selbst den Copyright Hinweis anpassen kann. Also den Hinweis, der auf coaster-platform.org unter dem Bild stehen wird SOWIESO den Hinweis, den jeder einbinden muss wenn er eines deiner Bilder verwendet. Beispiel: Statt sowas mit Username: © by max_mustermann / coaster-platform.org oder mit Namen © by Max Mustermann / coaster-platform.org kann jeder den Hinweis auch für seine Bilder ändern, dass es auf das eigene Projekt zeigt: © by Max Mustermann / mustermann-blog.com Dann wäre es zwar CC - aber dein eigenes Projekt / Instagramm o.ä. wird immer unter all deinen Bilder stehen. Wäre ja eine gute Werbung ?

Heute gabs Anpassungen an der API. Im Hintergrund wird auch für die "normale" Ansicht die API verwendet. Wenn euch daher Fehler auffalen, vorallem bei der Filterung für die Sicherheitsbestimmungen oder ähnliches, dann ruhig bitte melden. Ansonsten habe ich ein paar neue Filter für Attraktionen eingefügt (FastPass, Single Rider, Standort, Barrierefrei) und den Filter für Elemente rausgenommen. Letzteres wird wieder kommen, aber dann auf einer Metrik Seite um dies noch genauer umsetzen zu können.

Kurz und knapp eben aus der Mittagspause: Habe ich soeben gefixed. Magst du nochmal schauen / testen?

Sorry, hatte mich beim Beispiel oben von dir scheinbar verguckt. Ich bin davon ausgegangen, du möchtest die Array Syntax und dennoch mit Keys arbeiten. Ein Array mit Objekten ist natürlich valide und stimme dir zu, dass es sauberer aussieht. Ich habs als Punkt bereits aufgenommen und wird die Tage angepasst. Schwieriges Thema. Einerseits möchte ich natürlich, dass coole Bilder gepflegt werden. Andererseits kann eine CC Lizenz für den ein oder anderen ein Grund sein, keine Bilder zu pflegen. Ich versuch da kurzfristig mal eine Lösung zu finden. Danke fürs Feedback zur API ? // Update Ab jetzt kann der Status einer Attraktion gepflegt werden. Alle bisher gepflegten Attraktionen erhalten den Status "In Betrieb". Zudem kann nach den Status gefiltert werden.

Ich werde mir mal eine Lösung überlegen. Argh, das hatte ich mir sogar mal vorgenommen. Aber scheinbar ging der Punkt unter. Habe ich jetzt als Punkt aufgeschrieben und wird definitv die Tage angegangen. Interessanter Punkt, bei dem ich selbst schon in ein Konflikt kam. Eigentlich will ich in der Attraction Resource keine Park Sachen, weil das zuviel frisst. Wenn ich mir 96 Attraktionen ausgeben lassen ist das ein overhead für jede Attraktion nochmal den Park nachzuladen. Eine Zeitlang gab es sogar Attribut "park" auch nicht. Zum Filtern von Attraktionen nach Parks war dann zumindest die ID aber irgenwann notwendig. Und daraus entstand, dass ich zumindest ein paar wenige Daten zum Park ausgebe. Ich hätte es lieber, dass einer explizit die Park Resource anfragt wenn er was vom Park wissen möchte. Damit es vielleicht ein wenig klarar Strukturiert ist, kann ich mir vorstellen den Park Attribut wirklich nur auf die ID und ggfs. ein Link zur Park Resource zu beschränken. Was meinst du? Ich verstehe was du meinst. Allerdings kennt JSON kein Array mit Keys. Es gibt nur die array Syntax ["foo", "bar"] oder die objekt Syntax {"field1": "foo", "field2": "bar"}. Diese Syntax ist invalide: [field1: 'foo', field2: 'bar']. Man könnte die Keys aus den Attributen entfernen, was allerdings dazuführt, dass man durch alle Attribute iterieren muss um an ein gesuchtes Attribut zu kommen. Aber hier ein array anstatt ein objekt zurück zu geben hört sich dennoch richtiger an - trotz des Handicap. Werd das dann anpassen. Auch an diversen anderen Stelle. Danke für den Hinweis, wäre mir gar nicht aufgefallen ? Das ist aktuell tatsächlich by design. Weil die Bilder nicht unter der CC Lizenz stehen und somit von niemanden verwendet werden dürfen, wird keine konkrete URL ausgegeben. Das überhaupt ein paar Informationen zu den Bilder ausgegeben werden, liegt nur schlicht daran, weil wir uns selbst an die API bedienen und diese Information brauchen. Ggfs. kann aber bald jeder Benutzer für sich selbst entscheiden, ob er seine Bilder unter die CC Lizenz stellt (siehe letzte Beiträge hier) - dann wird auch eine URL ausgegeben.