Wandle Blog

emilymaygreen:

I’m organising a tech conference for women. I’ve been involved with this in both London and Stockholm, and now I want to do the same in Berlin.

It’s a nice chance to get women who wouldn’t normally speak to speak, and it’s also just super lovely to totally geek out in all-female company. It makes a lovely change to usual.

Sign up is here:  http://geekgirlmeetup.de/2012/07/25/geekgirlmeetup-berlin-registration-open/

I want sbt to get the dependencies from an existing pom.xml (Maven) file.
Reading through the sbt documentation it seems like sbt should actually do that automatically if an pom.xml is there. It doesn’t do it for me though (sbt 0.11.3).

Since I couldn’t find anything on the web and the IRC channel couldn’t help out either here’s my makeshift solution:

ivyXML := <dependencies>{xml.XML.load("pom.xml") \\ "dependencies" \\ "dependency" filter (dep => (dep \\ "groupId").text != "org.scala-lang") map (dep => <dependency org={dep \\ "groupId" text} name={dep \\ "artifactId" text} rev={dep \\ "version" text} />)}</dependencies>

Yes, an awfully long line added to my buid.sbt mapping the Maven xml to Ivy xml which is used by sbt.

If only I knew better. 

In Scala a Stream is a lazy list, that is a list whose elements will only be evaluated when they’re actually requested.

This makes it possible to create infinite lists, which can be very handy.
To demonstrate one of the possible use cases I take a scenario I’ve just had:
While going through a list of items I want one item (e.g. the first one) to get special treatment.

Coming from a Java background here’s how I might’ve done something like that had I just begun learning Scala: 

def capitalize(string: Seq[Char]): Seq[Char] = {
  var first = true
  for (c <- string) yield {
    if (first) {
      first = false
      c.toUpperCase
    } else {
      c
    }
  }
}

There already is a method capitalize in Scala’s standard library which may be slightly more efficient than either implementation shown here.

Now this isn’t too pretty. Especially since I’ve used the “evil” var keyword. Though Scala allows code like that we should strive to get away from that and reduce side effects. The first and most obvious way to do it is to avoid using vars.

Here’s how one can drop the var in favour of a val and still achieve the same thing:

def capitalize(string: Seq[Char]): Seq[Char] = {
  val trueThenFalse: Seq[Boolean] = true #:: Stream.continually(false)
  for ((first, c) <- trueThenFalse zip string) yield
    if (first) c.toUpperCase else c
}

You see what I did there? No? Well, let me explain. First off #:: is the operator used to construct Streams. It’s the lazy equivalent to :: which is used to put Lists together.

true #:: Stream.continually(false) is equivalent to
Stream.cons(true, Stream.continually(false))

Stream.continually is one way you can build one of those infinite lists I was talking about. It takes a function which defines each of the Streams elements. So trueThenFalse is an infinite list whose first element is true while all following ones are false. By zipping that Stream with the Char sequence we can also tell which character is the first one and that without any side effects. Since the Stream is infinite we can zip it with Strings of any length.

At the end I present a more classic example of using a Stream to construct an infitinite list, or as you could say a series. The Fibonacci series can be defined as follows:

scala> def fib(a: Int, b: Int): Stream[Int] = a #:: fib(b, a + b)
fib: (a: Int, b: Int)Stream[Int]

scala> val series = fib(0, 1).take(10)
series: scala.collection.immutable.Stream[Int] = Stream(0, ?)

scala> series.toList
res3: List[Int] = List(0, 1, 1, 2, 3, 5, 8, 13, 21, 34)

Using a Stream here is rather important. You could also write def fib(a: Int, b: Int): List[Int] = a :: fib(b, a + b). Only once you called it you would get a StackOverflowError due to the infinite recursion. Apart from that the whole series - it being infinite and all - wouldn’t fit into memory at once anyway. Fortunately you can use Streams to calculate the series lazily only as far as you need it.

The first 10 elements of the series are only calculated when a (strict) List is created from it by calling toList.

