Nicht-funktionale Anforderungen: Seamless Deployment

Ein System soll unter Last deployed werden können ohne das es negative Auswirkungen auf den Kunden hat, das bezeichnet man als Seamless Deployment. Vor allem ist diese Anforderung wichtig, weil durch das Heute übliche Continuouse Deployment (CD) permanent neue Softwareversionen released werden. Dieser Test muss unter üblichen Lasten d.h. Volllast durchgeführt werden.

Bad Code: Multiple Exit Point Problem

Lange war mir nicht klar warum multiple Exit Points ein Problem sein sollen. Sei sind eine einfache Möglichkeit schlanken und einfachen Code zu schreiben. Bis jetzt.

Ich muss gerade bestehenden Code für Monitoring instrumentalisieren, das mache ich auf sehr einfache und verständliche Art mittels System.currentTimeMillis().  Das Hauptproblem sind multiple Exit Points:

1. Exit Points können übersehen werden. Das passiert bei langen Methoden manchmal nicht sehr schnell. 
2. Das Code auf Try Blöcken entfernt werden (Premature Optimization) und ich Code umkopieren muss um die Logik zu erhalten. Oder anders ausgedrückt: Code der eigentlich zum Try gehört aber sich nicht im Try Block befindet. Er steht nach dem letzten Catch, welche return Anweisungen enthalten. Dieser Code muss wieder in den Try Block eingefügt werden.

Fazit:

1. Multiple Exit Points sind keine gut Idee, 
2. Ausser die Methode ist ein 5-Zeiler.
3. Unit-Test sind die Basis des erfolgreichen Refactorings.

Zurück auf den alten Stand mit Git

Wenn man z.B. den Master oder einen wichtigen Branch zerstört hat und auf einen funktionierenden Softwarestand zurückkehren möchte muss man folgende zwei Schritte durchführen:

1) Den HEAD auf den entsprechenden funktionierenden Commit zurücksetzen und diese Änderung auf den Master pushen:
git revert --no-commit 14y6c335..HEAD
git commit
git push
Jetzt funktioniert der Master und Head wieder.


2) Lokal sind noch die alten, also die defekten Daten vorhanden, die kann man jetzt ggf editieren oder einen neuen Branch erzeugen oder einfach zurücksetzen. Dann ist die lokale Kopie wieder identisch mit dem Master und Head.
git reset HEAD --hard

Docker: Oracles Java auf einem Ubuntu Image

Das geht ganz einfach, bei den meisten gängigen Images bekommt man OpenJDK oder die Images sind nicht gewartet. Also hier eine relativ einfache, mögliche Lösung:

FROM ubuntu:latest

MAINTAINER mirko.ebert@g****.com

RUN apt-get update; apt-get -y upgrade

RUN apt-get -y  install software-properties-common

RUN add-apt-repository ppa:webupd8team/java

RUN apt-get update

RUN echo debconf shared/accepted-oracle-license-v1-1 select true |  debconf-set-selections

RUN echo debconf shared/accepted-oracle-license-v1-1 seen   true |  debconf-set-selections

RUN apt-get -y  install  oracle-java8-installer

RUN apt-get clean

R Package Helper: Finden aller benötigten R Pakete

So kann man alle R Pakete in einem Projekt finden und in eine Datei schreiben.

grep -r -h library src | tr -d '()' | tr '"' ' ' | awk '{print $2}' > DEPENDENCIES.txt

Später kann man diese Datei im Dockerfile verwenden um im Docker alle benutzen R Pakete zu installieren:

COPY DEPENDENCIES.txt /DEPENDENCIES.txt

RUN cat /DEPENDENCIES.txt \

    | xargs -i Rscript -e 'install.packages("{}", repos="http://cran.us.r-project.org")'

Awesome macOS command line tools

Eigentlich ist dem Titel nichts mehr hinzuzufügen. Unter https://github.com/herrbischoff/awesome-osx-command-line findet man eine sehr gute Sammlung von oft unbekannten macOS Commandozeilen Werkzeugen und Aufrufen die das Leben für Terminal-fixierte Leute auf dem Mac deutlich erleichtern. Ein paar der Sachen liefen bei mir schon. Jetzt haben ich neue Dinge um die Arbeit zu vereinfachen.

Robustness Test Scenario: Slow Down Connection via Command tc

Ein Robustness Test Szenario ist die langsame Verbindung zwischen Servern. Der Grund für so eine Störung können vielfältig sein, liegen aber meistens im Bereich Last, Lastenverteilung und fehlerhafte Software. Konkret können massives Logging (Debug Schalter in Live vergessen) zu massiven Schreiboperationen führen, wenn die Festplatte nicht lokal ist sondern per NAS bereitgestellt wird, kann dieses Logging auch andere Diensten Beeinträchtigen, weil das NAS ausgelastet ist.

Dieses Szenario kann jetzt auf verschiedenen Wege simuliert werden. Man kann das Logging simulieren oder man kann die Netzwerkschnittstelle drosseln. Bei SSH Verbindungen ist dies einfach, dort gibt es einen passenden Schalter, den gibt es auch bei CURL und Webbrowser wie Chrome können das auch. Aber es gibt für Linux auch einen allgemeineren Weg mit dem Commando tc. TC steht für Traffic Control und erlaubt das Drosseln der Verbindungsgeschwindigkeit (Bandbreite, bandwidth) und eine Erhöhung der Netzwerklatenz (ping, tarif shaping).

Hier ein kleines Beispiel.

Ein Ping auf Google.com Dauer etwas länger als 9ms.

Jetzt fügen wir 500ms Latenz hinzu.
sudo tc qdisc add dev eth0 root netem delay 500ms

Jetzt benötigt der Ping 509 ms.

Danach noch alle Änderungen rückgängig machen.
sudo tc qdisc del dev eth0 root

Das gleich funktioniert auch mit der Begrenzung des Traffic Durchsatzes. Neben Robustness Test lassen sich auch Web Performance Messungen mit unterschiedlichen Anbindungen (3G, UMTS, ...) simulieren.

Link:

1. http://mark.koli.ch/slowdown-throttle-bandwidth-linux-network-interface