Author Archives: Denis Kuniß

Thoughts about Laurence Tratt’s Article “Can We Retain the Benefits of Transitive Dependencies Without Undermining Security?”

Posted on by — No Comments ↓

This is a comment on Laurence Tratt’s blog article “Can We Retain the Benefits of Transitive Dependencies Without Undermining Security?” discussed in the context of the Flow Design approach. Indeed, it becomes more and more terrible to see how the transitive dependencies are becoming overwhelming (just think about the NPM transitive dependencies trees for non-trivial applications). This is definitely a challenge for the future of programming and software development which needs to be tackled. And, I agree with your conclusion that some combination of privilege separation and compartmentalization (like actors) are needed at the end. I’m part of a community Continue reading Thoughts about Laurence Tratt’s Article “Can We Retain the Benefits of Transitive Dependencies Without Undermining Security?”→

Let It Flow in Java

Posted on by — No Comments ↓
Waterfall at Java

As announced in my previous article, where I had introduced Flow Design, I want to show a concrete implementation in Java. The code for this example may be found on GitHub. I will follow the blog article “IODA Architecture by Example” of Ralf Westphal which made a Flow Design and implementation for the following scenario: Build an application that translates a Roman number entered by the user into an Arabic number and vice versa. It may be valuable to read his article too, to get further details. However, I will repeat his steps (sometimes a little bit shortened) for letting Continue reading Let It Flow in Java→

Go Beyond Object Oriented Design — Let it flow!

Posted on by — 2 Comments ↓
Strutured Flowing Water

Why is software engineering so different from all other engineering dealing with real parts? Why is the design of a software system almost not recognizable anymore in the code? I’m quite sure, software engineering can get closer to how other engineering disciplines are doing it. It is possible to make design directly recognizable in code. This blog article series is about a possible approach. Look at this block diagram about an Apple I Video Terminal: It describes in an abstract way the components the video terminal is build from and how they interact and depend on. E.g., data is flowing Continue reading Go Beyond Object Oriented Design — Let it flow!→

How To Set Up a Continuous Integration Process in the Cloud

Posted on by — No Comments ↓

If it’s not on Maven Central, it doesn’t exist! Having a library not on Maven Central or at least on Bintray is not state of the art. I mean, we are in 2016 and most of the developers would like to use Maven, Gradle or other modern build systems for resolving library dependencies against artifact repositories automatically. However, the challenge is not only to get a library into these repositories anyhow, but to get them in automatically through a continuous integration process. I took the opportunity to set up such a process for a standardization organization, members of which are Continue reading How To Set Up a Continuous Integration Process in the Cloud→

Alle Wege führen nach Rom – IODA-Architektur mit XtendFlow am Beispiel

Posted on by — No Comments ↓

Conceptual Art by Cildo Meireles, Madrid – Copyright Maureen Barlin, published under CC BY-NC-ND 2.0 here Nun habe ich endlich mal Zeit gefunden, eine echte nicht-triviale, wenn auch einfache, Implementierung mit XtendFlow zu realisieren. Ich nehme dabei wieder mal, wie so oft, einen Artikel von Ralf Westphal als Vorlage. Er hat in seinem Artikel „IODA Architecture by Example“ für die leicht erweiterte Code-Kata Roman Numerals eine IODA-Architektur designt und in C# realisiert. Etwas Historie Dies hat als erste XtendFlow-Implementierung auf zweifache Weise seinen Reiz. Zum ersten nimmt mir dies Design-Arbeit ab und ermöglicht einen direkten Vergleich zwischen einer C#-basierten und Continue reading Alle Wege führen nach Rom – IODA-Architektur mit XtendFlow am Beispiel→

Alles neu macht der … April – vollständige interne DSL für XtendFlow

Posted on by — No Comments ↓

Die im letzten Artikel vorgestellte Lösung zur Umgehung des Xtend-Problems, welches das Komponieren von Konstruktor-Code mit generiertem Code, erzeugt durch den Active-Annotation-Prozessor, verhindert, ist am Ende eben nur ein Workaround – ein hässlicher noch dazu, bei dem Initialisierungscode im Konstruktor als Java-Code (mit Semikola) niedergeschrieben werden muss. Dies veranlasste mich, noch mal grundsätzlicher über die Formalisierung einer FlowDesign-Spezifikation in Xtend nachzudenken. Ließe sich nicht auch das Anstoßen eines Flusses durch einen initialen Wert oder das Weiterleiten der Berechnungsergebnissen einer Funktionseinheit an einen Ausgabeport  expliziter als durch eine Methodenimplementierung ausdrücken, um auch den Wiedererkennungeffekt beim Lesen zu erhöhen, ähnlich dem Wiedererkennungseffekt Continue reading Alles neu macht der … April – vollständige interne DSL für XtendFlow→

