Grundlagen

Warum OAuth?

• Benutzerkontrolle: OAuth ermöglicht es Benutzern, Anwendungen und Diensten den Zugriff auf ihre Konten bei verschiedenen Anbietern zu gewähren, ohne dabei ihre Benutzername/Passwort-Kombinationen preiszugeben.

• Sicherheit: Da die Anmeldeinformationen nicht direkt geteilt werden, reduziert OAuth das Risiko von Datendiebstahl und Missbrauch von Anmeldeinformationen.

• Granulare Berechtigungen: OAuth erlaubt es Benutzern, den Umfang und die Dauer der Zugriffsberechtigungen, die an eine Anwendung vergeben werden, präzise zu steuern.

Hauptkomponenten von OAuth

• Ressourcenbesitzer (Resource Owner)
  Der Ressourcenbesitzer ist normalerweise der Endbenutzer, der den Zugriff auf seine Daten und Ressourcen bei einem Ressourcenserver gewährt.

• Ressourcenserver (Resource Server)
  Der Ressourcenserver hostet die geschützten Daten und Ressourcen des Ressourcenbesitzers. Er ist dafür verantwortlich, die Autorisierung und Authentifizierung von Anfragen mithilfe von OAuth-Tokens zu überprüfen. (Kleiner Tipp am Rande. Bei den Tokens handelt es sich nicht um die Tokens, die man aus den Kryptowährungen kennt 😉 )

• Client
  Die Client-Anwendung ist der Konsument der geschützten Ressourcen. Sie stellt Anfragen an den Ressourcenserver, um im Namen des Ressourcenbesitzers auf die Daten zuzugreifen.

• Autorisierungsserver (Authorization Server)
  Der Autorisierungsserver ist für die Ausgabe, Überprüfung und den Widerruf von OAuth-Zugriffstokens zuständig. Er agiert als Vermittler zwischen dem Ressourcenbesitzer, dem Client und dem Ressourcenserver.

OAuth-Fluss

Man kann den OAuth-Fluss in vier grundlegende Schritte unterteilen:

• Anfordern der Autorisierung: Der Client fordert die Autorisierung des Ressourcenbesitzers an, um auf dessen Ressourcen zuzugreifen.

• Autorisierungsantwort: Der Ressourcenbesitzer gewährt die Autorisierung und leitet den Client an den Autorisierungsserver weiter. Der Client erhält einen Autorisierungscode.

• Anfordern eines Zugriffstokens: Der Client sendet den Autorisierungscode an den Autorisierungsserver und fordert ein Zugriffstoken an.

• Token-Ausgabe: Der Autorisierungsserver überprüft den Autorisierungscode, stellt ein Zugriffstoken aus und sendet es an den Client.

Nachdem der Client das Zugriffstoken erhalten hat, kann er es verwenden, um auf die geschützten Ressourcen des Ressourcenbesitzers zuzugreifen, indem er Anfragen an den Ressourcenserver stellt. Der Ressourcenserver überprüft das Token und gewährt den Zugriff entsprechend der Berechtigungen, die vom Ressourcenbesitzer festgelegt wurden.

Versionen und Unterschiede von OAuth

Es gibt zwei Hauptversionen. OAuth 1.0 und OAuth 2.0. Die Veröffentlichung von OAuth 1.0 fand im Jahr 2010 statt und verwendet einen komplexeren kryptografischen Ansatz für die Sicherheit. Im Jahr 2012 folgte OAuth 2.0 und ist eine überarbeitete Version, die eine einfachere und flexiblere Architektur bietet. Zweiteres basiert auf Bearer-Tokens. Bei beiden handelt es sich nach wie vor um offene Standardprotokolle zur sicheren Delegierung von Zugriffsberechtigungen. Obwohl sie gemeinsame Ziele verfolgen, unterscheiden sie sich in ihrer Architektur, ihren Sicherheitsmechanismen und besonders in der Benutzerfreundlichkeit. Durch die unterschiedliche Architektur ist keine Abwärtskompatibilität gegeben.

Sicherheitsmechanismen:

1.0: Verwendet einen kryptografischen Ansatz, bei dem man Anfragen mithilfe von kryptografischen Signaturen und einem gemeinsamen Geheimnis (Shared Secret) zwischen dem Client und dem Autorisierungsserver signiert. Diese Methode erfordert einen erhöhten Aufwand bei der Implementierung und Konfiguration.

2.0: Verwendet Bearer-Token, bei denen der Besitzer des Tokens (Client) Zugriff auf die geschützten Ressourcen erhält. Die Sicherheit basiert hauptsächlich auf der sicheren Übertragung und Aufbewahrung von Tokens (z. B. über https). Diese Methode ist einfacher zu implementieren und erfordert weniger kryptografische Kenntnisse.

Flexibilität:

1.0: Bietet einen starren Ablauf zur Anforderung und Nutzung von Zugriffstokens, der weniger Anpassungsmöglichkeiten für verschiedene Anwendungsszenarien bietet.

2.0: Ermöglicht eine größere Flexibilität und Anpassungsfähigkeit, indem man verschiedene „Grant Types“ (Genehmigungsarten) zur Verfügung stellt, um unterschiedlichen Anwendungsszenarien und Plattformen Genüge zu tun.

Einfachheit:

1.0: Die Implementierung und das Debugging von OAuth 1.0 können komplex sein, da Entwickler den kryptografischen Prozess und das Signieren von Anfragen verstehen müssen.

2.0: Die Implementierung von OAuth 2.0 ist einfacher und erfordert weniger kryptografische Kenntnisse. Dies führt zu einer schnelleren und einfacheren Integration in Anwendungen und Dienste.

Mobile und native Anwendungen:

1.0: Aufgrund seiner komplexeren Natur und der kryptografischen Anforderungen ist OAuth 1.0 weniger geeignet für mobile und native Anwendungen, bei denen Ressourcen und Konnektivität eingeschränkt sein können.

2.0: Durch die einfachere Implementierung und den flexibleren Ablauf eignet sich OAuth 2.0 besser für die Integration in mobile und native Anwendungen.

Vorteile

Sicherheit: Es erhöht die Sicherheit, indem man Anmeldeinformationen nicht direkt teilen muss und Tokens verwendet, um auf Ressourcen zuzugreifen.

Benutzerfreundlichkeit: Es ermöglicht Single Sign-On (SSO) und reduziert die Notwendigkeit, mehrere Benutzernamen und Passwörter zu verwalten.

Flexibilität: Es bietet eine flexible Architektur, die für verschiedene Anwendungsszenarien und Plattformen geeignet ist.

Granularität: Es ermöglicht, den Umfang und die Dauer der gewährten Berechtigungen genau zu steuern.

Nachteile

Komplexität: Die Implementierung von OAuth, insbesondere bei OAuth 1.0, kann komplex sein, da es verschiedene Abläufe und Mechanismen beinhaltet. Dies kann zu einer steileren Lernkurve für Entwickler führen, die sich nicht mit dem Protokoll auskennen.

Sicherheitsrisiken: Trotz der verbesserten Sicherheit, die OAuth bietet, gibt es immer noch Sicherheitsrisiken. Fehlkonfigurationen, unzureichende Validierungen und direkte Angriffe auf den Autorisierungscode oder das Zugriffstoken können die Sicherheit weiter gefährden.

Abhängigkeit von Drittanbietern: Die Verwendung von OAuth kann eine Abhängigkeit von Drittanbieter-Autorisierungsservern schaffen, die möglicherweise Ausfallzeiten, Sicherheitsverletzungen oder andere Probleme aufweisen können.

Datenschutzbedenken: Bei der Verwendung von OAuth besteht das Risiko, dass Benutzer mehr Daten preisgeben als erforderlich, da Anwendungen möglicherweise Zugriff auf mehr Informationen anfordern, als für ihre Funktionen notwendig ist.

