Blog

My fairly incomplete view on programming

2018-12-17T00:00:00+00:00

Some time ago I had an argument about the notion of behavior and the definitions of referential transparency and purity in functional programming. Due to my incomplete knowledge I could not back my arguments and, therefore, decided to do some research. This post is a write up of my research and primarily serves me as a source. Nonetheless, I welcome you to comment and correct my result.

Models of computation

Theoretical computer science emerged primarily from the work of Alonzo Church and Alan Turing. One of their contributions was the logical foundation of computation. Such a model of computation describes the process of computation and, thus, provides the meaning of different computational steps.

Different to imperative programming languages the model of computation of functional programming is the lambda calculus by Alonzo Church. Raúl Rojas and Joscha Bach provide some very nice explanations.

The lambda calculus is a language of anonymous functions and conversion rules. A line of symbols is an expression. For example, expression λx.x is a function where the lambda sign denotes the beginning of the head and the dot the end of the head. The head defines the variables used in the body; the right hand side of the dot.

Functions can be applied to expressions. That is, the argument expression substitutes the variable in the function body. Evaluating application (λx.x)y yields y as result. This means λx.x is the identity function. The lambda calculus is equivalent to another, more well known model of computation: The Turing machine by Alan Turing.

The Turing machine has a state and symbols on an infinite tape. A table contains the instructions commanding the machine what compute, given a symbol read from the tape and the current state. The machine might erase or write a symbol, then move the head, assume a new state or remain in the current.

The main purpose of the Turing machine was not to be a suitable model for implementing programming languages but to answer general computation questions. For example, Turing was able to show that the Entscheidungsproblem has no general solution.

Turing’s research in this area resulted in a new field of study: The computability theory. In fact, the term turing complete refers to the property of a logical system to be able to compute all functions a Turing machine can compute. This means, if two models of computations are turing complete, then one can emulate the other.

Church was the PhD supervisor of Turing. This means the lambda calculus was known to Turing while he invented the Turing machine. Have a look here for more information about the relationship between Church and Turing.

For further information about models of computation, please see also Models of Computation.

Formal semantics

One of the crucial points is that a model of computation can be seen as a tool for describing the formal semantics of a programming language. A formal semantic is a set of semantic functions which assigns meaning to a syntactical correct program. Formal hereby means, that the rules are unmistakably expressed and often with the help of mathematics. For example, if a programming language adheres to the lambda calculus we know how to compute the result by applying the conversion rules. The conversion rules are the semantic functions because they express what the symbols in an expression mean.

In Java, the Java memory model provides the semantics of the Java programming language. It is the answer to the question of how to correctly assign meaning to an imperative program if it is computed concurrently.

Meaning of state

The notion of state in programming languages often sparks a lot of debate in the programming community. From a theoretical point of view, the lambda calculus does not have a global mutable state. There is just applying conversion rules to expressions until no more rules can be applied. In real functional languages this leads to a problem. If we can only use conversion on expressions, how do we model input and output and still adhere to the lambda calculus? In other words, how does a functional language with I/O stay pure?

This question lead to a debate what purity actually means and how it can be defined to capture the intention of only using expressions. Referntial transparancy, a concept borrowed from the analytical philosophy, is often used to define purity. A typical definition looks like follows:

An expression e is referentially transparent if, for all programs p, all occurrences of e in p can be replaced by the result of evaluating e without affecting the meaning of p. A function f is pure if the expression f(x) is referentially transparent for all referentially transparent x. – Rúnar Bjarnason and Paul Chiusano, Functional Programming in Scala, page 10

This sounds reasonable. Though, there is a subtlety which Rúnar and Paul point out in their companion booklet. What is the meaning of a program? Rúnar and Paul explain that the meaning of a program depends on “how we interpret or evaluate it, and whether some effect of the evaluation is to be considered a side effect depends on the observer. […] So ultimately what we consider to break referential transparency depends very much on what we can or care to observe.”

In the “Functional Programming in Scala” book, they continue to argue that “a mutation that happens inside a function is not a side effect if nothing outside the function refers to the mutated state”. For example, an imperative quicksort function with a mutable array is pure if the code outside does not hold a reference to the array.

However, I/O is a side effect which is observable by the outer code when performed by a function. It breaks referential transparency.

On referential transparency

As usual when concepts are borrowed from other fields the definition changes during the transfer. In his throughout answer to a Stack overflow question Uday Reddy points out the linguistic and semantic background of referential transparency. Informally defined, two expressions a and b are referential transparent if they refer two the same entity e and a can be replaced by b in a context c without altering the meaning. Uday exemplifies this definition.

The Scottish Parliament meets in the capital of Scotland.

The Scottish Parliament meets in Edinburgh.

The terms capital of Scotland and Edinburgh refer to the same entity. In the context of The Scottish Parliament… they are replaceable by each other and, thus, referential transparent. However, in the context of Edinburgh has been the capital of Scotland since 1999. this replacement is not possible without altering the meaning. The terms are not referential transparent in this context.

Uday explains that the differences between the definitions of referential transparency in functional languages and analytical philosophy are the concepts of evaluation and value versus the concept of reference. While values are the result of evaluation and only exist inside a language, references refer to an actual referent which exists outside the language. For example, Edinburgh is a reference to the actual city in Scotland which exists, even without a reference.

Refactoring towards a transaction monad

2017-09-03T00:00:00+00:00

In my last article, I discussed the idea of using higher-order functions to enable code reuse and as a means of describing effects. With higher-order functions, transactions can first be described and then executed. Though, the composition of transactional functions remained as duplicated code in each CRUD method. More subtle, a function does not convey the information whether a transaction is executed during application. This article presents a monadic transaction as a solution to both problems.

This article was originally published on techdev.de.

Before we start

If you are familiar with functions, higher-order functions and types, then you are well prepared for this article. In any other case, I recommend you to check out this presentation, Artem and I held at our local Java User Group in Mannheim.

A brief background about functional languages

Different to imperative languages the model of computation of most functional languages is the lambda calculus by Alonzo Church. A model of computation describes what it means to compute and what the computational elements are.

In a nutshell, the lambda calculus is a language of anonymous functions and some conversion rules. A line of symbols is an expression. For example, expression λx.x is a function where the lambda sign denotes the beginning of the head and the dot the end of the head. The latin letters within the head are variables. On the right side of the dot is the body.

Functions can be applied to expressions. That is, the argument expression substitutes the variable in the function body. Evaluating application (λx.x)y yields y as result. This means λx.x is the identity function. With some other conversion rules, this is enough to be as powerful as other models of computation, like the Turing machine or the Java memory model.

One implication is, that each problem expressed in terms of the lambda calculus has an equivalent representation in any other model of computation. The Haskell compiler proves this by being able to translate purely-functional Haskell code into imperative C code.

A brief and mostly incorrect introduction to monads

The lambda calculus does not rely on effects like exceptions. In functional languages this leads to a problem. If we can only use conversion on expressions, how do we integrate effects like input and output and still adhere to the lambda calculus? In other words, how does a functional language with effects stay pure?

Wadler describes in his paper that some functional languages, like Clojure, augment the lambda calculus with a number of possible effects and become impure. He further describes how monads can be used to integrate impure effects into pure functional languages.

Monad is a concept borrowed from category theory. Though, we don’t need to dig into this theory in order to use it properly. To state Mario Fusco:

“In order to understand monads you first need to learn category theory” is like saying “In order to understand Pizza you need to first learn Italian.”

Wadler continues to explain that monads simplify the code structure and increase the flexibility.

A monad of type M represents some computation. For example, a monad may represent computations with I/O, with potential absent values or with values available in the future. Computation M requires two operations. First, we need a way to turn a value into the computation that just returns this value again.

M<T> of(T value);

Second, we need a way to apply a function of type Function<T, M<U>> to a computation of type M<T>.

M<U> flatMap(M<T> computation, Function<T, M<U>> f);

The type signatures of the operations are important; not the naming. For example, operation of is sometimes named pure or return.

A monad is a triple (M, of, flatMap) consisting of a generic type M, and two operations of the given generic types. Expressions are written in the following form:

M<String> hello = of("hello");
Function<String, M<String>> world = str -> of(str + "World");
M<String> helloWorld = flatMap(hello, world); 

The result of computation hello is bound to variable str and then used in computation world. A monad must adhere to three laws:

left identity - if we turn a value into a computation using of and then feed it to a function using flatMap, it’s the same as just taking the value and applying the function to it: flatMap(of(x), f) == f.apply(x)
right identity - if we have a computation and we use flatMap to feed it to of, the result is our original computation: flatMap(m, v -> of(v)) == m
associativity - if we have a chain of function applications with flatMap, it shouldn’t matter how they are nested: flatMap(flatMap(m, f), g) == flatMap(m, v -> flatMap(f.apply(v), g))

A type which adheres to the laws is also called monadic. The laws describe how the operations relate to each other and, thus, allow us to make reasonable assumptions about their behavior. However, as Rúnar Bjarnason and Paul Chiusano pointed out in Functional Programming in Scala they don’t necessarily provide us a mental model of what a monad is or what a monad means.

Bjarnason and Chiusano continue to explain that we are used to perceive interfaces as a generalization of specific representations. For example, ArrayList and LinkedList both implement List which provides terms of “which a lot useful and concrete application code can be written”. Different to this, “Monad doesn’t generalize one type or another; rather, many vastly different data types can satisfy the Monad interface and laws. The Monad operations are often just a small fragment of the full API for a given data type that happens to be a monad. […] The Monad contract doesn’t specify what is happening between the lines, only that whatever is happening satisfies the laws of associativity and identity.”

Monads in Java 8

With the release of Java 8 we can back the observation about monads with evidence. For example, type CompletableFuture with operations completedFuture and thenCompose satisfies the laws of identity and associativity (see code below).

