Category

Allgemein

CONCEAL: Verbergen (5C Design, Teil 3)

By | Allgemein, Inhaltliches | No Comments

Verbirg so viel der internen Struktur eines Bausteins und der Art der Umsetzung vor der Außenwelt wie möglich.

  1. Software-Entwurf: Ein Blick zurück und nach vorn
  2. CUT: Richtig schneiden
  3. CONCEAL: Verbergen
  4. CONTRACT: Schnittstelle festlegen
  5. CONNECT: Verbinden
  6. CONSTRUCT: Aufbauen
  7. Its a Wrap: Zusammenfassung

Es war 1972 als David Parnas sein visionäres Papier mit dem Titel “On the Criteria To Be Used in Decomposing Systems into Modules” veröffentlichte. Während Parnas hier viele Aspekte der Modularisierung angesprochen hat, ist es inzwischen hauptsächlich noch für eines bekannt, und zwar für die Formulierung des Information-Hiding Prinzips. Alles, von dem man annahm, dass es sich später ändern könnte, sei vor der Außenwelt zu verbergen. So hat man die Garantie, dass es von außerhalb eines Bausteins niemals Abhängigkeiten dazu geben wird. Dadurch kann dies später jederzeit isoliert geändert werden. Ich unterstreiche das und gehe sogar noch weiter: Verbergen Sie am besten einfach alles, was sich verbergen lässt. Standardmäßig sollte einmal alles zunächst einmal verborgen sein. Nur wenn es außerhalb wirklich benötigt wird, sollte es auch veröffentlicht werden. Schließlich ist es schwierig vorherzusehen, was tatsächlich später einmal geändert werden muß.

Einer der Vorzüge der aktuell so beliebten Microservices ist, dass dabei Interna der einzelnen Module (dort eben Microservices genannt) automatisch hinter einer Remote-Schnittstelle (hier oft REST) verborgen werden. Durch den Verteilungsaspekt eines Service sind das nicht nur die konkreten Komponenten, sondern auch deren Laufzeitumgebung und die jeweils eingesetzte Technologie zur Implementierung.

Die verschiedenen Technologien bringen allerdings selbst bereits Dinge mit, um Subbausteine zu verbergen. In Java ist dies wie folgt möglich, wobei wir auf der niedrigen Abstraktionsebene beginnen und danach “nach außen zoomen”:

  • Innerhalb einer Klasse lassen sich einzelne Member (wie Methoden und Variable) verbergen, beispielsweise mit dem private-Keyword. In Java hat sich eingebürgert Instanzvariable einer Klasse prinzipiell zu verbergen, und wenn, dann nur über sogenannte getter und setter zu veröffentlichen.
  • Klassen lassen sich innerhalb eines Java-Packages verbergen, indem man diese als package-protected definiert. Die Angabe erfolgt dann ohne visibility Modifier in der Klassen-Deklaration.
  • Ab Java 9 können Packages mittels JigSaw (nähere Infos dazu hier) zu Modulen zusammengefasst werden. Dabei kann man gezielt Packages exportieren oder vor der Außenwelt verbergen.

Facade Pattern

Eine Möglichkeit um das Information-Hiding Prinzip umzusetzen stellt das Facade Pattern dar (nähere Infos dazu hier). Bei einer Fassade handelt es sich um einen dezidierten Einstiegspunkt in ein Modul oder Subsystem. Die einzelnen Bestandteile werden gezielt verborgen und jede Interaktion mit ihnen von außen erfolgt über die Fassade. Bei einer REST-API eines (Micro-)Service beispielsweise handelt es sich im Grunde ebenfalls auch immer um eine Fassade.

Law-of-Demeter / Principle of least Knowledge

Beim Law-of-Demeter (zum Ursprung und Namen des Prinzips siehe hier) handelt es sich um einen Spezialfall des Information-Hiding Prinzips. Für den Consumer einer Schnittstelle soll das Zusammenspiel des Providers mit anderen Komponenten möglichst verborgen sein. Der Consumer vemeidet dadurch Abhängigkeiten zu den vom Provider verwendeten weiteren Komponenten. Im folgenden Listing muss der Fahrer wissen, aus welchen einzelnen Bauteilen das Auto besteht, um es zu verwenden. Für die Hersteller des Autos hat dieses Design den Nachteil, bei Änderungen die Fahrer informieren zu müssen, damit diese sich darauf einstellen können.


Car wartburg = new Car();
wartburg.getSeatbelt().fasten();
wartburg.getEngine().start();

Im folgenden Listing sind diese Probleme behoben. Nun kann ich den Verbrennungsmotor durch Elektromotoren auswechseln, die an den Radnaben montiert sind, und außerdem den Start des Autos verweigern, sollte sich der Fahrer nicht angeschnallt haben. Den Fahrer muss ich über diese Änderungen gar nicht informieren.


Car tesla = new Car();
tesla.secureDriver();
tesla.activate();

Wenn Sie konsequent Dinge verbergen stellt sich die Frage, wie den möglichen Consumern der Zugang zur Funktionalität des eigenen Bausteins gewährt werden soll. Hier kommen dann Schnittstellen ins Spiel, was uns auch zu unserem nächsten Beitrag dieser Serie bringt, nämlich: “CONTRACT: Schnittstelle festlegen“. (Coming soon, stay tuned…)

CUT: Richtig schneiden (5C-Design, Teil 2)

By | Allgemein, Inhaltliches | No Comments

Je unabhängiger ein Baustein ist, desto einfacher wird er zu handhaben sein. Schneide Bausteine so, dass sie sich möglichst gut voneinander abgrenzen.

  1. Software-Entwurf: Ein Blick zurück und nach vorn
  2. CUT: Richtig schneiden
  3. CONCEAL: Verbergen
  4. CONTRACT: Schnittstelle festlegen
  5. CONNECT: Verbinden
  6. CONSTRUCT: Aufbauen
  7. It´s a Wrap: Zusammenfassung

Um Komplexität dauerhaft beherrschbar zu machen, gibt es kaum eine Alternative dazu, diese in einzelne kleinere Teile zu zerlegen. Dafür muss man sich zunächst einmal die Frage stellen, an welchen Grenzen diese Abgrenzung denn am besten funktioniert. Wie findet man diese? Im Endeffekt wird der Programmcode der Lösung ein Abbild der fachlichen Anforderungen sein. Die möglichen Grenzen müssten demnach bereits in den Anforderungen auffindbar sein. Warum eine solche “fachliche Grenzziehung” (auch Vertikalität genannt) zu mehr Eigenständigkeit der Bausteine führt möchte ich anhand eines Beispiels verdeutlichen.

Schichten vs. Vertikale Architektur

Abbildung 1 zeigt ein nach klassischer Manier in technische Strukturen zerlegtes System. Daraus ergeben sich die dort abgebildeten Schichten, manchmal auch Layer genannt. Damit werden vorrangig die technischen Aspekte der Lösung betont. Dies hat den Vorteil, dass Entwickler passend zu ihren Stärken Strukturen im Code wiederfinden. Es werden außerdem querschnittliche Themen wie Persistenz gleichartig behandelt, was meist auch gewünscht ist. Auch das User-Interface wird für den Benutzer hier wohl ein durchgängig flüssiges Erlebnis darstellen. Aber: Sobald der Wunsch auftaucht, in irgendeinem der bestehenden Features ein weiteres Eingabe-Feld hinzuzufügen, zieht dies eine Kaskade an Änderungen in allen Layern nach sich. Man beginnt in der DB, zieht dies dann im DB-Access-Layer nach, danach in der Service-Schicht und zum Schluss im UI. Auch wird ein Ausfall einer niedrigeren Schicht sich immer auch auf alle Schichten darüber auswirken. Solch technische Strukturen sind demnach nicht wirklich eigenständig.

Abb. 1: Schichtenarchitektur

