Use case of Akka system’s event bus: Logging of unhandled messages

Use case of Akka system’s event bus: Logging of unhandled messages

Akka is a toolkit for building concurrent applications on the JVM using Actor model and relying on asynchronous message-passing.

An actor sends a message to another actor which handles the message by its receive method in case the message type is registered. Look at Akka API and Akka documentation for detailed information.

If the receiver has no matching message type the message cannot be handled i.e. the message is programmatically not expected. An unhandled message is published as an UnhandledMessage(msg, sender,  recipient) to the actor system’s event stream.
If the configuration parameter akka.actor.debug.unhandled = 'on' it is converted into a Debug message. Confer: UntypedActor API, in: Akka Documentation v2.3.7, URL: http://doc.akka.io/docs/akka/2.3.7/java/untyped-actors.html (visited: 2014/11/24).

That’s fine for the configuration akka.loglevel = "DEBUG". But on “INFO” level there is no warning.

To log unhandled messages and that means even to know about such unexpected occurrences of messages you can subscribe an actor to the system’s event stream for the channel akka.actor.UnhandledMessage. This is done e.g. by
system.eventStream.subscribe(system.actorOf(Logger.props()), classOf[UnhandledMessage])

 

object Logger {
  def props() = Props(new Logger)

  val name = "UnhandledMessageLogger"
}

class Logger extends Actor with ActorLogging {

  /** logs on warn level the message and the original recipient (sender is deadLetters) */
  override def receive = {
    case ua@UnhandledMessage(msg, _, recipient) =>
      log.warning(s"Unhandled: $msg to $recipient")
  }

}

This logger actor bypasses the dependency of akka.loglevel = “DEBUG”. The information about unhandled messages is logged to the Akka build-in ActorLogging in the example ahead. But can be logged to the application specific logging component as well.

How to find a vision for your team

vision_road

What is a team vision

A vision is a long term goal – a declaration of the team’s future.

During one of the last retrospectives in our team I was quite excited about the possibility to form a team vision.

Basically a well formulated sentence which would then be hung up in our team room – visible for all internals and externals to drop by.

Why is it important

The team vision should serve as common ground for our day to day work, help with decisions to make and also differ us from other teams respective their doings and paths to follow.

So far to my optimistic theory.

How does it work

The method I tried to apply to form a team vision was like this: In the beginning, the whole team was asked to answer the question:

Why is a team vision important for us?

That should serve for some basic common ideas and get everyone to speed up for the next part.
It worked pretty well and the team came up rapidly with statements like ‘Motivation’, ‘Focus’, ‘Group Identity’, ’Solidarity’, ‘code of behaviour’.

In the next part, the team was asked to form a team vision statement – a statement in which they believe and which they support and also vice versa.
It should follow this pattern:

For (target organization)
Who (statement of the need or opportunity)
The (team name) is a (team classification, category)
That (team singularity, compelling reason for the team existence).

Unlike (current alternative without the team)
Our team (statement of primary differentation).

vision_statement_template

This turned out to be much harder than expected and I tell you why:

Not that the team did not believe in their strengths and abilities – much more the fact that it was nearly impossible to look at the company’s vision and extract a meaningful vision statement for the team blocked all from coming up with something round and smooth.

The team was forced to come up with something to fit in this predefined pattern – a template that was just not the correct one to apply.
Before things got more and more complicated and artificial we decided to not make up something that is not suitable for the team and – in the end even worse – makes them uncomfortable when talking about it.

As you can imagine, this felt quite like a failed approach for me as Scrum Master of the team. However, having let this experience sinked in for a while, it was the correct consequence chosen by the team.

What if something had been published that would serve as a burden rather than something motivational for everyone?
The team gets along as a team quite well – each one supports the others when stuck, we have some rituals and some truly common ground we base our work on.
The vision remains unspoken for now – still it is felt day to day when working in the team. Maybe it needs just some more time before a vision itself is “ready to release” – and therefore visual for everyone.

Why did it fail

What I learned from this experience is that trying to push something like a team vision (statement) is not easy at all.
The reason behind it needs to be explained very well and detailed first. And even then you have to nail the critical slot for the right timing.
This means that – instead of pushing something adHoc – it can be easily released during a coffee talk or team event just at the right point of time – and then feel right.
When the time is right. Stay patient. Inspect and adapt 😉