completedFuture("hello").thenCompose(v -> completedFuture(v + "world"))
                        .thenCompose(v -> completedFuture(v + "2017"));

completedFuture("hello").thenCompose(v -> 
  completedFuture(v + "world").thenCompose(w -> completedFuture(w + "2017"))
);

Let’s pretend we don’t know what the operations mean and what is happening. Still we can conclude that both expressions yield the same result because of the associativity law. What happens if we exchange operation thenCompose with operation thenComposeAsync? As it turns out, we just found another monad consisting of type CompletableFuture with operations completedFuture and thenComposeAsync.

Actually, type CompletableFuture allows us to implement the effect of time in our program. We can reason about CompletableFuture even without knowing its behavior or implementation just because it is monadic.

Towards a transaction monad

A monadic transaction type represents computations which are run within a transaction. It should provide operations to put an action into a transaction and to combine transactions into a single transaction. Further, interpreting or running a transaction with a given entity manager should return a potential result. The code below shows the usage of such a type.

public void update(int id, Consumer<T>... updates) throws Exception {
    findById(id).apply(entityClass)
                .flatMap(entity -> updateEntity(entity, updates))
                .run(entityManager);
}

private Function<Class<T>, Transaction<T>> findById(int id) {
    return clazz -> Transaction.of(em -> em.find(clazz, id));
}

private Transaction<Void> updateEntity(T entity, Consumer<T>... updates) {
    return Transcation.withoutResult(em -> {
        for (Consumer<T> up : updates) {
            up.accept(entity);
        }
    });
}

Method update uses function findById to search for an entity within a transaction. Function findById first accepts the ID of an entity and then its class. It uses the of operation to return a transaction with an action searching for the entity in the database.

The flatMap operation combines two transactions into a single transaction by composing their actions. In case of the update method, the transaction which finds an entity is combined with the transaction which updates an entity. Function updateEntity accepts an entity and some updates and creates a new transaction which applies the updates without returning anything.

The result of the combination is a transaction which both, finds an entity and updates it. This transaction is executed by the side-effecting run interpreter which takes care of starting, committing or rolling back a transaction.

The run method is called interpreter, because it interprets the transaction type as an actual database transaction. For testing purposes a different interpreter could just execute a transaction without a database transaction. This means the potential effect of the transaction type depends on the used interpreter.

Given the capability of describing a transaction before execution, a simple set of CRUD transactions can be factored in an own interface. All data access objects (DAO) or repositories which would like to support CRUD functionalities just inherit this interface.

public interface CrudTransactions<T> {

    default Transaction<Void> saveEntity(T entity) {
        return transactional(em -> em.persist(entity));
    }

    default Transaction<Void> removeEntity(T entity) {
        return transactional(em -> em.remove(entity));
    }

    default Transaction<Void> updateEntity(T entity, Consumer<T>... updates) {
        return transactional(em -> {
            for (Consumer<T> up : updates) {
                up.accept(entity);
            }
        });
    }
    
    default Transaction<Void> transactional(Consumer<EntityManager> action) {
        return Transaction.withoutResult(action);
    }

    default Function<Class<T>, Transaction<T>> findById(int id) {
        return clazz -> Transaction.of(em -> em.find(clazz, id));
    }
}

For example, the BaseEntityDao exposes CRUD methods which rely on the inherited transactions.

public class BaseEntityDao<T> implements EntityDao<T>, CrudTransactions<T> {

    private EntityManager entityManager;
    private Class<T> entityClass;

    @Inject
    public BaseEntityDao(
            @WeldExampleModule.MySQLDatabase EntityManager entityManager,
            @WeldExampleModule.UserClass Class<T> entityClass) {
        this.entityManager = entityManager;
        this.entityClass = entityClass;
    }

    public List<T> findAll(String table) {
        return Transaction.of(em -> {
            final String str = "select e from table e";
            final String jpql = str.replace("table", table);
            return (List<T>) em.createQuery(jpql).getResultList();
        }).run(entityManager);
    }

    public T find(int id) {
        return findById(id).apply(entityClass).run(entityManager);
    }

    public void update(int id, Consumer<T>... updates) throws Exception {
        findById(id).apply(entityClass)
                    .flatMap(entity -> updateEntity(entity, updates))
                    .run(entityManager);
    }

    public void save(T entity) {
        saveEntity(entity).run(entityManager);
    }

    public void remove(int id) {
        findById(id).apply(entityClass)
                    .flatMap(this::removeEntity)
                    .run(entityManager);
    }
}

This looks even more concise than just using higher-order functions. The responsibility of combining transactions by composing their actions is moved to flatMap.

From a developers perspective this is also quite convenient. Beneath CrudTransactions we are able to build up special purpose transactions and group them in different interfaces. By just inheriting these interfaces we get a lot of functionality for free.

This means, we built up a reusable vocabulary to talk in domain terms with our database. For example, UserDetailsDao implements ReadTransactions<User>, CountTransactions<User> may represent a DAO which backs a user details page.

The monadic transaction type itself looks as follows.

package de.gtrefs.transaction;

import javax.persistence.EntityManager;
import java.util.function.Consumer;
import java.util.function.Function;

public abstract class Transaction<T> {
    private final Function<EntityManager, T> action;

    private Transaction(Function<EntityManager, T> action) {
        this.action = action;
    }

    static Transaction<Void> withoutResult(Consumer<EntityManager> action) {
        return of(em -> {
            action.accept(em);
            return null;
        });
    }

    static <U> Transaction<U> of(U value) {
        return of(em -> value);
    }

    static <U> Transaction<U> of(Function<EntityManager, U> action) {

        return new Transaction<U>(action) {
            @Override U run(EntityManager entityManager) {
                try {
                    entityManager.getTransaction().begin();
                    final U result = action.apply(entityManager);
                    entityManager.getTransaction().commit();
                    return result;
                } catch (RuntimeException e) {
                    entityManager.getTransaction().rollback();
                    throw e;
                }
            }
        };

    }

    <U> Transaction<U> map(Function<? super T, ? extends U> mapper) {
        return of(action.andThen(mapper));
    }

    <U> Transaction<U> flatMap(Function<? super T, ? extends Transaction<U>> mapper) {
        return of(em -> {
            final Transaction<U> transaction = action.andThen(mapper).apply(em);
            return transaction.action.apply(em);
        });
    }

    abstract T run(EntityManager entityManager);
}

Operations withoutResult(Consumer<EntityManager> action), of(U value) and of(Function<EntityManager, U> action) put an action into a transaction. The first two are convenient for working with consumers and values. The last one creates a new transaction with the given action. It implements the run method which interprets a Transaction by starting an actual database transaction.

The map operation composes the action of the current transaction with the given mapper and returns a new transaction containing the composition. This means, both are run in the same transaction.

The flatMap operation combines transactions. Similar to map, action and mapper are composed and applied to the entity manager. Next, the result is flattened by also applying the action of the resulting transaction. All actions are executed in the same transaction.

Type Transaction with operations of and flatMap fulfills the monad laws. The proof is left to the interested reader.

Benefit of monads

By now, we saw two monads in the standard library and created one by ourselves. But what is the benefit of a monad? Why do we care about the laws and why do we try to adhere to them?

Knowing a monadic type and its operations, allows us to reason about the behavior. We can safely assume that the outcome does not change when we exploit the associativity law and rearrange the function chaining.

The problem is, that Java itself is a poor tool for monads. In Scala and Haskell there is a special syntax for traversal. For example, using the for comprehension in Scala we can rewrite the update method like the following.

def findAndUpdate(id:Int, clazz:Class[User], update:Consumer[User]){
  val transaction = for {
    entity <- findById(id)(clazz)
    update <- updateEntity(entity, update)
  } yield update
  transaction.run(entityManager)
}

The Scala compiler translates each step in a for comprehension to a flatMap call and the final yield to map. This looks much more like the imperative code we are used to. This works with any type which exposes a flatMap and a map operation.

Another point is, that monads in Java feel artificial because they are part of a solution to a problem which never existed in Java. Java is designed as a side-effecting imperative language describing computations as alterations of state. In contrast, pure functional languages adhere to an abstract mathematical thinking in functions, types and laws.

Though, monadic types help us dealing with side-effects in a predictable way. For example, as stated in the documentation of vavr, Try represents a computation that may either result in an exception, or return a successfully computed value. It puts exception handling back into the normal application flow and forces us to think about exceptional cases.

Summary

In this article we looked at the background of functional languages and how monads fit in. By showcasing CompletableFuture we saw, that a monad is merely a triple consisting of a type and two operations which adhere to the laws of identity and associativity. Different to the interfaces we are used to, the monad concept describes a self-containing interface which is satisfied merely when the laws are fulfilled.

From another perspective a monad is a computation which has an operation to put values into a new computation and another operation which composes two operations. Such a computation may be I/O or asynchronous.

We created a monadic transaction type for combining transactions and were able to define reusable transactions. The more general concept is known as Reader monad. It is intended to read values from an environment and feed them to functions. With Reader we are able to do dependency injection without any framework.

In the end we discussed the benefits of monads and saw that Scala has a better support. For more information about functional programming in general and with Scala in particular, I recommend you the book Functional Programming in Scala.

Higher Order Functions are useful

2017-07-19T00:00:00+00:00

In March I gave my first talk at a conference. It was about the combinator pattern and I wondered why there was only little feedback in regard of the pattern itself. The only question I got was surprisingly about monads. This kept me wondering and a little idea came to my mind: higher-order functions are useful. This article is the result of this thought, where I am going to show how to use higher-order functions for code reuse and as a means of describing effects.

This article was originally published on techdev.de.

Before we start

On higher-order functions

A higher-order function (HOF) is a function, which takes one or more other functions as parameters and/or returns another function. Functions are values: They are constructed and passed around. A function which is not a HOF is a first-order function. Look at the example below.

