Daniel Westheide

on making software

The Neophyte’s Guide to Scala Part 1: Extractors

More than 50,000 people signed up for Martin Odersky’s course “Functional Programming Principles in Scala” at Coursera. That’s a huge number of developers for whom this might have been the first contact with Scala, functional programming, or both.

If you are reading this, maybe you are one of them, or maybe you have started to learn Scala by some other means. In any case, if you have started to learn Scala, you are excited to delve deeper into this beautiful language, but it all still feels a little exotic or foggy to you, then the series of articles that is beginning with this one is for you.

Even though the Coursera course covered quite a lot of what you need to know about Scala, the given time constraints made it impossible to explain everything in detail. As a result, some Scala features might seem like magic to you if you are new to the language. You are able to use them somehow, but you haven’t fully grasped how they work and, more importantly, why they work as they do.

In this article and the ones following in the coming weeks, I would like to clear things up and remove those question marks. I will also explain some of the features of the Scala language and library that I had trouble with when I started learning the language, partially because I didn’t find any good explanations for them, but instead just stumbled upon them in the wild. Where appropriate, I will also try to give guidance on how to use these features in an idiomatic™ way.

Enough of the introductions. Before I begin, keep in mind that, while having attended the Coursera course is not a prerequisite for following this series, having roughly the knowledge of Scala as can be acquired in that course is definitely helpful, and I will sometimes refer to the course.

So how does this pattern matching thingie actually work?

In the Coursera course, you came across one very powerful language feature of Scala: Pattern matching. It allows you to decompose a given data structure, binding the values it was constructed from to variables. It’s not an idea that is unique to Scala, though. Other prominent languages in which pattern matching plays an important role are Haskell and Erlang, for instance.

If you followed the video lectures, you saw that you can decompose various kinds of data structures using pattern matching, among them lists, streams, and any instances of case classes. So is this list of data structures that can be destructured fixed, or can you extend it somehow? And first of all, how does this actually work? Is there some kind of magic involved that allows you to write things like the following?

1
2
3
4
5
case class User(firstName: String, lastName: String, score: Int)
def advance(xs: List[User]) = xs match {
  case User(_, _, score1) :: User(_, _, score2) :: _ => score1 - score2
  case _ => 0
}

As it turns out, there isn’t. At least not much. The reason why you are able to write the above code (no matter how little sense this particular example makes) is the existence of so-called extractors.

In its most widely applied form, an extractor has the opposite role of a constructor: While the latter creates an object from a given list of parameters, an extractor extracts the parameters from which an object passed to it was created.

The Scala library contains some predefined extractors, and we will have a look at one of them shortly. Case classes are special because Scala automatically creates a companion object for them: a singleton object that contains not only an apply method for creating new instances of the case class, but also an unapply method – the method that needs to be implemented by an object in order for it to be an extractor.

Our first extractor, yay!

There is more than one possible signature for a valid unapply method, but we will start with the ones that are most widely used. Let’s pretend that our User class is not a case class after all, but instead a trait, with two classes extending it, and for the moment, it only contains a single field:

1
2
3
4
5
trait User {
  def name: String
}
class FreeUser(val name: String) extends User
class PremiumUser(val name: String) extends User

We want to implement extractors for the FreeUser and PremiumUser classes in respective companion objects, just as Scala would have done were these case classes. If your extractor is supposed to only extract a single parameter from a given object, the signature of an unapply method looks like this:

1
def unapply(object: S): Option[T]

The method expects some object of type S and returns an Option of type T, which is the type of the parameter it extracts. Remember that Option is Scala’s safe alternative to the existence of null values. There will be a separate article about it, but for now, it’s enough to know that the unapply method returns either Some[T] (if it could successfully extract the parameter from the given object) or None, which means that the parameters could not be extracted, as per the rules determined by the extractor implementation.

Here are our extractors:

1
2
3
4
5
6
7
8
9
10
11
12
trait User {
  def name: String
}
class FreeUser(val name: String) extends User
class PremiumUser(val name: String) extends User

