Logback is a SLF4J API implementation for logging messages in Java and Groovy. We can configure Logback with a Groovy configuration file. The file is a Groovy script and allows for a nice an clean way (no XML) to configure Logback. If we want to show the logging configuration and see how Logback is configured we must add a StatusListener implementation in our configuration. The StatusListener implementation prints out the configuration when our application starts. Logback provides a StatusListener for outputting the information to system out or system error streams (OnConsoleStatusListener and OnErrorConsoleStatusListener). If we want to disable any status messages we use the NopStatusListener class.

In the following example configuration file we define the status listener with the statusListener method. We use the OnConsoleStatusListener in our example:

Continue reading →

When we use Logback as SLF4J API implementation in our code we can have our logging output send to our console. By default the standard output is used to display the logging output. We can alter the configuration and have the logging output for the console send to standard error. This can be useful when we use a framework that uses the standard output for communication and we still want to see logging from our application on the console. We set the property target for the ConsoleAppender to the value System.err instead of the default System.out. The following sample Logback configuration in Groovy send the logging output to the console and standard error:

appender("SystemErr", ConsoleAppender) {
    // Enable coloured output.
    withJansi = true

    encoder(PatternLayoutEncoder) {
        pattern = "%blue(%-5level) %green(%logger{35}) - %msg %n"
    }

    // Redirect output to the System.err.
    target = 'System.err'

}

root(DEBUG, ["SystemErr"])

Continue reading →

Gradle introduced the continuous build feature in version 2.5. The feature is still incubating, but we can already use it in our daily development. The continuous build feature means Gradle will not shut down after a task is finished, but keeps running and looks for changes to files to re-run tasks automatically. It applies perfectly for a scenario where we want to re-run the test task while we write our code. With the continuous build feature we start Gradle once with the test task and Gradle will automatically recompile source files and run tests if a source file changes.

To use the continuous build feature we must use the command line option --continuous or the shorter version -t. With this option Gradle will start up in continuous mode. To stop Gradle we must use the Ctrl+D key combination.

Continue reading →

In a previous blog post we made an API with spray. Now we're going to load test it. For this, we will use http://gatling.io/#/. 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! RobotsLoadTest.scala:

import io.gatling.core.Predef._
import io.gatling.http.Predef._
import scala.concurrent.duration._

class RobotsLoadTest extends Simulation {
	val baseUrl = "http://localhost:8080" //We need to have our API running here

	val httpProtocol = http
		.baseURL(baseUrl)
		.inferHtmlResources()
		.acceptEncodingHeader("gzip,deflate")
		.contentTypeHeader("application/json")
		.userAgentHeader("Apache-HttpClient/4.1.1 (java 1.5)")

	val s = scenario("Simulation")
		.exec(http("request_0")
		.post("/robots")
		.body(StringBody("""{
						|  "name": "C3PO",
						|  "amountOfArms": 2
						|}""".stripMargin))
		)

	setUp(s.inject(constantUsersPerSec(1000) during(10 seconds))).protocols(httpProtocol)
}

Continue reading →

Suppose I have a List of things on which I want to do something that may fail. In this example I have a List of Strings that I want to turn into a List of Integers.

val strings = List("1", "bla", "4")

Continue reading →

In a previous blog I wrote how to make an API. See here.
Now we'll make a client to use that API. This can be done with spray-client. First we add dependencies for spray-client and spray-json:

apply plugin: 'scala'

version = '1.0'

repositories {
    mavenCentral()
}

dependencies {
    compile group: 'org.scala-lang', name: 'scala-library', version: '2.11.6'
    compile group: 'com.typesafe.akka', name: 'akka-actor_2.11', version: '2.3.9'
    compile group: 'com.typesafe.akka', name: 'akka-remote_2.11', version: '2.3.9'
    testCompile group: 'org.scalatest', name: 'scalatest_2.11', version: '2.2.4'
    compile group: 'io.spray', name: 'spray-http_2.11', version: '1.3.3'
    compile group: 'io.spray', name: 'spray-httpx_2.11', version: '1.3.3'
    compile group: 'io.spray', name: 'spray-json_2.11', version: '1.3.1'
    compile group: 'io.spray', name: 'spray-client_2.11', version: '1.3.3'
}

Continue reading →

Tuesday we had our second ever "Vrolijke Framboos" (Dutch for Happy Raspberry) Java code challenge at JDriven and it was a blast! This year’s challenge was to create a REST service client that would play a number guessing game with the server. After setting up a session you would guess a number and the server would respond with either "lower", "higher" or "bingo". The goal was to guess as many numbers in the two minutes you’d be given. Given the name of the challenge you can probably guess that the target platform would be a Raspberry Pi!

It was an incredible and fun experience and in this post I want to explain how I approached the challenge and how my solution ended up in the second place, making me just miss the opportunity to take home the trophy and a new Raspberry.

Continue reading →

As we all know Javascript gives us the awesome ability to create functions inside functions. This allows us to create private functions which support the main function. It is also something we do often when creating object functions. This structure is used by angular for the creation of providers and directives alike. Every once in a while I personally come to a point where I would like to test these private functions. This is especially true for use cases in Angular such as directives.I'd like to be able to run unit tests for a directive's private functions, but I'd like to do this without having to make them public. The way I do this is by using a concept called reflection. This process actually described by Bob Gravelle in his post 'Accessing Private functions in Javascript' actually exposes the private functions by using the toString method of a function. Before I go into specifics let me say that this article should only be used as an approach  for unit testing. There is a good reason for keeping private functions private and using this concept for application code may very well introduce interesting side effects. That being said let's go into details. In order for us to use this concept we'll need to make some slight changes to our directive. Normally we would declare our Directive Definition Object (DDO) and directly return it. As below:

return {
  restrict: 'E'
  ...
}

Continue reading →

One of the biggest struggles while testing web applications that use AJAX is dealing with the timing issues caused by asynchronous nature of the request. A common solution is using timeouts to wait for the AJAX call to be completed. This could cause lots of timing issues. Using Geb there is a better way to determine that the AJAX call and its callback has been completed.

In this blog post we will test the W3Schools website which has a button on it which executes an AJAX request: http://www.w3schools.com/ajax/ajax_example.asp

Continue reading →

Saturday May 30th was the first NextBuild developer's conference in Eindhoven at the High Tech Campus. The conference is free for attendees and offers a variety of subjects presented by colleague developer's. This meant all talks were very practical and covered subjects encountered in real projects. This adds real value for me to attend a talk. Although it was on a weekend day there were about 150 attendees present. The location was very nice and allowed for a nice, informal atmosphere with a lot of opportunities to catch up.

The day started with a key note talk by Alex Sinner of Amazon. He looked into microservices and explained the features of AWS and especially the container support and the new AWS Lambda service. With the AWS Lambda service we can deploy functions that are executed on the Amazon infrastructure and we only pay when such a function needs to be executed. After the keynote the conference tracks were separated into five rooms, so sometimes it was difficult to choose a track. I went to the talk by my JDriven colleague Rob Brinkman about a Westy tracking platform he built with Vert.x, Groovy, AngularJS, Redis, Docker and Gradle. For those that don't know, but a Westy is a Volkswagen van used for camping trips. Rob has build a platform where a (cheap) tracker unit communicates to a Vert.x module the location of the Westy. This is all combined with other trip details and information in a web application. Every works with push events and the information is updated in real time in the web application. The talks was very interesting and really shows also the power and elegance of Vert.x. Also the architecture provided is a like a blueprint for Internet of Things (IoT) applications.

Continue reading →