ChaosPad V1.1
Full screen

Server Notice:

hide

Public Pad Latest text of pad NUrZxHMGas Saved Dec 30, 2024

 
Green Coding
 
Links:
 
Mobile First , Accessbility First
 
  • Bei eigener Software möglich, bei bestehender eher nicht.
  • Mobile First hat Effizienzvorteile
  • Accessibility und Mobile gehört zusammen
  • Kommunikation mit Stakeholdern bzw. betroffenen Personen
  • Mit betroffenen Usern sprechen
  • Accessibility von Anfang an ist kleinerer Aufwand, als sie nachzurüsten
  • Wiederbenutzbare Komponenten zuerst accessible machen
  • Design von Stakeholdern widersprechen den Prinzipien
  • Tools benutzen, Accessibility Checker gibt es für verschiedene Plattformen
  • Bei HTML etc. auf native Elemente zurückgreifen, möglichst wenig eigenes bauen
 
 
Prozess-Lebenszyklus optimieren
  • Kommunizieren auch außerhalb der Entwickler-Bubble
  • Stakeholdern klarmachen welche Variante/Ziele (Servertool vs. Singletool) welche umsetzen wird
  •  
Obsoleszenz
  • Codequalität ist ein hilfreiches Ziel, aber ich habe 10 Azubis?
  • Qualitätsprozesse sind kein Allheilmittel
  • Wartungs- und Betriebskosten werden unterschätzt
  • Code ohne Wissen oder Code der unwartbar geworden ist erfordert ein Rewrite
 
Technologieauswahl
  • YAGNI:  
  • KISS 
  • Richtig Dependency auswählen.
  • Muss googlebar, sehr guter dokummeniert.
  • Doku möglichst nah am Code
  • Doku aktuell halten.
  • Verbreitung und Community
  • Offener Standard
  • Keinen Standard selber designen
 
Carbon Awareness
  • Prozesse Identifizieren die asynchron ablaufen können / nicht zeitkritisch
  • Resourcenintensive Prozesse ermitteln
  • Location-shifting hautsächlich sinnvoll bei Cloud Anbitern (GCP, AWS, Azure)
  • Wer? Architect, DevOps
  • Tools
  • Daten APIs um CO2 Identität und Prognosen bekommen
  • Electrity Maps (commercial)
  • WattTime (commercial)
  • carbon-aware-computing.com (creative commons)
  • Carbon Aware SDK
 
Datenmüllflut
  • Probleme
  • Werbung
  • JS Client-Side rendering
  • Video/Bilder Auflösung
  • Pre-Fetching/Overfetching
  • Analytics/Tracking/Logging/Tracing/Monitoring
  • Web Apps statt einfache Websites
  • Mehr Streaming (Video/Musik)
  • Lösungen
  • HTML picture Element
  • Neue Media Format (Video/Bilder/Audio)
  • Media+Container Queries
  • Neue Komprimierungsverfahren
  • Nur laden was gebraucht wird (lazy loading)
  • Server-Side rendering
  • Messen von User Verhalten
  • Filterung im Netzwerk (Ad Blocker/Script Blocker)
  • Fonts (Nur laden was benötigt wird - Schriftzeichensatz etc)
  • Messen statt glauben
  • nur nötigsten tracken
  • Native satt Web
  • Vektor statt Pixelgrafik
  • Modernes CSS statt JS
  • Text statt Bild/Video
  • Caching
  • Local/Session Storage
  • Weniger ist mehr
 
 
 
Emissionen Messen:
  • Messen schön und gut als Zusatzmaßname, aber Low Hanging Fruits wichtiger:
  • Nachts/Wochenende dev Server runter fahren
  • Features hinterfragen
  • Geräte länger unterstützen
  • ....
  • Seiten die häufig aufgerufen werden, eher Seiten messen, ansonsten ist das Optimierungspotential auf Serverseite höher (da wo kleine Änderungen viel bewirken können)
  • schon vorhandene Daten nutzen 
  • Cloud Anbieter (AWS, Google Cloud..) stellen schon Infos zu CO2 Verbrauch zur Verfügung
  • Google Lighthouse / Firefox Profiler hat Informationen (oft unter Performance)
  • Webseiten kann über Testseiten gestestet werden (Website Carbon Calculator, Cleaner Web Klimatest...)
  • muss nicht reale Emissionen wiederspiegeln:
  • mit sich selbst vergleichen
  • "Zählen von Servern"
  • Verbesserung gegenüber letzter Messung
  • nette Seiteneffekte klar machen:
  • gut an Kunden verkaufbar
  • Performance Optimierung
  • Kostenersparnisse feststellbar
  • nach außen Kommunizieren: 
  • Blauer Engel für Software <- Zertifizierung
  • CO2 Challenge <- Karlsruher Initiative in der sich Firmen selbst herausfordern 40% CO2 zu reduzieren (kein Wettbewerb)
  • für andere Nachvollziebar machen mit der SCI-Formel
 
  •  
  • Video/Bilder Auflösung
 