Did you like the post? Send me feedback. I would love to hear from you!

The Theory of Responsive Websites

Responsive Webdesign

Here at HolidayCheck responsive web design is a big challenge, although we’re all big fans.

I recently joined the company as a Frontend Developer and I have been a big fan of responsive web design for years. The latest article I wrote about the subject is called the Theory of Responsive Webdesign. (Currently only in German, sorry)

Here you have a small teaser…

There is a big difference between responsive websites and good responsive websites, and of course it takes much more than to only consider some CSS improvements. Principles like mobile first are pretty hyped these days, but the challenge is not only a technical one.

Consider loosing 80% of the available space of a desktop screen and try to put everything important inside the mobile version. Designers have to rethink their concepts to provide a good user experience on small devices. Then, step by step, details can be added (progressive enhancement). One of the main benefits of this principle is that adding details is much easier than removing them from an already blown site.

You don’t have to develop everything by yourself, because there are a lot of frameworks out there. Going from the small ones, which only provide a small set of CSS classes for a responsive grid, to the all-inclusive frameworks, which provide a full set of components like buttons, tables and forms.

One of the biggest and most discussed topics in RWD is performance. As there is only one website, the smallest device has to load the entire HTML code. Also images can become an annoying mess, because loading high resolution images on a slow device can be the overkill for loading time. There are some approaches as partial loading to resolve these problems, but as nearly everywhere, there is a lot of space for improvements.

You can read this and many other responsive things in the full article on heise. In the next few weeks I am going to write the practical part of RWD, stay tuned!

Testing REST-clients with “Jersey Test Framework” in specs2

In a “Microservice Architecture” there will likely be the case, that one service depends on another one. So you normally implement some kind of client in the service that connects to the other service. When writing unit tests you can then mock this client and make it behave like you expect. But how do you test the client itself? Therefore you need to mock the other service and make it response as you expect.

For writing tests against a jersey-server there exists the “Jersey Test Framework”. Here you use the jersey application as the system under test (SUT). But you can easiliy use this framework to use the application as a mocked service and run tests against the client using this mocked service.

We are mainly writing our code in scala and therefore writing our tests in specs2. Thats the reaseon why I wanted to find a way how I can use JerseyTest easiliy in my specs tests. Inspired by the project specs2-embedmongo I created a FragmentsBuilder that injects an embedded JerseyService into a spec.

trait EmbedService extends FragmentsBuilder {
  self: SpecificationLike =>

  //Override to configure the application
  def configure(): Application

  // Create a JAX-RS web target whose URI refers to the Jersey application
  def target(): WebTarget = {
    client.target(tc.getBaseUri)
  }

  private lazy val tc = {
    val baseUri = UriBuilder.fromUri("http://localhost/").port(8080).build()
    val context = DeploymentContext.builder(configure()).build
    val tcf = new GrizzlyTestContainerFactory
    tcf.create(baseUri, context)
  }

  private lazy val client = {
    ClientBuilder.newClient()
  }

  override def map(fs: => Fragments) = startService ^ fs ^ stopService

  private def startService() = {
    Step({ tc.start() })
  }

  private def stopService() = {
    Step({ tc.stop() })
  }

}

To use it you only have to mix in this trait and configure your expected behavior as a jersey application.

class EmbedServiceSpec extends Specification with EmbedService {

  override def configure(): Application = {
    new ResourceConfig(classOf[HelloResource])
  }

  "Embed service" should {
    "be able to return 'Hello World!' on a GET request" in {
      val hello = target().path("hello").request().get(classOf[String])
      hello must be equalTo("Hello World!")
    }
  }

}

@Path("hello")
class HelloResource {
  @GET
  def getHello() = "Hello World!"
}

The last thing you have to do is to inject the WebTarget into the Client you want to test.

class HelloResourceClientSpec extends Specification with EmbedService {

  override def configure(): Application = {
    new ResourceConfig(classOf[HelloResource])
  }

  val sut = new HelloResourceClient(target())

  "HelloResourceClient" should {
    "return 'Hello World!' on getData" in {
      val hello = sut.getData()
      hello must be equalTo("Hello World!")
    }
  }

}

class HelloResourceClient(target: WebTarget) {
  def getData() = {
    target.path("hello").request().get(classOf[String])
  }
}

That´s it. Have fun writing clients from now on!