Token-Hijacking: Obwohl es die Sicherheit gegenüber der direkten Weitergabe von Anmeldeinformationen verbessert, besteht immer noch die Gefahr, dass Angreifer Zugriffstoken abfangen oder stehlen können. Dies kann zu unbefugtem Zugriff auf Benutzerdaten führen.

Eingeschränkte Implementierung: Die Nutzung von OAuth in bestimmten Anwendungsszenarien, wie beispielsweise bei Geräten mit eingeschränkter Internetkonnektivität oder eingeschränkten Eingabemöglichkeiten, kann sich als schwierig oder teilweise unmöglich gestalten.

Best Practices

• Man sollte immer die neueste Version (aktuell OAuth 2.0) für bessere Sicherheit und Flexibilität verwenden.
• Implementierung von „Proof Key for Code Exchange“ (PKCE) Erweiterung ist zu empfehlen, um Angriffe, die den Autorisierungscode abfangen, verhindern zu können.
• Sichere Speicherung des Zugriffstokens und der Client-Anmeldeinformationen, um den Missbrauch zu verhindern.
• Verwenden von kurzen Gültigkeiten und Lebensdauern für Zugriffstokens und Erneuerungen bei Bedarf mithilfe von Aktualisierungstokens.
• Implementierung von Zustimmungsbildschirmen, um Benutzer über den Umfang und die Dauer der Berechtigungen, die man gewährt, zu informieren.

Fazit:

OAuth ist ein leistungsstarkes Protokoll, das die sichere Delegierung von Zugriffsberechtigungen im Internet ermöglicht. Durch das Verständnis der Grundlagen von OAuth und die Einhaltung der Best Practices können Entwickler Anwendungen erstellen, die eine sichere und benutzerfreundliche Erfahrung bei Login-Verfahren bieten.

Der Beitrag OAuth – Login ohne Preisgabe von Anmeldeinformationen erschien zuerst auf CEOsBay.

Kurze Zeitreise

Die Tosca Testsuite ist eine Entwicklung der österreichischen Firma Tricentis und die Veröffentlichung fand erstmals im Jahr 2007 statt. Gegründet von Wolfgang Platz und Franz Fuchsberger, die beide Erfahrung in der Software-Entwicklung hatten.

Als sie in ihrem Berufsleben immer wieder auf die Probleme von manuellen Tests und fehleranfälliger Testautomatisierung stießen, beschlossen sie, eine Lösung zu entwickeln, die den Testprozess effizienter und präziser machen sollte.

Im Laufe der Jahre hat die Tosca Testsuite eine Reihe von Verbesserungen und Erweiterungen erhalten. Funktionen kamen hinzu, um die Unterstützung verschiedener Plattformen und Technologien zu verbessern und die Testdatenverwaltung und Berichterstattung zu optimieren.

Wie funktioniert Tosca?

Die Tosca Testsuite bietet eine breite Palette von Funktionen, die den Testprozess vereinfachen und beschleunigen. Ein wichtiges Merkmal ist die Möglichkeit, Testszenarien aufzunehmen und automatisch zu generieren. Bewerkstelligt durch die Verwendung von Model-Based Testing (MBT), bei dem man Testszenarien aus Modellen der Anwendung automatisch generiert. Diese Methode bietet eine höhere Effizienz und Präzision als manuelle Tests. An dieser Stelle verweise ich auch gerne auf (TDD), dem Test Driven Development.

Die Testsuite bietet auch eine integrierte Testdatenverwaltung, die grundsätzlich die Erstellung, Verwaltung und Wiederverwendbarkeit von Testdaten ermöglicht. Dies kann den Testprozess signifikant vereinfachen und reduziert die Fehlerquote.

Ein weiteres wichtiges Merkmal der Tosca Testsuite ist die Möglichkeit, Tests in einer Vielzahl von Umgebungen durchzuführen. Es unterstützt verschiedene Plattformen und Technologien wie Web-Anwendungen, mobile Anwendungen, SAP-Systeme und Legacy-Systeme.

Die Testsuite bietet auch eine umfassende Berichterstattungsfunktion, die eine genaue Übersicht über den Testprozess und über die Ergebnisse bietet. Man kann die Berichte auch anpassen, um die individuellen Anforderungen zu erfüllen. Unter anderem ermöglicht dies den Benutzern auch, schnell und einfach Einsicht in den Status des Testprozesses zu erhalten.

Die Tosca Testsuite ist relativ einfach zu bedienen und zu erlernen. Es bietet eine intuitive Benutzeroberfläche und eine umfangreiche Dokumentation, um den Einstieg zu erleichtern.

Fazit

Insgesamt bietet die Tosca Testsuite eine umfassende Lösung für das Testmanagement, die Automatisierung und die Überwachung von Anwendungen. Es verbessert die Effizienz des Testprozesses und reduziert die Fehlerquote, was zu einer höheren Qualität der Anwendung und einer besseren Benutzererfahrung führt.

Der Beitrag Tosca – Testautomatisierung für agile und fehlerfreie Softwareentwicklung erschien zuerst auf CEOsBay.

Man verwendet den Ausdruck Modultest unter anderem bei frühen Teststufen, in denen man die inneren, detailliertesten Komponenten der Software testet. Gemäß Software Validation & Verification Plan sind diese Tests nur für Module mit geringer Kritikalität nicht notwendig. Im Grunde genommen bei Fehlern, die dem User nur geringfügige Unannehmlichkeiten bereiten.

In einer Abstraktion der verwendeten Programmiersprache, spricht man von Komponente oder Softwarebaustein. Den Test eines solchen einzelnen Softwarebausteins bezeichnet man auch allgemeiner als Komponententest.

Als Testbasis kann man in der Regel die komponentenspezifische Anforderung und das Softwaredesign der Komponente (auch Komponentenspezifikation genannt) heranziehen. Für Whitebox-Testfälle oder um Aussagen zur Codeüberdeckung zu erhalten, kann man zusätzlich den Sourcecode einer Komponente analysieren und diesen als Testbasis verwenden. Wobei dabei auch Tools wie Jacoco helfen können. Ob die Komponente auf einen Testfall richtig reagiert, muss man allerdings auch hier auf Basis der Design- und Anforderungsdokumente beurteilen.

Typische Testobjekte sind wie bereits beschrieben Programmunits, -Module bzw. Klassen. Aber auch Kommandozeilenskripte des Betriebssystems (Shell-Skripte), Datenbankskripte, Datenkonvertierungs- oder Migrationsprozeduren, Datenbankinhalte sowie Konfigurationsdaten können Testobjekte sein. Kennzeichnend ist in der Regel der isolierte Test eines einzelnen Softwarebausteins. Dies dient primär, um komponentenexterne Einflüsse beim Testen auszuschließen. Alle so ermittelten Fehler kann man so dem spezifischen Modul zuordnen.

Klar zu unterscheiden ist auf jeden Fall der Integrationstest, den ich in einem separaten Beitrag thematisiere. Bei einem Integrationstest konzentriert man sich auf die Wechselwirkung mit Nachbarkomponenten.

Die Erstellung solcher Tests ist in der Regel die Aufgabe eines Programmierers. Dies liegt zum einen daran, dass man ein ausgeprägtes Verständnis für die Programmiersprache in der die Anwendung geschrieben ist haben muss. Und zum anderen daran, dass man meist auch einen Testtreiber benötigt, dessen Programmierung in der Regel auch der Entwickler übernimmt.

Einordnung im Testprozess

Algorithmen auf Unitebene besitzen meist nur eine begrenzte Komplexität und man kann sie über klar definierte Schnittstellen aktivieren. Daher kann sie mit relativ wenigen Testfällen weitgehend vollständig testen. Dies gilt als Voraussetzung für die anschließende Teststufe. Dem Integrationstest, um dort die Testfälle auf das integrierte Zusammenwirken größerer Funktionsteile oder der gesamten Anwendung ausrichten zu können. Die modulspezifischen Detailkonstellationen lassen sich damit auf Stichproben beschränken, was die Anzahl der erforderlichen Testfälle signifikant reduziert.

