- Dienstag
01.02. - Mittwoch
02.02. - Donnerstag
03.02.
Quarkus erfreut sich wachsender Popularität und ist auf dem besten Weg, eine ernstzunehmende Alternative zu Spring Boot zu werden. Insbesondere Teams, die bislang auf Basis von Java EE entwickelt haben, werden von Quarkus abgeholt. Das Framework ermöglicht diesen Teams, ihr vorhandenes Know-how zu großen Teilen weiter zu nutzen, aber gleichzeitig Anwendungen auf modernstem technischen Fundament zu entwickeln. JAX-RS, CDI und JPA werden ebenso unterstützt wie MicroProfile, Kafka, Docker, Kubernetes oder die Erstellung nativer Images mit der GraalVM. Quarkus bietet somit auch einen interessanten Zukunftspfad für bestehende Java EE-Anwendungen. Während dieses Vortrags wird eine beispielhafte Quarkus-Anwendung live erstellt und dabei unterschiedliche Features vorgestellt.
Zielpublikum: Java-Entwickler
Vorrausetzungen: keine
Thilo Frotscher arbeitet als freiberuflicher Software-Architekt und Trainer. Als Experte für Java, APIs und Systemintegration unterstützt er seine Kunden überwiegend durch die Mitarbeit in Projekten, Reviews oder die Durchführung von Schulungen. Thilo ist (Co-) Autor mehrerer Bücher in den Bereichen Java, (Web-) Services und Systemintegration, hat zahlreiche Fachartikel verfasst und spricht regelmäßig auf Fachkonferenzen und Schulungsveranstaltungen sowie bei Java User Groups.
"Infrastructure as Code" ist heutzutage eine wichtige Komponente, um die Erstellung von Cloud-Umgebungen gut strukturieren, versionieren und verwalten zu können. Als eines der führenden Tools für diesen Zweck gilt HashiCorp Terraform. Ich möchte in meinem Vortrag Grundlagen und Konzepte erklären und einen kleinen Einblick geben, was noch alles machbar ist. Seid gespannt auf die tollen Features, die Terraform außer dem stumpfen Auflisten von Ressourcen noch zu bieten hat.
Zielpublikum: Developer, Systemadministratoren und alle anderen die etwas über Terraform lernen möchten.
Voraussetzungen : Es gibt keine besonderen Voraussetzungen.
Sandra Gerberding arbeitet seit 2003 als Softwareentwicklerin und beschäftigt
sich seit 2009 mit den Themen Continuous Integration, Testautomatisierung und
Deployment von Java-Webanwendungen. Seit 2013 arbeitet sie als DevOps Engineer mit den Themenschwerpunkten CI/CD, Docker, Kubernetes und Cloud Computing. Außerdem beschäftigt sie sich mit dem Leben, dem Universum und dem ganzen Rest.
Bisher gilt die gesetzliche Mindesteffizienz nur für Hardware. Aber auch die Software hat Einfluss auf die Begrenzung der Nutzungsdauer oder den gestiegenen Energieverbrauch. Es ist Zeit, dass Anforderungen an die Effizienz der Verarbeitung, Speicherung & Übertragung der Daten auch für Software gestellt werden. Wie kann man die Umweltverträglichkeit von Software erkennen & messen? Welche Umweltlasten entstehen durch Cloud-Dienstleistungen (s. z.B. Video-Konferenzen oder Streaming)? Der Vortrag wird unter anderem diese Fragen beantworten.
Extended Abstract
Die Grundtechnologie der Digitalisierung ist das Internet und der Rohstoff dabei sind die Daten, die bei jedem Kontakt mit den vernetzten Geräten erfasst und in der Cloud und somit in Rechenzentren verarbeitet werden. Diese Cloud besteht eben nicht, wie Wolken, aus feinen Wassertröpfchen, sondern aus handfesten elektronischen Komponenten, die aus wertvollen Rohstoffen hergestellt und für deren Betrieb viel elektrische Energie erforderlich ist. Gleiches gilt für die vernetzen Geräte, die nur durch die elektronischen Komponenten in der Lage sind zu kommunizieren. Die Software ist die eigentliche Königin in dieser elektronischen Welt. Sie steuert die Hardware und sie speichert die Informationen als elektronische Daten. Sie ist maßgeblich dafür verantwortlich wie energie- und hardwareintensiv eine Funktion ausgeführt wird. Und sie verantwortet zum großen Teil auch die begrenzte Nutzungsdauer der Geräte.
Bisherige gesetzliche Anforderungen an die Mindesteffizienz gelten nur für die IT-Hardware. Das kann ungeahnte Folgen auf den Stromverbrauch und die Nutzungsdauer haben. Die Software hat mindestens einen ähnlich großen Einfluss auf die Energie- und Hardwareeffizienz der Informationsverarbeitung. Jüngste Beispiele zeigen den Einfluss von Softwareupdates auf die Begrenzung der Nutzungsdauer oder auf den plötzlich gestiegenen Energieverbrauch nach einem Software-Update. Es ist somit an der Zeit, dass Anforderungen an die Effizienz der Verarbeitung, Speicherung und Übertragung der Daten auch für Software gestellt werden. Doch wie kann man die Umweltverträglichkeit von Software erkennen und schließlich wie messen? Welche Umweltlasten entstehen durch Cloud-Dienstleistungen, wie die Teilnahme an einer Video-Konferenz oder das Streamen der Lieblingsserie? Der Vortrag wird unter anderem diese Fragen beantworten.
"GitOps ist doch nichts anderes als Infrastructure-as-Code."
Dieses Missverständnis von GitOps hält sich hartnäckig und ist vermutlich der Grund, weshalb das Verständnis über die Vorteile von GitOps noch nicht bei allen Entwickler:innen angekommen ist.
Git wird dabei als Schnittstelle für einen Operator verwendet, der Deployment- und Betriebsaufgaben innerhalb der Zielumgebung ausführt.
In dieser Session räume ich mit Vorurteilen auf und zeige, welche Fallstricke bei der Anwendung dieser neuen Deployment- und Betriebsstrategie lauern. Außerdem gebe ich Tipps bei der schrittweisen Transformation – weg von traditionellen CI/CD Pipelines hin zu Cloud-Native Deployment und Betrieb mit GitOps
Zielpublikum: Entwickler:innen, SREs, Plattform Engineers
Voraussetzungen: Grundlagenwissen CI/CD
Anja Kammer ist Senior Consultant bei INNOQ und entwickelt cloud-native Web-Anwendungen. Sie beschäftigt sich mit Automatisierung von Deployments und CI/CD Systemen im Speziellen. Ihre Schwerpunkte liegen in den Bereichen DevOps, Cloud Infrastruktur und Kubernetes.
Many of us have a rough idea of what side-effects are and a vague sense that they're bad. It's a shame we're not more precise about it, because when you really understand side-effects you have an excellent new lens through which you can judge individual blocks of code, larger architectural patterns, and even whole system designs.
So let's start by clarifying our understanding of what side-effects are and how to spot them. We'll see how easily they arise, leaving code that's harder to understand, harder to test and harder to decouple. Then we'll look at tools and techniques for eliminating those side-effects where it's possible and managing them where it isn't.
Finally we'll zoom out to see how those ideas get expressed in every field of computing, yielding fundamentally different approaches to programming language design, DevOps, system architecture, and database design. There's an iceberg of complexity hiding in your systems' side-effects and by the end of this talk you'll be able to spot it and start tackling it, rethinking the way we deal with data and the systems around it."
Kris Jenkins is a Developer Advocate for Confluent, a veteran startup contractor, and former CTO & Co-Founder of a gold trading business. He started his career working for a finance company whose success depended on having a better data model than all their competitors, and the search for better architecture has been with him ever since.
Bei der Softwareentwicklung wird viel Wert darauf gelegt, dass die Software technisch korrekt erstellt wird. Dass die Software tatsächlich das leistet, was sich der Kunde vorgestellt hat, kommt oft zu kurz. Dies führt häufig zu unzufriedenen Kunden und frustrierten Entwicklern. "Specification by Example" hilft, gleich im ersten Anlauf fachlich korrekte Software zu entwickeln. Hierbei handelt es sich um eine kollaborative Methode zur Erstellung von Requirements und fachspezifischen Tests, die zuerst 1996 von Ward Cunningham beschrieben wurde und die 2002 von Martin Fowler ihren Namen bekam.
Sie kommt bei der Anforderungsanalyse, der Erstellung von fachspezifischen Tests und bei der Dokumentation zum Einsatz und nimmt auch Einfluss auf das Design der Software.
In diesem Vortrag erfahren die Teilnehmer:
- Wie Specification by Example es schafft, Anforderungsmanagement, Entwicklung und Dokumentation unter einen Hut zu bringen.
- Wie Domänenbegriffe dabei helfen können, Tests passgenauer zu schneiden.
- Wie wichtig es ist, die Business-Anforderungen des Kunden genau zu verstehen und Randfälle kritisch zu hinterfragen
Zielpublikum: Software-Entwickler, Tester, Domänenexperten
Voraussetzungen: Keine
Wir alle lieben Programmieren. Nur ist Programmieren ist ja kein Selbstzweck. Und woher wissen wir eigentlich, was wir programmieren sollen? Dazu brauchen wir ein Werkzeug mit dem wir die Domäne und Ihre Sprache kennenlernen können.
Domain Storytelling heißt, dass wir unsere Anwender Geschichten von ihren Aufgaben erzählen lassen. Beim Zuhören zeichnen wir die Geschichten mit einer grafischen Sprache auf. Unsere Fachexperten können direkt sehen, ob wir sie richtig verstehen und was wir noch falsch verstehen. Nach nur wenigen Stories verstehen wir die Sprache unserer Anwender und können ein Domänenmodell daraus bauen und implementieren.
Zielpublikum : Entwickler:innen, Architekten (Requirement Engineers und Product Owners können im ersten Teil ohne Code auch etwas lernen)
Voraussetzungen : Keine
Henning Schwentner loves programming in high quality. He lives this passion as coder, coach, and consultant at WPS – Workplace Solutions in Hamburg, Germany. There he helps teams to structure their monoliths or to build new systems from the beginning with a sustainable architecture. Microservices or self-contained systems are often the result. Domain-driven Design as well as Domain Storytelling and other collaborative modelling methods help here. Henning is author of “Domain Storytelling – A Collaborative Modelling Method” and translator of “Domain-Driven Design kompakt”.
In diesem Vortrag möchte ich euch Grundlagen und Prinzipien von React vorstellen, sodass ihr einen Eindruck bekommt, was diese Bibliothek besonders macht. Da ihr in euren React-Anwendungen in der Regel noch weitere Bibliotheken und Tools benötigt, werden wir uns neben React selbst auch das Ökosystem ansehen. Ich stelle euch Bibliotheken für verschiedene Anwendungsfälle vor, sodass ihr nach dem Vortrag einen Eindruck habt, wie ihr ein ernsthaftes React-Projekt in der Praxis starten könnt. Im Vortrag werde ich etwas React-Code zeigen, ansonsten bewegen wir uns aber auf einer konzeptionellen Ebene, sodass Vorkenntnisse in JavaScript nicht erforderlich sind.
Publikum: Architekten und Entwickler, die grundlegende Konzepte und Ideen von React und dessen Ökosystem kennenlernen wollen, um React in ihrem Projekt einzusetzen bzw. einschätzen zu können, ob React eine gute Idee für ihr eigenes Projekt ist
Voraussetzung :keine
In der Frontend-Entwicklung kommt man selten ohne JavaScript aus. Gestandene Backend-Profis sehen sich dann mit einer komplett neuen Toolchain konfrontiert, die vor unbekannten Fachbegriffen nur so strotzt. Ein Webpack möchte mit Loadern die Packages bündeln, aber selbstredend mit aktiviertem Babel-Support, damit man auch zu ES6 transpilieren kann. Wie meinen?! In diesem Vortrag werden wir uns – ausgehend von JavaScript, CSS und HTML – die Aufgaben einer Frontend-Toolchain ansehen und deren Strategien, wie sie ein performantes Resultat erzeugen. Lasst uns gemeinsam Trees shaken!
Zielpublikum: Frontend- und Fullstack-Entwickler:innen Backend-Entwickler:innen mit Interesse an Frontend
Voraussetzungen: Basiswissen Frontend/HTML/CSS/JS (es reicht aus, wenn man selbst schon mal eine kleine Webseite gebaut hat)
Single-Page-Applications -ursprünglich als kleines fancy Frontend gestartet- sind in den letzten Jahren zu großen, schwergewichtigen eigenen Applikationen angewachsen, die fehleranfällig, schwer wartbar und langsam in der Weiterentwicklung sind. Aber woran liegt das eigentlich? Im Frontend gibt es als Abstraktion zumeist nur das Konzept der Komponenten. Eine tiefergehende Analyse der benötigten Bausteine bleibt in der Regel aus. Im Backend hingegen, erfolgen solche Analysen seit Jahren.
Zielpublikum: (Frontend-)Architekten
Voraussetzungen: Erfahrung mit Single-Page-Applications von Vorteil
Wenn eine weltweite Sicherheitslücke das Internet kaputt macht, dann kann man sich schon die Frage stellen: ist es wirklich so schlimm? Repariert das nächste Release das Problem tatsächlich? Oder handelt es sich eine weltweite Verschwörung der Open Source Entwickler? Ein kurzer Einblick in die Welt der Apache Software Foundation, in die bisher belanglose Welt der Logging-Frameworks und das schreckliche Leben der (fast) unbezahlten Open Source Entwickler.
Christian Grobmeier ist selbstständiger Trainer und Software Entwickler. Außerdem ist er seit knapp 13 Jahren unbezahlter Mitarbeiter der Apache Software Foundation. Dort ist er derzeit VP Data Privacy, er hat aber auch im mittlerweile recht bekannten Log4j Projekt mitgewirkt. Sie erreichen Ihn auf Twitter unter @grobmeier oder über seine Internetseite https://grobmeier.solutions
Wenn Designer und Entwickler miteinander kommunizieren, fühlt es sich oft so an, als ob sie verschiedene Sprachen sprechen würden. Selbst beim besten Willen können sie die Bedürfnisse und Vorgehensweisen des jeweils anderen nicht nachvollziehen und reden einfach aneinander vorbei. Auch wenn diese Art von Problemen nicht neu ist, werden sie für Unternehmen, die eine konsistente Benutzererfahrung über mehrere Anwendungen hinweg gewährleisten möchten, noch wichtiger. Doch wie kann man diese Lücke schließen?
Voraussetzung hierfür ist ein gemeinsames Fundament: ein Designsystem, das von beiden Seiten verwendet wird. Repräsentiert wird das Designsystem von einem so genannten Living Styleguide, in dem alle Teile des Designs beispielhaft gezeigt werden, so dass das Aussehen und der dazu notwendige Code gemeinsam veranschaulicht werden. Dies ermöglicht jedem Teammitglied die problemlose Kommunikation über Designänderungen und deren Auswirkungen auf den Code. Gleichzeitig bietet es eine Vielzahl von Komponenten, um produktiv neue Anwendungen mit einer konsistenten Benutzererfahrung zu erstellen
Zielpublikum: Der Vortrag richtet sich an Entwickler:innen, sowie Teamleiter:innen und Unternehmensverantwortliche, die sich eine bessere Zusammenarbeit von Design und Entwicklung wünschen.
Voraussetzungen: Die Codebeispiele bestehen aus HTML, CSS und JavaScript. Grundkenntnisse dieser Sprachen sind von Vorteil, aber zum Verständnis des Vortrags an sich nicht erforderlich.
Elisabeth Engel ist Head of UX & Innovation bei interfacewerk und Co-Organisatorin des Münchner Usability Testessens. Nach ihrem Studium der Medieninformatik arbeitete sie in verschiedenen Softwareprojekten – unter anderem für Telefónica Deutschland und gutefrage.net. Dabei haben es ihr besonders die Themen nachhaltige Teamentwicklung, leane Prozessgestaltung und hervorragende Bedienerfreundlichkeit angetan. In ihrer Freizeit geht sie gerne auf Erkundungstour und hält Ausschau nach neuen Inspirationen.
Some codebases are nicer to work with than others. This is true for applications, services, libraries, frameworks, even programming languages themselves. Is this a purely personal choice or are there universal characteristics of software that can make code a joy to work with? Daniel has been thinking about this for a long time, especially since he poked a stick at the SOLID principles for fun a few years ago and people came after him with pitchforks.
Extended Abstract
His recent post about why he feels SOLID is outdated ended up on the front page of Hacker News! Now he has codified his thoughts into his own pithy five-letter acronym, CUPID: Composable, Unix philosophy, Predictable, Idiomatic, Domain-based. Why these characteristics, what do they mean, and why should you care? Can they improve your coding experience or is this just more programmer navel-gazing?
By the time you get to a level of supporting junior developers, you're likely to have forgotten what it feels like to be one. When done right, supporting junior developers not only leads to them feeling comfortable and confident in their growing skills, but also allows you to learn more about yourself and your own knowledge. Supporting junior developers is also the key to growing senior developers, building strong teams over the mid- to long-term, and preventing burnout.
This talk will cover what being a junior developer is like in 2022, and how you can better support your juniors and drive excellence alongside healthy patterns of thinking. It will address the most common junior developer pain points (impostor syndrome, fear of retribution, etc), where they stem from, and the practical steps you can take to alleviate that pain.
Zielpublikum: Developers mid- to senior level, team leads, etc
Voraussetzungen: None
Anna McDougall is no stranger to career discussions. At 25 she moved on from her project management and marketing career to complete a Masters in Music and worked for seven years as a professional opera singer. In 2020, it was time for another change, and Anna ended up successfully transitioning into web development and software engineering. She now works as a Director, Product and Engineering at National Media and Tech. Anna spends a lot of her free time on social media and YouTube, coaching others from non-traditional backgrounds and helping them to launch successful careers in programming and tech.
“Key lesson is, you can always (read: most of the time) do greenfield in a legacy code base.”
– Michael Feathers
Legacy Code ist eine der größten Herausforderungen für Entwickler überhaupt. Er kostet Nerven und fordert oft all unsere Kräfte, um auch nur ein kleines Feature in Produktion zu bringen. Aktuelle IDEs bringen viele Refactoring-Werkzeuge mit, die uns das Leben und Arbeiten im Brownfield erleichtern. Weniger bekannt sind aber Refactorings, die nicht vollautomatisch von unserer IDE übernommen werden können.
Motiviert von Michael Feathers’ Zitat möchte ich einige Refactorings und Legacy-Code-Techniken live vorführen, die die IDE nicht automatisch für uns ablaufen lassen kann, die man dafür auch tief im Schlamm des Brownfields einsetzen kann. So pflanzt man testgetriebene, grüne Inseln, die sich Schritt für Schritt vergrößern und so das ganze Projekt verbessern.
Als Beispielprojekt nehme ich die Gilded Rose Kata von Emily Bache und zeige damit systematisch, wie die Techniken in der Praxis eingesetzt werden können. Die Tests bleiben dabei immer grün und die Techniken werden so kleinschrittig wie möglich ausgeführt.
Zielpublikum: Entwickler, die mit Legacy Code kämpfen und sowohl Refactorings als auch Features parallel in die Codebase bringen müssen.
Voraussetzungen: Vorkenntnisse: Etwas Java- und Refactoring-Erfahrung sind von Vorteil. Man muss aber kein Experte darin sein, um dem Vortrag folgen zu können.
Georgs Handwerk und Leidenschaft ist die Programmierung, meistens in JVM-Sprachen wie Java, Groovy, Kotlin oder Clojure. Zum Handwerk gehören für ihn auch Themen wie die Pflege von Legacy Code, Automatisierung von Builds und Deployments oder Agilität im Team. Seit einigen Jahren ist er Co-Organisator der Software-Craftsmanship-Communities im Ruhrgebiet und in Düsseldorf. Wenn er mal nicht programmiert, spielt er Trompete, pflegt seine Bonsai oder praktiziert Aikido.
Unsere Webapplikationen sollen unsere Kunden glücklich machen und einfach zu betreiben sein – aber wie finden wir heraus, welche Bedürfnisse unsere Kunden haben und welche technischen Änderungen sinnvoll sind, ohne die Kunden direkt zu fragen? Die Antwort ist der Build-Measure-Learn-Zyklus – aber wie setzen wir das "Measure" um? Wie können wir Metriken erfassen, durch die wir verstehen, welche Veränderungen oder neuen Features unsere Kunden am glücklichsten machen? Egal, ob das Ziel eine eher klassische oder eine cloud-basierte, horizontal sklierbare Umgebung ist: ein dazu passender, sehr verbreiteter Technologiestack besteht aus Spring Boot, Micrometer, Prometheus und Grafana. Ich möchte in meinem Vortrag sowohl ein wenig theoretisches Basiswissen über Metriken vermitteln als auch die praktische Umsetzung von der Erfassung von Messwerten bis hin zu hübschen Grafana-Charts anhand von konkreten Beispielen zeigen.
Zielpublikum: Software-Entwickler, die sich für die Erfassung von Metriken in Web-Applikationen interessieren.
Voraussetzungen: Etwas Erfahrung bei der Umsetzung von Spring-Boot-Web-Applikationen sollte vorhanden sein. Die Code-Beispiele nutzen Kotlin, sollten aber ohne weiteres von Java-Entwicklern ohne Kotlin-Kenntnisse verstanden werden können.
Frank Gerberding ist Softwareentwickler und -architekt bei der smartsteuer GmbH. Er beschäftigt sich seit über 20 Jahren mit vielen Themen im Umfeld der Java-Plattform. Als Full-Stack-Webentwickler interessieren ihn vor allem Programmiersprachen, Webarchitekturen, Skalierbarkeit, Softwarequalität und der Blick auf das „Große, Ganze“.
"Der große Erfolg von Produkten, die auf Open-Source-Software (OSS) basieren, geht mit einer großen Anzahl von Bibliotheken Dritter einher.
Jede Bibliothek kann Sicherheitslücken enthalten.
Unkontrolliert führt dies zu einer epidemischen Anzahl von Schwachstellen in produktiven Systemen.
Angreifer nutzen diese Schwachstellen als Angriffsvektor.
Eine zunehmende Anzahl von Berichten darüber in den Nachrichten ist eine Folge davon, auch für diejenigen, die nicht direkt betroffen sind.
Die Betroffenen haben mit gestohlenen, verlorenen oder verschlüsselten Daten zu kämpfen. Im Extremfall folgen Konkurs und Arbeitsplatzverlust.
Die OSS-Welt bietet eine beeindruckende Sammlung von Bibliotheken und Frameworks, die ein breites Spektrum an Funktionen abdecken.
Um "das Rad nicht neu zu erfinden", ist die Verwendung von Bibliotheken sehr empfehlenswert und unter Entwicklern beliebt.
Daher sollte das Management von Sicherheitslücken bei Drittanbietern Teil jedes Projekts oder Produkts sein.
Offiziell ist dies auch Teil der kontinuierlichen Überwachung der Informationssicherheit (ISCM) und Teil der OWASP Top 10.
In diesem Vortrag werden wir erörtern, warum der Umgang mit Sicherheitslücken von Drittanbietern Teil jedes Projekts sein sollte.
Anhand einiger Beispiele werden wir verschiedene Werkzeuge und Maßnahmen zum Umgang mit diesen Sicherheitslücken zeigen.
Schließlich werden wir auch über die relevanten organisatorischen Aspekte sprechen."
Zielpublikum: Entwickler:innen
Voraussetzungen: Keine
Sebastian ist Identity und Access Management Consultant bei der codecentric AG. Eines seiner Schwerpunktthemen ist der Einsatz von Keycloak als SSO-Komponente und deren Integration in Unternehmensabläufe. Er hat viel Erfahrung als Softwareentwickler in Teams, die nach Agilität streben und Open Source Software hauptsächlich auf der JVM einsetzen. Die Softwarebranche ist seit fast 20 Jahren sein Arbeitsfeld. Er ist einer der Organisatoren der Java User Group Darmstadt eher selten twittert er als @srose204. Er lebt mit seiner Frau und zwei kleinen Kindern in Wiesbaden."
Everyone wants to innovate, the question is how do you change your environment to support innovation?
Gabrielle will introduce the innovation imperative; why innovation is a necessity, a look at the disruptors threatening the fundamental ways we do business, and how to create a sustainable innovation strategy.
We then go to the mean streets of Chelsea, London and meet Riccardo Mariti of Riccardo's restaurant. Riccardo will show you need to disrupt your business before you get disrupted and the importance of building continuous innovation into everything you do. Expect many stories and an interactive Q&A
Gabrielle Benefield founder of Mobius (Mobiusloop.com) is an advocate for purposeful innovation helping enterprises create innovation ecosystems to adapt to complexity and a rapidly changing future. Gabrielle adopted Agile and Lean thinking in the 90’s dotcom boom in Silicon Valley to successfully lead teams, including taking a scale-up reaching exponential 10x growth in a year and a robust Initial Public Offering, then spearheading one of the largest Agile enterprise transformations - scaling up to 250+ teams across three continents.
Since developing the earliest inception of Mobius in 2009 Mobius has helped individuals and organizations including Red Hat, World bank, American Express, World Health, Santander bank, US navy, Unicef solve complex problems in a transformational way. We work with scale-ups to large enterprises with over $73B in revenue, and diverse market sectors ranging from automotive, financial services, insurance, aerospace and healthcare.
https://www.linkedin.com/in/mobiusloop/
Riccardo Mariti is the Founder & CEO of Riccardo's Restaurant in London. He opened Riccardo's in 1995 and beginning in 2016 transitioned it to the ‘world's first scrum restaurant’. Using scrum, agile and mobius, Riccardo has pivoted his business model to measurably decrease staff overheads, decrease team member turnover while boosting team morale, customer satisfaction and profits.
Riccardo is a guest presenter at Harvard Business School’s intensive MBA program, and Riccardo’s Restaurant has become a showcase model for agile and innovation in a bricks and mortar business. Tesla, Bosch, 3m and EBRD European Bank of Reconstruction and Development have frequently visited the restaurant with senior management to see how the restaurant is run.
In 2020, in response to the Covid-19 Pandemic, Riccardo converted the restaurant into a deli and launched within 5 hours of the initial announcement of lockdown, later creating a line of retail food products which are now offered nationwide by overnight courier service. He is also pursuing several other joint ventures directly related to the Chelsea restaurant. Riccardo also has a background in real estate investment, development and management.
Die Entwicklung von APIs beginnt immer mit der alten und mittlerweile langweiligen Schlacht von API oder Code first. Die Arbeit mit APIs bezieht sich auf einen Prozess, der Design, Entwicklung und Betrieb umfasst. Somit wird schnell DevOps als Paradigma der Wahl herangezogen. Mit Blick auf bestehende CI/CD-Prozesse stellt sich aber die Frage, wie sich die Prinzipien von API first mit diesen Prozesses vereinbar sind und wie ein entsprechendes Setup aussehen kann. Alles im Bezug auf Geschwindigkeit und Qualität einer hervorragenden API Experience, auch im Hinblick auf das automatisierte Deployment von Infrastrukturkomponenten.
Zielpublikum: Anfänger und Fortgeschrittene Entwickler:innen
Voraussetzungen: Verständnis von DevOps und CI/CD
Von Oktober 2016 an ist Daniel ein Teil des Teams der codecentric am Standort in Solingen. Schon seit Anfang der 2000er Jahre widmet er sich dem Thema der „Digitalen Transformation“. Neben den aktuellen Schwerpunkten API-Management, Application Lifecycle Management Tooling und VoiceUI, ist er auch Experte für den Einsatz von Produktinformationssystemen (PIM) und Database-Publishing mit Hilfe von Rendering-Technologien.
For most people, AI means robots taking human jobs or China’s surveillance of its citizens. Despite the hype around it and its image of progress, the real workings of artificial intelligence are not widely understood. Companies are already implementing a web of algorithms to optimize manual business processes. Most of the time, the larger IT organization is not included on the journey. This talk is an overview of how IT leaders can center the development of human teams in a world that is increasingly optimized by algorithms.
As an expert you will be asked to facilitate the learning of others, not to mention your personal eternal learning in your field. Join an interactive session about how our brains accept new knowledge and store it for later use. Your take-away will be three-fold; how to chunk information you give to others, how to improve your own learning AND something to entertain with at dull parties.
Zielpublikum: Anyone who ever needs to teach someone something or explain something to anyone.
Voraussetzungen: None.