object FreeUser {
  def unapply(user: FreeUser): Option[String] = Some(user.name)
}
object PremiumUser {
  def unapply(user: PremiumUser): Option[String] = Some(user.name)
}

We can now use this in the REPL:

1
2
scala> FreeUser.unapply(new FreeUser("Daniel"))
res0: Option[String] = Some(Daniel)

But you wouldn’t usually call this method directly. Scala calls an extractor’s unapply method if the extractor is used as an extractor pattern.

If the result of calling unapply is Some[T], this means that the pattern matches, and the extracted value is bound to the variable declared in the pattern. If it is None, this means that the pattern doesn’t match and the next case statement is tested.

Let’s use our extractors for pattern matching:

1
2
3
4
5
val user: User = new PremiumUser("Daniel")
user match {
  case FreeUser(name) => "Hello " + name
  case PremiumUser(name) => "Welcome back, dear " + name
}

As you will already have noticed, our two extractors never return None. The example shows that this makes more sense than it might seem at first. If you have an object that could be of some type or another, you can check its type and destructure it at the same time.

In the example, the FreeUser pattern will not match because it expects an object of a different type than we pass it. Since it wants an object of type FreeUser, not one of type PremiumUser, this extractor is never even called. Hence, the user value is now passed to the unapply method of the PremiumUser companion object, as that extractor is used in the second pattern. This pattern will match, and the returned value is bound to the name parameter.

Later in this article, we will see an example of an extractor that does not always return Some[T].

Extracting several values

Now, let’s assume that our classes against which we want to match have some more fields:

1
2
3
4
5
6
7
trait User {
  def name: String
  def score: Int
}
class FreeUser(val name: String, val score: Int, val upgradeProbability: Double)
  extends User
class PremiumUser(val name: String, val score: Int) extends User

If an extractor pattern is supposed to decompose a given data structure into more than one parameter, the signature of the extractor’s unapply method looks like this:

1
def unapply(object: S): Option[(T1, ..., Tn)]

The method expects some object of type S and returns an Option of type TupleN, where N is the number of parameters to extract.

Let’s adapt our extractors to the modified classes:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
trait User {
  def name: String
  def score: Int
}
class FreeUser(val name: String, val score: Int, val upgradeProbability: Double)
  extends User
class PremiumUser(val name: String, val score: Int) extends User

object FreeUser {
  def unapply(user: FreeUser): Option[(String, Int, Double)] =
    Some((user.name, user.score, user.upgradeProbability))
}
object PremiumUser {
  def unapply(user: PremiumUser): Option[(String, Int)] = Some((user.name, user.score))
}

We can now use this extractor for pattern matching, just like we did with the previous version:

1
2
3
4
5
6
val user: User = new FreeUser("Daniel", 3000, 0.7d)
user match {
  case FreeUser(name, _, p) =>
    if (p > 0.75) name + ", what can we do for you today?" else "Hello " + name
  case PremiumUser(name, _) => "Welcome back, dear " + name
}

A Boolean extractor

Sometimes, you don’t really have the need to extract parameters from a data structure against which you want to match – instead, you just want to do a simple boolean check. In this case, the third and last of the available unapply method signatures comes in handy, which expects a value of type S and returns a Boolean:

1
def unapply(object: S): Boolean

Used in a pattern, the pattern will match if the extractor returns true. Otherwise the next case, if available, is tried.

In the previous example, we had some logic that checks whether a free user is likely to be susceptible to being persuaded to upgrade their account. Let’s place this logic in its own boolean extractor:

1
2
3
object premiumCandidate {
  def unapply(user: FreeUser): Boolean = user.upgradeProbability > 0.75
}

As you can see here, it is not necessary for an extractor to reside in the companion object of the class for which it is applicable. Using such a boolean extractor is as simple as this:

1
2
3
4
5
val user: User = new FreeUser("Daniel", 2500, 0.8d)
user match {
  case freeUser @ premiumCandidate() => initiateSpamProgram(freeUser)
  case _ => sendRegularNewsletter(user)
}

This example shows that a boolean extractor is used by just passing it an empty parameter list, which makes sense because it doesn’t really extract any parameters to be bound to variables.

