Monday, January 10, 2011

Scala building blocks part 2: imports and packages

If you're used to Java, Scala imports and packages look both familiar and all wrong and weird.


The first thing that you may notice in some code you're reading is the use of _ in imports. The best way I've found to deal with _ is to replace it in my head with "whatever". It works in imports, but it also works in other cases where you encounter _.

So, when you see

import com.nancydeschenes.mosaique.model._

it means "import whatever you find under com.nancydeschenes.mosaique.model"

You can lump together multiple imports from the same package:

import scala.xml.{ NodeSeq, Group }

Imports are relative:

import net.liftweb._
import http._

imports whatever's needed in net.liftweb, and whatever's needed from net.liftweb.http.

But what if I have a package called http, and don't want net.liftweb.http? use the _root_ package:

import net.liftweb._
import _root_.http._


Like Java, code goes in packages. Unlike Java, packages aren't dictated by the directory structure. You can put multiple public classes in one file, and the location of the file doesn't imply what package it will be in. Do keep things simple, tho, if you ever want to be able to re-read yourself.

You can use the same package statement you would with Java:

package com.nancydeschenes.mosaique.snippet

Or, you can use the package block:

package com.nancydeschenes.mosaique {
  // Some stuff

  package snippet {
    // stuff that ends up in com.nancydeschenes.mosaique.snippet

Sunday, January 9, 2011

Scala building blocks

When I first started reading about Scala, I saw a lot of very interesting looking code, but I felt lost.  It looked as if I was trying to learn a foreign language with a phrasebook.  I saw a number of examples, but I felt I was missing the building blocks of the language.

I've been using Scala for a little while now, and this is the introduction I wish I'd had then.  This post is not meant as a detailed "how things are" but just to provide a newcomer with the right frame of mind to understand the rest.  There are some over-simplifications, but I find they help me understand, so I'm sharing them.

Classes, traits, objects, companions

Everything in Scala is an object, and every object is of a particular class.  Just like Java (if you ignore the pesky primitives).  So, generally speaking, classes work the way you expect them.  Except that there's no "static".  No static method, no static values.

Traits are like interfaces, but they can include fields and method implementations.

Objects can be declared and are then known throughout the program, in a way that's reminiscent of dependency injection, particularly the Grails flavour.  Object declarations can even include implementation, and new fields and methods.

Companion objects are objects named the same as a class.  This is how you handle details that you would normally want to do as static methods/fields/etc.  This is very elegant: it makes it look as if you had access to static elements, while preserving a true object-oriented approach.

So you may encounter code such as

class Car extends Vehicle with PassengerAble {
   val numWheels = 4
   val numPassengerSeats = 6

object Car {
  def findByLicensePlate(String plate, String emitter) : Car = {

object MyOwnCar extends Car with PassengerSideAirbags, RemoteStarter {
  val numChildSeats = 2;
  def honk : Unit = {;

In that example, the first Car is a class.  The second Car is an object.  MyOwnCar is an object that can be addressed anywhere (same package rules apply as java), but MyOwnCar has extra stuff in it: PassengerSideAirbags and RemoteStarter are trait (you can guess that because of the with keyword).  It even defines a new method so that honking it MyOwnCar should remind you of the Dukes of Hazzard.


Unlike Java, in Scala, everything is an object.  There is no such thing as a primitive.

Basic types

At the top of the object hierarchy, we have Any.  Every object, either what you think of an object in a Java sense, or the types that are primitives in Java, every thing inherits from Any.

The hierarchy then splits into two: AnyVal and AnyRef.  Primitive-like types are under AnyVal and AnyRef is essentially the equivalent of java.lang.Object.  All Java and Scala classes that you define will be under AnyRef.

Strings are just like Java Strings.  Double-quoted.  But Scala defines a few additional methods on them, and treats them as collections, too, so your String is also a list of characters.  A particularly convenient method, I've found, is toInt.  There's toDouble and toBoolean too.

Unit is what a method returns when it doesn't return anything.  You can think of it as "void".

Null as you know it is a value, but in Scala, every value has type, so it's of type Null.  And Null extends every single class, so that null (the one and only instance of Null) can be assigned to any AnyRef object.  It sounds crazy, but if you let it sink in, it will make sense.  Null is actually a trait, not a class.

Nothing is the absolute bottom of the hierarchy.  Nothing doesn't have any instances.

Numeric Types

Integers are of type Int.

Doubles are Doubles, floats are Float.

A litteral in the code is treated an object of the appropriate type.  Things just work, without "autoboxing" or other convolutions.

Strings and numeric types are immutable.


Collections come in mutable and immutable variations.

The operation you can perform on collections are probably easier to understand and get used to when you remember lisp/scheme.  Or perl.  Try to view collections are a whole, and not so much as an object with a few methods, the way we tend to in Java.  The think of the methods as operations on the whole.  It may also help to dust out set theory concepts.

A special kind of collection is the Tuple.   It's an ordered group of N items that can be of the same or of different types.  They are defined for N=2 to N=22.  You can access the j-th element of the tuple with ._j   (ex: the first is myTuple._1, the third is myTuple._3)


The first thing you have to realize about options is that they're everywhere, so you better get used to the idea.  Lift uses Box instead, but it serves the same purpose.

The second thing you have to realize is that Options (or Box) is the right way to handle multiple scenarios, but you've spent your programming life working around that fact.

Let's take a simple example.  You want to implement a method that computes the square root of the parameter it receives.  What should that method return?  a Double.  So you start:

def sqrt (x: Double) : Double = {
 // ...

You start implementing, maybe by writing some tests first... Hm... what happens if x is a negative number?  you may think "I'll just return null" or "I'll throw an exception".  If you return null, chances are the caller wont bother checking, and bad things will happen.  If you throw an exception, you slow things down a bit (exceptions should be for exceptional condition).  If you throw an unchecked exception, who knows where in the caller's code that will be handled.  If you throw a checked exception, the caller's probably already sick of catching every exception every where and has a standard, no-thought solution (ignore, wrap in a RuntimeException, etc)

Options tell you that there are multiple outcomes possible.  The case where a regular value is returned, the Option is actually a Some (subclass of Option), with the value in it.  In cases when no value can be returned, the Option is actually None (an object).  Of course, Options can be used in contexts other than returning a value from a method, but that's an easy way to see their usefulness.

Once you have an Option, you can test it for Some or None, or you can try to find what's in it: myOption.get will return the content of the Some (or throw an exception if it's None, so don't do that unless you know).  If you're not sure, you can use myOption.getOrElse(defaultVal)  which will return the contents of the Some, or gracefully (and elegantly) use the default you provided.

Or, you can use matching to decide what to do:

MathHelper.sqrt(x) match {
  case Some(y) => "The square root of " + x + " is " + y
  case None => "The value " + x + " does not have a square root"

Monday, January 3, 2011

Ruminations on Rejection

A few months ago, I attended a Montreal Geek Girl Dinner about "Women in technology".  I was hoping to meet like-minded women and maybe some men, but I was surprised that the majority of attendant were what I consider technology users, rather than technology producers.  These are women who use technology to provide content, who mange technology production, who sell it, who bring it to all of us, making our lives easier, more interesting, or more fun.  I was glad I came, even tho it wasn't what I had expected.

At one point, the issue of the few women speakers at conferences came up.  One of the the organizers of ConFoo (one of the brave men in attendance) asked for ways to get more speakers, because very few women step up.  I thought about it, and I think maybe I'm one of those women who just do not step up to be heard. I want to do it, but..  surely, there's someone better than me out there, surely there's nothing special I can bring to a crowd... I'm just a developer - a good one, but why me?  What would make me step up?

I'm not exactly shy.  Well, okay, maybe a little, but when I see a need, I step up.  I  usually let others lead, but when I know I can do better, I speak up, and guide the situation the way I think will work best.  So what would make me volunteer as a speaker? a void; a need.  I went to the organizer of ConFoo, and told him that maybe, instead of sending out vague requests for speakers, they should suggest specific topic to specific women, showing them the need.  Which he promptly turned around on me, and suggested I do a Grails talk at ConFoo.

I considered it for some time, trying to convince myself I could do it.  I know Groovy and Grails well, I like it, and I think I can communicate my enthusiasm to other developers.  I took a deep breath, and proposed the talk.  And felt all giddy.  And started thinking about how I'd do the presentation.  Then I realized I'm also pretty good at SQL, from a programmer's perspective.  How you can't tune a database on it's own, but you have to look at it in the context of the application; sometimes you have to change the logic in your program instead of tossing another index at the problem.  How sometimes, it's better if a process takes longer, if it's less intrusive on the other users of the system.  And how to write and rewrite queries until they do what you want, and how you want.  After the rush of the first proposal (and a few words of encouragement) I proposed a session on SQL for programmers.

Finally, I had most recently started working with Scala and Lift, and I could see the potential.  I submitted a session for this too, because I thought it should be presented, but I was hoping I wouldn't get selected - I have so little experience with it, and none in a proper "work" context, that I thought it was pushing it a little.  Still, no better way to learn than when thinking "and how do I explain that to someone else?"

So I submitted three talks, and waited.  I started writing notes about how I wanted to design each presentation, what aspects I particularly didn't want to forget, etc.  Just in case I was selected.  They did say they wanted a session on Grails, and they did say they wanted more women.  I wasn't expecting to get a session due to my gender alone, but I thought my chances were pretty good.  But I also knew very well I had no experience to show for, no visible accomplishment.  And I was worried that I would get selected! Would I have enough time to prepare as well as I'd like?

And then, the decision came.  The list of speakers was published, and I couldn't find my name on it.  I looked and looked and.. nope! nothing.  Not for the Scala talk, not for the Grails talk, not for the SQL talk.

I was surprised at how disappointed I was.  It's not like I was promised anything.  There were quite a number of proposals, many by professional speakers, or by people directly involved in the making of the technology discussed.  I was able to confirm later that there will be a talk on Grails, and at least a talk on SQL (by someone whose blog I've consulted on many occasions, so he's a lot more of an authority than I am, let's face it).  I didn't see anything about Scala/Lift, but I may have missed it.  And it's very new, and definitely a serious paradigm shift for anyone doing Java or PHP, and even Python.

So, why was I so disappointed?

Probably because in order to even dare proposing a session, I had to convince myself that it was needed, and that I was the only one who could do it.  I wasn't.  I don't like taking chances, I don't like selling myself.  People should just realize how awesome I am, without me ever having to brag.  Yeah, that's not how it works..  I have done very well for myself with that philosophy, but I have also not done anything particularly visible, cool, amazing...  Oh, I've done some really impressive stuff.  I wrote one of the first CMS (but you wouldn't know it) and I worked one some pretty cool sites (like - but you probably don't remember it).  I wrote one of the first applets that kept track of who was on-line - well before anyone spoke of "Web 2.0".  Well, if I want to be seen, be recognized by my peers, I'll have to do a lot more than wait for someone to offer me a session at a conference.

What now?

Now that I've tasted the thrill of proposing sessions at a conference, and now that I know that rejection sucks, but you survive, dust yourself off, put a band-aid on the bruised ego and move on... now, I've decided that working alone in my office and gathering knowledge and skills is not enough.  I want more.  I will be more.  I will take risks, and put myself out there.  I will not stop at "what I'm supposed to do".  I will also listen to what I want to do.  And I will try to share what I know, as best I can.  And there are plenty of other conferences.  And there's next year.

I know that whenever we do something, we "practice" doing it - we get better at it, it becomes easier.  So it's time for me to start practicing risk taking.  At least a little.

Isn't it convenient that this is happening at the turning of the year?

Here's to 2011!