Zum Vergleich: Ein Gerät wird erst dann als Ganzes getestet, wenn die Funktionsfähigkeit seiner Einzelteile gesichert ist.

Test des Vertrages und nicht der Algorithmen

Man testet bei Modultests gemäß dem Design-by-contract-Prinzip möglichst nicht die Interna einer Methode, sondern nur ihre externen Auswirkungen (Rückgabewerte, Ausgaben, Zustandsänderungen, Zusicherungen). Sind die internen Details der Methode geprüft (dies wird als White-Box-Testing bezeichnet), kann der Test fehlschlagen, obwohl sich die externen Auswirkungen nicht geändert haben. Daher empfiehlt man in der Regel das sogenannte Black-Box-Testing, bei dem man sich auf das Prüfen der externen Auswirkungen beschränkt.

Was sind die Vorteile von Unit Tests?

• Mittels automatisierter Unittests kann man im Schnitt 30 % der Fehler erkennen. Bei der Verwendung von TDD (Test Driven Development) kann man im Schnitt 45 % und im besten Fall 85 % der Fehler vermeiden.
• Fehler erkennt man durch Modultests bereits während der Entwicklung. Die durch Unittests vermiedenen Fehlerkosten sind daher gemäß der Rule of Ten (Dazu später mehr) um ein Vielfaches höher als bei späteren Teststufen, was Unittests zur effizientesten Teststufe machen.
• Im Falle eines Fehlers kann man diesen sehr viel genauer eingrenzen und damit schneller finden und beheben.
• Die Tests erfüllen den Zweck einer lebenden Dokumentation. In Kombination mit einer sinnvollen Benamung der Objekte (Clean Code) können zusätzliche Dokumentationsmaßnahmen entfallen.
• Da einzelne Module nur wenige mögliche Codeausführungspfade besitzen, muss man viel weniger mögliche kombinatorische Ausführungspfade berücksichtigen als bei anderen Testarten. Bei übergeordneten Tests kann man sich dann stichprobenartig auf die wichtigsten Ausführungspfade konzentrieren und damit die Anzahl dieser Tests deutlich reduzieren.
• Da man nur einzelne Module testet, kann man Modultests, oft um mehrere Größenordnungen, schneller und damit öfter (bzw. kontinuierlich) ausführen als andere Testarten.
• Wenn man Fehler mit einem Test absichert, kann man den erneuten Auftritt des gleichen Fehlers verhindern.
• Durch die Fehlerreduktion ergeben sich Geschwindigkeitsvorteile in der Entwicklung in mittleren bis großen Softwareprojekten.
• Da man Abhängigkeiten zwingend vermeiden muss, um einen Modultest zu ermöglichen, bleibt der Code verhältnismäßig schnell änderbar. Hierdurch kann man schneller auf wechselnde Anforderungen reagieren. Siehe Agile Manifest 😉
• Da automatisch ausgeführte Tests um mehrere Größenordnungen schneller sind als manuelle Tests, reduziert sich der Zeitaufwand für das Testen deutlich. Hierdurch kann man die Entwicklungsstufen schneller durchlaufen und die Release-Zyklen signifikant verkürzen.

Was sind die Nachteile von Unit Tests?

• Bei der Implementierung neuer Funktionen muss man nicht nur die Funktion implementieren, sondern auch die dazugehörenden Tests vorbereiten bzw. definieren. Dadurch ergibt sich ein oft mehrfacher Implementierungsaufwand.
• Bei Änderungen muss man nicht nur die geänderten Funktionen, sondern auch die dazugehörenden Tests anpassen. Insbesondere bei der Entwicklung von Prototypen, bei der sich die Codebasis schnell verändert, ist das Testen daher oft eher ein Hindernis.
• Da man die Funktionalität der Tests verwendet, ist in den IDEs schwerer ersichtlich, ob eine Funktionalität keine Verwendung mehr findet und ob man es daher entfernen kann.
• Weisen die Tests untereinander Abhängigkeiten auf (z. B. durch gemeinsame Testdaten), so können einzelne Änderungen an der Codebasis eine Vielzahl von Tests beeinflussen, was den Änderungsaufwand mit der Größe der Codebasis exponentiell erhöht.

Fehlerkosten 10er Regel (Rule of ten)

Die Zehnerregel der Fehlerkosten besagt, dass je weiter ein Fehler sich unentdeckt in die späten Phasen des Werdegangs eines Produktes oder Prozesses bewegt – oder gar bis zum Kunden –, desto höher steigen die Kosten zur Behebung des Fehlers. Eindrucksvoll untermauert durch die Ergebnisse einiger Studien aus den 70er Jahren in Japan, USA und Großbritannien, die sich mit den Ursachen von Produkt- bzw. Qualitätsmängeln beschäftigten. Alle Analysen lieferten nahezu die gleichen Ergebnisse: Ca. 70 % aller Produktmängel hatten ihre Ursache bereits in der Entwicklung, Konstruktion und Arbeitsvorbereitung. Der Herstellungsprozess selbst hat bezüglich der Endqualität des Produktes offensichtlich eher einen sekundären Einfluss. Eine VDMA-Studie zum Thema „Qualitätsbezogene Kosten“ Anfang der 90er Jahre in der Bundesrepublik Deutschland bestätigt dieses Ergebnis.

Die Zehnerregel der Fehlerkosten oder „Rule of ten“ sagt aus, dass sich die Fehlerkosten für einen nicht entdeckten Fehler von Stufe zu Stufe der Wertschöpfung um den Faktor 10 erhöhen. Je früher ein Fehler entdeckt und beseitigt wird, desto kostengünstiger ist dies für die Organisation und schlussendlich auch für den User bzw. Kunden.

Ansonsten sind diese auch in der DIN 55350-11 im Rahmen des Qualitätsmanagements festgehalten. Doch darauf gehe ich in einem separaten Beitrag ein.

Wo sind die Grenzen der Unit Tests?

Unit Tests können (wie jeder Test) die Fehlerfreiheit der getesteten Units, Module usw. nicht garantieren oder nachweisen, sondern lediglich unterstützen. Die Grenzen von Unit Tests liegen primär nur in den Fällen vor in denen man Fehler finden kann, zu deren Entdeckung die verwendeten Tests geeignet sind. Eine Softwarekomponente, die „grün“ testet, ist also nur bedingt fehlerfrei.

Das Merkmal von Code, „grün“ zu testen, und durchaus auch der Wunsch nach diesem Ergebnis, kann dazu führen, dass man tatsächlich (unbewusst) nur so viel testet, bis alle Tests „grün“ sind. Module, die keine fehlschlagenden Modultests haben, als fehlerfrei zu behandeln, ist ein Fehlschluss in der Praxis des (TDD) Test Driven Development.

Um eine ausreichende Testabdeckung zu erzielen, lohnt es sich u.U., vor dem Erstellen der Testfälle Refactoring-Maßnahmen anzuwenden. Dies erst nach abgeschlossenen Unit Tests (für den alten Code) zu tun, schafft Raum (wie jede Änderung im Code) für neue Fehlerrisiken und kann deshalb wiederholtes Testen erforderlich machen.

Wenn der Autor von Unit Tests mit dem Autor der Module identisch ist, können Denkfehler in der Implementierung auch im Test erscheinen und verpasst gegebenenfalls die Chance, diese aufzudecken. Wenn es sich um dieselbe Person handelt, kann man die vorrangige Entwicklung der Tests ebenfalls nicht garantieren, da sowohl die beabsichtigte Funktionsweise des Codes als auch die zukünftige Gestalt bereits im Gedankengut des Testautors und späteren Codeautors präsent sein können. Dies kann im Extreme Programming durch „Test Ping-Pong“ abgefangen werden, bei der sich Entwickler bei der Implementierung der Funktionalität und der Tests abwechseln.

