Donnerstag, 29. Januar 2015

Vortrag auf der Konferenz Developer World 2015

Wer möchte kann mich auf der Developer World Konferenz (Link) am 17.4.2015 in Hannover erleben. Zusammen mit Uwe Beßle halte ich den Vortrag: Erfahrungsbericht: Testen von nichtfunktionalen Anforderungen im E-Commerce bei OTTO Hamburg
Das Testen funktionaler Anforderungen ist heute Standard in der Softwareentwicklung und wird gut durch Software unterstützt. Nichtfunktionale Anforderungen werden dagegen derzeit oft nicht ausreichend getestet. Am Beispiel von OTTO.de wird gezeigt, wie verschiedene nichtfunktionale Anforderungen, wie Performance, Lastverhalten sowie Robustheit systematisch als Qualitätskriterien getestet werden können. Es werden Vorgehen, Tests, Tools und Integration in den Entwicklungsprozess beschrieben.

Link zum Konferenzprogramm.

Dienstag, 13. Januar 2015

Code Weaving

Wie immer verursacht der Tiobe-Index immer eine heftige Diskussion unter Softwareentwicklern über die Sinnhaftigkeit des Index und die Erstellung eben dieses Index. Warum ist meine Lieblingssprache nur so weit unten. Das kann doch nicht sein. Wie wird dieser Index eigentlich erstellet.

2014: JavaScript wurde zur Sprache des Jahres. Keine wirkliche Überraschung, bei dem was sich hier in den letzten Jahren getan hat, Unit-Tests, Paketmanager, bessere Libs, hübsche Visualisierungen. JavaScript ist überall mit dabei. Verlierer des Rankings ist sicher Groovy, das es nicht mal in die Top 50 geschafft hat.

Neben diesem Ranking entspann sich die Frage, warum die Softwareentwickler nicht die für das Problem am besten geeignete Sprache einsetzen und die gesamt Applikation zusammenweben aus den Codestücke der verschiednen Programmiersprachen. Das entspricht dann einer Best-of-Beed-Strategie. Der Vorteil, man hat immer das optimale Tool bzw. Programmiersprache um ein Teilproblem zu lösen. Hier ein Beispiel, man steuert eine Servierfarm via Python macht REST Calls mit CURL, verarbeitet numerische Daten mit R. Das alles wird dann zusammen gewoben mit BASH, Ant oder dem Jenkins. Zusätzlich erhält man so eine einfache und sehr gut testbare, modularisierte Software. Aber der Nachteil, es bedarf sehr viel Know-Hows um diese Software zu warten.

Code Weaving ist damit sehr gut für die effiziente Erstellung von Prototypen oder PoC (Proof of Concept) geeignet. Es ist danach sehr einfach für normale Softwareentwickler diesen Code in eine Zielsprache wie Java zu übertragen. Nebenbei können die Daten aus dem PoC als Testdaten für Unit- und Integrationstest genutzt werden. Die scheinbar doppelte Arbeit rentiert sich sehr schnell, weil die Entwicklung des Zielsystems wesentlich schneller und in höherer Qualität möglich ist.

Mittwoch, 7. Januar 2015

Heisseste IT Thema 2014

Das heisseste IT Thema 2014 war hier im Blog: Elastic Search. Dies ist nicht allzu erstaunlich, bei der geringen Menge an Beiträgen, aber es zeigt auch klar, dass Elastic Search, die Alternativen und Big Data in die breite IT Masse einsickern und in den nächsten Jahren zu einem Standardthema werden.

Dienstag, 6. Januar 2015

Gradle Dependencies und Snapshots

Wer als Softwareentwickler den Snapshot Mechanismus von Maven kennt, wird ihn gerne verwenden. Er bietet eine leichte und einfache Weise Software zu testen über die Grenzen eines einzelnen Projektes hinaus. Leider gibt es diesen Mechanismus in Gradle nicht. Die ist ein wirklicher Nachteil von Gradle im Vergleich zu Maven und es ist nicht der einzige Nachteil. Aber das ist hier nicht das Thema.

In Gradle kann relativ einfach lokale Jar-Dateien, z.B. aus einem anderen Projekt als Dependency einbinden:

 dependencies {
          classpath files('../wpt-gradle-plugin/target/lpt-gradle-plugin-0.0.19-SNAPSHOT.jar')

 }

So lassen sich sehr einfach Software-Artefakte aus anderen Projekten einbinden ohne sie permanent auf einen Nexus hochzuladen. Damit entfällt auch das sehr lästige manuelle hochzuholen der Versionenummern in den beiden beteiligten Projekten. Der Nachteil dieser Lösung ist, dass wenn die Har-Datei selber Abhängigkeiten hat, dann werden diese nicht aufgelöst, weil Gradle die dafür notwendigen Informationen fehlen.

