Mixing Java and Scala verticles in one Java-project

The JVM is a remarkable piece of software engineering not least because of it’s polyglot nature. I wanted to gain from that and write verticles for Vert.x in Java as well as in Scala. I started with a Maven archetype to create the initial project.

Under src/main/java I put my Java verticles, the most important verticle is my StartVerticle that initializes all necessary Verticles:

In my start-method I deploy the verticles of my application. The first deployment is pretty straight-forward: my Java verticle (yes, I’m still using Java 7) that is in the classpath is referenced directly and deployed.

In the next line, I deploy a Scala-based verticle that will be compiled during the start of the application. In my case, I put the HelloScala.scala-script under resources (it’s just a POC).

To tell the Vert.x-runtime that the StartVerticle is the verticle that should be started first, we have to put a file called mod.json directly under resources

Now we can build the application with mvn package and start it with

Pretty cool, isn’t it?

(Recently I’ve realized that there seems to be a bug if I try to build and run the same application as a fat jar, I filed a bug, let’s see).

Update:

Galder Zamarreño recommended to switch from Scala scripts to Scala classes that get compiled like Java classes (which was actually my starting-point). I had to change a few things, but now it works perfectly fine (I updated the example project in GitHub).

The HelloScala-verticle now looks like:

My Starter-verticle now has a small “hook” to avoid ClassCastExceptions:

I had to change a few things in my pom.xml:

And now … it works!!!

Update 2:

We found a way to build Fat-JARs directly using Maven:

JMX metrics for Apache Kafka 0.8.1 (Jmxtrans Chef template for Kafka)

Recently we upgraded to Apache Kafka 0.8.1 and realised that the MBeans slightly changed, here is our latest Jmxtrans configuration (as Chef template):

Problem was: the MBean-names now contain quotes.

JUG-BB-Talk: Production ready Vert.x

Vert.x is a lightweight, high performance application platform for the JVM that’s designed for modern mobile, web, and enterprise applications. In this talk you will learn how to create elastic, resilient, responsive and event-driven applications based on the principle of Continuous Deployment. We will give you some insights on the problems we had experienced during development so far and how we solved them.


Video: Mobile Apps richtig bewerben und monetarisieren

Auf der MTC 2013 habe ich ein paar Sätze zu mobile advertising erzählt, das Video ist hier zu finden.

Zu meiner Verteidigung muss ich sagen: an dem Tag hatte ich leider Fieber :/

Von Zauberformeln, Apfelmännchen und schwarzen Schwänen

Rendite ohne Risiko, welcher Anleger wünscht sich das nicht? 1973 haben Fischer Black und Myron Samuel Scholes die vermeintliche Lösung gefunden und das sogenannte “Black-Scholes-Modell” [1] veröffentlicht (am Modell mitgearbeitet hat auch der Finanzökonom Robert Merton, daher müsste es korrekterweise “Black-Scholes-Merton-Modell” heißen). Das Black-Scholes-Modell ist das bekannteste in der Praxis eingesetzte finanzmathematische Modell zur Bewertung von Optionen. Eine Option ist das Recht, eine bestimmte Sache zu einem späteren Zeitpunkt zu einem vereinbarten Preis zu kaufen (Call-Option) oder zu verkaufen (Put-Option). Mit dem Black-Scholes-Modell ist es – theoretisch – möglich, den fairen Preis einer Option zu jedem Zeitpunkt zu berechnen. Dabei geht dieses Modell von folgenden – idealisierten – Annahmen aus:

  • Es existiert ein vollkommener und vollständiger Kapitalmarkt (Transaktionskostenfreiheit, keine Beschränkung von Leerverkäufen sowie Nichtexistenz von Arbitrage)
  • Die betrachteten Aktien haben keine Dividendenzahlung (im Grundmodell)
  • Es kann beliebig Geld zu einem konstanten Zinssatz geliehen und angelegt werden

Das Black-Scholes-Modell verwendet die geometrische brownsche Bewegung [2] für die Bewertung des zugrundeliegenden Basiswerts. Dieser Basiswert wird auch “Underlying” genannt. Im Falle einer Aktienoption wäre das Underlying der Option die entsprechende Aktie.

