You are here: SE » ThesesHome » ThesisDPPIV » ThesisDPPIVBerichte

Wochenberichte

Die wöchentlichen Berichte sollen folgendes protokollieren:

  • Welche Tätigkeiten habe ich in der Woche ausgeübt?
  • Gab es dabei irgendwelche Probleme? Verzögerungen?
  • Welche Literatur habe ich gelesen?

Woche 0 (nur 2 Tage)

Tätigkeiten:

  • Arbeitsplatz eingerichtet und andere organisatorische Dinge
  • Entwicklungsumgebung (Eclipse) inklusive Saros eingerichtet
  • Anforderungen aus DPPI, DPPII und DPPIII zusammengetragen

Probleme:

keine

Literatur:

  • Diplomarbeit von Riad Djemili (DPPI)
  • Diplomarbeit von Oliver Rieger (DPPIII)

Woche 1

Tätigkeiten:

  • Anforderungskatalog erstellt
  • Use Cases erstellt
  • Defekttests + Problemdokument erstellt
  • Bug-Tracker aufgeräumt

Literatur:

  • Craig Larman: UML 2 und Patterns angewendet - Objektorientierte Softwareentwicklung

Probleme:

  • Windows-Firewall Probleme → nun Adminrechte auf Brazzaville
  • Arbeitsspeicher von Brazzaville ist für 3-4 Eclipse Instanzen (beim Testen) etwas knapp bemessen, geht aber

Woche 2

Tätigkeiten:

  • mit bestehenden Unit-Tests getestet
  • Anforderungsdokument überarbeitet
  • Recherche zu Dateiübertragung mit Jingle und NAT Traversal
  • Analyse für Lösung in unterschiedlichen Netzwerktoplogien
  • Projektseite von Sourceforge zum Fachbereich migriert (TWiki)

neu hinzugekommende Literatur:

[1]

Woche 3

Tätigkeiten:

  • Chat als Eclipse View realisiert und getestet (funktioniert zunächst nur für den im 1. Test fest eingestellten Jabber-Server)
  • Recherche zu NAT-Traversierung (STUN,TURN,ICE)
  • Überarbeitung des Netzweranalysedokuments
  • Testplan für 1. Testexperiment angefangen (wird bis Montagabend vervollständigt)
  • Defektausbesserungen der schwerwiegendsten Bugs (Probleme bei Kontaktaufnahme + Multi-Driver-Modus)
  • Codeformatierung im Projekt vereinheitlicht (nach Java-Codierrichtlinien)
  • Testaufbau nachgestellt und Saros in dieser getestet (funktioniert einigermaßen, so dass 1. Test möglich)

neu hinzugekommende Literatur:

[2], [3],[4], [5]

Probleme:

  • Jabber-Server jabber.cc teilweise nicht erreichbar, was Debugging erschwert → für Debugging eigenen Jabber-Server verwenden

Woche 4

Tätigkeiten:

  • Testplan für ersten Test erstellt
  • Eclipse Plugin Tutorial durchgeführt
  • Generalprobe für ersten Test (alleine durchgeführt) → Wichtig: Windows-Firewall aus/WLAN aus/Server in Host-Datei
  • 1. Test mit Triple durchgeführt (Ergebnis: immer noch schwerwiegende Mängel in Saros)
  • Angafangen Bericht und Auswertung des 1. Tests zu verfassen
  • Angefangen Regressionstests zu überarbeiten

Probleme:

  • Konfigurieren des JUnit-Projektes war schwierig (Anhängigkiten), Probleme konnten aber im Meeting mit Christopher gelöst werden

Woche 5

Tätigkeiten:

  • Recherche zu Reliable UDP / Implementierung von Limewire (→ scheint für Saros zu passen)
  • Analyse des Video und Audio Materials vom Test (→ oft scheinen spezielle IDE-Aktivitäten schuld an Inkonsistenzen zu sein)
  • Bericht und Auswertung des ersten Tests (→ Eintragen der Bugs und Feature Requests erst Anfang nächster Woche)
  • Recherche zu Peer-to-Peer durch NATs mittels Hole Punching ( → zwar grundsätzlich auch für TCP möglich aber funktioniert deutlich weniger als mit UDP)
  • Verfeinerung des Netzwerkanalysedokuments (bessere Unterscheidung zwischen STUN und Hole Punching)
  • Ant-Skripte überarbeitet

neu hinzugekommende Literatur:

[6]

