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.
There is the well established notion of what Scrum-But is. There is also a clear definition of Scrum – although people still argue if someone is doing Scrum or his process is only Scrumish. But more or less, territory is known. At least in the two dimensions, black and white about Scrum or not-Scrum.
After many years of Scrum people have inspected and adapted for many iterations. Additionally the current increase in lean and Kanban adoption engulfs many Scrum projects. Developers are using Scrum together with XP and some believe you are more successfully and productive when using XP practices together with Scrum.
There is no term describing these efforts. People who have moved beyond Scrum-by-the-book, adapted lean values, moved to flow and continuous deployments and who have perhaps dropped some of their Scrum practices (LINK mein blog) like iteration reviews, what should they call their process? Strong Scrum enthusiasts would say don’t call it Scrum at all. Call your process agile or lean. But with iterations, a ScrumMaster, ProductOwner and story point estimation, this sounds too weak and doesn’t reflect the still strong Scrum base of the practice.
I suggest calling these processes Trans-Scrum. This term is for people who still believe in Scrum and have adopted Scrum successfully, not those who dropped the effort for whatever reason (and this is fine!). As long as Scrum and the values of Scrum are the base of your process, you’re Trans-Scrum.
This would help communication between people, talking about processes and sharing knowledge and wisdom. I often struggle expressing myself what we do here. This is difficult because when you, as a Trans-Scrumer, tell people you do Scrum they get the wrong impression. If you tell them you don’t do Scrum, they also get the wrong impression. Even more if you tell them – who would? – you do Scrum-But? [1]
Only when you move beyond that, what some surely will as they adapt even more to their context, start calling your process something else.
What would you call this process? Scrum 2.0? Scrum++?
[1] The difference between Scrum-But and Trans-Scrum is, in the Toyota sense, that you’ve done practices in Trans-Scrum and after learning you’ve dropped them as not necessary. While with Scrum-But you don’t do these practices from the start because you think they don’t work for you.
Recently I’ve read a blog post by Keith Dahlby. It was titled “Is Functional Abstraction Too Clever?”. The title sounded more rhetoric because clearly Keith was very satisfied with the code he presented.
But it got me thinking again. After some time with Lisp at university, some Haskell and some functional thinking in Ruby, I’m deep into Scala for some months. I’ve written some functional code before in Java, but I’m using much more with Scala now. Many examples are mostly thinking and syntactic sugar to me, not something I can put a finger on: this is functional.
Haskell examples clearly are more functional – how so? – and some blog authors give very nice functional solutions. Some blog posts by Raganwald and Debasish gave me great insights into functional composability. But many examples of people new to functional programming do not look functional to me.
Keith says about functional programming:
To me, this is the value proposition of functional programming. By expressing the algorithm in terms of common operations, we’re able to spend more time thinking about the problem than the details of the solution.
Let’s take a look at his code:
static int[] GetSlots(int slots, int max)
{
return new Random().Values(1, max)
.Take(slots - 1)
.Append(0, max)
.OrderBy(i => i)
.Pairwise((x, y) => y - x)
.ToArray();
}
Looks more like a filter pipeline than functional programming. Especially compared for example to the things Apocalisp does with functional programming. Years ago I wrote a rendering pipeline, before the functional hype, and it was just a collection of Filter objects which filtered and transformed input into output. There were many users, and no-one thought of it as “functional”. Keith goes on:
A similar change in an imperative implementation would almost certainly have been more involved and prone to error.
The example is written in C# so it supports closures neatly, transformed to Java it might look like this (the generics are not totally correct, I’m spoiled by Scala):
static int[] getSlots(int slots, int max) {
return new Random()
.values(1,max)
.take(slots - 1)
.append(0, max)
.orderBy(new Order[int]() { public int by(int i) { return i })
.pairwise(new Folder[int]() { public int fold(int x, int y) { return y - x })
.toArray();
}
More involved? More prone to error? Not so sure. Someone with an OO background would righteously say: Sure this is OO. Method chaining and objects.
As we all know, Java is not a functional programming language, but an object oriented one. There isn’t much difference here, some shorter code, some syntactic sugar for creating functions. The only difference between object oriented and functional being that OO is more noisy? Is OO as superset of FP? The line blurs even more with Functional Java. Is functional not only a way of thinking? Immutable, side effect free, composable code blocks?
Is this example functional? What is functional? Your view would be appreciated, especially if you’re one of the usual suspects.