Black, Scholes und Merton haben es in ihrer Theorie geschafft, das Risiko bei der Bewertung von Optionen vollständig zu eliminieren. 1997 erhalten Scholes und Merton für die Entwicklung dieses Modells sogar den “Nobelpreis” der Wirtschaftswissenschaftler, den Preis der schwedischen Reichsbank für Wirtschaftswissenschaften, erhalten. Das Black-Scholes-Modell wurde so quasi zur Initialzündung für die Entwicklung moderner Finanzinstrumente. Auch heute noch wird die “magische Formel” tagtäglich genutzt.

Das Black-Scholes-Modell arbeitet mit folgenden Werten: dem Kurs der Aktie (S), dem Ausübungspreis der Option (X) (dem sog. “Strike”), der Laufzeit (T), dem risikolosen Zins (r) und der Volatilität (Kennzahl für die Schwankungsbreite des Aktienpreises) der Aktie (σ). Folgendes Beispiel verdeutlicht die Formel recht gut; am 09. Juni 2003 hatte die Aktie einen Kurs von 23,75$, als Strike-Price nehmen wir 15$ an, eine Laufzeit von sechs Monaten, einem risikolosen Zins von 1% und einer Volatilität von 35% (errechnet aus historischen Daten). Die Black-Scholes-Formel kommt dabei auf einen Optionspreis von 8,88$, der tatsächliche Preis betrug 9,10$ (unter [3] ist ein Black-Scholes-Rechner zu finden).

Der Knackpunkt ist die Volatilität: Mit der Volatilität einer Aktie bezeichnet man deren Schwankungsbereich über eine gewisse Zeitspanne hinweg. Niemand weiß genau, bei welchem Kurs eine bestimmte Aktie in zwei Tagen schließen wird. Aber die Volatilität über zwei Tage gibt einen ungefähren Bereich an, in dem sich die Aktie bewegen kann. Diese Volatilität ist in der Praxis natürlich nicht genau bekannt. Um dieses Problem zu umgehen und dennoch einen Wert für die Votalität einer Aktie festlegen zu können, können zum Beispiel historische Daten herangezogen werden. Dabei betrachtet man, wie sich eine Aktie über eine bestimmte Zeit hinweg entwickelt hat. Weiterhin geht das Modell davon aus, dass der Kurs einer Aktie normalverteilt ist. Diese idealisierte Annahme ist in der Realität aber nicht haltbar. Es gibt immer wieder starke Schwankungen der Kurse. Diese sog. “Fat Tail Risks” werden dieser Verteilung nicht hinreichend berücksichtigt. Von einer Normalverteilung geht im übrigen nicht nur das Black-Scholes-Modell, sondern auch eine ganze Reihe von anderen finanzmathematischen Modellen aus, die auch heute genutzt werden. Das Spiel mit den Annahmen funktioniert so lange ganz gut, so lange es keine “Schwarzen Schwäne” gibt. “Schwarze Schwäne” nennt der Finanzmathematiker und Wissenschaftler Nassim Nicolas Taleb extrem seltene, aber mächtige und unvorhergesehene Ereignisse [4]. “Schwarze Schwäne” sind Ereignisse, die extrem unwahrscheinlich sind und eigentlich nie auftreten sollten. Talebs Conclusio ist: traue keinem “Experten” und keinem scheinbar wasserdichten theoretischen Modell. Das Buch “The Black Swan” wurde im April 2007 veröffentlicht und hat quasi die kurz darauf folgende Subprime-Krise vorhergesehen. In einem bemerkenswerten Artikel in der Financial Times [5] hat Taleb 10 Prinzipien für eine Welt vorgestellt, die mit Schwarzen Schwänen deutlich besser zurecht kommt:

  1. What is fragile should break early while it is still small.
  2. No socialisation of losses and privatisation of gains.
  3. People who were driving a school bus blindfolded (and crashed it) should never be given a new bus.
  4. Do not let someone making an “incentive” bonus manage a nuclear plant – or your financial risks.
  5. Counter-balance complexity with simplicity.
  6. Do not give children sticks of dynamite, even if they come with a warning.
  7. Only Ponzi schemes should depend on confidence. Governments should never need to “restore confidence”.
  8. Do not give an addict more drugs if he has withdrawal pains.
  9. Citizens should not depend on financial assets or fallible “expert” advice for their retirement.
  10. Make an omelette with the broken eggs.

Taleb sieht Risiken nicht als etwas an, das mit der Gauss-Kurve zu beherrschen ist, sondern Risiken sind fraktal, d.h. sie repetieren und multiplizieren sich. Die meisten Menschen kennen Fraktale im Zusammenhang mit dem sog. “Apfelmännchen” [6], einer Visualisierung der Mandelbrot-Menge, benannt nach dem Mathematiker Benoît Mandelbrot [7], auf den sich auch Taleb immer wieder bezieht.

