What happened is that I needed something like matching that kind of combination… and this speaks to something about Scala that I love: it becomes intuitive after a while. So how did I find that such matching is possible? I simply tried… =)

This is what this feature looks like:

msg match {
  case x: X with Z => println("matching combination!")
}

In this case, X would be a class, and Z a trait. The case x will be triggered only if msg is an instance of class X and mixes in trait Z. With this, we make sure to have access to all members both from the class and from the trait, while being really type safe about the matching. No unsupported combinations will pass through, and no need for castings, like would be necessary in Java.

Lets try a dummy example. Imagine we have a Superman class, and two traits: BlueCape and RedCape, like the following code:

class Superman(val realname: String)
trait BlueCape
trait RedCape

Now, we want to match on a Superman instance, but we want to know if it is fake or not. Finally, we also want to print the guy’s name, which means we need access to the realname field. This is how you could do that:

def whichSuperman(superman: AnyRef) = superman match {
  case s: Superman with RedCape => println("real superman: " + s.realname)
  case f: Superman with BlueCape => println("fake superman: " + f.realname)
}

Flexible and type safe! And if the traits had any field, we would be able to access them as well. Quick sample test code:

val mys = new Superman("clark") with RedCape
val myf = new Superman("clurk") with BlueCape

whichSuperman(mys)
whichSuperman(myf)

The part that matches the class is not very useful in this example, since this could be defined in the function parameter, but it was in my local scenario, where we are using actors and the messages can be AnyRef.

If you want to know a bit more about pattern matching, I wrote about it a while ago here. I also described how to match a range of numbers here.

I’ll come back after the meeting for a ‘report’ of how it went =)

In time: I should write more posts about scala soon, just need to get some stuff in place before that.

Lets first explain what I discovered later: what sbaz does. It is some kind of scala package manager for your local scala installation. If you issue a sbaz available, it will list all packages it is able to install for you, for example. Also, and this was the somewhat tricky part for me, it is able to upgrade all current packages to their latest versions, including the main scala stuff, like the scala-library.

This is all great.. as long as you don’t run sbaz upgrade by mistake. This happened some weeks ago to me… And I was lucky enough to not have any major problem. I was running scala 2.8.0 at the time, and 2.9.0 was already out. Result: I upgraded to scala 2.9.0 before I intended to… and one day before a speech I gave at a conference, where I presented plenty of scala code examples.

In the end all went well, but I had to update some sample code, and to upgrade the Netbeans scala plugin to the version that supports 2.9.0. The other option would be to erase the installation folder and install scala from scratch again, but I chose to use this “event” to upgrade to 2.9.0 for real =)

Bottom line: learn that scala has a very nice package manager tool called sbaz, but use it with care

Although those are certainly the main places where you would consider using parallel collections, there are more simpler ways you can leverage them. The code to use this feature is so simple that it’s easy to come up with reasons to use it everywhere:

myCol.par foreach(println)

Now how could that be easier??

So where did I use that for real, you might ask. The current company I work on stores files in Amazon S3. Before that, those files where stored in the local disk. So, when we migrated to S3, I wrote a script, in Scala, to upload all the files… thousands of them. My first solution looked something like this:

listOfFiles foreach(file => sendToS3(file))

And then suddenly it occurred me that it’s ridiculously simple to parallelize the upload of the files:

listOfFiles.par foreach(file => sendToS3(file))

Result: half the time for uploading the files, having to do almost nothing! Pretty neat, ain’t it?

P06 (*) Find out whether a list is a palindrome.

Example:

scala> isPalindrome(List(1, 2, 3, 2, 1))
res0: Boolean = true

The first thing I had to do was to find out the meaning of palindrome. From the example, it’s easy to guess, but I prefer to be sure. So, from dictionary.com:

Interesting, so this is valid not only for numbers =)

Now, to some coding! My first solution:

def isPalindrome(list: List[Any]): Boolean = list match {
  case Nil => true
  case head :: Nil => true
  case head :: rest if head == rest.last => isPalindrome(rest.dropRight(1))
  case _ => false
}

This first solution uses pattern matching to investigate the list recursively. It checks if the list is empty or if it contains only one element and returns true. Otherwise, it checks if the head of the list equals the last element. If so, the rest of the list (its middle part) is passed recursively to the function. This is one more case where we can see the great power of scala’s pattern matching in action.

Also, the solution will work with strings as well, so it matches the dictionary definition – just call toList on the string. Sample execution from the REPL:

scala> isPalindrome("oio".toList)
res11: Boolean = true

scala> isPalindrome("oioo".toList)
res12: Boolean = false

To be honest, I don’t feel too much creative when thinking about this problem, so the next solution is quite similar to the previous one, but without pattern matching:

def isPalindrome(list: List[Any]): Boolean = {
  if (list.isEmpty || list.size == 1) true
  else if (list.head == list.last) isPalindrome(list.slice(1, list.size-1))
  else false
}

Now lets take a look at the original solution and… I’m stunned by its simplicity. While I went all fancy at things like pattern matching, the original solution goes like this:

def isPalindrome[A](ls: List[A]): Boolean = ls == ls.reverse

Yeah, I should have thought of that…

Now, of course I wanted to have this puzzle solved. So I finally used some spare time and coded a solution. My solution is not the best possible one by any means, but it works and was really fun to work on.

Before showing the solution, a brief explanation of the problem, translated from the description in portuguese:

Write a program that generates all possible anagrams of a given string.

For instance, the possible anagrams of "biro" are:

biro bior brio broi boir bori
ibro ibor irbo irob iobr iorb
rbio rboi ribo riob roib robi
obir obri oibr oirb orbi orib

I’m still trying to find better and more readable solutions, but for now the current one is as follows:

class Anagram {
  def anagrams(word: String): Set[String] = anagram(word).toSet

  def anagram(word: String): List[String] = {
    if (word.length == 1) {
      List(word)

    } else {
      var anagrams = ListBuffer[String]()
      0 to word.length-1 foreach { i =>
        anagrams ++= (anagram(without(i, word)) map (word.charAt(i) + _))
      }

      anagrams.toList
    }
  }

  def without(index: Int, word: String): String = new StringBuilder(word).deleteCharAt(index).toString
}

In summary, what I tried to do was combining the ‘current’ char with all combinations of the rest of the input string. I hope this makes sense while reading the code. The code works – I have some unit tests that we generated during the coding dojo plus a couple more tests I added afterwards. Yet, I’m not happy with the anagram ListBuffer… I guess this could be solved in a more elegant way. Ideas?

An extra curiosity. While looking into the Scala Docs API to find possible ways to solve the puzzle, I discovered a very handy function that can be called on strings (and other kinds of collections as well): permutations. It basically solves this puzzle in a single method call…

Before talking more about the conference, I have to thank Globalcode (in special Vinicius and Yara). They did a great job =)

Since last year, the premise of the conference is to have people from all kinds of backgrounds, from a lot of different communities, like Java, Ruby, Python, Agile, Javascript, .NET and lots more. Each day featured five different tracks, with different topics, to fit all those communities and tools. The result is that we had a lot of different people and lots of opportunities to talk to people you usually would not encounter. This was a really enriching experience.

In a personal level, this conference was special to me: I made two ‘speaking’ participations. In one of them I talked about Scala, an introductory talk (you can find the sample code used in the talk in my github). The other one was a panel consisting of people from different languages on the jvm – lots of fun =)

In the event, I had one personal fail moment, that should remain as a tip for everyone out there. In a given moment, when talking to someone, I was asked for my business card… and didn’t have any on me. So the obvious tip: always have business cards with you. Always.

Now, if you follow my posts about events you may have noticed that this one is a little different. It contains no pictures. This is due to a second fail, that happened on this last Monday. I lost (or it got stolen…) my mobile. And with it, all the pictures from the entire event. Sorry =(

P05 (*) Reverse a list.

Example:

scala> reverse(List(1, 1, 2, 3, 5, 8))
res0: List[Int] = List(8, 5, 3, 2, 1, 1)

Starting with the obvious solution, using the API:

val list = List(1, 2, 3, 4)
list.reverse

Yes, the List API has a reverse function. Pretty handy =)

How about being more creative now? Like this:

def myReverse[A](list: List[A]): List[A] = list match {
  case head :: tail => myReverse(tail) :+ head
  case Nil => Nil
}

With pattern matching and recursion, the solution is pretty simple. We basically decompose the list, and rebuild it in the opposite order. The code is simple, but it can take a while to understand if you are not used to recursion. The pattern matching part shows how nicely we can decompose Lists in scala =)

Lets try a different solution now:

def myReverse[A](list: List[A]): List[A] = {
  var reversedList = List[A]()
  list.foreach(item => reversedList = item +: reversedList)
  reversedList
}

Here we take a more ‘traditional’ approach – its closer to what we would do in Java, but still more compact and readable. First we create a buffer list, and add each element of the original list to the beginning of the buffer. Finally, we return the reversed list.

You can find the original solution to the problem here. As always, I learned something more after reading the original solution – I always write my solution before reading that. What I found is that it is also possible to solve the problem in a pure functional way, with foldLeft (copied from the original solution):

def reverseFunctional[A](ls: List[A]): List[A] =
    ls.foldLeft(List[A]()) { (r, h) => h :: r }

This solution is probably the most difficult to get at first, but the best after you get used to this kind of ‘extreme’ functional stuff. Nice =)

