• Play Json date format customization

    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:
  • javaOptions in sbt integration tests

    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.
  • Scala traits internals or what needs to be recompiled

    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.
  • Futures and blocking in Scala

    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.
  • SBT integration tests: automatically launch application

    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 raison d'être

    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.
  • Markdown in Blogger

    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:
  • Sbt repository authentication

    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.
  • H2 LIMIT and OFFSET

    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"
  • Scala protected methods aren't that much protected

    Just discovered weird behavior of Scala's protected methods: they're actually compiled to public methods in byte-code. Therefore if you try to override them in Java code with another protected method compilation will fail with something like this: "attempting to assign weaker access privileges; was public". After some googling I've discovered that other people also spotted this issue. I think such weird compiler behavior was needed because of access level mismatch in Scala and Java - but I thought that Scala's protected is more restrictive then Java's.