repositories {
          mavenLocal()

 }

 dependencies {
          classpath "de.otto:lpt-gradle-plugin:0.0.19-SNAPSHOT"

 }

Ein einfache Lösung die die Vorteile beider Lösungen kombiniert ist die Benutzung des lokalen Maven Stores zum laden der Entwickler-Jar-Datei und dem laden der Dependencies. Um die Har-Datei in den lokalen Maven stören zu bringen muss mann das Maven Target install ausführen:
...
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ lpt-gradle-plugin ---
[INFO] Building jar: /Users/mirkoebert/Documents/workspace/wpt-gradle-plugin/target/lpt-gradle-plugin-0.0.19-SNAPSHOT.jar
[INFO] 
[INFO] --- maven-install-plugin:2.4:install (default-install) @ lpt-gradle-plugin ---
[INFO] Installing /Users/mirkoebert/Documents/workspace/wpt-gradle-plugin/target/lpt-gradle-plugin-0.0.19-SNAPSHOT.jar to /Users/mirkoebert/.m2/repository/de/otto/lpt-gradle-plugin/0.0.19-SNAPSHOT/lpt-gradle-plugin-0.0.19-SNAPSHOT.jar
[INFO] Installing /Users/mirkoebert/Documents/workspace/wpt-gradle-plugin/pom.xml to /Users/mirkoebert/.m2/repository/de/otto/lpt-gradle-plugin/0.0.19-SNAPSHOT/lpt-gradle-plugin-0.0.19-SNAPSHOT.pom
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3.195 s
[INFO] Finished at: 2015-01-06T22:48:13+01:00
[INFO] Final Memory: 17M/171M

[INFO] ------------------------------------------------------------------------

Montag, 5. Januar 2015

Erstellen eines eigenen Grade Plugins

Gradle lässt sich wie fast jeden andere System mittels Plugins erweitern. Ein Plugin ist nichts weiter als eine Jar-Datei die man am besten auf einen Nexus deployed. Über diesen Nexus wird dann das Plugin für andere Gradle-Projekte bereitgestellt. Hier ein typischer Ausschnitt aus der Datei build.gradle.

buildscript {
        repositories {
                maven { url "http://nexus.ebert-p.com:8080/content/groups/public" }
                maven { url "http://repo.gradle.org/gradle/libs-releases-local" }
        }

        dependencies {
                classpath "de.otto:lpt-gradle-plugin:0.0.3-SNAPSHOT"
        }
}


apply plugin: "lpt-gradle"

Mit repositories wird definiert wo nach den dependencies gesucht werden soll. Mit  dependencies wird die Jar-Datei beschrieben, die Code, hier ein eigenes Gradle-Plugin enthält. Mit apply wir das Gradle-Plugin auf das aktuelle Projekt angewendet. Wie Gradle von dem Plugin-Namen zur ausführbaren Klasse kommt wird unten beschrieben.

Zuerst muss das Plugin programmiert werden. Womit man diese Jar-Datei baut ist egal, es ist auch möglich ein Gradle-Plugin mit Maven zu bauen. Wenn man das Gradle Plugin mit Java entwickeln möchte, muss man seine Haupklasse von org.gradle.api.Plugin ableiten.

package com.ebertp.gradleplugin.wpt;

import org.gradle.api.Plugin;
import org.gradle.api.Project;


public final class WptTest implements Plugin<Project> {

@Override
public void apply(Project project) {
System.out.println("Hello Gradle Plugin User, this is Java.");
}


}


Als Zweites muss ein Mapping vom Plugin-Namen zur Hauptklasse definiert werden. Dafür muss eine Properties-Datei mit dem Namen des Plugins unter resources/META-INF/gradle-plugins angelegt werden.

src/
├── main
│   ├── java
│   │   └── com
│   │       └── ebertp
│   │           └── gradleplugin
│   │               └── wpt
│   │                   └── WptTest.java
│   └── resources
│       └── META-INF
│           └── gradle-plugins
│               └── lpt-gradle.properties
└── test
    ├── java

    └── resources

In dieser Properties-Datei wird das Mapping des Plugin-Names auf die Java Klasse definiert:

implementation-class=com.ebertp.gradleplugin.wpt.WptTest


Wichtig, der Plugin-Name hat nichts mit dem Namen der Jar Datei zu tun!

Jetzt muss nur noch eine Har-Datei gebaut werden und auf den Nexus hochgeladen werden.