Die Alternative zu technischen Strukturen sind fachliche bzw. vertikale Strukturen (siehe Abb. 2). Hier wird besonders die Fachlichkeit betont. Das heißt übrigens nicht, dass man bei näherem Blick in eine dieser fachlichen Strukturen nicht wieder so etwas wie Layer finden wird. Trotzdem: Der Aspekt, der der obersten Abstraktionsebene Form gibt, wird immer etwas stärker betont werden als der sekundäre Aspekt innerhalb dieser primären Struktur.

Abb. 2: Vertikale / Fachliche Architektur

Die Grenzen der fachlichen Zerlegung

Tatsache ist allerdings, dass vertikale Abtrennung in manchen Fällen etwas besser funktionieren wird, und in anderen Fällen wiederum nicht so gut. Die Anforderungen eignen sich nämlich nicht immer in gleichem Maß für eine solche Aufteilung. Manchmal sind bereits die Business-Regeln, die der Fachexperte formuliert, so dermaßen miteinander vernetzt, dass eine effiziente Zerlegung schwierig wird. Werfen Sie dazu bitte einen Blick auf die Architektur, die in Abb. 3 dargestellt ist. Es handelt sich dabei um einen Web-Shop, welcher nach allen aktuellen Regeln der Kunst in fachliche Microservices zerlegt wurde, während die User-Interfaces nach wie vor als monolithische Layer implementiert sind.

Zunächst ist bemerkenswert, dass man ein solch monolithische Design des UI in Microservice-Architekturen häufig antrifft. Hier möchte ich kurz innehalten und die Frage stellen, warum dem eigentlich so ist. Warum klappt hier die fachliche Zerlegung oft nicht so gut wie im Backend? Die Ursache ist bei einer nicht-funktionalen (oder qualitativen) Anforderung zu finden. Wenn ich dem User ein durchgängiges Erleben des UIs ermöglichen möchte, so ist ein vertikaler Architekturstil an dieser Stelle nicht besonders gut geeignet. Daran sieht man, dass qualitative Anforderungen ebenfalls Einfluss auf die optimal mögliche Zerlegung eines Systems haben können.

Im Backend wiederum scheint die vertikale Modularisierung prima geklappt zu haben. Im Service “Kundenkonto” werden die Daten gespeichert, die ich vom Kunden benötige um ihn in der Plattform zu registrieren. Dabei wird die Validität seiner Angaben entweder über eine EMail oder eine SMS geprüft. Aus diesem Grund haben wir das Thema “Kommunikation” hier mit rein gepackt. Weiters gibt es Services für die “Bestellung”, das “Lager”, die “Bezahlung” und die “Lieferung”. Querschnittliche fachliche Themen wie die Daten des Kunden (Zahlungsweise, Lieferadresse, Rechnungsadresse etc.) haben wir ebenfalls auf diese Services aufgeteilt wie das Produkt an sich (Preis, Lagerstand, Beschreibung etc.).

Das Ziel war Logik und Daten jeweils nahe beieinander zu haben um eine Architektur mit hoher Kohäsion und niedriger Kopplung zu erreichen. Dies ist hier auch ganz gut gelungen, wie ich finde. Würde mir das jemand als Architektur zum Review vorlegen mit der Fragestellubg, ob dies gängigen Best-Practices folgt, hätte ich zumindest auf den ersten Blick nichts zu beanstanden.

Abb. 3: Die einwandfreie Microservice-Architektur unseres Web-Shops

Eine neue Anforderung

Ab sofort soll es in gewissen Fällen möglich sein, frische Schnittblumen bei jeder Bestellung mit auszuliefern. Dies kann entweder über Bezahlung möglich sein, oder ab jeweils einem Umsatz von 1000 Euro einmalig als Gratis-Angebot. Dies ist allerdings nur möglich bei Lieferdiensten, die dabei auch mitmachen. Diese müssen nämlich die Blumen immer frisch bei örtlichen Blumenhändlern abholen. Außerdem ist dies nur möglich, wenn es in der jeweiligen Gegend auch einen Blumenhändler gibt, der mit uns kooperiert. Angeboten wird dies außerdem nur weiblichen Kunden. Für männliche Kunden wird überlegt evtl. später ein After-Shave als Bonus den Paketen beizulegen. Allerdings nur solange auch welche auf Lager sind. In welchem der Bausteine würden Sie diese Änderung verorten? Es gäbe dafür diverse Strategien:

  • Man schreibt einen neuen Service “Geschenke”, der genau dieses Feature abbildet.
  • Man gibt das neue Feature irgendwo dazu, z.B. bei Payment, Bestellung oder Lieferung.
  • Man extrahiert aus den bestehenden Services einen neuen namens “Produkt”, der Daten und Logik der Produkte beinhaltet und dabei die Geschenke als Sonderfall behandelt.

Jede dieser Lösungen führt dazu, dass sich die Kopplung zwischen den Services im Vergleich zur Situation davor vergrößert. Dies allerdings nicht, weil keine gute Arbeit geleistet wurde, sondern weil dies die Anforderungen selbst nötig machten.

Fazit

Es gibt nicht nur qualitative Anforderungen, die eigentlich immer querschnittlicher Natur sind. Es gibt ebenfalls funktionale Anforderungen, welche auf gewisse Weise übergreifend sind. Sie vernetzen bestehende Anforderungen und sind nicht so gut als Modul isolierbar. Sie führen dazu, dass sich die Software in Summe nicht so gut modularisieren lässt. Die Aufgabe ist, eine Struktur zu finden, welche möglichst gut zu den fachlichen Anforderungen passt. Außerdem haben Sie idealerweise noch die Möglichkeit, auf Änderungen der Fachlichkeit zu reagieren, indem Sie im Zuge eines Refactorings eine Restrukturierung vornehmen. Abhängig von der Komplexität der Anforderungen selbst wird Ihnen das manchmal besser gelingen, und manchmal sind dem gewisse Grenzen gesetzt. Wenn Ihnen das gelungen ist, geht es weiter mit dem nächsten der 5 C´s, nämlich: “CONCEAL: Verbergen”.

Software-Entwurf: Ein Blick zurück und nach vorn (5C-Design, Teil 1)

By | Allgemein, Inhaltliches | No Comments

Als in den 80ern und 90ern des vorigen Jahrhunderts die Objektorientierte Programmierung angetreten ist alle Probleme der Entwicklung komplexer Software zu lösen, fasste Robert C. Martin einige Prinzipien des Software-Entwurfs unter dem Kürzel (und Schlagwort) SOLID zusammen. Diese Sammlung an Prinzipien ist auch heute noch populär, obwohl sich seither einiges getan hat. Anfangs der 2000er wurde dann die “SOA-Sau” durchs Dorf getrieben, und heute muss man sich fast schon schämen, wenn man keine “Microservices” macht. Und das, obwohl der Terminus “Microservices” alles andere als exakt definiert ist und eigentlich einige unterschiedliche Architekturstile umfasst. Die SOLID Prinzipien gab es als eine weithin anerkannte Grundlage des Software-Entwurfs dabei die ganze Zeit. Leider waren diese aber keineswegs hilfreich dabei die SOA zu widerlegen, noch kann man sie als Grundlage für gute Microservice Architekturen zu Rate ziehen.

  1. Software-Entwurf: Ein Blick zurück und nach vorn
  2. CUT: Richtig schneiden
  3. CONCEAL: Verbergen
  4. CONTRACT: Schnittstelle festlegen
  5. CONNECT: Verbinden
  6. CONSTRUCT: Aufbauen
  7. It´s a Wrap: Zusammenfassung

Über SOLID

Es war 1999 als Robert C. Martin auf der Basis seiner eigenen Arbeit, und der Arbeit einiger anderer wie Bertrand Meyer und Barbara Liskov, seine Top 5 Prinzipien des objektorientierten Entwurfs festgelegt hat. Später erst fiel es einem gewissen Michael Feathers auf, dass man diese prima unter dem Akronym SOLID zusammenfassen kann. Dass diese Abkürzung der Popularität geholfen hat merkt man alleine schon daran, dass die anderen Prinzipien, die er gleichzeitig für Kohäsion und die Kopplung von Packages festgelegt hat, heute kaum noch jemand kennt. Bei SOLID handelt es sich im Detail um die folgenden 5 Prinzipien:

  • Single-Responsibility Principle: Eine Klasse sollte einen, und nur (!) einen Änderungsgrund haben
  • Open-Closed Principle: Sie sollten in der Lage sein, das Verhalten einer Klasse zu erweitern, ohne diese im Zuge dessen ändern zu müssen
  • Liskov´s-Substitutionsprinzip: Basisklassen müssen durch ihre abgeleiteten Klassen ersetzbar sein
  • Interface-Segregation Principle: Entwerfe kleine Schnittstellen, jeweils passend für einen Anwendungsfall der Benützung der Klasse
  • Dependency-Inversion Principle: Sei immer von Abstraktionen abhängig, und niemals von konkreten Implementierungen

Wie man sieht ging man damals davon aus, dass Software-Entwurf dem Entwurf von Klassen entspricht. Darauf lag auch der Fokus von SOLID. Objektorientierung war damals das, was heute Microservices sind. Sie galten als Patentrezept zur Lösung so ziemlich aller Probleme der Software-Architektur. Unnötig zu erwähnen, dass man das heute anders sieht. Die OOP gilt als überschätzt, und auch wenn man ab und zu auf Vererbung setzt, so gilt doch der Grundsatz: Composition-over-Inheritance.

Dependency Inversion

Wenn auch tatsächlich keiner der 5 Punkte in SOLID falsch ist, so möchte ich doch zumindest die damals gültige Interpretation des Dependency-Inversion Prinzips hinterfragen. Robert C. Martin war der Meinung, dass eine Klasse A, welche die Schnittstelle einer anderen Klasse B benützt nicht direkt von Klasse B abhängig sein sollte. Niemals. Stattdessen sollte A eine Abstraktion der benötigten Schnittstelle festlegen. B implementiert dann diese Schnittstelle. Damit wäre die Abhängigkeit umgekehrt (siehe u.a. Abbildung), wenn man die neu hinzugefügte Schnittstelle als Teil von A sieht. Das hätte den positiven Effekt, dass später die Implementierung der Schnittstelle ausgewechselt werden kann. B kann also durch eine andere Klasse C ersetzt werden, wenn diese dieselbe Schnittstelle implementiert. Heute sieht man es keineswegs so, dass dies immer zu geschehen habe, sondern eher, dass dies in Ausnahmefällen Sinn macht. Eine abstrakte Schnittstellendefinition sollte man nur festlegen, wenn:

  • … es mehr als eine Implementierung davon gibt.
  • … es absehbar ist, dass es in naher Zukunft mehr als eine Implementierung davon geben wird.
  • … die Schnittstelle als möglicher Erweiterungspunkt dienen soll. Dies ist oft bei der Entwicklung von Frameworks der Fall.
Abhängigkeitsumkehr, dem D in SOLID entsprechend

Das genügt hoffentlich als Beleg dafür, dass SOLID keinesfalls als allumfassende Grundlage für zeitgemäßen Software-Entwurf gesehen werden kann. Wenn wir Software in ihre Einzelteile zerlegen, und uns dabei an Best-Practices orientieren möchten, dann benötigen wir etwas anderes, moderneres. Bevor wir so etwas entwickeln, schärfen wir aber noch die Zielsetzung. Schließlich gibt es ja moderne Prinzipien-Sammlungen, wie die der 12-Factor-App. Diese hat als konkrete Zielsetzung, dass sich die damit entwickelten Applikationen zum “Deployment auf modernen Cloud-Plattformen eignen, die Notwendigkeit von Servern und Serveradministration vermeiden”. Ein adäquater Ersatz für Robert C. Martins Prinzipiensammlung sollte sich aber eher um Wartbarkeit von Code drehen.

