Model-View-Presenter anstelle von Massive-View-Controller

Model-View-Presenter anstelle von Massive-View-Controller

Ein Großteil der entwickelten Android Apps verwenden eine typische Model-View-Controller Architektur.  Häufig werden die zunächst überschaubaren Anwendungen Schritt für Schritt erweitert. Der Code wächst zu einem komplexen Gebilde und wird schwer wartbar. Durch die enge Verzahnung der Klassen mit dem Android-SDK ist der Code häufig auch nicht testbarEine Möglichkeit dieses Problem bereits auf der Präsentationsschicht aufzulösen bietet das Prinzip des Model-View-Presenters (MVP).

Read More

Darf’s auch ein bisschen schneller sein?! Webanwendungen mit JavaScript

Darf’s auch ein bisschen schneller sein?! Webanwendungen mit JavaScript

JavaScript ist laut TIOBE Index mittlerweile auf Platz sieben der bekanntesten Programmiersprachen und die Tendenz ist steigend. In der Business IT tut sie sich gegen den Branchenprimus Java aber noch schwer. Dabei ist JavaScript gerade für Webanwendungen ‚state of the art’ und bekannt für schnelle und schicke „Single Page Apps“. Aber warum setzt sich JavaScript bei Unternehmensanwendungen dennoch nicht durch?

Read More

Clean Code Coding Dojo - Fazit eines Workshops

Clean Code Coding Dojo - Fazit eines Workshops

Was ist Clean Code und welche Prinzipien unterstützen einen um sauberen Code zu erzeugen? Diese und weitere Fragen wurden von uns in dem Zwei-Tages Workshop letzte Woche in der HfT beantwortet. Um das theoretische Wissen gleich in der Praxis anzuwenden haben wir mehrere kleine Übungsaufgaben mitgebracht.

Read More

Rückblick: Java Forum Stuttgart 2016 – Best Practice für Software Verbesserung

Rückblick: Java Forum Stuttgart 2016 – Best Practice für Software Verbesserung

Im letzten Beitrag zum Java Forum Stuttgart (JFS) 2016 ging es um die Neuerungen bei JUnit 5. In diesem Beitrag steht ein weiteres interessantes Thema des JFS im Fokus: der wichtige aber häufig vernachlässigte Bereich der Verbesserung bestehender Software.

Erweitern, korrigieren, ändern, patchen, fixen von Software ist ein beständiger und wichtiger Teil der Softwareentwicklung. In der IT-Ausbildung aber auch in der Praxis wird allerdings häufig mehr Wert auf die Neuerstellung gelegt. Das Framework aim42 – systematic software evolution and improvement, ist eine Sammlung von Best Practices und Mustern zur Wartung, Modernisierung, Migration und Verbesserung von Altsystemen. 

Read More

Rückblick: Java Forum Stuttgart 2016 – Das neue JUnit

Rückblick: Java Forum Stuttgart 2016 – Das neue JUnit

Mit einem Besucherrekord konnte das Java Forum Stuttgart (JFS) in diesem Jahr aufwarten. Rund 1.700 Besucher kamen am 07. Juli zum 19. JFS ins Kultur- und Kongresszentrum Liederhalle (KKL). Damit gehört das Java Forum Stuttgart zu den wichtigsten Events der Java Community in Deutschland. Mit rund 50 Vorträgen und zwei BoF-Sessions gab es viel zu lernen und zu diskutieren. Neben der Wissensvermittlung stand aber natürlich auch das Networking im Zentrum der Veranstaltung. Für it-economics war in diesem, wie auch im letzten Jahr, Katharina Knaus als Moderatorin dabei. In diesem und dem folgenden Blogpost gibt’s einen Überblick über die spannendsten Themen und Neuerungen vom diesjährigen JFS.

Read More

WJAX 2015: Wir waren dabei.

WJAX 2015: Wir waren dabei.

Um meine Erfahrungen etwas ausführlicher mitteilen zu können, habe ich mich dazu entschieden, den Blog in mehrere Teile zu splitten. Im ersten und zweiten Teil erzähle ich vom ersten Tag der Veranstaltung, wobei beim zweiten Teil der Schwerpunkt auf der Agilität liegt. Im dritten Teil werde ich kurz auf die interessanten Vorträge der nachfolgenden beiden Tage eingehen. Den letzten Teil der Blog-Reihe widme ich dem Vortrag von Thilo Frotscher „Der glückliche Java-Entwickler“. Ich hoffe, dass Ihnen das Lesen genauso viel Freude bereitet wie mir die Konferenz.

Read More

Wie misst man Clean Code?

Wie misst man Clean Code?

Als Software-Entwickler stehe ich am Ende des Tages mit einer mal mehr, mal weniger großen Menge neuen Codes da und stelle mir die Frage: Wie gut ist das, was ich heute geschrieben habe?

