Sonntag, 18. Oktober 2015

The 2nd Most Important Task of a Software Developer

The most import task of a software developer is to write code. Well, this answer was pretty easy. Really, yes! But what is second most important skill. I ask my colleagues, first guy says, watching youtube - nice but wrong, 2nd guy: write good documentation - good shot but also wrong.
For me and I'm confident that I'm right, the second most important task of a software developer is to delete code. The first important task is to write code and the second important task is to delete code.
I don't mean delete bugy code, I mean delete working code. Why should you do this?

We have limited time and limited count of developer, this means, we have a more or less constant velocity developing code. If our code base grows, we spend time for maintenance code an we have less time for developing new features, an so on and so on util we reached standstill.

To avoid the standstill, we suggest following tasks to reduce the code size, it a little bit like the Simplify your Life Literature

  1. remove dead code
  2. refactor code to build simpler and shorter code
  3. reimplement code in an effective way, change tools, ... 
  4. delete working code if there is users don't require the function anymore
If somebody say's that we keep this function because, we may use them - then remove the code. The word may is the indicator to remove the code. If we delete to much code, don't worry. Most of the times it cheaper to rewrite a little peace of code instead of keeping all old code fragments.


Here some link illustrating the problems:

  1. Linux Maintainer needed, because of heavy load and huge Code base http://www.golem.de/news/linuxcon-dem-linux-kernel-fehlen-maintainer-1510-116749.html
  2. Linux is planning to remove EXT3 filesystem http://www.pro-linux.de/news/1/22532/ext3-dateisystemtreiber-soll-aus-linux-entfernt-werden.html


Dienstag, 13. Oktober 2015

Log Jmeter Variables with Flexible File Writer

There is no easy way to write a JMeter variable into a standard log file. Also the flexible file writer is not able to use calculated variables into the log file. The flexible file writer is only able to use the properties of the previous sampler. These properties are fixed. So I use a small hack to implement this functionality in Jmeter.

First is calculate a variable called CACHE_INFO e.g. with the regular expression extractor.

Second, I use the BeanShell PostProcessor to overwrite an unused property, here I use ThreadName, of the previous sampler.


Third, I use this abused sampler property with the flexible file writer.

Donnerstag, 8. Oktober 2015

Avoid double software development? No!

In the many cases of software development like this, double work is a better opportunity. Reasons there for:

1)
If you try to avoid double work, you have to spend significant time to collect the requirements and to coordinate the work. You don’t reduce the time you need to develop a working software solution. Let me illustrate that, if you speak every week with 8 people for 1,5h for four weeks, then you have spend 60h of working time plus one week for software development, makes total 100h. If two developers build two solution, you spend only two weeks, total 80h. One additional reason, too much and too less communication frustrates developers easily.

2)
If you develop two proper working solutions, you can decide for better solution. This means, if you has developed only one solution, your chance is 50% to have the worst solution. If you select one solution from two, you chance is 100% to have not the worst solution.

My advise is in the first develop round, every team are allowed to develop his own solution. This mean share nothing. In the next round,  the development teams can decide to switch to one solution, to the better one or to decide to develop an better third solution with the experiences of booth early versions.

Freitag, 18. September 2015

How to setup routing with Cisco VPN an Mac OS X

If you are using the build-in Cisco VPN Client in Mac OS X, you can also route your normal request beside the VPN tunnel. In the common OpenVPN client Tunnelblick, it's easy to setup these routes in the config file.
With the build-in Cisco VPN client, there is no preferences for these routes. The solution is to add these missing routes via Terminal.

Your local network has IPs like 192.168.1.X

sudo route -nv add -net 10 -interface utun0
This line routes all IPs starting with 10 through the VPN tunnel. 10 is here the net on the other side.

sudo route change default 192.168.1.1
This line route all other requests through through your local gateway (router). In my local network my gateway has the IP 192.168.1.1 an I have an 192.168.X.X local network.

Montag, 7. September 2015