UN-Nachhaltigkeitsziele
  • Geschlechter-Gleichstellung:
  • Geschlechtseintrag in Formularen
  • bias durch machine learning / in Algorithmen
  • Weniger Ungleichheiten:
  • Zugang ermoeglichen
  • finanzielle Unterstuetzung // open source
  • physische Erreichbarkeit
  • Menschenwuerdige Arbeit:
  • Vermeidung von Software, die unter menschenunwuerdigen Bedingungen produziert wurde (Bsp: Click- Worker ChatGPT)
  • Alternativen schwierig zu finden/ Huerden fuer Nutzung gross
  • Widerstandsfaehige Infrastruktur:
  • Dezentralisierung / single points of failure vermeiden/minimieren
  • mehr finanzieller Einsatz fuer robuste Systeme
  • Nachhaltigen Staedte/Gemeinden: 
  • robuste Software einsetzen
  • Kritis unabhaengig und nicht proprietaer
  • Grundsaetzliches:
  • bei Entwicklung beachten, dass Risiko fuer Ausschluss bestimmter Gruppen (z.B. offline-Angebote) besteht --> Schnittstellen schaffen/ Konkurrenz vermeiden
  • weg von Gewinnmaximierung
  • Dekapitalisierung von Infrastruktur (Beispiel wie Fediverse)
  • Solidarisch mit sozialen und gruenen Bewegungen sein, intrasektional mit demonstrieren
 
 
Daten minimieren
  • Wo läuft der "nightly build"? Auf https://app.electricitymaps.com/map gucken, wann dort de Strommix physikalisch grün ist (nicht nur laut RZ-Zertifikat) und scheduled jobs in jene Zeiten legen (mittags = "lunchly build")
  • Dependencies ausmisten/minimieren, insb. wenn nur wenige Code-Pfade derselben benutzt werden.
  • Bei Ausbildung / Pair Programming auf profiling & observability, einfachere Tools, etc. achten
  • Erwartungen kommunizieren: "Wie schnell sollte ein Web Request sein?" "Ab 200ms gibt es wohl ein Problem!"
  • Big Data mit grap & Co, statt Hadoop, etc.
  • Immutable Data Structures & Event Sourcing
  • Datenfluss visualisieren & Events modellieren
  •  
 
Ereignisbasierte Architektur
 
  • Eventbasierte Kommunikation erhöht i.d.R. die Komplexität
  • Man braucht Entwickler*innen, die Erfahrung damit haben
  • Entscheidung für eine Architektur sollte kollaborativ gefällt werden -> RFCs, Peer-Reviews
  • Rolle des Managements: Nachhaltigkeit als Ziel setzen, ABER erst wenn betriebswirtschaftlich das Unternehmen überlebt
  • Hosting-Kosten als Proxy für den Nachhaltigkeits-Impact
  • Auf Unternehmenseben: Nachhaltigkeit in der Software-Entwicklung kann mit anderen Nachhaltigkeits-Zielen konkurrieren
 
Überkomplexität vermeiden
  • Technische Komplexität != kognitive Komplexität
  • Messen ob Features benutzt werden
  • Aber: Messen erhöht auch die Komplexität! Zusätzliche Tools, Extra-Requests etc.
  • Ab wann macht es Sinn, zu messen?
  • Neue Technologien nur mit sehr gutem Grund einführen, im Team diskutieren, auf stabile Technologien setzen
  • Rolle der*des Tech Lead: kritisch prüfen, ob eine Technologie eingesetzt werden soll
  • aber alle Teammitglieder sollten sich in der Verantwortung fühlen
  • Rolle der*des PO: Muss Raum für Verbesserungen und gute Implementierung lassen
  •