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.

Dienstag, 2. Dezember 2014

Use latest Vim on MacOSX and Setup

Vim ist neben Eclipse mein zweit liebster Editor für Sourcecode. MacOSX kommt mit einem nicht ganz aktuellem Vim daher, dies ist oft kein grosses Problem.  Man kann mit  dem MacOSX Packetmanager Homebrew eine aktuelle Vim Version installieren:
brew install vim 

Bei einem Aufruf von Vim wird jetzt aber immer noch das alte Vim gestartet. die kann man wie folgt im Terminal beheben:
sudo mv /usr/bin/vim /usr/bin/vim73
sudo ln -s  /usr/local/Cellar/vim/7.4.488/bin/vim /usr/bin/vim

Das alte Vim bleibt so erhalten.

Dann hat man aber auf dem MacBook Pro das Problem dass die Pfeiltasten nicht korrekt funktionieren, sie liefern die Buchstaben A, B, C, D. Ausserdem funktioniert die Backspace Taste nicht. Um dies Beides zu beheben, muss man die die Datei .vimrc im Home-Vereichnis des Users anlegen und sie mit folgen Inhalt versehen:
set nocp

set backspace=2

Neben dem alten Vim bietet MacOSX auch ein veraltetes Git und Maven. 

Dienstag, 11. November 2014

Neues Java Projekt gelauncht: Simple Guitar Tuner

Ich habe auf Github ein kleines Projekt simpleguitartuner gelauncht und das erste Release gebaut. Mit ihm kann sehr einfach die Saiten einer Gitarre stimmen. Im Gegensatz zu den anderen Tuningprogrammen ist dieses sehr präzise bezüglich der Frequenzen. Das Programm wird gestartet: java -jar simpleguitartuner-0.0.1.jar und gestoppt mit CTRL + C. Einfacher geht es nicht. Nach dem Start gibt die Saite an, die man stimmen möchte, dann spielt man die Saite und bekommt das Ergebnis und den Sollwert sehr genau angezeigt. Das geht so lang, bis man das Programm beendet.

Hier die Daten:

Mittwoch, 22. Oktober 2014

Optimierung von If Else in Java

If-Else Konstrukte mit zwei Exit-Points kann auf zwei verschiedene Weisen in Java formuliert werden:
Hier beide Varianten, einmal mit und einmal ohne Kommentare. Dann befindet sich der zweite Exit-Point im Else-Zweig. Welche dieser beiden Varianten ist performanter?

Die Antwort ist, es egal. Aus beiden Code-Varianten wird identischer Byte-Code erzeugt: