Was ist VGG?

Die Visual Geometry Group der Universität Oxford entwickelte das VGG-Netzwerk, ein tiefes Convolutional Neural Network, dass 2014 von K. Simonyan und A. Zisserman in ihrer Arbeit „Very Deep Convolutional Networks for Large-Scale Image Recognition“ vorgestellt wurde. Die Architektur wurde speziell für die Herausforderung der Bildklassifikation entworfen und erzielte beeindruckende Ergebnisse im ImageNet-Wettbewerb, einem der renommiertesten Tests für Bildverarbeitungssysteme. Siehe auch meinen Beitrag „Überwachtes Lernen bei Künstlicher Intelligenz„.

Die Struktur basiert auf der Verwendung kleiner 3×3-Faltungskerne. Diese Kerne kombinieren sich in mehreren aufeinanderfolgenden Schichten, um tiefe Netzwerke zu bilden. Das reduziert die Komplexität, während eine hohe Modellkapazität gewahrt bleibt.

Die Architektur von VGG

Die Architektur gibt es in verschiedenen Varianten, die sich durch die Anzahl der Schichten unterscheiden, wie VGG-11, -16 und -19. Die Zahl hinter dem Namen entspricht den gewichtstragenden Schichten. VGG-16, beispielsweise, verfügt über 16 gewichtstragende Schichten, die sich aus Convolutional- und Fully-Connected-Layern zusammensetzen.

Einige Schüsselpunkte der Architektur:

1. Tiefere Netzwerke: Im Vergleich zu früheren Modellen wie AlexNet repräsentiert VGG durch seine tiefere Struktur Bildmerkmale genauer.
2. Kleine Faltungskerne: Mit 3×3-Faltungskernen erfasst es Details effektiv und erreicht eine feine Granularität.
3. Max-Pooling-Schichten: Diese Schichten reduzieren die Dimensionen der Merkmalskarten und sorgen für Translation Invariance.

Die symmetrische und elegante Modellarchitektur macht es zu einer beliebten Wahl für Forschung und Lehre.

Warum ist VGG so bedeutsam?

Es beeinflusste die Entwicklung der KI auf vielfältige Weise:

1. Benchmark-Leistung: Beim ImageNet Large Scale Visual Recognition Challenge (ILSVRC) 2014 erzielte es bahnbrechende Ergebnisse hinsichtlich der Genauigkeit und belegte den zweiten Platz in der Bildklassifikation.
2. Einfluss auf moderne Architekturen: Spätere CNN-Modelle wie ResNet und DenseNet bauten auf Konzepten auf, die VGG eingeführt hatte. Insbesondere die Verwendung kleiner Faltungskerne wurde zum Standard.
3. Vielfältige Anwendungen: Es findet nicht nur in der Bildklassifikation Anwendung, sondern auch in Bereichen wie Objektsegmentierung, Transfer Learning und medizinischer Bildverarbeitung.

Herausforderungen und Grenzen

Obwohl es viele Stärken besitzt, gibt es auch Schwächen:

• Rechenintensiv: Die Tiefe und die hohe Anzahl der Parameter machen VGG rechen- und speicherintensiv.
• Overfitting: Ohne geeignete Regularisierung neigt es bei kleineren Datensätzen zu Overfitting.
• Effizienz: Neuere Architekturen wie ResNet arbeiten effizienter und benötigen weniger Rechenressourcen, wodurch VGG im Vergleich veraltet erscheint.

Fazit

Moderne Architekturen werden zwar häufiger verwendet, doch bleibt VGG ein bedeutender Meilenstein in der Geschichte der KI. Es ebnete den Weg für tiefere und leistungsfähigere Netzwerke und bildet nach wie vor eine Grundlage für das Verständnis von Convolutional Neural Networks. Forschende und Praktiker profitieren von diesem wichtigen Schritt in der Evolution der KI.

Die Einfachheit und Effizienz von VGG inspirierte viele der heutigen Fortschritte und erinnert daran, dass Durchbrüche in der KI oft das Ergebnis klarer und durchdachter Innovationen sind.

Der Beitrag VGG – Meilenstein in der Entwicklung der Künstlichen Intelligenz erschien zuerst auf CEOsBay.

Die Entstehung der CPU

Die Geschichte beginnt in den 1960er Jahren. Integrierte Schaltungen ersetzten immer mehr die älteren Vakuumröhren und Transistoren, die man früher für Rechenoperationen genutzt hat. 1971 präsentierte Intel dann den 4004, den ersten kommerziell erhältlichen Mikroprozessor. Mit der Vorstellung dieses bahnbrechenden Produkts begann eine Ära, die die Computertechnologie für immer verändern sollte.

Die Architektur der CPU

Eine CPU besteht aus Millionen von Transistoren, die elektrische Signale verarbeiten. Dies ermöglicht ihr, Anweisungen auszuführen, die in Form von Maschinencode vorliegen. Das Kernstück bildet der ALU (Arithmetic Logic Unit), der für arithmetische und logische Operationen verantwortlich ist. Moderne CPUs verfügen zudem über mehrere Kerne, die es ihnen ermöglichen, mehrere Aufgaben gleichzeitig zu bewältigen.

Die richtige Auswahl und der korrekte Einbau

Bei der Auswahl einer CPU spielen viele Faktoren eine Rolle:

1. Geschwindigkeit und Performance: Der Takt, oft in Gigahertz (GHz) angegeben, zeigt an, wie viele Operationen sie pro Sekunde ausführen kann.
2. Kerne: Mehrere Kerne bedeuten, dass sie mehrere Aufgaben gleichzeitig bearbeiten kann.
3. Energieverbrauch: Für mobile Geräte sind stromsparende CPUs besonders wichtig.

