Daniel Westheide

on making software

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.


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.


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.