Genauso wie viel andere neige ich aber dazu, nicht immer 100 % objektiv zu sein, wenn ich die Qualität meines Codes selber beurteilen muss. Deswegen ist in unserer „Definition of Done“ festgelegt, dass jeder Code durch einen Kollegen revidiert werden muss. Dadurch erhalte ich eine zweite, unabhängigere Sicht auf meinen Code.

Falls man aber gerade keinen Kollegen zur Hand hat, hilft es auch, nacheinander die Prinzipien des Clean Codes durchzugehen und den Code darauf zu überprüfen, wie gut die Prinzipien dort umgesetzt sind. Und um dem eigenen, wohlwollenden Blick ein wenig Objektivität zur Seite zu stellen, hat es sich für mich bewährt, ein paar Code-Metriken zur Unterstützung heranzuziehen.

Read More

Java 8 - kurz und bündig

Java 8 - kurz und bündig

Java 8 ist seit März 2014 in der Release-Version verfügbar und bahnt sich derzeit den Weg in die ersten Projekte. Zwar findet sich auf http://java.com aktuell noch die siebte Version der Java Runtime Environment, doch die Entwicklerversion JDK 8 kann bereits seit dem Frühjahr 2014 heruntergeladen werden. Passend dazu wurde auch die IDE Eclipse 4.4 Luna fertiggestellt, die Java 8 vollständig unterstützt.

Read More

Einfache Java-Bytecode-Instrumentalisierung

Einfache Java-Bytecode-Instrumentalisierung

In modernen Architekturen ist der Einsatz von Frameworks und 3rd Party Libraries selbstverständlich. Erfolgt die Entwicklung in einem Unternehmen, so sind die Zuständigkeiten für das Gesamtsystem häufig unter anderem zwischen den Teams der technischen Architektur und der Entwicklung verteilt. Besteht das Bedürfnis seitens des Teams Entwicklung, zu Analysezwecken in die Frameworks und Libraries programmatisch tiefer einzugreifen, als von der Architektur vorgesehen, sind solche Änderungen in der Regel mit extra Aufwand seitens Team Architektur verbunden. Neben dem zusätzlichen Aufwand spielen die Sicherheit und die Qualität des Frameworks eine wichtige Rolle – Änderungen im Framework, die nur eine ganz spezielle und unter Umständen einmalig auftretende Frage beantworten, aber nicht in der Produktion wirksam sein sollen, sind zu vermeiden.

Read More

Das Interface Segregation Principle - Nicht nur auf den Schnitt kommt es an

Das Interface Segregation Principle - Nicht nur auf den Schnitt kommt es an

In unserem heutigen SOLID-Beitrag geht es um das „Interface Segregation Principle“. Wie wir im Blog sehen werden, ist dabei weniger die Trennung nach Interfaces das Problem, als vielmehr die an manchen Stellen wieder benötigte, sinnvolle Zusammenführung von Funktionalitäten aus verschiedenen Interfaces eines Objekts.

Vorweg: Die Fachabteilung war ganz begeistert, dass wir neulich die Anforderung zur Aufnahme von nicht registrierten Kunden so schnell und sauber umsetzen konnten. Die ausführliche Geschichte und wie die Anwendung des Liskov Substitution Principle zu einer sauberen Lösung beigetragen hat, kann man im „L“-Blog unserer SOLID-Reihe nachlesen.

Allerdings hat diese Erweiterung den Einfallsreichtum angespornt. Die neue Vision: Zukünftig sollen weitere neue Kundentypen im System eingeführt werden können. Außerdem soll es möglich sein, bestehende Kunden in einen anderen Kundentyp zu wandeln ohne dazu den Kunden im System neu anlegen zu müssen. 

Read More

Das - Liskov Substitution Principle - LSP

Das - Liskov Substitution Principle - LSP

ubtypes must be substitutable for their base types. 

So, das „S“ und das „O“ der SOLID-Prinzipien haben unser Design hinsichtlich der Qualitätsmerkmale wie Wartbarkeit, Testbarkeit und Erweiterbarkeit bereits erheblich verbessert. Wir haben gesehen, dass es Sinn macht, einer Klasse möglichst nur eine Verantwortlichkeit zu übertragen (Single Responsibility Principle) und Programmcode offen für Erweiterungen, aber geschlossen für Änderungen zu implementieren (Open Closed Principle).

Read More

Das Open-Closed Principle (OCP)

Das Open-Closed Principle (OCP)

Software sollte lesbar, modular und wartbar sein. Leider entsteht im Laufe der Entwicklung, vor allem aber auch bei Weiterentwicklungen, immer wieder schlechtes Software-Design. Im schlimmsten Fall treten Programmfehler bei bereits längst getesteten Funktionalitäten auf. Die Beachtung der SOLID-Prinzipien objektorientierter Softwareentwicklung kann helfen, diese Fehler zu vermeiden und Programmcode wartbar zu halten. Insbesondere die Wartbarkeit ist von großer Bedeutung, da man selten Softwareentwicklung auf der grünen Wiese betreibt, sondern in den allermeisten Fällen auf vorhandenem Programmcode aufbaut.