Wenn die passende CPU ausgewählt ist, geht es um den Einbau. Dabei sollte man vorsichtig vorgehen, um Beschädigungen zu vermeiden. Nach dem Einsetzen auf das Mainboard kommt etwas Wärmeleitpaste auf die CPU und im Anschluss befestigt man dann den Kühlkörper darauf, um eine Überhitzung zu verhindern.

Optimierung und Hinweise

1. Kühlung: Für eine optimale Leistung ist es wichtig, die CPU gut zu kühlen. Hier eignen sich sowohl Luft- als auch Wasserkühlungssysteme. Es gibt auch andere kreative Ansätze, wie den Rechner in ein Ölbad zu setzen, doch derartige Praktiken thematisiere ich hier nicht 🙂
2. Updates: Software- und Firmware-Updates können die Performance verbessern. Daher sollte man regelmäßig nach Updates suchen.
3. Übertakten: Erfahrene Nutzer können versuchen, ihre CPU zu übertakten, um mehr Leistung herauszuholen. Dies birgt jedoch Risiken und sollte mit Vorsicht durchgeführt werden.

Fazit

Die CPU bildet das Herz eines jeden Computers. Ihre Entwicklung hat die Technologiewelt revolutioniert und ermöglicht heute eine Vielzahl von Anwendungen. Bei der Auswahl und dem Einbau sollte man sorgfältig vorgehen und stets auf eine optimale Kühlung achten, um das Beste aus dieser wunderbaren Technologie herauszuholen. An dieser Stelle möchte ich auch gerne auf den Beitrag über die GPU hinweisen.

Der Beitrag CPU – Geschichte, Aufbau und Optimierung erschien zuerst auf CEOsBay.

Entstehung

Obwohl das Konzept der Softwarearchitektur so alt ist wie die Softwareentwicklung selbst, gewann der Begriff „Softwarearchitektur“ erst in den späten 1980er Jahren an Bedeutung. Der Credit für die Etablierung dieses Konzepts geht an Computerwissenschaftler wie David Parnas, Mary Shaw und Fred Brooks, die erkannten, dass eine strukturierte Herangehensweise an die Softwareentwicklung notwendig ist, um komplexe Systeme zu verwalten.

Die Forscher bemerkten, dass die steigende Komplexität von Softwareprojekten eine genaue Planung und Organisation erfordert. Damit begann das Zeitalter der Softwarearchitektur, in dem die Gestaltung eines Systems genauso wichtig wurde wie die Implementierung des Codes selbst.

Was ist Softwarearchitektur?

Softwarearchitektur bezeichnet die Struktur eines Softwaresystems, das seine Elemente, die Eigenschaften dieser Elemente und die Beziehungen zwischen ihnen umfasst. Sie bietet einen Plan, der die Arbeitsweise des Systems und die Kommunikation zwischen seinen verschiedenen Teilen definiert. Die Softwarearchitektur legt auch die Regeln und Vorgaben für die Softwareentwicklung und -wartung fest, um sicherzustellen, dass das Endprodukt den Anforderungen entspricht.

Umsetzung

Die Implementierung folgt einer systematischen Methode. Sie beginnt mit der Anforderungsanalyse, in der die funktionalen und nicht-funktionalen Anforderungen des Systems definiert werden. Anschließend wird das Systemdesign erstellt, das die Hauptkomponenten des Systems und ihre Interaktionen definiert. Dieses Design dient als Blaupause für die Entwicklungs- und Wartungsphase.

Es ist wichtig zu beachten, dass die Architektur flexibel genug sein muss, um Änderungen zu ermöglichen, da die Anforderungen oft variieren können. Daher sind iterative Entwicklungsansätze wie Agile (Siehe Agile Manifest) und (DevOps) oft geeignet für die Implementierung der Softwarearchitektur.

Wichtige Punkte bei der Umsetzung der Softwarearchitektur

Die Umsetzung der Softwarearchitektur erfordert sowohl technische als auch organisatorische Kompetenzen. Hier sind einige Punkte, die zu berücksichtigen sind:

• Verständnis der Geschäftsziele: Die Architektur sollte auf den Geschäftszielen und Anforderungen basieren und nicht nur auf technologischen Überlegungen.
• Verwendung von Design Patterns: Design Patterns sind bewährte Lösungen für gemeinsame Designprobleme. Ihre Verwendung kann die Entwicklungszeit verkürzen und die Qualität des Endprodukts verbessern.
• Dokumentation: Eine gut dokumentierte Architektur erleichtert die Kommunikation innerhalb des Entwicklungsteams und die Wartung des Systems. Auch fällt es den Entwicklern durch eine gute Dokumentation leichter, sich in den verschiedenen Komponenten zurechtzufinden.
• Berücksichtigung von Nicht-Funktionalen Anforderungen: Neben den funktionalen Anforderungen sind auch Nicht-Funktionale Anforderungen wie Sicherheit, Leistung und Skalierbarkeit entscheidend. (Siehe in diesem Zusammenhang auch „Nicht funktionale Tests„)

Fazit

Die Softwarearchitektur spielt eine entscheidende Rolle in der Softwareentwicklung. Sie bietet einen strukturierten Ansatz, um komplexe Systeme zu verwalten und zu warten. Durch die Berücksichtigung der oben genannten Punkte können Entwickler eine effektive und effiziente Architektur erstellen, die den Anforderungen gerecht wird und die langfristige Wartung des Systems erleichtert.

Der Beitrag Softwarearchitektur – Entstehung, Bedeutung und Best Practices erschien zuerst auf CEOsBay.

Es beschreibt unter anderem eines der wichtigsten REST-Eigenschaften. Da der Architekturstil eine universelle Schnittstelle bieten soll, fordert HATEOAS, dass der REST-Client sich ausschließlich durch das Folgen von URIs (Uniform Resource Identifier) im Hypermedia-Format durch die Webanwendung bewegen kann. Wird dieses Prinzip umgesetzt, benötigt der Client abgesehen von einem grundsätzlichen Verständnis von Hypermedia. Keinerlei weitere Informationen, um mit der Anwendung bzw. dem Server zu kommunizieren.

