Events in Polymer

When playing around in Polymer, we encounter iron signals. Besides normal javascript events, this gives us a lot of options for dealing with events. Lets try it all out!

We can catch events using the on-event attribute:

This calls method push1:

Scroll down for the complete code listing. Or see it on github.

Another way to catch it is using a listener:

We can also fire our own events:

We can catch that in the parent component using the on-event attribute or a listener.

These events will always bubble up to parent components. Even when the event is caught. But never sideways.

So in this situation the methods push, push-parent and push-grandparent will be called, but not push-sibling.

So it’s good to not use too generic names, because the parent component might also use that event.
You can prevent that by prefixing your event names with your component name.

you can stop an event from bubbling up by using event.stopPropagation():

You can also use iron-signals to throw events sideways.

Throw them:

and catch them:

You can also catch them in multiple places.

I recommend against using iron-signals, because it can be hard to find out where the even comes from or will be caught. Use the rule of least power and stay with normal javascript events.

Complete code.

This uses subComponent1:

and subComponent2:

AI movie critic – part 1 – Reading the training data

This is the first of a series of posts. Where we will use machine learning to rate movies. For this task we’re not going to watch all the movies. I assume it’s good enough to just read the plot. We’ll use Markov chains to rate the movies and as an added bonus we can also generate new movie plots for awesome (or terrible) movies.

In this first part we’ll get the data and change it into a more usable format.
We can use the data from IMDB, which is published on Of interest are the plots and the ratings.

Plots look like this:

and from ratings.list:

We’ll combine these and output one file with just a title, one plot and a rating in stars (1 to 5).

Now it looks like this:

next time: Markov chains

You can find all the code on github.

Making a simple stubserver with Drakov

Today I’ll show how you can create a simple stubserver with Drakov.

If you do some frontend programming, you’ve probably already installed npm (Node Package Manager), otherwise here is how you install that.
Then with npm you can install Drakov.

We can specify in a markdown file how the stubserver will behave. Using the rules of api-blueprint. This is normally used to specify what your API will look like and what inputs/outputs there are. Here we use it to actually create these in and outputs.

First let start with some GETs.

After the ## we specify the paths. Underneath that we specify different methods (POST,GET). And how we will respond.
So here we have 3 endpoints.
On root (/) we return some documentation in text format.
On /vegetables we return a list of vegetables.
And specific vegetables under /vegetables/xxx

We can start Drakov with this specification:

Now we can try some requests with curl:

Lets try some POSTs now.

A nice extra because it’s a markdown file is that we can also let Markdown format it to make it even more readable. See

Here we made it so that you can post any JSON object to /vegetables and return with http code 201 (created).

We say it needs to be JSON, so it will not work without the Content-Type header

It will also not work with incorrect JSON (no quotes around eggplant)

It will also not work with JSON that is not an object

We can also define some data structures to parse input.

Show a list (of one object) with the example object.

Shows the example object

The input will need to be a correct JSON object

Now it will fail on a JSON object that is not to our specifications

It will work with a correct vegetable

These examples are also available on

“this” in javascript

In object-oriented languages, like Java, this refers to the instance of the class where you run the method. In javascript this is often also the case, but not always.

In this post we’ll explore some situations. And I give some tips on how to deal with them.

The normal case. The function eat is defined on carrot. And we simply run it. this will refer to the enclosing object, which is carrot, with name “carrot”.

When we define and run eat on the toplevel, this will be the window object, with name “result”.

With the function apply, we can change where the function will run on. This will effectively change the meaning of this.

With bind, we can bind a function to another object. This will create a new function that you’ll have to assign to a new variable. The old function stays the same.
Notice that you cannot override that with apply.

With callback functions, we don’t even need to explicitly use apply to mess things up.

When we use anonymous callback functions inside an object, we have to remember that this does not refer to the object anymore. If we want to use it, we’ll have to assign it to an intermediate variable.