Read More

iOS RoboVM – eine Native Cross Plattform

iOS RoboVM – eine Native Cross Plattform

I mean, Android is Java, so there is a lot of opportunity here for sharing code between Android and iOS (Niklas Therning). Dieses Zitat des Erfinders von RoboVM aus einem Artikel auf Jaxenter.com möchte ich als Einstieg für meine Beschreibung nehmen, wie eine iOS-Applikation mit Java-Code realisiert werden kann.

Read More

Das Single Responsibility Principle (SRP)

Das Single Responsibility Principle (SRP)

There should never be more than one reason for a class to change.

Heute beginnen wir mit dem ersten SOLID–Prinzip: Eine Klasse sollte immer eine einzige Verantwortung haben, oder anders ausgedrückt: Es sollte nie mehr als einen Grund geben, eine Klasse zu ändern (Single Responsibility Principle, SRP).

Das SRP wendet man an, um übersichtliche, leicht erweiterbare und einfach zu wartende Software zu konzipieren.

Read More

Java Fork - Join Framework und effizienter Code

Java Fork - Join Framework und effizienter Code

In diesem Blog geht es um das in Java 7 enthaltene Fork/Join Framework, auch bekannt als JSR-166 Concurrency Utilities, das zum Ziel hat, effizienten Code zu schreiben.
Es gibt diverse Fachliteratur sowie einige Blogs zu dieser Thematik; ich werde am Beispiel der Fibonacci-Berechnung auf die Vor- und Nachteile von Fork/Join Frameworks eingehen.

In Zeiten steigender Taktraten genossen Entwickler die Tatsache, dass ihre Single-threaded-Software durch Hardwareoptimierungen immer schneller ausgeführt wurde. In den letzten Jahren hat aber ein Paradigmenwechsel auf dem Gebiet der Computer-Prozessoren stattgefunden. Dies betrifft neben PCs, Notebooks und Servern auch Mobiltelefone.

Read More

Beideskönner. Wie das Gemini Blueprint Projekt Spring und OSGi miteinander sprechen lässt

Beideskönner. Wie das Gemini Blueprint Projekt Spring und OSGi miteinander sprechen lässt

Es könnte doch eigentlich alles so schön sein.

In der Theorie lernen wir von Programmierers Kindesalter an, wie moderne Architekturen aussehen, wie moderne objekt- und vor allem service-orientierte Konzepte funktionieren. Dass über Bausteingrenzen hinweg munter und verteilt kommuniziert wird, dass ein hoher Wiederverwendungswert einzelner Bausteine zum schnellen voranschreiten in der Projekt-Entwicklung führt und dass wir das Rad nur noch selten neu erfinden müssen. Modernes Programmieren gleicht mehr dem zusammensetzen von Bausteinen zur Entwicklung einer Lösung statt dem klassischen Entwickeln von Bausteinen selbst.

Als Spring noch das allgemein gängige Handwerkszeug war, um Bausteine von Software Architekturen elegant zu entkoppeln, gab es keine Sprachbarriere. Spring-Beans konnten sich wunderbar untereinander und mit Hibernate unterhalten, mit gut zusammengestellten Konfigurationsdateien waren schnell große Projekte aufgesetzt und zusammengepuzzelt.

Nun stellt seit einigen Jahren OSGi die spring’sche Vormachtstellung in Frage bzw. greift unterstützend und maßgebend in neuere Systemarchitekturen ein. Daher scheint es nur folgerichtig, eine verständliche Antwort auf die Frage „Was ist OSGi?“ zu suchen und zu untersuchen inwiefern OSGi mit Spring kombiniert werden kann.

Also, was ist das nun, OSGi und warum gilt es überhaupt darüber nachzudenken zukünftige Systeme in ein OSGi Umfeld zu integrieren, wenn Spring doch unsere Probleme bisher ganz vorzüglich lösen konnte?

Read More

Legacy Code unter Kontrolle - Folge 3, JMockit für Fortgeschrittene

Legacy Code unter Kontrolle - Folge 3, JMockit für Fortgeschrittene

m ersten Blog-Eintrag dieser kleinen Serie habe ich erzählt, warum JMockit eine so wichtige Rolle spielt, wenn es darum geht, eine Legacy-Anwendung zu testen. Im nächsten Eintrag habe ich das wichtigste API von JMockit, das Expectations-API vorgestellt. Als Abschluss zeige ich an zwei konkreten Beispielen aus der Praxis, wie JMockit einem auch in schwierigen Fällen einen Unit-Test möglich macht.

Hier nochmal der Überblick über die ganze Serie:
•    Folge 1: Vorstellung von JMockit
•    Folge 2: Die Grundkonzepte von JMockit. Ein erster Test, der ohne JMockit nur schwer zu erstellen wäre.
•    Folge 3: Zwei schwierige Fälle aus der Praxis: Ein Schaltjahresproblem und ein Singleton-Factory-Lindwurm.

Read More