apfelmännchen
Abb. 1: Die Visualisierung der Mandelbrot-Menge, das sog. “Apfelmännchen”

Geradezu Beispielhaft ist der Fall des LTCM-Fonds, ein Fond, der 1994 u.a. von Scholes und Merton aufgelegt wurde und zunächst mit einer Rendite von 30-40% immensen Erfolg hatte. Mit Hilfe komplexer mathematischer Modelle hat der Fond aus minimalen Preisdifferenzen an den Kapitalmärkten Profit erwirtschaften können. Um die notwendigen Renditen zu erwirtschaften, ist natürlich enormer Kapitaleinsatz notwendig. Dazu wurde bereits 1995 ein extremer Kredithebel von 1 zu 28 genutzt (3,6 Milliarden Eigenkapital bei 102 Milliarden Schulden). 1998 beliefen sich die Schulden auf 200 Milliarden Dollar. LTCM hatte Derivate im Wert von schier unglaublichen 1,25 Billionen Dollar in den Büchern stehen. Im selben Jahr tauchte mit dem Staatsbankrott in Russland jedoch ein “Schwarzer Schwan” auf. Russland hat den Rubel abgewertet und dadurch wurden russischen Anleihen über nacht quasi wertlos. LTCM hat in diesen Tagen alleine an einem Tag mehr als eine halbe Milliarde Dollar verloren, da sie falsche Annahmen getroffen haben. Das Problem war, dass zunächst die Aktienkurse fielen und sich durch die Nutzung der selben Modelle durch alle Anleger ein selbst verstärkender Effekt erzeugt wurde. Die Anleger erschufen somit selbst ein Ereignis, dessen Eintrittswahrscheinlichkeit – laut Modellannahmen – sehr gering ist. Jackwerth and Rubinstein haben 1995 auf Basis der geometrischen brownschen Bewegung nachgewiesen, dass der Crash von 1987 ein höchst unwahrscheinliches Ereignis gewesen ist.
“Take for example the stock market crash of 1987. Following the standard paradigm, assume that the stock market returns are log-normally distributed with an annualized volatility of 20%. …On October 19, 1987, the two-month S&P 500 futures price fell 29%. Under the log-normal hypothesis, this [has a probability of] 10^(-160). Even if one were to have lived through the 20 billion year life of the universe …20 billion times …that such a decline could have happened even once in this period is virtually impossible.” [8]

Der Fond musste in einer konzertierten Aktion und mit 3,6 Milliarden Dollar “gerettet” werden. Offensichtlich hat man aus dem LTCM-Debakel nichts gelernt, denn nur 9 Jahre später stehen die Hedge-Fonds und Banken vor dem gleichen Scherbenhaufen. Was als Subprime-Krise begann, entwickelte sich zu einer veritablen weltweiten Finanzkrise mit dem Lehman-Zusammenbruch und “Zombie”-Banken, die durch staatliche Kapitalspritzen am Leben gehalten werden müssen. Ab Ende 2009 – die Finanzmärkte hatten sich wieder ein wenig beruhigt – kam diese Krise in anderer Form wieder zurück: als Europäische Staatsschuldenkrise mit der Fast-Insolvent von Griechenland.

Und wie geht es weiter? Die klassischen finanzmathematischen Risikomodelle wie die Portfoliotheorie von Markowitz [9] oder die Black-Scholes-Formel sind offensichtlich nicht in der Lage, die realen Risiken sinnvoll abzubilden. Das fundamentale Problem all dieser Modelle liegt in den falschen Grundannahmen (rein rationales Handeln, perfekte und effiziente Märkte [10], etc.). Märkte sind nun einmal nicht perfekt, weil die Marktteilnehmer nicht ausschließlich rational handeln. Einer der wichtigsten Schritte ist es, von der Normalverteilung als Basis der Risikomodelle wegzukommen und “fat tails” in die Modelle mit aufzunehmen [11]. Trotz all der Schwächen bleiben diese klassischen Modelle eine wichtige Hilfe bei der täglichen Arbeit, um Risiken einigermaßen sinnvoll bewerten zu können.

tl;dr