Bei der Entwicklung von Modultests können Testfälle entstehen, die der Zielsetzung und dem Charakter von Modultests nicht oder nur zum Teil entsprechen. Wie bei der Programmierung existieren daher auch für die Entwicklung von Modultests Anti-Pattern, die man möglichst vermeiden sollte.

Der Beitrag Unit Tests – Fundament für stabile und effiziente Software erschien zuerst auf CEOsBay.

Kurze Zeitreise

Anfang 2001 trafen sich vor der Kulisse der Wasatch Mountains in Snowbird, Utah, 17 Personen, um über die Zukunft der Softwareentwicklung zu diskutieren. Die Mitglieder der Gruppe teilten die Enttäuschung über den aktuellen Stand der Dinge, wenn es um die Softwareentwicklung in agilen Teams ging. Zu diesem Zeitpunkt waren Sie sich einig, dass man etwas ändern muss. Lediglich bestand noch keine Einigkeit darüber, was genau und wie genau es aussehen sollte.

Das Problem, so waren sie sich einig, bestand darin, dass die Unternehmen sich so sehr auf die exzessive Planung und Dokumentation ihrer Softwareentwicklungszyklen konzentrierten, dass sie das Wesentliche aus den Augen verloren – die Zufriedenheit der Kunden.

Die Unternehmen rühmten sich zwar mit Unternehmenswerten wie „Exzellenz“ und „Integrität“, aber diese Werte trugen wenig dazu bei, die Menschen – insbesondere die Softwareentwickler – auf einen besseren Weg zu bringen. Das musste sich ändern. Viele der Snowbird 17 hatten bereits Ideen, wie man die neue Ära der Softwareentwicklung einläuten kann. Die Reise in die Berge war die Chance, dies zu diskutieren.

Aus diesem verlängerten Wochenende ging das Agile Manifest mit gerade einmal 68 Wörtern hervor. Dieses kurze und knappe Dokument sollte die Softwareentwicklung für immer beeinflussen. In den zwei Jahrzehnten, die seit der Entstehung vergangen sind, haben unzähligen Einzelpersonen, Teams und Unternehmen (in unterschiedlichem Maße) diese Worte bzw. die nachfolgenden 4 Kernaussagen und 12 Prinzipien übernommen.

Die 4 Kernaussagen

„Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan„

Folglich

Individuen und Interaktionen stehen über Prozessen und Werkzeugen

Funktionierende Software steht über umfassender Dokumentation

Zusammenarbeit mit dem Kunden steht über der Vertragsverhandlung

Eingehen auf Veränderung steht über dem Befolgen eines Plans

Die 12 Prinzipien:

„Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.„

Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Lieferung von wertvoller Software zufrieden zu stellen.

„Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.„

Anforderungsänderungen sind auch spät in der Entwicklung willkommen. Agile Prozesse machen Veränderungen für den Wettbewerbsvorteil des Kunden nutzbar.

„Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.„

Liefern Sie regelmäßig, alle paar Wochen bis alle paar Monate, funktionierende Software, wobei ein kürzerer Zeitrahmen bevorzugt wird.

„Business people and developers must work together daily throughout the project.„

Geschäftsleute (Fachleute) und Entwickler müssen während des gesamten Projekts täglich zusammenarbeiten.

„Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.„

Bauen Sie Projekte um motivierte Einzelpersonen herum auf. Geben Sie ihnen das Umfeld und die Unterstützung, die sie brauchen, und vertrauen Sie darauf, dass die Arbeit erledigt wird.

„The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.„

Die effizienteste und effektivste Methode der Vermittlung von Informationen an und innerhalb eines Entwicklungsteams ist ein Gespräch von Angesicht zu Angesicht.

„Working software is the primary measure of progress.„

Funktionierende Software ist der primäre Maßstab für den Fortschritt.

„Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.„

Agile Prozesse fördern die nachhaltige Entwicklung. Sponsoren, Entwickler und Benutzer sollten in der Lage sein, auf unbestimmte Zeit ein konstantes Tempo beizubehalten.

„Continuous attention to technical excellence and good design enhances agility.„

Kontinuierliche Aufmerksamkeit für technische Exzellenz und gutes Design erhöht die Agilität.

„Simplicity–the art of maximizing the amount of work not done–is essential.„

Einfachheit – die Kunst, die Menge nicht-getaner Arbeit zu maximieren – ist essenziell.

„The best architectures, requirements, and designs emerge from self-organizing teams.„

Die besten Architekturen, Anforderungen und Designs gehen aus sich selbst organisierenden Teams hervor.

„At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.„

In regelmäßigen Abständen reflektiert das Team darüber, wie es effektiver werden kann und passt sein Verhalten entsprechend an.

Und das war’s. Seitdem hat sich die Website des Agilen Manifests, wenn überhaupt, nur minimal verändert. Aber die Welt rund um Agile könnte nicht unterschiedlicher sein.

Die große Debatte

Den Snowbird 17 ist es gelungen, ihre unterschiedlichen Standpunkte unter einigen wenigen Kernpunkten zu vereinen. Doch damit war die Debatte noch nicht beendet. In gewisser Weise hat sich Agile in viel mehr Arbeitsweisen aufgesplittert, als die Visionäre es ursprünglich geplant hatten bzw. erahnen konnten. Es scheint, als ob jeder seine eigene Sichtweise von dem Begriff „Agile“ hat und so auch an der eigenen Suppe kocht.

Heute gibt es SAFe und LeSS. Anwendungen von Agile, die nichts mit Softwareentwicklung zu tun haben, auch wenn es im Manifest zu Beginn heißt: „Wir entdecken bessere Wege, Software zu entwickeln, indem wir es tun und anderen helfen, es zu tun“.

Grundsätzlich kann man sagen, dass Zwei Fragen unmittelbar zusammengehören. Die eine richtet sich auf die Wahl des passenden Frameworks als Tool. Die andere auf die Entwicklung der agilen Kultur im Unternehmen. Beides lässt sich nicht getrennt voneinander betrachten.

Darum sollte man sich gleich zu Beginn die Fragen stellen: Was erwartet man? Was soll am Ende des Tages als Ergebnis stehen? Das Skalierungs-Framework selbst ist letztendlich nur ein methodisches Stützrad, um Organisationen Agilität beizubringen. Aber dazu in einem separaten Beitrag mehr.

Dave West, CEO von Scrum.org, der zu verschiedenen Organisationen reist, um agile Praktiken zu beobachten, nannte in einer Publikation ein Forschungsteam, dass agile Methoden einsetzt, um mit Hilfe von Viren ein Heilmittel für genetische Blindheit zu entwickeln.

In der Tat hat sich agiles Vorgehen außerhalb des Softwarebereichs durchgesetzt. Aber es ist nicht unbedingt das, was die Urheber des Manifests beabsichtigten.

Der agile Industriekomplex

Viele argumentieren, dass „Faux Agile“ und sein böser Zwilling „Dark Agile“, durch die Monetarisierung der agilen Ausbildung und Beratung, die gesamte Situation verschlimmern bzw. verschlimmert haben. Einige gehen sogar so weit, dass sie die Organisationen, die hinter dieser Monetarisierung stehen, als „The Agile Industrial Complex“ bezeichnen.

„Es gibt den agilen Cargo-Kult, bei dem man zwar die richtigen Dinge tut und sagt aber die grundlegenden Prinzipien nicht versteht bzw. schlichtweg nicht einhält. Ich selbst kann dies noch nicht so gut beurteilen, da ich noch nicht so viele agile Teams in Aktion gesehen habe, um eine global repräsentative Aussage zu treffen.