There is one other peculiarity in this example: I am pretending that our fictional initiateSpamProgram function expects an instance of FreeUser because premium users are never to be spammed. Our pattern matching is against any type of User, though, so I cannot pass user to the initiateSpamProgram function – not without ugly type casting anyway.

Luckily, Scala’s pattern matching allows to bind the value that is matched to a variable, too, using the type that the used extractor expects. This is done using the @ operator. Since our premiumCandidate extractor expects an instance of FreeUser, we have therefore bound the matched value to a variable freeUser of type FreeUser.

Personally, I haven’t used boolean extractors that much, but it’s good to know they exist, as sooner or later you will probably find yourself in a situation where they come in handy.

Infix operation patterns

If you followed the Scala course at Coursera, you learned that you can destructure lists and streams in a way that is akin to one of the ways you can create them, using the cons operator, :: or #::, respectively:

1
2
3
4
5
val xs = 58 #:: 43 #:: 93 #:: Stream.empty
xs match {
  case first #:: second #:: _ => first - second
  case _ => -1
}

Maybe you have wondered why that is possible. The answer is that as an alternative to the extractor pattern notation we have seen so far, Scala also allows extractors to be used in an infix notation. So, instead of writing e(p1, p2), where e is the extractor and p1 and p2 are the parameters to be extracted from a given data structure, it’s always possible to write p1 e p2.

Hence, the infix operation pattern head #:: tail could also be written as #::(head, tail), and our PremiumUser extractor could also be used in a pattern that reads name PremiumUser score. However, this is not something you would do in practice. Usage of infix operation patterns is only recommended for extractors that indeed are supposed to read like operators, which is true for the cons operators of List and Stream, but certainly not for our PremiumUser extractor.

A closer look at the Stream extractor

Even though there is nothing special about how the #:: extractor can be used in pattern matching, let’s take a look at it, to better understand what is going on in our pattern matching code above. Also, this is a good example of an extractor that, depending on the state of the passed in data structure, may return None and thus not match.

Here is the complete extractor, taken from the sources of Scala 2.9.2:

taken from scala/collection/immutable/Stream.scala, (c) 2003-2011, LAMP/EPFL
1
2
3
4
5
object #:: {
  def unapply[A](xs: Stream[A]): Option[(A, Stream[A])] =
    if (xs.isEmpty) None
    else Some((xs.head, xs.tail))
}

If the given Stream instance is empty, it just returns None. Thus, case head #:: tail will not match for an empty stream. Otherwise, a Tuple2 is returned, the first element of which is the head of the stream, while the second element of the tuple is the tail, which is itself a Stream again. Hence, case head #:: tail will match for a stream of one or more elements. If it has only one element, tail will be bound to the empty stream.

To understand how this extractor works for our pattern matching example, let’s rewrite that example, going from infix operation patterns to the usual extractor pattern notation:

1
2
3
4
5
val xs = 58 #:: 43 #:: 93 #:: Stream.empty
xs match {
  case #::(first, #::(second, _)) => first - second
  case _ => -1
}

First, the extractor is called for the intitial stream xs that is passed to the pattern matching block. The extractor returns Some((xs.head, xs.tail)), so first is bound to 58, while the tail of xs is passed to the extractor again, which is used again inside of the first one. Again, it returns the head and and tail as a Tuple2 wrapped in a Some, so that second is bound to the value 43, while the tail is bound to the wildcard _ and thus thrown away.

Using extractors

So when and how should you actually make use of custom extractors, especially considering that you can get some useful extractors for free if you make use of case classes?

While some people point out that using case classes and pattern matching against them breaks encapsulation, coupling the way you match against data with its concrete representation, this criticism usually stems from an object-oriented point of view. It’s a good idea, if you want to do functional programming in Scala, to use case classes as algebraic data types (ADTs) that contain pure data and no behaviour whatsoever.

Usually, implementing your own extractors is only necessary if you want to extract something from a type you have no control over, or if you need additional ways of pattern matching against certain data. For example, a common usage of extractors is to extract meaningful values from some string. As an exercise, think about how you would implement and use a URLExtractor that takes String representations of URLs.