int calculate(int i, Function<Integer, Integer> f){
  return f.apply(i);
}

The calculate function takes an integer and a function and applies the function to the integer. The interesting part is, that before and after the function application other code can be run (see listing below).

int increaseAndCalculate(int i, Function<Integer, Integer> f){
  int increased = i + 1;
  return f.apply(increased);
}

This simple example demonstrates that HOFs can be used to separate concerns. Increasing the integer value i is a different concern than applying function f.

Code Reuse

The idiom of separating concerns is also found in the execute around method pattern. Marius Herring has a nice blog post where he uses this pattern to unify transaction handling in one place. Let’s illustrate and discuss this idea by refactoring the code of Alejandro Gervasio in his article about using Weld to inject Entity Managers.

Weld is the reference implementation of the Context and Dependency Injection (CDI) specification and an important part of the Java EE platform. CDI specifies how beans declare their dependencies and how the context can be used to manage a bean’s life cycle. Further, it also manages resources like data sources or entity managers.

Alejandro demonstrates how dependency injection with Weld can be used to inject managed resources and beans in Java SE. As part of the presented idea, Alejandro builds up a generic Data Access Object (DAO; see code below).

public class BaseEntityDao<T> implements EntityDao<T> {

    private EntityManager entityManager;
    private Class<T> entityClass;

    @Inject
    public BaseEntityDao(
            @MySQLDatabase EntityManager entityManager,
            @UserClass Class<T> entityClass) {
        this.entityManager = entityManager;
        this.entityClass = entityClass;
    }

    public T find(int id) {
        return entityManager.find(entityClass, id);
    }

    public List<T> findAll(String table) {
        String str = "select e from table e";
        String jpql = str.replace("table", table);
        return entityManager.createQuery(jpql).getResultList();
    }

    public void update(int id, Consumer<T>... updates) throws Exception {
        T entity = find(id);
        Arrays.stream(updates).forEach(up -> up.accept(entity));
        beginTransaction();
        commitTransaction();
    }

    public void save(T entity) {
        beginTransaction();
        entityManager.persist(entity);
        commitTransaction();
    }

    public void remove(int id) {
        T entity = find(id);
        beginTransaction();
        entityManager.remove(entity);
        commitTransaction();
    }

    private void beginTransaction() {
        try {
            entityManager.getTransaction().begin();
        } catch (IllegalStateException e) {
            rollBackTransaction();
        }
    }

    private void commitTransaction() {
        try {
            entityManager.getTransaction().commit();
        } catch (IllegalStateException | RollbackException e) {
            rollBackTransaction();
        }
    }

    private void rollBackTransaction() {
        try {
            entityManager.getTransaction().rollback();
        } catch (IllegalStateException | PersistenceException e) {
            e.printStackTrace();
        }
    }
}

The BasicEntityDAO contains the Create, Read, Update and Delete (CRUD) functionalities one would expect. Alejandro focused on using constructor injection by exposing the dependencies through the constructor. He uses CDIs feature for creating custom annotations like MySQLDatabase, called custom qualifiers, to specify which kind of beans and resources are demanded.

In this implementation all CRUD methods deal explicitly with transaction handling: transactions are started, committed or aborted. For example, in case of the save method transaction handling makes up 2/3 of the complete code.

The idea of the execute around method pattern is to move a scattered and/or repeated responsibility into one single method. This method accepts an action and executes the responsibility around it. In case of the DAO, transaction handling is refactored in this way (see code below).

public class BaseEntityDao<T> implements EntityDao<T> {

    private EntityManager entityManager;
    private Class<T> entityClass;

    @Inject
    public BaseEntityDao(
            @WeldExampleModule.MySQLDatabase EntityManager entityManager,
            @WeldExampleModule.UserClass Class<T> entityClass) {
        this.entityManager = entityManager;
        this.entityClass = entityClass;
    }

    public T find(int id) {
        return entityManager.find(entityClass, id);
    }

    public List<T> findAll(String table) {
        String str = "select e from table e";
        String jpql = str.replace("table", table);
        return entityManager.createQuery(jpql).getResultList();
    }

    public void update(int id, Consumer<T>... updates) throws Exception {
        T entity = find(id);
        transactional(em -> Arrays.stream(updates).forEach(up -> up.accept(entity)));
    }

    public void save(T entity) {
        transactional(em -> em.persist(entity));
    }

    public void remove(int id) {
        transactional(em -> em.remove(find(id)));
    }

    private void transactional(Consumer<EntityManager> action){
        try{
            entityManager.getTransaction().begin();
            action.accept(entityManager);
            entityManager.getTransaction().commit();
        }catch (RuntimeException e){
            entityManager.getTransaction().rollback();
            throw e;
        }
    }
}

The transactional method accepts an action and executes a new transaction around it. All other methods use transactional to ensure that a given logic is executed in a transaction. This leads to more concise code and reduces the potential of incorrect transaction management.

There is only one way a pure function may return nothing: when it does nothing. Any other observed effect is a side effect. Because of this, transactional is not a HOF, but rather a higher-order procedure. From an outside perspective this makes it hard to reason about how it affects the program state.

Further, we might want to have more control about how actions are executed in a transaction. For example, when the DAO evolves, more sophisticated actions, like updating and removing entities at the same time, might be necessary. How do we compose those actions in the same transaction without relying on code duplication again?

Means of describing effects

Let us sit back and look at the transactional method. Transaction execution is the apparent side effect. What we need is a means to describe the transaction and delay its execution. This would allow us to compose descriptions without the burden of side effects.

A function is an interface exposing its input and output types. Adhering to this contract, transactional can be refactored to a pure HOF. Let’s have a look at the code below.

public void save(T entity) {
    Function<EntityManager, Void> transaction = noResult(em -> em.persist(entity));
    transaction.apply(entityManager);
}

public T convert(int id, UnaryOperator<T> converter){
   Function<EntityManager, T> find = em -> em.find(entityClass, id);
   Function<EntityManager, T> transaction = transactional(find.andThen(converter));
   return transaction.apply(entityManager);
}

private Function<EntityManager, Void> noResult(Consumer<EntityManager> action) {
    return transactional(em -> {
         action.accept(em);
         return null; 
    });
}

private Function<EntityManager, T> transactional(Function<EntityManager, T> action){
    return em -> {
         try {
              em.getTransaction().begin();
              final T result = action.accept(em);
              em.getTransaction().commit();
              return result;
        } catch (RuntimeException e) {
              em.getTransaction().rollback();
              throw e;
        }
    };
}

The save method show-cases the distinction between description and execution. First, it uses the noResult function to describe that saving an entity should be done in a transaction. Then it executes the transaction by applying it to the entityManager. Thus, transaction description is pure and execution is side effecting.

Method convert illustrates how descriptions are composed. It is responsible for finding an entity, applying the conversion and returning the converted entity. The responsibility is split into the functions find and convert. The action which is executed within a transaction is the composition of these functions.

This approach has some draw backs. Interface Function hides transaction handling details and, thus, does not convey the information whether a transaction is executed during application or not. This may lead to unwanted side effects. To demonstrate this, the code below contains the transactionalConvert method which has the same responsibility as the convert method.

public T transactionalConvert(int id, UnaryOperator<T> converter){
   Function<EntityManager, T> find = transactional(em -> em.find(entityClass, id));
   Function<EntityManager, T> convert = transactional(em -> converter.apply(entity));
   Function<EntityManager, T> transaction = find.andThen(convert);
   return transaction.apply(entityManager);
}

The responsibility is split into the find and convert functions. This time, however, both functions are transactions by themselves. Composing and executing these functions results in two separate transactions being executed. This might not be what the developer intended.

Another more subtle drawback is that the responsibility of composition is duplicated in each CRUD method. Would it not be better to shift this to some combinators?

Summary and Conclusion

In this article we have seen that the execute around method pattern can be used to move the scattered responsibility of transaction management into one single method transactional which accepts an action and executes a transaction around it. Due to this immediate side effect transactional is not a higher-order function but rather a higher-order procedure.

We then used the concept of a function as interface which allowed us to compose descriptions without the burden of side effects. This made composing actions easier and we were able to defer different parts of a transaction into different functions.

However, a function does not convey the information whether a transaction is executed during application or not. This makes it hard to reason about side effects. Another drawback was the repetition of transaction composition in every CRUD method.

There is a solution to both problems: monads. In my next article, I will describe what a monad is and how it helps us to combine transactions.

Six Ways to functional FizzBuzz with Vavr

2017-05-08T00:00:00+00:00

Sometime last year I stumbled over the excellent post of twenty ways to do FizzBuzz in JavaScript. I asked myself, how some functional solutions in Java 8 and vavr could look. In this article I present 6 different solutions using functional data structures, higher order functions and property checking. All these solutions adhere to the test harness I introduced in my last article.

This article was originally published on sitepoint.com.

Before We Get Started

My motivation behind this article was to experiment with different functional approaches to get used to a more functional thinking. The presented solutions not necessarily line up in a linear procession from bad to good. They are just different ways to skin the same cat and have different trade-offs, which is exactly what I want to explore. If you know another solution or want to discuss a presented one, please leave a comment.

Before we start with the actual functional solutions we will look at an imperative one and discuss its responsibilities. Further, we do some functional reasoning and introduce the stream data structure which we will use extensively. Last, the properties a FizzBuzz function should fulfill are discussed.

Imperative Solution and Functional Reasoning

A simple imperative solution exactly states how to count from 1 to 100, how to compute the modulo, and how to decide what is printed when. It is like following a recipe.

public void fizzBuzzFrom1to100(){
    for(int i = 1; i <= 100; i++){
        if (i % 3 == 0 && i % 5 == 0) {
            System.out.println("FizzBuzz");
        } else if (i % 3 == 0) {
            System.out.println("Fizz");
        } else if (i % 5 == 0) {
            System.out.println("Buzz");
        } else {
            System.out.println(i);
        }
    }
}