Man kann es nennen, wie man will. Ob „faux“, „dark“ oder „Cargo-Kult“, diese agilen Subversionen führen oft zu Situationen, die den Intentionen des Manifests zuwiderlaufen – Mikromanagement, Burnout-Rate, mangelnde Lieferfähigkeiten und das Festhalten an veralteten Prozessen bzw. Konzepten, statt an Prinzipien, sind die auffälligsten Beispiele. Selbst wenn man in dem Bereich ein Zertifikat erworben hat, führen Erfahrungen wie diese, die man in Zusammenhang mit agilen Methoden hatte, oft dazu, dass manche Menschen agilen Methoden ganz abschwören oder sie so umschreiben, dass sie ihre realen Erfahrungen damit widerspiegeln.

Ron Jeffries, einer der Snowbird 17, hat versucht, diesen Irrwegen mit folgender Einschränkung zu begegnen:

“Here and in other writings, I use the quoted word ‘Agile’ to refer to the many instances, approaches, and processes that use the word ‘agile’ to describe themselves, but that do not necessarily adhere to the letter or spirit of Agile Software Development we wrote about in the Agile Manifesto. I will sometimes refer to ‘Faux Agile’ for emphasis, or to ‘Dark Agile’, which I use to describe so-called ‘Agile’ approaches that have really gone bad. I might refer to ‘Manifesto Agile’ to mean the core ideas from the Manifesto, in which I still believe.”

„Hier und in anderen Schriften verwende ich das zitierte Wort ‚Agile‘, um mich auf die vielen Instanzen, Ansätze und Prozesse zu beziehen, die das Wort ‚Agile‘ verwenden, um sich selbst zu beschreiben, die aber nicht unbedingt den Buchstaben oder dem Geist der Agilen Softwareentwicklung entsprechen, über die wir im Agilen Manifest geschrieben haben. Ich beziehe mich manchmal auf „Faux Agile“, um dies zu betonen, oder auf „Dark Agile“, womit ich sogenannte „agile“ Ansätze beschreibe, die wirklich schlecht geworden sind. Mit ‚Manifest Agile‘ bezeichne ich die Kernideen des Manifests, an die ich immer noch glaube.“

Jetzt kann man sich natürlich die Frage stellen, ob das Agile Manifest angesichts der weiten und manchmal fehlgeleiteten Verbreitung von Agile immer noch ein Dokument darstellt, auf das man sich beziehen sollte oder ob es nicht schon obsolet ist.

Ist das Manifest noch relevant?

Nun, nachdem ich mich erst seit kurzer Zeit mit dieser Thematik auseinandersetze, mag meine Einschätzung nicht qualifiziert genug sein. Dennoch glaube ich, dass Zeit relativ ist. Und soweit es mir meine Recherchen und unzähligen Gespräche mit Mitstreitern sowie Entwicklerfreunden gestatten, bin ich davon überzeugt, ein recht gutes Bild von der Ist-Situation erhalten zu haben. Die Antwort lautet „Ja!“. Man kann sich meiner Meinung nach immer noch auf das Manifest beziehen!

Fazit

Die zwölf Prinzipien machen deutlich, dass die Anfänge des agilen Projektmanagements von einer Ablehnung traditionellen Projektmanagements mit intensiver Planung, Überwachung und Steuerung geprägt sind.

Das agile Manifest beinhaltet vier Werte und zwölf Prinzipien. Damit ist es keine Checkliste, die man befolgt und abhakt. Vielmehr gilt es, diese Werte und Prinzipien im Team zu etablieren und damit ein agiles Mindset zu entwickeln.

Damit lassen sich meiner Meinung nach komplexe Anwendungen sinnvoll und human, sowohl mit kleinen als auch großen Teams realisieren.

Der Beitrag Agile Manifest – Die bessere Art der Softwareentwicklung erschien zuerst auf CEOsBay.

Wie funktioniert SonarQube?

SonarQube besteht aus drei Komponenten

1. Einem Modul für Build-Management-Tools wie Apache Maven oder Apache Ant. (Hauptsächlich für die Analyse des Quelltextes hinsichtlich verschiedener Qualitätsmerkmale.)
2. Einer Datenbank, für Speicherung der Ergebnisse der Qualitätsanalyse.
3. Einer Website für die visuelle Darstellung, Auswertung und das Management der Qualitätsanalyse-Ergebnisse.

Durch diese Architektur kann man sowohl eine Prüfung des Quelltextes auf dem Entwicklungsrechner ermöglichen als auch eine Einbindung von SonarQube in den Entwicklungsprozess gewährleisten. Dies unterstützt die Ermittlung der Qualitätsmetriken auf einem Build-Server für die kontinuierliche Integration.

SonarQube analysiert den Quelltext hinsichtlich der Abdeckung durch Modultests, checkt den Quellcode nach doppeltem Code und in Bezug auf die Komplexität. Auch werden unter anderem potenzielle Fehler im Code, Kodier-Richtlinien als auch Kommentare überprüft.

Modularer Aufbau und Erweiterungen

SonarQube ist modular aufgebaut und integriert selbst einige bekannte Entwicklungswerkzeuge zur Analyse der Codequalität, darunter PMD und Checkstyle für die Erkennung von doppeltem Code für die Prüfung von Kodier-Richtlinien. Damit wird unter anderem auch nach ineffizientem Code gesuche. FindBugs dient beispielsweise zum Aufdecken potenzieller Fehler sowie Surefire und Cobertura zur Messung der Qualität der Modultests.

Diese Werkzeuge nutzen entsprechend ihrer Natur und Einsatzgebiete Metriken, um die jeweiligen Auswertungen bzw. Statistiken zu erzeugen. Der Name „Metrik“ trägt jedoch wenig Bedeutung von dem in sich, was eine Metrik ausmacht. Schlägt man nämlich nach woher der Name kommt, landet man im Lateinischen: „ars metrica„, die Lehre von den Maßen. Fragt man jedoch das Institute of Electrical and Electronics Engineers, was eine Softwaremetrik ist, erhält man folgende Antwort:

„software quality metric: A function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which software possesses a given attribute that affects its quality.“ „Eine Softwarequalitätsmetrik ist eine Funktion, die eine Software-Einheit in einen Zahlenwert abbildet, der als Erfüllungsgrad einer Qualitätseigenschaft der Software-Einheit interpretierbar ist.“ – IEEE Standard 1061, 1998

Folglich bedeutet dies, dass es sich bei einer Metrik am Ende des Tages um eine Funktion handelt, die für beliebige Eingaben Zahlen erzeugt. Die Beschaffenheit ist so, dass sie, nur so 

lange sie von derselben Funktion erzeugt wurden, vergleichbar sind. Dadurch kann man Rückschlüsse auf die Eingabe mit Hinblick auf die Funktion erzielen.

Ein Beispiel dafür ist die McCabe-Metrik, auch zyklomatische Komplexität genannt. Diese sehr grundlegende Metrik berechnet die Anzahl der unterschiedlichen Pfade durch ein Stück Code. Die Formel ist relativ einfach: Es wird die Anzahl an Kontrollstrukturen wie if, while, case und boolescher Operatoren wie && und || summiert und nochmals mit 1 addiert. Möchte man diese Information nochmals anhand eines Beispiels betrachten, sieht es folgendermaßen aus:

String nameDesWochenTags(int nr) {
  switch(nr) {
    case 1: return "Montag";
    case 2: return "Dienstag";
    case 3: return "Mittwoch";
    case 4: return "Donnerstag";
    case 5: return "Freitag";
    case 6: return "Samstag";
    case 7: return "Sonntag";
  }
  return "";
}

