Die Wurzeln des Pestizid-Paradoxons liegen in der Landwirtschaft. Wenn ein Bauer ständig dasselbe Pestizid verwendet, um seine Ernte zu schützen, entwickeln schließlich die Schädlinge, die überleben, eine Immunität gegen dieses spezifische Pestizid. Im Laufe der Zeit verliert das Pestizid seine Wirksamkeit. Analog dazu, in der Softwareentwicklung, wenn Entwickler und Tester immer wieder dieselben Tests anwenden, werden sie nur die Fehler finden und beheben, die diese Tests identifizieren können.

Das Pestizid-Paradoxon in der Softwareentwicklung verweist also auf die Notwendigkeit, kontinuierlich neue und verschiedene Testfälle zu erstellen. In der modernen agilen Entwicklung (Siehe Beitrag „Agiles Manifest„), bei der man Software kontinuierlich ändert und verbessert, muss das Testen Schritt halten und sich anpassen.

Mit der Zeit entdecken Testfälle weniger und weniger Bugs, genau wie Pestizide, die ihre Wirksamkeit gegen Schädlinge verlieren. Um Qualität und Sicherheit zu gewährleisten, muss man die Testszenarien daher regelmäßig überprüfen und aktualisieren. Ebenso muss man neue Tests entwickeln, um auf veränderte oder neue Funktionen zu reagieren.

Ein weiterer zentraler Aspekt des Pestizid-Paradoxons in der Softwareentwicklung ist die Notwendigkeit einer vielfältigen Teststrategie. Dazu gehören Funktionstests, Integrationstests, Leistungstests, Sicherheitstests und Benutzerakzeptanztests. Ein vielfältiges Test-Portfolio, das verschiedene Aspekte und Ebenen der Software abdeckt, erhöht die Wahrscheinlichkeit, dass mehr Fehler entdeckt und behoben werden.

Das Pestizid-Paradoxon ist somit eine starke Erinnerung daran, dass Veränderung in der Softwareentwicklung nicht nur unausweichlich, sondern notwendig ist. Es lehrt uns, dass wir uns nicht auf bewährte Testverfahren verlassen sollten. Es macht Sinn, ständig neue Methoden und Ansätze zu entwickeln und anzuwenden, um Softwarequalität und -sicherheit zu gewährleisten.

Der Beitrag Pestizid-Paradoxon – Resistenz von Bugs und Fehlern erschien zuerst auf CEOsBay.

Continuous Integration (CI)

CI ist eine Praxis der Softwareentwicklung, bei der Entwickler ihre Änderungen am Code regelmäßig in einer zentralen Repository integrieren, in der Regel mehrmals täglich. Dieser Ansatz soll Probleme wie Merge-Konflikte oder schwer auffindbare Fehler aufgrund von Inkonsistenzen im Code frühzeitig erkennen und beheben.

Vor- und Nachteile von CI/CD

Einige der Hauptvorteile von CI sind:

• Früherkennung von Fehlern und Konflikten: Durch regelmäßige Integration und automatisierte Tests findet die Fehlerfindung und dadurch die Behebung der Fehler frühzeitig statt, bevor sie zu größeren Problemen führen.
• Reduzierung von Risiken: Da man Änderungen in kleineren Schritten und häufiger integriert, reduziert sich das Risiko, dass neue Funktionen bestehende Funktionen beeinträchtigen.
• Verbesserung der Codequalität: CI ermutigt Entwickler, Code häufiger zu testen, was zur Verbesserung der Codequalität beiträgt.

CI-Tools:

Es gibt eine Vielzahl von CI-Tools auf dem Markt, darunter Jenkins, GitLab CI, Travis CI und CircleCI. Diese Tools automatisieren den Integrationsprozess, indem sie den Code überprüfen, bauen und testen, sobald Änderungen eingecheckt sind.

Continuous Deployment (CD)

Continuous Deployment ist ein Prozess, bei dem man automatisierte Tests und Freigabeprozesse durchführt, um neue Codeänderungen kontinuierlich und in kürzester Zeit in die Produktionsumgebung einzuführen. Im Gegensatz zu Continuous Delivery, bei dem man die Freigabe in die Produktion noch manuell auslösen muss, geschieht dies bei Continuous Deployment vollautomatisch.

Vorteile von CD:

• Schnellere Markteinführung: Durch den Einsatz von CD kann man Software schneller auf den Markt und in Umlauf bringen, da man dadurch den manuellen Aufwand für die Bereitstellung minimiert.
• Automatisierte Fehlerbehebung: CD-Systeme bieten Möglichkeiten zur automatischen Fehlerbehebung und Rollbacks, um sicherzustellen, dass die Produktionsumgebung stabil bleibt.
• Bessere Zusammenarbeit: Durch CD kann man verschiedene Teams wie die Entwicklung, QA bzw. Testing und Operations besser aufeinander abstimmen, was die Zusammenarbeit und Kommunikation wesentlich verbessert.

