These are the slides from the talk I gave last week about ReactiveMongo - an Asynchronous and Non-blocking Scala driver for MongoDB.
Although it is a very technical talk, which the slides reflect, much of the detail is delivered along with the presentation and so I am looking forward to when 10gen publish the video as it will make it easier to digest and will also include the questions afterwards.
It was a pleasure to take part and I was especially pleased with all of the positive feedback, where people came up to me hours afterwards even.
Thanks to 10gen for putting on a great conference & an even bigger thank you to Stephane Godbillion for writing ReactiveMongo, you’re awesome.
Next week I will be giving a talk about ReactiveMongo (a non-blocking Scala driver for MongoDB) at MongoDB London.

If you are evaluating MongoDB, or just want to learn faster and gain invaluable tips & insights then I would recommend attending as I did last Summer. You will get a feel for the community around the technology and can even speak to 10gen directly (the MongoDB company).
These are some of the highlighted talks:
Best of all, you can use the discount code Speaker20 for 20% off tickets.
Hope to see you there!
Alex
This post attempts to determine if running Scala is more performant under the Java 6, or 7 virtual machines, using a benchmark recently used to compare Scala versions 2.9.2 and 2.10-RC3.
Recently I upgraded my Java version from 6 to 7 (1.6.0_37 to 1.7.0_09 Oracle JDK) and thought I noticed a performance increase when running my Scala applications, but was not sure. Since Scala runs on the JVM, it would be reasonable to expect it to use the same JVM as installed on a system and based on the bash script of the ‘scala’ command, it appears that it does run the ‘java’ command with Scala as a library.
After reading about the increased performance in Scala 2.10 over 2.9.2 in this performance benchmark I thought that it would be interesting to run the same benchmarks again in the different JVM versions and compare the results.
So without further ado:

As expected, Scala 2.10-RC3 trumps 2.9.2 in all cases (lower is better).
Rather unexpected however is that JDK 6 is faster than 7 for the Eratosthenes tests for Scala 2.9.2, but the difference is negligable for the warm mean in 2.10 and JDK 7 is only 1ms faster.
In conclusion then, running Scala on a Java 7 virtual machine has proven to be more performant, but only for Scala 2.10 and only with this limited benchmark.
This post describes a Base64 alternative to working with hexadecimal representations of ObjectId’s in mongo.
This:
UKZBAooUfVcAYOfa
Instead of:
50a641028a147d570060e7da
That is 16 characters instead of 24 and depending on your style, you may prefer it.
After designing an API that looks something like this:
GET http://example.com/resource/50a641028a147d570060e7da
I wondered if there was a more elegant alternative - surely a hexadecimal string is not the most compact form.
MongoDB is a great database and provides a default index field “_id” which is comprised of 12 bytes of data in a type called ObjectID, usually represented in hexadecimal format as above.
There are advantages to sticking with ObjectID, for example:
Encoding the 12 ObjectId bytes into URL safe Base64 is simple and effective, meaning you can indeed write an API like this without losing the benefits of ObjectID and all without declaring another field on your document.
GET http://example.com/resource/UKZBAooUfVcAYOfa
But what about the mongo shell? There’s clearly no point of having all this indirection if the tools we have refuse to work for us.
Clone the repoistory on GitHub
git clone https://github.com/alexanderjarvis/mongo-base64id
Link mongo-base64id.js to .mongorc.js in your home directory.
ln -sf <mongo-base64id-dir>/mongo-base64id.js ~/.mongorc.js
Data is now returned in Base64Id format:
$ mongo
> db.users.find()
{ "_id" : Base64Id("UKZBAooUfVcAYOfa"), "email" : "john@smith.com" }
You can also query by Base64Id:
> db.users.find(Base64Id("UKZBAooUfVcAYOfa"))
{ "_id" : Base64Id("UKZBAooUfVcAYOfa"), "email" : "john@smith.com" }
What if I want to use ObjectId again? Easy:
> setBase64Id(false)
Since this is a technical blog, you may be interested to know that you can and will be able to also browse the archive of the posts at GitHub.
It is currently hosted for free by Tumblr, which allows for posts to be written in Markdown.
A similar solution is also probably possible using GitHub Pages, but this was the easiest to get working for now.
Comments welcome.
Documentation for getting a Play 2 project working with Sublime Text 2 is available, but sparse, so this post aims to consolidate the steps necessary to get you up and running quickly.
Once done, you should have a more semantically aware Sublime Text installation which highlights errors just like a regular IDE, but without all the hassle and lockups.

$ mkdir ~/.sbt/plugins
$ echo "addSbtPlugin(\"org.ensime\" % \"ensime-sbt-cmd\" % \"0.1.0\")" >> ~/.sbt/plugins/plugins.sbt
Make sure to obtain the correct version number from https://github.com/aemoncannon/ensime-sbt-cmd
From the sbt/play console of your project:
$ ensime generate
Mac
$ cd ~/Library/Application\ Support/Sublime\ Text\ 2/Packages/
$ git clone git://github.com/sublimescala/sublime-ensime.git Ensime
Linux
$ cd ~/.config/sublime-text-2/
$ git clone git://github.com/sublimescala/sublime-ensime.git Ensime
Download Ensime package from http://download.sublimescala.org/
Extract the contents of this package into the server subdirectory of just created Ensime directory. You may need to create this directory
Mac
$ cd ~/Library/Application\ Support/Sublime\ Text\ 2/Packages/Ensime
$ mkdir server
Linux
$ cd ~/.config/sublime-text-2/Ensime
$ mkdir server
I would recommend the play2-sublimetext2 bundle for syntax highlighting and code snippets if you are using Play.