Playing with fire Subscribe

So, Play Framework being my favorite web development framework, I got some experience using it for a public R&D project of mine - racerkidz.com, a kind of wiki with some other cool features (my personal blogging platform being one of them) and I figured I share some of the highlights, issues and my take on the current status of this part of the scala ecosystem.

Development with scala and Play is very nice. The language is high-level, the APIs flow quite nicely and since the Eclipse plugin started underlining errors and doing content assist in play templates, it got very nice. One piece of awesomeness was the Eclipse IDE doing content assisst inside a string interpolator expression - I'm still in awe at that and it did make up for a lot of the crap I have to put up with. Cheers for that!

For this project I used:

  • scala 2.10
  • Eclipse IDE
  • Play 2.0, 2.1.5 now
  • mongodb with casbah
  • knockoff markdown parser
  • akka
  • cygwin on Windows, for development
  • Ubuntu VMs on Rackspace Cloud then moved to Digital Cloud, for production
  • apache as a proxy
  • Twitter Bootstrap
  • bunch of stuff I forget

The development model is great: start with play ~run and as you save a template, just refresh the page in the middle of a sequence and in 5 seconds, keep on coding. The only slow down was that the eclipse plugin inssists on recompiling a lot of stuff when you modify a template, although it doesn't compile the template itself so it just loves wasting my time.

It does occasionally run out of memory and compete with Eclipse on CPU and memory resources because they both like to reompile at the same time, often without any value, but it keeps them both happy and the annoyance level is low, so whatever.

sbt starts acting up

Nevertheless, that worked great for a while, until I did something that now triggers sbt to recompile every file and it's 20-30 seconds instead of 5... luckily, most relevant screens were done at this point or I would have stopped using Play. If I were to use maven, I probably would have never even started, heh. Apparently the new version of Play uses a new sbt which might solve this. Or not, hard to know...

Sbt is a major part of the scala development environment and, while much simpler than maven, I find it very opaque. The examples mostly don't work since there's so many versions found by google, I can't keep track of what's going on... and I have no way to clean everything or debug what's going on, at least none that google can find for me...

I do believe this is a scala problem, some interaction between implicits, with sub-projects with god-knows-what, but at this point I was racing against the clock so the 1 hour allocated to fixing this expired quickly... stuck now with a full recompile done frequently and randomly by sbt.

SBT - this is probably the single biggest pain point with developing in scala at this point... since the Eclipse IDE got nice. It's the interaction between scala and sbt... kind of like GIT: it can do a thousand things with a thousand switches, but when something goes wrong, you better start praying. I have no desire -and actively refuse- to learn the thousand switches needed to get it to do what I want, by the way... so go ahead, blame it on me.

Lesson 1 as soon as sbt starts acting up in any way, stop whatever you are doing, start rolling back your changes and fix that.

Lesson 2 read this link on the scala-sbt interaction, at least 10 times and forget any advanced language features that don't jive well here: Understanding-incremental-recompilation. PaulP has it right: stupid fast beats awesome slow, on a daily basis.

Version dependencies

I updated the mongo drivers and some other stuff at some point, chasing an instability and now I have a constant warning every time and no way to debug it...

[warn] Potentially incompatible versions of dependencies of {file:/C:/cygwin/home/razvanc/w/racerkidz/}racerkidz:
[warn]    org.scala-lang: 2.10.2, 2.10.0

I thought 2.10 is binary compatible, so whatever - I don't know if something bad is going on or not. Maybe that's why sbt recompiles everything all the time? Don't know... this is not the first time I wasted hours on some version incompatibilities, so whatever. Modern development involves sticking a lot of round pegs in square holes, so some level of this is expected, I guess.

There's some settings in one of my home folders - windows or cygwin, I forget which, there's some for each project, there's some in build.sbt, some in plugins.sbt, some in Build.scala and I am absolutely certain there's some more that I can't find...

Play Modules

I figured I'd open source some of the code, so everyone has a basic markdown wiki to embed in any web app, so I spent 1 day, decoupling code and creating two sub-projects, at about the same time sbt started acting up, unfortunately. It worked ok, until I realized that there is no easy way I can put them in their own github repos without messing up my Eclipse development model and stopped.

I will probably look at this again, some other time. The insistance on having modules in a certain directory structure makes it unusable for easily sharing code... at least the way I understand it right now.

Many people do not seem to realize that any restrictions and unneccesary switches and stuff only adds to other restrictions and switches from another of the hundred pieces needed to have a working main() and all they do is make the ensamble brittle. Complex versus complicated falls on deaf ears most of the time... like on language/frameworks/tools designers forgetting they're just part of an ecosystem...

The above is not really why I titled this blog "playing with fire" - you'll find that in the other episodes chasing the instability. Continue to Playing with fire 2 - the instability comes into play.

By: Razie | 2013-11-12 .. 2016-05-11 | Tags: post , scala , play , devops |


See more in: Cool Scala Subscribe

Viewed 626 times ( | Print ) this page.


This content is Copyrighted, all rights reserved.

You need to log in to post a comment!