Warning: Table './devblogsdb/cache_page' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_page WHERE cid = 'http://www.softdevblogs.com/?q=aggregator/categories/7&page=1' in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc on line 135

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 729

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 730

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 731

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 732
Software Development Blogs: Programming, Software Testing, Agile, Project Management
Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/common.inc on line 153.

A 360 Degree View of the Entire Netflix Stack

This is a guest repost by Chris Ueland, creator of Scale Scale, with a creative high level view of the Netflix stack.

As we research and dig deeper into scaling, we keep running into Netflix. They are very public with their stories. This post is a round up that we put together with Bryan’s help. We collected info from all over the internet. If you’d like to reach out with more info, we’ll append this post. Otherwise, please enjoy!

–Chris / ScaleScale / MaxCDN

A look at what we think is interesting about how Netflix Scales
Categories: Architecture

Stuff The Internet Says On Scalability For November 6th, 2015

Hey, it's HighScalability time:

Cool geneology of Relational Database Management Systems.
  • 9,000: Artifacts Uncovered in California Desert; 400 Million: LinkedIn members; 100: CEOs have more retirement assets than 41% of American families; $160B: worth of AWS; 12,000: potential age of oldest oral history; fungi: world's largest miners 

  • Quotable Quotes:
    • @jaykreps: Someone tell @TheEconomist that people claiming you can build Facebook on top of a p2p blockchain are totally high.
    • Larry Page: I think my job is to create a scale that we haven't quite seen from other companies. How we invest all that capital, and so on.
    • Tiquor: I like how one of the oldest concepts in programming, the ifdef, has now become (if you read the press) a "revolutionary idea" created by Facebook and apparently the core of a company's business. I'm only being a little sarcastic.
    • @DrQz: +1 Data comes from the Devil, only models come from God. 
    • @DakarMoto: Great talk by @adrianco today quote of the day "i'm getting bored with #microservices, and I’m getting very interested in #teraservices.”
    • @adrianco: Early #teraservices enablers - Diablo Memory1 DIMMs, 2TB AWS X1 instances, in-memory databases and analytics...
    • @PatrickMcFadin: Average DRAM Contract Price Sank Nearly 10% in Oct Due to Ongoing Supply Glut. How long before 1T memory is min?
    • @leftside: "Netflix is a monitoring system that sometimes shows people movies." --@adrianco #RICON15
    • Linus: So I really see no reason for this kind of complete idiotic crap.
    • Jeremy Hsu: In theory, the new architecture could pack about 25 million physical qubits within an array that’s 150 micrometers by 150 µm. 
    • @alexkishinevsky: Just done AWS API Gateway HTTPS API, AWS Lambda function to process data straight into AWS Kinesis. So cool, so different than ever before.
    • @highway_62: @GreatDismal Food physics and candy scaling is a real thing. Expectations and ratios get blown. Mouth feel changes.
    • @randybias:  #5 you can’t get automation scaling without relative homogeneity (homologous) and that’s why the webscale people succeeded
    • Brian Biles: Behind it all: VMs won.  The only thing that kept this [Server Centric Storage is Killing Arrays] from happening a long time ago was OS proliferation on physical servers in the “Open Systems” years.  Simplifying storage for old OS’s required consolidative arrays with arbitrated-standard protocols.
    • @paulcbetts: This disk is writing at almost 1GB/sec and reading at ~2.2GB/sec. I remember in 2005 when I thought my HD reading at 60MB/sec was hot shit.
    • @merv: One of computing’s biggest challenges for architects and designers: scaling is not distributed uniformly in time or space.

  • To Zookeeper or to not Zookeeper? This is one of the questions debated on an energetic mechanical-sympathy thread. Some say Zookeeper is an unreliable and difficult to manage. Others say Zookeeper works great if carefully tended. If you need a gossip/discovery service there are alternatives: JGroups, Raft, Consul, Copycat.

  • Algorithms are as capable of tyranny as any other entity wielding power. Twins denied driver’s permit because DMV can’t tell them apart

  • Odd thought. What if Twitter took stock or options as payment for apps that want to use Twitter as a platform (not Fabric)? The current user caps would effectively be the free tier. If you want to go above that you can pay. Or you can exchange stock or options for service. This prevents the Yahoo problem of being King Makers, that is when Google becomes more valuable than you. It gives Twitter potential for growth. It aligns incentives because Twitter will be invested in the success of apps that use it. And it gives apps skin in the game. Although Twitter has to recognize the value of the stock they receive as revenue, they can offset that against previous losses.

  • One of the best stories ever told. Her Code Got Humans on the Moon—And Invented Software Itself: MARGARET HAMILTON WASN’T supposed to invent the modern concept of software and land men on the moon...But the Apollo space program came along. And Hamilton stayed in the lab to lead an epic feat of engineering that would help change the future of what was humanly—and digitally—possible. 

Don't miss all that the Internet has to say on Scalability, click below and become eventually consistent with all scalability knowledge (which means this post has many more items to read so please keep on reading)...

Categories: Architecture

Notes on testing in golang

Agile Testing - Grig Gheorghiu - Fri, 11/06/2015 - 00:00
I've been doing a lot of testing of APIs written in the Go programming language in the last few months. It's been FUN! Writing code in Golang is also very fun. Can't have good code quality without tests though, so I am going to focus on the testing part in this post.

Unit testing
Go is a "batteries included" type of language, just like Python, so naturally it comes with its own testing package, which provides support for automated execution of unit tests. Here's an excerpt from its documentation:
Package testing provides support for automated testing of Go packages. It is intended to be used in concert with the ‚Äúgo test‚ÄĚ command, which automates execution of any function of the form
func TestXxx(*testing.T)
where Xxx can be any alphanumeric string (but the first letter must not be in [a-z]) and serves to identify the test routine.The functionality offered by the testing package is fairly bare-bones though, so I've actually been using another package called testify which provides test suites and more friendly assertions.

Whether you're using testing or a 3rd party package such as testify, the Go way of writing unit tests is to include them in a file ending with _test.go in the same directory as your code under test. For example, if you have a file called customers.go which deals with customer management business logic, you would write unit tests for that code and put them in file called customers_test.go in the same directory as customers.go. Then, when you run the "go test" command in that same directory, your unit tests will be automatically run. In fact, "go test" will discover all tests in files named *_test.go and run them. You can find more details on Go unit testing in the Testing section of the "How to Write Go Code" article.

Integration testing
I'll give some examples of how I organize my integration tests. Let's take again the example of testing an API what deals with the management of customers. An integration test, by definition, will hit the API endpoint from the outside, via HTTP. This is in contrast with a unit test which will test the business logic of the API handler internally, and will live as I said above in the same package as the API code.

For my integration tests, I usually create a directory per set of endpoints that I want to test, something like core-api for example. In there I drop a file called main.go where I set some constants used throughout my tests:

package main

