Alle Beiträge von johannes

Persönlich: Abschlusspräsentation

Obwohl wir zum Ende des Projekts einen umfangreichen und funktionieren Prototypen fertigstellen konnte, entschieden wir uns als Gruppe nicht am Coding Davinci Wettbewerb teilzunehmen.

Die Gründe dafür waren vielfältig, aber für die Gruppe ausschlaggebend, dass es für einzelne wichtige Terminüberschneidungen gab, unsere Anmeldung aus technischen Gründen über das Google Docs Formular nicht bei den Veranstaltern ankam und wir nicht die Ziele erreichen konnten, die wir uns gesetzt hatten.

Der letzte Punkt war besonders für mich relevant. Wie ich zuvor schon schrieb, war eines meiner Ziele mich mit modernen Webtechnologien, im Speziellen AngularJS, zu beschäftigen. Und ich wollte eine dynamische, responsive Webseite, die von allen Geräten benutzbar ist.

Leider war das im  Rahmen dieses Projektes nicht möglich. Einerseits, da uns als gemeinsame Gruppe die Expertise fehlte das im Rahmen der kurzen Zeit technisch zu realisieren. Andererseits, da sich unser Layout immer weiter in Richtung einer App entwickelte.

Ich hatte zwar Erfahrungen mit HTML, CSS, JavaScript und MFC-Frameworks, aber noch nie konkret mit AngularJS und Django gearbeitet. Und Philipp hatte, wie er transparent am Anfang mitteilte, noch gar keine Erfahrungen in der Webentwicklung. Unter diesen Voraussetzungen war es utopisch AngularJS als weiteres Framework mit steiler Lernkurve einzusetzen. Damit ließen wir auch die Idee einer dynamischen Seite hinter uns entwickelten wieder klassische Views, die jeweils eine vollständige HTML Seite ausliefern.

Wie ich im letzten Beitrag schon anmerkte änderte sich unser Design ziemlich oft. Während es sich am Anfang noch stark an den von Bootstrap vorgegeben Strukturen orientierte, hatten wir am Ende eher ein für eine App geeignete Struktur: 100% hohe Seitenleisten am linken und rechten Bildschirmrand und einzelne horizontal scrollbare Blöcke. Diese Veränderung führte nicht nur dazu, dass wir sehr viel selbst Entwerfen mussten und eigentlich kein einziges Bootstrap Feature mehr nutzen, sondern auch zu einem Layout, dass nur unter bestimmten Bedingungen gut aussieht. Es ist möglich ein solches Layout für beliebige Auflösungen anzupassen, aber nicht in diesem kurzen Zeitrahmen.

Somit konnten wir, aus meiner Sicht, zentrale Ziele unseres Projekts nicht erreichen, weshalb ich keine große Leidenschaft hatte das Projekt im Rahmen der Abschlusspräsentation zu pitchen.
Wie gesagt wäre das allein kein Grund gewesen auf die Abschlusspräsenstation zu verzichten, aber da unserer Anmeldung eh nicht geklappt hätte und ich unter Umständen alleine auf der Bühne hätte stehen müssen, entschieden wir uns als Gruppe gegen die Präsentation.

Der sehr negative Eindruck kurz vor Ende des Projekts hängt wahrscheinlich auch mit dem Arbeitsdruck in der Woche zuvor zusammen. Wir hatten lange gemeinsame Treffen und viele kleine Issues, die sich auf Details des Layouts bezogen und jedes mal mehr Zeit in Anspruch nahmen als wir planten. Insgesamt hatten wir zu diesem Zeitpunkt einfach zu oft auf unsere Musterseite geschaut und damit den Bezug auf die positiven Seiten verloren.

Jetzt mit ein paar Tagen Abstand, sehe ich viel deutlicher wieviel wir geschafft haben und bin begeistert wieviel wir in der kurzen Zeit geschafft haben. Die eigenen Ansprüche sind halt doch oft zu hoch und man verliert den Blick für das Gesamte wenn man sich nur auf die Details und offenen Aufgaben konzentriert.

Persönlich: Kommunikationsprobleme

Mein konkreter Wechsel in die Muster/Pattreator Gruppe gestaltete sich leider ziemlich holprig, da erstmal Philipp und dann ich eine Woche krankheitsbedingt ausfielen. Als komplette Gruppe konnten wir uns daher erst in meiner 3. Woche treffen und beginnen unser gemeinsames Vorgehen zu koordinieren.

Zu diesem Zeitpunkt wurde auch schon klar, dass auf Entwicklerseite E-Mails zur Koordination nicht ausreichen und wir entschieden uns für die Aufgabenverteilung den Issuetracker auf Github zu verwenden.  Allerdings zeigten sich auch hier Startschwierigkeiten.

Wie im letzten Beitrag erwähnt hatte mein Informatikkommilitone bislang keine Erfahrung in der Webprogrammierung und so fiel mir die Rolle zu Aufgaben festzulegen und zu verteilen.  Wie schnell klar wurde bedarf das jedoch auch einiger Erfahrung. Meine ersten Aufgabenpakete waren viel zu groß und ungenau beschrieben und führten damit nicht zu Fortschritt, sondern zu Frust.  Zudem hatte ich komplett unterschätzt wie viel Arbeit es bedeutet sich komplett neu in HTML, CSS und JavaScript einzuarbeiten.

