Entwickler Hangout 01

Das erste Entwicklerhangout hat am Mittwoch den 01.11.17 um 18-20:00 Uhr stattgefunden

Aufzeichnung

Tagesordnung

• Begrüßung
• Klärung der Anwesenheit
• Vorstellung des Konzepts
• Aktueller Projektstand
• Let's Talk

Besprochene Themen

• Problemstellungen
• Die Idee
• Crowdfunding Status
• Kryptographie
• Client Technologie
  • Ruby mit Turbolinks
  • NativeScript mit AngularJS2
  • ReactNative
  • GraphQL
  • Xamarin
  • Ember.js
  • Cordova
• Server Technologien
  • AWS Lambda mit Node
  • Azure Serverless mit Node oder PHP
• Segen des CCC für das Konzept
• Animation
• Lightning Talk
• Bundestagsdaten
• Nutzererfahrung mit Papierprototyp ermitteln und testen
• Torsten kennt sich mit Serverless-Technologie aus

Kommetar von Johannes

Krytographie/Datenschutz

Ein Prototyp ist dazu da, die Machbarkeit zu klären. Ziel des Prototyps ist es daher, die technische Machbarkeit zu evaluieren und Grundsatzfragen zu klären. Das schließt meiner Meinung nach ein, wie sehr anonymisiert die Daten sein sollen. Denn davon hängt ganz maßgeblich ab, welche Features wir in Zukunft einbauen und damit auch versprechen können.

Das MVP ist somit lediglich die kleinste mögliche, echte Produktumsetzung um Feedback zu gewinnen, die Grundfunktionen zu zeigen und zu sehen, wo die Reise danach hingehen soll. Hier sollten nach Möglichkeit keine Grundsatzentscheidungen mehr getroffen werden müssen, da das die ganze Planung und damit das Vertrauen der wartenden "Kunden" beansprucht sowie auch das eigene Team demotivieren könnte, weil Ziele nicht mehr erreicht werden könnten.

Ich stimme daher Robert zu, dass die Entscheidung, wie viel Verschlüsselung und Datenschutz wir wollen oder brauchen, vor dem Entwicklungsbeginn getroffen und ggf. auch evaluiert werden muss.

Robert hat auch das Problem des Mehrfachwählens angesprochen. Tatsächlich sehe ich hier das allergrößte Problem, insbesodnere dann, wenn wir sagen, wir möchten das alles möglichst stark anonymisieren. Denn bereits der Staat hat mit seiner sehr sehr viel besseren Identifikationsinfrastruktur erhebliche Probleme, das zu vermeiden. Wenn wir dann auch noch Stimmen vom User anonymisiert ablegen und nicht mehr zuordnen können, weil wir auf eben diese Infrastruktur nicht zurückgreifen können, habe ich aktuell keine Idee, wie wir Mehrfachabstimmung verhidnern wollen und aber gleichzeitig dem User die Möglichkeit geben wollen, seine Abstimmungshistorie zu behalten. Ganz zu schweigen davon, das üebr mehrere Geräte hinweg zu synchronisieren (siehe Threema, die bei der Übertragung auf ein anderes Gerät die Chathistorie nicht mitnehmen).

Ich persönlich glaube, wie einige im Hangout, dass die Anonymisierung kaum eine Rolle spielen dürfte, auch wenn ich das persönlich mag, die Fahne für den Datenschutz hoch zu halten. Aber nicht einmal ich benutze Threema, weil mir das schon zu unkomfortabel ist.

Wen kennt ihr, der auch nur bei WhatsApp mal die "Sicherheitsnummer" übrprüft? Wen kennt ihr, der PGP zu Email-Verschlüsselung, ach was, nur zur Signierung verwendet? Die breite Mehrheit - auf die wir ja abzielen /müssen/ wird meines Erachtens nach mit einem so hohen Datenschutzstandard nicht klarkommen. Einige von uns hatten ja schon Probleme in den Hangout zu kommen, siehe den Kommentar von Ulf am Anfang der Videoaufzeichnung des Hangouts 😉. Auch Thorsten sagt später: "es setzt sich das durch, was am einfachsten zu benutzen ist - nicht das in anderen Kategorien subjektiv (technisch etwa) beste" (lose zitiert).

Frontend Cross-Platform-Entwicklung

