Muster, Metadaten und Mails

Unsere Gruppe hat es sich zur Aufgabe gemacht die Stoffmuster der HTW Berlin über eine Webapplikation zu präsentieren. Dazu sollen aus den Scans der Seiten einzelne Muster ausgeschnitten und vektorisiert werden. Über unsere Webapplikation kann man diese dann mit Schlagworten versehen, favorisieren und zum weiterverwenden heruntergeladen werden.

Zur Entwicklung einer Webapplikation gibt es wahrscheinlich für jede Programmiersprache mindestens 1000 Frameworks, die mehr oder weniger viel Arbeit abnehmen. Aufgrund unserer Programmiererfahrungen mit Python innerhalb der Gruppe, haben wir uns für Django entschieden.
Für Django spricht eine rege OpenSource Community und die gute Dokumentation. Allerdings ist letztere für Einsteiger auch zwingend notwendig:  Die Lernkurve sich in der Datenbankabstraktion,  den Templates und Konventionen des Frameworks zurecht zu finden ist ziemlich steil.  Nach der Einarbeitungsphase zeigt sich jedoch der Vorteil des Frameworks, da neue Ansichten oder die Erweiterung der Datenmodelle sehr schnell und einfach möglich sind.

Für einen Prototypen bedarf es auch der Metadaten der HTW, die zwar in einem maschinenlesbaren, aber sehr unübersichtlichen Format gespeichert sind. Zudem werden die auf Wikimedia Commons gespeicherten Scans nicht in den Metadaten referenziert und müssen über eine (nicht explizit definierte) Konvention der Dateinamen verknüpft werden.
So nahm die Extraktion der Informationen aus dem XML Baum in unsere Datenbank insgesamt doch viel mehr Zeit in Anspruch als wir für diese Iteration geplant haben. Und das Ticket kann immer noch nicht endgültig geschlossen werden, da es Fehler mit einzelnen Musterseiten gibt, deren Name nicht der Konventionen entsprechen oder für welche schlicht Metadaten fehlen.

Dennoch konnten wir für diese Woche einen ersten im Browser bedienbaren Prototypen vorstellen. Ein Erfolg, der nach der langen Planungsphase sehr viel neue Motivation mit sich brachte.

Mit dem Wechsel aus der Planungs- in die Programmierphase hat sich auch unsere Gruppenkommunikation verändert.  Während wir in der ersten Phase über E-Mail kommunzierten, was zwar sehr einfach ist aber leider auch sehr schnell unübersichtlich wird, nutzen wir für die Verteilung und das Verfolgen von Aufgaben den Issuetracker von Github.  Dort erstellen wir für jede Woche einen Milestone, der von einer User Story abgeleitet Aufgaben enthält.
Wie wir dabei schon die erste Woche feststellten, ist es sehr wichtig diese Aufgaben genau zu speizifizieren und so klein  zu halten, dass sie in einer Iteration zu schaffen sind.

Für die nächste Woche steht nun erstmal der Wechsel auf ein neues Layout an. Zudem wollen wir ausgehend vom Feedback des Testings die bestehende Funktionalität verbessern. Zudem müssen für den Prototypen erste Muster ausgeschnitten und in das System eingepflegt werden um mit der Umsetzung der User Stories weitermachen zu können.