This allows you to write code that is much more expressive than having ‘if != null‘ all over the place. Also, it is much less likely that you will forget to verify for nullity. One way of leveraging an Option value is through pattern matching:

val myValue: Option[String] = Some("Hello")
myValue match {
  case Some(x) => println("my value is " + x)
  case None => println("nonthing found")
}

The Option class also offers some collection-like functions that allow for great readability as well. From the Scaladoc:

val name: Option[String] = request.getParameter("name")
val upper = name map { _.trim } filter { _.length != 0 } map { _.toUpperCase }
println(upper.getOrElse(""))

Notice how the code execute transformations and ‘if-like’ filtering, in a very clean way. After that, they try to use the value with the getOrElse function, which allows you to pass a default value to be used if the result from the previous line was None. Finally, if you REALLY want to use an if statement, you can call the isDefined function, which returns true if the value is Some, false otherwise.

Now lets talk about system properties. Lets face it: dealing with System Properties in Java is boring. You have to get each property you are interested in and have to verify if it is null or empty. After all the talk above, you probably are starting to guess where I’m heading, right?

Well, it is better than that. Scala encapsulates the system properties in a way we can leverage all the Option stuff explained above. Those properties are encapsulated in a class named SystemProperties and can be accessed by the object ‘sys.props‘. Try typing it into a scala console session to see for yourself.

Since it is a map, you can use any map function you can use with other maps. Also, you can add and get properties from this object, and they will be reflected in the actual System Properties – which means that your Java code should be able to read the properties as well, even if through more traditional means (i.e. System.getProperty). Printing all system properties is as simple as:

sys.props.foreach(println)

And you clearly could do something more clever and useful with those properties.

There are two functions available in the SystemProperties class that I want to cover here: get and getOrElse. The first one returns a property with a given name, in an Option. With this, you can now handle your property with all the Option goodness we talked about above. The second function, getOrElse, is basically a direct way of calling the same function you could call in an Option. For example, lets say you read a database configuration from the system properties, and want to fall back to a default configuration if the property is not found:

val dbURL = sys.props.getOrElse("myapp.database.url", "jdbc:postgresql://localhost:5432/mydb")

A lot better than reading the property and verifying if it exists ‘by hand‘, right?

This time I wanted to bring something different about scala – so I decided to migrate a java project to this language. The chosen one is an open source test framework for the Web Objects framework (sorry for the double f* word there) called WOUnit.

Web Objects is a web application framework that is quite old, and is developed by Apple. I’m not the right person to talk about this framework, so I’m not going further than that. The point is that this framework has some specificities that could make writing pure JUnit tests more troublesome than it should be, and this is where WOUnit comes in.

This project is reasonably small, so its a good choice for our small experiment. I’ll talk about what I did bellow, you can take a look in the project in the link above, and in the changes I made in my fork.

The current changes consisted of the following steps:

• added the scala plugin and scala library dependency to the project’s pom.xml file – more about the maven scala plugin here;
• renamed the EOAssert.java file to EOAssert.scala;
• rewrote the contents of the file to use scala sintax

It was not complicated at all. You can find the current version of the file here. And what have we gained with this?

First, the code is now more readable. Which one is easier to read, this:

public static Matcher<EOEnterpriseObject> canBeDeleted() {
    return new CanBeDeletedMatcher<EOEnterpriseObject>();
}

or this:

def canBeDeleted(): Matcher[EOEnterpriseObject] =
  new CanBeDeletedMatcher[EOEnterpriseObject]

Nice, isn’t it? This comes to a point made by Martin Odersky (creator of Scala), where he said that the most important information in a function / method declaration is it’s name. Makes sense.

Second, you might have noticed that something seems to be missing in the scala version above. The java version has a static method, which doesn’t exist in scala. Actually, it isn’t even needed. Our EOAssert in scala is an object, which means scala handles it internally as a singleton. This feels a lot more correct from an object orientation point of view than having static things all over the place. Yet, from Java, you access EOAssert’s methods exactly as before – which means I didn’t have to change ANYTHING in the EOAssert class usages throughout the project, and it kept compiling and the tests passing.

Also, please notice how we are mixing java and scala code seamlessly here. Any doubts you could use scala as part of just about ANY java project without major headaches?

One thing I’m not sure about how it is working right now are the javadocs. In the migration, I kept then exactly how they were, and I’m not sure how the scaladoc would be generated for then. Since EOAssert class is intended as a public API, this is an issue that must be taken into account.

In summary, I didn’t do too much here – it was just a small experiment on migration a java project to scala. I hope you liked it and perhaps felt that scala is really worth considering serious usage. I’m not sure if I’ll continue this migration, but if I do, I’ll have more posts about it.

EDIT:

about the scaladocs point, this link might help a little bit: http://lampsvn.epfl.ch/trac/scala-old/wiki/Scaladoc/AuthorDocs