import (

const API_VERSION = "v2"
const API_HOST = "myapi.example.com"
const API_PORT = 8000
const API_PROTO = "http"
const API_INIT_KEY = "some_init_key"
const API_SECRET_KEY = "some_secret_key"
const TEST_PHONE_NUMBER = "+15555550000"
const DEBUG = true

func init() {
        fmt.Printf("API_PROTO:%s; API_HOST:%s; API_PORT:%d\n", API_PROTO, API_HOST, API_PORT)

func main() {

For integration tests related to the customer API, I create a file called customer_test.go with the following boilerplate:

package main

import (


// Define the suite, and absorb the built-in basic suite
// functionality from testify - including a T() method which
// returns the current testing context
type CustomerTestSuite struct {
        apiURL          string
        testPhoneNumber string

// Set up variables used in all tests
// this method is called before each test
func (suite *CustomerTestSuite) SetupTest() {
        suite.apiURL = fmt.Sprintf("%s://%s:%d/%s/customers", API_PROTO, API_HOST, API_PORT, API_VERSION)
        suite.testPhoneNumber = TEST_PHONE_NUMBER

// Tear down variables used in all tests
// this method is called after each test
func (suite *CustomerTestSuite) TearDownTest() {

// In order for 'go test' to run this suite, we need to create
// a normal test function and pass our suite to suite.Run
func TestCustomerTestSuite(t *testing.T) {
        suite.Run(t, new(CustomerTestSuite))

By using the testify package, I am able to define a test suite, a struct I call CustomerTestSuite which contains a testify suite.Suite as an anonymous field. Golang uses composition over inheritance, and the effect of embedding a suite.Suite in my test suite is that I can define methods such as SetupTest and TearDownTest on my CustomerTestSuite. I do the common set up for all test functions in SetupTest (which is called before each test function is executed), and the common tear down for all test functions in TearDownTest (which is called after each test function is executed).

In the example above, I set some variables in SetupTest which I will use in every test function I'll define. Here is an example of a test function:

func (suite *CustomerTestSuite) TestCreateCustomerNewEmailNewPhone() {
        url := suite.apiURL
        random_email_addr := fmt.Sprintf("test-user%d@example.com", common.RandomInt(1, 1000000))
        phone_num := suite.testPhoneNumber
        status_code, json_data := create_customer(url, phone_num, random_email_addr)

        customer_id := get_nested_item_property(json_data, "customer", "id")

        assert_success_response(suite.T(), status_code, json_data)
        assert.NotEmpty(suite.T(), customer_id, "customer id should not be empty")

The actual HTTP call to the backend API that I want to test happens inside the create_customer function, which I defined in a separate utils.go file:

func create_customer(url, phone_num, email_addr string) (int, map[string]interface{}) {
        fmt.Printf("Sending request to %s\n", url)

        payload := map[string]string{
                "phone_num":  phone_num,
                "email_addr": email_addr,
        ro := &grequests.RequestOptions{}
        ro.JSON = payload

        var resp *grequests.Response
        resp, _ = grequests.Post(url, ro)

        var json_data map[string]interface{}
        status_code := resp.StatusCode
        err := resp.JSON(&json_data)
        if err != nil {
                fmt.Println("Unable to coerce to JSON", err)
                return 0, nil

        return status_code, json_data

Notice that I use the grequests package, which is a Golang port of the Python Requests package. Using grequests allows me to encapsulate the HTTP request and response in a sane way, and to easily deal with JSON.

To go back to the TestCreateCustomerNewEmailNewPhone test function, once I get back the response from the API call to create a customer, I call another helper function called assert_success_response, which uses the assert package from testify in order to verify that the HTTP response code was 200 and that certain JSON parameters that we send back with every response (such as error_msg, error_code, req_id) are what we expect them to be:

func assert_success_response(testobj *testing.T, status_code int, json_data map[string]interface{}) {
        assert.Equal(testobj, 200, status_code, "HTTP status code should be 200")
        assert.Equal(testobj, 0.0, json_data["error_code"], "error_code should be 0")
        assert.Empty(testobj, json_data["error_msg"], "error_msg should be empty")
        assert.NotEmpty(testobj, json_data["req_id"], "req_id should not be empty")
        assert.Equal(testobj, true, json_data["success"], "success should be true")

To actually run the integration test, I run the usual 'go test' command inside the directory containing my test files.

This pattern has served me well in creating an ever-growing collection of integration tests against our API endpoints.

Test coverage
Part of Golang's "batteries included" series of tools is a test coverage tool. To use it, you first need to run 'go test' with various coverage options. Here is a shell script we use to produce our test coverage numbers:


# Run all of our go unit-like tests from each package

set -e
set -x

cp /dev/null $CTMP
cp /dev/null $CREAL
cp /dev/null $CMERGE

go test -v -coverprofile=$CTMP -covermode=count -parallel=9 ./auth
cat $CTMP > $CREAL

go test -v -coverprofile=$CTMP -covermode=count -parallel=9 ./customers
cat $CTMP |tail -n+2 >> $CREAL

# Finally run all the go integration tests

go test -v -coverprofile=$C -covermode=count -coverpkg=./auth,./customers ./all_test.go
cat $CTMP |tail -n+2 >> $CREAL

rm $CTMP

# Merge the coverage report from unit tests and integration tests

cd $GOPATH/src/core_api/
cat $CREAL | go run ../samples/mergecover/main.go >> $CMERGE

set +x

echo "You can run the following to view the full coverage report!::::"
echo "go tool cover -func=$CMERGE"
echo "You can run the following to generate the html coverage report!::::"
echo "go tool cover -html=$CMERGE -o coverage.html"

The first section of the bash script above runs 'go test' in covermode=count against every sub-package we have (auth, customers etc). It combines the coverprofile output files (CTMP) into a single file (CREAL).

The second section runs the integration tests by calling 'go test' in covermode=count, with coverpkg=[comma-separated list of our packages], against a file called all_test.go. This file starts an HTTP server exposing our APIs, then hits our APIs by calling 'go test' from within the integration test directory.

The coverage numbers from the unit tests and integration tests are then merged into the CMERGE file by running the mergecover tool.

At this point, you can generate an html file via go tool cover -html=$CMERGE -o coverage.html, then inspect coverage.html in a browser. Aim for more than 80% coverage for each package under test.

Robot Framework and the keyword-driven approach to test automation - Part 1 of 3

Xebia Blog - Wed, 11/04/2015 - 21:55

Hans Buwalda is generally credited with the introduction of the keyword-driven paradigm of functional test automation, initially calling it the 'action word' approach.

This approach tackled certain fundamental problems pertaining to the efficiency of the process of creating test code (mainly the lack of reuse) and the maintainability, readability and robustness of that code. Problems surrounding these aspects frequently led to failed automation efforts. The keyword-driven framework therefore was (and is) a quantum leap forward, providing a solution to these problems by facilitating the application of modularity, abstraction and other design patterns to the automation code.

Robot Framework (RF) can be regarded as the epitome of this type of automation framework. Our first post on the RF concentrated on the high-level design of the platform. In this second of our three-part series of introductory-level posts, we will take a closer look at what the keyword-driven approach to test automation is all about.

This second post will itself be divided into three parts. In part 1, we will look at the position of the keyword-driven approach within the history of test automation frameworks. In part 2 we will delve into the concept of a 'keyword'. Finally, in part 3, we will look at how the keyword-driven approach is implemented by the RF.

A short history of test automation frameworks

In order to get a first, overall impression of the nature and advantages of the keyword-driven approach to test automation, let's have a look at the different framework generations that make up the history of test automation platforms. In doing so, we'll come across some of the differences, similarities and interdependencies between these various types of frameworks.

Please note that this history is partially a recap of similar (and sometimes more elaborate) genealogies in existing books, articles and blog posts. Nevertheless, I want to present it here as part of my comprehensive RF introduction. Moreover, I intend to give my own spin to the categorization of frameworks, by arguing that hybrid, MBT (Model-based testing) and Agile frameworks have no place in this lineage and that Scriptless Frameworks are not really scriptless.

Having said that, let's take a closer look at the various types of automation frameworks. The methodological and technological evolution of automated functional testing platforms is often divided into the following stages.

Linear frameworks (such as record & playback frameworks)

The code that is written or generated is procedural in nature, lacking both control structures (for run-time decision making and the reuse of code sequences) and calling structures (for the  reuse of code modules). To wit, code consists of long sequences of statements that are executed one after the other.

Test cases are thus implemented as typically large, monolithic blocks of static code, mixing what Gojko Adzic calls the technical activity level, user interface workflow level and business rule level. That is, the procedural test case consists of a series of lowest-level statements that implements and 'represents' all three levels. Up until the advance of the keyword-driven approach, this mixing was a staple of test automation.

It will be clear that such code lacks reusability, maintainability, readability and several other critical code qualities. The linear framework therefore always injected major drawbacks and limitations into an automation solution.

Amongst many other examples (of such drawbacks and limitations), is that adding even the slightest variation on an existing test case was labour-intensive and leading to more code to maintain. Due to the lack of control structures, any alternative functional flow had to be implemented through an additional test case, since the test code had no way of deciding dynamically (i.e. run-time) which alternative set of test actions to execute. This was worsened by the fact that test cases could not be made generic due to the lack of data-driven capabilities. Consequently, each test case had to be implemented through a dedicated, separate script, even in those cases where the functional flow and (thus) the required test actions were completely identical and only the data input had to be varied.

The lack of control structures also meant less robustness, stability and reliability of the code, since custom error detection and recovery logic could not be implemented and, therefore, run-time error handling was completely lacking.

It was also hard to understand the purpose of test cases. Especially business stake holders were dependant on documentation provided with each test case and this documentation needed to be maintained as well.

With the advent of each subsequent framework generation, this situation would gradually be improved upon.

Structured/scripted frameworks

The automation code now featured control/flow structures (logic), such as for-loops and conditional  statements, making the code maybe even harder to read while not improving much upon maintainability and reusability.

Of course, this approach did provide flexibility and power to the automation engineer. It also prevented code duplication to some extent, on the one hand due to the reuse of blocks of statements through looping constructs and on the other hand because alternative functional flows could now be handled by the same test case through decisions/branching. Additionally, robustness and stability was greatly improved upon because through the control structures routines for error detection and handling could be implemented.

Data-driven frameworks

Data is now extracted from the code, tremendously improving upon automation efficiency by increased levels of both reusability and maintainability.

The code is made generic by having the data passed into the code by way of argument(s). The data itself persists either within the framework (e.g. in lists or tables) or outside the framework (e.g. in databases, spread sheets or text files).

The automation platform is thereby capable of having the same script iterate through sets of data items, allowing for a truly data-driven test design. Variations on test cases can now be defined by simply specifying the various sets of parameters that a certain script is to be executed with. E.g. a login routine that is repeatedly executed with different sets of credentials to test all relevant login scenario's.

Through this approach, the 1-1 relation between test case and test script could be abandoned for the first time. Multiple test cases, that require identical sequences of test actions but different input conditions, could be implemented through one test script. This increased the level of data coverage immensely, while simultaneously reducing the number of scripts to maintain.

Of course, the data-driven approach to test design comes with a trade-off between efficiency and readability. Nevertheless, it is now possible to very quickly and efficiently extend test coverage. For instance through applying boundary-value analysis and equivalence partitioning to the test designs.

Where the structured frameworks added efficiency to the testing of variations in functional flows, the data-driven framework added efficiency to the testing of variations in data-flows.

Keyword-driven frameworks (sometimes called modularity frameworks)

Reusable blocks of code statements are now extracted into one or more layers of lower-level test functions. These functions are called 'keywords'. Consequently, there are now at least two layers in the automation code: the higher-level test cases and the lower-level, reusable test functions (keywords).

Test cases now can call keywords, thereby reusing the involved keyword logic and abstracting from the technical complexities of the automation solution.

The keywords can live in code (e.g. Python, Java, .Net) or can be created through a (proprietary) scripting language. A combination of coding and scripting is also possible. In that case the scripted functions typically reuse (and are implemented through) the lower-level, coded functions.

By facilitating modularization and abstraction, the keyword-driven framework dramatically improves the reusability and maintainability of the test code as well as the readability of both test code and test cases.

More on the nature and advantages of the keyword-driven framework, in part 2 of this second post.

Scriptless frameworks

There is a substantial level of controversy surrounding this type of framework. That is, there is a lot of polarized discussion on the validity of the claims that tool vendors make with regard to the capabilities and benefits of their tools.

The principal claim seems to be that these frameworks automatically generate the reusable, structured code modules as featured in the keyword-driven approach. No scripting required.

I must admit to not having a lot of knowledge of (let alone hands-on experience with) these frameworks. But based on what I have seen and read (and heard from people who actually use them), it appears to me that the 'scriptless' amounts to nothing more than the automated generation of an (admittedly advanced) object/UI map through some sort of code scanning process. For example, the controls (i.e. GUI elements such as edit fields, buttons, etc.) of some part of an application's GUI may be inventoried (in terms of all kinds of properties) and then be made available for the application of some sort of operation (e.g. click or input) or assertion (e.g. isEnabled, hasValue). The available types of operations and assertions per GUI element are thus part of the object map. But all of this hardly constitutes a truly scriptless approach, since the logic that these actions must be embedded in (to model the workflow of the SUT), still needs to be scripted and/or coded.

Hybrid frameworks

Sometimes hybrid frameworks. are mentioned as the follow-up generation of the keyword-driven approach, but, since keyword-driven frameworks are always data-driven as well, this is a superfluous category. In general, any generation is 'subsuming' the essential features of its predecessors, adding new features. So, for example, keyword-driven means structured and data-driven as well.

Note though that certain modern, keyword-driven frameworks are not inherently structured, since they do not feature a (proprietary) scripting language in which to create (mid-level) structured functions, but only support coding such functions at the lowest level in e.g. Java.

For instance, the 'scenario' tables of FitNesse, although often used as a middle layer between test cases (specifications) and the fixtures implemented in code, cannot hold structured functions, since FitNesse does not provide control structures of any form. Therefore, the scenario table contains linear 'code'. For a long time, these tables weren't even able to provide return values.

As a side note: of all the keyword-driven frameworks, RF features the most mature, complete and powerful scripting engine. We will go into details of the RF scripting facilities in a later post. Of course, to what extent such scripting should be applied to test code development is subject to discussion. This discussion centers mainly around the impact of scripting on the risks that apply to the involved automation efforts. Again, a later RF post will focus on that discussion.

Model-based testing frameworks

Similarly, Model-based testing (MBT) frameworks are sometimes mentioned as preceding the scriptless framework generation. But the specific capabilities of this type of tool pertain to the automated generation of highly formalized (logical) test designs with a specific form of coverage. Therefore, in my opinion, model-based frameworks do not belong in this genealogy at all.

With MBT frameworks test cases are derived from a model, such as e.g. a finite state machine, that represents the (behavior of the) SUT. The model, that serves as input to the framework, is sometimes created dynamically as well. However, the model-based approach to test design is, in itself, agnostic towards the question of how to execute the generated set of cases. It might be automated or it might be manual. Accordingly, there are three 'deployment models' for the execution of a model-based test design.

Only seldom, in the case of the so-called 'online testing' deployment scheme, the generated tests can be executed automatically. The logical test cases are first dynamically made concrete (physical) and are then executed. In that case, the execution is typically performed by an execution engine that is part of the same framework (as is the case with e.g. Tricentis Tosca). However, depending on the product technology and interfaces, customizations (extensions) to the execution engine could be required.

At times the created test cases are candidates for automated execution. This is the case with the so-called 'offline generation of executable tests', deployment scheme which generates the test cases as machine-readable code modules, e.g. a set of JAVA or Python classes. These can then be integrated into the test automation code created on platforms such as Cucumber or RF and subsequently be executed by them.

Most often though the generated test designs adhere to the so-called 'offline generation of manually deployable tests' deployment scheme. In that case, the framework output is a set of human-readable test cases that are to be executed manually.

The fact that occasionally model-based test designs can be executed directly by an MBT framework component (namely in one of the three deployment schemes), is the reason that these frameworks are sometimes (and erroneously) listed in the genealogy of test automation frameworks.

Agile/ATDD/BDD frameworks

Finally, sometimes Agile, ATDD (Acceptance Test Driven Development) or BDD (Behavior Driven Development) frameworks are mentioned as well. However, this is not so much a category onto itself, but rather, at the utmost, an added feature to (or on top of) modern, keyword-driven frameworks. Frameworks such as the Robot Framework or FitNesse allow for high-level, business-readable, BDD-style test designs or specifications. For instance, a test design applying the Gherkin syntax of Given-When-Then.

These BDD-specific features thus add to the frameworks the capability of facilitating specification and collaboration. That is, they enable collaborative specification or specification by example. Some frameworks, such as Cucumber or JBehave actually define, understand and promote themselves in terms of this specific usage. In other words, although they can be used in a 'purely' keyword- and data-driven manner as well, they stress the fact that the main use case for these frameworks is 'specification by example'. They position themselves as advocates of the BDD philosophy and, as such, want to stimulate and evangelize BDD. From the JBehave web site: "JBehave is a framework for Behaviour-Driven Development (BDD). BDD is an evolution of test-driven development (TDD) and acceptance-test driven design. It shifts the vocabulary from being test-based to behaviour-based, and positions itself as a design philosophy." [italics MH]

It is precisely through their ability to create modularized and data-driven test automation code, that the keyword-driven frameworks facilitate and enable a layered and generic test design and thus the ATDD/BDD practices of creating executable specifications and of specifying by example. These specifications or examples need to be business-readable and, consequently, require all of the implementation details and complexities to be hidden in lower layers of the automation solution. They must also be able to allow for variations on test cases (i.e. examples), for instance in terms of boundary cases or invalid data. The keyword-driven mechanisms, mainly those of code extraction and data extraction, thus form the technical preconditions to the methodological and conceptual shift from the 'test-based vocabulary' to the 'behavior-based vocabulary'. ATDD/BDD practices, methods and techniques such as collaborative design, Gherkin, living documentation, etc. can be applied through putting those keyword-driven features that form the key advantages of this type of framework to their best use. So, to create, for instance, high-level scenario's in Gherkin is nothing more than a (somewhat) new form of usage of a keyword-driven framework and a (slightly) different spin on the keyword-driven approach. Although originally not devised and designed with these usages in mind, the keyword-driven frameworks proved to be just the perfect match for such practices.

In conclusion, although Agile, ATDD and BDD as methodological paradigms or conceptual frameworks are new, the phrase 'Agile/ATDD/BDD test automation frameworks' merely refers to a variation on the application of the keyword-driven approach and on the usage of the involved frameworks. This usage can, however, be regarded as applying the keyword-driven approach to the fullest extent and as bringing it to its logical conclusion.

At the end of the day, applying ATDD/BDD-style test designs comes down to layering these designs along the lines of the (already mentioned) distinction made by Gojko Adzic. This layering is made possible by the keyword-driven nature of the utilized frameworks and, consequently, always implies a leyword-driven approach.


We now have a better understanding of the position that the keyword-driven approach holds in relation to other types of test automation frameworks and of some of its unique advantages.

As a side-effect, we have also gained some knowledge concerning the evolution of test automation frameworks as well as concerning the problem space that they were developed in.

And finally, we have seen that certain framework 'types' do not belong into the pantheon of functional test automation frameworks.

Building upon this context, we will now give a brief, condensed analysis of the notion of a 'keyword' in part 2 of this three-part post.

Strategy: Avoid Lots of Little Files

I've been bitten by this one. It happens when you quite naturally use the file system as a quick and dirty database. A directory is a lot like a table and a file name looks a lot like a key. You can store many-to-one relationships via subdirectories. And the path to a file makes a handy quick lookup key. 

The problem is a file system isn't a database. That realization doesn't hit until you reach a threshold where there are actually lots of files. Everything works perfectly until then.

When the threshold is hit iterating a directory becomes very slow because most file system directory data structures are not optimized for the lots of small files case. And even opening a file becomes slow.

According to Steve Gibson on Security Now (@16:10) LastPass ran into this problem. LastPass stored every item in their vault in an individual file. This allowed standard file syncing technology to be used to update only the changed files. Updating a password changes just one file so only that file is synced.

Steve thinks this is a design mistake, but this approach makes perfect sense. It's simple and robust, which is good design given, what I assume, is the original reasonable expectation of relatively small vaults.

The problem is the file approach doesn't scale to larger vaults with thousands of files for thousands of web sites. Interestingly, decrypting files was not the bottleneck, the overhead of opening files became the problem. The slowdown was on the elaborate security checks the OS makes to validate if a process has the rights to open a file.

The new version of 1Password uses a UUID to shard items into one of 16 files based on the first digit of the UUID. Given good random number generation the files should grow more or less equally as items are added. Problem solved. Would this be your first solution when first building a product? Probably not.

Apologies to 1Password if this is not a correct characterization of their situation, but even if wrong, the lesson still remains.

Categories: Architecture

Agile, but still really not Agile? What Pipeline Automation can do for you. Part 3.

Xebia Blog - Tue, 11/03/2015 - 13:07

Organizations adopting Agile and teams delivering on a feature-by-feature basis producing business value at the end of every sprint. Quite possibly this is also the case in your organization. But do these features actually reach your customer at the same pace and generate business value straight away? And while we are at it: are you able to actually use feedback from your customer and apply it for use in the very next sprint?

Possibly your answer is ‚ÄúNo‚ÄĚ, which I see very often. Many companies have adopted the Agile way of working in their lines of business, but for some reason ‚Äėold problems‚Äô just do not seem to go away...

Hence the question:

‚ÄúDo you fully capitalize on the benefits provided by working in an Agile manner?‚ÄĚ

Straight forward Software Delivery Pipeline Automation might help you with that.

In this post I hope to inspire you to think about how Software Development Pipeline automation can help your company to move forward and take the next steps towards becoming a truly Agile company. Not just a company adopting Agile principles, but a company that is really positioned to respond to the ever changing environment that is our marketplace today. To explain this, I take the Agile Manifesto as a starting point and work from there.

In my previous posts (post 1, post 2), I addressed Agile Principles 1 to 4 and 5 to 8. Please read below where I'll explain about how automation can help you for Agile Principles 9 to 12.


Agile Principle 9: Continuous attention to technical excellence and good design enhances agility.

In Agile teams, technical excellence is achieved by complete openness of design, transparency on design-implications, reacting to new realities1-Quality and using feedback loops to continuously enhance the product. However, many Agile teams still seem to operate in the blind when it comes to feedback on build, deployment, runtime and customer experience.

Automation enhances the opportunity to implement feedback loops into the Software Delivery Process as feedback. Whatever is automated can be monitored and immediately provides insight into the actual state of your pipeline. Think of things like trend information, test results, statistics, and current health status at a press of a button.

Accumulating actual measurement data is an important step, pulling this data to an abstract level for the complete team to understand in the blink of an eye is another. Take that extra mile and use dashboarding techniques to make data visible. Not only is it fun to do, it is very helpful in making project status come alive.


Agile Principle 10: Simplicity--the art of maximizing the amount of work not done--is essential.

Many¬†of us may know the quote: ‚ÄúEverything should be made as simple as possible, but no simpler‚ÄĚ. For ‚ÄúSimplicity-the art of maximizing the amount of work not done‚ÄĚ, wastes like ‚Äėover-processing‚Äô and ‚Äėover-production‚Äô are minimized by showing the product to the Product Owner as soon as possible and at frequent intervals, preventing gold plating and build-up of features in the pipeline.Genius-2

Of course, the Product Owner is important, but the most important stakeholder is the customer. To get feedback from the customer, you need to get new features not only to your Demo environment, but all the way to production. Automating the Build, Deploy, Test and provisioning processes are topics that help organizations achieving that goal.

Full automation of your software delivery pipeline provides a great mechanism for minimizing waste and maximizing throughput all the way into production. It will help you to determine when you start gold plating and position you to start doing things that really matter to your customer.

Did you know that according to a Standish report, more than 50% of functionality in software is rarely or never used. These aren’t just marginally valued features; many are no-value features. Imagine what can be achieved when we actually know what is used and what is not.


Agile Principle 11: The best architectures, requirements, and designs emerge from self-organizing teams.

Traditionally engineering projects were populated with specialists. Populating a team with specialists was based on the concept to divide labor, thereby pushing specialists towards focus on their field of expertise. The interaction designer designs the UI, the architect creates the required architectural model, the database administrator sets up the database, the integrator works on integration logic and so forth. Everyone was working on an assigned activity but as soon as components were put together, nothing seemed to work.

In Agile teams it is not about a person performing a specific task, it is about the team delivering fully functional slices of the product. When a slice fails, the team fails. Working together when designing components will help finding a optimal overall solution instead of many optimized sub-solutions that need to be glued together at a later stage. For this to work you need an environment the emits immediate feedback on the complete solution and this is where build, test and deployment automation come into play. Whenever a developer checks in code, the code is to be added to the complete codebase (not just the developer's laptop) and is to be tested, deployed and verified in the actual runtime environment as well. Working with fully slices provides a team the opportunity to experiment as a whole and start doing the right things.


Agile Principle 12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

To improve is to change, to be perfect is to change often. Self-learning teams and adjustments to new realities are key for Agile teams. However, in many organizations teams remain shielded from important transmitters of feedback like customer (usage), runtime (operational), test resucontinuous_improvement_modellts (quality) and so on.

The concept of Continuous Delivery is largely based upon receiving reliable feedback and using the feedback to improve. It is all about enabling the team to do the right things and do things right. An important aspect here is that information should not become biased. In order to steer correctly, actual measurement data need to be accumulated and represented at an understandable way to the team. Automation of the Software Delivery process allows the organization to gather real data, perform real measurements on real events and act accordingly. This is how one can start act on reality instead of hypothesis.


Maybe this article starts to sound a bit like Steve Balmers Mantra for Developers (oh my goshhhh) but than for "Automation", but just give it five minutes... You work Agile, but are your customers really seeing the difference? Do they now have a better product, delivered faster? If the answer is no, what could help you with this? Instantly?


Michiel Sens.

Bringing Agile to the Next Level

Xebia Blog - Mon, 11/02/2015 - 22:22

The Best is Yet to Come written on desert roadI finished my last post with the statement Agile will be applied on a much wider scale in the near future. Within governmental organizations, industry, startups, on a personal level, you name it.  But how?  In my next posts I will deep dive in this exciting story lying in front of us in five steps:

Blogpost/Step I: Creating Awareness & Distributing Agile Knowledge
Change is a chance, not a threat.  Understanding and applying the Agile Mindset and toolsets will help everyone riding the wave of change with more pleasure and success.  This is the main reason why I’ve joined initiatives like Nederland Kantelt, EduScrum, Wikispeed and Delft University’s D.R.E.A.M. Hall.

Blogpost/Step II: Fit Agile for Purpose
The Agile Manifesto was originally written for software.  Lots of variants of the manifesto emerged the last couple of years serving different sectors and products. This is a good thing if the core values of the agile manifesto are respected.

However, agile is not applicable for everything.  For example, Boeing will never apply Scrum directly for producing critical systems.  They’re applying Scrum for less critical parts and R&D processes. For determining the right approach they use the Cynefin framework.  In this post I will explain this framework making it a lot easier where you could apply Agile and where you should be careful.

Blogpost/Step III: Creating a Credible Purpose or ‚ÄúWhy‚ÄĚ
You can implement a new framework or organization, hire the brightest minds and have loads of capital, in the end it all boils down to real passion and believe. Every purpose should be spot on in hitting the center of the Golden Circle.  But how to create this fontainebleau in spring?

Blogpost/Step IV: Breaking the Status Quo and Igniting Entrepreneurship
Many corporate organizations are busy or have implemented existing frameworks like SAFe or successful Agile models from companies like Netflix and Spotify.  But the culture change which goes with it, is the most important step. How to spark a startup mentality in your organization?  How to create real autonomy?

Compass with needle pointing the word organic. Green and grey tones over beige background, Conceptual illustration for healthy eating and organic farming.Blogpost/Step V: Creating Organic Organizations
Many Agile implementations do not transform organizations in being intrinsically Agile.  To enable this, organizations should evolve organically, like Holacracy.   They will become stronger and stronger by setbacks and uncertain circumstances.  Organic organizations will be more resilient and anti-fragile.  In fact, it’s exactly how nature works.  But how can you work towards this ideal situation?

Paper: Coordination Avoidance in Distributed Databases By Peter Bailis

Peter Bailis has released the work of a lifetime, his dissertion is now available online: Coordination Avoidance in Distributed Databases.

The topic Peter is addressing is summed up nicely by his thesis statement: 

Many semantic requirements of database-backed applications can be efficiently enforced without coordination, thus improving scalability, latency, and availability.

I'd like to say I've read the entire dissertation and can offer cogent insightful analysis, but that would be a lie. Though I have watched several of Peter's videos (see Related Articles). He's doing important and interesting work, that as much University research has done, may change the future of what everyone is doing.

From the introduction:

The rise of Internet-scale geo-replicated services has led to upheaval in the design of modern data management systems. Given the availability, latency, and throughput penalties associated with classic mechanisms such as serializable transactions, a broad class of systems (e.g., “NoSQL”) has sought weaker alternatives that reduce the use of expensive coordination during system operation, often at the cost of application integrity. When can we safely forego the cost of this expensive coordination, and when must we pay the price?

In this thesis, we investigate the potential for coordination avoidance—the use of as little coordination as possible while ensuring application integrity—in several modern dataintensive domains. We demonstrate how to leverage the semantic requirements of applications in data serving, transaction processing, and web services to enable more efficient distributed algorithms and system designs. The resulting prototype systems demonstrate regular order-of-magnitude speedups compared to their traditional, coordinated counterparts on a variety of tasks, including referential integrity and index maintenance, transaction execution under common isolation models, and database constraint enforcement. A range of open source applications and systems exhibit similar results.

Related Articles 
Categories: Architecture

How Shopify Scales to Handle Flash Sales from Kanye West and the Superbowl

This is a guest repost by Christophe Limpalair, creator of Scale Your Code.

In this article, we take a look at methods used by Shopify to make their platform resilient. Not only is this interesting to read about, but it can also be practical and help you with your own applications.

Shopify's Scaling Challenges

Shopify, an ecommerce solution, handles about 300 million unique visitors a month, but as you'll see, these 300M people don't show up in an evenly distributed fashion.

One of their biggest challenge is what they call "flash sales". These flash sales are when tremendously popular stores sell something at a specific time.

For example, Kanye West might sell new shoes. Combined with Kim Kardashian, they have a following of 50 million people on Twitter alone.

They also have customers who advertise on the Superbowl. Because of this, they have no idea how much traffic to expect. It could be 200,000 people showing up at 3:00 for a special sale that ends within a few hours.

How does Shopify scale to these sudden increases in traffic? Even if they can't scale that well for a particular sale, how can they make sure it doesn't affect other stores? This is what we will discuss in the next sections, after briefly explaining Shopify's architecture for context.

Shopify's Architecture
Categories: Architecture

3 Fights Each Day

‚ÄúSometimes the prize is not worth the costs. The means by which we achieve victory are as important as the victory itself.‚ÄĚ
‚Äē Brandon Sanderson

Every day presents us with new challenges.  Whether it‚Äôs a personal struggle, or a challenge at work, or something that requires you to stand and deliver.

To find your strength.

To summon your courage, or find your motivation, or to dig deep and give it your all.

Adapt, Adjust, Or Avoid Situations

Sometimes you wonder whether the struggle is worth it.  Then other times you breakthrough.  And, other times you wonder why it was even a struggle at all.

The struggle is your growth.  And every struggle is a chance for personal growth and self-actualization.  It‚Äôs also a chance to really build your self-awareness.

For example, how well can you read a situation and anticipate how well you will do?   In every situation, you can either Adapt, Adjust, or Avoid the situation.  Adapt means you change yourself for the situation.  Adjust means you change the situation to better suite you.  And Avoid means, stay away from it.  You will be like a fish out of water.  If you don‚Äôt like roller coasters, then don‚Äôt get on them.

So every situation is a great opportunity to gain insight into yourself as well as to learn how to read situation, and people, much better.  And the faster you adapt, the more fit you will be to survive, and ultimately thrive.

Nature favors the flexible.

The 3 Fights We Fight Each Day

But aside from Adapting, Adjusting, and Avoiding situations, it also helps to have a simple mental model to frame your challenges each day.  A former Navy Seal frames it for us really well.  He says we fight 3 fights each day:

  1. Inside you
  2. The enemy
  3. The ‚Äúsystem‚ÄĚ

Maybe you can relate?  Each day you wake up, your first fight is with yourself.  Can you summon your best energy?  Can you get in your most resourceful state?  Can you find your motivation?   Can you drop a bad habit, or add a good one?   Can you get into your best frame of mind to tackle the challenges before you?

Winning this fight sets the stage for the rest.

The second fight is what most people would consider the actual fight.  It‚Äôs the challenge you are up against.   Maybe it‚Äôs winning a deal.  Maybe it‚Äôs doing your workout.  Maybe it‚Äôs completing an assignment or task at work.  Either way, this is where if you lost your first fight, this is going to be even tougher now.

The third fight is with the ‚Äúsystem.‚ÄĚ  Everybody operates within a system.  It might be your politics, policies, or procedures.  You might be in a school or a corporation or an institution, or on a team, or within an organization.  Either way, there are rules and expectations.  There are ways for things to be done.  Sometimes they work with you.  Sometimes they work against you.   And herein lies the fight.

In my latest post, I share some simple ways from our Navy Seal friends how you can survive and thrive against these 3 fights:

3 Fights We Fight Each Day

You can read it quickly.  But use the tools inside to actually practice and prepare so you can respond better to your most challenging situations.  If you practice the breathing techniques and the techniques for visualization, you will be using the same tools that the world‚Äôs best athletes, the Navy Seals, the best execs, and the highest achievers use ‚Ķ to do more, be more, and achieve more ‚Ķ in work and life.

Categories: Architecture, Programming

Dancing with GetKanban (Using POLCA)

Xebia Blog - Mon, 11/02/2015 - 12:59

Very recently POLCA got some attention on twitter. The potential and application of POLCA to knowledge work I explained in my blog 'Squeeze more out of kanban with POLCA!' [Rij11] of 4 years ago.

In this blog the GetKanban [GetKanban] game is played by following the the initial 'standard' rules for handling Work in Progress (WiP) limits and by changing the rules of the game inspired by POLCA (See [POLCA]).

The results show an equal throughput between POLCA and non-overlapping WiP limits, with smaller inventory size in the case of POLCA way of approaching WiP limits.

First a short introduction to the GetKanban game is given and a description of the set-up together with the basic results.

Second a brief introduction to POLCA is given and the change of rules in the game is explained. Thirdly, the set-up of the game using POLCA and the results are discussed.

Finally, a few words are spent on the team's utilization.

Simulation: GetKanban Game

The step-up with standard WiP limits is shown below. The focus is on a basic simulation of the complete 24 project days of only the regular work items. The expedite, fixed delivery date, and intangibles are left out. In addition, the events described on the event cards are ignored. Reason being to get a 'clean' simulation showing the effect of applying the WiP limits in a different manner.


Other policies taken from the game: a billing cycle of 3 days, replenishment of the 'Ready' column is allowed only at the end of project days 9, 12, 15, 18, and 21.

The result of running the game at the end of day 24 iskanban

The picture shows the state of the board, lead time distribution diagram, control chart, and cumulative flow diagram.

From these it can be inferred that (a) 10 items are in progress, (b) throughput is 25 items in 24 days, (c) median of 9 days for the lead time of items from Ready to Deployed.


Interesting is that the control chart (middle chart) shows the average lead time dropping to 5-6 days in the last three days of the simulation. Since the game starts at day 9, this shows that it takes 12 days before the system settles in a new stable state with 5-6 as an average lead time compared to the 9 days at the beginning.

POLCA: New Rules

In POLCA (see [POLCA]) the essence is to make the WiP limit overlap. The 'O' of POLCA stands for 'Overlapping':

POLCA - Paired Overlapping Loops of Cards with Authorization

One of the characteristics differentiating POLCA from e.g. kanban based systems is that it is a combination of push & pull: 'Push when you know you can pull'.

Setting WiP limits to support pushing work when you know it can subsequently be pulled. The set-up in the game for POLCA is as follows:


For clarity the loops are indicated in the 'expedite' row.

How do the limits work? Two additional rules are introduced:

Rule 1)
In the columns associated with each loop a limit on the number of work items is set. E.g. the columns 'Development - Done' and 'Test' can only accommodate for a maximum of 3 cards. Likewise, the columns underneath the blue and red loops have a limit of 4 and 4 respectively.

Rule 2)
Work can only be pulled if a) the loop has capacity, i.e. has fewer cards than the limit, b) the next, or overlapping loop, has capacity.

These are illustrated with a number of examples that typically occur during the game:

Example 1: Four items in the 'Development - Done' column
No items are allowed to be pulled in 'Ready' because there is no capacity available in the blue loop (Rule 2)

Example2: Two items in 'Test' & two items in 'Analysis - Done'
One item can be pulled in 'Development - In Progress' (Rule 1 and Rule2).

Results for POLCA

The main results for running the game for 24 days with the above rules is shown in the charts below.

The Control Chart shows that it takes roughly 6 days for all existing items to flow out of the system. The effect of the new rules (POLCA style WiP limits) are seen starting from day 15.

Lead Time
On average the charts show a lead time of 3 days, starting from day 18. This is also clearly visible on the lead time distribution chart and on the narrow cumulative flow diagram.

The number of items produced by the project is 24 items in 24 days. This is equal enough to the through put as measured using the standard set of rules.

Work In Progress
The total number of items in progress in only 3 to 4 items. This is less than half of the items as seen in the simulation run using the standard set of rules.

polca-new-3 polca-new-1 polca-new-2

Note: The cumulative flow diagram clearly shows the 3-day billing day and replenishment (step-wise increments of black and purple lines).


As described in my blog 'One change at a time' [Rij15] getting feedback from improvements/changes that effect the flow of the system take some time before the system settles in the new stable state.

With POLCA it is expected that this learning cycle can be shortened. In running the game the control charts show that it takes approximately 12 days before the system reaches the stable state, whereas with the POLCA set of rules this is reached in half the time.

Results for POLCA - Continuous Replenishment

As described above, until now we have adhered to the billing cycle of 3 days, which also allows for replenishment every 3 days.

What happens if replenishment is allowed when possible. The results are shown int he charts below.

polca2-1 polca2-2 polca2-3

The cumulative flow diagram shows the same throughput, namely 24 items over a period of 24 days. Work in progress is larger because it is pulled in earlier instead of at the end of every third day.

What is interesting is that the Control Chart shows a large variation in lead time: from 3 to 6 days. What I noted during playing the game is that at regular times 3 to 4 items are allowed to be pulled into 'Ready'. These would sit for some time in 'Ready' and then suddenly completed all the way to 'Ready for Deployment'. Then another bunch of 3 to 4 items are pulled into 'Ready'.
This behavior is corroborated by the Control Chart (staircase pattern). The larger variation is shown in the Lead Time Distribution Chart.

What is the reason for this? My guess is that the limit of 4 on the red loop is too large. When replenishment was only allowed at days 9, 12, 15, ... this basically meant a lower limit for the red loop.
Tuning the limits is important for establishing a certain cadence. Luckily this behavior can be seen in the Control Chart.


In the GetKanban game specialists in the team are represented by colored dices: green for testers, blue for developers, and red for analysts. Effort spent is simulated by throwing the dices. Besides spending the available effort in their own speciality, it can also be spent in other specialities in which case the effort to spend is reduced.

During the game it may happen that utilization is less than 100%:

  1. Not spending effort in the speciality, e.g. assigning developers to do test work.
  2. No work item to spend the effort on because of WiP limits (not allowed to pull work).

The picture below depicts the utilization as happened during the game: on average a utilization of 80%.



In this blog I have shown how POLCA style of setting WiP limits work, how overlapping loops of limits help in pulling work fast through the system, and the positive effect on the team's learning cycle.

In summary, POLCA allows for

  • Shorter lead times
  • Lower work in progress, enabling a faster learning cycle

Tuning of the loop limits seems to be important for establishing a regular cadence. A 'staircase' pattern in the Control Chart is a strong indication that loop limits are not optimal.


[GetKanban] GetKanban Game: http://getkanban.com

[Rij11] Blog: Squeeze more out of kanban with POLCA!

[Rij15] Blog: One change at a time

[POLCA] POLCA: http://www.business-improvement.eu/qrm/polca_eng.php


The power of map and flatMap of Swift optionals

Xebia Blog - Sun, 11/01/2015 - 01:22

Until recently, I always felt like I was missing something in Swift. Something that makes working with optionals a lot easier. And just a short while ago I found out that the thing I was missing does already exist. I'm talking about the map and flatMap functions of Swift optionals (not the Array map function). Perhaps it's because they're not mentioned in the optionals sections of the Swift guide and because I haven't seen it in any other samples or tutorials. And after asking around I found out some of my fellow Swift programmers also didn't know about it. Since I find it an amazing Swift feature that makes your Swift code often a lot more elegant I'd like to share my experiences with it.

If you didn't know about the map and flatMap functions either you should keep on reading. If you did already know about it, I hope to show some good, real and useful samples of it's usage that perhaps you didn't think about yet.

What do map and flatMap do?

Let me first give you a brief example of what the functions do. If you're already familiar with this, feel free to skip ahead to the examples.

The map function transforms an optional into another type in case it's not nil, and otherwise it just returns nil. It does this by taking a closure as parameter. Here is a very basic example that you can try in a Swift Playground:

var value: Int? = 2
var newValue = value.map { $0 * 2 }
// newValue is now 4

value = nil
newValue = value.map { $0 * 2 }
// newValue is now nil

At first, this might look odd because we're calling a function on an optional. And don't we always have to unwrap it first? In this case not. That's because the map function is a function of the Optional type and not of the type that is wrapped by the Optional.

The flatMap is pretty much the same as map, except that the return value of the closure in map is not allowed to return nil, while the closure of flatMap can return nil. Let's see another basic example:

var value: Double? = 10
var newValue: Double? = value.flatMap { v in
    if v < 5.0 {
        return nil
    return v / 5.0
// newValue is now 2

newValue = newValue.flatMap { v in
    if v < 5.0 {
        return nil
    return v / 5.0
// now it's nil

If we would try to use map instead of flatMap in this case, it would not compile.

When to use it?

In many cases where you use a ternary operator to check if an optional is not nil, and then return some value if it's not nil and otherwise return nil, it's probably better to use one of the map functions. If you recognise the following pattern, you might want to go through your code and make some changes:

var value: Int? = 10
var newValue = value != nil ? value! + 10 : nil 
// or the other way around:
var otherValue = value == nil ? nil : value! + 10

The force unwrapping should already indicate that something is not quite right. So instead use the map function shown previously.

To avoid the force unwrapping, you might have used a simple if let or guard statement instead:

func addTen(value: Int?) -> Int? {
  if let value = value {
    return value + 10
  return nil

func addTwenty(value: Int?) -> Int? {
  guard let value = value else {
    return nil
  return value + 20

This still does exactly the same as the ternary operator and thus is better written with a map function.

Useful real examples of using the map functions

Now let's see some real examples of when you can use the map functions in a smart way that you might not immediately think of. You get the most out of it when you can immediately pass in an existing function that takes the type wrapped by the optional as it's only parameter. In all of the examples below I will first show it without a map function and then again rewritten with a map function.

Date formatting

Without map:

var date: NSDate? = ...
var formatted: String? = date == nil ? nil : NSDateFormatter().stringFromDate(date!)

With map:

var date: NSDate? = ...
var formatted: date.map(NSDateFormatter().stringFromDate)
Segue from cell in UITableView

Without map:

func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {
  if let cell = sender as? UITableViewCell, let indexPath = tableView.indexPathForCell(cell) {
    (segue.destinationViewController as! MyViewController).item = items[indexPath.row]

With map:

func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {
  if let indexPath = (sender as? UITableViewCell).flatMap(tableView.indexPathForCell) {
    (segue.destinationViewController as! MyViewController).item = items[indexPath.row]
Values in String literals

Without map:

func ageToString(age: Int?) -> String {
    return age == nil ? "Unknown age" : "She is (age!) years old"

With map:

func ageToString(age: Int?) -> String {
    return age.map { "She is ($0) years old" } ?? "Unknown age"

(Please note that in the above examples there need to be backslashes before (age!) and ($0) but unfortunately :-( that breaks the formatting of WordPress in this post)

Localized Strings

Without map:

let label = UILabel()
func updateLabel(value: String?) {
  if let value = value {
    label.text = String.localizedStringWithFormat(
      NSLocalizedString("value %@", comment: ""), value)
  } else {
    label.text = nil

With map:

let label = UILabel()
func updateLabel(value: String?) {
  label.text = value.map { 
    String.localizedStringWithFormat(NSLocalizedString("value %@", comment: ""), $0) 
Enum with rawValue from optional with default

Without map:

enum State: String {
    case Default = ""
    case Cancelled = "CANCELLED"

    static func parseState(state: String?) -> State {
        guard let state = state else {
            return .Default
        return State(rawValue: state) ?? .Default

With map:

enum State: String {
    case Default = ""
    case Cancelled = "CANCELLED"

    static func parseState(state: String?) -> State {
        return state.flatMap(State.init) ?? .Default
Find item in Array

With Item like:

struct Item {
    let identifier: String
    let value: String

let items: [Item]

Without map:

func find(identifier: String) -> Item? {
    if let index = items.indexOf({$0.identifier == identifier}) {
        return items[index]
    return nil

With map:

func find(identifier: String) -> Item? {
    return items.indexOf({$0.identifier == identifier}).map({items[$0]})
Constructing objects with json like dictionaries

With a struct (or class) like:

struct Person {
    let firstName: String
    let lastName: String

    init?(json: [String: AnyObject]) {
        if let firstName = json["firstName"] as? String, let lastName = json["lastName"] as? String {
            self.firstName = firstName
            self.lastName = lastName
        return nil

Without map:

func createPerson(json: [String: AnyObject]) -> Person? {
    if let personJson = json["person"] as? [String: AnyObject] {
        return Person(json: personJson)
    return nil

With map:

func createPerson(json: [String: AnyObject]) -> Person? {
    return (json["person"] as? [String: AnyObject]).flatMap(Person.init)

The map and flatMap functions can be incredibly powerful and make your code more elegant. Hopefully with these examples you'll be able to spot when situations where it will really benefit your code when you use them.

Please let me know in the comments if you have similar smart examples of map and flatMap usages and I will add them to the list.

Android Resource Configuration override and Large Text Mode

Xebia Blog - Sat, 10/31/2015 - 13:15

In Android, the resource Configuration dictates what resources and assets are selected. The system populates a default configuration to match your device and settings (screen size, device orientation, language). Sometimes, you need to deviate from these defaults. Since API 17 you can use applyOverrideConfiguration(Configuration) to specify an alternative resource config. The normal place to do so is in the attachBaseContext(Context) method of your Activity.

public class MainActivity extends Activity {

protected void attachBaseContext(Context newBase) {
    final Configuration override = new Configuration();
    override.locale = new Locale("nl", "NL");



Here's what that looks like:

Screenshot Screenshot

Unfortunately, there's a catch.

Android has a "Large Text" setting in its accessibility options (and in some cases a different text size setting in the display options). If you use the overrideConfiguration method to set your own resource configurtation, you will wipe out the Large Text preference, hurting your accessibilty support. This problem is easily overlooked, and luckily, easily fixed.

Screenshot Screenshot

The large fonts setting works by changing the Configuration.fontScale attribute, which is a public float. This works with the scaled density-independent pixels (sp's) that you use to define fontSize attributes. All sp dimensions have this fontScale multiplier applied. My Nexus 5 has two font size settings, normal at 1.0 and large at 1.3. The Nexus 5 emulator image has four, and many Samsung devices have seven different font sizes you can choose from.

When you set the override configuration, the new Configuration object has its fontScale set to 1.0f, thereby breaking the large fonts mode. To fix this problem, you simply have to copy the current fontScale value from the base context. This is best done using the copy constructor, which will also account for any other properties that come with the same issue.

public class MainActivity extends Activity {

protected void attachBaseContext(Context newBase) {
    final Configuration override = new Configuration(
            // Copy the original configuration so it isn't lost.
    override.locale = new Locale("nl", "NL");

    // BTW: You can also access the fontScale value using Settings.System:
    // Settings.System.getFloat(getContentResolver(), Settings.System.FONT_SCALE, 1.0f);



The app now works as intended, with accessibility support intact.


Long story short: when you use applyOverrideConfiguration, always test your app in the Large Fonts accessibility setting. Be sure to copy the original Configuration in your new Configuration constructor, or use the System.Settings.FONT_SCALE property to retrieve the font scale separately.

Stuff The Internet Says On Scalability For October 30th, 2015

Hey, it's HighScalability time:

Movie goers Force Crashed websites with record ticket presales. Yoda commented: Do. Or do not. There is no try.
  • $51.5 billion: Apple quarterly revenue; 1,481: distance in light years of a potential Dyson Sphere; $470 billion: size of insurance industry data play; 31,257: computer related documents in a scanned library; $1.2B: dollars lost to business email scams; 46 billion: pixels in largest astronomical image; 27: seconds of distraction after doing anything interesting in a car; 10 billion: transistor SPARC M7 chip; 10K: cost to get a pound in to low earth orbit; $8.2 billion: Microsoft cloud revenue; 

  • Quotable Quotes:
    • @jasongorman: A $trillion industry has been built on the very lucky fact that Tim Berners-Lee never thought "how do I monetise this?"
    • Cade Metz: Sure, the app [WhatsApp] was simple. But it met a real need. And it could serve as a platform for building all sorts of other simple services in places where wireless bandwidth is limited but people are hungry for the sort of instant communication we take for granted here in the US.
    • Adrian Hanft: Brand experts insist that success comes from promoting your unique attributes, but in practice differentiation is less profitable than consolidation.
    • Jim Butcher: It’s a tradition. Were traditions rational, they’d be procedures.
    • Albert Einstein~ Sometimes I pretend I’m the Mayor of my kitchen and veto fish for dinner. ‘Too fishy’ is what I say!
    • @chumulu: “Any company big enough to have a research lab is too big to listen to it" -- Alan Kay
    • Robin Harris: So maybe AWS has all the growth it can handle right now and doesn’t want more visibility. AWS may be less scalable than we’d like to believe.
    • Michael Nielsen: Every finitely realizable physical system can be simulated efficiently and to an arbitrary degree of approximation by a universal model (quantum) computing machine operating by finite means.
    • Sundar Pichai~ there are now more Google mobile searches than desktop searches worldwide.
    • Joe Salvia~ The major advance in the science of construction over the last few decades has been the perfection of tracking and communication.
    • apy: In other words, as far as I can tell docker is replacing people learning how to use their package manager, not changing how software could or should have been deployed.
    • @joelgrus: "Data science is a god-like power." "Right, have you finished munging those CSVs yet?""No, they have time zone data in them!"
    • @swardley: "things are getting worse. Companies are increasingly financialised and spending less on basic research" @MazzucatoM 
    • Dan Rayburn: The cause of what Akamai is seeing is a result of Apple, Microsoft and Facebook moving a larger percentage of their traffic to their in-house delivery networks.
    • @littleidea: containers will not fix your broken architecture you are welcome
    • spawndog: I've typically found the best gameplay optimization comes from a greater amount of creative freedom like you mention. Lets not do it. Lets do it less frequently. Lets organize the data into something relative to usage pattern like spatial partitions.
    • @awealthofcs: The 1800s: I hope I survive my 3 month voyage to deliver a message to London Now: The streaming on this NFL game in London is a bit spotty
    • @ddwoods2: just having buffers ≠ resilience; resilience = the capacities for changing position/size/kind of buffers, before events eat those buffers
    • unoti: There's a dangerous, contagious illness that developers of every generation get that causes them to worry about architecture and getting "street cred" even more than they worry about solving business problems. I've fallen victim to this myself, because street cred is important to me. But it's a trap.
    • @kelseyhightower: Kubernetes is getting some awesome new features: Auto scaling pods, Jobs API (batch), and a new deployment API for serve side app rollouts.

  • Great story on Optimizing League of Legends. The process: Identification: profile the application and identify the worst performing parts; Comprehension: understand what the code is trying to achieve and why it is slow; Iteration: change the code based on step 2 and then re-profile. Repeat until fast enough. Result: memory savings of 750kb and a function that ran one to two milliseconds faster. 

  • Fantastic article on Medium's architecture: 25 million uniques a month;  service-oriented architecture, running about a dozen production services; GitHub; Amazon’s Virtual Private Cloud; Ansible; mostly Node with some Go; CloudFlare, Fastly, CloudFront with interesting traffic allocations; Nginx and HAProxy; Datadog, PagerDuty, Elasticsearch, Logstash, Kibana; DynamoDB, Redis, Aurora, Neo4J; Protocol Buffers used as contract between layers; and much more.

  • Are notifications the new Web X.0? Notification: the push and the pull: Right now we are witnessing another round of unbundling as the notification screen becomes the primary interface for mobile computing.

  • Algorithm hacking 101. Uber Surge Price? Research Says Walk A Few Blocks, Wait A Few Minutes.

Don't miss all that the Internet has to say on Scalability, click below and become eventually consistent with all scalability knowledge (which means this post has many more items to read so please keep on reading)...

Categories: Architecture

Angular reverse URL construction

Xebia Blog - Thu, 10/29/2015 - 09:02

Let's discuss a problem you probably aren't aware you are having in your web app:

Hardcoded URLs

These hardcoded, static URLs are simple at first, but the code is error prone and increases the app complexity. Instead what you should be doing is creating dynamic URLs by means of reverse URL construction. I have grown up using the Django web framework which extensively uses reverse routing and I love it. Let us look at how this simple system improves your coding and I'm sure you'll love it too.

We'll look at URL construction using an AngularJS example. Even if you don't use Angular, the general idea behind reverse URLs should become apparent.

The stage

Say we have simple web application with a contact page, a list of users and user pages:

 /contact -> contact.html
 /users -> users.html
 /user/foo -> user.html for user "foo"

We will reference these routes directly in our page using the `<a>` tag and occasionally we might even require an URL inside JavaScript. A link to the contact page is easily created using: `<a href="/contact">Contact us</a>. There are however a few drawbacks to this approach.

The first issue is that the URL is now defined in two places, the route configuration and the anchor tag. If you ever decide to change the URL to `contact-us`, all references should be updated as well. As the app grows so do all the duplicate references and you'll end up changing a lot of them. Chances are that you will miss one and cause a bad link.

More problems arise as soon as the URL contains a dynamic element. Lets say the page behind `/users` list all users in our application as follows:

<ul ng-repeat="user in users">
  <li><a ng-href="/user/{{user.name}}"></a></li>

Because the URL is constructed using simple interpolation we can't check whether the resulting URL is valid. Lets say the app router matches the URL on the pattern: `^/user/([a-z]+)$`. This would mean the user's name may only consist of letters, for example "foo". If the name contains an integer, say "foo2015", the URL won't be recognized by our router. So we allow bad URLs to be constructed.

So hardcoded URLs aren't great, what is?

Reverse URL resolution

The solution has many names: URL construction, reverse URL resolution and reverse routing. The essence of this method is that every route is identifiable by a unique element. Reversing the URL is done by referencing the route and supplying parameters. The route itself is stored in a single location, the router. This route is used both for routing a request and constructing a URL.

We will add reverse routing to the standard Angular "$routeProvider". A small project angular-reverse-url adds the reverse resolution capability. We can use a filter to build URLs by referencing either the route name or its controller name. In this example we will identify the route using the route name. But bear in mind that the controller approach would work just as well (given a route is uniquely defined by a controller).

Now let's see how reverse URL construction is done. We will use the example setup as follows:

    .when('/contact', {
      template: 'contact.html',
      name: 'contact'
    .when('/users', {
      template: '/users.html',
      name: 'user-list'
    .when('/user/:id/:name', {
      template: '/users.html',
      name: 'user-detail'
Constructing static URLs

Our web app needs needs a navigation bar. Inside our navigation we can link to the contact page using:

    <li><a ng-href="{{ 'contact' | reverseUrl }}">Contact us</a></li>

The reverseUrl filter simply uses the 'contact' name to construct the URL from the route defined in the $routeProvider.

Parameter based URL generation

Creating plain URLs without any parameters is hardly interesting. The benefits of reverse URL resolution become apparent when we start introducing route arguments. We can list the user pages in our application using:

<li ng-repeat="user in users">
  <a href="{{ 'user-detail' | reverseUrl:{id: user.id, name: user.name} }}">{{user.name}}</a>

Clean and simple!

There is not duplicate route defined and parameters are conveniently mapped by name. We explicitly map the parameters in this example, but we can also pass an object to the filter directly to greatly simplifying the statement. If you so prefer there is also the option to provide positional arguments:

<a href="{{ 'user-detail' | reverseUrl:[user.id, user.name] }}">{{user.name}}</a>
In code URL resolution

Occasionally the need arises to compose an URL directly in code. As `reverseUrl` is an Angular filter, we can simply call it directly inside our JavaScript:

$filter('reverseUrl')('user-detail', { id: 1, name: 1 })

This works just fine, though I would suggest wrapping the filter in a service if you often construct URLs in code.

Other solutions

The library presented here offers a very simple yet elegant way to do reverse URL resolution. It should be relatively easy to extend with extra functionality such as parameter type checking. There are also quite a lot of other libraries that offer reverse URL construction. We'll look at the new Angular router and the popular ui-router.

Angular >= 1.5

The new Angular 1.5 router offers reverse URL resolution out of the box. If you've made the leap to the new component based routing, reverse resolution should be a breeze. There are some minor syntactical differences:


AppController.$routeConfig = [
  { path: '/user/:id/:name', component: 'user-detail' }

Template usage

<a ng-link="user-detail({ id: 1, name:'foo' })">Foo's page</a>
UI router

The wildly popular Angular ui-router also offers reverse routing. Chances are if you are using ui-router, you are using this reverse resolution of URLs already. If you are using ui-router and are still hardcoding URLs, switch today! Setup is easy:


 .state('user-detail', {
   URL: "/user/:id/:name",
   controller: "UserDetailCtrl",
   templateUrl: "views/user.html"

Template usage

<a ui-sref="user-detail({ id: 1, name: 'foo' })">Foo's page</a>
Stop hard coding URLs

With so many options, there really is no good reason to hard code URLs in your application. From now on, all URLs you create in any sizable project should be using a reverse URL resolution system.

Reverse URL construction is really simple, it keeps your routes in one place and standardizes URL generation in your app.

If you want to take a closer look at the Angular example code, see the full example: reverse-routing-Angular-example

Five Lessons from Ten Years of IT Failures

IEEE Spectrum has a wonderful article series on Lessons From a Decade of IT Failures. It’s not your typical series in that there are very cool interactive graphs and charts based on data collected from past project failures. They are really fun to play with and I can only imagine how much work it took to put them together.

The overall takeaway of the series is:

Even given the limitations of the data, the lessons we draw from them indicate that IT project failures and operational issues are occurring more regularly and with bigger consequences. This isn’t surprising as IT in all its various forms now permeates every aspect of global society. It is easy to forget that Facebook launched in 2004, YouTube in 2005, Apple’s iPhone in 2007, or that there has been three new versions of Microsoft Windows released since 2005. IT systems are definitely getting more complex and larger (in terms of data captured, stored and manipulated), which means not only are they increasing difficult and costly to develop, but they’re also harder to maintain.

Here are the specific lessons:

Categories: Architecture

Sponsored Post: Digit, iStreamPlanet, Instrumental, Redis Labs, Jut.io, SignalFx, InMemory.Net, VividCortex, MemSQL, Scalyr, AiScaler, AppDynamics, ManageEngine, Site24x7

Who's Hiring?
  • Digit Game Studios, Irish’s largest game development studio, is looking for game server engineers to work on existing and new mobile 3D MMO games. Our most recent project in development is based on an iconic AAA-IP and therefore we expect very high DAU & CCU numbers. If you are passionate about games and if you are experienced in creating low-latency architectures and/or highly scalable but consistent solutions then talk to us and apply here.

  • As a Networking & Systems Software Engineer at iStreamPlanet you’ll be driving the design and implementation of a high-throughput video distribution system. Our cloud-based approach to video streaming requires terabytes of high-definition video routed throughout the world. You will work in a highly-collaborative, agile environment that thrives on success and eats big challenges for lunch. Please apply here.

  • As a Scalable Storage Software Engineer at iStreamPlanet you’ll be driving the design and implementation of numerous storage systems including software services, analytics and video archival. Our cloud-based approach to world-wide video streaming requires performant, scalable, and reliable storage and processing of data. You will work on small, collaborative teams to solve big problems, where you can see the impact of your work on the business. Please apply here.

  • At Scalyr, we're analyzing multi-gigabyte server logs in a fraction of a second. That requires serious innovation in every part of the technology stack, from frontend to backend. Help us push the envelope on low-latency browser applications, high-speed data processing, and reliable distributed systems. Help extract meaningful data from live servers and present it to users in meaningful ways. At Scalyr, you’ll learn new things, and invent a few of your own. Learn more and apply.

  • UI EngineerAppDynamics, founded in 2008 and lead by proven innovators, is looking for a passionate UI Engineer to design, architect, and develop our their user interface using the latest web and mobile technologies. Make the impossible possible and the hard easy. Apply here.

  • Software Engineer - Infrastructure & Big DataAppDynamics, leader in next generation solutions for managing modern, distributed, and extremely complex applications residing in both the cloud and the data center, is looking for a Software Engineers (All-Levels) to design and develop scalable software written in Java and MySQL for backend component of software that manages application architectures. Apply here.
Fun and Informative Events
  • Your event could be here. How cool is that?
Cool Products and Services
  • Instrumental is a hosted real-time application monitoring platform. In the words of one of our customers: "Instrumental is the first place we look when an issue occurs. Graphite was always the last place we looked." - Dan M

  • Real-time correlation across your logs, metrics and events.  Jut.io just released its operations data hub into beta and we are already streaming in billions of log, metric and event data points each day. Using our streaming analytics platform, you can get real-time monitoring of your application performance, deep troubleshooting, and even product analytics. We allow you to easily aggregate logs and metrics by micro-service, calculate percentiles and moving window averages, forecast anomalies, and create interactive views for your whole organization. Try it for free, at any scale.

  • Turn chaotic logs and metrics into actionable data. Scalyr replaces all your tools for monitoring and analyzing logs and system metrics. Imagine being able to pinpoint and resolve operations issues without juggling multiple tools and tabs. Get visibility into your production systems: log aggregation, server metrics, monitoring, intelligent alerting, dashboards, and more. Trusted by companies like Codecademy and InsideSales. Learn more and get started with an easy 2-minute setup. Or see how Scalyr is different if you're looking for a Splunk alternative or Sumo Logic alternative.

  • SignalFx: just launched an advanced monitoring platform for modern applications that's already processing 10s of billions of data points per day. SignalFx lets you create custom analytics pipelines on metrics data collected from thousands or more sources to create meaningful aggregations--such as percentiles, moving averages and growth rates--within seconds of receiving data. Start a free 30-day trial!

  • InMemory.Net provides a Dot Net native in memory database for analysing large amounts of data. It runs natively on .Net, and provides a native .Net, COM & ODBC apis for integration. It also has an easy to use language for importing data, and supports standard SQL for querying data. http://InMemory.Net

  • VividCortex goes beyond monitoring and measures the system's work on your servers, providing unparalleled insight and query-level analysis. This unique approach ultimately enables your team to work more effectively, ship more often, and delight more customers.

  • MemSQL provides a distributed in-memory database for high value data. It's designed to handle extreme data ingest and store the data for real-time, streaming and historical analysis using SQL. MemSQL also cost effectively supports both application and ad-hoc queries concurrently across all data. Start a free 30 day trial here: http://www.memsql.com/

  • aiScaler, aiProtect, aiMobile Application Delivery Controller with integrated Dynamic Site Acceleration, Denial of Service Protection and Mobile Content Management. Also available on Amazon Web Services. Free instant trial, 2 hours of FREE deployment support, no sign-up required. http://aiscaler.com

  • ManageEngine Applications Manager : Monitor physical, virtual and Cloud Applications.

  • www.site24x7.com : Monitor End User Experience from a global monitoring network.

If any of these items interest you there's a full description of each sponsor below. Please click to read more...

Categories: Architecture

What ideas in IT must die?

Are there ideas in IT that must die for progress to be made?

Max Planck wryly observed that scientific progress is often less meritocracy and more Lord of the Flies:

A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it.

Playing off this insight is a thought provoking book collection of responses to a question posed on the Edge: This Idea Must Die: Scientific Theories That Are Blocking Progress. From the book blurb some of the ideas that should transition into the postmortem are: Jared Diamond explores the diverse ways that new ideas emerge; Nassim Nicholas Taleb takes down the standard deviation; Richard Thaler and novelist Ian McEwan reveal the usefulness of "bad" ideas; Steven Pinker dismantles the working theory of human behavior.

Let’s get edgy: Are there ideas that should die in IT?

What ideas do you think should pass into the great version control system called history? What ideas if garbage collected would allow us to transmigrate into a bright shiny new future? Be as deep and bizarre as you want. This is the time for it.

I have two: Winner Takes All and The Homogeneity Principle.

Winner Takes All
Categories: Architecture

Learning about test automation with Lego

Xebia Blog - Mon, 10/26/2015 - 15:44

‚ÄúHold on, did you say that I can learn about test automation by playing with Lego? Shut up and take my money!‚ÄĚ Yes, I am indeed saying that you can.¬†It will cost you a couple hundred Euro‚Äôs, because Lego isn‚Äôt cheap, especially the¬†Mindstorm EV3 Lego. It turns out that¬†Lego robots eat at¬†a lot¬†of AA batteries, so buy a couple of packs of these as well.¬†On the software¬†side you need to¬†have a computer¬†with a Java development environment and an IDE of your choice (the free edition of IntelliJ IDEA will do).¬†

‚ÄúOkay, hold on a second. Why do you need Java? I thought Lego had its own programming language?‚ÄĚ. Yes, that‚Äôs true. Orginally, Lego provides you with their own visual programming language. I mean, the audience for the EV3 is actually kids, but it will be our little secret. Because Lego is awesome, even for adults. Some hero made a Java library that can communicate with the EV3 hardware,¬†LeJos, so you can do more awesome stuff with it. Another hero dedicated a whole website to his Mindstorm projects, including instructions on how to build them.

Starting the project

So, on a sunny innovation day in August at Xebia, Erik Zeedijk and I started our own Lego project. The goal was to make something cool and relevant for Testworks Conf. We decided to go for The Ultimate Machine, also known as The Most Useless Machine.  It took us about three hours to assemble the Lego. If you’re not familiar with the Useless Machine, check this video below. 

Somehow, we had to combine Lego with test automation. We decided to use the Cucumber framework and write acceptance tests in it. That way, we could also use that to figure out what options we wanted to give the machine (sort of a requirements phase...what did I just say!?). The Ultimate Machine can do more than just turn off the switch, as you could tell if you watched the above video. It can detect when a hand is hovering above the switch and that can trigger all kinds of actions: driving away to trick the human, hiding the switch to trick the human, etc. With Acceptance Test Driven Development, we could write out all these actions in tests and use those tests to drive our coding. In that sense, we were also using Test Driven Development. In the picture below is an example of a Cucumber feature file that we used.


The idea sounded really simple, but executing it was a bit harder. We made a conceptual mistake at first. To run our tests, we first coded them in a way that still required a human (someone who turned the switch on). Also, the tests were testing the Lego hardware too (the sensors) and not our own code. The Lego hardware has quite some bugs in it, we noticed. Some of the sensors aren’t really accurate in the values they return. After some frustration and thinking we found a way to solve our problem. In the end, the solution is pretty elegant and in retrospect I face-palm because of my own inability to see it earlier.

We had to mock the Lego hardware (the infrared sensor and the motors), because it was unreliable and we wanted to test our own code. We also had to mock the human out of the tests. This meant that we didn’t even need the Lego robot anymore to run our tests. We decided to use Mockito for our mock setup. In the end, the setup looked like this. 

robot setup

The LeJos Java library uses a couple of concepts that are important to grasp. An arbitrator decides which behavior should run. All the behaviors are put in a behaviorList Inside each behavior is a boolean wantControl that becomes 'true' when certain conditions arise. See the picture below for an example 'wantControl' in the DriveBehavior class. 


Then the behavior starts to run and when it is finished it returns 'idle = true'. The arbitrator then picks a new behavior to run. Because some behaviors had the same conditions for 'wantControl' we had to think of a way to prevent the same behavior from triggering all the time. In each behavior we put a boolean chanceOfBehaviorHappening and we assigned a chance to it. After a bit of tweaking we had the robot running the way we liked it.

The tests were reliable after this refactoring and super fast. The test code was neatly separated from the code that implemented the robot’s behaviour. In addition, you could start the real Lego robot and play with it. This is a picture of our finished robot. 

Lego Ultimate Machine

We didn’t implement all the behaviors we identified on purpose, because our goal was to get attendants of TestWorks Conf to code for our robot. This little project has taught both Erik and me more about writing good Cucumber feature files, TDD and programming. We are both not really Java experts, so this project was a great way of learning for both of us. I certainly improved my understanding of Object Oriented programming. But even if you are a seasoned programmer, this project could be nice to increase your understanding of Cucumber, TDD or ATDD. So, convince your boss to shell out a couple hundred to buy this robot for you and start learning and have fun.

FYI: I will take the robot with me to the Agile Testing Days, so if you are reading this and going there too, look me up and have a go at coding.

Model updates in Presentation Controls

Xebia Blog - Mon, 10/26/2015 - 11:15

In this post I'll explain how to deal with updates when you're using Presentation Controls in iOS. It's a continuation of my previous post in which I described how you can use Presentation Controls instead of MVVM or in combination with MVVM.

The previous post didn't deal with any updates. But most often the things displayed on screen can change. This can happen because new data is fetched from a server, through user interaction or maybe automatically over time. To make that work, we need to inform our Presentation Controls of any updates of our model objects.

Let's use the Trip from the previous post again:

struct Trip {

    let departure: NSDate
    let arrival: NSDate
    let duration: NSTimeInterval

    var actualDeparture: NSDate
    var delay: NSTimeInterval {
        return self.actualDeparture.timeIntervalSinceDate(self.departure)
    var delayed: Bool {
        return delay > 0

    init(departure: NSDate, arrival: NSDate, actualDeparture: NSDate? = nil) {
        self.departure = departure
        self.arrival = arrival
        self.actualDeparture = actualDeparture ?? departure

        // calculations
        duration = self.arrival.timeIntervalSinceDate(self.departure)

Instead of calculating and setting the delay and delayed properties in the init we changed them into computed properties. That's because we'll change the value of the actualDeparture property in the next examples and want to display the new value of the delay property as well.

So how do we get notified of changes within Trip? A nice approach to do that is through binding. You could use ReactiveCocoa to do that but to keep things simple in this post I'll use a class Dynamic that was introduced in a post about Bindings, Generics, Swift and MVVM by Srdan Rasic (many things in my post are inspired by the things he writes so make sure to read his great post). The Dynamic looks as follows:

class Dynamic<T> {
  typealias Listener = T -> Void
  var listener: Listener?

  func bind(listener: Listener?) {
    self.listener = listener

  func bindAndFire(listener: Listener?) {
    self.listener = listener

  var value: T {
    didSet {

  init(_ v: T) {
    value = v

This allows us to register a listener which is informed of any change of the value. A quick example of its usage:

let delay = Dynamic("+5 minutes")
delay.bindAndFire {
    print("Delay: $$$0)")

delay.value = "+6 minutes" // will print 'Delay: +6 minutes'

Our Presentation Control was using a TripViewViewModel class to get all the values that it had to display in our view. These properties were all simple constants with types such as String and Bool that would never change. We can replace the properties that can change with a Dynamic property.

In reality we would probably make all properties dynamic and fetch a new Trip from our server and use that to set all the values of all Dynamic properties, but in our example we'll only change the actualDeparture of the Trip and create dynamic properties for the delay and delayed properties. This will allow you to see exactly what is happening later on.

Our new TripViewViewModel now looks like this:

class TripViewViewModel {

    let date: String
    let departure: String
    let arrival: String
    let duration: String

    private static let durationShortFormatter: NSDateComponentsFormatter = {
        let durationFormatter = NSDateComponentsFormatter()
        durationFormatter.allowedUnits = [.Hour, .Minute]
        durationFormatter.unitsStyle = .Short
        return durationFormatter

    private static let durationFullFormatter: NSDateComponentsFormatter = {
        let durationFormatter = NSDateComponentsFormatter()
        durationFormatter.allowedUnits = [.Hour, .Minute]
        durationFormatter.unitsStyle = .Full
        return durationFormatter

    let delay: Dynamic<String?>
    let delayed: Dynamic<Bool>

    var trip: Trip

    init(_ trip: Trip) {
        self.trip = trip

        date = NSDateFormatter.localizedStringFromDate(trip.departure, dateStyle: .ShortStyle, timeStyle: .NoStyle)
        departure = NSDateFormatter.localizedStringFromDate(trip.departure, dateStyle: .NoStyle, timeStyle: .ShortStyle)
        arrival = NSDateFormatter.localizedStringFromDate(trip.arrival, dateStyle: .NoStyle, timeStyle: .ShortStyle)

        duration = TripViewViewModel.durationShortFormatter.stringFromTimeInterval(trip.duration)!

        delay = Dynamic(trip.delayString)
        delayed = Dynamic(trip.delayed)

    func changeActualDeparture(delta: NSTimeInterval) {
        trip.actualDeparture = NSDate(timeInterval: delta, sinceDate: trip.actualDeparture)

        self.delay.value = trip.delayString
        self.delayed.value = trip.delayed


extension Trip {

    private var delayString: String? {
        return delayed ? String.localizedStringWithFormat(NSLocalizedString("%@ delay", comment: "Show the delay"), TripViewViewModel.durationFullFormatter.stringFromTimeInterval(delay)!) : nil

Using the changeActualDeparture method we can increase or decrease the time of trip.actualDeparture. Since the delay and delayed properties on trip are now computed properties their returned values will be updated as well. We use them to set new values on the Dynamic delay and delayed properties of our TripViewViewModel. Also the logic to format the delay String has moved into an extension on Trip to avoid duplication of code.

All we have to do now to get this working again is to create bindings in the TripPresentationControl:

class TripPresentationControl: NSObject {

    @IBOutlet weak var dateLabel: UILabel!
    @IBOutlet weak var departureTimeLabel: UILabel!
    @IBOutlet weak var arrivalTimeLabel: UILabel!
    @IBOutlet weak var durationLabel: UILabel!
    @IBOutlet weak var delayLabel: UILabel!

    var tripModel: TripViewViewModel! {
        didSet {
            dateLabel.text = tripModel.date
            departureTimeLabel.text = tripModel.departure
            arrivalTimeLabel.text  = tripModel.arrival
            durationLabel.text = tripModel.arrival

            tripModel.delay.bindAndFire { [unowned self] in
                self.delayLabel.text = $0

            tripModel.delayed.bindAndFire { [unowned self] delayed in
                self.delayLabel.hidden = !delayed
                self.departureTimeLabel.textColor = delayed ? .redColor() : UIColor(red: 0, green: 0, blue: 0.4, alpha: 1.0)

Even though everything compiles again, we're not done yet. We still need a way to change the delay. We'll do that through some simple user interaction and add two buttons to our view. One to increase the delay with one minute and one to decrease it. Handling of the button taps goes into the normal view controller since we don't want to make our Presentation Control responsible for user interaction. Our final view controller now looks like as follows:

class ViewController: UIViewController {

    @IBOutlet var tripPresentationControl: TripPresentationControl!

    let tripModel = TripViewViewModel(Trip(departure: NSDate(timeIntervalSince1970: 1444396193), arrival: NSDate(timeIntervalSince1970: 1444397193), actualDeparture: NSDate(timeIntervalSince1970: 1444396493)))

    override func viewDidLoad() {

        tripPresentationControl.tripModel = tripModel

    @IBAction func increaseDelay(sender: AnyObject) {

    @IBAction func decreaseDelay(sender: AnyObject) {

We now have an elegant way of updating the view when we tap the button. Our view controller communicates a change logical change of the model to the TripViewViewModel which in turn notifies the TripPresentationControl about a change of data, which in turn updates the UI. This way the Presentation Control doesn't need to know anything about user interaction and our view controller doesn't need to know about which UI components it needs to change after user interaction.

And the result:

Hopefully this post will give you a better understanding about how to use Presentation Controls and MVVM. As I mentioned in my previous post, I recommend you to read Introduction to MVVM by Ash Furrow and From MVC to MVVM in Swift by Srdan Rasic as well as his follow up post mentioned at the beginning of this post.

And of course make sure to join the do {iOS} Conference in Amsterdam the 9th of November, 2015. Here Natasha "the Robot" Murashev will be giving a talk about Protocol-oriented MVVM.