Scala

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.

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.

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.

Finally found this answer: http://stackoverflow.com/questions/23229864/how-can-i-show-a-source-directory-to-sbteclipse-without-adding-it-to-the-compile to a question: how to include integration test sources in Scala IDE (Eclipse) - just add the following line to your build.sbt: EclipseKeys.configurations := Set(Compile, Test, IntegrationTest)

It wasn't obvious for me how to make HTTPS calls with Finagle so I'd like to share key points here: When building client: explicitly specify correct port (typically 443 instead of 80)When building client: enable TLS using ClientBuilder.tls(...) or ClientBuilder.tlsWithoutValidation() methodWhen making actual call: specify HTTPS protocol in requested URLIn practice you'll get something like this: val client = ClientBuilder() .codec(Http()) .hosts("yourServer:443") .tls("yourServer") .build() val httpRequest = RequestBuilder().url("https://yourServer/somePath").buildGet

Suppose you have some class MyService configured as Spring bean: @Component class MyService extends MyBaseService { def myOperation() { ... } } Which is referenced somewhere in the project: ... @Autowired private var myService: MyService = _ ... So far this code works, and now you'd like to mix in some trait into your service to add common functionality: @Component class MyService extends MyBaseService with MyTrait {

I've just discovered funny thing about default parameter values in Scala. If you call a function without parenthesis default values can't be applied and compilation fails. If you have such function: def hello(name: String = "world") { println("hello, "+name) } Then this would fail to compile: hello and this would compile and run well: hello()