Zum PlayerInterface

Eine Frage an die Verantwortlichen:

Wozu macht man ein Interface zur Protokollspezifikation, wenn es ständig verändert wird!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?

Geht es nur mir so, oder kommt sich sonst keiner bisschen veräppelt vor?

Ich bitte um eine rege Diskussion! Vor allem da alle davon betroffen sind (die dieses Praktikum machen).

... na ja. Also zu diese Frage sollte schon lange einen Thread geöffnet werden.

Nicht nur, dass der Protokoll ständig verändert wird, sondern auch nur mit überflüssigen Sachen. Manchmal denke ich mir, da hat sich niemand eigentlich Gedanken gemacht, wie die Implementation ausschauen wird. Theorie + Idee ist eine Sache, ... wenn man aber implementieren beginnt da entstehen andere Probleme. z.B. - Warum hat niemand gedacht über eine gescheite Fehlerbehandlung. computeMove(...)/trackMove(...) throws IOException währe eine wunderbare Idee, findet Ihr nicht? Erst dann kann man Sachen wie reconnect SAUBER implementieren?

...

Die machen das entweder weil sie nicht nachgedacht haben, oder um unsere Team-Fähigkeit zu testen.

Keiner verbietet euch das PlayerInterface um ein throws zu erweitern, das ändert ja das Protokoll nicht!

... na das währe super. Falls die Offiziellen das auch bestätigen würden währen wir als Team total zufrieden.

Alexander V. hat Folgendes geschrieben:

... na das währe super. Falls die Offiziellen das auch bestätigen würden währen wir als Team total zufrieden.

genaugenommen müssen wir ja nichtmal die auf der hp zur verfügung gestellte datei benützen, unser programm muss nur das protokoll erfüllen

Was bitte soll das sein?
public static final String SET_TIME_OUT = "setTimeOut";

Ich sende das doch nie, oder täusch ich mich.. es wäre sinnvoller unsere Timeout-Variable als long in das PlayerInterface zu legen...

(und zwar sowohl das Spielzug-Timeout, als auch die Zeit die man hat um das OK zurückzusenden)

Um auch mal wieder was zu schreiben,

das traceAndComputeMove ist ja mal ein lustiger Ansatz. Es ist zum Einen echt blöd zu implementieren, weil man für den ersten und den letzen zug Spezialfälle hat. Desweiteren ist die Veralgemeinerung mit Spielen für mehr als 2 Benutzer sehr komischt. Und nicht zuletzt bewirkt man damit ja auch nichts.

Der Ansatz für sämtliche RMIs ausser computeMove 2 Sekunden Zeit zu gewähren und für computeMove(timelimit) genau timeLimit + 2 Sekunden einzuräumen und dann je nach Gusto timeLimit auf 56 Sekunden zu stellen bezweckt genau das selbe wie traceAndComputeMove(60 Sekunden).

Dieses traceAndComputeMove macht meiner Ansicht nach dieses schöne n-Spieler-fähige Protokoll total kaputt.

Also die ständigen Änderungen an der grunsätzlichen Architekur und am PlayerInterface sind unnötiger Aufwand und nerven irgendwie. Sowas hätte doch in einem ordentlichen Konzept bereits vorher festlegt werden können, statt hinther zu sagen, dass es ja so zum Beispiel für Cheating anfällig ist.
Genauso unsinnig ist es ja auch computeMove nur einmal auszuführen, weil ist der Ping auch nur irgendwo im Netzwerk wegen mehr Traffic höher sein kann, fällt man aus dem Zeitfenster, das sicher sehr gering sein wird...
Und sollte es zum Beispiel 1 Sekunde nur sein und wegen höhrem Netzwerk Ping dann verlieren ...da gehört auch eine regemäßige computeMove Übertragung her und am Ende der Zeit wird der letzte noch erhaltene Zug einfach genommen.
Ansonsten gibst eigentlich noch weitere Cheat Einschränkungen wie Verbot von Datenbanken oder Netzwerkanbindung an Datenbanken...??

Globetrotter hat Folgendes geschrieben:

Ansonsten gibst eigentlich noch weitere Cheat Einschränkungen wie Verbot von Datenbanken oder Netzwerkanbindung an Datenbanken...??

Heute im Plenum wurde alles verboten was nicht lokal auf einem beliebigen CIP-Rechner gestartet werden kann (und sich auf diesen beschränkt) und mit Java bedient wird.

Bedienung ist das eine. Man kann ja auch eine Java-Anwendung schreiben die einen C++ Code in nen GNU C++ Compiler jagt und die so erzeugte native KI befragt.
CIP ist allesamt Linux, und größtenteils wohl ein und dasselbe System, das macht es sehr einfache sich was lustiges zu basteln. Zumal man ja auch nicht auf das offizielle Ranking warten muß da man ja selber über Netz so ziemlich alles loggen kann. Und wenn man sich geschickt anstellt (UDP, ...) sieht man's noch nicht einmal wenn man was schickt.

Ich will ja niemandem etwas unterstellen, aber ich befürchte, dass ersteres zutrifft...

Oha, das ist ja schon mal wirklich ein bisschen ein Lichtblick. Da ich tatsächlich davon ausging, dass wir das Interface implementieren müssen, ist das schon eine angenehme Sache. Aber wenn das nicht der Fall ist... danke mal für diese Info

Angesichts einer gewissen Resonanz, die dieser Thread in der Kürze der Zeit erhält, glaube ich, dass noch längst nicht alles zu dem Thema gesagt wurde. Ich möchte deshalb nochmal jeden bitten, der sich auch nur ein wenig betroffen fühlt, sich hier "auszulassen". Mag sein, dass es für uns zu spät ist, aber es wird ja auch noch weitere ProgPrakts geben - und hoffentlich wird da der eine oder andere Verantwortliche seinen Kopf schon vorher bisschen anschalten, in Rückblick auf diese Kritik hier.

Immerhin haben die Offiziellen den Abgabe-Termin für die in den Folien stehenden Änderungen auf die 2. Kalenderwoche verschoben.

Leider wurde diese Information die in der Abgabe(KW)-Spalte zu finden sind, in den Folien auf der letzten Seite nicht mehr angepasst. (es gelten aber erstere)

Außerdem ist ein Javadoc Bug im Playerinterface. Also mein javadoc jammert bei

/**
 * @return Only the following characters are allowed: {@see #LEGAL_NAME}}
 */
public String getName();

und ich denke es sollte folgendermaßen heißen:

/**
 * @return Only the following characters are allowed: {@link #LEGAL_NAME}}
 */
public String getName();

Abgesehen davon könnte man die UserStories mal wieder aktualisieren.
(z.B GUI kommt noch.. naja für Reversi schon, aber in TTT war diese Woche abgabe dafür soweit ich weiß )

heyhey , ich hab die lösung für soviel gejammer. wir legen zusammen und fahren mit einem mobilen cip-pool in einen Vw-bus auf.dort darf dann jeder sein eigenes protokoll verwenden , das programm in c , von mir aus auch gleich in assembler sein.und der gewinner veranstaltet dann das praktikum nächstes jahr.aber bitte nicht so diletantisch wie dieses jahr.manche leute haben scheinbar sonst keine probleme,wahnsinn.

jaja, schon OK Schlaubi Schl... ähhh, Fabulus ^^

Das kann ich nur voll und ganz unterschreiben. Lästiger gehts echt nicht..

Es ist natürlich, dass ihr euch hier über die Änderungen ärgert. Ihr könnt mir aber glauben, wenn ich sage, dass das bisher in jedem Semester mehr oder weniger so gewesen ist. Man sollte sich an den Gedanken gewöhnen, dass das auch weiterhin so bleiben wird. Ich habe meinen Gruppen von Anfang an gesagt, dass das PlayerInterface ganz sicher noch verändert wird, und dass sie ihre Implementierungen so allgemein wie möglich halten sollen um Änderungen schnell und einfach einbauen zu können. Und bisher waren wirklich nur kleine Änderungen am Protokoll, da erwarten uns sicher noch weitere (und größere) Änderungen.

Ich werde mich nicht dazu äußern, warum das so ist. Ich weiß nur, dass es immer so gewesen ist.