Die IT in der Legacy Krise

Dass Wartbarkeit ein großes Thema ist merkt man alleine schon an der Zahl der komplexen Softwaresysteme, die inzwischen als “Legacy” bezeichnet werden. Meist meint man damit einen gewissen Kontrollverlust, der sich in Instabilität und steigenden Kosten bei den laufenden Updates (der Wartung) am System zeigt. Um hier für Abhilfe zu sorgen werden wir zunächst eine Blick auf mögliche Ursachen werfen. Sobald das Team die Software nicht mehr versteht besteht die Gefahr des Kontrollverlustes. Das Verhalten bei Änderungen an der Software wird dadurch in hohem Ausmaß nicht-deterministisch und es kommt zu unerwünschten Seiteneffekten. Dies kann ganz banale Ursachen haben, wie das Fehlen einer Dokumentation. Oder es wurde den Entwicklern, denen das System zur Wartung übergeben wurde, schlichtweg nicht die Möglichkeit gegeben sich in den Code einzuarbeiten. Meist ist es aber so, dass das System zu komplex geworden ist.

Über Komplexität

Aber was heißt eigentlich Komplexität? Eine mögliche Definition ist, dass es dabei um die Knoten eines Graphen geht, und die Kanten mit denen diese miteinander verbunden sind. Je mehr Knoten in Summe, und je mehr Kanten in Relation zu diesen Knoten ein Graph hat, desto komplexer ist er. Ein Beispiel für eine sehr hohe Komplexität ist im folgenden Bild dargestellt. Es handelt sich bei den außen dargestellten Knoten um die Klassen eines der Module der OpenJPA , und bei den Kanten dazwischen um die Abhängigkeiten dieser zueinander. Man kann sich leicht vorstellen, dass die Wartung dieses Codes zumindest eine Herausforderung darstellt. Wenn die Entwickler der OpenJPA das Ding auch offensichtlich unter Kontrolle haben, so können wir uns hoffentlich darauf einigen, dass diese Situation keinesfalls als erstrebenswert bezeichnet werden kann. Ich habe jedenfalls noch nie erlebt, dass etwas vergleichbares vorab als Zielbild entworfen wurde. Demnach ist davon auszugehen, dass dies irgendwie “passiert” ist und niemals so geplant war.

Ein Teil (!) der Komplexität der OpenJPA Codebasis im Tool Sonargraph

So geht es weiter…

Nachdem wir nun ein gemeinsames Verständnis der Problematik haben, gehen wir einen Schritt weiter und beginnen mit der Lösungssuche. Wir brauchen ein Modell, welches den Entwicklern der Software hilft, dauerhaft die Kontrolle darüber zu behalten. Dazu ist es nötig die Komplexität, die bei der Entwicklung von Software automatisch entsteht, in geordnete Bahnen zu lenken. Dafür gibt es keinen besseren Weg als die Gesamtkomplexität in ihre einzelnen, danach im Kleinen einfacher beherrschbaren, Teile zu zerlegen. Ziel ist, dass diese einzelnen Teile danach:

  • … möglichst ohne Seiteneffekte und Abstimmungsarbeit weiterentwickelt werden können.
  • … unabhängig vom Rest zu dokumentieren und zu verstehen sind.
  • … an ihren ein- und ausgehenden Schnittstellen isoliert getestet werden können.
  • … unabhängig voneinander ausgetauscht werden können.

Im nächsten Teil dieser Artikelserie beginnen wir gleich mit dem ersten logischen Schritt, nämlich der möglichst effizienten Zerlegung eines großen Ganzen in seine Einzelteile und nennen dies: „CUT: Richtig schneiden“! Dabei handelt es sich um das erste von 5 C´s, welche dann in Summe die moderne Sammlung von Prinzipien zum Software-Entwurf darstellen werden.

xing_workshop Olli

Hands-On Einführung in Machine Learning

