Green Coding Links: * https://greensoftware.foundation/ * https://docs.electricitymaps.com/ * https://carbon-aware-sdk.greensoftware.foundation/ * https://sustainable-computing.io/ 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 * Reproducible builds und dann dependencies nicht per Schedule updaten, sondern nur bei Änderungen: https://docs.renovatebot.com/getting-started/running/#docker-images * 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. * https://adamdrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html * https://stackoverflow.com/questions/9066609/fastest-possible-grep/9067042#9067042 * 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 *