Tag: Java

Posted on

Akka

Something else I picked up at Devoxx is Akka. I had heard of it before. Following a session about it renewed my interest.

Akka is a framework created to address problems in creating highly scalable and concurrent software. It is also the name of a mountain in Sweden and a Goddess.
Akka’s Keywords are: concurrency, scalability, fault-tolerance
Akka tries to address system overloads and is currently used in finance, telecom simulation, e-commerce and betting system. All applications that need a lot of event driven actions.
If you have heard of the Play framework, it will be using Akka internally from 2.0 on.

An Akka application uses Actors. What’s an actor: an object that encapsulates state and behaviour. Actors talk to each other as like they send mail. They don’t wait for each other. ( e.g. an actor could be every user in a mmorpg)

Some actor features: Continue reading “Akka”

Posted on

Stop sleeping, start awaiting

On Devoxx there was a quicky session named ‘Stop sleeping, start awaiting’

The speaker presented Awaitility. A test-framework for helping you out waiting on objects. Mainly usable for testing asynchronous code in unit testing. A unit test does not wait for code to be executed, developers tend to use Object.sleep(xxx) but this will not always work. On some systems the xxx needs more milliseconds then on others. In the end you’ll be waiting ( rather sleeping) while all the tests that have sleep() run. The whole testsuite will go very slow.

Awaitility is a framework to help you wait for code to be executed,
It goes like:

await().untilCall(wrappedCallMethod).statusOf(xxx).is(OKAY);

It’s like a mocking framework. Personally I do the same with mockito and java.util.concurrency waiting and locking classes. But perhaps Awaitility will make you create the tests faster.

This is certainly one framework I will try out!

Posted on

JRebel time-savings

I’ve been using JRebel for little more then a month now on the yellow pages project. It think it’s safe to say it saves me about a day of waiting for deployments in a 30 day time frame.
UPDATE: I forgot to mention, on those 30 days I worked only 12 days. I think JRebel stats don’t take that into account so it’s more like 2 days in 30.

In the previous post I wrote that the actual time savings is probably a bit less because you can do other stuff. But during Devoxx Joachim claimed ‘you safe more then JRebel shows you’. And you know what, he’s right.

What happens without JRebel?

You deploy, restart server. During waiting time you check email or twitter or stare outside thinking … (fill in what you do). This means you get distracted from your ‘coding flow’. You get distracted more often then every 25 minutes.

What happens when JRebel is active?

You don’t deploy, JRebel does that for you when hitting a page that has changed Java code behind it. This means you don’t start reading email or twitter or … Hence you don’t get distracted and can stay in your ‘coding flow’. You don’t have to refresh your memory every time you turn back towards your IDE to pick up where you left before deploying and reading email or …. Consequence: you can keep writing code and don’t get distracted, most likely resulting in better code.