All posts by Andreas Scharf

Presentation requirements

Seminar, WS1314

Every author must present his work to the audience. Please note:

  • 15 minute presentation. It is very important to meet these 15 minutes as exactly as possible. +/- 30 seconds is ok.

Important: Deadline for submitting the slides is 9th of February, 11:59 p.m. Later submission will result in a deduction of points.

Review Requirements

Seminar, WS1314

These are the requirements and outline for writing a review:

  • Based on these review examples:
  • Reviewer information
    • Lastname,Firstname, Mail adress
  • Reviewers Experience
    • 1-5 (1 never heard about that before, 5 I’m an expert)
  • Rating
    • +3 to -3:
      • +3 = Strong accept
      • +2 = accept
      • +1 = weak accept
      •   0 = borderline (I don’t care, let the others decide)
      • -1 = weak reject
      • -2 = reject
      • -3 = strong reject
  • Evaluation
    • Short summary,
      • 3-4 sentences, approx. length of an abstract
    • Content:
      • some paragraphs (depends on length of paper), also bullet-point style
      • Understandable?
      • Enough (8-10 pages, more is ok)?
      • The paper should either provider a good overview OR should be focused on a dedicated subject.
    • Well written?
      • 1-2 sentences (depends on length of paper)
      • examples for bad phrases
    • Layout, format
      • 1 sentence
  • Optional: Comments for the PC (will not be sent to the authors)
    • Some sentences
    • Things you want the program committee to know, e.g.

Detailed information will be given at the event on Monday, 13th of January 2014.

Important: Deadline for reviews is Sunday, 19th of January, 11:59 p.m. Later submission will result in a deduction of points.

Seminar Auftaktveranstaltung WS 13/14

Seminar, WS1314

Die Auftaktveranstaltung zu den im Fachgebiet angebotenen Seminaren findet am kommenden

Montag den 28.10.2013 um 13 Uhr im Seminarraum des FG Software Engineering statt.

Bisher bieten wir folgende Themen an:

  • Apache Shiro“Apache Shiro is a powerful and easy-to-use Java security framework that performs authentication, authorization, cryptography, and session management. With Shiro’s easy-to-understand API, you can quickly and easily secure any application – from the smallest mobile applications to the largest web and enterprise applications.”
  • Apache Giraph“Apache Giraph is an iterative graph processing system built for high scalability. For example, it is currently used at Facebook to analyze the social graph formed by users and their connections. Giraph originated as the open-source counterpart to Pregel, the graph processing architecture developed at Google and described in a 2010 paper.”
  • Apache MahoutScalable machine learning and data mining
  • Xcore“Xcore is an extended concrete syntax for Ecore that, in combination with Xbase, transforms it into a fully fledged programming language with high quality tools reminiscent of the Java Development Tools. You can use it not only to specify the structure of your model, but also the behavior of your operations and derived features as well as the conversion logic of your data types. It eliminates the dividing line between modeling and programming, combining the advantages of each. All this is supported for both generated and dynamic EMF models.
  • Xtend “Xtend is a flexible and expressive dialect of Java, which compiles into readable Java 5 compatible source code. You can use any existing Java library seamlessly. The compiled output is readable and pretty-printed, and tends to run as fast as the equivalent handwritten Java code.”

 

Falls ihr selbst ein tolles Thema habt, bringt die Idee einfach mit – meist findet sich dann auch ein Betreuer!

SE 1 Abschlussturnier am Freitag, 13.09.2013

Software Engineering I, SS13

Liebe SE 1 Teilnehmer,

es ist geschafft. Seit letzter Woche ist nun die Veranstaltung offiziell beendet, doch wie jedes Jahr wollen wir alle natürlich sehen, was nach 16 Wochen Entwicklungszeit bei unserem Projekt herausgekommen ist. Der Termin für unser Abschlussturnier steht fest:

SE 1 Abschlussturnier am Freitag den 13.09.2013, 13 Uhr, Labor des Fachgebiets Software Engineering

Sofern wir wie jedes Jahr einen Sponsor finden, wird es ein paar Getränke sowie einen kleinen Hauptpreis für die Sieger geben.

Bis dann,
Andreas

How To: Fortschrittskarte ausspielen

Software Engineering I, SS13

Da das erfolgreiche Ausspielen einer Fortschrittskarte nicht ganz trivial ist, wird in diesem Beitrag exemplarisch das Ausspielen der Fortschrittskarte “Handelshafen” vorgestellt. Das erste Szenario veranschaulicht den erfolgreichen Austausch zweier Rohstoffkarten durch 2 Handelswaren. Das zweite Szenario beschreibt einen möglichen Fehlerfall.

Hinweis: Natürlich gibt es noch eine ganze Reihe anderer Fehlerfälle, die sich jedoch analog zu dem unten dargestellten verhalten.