Insgesamt stimme ich erstmal denen zu, die sagen: wir sollten das nehmen, wo die Entwickler die wir haben, Erfahrung mit haben. Es ist aber ein absoluter Mythos, dass man mit einem Tool alles abdeckt.

Zu glorifizierter Browser als App: Bin ich kein Fan von, weil das nicht nativ ist und daher (wie man bei vielen fertigen Apps, auch großer Konzerne, sieht) anfällig für Performanceprobleme ist. Außerem sehen diese Apps immer wie Browser-Apps aus und natives UI kommt gar nicht zum Tragen, was die User nicht besonders schätzen.

Abseits davon wrüde ich Xamarin, ReactNative oder NativeScript bevorzugen, da diese Technologien in echte, native App übersetzt werden und man das native UI nutzen kann. Dies erhöht die Akzeptanz bei den Usern (wir haben in unserer Firma eine kleine interne Studie dazu gemacht; besonders bei iOS trifft das zu).

Ich persönlich arbeite aktuell in einem Xamarin-Projekt (mit .NET Backend) und das ist einfach nur geil, weil man auch Schnittstellen-Code mit dem Backend teilen und das UI für jede Platform spezifisch machen kann, wenn man will. Oder man startet (wie wir) mit Xamarin Forms (XAML/C#/.NET), mit dem man auch im UI fast alles cross-platform bauen kann. Wenn man dann den MVP fertig hat, kann man dann Schritt für Schrtitt das UI nochmal platform-spezifisch bauen (mit XAML/C#/.NET).

Abschließende Frage: Was versteht ihr unter Desktop? Windows (UWP?), Mac und Linux?

  Backend

Nachdem ich ja im Grunde ausschließlich Backend-Entwicklung mache, habe ich mir besonders viele Gedanken in diesem Bereich gemacht und finde ehrlich gesagt, dass das im Gespräch etwas zu kurz kam. Ich persönlich glaube, dass die Backend-Implementierung ganz Zentral für den Efolg des MVP ist. Die wichtigsten Schlachten werden denke ich ich Backend entschieden:

• Wie und wo persistiere ich die Daten?

• Wo werden die Daten verarbeitet?

• Wie kann ein Audit durch Kontrollinstanzen durchgeführt werden?

• Wie binde ich externe Schnittstellen (wie die Bundestags-API) an?

• Account-Magement ist ein hochkomplexes Thema, insbesondere hierbei

  Cloud-Provider
  

Nach meinem aktuellen Stand ist auch Microsoft der einzige große Cloud-Betreiber, der zwei Datencenter in Deutschland besitzt, sie aber durch einen externen, deutschen Betreiber (T-Systems) betreiben lässt, damit Microsoft als US-Konzern nicht zur Auslieferung von Daten an US-Behörden gezwungen werden kann. Das war vor 1,5 Jahren der wichtigste Grund für meine Firma, auf Azure zu setzen. Ich bin da aber aktuell nicht auf dem Stand der Dinge - vermutlich hat Amazon AWS da bereits nachgezogen. Auslöser für diese Treuhänder-Lösung war, dass eben genau das in Irland passiert ist: Microsoft wurde von den US-Behörden gezwungen, Daten von Office365 eines europäischen Kunden aus Irland auszuliefern. Wichtig ist hier: EU-Datenschutzgesetzte != BDSG bzw. die neue Datenschutz-Grundverordnung. Also: Finger weg von nicht-deutschen Datencentern 😉 Übrigens ist AWS nicht der einzige Cloud-Betreiber, der /BSI C5 zertifiziert/ ist. Siehe Link https://news.microsoft.com/de-de/microsoft-azure-deutschland-erhaelt-testat-nach-c5-pruefstandard/.

    Infrastruktur

Serverless (bescheuerter Name, denn da ist ja letztlich auch nicht weniger Server dahinter) macht meiner Meinung nach nur dann Sinn, wenn man eine sehr kleine Applikation baut. Der entscheidende Nachteil für mich ist die Verwaltung, die bei wachsendem Umfang schnell zum Problem wird. Auch das Tooling & Debugging ist (meiner kleinen Erfahrung nach) nicht so doll.

Einen ähnlichen Effekt kann man mit Containern (etwa Docker) erreichen oder mit den jeweiligen "Platform as a Service" (PaaS)-Angeboten aller Cloud-Provider. Wobei Docker sicher das aktuell portabelste Modell ist, da man eine Multi-Service-Applikation auf nahezu jeder Betriebssystem-Architektur betreiben und entwickeln kann (kein "works on my machine, but not on yours"-Problem mehr), wobei für Produktivumgebungen Linux vorzuziehen ist. Zudem kann man mit Docker extrem gut und einfach skalieren und Ausfallsicherheit gewährleisten.

    Architektur

Für den Anfang würde ich eine relativ einfache Grundstruktur mit zwei getrennten Applikations-Services (und deren Peripherie) vorschlagen:

Basis-Architektur

Mit Containern wäre das sehr einfach zu lösen, mit PaaS recht gut und meiner Meinung nach mit "Serverless" ein Verwaltungs-Albtraum. Mit dieser Architektur hat man auch die wichtigsten Herausvorderungen bereits genommen:

• Wie behandle ich Accounts getrennt vom Rest der Daten

• Wie verwalte ich Accounts

• Wie kommuniziere ich zwischen Applikationskomponenten

• Wie persistiere ich die Daten

• Wo persistiere ich die Daten

• Wie sind die Daten und die Applikation gegen Angriffe gesichert

• Wie betreibe ich die Platform? Relase-Management wird geübt und Prozesse aufgebaut (erste Erfahrungen gesammelt!)

  Programmiersprachen/Frameworks
  

Ich persönlich bevorzuge .NET Core mit C# auf Backend-Seite. Das arbeitet hervorragend mit .NET im Frontend (Xamarin) zusammen und bietet out-of-the-box ein hervorragendes Web-Framework mit (ASP.NET Core), auf dem dann JavaScript/TypeScript aufsetzen kann. Beides hat eine angenehme Lernkurve für Neueinsteiger und ist robust, performant, cross-platform und open-source.

Crowdfunding/PR


  Crowdfunding/Finanzierung

Für mich persönlich ist das Crowd-Funding in der Hinsicht nicht relevant, da ich glaube, dass aus Software-Entwicklungssicht und technischer Betrieb kaum monetäre Resourcen nötig sind. Lediglich ein Redaktionsteam und die Leitung des Projekts müssen meiner Meinung nach getragen werden. Aber ich denke, das kann denke ich auch üebr andere Kanäle erreicht werden (Philantropen und andere Sponsoren, Micro-Financing wie Patreon, Förderungen...). Mittel- udn Langfristig stelle ich mir eine gemeinnützige GmbH vor, die sich eben darum kümmert und damit letztlich die Redaktion, Verwaltung und ggf. Entwicklung trägt.

  PR

Nun bin ich kein PR-Experte, aber dem Name ist wirklich ungünstig gewählt, da es ein "Allerweltsbegriff" ist und auch noch eher in den englischsprachigen Raum lenkt. Es muss meiner Meinung nach dringend ein einzigartiger Name her - das würde die Bekanntheit vermutlich stark beeinflussen.

Ich habe wie Robert(?) auch sehr gute Erfahrungen mit Meetups (in München) gemacht, auf denen ich Lightning-Talks gegehalten habe. Allerdings ist das vermutlich erst interessant, wenn wir technologisch über etwas reden können.

Was soll der MVP beinhalten


  IN

• Klar formulierte, kurze Hintergründe zu jeder Abstimmung, am besten mit weiterführenden Links und ggf. die wichtigsten Pro/Contra-Positionen (wobei das vielleicht schon zu weit geht). Redaktionsteam ist hierfür notwendig

• Abstimmen

• Abstimmungsverhalten (Bundestag und Bürger), aber einfache Pie-Charts oder ähnliches, visuelles

  OUT

• Kommentare

• Abstimmungs-Historie noch nicht nötig

  Anmerkungen

Ich finde, dass wir über jeden moralischen Zweifel erhaben sein müssen. Da bedeutet für mich ein wasserdichtes Konzept - und damit meine ich den operativen wie auch den technischen Standpunkt. Wir müssen daher auch mehr als "Serverless" im Backend zeigen, wobei wir da nicht unbedingt den ganzen Weg gehen, aber beweisen müssen, dass wir das können. Deshalb ist auch Open Source hier für mich so wichtig. Das bedeutet dabei aber für mich auch, dass bereits Kommentare für den MVP nicht wünschenswert sind, da wir uns da noch einen extra Spurt aufzwingen, was das Konzept und die Technik betrifft.

Papier-Prototypen (oder ganz einfache Klick-Prototypen) sind ein Muss!