From an outside perspective, this method does not exhibit any behavior other than printing to the console. It is quite tedious to test because in order to verify the computed results we need to mock System.out and count the calls. But in order to do the mocking we need to know the internals.

When we already risk a look inside the method we see that it is responsible for computing and displaying the result. We can factor the logic of computing into an own function and use a secondary method on an outer layer to print the result.

public List<String> fizzBuzz(int amount) {
    List<String> ret = new ArrayList<>();
    for (int i = 1; i <= amount; i++) {
        if (i % 3 == 0 && i % 5 == 0) {
            ret.add("FizzBuzz");
        } else if (i % 3 == 0) {
            ret.add("Fizz");
        } else if (i % 5 == 0) {
            ret.add("Buzz");
        } else {
            ret.add(String.valueOf(i));
        }
    }
    return ret;
}

public void printList(List<String> list){
    for(String element: list){
        System.out.println(element);
    }
}

printList(fizzBuzz(100));

Testing the fizzBuzz function becomes easy because everything the function does is represented by the returned list. We can check any element in the list for its value.

Given a particular input, the fizzBuzz function will always produce the same output. We could replace function application fizzBuzz(100) with the computed list without changing the meaning of our program. That is, the fizzBuzz function is pure.

The reasoning is, that a method with side effects can always be factored into a pure function and two side-effecting methods supplying input and coping with output. That is, we push the side effects to the boundaries of our application. All presented solutions follow this principle by shifting the responsibility of iteration and displaying to vavr’s stream data structure. The shell code of these functions looks as follows.

public static void main(String... args){
    fizzBuzzStream(100).forEach(System.out::println);
}

private static Stream<String> fizzBuzzStream(int amount){
    return Stream.from(1)
        .map(fizzBuzz())
        .take(amount);
}

In the next section we have a deeper look on streams, but let me point out the important parts of this code. First, in the fizzBuzzStream function we create a stream of integers which counts from 1 on. Then, we map these integers with the help of a fizzBuzz function which computes a FizzBuzz element for a given number. This is the part most solutions will implement. Next, we convert the infinite stream to a finite one by taking amount elements. In the main method these elements are printed onto the console.

Notice how the stream hides details like iteration and creation. We operate on a very declarative level and become very concise in expressing our program. Also notice that the side effect of printing the elements is the last action that is performed. Effectively it is the most outer layer in our program.

vavr Stream

The functional data structure Stream may be Empty or a Cons. A Cons consists of a head element and a lazy computed tail Stream. An infinite Stream does not contain an Empty tail.

We write Stream.cons(1, () -> Stream.empty()) to define a stream which contains 1 as head and an empty tail. Following this notation, defining an infinite stream of 1s may look like this: Stream.cons(1, () -> Stream.cons(1,...)). However, this is not valid syntax in Java and would be rather tedious. Therefore, we employ a recursive function which computes the next 1 on demand.

Stream<Integer> ones() {
    return Stream.cons(1, () -> ones());
}

Java evaluates method arguments before a method is called. In case of an infinite stream this is tricked with a Supplier in order to prevent a stack overflow. This also allows a memory efficient representation of a stream because just the head is kept in memory. This differs from a List which contains all elements and from a Java 8 stream which is a composed aggregate operation on a sequence of data elements from some source.

Test Harness

There are three invariants, a stream of FizzBuzz elements should satisfy:

Every third element should start with Fizz
Every Multiple of 5 must end with Buzz
Every non-third and non-fifth Element should remain a number

In property based testing (PBT), each invariant is combined with a sample generator forming a property. For example, in case of the Fizz invariant, a generator creates multiples of 3. For each generated sample, the invariant is checked. If one check yields false, the property is said to be falsified. Otherwise, it is called satisfied.

For a more thorough introduction and a build-up of the FizzBuzz test harness have a look at my article on property based testing with vavr.

6 Ways to FizzBuzz

The first three solutions are about writing pure functions computing FizzBuzz elements. At their core, each of these functions maps a number to a word. This information is exposed by their type: Function<Integer, String>. In fact, any of the three implementations could be used to replace any other one. That is, they are referentially transparent.

In the fourth and fifth solution we have a look at how functions on streams can be employed to create a FizzBuzz solution. We always stay in the stream context and the return type is Stream<String>.

The sixth and last solution explores another approach contributed by Pierre-Yves.

1. A Simple Function

This is the computational core of the imperative solution. Depending on the modulo operations, the corresponding FizzBuzz element is returned.

static Function<Integer, String> fizzBuzz(){
    return i -> {
        if (i % 3 == 0 && i % 5==0) {
            return "FizzBuzz";
        } else if (i % 3 == 0) {
            return "Fizz";
        } else if (i % 5 == 0) {
            return "Buzz";
        } else {
           return i.toString();
        }
   }
}

What I like about this solution is, that it is pretty straight forward and that it shows that a pure function can be factored out of a side-effecting method. However, this solution is still quite inflexible and looks like an imperative solution. For example, if we want to add another case for replacing every multiple of 4 by Bizz we need to add another clause.

2. Pattern Matching

This solution differs from the first one by employing pattern matching instead of if-statements. Think of pattern matching as a switch-statement on steroids that examines the structure of an expression and has no fall-through semantics.

static Function<Integer, String> withPatternMatching(){
    return e -> Match(Tuple.of(e % 3, e % 5)).of(
        Case(Tuple2($(0),$(0)), "FizzBuzz"),
        Case(Tuple2($(0), $()), "Fizz"),
        Case(Tuple2($(), $(0)), "Buzz"),
        Case($(), e.toString())
    );
}

We match the tuple of the computational result against patterns described in cases. If a case matches, the string on the right side is returned. For example, if a number is both divisible by 3 and by 5, "FizzBuzz" is returned.

This solution is more concise than the first one and we got rid of the explicit if-statements. However, we became even less flexible. For example, to test for another number we now need to extend the match clause and add another case.

3. Combinator Pattern

In this solution I used the combinator pattern.

static Function<Integer, String> withCombinator(){
    return fizzBuzz()
        .orElse(fizz())
        .orElse(buzz())
//      .orElse(word("Bizz").ifDivisibleBy(4))
        .orElse(number());
}

interface NumberToWord extends Function<Integer, String> {

    static NumberToWord fizzBuzz(){
        return fizz().and(buzz());
    }

    static NumberToWord fizz(){
        return word("Fizz").ifDivisibleBy(3);
    }

    static NumberToWord buzz(){
        return word("Buzz").ifDivisibleBy(5);
    }

    static NumberToWord word(String word){
        return i -> word;
    }

    static NumberToWord number(){
        return Object::toString;
    }

    default NumberToWord ifDivisibleBy(int modulo){
        return i -> i % modulo == 0 ? apply(i) : "";
    }

    default NumberToWord orElse(NumberToWord other){
        return i -> {
            String result = apply(i);
            return result.isEmpty()
                ? other.apply(i)
                : result;
        };
    }

    default NumberToWord and(NumberToWord other){
        return i -> {
            String first = this.apply(i);
            String second = other.apply(i);
            return (first.isEmpty() || second.isEmpty())
                ? "";
                : (first + second);
        };
    }
}

The combinator pattern helps us to write a little embedded domain specific language with terms from the FizzBuzz domain. Even more, the language is shaped in a way that allows us to add new words for numbers without changing the core WordToNumber type.

I like how declarative this solution is, but there is a loss in conciseness. The increase in readability (assuming you internalized the combinator pattern) compensates this more than enough, though.

4. Zipped Streams

In this solution we have a different perspective on the FizzBuzz problem that allows us to compute no element at all. The idea is to see each FizzBuzz subsequence, for example the one going nothing, nothing, "Fizz", as its own stream.

static Stream<String> withZippedStreams(){
    return Stream.of("","","Fizz").cycle()
            // creates a Stream<Tuple2<String, String>>
            .zip(Stream.of("","","","","Buzz").cycle())
            // creates a Stream<Tuple2<Tuple2<String, String>, Integer>>
            .zip(Stream.from(1))
            // flattens Tuple2<Tuple2<String, String>, Integer> to String
            .map(flatten());
}

private static Function<Tuple2<Tuple2<String, String>, Integer>, String>
        flatten() {
    return tuple -> {
        String fizzBuzz = tuple._1._1 + tuple._1._2;
        String number = tuple._2.toString();
        return fizzBuzz.isEmpty()
            ? number
            : fizzBuzz;
    };
}

Every third element should be Fizz is expressed as a stream which cycles over a sequence of two empty elements and the third element being “Fizz”. This results into a stream which repeats this sequence infinitely. The same idea applies to the to the Buzz element.

Both streams are merged using the zip function. The name of the function states what it does: It binds two streams into a stream of tuples (see also zipper).

This zipped stream is merged again with another stream containing the integers from 1 on. The flatten function maps the result by deciding what the actual element should be. For example, if both elements from the Buzz and Fizz stream are empty, the element becomes the number.

I like this solution because it follows a thought outside the box. What if everything I have is a stream?

5. Zipped Transformation Stream

Different from the previous solution we are now zipping streams of functions.

static Stream<String> withFunctions(){
    return fizzBuzzTransformations()
            .zip(Stream.from(1))
            .map(functionAndNumber ->
                    functionAndNumber._1.apply(functionNumber._2));
}

private static Stream<Function<Integer, String>> fizzBuzzTransformations() {
    Function<Integer, String> empty =  i -> "";
    return Stream.of(empty, empty, i -> "Fizz").cycle()
            // creates Stream<Tuple2<Function<Int, Str>, Function<Int, Str>>>
            .zip(Stream.of(empty, empty, empty, empty, i -> "Buzz").cycle())
            // flattens Tuple2<Function<Int, Str>, Function<Int, Str>>
            // to Function<Int, Str>
            .map(flatten());
}