Die Bereitstellung der einzelnen URIs erfolgt dabei beispielsweise in Form von href- und src-Attributen. Vorausgesetzt es handelt sich um HTML-Dokumente oder -Snippets. Auch durch JSON– bzw. XML-Attribute/-Elemente, die der jeweilige Client automatisch erkennt.

Durch die Umsetzung des HATEOAS-Prinzips lässt sich die Schnittstelle eines REST-Services jederzeit anpassen. Dies kann ein wichtiger Vorteil dieser Architektur gegenüber anderen Applikationsstrukturen sein. Vor allem im direkten Vergleich mit Anwendungen, die man auf Grundlage von SOAP (Simple Object Access Protocol) ausführt.

Das HATEOAS-Konzept ist wichtig, weil es die Flexibilität und Skalierbarkeit von RESTful APIs verbessert. Ohne HATEOAS müsste ein Client spezifische URLs und Endpunkte kennen, um eine Anwendung effektiv zu nutzen. Dies kann jedoch kritisch sein, da URLs sich in der Regel ändern können. Diese Tatsache kann jedoch eben auch zu Fehlern und fehlerhaften Anfragen führen.

Durch die Verwendung von Hypertext-Links wird ein Client in die Lage versetzt, den aktuellen Zustand der Anwendung zu verstehen und dynamisch zu navigieren. Wenn beispielsweise ein Client eine Anfrage an den Server sendet, um eine Liste von Benutzern abzurufen, könnte der Server eine Antwort zurückgeben, die Links zu den einzelnen Benutzerdetails enthält. Der Client kann dann den Link zu einem bestimmten Benutzer folgen, um weitere Informationen abzurufen.

Ein Beispiel ist eine Bestellungsverwaltung in einem Online-Shop. Wenn ein Kunde eine Bestellung aufgeben möchte, kann der Server eine Antwort zurückgeben. Die enthalten wiederum Links zu den verschiedenen Schritten des Bestellvorgangs. Um beispielsweise den Warenkorb anzuzeigen, die Versandadresse anzugeben, Zahlungsinformationen anzugeben, etc. Der Client kann dann den Link zum nächsten Schritt folgen, ohne spezifische URLs oder Endpunkte zu kennen.

HATEOAS ist jedoch nicht nur für die Navigation innerhalb einer Anwendung wichtig. Es ermöglicht auch eine einfache Integration mit anderen Anwendungen und Diensten. Wenn eine API beispielsweise HATEOAS-konform ist, kann man sie von anderen Anwendungen oder Diensten aus leichter nutzen, da sie den Zustand der Anwendung und die verfügbaren Aktionen verstehen können.

Fazit

Insgesamt verbessert das HATEOAS-Konzept die Flexibilität und Skalierbarkeit von RESTful APIs, indem es Clients in die Lage versetzt, dynamisch zu navigieren und den aktuellen Zustand der Anwendung zu verstehen. Durch die Verwendung von Hypertext-Links werden Anwendungen leichter integrierbar und besser wartbar. Wenn man also eine RESTful API entwirft, sollte man in Betracht ziehen, HATEOAS zu verwenden, um die Nutzbarkeit und die Flexibilität der Anwendung zu optimieren.

Der Beitrag HATEOAS – Evolution von REST für selbsterklärende APIs und zukunftssichere Web-Anwendungen 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.

Seit 2009 ist es ein Open-Source-Projekt, dass auf gute Testbarkeit ausgelegt ist (An dieser Stelle möchte ich auf den Test Driven Development Beitrag verweisen 😉 ). Dies bietet ein MVC/MVVM-Framework, welches bidirektionales Databinding unterstützt.

MVC/MVVM?

MVVM teilt die verschiedenen Komponenten des Entwicklungsprozesses in drei Kategorien auf. Model, View und ViewModel. In der Regel handelt es sich dabei um Code-Markup oder grafische Benutzeroberflächen (GUI). MVC (Model-View-Control) ist eine Methode, mit der Entwickler Programme in diese drei Komponenten aufteilen. Auf diese Weise lassen sich geschäftliche Anforderungen und Regeln von der Art und Weise unterscheiden, wie Benutzer mit der Anwendung arbeiten. Gerne gehe ich in einem zukünftigen Beitrag näher darauf ein.

Unterschiede zwischen Angular und AngularJS

Angular ist wie bereits erwähnt der Nachfolger von AngularJS. Von Grund auf neu geschrieben, unterscheiden die beiden sich grundsätzlich und in vielerlei Hinsicht.

• Angular kennt keine „scopes“ oder Controller, sondern verwendet eine Hierarchie von Komponenten als zentrales Architekturkonzept.
• Angular hat eine einfachere Syntax für Ausdrücke: Mit „[ ]“ werden Bindings für Eigenschaften und mit „( )“ werden Bindings für Events erzeugt.
• Mobile-First-Ansatz: Die Anforderungen von mobilen Plattformen haben besondere Priorität.
• Modularität: Module können Funktionalitäten auslagern, sodass Code leichtgewichtiger und schneller sein kann.
• Es liegt lediglich die Unterstützung moderner Browser vor, wodurch man weniger Workarounds wegen Browser-Kompatibilitätsproblemen benötigt.
• Angular empfiehlt die Verwendung von TypeScript. Es bietet Klassenbasierte objektorientierte Programmierung, Statische Typisierung und Generics.
• TypeScript ist eine Obermenge von ECMAScript 6 (ES6) und ist rückwärts kompatibel mit ECMAScript 5, damit JavaScript. Angular bietet somit auch die Vorzüge von ES6: (Lambdas, Iteratoren, for…of-Schleifen, Generatoren im Stil von Python, Reflexion)
• Verbesserte Dependency Injection: Bindings ermöglichen die Benennung von Abhängigkeiten.
• Directives dienen dem Zweck, dass Aussehen und Verhalten eines Tags dynamisch zu verändern.
• Dynamisches Laden ist möglich
• Asynchrone Kompilierung von Templates
• Einfacheres Routing
• Kontroller und $scope sind durch Komponenten und Directives ersetzt. Eine Komponente ist eine Directive mit einem Template.
• Reaktive Programmierung mit RxJS

