Publikationen

  • Zurück zum Server (Teil 3) | Julian Schäfer

    Viele Rendering Patterns wurden bereits in den letzten beiden Artikeln betrachtet. Wir konnten die Entwicklung verfolgen, wie Inhalte zuerst statisch sowie...

    Viele Rendering Patterns wurden bereits in den letzten beiden Artikeln betrachtet. Wir konnten die Entwicklung verfolgen, wie Inhalte zuerst statisch sowie serverseitig gerendert wurden, dann immer mehr Aufgaben auf den Client verlagert wurden, bevor der Trend wieder zurück zum Server ging. Die Kunst besteht heute darin, in diesem Spektrum den optimalen Bereich, den sogenannten Sweet Spot zu finden.

  • Ein breiteres Spektrum – komplexere Patterns (Teil 2) | Julian Schäfer

    Nachdem im ersten Teil die Grundlagen für ein besseres Verständnis davongelegt wurden, wie Inhalte im Web geladen und gerendert werden, wenden wir uns nun...

    Nachdem im ersten Teil die Grundlagen für ein besseres Verständnis davongelegt wurden, wie Inhalte im Web geladen und gerendert werden, wenden wir uns nun komplexeren Ansätzen zu.

  • Spektrum der Rendering Patterns (Teil 1) | Julian Schäfer

    SSG, SSR, CSR, ISR, Prerendering, Hydration, Streaming, Resumability. Einige dieser
    Begrifflichkeiten begegnen einem Entwickler, wenn er oder sie sich mit der Frage

    SSG, SSR, CSR, ISR, Prerendering, Hydration, Streaming, Resumability. Einige dieser
    Begrifflichkeiten begegnen einem Entwickler, wenn er oder sie sich mit der Frage
    beschäftigt, wie Inhalte im Web geladen und dargestellt werden können. Vielen
    ist dabei nicht klar, was sich dahinter verbirgt und welche Stärken bzw. Schwächen
    die Patterns haben. Bringen wir Licht ins Dunkel.

  • Team Cognitive Load | Arnold Franke

    Wer schon in einem Entwicklungsteam gearbeitet hat, der kennt das bestimmt: Schattenboxen mit Problemen, die konkrete Schmerzen bereiten, aber deren Ursache schwer...

    Wer schon in einem Entwicklungsteam gearbeitet hat, der kennt das bestimmt: Schattenboxen mit Problemen, die konkrete Schmerzen bereiten, aber deren Ursache schwer greifbar ist. “Ich komm zu nix!”, “Warum wurde dieser Service schon seit Jahren nicht geupdatet?”, “Bei dem Thema sind wir jetzt der Flaschenhals”, “Diesen Sprint haben wir wieder nicht viel geschafft, es waren zu viele Ablenkungen”. Die schwer greifbare Ursache ist nicht selten die zu hohe kognitive Last – Cognitive Load – des Teams. Aber was ist das genau? Woher kommt das? Und was macht man dagegen? Das wollen wir uns in diesem Artikel mal genauer anschauen.

  • Wie Soziologie und Softwareentwicklung zusammenspielen können | Christian Mennerich, Frederick Meseck

    Heutige Softwareentwicklung wendet häufig Techniken des modernen Domain-Driven Design an. In dessen Kern gilt es, mit geeigneten Kommunikationsmitteln abgeschlossene...

    Heutige Softwareentwicklung wendet häufig Techniken des modernen Domain-Driven Design an. In dessen Kern gilt es, mit geeigneten Kommunikationsmitteln abgeschlossene Kontexte zu finden und in Software zu gießen (Achtung: Conway‘s Law). Die soziologische Systemtheorie nach Luhmann fokussiert auf Kommunikation und nimmt in ihrem Kern die Unmöglichkeit unabhängigen Beobachtens an. Zusammengenommen kann dies ein besseres Verständnis für die Anforderungsfindung und das Zusammenstellen und -arbeiten von Teams liefern.

  • Architekturpatterns in Modulithen – Teil 3 | Arnold Franke

    Javamagazin Heft 2|21: Puh, endlich geschafft. Die Artikelserie geht dem Ende zu. Diese Menge Code zu einem anständigen Modulithen zu formen, war ganz schön...

    Javamagazin Heft 2|21: Puh, endlich geschafft. Die Artikelserie geht dem Ende zu. Diese Menge Code zu einem anständigen Modulithen zu formen, war ganz schön anstrengend. Zum Glück ist er jetzt fertig, alle Arbeit ist getan! Wie? Weiterentwicklung? Wartung und Betrieb? Neue Anforderungen? Das Team skalieren? Technische Schulden? Aber das Ding ist doch ganz neu! Warum müssen wir da schon wieder ran? Tja, machste nix. Oder doch?

  • Architekturpatterns in Modulithen – Teil 2 | Arnold Franke

    Javamagazin Heft 1|21: So manche Codebase macht nur auf den ersten Blick einen aufgeräumten Eindruck. Schön in Packages sortierter Code ohne...

    Javamagazin Heft 1|21: So manche Codebase macht nur auf den ersten Blick einen aufgeräumten Eindruck. Schön in Packages sortierter Code ohne Abhängigkeitsmanagement ist wie ein „auf-geräumtes“ Kinderzimmer, bei dem einem die Lawine entgegenkommt, wenn man es wagt, die Schranktür aufzumachen. Um zu verhindern, dass Abhängigkeitszyklen und wuchernde Queraufrufe den Code zu einem „Big Ball of Mud“ machen, gilt es, höllisch aufzupassen.

  • Architekturpatterns in Modulithen – Teil 1 | Arnold Franke

    Javamagazin Heft 12|20: „Wir haben diesen Legacy-Monolithen, den wollen wir in Microservices aufbrechen“. So einen Satz hört man als Berater in der...

    Javamagazin Heft 12|20: „Wir haben diesen Legacy-Monolithen, den wollen wir in Microservices aufbrechen“. So einen Satz hört man als Berater in der Softwarebranche oft. Auf die Frage „Warum“ erhält man oft die Antwort „Modularisierung“. Denn es herrscht die weitverbreitete Ansicht, dass Monolithen grundsätzlich aus schlecht strukturiertem Legacy-Code bestehen und sich Monolithen und Modularisierung gegenseitig ausschließen. Dass dem nicht so ist, zeigt die Architekturform der Modulithen.

  • Gut beraten, gut entwickelt – Systemisch-agile Sofwareentwicklung | Christian Mennerich, Frederick Meseck

    Informatik Aktuell: In seiner Arbeit von 1968 formulierte Melvin Conway die nach ihm benannte (empirische) Gesetzmäßigkeit: “Jede Organisation, die im weitesten...

    Informatik Aktuell: In seiner Arbeit von 1968 formulierte Melvin Conway die nach ihm benannte (empirische) Gesetzmäßigkeit: “Jede Organisation, die im weitesten Sinne ein System entwirft, wird ein Design erzeugen, dessen Struktur eine Kopie der Kommunikationsstruktur der Organisation ist.” [1] Diese Gesetzmäßigkeit – als Conways Law bekannt – kann auf unterschiedliche Arten und Weisen interpretiert werden (EuroPLoP). Seit einiger Zeit ist auch der Begriff des inversen Conway-Manövers (Inverse Conway Maneuver) bekannt, das sich als Werkzeug versteht, eine Organisation so zu formen, dass das Ergebnis einem formulierten Architekturwunsch entspricht: “Idealerweise sind die technologische Struktur und die Geschäftsstruktur zueinander isomorph.” [2] Dieser von Conways Law konstatierte Isomorphismus, der eine strenge formale Gleichheit zwischen System(design) und der Kommunikationsstruktur im Unternehmen beschreibt, hat also zwei Richtungen. D.h. Änderungen in der Unternehmenskommunikation beeinflussen notwendig die Struktur des Softwareproduktes, und umgekehrt beeinflusst (und steuert) eine Software notwendig die Prozesse, die sie abbildet.