CD-Tools:

Zu den beliebtesten CD-Tools gehören Spinnaker, GitLab CD, Octopus Deploy und Harness. Diese Tools helfen bei der Automatisierung von Bereitstellungsprozessen, einschließlich der Erstellung von Umgebungen, dem Ausführen von Tests und dem Verwalten von Konfigurationen.

Einige wichtige Punkte, die noch bei der Einführung und Anwendung von CI/CD zu beachten sind:

• Organisationskultur: Die Implementierung von CI/CD erfordert eine Veränderung in der Denkweise und Kultur eines Teams oder einer Organisation. Es ist wichtig, dass alle Beteiligten die Vorteile erkennen und bereit sind, sich auf kontinuierliche Verbesserung und Zusammenarbeit zu konzentrieren.
• Automatisierung: Um die Vorteile von CI/CD voll auszuschöpfen, ist es entscheidend, möglichst viele Schritte im Entwicklungs- und Bereitstellungsprozess zu automatisieren. Dies kann das Schreiben von Skripten für das Erstellen, Testen und Bereitstellen von Code oder die Verwendung von Tools und Plattformen umfassen, die diese Prozesse unterstützen.
• Testabdeckung: Um sicherzustellen, dass der Code in einer CI/CD-Pipeline zuverlässig funktioniert, ist es wichtig, ausreichende Testabdeckung sicherzustellen. Dies umfasst sowohl Unit-Tests als auch Integrationstests, um sicherzustellen, dass alle Aspekte einer Anwendung korrekt funktionieren. Hier macht es Sinn den Beitrag SonarQube zu erwähnen 😉
• Monitoring und Feedback: Im Zusammenhang mit CI/CD ist es wichtig, ein effektives Monitoring-System einzurichten, um Leistungsprobleme oder Fehler frühzeitig zu erkennen. Ebenso ist ein Feedback-System für Entwickler und Stakeholder entscheidend, um kontinuierlich voneinander zu lernen und Verbesserungen vorzunehmen. Hierzu schreibe ich in zukünftigen Beiträgen mehr. Bis es so weit ist, ist der Beitrag über Grafana erwähnenswert 😉
• Sicherheit: Bei der Implementierung von CI/CD ist es unerlässlich, Sicherheitspraktiken zu berücksichtigen. Dies umfasst die regelmäßige Überprüfung von Sicherheitspatches, die Durchführung von Sicherheitstests und die Einhaltung von Best Practices für sicheren Code.

Fazit

Continuous Integration und Continuous Deployment sind entscheidende Konzepte in der modernen Softwareentwicklung, die dazu beitragen, den Entwicklungsprozess zu beschleunigen, die Codequalität zu verbessern und die Zusammenarbeit zwischen Teams zu fördern. Durch die Einführung von CI/CD-Praktiken im Entwicklungsworkflow kann man Fehler frühzeitig erkennen, den Zeitaufwand für die Behebung von Problemen reduzieren und die Bereitstellung neuer Funktionen und Updates beschleunigen.

Indem man diese Faktoren berücksichtigt und CI/CD-Praktiken erfolgreich in einem Softwareentwicklungsprozess integriert, kann man von den Vorteilen der schnelleren Entwicklungszyklen, verbesserten Zusammenarbeit und von einer höheren Codequalität profitieren.

Der Beitrag CI/CD – Continuous Integration und Continuous Deployment erschien zuerst auf CEOsBay.

Kurze Zeitreise und die Entstehung von Community of Practice

Die Entstehung des Begriffs Community of Practice geht zurück auf das Jahr 1991. Geprägt durch die beiden Sozialwissenschaftler Jean Lave und Étienne Wenger. Sie stellten das Lernen in den Kontext sozialer Beziehungen. Dabei zeigten sie, dass für den Wissenserwerb – neben Strukturen oder Modellen – insbesondere die Teilnahme an einer Gemeinschaft entscheidend ist, in der man das Wissen konstruiert.

