So Does ReactiveMongo

Since I am handing out endorsements this week, I figured I’d throw one more onto the pile.  ReactiveMongo is an asynchronous MongoDb driver for the JVM.  It’s the only non-blocking MongoDB driver there is for the JVM I believe.  It’s such a good driver that it actually makes a stronger case for using Mongo than Mongo itself does.  If this driver existed for Postgresql instead of Mongo, I’d use Postgresql.  That’s how good this driver is.  I hardly care about the underlying db because the driver is so good.  It is the best driver for any db I have ever used on any platform.  Mongo basically uses json to interact with it.  That is about as simple as it gets.  As simple as that is though, the ReactiveMongo driver is actually easier.  I wasn’t totally sold on Mongo a few months ago.  I feel like Postgres is actually a really solid platform, and with its ability to handle json, it’s arguably better than Mongo, even as a document store.  ReactiveMongo is a game changer for me though.  I’m using Mongo on new projects just because the ReactiveMongo driver is so good.  That’s saying something.  Good work guys.

Scalatra Rules

If you’re doing Scala development and want to save yourself a ton of time and headache, seriously check out Scalatra. I’ve worked quite a bit with the Play framework and worked against Spray, and I have to say that Scalatra is just a joy to use. I might name my kid Scalatra. Scalatra Legler. It rolls right off the tongue. That’s how impressed with it I am.

I’m not going to knock Play too much because it is a great piece of software. It’s just really heavy if all you need is web services though, and I’m not crazy about the functional testing framework (I’m looking at you FakeApplication, you crashy bastard). That’s beside the point though. I’m building an app that makes heavy use of web services and websockets, but the entire front end is javascript. I don’t need Play’s templating etc, so it’s just overkill. I researched micro frameworks and out of several, I decided to play around with Spray and Scalatra. Actually, I shouldn’t say that. I decided on Spray because it is so tightly integrated with Akka, which I use extensively, and so began the trouble.

The Spray toolkit is nicely decoupled, so you can use just the part you need, which I like. I love their caching module, in fact, I use it with Scalatra. I found their routing really cumbersome though, and I hate how implicit everything is. There is a lot of magic going on, which I don’t like. I’m building a REST service. If I want to send a response code with a json payload, that should be trivial. I shouldn’t have to look that up. I certainly should have to spend hours looking it up and learn an entire new vernacular of Spray idiomatic concepts to express what I am trying to do. Yet hours into messing with it, I found myself in the bowels of various google groups finding out that I have to write customer marshalers to do it? (again, we can’t agree to call them serializers? We have to come up with different terms?) Fucking annoying. The problem that put me over the edge was trying to return a 204 Status message if there were not results to display. This is a really really really common thing to do, and for the life of me, I could not get Spray to do it. This should be a one liner. I also wanted to throw 400 status codes when url parameters were missing with details as to what was missing in Json. Again, totally normal, should be a one liner, and a total fucking nightmare in Spray. I am sure that once you learn the idiosyncrasies of Spray, it’s a delight to use; however, I have shit to do and it was driving me crazy. Enter Scalatra.

At the point I went to Scalatra, I was completely disgusted with the Scala community’s acceptance of stupid complexity. This happens regularly for me. The people are great, but the idea that this complexity is acceptable is irritating. The Scala community at large needs to step back and start thinking of best practices for the language. It seems like the people with the loudest voices in the community have raging boners for the most complex abstract mathy ways to do everything. It’s exhausting. The thing about Scala is though, that if you ignore those people, the language is awesome. You don’t have to go down the pure functional hole to get performance out of it. I write Scala using the Zen of Python as my guide. It works great, and it makes me not feel guilty about ignoring the people running things. In any case, Scalatra is sweet relief from the abstract implicit horseshit going on in the Scala community. They’re my kind of people.

Let’s get back on task here and use an example to do it! For example, let’s say you have a parameter called name in your url, from which you’d like to get a value, probably a name if you’re into obviousness the way I am. Let’s say you want to throw a 400 code if it is missing and a json response explaining what happend. There are lots of ways to do this, but an easy one for me was something like this: Create a case class called HaltReason that contains a string called error. You’ll use this to deliver the message to your users of what the problem is. In your Servlet, extend ScalatraServlet with NativeJsonSupport. You do this to convert your HaltReason object into json. Then get your value with this line of code:

val name = params.getOrElse("name", halt(400, HaltReason("missing name parameter")))