By | Allgemein | No Comments

Hands-On Einführung in Machine Learning

Hands-On Einführung in Machine Learning
Peter Götz & Oliver Zeigermann
Workshop
Dienstag, 02. Juli 2019, 9 – 17 Uhr
München

Neuronale Netze sind Software 2.0. Diese Meinung verbreitet jedenfalls Machine Learning Star Andrej Karpathy, Head of AI bei Tesla. Wir beschäftigen uns in diesem Workshop mit dieser These und wie die klassische Software-Entwicklung durch diesen Ansatz ergänzt wird.

Passend dazu lernst du an diesem interaktiven Workshop, wo uns als Software-Entwicklern Machine Learning begegnet und wo sich der Ansatz von
Machine Learning grundsätzlich von dem der Software-Entwicklung unterscheidet und wo es Parallelen gibt.

Anhand eines praktischen Beispiels werden wir dabei Machine Learning als Alternative zu klassischer Business-Logik erleben. Zum Abschluss werden wir diskutieren, wie man einen solchen Ansatz im eigenen Unternehmen oder Projekt integrieren kann und welche Anwendungsfälle sinnvoll sind.

Dieser Workshop eignet sich für jeden, der sich mit Software-Entwicklung beschäftigt und setzt kein Wissen über Machine Learning voraus.

Infos & Anmeldung (Xing)

echo Februar 2019

embarc echo – Februar 2019

By | Allgemein, echo | 2 Comments

Frische Einblicke & Nützliches in Kürze – embarc echo

Finden Sie in gewohnt kurzer Form Anregungen für Ihre Vorhaben – in aktuellen Fachartikeln, Konferenzbeiträgen oder im Blog. Außerdem haben wir einen Starschnitt in Lebensgröße, frisches Referenzwissen und stellen einen unserer neuen Kollegen vor. Ein kleines Goodie für unsere echo-Leser gilt es auch zu finden! Für Frühjahr & Sommer stehen weitere Veranstaltungen in Deutschland & Österreich in Aussicht – unsere Landkarte bringt die nächsten Stationen auf einen Blick zusammen.

Download embarc echo Februar-2019 (PDF, 9 Seiten)

Architektur Meetup Wien

Softwarearchitektur Meetup Wien: Evolutionäre-Architektur & Digitalisierung

By | Allgemein, Publikationen, Vorträge | No Comments

Meetup

 Evolutionäre-Architektur & Softwarearchitektur/Digitalisierung
Impuls und Moderation: Stefan Toth & Herbert Dowalil
Veranstaltung beim Softwarearchitektur Meetup Wien
05. November 2018, 18:00 Uhr
weXelerate, Praterstrasse 1 in Wien

Foliendownload (PDF)

Evolutionäre Architekturansätze können helfen, sich kleinteiliger und stetiger um Innovation zu kümmern und auch mit größeren Systemen über längere Zeit hohe Qualität auszustrahlen. Sie werden mehr und mehr der neue Standard – das neue Normal.

Beim neuen Softwarearchitektur Meetup gestern Abend in Wien gab Stefan Toth einen Überblick, welche Faktoren Softwarearchitektur heutzutage erfolgreich machen, um in einem dynamischen Umfeld zu bestehen. Er stellte den Zyklus evolutionärer Architekturentwicklung vor – von Lernfenstern mit Experimenten und erlaubten Abweichungen vom „Standard“, über weich definierte Regeln und geförderte Innovation bis hin zur eingeschränkten Anwendbarkeit von überholten Konzepten. Dabei spielen aktuelle Konzepte wie Anti-Zähigkeit und Fitness-Functions eine zentrale Rolle. Praxisbeispiele aus realen Entwicklungsvorhaben verdeutlichen die Ansätze. Fast 60 Teilnehmer waren beim Kickoff des Wiener Meetups in den Räumen von weXelerate dabei und es gab einen regen Austausch zwischen Speakern, Besuchern und Organisatoren!