1998 erweiterte Etienne Wenger das Konzept für die Organisationsentwicklung und bestimmte damit einen neuen Entwicklungsschwerpunkt. Wenger hat mehr oder weniger die theoretische Grundlegung des Konzeptes beschrieben und generelle Verständnisgrundlagen des Konzeptes dargelegt. Aber auch außerhalb von Organisationen finden sich Communities of Practice. Besonders trifft man auf CoP’s bei internetgestützten Arbeitsgemeinschaften. Die Community of Practice wird heute in enger Verbindung zu Online-Communities und zum Wissensmanagement gesehen und stellt eine wichtige Möglichkeit zur Bildung sozialen Kapitals dar. Der Begriff des Wissensmanagements ist dabei von den beiden Herrschaften kritisch gesehen. Laut Lave, Wenger und anderen Sozialwissenschaftlern ist das Management von Wissen grundsätzlich nicht möglich. Wissen ließe sich ebenso wie die Bildung von Communities of Practice nicht „allein“ durch eine top-down Anordnung oder durch systematische Einrichtungsprozesse implementieren. Sozialwissenschaftler scheinen die Begriffe des „Gardening“ und „Nurturing“ zu bevorzugen.

Struktur

Eine Community of Practice besitzt in der Regel eine Struktur, in der Personen nicht via Festlegung eine bestimmte Rolle erhalten, sondern aufgrund ihrer Tätigkeit und der Akzeptanz bzw. Ablehnung durch andere Mitglieder eine Rolle erwerben. Mit „Festlegung“ ist in diesem Fall die Vorgabe durch Führungskräfte, Organisationsdiagramme oder andere „formale Vorgaben“ gemeint.

Den Begriff der Rolle, der besonders im deutschsprachigen Raum eine längere Tradition hat, verwenden die Sozialwissenschaftler dabei ungern. Sie sprechen von „Identität“, die sich ausbildet, und von Aufgabenverteilungen, die man untereinander aushandelt. So entwickeln sich auf Basis der Kommunikationsprozesse aktive und weniger aktive Mitglieder, Moderatoren und Experten. Diese Moderatoren darf man sich nicht als starr vergebene Positionen innerhalb des Geflechts der Community of Practice vorstellen. Es handelt sich hierbei auch um situativ ausgehandelte Funktionen und Aufgaben innerhalb der Community. Ebenso können sich Untergruppen bilden oder man bindet externe Personen als Gäste ein.

Aus eigener Erfahrung, beispielsweise im Open Source Space, kann ich sagen, dass zwar in der Öffentlichkeitsarbeit ein gewisses Bild einer Hierarchie erkennbar ist, doch innerhalb einer Arbeitsgruppe Rollen weitestgehend irrelevant sind. Dies liegt zum einen daran, dass man es meist mit sehr facettenreichen und gebildeten Personen zu tun hat und zum anderen daran, dass in diesem Umfeld das Lernen und die Wissensvermittlung im Vordergrund stehen.

Phasen

Fünf Phasen charakterisieren die Entwicklung einer Community of Practice.

1. Die erste Phase (Potential/Potenzial) ist durch eine oder mehrere Personen gekennzeichnet, die sich einer bestimmten Thematik annehmen.
2. Die zweite Phase (Coalescing/Vereinigung) ist geprägt durch die Bildung einer Grundstruktur, in der man Ziele, Aufgaben und Kommunikationswege skiziiert.
3. In der dritten Phase (Maturing/Reifung) beginnt die eigentliche Arbeit der Gemeinschaft. Der Wissensaufbau und Austausch. Mit zunehmender Aktivität steigt in der Regel auch die Zahl der Mitglieder. Fortlaufend werden Ziele, Aufgaben und Kommunikationswege bewertet und an die Bedürfnisse der Mitglieder durch die Mitglieder selbst angepasst.
4. Als vierte Phase (Stewardship/Verantwortung) wenn für die Mehrzahl der Mitglieder ein akzeptabler Stand erreicht ist und kein Bedarf für weitere Aktivitäten erkennbar sind. In diesem Fall sinkt die Anzahl der eingepflegten Informationen im Vergleich zu jener der entnommenen Informationen.
5. In der fünften und letzten Phase (Transformation/Umwandlung) verliert die Gemeinschaft zunehmend an Gewicht als zentraler Informationsknotenpunkt, weil man auf andere Quellen ausweicht oder die Thematik selbst an Bedeutung verliert.

Diese Phasen können, aber müssen nicht auf diese Art und Weise auftreten bzw. durchlaufen. Diesen Phasenablauf haben Wenger, Snyder und McDermott aus verschiedenen Fällen generalisiert, um so ein „Gerüst“ für den jeweiligen Unterstützungsbedarf für das Florieren der Community zugrunde zu legen.

Die Pflege von Community of Practice

Design for evolution