Angular für konventionelle Websites?

Angular ist ideal für Websites mit dynamischem Inhalt, jedoch nicht für kleine Seiten mit statischem Inhalt geeignet. Die Implementierung von Angular erhöht in diesem Fall lediglich die Gesamtgröße des Projekts und folglich auch die Ladezeiten. Dies ist eines der Hauptgründe, warum man Angular nicht für Landing Pages und Websites mit statischem Inhalt verwenden sollte. Davon abgesehen ist Angular weit davon entfernt, SEO-freundlich zu sein. Und im Zeitalter von Search-Engine-Optimization gibt es weitaus bessere Alternativen, um dieses Ziel zu erreichen. Auch ist Angular keine gute Lösung für kurzfristige Projekte oder Start-ups mit begrenzten Ressourcen. Die Komplexität des Front-Ends kann in relativ kurzer Zeit immense Ausmaße annehmen und später schwer zu bändigen sein.

Das Hauptanwendungsgebiet von Angular bestand darin, Einzelseiten-Webanwendungen zu erstellen. Aus diesem Grund verfügt es über eine breite Palette von Werkzeugen für die SPA-Entwicklung. Darüber hinaus ist es eine ideale Technologie für Websites, bei denen sich der Inhalt auf der Grundlage des Nutzerverhaltens und der Präferenzen der Benutzer dynamisch anpasst. Dependency Injections stellen sicher, dass im Falle der Änderung einer Komponente andere Komponenten, die mit ihr in Zusammenhang stehen, automatisch mitgeändert werden.

Die 3 verschiedenen Ladetechniken

Bei der Arbeit mit Angular bieten sich 3 verschiedene Ladetechniken an. Diese sind das Eager Loading, Lazy Loading und Preloading, auf die ich nachfolgend eingehe.

Eager Loading (Eifriges Laden)

Der Abruf aller benötigten Daten möglichst wirksam und umgehend bzw. sofort. Hierzu gibt es im Grunde genommen nicht viel anzumerken. Die Technik ist zwar effizient, doch die Tatsache, dass man eventuell nur einen bestimmten Teil der Daten benötigt aber dennoch alle Daten lädt, kann sich schnell zu einem Nachteil entwickeln, wenn es sich um große Datenmengen handelt.

Lazy Loading (Langsames Laden)

Die am wenigsten eifrige bzw. nicht eifrige Ladetechnik. Wenn man faul ist, tut man so lange nichts, bis man es wirklich muss oder dazu gezwungen wird. Man stelle sich vor, dass die Anwendung drei Bereiche hat. Home, Admin und das Dashboard. Auf den Home-Bereich wird ständig zugegriffen, auf den Dashboard-Bereich die meiste Zeit. Der Admin-Bereich wird jedoch nur von einigen wenigen Nutzern verwendet. Folglich kann man die Admin-Route nach und nach laden. So lange niemand auf die Idee kommt, auf den Verwaltungsbereich der Anwendung zu klicken, wird der damit verbundene Code auch nicht ausgeführt bzw. nicht geladen.

Die Mehrheit der Nutzer lädt den Code für den Verwaltungsbereich schlichtweg nie. Wenn man also Lazy Loading verwendet, kann man grundsätzlich schneller auf die Anwendung zugreifen, da man nicht so viel Code vom Server laden muss. Dies hängt damit zusammen, dass das ORM-Werkzeug (Objekt-Relationales Mapping-Werkzeug) jeglichen Zugriff auf alle Objektreferenzen »abfangen« muss, um hier bei Bedarf die verbundenen Objekte nachladen zu können. Dieses Abfangen erfolgt durch die Verwendung bestimmter Klassen für Einzelreferenzen und Mengenklassen. Der Unterschied zwischen den ORM-Werkzeugen liegt darin, ob der Entwickler diese Klassen explizit im Code verwenden muss oder ob das ORM-Werkzeug diese beim Kompilieren oder zur Laufzeit austauscht.

Preloading (Vorladen)

Die „somewhere-in-between“ (Irgendwie Zwischendrin) Ladetechnik. Beim Preloading macht man im Grunde genommen dasselbe wie beim Lazy Loading, nur ein bisschen anders.

Anhand des Home, Dashboard und Admin Beispiels lässt sich dies folgendermaßen darstellen. Die Startseite braucht man immer. Also lädt man diese schnell bzw. eifrig. Der Admin-Bereich wird nur selten und nur von wenigen Benutzern benötigt, also kann man diesen erst einmal etwas vernachlässigen bzw. „lazy“ laden. Aber das Dashboard ist nicht das Erste, was ein Benutzer sieht, also kann es grundsätzlich erst einmal warten. Doch das Dashboard ist gleichzeitig etwas, dass die meisten der Benutzer irgendwann sehen möchten. Also sollte es zumindest dann zur Verfügung stehen, wenn das Laden des Home-Bereichs fertiggestellt ist. Nach jeder erfolgreichen Navigation sucht der Router in seiner Konfiguration nach einem nicht geladenen Modul, das er vorladen kann.

Der Home-Bereich wird erfolgreich geladen und unmittelbar danach wird der Dashboard-Bereich im Hintergrund geladen.

Welche Ladetechnik kann/soll ich nun verwenden?