Das übliche Risikomanagement im Finanzbereich basiert zum großen Teil auf der Normalverteilung und greift beim Auftreten von “Schwarzen Schwänen” nicht mehr.

[1] http://de.wikipedia.org/wiki/Black-Scholes-Modell
[2] http://de.wikipedia.org/wiki/Geometrische_brownsche_Bewegung
[3] http://www.claus-ebert.de/doc/wertpapiere/optionsscheine/black_scholes_calc.html
[4] http://de.wikipedia.org/wiki/Nassim_Nicholas_Taleb
[5] http://www.ft.com/intl/cms/s/0/5d5aa24e-23a4-11de-996a-00144feabdc0.html
[6] http://de.wikipedia.org/wiki/Mandelbrot-Menge
[7] http://de.wikipedia.org/wiki/Beno%C3%AEt_Mandelbrot
[8] J. C. Jackwerth and M. Rubenstein. Recovering probability distribtions from contemporaneous security prices. Journal of Finance, 1995
[9] http://de.wikipedia.org/wiki/Portfoliotheorie
[10] http://arxiv.org/pdf/1002.2284v2.pdf
[11] https://www.credit-suisse.com/asset_management/downloads/marketing/new_normal_investing_white_paper_042012.pdf

Monitoring JBoss 7.x with Jmxtrans

Monitoring JBoss instances worked out-of-the-box till version 7.x. This release changed a few things in the way how to access JMX-data. First of all, you have to do the same things as for JConsole or VisualVM: you have to add the necessary JBoss-releated JAR-files to your classpath and slightly change the invocation of Jmxtrans.

In the JSON-files, you have to use an JMX-URL instead of server and port. This URL accesses remote-jmx on port 9999 (remote-jmx has to be enabled in your JBoss-configuration):

That’s basically it, now you can use Jmxtrans to monitor your JBoss 7.x-instances.

Artikel: Vert.x im Unternehmenseinsatz

Im aktuellen Java-Magazin ist ein Artikel von meinen Kollegen und mir über “Vert.x im Unternehmenseinsatz. Entwicklung und Betrieb von asynchronen Applikationen mit Vert.x in der Praxis.” erschienen. Einen kurzen Teaser gibt es hier.

Über Feedback und Austausch würden wir uns sehr freuen!

Vert.x and RabbitMQ

Integrating RabbitMQ and Vert.x is pretty easy because the RabbitMQ-driver supports asynchronous interaction. Therefore it’s not necessary to implement a WorkerVerticle that polls queues in an infinite loop. An implementation could look like this:

Pretty easy, isn’t it? And you don’t have to block the event-loop!

Chef Cookbook for Vert.x

I wrote a community Cookbook for Vert.x a few days ago. This Cookbook is suited for Debian and the “RHEL-family” (CentOS, RHEL, Fedora, Amazon Linux). In addition to Vert.x (version 2.0.2), JDK 7 (from Oracle) will be installed. The Java community Cookbook from Opscode made a lot of problems installing OpenJDK, so I switched to Oracle JDK. During installation, a runtime user (user vertx) is created for security reasons so the Java process does not run with root privileges. That means, binding to port 80 is not possible without problems. For Debian, the package authbind is installed additionally and configured as follows:

touch /etc/authbind/byport/80
chown vertx:vertx /etc/authbind/byport/80
chmod 755 /etc/authbind/byport/80

This Cookbook is using ark to simplify the whole installation process which means that Vert.x is installed under /usr/local with softlinks from /srv/vertx. The basic idea of the Cookbook is to use Vert.x as a container, similar to JBoss or Tomcat. That makes production usage, configuration and deployment much easier. Two additional files – vertx and vertx_deploy – are created under /etc/default or /etc/sysconfig, vertx contains general JVM-parameters and vertx_deploy contains the deployed application. During startup both files are read in the runlevel-script/vertx-start-script and Vert.x will use those parameters:

That’s basically how this Cookbook works, if you plan to run Vert.x in AWS (yes, this Cookbook is written for EC2 as well), you just have to do the following:

knife ec2 server create -I ami-c7c0d6b3 -i -S knife -r "recipe[vertx]"

Jmxtrans configuration for Vert.x

Maybe you know this totally awesome async application platform for the JVM called . Often you have a problem monitoring platforms like this one, because there is no proper adapter for your preferred monitoring system. So I wrote a small Jmxtrans-config (as a Chef-template) that reads the defined metrics from the JVM using JMX and pushes the data to Graphite.