Stefan Toth - Softwarearchitektur Meetup Wien: Evolutionäre-Architektur


Unser nächstes Meetup ist für den 12. Dezember 2018 geplant – wir freuen uns auf den Austausch in Vorträgen, Diskussionen und interaktiven Formaten!

Fotos vom Softwarearchitektur Meetup am 05. November 2018:


















Machine Learning Summit

Interview: Anwendungsmöglichkeiten von Machine Learning

By | Allgemein, Inhaltliches | No Comments
„Anwendungsmöglichkeiten von Machine Learning“ (Interview zum ML-Summit)


Anwendungsmöglichkeiten von Machine Learning
Interview mit Oliver Zeigermann
online im ML-Summit Blog
erschienen am 24. Juli 2018


embarc Vorträge & Workshops auf dem ML-Summit

Oliver Zeigermann, Programm Chair und Trainer auf dem ML Summit, hat im Vorfeld des Events mit dem Entwickler Magazin über die vielfältigen Möglichkeiten zum Einsatz von Machine Learning und Deep Learning gesprochen. In dem Interview zeigt Oliver auf, welche Chancen ML auch für laufende Projekte bietet und womit ein Einstieg in die Arbeit mit Deep Learning möglich ist.

Lesen Sie das ganze Interview und erhalten Sie einen Vorgeschmack auf das große 2-in-1-Trainingsevent vom 1. bis 2. Oktober in Berlin.

zum Interview

embarc echo_Juli 2018

embarc echo – Juli 2018

By | Allgemein, echo | No Comments

Impulse aufgreifen – embarc echo

Finden Sie in gewohnt kurzer Form frische Anregungen aus unseren Konferenzbeiträgen, Fachartikeln oder in unserer aktuellen Blogserie rund um zeitgemäße Architekturstile. Außerdem haben wir Tipps für einen schnellen Einstieg in das Thema Machine Learning, Referenzwissen direkt zum Download und stellen einen unserer neuen Kollegen vor. Mit aktuellen Informationen und einem Ausblick schauen wir zudem auf künftige Termine & Veranstaltungen.

Download embarc echo Juli-2018 (PDF, 8 Seiten)

embarc_echo_Juli-2018 -- Klicken zum Download ...

Oliver Zeigermann, SciPy 2018 Austin – Understanding Machine Learning

By | Allgemein, Vorträge | No Comments
„Understanding Machine Learning by Looking at Simple Visualizations“

Artificial Intelligence & Machine Learning 101



Understanding Machine Learning by Looking at Simple Visualizations
Speaker: Oliver Zeigermann
Scientific Computing with Python, Austin, Texas July 9-15, 2018
SciPy 2018 – Talks and Posters
AT&T Executive Education and Conference Center, University of Texas campus in Austin

Machine Learning can be extremely helpful, but at the same time very hard to get into. So if you are either struggling to understand it yourself or want to help others understanding it, visualizations can be extremely helpful.

We embrace this idea and by looking at plots of a single, simple and intuitive data set we will explain the core concepts and Learning strategies.

The concepts include the difference between programming and machine learning, validation, and over- and underfitting. We will also cover k-nearest neighbors and neural networks.

Scipy 2018

follow us on Twitter – @embarced

embarc echo März 2018

embarc echo – März 2018

By | Allgemein, echo | No Comments

Impulse aufgreifen – embarc echo

Kurz gesagt was wichtig ist.

Finden Sie frische Anregungen und Wissenswertes in aktuellen Veröffentlichungen im Web & in Fachzeitschriften. Dazu einige YouTube-Mitschnitte und kompakt aufbereitetes Wissen für Ihre Projekte. Kurz gefasst geben wir Ihnen die Möglichkeit, Themen nachzulesen oder zu vertiefen – und unser Überblick zu kommenden Terminen & Konferenzen zeigt, ob wir demnächst auch in Ihrer Nähe vor Ort sind.


Download embarc echo März-2018 (PDF, 7 Seiten)

embarc echo Maerz 2018 -- Klicken zum Download ...