> I have been working with Go in a service-oriented architecture over the past year and a half. It has been a fun ride after years of working with and enjoying JavaScript. This post is part of a series in which I attempt to make my learnings accessible to other engineers with a JavaScript background. Huge thanks go to my dear colleague [Tom Arrell](https://tomarrell.com "Tom's website") who has taught me most of the things I now know about Go.

Tests are one of the most important things when shipping software users depend on. When making fast incremental changes in a large project, tests and good test coverage allow us to trust we did not break anything. This is especially true when working in an unfamiliar codebase where tests also help us understand how a certain part of the code works.

TypeScript and Go each have a static type system which protects us from passing incompatible parameters to functions or accessing object properties in an unsafe way. Having that extra safety compared to JavaScript is great, but we will still want to cover our application or library code in tests. In this blog post we will explore how to do that in Go, and we will look at some patterns for different test scenarios and contexts.

I assume you test your JavaScript code with [Jest](https://jestjs.io "Jest Testing Framework Website"). All examples from this post are [available on GitHub](https://github.com/felixjung/blog-posts/tree/main/posts/go-tests/example-code "Go to the GitHub repository containing the example code").

## Writing a Basic Function Test

Let’s start by testing a simple `sum` function which takes two numbers and returns their sum.[^1] The JavaScript version of that function looks like as follows.

```js
function sum(a, b) {
 return a + b
}
```

In our test we set up the two inputs `a` and `b`, write down the expected return value (`want`) and run our assertion using Jest’s `expect` [function](https://jestjs.io/docs/en/expect "Jest documentation for the expect function") and the `toBe` [matcher](https://jestjs.io/docs/en/using-matchers "Jest documentation for common matchers"). The test file, `sum.spec.js`, is colocated with the module, `sum.js`.

```js
import { sum } from './sum';

test('sum', () => {
 const a = 1;
 const b = 2;

 const want = 3;

 const got = sum(a, b)

 expect(got).toBe(want);
});
```

The Go equivalent to the above example looks like this.

```go
package math

func Sum(a, b int) int {
	return a + b
}
```

In a `math` package we export a `Sum` function from a `sum.go` file. Right next to that file we place our test file, `sum_test.go` with the following test code.

```go
package math

import "testing"

func TestSum(t *testing.T) {
	a := 1
	b := 2

	want := 3

	got := Sum(a, b)

	if want != got {
		t.Fatalf("Sum: wanted %d, got %d", want, got)
	}
}
```

Our testing approach is the same as in the JavaScript example. So let us look at the differences in [how tests work in go](https://golang.org/pkg/testing/ "Go documentation on testing"). The most significant difference is that Go has out of the box-support for testing. You do not need a testing framework like Jest.

> Testing frameworks for Go do exist. If you look for them, you will most likely stumble upon [Ginkgo](https://onsi.github.io/ginkgo/ "Ginkgo testing framework website") or [GoConvey](http://goconvey.co "GoConvey testing framework website"). Both these examples aim at providing a Behavior-Driven Development (BDD) testing experience. They provide abstractions for writing tests and test runners with features like watch mode.
> 
> I would recommend _against_ using such testing frameworks. As with other aspects of writing Go, I feel that sticking close to the language and its tooling keeps things simple. If you want to write BDD style tests, there are ways of doing that with Go’s testing support as explained later in this post.

Tests are run with the `go test` command and package `testing` provides all the basics you need to test your code. Additionally, the example demonstrates the following.

* Tests live in a file with the `_test` suffix in the filename. When you run `go test`, the test tool will look for files with that suffix.
* Every test is defined with [a function using the `Test` prefix](https://pkg.go.dev/testing#pkg-overview "Open the Go documentation for package "testing"") in the function name, i.e. `TestSum`. It is important that the first letter after `Test` is capitalized. Functions located in a test file and using this name pattern are identified as test routine.
* Test routines are called with a pointer to an instance of [the `T` struct from the `testing` package](https://pkg.go.dev/testing#T "Documentation for the T type of package testing") (i.e. `*testing.T`). `T` manages the test state and provides functions for failing a test or writing logs.
* Assertions can be written with plain Go. You make your assertion in a simple `if` statement. You fail the test by calling `t.Fail`, `t.FailNow`, `t.Fatal`, `t.Fatalf`, or other methods on the `T` struct. This becomes a bit tedious for more complicated assertions, so will look at assertion libraries in the next section.

## Powerful Assertions With Testify

Making assertions with `if` statements can get a bit harder to read and may become quite involved when you start handling more complicated assertions. For example, you may want to test whether a slice contains a certain value or that an HTTP handler returns a certain status code. [Testify](https://github.com/stretchr/testify "Testify GitHub repository") is a very popular library for mocking and assertions. It is designed to work well with the standard library.[^2]

Let us rewrite the assertion in `TestSum` with Testify.

```go
package math

import (
	"testing"

	"github.com/stretchr/testify/require"
)

func TestSumWithTestify(t *testing.T) {
	a := 1
	b := 2

	want := 3

	got := Sum(a, b)

	require.Equal(t, want, got)
}
```

Here we are using Testify’s `require` package and the `Equal` assertion. Testify also has an `assert` package with the same API. However, the assertions in `require` will fail your test immediately, while `assert`’s assertions will allow your test to continue. I prefer my tests to fail immediately because I find it easier to identify the underlying problem. The first argument to an assertion is the `testing.T` pointer. Assertions comparing an expected and an actual value take the expected value as second parameter and the actual value as third parameter. This is important because you can easily get confused by a failing test’s output when you flipped the two.

If you have a test with several assertions, you can create an instance of the `require` package `Assertions` and use that directly. The same is true for the `assert` package.

```go
package math

import (
	"testing"

	"github.com/stretchr/testify/require"
)

func TestSumWithAssertionsInstance(t *testing.T) {
	require := require.New(t)

	a := 1
	b := 2

	want := 3

	got := Sum(a, b)

	require.Equal(want, got)
}
```

Some linter rules may complain about shadowing the `require` package inside your test function. Do not bother with those violations, as this is common practice.

## Behavior-Driven Development With Subtests

Earlier in this post I mentioned how some Go testing frameworks are made for [Behavior-Driven Development (BDD)](https://en.wikipedia.org/wiki/Behavior-driven_development "BDD on Wikipedia"). In BDD you develop your software and tests against human-readable requirements. These requirements can, for example, be written by product managers using a product domain’s [ubiquitous language](https://martinfowler.com/bliki/UbiquitousLanguage.html "Martin Fowler definition of Ubiquitous Language"). 

To make the example a bit more interesting, let us consider a `sumOrMax` function. `sumOrmax` returns the sum of parameters `a` and `b` as long as it stays below a `max` value provided as a third parameter. If the sum is larger than `max`, `sumOrMax` returns `max`.

```js
export function sumOrMax(a, b, max) {
 const sum = a + b;

 return sum < max ? sum : max;
}
```

Jest supports BDD tests out of the box with the `describe` and `it` functions.

```js
import { sumOrMax } from './sum-or-max';

describe('sumOrMax', () => {
 describe('when the sum is below the maximum', () => {
 it('should return the sum', () => {
 const a = 1;
 const b = 2;
 const max = 4;

 const want = 3;

 const have = sumOrMax(a, b, max);

 expect(have).toBe(want);
 });
 });

 describe('when the sum is at or above the maximum', () => {
 it('should return the maximum', () => {
 const a = 5;
 const b = 10;
 const max = 4;

 const want = max;

 const have = sumOrMax(a, b, max);

 expect(have).toBe(want);
 });
 });
});
```

In Go, we can achieve something equivalent with subtests. The Go version of `sumOrMax` looks as follows.

```go
package math

func SumOrMax(a, b, max int) int {
	sum := a + b

	if sum < max {
		return sum
	}

	return max
}
```

To write our BDD-style test, we take advantage of the [`Run` method exposed by the `T`](https://pkg.go.dev/testing#T.Run "View the Go documentation for the T.Run method") struct. It allows us to spawn a new test, a subtest. The behavior is similar to that of `it` in Jest.

```go
package math

import (
	"testing"

	"github.com/stretchr/testify/require"
)

func TestSumOrMax(t *testing.T) {
	t.Run("when the sum is below the maximum", func(t *testing.T) {
		a := 1
		b := 2
		max := 4

		want := 3

		have := SumOrMax(a, b, max)

		require.Equal(t, want, have, "should return the sum")
	})

	t.Run("when the sum is at or above the maximum", func(t *testing.T) {
		a := 5
		b := 10
		max := 4

		want := max

		have := SumOrMax(a, b, max)

		require.Equal(t, want, have, "should return the maximum")
	})
}
```

For every `describe` block in the JavaScript test suite, we introduce a call to `t.Run`. For the description of the `it` blocks we pass a description of the expected behavior to the assertion call. Most of Testify’s assertions support that extra `msgAndArgs` parameter.

## Testing Many Scenarios With Table-Driven Tests

Especially in unit tests we may want to test a given function for many different inputs. In such cases, table-driven tests are an efficient approach allowing us to test many scenarios without duplicating test logic.

Let us try table-driven tests with a `fib` function, which returns the nth number in the [Fibonacci series](https://en.wikipedia.org/wiki/Fibonacci_number "Wikipedia page for the Fibonacci number").[^3] Our JavaScript implementation looks as follows.

```js
export function fib(n) {
 if (n < 2) {
 return n;
 }

 return fib(n - 1) + fib(n - 2);
}
```

In [Jest, we implement a table-driven](https://jestjs.io/docs/en/api#testeachtablename-fn-timeout "Jest documentation on table driven tests") test as follows.

```js
import { fib } from './fib';

describe('fib', () => {
 it.each([
 [0, 0],
 [1, 1],
 [2, 1],
 [3, 2],
 [4, 3],
 [5, 5],
 [6, 8],
 [7, 13],
 [8, 21],
 ])('fib(%i) should be %i', (n, want) => {
 const have = fib(n);

 expect(have).toBe(want);
 });
});
```

In case you are not familiar with how table tests in Jest work, I will walk you through it.

1. In our call to `each()` we pass the _test table_. This is a nested array where every element is a test case. Each test case consists of function parameters and the expected value. You may order these as you like as the values are just forwarded in order.
2. In the chained call to the return value of `each()` we pass a description of the test and a function to run the test. The description is a template string, where the test case values can be rendered using `printf` format. The test function receives the values of our test case as arguments.
3. In our test function we run assertions just like we would in a normal `it()` test.

Jest will run every test case and show a nice report of the successes and failures.

The Go implementation, `Fib` looks as follows.

```go
package math

func Fib(n int) int {
	if n < 2 {
		return n
	}

	return Fib(n-1) + Fib(n-2)
}
```

To create the same table-driven test as we did for the JavaScript version we will use `t.Run`, just like we did in our subtests.

```go
package math

import (
	"fmt"
	"testing"

	"github.com/stretchr/testify/require"
)

func TestFib(t *testing.T) {
	require := require.New(t)

	tc := []struct {
		n int
		want int
	}{
		{0, 0},
		{1, 1},
		{2, 1},
		{3, 2},
		{4, 3},
		{5, 5},
		{6, 8},
		{7, 13},
		{8, 21},
	}

	for _, tt := range tc {
		name := fmt.Sprintf("fib(%d) should be %d", tt.n, tt.want)

		t.Run(name, func(t *testing.T) {
			require.Equal(tt.want, Fib(tt.n))
		})
	}
}
```

There is no test framework magic involved here.

1. We create a table for our test cases, `tc`, as a slice using an inline struct type for the values.
2. We iterate over the test cases in a [`for` loop using the range expression](https://gobyexample.com/range "Go by Example documentation page for range").
3. Finally, we create a name for the subtest and run the test using testify for assertions.

And that is it, we have successfully tested `Fib` for many inputs.

## Conclusion

In this post we have learned how to write tests for simple Go functions. These functions were simple in the sense that they were pure: the same inputs lead to the same output with no other side effects.

Testing a function is straightforward with Go’s standard library — you just write Go, no frameworks needed. Libraries like Testify help a lot by reducing the effort you have to put into your assertions. Subtests allow you to structure your test cases in a BDD style manner. Finally, table-driven tests make it easy to handle many test cases with very little code.

Things will get a bit more difficult when you need to deal with dependencies, such as databases. For example, if your function queries a database, you will not necessarily want to have that database running for a unit test. In a future post we will look at how interfaces and mocks can help us with this problem.

[^1]:	Incidentally, this is the same example the Jest folks [use on their website](https://jestjs.io/docs/en/getting-started "Go to the Jest Getting Started guide"). 🤷‍♂️

[^2]:	I would recommend using the official [GoMock framework](https://github.com/golang/mock "GoMock GitHub repository") over using Testify’s mocking feature.

[^3]:	This example is shamelessly taken from [Dave Cheney’s very helpful and always interesting blog](https://dave.cheney.net/2013/06/09/writing-table-driven-tests-in-go "Dave Cheney — Writing table driven tests in Go").

Tests are important for many reasons. Knowing your software behaves as expected, safely making changes in an unfamiliar codebase, or documenting the behavior of business logic are just a few reasons to write tests. In contrast to JavaScript, Go ships with great testing capabilities as part of the standard library. In this post we learn the basics of how to leverage them.

JS to Go: Writing Basic Tests in Go

> I have been working with Go in a service-oriented architecture over the past year and a half. It has been a fun ride after years of working with and enjoying JavaScript. This post is part of a series in which I attempt to make my learnings accessible to other engineers with a JavaScript background. Huge thanks go to my dear colleague [Tom Arrell](https://tomarrell.com "Tom's website") who has taught me most of the things I now know about Go.

In object-oriented programming languages, interfaces are abstract types 
allowing developers to define a set of behaviors that a concrete type, such as a struct or class type, needs to exhibit to be used in a given context.

JavaScript has no concept of interfaces, which is not surprising because JavaScript also does not have a strong static type system. 🙃 If you are familiar with TypeScript you are likely to have come across interfaces, for example to describe the props of a React component. Interfaces in TypeScript are mighty and cover many of the different objects present in JavaScript: object literals, function types, indexable types, and classes.[^1] Typescript interfaces can also be implemented both implicitly and explicitly as shown below.

```ts
interface User {
  email: string;
}

// The object literal foo implicitly implements the User interface.
const foo = {
  email: 'foo@bar.com',
  firstName: 'Foo',
  lastName: 'Bar',
}

// Class SuperUser explicitly implements the User interface by
// declaring so with the 'implements' keyword.
class SuperUser implements User {
  email: string
  permissions: string

  constructor(email: string, permissions: string) {
    this.email = email
    this.permissions = permissions
  }
}
```

The [TypeScript handbook page on interfaces](https://www.typescriptlang.org/docs/handbook/interfaces.html "TypeScript Handbook — Interfaces") has a pretty extensive rundown of how the language supports them. For this post, the above explanations should suffice.

In Go, interfaces are much simpler than in TypeScript, but still incredibly powerful. [Jordan Orelli’s blog post “How to use interfaces in Go”](https://jordanorelli.com/post/32665860244/how-to-use-interfaces-in-go "Jordan Orelli — How to use interfaces in Go") covers a lot of the technical details and intricacies you may run into when working with interfaces in Go. Broadly speaking, interfaces in Go are a named set of methods. Interfaces are implemented implicitly. That is to say, if a given type implements all methods defined by an interface, it implements the interface. Let’s take a look at an example.

## A `UserStorage` Interface Example in Go

Consider the example of a user web service. Such a service could provide a CRUD API for users and depend on some storage mechanism supporting the required Create, Read, Update, and Delete operations. As developers, we do not necessarily care about _how_ these operations are implemented. In fact, we might want to postpone dealing with their concrete implementation until we have a better idea of what the usage patterns will look like.[^2] In such cases — and for other reasons like testing — we introduce an interface, like the `UserStorage` Go interface below.

```go
// User is a struct type for a user in the system. The ID is a UUID and
// stored as a string.
type User struct {
	ID        string
	FirstName string
	LastName  string
	Email     string
}

// UserStorage provides methods for creating, reading, updating, and deleting
// users in a storage dependency like a database or a file system.
type UserStorage interface {
	Create(user User) error
	Read(userID string) (User, error)
	Update(user User) (User, error)
	Delete(userID string) (User, error)
}
```

`UserStorage` describes all the behaviors we expect a dependency to implement so that we can provide a basic CRUD API in our user service. Let’s create a `Server` struct in a new `server` package with a handler for the create operation of our users API.

```go
package server

import (
	"net/http"

	"github.com/gorilla/mux"
)

// User is a struct type for a user in the system. The ID is a UUID and
// stored as a string.
type User struct {
	ID        string
	FirstName string
	LastName  string
	Email     string
}

// UserStorage provides methods for creating, reading, updating, and deleting
// users in a storage dependency like a database or a file system.
type UserStorage interface {
	Create(user User) error
	Read(userID string) (User, error)
	Update(user User) (User, error)
	Delete(userID string) (User, error)
}

type Server struct {
	s      *http.Server
	Router *mux.Router
	us     UserStorage
}

func NewServer(s *http.Server, us UserStorage, r *mux.Router) *Server {
	return &Server{s, r, us}
}

func (s *Server) Listen() error {
	return s.s.ListenAndServe()
}

// createUserHandler returns the http.handlerFunc for the createUser operation.
// By creating a closure, the HandlerFunc has access to the server and thereby
// our UserStorage.
func (s *Server) CreateUserHandler() http.HandlerFunc {
	return func(w http.ResponseWriter, r *http.Request) {
		// Process the request and write to the user. Here we use a dummy.
		routeParams := mux.Vars(r)
		// TODO: verify id route param.
		u := User{
			ID: routeParams["id"],
		}
		if err := s.us.Create(u); err != nil {
			// TODO: handle errors.
		}
		// TODO: write response.
	}
}
```

As you can see we are able to write the code for a server without having considered the dependency we want to use to store our user data. Only when we initialize our server in `main()`, we will have to instantiate and pass an actual dependency which implements the `UserStorage` interface.[^3] However, this dependency could write and read users from JSON files in the local file system or from a Postgres database; it does not matter.

If we decide to use a Postgres database as storage for our user data, we implement the `UserStorage` interface with a `DB` struct in a `postgres` package.

```go
package postgres

import (
	"context"
	"fmt"

	"github.com/felixjung/blog-post/go-interfaces/example-code/server"
	"github.com/jackc/pgx/v4"
)

type DB struct {
	conn *pgx.Conn
}

func NewDB(config *pgx.ConnConfig) (*DB, error) {
	conn, err := pgx.ConnectConfig(context.Background(), config)
	if err != nil {
		return nil, fmt.Errorf("failed to connect to postgres: %v", err)
	}

	return &DB{conn}, nil
}

func (db *DB) Create(u server.User) error {
	// TODO: Create the user in postgres
	return nil
}

func (db *DB) Read(userID string) (server.User, error) {
	// TODO: Read the user from postgres
	return server.User{}, nil
}

func (db *DB) Update(u server.User) (server.User, error) {
	// TODO: Update the user in postgres.
	return server.User{}, nil
}

func (db *DB) Delete(userID string) (server.User, error) {
	// TODO: Delete the user in postgres.
	return server.User{}, nil
}
```

The `DB` struct has all the methods defined in the method set of our `UserStorage` interface. It therefore implements `UserStorage` and can be used with our server as shown in the continued example below.

```go
package main

import (
	"log"
	"net/http"

	"github.com/felixjung/blog-post/go-interfaces/example-code/postgres"
	"github.com/felixjung/blog-post/go-interfaces/example-code/server"
	"github.com/gorilla/mux"
	"github.com/jackc/pgx/v4"
)

func main() {
	host := ":8080"
	apiRoot := "/api"
	// FIXME: pass an actual config with valid values here. This currently does
	// not run.
	db, err := postgres.NewDB(&pgx.ConnConfig{})
	if err != nil {
		log.Fatalf("failed to connect to postgres DB: %v", err)
	}

	// Create our server.
	srv := server.NewServer(
		&http.Server{Addr: host},
		// postgres.DB implements user.UserStorage so we can use it here. 🙌
		db,
		mux.NewRouter().PathPrefix(apiRoot).Subrouter(),
	)

	// Register the createUser route handler. It would work the same for other
	// handlers.
	srv.Router.
		Path("/users").
		Methods("POST").
		HandlerFunc(srv.CreateUserHandler())

	// Start the server and listen for connections.
	if err := srv.Listen(); err != nil {
		log.Fatalf("failed to start or run server: %v", err)
	}
}
```

In the above code we have successfully introduced a `UserStorage` interface to separate the concerns of our users CRUD API and the dependency used to persist and read user data.

## Benefits of using Interfaces in Go

Leveraging interfaces in your Go code has several benefits. These two stand out for me.

1. By using an interface we have a much easier time testing our application business logic, for example in the route handlers, without having to run tests against an actual database. A tool like [GoMock](https://github.com/golang/mock "GoMock mocking framework on GitHub") will generate mocks for the interfaces in our code. In the above example, we would generate a mock for the `UserStorage` interface. The generated mock will be called something like `MockUserStorage`. `MockUserStorage` will implement the `UserStorage` interface so we can use it when instantiating our `server` struct in unit tests. Mocks generated by GoMock expose an `EXPECT()` method through which we can set expectations on the interface’s methods. For example, we can set the expectation that `CreateUser()` will be called by the `createUserHandler` `HandlerFunc`. We get fast unit tests that allow us to develop our handler in a test-driven way. Testing and using mocks will be the topic of another blog post.
2. We can postpone the decision for a specific storage layer until we know exactly what our requirements for that layer are. In the early stages of our project this means we can choose not to implement the storage layer at all and focus on something like the validation logic in our connection handlers. After that we could take things a step further with a prototype and implement the `UserStorage` interface with a simple NoSQL database. This would allow us to postpone decisions regarding the database schema. Once our schema stabilizes and we feel the need to work with a relational database, we may move on to something like our `postgres` package above. Our interface draws a nice architectural boundary that we can take advantage of.

##  My Top 3 Learnings from Using Interfaces in Go

1. **Define interfaces where you use them.** Doing so will allow you to keep them as narrow as you need them to be for the specific use case (i.e., interfaces will only include methods needed in the code that depends on them). It is much easier to reason about a narrow interface than a very wide one, for example when setting expectations against mocks in your tests. Having many narrow interfaces also helps with breaking up monolithic dependencies. Say for example your application relies on a NoSQL database for storage. In addition to the `User` model above, you have an `Order`, a `Product`, and a `Transaction` model. At some point you realize that  you are performing a lot of queries to fetch a list of users together with their orders and the respective product information. You come to the conclusion that a relational database would be better suited to handle these kinds of queries. With your NoSQL dependency, you had a `mongo` package exposing a `MongoDB` struct, which implemented the `UserStorage`, `OrderStorage`, `ProductStorage`, and `TransactionStorage` interfaces used in different parts of your code base. You could inject the same struct in all those places. Because of the implicit implementation of Go interfaces, all you need to do now to switch to a relational database is to create a new `postgres` package with a `PostgresDB` struct implementing the `UserStorage`, `OrderStorage`, and `ProductStorage` interfaces. You will then inject an instances of `PostgresDB` where you previously used an instance of `MongoDB` for these three interfaces. To take advantage of your new relational database, you can now create a new specialized interface to handle your more complex queries and implement that on `PostgresDB`.
2. **Create One Package for Every Dependency Implementation.** Every implementation of an interface should have its own package. By isolating dependencies, especially external dependencies like databases or message brokers, you are also able to test them in isolation. For example, a `postgres` package will contain all the methods for interacting with a Postgres database. You can unit-test those methods very efficiently using a library like [Dockertest](https://github.com/ory/dockertest "GitHub repository of the Dockertest library").
3. **Mock your interfaces with GoMock for great unit test performance.** I have already mentioned GoMock, but I would really like to stress how useful it is when writing unit tests. Use your mocks in tests. Every time you update an interface, regenerate the mocks.

## Conclusion

And that is it. JavaScript does not have interfaces. However, that does not mean you should be afraid of them when picking up Go. With a little bit of practice they will become your ally in building simple and maintainable applications. You can find the [source code for the above Go example on GitHub](https://github.com/felixjung/blog-posts/tree/main/posts/go-interfaces/example-code "Go user service example code on GitHub").

[^1]:	Remember that in JavaScript [almost everything is an object](https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Objects/Basics "MDN web docs — JavaScript object basics").

[^2]:	In his classic book, “Clean Architecture”, Robert C. Martin deals with these ideas in Part V on Architecture.

[^3]:	Tip of the hat to Mat Ryer for the [pattern of creating route handler closures on the server](https://pace.dev/blog/2018/05/09/how-I-write-http-services-after-eight-years.html "Mat Ryer — How I write HTTP services after eight years.") struct.

Unlike JavaScript, Go has interfaces. Interfaces are a huge help in building maintainable software. In this post I share what I learned about leveraging Go interfaces effectively in the past one and a half years of using the language in a service-oriented architecture.

JS to Go: Interfaces

On November 27th, [Mitchell Hamilton](https://twitter.com/mitchellhamiltn)
announced the release of Emotion 10
[in a blog post](https://medium.com/emotion-js/announcing-emotion-10-f1a4b17b8ccd).
The new version comes with a lot of changes, a new API, and new packages. I
encourage you to read the post and check out
[the documentation](https://emotion.sh/docs/@emotion/core).

One of the biggest changes coming in this new version of Emotion is how the
`css` prop works, both, on the API level and under the hood. In this post, I am
going into detail on how the `css` prop works in Emotion 10.

## The `css` prop in previous versions of Emotion

Like the standard `styles` prop supported by React, Emotion’s `css` prop has
always allowed you to apply styles directly to your components or elements. For
example, the following code would produce a paragraph with red text containing a
`span` with blue text.

```jsx
import { css } from 'react-emotion';

const MyComponent = () => (
 
 I have red text. And some{' '}
 
 blue
 {' '}
 text.
 
);
```

Notice how we are using object and string styles. The string styles use
Emotion’s `css` function as a tagged template literal.

In order for this syntax to work, previous versions of Emotion required you to
use the [Emotion Babel plugin](#). The plugin transpiles the `css` prop to a
`className` prop whose value is a unique Emotion-generated CSS class name — a
string. And all CSS classes for your component are part of a stylesheet that
gets injected into the DOM at runtime.

Mitchell mentions some of the problems of the old implementation in the Emotion
10 blog post.

> - It required a babel plugin
> - It was not compatible with spreading an object as props
> - Style composition order was confusing, undocumented and could break

On top of these, one problem I always faced was the lack of support for theming.
If you used the `emotion-theming` package to pass down a theme via the
`ThemeProvider` component, you had to wrap your component in the `withTheme`
[higher-order component (HOC)](https://reactjs.org/docs/higher-order-components.html),
to use the theme in your styles.

```jsx
import { css } from 'react-emotion';
import { withTheme } from 'emotion-theming';

const MyComponent = ({ theme }) => (
 
 I have red text. And some{' '}
 
 blue
 {' '}
 text.
 
);

export default withTheme(MyComponent);
```

Emotion 10 addresses all of the above issues.

## Enabling the `css` prop in Emotion 10

You now have two ways of enabling the `css` prop in your React code. The first
is to use the Babel plugin, just like in previous versions. However, this can be
problematic in contexts where you do not want to or are unable to set up a
custom Babel configuration. For example, you might be using
[create-react-app](https://facebook.github.io/create-react-app/) or
[CodeSandbox](https://codesandbox.io).

In those cases you can now resort to using Babel’s
[`jsx` pragma](https://babeljs.io/docs/en/babel-plugin-transform-react-jsx#pragma).
Use what? When I first read this in the Emotion 10 docs, I did not understand at
all what this meant and when or how I should use it. So here is what I learned
since.

Babel’s React JSX plugin has an option to specify the function it uses to
transpile JSX expressions. The plugin defaults to using `React.createElement`.
But by relying on `React.createElement`, you can only use syntax, such as props,
supported by `React.createElement`. So, if you provide a different function to
transpile JSX, you can support a different syntax.💡

Here is how you do this with Emotion 10.

```jsx
/** @jsx jsx */

import { css, jsx } from '@emotion/core';

const MyComponent = () => (
 
 I have red text. And some{' '}
 
 blue
 {' '}
 text.
 
);
```

In the above example, we use the `jsx` pragma (`/** @jsx jsx */`) to tell Babel
it should use the `jsx` function imported from `@emotion/core` to transpile JSX.
And that is all you need to do to use the `css` prop. You do not need Emotion’s
Babel plugin.

### When to use the `jsx` pragma

Initially, I got somewhat confused about when I should use import the `jsx`
function and when to import `React`. ESLint would complain about unused `jsx` or
`React` imports. So should I use `jsx` everywhere for the sake of consistency?
The answer to this is a simple: “No”!

Importing React in a component is not an actual module import. It merely tells
Babel that your JavaScript module contains JSX, which should be transpired using
the React JSX plugin (i.e., with `React.createElement`). Using the `jsx` pragma
allows you to opt into the `css` prop on a per component basis, by changing the
way that component’s file is transpiled by Babel. You only need to specify the
pragma, if you use the `css` prop in your component’s JSX. Otherwise, just keep
importing `React`. You will definitely keep importing `React`, if your component
uses something like `React.memo`, `React.Fragment`, `React.useState`, etc.

If you are using the Emotion Babel plugin, you do not need to use the pragma at
all.

## How to use the `css` prop

You can still use the `css` prop as in previous versions of Emotion. The example
from above will still work.

```jsx
/** @jsx jsx */

import { css, jsx } from '@emotion/core’;

const MyComponent = () => (
 
 I have red text. And some{' '}
 
 blue
 {' '}
 text.
 
);
```

The styles will be evaluated and stored in Emotion’s cache under a class name.
The class name is passed down to the React element through the `className`
property. So far, so good.

One great improvement over previous versions is that you now have direct access
to the theme context created by a `ThemeProvider`!

```jsx
/** @jsx jsx */

import { css, jsx } from '@emotion/core';
import { ThemeProvider } from 'emotion-theming';

const theme = {
 colors: {
 brandRed: 'red',
 brandBlue: 'blue'
 }
};

const MyComponent = () => (
 ({ color: theme.colors.brandRed })}>
 I have red text. And some{' '}
 
 css`
 color: ${theme.colors.brandBlue};
 `
 }
 >
 blue
 {' '}
 text.
 
);

const App = () => (
 <ThemeProvider theme={theme}>
 <MyComponent />
 </ThemeProvider>
);
```

This is extremely powerful. Yes, some people might argue that having all these
“inline” styles does not help with readability. I would tend to agree. However,
styling an element inline every now and then, without having to wrap your
component in a HOC or having to create a
[styled-component](https://emotion.sh/docs/styled), _is_ extremely useful.

## Conclusion

For me, the `css` prop has become a whole different animal with Emotion 10.
Being able to use it without a Babel plugin is great when putting together a
quick example in CodeSandbox or working with create-react-app. Having access to
your application’s theme is invaluable when making smaller adjustments to
existing components. Style composition with the `css` prop has also improved a
lot with Emotion 10. The documentation on that is pretty great, so make sure to
[take a look](https://emotion.sh/docs/css-prop#style-precedence).

Much has been said and written about the current state of Apple over the past weeks, months, and even years. Things are not perfect, but there are not enough reasons to switch.

The css Prop in Emotion 10

In a previous post I wrote about customizing iTerm2's titlebar to match your
current theme. This provided a pretty neat visual upgrade and brought the user
experience closer to that of the all hyped and very beautiful Hyper terminal
emulator bei Zeit.co.

Unfortunately,
[an API change in macOS High Sierra](https://gitlab.com/gnachman/iterm2/issues/4080#note_43758478)
stopped the titlebar customization from working.
[The author of iTerm2 had promised](https://gitlab.com/gnachman/iterm2/issues/4080#note_64566741)
to work on changes bringing the feature back, but for a long time nothing seemed
to happen.
[That has changed now](https://gitlab.com/gnachman/iterm2/issues/4080#note_93855327).

A new combination of features and settings in iTerm2's nightly build allows you
to configure the most beautiful terminal on macOS, yet. You will need to be on
macOS Mojave to be able to do so.

![iTerm2 final setup](https://felixjung.imgix.net/iterm2-final.jpg 'Screenshot of iTerm2 window')

Here are the steps you need to take to get to this set up.

1. **Upgrade to macOS Mojave, if you have not already.** The upgrade went
   flawlessly for me and I have seen only positive reports online. To get
   started, open the App Store on your Mac, download the macOS Mojave installer,
   and follow the instructions.
2. **Install the iTerm2 nightly build.** I usually run the nightly on my
   systems. It is great and rarely causes problems.
3. **Set the iTerm2 theme to _Minimal_.** Go to _Settings_, select the
   _Appearance_ tab, and choose _Minimal_ from the _Theme_ dropdown.
4. **Set your Profile's window style to _Compact_.** In the _Settings_ go to the
   _Profiles_ tab, choose _Window_, and in the _Settings for New Windows_
   section select _Compact_ from the _Style_ dropdown.
5. **Open a new terminal window.**

At this point, the new terminal window should look fairly similar to the above
screenshot, matching your current theme. There are some additional _Advanced_
settings of iTerm2, that you can tweak to get even closer or adjust things to
your liking. Here's how I have set them.

![iTerm2 final setup advanced settings.](https://felixjung.imgix.net/iterm2-advanced-settings.jpg 'Screenshot of iTerm2 advanced settings')

That's it! 🎉 Enjoy an amazingly beautiful terminal experience for endless
developer Zen. Looking at the
[issue on Gitlab](https://gitlab.com/gnachman/iterm2/issues/4080), this feature
is not done yet and the experience might get even better. So stay tuned! Thanks
so much to George Nachman for making such a great terminal emulator.

New features in iTerm2 under Mojave allow configuring a beautiful titlebar with integrated tabs, matching theme colors, and more. It is the prettiest it has ever been.

Pretty iTerm2 With a Modern Titlebar 💄💅

I recently started working on a lot of mostly presentational React components in
a project at work. These components are created with the
[👩‍🎤 emotion](https://emotion.sh)
[`styled` function](https://emotion.sh/docs/styled). `styled` mirrors more or
less how [styled-components](https://www.styled-components.com) and
[glamorous](https://glamorous.rocks) work. Instead of writing out a functional
React component and adding styling to it, like this,

```js
import React from 'react';
import classNames from 'classnames';

// We wrote some BEM classes in a CSS file.
import './Input.css';

const Input = ({ disabled, isInvalid, ...props }) => {
 const className = classNames('input', {
 'input--disabled': disabled,
 'input--invalid': isInvalid
 });
 return <input {...{ disabled, className, ...props }} />;
};

export default Input;
```

you end up writing this

```js
import styled, { css } from 'react-emotion';

const modifierDisabled = ({ disabled }) =>
 disabled &&
 css`
 pointer-events: none;
 opacity: 0.4;
 `;

const modifierInvalid = ({ isInvalid }) =>
 isInvalid &&
 css`
 pointer-events: none;
 opacity: 0.5;
 border-color: red;
 color: lightcoral;
 `;

const StyledInput = styled('input')`
 border-radius: 3px;
 border: 1px solid #999;
 font-size: 16px;
 padding: 8px 12px;

 &:focus,
 &:active {
 outline: none;
 }

 ${modifierDisabled} ${modifierInvalid};
`;

export default StyledInput;
```

Notice how pretty much all of this file has become styles? If you boil the code
down to the "actual" JavaScript, you get this:

```js
import styled, { css } from 'react-emotion';

const modifierDisabled = ({ disabled }) => disabled && css``;
const modifierInvalid = ({ isInvalid }) => isInvalid && css``;

const StyledInput = styled('input')`
 ${modifierDisabled}
 ${modifierInvalid}
`;

export default StyledInput;
```

Personally, I find this very refreshing. If your component does not need logic,
apart from "dynamic styles" (more on that later), you end up writing next to no
code!

- You don't import your styles.
- You don't have to write a function for your component.
- You don't need to determine the classes you want to apply to your component
 with something like the classnames module.

It feels very productive. But what exactly is going on here?

## The `styled` and `css` Functions

The `styled` function is what creates your component. You pass in the
component's style either via a tagged template literal or as arguments to a
function call.

```js
// Tagged template literal usage
const StyledInput = styled('input')`
 color: black;
`;

// Function usage with object styles
const StyledInput = styled('input')({ color: 'black' });
```

Emotion will create a class for your component and inject the stylesheet into
the DOM.

In the examples further up, you've seen the [`css`](https://emotion.sh/docs/css)
function. This function, like [`styled`](https://emotion.sh/docs/css), can also
be used with tagged template literals and
[object styles](https://emotion.sh/docs/object-styles). It can also take an
array of objects, composing them into a single stylesheet. The function returns
a class name, which you can then use either in a regular React component (i.e.,
without `styled`) or inside another `styled` or `css` call. The latter is what
we refer to as the _composition pattern_ in Emotion.

```js
const fontStyles = css`
 font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto;
 font-size: 12px;
 line-height: 1.2;
`;

const colorStyles = css`
 background-color: blue;
 color: yellow;
`;

// As tagged template literal
const MyDiv = styled('div')`
 ${fontStyles}
 ${colorStyles}
`;

// In a function call
const MyDiv = styled('div')(fontStyles, colorStyles);
```

Emotion will create three class names here. One for `fontStyles` , one for
`colorStyles`, and finally another third class name for the `MyDiv` component.
For the styles of `MyDiv` emotion will merge `fontStyles` and `colorStyles` and
also take care of specificity for us.

This is a very powerful pattern, allowing you to create and re-use styles
throughout your components. We will see how to leverage composition even more to
create modifier styles for our components in the next section.

## Dynamic Styles

In the first example of using `styled` above, you see how style functions are
passed to the `StyledInput` component. These functions receive an object
parameter, which is destructured into variables. The variables are then used to
determine whether to return styles or not. For example,

```js
const modifierDisabled = ({ disabled }) =>
 disabled &&
 css`
 pointer-events: none;
 opacity: 0.4;
 `;
const StyledInput = styled('input')`
 // Base styles
 ${modifierDisabled}
`;
```

What is happening here, is that Emotion calls every style function passed to a
styled component, passing in the component's props. The style function then uses
the props to calculate _dynamic styles_. This way we can compose multiple
dynamic modifier styles of our component into one rendered style.

## Conclusion

Emotion's styled components — or those from styled-components and glamorous —
enable simple yet powerful creation of presentational React components. This is
facilitated by _dynamic styles_ and _composition_.

In this post, I have used the way I've come to write styled components, with

- a styled component that has base styles
- and modifier functions that call `css`.

However, Emotion is flexible and very permissive in how you can use it. You may
continue to write full BEM compliant stylesheets or put all your dynamic styles
into the main `styled` call. This
[issue on the Emotion repository](https://github.com/emotion-js/emotion/issues/381)
discusses different approaches. Emotion is also compatible with a lot of tools
from the large styled-components ecosystem. You can, for example, use the
[polished "mixin" library](https://polished.js.org). It also offers a bunch of
ecosystem packages of its own. There is a very refreshing approach to media
queries, called [facepaint](https://emotion.sh/docs/media-queries#facepaint).
You can use the [ThemeProvider pattern](https://emotion.sh/docs/theming). There
are [testing utilities for Jest](https://emotion.sh/docs/jest-emotion), that
help snapshotting your styles. And so much more. Take a look at the
[very nice documentation](https://emotion.sh/docs) and dive in (it lets you
_edit examples in the docs_)! Finally, here is a
[CodeSandbox with the input example](https://codesandbox.io/s/6v6y9qxw1w) from
this post. Check it out.

Writing presentational React components often requires more code than it should. Styled components with Emotion let you focus on the presentation alone, leveraging dynamic styles and composition.

Presentational React Components — the 👩‍🎤emotion Way

If you are like me, you get pretty obsessed about the look and feel of your
development environment. It’s such a productivity waste, but I am a sucker for
nice looking apps. After all, as a dev, you look at this stuff all day.

Over the past years, Electron apps have become all the rage. If you look at a
typical JavaScript dev’s development environment these days, you will probably
notice them running either [Atom](https://atom.io) or
[Visual Studio Code](https://code.visualstudio.com) (VSCode) for their editor
and [Hyper](https://hyper.is) for their terminal emulator. In particular VS Code
seems to have become the default editor for most. Personally, I do not really
like the look of VS Code. Yes, it has made a lot of progress and there are some
cool themes, but to me, it still really looks like a Microsoft product. At least
as soon as you start digging a level deeper. Atom and Hyper on the other hand,
not so much. Look at these two beautiful apps next to each other. They are
🔥🔥🔥🔥.

![Atom on the left, Hyper on the right. Two beautiful Electron apps.](https://felixjung.imgix.net/atom-and-iterm.jpg 'Screenshot showing the Atom text editor and an iTerm2 window next to each other.')

Sadly, though, I cannot get myself to use these apps for work. I am used to
[Neovim](https://neovim.io)/Vim and Atom’s model for splits is way too
different. It just does not feel right. And while Hyper is beautiful and its
plugin system rocks, as soon as I try to run Vim in it, I start noticing all
kinds of performance related glitches and lag. On top of all of that, these
Electron apps just take too much of my system’s resources. Today, I noticed Atom
causing 150% CPU load when I was scrolling its settings screen. _Scrolling_.
Both apps regularly take up gigabytes of memory.

So, I am stuck with my iTerm2, tmux, Neovim combo, which is not easy to get to
look really nice. With enough patience and determination, I think I ended up
with a nicely looking setup (getting theme colors to work has become a lot
easier thanks to [True Color](https://gist.github.com/XVilka/8346728) support
across the stack). You be the judge.

![Neovim on the left, terminal on the right, all running inside a tmux session in iTerm2.](https://felixjung.imgix.net/neovim-and-prompt.jpg)

However, one thing that always bothered me was iTerm’s grey titlebar. In the
nightly builds, George Nachman has added support for macOS’ dark mode for the
titlebar. This is nice, but still does not look as beautiful as Hyper.

![iTerm2 with dark titlebar left, Hyper on the right.](https://felixjung.imgix.net/neovim-and-prompt.jpg)

Recently, I finally — by accident — found a solution to this problem. 🎉 Turns
out, iTerm2 supports some
[proprietary escape codes](https://www.iterm2.com/documentation-escape-codes.html)
for overwriting certain settings. And yes, there are codes to change the
titlebar background color!

Here is how to set the titlebar color to the background of the
[iTerm2 One Dark](https://github.com/joshdick/onedark.vim/blob/master/term/One%20Dark.itermcolors)
theme I am using. Type the following into your iTerm2 terminal.

```bash
$ echo -e "\033]6;1;bg;red;brightness;40\a"
$ echo -e "\033]6;1;bg;green;brightness;44\a"
$ echo -e "\033]6;1;bg;blue;brightness;52\a"
```

This is what it looks like.

![iTerm2 with custom titlebar background.](https://felixjung.imgix.net/iterm-custom-titlebar.jpg)

Finally. iTerm will not save this to your settings. The solution is to
automatically execute the above commands when launching a new session. Just add
them to your .bashrc or .zshrc, etc.

Make your iTerm2 setup look as beautiful as Hyper. iTerm2 supports proprietary escape codes to achieve just that. Read the story to find out how they work.

Custom iTerm2 Titlebar Background Colors

About a month ago, Facebook announced [Prepack](https://prepack.io), a build tool that optimizes JavaScript for faster runtime execution. It does so by replacing any computations known at “compile time” with their result. Here’s an example from the Prepack webiste:

```js
// Input
(function () {
  function hello() { return 'hello'; }
  function world() { return 'world'; }
  global.s = hello() + ' ' + world();
})();

// Output
(function () {
  s = "hello world";
})();
```

Prepack still has a very long way to go before becoming production-ready for your average single-page application code. For example, at the moment, it is completely unaware of its environment. In the browser, document and window would evaluate to undefined, if you do not provide what the Prepack folks call a “model”.

However, that did not stop my colleagues at [@SumUpEng](https://twitter.com/sumupeng) and myself from taking Prepack for a spin in our Dashboard application — just to see what it would do in terms of performance.

### Setting up Prepack with webpack 2

Turns out, there is a [webpack 2 plugin](https://github.com/gajus/prepack-webpack-plugin) that came out shortly after Prepack was announced. All you have to do is to instantiate the plugin with a configuration object (possibly empty) and add it to the plugins property of your webpack config.

```js
import PrepackWebpackPlugin from ‘prepack-webpack-plugin’;

module.exports = (env) => ({
  // ...
  plugins: [
    new PrepackWebpackPlugin({})
  ]
});
```

One thing to note is that this plugin [will not work properly](https://github.com/gajus/prepack-webpack-plugin/issues/11) when you run it after the UglifyJS plugin. So make sure to position it before UglifyJS in the plugins array.

### What we learned

After doing some *very* casual tests loading a build of the Dashboard without and one with the Prepack webpack plugin, I was somewhat surprised. The overall size of the application had gone from 4.9MB for 5MB. Say what? I thought this was supposed to optimize our app? Why did it get bigger?

Luckily, my colleagues and I were at [@jsconfeu](https://twitter.com/jsconfeu?lang=en) when we made this experiment. So I walked over to Facebook’s [Christoph Pojer](https://twitter.com/cpojer) and some of his fellow engineers to figure out what was going on. And while these guys do not work on Prepack, they were quick to help me overcome some misconceptions I had.

Being a tool for optimizing runtime performance, Prepack does not care about file size! The only thing it should care about is making the code run faster inside the JavaScript VM. This means: simple instructions (i.e. a lot of simple assignments) and — in some cases — long computation results instead of the original computation code. Here is an example where Prepack will create significantly more code. You can go to the [interactive repl](https://prepack.io/repl.html) on prepack.io to try it out live.

```js
/**
 * Input @ 262 characters, measured by running
 * `wc -c prepack-example.js`.
 **/

const names = [
  'Han', 'Leia', 'Luke', 'Obi-Wan',
  'Anakin', 'Jyn', 'Rey', 'Finn'
]

function sayHello(name) {
  return `Hello ${name}! It is very nice to meet you. How are you doing?`
}

const greetAll = names.map(sayHello).join('\n')

console.log(greetAll)

/*
 * Prepack output @ 663 characters, measured by running
 *
 * prepack hello-star-wars.js \
 *   --out hello-star-wars-prepacked.js \
 *   && wc -c hello-star-wars-prepacked.js
 *
 **/

var sayHello;

(function () {
  function _0(name) {
    return `Hello ${name}! It is very nice to meet you. How are you doing?`;
  }

sayHello = _0;
  console.log("Hello Han! It is very nice to meet you. How are you doing?\nHello Leia! It is very nice to meet you. How are you doing?\nHello Luke! It is very nice to meet you. How are you doing?\nHello Obi-Wan! It is very nice to meet you. How are you doing?\nHello Anakin! It is very nice to meet you. How are you doing?\nHello Jyn! It is very nice to meet you. How are you doing?\nHello Rey! It is very nice to meet you. How are you doing?\nHello Finn! It is very nice to meet you. How are you doing?");
})();
```

Optimizing the example code using Prepack, we end up with a wooping **663** characters instead of the original 262.

> The time the VM spends parsing your bundle before anything happens seems like a big topic right now.

What does this mean for your application? Should you use Prepack or not, once it becomes ready for production? The answer will probably end up being: “it depends”. At least that’s what the conversation with [Christoph Pojer](https://twitter.com/cpojer) and colleagues came down to.

Here is why. The size of your bundle is most likely the biggest factor in how quickly your users will be able to interact with the page. However, the time the browser spends parsing your code before it can execute might add significantly to that time. Parsing performance seems like a big topic right now. [Addy Osmani](https://twitter.com/addyosmani)
[touched on it](https://youtu.be/7vUs5yOuv-o?t=23m10s) at JSConf EU and [Marja Hölttä](https://twitter.com/marjakh) [gave an entire talk](https://youtu.be/Fg7niTmNNLg) about how Chrome parses JavaScript. If the parsing time you save by optimizing with Prepack outweighs any additional load time due to an increased bundle size, it is worth using Prepack. Otherwise, probably not.

Personally, I was not aware of these performance implications. And having focussed so much on chunk sizes in the build output (see my post on [upgrading to webpack 2](https://codematters.blog/upgrading-to-webpack-2-fc09bd8adbd4) for more details on the topic), I had totally missed the point of Prepack. After some conversations on the topic with other developers, it seems I was not the only one, though.

Prepack is a new build tool from Facebook. It optimizes your application’s runtime performance by eliminating computations known at compile time. What effect does it have on a real-world app?

Test-driving Prepack with webpack 2 

A recount of what I learned upgrading our Angular 1.6 app at work from webpack 1 to webpack 2. Including commons chunks, lodash and D3 optimizations, and tree-shaking.

Upgrading to Webpack 2 — What I Learned Along the Way

At the point of this writing, my Github account has 24 public repositories,
about ten of which could be considered small unfinished or abandoned side
projects. Here are some examples:

- [contentful-utils](https://github.com/felixjung/contentful-utils): a small CLI
  tool to help managing content types and entries on Contentful, a headless
  content management system.
- [carousel](https://github.com/felixjung/carousel): my very unfinished attempt
  to build a nice, responsive, touch friendly slider that I could use on a
  photography portfolio site, which I never started building.
- [twitter-tail](https://github.com/felixjung/twitter-tail)/[twitter-tail-server](https://github.com/felixjung/twitter-tail-server):
  a client/server application that was supposed to let you follow a topic or
  location on Twitter using the streaming API. I started it to get a feeling for
  Angular 2 after attending AngularConnect 2016.

None of these projects are in a state where I would consider them complete. I
still had/have many ideas for potential features. I even went though the trouble
of creating custom colored tags for some of the repositories and created
[lists](https://github.com/felixjung/contentful-utils/issues) of
[issues](https://github.com/felixjung/carousel/issues). I bet there are many
other developers who have this same problem.

We developers have ideas for cool side projects all the time. We like learning
new things and tinkering with new technologies. We want to improve our skills
and fight off this feeling that we are not learning quickly enough — I know this
is at least true for myself. In my experience, however, these side projects
often become too big for what they should be: very small prototypes that allow
us to learn something and feel a sense of accomplishment. We get lost dreaming
up a list of potential features, we will not finish in the little amount of
coding time we have next to work and social life. I have the additional problem
of quickly losing interest, after my initial curiosity for a problem has been
satisfied.

Not completing your projects to a satisfactory level can have several bad
effects. I constantly hear a nagging voice reminding me that I still have not
finished the cool things I wanted to build; that I _never_ finish the cool
things I want to build. I get disappointed and maybe even somewhat anxious about
not advancing my skills quickly enough. Basically, I am unable to follow through
with anything, right? 😔 When you think about it, that’s not true, of course.
These unfinished projects helped me acquire new skills. I did solve problems I
had not faced before. But this does not register.

So what might be a good strategy to help yourself feel happy about these
accomplishments? How can you turn our small projects into successes? I think,
the answer to these questions is: “By finishing”. Because finishing is going to
give you a sense of accomplishment. But how are you going to finish? Was this
not the problem in the first place? Yes, but now you are going to set small
limited scopes for all projects you start. You will figure out the absolute
minimum you need to do in order to

1. learn something new and
2. have something complete to put on the shelf and be happy about.

Whenever you feel the urge to add another feature to a project, put it on a list
for potential future versions. Do not try to add it before your project’s
initial version is complete. This should help you stay focused. If a project
turns out great or you have some actual real-world use for it, you can always
come back to that list of nice ideas.

If you find you cannot complete a project for whatever reason, having a very
small scope will help you not feeling like you wasted a lot of time. Your idea
just did not work out and you can move on to the next.

I for myself, am going to try and follow this strategy. In fact, I wrote this
blog post after finding myself unable to implement a JSON/file-based “API” with
nothing but Jekyll running on Github Pages, this weekend. I wanted to build a
small prototype and write about it. When I found my idea would not work out as
planned, at first, I felt like I had wasted time. Then, I realized I had just
tried something for an hour or two and I could write about my experience.
Suddenly I had this blog post and accomplished something after all. Success! 💪🏻

Developers have great ideas for interesting side projects. All to often these ideas turn into unfinished zombie repositories on Github. Here is how to stop that from happening.

Feeling Good About Side Projects and Experiments

Much has been said and written about the current state of Apple over the past
weeks, months, and even years. Things seem to have gotten more intense since the
release of the new MacBook Pro in November. My perception is that a lot of
people think this year will finally reveal some future the company has chosen
for itself; as the “old” Apple with that unique soul and care for products like
the Mac or as the “new” Apple, expanding horizontally and producing all kinds of
nicely designed but not as innovative/powerful mass market consumer products.

I have been a _very_ happy Apple customer ever since I got my first iPod nano
for Christmas in 2005. Since then I have owned four iPods, seven Macs, one
Cinema Display, both an Airport Extreme and an Airport Express, six iPhones, two
iPads, an AppleTV, an Apple Watch, and a pair of AirPods. I have been following
Apple-related news and rumors and listened to Apple related podcasts. And after
all that, I must admit I feel some of the pessimism over the company’s future
creep into my own thoughts.

Among the pieces I have read on the topic over the past months, I think
[Chug von Rospach](https://chuqui.com/2017/01/apples-2016-in-review/)’s was the
best at analyzing what is currently going on. I can totally identify with the
“niche users” Chug describes

> The problem? This group is fairly small and have needs living well towards the
> end of the bell curve. They are, effectively, a niche within the niche that
> the Mac now finds itself in. Apple seems to have made business decisions not
> to support this group. Why?

In the following, I am going to take some of the topics Chug addresses and add
some of my observations, some of which I have not seen mentioned anywhere so
far. Bear with me, this is going to be a long one.

### Missing Shipping Dates and Not Meeting Demand

> But over the last year or so, we’ve seen a number of products announced with
> shipping dates that were pushed out, and out, and out, or met by small
> shipments that woefully struggled with demand. Last year it was the pencil,
> and now, we’re seeing a similar challenge to ship with the AirPods.

Personally, I do not care too much about Apple having to postpone products. Sure
if they have to postpone more often it is a sign that either their planning or
their execution is lacking. But if they miss a release date once or twice a
year, I do not care. What I do care about is the _extremely_ limited
availability of products once they are released. Last year, I bought the iPhone
7, the Apple Watch Series 2, a 15” MacBook Pro, and a pair of Air Pods. Every
single product was backordered several weeks despite me making the purchase
within minutes (iPhone 7, MacBook Pro, Apple Watch) our hours (Air Pods) of
availability. How is it possible that for basically any new product Apple keeps
struggling with demand? They should be able to handle this by now, no? With the
MacBook Pro I made the mistake of choosing wire transfer as payment method,
because it was a pre-order — my money would surely arrive way before any
shipments would get prepared, right? — and I thought the delivery estimate of
2–3 weeks in the store would be accurate (this was in line with the actual
launch date). What then happened was just frustrating. First, the confirmation
e-mail showed a shipping estimate of 4–5 weeks. When the shipping date
approached, my delivery estimate was pushed back another week and finally it was
set for December 22nd. Meanwhile, friends, who had ordered via credit card later
than me, were getting their new MacBook Pros. What I take away from this is that
Apple kept prioritizing orders, for which they had yet to receive a payment,
over mine. I understand the business logic. But I always thought Apple to have
some moral high ground. This is simply not what I would have expected from them.
They should be better than this.

### Languishing and Discontinued Products

> Apple has products it’s let languish without any significant update for long
> periods of time.

There are many examples for this in Apple’s product line: the Mac Pro, the Mac
mini, the Airport line of routers, the Thunderbolt Display, and — at the moment
— even the non-pro versions of the iPad, iPad Air and iPad mini. Before
November, the MacBook Pro would have been on that list.

I do not understand how Apple can leave these products this unattended for such
a long time. People rely on them. It is simply embarrassing that the Mac Pro,
which Phil Schiller announced with “Can’t innovate anymore my Ass” is still
being sold without any hardware updates in more than 1000 days. Heck, until
recently Apple was still advertising this computer with performance gains in
Aperture, the company’s long discontinued professional photography Application.
Double the embarrassment. Why don’t they just acknowledge these problems? I bet,
if they were more open about this, people like me would totally understand.

<blockquote class="twitter-tweet" data-lang="en">Reminder: The current Mac Pro page brags about the performance with Aperture, a program that Apple retired 2+ years ago: <a href="https://t.co/woJHb50kkE">pic.twitter.com/woJHb50kkE</a>&mdash; Brian Stucki (@brianstucki) <a href="https://twitter.com/brianstucki/status/791671150703091712?ref_src=twsrc%5Etfw">October 27, 2016</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charSet="utf-8"></script>

Same goes for the Airport routers. These were really great routers once. Apple
has not updated them in years and by now there are much better products
available — performance-wise.
[Rumor has it](https://www.bloomberg.com/news/articles/2016-11-21/apple-said-to-abandon-development-of-wireless-routers-ivs0ssec),
Apple is going to discontinue them, too. Chuq notes

> Now, to be fair, I think it makes sense for Apple to stop making WIFI devices;
> the market is established and there are good products in there, unlike when
> Apple stepped in and started selling them.

I disagree. While alternatives such as [Eero](#)(http://eero.com) and
[Google Wifi](https://madeby.google.com/wifi/) exist, these are not yet
available in most markets outside of the US. In places like Germany you still
have to buy ugly, potentially nightmare inducing, routers from PC companies or
an [AVM FRITZ!Box](https://en.avm.de/products/fritzbox/), a product so German
and boring I never even considered buying it. Yes, there is Ubiquity, but their
offerings are more for the professional market.

![Linksys routers on Amazon](https://felixjung.imgix.net/routers.jpg)

So yes, Apple should continue making their routers, in particular if they want
to maybe finally establish HomeKit as a real thing.

### The Nickle-and-diming

This was not part of Chug’s piece, but I think it’s worth discussing, as it has
popped up in other discussions. Apple opponents have often argued, Apple
products are overpriced and you could get equally good alternatives for much
less money. While this has always been true when looking only at specs, Apple’s
products turned out to be comparably priced when considering all their features,
bundled software, and low cost of maintenance. In particular the last point is
so significant that
[IBM apparently saves $273 — $543 per Mac compared to a PC](http://www.imore.com/macs-are-543-cheaper-windows-pcs-says-ibm).
Mac users like me were thus willing to pay the seemingly higher price. We knew
we were getting a significantly better product.

With the most recent MacBook Pro update, I am starting to get a bit frustrated
with Apple’s pricing model, however. These machines are more expensive than they
used to be.
[According to BGR](http://bgr.com/2016/10/28/apple-defends-expensive-macbook-pro-pricing-we-design-for-the-experience/)
the new line of MacBook Pros has seen price increases between between
$200 and $300. In Germany, where Apple is also adjusting to the depreciation of
the Euro against the Dollar, the price increases were even bigger. The 15” base
model is
[apparently €500 more expensive than its predecessor](http://www.giga.de/unternehmen/apple/news/teure-macbook-pro-modelle-die-preise-im-zeitlichen-verlauf/)
(this includes the VAT of 19 percent). That is quite _a lot_ of money. But there
is more. You will end up spending $50-$150 on Thunderbolt 3 / USB-C dongles — I
am 100 percent convinced going Thunderbolt 3 only was the right decision. But
wait, there is more. Apple found a way to charge you more for the power adapter.
A lot of people tend to buy an extra power adapter for their MacBook. It is very
convenient to have one for home and one for work or travel. The 85W MagSafe 2
Power Adapter costs
$79. It includes the MagSafe cable *and* an extension cord. With the new 87W USB-C Power Adapter, this is a different matter. You have to buy *three* separate items to match what is in the box with the old adapter; the power adapter itself (still the same $79),
the USB-C cable connecting to your MacBook to the power adapter
($19), and the extension cord ($19). So the new power adapter comes in at an
extra
$38 compared to the old MagSafe 2 version. Considering all these extra expenses, the new MacBook Pros come in at a significant premium compared to their predecessors. Some people have made fun of Mac users, who spend $2,800
on a new computer and then complain about
$100 extra for adapters. It’s simple not just that. All things considered we are talking up to $500
or even €700 added to the usual cost of upgrading to the latest hardware. Why
does Apple keep raising prices? Yes, they are a publicly listed company. Yes, a
lot of people are still paying these prices. But at some point this simply looks
greedy. Apple could have included adapters and cables in the box with this
already much more expensive MacBook Pro. That would have been the right thing to
do. We have seen the same behavior in the past. The iPod and iPhone used to ship
with a dock, remember? Then someone found out it would help the company’s
profits to remove these “extras”. This time this is happening on a much bigger
scale, though.

### Products Losing Their Soul

One reason a lot of people became Apple fans and fell in love with products like
the Mac and the iPhone was their soul. Apple would always put some extra effort
into their products; add some nifty or playful little feature. Some examples of
this are

- the Mag Safe connector by itself and the charing indicator LED on it,
- being able to configure AirPort routers via an app, rather than a web
 interface,
- the battery indicator pre-retina MacBooks used to have,
- the sleeping LED light of pre-retina MacBooks,
- the seemingly first inline microphone and remote not requiring a special
 connector on the iPhone’s headset,
- the various connectors on the Thunderbolt Display,
- the asymmetrical fans in the retina MacBook Pros, or
- the pairing mechanism used by the AirPods.

But a Mac fan like me sees this list and notices all the delightful features and
products that have been removed or discontinued without an adequate replacement.
I remember getting my first MacBook Pro and keeping connecting and disconnecting
the Mag Safe connector. To me, coming from an Asus notebook, this was magic.
Likewise, you could buy a Cinema or Thunderbolt Display and have this amazing
screen that opened a world of possibilities for your MacBook with just a single
cable connecting the two. Back then, nobody else provided features like this.
Now we have USB-C and you can get similar solutions from regular PC vendors.
Probably this is why Apple stopped producing their own displays. Other products
were deemed good enough.

That’s the thing, though. People used to fall in love with Apple products,
because they were never just good enough. With the AirPods Apple has kind of
shown they are still capable of delivering true innovation and magic. But why
should “old” products loose all their magic, their soul? Why does Apple seem to
be caring less about putting a smile on people’s faces when they notice a
magical little feature? Apple needs to get this back! It is the differentiating
factor making people passionate about the company.

### Why There Still Is No Reason to Abandon Ship

Like Chug, I do not think all is lost. By far not. And despite a lot of posts
about people trying Linux or going back to Windows have been popping up, I feel
switching is not a viable option. First, other hardware simply is not designed
as nicely. Turns out, I do care how my computer looks and feels. Secondly, I do
not want to buy a laptop, then try to get Bluetooth, Wireless, and what not
working and probably fail in some instances. And what about a consistent nice UI
where all apps at least have a similar design language? What about all the
awesome apps you can find on macOS, that happen to come with an iOS, even an
Apple Watch companion? The [Omni Focuses](https://www.omnigroup.com/omnifocus),
the [Tweetbots](https://tapbots.com/tweetbot/), the
[Reeders](http://reederapp.com/mac/), the [Sketches](https://sketchapp.com), the
[Towers](https://www.git-tower.com/mac/) and the 200 other amazing apps made by
indie developers? Am I supposed to settle for
[ugly UIs](http://corebird.baedert.org/scrot1_1.4.jpg) and webapps? I just do
not think Apple’s hard- and software have gone even 10 percent down the hill at
whose end I will switch to Linux — yes, at this point I would only consider
Linux. A colleague of mine uses Windows 10 for web development. Basically every
time we make a change to the build tools of a project, it will fail on his
machine. We will spend hours trying to fix it, eventually finding some obscure
workaround or finding that a reboot will fix things. Seriously? 😳

So, I feel the pain and I wish things were a bit different for the hardcore
Apple user, but there is a long, long, long way to go before I would even
consider another platform. And who knows, maybe we will see another “Can’t
innovate anymore, my Ass!” from Phil in 2017!?

On Apple

When you are a developer and hacking together some scripts for yourself, there
is no immediate need to care about the quality of your code or its style.
Likewise when you are using Git to maintain some small personal project, why
should you are about things like commit messages or even pull request titles —
who creates branches in personal projects anyway, right?

It is easy to see it this way and keep on hacking together a bunch of code. Keep
on committing with messages like “Bug fixes”, ”More bug fixes”, ”More bug fixes
2”. _Every_. _Single_. _Time_. After all, it is just some side project, right? I
think most developers, myself included, have told themselves something along the
lines of “Ah come on, who cares. I’m just going to commit it like this.” before.
But you know what? I strongly believe every time we do that, a tiny part of the
better developer most of us want to become goes into a corner and dies. 💀

A big part of becoming a better developer is experience, sure. Write enough
lines of code in different languages and for enough problems and you will have a
pretty good idea of what you need to do most of the time. But this is only part
of the story. Another huge part, maybe equally as important, is caring about how
you write all that code; how you commit your code, too. Whenever you write code,
at every step, ask yourself: “Is there a better way to do this?”. Some examples:

- “Does this function or variable name communicate its meaning as precisely as
  possible?”
- “Instead of using this if-else block, can I maybe just use an if block and
  return early?”
- “Can I generalize this bit of code and make it a function instead of repeating
  myself all over the place?”
- “Is the piece of code I’m about to commit an atomic unit? Should I split it
  into multiple commits?”
- “Is my commit message easily understandable? Does it accurately summarize the
  changes in this commit? Can I make it even more concise?”

Always challenge yourself when you code. You might not find the perfect answer
to the above questions right away, but asking them and doing your best to
improve will eventually make you a better developer.

But it does not stop there. Not only will you become a better developer, other
contributors to that open source project you have been helping out on and your
colleagues at work will benefit, too! 🙋🙋🏾‍♂️ More examples:

- The junior your team just hired will be able to read your code and learn from
  it more easily!
- When you go on vacation and people find a bug in the code you committed just
  before leaving, they can quickly identify the commit that introduced it
  (remember, concise commit messages) and revert it (you made a nice atomic
  commit). You can take care of the problem once you get back.
- And that huge new feature branch you had been working on for months before it
  was squash-merged can also be reverted because you named your pull request
  nicely and even included the ticket number from whatever ticket system you
  poor soul have to use at your company — yes Jira, I am talking about you.

So yeah, just give a damn about this stuff. You will be a better developer for
it and people will enjoy working with you. Everybody wins. 🎉 Pro tip: this is
true for most things in life.

When you are a developer and hacking together some scripts for yourself, there is no immediate need to care about the quality of your code or its style. Think again.