Vortrag auf der Hamburger Konferenz Solutions

Ihr könnt mich und das SCALE Team von OTTO auf der 2015 Solution Hamburg erleben. Hier stehen wieder die nichtfunktionalen Anforderungen wie Robustness, Performance, Load und Security im Mittelpunkt.

Datum und Ort:
09. – 11. September 2015
auf Kampnagel in Hamburg

Freitag, 26. Juni 2015

Robust Code: Security Counter and Endless Loop

Eines der typischen Probleme bei der Entwicklung von Code sind Endlos-Schleifen. Von Ausnahmen mal abgesehen sind Endlos-Schleifen in der Regel nicht erwünscht. Leider entstehen sie durch scheinbar einfachen Code, der scheinbar korrekt ist. Hier ein Beispiel, von der Initialisierung eines Objektes, das selbst ein externes Subsystem (ZAP) initialisiert und dem entsprechend darauf wartet:

private void waitForStart() {
    while(!this.isZapDaemonUp() ) {
  sleep(1000);
        }
}

Das Problem an dieser Schleife ist, dass wenn das Subsystem nicht startet, dann hängt das eigentliche Programm in einer Endlosschleife. Der Benutzer kann das nicht erkennen. Eine robuste Lösung besteht darin einen Sicherheit-Counter einzuführen, der nach er gewissen Menge an Versuchen den Code abbricht.

private void waitForStart() {
     def secCounterStartup = 0;
     while(!this.isZapDaemonUp() ) {
         secCounterStartup++;
         log.debug "waiting for ZAP"
         sleep(1000);
         if (secCounterStartup > 20){
                throw new Exception("Zap does't start up.");                                           
         }
  }
  sleep(2000)
}

Montag, 8. Juni 2015

Json Processing in der BASH mit JQ

JSON ist nicht das schönste Datenformat, so gibt es keine Kommentare in JSON. Aber zur Zeit braucht man JSON es an vielen Stellen, z.B. um Elastic Search Abfragen zu stellen bzw. die Elastic Search Results auszuwerten. Wer mit der Bash arbeitet wird JQ als Anfragewerkzeug zu schätzen wissen. Ein immer wieder auftauchendes Problem sind Keys in JSON, die böse Zeichen enthalten wie / oder - (Slash, Minus) die bei Abfragen via JQ escaped werden müssen.

jq .hits.hits[3]._source.http-rc result2.0.json 
error: rc is not defined

.hits.hits[3]._source.http-rc                           1 compile error

So geht es richtig:

jq '.hits.hits[3]._source["http-rc"]' result2.0.json 
"200"


Was lernen wir daraus? Bezeichner, Keys, Namen im Camel Case setzen! Das spart viel Zeit, bei deinen Kollegen.

Hier als Ergänzung der Link zu Googles JSON Style Guide: http://google-styleguide.googlecode.com/svn/trunk/jsoncstyleguide.xml#Property_Name_Format

Sonntag, 15. März 2015

Installieren eines R Paketes mit Hilfe eines eigenen TMP Verzeichnisses

In einigen Linux Installationen ist das TMP Verzeichnis nicht ausführbar. Dies ist eine Sicherheitsmassnahme die leider auch das Arbeiten erschwert.  Die Installation von R Paketen benutzt das TMP Verzeichnis als Ablage der zu installierenden Pakete. Einige R Pakete werden auf dem Zielsystem kompiliert. Dazu wird configure ausgeführt, dies schlägt Fehl auf diesen so geschützten Systemen. Um das Problem zu umgehen, muss  das TMP Verzeichnis das R benutzt, explizit gesetzt werden. Danach kann das Paket installiert werden.

Sys.setenv(TMPDIR="/home/jenkins_slave")
install.packages("sqldf")

Montag, 2. Februar 2015

Wachsende Bedeutung von R

