Scala is ideally suited for programming in roles because it does features traits. Think of Traits like interfaces in Java with implementation code. Say you have a dog:
class Dog {
def call() { println("Comes to you") }
def feed() { println("Feeds") }
}
then this dog has two roles, Callable and Feedable. You can extract those into traits:
trait Callable {
def call() { println("Comes to you") }
}
trait Feedable {
def feed() { println("Feeds") }
}
and combine them with your Dog:
class Dog extends Callable with Feedable
This is the first Scala goodness. But you can also extend your Dog at calltime:
scala> class Dog
defined class Dog
scala> val d = new Dog
d: Dog = Dog@1f808e6
scala> d.call
:7: error: value call is not a member of Dog
d.call
^
scala> val d = new Dog with Callable with Feedable
d: Dog with Callable with Feedable = $anon$1@1bca486
scala> d
res5: Dog with Callable with Feedable = $anon$1@1bca486
scala> d.call
Comes to you
When you’ve developed Java for some time and adhere to the usage of interfaces for roles, you surely have tripped over the problem that one of your methods expects a parameter object to implement two interfaces (sometimes this is a sign that the method does too much) and you resorted to adding an object twice to the method signature:
public void callAndFeed(Callable c, Feedable f) {
c.call();
f.feed();
}
callAndFeed(dog,dog);
The call with twice the dog really does look ugly. And you get into shallow water semantically. Does the method call the two methods on two objects? Shouldn’t it call them on one method after each other?
Update: As Daniel pointed out, in Java one can write:
public void callAndFeed(T cf) {
cf.call();
cf.feed();
}
In Scala the method can be expressed nicer with a compound type as the parameter type:
scala> def callAndFeed(d:Callable with Feedable) {
d.call();
d.feed();
}
callAndFeed: (Callable with Feedable)Unit
scala> callAndFeed(d)
Comes to you
Feeds
Scala glory!
With all this talk about NoSQL and new programming languages, I though I’d try getting Cassandra to work with Scala. Always being interested in productivity, I wanted to know how easy and concise an integration would be. One option was to use the Java client for Cassandra, as using Java libraries in Scala is rather easy. Obviously more concise would be a library written for Scala, so I tried Akka.
What is Cassandra? Taken from the homepage
Cassandra is a highly scalable, eventually consistent, distributed, structured key-value store. Cassandra brings together the distributed systems technologies from Dynamo and the data model from Google’s BigTable. Like Dynamo, Cassandra is eventually consistent. Like BigTable, Cassandra provides a ColumnFamily-based data model richer than typical key/value systems.
Cassandra has a steep learning curve as it’s more than a key/value store. The article WTF is a SuperColumn helped me tremendously.
After installing Cassandra you need to configure your storage. For this short example only one entry is necessary.
<Keyspaces>
<Keyspace Name="AweSomeApp">
<ColumnFamily CompareWith="UTF8Type" Name="ShoppingList"/>
</Keyspace>
</Keyspaces>
What is Akka?
What is Akka? Akka is a framework stack for highly scalable, concurrent applications in Scala and Java. Akka supports different concurrency paradigms like actors and software transactional memory (STM) and easy and automatic storage to backends, including Cassandra and MongoDB.
As I’m using Maven – still I know – I wanted to get Akka running with Maven. Getting Akka to work with Maven was easy. I compiled Akka to get a 0.6 JAR which I put in an embedded repository in Maven. For Cassandra I’ve used the 0.4 version. I took a clue from the Akka Maven description and created an embedded repository for my Akka JAR.
<repositories>
<repository>
<id>project.embedded.module</id>
<name>Project Embedded Repository</name>
<url>file://${basedir}/../embedded-repo</url>
</repository>
<repositories>
Then adding a dependency for Akka. The generated Akka JAR contains all dependencies which is nice for prototyping but would be needed to change in a production enviroment.
<dependency>
<artifactId>akka</artifactId>
<groupId>se.scalablesolutions.akka</groupId>
<version>0.6</version>
</dependency>
Now your application should build with an Akka dependency.
The Scala code
The example application I’ve written is managing a shopping list. I’ve used this example before to illustrate AJAX, REST, JSON and XML. The core is a domain class called ShoppingList. It’s modeled after the domain classes in Lift and uses a composable, domain driven design. The class is short and does only contain a name, an id an a list of items.
class ShoppingList extends Entity
with Nameable[ShoppingList]
with Idable[ShoppingList, String] {
object items extends OneToMany[ShoppingList, Item](this)
}
Now we want to store an instance of ShoppingList. In which format to write data to the Cassandra Storage? I decided to go with a more key/value storage approach at first and do not use Cassandra for structuring data. This leaves the question how to store the value. Beside binary formats there are two obvious contenders: JSON and XML. Both have pros and cons.
JSON has the benefit of storing – after checking – data from AJAX calls directly to the storage and retrieving data and delivering data without processing to AJAX calls. The downside of JSON is it does contain less semantic information and could lead to problems down the road. XML is a better format for long term storage and enterprise integration as it contains more semantic information and is easy accessible. The downside: Very few people use XML for AJAX and it’s much more verbose than JSON.
Let’s try both approaches with Scala. Converting an object to XML is easy with Scala, as Scala has builtin XML support.
def toNode(list: ShoppingList) = {
import list._
<shopping-list>
<id>{id.stringify}</id>
<name>{name}</name>
<list:items>{items.list.map(Item.toNode(_))}</list:items>
</shopping-list>
}
With LiftJson (which is usable without Lift) it’s nearly as easy to generate JSON:
def toJson(list: ShoppingList) = {
import list._
JsonAST.render(
("id" -> id.stringify) ~
("name" -> name.get) ~
("items" -> items.list.map(Item.toJson(_)))
)
}
which would result in
{
"id":"3",
"name":"Steffis list",
"items":[{
"description":"First"
},{
"description":"Really Second"
},{
"description":"Third"
}]
}
Reading and writing to Cassandra with Akka
Now to the juicy bits, reading and writing to Cassandra with Akka.
val ENCODING = "UTF-8"
val columnName = "list".getBytes(ENCODING)
def find(id: String) = {
val column:Option[ColumnOrSuperColumn] =
CassandraStore.sessions.withSession {
session =>
session | (id, new ColumnPath("ShoppingList", null, columnName))
}
if (column.isDefined) {
// Convert to ShoppingList
...
Some(shoppingList)
} else {
None
}
}
where the CassandraStore is a static wrapper around the Akka Cassandra sessions. Obviously this would need to go into a injected dependency or a base class. Storing data into Cassandra is just as easy.
def store(list: ShoppingList) {
// insert a column
val value = ShoppingList.toNode(list).toString.getBytes(ENCODING)
CassandraStore.sessions.withSession {
session =>
session ++| (list.id.stringify,
new ColumnPath("ShoppingList", null, columnName),
value,
System.currentTimeMillis)
}
}
Up to now I’m still quite satisfied with the code, how Akka worked with Cassandra. Cassandra setup in a VirtualBox and Ubuntu was easy and is a sane approach for working on Windows. With this code it should be easy for you to get Cassandra going with Scala. Any hints, opinions and suggestions, as usual in the comments.
There are many traits a good developer has. Focus. Sense of Quality. Interest in what he does. Knowledge of programming languages and skills in software development. An opinion. Team player. Update see comments: Being creative and innovative. Propose ideas.
But the things I most value are professionalism and getting things done.
Those are similar to the one Fog Creek and Joel Spolsky find important. Joel on Software values:
First of all, the #1 cardinal criteria for getting hired at Fog Creek:
Smart, and
Gets Things Done.
Why professionalism? There is not enough sense of a profession on our industry. We do need more professionalism to be taken serious by others. By our customers. Noone would argue with an account about his practices, or with a surgeon about his. The only high-profile person caring about professionalism seems to be Uncle Bob. This can be felt in many of his arguments:
Look, TDD is not my religion, it is one of my disciplines. It’s like dual entry bookkeeping for accountants, or sterile procedure for surgeons. Professionals adopt such disciplines because they understand the theory behind them, and have directly experienced the benefits of using them.
Professionalism is about not doing things that are stupid. Not cutting corners. Have pride in your work and write clean code. Get the software development industry and your job to a level where surgeons and accountants have been for centuries.
Why gettings things done? In the end, what counts is money earned. Everything else is a proxy. If you want to get paid, your company needs to earn money. Honour deadlines. Getting things done means no gold plating. It means understanding the necessity for business to get features to their customers. Suppressing the urge to develop a framework out of everything, to develop frameworks first before you really know what is needed. Write frameworks when it helps you getting things done. To dive into large refactorings at the wrong time.
You need to strike a balance between both. Too much professionalism and your customers will be annoyed. As will be your boss and your colleagues. It means you will make professionalism and end in itself and forget about getting things done. Too big a focus on getting things done will make you cut corners. Write bad code. Being not professional.
Your company needs to support you with both – a environment for professionalism and letting you getting things done. Many companies don’t. Some focus too much on professionalism, some focus too much on getting things done. What if your environment doesn’t support you? Joel writes in another article about you getting things done:
A lot can be done to improve the project just by one person doing it. Don’t have a daily build server? Make one. Set your own machine up with a scheduled job to make builds at night and send out email results. Does it take too many steps to make the build? Write the makefile. Nobody does usability tests?
And most managers will value you highly when you get things done.
What about you, what do you value? I’d like to hear in the comments.