Diese relativ einfache Methode gibt den Namen eines Wochentages entsprechend seiner 1-indizierten Position innerhalb der Woche zurück. Ihre zyklomatische Komplexität beträgt 8. Zumal 1 + 7 x case. Dies ist ein verhältnismäßig hoher Wert. Ein Maximalwert von 10 gilt als allgemein akzeptiert und ausreichend erprobt. Um also die Komplexität dieser Methode zu verringern, findet eine Refaktorisierung statt, die folgendermaßen aussehen kann:

String nameDesWochenTags(int nr) {
  String[] names = new String[] {
    "Montag", "Dienstag", "Mittwoch",
    "Donnerstag", "Freitag", "Samstag",
    "Sonntag"
  };
  if(nr) > 0 && <= names.length) {
    return names[nr - 1];
  }
  return "";
}

Die zyklomatische Komplexität dieser Methode beträgt 3. Zumal 1 + 1 x if + 1 x &&. Durch den unterschiedlichen Ansatz kann man die Komplexität verringern. Dennoch ist es relativ unstrittig, dass die erste Version leichter zu verstehen ist.

Will man nun also alle Tools gemeinsam benutzen, muss man alle konfigurieren und ihre Ergebnisse zusammenführen, damit sich ein Gesamtbild darstellen lässt. Außerdem kommt es dabei zwangsweise zu Dopplungen in ausgewerteten Metriken oder anderen Kennzahlen. PMD beispielsweise besitzt durch seinen relativ vagen Aufgabenbereich Überschneidungen im Hinblick auf Codestil mit checkstyle, während es aber auch genauso wie FindBugs auf toten Code achtet. An solchen und weiteren Stellen kann SonarQube Verbesserungen herbeiführen.

Neben der visuellen Anzeige der Ergebnisse der einzelnen Bereiche, ermöglicht SonarQube das Drill-Down der Ergebnisse bis auf die einzelne Metrik und Codezeile sowie die Verknüpfung der einzelnen Metriken sowie die Darstellung ihrer historischen Entwicklung in einer recht übersichtlichen grafischen Oberfläche.

Über einen ausgeklügelten Plugin-Mechanismus ist eine relativ einfache Integration von Erweiterungen möglich. Neben den Erweiterungen für die Analyse zusätzlicher Programmiersprachen gibt es Plugins für ergänzende Metriken, Governance, Schnittstellen zu Entwicklungsumgebungen, Visualisierungen, Integration sowie zur Berechnung der technischen Schuld(en).

Fazit

Ich arbeite noch nicht so lange mit SonarQube. Um genau zu sein, habe ich es mir erst heute das erste Mal angeschaut. Zusammenfassend kann ich folgendes sagen:

Statistiken sind zwar interessant und es kann Spaß machen, sich diese anzuschauen, doch ist eine statische Codeanalyse erst dann wirklich vollständig, wenn ein Mindestmaß an Interpretation hineingeflossen ist.

Die Codeanalyse liefert ein gutes Gefühl für die Codebasis. Erst so kann man fundierte Aussagen darüber treffen, welche Bereiche des Projekts besonders gefährdet, instabil oder verbesserungsfähig sind.

Regelmäßige Analysen können die Teammotivation erhöhen. Eine positive Issuebilanz am Ende eines Sprints und aufwärtszeigende Historiengraphen sollten gute Treiber für eine Gruppe Entwickler und ein Beweis für die eigene Leistung sein.

Alles in allem sind Analyseergebnisse immer gut als Argumentationsgrundlage. Mit Hilfe der Projekthistorie, die eine Auswahl gut darstellbarer Kennzahlen beinhaltet, kann man vor Kunden oder Entscheidern besser über ein eventuell nötiges technisches Release diskutieren.

Der Beitrag SonarQube – Das Code-Qualitätsmanagement-Tool erschien zuerst auf CEOsBay.

Insbesondere trifft man auf JSON bei Webanwendungen und mobilen Apps in Verbindung mit JavaScript, Ajax oder WebSockets zum Übertragen von Daten zwischen dem Client und dem Server.

Serialisierung

Bei einer Abbildung von strukturierten Daten auf eine sequenzielle Darstellungsform, spricht man in der Informatik von einer Serialisierung. Die Serialisierung wird hauptsächlich für die Speicherung von Objekten in Dateien und für die Übertragung von Objekten über das Netzwerk bei verteilten Softwaresystemen verwendet.

Übliche Speichermedien sind nur in der Lage, Datenströme zu speichern. Serialisierung für die Persistenz von Objekten. Hier wird der komplette Zustand des Objektes, inklusive aller referenzierten Objekte, in einen Datenstrom umgewandelt, der anschließend auf ein Speichermedium geschrieben wird.

Nach der Serialisierung liegt ein Objekt mehrfach vor. Sowohl in der externen Darstellung, beispielsweise als Datei als auch im Arbeitsspeicher. Wird nach der Serialisierung eine Änderung am Objekt im Arbeitsspeicher vorgenommen, hat dieses keine Auswirkung auf das serialisierte Objekt in der externen Darstellung.

Die Umkehrung der Serialisierung, also die Umwandlung eines Datenstroms in Objekte, bezeichnet man als Deserialisierung.

In der Linguistik bezeichnet man mit Serialisierung die Art und Weise, wie hierarchische grammatikalische Strukturen in eine lineare Abfolge gebracht sind, damit sie in einer zeitlichen Abfolge sprachlicher Ausdrücke dargestellt werden kann. Diese Reihenfolge kann in verschiedenen Sprachen unterschiedlich sein.

Eine kurze Zeitreise

JSON entstand aus der Notwendigkeit heraus, ein zustandsloses (stateless) Echtzeit-Kommunikationsprotokoll zwischen Server und Browser zu haben, ohne Browser-PlugIns wie Flash oder Java-Applets zu verwenden, die sich Anfang der 2000er Jahre als vorherrschende Methoden, im Einsatz befanden.

Crockford spezifizierte und verbreitete als Erster das JSON-Format. Das Akronym stammt von State Software, ein von Crockford und anderen im März 2001 gegründetes Unternehmen. Die Gründer hatten sich geeinigt, ein System zu entwickeln, dass Standard-Browser-Funktionen nutzte und eine Abstraktionsschicht für Web-Entwickler bereitstellte, um zustandsbehaftete (abstraction layer) Web-Anwendungen zu erstellen, die über eine dauerhafte Duplex-Verbindung zu einem Web-Server verfügten. Sie hielten dafür zwei Hypertext Transfer Protocol (https)-Verbindungen offen und bauten die Verbindung wieder auf, bevor die Standard-Browser-Timeouts eintraten, wenn kein Datenaustausch stattfand. Die Gründer stimmten darüber ab, ob das Datenformat JSML (JavaScript Markup Language) oder JSON (JavaScript Object Notation) genannt und unter welcher Lizenz die Verfügungstellung stattfinden sollte. Die Website JSON.org ging dann im Jahr 2002 online. Im Dezember 2005 begann Yahoo! damit, die ersten Webdienste (Web-Services) in JSON anzubieten.

Vorgänger geht auf ein Spiel für Kinder

Ein Vorläufer der JSON-Bibliotheken wurde in einem Projekt für Kinder, einem digitalen Trading-Spiel namens Cartoon Orbit bei Communities.com (Die Gründer von State hatten alle zuvor bei diesem Unternehmen gearbeitet), für Cartoon Network verwendet, dass ein browserseitiges Plugin mit einem proprietären Nachrichtenformat zur Manipulation von DHTML-Elementen nutzte (Dieses System gehört übriges 3DO). Nach der Entdeckung der frühen Ajax-Fähigkeiten verwendeten digiGroups, Noosh und andere, Frames, um Informationen in das visuelle Feld des Browsers zu übertragen, ohne den visuellen Kontext einer Webanwendung aktualisieren zu müssen. So hatten sie Rich-Web-Anwendungen in Echtzeit erstellt, die nur die Standard https-, HTML– und JavaScript-Fähigkeiten von Netscape 4.0.5+ und IE 5+ verwendeten. Crockford fand darauf heraus, dass JavaScript als objektbasiertes Nachrichtenformat für ein solches System verwendet werden kann. Das System wurde später an Sun Microsystems, Amazon.com und EDS verkauft.