Conclusion

In this first part of the series, we have examined extractors, the workhorse behind pattern matching in Scala. You have learned how to implement your own extractors and how the implementation of an extractor relates to its usage in a pattern.

We haven’t covered all there is to say about extractors, because this article is already long enough as it is. In the next part of this series, I am going to revisit extractors, covering how to implement them if you you want to bind a variable number of extracted parameters in a pattern.

Please do let me know if this article was helpful to you or if something is not clear to you.

Functional Programming Principles in Scala: A Wrap-up

For the past seven weeks, I have been participating in the online class “Functional Programming Principles in Scala” provided by Martin Odersky, the EPFL, and Coursera. This has not only reignited my more or less dormant passion for the Scala language, but has also been tremendously fun and instructive at the same time. Having just finished the final assignment, let me tell you why.

First of all, of course, the chance of attending a class on a programming language and paradigm that is conducted by the very designer of that language, a distinguished expert in their field, is all kinds of amazing in itself. It’s great to live in a time in which attending such a class online and for free is possible for thousands of interested students who would otherwise not have had the opportunity at all, or who otherwise have to make do with the often times mediocre lecturers at their own university.

This was my first ever online class, and I must say I didn’t really miss the physical presence of a meatspace university class at all. In each of the seven weeks, the programme consisted of numerous video lectures, sessions of five to 25 minutes, altogether between one and two hours a week. These video lectures were accompanied by weekly (or sometimes biweekly) programming assignments in which students had to transfer and apply what they learned to a new problem. Usually, this meant to implement several pre-defined functions, with the groundwork already laid for you.

During the first couple of weeks, the course was focused a lot on the basic principles of functional programming, while keeping the amount of Scala syntax and library code used to an absolute minimum. This changed in the second half, when a bunch of important Scala concepts were introduced, like for comprehensions and pattern matching.

I found the course to be challenging at just the right level, and the assignments had just about the right mixture of highly abstract problems and ones with interesting practical relevance, like analyzing a feed of tweets or implementing a solver for an interesting Flash game. I have already had my share of experience with functional programming in general, and Scala in particular, so some small parts of assignments were just a finger exercise, and I assume I haven’t had to think about getting my Scala code syntactically right or more idiomatic as much as students new to the language.

Thankfully, such experience didn’t make solving the assignments a cakewalk altogether. I noticed that I wasn’t used to thinking in the abstract any more as much as I had thought, so having to reflect on these problems to come up with a solution was not always easy and took a while, but was also one of most important profits I drew from the class. I literally felt like a student again, back in the days, and enjoyed this very much.

The Coursera Scala course is highly recommended if you want to delve into the world of functional programming or you want to learn Scala. I don’t know any other up-and-coming language with such high-quality, educational and fun learning material, so I can imagine Scala gaining some traction from it.

Have you attended the course, too? If so, tell me about your experience!

Bonn Agile August 2012: CQRS-based Architectures

Last Monday, at the August meetup of Bonn Agile, I did a talk about architectures based on the CQRS pattern. I presented various opportunities enabled by this pattern, specifically asymmetrical scaling, separating the models for reading and writing, eventual consistency, and event sourcing. I also put up some very crude demo code in Scala to show how one might implement a command handler and a write model handler, and how easy it is to build the current state of an aggregate from the events stored for it.

Although the pattern and the architectural decisions it enables haven’t made their way into the mainstream yet, a couple of people had at least heard of them. Since I was speaking to an audience of agilists, I tried to bring two questions into the focus of the discussion:

  1. How can such an architecture help us be more agile?
  2. When does it rather hinder us from being agile?

I might put my thoughts on these topics into a blog post if there is sufficient interest in that.

What I really found interesting about the evolving discussion at the end of my talk was the fact that some people have built applications in which events are actually an almost natural part of the domain model. Apparently, they implemented some of the ideas behind event sourcing, but without really knowing about it, so events did not play the first class role that they have in an event-sourced architecture. This suggests that currently, CQRS-based architectures, and especially event sourcing, are indeed under-used.

Link: Slides

Book Review: Team Geek

Many books have been published about the technical aspects of software development, and, granted, a lot has been written about how to successfully manage IT projects and about why and how to apply certain agile methodologies. Yet, you hardly find any literature dealing with the human factors of software development, neither does it play a significant role on any of the computer science curricula that I know of.

This is is especially strange because, based on my own experience and my conversations with other developers, human problems among team members as well as with other stakeholders, be it managers or users, seem to be very common and can have more serious consequences for the success of a project than is apparent at first glance.

Behold, though, fellow developers, you no longer need to shed lonely tears! “Team Geek” is a completely non-technical book by Google’s Brian Fitzpatrick and Ben Collins-Sussman that, while also containing some crucial lessons for management people, is targeted explicitly at software developers.

As a developer, you are nearly always in the position of being a member of a team, and all of a sudden, sooner than you know, you may even find yourself leading a team, even if it’s only temporary. This book teaches you a couple of important things:

  • How to be a great team member
  • How to be a good team leader
  • How to recognize and deal with poisonous team members of various categories
  • How to deal with poisonous people from outside your team
  • How to exert influence in your company or other organization

In each of the chapters of the book, Fitzpatrick and Collins-Sussman describe certain problems that are likely to occur in software development teams or projects sooner or later, often anecdotally, sometimes also as a collection of anti-patterns. Most of the problems can occur both in a company environment as well as in medium-sized or big open source projects. However, some of them are very specific to open-source projects and stem directly from the authors’ experience with the Subversion project.

All this is written in a very entertaining and engaging way, and unless you are an extremely lucky person or someone who is only about to start their career as a software developer, you will often nod in agreement, hopefully smiling, thinking of specific instances of the described problems that you have experienced first-hand. The text is far from being dry, and so are the humourous illustrations that clarify the authors’ respective messages.

While the price of the book is worth paying for the entertainment value of the described problems alone, what makes this book really valuable, of course, are the proposed ways of dealing with each of the described problems, which are based on many years of experience by the two authors.

In the end, Fitzpatrick and Collins-Sussman always come back to the trinity of humility, respect, and trust (HRT) as the core of nearly all their problem solutions, and to building and keeping intact a specific team culture. Of course, there are more specific recommendations than that, but they are mostly based on one or more of those three principles.

While some of the solutions are rather obvious, and some very few I do not wholeheartedly agree with, all in all I found this book to be a real treasure, giving me new insight, new perspectives, and also more confidence in dealing with the addressed human problems of software development. An especially inspirational chapter was the one on “The Art of Organizational Manipulation”. It demonstrates that fighting the ways an organization works, no matter how pointless its rules are, only brings you so far. Instead, understand the rules, play by them, and the chances are usually much better that you will be able to change it to the better, thereby essentially hacking the organization.

TL;DR: Being a great developer also comprises being a great team player. “Team Geek” teaches you exactly that and should be required reading for prospective and experienced software developers alike. Even if you don’t have any of the covered problems in your current team, you will want to be prepared for it.

Team Geek: A Software Developer’s Guide to Working Well with Others
By Brian W. Fitzpatrick and Ben Collins-Sussman
Publisher: O’Reilly
Released: July 2012
Pages: 194

Link: “Team Geek” at the O’Reilly shop

Advance Hackathon 2012: A Retrospective

Last weekend, I attended the Advance Hackathon 2012, which was hosted at the Coworking Space Gasmotorenfabrik in Cologne. Even though I had been intending to participate at such an event for a long time, this was indeed my first hackathon.

There were 80-90 people working on 20 projects from Saturday, 10am to Sunday 4pm. All of the projects were very interesting, and most of them managed to make a lot of progress in the course of the weekend.

The project I was involved in is called lunjure. Our goal was to create a lunch planner as a single-page HTML5 web application that is written in pure Clojure and ClojureScript, making use of web sockets for most of the communication between the client and the server. While we didn’t finish this project in the short time of the hackathon, we managed to implement all of the core functionality and will probably continue working on it. If nothing else, it is certainly a nice demo project showcasing the usage of the aforementioned technologies.

The only minor complaint I have to make is this: Everybody who had submitted a project idea was to pitch it on Saturday morning in order to find interested developers. However, my impression was that least 80 percent of the participants had already formed teams before the hackathon, and that for the most part, people who already knew each other worked together in a team. This is okay, of course (and maybe my impression is completely wrong anyway), but it made the whole pitching process somewhat redundant.

Nevertheless, it was an amazing weekend, and all the people involved in the organization did an outstanding and highly professional job, and what little need for improvisation arose once in a while was handled very gracefully. Also, the whole atmosphere was very friendly and cooperative. I would definitely like to see an Advance Hackathon 2013.

Google+ Circles: Square Them, Please!

More than two months ago, I wrote an article about the then brand-new Google+ and its most prominent feature, Circles, announcing a follow-up in which I would dwell on the shortcomings and problems of this feature. Well, since I only found the time to write this article now, some of those problems have either already been addressed or at least acknowledged by the Google+ team, or they have already been discussed by other people. So, please forgive me if any of the points I make in this article are an old hat to you.

The fair-play network

During the last couple of months, I have been using Google+ quite a lot, and I noticed that it does its job very well when it comes to helping me to protect my privacy. Only sharing something with a specific circle of friends, but not with your co-workers, for example, is a breeze.

However, I also noticed that this is not the primary motivation for me and many others to use Google+ and its Circles feature. Somehow, the idea of Circles lends itself to being a fair-play social network user, one who cares about not spamming the people he is connected to with stuff they are most certainly not interested in. You do that, of course, by having circles for each of your different interests groups, and posting the stuff only to the appropriate circle.

While this basically works, it also makes the thing I shared private when all I wanted was be friendly to the people whom I assumed not to be interested in that posting. Alright, this posting can still be shared by those people who did see it in the first place, but wouldn’t it be great if I was able to make something public in the first place, and still prevent certain circles from seeing it in their default stream?

Also, certain people are just not into fair-play, but I’m still interested in some of the things they share. As a consumer, I have an all-or-nothing choice to make: Either accept to receive all of that person’s postings, or none at all. My suggestion would be that people can publish certain circles of interest, and others can then subscribe to those circles. Those circles would be public and not meant to protect your privacy.

Scaling

Currently I have about 80 people in twelve circles. This is not much at all. Yet, I already noticed that managing your circles can become a problem with this low number of people.

The thing is, if you use your circles to be a fair player, you want to organize the people in your circles by various dimensions – for instance, by interest, by language, and possibly by location, and probably also by how close you are to them. I don’t really want to have a circle “Software developers, German”, and another one, “Software developers, English”, and so on for my other interests. Hence, I really miss the feature to share postings with the intersection of two or more circles. This would radically reduce the number of circles I need for my purposes.

Summary

In my opinion, Google+ Circles are still the best currently available way of doing social networking. However, there are numerous issues that prevent it from being the perfect solution catering to my specific needs and customs. I am not sure if some of my ideas would pollute the incredibly clean and simple design of G+ by adding a lot of complexity to the user interface. Am I asking for squaring the cirlce?

Google+ Circles: The Swiss-Army Knife of Social Networking

Yesterday, only one day after Google+ was announced, I got an invite and so became one of the lucky people who can participate in the field test of this new set of social networking tools, labelled by many as “Google’s Facebook killer”. My first impression is a very positive one: The user interface is much more tidy than Facebook’s, and altogether it appears to be very well thought out1, taking a user-centered approach to design. For me, Google+ comes very close to how I want a social networking site to be, and as Gina Trapani pointed out, Google has apparently learned a lot from the mistakes made with Buzz and Wave.

Personally, I think that Circles is the most important feature of Google+. Every individual has got multiple identities, and managing them has been either too difficult or impossible in existing social networking or microblogging platforms. While Circles is definitely not perfect, it makes the management of what you want to share with whom a core part of the application. Both Facebook and Twitter are problematic at best in this regard.

In the following, I’m going to describe some typical problems I have experienced with Facebook and Twitter, and how Circles can help to solve them. In a future article, I will elaborate on the shortcomings I see with the current shape of Circles.