Szenario: Zenobios spielt die Fortschrittskarte “Handelshafen” aus und tauscht 2 Getreide gegen 2 Handelswaren.

Startsituation:

Zenobios, Bob und Charly spielen Siedler von Catan. Die momentanen Karten der jeweiligen Spieler sind:

  • Zenobios: Fortschrittskarte “Handelshafen” (Commercial Harbor), 2 Getreide
  • Bob: 1 Münze, 1 Tuch
  • Charly: 2 Holz, 1 Papier

Aktion:

Zenobios spielt seine Fortschrittskarte “Handelshafen” aus. Dazu schickt er folgenden Befehl an den Server:

{"@action":"PLAY","properties":{"entry":{"key":"id","value":"ProgressCard@473d86b3"}}}

Der Server antwortet (sofern keine Fehler auftreten) mit:

{"@ts":"1374831612034","@src":"SERVER","@prop":"USER_MESSAGE","@nv":"OK - offer(card,user)"}

In der Nachricht fordert der Server den Spieler nun auf, einen OFFER Befehl zu schicken, der einem anderen Spieler eine Rohstoffkarte anbietet. Zenobios schickt folgenden Befehl an den Server, um Charly ein Getreide anzubieten und bekommt vom Server (sofern keine Fehler auftreten) eine OK Meldung:

  1. {"@action":"OFFER","properties":{"entry":[{"key":"user","value":"UserAssets@551a1599"},{"key":"id","value":"Card@4051eda3"}]}}
  2. {"@ts":"1374831958351","@src":"SERVER","@prop":"USER_MESSAGE","@nv":"OK - offer(card,user)"}

Charly bekommt vom Server nun die Nachrichten, dass ihm Zenobios eine Rohstoffkarte vom Typ Getreide (GRAIN) angeboten hat sowie die Aufforderung, eine Handelsware auszuwählen:

  1. {"@ts":"1374831799175","@src":"SERVER","@prop":"USER_MESSAGE","@nv":"OK - User zenobios offered you a card of type GRAIN. Choose one of your commodity cards for exchange."}
  2. {“@ts”:”1374831799176″,”@src”:”SERVER”,”@prop”:”USER_MESSAGE”,”@nv”:”OK – choose(commodityCard)”}

Charly wählt als Handelsware Papier aus und schickt daher folgende Nachricht an den Server, die mit einem OK bestätigt wird (sofern keine Fehler auftreten):

  1. {"@action":"CHOOSE","properties":{"entry":{"key":"id","value":"Card@71f20640"}}}
  2. {"@ts":"1374833919934","@src":"SERVER","@prop":"USER_MESSAGE","@nv":"OK - CHOOSE"}

Analog verhält sich der Kartenaustausch mit Bob. Nachdem der Kartentausch mit Bob abgeschlossen ist, schickt der Server dem Spieler Zenobios die folgende Nachricht:

{"@ts":"1374832550656","@src":"SERVER","@prop":"USER_MESSAGE","@nv":"OK - yourTurn"}

Endsituation:

Die momentanen Karten der jeweiligen Spieler sind:

  • Zenobios: 1 Münze, 1 Papier
  • Bob: 1 Getreide, 1 Tuch
  • Charly: 2 Holz, 1 Getreide

Zenobios kann seinen Zug nun normal fortsetzen.

Szenario: Zenobios spielt die Fortschrittskarte “Handelshafen” aus. Kein anderer Spieler besitzt Handelswaren.

Startsituation:

Zenobios, Bob und Charly spielen Siedler von Catan. Die momentanen Karten der jeweiligen Spieler sind:

  • Zenobios: Fortschrittskarte “Handelshafen” (Commercial Harbor), 3 Getreide
  • Bob: 3 Getreide
  • Charly: Keine Karten

Aktion:

Zenobios spielt seine Fortschrittskarte “Handelshafen” aus. Dazu schickt er folgenden Befehl an den Server:

{"@action":"PLAY","properties":{"entry":{"key":"id","value":"ProgressCard@435a0940"}}}

Da kein anderer Spieler eine Handelsware besitzt, antwortet der Server mit:

  1. {"@ts":"1374832550637","@src":"SERVER","@prop":"USER_MESSAGE","@nv":"ERROR: PLAY - Sorry, but there is no player who has a commodity card."}
  2. {"@ts":"1374832550656","@src":"SERVER","@prop":"USER_MESSAGE","@nv":"OK - yourTurn"}

Endsituation:

Die momentanen Karten der jeweiligen Spieler sind:

  • Zenobios: 3 Getreide
  • Bob: 3 Getreide
  • Charly: Keine Karten

Server v1.2.1 online

Software Engineering I, SS13

Liebe SE 1 Teilnehmer,

seit kurzem ist Version 1.2.1 des SE 1 Servers online. Alle zum Spiel gehörenden Features wurden nun freigeschaltet und können von euch getestet werden. Dies betrifft im Besonderen die Fortschrittskarten. Damit ihr besser testen könnt, wird dem Spieler der einem testgame Spiel beitritt, jeweils eine Karte von jedem Typ  ausgeteilt.

Viel Spaß,
Andreas

Release Präsentationen

Software Engineering I, SS13

Da es offenbar einige Missverständnisse gab, was den Ablauf der Release Präsentation angeht, hier nochmal klar die wichtigsten Eckdaten.

  • Die Präsentation ist gemeinsam von PO und SM zu halten. Gemeinsam bedeutet: Beide erscheinen zum mit dem Kunden ausgemachten Termin und befinden sich die komplette Vortragsphase im Vortragsraum.
  • PO und SM bereiten jeweils einen 10 minütigen Talk vor. Natürlich darf ein gemeinsamer Foliensatz verwendet werden, es kommt lediglich darauf an, dass sowohl PO als auch SM in Summe die 10 Minutenmarke möglichst genau treffen. Es ist dabei unerheblich, ob zuerst der SM/PO komplett vorträgt und dann der jeweils andere oder ob es häufigere Wechsel des Vortragenden gibt.

Bitte fragt die jeweiligen PO/SMs aus den vorangegangenen Releases, wie deren Präsentation lief. So können viele Missverständnisse schon im Vorfeld aus dem Weg geräumt werden.Beitragsbild festlegen

Hinweis zum JSON Protokoll

Software Engineering I

In der Google Group kam die Frage nach “invalidem” JSON auf: Invalides JSON senden?. JSON Bibliotheken verwenden statt der folgenden Darstellung

Action Keys Beispiel Bemerkung
MESSAGE message, (audience)?, (recipient)? {"@action":"MESSAGE","properties":{"entry":{"key":"message","value":"Hallo"},"entry":{"key":"audience","value":"USER"},"entry":{"key":"recipient","value":"zenobios"}}} Verschickt eine Nachricht an alle oder den angegebenen User/Team. Der Parameter audience erlaubt folgende Werte:ALL, USER, TEAM.

Folgende Kombinationen von audience und recipient sind möglich:

  • audience: leer, recipient:leer -> Nachricht wird an alle User im Spiel geschickt
  • audience: leer, recipient:nicht leer -> Nachricht wird nicht verschickt
  • audience: ALL, recipient:leer -> Nachricht wird an alle User im Spiel geschickt
  • audience: ALL, recipient:nicht leer-> Nachricht wird nicht verschickt
  • audience: USER, recipient:leer -> Nachricht wird nicht verschickt
  • audience: USER, recipient:username -> Nachricht wird an user username verschickt
  • audience: TEAM, recipient:leer -> Nachricht wird an das eigene Team geschickt
  • audience: TEAM, recipient:teamname -> Nachricht wird an das Team teamname verschickt

Events, die durch diesen Command ausgelöst werden übergeben die Art der Message mit, um im Client eine Unterscheidung durchführen zu können. Mögliche Werte sind:ERROR, MESSAGE, PUBLIC_MESSAGE, USER_MESSAGE, TEAM_MESSAGE

in der Regel die Darstellung

Action Keys Beispiel Bemerkung
MESSAGE message, (audience)?, (recipient)? {“@action”:”MESSAGE”,”@id”:”0″,”properties”:{“entry”:[{"key":"message","value":"Hallo"},{"key":"audience","value":"USER"},{"key":"recipient","value":"zenobios"}]}} Verschickt eine Nachricht an alle oder den angegebenen User/Team. Der Parameter audience erlaubt folgende Werte:ALL, USER, TEAM.

Folgende Kombinationen von audience und recipient sind möglich:

  • audience: leer, recipient:leer -> Nachricht wird an alle User im Spiel geschickt
  • audience: leer, recipient:nicht leer -> Nachricht wird nicht verschickt
  • audience: ALL, recipient:leer -> Nachricht wird an alle User im Spiel geschickt
  • audience: ALL, recipient:nicht leer-> Nachricht wird nicht verschickt
  • audience: USER, recipient:leer -> Nachricht wird nicht verschickt
  • audience: USER, recipient:username -> Nachricht wird an user username verschickt
  • audience: TEAM, recipient:leer -> Nachricht wird an das eigene Team geschickt
  • audience: TEAM, recipient:teamname -> Nachricht wird an das Team teamname verschickt

Events, die durch diesen Command ausgelöst werden übergeben die Art der Message mit, um im Client eine Unterscheidung durchführen zu können. Mögliche Werte sind:ERROR, MESSAGE, PUBLIC_MESSAGE, USER_MESSAGE, TEAM_MESSAGE

Die vom Server verwendete JSON Bibliothek Jersey versteht beide Formate! Dennoch wurde das Beispiel in der Beschreibung vom Serverprotokoll angepasst!

Gruß,
Andreas