I prefer using Java Enums even in Scala code, because unlike Scala enums they’re distinguished by actual type, not just type parameter. Thus they still can be distinguished after compilation, unlike Scala enums which end up as the same type after type erasure (at least if not taking into account experimental tricks like type tags). Unfortunately, Play doesn’t have built-in support for Java enum serialization/deserialization to/from JSON at the moment (v.

By default Play Json just truncates time zone when working with ZonedDateTime from Java 8. So the following code: case class MyClass(createdAt: ZonedDateTime) implicit val myWrites = Json.writes[MyClass] ... val d = MyClass(ZonedDateTime.parse("2015-10-01T12:13:14.00+02:00")) val json = Json.toJson(d) would produce following Json: {"createdAt": "2015-10-01T12:13:14"}. That’s because play.api.libs.json.DefaultWrites.DefaultZonedDateTimeWrites uses same formatter as DefaultLocalDateTimeWrites and simply disregards time zone. To display the time zone together with date time you’ll need to add following code before myWrites:

My goal was to make separate config files for run, tests, and integration tests in Play application - so that default settings for database in run and integration test environments would be different, and in tests database settings would be unavailable to make sure that no unit test works with real DB. This may be achieved via config.resource system property. I’ve tried to apply solution from http://stackoverflow.com/questions/15399161/how-do-i-specify-a-config-file-with-sbt-0-12-2-for-sbt-test with such code in build.

I was wondering if classes inherited from traits need to be recompiled if trait code changes, so I’ve investigated a bit traits internals - how are they represented after compilation. I’d like to share some observations. Suppose we have file SuperTrait1.scala: trait SuperTrait1 { def doOp1(): Unit = { println("do op1 V1") } } SuperTrait2.scala: trait SuperTrait2 { def doOp2(): Unit = { println("do op2 V1") } } and SubClass.

Quite often I see around ignorance about core concept around Futures in Scala: transition from synchronous to asynchronous code and back, execution context configuration and so on. I’ve shot myself in the leg with same mistakes once, and then had to dive into the details and make the picture clear for myself. Here I’d like to share some lessons learned and make Futures a little less “magic”. Let’s remind ourselves some basic primitives Just to make sure we’re on the same page.

I’d like to share my experience in automatic launch of tested web application in SBT (tested with version 0.13.6) before running integration tests and shutting it down after tests. That wasn’t very straight-forward and involved custom tasks creation. I’d be happy to hear about easier ways if you know some. SBT documentation about testing describes how to enable integration tests and run custom code before them via testOptions in IntegrationTest += Tests.

Iteratees were pretty hard concept to grasp for me. Thanks to nice article http://mandubian.com/2012/08/27/understanding-play2-iteratees-for-normal-humans/ I managed to understand what it is and how it works, but event then it wasn’t clear for me why one may need it - mentioned features seem to be achievable with simpler tools like Scala lazy Streams (http://scala-lang.org/api/current/#scala.collection.immutable.Stream) and RxScala observables (http://reactivex.io/documentation/observable.html): Backpressure (produce data with such speed that consumer has time to process it) - lazy Streams do exactly this thing: element of Stream isn’t evaluated until someone attempts to retrieve it.

For a long time I was upset with lack of native support of Markdown in Blogger. Both manual editing of HTML and lame WYSIWYG editor are counter-productive. Recently I finally had time to search for solution - and here is almost a silver bullet: StackEdit. It can be used on-line or installed as a Chrome Plugin. This is the first post written with StackEdit. For me it worked like this - hope that by the time you read it StackEdit will be further improved and it will be a bit simpler:

Here is brief instruction how to access repositories protected by basic authentication from sbt - checked with version 0.13. That's how one would configure custom repository in .sbt file: resolvers ++= Seq( .. "MyRepositoryName" at "http://repository.host.com/nexus/content/repositories/releases", ... ) If repository requires authentication - sbt would just show rather meaningless warning and claim that artifact isn't found: [warn] ==== MyRepositoryName: tried [warn] http://repository.host.com/nexus/content/repositories/releases/... here goes path to artifact ... You'll need to know authentication realm returned by repository server in order to configure credentials.

Funny thing - H2 in PostgreSQL compatibility mode requires that OFFSET should go strictly after LIMIT (like LIMIT 25 OFFSET 50). Otherwise it can't parse the query: error in SQL statement "SELECT .......... OFFSET 0 LIMIT[*] 25 "; expected "[, ::, *, /, %, +, -, ||, ~, !~, NOT, LIKE, REGEXP, IS, IN, BETWEEN, AND, OR, ROW, ROWS"