Probleme:

  • Versionsnummern synchronisieren zwischen ant-Skripten und plugin.xml/feature.xml (notfalls per Hand setzen)

Woche 6

Tätigkeiten:

  • User Manual überarbeitet
  • Bugs und Feature Requests vom Test in Tracker übernommen
  • Webseite überarbeitet
  • kleiner Bugfixes (z.B. Undo/Redo bei Observer verhindern)
  • Analyse der Undo/Redo Problematik bei Gruppeneditoren → Undo/Redo Funktionalität allgemein bei Gruppeneditoren sehr schwierig zu realisieren, mit Eclipse eigenen Dokument/Editor/UndoManager Klassen wahrscheinlich unmöglich (linare, indizes-basierte UndoManager und Dokumente mir nur einem Undo-Kontext)
  • Debuggen der Konsistenzüberwachung (beim Speichern) → Konsistenzüberwachung ist höchstwahrscheinlich fehlerhaft und hat selbst Inkonsistenzen zur Folge

neu hinzugekommende Literatur:

[7]

Probleme:

  • immer noch einige Inkonsistenzen bei mehr als einem Driver (Buchstabendreher wenn mehrere Driver viel an einer Stellen eingeben + Zeichentrenner-Probleme

Woche 7

Tätigkeiten:

  • Zeichentrennerproblem gelöst (wird auf Unix-Zeichentrenner konvertiert wenn anders)
  • Inkonsistenzen (Buchstabendreher) bei Eingaben in einer Zeile gelöst (wurden durch race conditions verursacht und konnten durch geeignete Synchronisation mit dem single-SWT-thread verhindert werden)
  • Inkonsistenzproblem gelöst, wenn unterschiedliche Driver nacheinander an der gleichen Stelle die gleich Eingabe tätigen (besonders schwerwiegend bei newline)
  • kleinere Defektausbesserungen (z.B. falsche Rollenanzeige bei darauffolgenden Sitzungen)

neu hinzugekommende Literatur:

[8]

Probleme:

  • immer noch sporadisch auftretene Inkonsistenzen
    • TransformationException (precondition #3 violated)
    • BadLocationException bei Viewport-Änderung

Woche 8

Tätigkeiten:

  • Problem behoben wenn mehrere Driver unterschiedliche Dateien bearbeiten
  • Implementierung einer Konsistenzüberprüfung, die alle paar Sekunden die Hashwerte der Dokumente vergleicht
  • Text-Selektierungen werden nun im richtigen Editor angezeigt, auch wenn unterschiedliche Editoren geöffnet sind
  • Viewport-Änderungen werden nun im richtigen Editor angewendet
  • kleinere Defektausbesserungen (z.B. wenn Benutzer sich mit 2 Saros Instanzen anmeldet erscheint ein Hinweis das Verbindung aufgrund dessen beendet worden ist)

Status bezüglich Plan des nächsten Milestones (15.Dezember)

  • AP4 (Codeinspektion der Jupiteranbindung) zunächst erledigt (siehe Woche 7)
  • AP2 (Bugfixes bzgl. Eclipseintegration) zum größten Teil erledigt
  • AP1 (Netzwerk) wird spätestens Montag angefangen (Dateitransfer mit Jingle (TCP wenn möglich, sonst UDP/RUDP))
  • AP6 (Dateioperationen mit Speermechanismus) steht noch aus (unklar ob in dieser Iteration noch fertig wird)
  • AP5 (verbesserte Dateisynchronisation am Anfang einer Session) wird in die nächste Iteration verschoben
  • AP3(Chat, MUC-Änderungen + Fallback falls kein MUC vorhanden) wird in die nächste Iteration verschoben
  • AP7 (Vorbereiten des nächsten Tests): muss gemacht werden

Woche 9

Tätigkeiten:

  • Entwicklungsarbeiten am Netzwerk-Modul (AP1): Jingle File Transfer (Status: TCP implementiert, bei UDP/RUDP erste Verbindungserfolge)
  • Arbeiten an der Konsistenzüberwachung und Eclipseintegration (AP2) (Status: noch keine Konsistenzwiederherstellung wenn welche erkannt wurden)

Woche 10

Tätigkeiten:

  • Jingle File Transfer mit UDP/RUDP implementiert
  • Timing Problem beim Start des Jingle Managers gelöst
  • erneutes Senden einer Datei vom Host wenn Inkonsistenz erkannt wurde
  • kleinere Bugfixes

Status bezüglich Plan des nächsten Milestones (15.Dezember)

  • AP4,AP2,AP1 erledigt
  • AP5,AP6,AP3 nächste Iteration
  • AP7 (Vorbereiten des nächsten Tests): wird Anfang nächster Woche erledigt
  • Code-Freeze (bis zum Test nur noch Bug-Fixes)

Woche 11

Tätigkeiten:

  • Statusbericht, sowie Roadmap für weiteres Vorgehen erstellt
  • Überarbeitung der Konsistenzkontrolle
  • kleinere Bugfixes
  • 2. Test vorbereitet
  • 2. Test durchgeführt
    • "Johny can't count" Aufgabe ging ohne Inkonsistenzen oder Abstürzen durch (30 Minuten), als strörend wurde empfunden, dass bei mehreren Driver die Autovervollständigung von Eclipse nicht mehr gut benutzbar ist (Box wird bei Tastatureingabe des anderen geschlossen)
    • Probleme bei der Dateiübertragung bei Verbindung von entfernten Rechner zum Institut (auch IBB Fallback funktionierte nicht)
    • Probleme beim Hinzufügen von Buddies (höchstwahrscheinlich durch die erst kurz vor dem Test hinzugefügte Session-ID, deshalb werden die Messages fälschlicherweise nicht bearbeitet).
    • bei den Dateioperationen ging so gut wie alles schief, wenn es mehr als ein Driver gibt, auch Abstürze des Consistency-Watchdogs

Woche 12/13

Tätigkeiten:

  • Herausgefunden, das die Probleme beim Hinzufügen von Kontakten mit der Umstellung auf Smack 3.1.0 gekommen sind (herausgefunden durch 'switchen' auf ältere Versionen)
    • 'Downgrade' auf 3.0.4 vollzogen, mit dieser Version kompiliert aber Jingle-Komponente nicht mehr richtig, da vorher eine von Oliver 'ausgecheckte' Zwischenversion verwendet wurde (die er sinnigerweise 3.5 nannte)
    • nach reichlicher Überlegung habe ich entschlossen, wieder die offizielle Version 3.1.0 zu verwenden und dem Problem auf den Grund zu gehen, bin da auch schon sehr weit, hoffe dieses Wochenende das Problem in den Griff zu bekommen.
  • Herausgefunden dass der Weihnachtsmann nicht existiert
  • Ausarbeitung angefangen
    • Grobstruktur erarbeitet (vielleicht mal kurz mit den Betreuern absprechen)
    • Einleitung sowie Grundlagen Kapitel angefangen

Woche 14

Tätigkeiten:

  • Problem beim Hinzufügen von Kontakten gelöst
  • Implementieren einer manuellen Erlaubnisvergabe für das Hinzufügen von Kontakten
  • Änderungen an der Jingle-Komponente
  • erste Version eines Netzwerk-Views der Informationen über Peer-to-Peer Verbindungen anzeigt
  • Netzwerktests mit 2 vom Internet isolierten Routern mit eigenem Openfire-Server
    • Probleme mit dem Konfigurieren des Openfire-Servers (insbesondere des integrierten STUN-Servers)
    • → nicht eigenen Jabber-Server für NAT-Tests verwenden (siehe nächsten Punkt)
  • Netzwerktest mit einem NAT-Router zum Fachbereichs-VPN
    • Probleme den Linksys-Router als PPTP-Client für Fachbereichs-VPN zu konfigurieren
    • → Asus eeePC als NAT-Router eingerichtet
    • Ergebnis:
      • wenn ICE verwendet: auf der Seite hinter dem NAT bekomme ich ein Fehler beim Instanziieren des ICETransportManagers → werde am Wochenende im Community Forum posten und um Unterstützung fragen
      • wenn nur STUN verwendet → Jingle Peer to Peer funktioniert über den NAT (meistens UDP aber auch manchmal TCP), allerdings werden immer die öffentlichen IP-Adressen genommen, auch wenn im gleichen Netz oder sogar auf gleichen Rechner (ICE liefert einem auch die lokalen IP-Adressen), was oft dazu geführt hat, dass Peer To Peer dann nicht ging (ICE funktioniert hier aber sehr zuverlässig). Fallback auf IBB funktioniert aber mittlerweile recht zuverlässig.

Woche 15

Tätigkeiten:

  • Unterstützungsanfrage im Community-Forum von Smack wegen Initialisierungsfehler des ICETransportManagers gestellt → keine Antwort
  • Saros in Eclipse Galileo (kommende Eclipse-Version) kurz getestet → scheint zu funktionieren
  • Erkältung hat mich 2 komplette Tage lahm gelegt
  • Besprechung des teles-Szenarios und der Studienarbeit von Marc Rintsch
  • neuer Branch für teles erstellt: statt JDT wird hier CDT verwendet → Status: nach kurzen Tests scheint es nun grundsätzlich zu funktionieren

Woche 16

Tätigkeiten:

  • gebündelter Driverwechsel implementiert
  • Work Breakdown Structure und Zeitplan für teles erstellt
  • Benutzer haben nun global eindeutige Farben (Zusammenarbeit mit Marc) → dadurch hat Marc den Code besser kennengelernt
  • Follow-Mode und Viewport-Anzeige angefangen
  • für Statusinformationen gibt es nun eine Status-Tabelle am Whiteboard im Studentenraum (mit Christopher erstellt)

Woche 17

Tätigkeiten:

  • Follow-Mode neu implementiert
  • erster Test der teles Version von Saros (siehe geschickten Testbericht)
  • Änderungen an der JingleFileTransferSession, da Projektübertragung beim Test nicht immer funktionierte
    • Test der Projektübertragung (mit den Änderungen), siehe ThesisDPPIVNetzwerkTest → immer noch teilweise Probleme
  • Viewport Anzeige nun in der Farbe des Drivers (Marc)
  • Änderungen an der Userverwaltung (hauptsächlich Marc)
  • "Initial Scan" Problem gelöst (Marc)
    • quadratische Laufzeit entfernt (vorher extrem dumme Implementierung)

Woche 18

Tätigkeiten:

  • Review der Jingle-Komponente (PP mit Christopher) → läuft stabil
  • Refactoring der Netzwerkkomponente (PP mit Christopher) → sehr viel wartbarer
  • kleinere Entwurfsänderungen hin zu einer besseren SW-Architektur (PP mit Christopher)
  • ConsistencyWatchdog weiter implementiert (mit Christopher) → noch nicht fertig
  • Verbindung mittels P2P nur wenn Partner Jingle aktiviert hat (Discovery)
  • kleinere Bugfixes
    • Session bei allen Teilnehmern schließen wenn Host Session verlässt
    • Einladungsdialog immer nur bei Host möglich
    • Follow Mode nur bei Observer möglich
    • Benachrichtigung wenn eigene Rolle (Driver/Observer) sich geändert hat

für einen genaueren Status, siehe Bug-Tracker bei Sourceforge

Woche 19

Tätigkeiten:

  • zwei Tests am Anfang und am Ende der Woche → die Tests haben noch viele Fehler in Saros ans Tageslicht gebracht
  • Struktur der schriftlichen Ausarbeitung festgelegt → Feedback von Stephan, der es im Prinzip gut fand mit einigen Detailanmerkungen
  • Weiterentwicklung des ConsistencyWatchdogs → es werden nun fehlende Dateien erkannt und vom Host kopiert
  • Die Installationsdateien wurden in den File-Release-System (FRS) von Sourceforge verlagert, so dass Downloads nun in der Statistik erscheinen
  • Überprüfung ob der Einzuladene Saros verwendet → Probleme wenn Discovery fehlschägt, dann kann man Kontakt nicht einladen → muss noch eine Lösung gefunden werden
  • kleinere Bugfixes

für einen genaueren Status, siehe Bug-Tracker bei Sourceforge

Woche 20

Tätigkeiten:

  • am Montag Test von Saros → Version wurde von allen Beteiligten als präsentierbar empfunden, Feature Freeze
  • ein wenig an der schriftlichen Ausarbeitung weitergearbeitet
  • am Mittwoch: es kamen doch noch gravierende Versagen der Software zu Tage → Panik, Nachtprogrammiersession von Christopher und mir
  • Donnerstag: letzte Tests von Saros, Vorbereitungen für die Präsentation bei teles
  • am Freitag: trotz einiger Versagen der Software konnte die Software erfolgreich präsentiert werden

Woche 21

Tätigkeiten:

  • ConsistencyWatchdog gibt ein diff aus, wenn Inkonsistenz behoben → besseres Debuggen möglich
  • viele von den schwersten Bugs am Montag gefixed → vermeidliche Inkonsistenzen haben sich als keine herausgestellt, ein Defekt im ConsistencyWatchdog war für den Fehlalarm verantwortlich
  • weiter an der schriftliche Ausarbeitung gearbeitet (Grundlagen) → ich komme schleppend voran, wird hoffentlich bald besser
  • Besprechung mit Betreuern über empirischen Teil → offene Fragen wurden geklärt
  • angefangen mit empirischen Teil → Ziel und Fragen aufgestellt, genauere Planung insbesondere die Auswahl von geeigneten Aufgaben steht noch aus, da nicht so einfach etwas passendes zu finden (ich werde am Wochenende weiter dran arbeiten)

Woche 22

Tätigkeiten:

  • Bug-Fixes mit Christopher
  • Ziele für Mini-Fallstudie aufgestellt, Mini-Fallstudie konzipiert (Aufgabenstellung, Szenario, Fragebögen…)
    • Frage 1: Wird eine hinreichende Interaktion zwischen den Entwicklern durch Saros ermöglicht?
    • Frage 2: Wird die Möglichkeit von mehreren Drivern in einer Programmiersitzung verwendet und wird diese als positiv bewertet?
    • Frage 3: Bei welchen Entwicklungstätigkeiten wird die Verwendung von Distributed Pair Programming mit Saros von den Entwicklern als besonders und in welchen als weniger nützlich empfunden.
  • Mini-Fallstudie durchgeführt → leider wurde die Fallstudie durch teilweise schwere Fehler in Saros beeinträchtigt, aber nicht so stark, dass die komplette Durchführung gefährdet wurde → Christopher hat wahrscheinlich den schwersten Defekt behoben, so dass es bei der nächsten Mini-Fallstudie nächste Woche besser laufen sollte
  • erste Versuche Saros für unsere eigene Entwicklung an Saros zu verwenden ("eats its own dog food") → große Probleme damit → hauptsächlich noch keine ausreichende SVN-Unterstützung und ein Versagen dass wir auf Save Actions zurückführen konnten → Saros unterstützt (noch) keine Save Actions (in die Liste der bekannten Probleme aufgenommen)

Woche 23

Tätigkeiten:

  • Kapitel über Eclipse als Ablaufplattform geschrieben
  • Weiterentwicklung des ConsistencyWatchdogs
    • er kann nun mit Inkonsistenzen in mehreren Dateien umgehen und diese auf ein Mal beheben
    • die Konsistenzwiederherstellung wird für alle Cleints mit Inkonsistenzen auf ein Mal gemacht
  • Mini-Fallstudie mit zwei weiteren Gruppen (nur 2er Gruppen) (Marc hat mich dabei unterstützt)
    • einige haben abgesagt, andere sind ohne Absage nicht gekommen
    • beim Erstellen von neuen Dateien kamen erhebliches Versagen der Software zu Tage
    • Probleme unter MacOS eine Peer-to-Peer Verbindung aufzubauen
  • Kapitel über das erste Testexperiment geschrieben
  • PP mit Marc:
    • Dateioperationen blockieren nun bis die Operation fertig → sollte Probleme mit Dateien beseitigen
    • ActivitySequencer als Quelle von vielen Problemen identifiziert → Marc kümmert sich darum, den Defekt zu beheben
  • Kapitel über Anforderungen angefangen (wird am Wochenende hoffentlich fertig)

Literaturliste:

[1] Berthold Daum: 'Java-Entwicklung mit Eclipse 3.3: Anwendungen, Plugins und Rich Clients'

[2] Jonathan Rosenberg, Cisco Systems: Interactive Connectivity Establishment; IETF Journal; http://www.isoc.org/tools/blogs/ietfjournal/?p=117

[3] Jonathan Rosenberg: ICE Basic Tutorial; http://www.jdrosen.net/papers/ice-basic-tutorial.pdf

[4] Jonathan Rosenberg: TCP Candidates with Interactive Connectivity Establishment (Internet-Draft); http://tools.ietf.org/html/draft-ietf-mmusic-ice-tcp-07

[5] englische Wikipedia-Artikel zu STUN, TURN, ICE; http://en.wikipedia.org

[6] Bryan Ford, Pyda Srisuresh: Peer-to-Peer Communication Across Network Address Translators; http://www.brynosaurus.com/pub/net/p2pnat.pdf

[7] Chengzheng Sun, Griffith University: Undo as Concurrent Inverse in Group Editors, ACM Transactions on Computer-Human Interaction (TOCHI) Volume 9, Issue 4 (December 2002), 309 - 361, ISSN:1073-0516

[8] David A. Nichols, Pavel Curtis, Michael Dixon, and John Lumping ,Xerox PARC: High-Latency, Low-Bandwidth Windowing in the Jupiter Collaboration System

Comments