R ist im universitären Umfeld eine durchaus Gebräuche Sprache und Analyse Software. Der Hauptvorteil der Software liegt in ihrer günstigen Beschaffung, R ist GPL. Aktuell legt R im Tiobe Index stetig zu, zur Zeit erreicht es (01-2015) Platz 18. Dieser Trend wird sich weiter gehen, in den nächsten Jahren ist ein R, Abwahl es eine Spezialsprache für statistische Auswertungen ist, zulegen. Natürlich wird es nie die Verbreitung eine Generell Purpose Sprache wie Java oder C erreichen. Generell gibt aber den Trend der Diversifizierung der Programmiersprachen. Das heisst, es wird keine  übermächtige Programmiersprache geben, sondern ein guter Strauß an Programmiersprachen, die unterschiedliche Ding gut können, neben einer Handvoll Generell Purpose Sprachen. Siehe auch http://programming-2.blogspot.de/2015/01/code-weaving.html
Die Gründe für eine wachsende Bedeutung und Verbreitung von R ist der, das man Big Data heute beherrscht, dass diese Daten auch ausgewertet werden müssen. Jüngst hat Oracle bekannt gegeben, das R durch die Datenbank selbst ausgeführt wird und dies auch noch parallel. Bei Oracle heisst das dann gleich Oracle R Enterprise. Neuerdings ist auch Microsoft auf R Analyse Pfaden und kauft die Firma Revolution Analytics (Link).
Splunk als Platzhirsch bei den kommerziellen Big Data Lösungen bietet etwas ähnliches, sehr einfallsreich R Projekt heisst. Sprung scheint aber noch im Bereich R noch nicht das Niveau von Oracle erreicht zu haben.
Im Open Source Bereich gibt es nichts entsprechendes. Natürlich kann man OS Bereich alles selber bauen. Optimal wäre wenn die Daten nicht zwischen Server transferiert werden müssten und man auch alle Prozessoren und Hauptspeicher der Server nutzen könnte. D.h. optimal wäre eine Integration von R in Elastik Search selbst.
Um das Bild weiter abzurunden, noch der Hinweis auf einen Analyse Software Stack, AMPLab der UC Berkley.

Sonntag, 1. Februar 2015

Splunk Alternativen

Wenn es heute um professionelle Big Data Lösungen oder Log File Analysen geht, dann ist die häufigste Antwort Splunk. Sprung ist wirklich eine gute Softwarelösung, skaliert gut und lässt sich sogar auf dem Laptop installieren. Für viele Anwender sind die Lizenzkosten der Hauptnachteil von Splunk. Deshalb schauen sich viel Unternehmen nach FOSS (Free and Open Source Software) Alternativen um. Je nach Anwendungsfall bieten sich zwei ähnliche Verfolger an, Elastic Search mit Kibana oder Graylog2. Graylog2 ist eine Java-Anwendung, Kibana ist JavaScript. Beide sind ein Elastic Search Frontend, Graylog2 geht aber noch darüber hinaus und bietet weitere Management-Funktionen bzw. ein Monitoring an.

Im Alltag sind sowohl Kibana als auch Graylog2 gut einsetzbar, man merkt ihnen aber noch deutlich ihr junges Alter an. Es gibt immer Dinge die fehlen. Keines der beiden Systeme kommt an den Funktionsumfang, die Benutzbarkeit oder die Robustheit von Splunk heran. Man muss klar sagen,  das Splunk zur Zeit mehrere Jahre Technologievorsprung hat gegenüber den beiden Verfolgern Kabine und Graylog2. Um den Technologiestack im Analysebereich abzurunden, sollte man noch R oder ggf. Python hinzuziehen. Alle Systeme nehmen Anfragen via REST-API entgegen. Leider liefert Elastic Search (Kibana, Graylog2) nur Daten als JSON. JSON ist wie XML für schnelle Datenanalysen nicht optimal geeignet und muss umgewandelt werden z.B. CSV.

Man kann Big Data Lösungen natürlich auch mit einem ganz anderen Softwarestack umsetzen, z.B. mit konventionellen relationalen Datenbanken und oder Filesystemen.

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.