private static Function<
            Tuple2<Function<Integer, String>, Function<Integer, String>>,
            Function<Integer, String>>
        flatten() {
    return functions -> i -> {
        String fizzBuzz = functions._1.apply(i) + functions._2.apply(i);
        return fizzBuzz.isEmpty()
            ? i.toString()
            : fizzBuzz;
    };
}

The Fizz element, for example, is translated to a stream which cycles over a sequence of three functions. The first two elements, are the empty function which returns nothing for a given integer. The last element, is the Fizz function which returns Fizz for a given number. The Buzz element is translated equivalently.

The interesting part is how we map the stream of tuples of functions. For a given tuple we return a function which takes a number and applies the functions in the tuple. That is, for each tuple in the stream we compose a new function which uses the previous functions for deciding what the actual element is. For example, if both elements are the empty function, the actual element becomes the number. This is similar to the flatten function from the previous solution.

The resulting stream of composed functions is zipped with a stream which counts from 1 on. The only thing left is to apply the function in each tuple to the number.

What I very much like about this solution is how it displays that functions are values which can be passed around.

6. A Wheel

During our internal review session, Pierre-Yves noticed and pointed out that a wheel is the underlying pattern of the two stream based solutions. Wheel is a metaphor for a periodic sequence of elements. The repeated subsequence starts from 1 and ends with the first FizzBuzz. When you distribute the elements of the subsequence equally over a wheel, then determining the next element is advancing the wheel to the next element. Pierre-Yves visualized this idea with the following code.

public static void main(String... args) {
    String[] wheelArray = new String[] {
            "", "", "Fizz", "", "Buzz",
            "Fizz", "", "", "Fizz", "Buzz",
            "", "Fizz", "", "", "FizzBuzz"};
    Stream<String> fizzBuzz = fizzBuzzStream(wheelArray);
    fizzBuzz.take(30).forEach(System.out::println);
}

private static Stream<String> fizzBuzzStream(String[] wheelArray) {
    return Stream
            .iterate(new Wheel(wheelArray), Wheel::next)
            .map(Wheel::getValue);
}

static class Wheel {

    private final String[] wheel;
    private final int numValue;
    private final String value;

    private Wheel(String[] wheelArray) {
       this(wheelArray, 0);
    }

    private Wheel(String[] wheelArray, int n) {
        this.wheel = wheelArray;
        this.numValue = n + 1;
        int index = n % wheel.length;
        this.value = wheel[index].length() == 0
            ? Integer.toString(numValue)
            : wheel[index];
    }

    private String getValue() {
        return this.value;
    }

    private Wheel next() {
        return new Wheel(this.wheel, this.numValue);
    }
}

The interesting part is the use of an immutable class Wheel to keep track of the state and method references to an instance method of an arbitrary type. The wheel takes an initial sequence of elements. It then computes the numeral value, the index, and the value determined by the position of the wheel. If the element in the wheel array at the index position is not empty, it becomes the value. Otherwise, the numeral value becomes the value.

The constructed stream iterates wheels, returned by the next function, each being one step further compared to the previous one. This infinite stream of wheels is then mapped to the computed FizzBuzz element using Wheel::getValue.

Summary

The FizzBuzz problem is easy to understand. Nonetheless, there are manifold ways to solve it. In this article we concentrated on functional solutions using the vavr library.

We first discussed an imperative solution and how we can factor a functional core. This led us to a more general discussion about how to reason with functional programs. The key insight here is, that every non-functional method can be transformed into a pure function and two methods which supply input and cope with output. Side effects are pushed to the boundaries of our program.

In the second part of the article we had a look on 6 different solutions for the FizzBuzz problem. The first three solutions focused on computing the FizzBuzz element for a given number while the last two put their focus on using functions on streams. All solutions had some advantages and disadvantages. The key insight here is, that thinking outside the box may lead to unexpected solutions.

Do you know another functional FizzBuzz solution or a simple problem which might be solved in different ways? Leave a comment!

Your little dose of octocat zen

2017-03-13T00:00:00+00:00

Last year at Socrates Matthias gave a little introduction how GitHub makes GitHub. A little collection of 14 statements, called zen, capture the core values and principles. This zen is available through the public API.

Let’s have a look on such a zen statement. Try it out:

curl https://api.github.com/octocat

You get back a octocat telling you one zen statement.

               MMM.           .MMM
               MMMMMMMMMMMMMMMMMMM
               MMMMMMMMMMMMMMMMMMM      _____________________
              MMMMMMMMMMMMMMMMMMMMM    |                     |
             MMMMMMMMMMMMMMMMMMMMMMM   | Speak like a human. |
            MMMMMMMMMMMMMMMMMMMMMMMM   |_   _________________|
            MMMM::- -:::::::- -::MMMM    |/
             MM~:~ 00~:::::~ 00~:~MM
        .. MMMMM::.00:::+:::.00::MMMMM ..
              .MM::::: ._. :::::MM.
                 MMMM;:::::;MMMM
          -MM        MMMMMMM
          ^  M+     MMMMMMMMM
              MMMMMMM MM MM MM
                   MM MM MM MM
                   MM MM MM MM
                .~~MM~MM~MM~MM~~.
             ~~~~MM:~MM~~~MM~:MM~~~~
            ~~~~~~==~==~~~==~==~~~~~~
             ~~~~~~==~==~==~==~~~~~~
                 :~==~==~==~==~~

I really like this and created a little zsh plugin which displays a zen statement, every time you start a console. When I am lucky Robby Russel will accept my pull request.

If you are unwilling to wait, then you can just add the following code to your .zshrc. This might even work with bash but I did not test it.

function display_octozen() {
  local command="curl -s https://api.github.com/octocat"
  local zen=$(eval ${command})
  if [ "$zen" != "" ]; then
    printf '%s\n' ${zen}
  fi
}
 
display_octozen

Until then, happy coding.

Property Based Testing with Javaslang

2017-02-17T00:00:00+00:00

Usual unit testing is based on examples: We define the input for our unit and check for an expected output. Thus, we can ensure that for a specific sample our code works right. However, this does not prove the correctness for all possible inputs. Property based testing, also called property checking, takes another approach by adhering to the scientific theory of Falsifiability: As long as there is no evidence that a proposed property of our code is false, it is assumed to be true. In this article we are using Javaslang’s API for property based testing to verify a simple FizzBuzz implementation.

This article was originally published on sitepoint.com.

Before We Start

I am using Javaslang Streams to generate an infinite FizzBuzz sequence which should satisfy certain properties. Compared with Java 8 Streams, the main benefit in the scope of this article is that the Javaslang variant provides a good API to retrieve individual elements with the get function.

Property Based Testing

Property based testing (PBT) allows developers to specify the high-level behaviour of a program in terms of invariants it should fulfill. A PBT framework creates test cases to ensure that the program runs as specified.

A property is the combination of an invariant with an input values generator. For each generated value, the invariant is treated as a predicate and checked whether it yields true or false for that value.

As soon as there is one value which yields false, the property is said to be falsified and checking is aborted. If a property cannot be falsified after a specific amount of sample data, the property is assumed to be satisfied.

Reverse List Example

Take a function that reverses a list as an example. It has several implicit invariants that must hold in order to provide proper functionality. One of them is, that the first element of a list is the last element of the same list reversed. A corresponding property combines this invariant with a generator which generates lists with random values and lengths.

Assume, that the generator generates the following input values: [1,2,3], ["a","b"] and [4,5,6]. The list reverse function returns [3,2,1] for [1,2,3]. The first element of the list is the last element of the same list reversed. The check yields true. The list reverse function returns ["a", "b"] for ["a", "b"]. The first element of the list is not the last element of the same list reversed. The check yields false. The property is falsified.

In Javaslang the default amount of tries to falsify a property is 1000.

Property Checking FizzBuzz

FizzBuzz is a child’s play counting from 1 on. Each child in turn has to say the current number out loud. If the current number is divisible by 3 the child should say “Fizz”, if it is divisible by 5 the answer should be “Buzz” and if it is divisible by both 3 and 5 the answer should be “FizzBuzz”. So the game starts like this:

1, 2, Fizz, 4, Buzz, Fizz, 7, 8, Fizz, Buzz, 11, Fizz, 13, 14, FizzBuzz, …

FizzBuzz is often taken as a sample exercise in job interviews where applicants should fizzbuzz the numbers from 1 to 100. FizzBuzz can also be used as a Kata simple enough to focus on the surroundings like language, libraries or tooling instead of the business logic.

A stream seems to be a good way to model FizzBuzz. We will start with an empty one and gradually improve it to pass our tests.

public Stream<String> fizzBuzz() {
    Stream.empty();
}

Every Third Element Should Start with Fizz

From the description of FizzBuzz we can derive a first property about the FizzBuzz Stream: Every third element should start with Fizz. Javaslang’s property checking implementation provides fluent APIs to create generators and properties.

@Test
public void every_third_element_starts_with_Fizz) {
    Arbitrary<Integer> multiplesOf3 = Arbitrary.integer()
        .filter(i -> i > 0)
        .filter(i -> i % 3 == 0);

    CheckedFunction1<Integer, Boolean> mustStartWithFizz = i ->
        fizzBuzz().get(i - 1).startsWith("Fizz");

    CheckResult result = Property
        .def("Every third element must start with Fizz")
        .forAll(multiplesOf3)
        .suchThat(mustStartWithFizz)
        .check();

    result.assertIsSatisfied();
}

Let’s go through it one by one:

Arbitrary.integer() generates arbitrary integers which are filtered for positive multiples of 3 using filter.
The function mustStartWithFizz is the invariant: For a given index, the corresponding element in the stream (get is 0-indexed) must start with Fizz. The call to suchThat further below requires a CheckedFunction1, which is like a function but may throw a checked exception (something we do not need here).
Property::def takes a short description and creates a Property. The call to forAll takes an Arbitrary and ensures that the invariant in suchThat must hold for all input values generated by the Arbitrary.
The check function uses the generator to create multiples of 3 in the range from 0 to 100. It returns a CheckResult which can be queried about the result or be asserted.

The property is not satisfied, because for every generated multiple of 3 the corresponding element does not exist in the empty Stream. Let’s fix this by providing a suitable stream.

public Stream<String> fizzBuzz() {
    return Stream.from(1).map(i -> i % 3 == 0 ? "Fizz": "");
}

Stream::from creates an infinite stream, which counts from the given number on. Every multiple of 3 is mapped to Fizz. The resulting stream contains a Fizz for every third element. Once we check the property again, it is satisfied and the result is printed on the console:

Every third element must start with Fizz: OK, passed 1000 tests in 111 ms.

Increase the Sample Size

Per default, check tries to falsify a property 1000 times. Each time, the given Arbitrary generates a sample value which depends on a size parameter. Per default, the size parameter is set to 100. For Arbitrary.integer() the negative size parameter defines the lower bound and the positive size parameter defines the upper bound for the generated value. This means, a generated integer has a value between -100 and 100. We further limit the generated values to be only positive and to be multiples of 3. This means, we test each multiple of 3 in the range from 1 to 100 approximately 30 times.

Fortunately, Javaslang allows us to adapt the size and the number of tries by providing corresponding parameters to the check function.

CheckResult result = Property
	.def("Every third element must start with Fizz")
	.forAll(multiplesOf3)
	.suchThat(mustStartWithFizz)
	.check(10_000, 1_000);

Now, the generated multiples of 3 are drawn from a range between 1 and 10’000 and the property is checked 1000 times.

Every Multiple of 5 Must End with Buzz

A second property which can be derived from the FizzBuzz description is that every multiple of 5 must end with Buzz.

@Test
public void every_fifth_element_ends_with_Buzz() {
    Arbitrary<Integer> multiplesOf5 = Arbitrary.integer()
        .filter(i -> i > 0)
        .filter(i -> i % 5 == 0);

    CheckedFunction1<Integer, Boolean> mustEndWithBuzz = i ->
        fizzBuzz().get(i - 1).endsWith("Buzz");

    Property.def("Every fifth element must end with Buzz")
        .forAll(multiplesOf5)
        .suchThat(mustEndWithBuzz)
        .check(10_000, 1_000)
        .assertIsSatisfied();
}

This time, property checking and assertion are combined.

This property is falsified just like the one checking Buzz was initially. But this time not because there are no elements (since the last test the fizzBuzz function creates an infinite stream) but because every fifth element is an empty string or sometimes Fizz but never Buzz.

Let’s fix this by returning Buzz for every fifth element.

public Stream<String> fizzBuzz() {
    return Stream.from(1).map(i ->
        i % 3 == 0 ? "Fizz" : (i % 5 == 0 ? "Buzz" : "")
    );
}

When we check the property again, it is falsified after some passed tests:

Every fifth element must end with Buzz: Falsified after 7 passed tests in 56 ms.

The message in the AssertionError describes the sample which falsified the property:

Expected satisfied check result but was Falsified(propertyName = Every fifth element must end with Buzz, count = 8, sample = (30)).

The reason is, that 30 is divisible by 3 and by 5 but in the fizzBuzz() implementation above divisibility by 3 has a higher precedence than divisibility by 5. However, a change in precedence does not solve the issue, because the first property that every third element should start with Fizz would be falsified. A solution is to return FizzBuzz if it is divisible by 3 and 5.

private Stream<String> fizzBuzz() {
    return Stream.from(1).map(i -> {
        boolean divBy3 = i % 3 == 0;
        boolean divBy5 = i % 5 == 0;

        return divBy3 && divBy5 ? "FizzBuzz" :
            divBy3 ? "Fizz" :
            divBy5 ? "Buzz" : "";
        });
}

Both properties are satisfied with this approach.

Every Non-Third and Non-Fifth Element Should Remain a Number

A third property that can be derived from the FizzBuzz description is that every non-third and non-fifth element should remain a number.

@Test
public void every_non_fifth_and_non_third_element_is_a_number() {
    Arbitrary<Integer> nonFifthNonThird = Arbitrary.integer()
        .filter(i -> i > 0)
        .filter(i -> i % 5 != 0)
        .filter(i -> i % 3 != 0);

    CheckedFunction1<Integer, Boolean> mustBeANumber = i ->
        fizzBuzz().get(i - 1).equals(i.toString());

    Property.def("Non-fifth and non-third element must be a number")
        .forAll(nonFifthNonThird)
        .suchThat(mustBeANumber)
        .check(10_000, 1_000)
        .assertIsSatisfied();
    }

The check of this property fails, because so far the fizzBuzz function maps non-_Fizz_ and non-_Buzz_ numbers to the empty String. Returning the number solves this issue.

private Stream<String> fizzBuzz() {
    return Stream.from(1).map(i -> {
	boolean divBy3 = i % 3 == 0;
	boolean divBy5 = i % 5 == 0;

	return divBy3 && divBy5 ? "FizzBuzz" :
		divBy3 ? "Fizz" :
		divBy5 ? "Buzz" : i.toString();
	});
}

Other Properties

Checking these three properties is enough to shape the fizzBuzz function. There is no need for a special FizzBuzz property because this case is already covered by the Fizz and Buzz properties. However, we could add another property which should not hold for all elements. For example, there should be no white space between Fizz and Buzz in FizzBuzz. I think this is a nice exercise and I leave it you, my dear reader, to define and check such a property.

There is another flaw in our tests, though: Our properties are not specific enough. Checking that an element starts with Fizz or ends with Buzz is also satisfied by a stream which just contains FizzBuzz for any multiple of 3 and 5. Can you fix our properties?

Benefits and Disadvantages

As said before, PBT has the advantage that one can focus on specifying the expected behaviour of a program instead of defining each edge case. This shifts testing to a more declarative level.

Compared with other implementations Javaslang provides a nice fluent API which is unobtrusive regarding the used test framework. It works with JUnit 4, JUnit 5 and TestNG. Spock has a BDD mindset and I am not sure if the term specifcation has the same meaning in Spock as in PBT but this could be explored in another article. It seems to be a nice addition to the data-driven approach.

A disadvantage is that rare bugs may not be discovered on the first run and may brake later builds. Further, coverage reports may differ from build to build. However, this is negligible.

The crucial part of PBT is how well the underlying random number generator (RNG) performs and how well it is seeded. A bad RNG yields a bad distribution of test samples and this may result in “blind spots” of the tested code. Javaslang relies on ThreadLocalRandom and this is more than okay.

Javaslang currently has a limited amount of supported types. It would be beneficial to also support generic subdomains like time and to provide a way to generate random entities and value objects of a core domain.

Summary

We have seen that Property based testing is based on the theory of Falsifiability. We learned that Javaslang has a fluent API which codifies this idea. It enables us to define properties as the combination of an invariant and an input values generator. Per default, an invariant is checked against 1000 generated samples.

This enabled us to think about FizzBuzz on more declarative level. We defined and checked three properties and discussed the outcomes.

Last, we talked about benefits and disadvantages of PBT.

Combinator Pattern with Java 8

2016-07-28T00:00:00+00:00

The Combinator Pattern is well-known in functional programming. The idea is to combine primitives into more complex structures. At my last talk at the majug I presented a way of how to employ this pattern with Java 8. In this post we will have a look at this design.

Before we start

If you know functions and higher-order functions in Java 8, then you are more than prepared to read this post. If not, I recommend you to look at this presentation. There you will find a nice introduction to functions in Java 8 by Artem. The code can be found here.

On primitives and combinators

Like many constructs in functional programming, primitives and combinators are names for abstractions. Wikipedia provides a description for language primitives:

In computing, language primitives are the simplest elements available in a programming language. […] an atomic element of an expression in a language. – Wikipedia

Likewise, primitives used in the combinator pattern are the simplest elements within a domain. For example, addition and multiplication in the domain of integers. Combinators provide means to compose primitives and/or already composed structures into more complex structures. For example, combining multiplication and addition. Due to the declarative nature of this pattern, the code itself employs a lot of domain terms.

Validation with combinators

Let’s pretend we are tasked to validate users. A user is valid if the name is not empty and the email contains an @ sign. A straight-forward way to model this, is to add query methods to the corresponding entity:

public class User{
   public final String name;
   public final int age;
   public final String email;

   public User(String name, int age, String email){
     this.name = name;
     this.age = age;
     this.email = email; 
   }

   public boolean isValid(){
     return nameIsNotEmpty() && eMailContainsAtSign();
   }

   private boolean nameIsNotEmpty(){
     return !name.trim().isEmpty();
   }

   private boolean eMailContainsAtSign(){
     return email.contains("@");
   }
}

new User("Gregor", 30, "nicemail@gmail.com").isValid(); // true

While this reads well, there are some disadvantages. What happens when the validation rules change? For example, for some use cases users must be older than 14. In this case, we need to adapt the isValid method. So this looks like a violation of the SRP. Before we refactor and extract the validation part into an own class, let us sit back and think about what we want to express. A user is valid if and only if a given set of rules are satisfied. A rule describes the properties a user must have. Different rules can be combined to more complex ones. Applying a rule yields a validation result which describes the outcome. For now, let us assume that a true boolean value indicates that a user is valid. In more functional terms, we can express this in the following way:

public interface UserValidation extends Function<User, Boolean>{}
UserValidation nameIsNotEmpty = user -> !user.name.trim().isEmpty();
UserValidation eMailContainsAtSign = user -> user.email.contains("@");
User gregor = new User("Gregor", 30, "nicemail@gmail.com");

nameIsNotEmpty.apply(gregor) && eMailContainsAtSing.apply(gregor); // true

There is some boilerplate code here. Why do we have to create the nameIsNotEmpty and eMailContainsAtSign rules by ourselves? Why do we have to combine the results manually? Why are there 4 lines of initialization code for just one application line? Although the code is a bit wordy, it contains all building blocks for the combinator pattern: nameIsNotEmpty and eMailContainsAtSign are primitives and && is a combinator. With Java 8 we are able to move primitives and combinators into the UserValidation type.

interface UserValidation extends Function<User, Boolean> {
    static UserValidation nameIsNotEmpty() {
        return user -> !user.name.trim().isEmpty();
    }

    static UserValidation eMailContainsAtSign() {
        return user -> user.email.contains("@");
    }

    default UserValidation and(UserValidation other) {
        return user -> this.apply(user) && other.apply(user);
    }
}

User gregor = new User("Gregor", 30, "nicemail@gmail.com");
nameIsNotEmpty().and(eMailContainsAtSign()).apply(gregor); // true

Primitives are translated to static methods and combinators to default methods. Both primitives, nameIsNotEmpty and eMailContainsAtSign, return a lambda expression with UserValidation as target type. Different to primitives, the and combinator composes UserValidations by using the && operator. There are two important observations in using this pattern. First, there is no application during combining time. This means, one first constructs a UserValidation and then executes it. This distinction makes one UserValidation applicable for many users. Second, UserValidation has no own state. This means, one UserValidation can be applied in a parallel environment without race conditions. For example, the following code conducts user validations in parallel.

List<User> users = findAllUsers()
    .stream().parallel()
    .filter(nameIsNotEmpty().and(eMailContainsAtSign())::apply) // to Predicate
    .collect(Collectors.toList());

Validation result reasoning

Do you think that Boolean is a reasonable choice as type for validation results? In general, built-in language types are often a bad choice for representing domain information. Two reasons why: First, in Java it is hardly possible to adapt code we don’t own. We cannot add query methods to the Boolean type. This makes it hard to determine which rules invalidated the result. Second, the semantics of a built-in type is implicit and context-specific. For example, in the validation context true means that a user is valid; i.e. all desired properties are present. This assumption might not hold, when we pass validation results to other contexts. There is a need for a new type ValidationResult containing the reason why a user is invalid under a specific rule.

interface ValidationResult{
    static ValidationResult valid(){
        return ValidationSupport.valid();
    }
    
    static ValidationResult invalid(String reason){
        return new Invalid(reason);
    }
    
    boolean isValid();
    
    Optional<String> getReason();
}

private final static class Invalid implements ValidationResult {

    private final String reason;

    Invalid(String reason){
        this.reason = reason;
    }

    public boolean isValid(){
        return false;
    }

    public Optional<String> getReason(){
        return Optional.of(reason);
    }

    // equals and hashCode on field reason
}

private static final class ValidationSupport {
    private static final ValidationResult valid = new ValidationResult(){
        public boolean isValid(){ return true; }
        public Optional<String> getReason(){ return Optional.empty(); }
    };

    static ValidationResult valid(){
        return valid;
    }
}

A ValidationResult is either valid or Invalid. The equality of two ValidationResults is defined by the equality of their properties and types; i.e. two Invalid instances are equal if and only if they have the same invalidation reason. An anonymous singleton instance yields the same meaning in the valid case. This means, valid and Invalid are value objects. In order to use the new ValidationResult, we have to adapt UserValidation.

interface UserValidation extends Function<User, ValidationResult> {
    static UserValidation nameIsNotEmpty() {
        return holds(user -> !user.name.trim().isEmpty(), "Name is empty.");
    }
  
    static UserValidation eMailContainsAtSign() {
        return holds(user -> user.email.contains("@"), "Missing @-sign.");
    }

    static UserValidation holds(Predicate<User> p, String message){
        return user -> p.test(user) ? valid() : invalid(message);
    }

    default UserValidation and(UserValidation other) {
        return user -> {
            final ValidationResult result = this.apply(user);
            return result.isValid() ? other.apply(user) : result;
        };
    }
}

UserValidation validation = nameIsNotEmpty().and(eMailContainsAtSign());
User gregor = new User("", 30, "mail@mailinator.com");

ValidationResult result = validation.apply(gregor);
result.getReason().ifPresent(System.out::println); // Name is empty.

Primitive holds tests a given Predicate and, either, returns valid or a new Invalid. Primitives nameIsNotEmpty and eMailContainsAtSign have been refactored accordingly. The and combinator only computes the result of other if this yields valid. For example, eMailContainsAtSign is not evaluated for a given user, if nameIsNotEmpty is already Invalid. From a developers perspective this little API change conveys much more information compared to a plain Boolean value. However, there are some flaws in the design. For example, in a web context one would like to evaluate all validation rules in order to have an extensive report, but the and operator is short-circuiting. Thus, there is a need for an all combinator evaluating all validation rules.

Implement an all combinator which executes all given UserValidations and gathers the results. Use the following method declaration.

static UserValidtion all(UserValidation... validations){ 
  // Your code here 
}

Summary

This post presented a possible design for the combinator pattern in Java 8. We discussed primitives and combinators as building blocks. A validation use case illustrated how the pattern is applied to a specific domain. Last, we reasoned about the result of a validation. There are some benefits of a well-applied combinator pattern. From a developers perspective the API is made of terms from the domain. For example, primitives nameIsNotEmpty and eMailContainsAtSign clearly state their purpose. It strengthens the Single Responsibility Principle by enabling an easier separation of concern. Further, there is a clear distinction between combining and application phase. One first constructs an instance and then executes it. This makes the pattern applicable in a parallel environment.

CraftConf 2016 - Crafting Code Workshop

2016-04-26T00:00:00+00:00

The day is here: First time CraftConf ever. So far, Budapest is a pleasurable stay. I got to know Thomas who studies medicine in Hungary and drove me into the city. Further, the room I booked revealed itself as a complete flat with 2 rooms, kitchen and bathroom. Hamburg, your accomondations has nothing on that! For me, the conference started with the two-days workshop Crafting Code by Sandro Mancuso.

Crafting Code

This course is designed to help developers write well-crafted code—code that is clean, testable, maintainable, and an expression of the business domain. The course is entirely hands-on, designed to teach developers practical techniques they can immediately apply to real-world projects.

The leading motive of this course is coding exercises in changing pairs. Each participant introduced himself and shortly described his favorite programming language and TDD experience. In my modesty, I explained that my favourite language is Java (even though I am learning Scala right now) and that I took part in another TDD workshop. In total, Java, by far, was most frequently stated. But, there were some C#, Python and one Scala developers.

First exercise

I did my first exercise with two other Java developers (Peter was one of them) and we all agreed that a Stack should reasonable easy to implement. Intuitionally, we started to test our Stack to throw an exception if it is popped when empty. After that, we were trapped in a dead lock. How can we independently test the push and pop methods without introducing new behaviour like a size method? Answer is: We can’t. However, we can describe a property of the stack which must hold: The last object which was pushed must be popped first. Thus, our next test case should first push an object and then assert that the pop method returns this object. Thereby, there should not be a single line of production code which is not forced by a test case. For example, consider the following snippet:

The easiest way to make this test green is to store the given object in an instance variable:

Searching the problem domain, we found another property resulting into a good test case: Objects which have been pushed must be popped in reverse order. Expressed as test case, this property forces us to store the objects properly. From this exercise, I learned the following:

Only use terms from the domain (return vs. pop)
Don’t introduce additional business behaviour because of test code (cf. size method)
Tests should have a setup (does not matter if AAA or Given-When-Then)
Describe the behaviour instead of testing single methods
Go from simple to complex
Tests get more specific while the business code gets more generic
Assert first, then Act, last Arrange
Command: void; Query: return something
- difficult to have methods which do both (exception: Front controller)
- Commands are hard to test because they change state

Second exercise

For this exercise I teamed up with the only Scala developer. We wrote tests in Specs2 which was not familiar to me. The first thing, I realized is that I have to do more Katas, because I recognized the exercise from before but could not remeber the solution. Again, we were quick in finding a simple test case (RomanNumberConverter(1) == "1") but got stuck deriving more complex test-cases from the domain. This resulted into a lot of if-else expressions for different roman numbers. Sandro helped us by introducing the Transformation Priority Premise. After we applied some of these transformations to our code we were able to see patterns. For example, consider the following snippet:

A roman literal is added to the result as long as the corresponding arabic number still fits in the intermediate conversion result. We ignored the excpetional case of having a leading lower number (for example, IV) and came up with the following code:

Leading lower number cases are reflected as own entries in the arabicToRoman list:

From this exercise I learned:

Specs2 seems to be a nice Testing Framework
Write enough tests to reveal a pattern
Treat excpetions in the end
- Don’t overengineer your code before

Third exercise

For this exercise I teamed up with one of the python guys. Unfortunately, I did not get a hold of the source code. Nontheless, I learned the following:

Introduce types where necessary (Year(2016).isLeap())?
Primitive types don’t know anything about the domain (cf. int vs. Year)
Value objects attract behaviour (cf. isLeap)

Fourth exercise

Java: Outside-In TDD

Write tests first (maybe red)
Outside: Outside classes model a process (How to call the components) while inner classes do the actual work. Instead to verify the outcome it is necessary to verify the process (process vs. state)
- Test with mocks
Diff to FP: The building block ins FP are small functions which are taken to compose more complex scenarious (Classist approach)

To be continued

Java annotations as GitHub names

2015-09-06T09:23:20+00:00

