P2016 05 13

Techtalk #n+1 - 13.05.2016

Ort: Space, Bahnhof Mitte (http://www.openstreetmap.org/node/3949379062)

Anwesende: Felix, Peter, Steve, Joschka

Beginn: 14:20 Uhr Ende: 18:00

Ziel: technische Entscheidungen treffen, Arbeitsfähigkeit herstellen

Material: https://drive.google.com/open?id=0B_f-GXm8FBzpUVdVNzZQOGg0a3M

vorheriges Protokoll: https://github.com/foobar0112/afeefa/wiki/P2015-12-04-b

Agenda

• Anmerkungen zur Tagesordnung
• Kontext-Update
• aktuelle Entwicklungen bei Afeefa
• Architektur
• Vgl. aktuelle und gewünschte Architektur
  • ist: BE: php/ TYPO3-Neos, API: Neos, FE: JavaScript
  • soll: BE: JS-Framework, API: ruby, FE: JS-Framework
• Review Datenmodell
  • Wissensportal berücksichtigen
• Technologie
• Backend-Frontend-Anbindung
• API
  • zw. BE, FE oder
  • zwischen BE, FE, Data
• microservices
• JS-Framework: angular, react, ember?
• Aufgabenpakete
• Review use cases
• neue use cases formulieren
• Aufgabenverteilung + weiteres Personal
• Zeitplan für weiteres Vorgehen
• Tools
• PM: redmine, trello, waffle, taiga, ..?
• Server: jenkins, ...?

Protokoll

Anmerkungen

• Warum hat es das letzte Mal nicht geklappt, ist nicht losgegangen?
• zu groß, taiga doch nicht praktikabel
• man kann nicht alles kennen, dafür zu unübersichtlich
• Architektur im inneren des backends unklar
• blockierende Aufgaben
• wording
• backend (BE) .. das, wo man sich zur Verwaltung einloggt
• frontend (FE) .. das, was der Nutzer dann sieht (Karte und so...)
• genauer: BE-UI und FE-UI
• API .. klar
• Kern .. Datenhaltung, da wo die API ansetzt

Tools

• taiga abgewählt, github-issues/ waffle zu einfach
• wir versuchen Radmine! \o/

Vorgehen

• schnell ersten Prototypen erreichen (Afeefa-BE 0.1)
• entscheiden welche Features (s. Mindmap) mit rein sollen

Technologie

• JS-Framework: ember

geplanter erster Prototyp 0.1

• user + orga models und relation implementieren (done)
• in microservices aufteilen (zunächst einer)
• orgas anlegen und anderen orgas zuordnen (hierarchie aufbauen)
• user anlegen, orga zuweisen
• rollen (admin, editor, user) und rechtemodell implementieren
• login gewährt nur zugang (keine rechtedetails übermitteln, aber vorsehen)
• BE-UI per emberjs
• API für alle zu übermittelnden daten
• NICHT: thing, location, category, tag, language

aufgaben für 0.1

• user stories für 0.1 erstellen (alle in tabelle sammeln bis zum nächsten treffen)
• UI mockup
• infrastruktur
• jenkins einrichten (optional für 0.1)
• mapcat.afeefa.de
• ember recherche: vor allem testgetriebene entwicklung auch im frontend

Zeitplan

• mittwoch: 18.5.
• user stories durchgehen und ins redmine übertragen
• gemeinsam wireframes erstellen
• user stories verteilen und implementieren
• prototyp 0.1 am 27.5.
• ... weitere prototypen planen ...
• produktiver status erreicht: zuerst backend austauschen und altes frontend per überbrückungs-API anbinden
• vorteil: frontend bleibt; redakteure genießen neues backend; performance-vorteile fürs frontend
• jahresende: neues frontend und neues backend \o/

Unterstützung

• mitarbeiterakquise an der uni gehen wir nach nächsten treffen an, wenn wir uns klarer über aufgaben sind (sind eh pfingstferien)

kommende Termine

• Arbeitstreffen am 18.05. (space)

Anhang

Input Martin

bitte nicht falsch verstehen - ich hab sicher einige Gespräche verpasst und kann daher nur blöd von der Seite quatschen

Architektur

ich verstehe den Ansatz BE=JS und API=rails nicht. Die Seite läuft und besteht im wesentlichen aus JavaScript und lädt dynamisch Inhalte nach. Die Daten liefert ein Rails Server der die Daten in einer DB (am besten imho MySql) verwaltet. Ich würde nicht Rails mit JS mischen, ich habe einen Ansatz gesehen der über ein JS-Script-Engine in Java ein Regelwerk abarbeitet - hat mich aber noch nicht überzeugt. Klare Trennung erlaubt besser Testbarkeit und Austauschbarkeit.

Wichtig aus meiner Sicht ist die Testbarkeit und das Testvorgehen. Wir werden sicher immer mal schnell hier und da was schrauben, nur 1-2 Leute werden den ganzen Code kennen, wenn überhaupt. Daher sollte wir, auch um schon Sachen mal gut zu durchdenken, nahezu testgetrieben vorgehen. Sprich viele Tests ersetzen nachher hunderte Stunden Fehlersuche. Sprich es muss möglich sein, zu prüfen ob noch alles funtzt wenn eine Änderung rausgehen soll.

Technologie

Wenn möglich sollten REST-Services verwendet werden. Versionierbarkeit erlaubt das einfache Aufschalten neuer Funktionen wenn gleichzeitig Nutzer noch auf bestehender alter Version arbeiten können. Gleichzeitig sollte letzte Version über Fallback immer funktionieren.
An MicroServices würde ich mich weniger orientieren, da Grundentwicklung eher in der Erweiterung singulärer Abfragen besteht als in dem Aufbrechen komplexer Prozessketten, in die ggf. geänderte Teilschritte einfliessen müssen. Die Kommunikation sollte weiter auf JSON basieren. mh.. ja angluar klingt nicht verkehrt, aber Erfahrungen habe ich nicht

Tools

aus meiner Sicht braucht es auch ein einfaches Scrum-Board - was ist egal Zur Replikation, zum Verteilen könnte man eine VM, ggf. Dockers verwenden. Dann hat man immer alles dabei, allerdings müssten wir dann hin und wieder einige GB durch die Gegend schaufeln. Der Vorteil liegt auf der Hand - es geht garatiert, zum Testen und Entwicklen können wir extrem schnell skalieren. Zum Entwickeln mit Rails hatte ich Aptana Studio verwendet und fand das echt gut - hier hat Steve aber sicher was besseres am Start ;-) Jenkins kann ich als Test-Umgebung auf jeden Fall empfehlen.

Nicht wirklich technisches, aber was den "Durchbruch" verhindern könnte

• Zeit als Kriterium für Events

  • neueste Einträge
  • Ereignisse in naher Zukunft

  "ältere Einträger oder Events in anderen Regionen könnten uninteressant sein"

• Alle Webnutzer können anonym Einträge erstellen

  • jeder Eintrag sollte einen "Melden"-Button erhalten, um möglichen Missbrauch zu erkennen <-- gleichzeitig sichert das Aktualität, die die Seite erst richtig nutzbar macht (natürlich sind diese ungeprüften Einträge erkennbar und werden nach 100x "Melde" erstmal automatisch deaktivert und zur Prüfung eingestellt.