Wie bei vielen Angelegenheiten in der IT kommt es hier auf den spezifischen Anwendungsfall und den zur Verfügung stehenden Ressourcen an. Wenn man nicht genau weiß, ob man die zusätzlichen Daten benötigt oder nicht, dann kann es ungünstig sein, sie direkt zu laden. Es kann aber auch ungünstig sein, sie später nachladen zu müssen. Entscheidend bei der Entscheidung ist die Wahrscheinlichkeit, ob und wann man die jeweiligen Daten für wen benötigt, um welche Datenmenge es sich handelt und ob man die Daten später einfach nachladen kann. Zu beachten ist, dass man ein automatisches Nachladen, nach einer Serialisierung, in der Regel nicht mehr initiieren kann.

Release-Frequenz

Angular Releases folgen dem Konzept des Semantic Versionings. Man unterscheidet zwischen Major-, Minor- und Bugfix-Releases. Alle 6 Monate gibt es eine neue Major Release. Major Releases enthalten signifikante neue Features, sind aber nicht abwärtskompatibel. Der Umstieg auf eine neuere Major Release benötigt daher oft Update-Scripts, Refactorings des bestehenden Codes, weitere Tests und das Erlernen neuer APIs. Zu jeder Major Release gibt es ein bis drei Minor Releases. Patch Releases und Pre-Releases gibt es fast jede Woche.

Support

Der Support von Major Releases beträgt typischerweise 18 Monate lang nach Release. Davon 6 Monate aktiv. Aus diesem Grund gibt es in regelmäßigen Abständen Minor Releases und Patch Releases. Es folgt ein 12-monatiger Long Term Support (LTS) in Form von Patch-Releases, ausschließlich zur Behebung kritischer und sicherheitsrelevanter Fehler.

Fazit

Bei der Verwendung von Angular sollte von vornherein klar sein, dass die Realisierung eines Projekts mit der Abnahme vieler Entscheidungen über Architektur und des Renderings verbunden ist. Dies hat den Vorteil, dass sich das Projektteam zu 100% auf die Umsetzung von Features konzentrieren kann und nicht die grundlegende Architektur eigenständig aufbauen muss.

Durch die sehr einheitliche Struktur von Angular Anwendungen lassen sich gute Entwickler sehr schnell in das Projekt integrieren, da Angular Anwendungen stets einer gewissen Struktur folgen. Dies vereinfacht die Skalierbarkeit des Teams als auch des Projektes selbst als vergleichsweise bei Individuallösungen der Architektur in anderen Frameworks.

Generell ist es für Enterprise Projekte sicherlich eine gute Wahl. Dennoch sollte man andere Frameworks wie React und VueJS nicht außer Acht lassen, über die ich in den kommenden Tagen schreibe.

Der Beitrag Angular – Entfaltung des vollen Potenzials von Webanwendungen erschien zuerst auf CEOsBay.

Im dynamischen Bereich der 3D-Modellierung und Animation ist Autodesk 3ds Max ein unverzichtbares Werkzeug für Profis und Einsteiger gleichermaßen. Ob es um die Gestaltung beeindruckender Spielwelten, realistischer Film-Szenen oder detaillierter Architektur-Visualisierungen geht, 3ds Max bietet eine umfangreiche Palette an Funktionen, die den kreativen Prozess unterstützen. Besonders hat mir damals gefallen, dass ich mit Koordinaten Objekte platzieren und manipulieren konnte. Dies ermöglichte mir einen raschen Einstieg in völlig neue und digitale Welten. Die aus meinem Gedankengut. Doch heute geht es eher um Fakten. Daher…

Umfangreiche Modellierungsfunktionen

Autodesk 3ds Max ermöglicht es, eine breite Palette von 3D-Modellen und Strukturen zu erstellen. Die Software bietet zahlreiche Modellierungswerkzeuge, darunter Mesh-, Patch- und NURBS-Modellierung sowie Modifikatoren, um Formen und Texturen präzise zu manipulieren. Mit diesen vielfältigen Möglichkeiten können Designer und Künstler komplizierte Modelle mit hoher Präzision erstellen und ihre kreativen Visionen verwirklichen.

Leistungsstarke Animationstools

Die Animation ist eines der Hauptmerkmale von 3ds Max. Die Software ermöglicht es Benutzern, Charaktere und Objekte zu animieren, indem sie Schlüsselrahmen, Skelett- und Rigging-Systeme verwenden. Mit der integrierten CAT- (Character Animation Toolkit) und Biped-Animationssystemen lassen sich komplexe Animationen intuitiv erstellen und bearbeiten. Zusätzlich bietet 3ds Max Werkzeuge für Partikelanimation, Flüssigkeiten, Stoffe und Haare, um realistische Effekte zu erzielen und 3D-Szenen Leben einzuhauchen.

Hochwertiges Rendering

3ds Max bietet eine beeindruckende Auswahl an Rendering-Optionen, um Projekte in sehr guter Qualität zu präsentieren. Die Integration von Arnold, einem leistungsstarken und vielseitigen Renderer, ermöglicht es, realistische Licht- und Schattenwirkungen zu erzielen. Darüber hinaus kann man auch Drittanbieter Render-Engines wie V-Ray, Corona Renderer und OctaneRender nutzen, um die bestmöglichen Ergebnisse für Projekte zu erzielen.

Umfangreiche Material- und Texturbibliotheken

Dank der großen Material- und Texturbibliotheken von 3ds Max kann man realistische Oberflächen und Effekte erstellen. Mit dem Slate Material Editor benutzerdefinierte Materialien erstellen, indem man Texturen und Schattierungseffekte kombiniert. Außerdem unterstützt die Software gängige Dateiformate wie HDR, EXR und Substance, um volle Flexibilität bei der Gestaltung der Texturen zu bieten. Substance Designer und Painter sind übrigens ebenfalls grandiose Programme, die ich ebenfalls sehr gerne verwende. Von dem her, in der Zukunft, auch einen Beitrag wert.

Erweiterbarkeit und Anpassungsfähigkeit von 3ds Max