Twitter, Facebook and GitHub have the name reference functionality in common. To mention another user, person and/or organization in your post, tweet, timeline and/or commit just type @ and add the corresponding name. Escpecially, GitHub and Java have an interesting relationship because whenever a comment or commit containing a Java annotation is published an equally-named GitHub user is notified. In this post I exploit this by registering FunctionalInterface and RestController as GitHub users and by providing a little script to check for available Java-GitHub-Names.

Names

The first name I registered was FunctionalInterface which was introduced with Java 8 and marks an interface to have a single abstract method. In this way it may be used by the compiler for type inference for lambda expressions. Next, I registered RestController which is defined by the Spring MVC framework indicating classes as Front Controllers for RESTful services. Some Java annotations were already registered as GitHub users. To check available names I created a little Python script.

Each line in the annotations file is considered to be a user name. The list contains all annotations in Java SE 8 and some Spring annotations. Following 27 names were taken: After, Around, Aspect, Autowired, Before, Component, Order, Pointcut, Qualifier, Repeat, Repository, Required, Resource, Rollback, Scope, Service, Timed, Transactional, Deprecated, Documented, FunctionalInterface, Inherited, Override, Retention, SuppressWarnings, Target and RestController.

Results

Annotation	Project	User	# mentions	Example link
FunctionalInterface	Eclipse JDT core	asbharadwaj	1	commit
FunctionalInterface	sai	jmorwick	6	commit
FunctionalInterface	ironrhino	zhouyanming	1	commit
FunctionalInterface	spark	bentolor	5	commit
FunctionalInterface	OTBProject	NthPortal	2	commit
FunctionalInterface	SpongeAPI	gabizo	1	comment
FunctionalInterface	Eclipse Platform ui	vogella	1	commit
RestController	kuitos.github.io	Kuitos	1	issue
RestController	firstRest	prochiy	-	-
RestController	Spring	UnAmi	-	-
RestController	springfox	rcruzper	1	issue
RestController	spring-integration-kafka	ashishsoni	1	issue
RestController	exercise-spring-boot-integration-tests	ebragaparah	1	commit
RestController	find	matthew-gordon-h	1	commit
RestController	swagger4spring-web-jdk6	wkennedy	2	commit
RestController	spring-security-oauth	berrytchaks	1	issue
RestController	springside	shurun19851206	2	commit

I would have assumed to get more notifactions from annotation FunctionalInterface. One reason for this limited recall might be that an user is only notified when the mention is in a comment or commit message. Looking at the projects themselves there is eclipse as the biggest one and sai as the smallest one. Also the commit sizes differ: SpongeAPI has rather large commits while OTBProject has smaller ones. Different to FunctionalInterface RestController is referenced by a lot more toy projects (for example Spring and firstRest) which yields more notifications. Personally, I perceived the notfications as pleasent because I get informed about new code related to topics I am interested in. I would not mind, if GitHub would add a topic based subscription feature.

Umgebung in Singapur

2015-08-14T00:00:00+00:00

Die ersten paar Tage in Singapur waren nicht sehr anstrengend. Den ersten Tag hatte ich frei, da mein Vorgesetzter kurzfristig krank geworden ist. Diesen Tag habe ich genutzt um ein bisschen auszuschlafen und meine direkte Umgebung zu erkunden. In diesem Eintrag zeige ich euch ein paar Fotos. Ich möchte mich jetzt gar nicht herausreden, aber es ist hier schon viel los, sodass ich nicht wirklich zum Schreiben komme.

Vor meiner Hasutür

Vor meiner Haustüre gibt es viele Essenstände und Restaurants. Ich habe in letzter Zeit viel beim Vietnamnesen und Chinesen verbracht. Hier sind Bilder direkt aus meinem Fenster.

Auf dem ersten Bild seht ihr den rechten Teil der Foodstreet. Die Tische dort sind für alle Kunden die an einem Stand etwas gekauft haben oder für Menschen die um 1 Uhr Nachts etwas angetrunken aus der Sportsbar gegenüber kommen. Ich bin da natürlich nicht dabei. Auf dem nächsten Bild seht ihr den linken Teil der Foodstreet. Das ist auch der Weg, den ich zur Arbeit laufe. Das Bild zeigt auch Werbung für Yummy Viet. Tolles Essen zum tollen Preis. Die nächsten beiden Bildern zeigen den Essenstand direkt unter meinem Fenster. Da esse ich kein zweites Mal. Essen war mies und preislich viel zu teuer. Hier ein paar Bilder was ich schon so alles verdrückt habe.

Die beiden oberen Bilder sind aus dem Vietnamnesen. Das sind Sommerrollen mit Erdnussoße und Reisnudelsalat mit Erdnüssen und Schweinefleisch. Für $12 ist das mehr als in Ordnung. Das Bild unten links zeigt ein echt wunderbares Hähnchen süß-sauer und das Bild rechts enthält ebenfalls Hähnchen mit einer Vorspeise. Wenn ich mich recht erinnere waren beide Speisen etwas teurer als der Reisnudelsalat (ca. $18-20). Trotzdem sehr lecker. Es gibt hier in der Umgebung allerdings auch Exoten. So habe ich einen Österreicher entdeckt der Fleichkäsebrötchen und andere Wurstwaren verauft. Ich habe einmal dort gegessen, aber zum Fotografieren der Speisen hat es nicht gelangt.

An beiden Eingängen der Smith Street steht folgende Statue.

Die Smith Street war nicht immer die Food Street. Wenn man Google Street View bemüht, sieht man dass im Jahr 2009 noch regulär Autos durch die Straße gefahren sind.

Der Weg zur Arbeit

Leider kann ich nicht die ganze Zeit essen. Das liegt vor allem daran, dass ich nicht ausschließlich zum Vergnügen in Singapur bin. Zeitlich brauche ich zur Arbeit 5 Minuten zu Fuß. Der Weg führt über die South Bridge Road hinauf zur Club Street, welche ich hinunter laufe und dann angekommen bin.

Auf den oberen beiden Bildern seht ihr die South Bridge Road. Dort wo der schwarze Wagen auf die South Bridge Road abbiegt, gehe ich hinauf. Im dritten Bild befinden wir uns mitten auf der Club Street. Das nächse Bild ist an der gleichen Kreuzung aufgenommen nur in die andere Richtung. Direkt neben der Bar Bartine befindet sich der Eingang zum Büro. In dem Bild ist er halb offen.

Ich muss sagen, dass ich mich mit der Zeit an die Wärme gewöhnt habe: Ich gehe mit langen Hosen zur Arbeit. Bis jetzt gefällt mir Singapur jeden Tag besser. Ich werde probieren nächste Woche noch einmal einen Eintrag zu schreiben. Entweder über Marina Bay oder Kuala Lumpur. Bis dahin wünsche ich euch ein paar schöne Tage. Ihr könnt mir gerne wieder einen Kommentar hinterlassen. Das würde mich freuen.

Ankunft in Singapur

2015-07-12T00:00:00+00:00

Wie ihr sicherlich alle wisst, habe ich Anfang März 2015 mit meiner Promotion begonnen. Was ihr vielleicht nicht wisst, ist dass ich gesponsort bin. Ja ich bin gekauft. Meine Firma hat mich nun für knapp 2 Monate nach Singapur eingeladen. Also heißt es für mich: Koffer packen und mit dem Flieger fliegen. Mit diesem Blog würde ich euch gerne über meine Reise auf dem Laufenden halten und ihr dürft so tun als ob es euch interresiert. Das könnt ihr am Besten mit einem Kommentar unter meinen Einträgen.

Vor der Abreise

Ich habe mir vor meiner Abreise einen neuen Koffer gekauft. Der Grund ist, dass ich keinen großen Koffer hatte. Der Grund hierfür ist, dass dies meine erste Reise mit längerem Aufenthalt ist. Der Koffer ist groß und es passt viel rein. Also genau richtig für mich. Kurz vor der Abreise bin ich krank geworden und mit hohem Fieber zu Hause gelegen. Meine gesamte Reise hat sich damit um eine Woche nach hinten verschoben, sodass ich erst am 6. Juli losgeflogen bin.

A380 in Frankfurt

Flug und Ankunft

Ich bin mit dem Zug zum Flughafen Frankfurt gefahren und habe dort meinen A380 um 21:50 Uhr bestiegen. In der Economy-Klasse gibt es leider nicht so viel Platz und nach 12 Stunden Flug ist man ganz schön geschlaucht. Glücklicherweise hat das Kind in der Reihe neben mir erst 30 Minuten vor der Landung angefangen zu schreien. Der Flughafen in Singapur ist groß und sauber. Ich muss sagen, das war ein schöner erster Eindruck.

Landebahn Flughafen Singapur

Ich habe mir ein Taxi genommen und bin zur 30 Smith Street gefahren. Das ist mitten in der Food Street von China Town. Die ganze Straße besteht quasi aus Restaurants und Essensständen. Hunger muss ich also nicht leiden.

Smith Street / Food Street

Das Zimmer befindet sich im 2. Stock über der Smith Street. Von meinem Fenster aus kann ich direkt in die Kochtöpfe schauen. Das Bett ist groß und die Ausstattung durchaus komfortabel. Leider ist es auch ein wenig laut. Aber spät am Abend herrscht Ruhe, sodass ich doch ein wenig schlafen kann.

Zimmer mit Naßzelle und King Sized Bed

Ich bin ein Wintermensch. Was mich nervt ist die hohe Luftfeuchtigkeit. Kaum ist man 5 Minuten auf der Straße fühlt man sich an wie beidseitiges Klebeband. Auf der anderen Seite ist fast jeder Raum klimatisiert. Wenn ich als Klebeband dann auf die Kälte treffe würde ich mir gerne wieder einen Pulli anziehen. In diesem Sinne wünsche ich euch einen schönen Tag.