BASTA! Spring 2017 Fast Facts
Was ich diesmal mitgenommen habe (von Markus Winhard)
Es war wieder mal eine gelungene Konferenz. Und da man bei so vielen tollen Vorträgen leicht etwas vergisst, habe ich mir Stichpunkte gemacht.
Ausführliche Details dazu gibts beim Usergroup-Treffen.
Tag 1
Surviving C# Code Reviews
- Visual Studio kann statische Code Analyse
- Alternative NDepend
- die meisten Teams haben heute eher das Problem des Over-Engineerings, zu viele Interfaces, zu viele kleine Projekte,
zu viel Abstraktion, zu komplex
- Parallelisierung an den falschen Stellen erzeugt oft Performance Probleme
- so viel wie möglich automatisieren (Buildserver, etc.)
- Anwendungs-Metriken automatisch einsammeln (Errorlogs, Feature Usage Count, Memory- und CPU-Last, nicht nur im Fehlerfall)
Stack Overflow behind the Scenes - How it's made
- keine Quellcode Branches, nur ein Master Branch, das Mergen der Branches hat zu Fehlern im Quellcode geführt
- kleine Check-Ins
- Feature Switches
- Entwickler-PC, Staging, Production
- jeder Entwickler darf den aktuellen Stand auf Production deployen und soll das auch tun, sobald er seine Arbeit auf Staging getestet hat
- relativ wenig automatisierte Tests, weil die Anwender die Fehler so schnell melden
- Performance Monitoring an allen Ecken inkl. Live-Überwachung
- Caching von HTML Snippets im RAM und in Redis
- Dapper ORM
- Jil (Json Serializer)
- Performance is a feature
- 1 Kollege macht nur Performance Optimierung
- Tag Engine läuft auf mehreren GPUs
- bunte Mischung von Windows und Linux Servern, genommen wird, worauf die Software schneller läuft
- Azure und Co. ist keine Alternative, weil die Performance unvorhersagbar schwankt
- Hardware wäre eigentlich schnell genug, muss aber ausgetauscht werden, weil der Support des Herstellers abläuft
- 9 Server, aber einer würde die Last auch schaffen (kam schon mal vor)
CSS Flexbox: Oberflächenlayout der Zukunft
- neuer W3C Standard für CSS
- Direktiven: display:flex, flex-direction, flex-grow, flex-basis
- "Auto" richtet sich am enthaltenen Text aus
- ähnlich wie WPF StackPanel
- Unterstützung durch alle aktuellen Browser
- Polyfills für Internet Explorer 9 und älter
- Angular Material verwendet Flexbox
- Twitter Bootstrap kann in der neuesten Version wahlweise Flexbox nutzen
- Performance mindestens genauso gut wie bisherige Lösungen, tlw. deutlich schneller
- ermöglicht automatische Scrollbars in Containern ohne das Layout anderer Elemente zu beeinflussen
- Alternative: Grid Layout ähnlich wie WPF (bisher nur IE und Edge, alle Anderen implementieren gerade)
Behind the Sc#enes: Was der C#-Kompiler hinter den Kulissen treibt
- hier gab es viel IL Code und ILSpy zu sehen
- fast alle Sprach-Features nach C# 2.0 werden vom Compiler nur in älteren Code übersetzt
(Lambdas, LINQ, async/await, anonyme Methoden, lokale Methoden, optionale Parameter, benannte Parameter, etc.)
- der Erfinder (Anders Heilsberg) macht gerade das Selbe bei TypeScript
- der Austausch von DLLs mit Methoden mit optionalen Parametern kann zu Problemen führen,
weil die fehlenden Parameter vom Compiler in die aufrufende Methode eingesetzt werden
Tag 2
Keine Angst von React, Mut zur Performance
- State steckt in Javascript Properties
- ändern dieser Properties führt zum Neu-Rendern der View
- erstellen von HTML-Elementen im Code per createElement() oder inline per JSX
- Javascript und HTML, ggf. auch CSS, in der selben Datei
- läßt sich mit TypeScript kombinieren
- Quellcode für React ist immer noch gewöhnungsbedurftig
Der Weg der Daten vom Server bis zum Browser mit ASP.NET Web API, Angular 2 u.a.
- Dr. Holger Schwichtenberg in seinem Element
- MiracleList als Beispiel-Anwendung
- 33 Stunden inkl. Desktop Variante für Windows/Mac/Linux
- Angular 2, Bootstrap, Electron, ASP.NET Core, Swagger, TypeScript
- Testen des Webservice API mit PostMan
- async/await mit TypeScript 2.1
Web-APIs mit Node.js und TypeScript - für .NET-Entwickler
- Manuel Rauber hat anschaulich erklärt, wie Node.js funktioniert
- Web API ist alles, das HTTP spricht und Daten liefert bzw. entgegen nimmt
- Javascript (bzw. TypeScript) vom Client bis ins Backend ist ein Vorteil
- bei Node Modulen ist der Quellcode oft die einzige Dokumentation
- Restify unterstützt bei der Architektur des Node.js Webservice
- Package ts-node erlaubt direktes Verwenden von TypeScript Klassen (in-Memory Transpilierung)
- Sequelize ORM ist mit TypeScript sehr aufwändig und unnötig schwierig
- Token Authentication via OAuth2 STS
Testen fängt beim Schneiden an
- Druckbetankung von Ina Einemann, viel Stoff und ein trockenes Thema, aber sehr unterhaltsam erklärt
- ein Tester muss die korrekte Vorstellung des Problems haben, damit er richtig testen kann
- Personas helfen, die Anwender und ihre Ziele im Blick zu behalten
- messbare Ziele definieren
- Produktvision auf Flipchart
- Elevator Pitch kann verwendet werden um die Vision des Produkts zu erklären
- User Story: Als <Rolle> möchte ich <Aktion> damit <Nutzen>
- User Stories im Backlog alleine sind zu unübersichtlich
- Akzeptanz-Kriterien pro User-Story definieren, damit man weiß, wass man fertig ist
- Walking Skeleton als erste funktionierende Version
- beim "Schneiden" von User Stories darauf achten, dass der Kunde Funktionalität erhält, die ihm nützt
- besser einen schmalen Durchstich als erst Mal nur die Datenbank fertig stellen
- erst Mal eine simple Version, die funktioniert
- die Schritte eines Workflows sind meist gute Schnitte, evtl. nur den ersten und letzten Schritt
- kleine Stories sind schneller umzusetzen
- 6 bis 10 User Stories pro Sprint
- technische K.O.-Kriterien möglichst früh anpacken, besser früh scheitern als spät
ASP.NET Core und ASP.NET MVC Core
- Warum ASP.NET Core? Multi-Platform, bessere Performance, weniger Abhängigkeiten
- .NET Standard ist der Nachfolger der Portable Libraries
- neuer Webserver Kestrel
- Visual Studio 2017 verwenden
- .csproj Dateien sind zurück, MSBuild ist Multi-Platform
- Referenzen werden über Nuget Packages hinzugefügt
- zeitkritische Sachen werden per async/await aufgerufen
- jede gewünschte Funktionalität muss programmatisch dazu konfiguriert werden
- AddScoped() liefert ein Singleton für alle Aufrufe des aktuellen HTTP Requests
- appsettings.json kann web.config ersetzen, Alternative XML- oder ini-Datei, Konfiguration im Code,
Environment-Variablen können Konfigurationen steuern, Einstellungen in später geladenen Konfigurationsdateinen
überschreiben frühere Einstellungen
- alle Logger verwenden das selbe Interface
- neues MVC Projekt mit Bootstrap kann per "dotnet new" erzeugt werden
- alle Komponenten sind austauschbar
- Tag Helper Syntax ist ähnlich wie Angular 2
- View Components erlauben Views zu schachteln
- Dependency Injection wird viel verwendet
Tag 3
Microsoft und DevOps: Es weht ein neuer Wind
- Satya Nadella war selbst mal Programmierer
- er hat entschieden "wir gehen auf Git"
- Weiterentwicklung von Scrum zu DevOps
- keine Einzelkämpfer mehr, nur noch Teams
- ein paar sehr gute Programmierer wollten nicht im Team arbeiten und haben deshalb Microsoft verlassen
- der restliche Vortrag bezog sich hauptsächlich auf das TFS Team
- es gibt Feature Teams, dadurch wenig Abhängigkeiten der Teams untereinander
- das Product Management gibt nur die grobe Richtung vor
- das Team ist verantwortlich für die Features
- das Team ist auch verantwortlich für den produktiven Betrieb
- jedes Team-Mitglied hat mal Rufbereitschaft am Wochenende, das erhöht die Bereitschaft, nur funktionierenden Code einzuchecken
- tlw. tägliche Releases, dadurch kleinere Checkins und weniger Fehler
- keine Branches, nur ein Master Branch
- stattdessen Feature Flags, neue Features können in mehreren Stufen freigeschaltet werden
Visual Studio Code
- die meisten coolen Funktionen kommen aus Extensions
- F5 startet Debugger, gezeigt am Beispiel von Node.js
- Git Integration
- es gibt eine Extension für TFS Version Control
- Source Code Compare zeigt geänderte Buchstaben, nicht nur gane Zeilen
- F12 funktioniert
- Find All References Kontext-Menü vorhanden
- ASP.NET Core debuggen wie in Visual Studio
- gezeigt, wie man eine eigene Extension programmiert und in einer neuen Instanz von Visual Studio Code testet
Redis - Cache, NoSQL-Datenbank und mehr
- in-Memory Datenbank
- keine echte Datenbank, nur ein Key-Value Store, alles Andere ist aufgesetzt
- sehr schnell
- wird oft als Cache für Teile bestehender Anwendungen verwendet
- z.B. als zentraler Cache Server für eine Webserver-Farm
- Cluster aus mehreren Redis Servern sind einfach zu erstellen, auch auf einem Entwickler-PC
- Open Source
- EXE mit lokaler config Datei, Portable
- Microsoft Opentech hat einen MSI Installer gebaut
- auch in Azure fertig verfügbar, dort allerdings kostenpflichtig
- Pattern-Abfragen liefern alle Keys, die dem Pattern entsprechen, aber keine Daten
- speichern mit set, lesen mit get
- set ... expiry ... löscht den geschriebenen Wert automatisch nach der angegebenen Zeit
- C# Client von StackExchange verwenden
- ASP.NET Session Client speichert ASP.NET Session in Redis
- kann Daten auf die Platte speichern
- keinerlei Security ausser dem Master-Passwort
- Einsatz nur innerhalb geschützter Netzwerke empfohlen
Continuous Quality - Hohe Prozessreife für kürzere Releasezyklen
- die Anforderungen und Prioritäten im Projektmanagement haben sich geändert
- ein Team braucht eine gemeinsame Vision der Ziele und Nicht-Ziele jedes Sprints
- Projektmanagement ist Team-Aufgabe
- Reviews sind wichtig
- automatisieren was geht um Zeit für Reviews zu schaffen
- schriftlich festhalten, welche Code Style Guides das Team verwenden will
- Code Style Guides automatisch prüfen, so weit das möglich ist
- SonarQube dafür verwenden
- automatisierte Build und Release Prozesse nutzen
- technische Schulden zeitnah abbauen, sonst häufen sie sich an
- deployed wird ab Minute 1, auch wenns da noch nicht viel zu deployen gibt
- Deploy über mehrere Stages, z.B. Dev/Betatester/Release
- Monitoring ab Minute 1
- Applikations-Telemetrie ist wichtig (Anzahl Nutzer, Antwortzeiten, Kennzahlen CPU und RAM, Betriebssystem, was klicken die User an)
- Fazit: Build -> Learn -> Measure, dann wieder von vorn
Mobile (Web-)Apps mit Ionic 2
- Ionic 2 ist Open Source, nur die Cloud Dienste sind kostenpflichtig
- verwendet Angular 2
- kein Angular Router, stattdessen Push-Pop Stack für Navigation
- Zugriffe auf native APIs sind in Cordova nicht standardisiert, in Ionic sauber verpackt und einheitlich
- TypeScript Support für native Cordova APIs
- Push Dienst für iOS und Android
- Live Updates für Apps (Ausliefern von Bugfixes ohne neue Version im Store) per Ionic Deploy Server
- Ionic Package ist ein Buildserver für Apps, da ist auch erklärt, wie man die Apps anschließend in den Stores einreichen kann
- Ionic App im AppStore zum Testen eigener Apps, ohne sie im Store einzureichen