JSON basiert teilweise auf JavaScript und wird häufig auch mit JavaScript verwendet. Dennoch ist es ein sprachunabhängiges Datenformat. Code zum Parsen und Generieren von JSON-Daten ist in vielen Programmiersprachen leicht verfügbar. Auf der JSON-Website sind die JSON-Bibliotheken nach Sprachen geordnet.

Im Oktober 2013 veröffentlichte Ecma International die erste Ausgabe seines JSON-Standards ECMA-404. Im selben Jahr verwendete RFC 7158 ECMA-404 als Referenz. 2014 wurde RFC 7159 zur Hauptreferenz für die Verwendung von JSON im Internet und löste RFC 4627 sowie RFC 7158 ab (wobei ECMA-262 und ECMA-404 als Hauptreferenzen beibehalten wurden). Im November 2017 veröffentlichte ISO/IEC JTC 1/SC 22 ISO/IEC 21778:2017 als internationalen Standard. Am 13. Dezember 2017 hat die Internet Engineering Task Force RFC 7159 durch die Veröffentlichung von RFC 8259, der aktuellen Version des Internet-Standards STD 90, überholt (ersetzt).

Crockford fügte der JSON-Lizenz eine Klausel hinzu, die besagt, dass „die Software für das Gute, nicht für das Böse verwendet werden soll“, um die JSON-Bibliotheken zu öffnen und sich gleichzeitig über Unternehmensjuristen und diejenigen lustig zu machen, die übermäßig pedantisch sind. Ironischer- und lustigerweise führte diese Klausel zu Konflikten der JSON-Lizenz mit anderen Open-Source-Lizenzen, da Open-Source-Software und freie Software in der Regel keine Einschränkungen hinsichtlich des Verwendungszwecks implizieren.

Wie ist JSON aufgebaut?

Die Daten können beliebig verschachtelt werden, beispielsweise ist ein Array (indizierte Liste) von Objekten möglich, die wiederum Arrays oder Objekte enthalten. Als Zeichenkodierung benutzt JSON standardmäßig UTF-8. Auch UTF-16 und UTF-32 werden unterstützt.

JSON und die Typen von Elementen

