Wer professionelle Webentwicklung betreibt, braucht einen gut funktionierenden Deployment-Prozess, um Updates von den lokalen Rechnern der Entwickler problemlos auf Test-, Stage- und Live-Server zu bekommen ohne dort die Datenbestände zu gefährden.
In dieser Session zeigen wir das Drupal-Deployment in einem neuen Workflow.
Mit von der Partie sind:
Features
Strongarm
Update- und Drush-Scripts
Updatescript- und Drushscript-Prozessor
Git und eine Repository-Strategie
Jenkins Continous Integration
Codemetriken und Codeanalyse beim Deployment
Continuous Testing: Integration- und UI-Testing mit OpenShift-Build-PipelinesTobias Schneck
Stabile und skalierbare Testumgebungen sind seit jeher schwer aufzusetzen und zu warten. Besonders in Zeiten von Continuous Delivery ist das Aufsetzen von Build-Pipelines in Verbindung mit automatisierten Integration- und UI-Tests eine besonders große Herausforderung. Einen eleganten Ausweg bieten containerbasierte Testumgebungen, die dynamisch zum Build-Zeitpunkt bereitgestellt werden. Der Talk zeigt anhand von mehreren Live-Demos, wie mit Hilfe von OpenShift-Build-Pipeline sowohl Server-APIs als auch grafische Web- und Rich-Client-Oberflächen getestet werden können. Zum Einsatz kommen hierfür die Open-Source-Test-Frameworks Citrus und Sakuli, die bereits für die Verwendung in OpenShift vorbereitet sind.
Hands-on Workshop: API-Dokumentation mit OpenAPI / Swagger in ASP.NET CoreGregor Biswanger
Das Dokumentieren einer API wird oft als mühsame, aber wesentliche Aufgabe angesehen. Mit OpenAPI / Swagger können wir eine API-Dokumentation angenehm einfach in ASP.NET Core integrieren. Gregor Biswanger zeigt, wie eine API-Dokumentation mit einer Benutzeroberfläche hinzugefügt wird, mit der wir die API testen können.
Als Nächstes erfahren wir, wie wir Attribute und Konventionen verwenden, um die generierte OpenAPI-Spezifikation zu verbessern. Abschließend wird gezeigt, wie wir mit der Authentifizierung, Versionierung und Anpassung der Benutzeroberfläche umgehen.
Wer professionelle Webentwicklung betreibt, braucht einen gut funktionierenden Deployment-Prozess, um Updates von den lokalen Rechnern der Entwickler problemlos auf Test-, Stage- und Live-Server zu bekommen ohne dort die Datenbestände zu gefährden.
In dieser Session zeigen wir das Drupal-Deployment in einem neuen Workflow.
Mit von der Partie sind:
Features
Strongarm
Update- und Drush-Scripts
Updatescript- und Drushscript-Prozessor
Git und eine Repository-Strategie
Jenkins Continous Integration
Codemetriken und Codeanalyse beim Deployment
Continuous Testing: Integration- und UI-Testing mit OpenShift-Build-PipelinesTobias Schneck
Stabile und skalierbare Testumgebungen sind seit jeher schwer aufzusetzen und zu warten. Besonders in Zeiten von Continuous Delivery ist das Aufsetzen von Build-Pipelines in Verbindung mit automatisierten Integration- und UI-Tests eine besonders große Herausforderung. Einen eleganten Ausweg bieten containerbasierte Testumgebungen, die dynamisch zum Build-Zeitpunkt bereitgestellt werden. Der Talk zeigt anhand von mehreren Live-Demos, wie mit Hilfe von OpenShift-Build-Pipeline sowohl Server-APIs als auch grafische Web- und Rich-Client-Oberflächen getestet werden können. Zum Einsatz kommen hierfür die Open-Source-Test-Frameworks Citrus und Sakuli, die bereits für die Verwendung in OpenShift vorbereitet sind.
Hands-on Workshop: API-Dokumentation mit OpenAPI / Swagger in ASP.NET CoreGregor Biswanger
Das Dokumentieren einer API wird oft als mühsame, aber wesentliche Aufgabe angesehen. Mit OpenAPI / Swagger können wir eine API-Dokumentation angenehm einfach in ASP.NET Core integrieren. Gregor Biswanger zeigt, wie eine API-Dokumentation mit einer Benutzeroberfläche hinzugefügt wird, mit der wir die API testen können.
Als Nächstes erfahren wir, wie wir Attribute und Konventionen verwenden, um die generierte OpenAPI-Spezifikation zu verbessern. Abschließend wird gezeigt, wie wir mit der Authentifizierung, Versionierung und Anpassung der Benutzeroberfläche umgehen.
Taugt AngularJS wirklich was? Erfahrungsbericht und AusblickPhilipp Burgmer
Slides for my presentation at WebTechCon/IPC 2014.
Visit us at http://www.thecodecampus.de
Folien zu meinem Vortrag bei der WebTechCon/IPC 2014.
AngularJS verspricht, die Entwicklung moderner Single-Page-Webanwendungen radikal zu vereinfachen. Doch kann dieses Versprechen auch bei Anwendungen, die über eine Demoanwendung (To-do-App) hinausgehen, gehalten werden? In diesem Vortrag zeigen wir die Stärken und Schwächen von AngularJS anhand unserer Erfahrungen aus mehreren Projekten und unserer Schulungen. Wie meistert man den Einstieg? Was sind die Gefahren, und wie minimiert man sie? Ist AngularJS bereit für den Einsatz in großen Anwendungen? Wir geben Antworten. Zusätzlich geben wir einen Ausblick auf AngularJS 2.0, wie die bekannten Schwächen dort behoben werden sollen und was an Neuerungen zu erwarten ist.
Verteilte Anwendungen bei Azure mit Docker und KubernetesGregor Biswanger
Kubernetes ermöglicht eine Automatisierung der Bereitstellung, Skalierung und Verwaltung von verteilten Docker-Container. Der Einstieg, die Umsetzung und Wartung hingegen ist eine extreme Herausforderung und kostet am Ende nicht nur viel Geld, sondern auch Ihre Nerven. Microsoft Azure bietet mit den Azure Kubernetes Services (Kurz AKS) die Erlösung, der soeben genannten Schmerzen. In dieser Session zeigt Ihnen der Docker- und Azure-Experte Gregor Biswanger einen Überblick von Kubernetes und wie einfach Azure für uns eine Kuberenetes-Landschaft herbeizaubern kann.
Quarkus, GraalVM und co. Java in der Cloud-Native WeltMichael Frembs
Java hat ein Problem. Es ist für die Cloud-Native Welt zu Ressourcen fressend. Mit Quarkus und der GraalVM gibt es eine Möglichkeit das Problem anzugehen. Die Präsentation wurde in folgendem MeetUp gehalten: https://www.meetup.com/de-DE/IBM-Hybrid-Multi-Cloud-Munich/events/262893313/
Electron.NET: Cross-Platform Desktop Software mit ASP.NET CoreGregor Biswanger
HTML5 ist überall - im Web, Mobile und natürlich auch auf den Desktop. Die große Stärke an HTML5 ist nicht nur, dass diese Plattform übergreifend unterstützt wird, sondern dass es immer mehr Features aus der Desktop-Welt bietet. Dennoch erfordert die Entwicklung von Desktop Anwendungen auf Basis von HTML & JavaScript neue Frameworks und Sprachen. Das Open Source Projekt Electron.NET verbindet ihr bekanntes C# & ASP.NET Core KnowHow mit den Möglichkeiten von Electron. In Kombination von C# und HTML5 können hoch performante Desktop Geschäftsanwendung für Windows, Mac und Linux entwickelt werden. Sie steigen mit den Grundlagen von Electron.NET ein und werden dann mit den wichtigsten Tools und Vorgehensweisen vertraut gemacht. Mit diesen Infos steigen Sie rasch zum versierten Cross-Platform Entwickler mit .NET auf.
Kuck mal, Node.js! Einstieg für .NET Entwickler mit Visual Studio Code und Ty...Gregor Biswanger
Das Jahr 2009 war die Geburtsstunde von Node.js. Dass hierbei JavaScript ebenfalls serverseitig verwendet werden kann, ist nur ein Teilaspekt für den hohen Erfolg. Viel relevanter ist die extrem hohe Performance, Skalierbarkeit und Produktivität. Nicht ohne Grund wird ASP.NET komplett neu erfunden und basiert auf den gleichen Ideen wie Node.js. Namenhafte Firmen wie Microsoft selbst, Google, PayPal, New York Times, GitHub, uvw. setzen bereits auf das leistungsstarke Node.js. Der Vortrag zeigt durch eine Reise der Node.js Architektur, woher die Vorteile kommen. Durch einen Vergleich von ähnlichen Funktionen, wird zudem der ideale Einstieg für .NET Entwickler geboten.
Alles an Metaprogrammierung, was eine klassische Enterprise Java Applikation zur Startup Zeit macht, können wir bereits vorher erledigt haben. Doch wie geht das? Und was können wir von Quarkus in dieser Richtung lernen?
---
Das #Softwarepicknick ist deine digitale Mittagspause mit den Experten der open knowledge GmbH.
Bei diesem meet und eat bringen wir dir hilfreiche Codesnacks und aktuelle Thesen der modernen Softwareentwicklung direkt auf den Tisch
und schaffen eine Wiese für deine konkreten Fragen aus dem Projektalltag.
Die 30-minütigen Sessions bieten dir informative Impulse und die Möglichkeit des direkten Austausches.
Nagios Conference 2007 | Pluginprogrammierung in Perl by Wolfgang BarthNETWAYS
Nicht immer findet sich ein passendes Plugin für die konkrete Aufgabenstellung. Dann ist Eigenbau angesagt. Plugins selbst zu schreiben ist nicht schwer, vorausgesetzt, man hält einige Spielregeln ein.
Dieser Workshop zeigt auf, wie man in Perl Plugins erstellt, die sich an die wichtigsten Spielregeln halten. Die Programmierung erleichtert das Perlmodul
Nagios::Plugin von Ton Voon, dem Maintainer der offiziellen Nagios-Plugins. Neben dem Modul Nagios::Plugin kommt auch das Modul GetOpt::Long für die Zerlegung der Kommandozeile und die Perl-Online-Dokumentation (POD) zur
Sprache. Für die Ausführung von Perl-Plugins liefert Nagios einen integrierten Perl-Interpreter mit (ePN – embedded Perl Nagios), der allerdings besondere Anforderungen an ein Plugin stellt. Der Workshop geht auch auf die nicht immer
einfache Fehlersuche ein, mit der man konfrontiert wird, wenn ein unter normalen Umständen funktionierendes Plugin nicht so recht mit ePN zusammen arbeiten mag.
Aus dem Inhalt:
Standard-Anforderungen an ein Plugin
Rückgabewerte und Textausgaben
Verarbeitung der Kommandozeile
Online-Hilfe und integrierte Manpage
Die Sache mit dem Timeout
Formate für Schwellwerte: Thresholds
Ausgabe von Performancedaten
Konfigurationdateien für ein Plugins verwenden
ePN, der embedded Perl-Interpreter: Anforderungen, Fehlersuche.
Der Workshop richtet sich an Teilnehmer mit Programmierkenntnissen in einer Skriptsprache und zumindest einfachen Perl-Grundkenntnissen. Die Plugin-Erstellung erfolgt unter Linux.
Punkt.de – Layout-Testing: was geht, was bringt´s, wer braucht´s?punkt.de GmbH
Mit Hilfe von Layout-Testing kann das Design von Webanwendungen wie Webseiten dauerhaft überprüft werden. Talk von Christiane Helmchen und Bianca Niestroj auf der Developer Week in Nürnberg. #dwx2016
Stephan Kaps – IT-Tage 2015 – Flyway vs. LiquiBase – Battle der Datenbankmigr...Informatik Aktuell
Wenn es das Ziel ist, Software regelmäßig auszuliefern, gegebenenfalls mehrmals am Tag, darf bei all den derzeitigen Überlegungen zu Automatisierung von Tests, Deployments und Infrastruktur die Datenbank nicht vergessen werden. Die Automatisierung von Änderungen (Migrationen) ist auch hier unverzichtbar. Inzwischen existieren Tools für diese Aufgabe, die sich sehr gut in den Entwicklungsprozess integrieren lassen. Die zwei bekanntesten Tools werden in diesem Vortrag vorgestellt und miteinander verglichen.
Was macht Clean Code aus? Wie kann man seinen Code verbessern? Welche Regeln helfen einem Programmierer, um zu sauberen Code zu gelangen? Welche Tipps und Tricks gibt es, mit denen man sich noch verbessern kann? Gibt es Patterns bzw. Muster, die zum Erfolg führen? Oder ist Clean Code nur Zeitverschwendung in Projekten unter Zeitdruck?
Wer das legendäre Buch 'Clean Code' noch nicht gelesen hat, oder eine Auffrischung gebrauchen kann, ist zu diesem Live-Stream gerne willkommen. Um es praxisnah zu halten, werden viele Code-Schnipsel gezeigt, die wir zusammen analysieren und verbessern.
Clean Code - A Handbook of Agile Software Craftsmanship: Englische Ausgabe
https://amzn.to/3pXpCOS
Clean Code - Refactoring, Patterns, Testen und Techniken für sauberen Code: Deutsche Ausgabe
https://amzn.to/3cNO55B
Diese Videobeschreibung enthält Amazon Affiliate Links, mit denen ihr mich beim Kauf unterstützen könnt, ich erhalte eine kleine Provision während ihr nichts extra zahlt für euren Amazon-Einkauf!
Continuous Integration wird längst in vielen Projekten praktiziert. Kein Wunder, steht für das Tooling doch in vielen Fällen ein Jenkins oder Travis zur Verfügung. Mit GitLab CI ist dies jedoch nicht mehr nötig. Schritt für Schritt wird in dieser Session eine Pipeline mit verschiedenen Test- und Analysetools aufgesetzt -- zur Integration in neue und bestehende Projekte.
Taugt AngularJS wirklich was? Erfahrungsbericht und AusblickPhilipp Burgmer
Slides for my presentation at WebTechCon/IPC 2014.
Visit us at http://www.thecodecampus.de
Folien zu meinem Vortrag bei der WebTechCon/IPC 2014.
AngularJS verspricht, die Entwicklung moderner Single-Page-Webanwendungen radikal zu vereinfachen. Doch kann dieses Versprechen auch bei Anwendungen, die über eine Demoanwendung (To-do-App) hinausgehen, gehalten werden? In diesem Vortrag zeigen wir die Stärken und Schwächen von AngularJS anhand unserer Erfahrungen aus mehreren Projekten und unserer Schulungen. Wie meistert man den Einstieg? Was sind die Gefahren, und wie minimiert man sie? Ist AngularJS bereit für den Einsatz in großen Anwendungen? Wir geben Antworten. Zusätzlich geben wir einen Ausblick auf AngularJS 2.0, wie die bekannten Schwächen dort behoben werden sollen und was an Neuerungen zu erwarten ist.
Verteilte Anwendungen bei Azure mit Docker und KubernetesGregor Biswanger
Kubernetes ermöglicht eine Automatisierung der Bereitstellung, Skalierung und Verwaltung von verteilten Docker-Container. Der Einstieg, die Umsetzung und Wartung hingegen ist eine extreme Herausforderung und kostet am Ende nicht nur viel Geld, sondern auch Ihre Nerven. Microsoft Azure bietet mit den Azure Kubernetes Services (Kurz AKS) die Erlösung, der soeben genannten Schmerzen. In dieser Session zeigt Ihnen der Docker- und Azure-Experte Gregor Biswanger einen Überblick von Kubernetes und wie einfach Azure für uns eine Kuberenetes-Landschaft herbeizaubern kann.
Quarkus, GraalVM und co. Java in der Cloud-Native WeltMichael Frembs
Java hat ein Problem. Es ist für die Cloud-Native Welt zu Ressourcen fressend. Mit Quarkus und der GraalVM gibt es eine Möglichkeit das Problem anzugehen. Die Präsentation wurde in folgendem MeetUp gehalten: https://www.meetup.com/de-DE/IBM-Hybrid-Multi-Cloud-Munich/events/262893313/
Electron.NET: Cross-Platform Desktop Software mit ASP.NET CoreGregor Biswanger
HTML5 ist überall - im Web, Mobile und natürlich auch auf den Desktop. Die große Stärke an HTML5 ist nicht nur, dass diese Plattform übergreifend unterstützt wird, sondern dass es immer mehr Features aus der Desktop-Welt bietet. Dennoch erfordert die Entwicklung von Desktop Anwendungen auf Basis von HTML & JavaScript neue Frameworks und Sprachen. Das Open Source Projekt Electron.NET verbindet ihr bekanntes C# & ASP.NET Core KnowHow mit den Möglichkeiten von Electron. In Kombination von C# und HTML5 können hoch performante Desktop Geschäftsanwendung für Windows, Mac und Linux entwickelt werden. Sie steigen mit den Grundlagen von Electron.NET ein und werden dann mit den wichtigsten Tools und Vorgehensweisen vertraut gemacht. Mit diesen Infos steigen Sie rasch zum versierten Cross-Platform Entwickler mit .NET auf.
Kuck mal, Node.js! Einstieg für .NET Entwickler mit Visual Studio Code und Ty...Gregor Biswanger
Das Jahr 2009 war die Geburtsstunde von Node.js. Dass hierbei JavaScript ebenfalls serverseitig verwendet werden kann, ist nur ein Teilaspekt für den hohen Erfolg. Viel relevanter ist die extrem hohe Performance, Skalierbarkeit und Produktivität. Nicht ohne Grund wird ASP.NET komplett neu erfunden und basiert auf den gleichen Ideen wie Node.js. Namenhafte Firmen wie Microsoft selbst, Google, PayPal, New York Times, GitHub, uvw. setzen bereits auf das leistungsstarke Node.js. Der Vortrag zeigt durch eine Reise der Node.js Architektur, woher die Vorteile kommen. Durch einen Vergleich von ähnlichen Funktionen, wird zudem der ideale Einstieg für .NET Entwickler geboten.
Alles an Metaprogrammierung, was eine klassische Enterprise Java Applikation zur Startup Zeit macht, können wir bereits vorher erledigt haben. Doch wie geht das? Und was können wir von Quarkus in dieser Richtung lernen?
---
Das #Softwarepicknick ist deine digitale Mittagspause mit den Experten der open knowledge GmbH.
Bei diesem meet und eat bringen wir dir hilfreiche Codesnacks und aktuelle Thesen der modernen Softwareentwicklung direkt auf den Tisch
und schaffen eine Wiese für deine konkreten Fragen aus dem Projektalltag.
Die 30-minütigen Sessions bieten dir informative Impulse und die Möglichkeit des direkten Austausches.
Nagios Conference 2007 | Pluginprogrammierung in Perl by Wolfgang BarthNETWAYS
Nicht immer findet sich ein passendes Plugin für die konkrete Aufgabenstellung. Dann ist Eigenbau angesagt. Plugins selbst zu schreiben ist nicht schwer, vorausgesetzt, man hält einige Spielregeln ein.
Dieser Workshop zeigt auf, wie man in Perl Plugins erstellt, die sich an die wichtigsten Spielregeln halten. Die Programmierung erleichtert das Perlmodul
Nagios::Plugin von Ton Voon, dem Maintainer der offiziellen Nagios-Plugins. Neben dem Modul Nagios::Plugin kommt auch das Modul GetOpt::Long für die Zerlegung der Kommandozeile und die Perl-Online-Dokumentation (POD) zur
Sprache. Für die Ausführung von Perl-Plugins liefert Nagios einen integrierten Perl-Interpreter mit (ePN – embedded Perl Nagios), der allerdings besondere Anforderungen an ein Plugin stellt. Der Workshop geht auch auf die nicht immer
einfache Fehlersuche ein, mit der man konfrontiert wird, wenn ein unter normalen Umständen funktionierendes Plugin nicht so recht mit ePN zusammen arbeiten mag.
Aus dem Inhalt:
Standard-Anforderungen an ein Plugin
Rückgabewerte und Textausgaben
Verarbeitung der Kommandozeile
Online-Hilfe und integrierte Manpage
Die Sache mit dem Timeout
Formate für Schwellwerte: Thresholds
Ausgabe von Performancedaten
Konfigurationdateien für ein Plugins verwenden
ePN, der embedded Perl-Interpreter: Anforderungen, Fehlersuche.
Der Workshop richtet sich an Teilnehmer mit Programmierkenntnissen in einer Skriptsprache und zumindest einfachen Perl-Grundkenntnissen. Die Plugin-Erstellung erfolgt unter Linux.
Punkt.de – Layout-Testing: was geht, was bringt´s, wer braucht´s?punkt.de GmbH
Mit Hilfe von Layout-Testing kann das Design von Webanwendungen wie Webseiten dauerhaft überprüft werden. Talk von Christiane Helmchen und Bianca Niestroj auf der Developer Week in Nürnberg. #dwx2016
Stephan Kaps – IT-Tage 2015 – Flyway vs. LiquiBase – Battle der Datenbankmigr...Informatik Aktuell
Wenn es das Ziel ist, Software regelmäßig auszuliefern, gegebenenfalls mehrmals am Tag, darf bei all den derzeitigen Überlegungen zu Automatisierung von Tests, Deployments und Infrastruktur die Datenbank nicht vergessen werden. Die Automatisierung von Änderungen (Migrationen) ist auch hier unverzichtbar. Inzwischen existieren Tools für diese Aufgabe, die sich sehr gut in den Entwicklungsprozess integrieren lassen. Die zwei bekanntesten Tools werden in diesem Vortrag vorgestellt und miteinander verglichen.
Was macht Clean Code aus? Wie kann man seinen Code verbessern? Welche Regeln helfen einem Programmierer, um zu sauberen Code zu gelangen? Welche Tipps und Tricks gibt es, mit denen man sich noch verbessern kann? Gibt es Patterns bzw. Muster, die zum Erfolg führen? Oder ist Clean Code nur Zeitverschwendung in Projekten unter Zeitdruck?
Wer das legendäre Buch 'Clean Code' noch nicht gelesen hat, oder eine Auffrischung gebrauchen kann, ist zu diesem Live-Stream gerne willkommen. Um es praxisnah zu halten, werden viele Code-Schnipsel gezeigt, die wir zusammen analysieren und verbessern.
Clean Code - A Handbook of Agile Software Craftsmanship: Englische Ausgabe
https://amzn.to/3pXpCOS
Clean Code - Refactoring, Patterns, Testen und Techniken für sauberen Code: Deutsche Ausgabe
https://amzn.to/3cNO55B
Diese Videobeschreibung enthält Amazon Affiliate Links, mit denen ihr mich beim Kauf unterstützen könnt, ich erhalte eine kleine Provision während ihr nichts extra zahlt für euren Amazon-Einkauf!
Continuous Integration wird längst in vielen Projekten praktiziert. Kein Wunder, steht für das Tooling doch in vielen Fällen ein Jenkins oder Travis zur Verfügung. Mit GitLab CI ist dies jedoch nicht mehr nötig. Schritt für Schritt wird in dieser Session eine Pipeline mit verschiedenen Test- und Analysetools aufgesetzt -- zur Integration in neue und bestehende Projekte.
Open Source als Innovator und Treiber von De‐Facto Standards für das Internet...Torsten Fink
Das Internet der Dinge braucht Standards für eine Interoperabilität der Einzelkomponenten. Die Standards müssen gut sein und eine gute Verbreitung aufweisen. Open Source Konzepte helfen dabei, solche Standards zu spezifizieren und zu etablieren. Obsoleszenz ist dabei manchmal eine erstrebenswerte Eigenschaft.
OpenRheinRuhr 2017 - Testgetriebene Entwicklung multimodaler ApplikationenRaphael Groner
VoiceXML ist als W3C Standard eine etablierte Sprache zur Entwicklung sprachba- sierter Anwendungen. Es ist für Sprache das, was XHTML für grafisch aufbereitete Webseiten ist. So wäre es beispielsweise auch für nicht versierte Fachkräfte möglich, Anwendungen für eine Telefonanlage vollständig mit VoiceXML auf einfa- che Art und Weise zu programmieren. Die kommende VoiceXML 3.0 Version zielt aber auch auf Anwendung ohne Telefonie-Anbindung. Ein erster Schritt in diese Rich- tung ist der aktuell veröffentlichte MMI Standard zur Entwicklung multimodaler Anwendungen. Obwohl die Sprache ausgereift und insbesondere im Bereich Tele- fon-basierte Anwendungsentwicklung stark verbreitet ist, existieren nur wenige ausgefeilte Testwerkzeuge, die direkt für VoiceXML eingesetzt werden können. In der Regel müssen die Entwickler selber zum Telefonhörer greifen, um die korrekte Funktionsweise der Anwendung zu überprüfen. Gerade im Hinblick auf größere De- ployments ist dieses Verfahren aber ungeeignet.
Ein Blick in die Kristallkugel mit dem Ziel spannende und relevante Online-Trends für das Jahr 2005 hervorzusagen. Auf der Liste sind:
- Open Source / Free Software
- WebAnalytics
- Compression
- VoIP
- Rich Thin Clients
- WiFi/WiMax
- SOA (Service-oriented architecture)
- Flash Streaming
- DAISY
- Folksonomy
Vorstellung des Leistunsspektrum der Firma WhereGroup GmbH & Co KG. Der Foliensatz erläutert die Zusammenhänge von Freie Software Lizenzen und Open Source Methoden und stellt die von der Wheregroup verwendete Softwarepalette vor. Die Wheregroup hat sich auf agile Projektsteuerung mit Scrum spezialisiert und verbindet diese Methode mit traditionellen V-Modell XT Vorgehensmodellen.
Dokumentation in agilen Projekten - WebMontag EditionSimon Krackrügge
Auch in agilen Projekten spielt die Dokumentation ein Rolle. Aber wie kann die Erstellung bedarfsgerecht passieren? Wer liest eigentlich die Dokumente und ist die Art und der Umfang für den Leserkreis geeignet? Braucht es neben der Definition of Ready und der Definition of Done noch eine Definition of agile Documentation?
Jeder von uns kennt sie – die alten PHP-Projekte, die vor vielen Jahren entstanden und heute noch eine wichtige Funktion im Unternehmen erfüllen. Und es gibt ebenso viele Ratschläge, mit diesen Applikationen umzugehen: Tests und Continuous Deployment einführen. Kompatibel zu Symfony2 machen oder gleich dahin portieren – oder doch lieber Laravel? Domain-driven Design und Microservices nutzen, durch Node.js, Go, Rust ersetzen. Der Talk zeigt, welche Optionen man hat, welche Probleme sie jeweils mit sich bringen und wie man sich entscheiden kann.
Open Standards, Open Source, Open Data. Zuviel des Guten?Arnulf Christl
Ein Vortrag von der FOSSGIS Konferenz 2013 in Rapperswil, Schweiz. Die Online Version dieses Vortrags finden Sie unter: http://metaspatial.net/conferences/fossgis2013_open.html
Der Vortrag beleuchtet ausnahmsweise mal die Schattenseiten dieser drei Gesellen, denn: Ja, es gibt sie, z.B.
* behindern Standards Innovation,
* zerstört Open Source bewährte Geschäftsmodelle und
* Open Data fördert das Chaos.
Eine konstruktive Herangehensweise zeigt, dass es lediglich gilt diese Schattenseiten auzuleuchten, um das volle Potential expliziter Offenheit ausschöpfen zu können.
Slides from my presentation about application architectures for .NET Core applications. It covers desktop application, web applications, mobile applications as well as container-based applications. It's a roundup of the Microsoft Architecture Guides.
1. Eine Stunde was mit API FirstEine Stunde was mit API First
Microservices bauen mit OpenAPI, Vert.x und Kotlin
Jan Weinschenker • Holisticon AG
@janweinschenker
1
2. AgendaAgenda
1. Wie entstand dieser Talk?
2. Wir wollen produktiv arbeiten™
3. API First! — Warum ist das eine gute Idee?
4. Wir unterstützen das™ vert.x und Kotlin
5. Fazit
2
3. Holisticon AG — About usHolisticon AG — About us
• @holisticon
Die Holisticon AG ist eine Management- und IT-Beratung mit
Niederlassungen in Hannover und Hamburg. Wir entwickeln beste
Individualsoftware, Webplattformen und Apps. Geschäftsprozesse
durchdringen wir und automatisieren sie. Große Datenmengen machen
wir mit Smart-Data-Ansätzen beherrschbar.
... und das alles agil.
www.holisticon.de
3 . 1
5. 1. Wie entstand dieser Talk?1. Wie entstand dieser Talk?
Ein Projekt mit > 70 Menschen
Viele Teams
Microservice-Architektur
Java, Scala, Kotlin, JavaScript, Typescript, ...
4 . 1
6. 1. Wie entstand dieser Talk?1. Wie entstand dieser Talk?
Vergleichsweise wenige Entwickler bauen Software für viele andereVergleichsweise wenige Entwickler bauen Software für viele andere
Entwickler.Entwickler.
Häufig disruptive Änderungen an Code und Schnittstellen
(APIs).
4 . 2
7. 1. Wie entstand dieser Talk?1. Wie entstand dieser Talk?
Andere Entwicklerteams treten als Kunden (i.S.v. Scrum)
auf
Wenig Zeit für Support und das Schreiben von Doku
Großer und steigender Bedarf an guter Dokumentation
und Entwickler-Support
4 . 3
8. 1. Wie entstand dieser Talk?1. Wie entstand dieser Talk?
Über Sinn und Unsinn geschriebener Doku ...
4 . 4
9. Sigberg’s First Law of DocumentationSigberg’s First Law of Documentation
In order for someone to read a document they must first:In order for someone to read a document they must first:
Know that it exists
Know where to find it
Care enough about the subject to actually take the time
out of their life to look it up
https://medium.com/@thorbjorn.sigberg/sigbergs-laws-of-documentation-fab155b2415b
4 . 5
10. Arnold's Laws of DocumentationArnold's Laws of Documentation
1. If it should exist, it doesn’t
2. If it does exist, it’s out of date
3. Only documentation for useless programs transcends
the first two laws
aus: Murphy's Law von Arthur Bloch
4 . 6
11. aus:aus: Extreme ProgrammingExtreme Programming
Josh Susser, devchat.tv Podcast
Kent Beck
“a comment is a lie waiting to happen”
“A comment is the code’s way of asking to be more clear”.
4 . 7
12. 1. Wie entstand dieser Talk?1. Wie entstand dieser Talk?
Durch die Erkenntnis, dass es sehr schwierig und gleichzeitig
sehr notwendig ist, gute Doku zu haben.
Wissenstransfer zwischen Entwicklern ist essentiell.
4 . 8
13. 1. Wie entstand dieser Talk?1. Wie entstand dieser Talk?
ZusammenfassungZusammenfassung
Doku und Implementierung entwickeln sich auseinander
Wie kann man diese Divergenz vermeiden?
4 . 9
14. 2. Wir wollen produktiv arbeiten™.2. Wir wollen produktiv arbeiten™.
Dafür sind wir auf das Wissen anderer Entwickler*innen
angewiesen.
Funktionierender Code ist das beste Medium für diesen
Wissenstransfer.
5 . 1
15. 2. Wir wollen produktiv arbeiten™.2. Wir wollen produktiv arbeiten™.
WunschzustandWunschzustand
APIs müssen ohne große Hürden anfassbar sein
Anstatt sich in Doku einzulesen, APIs einfach
ausprobieren
z.B. API-Spielwiese im Webbrowser
□ mehr dazu später ...
5 . 2
16. 2. Kein Appell gegen geschriebene Doku!2. Kein Appell gegen geschriebene Doku!
Für dasFür das Big PictureBig Picture::
Geschriebene Doku, Schaubilder und Diagramme
Entwicklerdoku:Entwicklerdoku:
Funktionierender, intuitiver Code
Tools und UI, die einfach anzuwenden sind
5 . 3
17. 3. API First!3. API First!
Alles steht und fällt mit der Güte der Schnittstelle!
API muss konsistent und intuitv sein
Nachträgliche Änderungen an API sind teuer
6 . 1
18. 3. API First!3. API First!
Ergo:Ergo:
API als First-Class-Citizen im Entwicklungsprozess
Schnittstellenbeschreibung (API Spec)
Entwurf vor der Implementierung :
□ Ressourcen, Operationen, Datenobjekte, Statuscodes
6 . 2
19. 3. API First!3. API First!
Frühere Ansätze für API Specs:Frühere Ansätze für API Specs:
CORBA IDL (1991 bis 2011*)
WSDL (2000 bis 2007*)
Apache Thrift (2011 bis 2017*)
*Letztes Release
7 . 1
20. 3. API First!3. API First!
Alternativen im REST-ZeitalterAlternativen im REST-Zeitalter
RAML — RESTful API Modeling Language
API Blueprint (Markdown)
Swagger / OpenAPI
7 . 2
21. 3. API First!3. API First!
Alternativen im REST-ZeitalterAlternativen im REST-Zeitalter
RAML — RESTful API Modeling Language
API Blueprint (Markdown)
Swagger / OpenAPI
7 . 2
22. 3. Swagger / OpenAPI3. Swagger / OpenAPI
Entscheidung für OpenAPI, weil:Entscheidung für OpenAPI, weil:
Sehr gutes Tooling
Unterstützung für alle gängigen Sprachen
Einbindung in bestehende CI/CD-Prozesse leicht möglich
7 . 3
23. 3. Swagger / OpenAPI3. Swagger / OpenAPI
API Spec basierend auf YAML
Hieß Swagger seit 2011
2016 umbenannt in OpenAPI
Umfangreiches Tooling
□ Gradle, Maven, Swagger UI, etc
□ Generatoren für Testdaten
7 . 4
24. 3. Swagger / OpenAPI3. Swagger / OpenAPI
Generator für Client- und Server-Code, SDKs, ...
Java (Jersey1.x, Jersey2.x, OkHttp, Retrofit1.x, Retrofit2.x, Feign, RestTemplate, RESTEasy,
Vertx, Google API Client Library for Java, Rest-assured, Spring 5 Web Client)
Scala, Kotlin, Dart, Ada, JavaScript, Typescript-Angular,
Clojure, C#, C++, Swift, Ruby, Python, Rust, Haskell, Elm, ...
Swagger UI
7 . 5
25. 3. Swagger / OpenAPI3. Swagger / OpenAPI
API Spec für das REST-Zeitalter
paths:
/apod: # https://www.my-cool-service/apod
post:
summary: create an apod with the specified date
requestBody:
required: true
description: The rating you want to set
content:
application/json:
schema:
$ref: '#/components/schemas/ApodRequest'
responses:
'201':
description: Apod entry created
headers:
location:
schema:
type: string
description: The location of the created resource.
7 . 6
26. 3. Swagger / OpenAPI3. Swagger / OpenAPI
API Spec für das REST-Zeitalter
paths:
/apod: # https://www.my-cool-service/apod
get:
summary: get all apods
responses:
'200':
description: An array of apods or an empty array, if no data is availab
content:
application/json:
schema:
type: array
items:
$ref: '#/components/schemas/Apod'
'500':
description: Server side error
content:
application/json:
schema:
$ref: '#/components/schemas/Error'
7 . 7
27. 3. Swagger / OpenAPI3. Swagger / OpenAPI
API Spec für das REST-Zeitalter
components:
schemas:
Apod:
description: the apod data object
required:
- id
properties:
id:
readOnly: true
type: string
dateString:
readOnly: true
type: string
title:
readOnly: true
type: string
imageUriHd:
readOnly: true
type: string
nullable: true
7 . 8
28. 3. Wir wollen produktiv arbeiten™3. Wir wollen produktiv arbeiten™
API Spec, kann ...API Spec, kann ...
den Medienbruch beim Implementieren vermeiden
über Repositories im Projekt verteilt und versioniert
werden
Kann uns und anderen Entwicklern das Leben erleichtern
7 . 9
29. 4. Wir unterstützen das™:4. Wir unterstützen das™: KotlinKotlin..
Schlauer Compiler
Statische Typisierung
Wenig Boilerplate
Excellente IDE Unterstützung, zumindest wenn der
Hersteller Jetbrains heißt
8 . 1
30. 4. Wir unterstützen das™:4. Wir unterstützen das™: KotlinKotlin..
OpenAPI generiert u.a. Kotlin Data classes
8 . 2
31. 4. Wir unterstützen das ™:4. Wir unterstützen das ™: Vert.xVert.x
Reactive Streams: Observable, Single, Maybe,
Completable, ...
Multi-Reactor-Pattern, ähnlich Node.js.
Unabhängige Komponenten (Verticles) kommunizieren
über einen Eventbus.
Single Threaded, Non-Blocking
8 . 3
33. 4. Wir unterstützen das ™:4. Wir unterstützen das ™: Vert.xVert.x
Vert.x verwendet die API-Spec für das Request-Routing und
die Request-Validierung.
OpenAPI3RouterFactory
.rxCreate(vertx, "swagger.yaml")
.map { routerFactory -> routerFactory.mountServicesFromExtensions() }
.flatMap { httpServer -> httpServer.rxListen(port) }
.subscribe()
8 . 5
34. 4. Unser Beispiel: Astronomy Picture of the Day4. Unser Beispiel: Astronomy Picture of the Day
https://apod.nasa.gov
https://api.nasa.gov
8 . 6
35. 4. Wir unterstützen das ™:4. Wir unterstützen das ™: Vert.xVert.x
/apod/{apodId}:
x-vertx-event-bus:
address: apod_query_service.apod # >>> Mapping auf implementierende Klasse
get:
summary: get an apod for the specified date
operationId: getApodForDate # >>> ID dieser Operations
x-vertx-event-bus:
method: getApodForDate # >>> Mapping auf implementierende Method
parameters:
- name: apodId
in: path
required: true
description: the id of the picture
schema:
type: string
pattern: '^d+$'
8 . 7