Say you have a mixed Java/Scala project and you have a couple of Java unit tests. While sbt automatically runs tests from the usual Scala test frameworks (specs, ScalaCheck, ScalaTest) it won’t run your Java tests per defaut.

Building Java sources with sbt is no problem, though. It comes for free, given the following project  structure:

src
  |
  |-- main
  |      |
  |      |-- java
  |      |
  |      |-- scala
  |
  |-- test
  |      |
  |      |-- java
  |      |
  |      |-- scala


Note: This is the default project structure expected by SBT,
      which is configurable, though.

SBT will simply pick up the Java sources and compile them along with your Scala code.
You can use your Java classes from within your Scala code and vice versa.
With tests, however, it doesn’t quite work so easily.

But fear not! It isn’t exactly complicated either.

Given you

• use sbt >= 0.10 for building
• use ScalaTest for your Scala tests
• use TestNG for your Java tests

You simply create ScalaTest wrappers for your Java test suites. Under  src/test/scala you put something like the following:

package my.scala.tests

import org.scalatest.testng.TestNGSuite

class MyJavaTests extends my.java.tests.MyJavaTests with TestNGSuite

If you’re using JUnit instead it should work simlarly by using org.scalatest.junit.JUnitSuite instead of the TestNGSuite.

Note that you still need to declare the dependency of your respective Java testing framework (JUnit/TestNG) within your sbt build file.

As I have only just learned, you can also use the sbt interfaces for TestNG and JUnit to make sbt run your tests directly and independently from ScalaTest.

Now when you run test on the sbt console both your Scala and your Java tests will be run!

In today’s (first) Scala Trivia post I’m gonna say a word or two about the method named collect, which you can use on collections.

For me this was new since I’d always thought that collect - knowing it from Smalltalk - was simply the same as map, which it is not. The difference is that while map requires a complete function, collect only needs a partial one.

I also use Ruby and there map and collect actually are the same.

Another possibly obvious side note: A non-exhaustive case block as shown below is a partial function, since it does not map the whole domain.

Only the elements on which said partial function is defined will make it into the resulting collection. So you could say that collect does a map and a filter at the same time.

val list = List("hey", "Friend", "want", "a", "Drink")
val nouns = list.filter(_.head.isUpperCase).map(_.toLowerCase)
val nouns2 = list.collect {
  case word if word.head.isUpperCase => word.toLowerCase
}

require(List("friend", "drink") == nouns && nouns == nouns2)

The same code for nouns2 only with map instead of collect would produce a MatchError.

I often found myself doing something like the following, until I learned about collect,
which is, however, the unnecessarily long-winded version of the above code using collect:

val nouns = list.flatMap { word =>
  if (word.head.isUpperCase) Some(word.toLowerCase)
  else None
}

I decided that I should start blogging quite some time ago already, but only recently have I started doing it. Looking for the right platform for this I ended up with the following options:

• Wordpress
• Tumblr
• Posterous
• My own creation

Now reinventing the wheel doesn’t make much sense most of the time. So I scratched the last one pretty fast. My first little blog entry I’ve created on Posterous then.

I’m a software developer. This is what I love to do and what I will blog about most of the time. I liked that Posterous provided built-in syntax highlighting at some point. I mean, I’m a developer and I plan on posting code.
It doesn’t do it anymore, though. It’s not working right now and support requests remained unheard.

I’m rather impatient at times. I tried making it happen through the excellent SyntaxHighlighter Javascript library, only to learn that custom Javascript is disabled on Posterous.

Alright, good bye Posterous then. As you can see I’ve now switched to tumblr. It was a close decision anyway. I must say that tumblr seems to be more polished at some places. I like it. Editing the HTML template on posterous was a nightmare, for instance.
I still like Posterous, it’s got a nice look and feel. But tumblr has that, too and allows more freedom on top of that.

Anyway, here I am and I like it so far.
I hope I will get around blogging more, especially about my little side project Wandledi of course.