Man kann das ja mal damit vergleichen, dass man einen Client schreibt, der gleichzeitig mit dem Server erscheinen soll (welcher folglich noch in der Entwicklung ist). Da kann es denke ich durchaus auch zu kleineren und größeren (Protokoll-)Änderungen während der Entwicklung kommen (je nachdem wie das Projekt geplant ist).

Und sonderlich tragisch fand ich die bisherigen Änderungen in der Tat auch nicht.

Und wie meint ihr wird das dann, wenn ihr mal Software für eure lieben Kunden entwickelt, die leider nicht so recht wissen, was sie wollen, bis ihr es ihnen fertigprogrammiert hab und zeigen könnt? Was meint ihr, wie oft ihr eure Anforderungen dann ändern müsst? Und da heißt es doch immer die Uni sei so praxisfern

Ich werde Lehrer, ich entwickle keine Software :p
Gegen Änderungen, die einem selbst sinnvoll erscheinen hätten glaub ich weniger Leute eine solche Abneigung. Das kann ich von denen, die wir hier vor den Latz bekommen leider nicht wirklich behaupten (was nicht heißen muss, dass sie es nicht sind).
Und der Kunde zahlt Geld für den Verschleiß meiner Nerven, der darf das

Nein, du musst es nur den Schülern beibringen, bzw. grundlegendes Verständnis vermitteln. Dazu muss man es selbst natürlich nicht können </ironie>

In der Tat, welche wären denn da sinnlos? Die meisten steigern die hypothetische Stabilität und Integrität des Servers enorm, andere sind halt "nur" praktisch.

Manuel Grabowski hat Folgendes geschrieben:

Und der Kunde zahlt Geld für den Verschleiß meiner Nerven, der darf das

Während die Uni (wenigstens noch ein Semester) kostenlos ist...? Wie undankbar, das wenn die Steuerzahler hören würden!

Manuel Grabowski hat Folgendes geschrieben:

Und der Kunde zahlt Geld für den Verschleiß meiner Nerven, der darf das

Das Praktikum zahlt nen Schein

Ich werde nächstes Mal ein "Bitte nicht so ernst nehmen ^^" unter meinen Text setzen, aber Danke für eure Reaktionen

Hab ich auch nicht ernst genommen. Meine Antwort ist ebenso scherzhaft, wie dein Kommentar.

Adrian Klein hat Folgendes geschrieben:

Manuel Grabowski hat Folgendes geschrieben: Globetrotter hat Folgendes geschrieben: Also die ständigen Änderungen an der grunsätzlichen Architekur und am PlayerInterface sind unnötiger Aufwand und nerven irgendwie. Das kann ich nur voll und ganz unterschreiben. Lästiger gehts echt nicht.. Und wie meint ihr wird das dann, wenn ihr mal Software für eure lieben Kunden entwickelt, die leider nicht so recht wissen, was sie wollen, bis ihr es ihnen fertigprogrammiert hab und zeigen könnt? Was meint ihr, wie oft ihr eure Anforderungen dann ändern müsst? Und da heißt es doch immer die Uni sei so praxisfern

Da ist aber ein kleiner unterschied. Weil da können wir eben so (den Code, wohlgemerkt!) ändern, wie wir wollen, um die Vorraussetzungen des Kunden zu erfüllen (was ja meistens Oberflächlichkeiten sind). Der sagt was man machen soll, was er noch haben oder nicht haben will. Aber er sagt nicht: "Euer Code muss so sein!" (Und das Interface macht nichts anderes, als uns in solche Sachen reinzuzwingen. Das kann man natürlich nur rausfinden, wenn man sich mit der Sache beschäftigt, und genau darum geht's ja.) Dann kann er's doch auch gleich selber machen?

Und tatsächlich gibt es einige Leute in diesem Praktikum, die davon ein Liedchen singen können, wie es in der Wirtschaft aussieht , womit wir wieder bei deinem letzten Satz wären... Davon abgesehen ist mir natürlich klar, dass das Praktikum eine sehr gute Plattform zum sammeln für praktische Erfahrungen ist