3ds Max ist ein äußerst anpassungsfähiges Programm, das über eine große Anzahl von Plugins und Skripts verfügt, um Workflows zu erstellen und zu optimieren. Die Unterstützung von Maxscript, Python und C++ ermöglicht es, benutzerdefinierte Funktionen und Automatisierungen hinzuzufügen, um Projekte effizienter zu gestalten. Die Online-Community rund um 3ds Max ist sehr aktiv und bietet eine Vielzahl von Ressourcen, einschließlich Tutorials, Foren und Plugins, um das Programm an spezielle Anforderungen anzupassen.

Nahtlose Integration von 3ds Max mit anderen Programmen

Eine der Stärken von Autodesk 3ds Max ist seine nahtlose Integration in andere Anwendungen und Software-Ökosysteme. Die Software ermöglicht den Import und Export von Dateiformaten wie OBJ, FBX und Alembic, wodurch die Zusammenarbeit zwischen Designern, Künstlern und Entwicklern aus verschiedenen Bereichen sehr leicht zu bewerkstelligen ist. Darüber hinaus kann man es problemlos mit anderen Autodesk-Produkten wie Maya, AutoCAD und Revit verbinden, um einen reibungslosen Workflow über verschiedene Projekte hinweg zu gewährleisten.

Branchenweite Akzeptanz von 3ds Max

Autodesk 3ds Max ist in einer Vielzahl von Branchen weit verbreitet und anerkannt, darunter Architektur, Film, Videospiele, Fernsehen und mehr. Dank der vielseitigen Funktionen und benutzerfreundlichen Oberfläche haben viele Branchenführer das Programm als Standardwerkzeug für die 3D-Modellierung und Animation gewählt. Als Ergebnis eröffnen sich mit der Beherrschung des Programms vielfältige berufliche Möglichkeiten in verschiedenen kreativen Bereichen und ich war in allen tätig, die ich soeben erwähnt habe 😀

Fazit

Autodesk 3ds Max ist ein mächtiges und vielseitiges Programm, das sich ideal für 3D-Modellierung, Animation und Rendering eignet. Durch umfangreiche Funktionen, einer benutzerfreundlichen Oberfläche und branchenweite Akzeptanz ist es ein unverzichtbares Werkzeug für Künstler und Designer, die auf der Suche nach einem Programm sind, das ihre Kreativität fördert und unterstützt. Unabhängig vom Fachgebiet oder der persönlichen Erfahrungsstufe bietet 3ds Max die Möglichkeit, atemberaubende 3D-Visualisierungen und Animationen zu erstellen und bei der Verwirklichung kreativer Visionen zu helfen. Viele mögen behaupten, dass das Programm mit Altlasten zu kämpfen hat. Doch dies kann ich so nicht bestätigen. Ich arbeite nach wie vor in meiner Freizeit als auch im professionellen Umfeld sehr gerne damit, wenn es sich mal wieder anbietet. Ansonsten kommen natürlich auch Maya, Blender, sowie viele andere Anwendungen zum Einsatz. Je nachdem, was man benötigt.

Der Beitrag Autodesk 3ds Max – Kreativität entfesseln erschien zuerst auf CEOsBay.

Der Zweck von REST liegt schwerpunktmäßig auf der Maschine-zu-Maschine-Kommunikation. REST stellt eine einfache Alternative zu ähnlichen Verfahren wie SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) und dem verwandten Verfahren RPC (Remote Procedure Call) dar. Anders als bei vielen verwandten Architekturen kodiert REST keine Methodeninformation in den URI (Uniform Resource Identifier), da der URI Ort und Namen der Ressource angibt, nicht aber die Funktionalität, die der Web-Dienst zu der Ressource anbietet. Der Vorteil von REST liegt darin, dass im WWW bereits ein Großteil der für REST nötigen Infrastruktur (z. B. Web- und Application-Server, https-fähige Clients, HTML- und XML-Parser, Sicherheitsmechanismen) vorhanden ist und viele Web-Dienste per se REST-konform sind. Eine Ressource kann dabei über verschiedene Medientypen dargestellt werden, auch Repräsentation der Ressource genannt.

So ist ein Online-Dienst, der lediglich unveränderte Seiteninhalte nach dem Internetstandard https anbietet, bereits REST-konform. Dynamisch erzeugte Seiten folgen diesem Paradigma jedoch meistens nicht. So bieten beispielsweise Nachrichtenseiten sich ständig ändernde Informationen mit sowohl unterschiedlichem Format als auch Inhalt an, die nur schwer automatisch verarbeitet werden können. Bliebe das Format unverändert, so wäre eine essenzielle REST-Eigenschaft erfüllt. So ist eine Webseite, auf der ständig die aktuelle Uhrzeit in immer demselben Format abrufbar ist, REST-konform.

Die Bezeichnung „Representational State Transfer“ soll den Übergang vom aktuellen Zustand zum nächsten Zustand (State) einer Applikation verbildlichen. Dieser Zustandsübergang erfolgt durch den Transfer der Daten, die den nächsten Zustand repräsentieren.

Kurze Zeitreise

Das REST-Paradigma entwickelte sich aus dem 1994 von Roy Fielding entworfenen https Object Model. Fielding entwickelte seine Idee von einem einheitlichen Konzept über die Jahre weiter, bis er 2000 den REST-Architekturstil im Rahmen seiner Dissertation (Hier der Link zu der Arbeit) veröffentlichte. Das Programmierparadigma der „RESTful Application“ wurde allerdings häufig falsch umgesetzt und findet erst seit 2014 Anklang in der Welt des WWW. In seiner Arbeit geht Fielding dabei auf die verschiedenen Anforderungen ein, die für die Webarchitektur wichtig sind.

Wie funktioniert REST?

Der Architektur-Stil verweist auf sechs Eigenschaften, die ein Dienst haben muss. Dabei ist nicht festgelegt, wie man diese Prinzipien implementieren muss. Fielding beschreibt für jedes Architekturprinzip dessen Vor- und Nachteile. Dabei handelt es sich um Client-Server, Zustandslosigkeit, Caching, Einheitliche Schnittstellen, Mehrschichtige Systeme und optional Code on Demand, auf die ich nachfolgend eingehen werde.