• null = Nullwert (Wird durch das Schlüsselwort null dargestellt.)
• Boolean = Boolescher Wert (Wird durch die Schlüsselwörter true und false dargestellt. Dies sind keine Zeichenketten. Sie werden daher, wie null, nicht in Anführungszeichen gesetzt.
• Number = Zahl (Ist eine Folge der Ziffern 0–9. Diese Folge kann durch ein negatives Vorzeichen – eingeleitet und durch einen Dezimalpunkt . unterbrochen sein. Die Zahl kann durch die Angabe eines Exponenten e oder E ergänzt werden, dem ein optionales Vorzeichen + oder – und eine Folge der Ziffern 0–9 folgt.)
• String = Zeichenkette (Eine Folge von null oder mehr Unicode-Zeichen. Es beginnt und endet mit doppelten geraden Anführungszeichen („). Es kann Unicode-Zeichen und durch \ eingeleitete Escape-Sequenzen enthalten.
• Array = Anordnung (Beginnt mit [ und endet mit ]. Es enthält eine durch Kommata geteilte, indizierte Liste von Elementen gleichen oder verschiedenen Typen. Leere Arrays sind ebenfalls zulässig.
• Object = Objekt (Beginnt mit { und endet mit }. Es enthält eine durch Kommata geteilte, ungeordnete Liste von Eigenschaften. Objekte ohne Eigenschaften („leere Objekte“) sind ebenfalls zulässig. Das Objekt besteht aus einem Schlüssel und einem Wert, getrennt durch einen Doppelpunkt (Schlüssel : Wert). Die Schlüssel sollten eindeutig sein, da unterschiedliche Parser mit mehrfach vorkommenden Schlüsseln unterschiedlich umgehen. Während ECMA-404 keine Eindeutigkeit voraussetzt, fordert RFC 7159, dass Schlüssel innerhalb eines Objekts eindeutig sind. Folglich ist der Schlüssel eine Zeichenkette und der Wert ein beliebiges Element.

Nicht signifikante Leerraum-Zeichen sind erlaubt, also Leerzeichen (Unicode U+0020), horizontale Tabs (U+0009), Zeilenumbrüche mittels LF und / oder CR (U+000D und U+000A). Diese Zeichen werden außerhalb von Zeichenketten bei der Interpretation ignoriert.

Die Grenzen von JSON

JSON unterstützt nicht alle von JavaScript unterstützten Datentypen. Bei nicht unterstützten Datentypen wird folgendermaßen serialisiert:

• NaN, Infinity und -Infinity werden zu null serialisiert.
• Date-Objekte werden in eine Zeichenkette konvertiert, die einer Datumsformatbeschreibung nach ISO-8601 genügt.
• Function-, RegExp- und Error-Objekte werden verworfen.

Das folgende Beispiel zeigt eine mögliche JSON-Darstellung zur Beschreibung meiner Person.

{
  "Unternehmen": "COEZBAY",
  "Nummer": "2023-23-23-777",
  "Waehrung": "BTC",
  "Inhaber": "CEO"
  {
    "Name": "Oezbay",
    "Vorname": "Cagatay",
    "maennlich": true,
    "Hobbys": ["IT", "Schach", "Basketball"],
    "Alter": 38,
    "Kinder": [],
    "Partner": null
  }
}

Das JSON-Schema

Das JSON-Schema gibt ein JSON-basiertes Format an, um die Struktur von JSON-Daten für die Validierung, Dokumentation und Interaktionssteuerung zu definieren. Es enthält einen Contract für die JSON-Daten, die für eine bestimmte Anwendung erforderlich sind und wie diese Daten geändert werden können.

Das Schema basiert auf den Konzepten des XML-Schemas, ist jedoch JSON-basiert. Wie in XSD (XML Schema Definition) können dieselben Serialisierungs- und Deserialisierungsprogramme sowohl für das Schema als auch für die Daten verwendet werden. Es ist selbstbeschreibend und in einem Internet-Entwurf der Internet Engineering Task Force festgelegt. Für verschiedene Programmiersprachen stehen mehrere Validatoren mit jeweils unterschiedlichen Konformitätsstufen zur Verfügung.

Der Vergleich mit XML

Sowohl JSON als auch XML beschreiben die Struktur eines Datensatzes. Der Datensatz kann weitere Datensätze enthalten. Dadurch sind beliebig tief verschachtelte Strukturen möglich.

In XML sind die einzelnen Knoten der Datenstruktur benannt, während die Knoten in JSON unbenannt bleiben.

Einfache Zeichenketten in XML können sowohl als Attribut eines Elements als auch als eigenständiges Element beschrieben sein. In JSON gibt es diese Unterscheidung nicht. Diese in den meisten Fällen irrelevante Flexibilität führt dazu, dass sich die Struktur von XML-Dokumenten häufig unnötigerweise unterscheidet.

Sowohl für JSON als auch für XML gibt es Beschreibungssprachen, um weiter einzugrenzen, wie „gültige“ Dokumente auszusehen haben. Ganz im Gegensatz zu „wohlgeformten“ Dokumenten.

Die Syntax von JSON ist einfacher gestaltet und erscheint daher oft lesbarer und insbesondere leichter schreibbar. In der Regel produziert JSON auch einen geringeren Overhead im Vergleich zu XML.

Sowohl JSON als auch XML müssen von einem speziellen Parser eingelesen werden. Traditionell ist jedes wohlgeformte JSON-Dokument ein gültiger JavaScript-Ausdruck. Das unaufmerksame Interpretieren von JSON-Dokumenten mit eval() führt jedoch zu Sicherheitslücken, die nicht zu unterschätzen sind.

Sowohl JSON als auch XML sind nicht gut zum Repräsentieren von Binärdaten geeignet, da beide Datenformate als Grundelement zeichenbasiert sind und nicht bytebasiert.

Der Beitrag JSON – Schönheit der einfachen Datenübertragung erschien zuerst auf CEOsBay.

Wer hat es erfunden?

Entwickelt hat es Dapper Labs, einem in Kanada ansässigen Unternehmen, dass im Jahr 2018 gegründet wurde. Das Unternehmen ist ein Pionier in der Entwicklung von Blockchain-Technologien und hat sich auf die Erstellung von dezentralen Anwendungen (DApps) spezialisiert. Unter anderem ist es besonders bekannt für die Entwicklung von CryptoKitties, einer der ersten Anwendungen auf der Ethereum–Blockchain, die die Verwendung von Non-Fungible Tokens (NFTs) populär machte.

Dapper Labs hat sich auch als Vorreiter in der Entwicklung von Blockchain-Technologien im Bereich des Sports etabliert. Das Unternehmen hat Partnerschaften mit der National Basketball Association (NBA) und der Union Cycliste Internationale (UCI) geschlossen, um NFTs und andere dezentrale Anwendungen im Sport zu fördern. Das Unternehmen arbeitet auch mit verschiedenen Künstlern und Unterhaltungsunternehmen zusammen, um innovative Anwendungen auf der Blockchain zu erstellen.

Insgesamt hat Dapper Labs eine führende Rolle bei der Entwicklung von Blockchain-Technologien und der Erstellung von Anwendungen auf der Blockchain übernommen. Das Unternehmen hat eine breite Palette von Anwendungen entwickelt, die auf verschiedenen Blockchain-Plattformen wie Ethereum und Flow laufen. Es hat auch Partnerschaften mit verschiedenen Branchen und Institutionen geschlossen, um die Akzeptanz und Verbreitung von Blockchain-Technologien zu fördern.

Wie funktioniert Flow?

Flow verwendet ein einzigartiges Modell, das darauf abzielt, die Skalierbarkeit von Anwendungen auf der Blockchain zu verbessern. Es verwendet eine Architektur, die man als „Layer-1“ bezeichnet, um die Geschwindigkeit und Leistung von Anwendungen zu verbessern. Dies erreicht man durch die Verwendung eines neuen Konsensmechanismus, den man als „Proof of Stake“ bezeichnet. Proof of Stake (PoS) ist ein alternatives Konsensmodell, dass man anstelle von Proof of Work (PoW) verwendet.

Man hat die Flow-Plattform speziell für die Erstellung von Non-Fungible Tokens (NFTs) entwickelt, die in der Blockchain-Industrie immer mehr an Beliebtheit gewinnen. NFTs sind digitale Assets, auf der Blockchain und einzigartig sind. Man verwendet sie in der Regel für digitale Kunstwerke, Musikstücke, Videos und andere digitale Inhalte bzw. Assets.

Die Flow-Plattform hat eine Reihe von Funktionen, die sie von anderen Blockchain-Plattformen unterscheiden. Es ist benutzerfreundlich, skalierbar und verhältnismäßig sicher. Die Plattform verwendet auch ein Modell für die Verwaltung von Transaktionsgebühren, die man als „Gasgebühren“ bezeichnet. Gasgebühren sind ein Mechanismus, die man dazu verwendet, um die Verarbeitung von Transaktionen auf der Blockchain zu priorisieren.

Fazit

Insgesamt ist Flow eine vielversprechende Plattform für die Erstellung von Anwendungen auf der Blockchain. Es bietet Entwicklern eine benutzerfreundliche Umgebung, die auf die Erstellung von Non-Fungible Tokens spezialisiert ist. Mit der Skalierbarkeit, Sicherheit und Leistung von Flow können Entwickler Anwendungen erstellen, die in der Lage sind, auf der Blockchain zu wachsen und zu gedeihen.

Der Beitrag Flow – Anwendungen einfach auf die Blockchain erschien zuerst auf CEOsBay.

Das Modell von React verspricht durch die Konzepte des unidirektionalen Datenflusses und des Virtual DOM den einfachen, aber trotzdem performanten Aufbau komplexer Anwendungen. React bildet aus diesem Grund die Basis für Single-Page-Webanwendungen, kann jedoch auch mit Node.js serverseitig (vor-)gerendert werden.

Ja, im Jahr 2013 war dies schon etwas ziemlich Gutes. Vor allem im Vergleich zum damaligen Angular, dass zwar komfortabel zu benutzen war aber aufgrund einer mäßigen Performance und der fehlenden Skalierbarkeit kaum in der Lage war, komplexe UIs abzubilden. Genau diese Probleme hat React damals bereits adressiert und führte zu diesem Zweck verschiedene Konzepte aus der funktionalen Programmierung in die UI-Welt ein.

Kurze Zeitreise

React ist die Entwicklung von Jordan Walke, einem Softwareentwickler bei Facebook. Erstmals 2011 für den Facebooks Newsfeed und später für Instagram eingesetzt. Facebook kündigte 2013 an, dass die Weiterführung des Projekts zukünftig als Open-Source stattfindet. Im Oktober 2014 wurde die Lizenz von der anfangs Apache-Lizenz auf die BSD-Lizenz mit zusätzlicher Patentlizenz geändert, welche den Widerruf der Lizenz bei Klagen gegen oder bei Patentstreitigkeiten mit Facebook vorbehält.

Diese unkonventionelle Klausel führte zu einer kontroversen Diskussion. Eine Umformulierung dieser Patentklausel im April 2015 beendete die Auseinandersetzung nicht. Im Juli 2017 kündigte die Apache Software Foundation an, keine Apache-Projekte mehr mit dieser Zusatzlizenz zu erlauben. Entgegen anfänglichen Angaben, nicht von der Klausel abrücken zu wollen, veröffentlichte Facebook im September 2017 React in der Version 16.0.0 unter der MIT-Lizenz. Vielleicht werde ich in der Zukunft noch die verschiedenen Lizenzmodelle etwas näher erläutern.

Fazit

Wie bereits erwähnt, ist es eine sehr spezialisierte und leichtgewichtige Programmbibliothek, sodass man es als einen Baustein von vielen betrachten kann. Da man React zwingend mit anderen Modulen kombinieren muss, um eine vollständige Anwendung zu entwickeln, kann React nicht zu einer systemrelevanten Größe heranwachsen. Gleichzeitig bildet diese Tatsache auch den Nachteil. Bei Angular hat man beispielsweise weniger Aufwand. Doch über Angular werde ich noch später schreiben.

Nicht zu vergessen ist die Integration mit JavaScript. Anders als zum Beispiel in Vue.js oder Angular gibt es in React keinen proprietären Weg, um eine Schleife, eine Bedingung oder eine Datenbindung herzustellen. Stattdessen verwendet React hierfür schlichtweg die Konstrukte, die es in JavaScript ohnehin gibt. Alles in allem ist es eine gute Lösung, mit einer eigenen Philosophie und einer relativ hohen Einstiegshürde, da man sich mit JSX auseinandersetzen muss. Ja, auch ich werde mich in einem zukünftigen Beitrag damit auseinandersetzen 🙂 Aber Einstiegshürden sind ja in der Regel relativ und es lässt sich darüber diskutieren, ob der Einstieg nun leicht oder schwer ist 😉

Der Beitrag React – Die Bibliothek für eine dynamische und interaktive Benutzeroberfläche erschien zuerst auf CEOsBay.