Autor Thema: Open Data à la Viennoise  (Gelesen 12114 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

13er

  • Verkehrsstadtrat
  • **
  • Beiträge: 27735
Re: Open Data à la Viennoise
« Antwort #30 am: 02. Januar 2013, 22:17:52 »
Bei ordentlichem Programmieren kommt es nicht vor, daß man in einer Endlosschleife landet.
Naja, so pauschal würd ich das nicht sagen. Es gibt doch immer wieder mal Code, wo man im Vorhinein nicht an sämtliche Möglichkeiten denkt. Programmieren ist im Grunde extrem komplex, auch wenn es immer wieder so dargestellt wird, als könne man mit einem Humboldt-Kurs den Programmierer 2 machen.

Jedenfalls habe ich im Umgang mit der WL-API (Qando) meine Kompetenz im Punkto Java Exception Handling enorm steigern können, das ist doch auch was! 8)
Mit uns kommst du sicher... zu spät.

Linie 41

  • Geschäftsführer
  • *
  • Beiträge: 11667
    • In vollen Zügen
Re: Open Data à la Viennoise
« Antwort #31 am: 02. Januar 2013, 22:50:21 »
Naja, so pauschal würd ich das nicht sagen. Es gibt doch immer wieder mal Code, wo man im Vorhinein nicht an sämtliche Möglichkeiten denkt.
Immerhin KANN man an alle Möglichkeiten denken. ;D
Ich verstehe das Konzept dahinter nicht und bin generell dagegen.

invisible

  • RBL-Disponent
  • ***
  • Beiträge: 1577
Re: Open Data à la Viennoise
« Antwort #32 am: 03. Januar 2013, 01:14:06 »
Das mit dem gespiegelten System ist sicher nicht so schlecht, denn dann kann man bei Programmschleifenfehler das aktuelle System mit zuvielen gleichzeitigen Zugriffen nicht in die Knie zwingen. Das Hauptproblem, wieso qando zeitweise nur Plandaten liefert. Das ist glaube ich auch eine Grundvoraussetzung für ein OpenData. Alles andere Wäre meiner Meinung nach ein programmiertechnischer Selbstmord.

Und alle, die jetzt kommen, beim Programmieren kommt es nicht vor, dass man sich auf einmal in einer Endlosschleife befindet, die haben offensichtlich noch nie ernsthaft programmiert.

Klar kommt das vor, und eine ordentliche Schnittstelle muss natürlich damit rechnen, dass sich die Clients nicht korrekt, geschweige denn nett verhalten.
Aber dafür gibt es geeignete und erprobte Ansätze. Einerseits wird man natürlich einen Cache einbauen, der die Ergebnisse der Abfrage ein paar Sekunden lang vorhält - das reicht schon mal um die Last am Server deutlich zu reduzieren bzw. besser vorhersehbar zu machen (z.B. kann man bei den Haltestellen-Echtzeitinfos dann davon ausgehen, dass innerhalb von x Sekunden maximal jede Haltestelle einmal abgefragt wird; darauf kann man dann die Serverleistung auslegen). Und dann wird man natürlich irgendeinen Zugangsmechanismus einbauen, der allzu häufige Abfragen blockiert (z.B. dass die selbe Anfrage von der selben IP nur einmal alle x Sekunden beantwortet wird).
Wenn man nett ist versieht man die ausgelieferten Daten noch mit einer Gültigkeitsdauer (die überraschenderweise mit der Cache-Dauer korreliert - wer hätte das gedacht), damit sich korrekt arbeitende Clients daran orientieren können und nicht mehr Anfragen stellen als nötig. Eine prognostizierte Ankunftszeit ändert sich ja (hoffentlich) nicht alle paar Sekunden komplett. Das kann man sogar dynamisch machen, z.B. wenn einmal die nächste Ankunft erst in 10 Minuten berechnet wurde zahlt es sich nicht aus, dass alle 10 Skeunden neu durchzurechnen und man kann den Wert länger aus dem Cache ausliefern, wohingegen - wenn der Zug bereits knapp vor der Haltestelle ist - 10 Sekunden den Unterschied zwischen '1' und 'boarding' ausmachen könnten.

Alles keine Hexerei.
Liebe Fahrgäste: Der Zug ist abgefahren.