Zudem änderte sich von Woche zu Woche das von unserem Designer entworfene Layout, was zu viel Stress und gefühlt unsinniger Arbeit führte. Der Fluch iterativer Entwicklung: Wenn sich ein Feature das Stunden an Zeit gefressen hat im nächsten Test als unpraktisch herausstellt fliegt es wieder raus. Das ist natürlich sehr sinnvoll, aber auch deprimierend. Leider entfernten sich die Entwürfe  immer weiter von unserem ursprünglichen Konzept und damit auch des schnellen Prototypings mittels Bootstrap.

Außerdem zeigten sich Kommunikationsprobleme in der Zusammenarbeit, da wir (eigentlich bis zum Ende) nur PDF Entwürfe bekamen, aus welchen wir dann umständlich Farbcodes rekonstruieren, Abstände und Größen raten sowie einzelne Elemente ausschneiden mussten. Auch auf mehrfache Nachfrage bekamen wir keine Farbpalette oder die Abmessungen in Pixeln.

Insgesamt waren die ersten Wochen sehr frustrierend für uns alle. Und ich war kurz davor das Projekt zu schmeißen und mir ein Softwareprojekt für die Vorlesungsfreie Zeit zu suchen.

Glücklicherweise hatten wir vorher doch nochmal ein längeres Treffen, bei dem wir die Probleme ansprechen und Lösungen suchen konnten. Die wichtigste Änderungen in unserer Gruppenstruktur waren dann regelmäßige gemeinsame Treffen um unserer Kommunikation zu verbessern. Die Treffen ermöglichten es uns sowohl technische Probleme oder verschiedene Konzeptvorstellungen gemeinsam zu diskutieren und zu lösen, als auch eine genauere Aufgabenspezifikation.

Dabei zeigte sich auch, dass Gamification beim Programmieren super funktioniert, da kleinere Aufgaben/Issues viel leichter bearbeitet und eben auch geschlossen werden konnten. Und jedes geschlossene Issue, den aktuellen Milestone Fortschrittsbalken weiter Grün färbte und ein Geühl von Erfolg vermittelte.

Trotz des ganzen Stresses, fand ich den Wechsel in die neue Gruppe gut, da es wichtig ist solche Kommunikationsprobleme, aber auch Lösungswege, kennen zu lernen.

Persönlich: Gruppenwechsel

Nach dem ersten „Speeddating“ und der Datenvorstellung hatte ich mich, um in den Metaphern des Kurses zu bleiben, mit der der Gruppe Stadtgeschichten „verlobt“. Das war meinem Interesse an Stadtpolitik, als auch den Gruppenmitgliedern geschuldet,  die ich seit meinem ersten Informatik Semester kenne.

Die Gruppe hatte sich relativ schnell entschieden ein Objekt zu entwerfen, welches von Person zu Person weitergereicht werden und Geschichten sammeln sollte. Ein spannendes Projekt, das aber erstmal die Entwicklung einer Android App bedeuten würde. Eigentlich sehr interessant, aber ich hatte das Softwareprojekt neben vielen anderen Gründen gewählt, da ich mich mit neueren Webtechnologien wie AngularJS auseinandersetzen wollte.

Das allein wäre aber kein Grund gewesen die Gruppe zu verlassen, da ich ihre Dynamik sehr positiv empfand. Das lag wahrscheinlich auch an der freundschaftlichen Zusammensetzung.

Allerdings hatte ich bedenken mit Freunden zusammenzuarbeiten, da ich zwar weiß wie gut man in solchen Konstellationen Brainstormen kann, aber auch die Konflikte kenne, wenn Aufgabenverteilungen nicht funktionieren und sich Kritik an der Arbeit mit freundschaftlicher Sympathie vermischt.

Ausschlaggebend für meinen Wechsel, war jedoch der Hilferuf der Mustergruppe, die auf einmal nur noch zu zweit waren und ohne weitere Unterstützung das Projekt hätten abbrechen müssen.

Das Musterkonzept entsprach ziemlich genau meinen Erwartungen an das Softwareprojekt. Das Ziel war es eine moderne Webapplikation zu entwickeln, die der besseren Darstellung und Weiterverwendung der von der HTW zur Verfügung gestellten Stoffmuster dienen sollte. Also perfekt dafür geeignet endlich mal ein konkretes Projekt mit Django, AngularJS und co. umzusetzen.

Dazu kam noch ein ansprechendes Layout des Designers und die Herausforderung der Zusammenarbeit mit einem unbekannten Team.

Trotz des schon fortgeschrittenen Projektverlaufs und des schon weitgehend feststehenden Konzeptes entschied ich mich daher nach einem sehr kurzen Kennenlernen und in Absprache mit meiner alten Gruppe zu einem Wechsel.

Neben Expertise und Motivation brachte ich auch einen Schwung technischer Ideen mit: Wie oben schon erwähnt sollten Django und AngularJS die Grundlage der Applikation bilden und mit Bootstrap schnell ein Designprototyp erstellt werden.
Das weder der Designer noch der zweite Entwickler bislang Erfahrungen mit Webentwicklung hatten, übersah ich in den ersten Planungen jedoch leider.

Pattreator Abschlusspräsentation

Für unsere Abschlusspräsentation haben wir zwei verschieden Foliensätze, da wir einerseits nochmal aus Designsicht auf das Konzept eingehen und andererseits Details zur technischen Umsetzung vermitteln wollten.

P.S. Leider erlaubt die Uploadfunktion keine Uploads über 10MB und PDFs unter Linux zu komprimieren scheint ein Ding der Unmöglichkeit. Deswegen hier nur Links zu einem externen Hoster.

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.