Stetige Veränderung ist notwendig: Anpassung an neue Mitglieder, Einführung neuer Mitglieder, Veränderung von Ressourcenlagen, Veränderung von Diskurstraditionen, Veränderung von Problemlagen von Mitgliedern, Veränderungen in der Struktur der CoP.

Open a dialogue between inside and outside perspectives

Der Austausch mit der Umgebung und die aktive Aushandlung von Bedeutung in der „Arena“ der CoP bilden den Hauptantriebsgrund, warum Menschen sich zu CoPs zusammenschließen.

Invite different levels of participation

Von Kernaktivisten allein wird keine CoP getragen. Man muss sich auch um den Nachwuchs für Positionen innerhalb der CoP kümmern. Der Einbezug von anderen „Zonen“ in der CoP trägt auch zur Pluralität der Blickwinkel auf ein spezifisches Problem bei.

Develop both public and private community spaces

Auch wenn die CoP oftmals selbst im „Organizational Underlife“ angesiedelt ist, so gibt es auch hier Bereiche, in denen sich Untergruppen treffen, in denen man Themen abseits der eigentlichen Agenda diskutiert, in denen man auch persönliche Problemlagen und Differenzen ansprechen kann, ohne vor das „Plenum“ der CoP zu treten. Spannungen bleiben unter Umständen bestehen, wenn man solche Probleme nicht abseits der „offiziellen Bühne“ diskutiert bzw. diskutieren kann. Oftmals bilden solche Nebenschauplätze auch die Geburtsstätte für nachfolgende Themen einer CoP, die diese dann aufrechterhält, wenn auch in vielleicht geänderter Konstellation.

Focus on value

Die Sicherstellung von Qualität ist auch für CoPs wichtig. Das betrifft sowohl die Pflege der CoPs auf einem Meta-Niveau als auch die Beiträge zum „Situated Negotiation of Meaning“.

Combine familiarity and excitement

Auch CoPs leben von tragenden Strukturen aus mehr routinisierten Praktiken und frischem Wind.

Create a rhythm for the community

Auch der Puls verschiedener Aktivitäten trägt zum Fortbestand und zu einem guten Arbeitsklima innerhalb der CoP bei.

Vorteile für das Individuum durch Community of Practice

Bei Community of Practice-Meetings geht es primär darum, Informationen und Fragen zu bestimmten Problemen aus dem professionellen Alltag zu besprechen und gemeinsam Lösungen zu finden. Die gegenseitige Unterstützung und Zusammenarbeit zwischen den Mitgliedern stehen damit im Vordergrund. Der große Vorteil liegt darin, dass Personen miteinander interagieren, die sonst im Alltag meist nicht miteinander arbeiten. Bei CoP-Meetings hat man die Möglichkeit individuelle Erfahrungen miteinander zu teilen, um daraus wiederum neue Möglichkeiten zu kreieren und bestimmte Herausforderungen zu meistern. Einzig durch die Interaktion von unterschiedlichen Netzwerken können neue Ideen entstehen, wobei jede Partei ihre eigenen Sichtweisen teilt, die Einfluss auf die Entscheidungen der anderen hat und dadurch ein Lerneffekt entsteht. Arbeiten und Lernen gehören im professionellen Kontext stets zusammen. Eine Community of Practice fördert diese Zusammenkunft von Arbeit und Lernen.

Vorteile für die Community

Communities profitieren von Community of Practice dahin gehend, dass das Team sich selbstständig und selbstorganisiert weiterentwickelt, ohne, dass Führungspersonen oder Verantwortliche kostspielige Ausgaben für Fortbildungen oder Ähnliches ausgeben müssen. 

Voraussetzungen hierfür sind natürlich, die verfügbare Zeit und die Ressourcen für die eingesetzte Hard- und Software bzw. je nachdem, in welchem Umfeld und mit welcher Zielsetzung man unterwegs ist. Die in den Meetings neu erlangten Kenntnisse wirken sich direkt auf die Leistungen im täglichen Leben aus.

Fazit

In meiner Wahrnehmung bzw. in meinem Verständnis, gehe ich davon aus, dass bei der Themenverarbeitung durch einige Sozialwissenschaftler im „Community of Practice“ von einer physischen Präsenz der Teilnehmenden die Rede ist. Zumal die Literatur, die ich gelesen habe, noch aus den frühen 90’ern ist. Jedoch habe ich diese Art von CoP’s primär online kennenlernen dürfen. Dementsprechend habe ich an Meetings virtuell bzw. remote teilgenommen, was seit den Anfängen der Coronapandemie immer häufiger stattgefunden hat und auch im konventionellen Geschäftsleben mehr und mehr ankommt. Besonders im Blockchain Space hat sich diese Methode sehr stark etabliert. Folglich konnte ich die genannten 5 Phasen mehrfach, sowohl mit einem positiven als auch mit einem negativen Verlauf wiedererkennen. Alles in allem sehe ich es von Vorteil, sich mit diesem Thema auseinanderzusetzen. So erhält man eine etwas differenzierte Sicht auf die Zusammenarbeit innerhalb und außerhalb von Communities und kann bewusst mit diversen Herausforderungen umgehen.

