Notes on Devoxx 2nd day (2 - Evening)

The reason I cut the notes into two was because there were a lot of things to say on evening session. So, here they are.

Scala BOF
In my previous post, I said that I did not like to bash other programming language -- after all, for a programming language lover, you can't do that. But,...., I could not avoid comparing  Groovy and Scala BOFs. The latter had simply double in term of audience... It could have been even better if the place was bigger, some people simply could not join the room anymore.

All right. Dick Wall and Bill Venners were there, and in addition, Martin Odersky was there too.

• Help with implicit. Martin said that IntelliJ showed and helped with code completion. Great, maybe I would give a try then.
• Code completion for implicit in REPL. Why not ? Technically feasible, just the question of resources.
• Code completion in REPL again: why didn't it work for jar loaded by :cp ?  No answers.
• Compilation time. Martin said we should expect that compilation time would not be drastically improved because the Scala compiler did a lot of things, especially on type checking, type erasure, translation to Java, and so on. The best we can expect is reducing by order of two. Otherwise, one may think of using better build tool, why not sbt. Otherwise, a classical answer: Scala will pay off with less codes (well...).
• SBT news : well, it's fine. on going.
• Debugger: anybody could tell the experiences on debugger ? No answer (I myself did not use debugger for my project, I used  plain old println).
• Scala ecosystem, industry adoption: Scala works with Java very fine. Industry started to adopt Scala. Play! was mentioned a couple of times. Dick Wall mentioned an interesting project called Squeryl, ORM in Scala. Bill mentioned about ScalaTest. The biggest missing things are tooling like Check Style, PMD, Code Coverage.
• Binary compatibility issues on 2.8 when migrating to 2.7: yes, it would be taken into account so that it never happened again. But, unfortunately, it will likely to happen on 2.9 with the introduction of parallel collection. Martin considered that should be acceptable for a language like Scala that is still relatively young, he compared with Java Collection that will be final hard to change.
• (A small incident happened when we discussed this, somebody somewhere outside the room yelled noisily ... didn't know to whom ....  We took that a joke: that must be a Java Collection developer)
• Tooling again: check style. Dick Wall told that FindBug might work although it complained too much by default at the moment.
• Best practice: it is important, to control the variation of codes, especially in big company where one code may move from one team to another. However, it might be challenging, given two trends so far: Scalaz trend and Java-ish trend. But, the three agreed to consider this issue as important.
• Training. Scala did have some good trainings, Martin, Bill, and Dick are Scala trainers. One of the trainee was there too. 
• Big company behind Scala. Martin said that there might be advantage of having that kind of company, but Ruby and Python were the two cases that both did not have big company behind them, but they did succeed.
• Code generation tool, like Grail for Groovy, Rail for Ruby. Dick argued that those two examples might not be applicable for Scala. The thing is to find other killer-app for Scala, and it's not necessarily a tool like Grail or Rail. The killer app might be Akka or Lift (Play! framework was again mentioned)
• 2.9 version. Parallel collection.
• Target of Scala, only JVM ? No .NET as well (funded by Microsoft directly). Is there any limitation imposed by this choice? Type erasure for example? Not really. Type erasure is not a limitation on itself either, only .NET does not erase type. Manifest introduced in 2.8 should be helpful for type erasure.
• Scala Solution. Scala solution is intended to provide professional development tool (again, tooling) and for longer future maybe on middleware. 
• Is there any design that you regret ? (Long reflection by Martin..., I expected XML literal, but not..., it was :) postfix operator.

Like Scala Lab in the morning, this session was fantastic. Thanks to the three people. Scala Rocks !

Hazelcast by Talip Ozturk

It was an interesting presentation on Hazelcast by Talip Ozturk. He is a nice guy. 

• How share data structures (map, queue, list) across several JVMs
• Multicast is used to discovery, followed by TCP/IP communication.
• Security: data can be encrypted.
• Demo on how map updated in one node affected other node.
• Also on locking/unlocking
• Interesting presentation on internal mechanism of Hazelcast.
• Executor service is useful to avoid unnecessary distributed computation.
• Update are synchronous.

Pretty interesting things Talip presented here. It was very powerful tool, but damn simple. Maybe I'll have a try.