Yes, I sort of know you, but I like my privacy!

Maybe this is just me, but this is something I regularly stumble upon at Facebook. Someone I know wants to add me as a friend. It would be impolite to deny the friend request, so I accept. But I don’t want that person to read about everything I write. That stuff targeted at people that are much closer to me. Creating a group and putting such people in there is not that intuitive in Facebook. I want to be stupid! Doing this must be super easy without requiring me to think. Also, I don’t want that person to be informed that I put them into my group “People I pretend to be friends with”.

With Circles, this is not a problem at all. Upon adding a person to my contacts, you are forced to choose at least one circle that person is supposed to belong to. Just put them into your “Pretended friends” circle (optionally create that circle in the same step) and nowhere else, and never share anything with that circle. The person will be informed that they have been added to your circles, but they don’t know anything about the particular circles you chose for them. Nifty!

What comes in really handy to ensure that you indeed never share anything with that circle is the fact that combinations of circles (you will need those!) you have previously shared content with are stored and can be selected again with one click instead of having to create that combination again. This is an apparently little-known feature so far. Many people wrote about the fact that the last combination of circles you shared content with is the default for sharing anything new. But circle combinations from the past are there, too, right at your finger tip.

Sure we’re friends, but I don’t want to read all your babbling!

This is the counterpart to the problem described above. There are people who you can’t reject as friends, but they are spamming your whole stream with information you don’t care about at all. Yay for information overload! I was told that there are ways to filter your stream in Facebook, but the fact that I can’t immediately see a way to do so and quickly browsing my account settings hasn’t given me any hint on how to day that means that there is something wrong. Again, let me be stupid!

Now, Circles helps you, but while the solution is simple, it is not very satisfying. You can simply put these persons into your “People I don’t wanna read” circle. The shortcoming of Circles in this case is, that you will no longer be able to read your global stream to profit from putting those people into that circle. You are forced to read the streams for all of your interesting circles separately. Not very nice! I am aware of the possibility to block people, but this is not always an option. There are people you don’t want to be spammed by, but you would still like to receive comments from them, for example.

Targeting multiple audiences

This is a problem I mostly know from Twitter. If you want to interact with multiple, completely different audiences, you quickly run into problems: By writing about topics that are only of interest to one of your audiences, you risk losing followers from your other audiences, who don’t want to read about all this boring stuff you write. The obvious solution, of course, is to use multiple accounts. But c’mon, we can do better than that, right? And after all, I am this one person with a diversity of interests and, hence, audiences. I don’t want to hide some of my interest behind specific accounts.

The Google+ solution is, of course, to use one circle for each of your target audiences. Since connections between people in Google+ are inherently unidirectional, similar to Twitter, this could really become Twitter done right.

Bottom line

For my personal way of interacting with social networks, Google+, and especially Circles, provides some handy solutions. Whether those problems I am facing in established networks are common or not, I cannot tell, but I have the impression that this time, Google have finally done it right and can change the landscape of social networking.

There are, however, a number of things I wish they had done better. Since this article is already long enough as it is, I decided to write about those in a separate posting.

1 Not that the Facebook UI is not very well thought out. I’m sure, with every new feature, some people have put a lot of thought into how to perform yet another act of Privacy Zuckering.

Mission Statement

I have been intending to start blogging again for a long time. Now I have finally managed to put this into practice. I am a maker of software, and my plan is to primarily blog about my experience as well as opinions on various aspects of the software development process. But from time to time, I will certainly put on the user hat and write about the intricacies of human computer interaction from that very different perspective.

Why do I do all that? I am humble enough to be convinced that the majority of the world will not care about what I write here, will not even read it. But I like to write, it helps me to get a clearer understanding by forcing me to organize my thoughts. Also, I have found other people’s blogs to be not only interesting, but also very useful in certain situations, and I do think that my contributions might be helpful to the one or the other person, too, or at least entertaining.

For those interested, I decided to stay away from hosted blogging systems and instead make use of Jekyll, a very nice, blog-aware static-site generator written in Ruby.