• Client-Server (Es gilt generell die Anforderung, dass alle Eigenschaften der Client-Server-Architektur gelten. Der Server stellt dabei einen Dienst bereit, der bei Bedarf vom Client abgefragt wird. Der Hauptvorteil dieser Anforderung ist die einfache Skalierbarkeit der Server, da diese unabhängig vom Client agieren. Dies ermöglicht des Weiteren eine unterschiedlich schnelle Entwicklung der beiden Komponenten.)
  
• Zustandslosigkeit (Jede REST-Nachricht enthält alle Informationen, die für den Server bzw. für den Client notwendig sind, um die Nachricht zu interpretieren. Weder der Server noch die Anwendung soll Zustandsinformationen zwischen zwei Nachrichten speichern. Man spricht daher von einem zustandslosen (englisch: stateless) Protokoll. Jede Anfrage eines Clients an den Server ist insofern in sich geschlossen, als dass sie sämtliche Informationen über den Anwendungszustand beinhaltet, die vom Server für die Verarbeitung der Anfrage benötigt. Zustandslosigkeit in der hier beschriebenen Form begünstigt die Skalierbarkeit eines Webservices. Beispielsweise können eingehende Anfragen im Zuge der Lastverteilung unkompliziert auf beliebige Maschinen verteilt werden, da jede Anfrage in sich geschlossen ist und Anwendungsinformationen somit ausschließlich auf der Seite des Clients vorgehalten werden. Aus diesem Grund ist auf der Seite des Servers keine Sitzungsverwaltung erforderlich. In der Praxis nutzen deswegen viele https-basierte Anwendungen Cookies und andere Techniken, um Zustandsinformationen auf der Client-Seite zu behalten. Weiterhin begünstigt wird die Ausfallsicherheit, weil die Zustandslosigkeit fordert, dass transaktionale Datenübertragung in einem einzigen Seitenaufruf erfolgt. Die Zustandslosigkeit bringt dabei aber den Nachteil mit, dass sich die Netzwerkperformance verschlechtert. Da bei jeder Abfrage alle Informationen zum Interpretieren mitgeschickt werden müssen, sind aufwendigere Abfragen nötig, als wenn sich der Server die Interaktionen merken würde.)
  
• Caching (https-Caching soll genutzt werden, wobei aber gilt: Eine Anfrage, die nicht gestellt werden muss, ist die schnellste Anfrage. Fielding führt dabei den Nachteil auf, dass der Client auf veraltete Cache-Daten zurückgreifen könnte, statt die neue Ressource abzufragen. Wir kennen dies beispielsweise, wenn wir an einer Website unsere Änderungen vorgenommen haben aber die aktualisierten Informationen nach der Synchronisierung mit dem Server nicht richtig angezeigt werden bzw. lediglich die alten Informationen)
  
• Einheitliche Schnittstelle (Dies ist das Hauptunterscheidungsmerkmal aller weiteren Architekturstile. Dabei besteht diese aus vier weiteren Eigenschaften.)

1. Die Adressierbarkeit von Ressourcen, bei der jede Information, die über einen URI kenntlich gemacht wird, als Ressource gekennzeichnet wird. Jeder REST-konforme Dienst eine eindeutige Adresse hat und dem Uniform Resource Locator (URL). Diese „Straße und Hausnummer im Netz“ standardisiert den Zugriffsweg zum Angebot eines Webservices für eine Vielzahl von Anwendungen (Clients). Eine konsistente Adressierbarkeit erleichtert es außerdem, einen Webservice als Teil eines Mashups weiterzuverwenden.
   
2. Repräsentationen zur Veränderung von Ressourcen, wodurch die unter einer Adresse zugänglichen Dienste unterschiedliche Darstellungsformen (Repräsentationen) haben können. Ein REST-konformer Server kann je nachdem, was die Anwendung anfordert, verschiedene Repräsentationen einer Ressource ausliefern, z. B. in verschiedenen Sprachen oder Formaten (HTML, JSON oder XML) oder auch die Beschreibung oder Dokumentation des Dienstes. Die Veränderung einer Ressource (also deren aktuellen Status) soll nur über eine Repräsentation erfolgen.
   
3. Selbstbeschreibende Nachrichten, REST-Nachrichten sollen selbstbeschreibend sein. Dazu zählt u. a. die Verwendung von Standardmethoden. Über diese Standardmethoden lassen sich Ressourcen manipulieren.
   
4. „Hypermedia as the Engine of Application State“ (HATEOAS) laut Fielding die wichtigste Eigenschaft

Ziel ist die Einheitlichkeit der Schnittstelle und somit ihre einfache Nutzung. 

• Mehrschichtige Systeme, bei dem die Systeme mehrschichtig aufgebaut sein sollen. Dadurch reicht es, dem Anwender lediglich eine Schnittstelle anzubieten. Dahinterliegende Ebenen können verborgen bleiben und somit die Architektur insgesamt vereinfachen. Vorteile dabei sind die bessere Skalierbarkeit der Server, sowie eine mögliche Abkapselung durch Firewalls. Durch Cache-Speicher an den Grenzen (z.B. vom Server zum Web) steigert man die Effizienz der Anfragen (Siehe Caching).
  
• Code on Demand, wobei diese Forderung von Fielding optional ist. Unter Code on Demand versteht man die Übertragung an den Client Code erst im Bedarfsfall. Folglich zur lokalen Ausführung. Ein Beispiel hierfür wäre die Übertragung von JavaScript-Code bei einer HTML-Repräsentation.