Nachtrag zu XtendFlow

Posted on by — 1 Comment ↓

Im letzte Artikel hatte ich erwähnt, dass eine angezeigte Warnung für die bind Methode der integrierenden Funktionseinheit Normalize eine Unzulänglichkeit des Xtend-Compilers sei und diese in der nächsten Version Xtext/Xtend behoben sein wird. Leider erwies sich die Korrektur in Xtend als schwieriger als gedacht, da eine Lösung die Komponierbarkeit von Xtend-Ausdrücken erfordert, was eine signifikante mit nicht geringem Aufwand verbundene Erweiterung von Xtend's Active-Annotation-Framework bedeutet. Das Xtext/Xtend-Team wusste noch nicht, wann sie das angehen werden. Deshalb habe ich mir noch mal Gedanken gemacht, wie man dieses Problem anders umgehen kann und habe eine Lösung gefunden, die mir im Nachhinein auch Continue reading Nachtrag zu XtendFlow→

Extend Your Flow Horizon – Flow-Design mit Xtend

Posted on by — 1 Comment ↓
Kepler Module in X-Form vor dem Horzont der aufegehnden Sonne vom der ISS aus gesehen

Kepler on the Horizon – Copyright NASA, published under CC here Flow-Design ist ein allgemeingültiges Design- und Programmierparadigma. Ralf Westphal hat dies schon mehrfach gezeigt – natürlich für C#, aber auch für Ruby. Es existiert eine Umsetzung in Java von Olaf Krummnow (leider ist sein Blog nicht mehr erreichbar). Ich habe es hier in meinem Blog für Scala gezeigt. Natürlich ist jede Sprache unterschiedlich stark prädestiniert für Flow-Design – wie prägnant sich Ports und deren Verbindungen spezifizieren lassen. Um es einigermaßen elegant, ohne viel syntaktisches Rauschen ausdrücken zu können, benötigt man schon Lambda-Ausdrücke in der Sprache. Ich will es auch Continue reading Extend Your Flow Horizon – Flow-Design mit Xtend→

Kreisfluß – Rückgekoppelte Systeme mit Flow-Design

Posted on by — No Comments ↓
Möbius Band als Sinnbild eines unendlichen nichttrivialen Zirkels unter einer filigranen Konstruktion

Fita de Möbius – Copyright Flavio Serafini, published under CC here Jede abgrenzbare Software ist ein technisches System. Wikipedia definiert ein technische System als Abbild (Modell) eines in der Regel komplexen technischen Produktes. Dabei werden die Wechselwirkungen zwischen den Komponenten des Systems und zwischen dem System und seiner Umgebung abgebildet und untersucht. Auf Software bezogen erfolgt diese Wechselwirkung durch Informationsflüsse: Eine Eingabe wird vom Software-System in eine Ausgabe transformiert. Das lässt sich bei jedem simplen GUI-basierten Programm verfolgen, welches eine menschliche Eingabe durch Maus oder Tastatur in eine Ausgabe auf dem Bildschirm umsetzt. Dieses System folgt einer linearen Kausalkette: das Continue reading Kreisfluß – Rückgekoppelte Systeme mit Flow-Design→

Mit den Fehlern leben – Fehlerbehandlung in Scala-Flow-Design

Posted on by — 1 Comment ↓

“If debugging is the process of removing software bugs, then programming must be the process of putting them in.” – Edsger Dijkstra Klar, Fehlerbehandlung muss sein, auch in Flow-Design. Dabei sind im Prinzip zwei Fehlerarten zu unterscheiden. Erwartete oder vorhersehbare Fehler – Dies sind Fehlersituation, die Bestandteil des Modells sind, welches mit Flow-Design entworfen und realisiert wird. Sie müssen über das Flow-Design-Modell darstellbar sein, am besten deklarativ. Der Benutzer einer Funktionseinheit wird damit gezwungen, sich mit dem Fehlerfall im Modell auseinanderzusetzen. Unerwartete Fehler – Mit diesen Fehlern muss vor allem die Infrastruktur, die Programmablaufumgebung umgehen können, denn es sind am Continue reading Mit den Fehlern leben – Fehlerbehandlung in Scala-Flow-Design→