Boom, that’s it. It either gets it, or it throws a useful explicitly defined error with an explicitly defined message to your user. Did I just blow your mind? If I hadn’t written that example and explanation, I’ll bet it would have pissed me off. I need examples man. I can’t conceptualize things like that. To remedy that, here is an example of the code in context.

Note: I didn’t compile this, so there may be syntax problems, but you get the gist. I also added a method that will always return a 204 response, just for awesomeness’ sake. You can imagine writing some code that results in no result, and then you can probably imagine explicity returning a response that says so. Imagining is fun.

import org.json4s.{ DefaultFormats, Formats }
import org.scalatra._
import org.scalatra.json._
case class HaltReason(error: String)
case class MyDumbResponse(name: String)
class ApiStoreServlet extends ScalatraServlet with NativeJsonSupport {
 implicit val jsonFormats: Formats = DefaultFormats
 // I put all of my routes here, this may not be totally normal. Check out the Scalatra website for real examples.
 before() { contentType = formats("json") }
 get("/getName") { doSomething(params) }
 get("/throw204") { doSomethingElse(params) }
 def doSomething(params: Params): MyDumbResponse = {
  val name = params.getOrElse("name", halt(400, HaltReason("missing name parameter")))
 def doSomethingElse(params: Params): MyDumbResponse = {
  halt(204) // This is just an example. I didn't even make it try to do something other than throw a 204 response.

Better? If not, check out and build an example project and try it out. Try to do the same thing in Spray. Actually, if you do it in Spray and get it working, send me the code. I gave up on it and I’d love to see it. My point is this: Scalatra makes it easy to do exactly what I wanted, and that is my favorite thing when it comes to software.

So what about Akka integration and all of that? What about the fact that it runs on old and busted Servlets. Don’t worry about it. The akka integration is perfect. You spin up an Actor system behind Scalatra, extend your Servlet with Future Support, and you can distribute and cluster until your heart is content. Worried about thread exhaustion because of the Servlets? Don’t worry, Scalatra works with Servlet 3.0+ containers, making that not a problem. It’s already integrated with Atmosphere, build some asychronous beast and make a billion dollars. Scalatra makes this stuff fun. I’m sure Spray is awesome too, but I just got frustrated with the complexity of it. I want my framework out of my way so I can do the things I want to do, and Spray just wanted my attention constantly. Play is great, but it’s heavy. Both Play and Scalatra are well documented and straighforward. Scalatra is just lighter, which I wanted and I like. There are others out there that I didn’t try as well, and I have no idea how well they work. Try them all if you like. I just really liked what I found with Scalatra. If your time means anything to you, I imagine you’ll find Scalatra to be a pretty valuable piece of software to use.

Crisis of Choice (software, not an actual crisis)

I’ve been writing Scala code for about 9 months now daily.  I just recently completed (as much as one can complete software) a small project at work that took much longer than expected due to things that didn’t seem like they should take very long taking an eternity to figure out (Marshaling and UnMarshaling data is a huge pain in the ass using spray-json.  I highly recommend fasterxml if you don’t want to waste shitloads of time battling the library itself.  It works like the Play libraries, which is nice.)

Once I get things working, they work reasonably well, although I feel like what I have built is fragile.    Things that should be easy are a huge pain in the ass.  It’s been running for 30 days with no problems, which is nice, but that’s mostly because Akka is solid.  I just don’t feel like I have my head around this language.  I was a dumbass and decided that using a web framework for what I was doing was overkill, so I tried to build it with Akka, Spray, and Slick.  It was a waste of time, other than for learning Akka/Spray/Slick.  I should have stuck with Play and used traits to make testing my code easier.   The previously mentioned huge pain in the ass (which I never did get working) would have never occurred, it just works in Play.  My primary complaint about Play was it was hard to test, but that was actually my problem not really understanding how useful traits are when it comes to testing.  Anyway, you live and learn.

It’s an interesting place to be.  Nine months seems like it should be enough time to grok a language; however, I still feel like I’m scratching the surface.  I’m not expecting to be an epic badass at it, but it’s harder than it should be.  I have the same feeling with Scala that I have with C++.  If I can’t get the bulk of the language into my head, I have much less confidence in what I am writing.  I think that makes me a weaker developer in some ways, but at the same time, the point of abstraction is to not have to worry as much about what’s going on within the abstraction.  Scala is so complex with its generics implementation and type system and every other thing it tries to throw in, that it just gets out of hand in a hurry.  It is an amazingly powerful language, and overwhelming because of it.  It feels like it has created a whole new set of very complicated problems for me to solve to do what should be less complicated.

Scala offers all kinds of badass ways to get concurrency and parallelism and a neat type system, but at the cost of being a really really complex language with a seemingly insurmountable amount of concepts and associated buzzwords.  I blame the JVM and the JVM community at large.  They love abstractions of abstractions with abstractions in them, wrapped in Lists of Generics, which are type erased so you can’t tell what is inside of them at runtime without writing a bunch Manifest or TypeTag bullshit, each with a different name depending on the order that the abstraction occurs.  It’s maddening.  The JVM is amazing, and also drives me nuts.  I’m starting to feel like the “solution” causes more problems than it solves.   I think I’ll always be a JVM outsider.  It just always feels a little wrong to me, even when it’s working (and gobbling up memory).

To put it in perspective, I rewrote my Scala app in Python in about 4 days using Falcon.  My Python version handles the load it needs to and actually uses less memory.  It won’t scale at even a fraction of the scale of the Scala version in its current version, but it doesn’t need to.  If that became a requirement, I’ll bet I could write it to scale in less time than it took me to write it in Scala.  Admittedly, I have been writing Python code for much longer, and since I already had the design worked out, reimplementing it is always easier than the original implementation.  I also used a framework, so it’s not as fair of a comparison as if I had used Play.  It isn’t 86 days easier though.  I’ve been looking at Go and it tries to solve the concurrency/speed/memory/complexity problems in a kind-of backwards way that is interesting to me.  It doesn’t have classes or generics, and I kind of love that idea.  They tried to intentionally keep it simple, which is the philosophical opposite of Scala.  It’s a get-shit-done language instead of an academic language.  I’ll give it a try at some point.

I’m not giving up on Scala.  The challenge is fun; however, I don’t think it will ever be a dominant language.  I don’t think it will every be possible to scale a Scala development team in most cities.  There just won’t be enough people that are actually good at it that don’t cost a fortune.  What do I know though?  I could be wrong, but it just doesn’t feel right to me.  Maybe it’s better if you love the JVM, I really don’t know.  It’s a very complex language though, and I’m not settling on it as the best way to tackle concurrency/parallelism problems.

What I like right now

I’ve been working a lot with Scala over the last few months, both at work and personally.  If you get a chance, check out  It is the new site for my girlfriend’s company.  She does custom calligraphy for weddings and events.  Her work is amazing.  It’s almost the exact opposite of what I do.  While I sit around beating my head against machines, she fashions these beautiful organic handmade creations.  It’s awesome.  We collaborated on the site.  I’m not much of a web developer, so she did all the design in illustrator, and then I coded it to get it working.  It turns out that the two of us make one half-decent web designer.  In any case, check it out.

The reason I mention it here is because the entire site is done in Scala against a PostgreSQL database using the Play Framework.  It’s running behind nginx on Ubuntu which is running on a Linode VM.    I guess that makes it a LNPS stack, which just rolls off of the tongue.  It’s been a lovely experience.

First off, Linode is awesome.  They totally get out of your way.  I feel bad for not having more to say about them; however, they are so good that I hardly notice that they are there.  I mean that in the best way possible.

Second, nginx is awesome.  It’s small, it’s fast, it’s wicked easy to configure.  I have it serving a bunch of blogs (including this one) which are WordPress sites,, etc. and it just works.

Third, Ubuntu Server is awesome.  It’s small, it’s fast, it’s wicked easy to configure.  I tried using Ubuntu as my main OS on my Dell laptop for work for the last 3 weeks and it’s not my favorite.  I’ll write about that some other time, but I like Server quite a bit.

Fourth, Play/Scala is awesome.  It’s as simple as it can be, and no simpler.  It’s a joy to work with.  It integrates with intellij (which is also an awesome piece of software).  It doesn’t use an ORM!  That might be my favorite part.  I write SQL, and it blazes.  It doesn’t get on board the java abstraction boner wagon.  The main reason I almost never write Java is because it feels heavy and slow.  It abstracts away things that people should probably understand if they are writing code.  I like a certain level of abstraction though, which is why I don’t program in C or C++ much.  I don’t need everything abstracted away though.  Play is a good balance and so far I really enjoy it.  Scala is mostly what makes it awesome.  There is part of me that still things the erlang vm is the way to go, but I’ll have to wait until I have more time to play around with it.  In the meantime, I’m getting things done with Scala, which is nice.