Der Beitrag Community of Practice – Kraft des gemeinsamen Lernens und Wachsens erschien zuerst auf CEOsBay.

Kurze Zeitreise

CSS (Cascading Style Sheets) entstand in den 90er Jahren als Reaktion auf die wachsende Komplexität des Webdesigns und das Bedürfnis, eine klarere Trennung zwischen Inhalt (HTML) und Gestaltung (CSS) zu erreichen. Bis dahin verwendeten Webdesigner und Entwickler hauptsächlich HTML-Tags und -Attribute, um das Design einer Webseite zu kontrollieren. Diese Praxis führte jedoch zu unübersichtlichem und schwer wartbarem Code und schränkte die kreativen Möglichkeiten ein.

Der norwegische Informatiker und Web-Pionier Håkon Wium Lie ist der Hauptentwickler von Cascading Style Sheets. Zusammen mit dem belgischen Informatiker Bert Bos schlug er 1994 die Idee von CSS vor. Lie arbeitete zu dieser Zeit am CERN (der Europäischen Organisation für Kernforschung) und war am Projekt beteiligt, das zum ersten Webbrowser führte, dem WorldWideWeb (später umbenannt in Nexus). Lie und Bos erkannten, dass man eine Lösung für das Design-Problem finden musste, und entwickelten das Konzept der Cascading Style Sheets.

Später übernahm World Wide Web Consortium (W3C) Cascading Style Sheets. Eine internationale Organisation, die Webstandards entwickelt und pflegt. Das W3C veröffentlichte CSS Level 1 (CSS1) im Jahr 1996. Relativ schnell nahm man es als Webstandard auf. Seitdem hat sich Cascading Style Sheets stetig weiterentwickelt und umfasst mittlerweile mehrere Versionen und Module, die unterschiedliche Aspekte des Webdesigns abdecken.

Die Syntax von CSS

Ein CSS besteht aus Regelsätzen, die jeweils aus einem Selektor und einer Deklaration bestehen. Der Selektor bestimmt, auf welche Elemente man die Stilregeln anwendet, während die Deklaration eine oder mehrere Eigenschaften und deren Werte definiert, die man auf die ausgewählten Elemente angewenden möchte.

Beispiel:

h1 {
  color: red;
  font-size: 24px;
}

Selektoren

Selektoren sind die grundlegenden Bausteine eines CSS-Stylesheets. Sie bestimmen, welche HTML-Elemente von den definierten Stilregeln betroffen sind. Es gibt verschiedene Arten von Selektoren, wie z.B. Element-Selektoren, Klassen-Selektoren, ID-Selektoren und Pseudoklassen.

Das Box-Modell von CSS

Eines der grundlegenden Konzepte in CSS ist das Box-Modell. Die Darstellung aller Elemente auf einer Webseite erfolgt als rechteckige Box.

Diese bestehen aus den folgenden vier Bereichen:

1. Inhalt
2. Padding
3. Border
4. Margin.

Durch die Manipulation dieser Bereiche kann man das Layout und die Anordnung von Elementen auf der Webseite steuern.

Responsive Webdesign

Das Aufkommen von mobilen Geräten hat die Wichtigkeit von Responsive Webdesign signifikant erhöht. CSS bietet verschiedene Techniken, um Websites auf unterschiedlichen Bildschirmgrößen und Geräten optimal darzustellen. Die bekannteste Technik ist die Verwendung von Media Queries, die es ermöglichen, verschiedene Cascading Style Sheet Regeln abhängig von der Bildschirmgröße oder anderen Geräteeigenschaften anzuwenden.

Fazit:

CSS ist immer noch ein unverzichtbares Werkzeug für Webdesigner und Entwickler. Durch das Verständnis der Grundlagen und der zugrundeliegenden Konzepte kann man das Aussehen und die Benutzererfahrung von Webseiten und Webanwendungen drastisch verbessern. Die Flexibilität und Leistungsfähigkeit von CSS eröffnen eine Welt der kreativen Möglichkeiten und helfen dabei, das Web nach den eigenen Vorstellungen zu gestalten.

Der Beitrag CSS – Die Sprache für ansprechendes Webdesign und kreative Freiheit erschien zuerst auf CEOsBay.