Folglich kommt für die Umsetzung des REST-Paradigmas ein zustandsloses Client-Server-Protokoll zum Einsatz. Als Anwendungsschicht-Protokolle werden hauptsächlich https und https eingesetzt. Dies liegt unter anderem daran, dass sich diese im WWW etabliert haben, über einen vergleichsweisen einfachen Aufbau verfügen und mit so gut wie jeder Firewall kompatibel sind. REST vereinheitlicht die Schnittstelle zwischen Systemen auf eine überschaubare und bezüglich des zu erwartenden Verhaltens standardisierte Menge von Aktionen. Welche Aktionen dies sind, ist in REST nicht festgelegt aber alle Aktionen sind allgemein definiert. In der Regel durch die verwendeten Protokolle der Anwendungsschicht.

Während REST als Abstraktion des WWW keine spezielle Implementierung und kein spezielles Protokoll fordert, ist doch zu beobachten, dass fast ausschließlich https zum Einsatz kommt. Dadurch werden auch die Menge der Aktionen festgelegt.

Wird über https zugegriffen, so gibt die verwendete https-Methode, darunter GET, POST, PUT und DELETE, an, welche Operation des Dienstes gewünscht ist. https schreibt vor, dass GET „safe“ (sicher) sein muss, was bedeutet, dass diese Methode nur Informationen beschafft und keine sonstigen Effekte verursacht. Die Methoden GET, HEAD, PUT und DELETE müssen laut https-Spezifikation idempotent (dasselbe) sein, was in diesem Zusammenhang bedeutet, dass das mehrfache Absenden der gleichen Anforderung sich nicht anders auswirkt als ein einzelner Aufruf. Abhängig von der Implementierung können noch weitere https-Befehle unterstützt werden. Dazu gehören COPY, MOVE, MKCOL, LOCK und UNLOCK des WebDAV-Protokolls, sowie LINK und UNLINK aus RFC 2068. Bei der Kommunikation über UDP kann zudem das CoAP aus RFC 7252 statt https eingesetzt werden, welches leicht abweichende Bedeutungen für GET, POST, PUT und DELETE besitzt.

Fazit

Die meisten Unternehmen verwenden den REST-Architekturstil für die Entwicklung / Implementierung von Webdiensten, da es sich um eine einfache und benutzerfreundliche Oberfläche handelt, die weniger Schulung für die vorhandenen / neuen Mitglieder des Projekts erfordert. Unternehmen erwägen REST zusammen mit ihren vorhandenen Webdiensten.

Der Beitrag REST – Schönheit der einfachen Architektur erschien zuerst auf CEOsBay.

Ab wann werden Frameworks relevant?

In der Regel definiert man als Programmierer oder als Team, zu Beginn eines Projekts, auf Basis der Anforderungen und der wirtschaftlichen Aspekte, die Herangehensweise.

Man hat immer die Auswahl, alles von Grund auf selber bzw. nativ zu programmieren, was zwar eine extrem individuelle Lösung darstellt und alles bis auf das kleinste Detail erstellt bzw. programmiert werden kann, ein CMS (Content Management System = Eine Software zur gemeinschaftlichen Erstellung, Bearbeitung, Organisation und Darstellung digitaler Inhalte zumeist zur Verwendung in Webseiten aber auch in anderen Medienformen) zu nutzen – Wobei ich Zweites in einem separaten Beitrag ausführlich thematisieren möchte (Übrigens basiert diese Webseite auch auf einem CMS. In diesem Fall handelt es sich um eine WordPress-Instanz). Und dann gibt es natürlich Frameworks. Wobei die Anforderungen an die Professionalität des Entwicklers bei dieser Herangehensweise relativ hoch angesiedelt sind. Allerdings muss man sagen, dass das hohe Maß an Flexibilität und die Verfügbarkeit ausgefeilter Struktur-Merkmale nicht unwesentlich sind.

Welche Frameworks gibt es?

Application Frameworks: Als Grundgerüst für die Programmierung von Anwendungen mit spezifischen Strukturen und Funktionen.

Web-Frameworks: Für die Entwicklung und Programmierung dynamischer Web-Sites und Web-Anwendungen.

Komponenten-Frameworks: Als Umgebungsrahmen für die Programmierung und Einbindung von Programm-Paketen.

Domain Frameworks: Als Rahmen für vordefinierte Problembereiche.

Coordination Frameworks: Zur Einrichtung von Geräte-Interaktionen bzw. für die Abfolge zu steuernder Einzelschritte.

Class Frameworks: Zur Zusammenfassung von „Klassen“ und „Methoden“, im Sinne einer optimalen Unterstützung des Programmierers bei der Implementierung seiner spezifischen Anwendungen.

Test Frameworks: Für das Testen von Programmen. Klassische Beispiele hierfür sind „Selenium“ für den Test von Webanwendungen und „JUnit“ für den Test von Modulen. Selenium habe ich in diesem Beitrag thematisiert.

Fazit

Eines der Vorteile ist, wie bereits erwähnt, dass Wiederkehrende Aufgaben schneller abgewickelt werden können, da im Framework bereits eine Reihe an Elementen vorprogrammiert sind. Diese können beliebig oft verwendet werden. Darüberhinaus beinhalteten Frameworks Basis-Bausteine, die auf die Design-Struktur eines Programms Einfluss nehmen. Sie bieten sich in der Regel bei speziellen Anforderungen und individuellen Lösungen an, so kann das vom Framework zur Verfügung gestellte Programmier-Gerüst eine gute Wahl darstellen. Nichtsdestotrotz sollte man meines Erachtens nach bei „kleineren“ Projekten die Nutzung von Content Management Systemen in Erwägung ziehen. Schlussendlich, hängt die Wahl der jeweiligen Herangehensweise und die Effizienz, in der das Projekt realisiert wird, häufig von der Qualifikation und dem Skillset eines jeden Programmierers ab.

Der Beitrag Frameworks – Effiziente Entwicklung und eine höhere Qualität durch Rahmenwerke erschien zuerst auf CEOsBay.