Testing akka: turn on debug

Testing is easier when you can see what messages are received by your actors. To do this, add logging to your real code, and then change your configuration. This post shows how to hard-code some debugging configuration for testing purposes.

Step 1: put logging into your receive method, by wrapping your existing receive definition in LoggingReceive:

import akka.event.LoggingReceive
def receive = LoggingReceive({ case _ => “your code here” })

Step 2: In actor system creation, put some hard-coded configuration in front of the default configuration.

val config: Config = ConfigFactory.parseString(“””akka {
         loglevel = “DEBUG”
         actor {
           debug {
             receive = on
             lifecycle = off
val system = ActorSystem(“NameOfSystem”, config)

Now when you run you’ll see messages like:

[DEBUG] [01/03/2014 16:41:57.227] [NameOfSystem-akka.actor.default-dispatcher-4] [akka://Seqosystem/user/$c] received handled message Something

Step 3: This is a good time to add names for your actors at creation, so you’ll see them in the log. 

val actor = system.actorOf(Props(new MyActor()), “happyActor”)

[DEBUG] [01/03/2014 16:41:57.227] [NameOfSystem-akka.actor.default-dispatcher-4] [akka://Seqosystem/user/happyActor] received handled message Something

Now at least you have some indication of messages flying around during your tests. Do you have any other pointers for debugging actor systems?


Daily JavaScript: empty objects

How do you test whether a JavaScript object is empty?
The short answer (if you’re using JQuery) is:


The longer answer is, you loop through its properties. This is the method JQuery is using.

for(var prop in obj) {
// it is not empty if this hits

The even longer answer is, you loop through its properties and check that they really belong to it. Properties added to the prototype will come up in this loop, and you might not want to count those.

for(var prop in obj) {
if (obj.hasOwnProperty(prop) {
// it is not empty if this hits

The loop variable there (prop) is a string which is the property name. Here’s a handy fiddle to insert the results of this into an unordered list:

your_object = {"armadillos":"are brown","carrots":"are fun too"};

function addObjectToList(my_object){
for(var property in my_object) {
  • '+property+': '+my_object[property]+'
  • '));


    Stupid git tricks: transferring part of one git repo to another

    Reference post. Don’t expect this to be interesting.

    We had a particular subdirectory of a repository (repoA) that really belonged in repoB. The goal is to transfer all files and history from repoA to repoB, permanently.

    Thanks to Nikolai in this blog post, the move isn’t too bad. I’m not going to repeat his instructions. Instead, here are three tricks we learned today:

    git filter-branch --subdirectory-filter dirName -- --all 

    This throws away everything in a repository except what’s in dirName, making dirName the new root. The “– –all” part tells it to keep the history, but it only keeps the portion of the history relative to this directory name.

    However, the experts report that I could have skipped some later steps if I had instead removed the other directories:

    git filter-branch --tree-filter 'rm -rf unwanted_folder/' --prune-empty -- --all

    Merging two repositories together means creating a new remote in the destination repo that points to the source repo. Fetch from it and then merge its branch into the current branch in your destination repo. The fetch and merge are very standard git.

    git merge --no-commit sourceRepo/master

    The new (to me) trick here is –no-commit; it lets you see and alter the results of the merge before committing.

    Finally, all this merging was fine, but it required moving the newly-imported files into a directory. Once they were moved, a “git log fileName” only showed the move in the commit history. Argh! The whole point of this operation was to retain the history.

    git log --follow fileName

    Here’s a trick useful all over the place. Telling git log to follow the rename gives the full commit history of the file, before and including the move.

    Thanks to Erik Jacobsen, Mike Bishop, and Jay Harris for this info.

    Setting up an Android project in IntelliJ Idea

    And there was pain…

    I imported an existing Android project into IntelliJ Idea Community Edition 10.5.1. Some things started complaining “Please select Android SDK.”

    The help pages are out of date; they say to do this in the Android facet settings. It isn’t there.

    Here is the secret do-things-right button: Module settings (ctrl-alt-shift-S), then pick Project, and then you need to change the Project SDK (1). To teach Idea where your Android SDK is, click New, and lo! There it is! The Android SDK option!

    Choose Android SDK, and then select the home directory of your Android SDK installation. It will then ask you to choose a target API level. Now, the Android SDK is set.

    The code still didn’t compile and the Run task still complained “Please select Android SDK.” Strangely, it seemed to have lost the SDK selection. I restarted Idea, opened the project structure options, and chose the Android SDK again. This time in “Edit Run Configurations”, I was able to select the virtual device to run on.

    If you know a better way to accomplish this setup, please comment.

    (1) You could follow these steps at the module level, too.