Using this knowledge we can create DSL-like functions with funky usage of this.

But it’s clearer to just use parameters.

And that’s basically the gist of it. You can do lots of funky things with this. But your colleagues (and future you), will be happier if you don’t. Some frameworks with callbacks may use it though, so be alert.

The code also exists on jsfiddle, where you can easily try it out.

Throttling in Akka and Spray

When you want to limit the amount of messages an actor gets, you can use the throttler in akka-contrib. This will let you limit the max transactions per second(tps). It will queue up the surplus.

Here I’ll describe another way. I’ll reject all the surplus messages. This has the advantage that the requester knows it’s sending too much and can act on that.

Both methods have their advantages. And both have limits, since they still require resources to queue or reject the messages.

In Akka we can create an Actor that sends messages through to the target actor, or rejects them when it exceeds the specified tps.

This will return an Accepted or ExceededMaxTps message to the sender.

In Spray we can make a directive that returns with http code 400 when you exceed the maximum.

This can then easily be used in our route.

And to see it in action, I quickly ran curl two times.

The whole code can be found here.



Iterating over a Map in Scala

Iterating over a map is slightly more complex than over other collections, because a Map is the combination of 2 collections. The keys and the values.

We make a Map using tuples. -> is just syntactic sugar for making a tuple.

We get these tuples when we iterate over a Map.


To get the key and the value we could use _1 and _2

But this looks confusing. It’s better to unpack it using case.

We can use map to change the keys of a Map.

If we just want to change the values, it’s better to use mapValues.

And of course our favorite method, flatMap, also works on Maps.

Chaining Options

When we have multiple Options and only want to do something when they’re all set.
In this example we have a property file with multiple configurations for one thing. A host and a port, we only want to use them if they’re both set.

We can chain them using map and flatMap.

Then the following statements are all true.

We can even use a for loop to make it more readable.

JSON parsing in Scala

We can use the Spray JSON parser for uses other than a REST API.

We add spray-json to our dependencies.
Our build.gradle:

We add the imports in JsonApp.scala:

We define our domain class. Then have an implicit variable in scope to define how it should be formatted:

Now we can parse JSON strings to vegetables:

Or output vegetables as JSON:


The whole App:

spray-json documentation:

Keystore without a password

Both the JVM and keytool have problems dealing with keystores without a password.

If you try to get a listing of the keystore it will think you didn’t provide a password and output falsehoods:

It incorrectly lists our key as being a secret key, which it isn’t.

We are able to get the correct output by providing the (empty) password in commandline:

Still we have problems when we want to use the keystore in our application.
So we’ll change it so it has a password. This has to be done in 2 steps.

1. We export the key and certificate to a .pem file.
Import password is empty, just press enter here. But be sure to specify a PEM pass phrase. If you leave that empty, it will not export the private key.

2. Then we create a new keystore with this .pem file.

We can use keytool to check the new keystore. Use the new password here.

After this we can remove keystoreWithoutPassword.p12 and tmp.pem


Load testing our robots API with Gatling

In a previous blog post we made an API with spray.

Now we’re going to load test it.
For this, we will use

In a scala class we can write exactly what and how we want to run the test.
In this test, we will do a post to our API and create a new robot called C3PO.
We will do this 1000 times per second and keep doing this for 10 seconds.
For a total of 10000 C3POs!


If you want to use maven, there is a nice Gatling plugin.
But of course we’d rather use gradle. This works fine too, since we can just run Gatling as a java program.

We can run this test with gradle gatling to get our results.

This is already a pretty neat report. Opening the html file will be even prettier.

Seems like our API can handle 1000 requests/second at least fine. Going higher we’ll have to take some other things into consideration.

  • The amount of connection we can open at once.
  • We’re running both the API and gatling on the same machine now.
  • If we run it on another machine, the network may become the bottleneck
  • Gatling may be the bottleneck.

You can find the whole source here.